> > I believe that adding Jelly support to the current Mailet > > container is a better route than creating a new container. > > Why? The current container knows, or will know when some > code is moved out > of JamesSpoolManager, how to initialize its matchers and > mailets from its > own XML configuration element. Its behavior is to initialize > and manage > matchers and mailets. It has some specialized code in it for > ensuring that > when we get to the end of the chain, there is code there to > handle the "fall > off" condition.
Hmmm. I wonder if your response would have been different if I had said what I meant to say! Try... > > I believe that adding Jelly support to the current Mailet container < < via a Matcher and Mailet > > is a better route than creating a new container. This allows the existing mail flow to be leveraged if required. If not required, as has been noted elsewhere, a single Jelly Mailet could establish its own environment and do whatever it wanted. -- Steve - - - - - - - - - - - - - - - - - - This private and confidential e-mail has been sent to you by Synergy Systems Limited. It may not represent the views of Synergy Systems Limited. If you are not the intended recipient of this e-mail and have received it in error, please notify the sender by replying with "received in error" as the subject and then delete it from your mailbox. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
