Getting the most mileage out of this class... multiple output "pipes"

[Mike Curwen]

So I'm trying to create a few re-usable library classes for my workplace.

One of these is a MailEngine. Basically a fairly thin wrapper to the JavaMail api.

The class so far looks a little like:

package com.gbim.mailer;
 
public class MailEngine {
  
   public static MailEngine getMailEngine() {
       // get a mail engine with defaults
   }
 
   public static MailEngine getMailEngine(Properties p) {
       // get a mail engine with selected properties overriden
   }
 
 
   public setFileLogger(File f) { 
        // set the file to be used to log progress
   }
 
   
   public String sendPersonalizedEmail(String to_email, String to_name, String t_email) throws MessagingException {
return "";
}
 
   public String sendGenericEmail(String to_email, String to_name) throws MailerException, MessagingException {
return "";
}
 
}

I have a few static "factory" methods to retrieve a Mail Engine. Once you have it, you'd use either of the two methods shown.

One is used for a generic message, it just needs the recipient information. You've previously called a method called "setMessageBody(String s)" (not shown)

The other is a personalized message, and you send the recipient info, plus the email body into the method.

This is basically a class to do a bunch of emails at once. (many of the fields like from email and subject are all the same, only the recipient and potentially the body of the email are different between calls to the 'send' methods). So the from and subject, etc... are set (and overridable) using the factory methods.

But now.. I'm trying to figure out the best way to design how this class reports back its progress, keeping in mind that it could be used from a command line, from an app, or from within a servlet.

I currently have it outputing to a log4j logger. This is a default property that you could override with the parametized factory method. There is also the 'setFileLogger()' method, which will (I hope) switch the file that log4j sends it log messages to.

But what about for use in a servlet ? I want to maybe output (and flush) to a ServletOutputStream. So then I thought that I'd make a sendXXXEmail method that takes an OutputStream. That way, at least, it could be used on any kind of output stream.

And then I thought "well, maybe it should just return a String", and the client of this class is responsible for flushing that back to the output stream or doing whatever it wants with the information.

And then I thought of custom events/listeners etc. Whoever wants to be told about the email activity will register themselves as a listener, and from within the sendXXXMail methods, a MailEngineEvent will be raised.

But my question is: what is the best over-all approach, while skewing the class towards web apps (because that's what we do here, generally)

The output stream might get really tedious. What if the email list is 1000 long? You really wanna sit there that long? you really wanna flush after every single line?
If it's an overly long process, perhaps handing it off to a 'worker' thread is the answer. The client can then receive a response like : "the job is in progress click here for a progress report." And I imagine somehow that the 'here' link would give me the log4j file.

Would a event/event-listener scheme be appropriate for servlets? I mean, who is the listener? the request? (surely not).

And finally, the other consideration is that this class should be re-usable in an 'offline' fashion, say from a scheduler like
quartz. I imagine this would benefit the most from an event-listener approach.

Hmm... did that seem a bit scatterbrained? It's because I'm trying to make this class VERY easy to use and usable almost anywhere, and able to be quite chatty.

[William Brogden]

I would certainly make the function(s) that actually contact your mail server run in a separate Thread. You don't want the servlet response to be held up if the mail server is feeling cranky.
You also need to provide for holding on to the mail if the server is down completely - a collection of unsent messages for example, that can be serialized out to disk.
Bill