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: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Mon, 09 Mar 2009 13:09:31 GMT
Robert Burrell Donkin ha scritto:
>>>> 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

Well, I did it something similar for jSPF:
But I doubt something similar will be enough for JAMES Server, that's
why I was suggesting that using an existing microkernel could be better
than writing yet another container.

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

I'm not following you. Unless you plan to put everything in a single
phoenix component you will still have to deal with xinfo and other
phoenix specific stuff even if you write your own kernel.

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

Understood. I didn't understood you wanted to deal with phoenix code.
I'm not sure I understand why we need to alter the phoenix container and
what it gives us in turn (what's the goal), but if you want to play with
it we'll see the result.

(Using phoenix makes sense only if we leverage its own configuration
stuff, its own kernel and its own JMX stuff. Otherwise let's remove
phoenix and use any other more modern container/framework)

BTW I think I'll better understand your plan once you'll start moving on
it: I'll be here watching :-)


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

View raw message