james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Mon, 09 Mar 2009 12:46:30 GMT
I would prefer to nuke the phonix stuff and just move forward.

I'm not really active atm, so feel free to ignore me ;-)

cheers,
Norman

2009/3/9 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> 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>
wrote:
>>>>>> 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.
>
> - 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


Mime
View raw message