james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: The Phoenix reborn -- Plexus returning to the ASF
Date Wed, 10 Oct 2007 08:36:15 GMT
Bernd Fondermann ha scritto:
> On 10/9/07, Robert Burrell Donkin <robertburrelldonkin@gmail.com> wrote:
>> On 10/9/07, Bernd Fondermann <bernd.fondermann@googlemail.com> wrote:
>>> Let's face it - there will be nothing what could remind you of Phoenix
>>> in the combined code base.
>>> But it probably will work similar to Spring IoC-Container. Much
>>> flexibility, simplicity.
>>> Anyway, every container apart from Phoenix will be fine.
>> pheonix is tightly coupled with the excaliber components we use.
> it's funny you write that. "the IoC container is tightly coupled with
> its components" ;-)
> James is not dependend on Phoenix (the only part I managed to get
> around in James/Spring), but it is very tightly coupled indeed with
> excalibur components. We'd probably have to rewrite much of our code
> to loosen these strings.

I don't agree with Robert and you about Phoenix being tightly coupled
with components we use. IMHO it is a good coincidence IF Phoenix uses
some of the same components we also decided to use to build JAMES
Server. This means less memory used as the container and the contained
application share something.
There is nothing, but Avalon interfaces that really bind us to Phoenix,
and your spring module is the final proof.

>> it is
>> possible that excaliber may be refactored into pojos and avalon
>> bindings.
> I'd like to see that happen. Anyone already working on that or is this
> only in theory?
>   Bernd

First we have to make a classification:

Excalibur jars are often splitted in api and impl: API does not have
dependencies on Avalon or anything container related. IMPLs often refer
some activity marker interface (Disposable) and the Avalon Logger (to be
injected). IMHO you can use them like any POJO: inject the dependencies
and use them.
In many cases excalibur code become some commons-* utility: there is a
documentation page, somewhere, that explain what common jar deprecated
each excalibur library.

Cornerstone are instead integration components to simplify using the
libraries above in a Avalon/Phoenix environment. They are very simple
jars often containing only 1 interface and 1 implementation, and this is
a common result of IoC frameworks. If you don't use them or you don't
include such "utility classes" in your main code you will end up writing
utility code for your framework. This also happens in spring. Spring try
to provide utility classes for most common libraries out there, but
often projects have to provide their own:

Sometimes our components directly extends cornerstone components: we do
this because we extend that code and not because we need to satisfy some
special obsolete container requirement.

Let me be clear: I don't like Phoenix as it is obsolete code no more
mantained, but I don't really think that Spring is the panacea and most
of the problems people is reporting about Phoenix are there also with

Too much times we use Avalon instead of Phoenix and viceversa, but here
we also have Excalibur and Cornerstone and each one have 2 kind of
dependency (api/descriptors and implementation). I would say that JAMES
is currently distributed with:
- avalon-api
- avalon-impl
- various excalibur-api
- various excalibur-impl
- various cornerstone-api
- various cornerstone-impl
- some phoenix block descriptor (I consider them like an API, even if it
is not introduce direct dependencies like an interface)
- phoenix itself.

The spring module replaced phoenix itself and ATM it keep using the
phoenix configuration files and descriptors.

I have difficult understanding what you (you all) want to refactor when
you talk about POJO, avalon, excalibur by mixing issues. Can we agree on
the above classification for our "dependencies" and be more specific in
the discussion?

Many times in past I started working on extracting the whole avalon
stuff (all of the above dependencies) from our base code to Avalon
wrappers, but, as I wrote multiple times, there are JAMES core
components using avalon interfaces as THEIR OWN way to manage lifecycle
for their contained/managed objects.
So the avalon "extraction" would have required a big big big refactoring
and every time I started discussing each step concretely discussion lead
to nothing.

IMHO the only way to go is replace one thing at a time (one of that
dependencies at a time): the only thing we partially did is to support
setter injection for services in addition to the ServiceManager. This is
a first step. This allow other users of the code to not understand what
ServiceManager is (and depend on it) and to directly work with the real

Then you have the Log issue: you can use/inject the logger from
commons-logging but they don't support child loggers, so either you
create your own interface and implements it via commons-logging, or you
simply keep using avalon logger and implements it via commons-logging
(like you already do in the spring module, right?).

Then you have the avalon Context: I think I managed to isolate the
context usage to the AvalonFileSystem block and removed it from everywhere.

As I wrote in past, and I rephrase it for the newer committers, I do not
favor removing "avalon framework api" interfaces from our code by simply
creating new interfaces in our packages and use them. IMHO if we do not
need different interfaces it does not make sense to duplicate avalon
interfaces: this add incompatibility with the avalon world, and does not
add any advantage.
IMHO avalon interfaces are the last thing to care about, IF and ONCE we
won't use phoenix anymore and we'll have removed any outdated components.

The "complicate" steps to remove avalon can be found looking for the
ContainerUtil class usage. They are the key of our usage of the avalon
container logic INSIDE our components. Once they are factored out from
the code (using Factories or any other pattern you can think about) then
everything else will be much smoother. Keep talking about POJOs,
avalon-free, and other similar thing without solving this concrete step
is something we already did for years. And maybe this is not so
complicate: it requires someone that do it and most of others to be
happy to see many changes committed.


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

View raw message