james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: [PATCH] Replace Components with Services
Date Wed, 25 Sep 2002 08:24:59 GMT
> For my part, I don't really have a tremendous objection to a tighter
> coupling between Avalon and the Mailet API.  I know that some do,
> because they want to see the Mailet API become a server-independent
> standard.  I respect that opinion, but it's not the reason I'm voting
> against this as a long term proposal.  I'm interested in James as an
> enterprise quality mail server, not in the Mailet API in the abstract.
> If the mailet API were to incorporate some subset of the Avalon
> lifecycle, I'd have no objection in principle.

I don't object to the avalon framework lifecycle, the alternative would be
to provide our own lifecycle framework which would needlessly duplicate
Avalon work.

> I do object however to an attempt to slip things in the back door.  The
> current situation is the worst of both worlds.


> We're tightly coupled to
> the Avalon lifecycle framework (see the current situation), but gain
> none of its benefits.  There is no ordered lifecycle, no well defined
> series of events.  There isn't even a wrapper method for the
> MailetContext to ensure that when we get the ComponentManager /
> ServiceManager we're actually getting a ComponentManager /
> ServiceManager object because that would introduce Avalon classes into
> the Mailet API.  That's supposedly a guarantee of the container, but it
> can't be a real guarantee because not every Mailet container is
> necessarily an Avalon container.  So these mailets aren't really
> portable even though their interfaces all say they are.  Arrgh.  But we
> don't have any Avalon interfaces in our API, so we're Avalon independent
> (wink, wink).  Double arrgh.

+1 IMHO we need to introduce avalon independant interfaces into the Mailet
API, and implement those ourselves using Avalon.

IMHO also we need to introuduce greater control over the mailet classpath to
enfoce this independance. If you view the mailet chagelog you'll see that
work has already been done to seperate Mailet from Avalon, IMHO this needs
to be taken further, and James is then free to use Avalon to provide
services specified by the Mailet API.

> iii) Do it all ourselves, making a more rigorous lifecycle for the
> mailet and write adaptors for the relevant Avalon classes - probably the
> least objections from those who want the Mailet API to be independent,
> adaptors might be tricky

As an "objector" I'd agree with this approach.

> Anyway, that's why I'm voting -1 on simply replacing ComponentManager
> with ServiceManager for the long haul.  I understand we may need to do
> it temporarily.  If we do, I want us to commit to coming up with some
> sort of acceptable solution by a given date/release.  Otherwise I'll
> vote against the change.

+1 I agree. The alternative is to go for Mailet 2.2, ensure it offers enough
to make Mailets truly portable, then make subsequent releases of James
support Mailet2.2.

I don't see a problem allowing James to ship with mailets which aren't
portable, but we have to provide a good enough API for 3rd party developers.


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