> I think it would be preferable for the James system to be acting a mailet
> container and following IOC principals.
> the mailet does not need to be concerned with "obtaining"
> the things it needs - instead - it gets supplied everything
> it needs.
I understand your view. There are good arguments both ways. At the moment,
the Mailet API design is not based upon IoC; it models J2EE, and is pull
oriented rather than push oriented. I don't expect that to change in the
Mailet API, although it would be possible for James to provide additional
lifecycle methods if a matcher or mailet supported them.
> Aside from the IOC issue - a pluggable configuration provider is
> definitely something I would be interested in seeing and using.
My proposal to Aaron supports that pluggable provider where needed. As
proposed it follows the J2EE pattern, although if everyone decided to change
the Mailet API to use IoC, the same basic strategy applies. It is just a
matter of how you get the resource.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
