Federico Barbieri wrote:
> Not sure about it... What a MailServletContext could be used for?

I meant to say MailServletConfig, not MailServletContext.  The servlet
config provides parameters to the servlet, and the servlet context is a
shared instance across all servlets that give access to server level
info/features.  State would be specific to that message being filtered. 
Here's a quick rundown of what I think the API should be...

//This needs to be an abstract class (not an interface) so that it
support
//handling initialization parameters, logging, whatever else
public abstract class MailServlet {
    //initialize the servlet and pass this config variable
    public void init (MailServletConfig config);
    //filter this message
    public abstract void service (MessageContainer container);
    //clean up
    public abstract void destroy ();
    //generic info
    public abstract void getServletInfo ();
    //specific to servlet instantiation
    public MailServletConfig getServletConfig ();
    //shared by all servlet instances
    public MailServletContext getServletContext ();
    //any init parameters... not sure with the XML document if this
should be a 
    //hashtable like javax.servlet, or whether we should just provide a
DOM fragment
    public String getInitParameter (String name);
    //or
    public Document getInitParameters ();
    //generic logging
    public void log (String msg);
    public void log (String msg, Throwable t);
}

//this is server level info/features passed on a servlet's init call
public interface MailServletConfig {
    public String getInitParameter (String name);
    public Enumeration getInitParameterNames ();
    //or a document fragment...
    public Document getInitParameters ();
    //also to access the servlet context
    public MailServletContext getServletContext ();
}

//shared across all servlets
public interface MailServletContext {
    //Returns the resource that is mapped to a specific path
    public URL getResource (String path);
    public InputStream getResourceAsStream (String path);
    //Generic server info
    public String getServerInfo ();
    //logging support
    public void log (String msg);
    public void log (String msg, Throwable t);
    //possible shared attribute info??  necessary??  certainly doesn't
seem hard
    public Object getAttribute (String name);
    public Enumeration getAttributeNames (String name);
    public void removeAttribute (String name);
    public void setAttribute (String name, Object object);
    //And the james/mail specific functionality...
    public void sendMessage (MimeMessage message, InternetAddress
recipient);
    public void sendMessage (MimeMessage message, InternetAddress
recipients[]);
    public void sendMessage (MimeMessage message, State state);
    public void sendMessage (MessageContainer container);
}

//This contains the State and Message object and is passed into the
service method
//of mail servlets
public class MessageContainer {
    public MessageContainer (MimeMessage message, State state);
    public MessageContainer (MimeMessage message, InternetAddress
recipient);
    public MessageContainer (MimeMessage message, InternetAddress[]
recipients);
    public MimeMessage getMessage ();
    public State getState ();
}

//This is information that accompanies the email message... initially
just
//the list of recipients
public class State {
    public State (InternetAddress recipient);
    public State (InternetAddress recipients[]);
    public InternetAddress[] getRecipients ();
    //this is for simple "session" information... so info can be shared
across servlets
    //about a given message
    public Object getAttribute (String name);
    public Enumeration getAttributeNames ();
    public void removeAttribute (String name);
    public void setAttribute (String name, Object object);
}

MimeMessage is straight from the javax.mail API, although the actual
implementating will probably be an extension of that since the
javax.mail implementation is geared towards client use (overwrites the
Message-ID header, and many other bad things for a server to do). 
(phew, that was a lot of work... hope this came across cleanly in the
email)

> It's still a bit rude but the Store interface implemented by
> avalon.blocks.masterstore.MasterStore could be a good starting point. It
> provide a simple mechanism to build Repository and these Repository are
> pluggable. So since default Repository are Object and Stream, James
> plugs its own MessageContainerRepository and use it.
> I'm planning to write a Repository implementing javax.Folder to better
> fit standards.
> 
> Planned Repository are: TransactionalRepository, SQLRepository,
> XMLRepository etc.
> Pay attention in the masterStore: if you define in configs a public
> Repository name "Inbox" and the ask for a Repository named
> :Inbox.scoobie" a new Repository is generated and it will be public as
> the parent.

Sounds great.  I'll try to look at that code this weekend... I still
have some patches to make at some point, but it looks like you've ripped
out so much from the tree, it'll be easy to just add it in once we're
ready.

Serge


------------------------------------------------------------
To subscribe:        [EMAIL PROTECTED]
To unsubscribe:      [EMAIL PROTECTED]
Archives and Other:  <http://java.apache.org/>
Problems?:           [EMAIL PROTECTED]

Reply via email to