Steve Brewin wrote:
I think James would secure itself most against the future by
developing a set of functional POJO's independent of any container.
+1
It would then be the responsibility of those who care to assemble them
into a deployable entity for the container of their choice.
+1
One of the easiest pitfalls to fall into is to neglect lifecycle. Different
containers use different method signatures for the same state. Coding to the
lifecycle states of a given container destroys portability. James currently
has a more sophisticated lifecycle (inherited from Avalon) than most IOC
containers offer, we may need to retain this.
PicoContainer has a org.picocontainer.Startable interface (and others),
but James should have its own lifecycle concept
org.apache.james.Startable etc. When used with PicoContainer an
org.picocontainer.LifecycleManager implementation could recognise
James's start/stop/dispose methods and act accordingly.
- Paul
co-lead PicoContainer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
