Being pass� is no reason of itself to "change the Mailet API". I'm sure I'm being paranoid, but you don't mean drop the current Mailet API do you?
Just that there are much better lifecycle and configuration options available now that IoC is better understood and available.
We could come up with a new Mailet API and deprecate the current one, or enhance the current one in a backwards compatible manner (which would most likely be no less pass�). It would be a dereliction of duty to simply "change the Mailet API" to something new and funky leaving current Mailets stranded.
If we do want a new Mailet API, as long as the parameters passed to a POJO DI class include those required by the current Mailet API, it would be simple enough to maintain backwards compatibility via an adapter in a POJO DI world.
My preference would be to keep the name (mailets), put it in a new package, call it 2.0, and have James support mailet/matchers using API 1.0, and convert all the mailets we package to 2.0.
-- Serge Knystautas Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
