james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter M. Goldstein" <peter_m_goldst...@yahoo.com>
Subject RE: JAMES SMTP API sub-project proposal
Date Sat, 23 Nov 2002 05:57:40 GMT


Noel et al,

> > Unfortunately [embedding] is a limitation of the Avalon framework
> 
> Actually, Merlin and Fortress are embeddable or going that way, so I
don't
> view that as an issue.  Remember, Cocoon embeds inside of Tomcat.

Agreed.  Embedded containers are one of the big themes on the Avalon-dev
list, third on the list after discord and sarcasm.  :)

Moreover, there is an EJB container that is embeddable inside Phoenix,
there is an active effort to embed Tomcat inside Phoenix, etc.  So not
only is the idea to embed Avalon framework containers inside other
containers, but also to embed other types of containers (EJBs, servlets,
etc.) inside Avalon framework containers.  It's almost Escher-esque.
 
> I don't think that the current version of James gets down to quite as
trim
> a
> package as we can build a mailet container, but that doesn't mean that
we
> need a separate codebase.  Let's just accept as a request for v3 that
> being
> able to embed a mailet container is a good thing, and see where that
takes
> us.

I agree.  But my approach would be to delegate the embeddedness to our
Avalon framework container.  There should be nothing in the Mailet API
that prohibits such embeddeding, but I don't think we need to re-invent
the wheel.  Merlin/Fortress/Avalon Container++ can handle this.

> Personally, I have some ideas but we'll see how this falls out.  I
will
> point out that you appear to be leaning towards making Avalon a part
of
> even
> embedded Mailet Containers.  I'm curious to see how Danny and Peter
> respond.
> And, of course, if I am wrong please clarify.

I actually (as I've mentioned before) really like the Avalon framework
lifecycle.  That said, I don't see any reason that we should build rings
within rings.  With the theme of not reinventing the wheel, I don't
think we need to re-implement Phoenix inside Phoenix.  The mailet
container doesn't need to support components of arbitrary complexity,
provided it has an effective API for getting other components in the
larger container (Avalon or another type of container).

For example, the RemoteDelivery mailet could be rewritten as a more
lightweight, single threaded class that passes the mail to a
RemoteDelivery component that is managed directly by Phoenix.  This
would allow the mailet to be kept nice and simple, the RemoteDelivery
component would be made easily pluggable, and the component could take
advantage of features of the container (i.e. JMX) that we might not want
to expose directly through the Mailet API.  This approach seems very COP
to me.

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.

But after 2.1 goes out we'll see what Danny's got written up and start
from there.  If it provides the same basic functionality as the Avalon
lifecycle phases above, that would probably be ok with me. 

--Peter
 



--
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