james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bernd Fondermann" <bernd.fonderm...@googlemail.com>
Subject Re: Avalon, Pheonix And Layers
Date Tue, 16 Sep 2008 19:28:13 GMT
On Tue, Sep 16, 2008 at 21:17, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 8:07 PM, Stefano Bagnara <apache@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Tue, Sep 16, 2008 at 5:58 PM, Bernd Fondermann
>>> <bernd.fondermann@googlemail.com> wrote:
>>>> On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <apache@bago.org> wrote:
>>>>> Robert Burrell Donkin ha scritto:
>>>>>> 1. spring-deployment is a (cool) spring based avalon container
>>>>>> 2. pheonix-deployment is an avalon container
>>>>>> 3. both depend on components coupled to intrusive avalon interfaces
>>>> Maybe it's ok to rephrase that a little bit, to highlight an important
>>>> difference to phoenix: The spring-deployment _supports_ Avalon-based
>>>> components, and thus it depends on Avalon interfaces. You can (at
>>>> least that was my intention) deploy any other non-Avalon-based bean
>>>> besides our Avalon-based components.
>>> cool :-)
>>>>>> 4. the intrusive nature of avalon is bad for the code base
>>>>>> this means that it's not going to be possible to factor out non-avalon
>>>>>> components within the current layer structure. either
>>>>>> spring-deployment needs to depend on pheonix-deployment or a new
>>>>>> is going to be needed the functions and the avalon-containers.
>>>>>> - robert
>>>>> This is a perfect summary of my previous concerns :-)
>>>>> To be more precise spring-deployment is a spring based avalon container
>>>>> compatible with phoenix configuration (config.xml) and descriptors
>>>>> (xinfo)
>>>>> so, there is something more than avalon in the coupling.
>>>>> I guess the ideas was to have spring as an avalon container so we could
>>>>> move
>>>>> some component out of avalon step by step.
>>>> this, and deploy new James components which are not tied to Avalon,
>>>> and get MBeans running again under modern JDKs, and make it easier to
>>>> integrate with anything already running in Spring, and to integrate
>>>> James into Spring-supporting containers, like Geronimo, Tomcat, Felix.
>>> cool
>>> how freely can avalon and spring components be mixed?
>> As much as you want. Components declared in assembly.xml are created as
>> spring beans using their block name.
>> You can add more non avalon blocks in the spring-beans.xml and you can
>> override assembly blocks with non avalon beans.
>> The only thing you have to care about is the Interfaces. The beans you
>> create for services have to implement the right interfaces.
>> The "serviceManager" bean defined in spring-beans.xml has the ability to
>> define a "replacements" map. In our case only the FileSystem service is
>> replaced with org.apache.james.container.spring.adaptor.FileSystemBridge.
>> The spring-deployment also supports configuration interceptors to allow for
>> changes of what is read from the phoenix config.xml.

I never did it but you could even use sping's AOP, proxying and
transaction support on these beans.
I only scratched the surface of what can be done.

one more exotic example: linking James and Vysper using Sieve, which
is defined for both, email and xmpp.

> does the existing pheonix deployment have any advantages over the spring one?

yes, a major one: it's the only released James deployment and used in
the field. :-)


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

View raw message