On Friday 25 June 2004 03:51, 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." 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.
I would not mind putting that on my list, well I guess most stuff that concerns RemoteDelivery has my interest ;-) Do you have more detail of how you envision this requeing service? --Søren > > --- Noel > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Søren Hilmer, M.Sc. R&D manager Phone: +45 70 27 64 00 TietoEnator IT+ A/S Fax: +45 70 27 64 40 Ved Lunden 12 Direct: +45 87 46 64 57 DK-8230 Åbyhøj Email: soren.hilmer <at> tietoenator.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
