james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Mon, 09 Mar 2009 12:44:05 GMT
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


Mime
View raw message