Noel J. Bergman wrote:
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.
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.
I think that we should support this. The standard OSGi interfaces are
inadequate and we will need adapters. Felix has some nice stuff that
could help here. But to restate my position, the OSGi/Felix code should
not be in James' core code.
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.
I think that w/ proper POJOification, you can properly support either.
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.
That is one use case, I think we should support others as well.
Regards,
Alan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
