> 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." 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.
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.
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.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
