[prev in list] [next in list] [prev in thread] [next in thread] 

List:       james-dev
Subject:    RE: Container direction for James
From:       "Hes Siemelink" <hes () izecom ! com>
Date:       2004-12-06 10:05:10
Message-ID: F15E0395D64CA14CAD616275B1C3A7B309E972 () izecom-martijn ! exchange ! izecom ! com
[Download RAW message or body]

Great idea!

If James were more granular and POJO-oriented, it would also be easier
to embed in other containers and applications. I think this will boost
James usage and development.

I am not familiar with CDI, but it sounds like a promising technique
that is easy to pick up and simple enough to work in various
environments. 

Cheers,

	Hes.

-----Original Message-----
From: Steve Brewin [mailto:sbrewin@synsys.com] 
Sent: Thursday, December 02, 2004 22:54
To: James Developers List (E-mail)
Subject: Container direction for James

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



---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]