james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Thu, 12 Mar 2009 13:38:51 GMT
Robert Burrell Donkin wrote:
> On Fri, Mar 6, 2009 at 5:39 PM, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Mar 3, 2009 at 9:20 AM, Stefano Bagnara <apache@bago.org> wrote:
>>>> Robert Burrell Donkin ha scritto:
>>>>> On Sun, Mar 1, 2009 at 8:05 PM, David Jencks <david_jencks@yahoo.com>
>>>>>> I'd kind of worry that if you start using annotations you are going
to be
>>>>>> building yet another wiring framework which may not be the ideal
focus of
>>>>>> this project.
>>>>> (unfortunately) i'm not sure a consensus would be possible about
>>>>> picking a more modern approach
>>>> I would prefer the use of an external wiring library instead of writing
>>>> our own. JAMES is complex enough to require some complex wiring and
>>>> writing our own library is not the right thing to do IMHO.
>>> i see no hope of gaining the consensus required to pick a new container
>> Why? Did we recently had a poll or did anyone expressed strong opinions
>> against one or another container? I know I'm less active lately and I
>> don't remember this.
> history
>>>> As far as we can go there's no way to ship only container-agnostic
>>>> components. One way or another we'll have to use a container and to put
>>>> wiring/configuration there and the wiring/configuration is part of the
>>>> distribution. We have to choose a container and use its facilities. One
>>>> thing we should do is to avoid to put container stuff all around our
>>>> code, but we should not write our own container to avoid being
>>>> container-specific.
>>> my suggestion is that we develop phoenix to a point where james can
>>> easily be run on other containers. this requires the development of
>>> some james specific wiring and a micro-kernel to plugin into phoenix.
>>> the development of a new container is not necessary.
>> what I meant is that I prefer to use an existing micro-kernel than
>> writing our own.
> depends how big your micro-kernel is ;-)
> the smallest service micro-kernel is a Map
>> xbean+spring, for example, is not documented, true, but at least it is
>> used and tested. Something written from scratch would be unused and
>> undocumented and less bulletproof.
> this sounds a good way for the spring deployment to go but i'm not
> sure that this would be easy to adapt phoenix to use this approach. if
> volunteers step forward who were willing to re-work and maintain the
> phoenix container to use a spring-xbeans based micro-kernel that'd be
> great by me but i'm not willing to devote the time required.
>> BTW this is just a preference. If you are convinced that writing your
>> own stuff is better and you're prepared to write it and make it work,
>> well, I won't stop you!
> i'm proposing a modification to the phoenix container, not creating a
> new one. it doesn't need to be bullet proof, just good enough to allow
> the james code base to move forward.

Why? I think would should not bother with Phoenix beyond the point of 
supporting it as a legacy container. I could be wrong, but no active 
committer is willing to support it much longer, so I lean towards ending 
support for it after the next release. As an option, we could already 
toss it for the upcoming release.

For me, there are a few valid wasy to move forward:

* Switch to Spring completely and only. Right now we have an adapter for 
Spring to behave like Phoenix for James components. Removing this 
adapter and becoming 'pure Spring' (and retaining all Avalon stuff we 
depend on) we would have no Spring specific code within James components.

* Support other prioprietary wiring framworks like Pico/Nanocontainer.

* Use some vendor-independent bean wiring framework like JSR-299 (if I 
recall the number correctly, I writing this as I'm offline). Form me, a 
precondition for going this route would be that we have a FOOS 
BSD-licensed container implementation for it.

I favor the third option.


> - robert
> ---------------------------------------------------------------------
> 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

View raw message