Alan Cabrera wrote:
> I'm going to investigate what it takes to convert James to maven 2 and
> XBean. I realize that others may not like that idea. My thinking is to
> convert a small piece and solicit comments.
Let's separate the two issues, shall we?
Personally, I'm not a big fan of Maven in any flavor, but I am willing to be
convinced. I certainly do not like maven generated web sites, nor am I a fan
of the repository system. Perhaps we could leverage multi-project builds, or
we could just improve our Ant builds.
As for XBean, I favor OSGi interfaces, particularly as OSGi and Sun are
cooperating via the JCP to establish what will become the official standard
interfaces. ApacheDS and Derby are already available as OSGi bundles, too. If
it is correct that XBean can serve as a convenience layer on top of OSGi, that
might be reasonable direction.
You could post a small piece as an example. I'd like to see that example, and
some discussion, as a prelude to discussion.
The best place to start might be to refactor the existing services into plain
POJO services and then look at how we want to tie those back into a particular
container. To be clear, since there has been a lot of discussion, such POJOs
would not be "services", per se. No lifecyle methods that we don't define
ourselves, e.g., the Mailet init() method. No sophisticated start, stop, etc..
Just the core business logic. This should help us to expose core requirements
for DI and/or service lookup. This would be a collaborative effort, with API
evolution, inherent support for JMX, etc., and thus would be looking at
JAMES-NEXT, not JAMES-NOW. :-) So a branch in SVN.
During this process, I would like to take control back from the avalon code.
We really use very little of conerstone, and what little we use seems to get in
the way of where we want to go as much as it helps. Such as repositories that
are interfering with the path to IMAP. Even Avalon was moving to use Jakarta
Commons packages whenever possible, and I would continue that move, using
standard java[x].* where possible, using org.apache.commons.* next, etc. For
key things, we should use org.apache.james.* interfaces, and either implement
or delegate to a suitable implementation, but we should own our key interfaces.
We should also carefully decide where we want to touch the container. For
example, JAMES has its own container notions, and effectively isolates the
Mailet API from the underlying container, except when a matcher or mailet
requires additional capabilities from the container. When DI isn't
appropriate, I would just as soon require JAMES to provide a suitable JNDI
InitialContext as part of its own container contract, than explose the
underlying platform.
As for IOC vs standard J2EE JNDI lookup, they each have their place, and we are
likely to use more of the latter than the former, although we'll see what falls
out from the API redesign.
Currently, configuration is XML-based. I want to see us end up able to support
dynamic reconfiguration in a distributed and clustered environment. That may
mean moving configuration into the Directory server, so that it is available
via JNDI from anywhere.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
