Steve Brewin wrote: > Noel J. Bergman wrote: > > I agree that dynamic reconfiguration is a container issue. I > > am not sure that we need to do anything with Mailets. I think > > that we can stick with the processor is a the configurable > > entity, or possibly even just the spooler.
> The spoolmanager, and hence mailets, would be restarted to pickup any > configuration changes > Done this way the Mailet API does not change, but it places a much greater > onus on mailets to free resources in the destroy() method as this cycle Works for me. I think that is a perfectly reasonable requirement. > > > Yes, the matcher/mailet syntax issue does need to resolved. > > I think we had a consensus on it, recorded in the wiki. > Where is this consensus recorded? I only see > http://nagoya.apache.org/wiki/apachewiki.cgi?JamesV3/MailetConfiguration > which documents three proposals, but no outcome. We can revisit it, but we had settled, IIRC, on proposal #1. The use of <parameter name=""> instead of <name> requires a change, but was considered desireable because it would allow scheme validation. Proposal #2 was rejected, as Danny is strongly against such complicated XML representation. Anything more complex than handled by proposal #1 was going to be exposed via JNDI. > > That should allow the use of BSF. Also, I think that > > it makes sense to consider a Jelly processor... > Once the new mailet syntax is in place Jelly should probably > be included in an update of the scripting support. I am thinking that we could have a JellyProcessor, e.g., <processor name="custom-stuff" class="org.apache.james.transport.JellyProcessor"> ... </processor> allowing the script to handle its own matching and functionality. When you look at something like sieve, this also makes sense. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
