Hi All, What follows is a summary of thoughts I have been having about the future direction of James, particularly in regard to containers. These were initially stimulated by discussions here about CDI instigated by Paul Hammant, see http://nagoya.apache.org/eyebrowse/SearchList?listId=&[EMAIL PROTECTED] arta.apache.org&searchText=Paul+Hammat&defaultField=sender&Search=Search and view the most recent entries.
The demise of Avalon adds some impetus to this, but for my part it is from my recent positive experience of working on a commercial project where we converted complex application a set of CDI cognizant parts assembled into a solution which as a by product yielded a large set of reusable and independently testable components from a large blob of hard to test code containing many circular dependencies (not that I'm suggesting James is like this). Applying the same approach to James - "a complete and portable enterprise mail engine solution based on currently available open protocols" (http://james.apache.org/index.html) - we could detach the James solution from its reliance on a specific and dead container environment (Phoenix) and, if we wished, establish a Commons of mail components from which the James solution is assembled but others might leverage in their own ways. Commons components could be more granular than the Avalon's components we currently have. They would be CDI enabled POJOs, meaning that they are simple Java classes that are instantiated with all the services they require via their one and only public constructor. Such components are just as usable outside of a CDI environment simply by programmatically instantiating them via the public constructor. Having a formal Commons of mail components is a philosophical shift for James. In my view a good one as it makes our code more accessible and contributing components easier. Others may have differing views? There is plenty of information about CDI around, and to paraphrase one pundit, as many implementations as there are advocates. One of the attractions of CDI is that deployed code is relatively container agnostic. The same POJO code will run in commonly used CDI containers such as Hivemind (http://jakarta.apache.org/hivemind/index.html), Pico/Nano (http://picocontainer.codehaus.org/, http://nanocontainer.codehaus.org/) and Spring (http://www.springframework.org) with a few caveats. Caveat 1: Most CDI containers add useful functionality over and above a pure lightweight CDI container, functionality such as XML configuration, service pooling, JMX, AOP, etc. If an application needs functionality which is absent from your chosen container, extend the container. This makes the new functionality available to all applications which run in the container. Where appropriate, offer your extensions to the community. Or choose a container that provides the functionality you require. Caveat 2: Typically, CDI containers have no lifecycle state support beyond start and stop states. If an application requires more granular states, it is easy to add further states as part of the container launch and termination processes, or internalise them to the application so that container.start() invokes your own portable state manager. Caveat 3: There is no CDI standard or reference implementation. For example, dependency resolution. This is not a problem when explicitly declaring dependencies, but to me explicit declaration is simply moving a problem whereas "auto-wiring" (automatic resolution of dependencies) solves it. Except that the "auto-wiring" algorithms of CDI containers can yield radically different results! Caveat 4: Given the previous caveats and the current state of play, whilst it is true that CDI enabled POJO code could be deployed on any CDI platform it can only be said to work on a chosen reference platform. Caveats aside, it would be a relatively painless exercise to modify the James components to acquire their services via CDI. The big issue is how to supply the services James requires that have hitherto been supplied by the Phoenix container. I would be minded to use Jakarta Commons solutions wherever possible, wrapping them with a CDI adaptor when necessary. There are other ways, but this was supposed to be a short summary! Obviously, this is not the only direction we could take. What ideas do you have? -- Steve --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
