Noel J. Bergman wrote:
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.
I would like to see the project after the maven2 port in order to give
my final thought. I had problems with the current ant-based build
process, so I'm *currently* fan of any test of a different build mechanism.
Things I would expect from maven2:
1) remove third party jars from our repository.
2) simpler integration with third party tools (code coverage, continuos
integration, ide configuration...)
3) clean support of multi-project so we can split our main components to
separate sub projects.
4) simple way to build an installer for the resulting application (IIRC
maven2 has plugins to simplify the creation of NSIS installers and more)
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 don't know both XBean and OSGi enough to say what I like.
XBean has really few documentation/information around the web and I
still don't understand what the various modules do and how.
Here:
http://incubator.apache.org/ip-clearance/geronimo-1478-xbean.html
I see the following and I have this questions:
"kernel": what services does it provide?
"osgi": what does it exactly bridge and what are the limitation?
"server": is "server" to "kernel" what "phoenix" is to "avalon" or what
else?
"spring": I know spring 2 introduced xml extensions: how does this
differs from spring2 support?
"telnet": I like it, IIRC there is also a phoenix kernel option to
support a similar task.
You could post a small piece as an example. I'd like to see that example, and
some discussion, as a prelude to discussion.
I like examples and discussions, but I think there is no better example
than a working almost finished work ;-). If Alan wants to try some of
this things and doesn't care wether James will accept the change or not
then I think we could safely "talk less" and wait for the "almost
finished code" or "work in progress code" to make our reviews and talk
about real things.
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.
I would no more discuss "POJO" issues: I want to see *real* proposals. I
am starting being really skeptic about buzzwords. 6 years ago everyone
was SOAPing their projects and if your application wasn't supporting
SOAP you where no-one. POJO means nothing and everything at the same time.
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.
I already expressed my option about Avalon interfaces: in short I think
we should keep them until we'll need to change them. I'm against moving
the interfaces in a james package with no other goal. Most of them are
single method interfaces: when you need to change them you probably just
need to introduce a new interface.
About cornerstone I think James usage is not "very little".
Most of our components depends on this core services:
--
org.apache.avalon.cornerstone.services.sockets.SocketManager
org.apache.avalon.cornerstone.services.scheduler.TimeScheduler
org.apache.avalon.cornerstone.services.datasources.DataSourceSelector
org.apache.avalon.cornerstone.services.threads.ThreadManager
org.apache.avalon.cornerstone.services.store.Store
--
What are the existing services that could replace this services? How
much work is needed?
We could even replace this one *BEFORE* James 3 and *BEFORE*
"POJOification" but we need the new components/services available first.
but our "MailRepository"One more note about repositories: the
repository interface is a James specific interface and is not binded to
Avalon. We only use the "Store" service from avalon but I think the
problem with IMAP is not the "Store". I don't see how the store limits
us implementing IMAP.
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.
This has been a blocking issue talking with Andrew C. Oliver about
James, Mailets and JBMS.
In the end, if we remove external services the useful mailets are
probably less than 10: So we should introduce at least a few known
services (repositories, datasources, user-directories, more?).
I think that JNDI should not be used in a sentence where we use POJOs
and DI. IMHO JNDI is like Avalon Service locator pattern (Serviceable)
but worst (more difficult to test, it is not easy to provide different
implementation of the same service to different components).
If we consider Avalon Serviceable a limit to James then we shouldn't
talk of JNDI: it is more easy to provide a ServiceManager that does
lookups via JNDI than viceversa.
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 would avoid JNDI uage in James components/services like plague . I
would only consider it for Mailets but I'm probably for DI usage in
mailets too.
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.
Avalon already provides a Reconfigurable interface. We should first
support it in our components and then we could search a container that
allow us to reload / change on the fly the configurations.
Here the biggest problem is supporting configuration changes IN the
components. Most of them should be disposed and recreated to do that.
I see this as an application issue much more than a container issue.
Stefano
PS: I'm inclined to hear and change my current ideas about all I wrote here.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
