Serge Knystautas wrote:
>
> 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)
Perfectly!
I've already wrote some of the classes you've defined and they're almost
identical.
I will move Vector recipient to InternetAddress[] recipients.
About MailServletConfig I was thinking to make MailServlet extend
Configurable and so the could get their init parameters as
Configuration. Configuration is quite easy to use:
long myLong = conf.getConfiguration("my_conf").getValueAsLong()
IMHO logging should be done inside the AbstractServlet itSelf:
public abstract class MailServlet {
...
void log(String msg) {
...
}
}
and any other feature common to all MailServlet should be included in
the abstract class. There is no reason to split it in two classes.
On the other hand even a quite empty MailContext could be useful. It
should be shared amongst group of MailServlet. I'm not sure it could be
of some use but... let's think big this time!
>
> > 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.
Hehe... and I'm continuing ripping!
Take a look at the newest code!
I'm moving to javax.mail but as you've noticed some classes need to be
reimplemented for optimization... maybe later...
>
> Serge
>
> ------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/>
> Problems?: [EMAIL PROTECTED]
--
Federico
*-----------------------------------*
"Troubles occurr when two people try
to be intelligent in the same time."
- Murphy
*-----------------------------------*
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/>
Problems?: [EMAIL PROTECTED]
