You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2007/10/08 15:26:30 UTC
The Phoenix reborn -- Plexus returning to the ASF
See: http://wiki.apache.org/incubator/ComposerProposal
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
>> I can't find any reference but I thought to remember I read sometimes
>> people saying that incubator can make releases but official
>> "non-incubator" ASF releases cannot depend/ship incubator products.
>
> this is a matter for each project
>
> - robert
Good to know, thank you!
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
> > On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
> >> Noel J. Bergman ha scritto:
> >>> See: http://wiki.apache.org/incubator/ComposerProposal
> >>>
> >>> --- Noel
> >> Thank you for the pointer. I read about this on the plexus list, but I
> >> think this won't affect us for a while as:
> >>
> >> 1st: we'll have to wait for it to be accepted in the incubator, promoted
> >> to TLP and release an official release.
> >
> > incubator podlings are allowed to create releases
> >
> > - robert
>
> I can't find any reference but I thought to remember I read sometimes
> people saying that incubator can make releases but official
> "non-incubator" ASF releases cannot depend/ship incubator products.
this is a matter for each project
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: The Phoenix reborn -- Plexus returning to the ASF
Posted by "Noel J. Bergman" <no...@devtech.com>.
Projects in the Incubator have one set of issues to deal with (Incubator
policies); projects that *use* them, have others.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
>> Noel J. Bergman ha scritto:
>>> See: http://wiki.apache.org/incubator/ComposerProposal
>>>
>>> --- Noel
>> Thank you for the pointer. I read about this on the plexus list, but I
>> think this won't affect us for a while as:
>>
>> 1st: we'll have to wait for it to be accepted in the incubator, promoted
>> to TLP and release an official release.
>
> incubator podlings are allowed to create releases
>
> - robert
I can't find any reference but I thought to remember I read sometimes
people saying that incubator can make releases but official
"non-incubator" ASF releases cannot depend/ship incubator products.
Is there anything true in this "memory"?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/8/07, Stefano Bagnara <ap...@bago.org> wrote:
> Noel J. Bergman ha scritto:
> > See: http://wiki.apache.org/incubator/ComposerProposal
> >
> > --- Noel
>
> Thank you for the pointer. I read about this on the plexus list, but I
> think this won't affect us for a while as:
>
> 1st: we'll have to wait for it to be accepted in the incubator, promoted
> to TLP and release an official release.
incubator podlings are allowed to create releases
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
RE: The Phoenix reborn -- Plexus returning to the ASF
Posted by "Noel J. Bergman" <no...@devtech.com>.
> AFAIK plexus does not anymore support Avalon out of the box and I
> don't see anything about Avalon in the Composer proposal.
We'll see, and I've already raised the topic.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Noel J. Bergman ha scritto:
> See: http://wiki.apache.org/incubator/ComposerProposal
>
> --- Noel
Thank you for the pointer. I read about this on the plexus list, but I
think this won't affect us for a while as:
1st: we'll have to wait for it to be accepted in the incubator, promoted
to TLP and release an official release.
2nd: AFAIK plexus does not anymore support Avalon out of the box and I
don't see anything about Avalon in the Composer proposal.
Stefano
PS[joking]: most "Composer" committers are maven developers, don't tell
me you let the dark side of the Force flow through you! ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/10/07, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
> > On 10/9/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> >> On 10/9/07, Bernd Fondermann <be...@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.
> There is nothing, but Avalon interfaces that really bind us to Phoenix,
> and your spring module is the final proof.
Right. That's also what I think. I just was picking at Roberts wording there.
> 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?
Yes, we are mixing up different things sometimes. But hey, this only
shows how complicated our server architecture is.
I understood Robert's statement about refactoring components as being
a statement about what might should happen inside excalibur, not here
at James. (If it will happen, who knows, I doubt it, but you happen to
be at the Excalibur PMC... ;-))
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On 10/9/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
>> On 10/9/07, Bernd Fondermann <be...@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:
http://people.apache.org/repo/m2-ibiblio-rsync-repository/org/apache/mina/mina-integration-spring/1.1.3/
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
Spring.
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
dependencies.
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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Bernd Fondermann <be...@googlemail.com>.
On 10/9/07, Robert Burrell Donkin <ro...@gmail.com> wrote:
> On 10/9/07, Bernd Fondermann <be...@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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On 10/9/07, Bernd Fondermann <be...@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 is
possible that excaliber may be refactored into pojos and avalon
bindings.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: The Phoenix reborn -- Plexus returning to the ASF
Posted by Bernd Fondermann <be...@googlemail.com>.
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.
Sorry for ranting ;-)
Bernd
On 10/8/07, Noel J. Bergman <no...@devtech.com> wrote:
> See: http://wiki.apache.org/incubator/ComposerProposal
>
> --- Noel
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org