The current discussion is valuable, but isn't converging and some of it
borders on silly religious debate. Let's clarify a few points, and
establish a direction.
-- much of JAMES is ALREADY independent of Avalon.
Only a few major components care about Avalon, and those are not too hard to
convert.
There are several different notions of container in JAMES, and that is as it
should be, actually.
-- services run in an application container.
These are the main SMTP, POP3, IMAP, NNTP, etc., services. The nature of
how those are deployed should NOT impact the mailet container. The mailet
container is intended to be a portable container installable in other
applications.
-- reuse of existing J2EE design patterns is a good thing.
J2EE is very much based upon containers and components. Servlets, JSPs,
Portlets, EJBs, etc., are all container managed components. Proper reuse of
existing patterns is reasonable. Mailets are quite similar, and are managed
by the mailet container.
Our transport services and mailets can use dependency injection and also
resource lookup. Both are both valuable and neccessary. Let's avoid
extremist philosophical rhetoric.
Consider the basic approach with J2EE. Standard things are injected by
lifecyle methods (e.g., ServletConfig). JNDI is also available because
these are general architectures. I've had experience with another approach,
where the component was given a context from which it could do an
constrained lookup, but that is a poor and non-standard approach, and the
next generation of that product has gone with JNDI as the standard
mechanism.
Whether we go with constructors to inject dependencies, or follow the more
flexible approach of using lifecycle methods isn't that big a deal.
Personally, I strongly favor lifecycle methods for a variety of technical
reasons. In fact, I have a few that I consider to weigh heavily against
constructor injection, but the exposed surface of the components should be
so small compared to internals that we should be able to fix things in
mid-stream if we go down the wrong route.
In short, I tend to agree with Mike Heath, and add JNDI as well where that
is appropriate.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
