james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 21:53:33 GMT
Noel

>[...]
>Now, back to your other question "what is the other mail server going to do
>since it does not support the concept [of inboxes or repositories]?"
>
>The answer is that it depends.  It depends upon how we specify things.  This
>is part of the challenge.  Right now, the Mailet requires a store component
>from the context:
>
>  compMgr =
>getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
>  MailStore mailstore =
>compMgr.lookup("org.apache.james.services.MailStore");
>  
>
-1.  I'd vote for MAILETS implementing Composable or Servicable :---

 MyMailet implements Mailet, Composable {
    MailStore ms;
    Blah processMailRequest(Blah blah) BlahException {
       return null;
    }
    public void compose(ComponentManager cm) throw ComponentException {
      ms = cm.lookup("org.apache.james.services.MailStore");
    }
 }

It is better IoC.

MailetContext should be specific to things that are peculiar the 
mail-context.

>As I understand it, the Avalon "Best Practice" on this would be to have
>Mailet components be composable.  If the configuration for the component
>said that it needs the MailStore service, the container will (a) know, and
>(b) make it available early in the component's lifecycle.
>  
>
Ohh blimey, I should read ahead in mails.

>I believe I am correct about this (and this also seems to be Nico's
>suggestion).  If so, I hope that Paul's example Mailet Container, which he
>has indicated he will post, will illustrate this point.
>  
>
Gawd, this is gunna be heavy for me to write ;-)

>As to the nature of Repositories and Stores, we already have interfaces for
>UsersRepository, MailRepository, SpoolRepository, MailStore, etc.  If those
>are sufficient, then we just use them with composable mailets.  If not, then
>perhaps the most flexible approach would be JNDI with some specific helpers
>to make life easier.  Some aspects of JNDI make sense (keyed access to node,
>dynamic keyed attributes on node), if we can keep it SIMPLE for simple
>cases.
>  
>
A lot of people are beginning to think of JNDI as part of the problem, 
not part of the solution.

>The problem isn't that Avalon-Framework has a failing.  The issue is whether
>we are willing to mandate that Mailet containers must support the Avalon
>programming model, as proposed for JSR 111.  As I understand it, this
>requirement does not impose significant development requirements on the
>container, but does result in benefits.  We'll see at the weekend, when Paul
>provides his proof-of-concept container.
>  
>
Gulp, me again ;-)

>>Frankly, I don't feel smart enough to know what the best solution is,
>>so I don't want to add logging to the mailet API and impose my
>>technical opinions on other mailet developers.  I don't think it's
>>appropriate to say SHALL.
>>    
>>
>
>If we go with the Avalon model, then if someone didn't like interface A, and
>came up with a better A', they can instrument the container to support both
>components that use A, and components that use A'.  This future-proofing is
>one of the benefits.
>
People like our API so much it is cloned all over the place.  Typically 
they do not like the work apache in the package name.  For thise that 
do, but still clone, they don't like the word Avalon.  It is changing 
now though.

-ph




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


Mime
View raw message