james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject Container direction for James
Date Thu, 02 Dec 2004 21:54:01 GMT
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=&listName=james-dev@jak
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: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


Mime
View raw message