Noel J. Bergman wrote:
> > While I agree that we should be container neutral, it would
> be good to
> > accomodate the extended, but optional, Avalon lifecycles
> into a reworked
> > Mailet API so that it can be leveraged when available.
>
> I would be -1 regarding any contamination of the Mailet API
> with container
> specific interfaces. But I do concur that we want to support dynamic
> reconfiguration. That is something we can all collaborate
> on, that is more
> of an issue for a Mailet Container than the Mailet API. I
> believe that we
> already have enough in the Mailet API to support destroying
> and re-initing
> Mailets. As you already noted to Stephen McConnell, "The
> current Mailet
> lifecycle is init, service, destroy. To reconfigure, the
> container could
> simply send a destroy followed by an init to effect
> reconfiguration."
To be clear, personally I am not proposing "any contamination of the Mailet
API with container specific interfaces". In truth, I am not currently
proposing anything, just exploring possibilities. Adding the reconfigure()
lifecycle state to the Mailet API, a specialization of it or as a discrete
interface, is simply identifying a possible requirement for new Mailet
behaviour, in addition to the current lifecycle states of init(), service()
and destroy(). That Avalon container interfaces include something similar is
by the by. Common concerns often lead to common solutions.
Agreed, the current Mailet API can support reconfiguration. My point was
that it may not always be the optimal way to do so. As examples, I gave
having to destroy and reinitialise expensive resources and losing context
while conversing with an external application. Here we could do more. In a
much earlier thread on this, we identified some James resources we would not
want to recycle during reconfiguration, or would recycle less brutally than
via a destroy/init cycle. The proposed reconfiguration state propogates this
option to Mailets. How it is achieved is another matter.
As other Mailet environments may not support reconfiguration I suggested it
be optional, perhaps achieved by a specialization of the Mailet API such as:
public interface org.apache.mailet.ReconfigurableMailet extends Mailet
{
reconfigure(MailetConfig config) throws javax.mail.MessagingException;
}
This would allow ReconfigurableMailets to play in a vanilla Mailet world
while allowing reconfigurable containers to distinguish between vanilla
Mailets and ReconfigurableMailets.
Alternatively, a family of non-mandatory discrete interfaces could be used.
For instance, for 'reconfigure'....
public interface org.apache.mailet.Reconfigurable
{
reconfigure(MailetConfig config) throws javax.mail.MessagingException;
}
...which is logically similair to the 'reconfigure' system event for
Listeners discussed below.
> The Servlet API demonstrates that we don't need more than that in
> the Mailet API
> to support reloading. And if/when we do add things, I would adopt a
> Listener interface approach, just as is done in the Servlet
> and Portlet
> APIs. The events would be in the Mailet domain, not a
> container domain.
As an alternative to incorporating non-mandatory states by specializing the
Mailet interface or adding new interfaces, using Listeners is an interesting
alternative. Still, those Listeners have to listen via an interface, so we
would still be adding something, such as an EventMailet specialization of
Mailet or a new discrete Event interface. I would favour the latter as there
is no true dependency on the Mailet interface.
In order to maintain Mailet portability when using Listeners, we would need
to reserve an event namespace for system events, and declare events such as
'reconfigure' within it. Other private event namespaces could do as they
wished but would lose portability, much as they would if they specialized
the EventMailet or Event interfaces mentioned above.
Which, if any, approach to take? New requirements will come along so some
kind of extension mechanism is attractive, regardless of the driver being
support for a 'reconfigure' event or something else. Listeners and discrete
interfaces are both able to accomodate these requirements, so I'm neutral as
to which.
> A key design area is the Mailet container, which is currently
> a Processor.
> We need to look at that, and decide whether we can merge Processor and
> Mailet; if we need to (and can) have Processor extend Mailet;
> if we can use
> some additional Listeners to allow dynamic reconfiguration of
> a Mailet;
> etc., but I would not tie this into the Avalon lifecycle
> except with an
> adapter. Nor would I require Mailets to register, anymore
> than Servlets or
> Portlets have to register if they have declared listener interfaces.
Merging Processor and Mailet would be nice. Putting my jSeive hat on for a
moment, an important element of any changes is to ensure that the Processor
API is agnositic, enabling the plugin of Mailet, jSieve or any other kind of
mail processing engine. Each engine should have visibility and callability
to <processor> level declarations. This will enable a jSieve Processor to
reuse Mailet logic expressed within a Mailet Processor rather than having to
reimplement the logic for every jSieve command that performs the same
function as an existing Mailet or Mailet chain. jSieve gets lots of commands
for free! And while jSieve is server neutral, James gives it such a big
helping hand behind the covers that it becomes the clear server of choice.
> On a related note, as I believe I've mentioned I'd like to
> change the way
> that RemoteDelivery works. Rather than have RemoteDelivery
> handle its own
> queuing, I'd like to push that out a level so that any
> matcher/mailet can
> benefit from that capability. For example, if a DNSRBL
> matcher failed, the
> operation could be requeued.
I agree. Exposing the served resource and making RemoteDelivery, DNSRBL and
anything else consumers makes sense. This should be the rule for all
resources, and generally is with a few exceptions such as this.
-- Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
