james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Murdoch <adammurd...@apache.org>
Subject Re: JAMES SMTP API sub-project proposal
Date Sat, 23 Nov 2002 06:41:26 GMT
On Sat, 23 Nov 2002 03:57 pm, Peter M. Goldstein wrote:


> To achieve this end, I'd like a Mailet API that either uses or copies in
> another package the equivalents of the Contextualizable, Composable,
> Configurable, Initializable, and Disposable interfaces.  I'll leave the
> logging question alone for the moment.  I don't think we need any of the
> other phases of the Avalon Framework lifecycle (Startable,
> Reconfigurable, etc.).  So I don't think the Mailet API should be a full
> Avalon Framework container.

Avoiding using Avalon Framework in the Mailet API is a good plan, I feel.  The 
API already has equivalents to most of the lifecycle interfaces you list 

* Mailet.init() and destroy() give you Initializable and Disposable.

* MailContext.getAttribute() gives you Contextualizable (as do the other get 
methods on MailContext).

* Composable can be done with a simple lookup method on MailetContext:
    Object getService( String roleName );
  or, perhaps better:
    Object getService( Class serviceInterface );

* Configurable could be done using MailetConfig's init parameter methods.  
Some way of getting at structured config would be better.  It doesn't 
necessarily have to be done via MailetConfig.  A good approach might be to 
configure the mailets (and maybe the matchers, too) using a 
reflection/javabean based scheme similar to the way Ant configures its tasks. 

Just out of interest, how much scope is there in v3 for changing the Mailet 
API, and the way james is partitioned into components?


To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message