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]