Danny Angus wrote: > > > On a serious note, with a good container & IoC design the > effort should > > be in the application interfaces and the POJOs that implement them > > rather than in the container framework being used. > > Yep I agree with this. > > I think James would secure itself most against the future by > developing a set of functional POJO's independent of any container. > > It would then be the responsibility of those who care to assemble them > into a deployable entity for the container of their choice. > > James could maintain one or more of these deployment sub-projects so > that we could always deliver a fully working solution, but we'd also > be delivering mail server functionality which could be widely embedded > and integrated into a vast range of systems.
My thoughts are summed up in http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] .org&msgNo=12565 and generally concur with Danny's. 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. This boils down to defining a James specific interface for each of the lifecycle states so that, if it exists, the corresponding method on a POJO can be invoked at the appropriate time (configure(), start(), stop(), etc). Varying degrees of extension and adaptation are required to implement new or map existing James lifecycle states to existing containers. Groovily enough, a scripted container, or a hard-coded vanilla Java container can do just what is required, no more no less. I would favour a James reference implementation that uses a simple scripted or vanilla Java launcher, whose code and documentation make clear the contracts and states it is fulfilling without embellishment. We should be happy to host sub-projects or Wiki examples of leveraging James services in more sophisticated containers with all of their wizzy features, but not be dependent on one. Finally, thanks to Alex for his endeavours and provoking this discussion. -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
