tags:

views:

146

answers:

1

I need to share java mail message objects between two web applications(A and B).

WebApplication A obtains the message and write it to the outputStream

for(int i=0;i<messagesArr.length;i++){
  uid = pop3FolderObj.getUID(messagesArr[i]);
//storing messages with uid names inorder to maintain uniqueness
  File f = new File("F:/PersistedMessagesFolder" + uid);  
  FileOutputStream fos = new FileOutputStream(f);
  messagesArr[i].writeTo(fos);
  fos.flush();
  fos.close();
}

Is FileOutputStream the best output stream for persisting message objects? Is it possible to use ObjectOutputStream for message object persistence?

WebApplication B reads the message object via InputStream

FileInputStream fis = new FileInputStream("F:/MessagesPersistedFolder"+uid);
MimeMessage mm = new MimeMessage(sessionObj,fis);

What if the mail message object which is already written via WebApplication A is not a MimeMessage? How can I read non-mime messages using input stream?

MimeMessage constructor mandates sessionObj as the first parameter? How can I obtain this sessionObj in WebApplicationB? Do I have to again establish store connection with the same emailid,emailpassword,popserver and port(already used in WebApplication A) with the email server inorder to obtain this session object? Even if obtained, will this session object remains the same as that of the session object which is priorly obtained in WebApplicationA?

Since I am using uids to name Message objects (inorder to maintain uniqueness of file names) how can I share these uids between WebApplication A and WebApplication B? WebApplication B needs the uid inorder to access the specific file which is present in "F:/MessagesPersistedFolder"

Please help me in resolving the aforeseen issues.

+1  A: 

What are the actual features you are trying to implement here? It sounds like you're trying to fit a square peg (the Javamail message classes) in a round hole (the requirement to share message data between two applications).

My advice would be either:

1) use a message queue and send the email message content from one application to the other using a javax.jms.TextMessage.

2) or save the message content to a clob field in shared database that both applications access.

At the end of the day, use the Javamail API for sending email not as a means to share data.

Also using serialization, which is what you'd be doing with an java.io.ObjectOutputStream will produce files that will only work with a specific version of the Javamail API and while I doubt Javamail changes much these days, I wouldn't want to exclude the possiblity.

Nick Holt
I'm developing a email client web application which will be communicated from a mobile for new emails.In the web app, there are 2 resource intensive classes. 1.MailGetter (iterates over the numerous emailids provided by user and obtains emails for emailids) 2. MailFormatter (parses Multipart content into simple text by removing html tags which will be sent to mobile and and this class also downloads bulk attachments)So I'm trying to implement MailGetter and MailFormatter as 2 web applications which will be in different servers. So I need to share message objects between these applications.
jezhilvalan
I'm assuming you want to store the 'simple text' and 'attachments', in which case, I'd be inclined to define domain classes and store the data in a database (which will take care of lock contention between the two web-apps on the data). The MailFormatter then becomes responsible for retrieving messages (using Javamail), converting to and storing instances of your domain classes. MailGetter's 'emails for emailids' then becomes a query, rather than an iteration in your code. The result being a common jar that contains the domain classes and DAOs, which is used by both web-apps.
Nick Holt
thanks for answering.Can you please illustrate the domain classes? What are these classes? So MailFormatter after obtaining emails from remote persists email headers, concised email body content and attachments in database.MailGetter queries the db for recently arrived email data. Am I comprehending it right? Can you please illustrate your concept?
jezhilvalan
Domain classes are normally identifiable from the nouns in your description. From what you've said likely candidates are EmailHeader, EmailBody and Attachment. Each domain class should contain one or more attributes (accessible via getters and maybe setters) and maybe some behaviour. For each domain class I'd typically write a DAO that is used to read and write instances of the domain classes to and from the database. The domain classes would be packaged into a single jar that is then used by both your MailGetter and MailFormatter. Make sense?
Nick Holt
jezhilvalan
Also in such scenario aren't we overloading MailGetter class with too much functionality?Obtaining the email,parsing the email message object and persisting the EmailBeanObject to DB via DAO.MailGetter also need to download bulk attachments.Suppose if MailGetter is iterating over 5 email ids which are provided for monitoring and presume MailGetter is currently downloading 10 MB attachment for first email id,new emails for the remaining 4 email ids will be obtained only after the completion of current download.How can we overcome such time consumptions?
jezhilvalan
Since DAO is a standalone class I can package it in a separate jar and use it in both MailGetter and MailFormatter web applications.Currently I am using filesystem to store emails.If I start persisting email content in database(MySQL),upto which extent I can store? This email system will be handling 1000+ users who are going to provide 10+ emailids for monitoring.I am using filesystem since bulk data can be stored in it,and even in need of additional space new hard diskettes can be added.
jezhilvalan
Sounds right in relation to the Domain classes. With DAOs I normally call the method load and save. You may have more than one load method, for example loadEmailsForEmailIds, dependent on your exact needs.
Nick Holt
With regards to the MailGetter becoming 'overloaded' I had seen that as the application, rather than a single class. You'd probably want to use a factory class to parse the Javamail message classes and create instances of the domain classes. The DAOs take care of the DB access and Javamail deals with the interaction with the Mail server. You'll need an application class that orchestrates between these classes but is should always delegate any real work.
Nick Holt
The downloads from the mail server should be taking place on another (lower priority) thread, probably under the control of a scheduling API such as Quartz. Requests for the existing emails should be processed on another thread controlled by the web-server.
Nick Holt
MySQL will be more than capable of handling your data requirements, use CLOB and BLOB fields for the email text and attachments respectively. While I'd still advise using a database, you could even continue to use the file system if you wanted, that would simply be down to your DAO implementation.
Nick Holt
To me jms is the best choice
Suresh S