You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Robert Burrell Donkin <ro...@gmail.com> on 2008/09/15 21:58:11 UTC
Avalon, Pheonix And Layers
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
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 layer
is going to be needed the functions and the avalon-containers.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Bernd Fondermann <be...@googlemail.com>.
On Wed, Sep 17, 2008 at 21:20, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Wed, Sep 17, 2008 at 12:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Bernd Fondermann ha scritto:
>>>
>>> On Tue, Sep 16, 2008 at 21:17, Robert Burrell Donkin
>>> <ro...@gmail.com> wrote:
>>>>>>
>>>>>> [...]
>>>>>> how freely can avalon and spring components be mixed?
>>>
>>> [...]
>>> 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.
>>
>> Cool!
>> I think this kind of use cases are what can make JAMES attractive for many.
>> Having a doc on how easy (and being sure it is easy ;-) ) to implement such
>> a thing in JAMES is something that give a feeling of JAMES flexibility.
>
> this is related to the total information management stuff
>
> i'd like to see james become a mail (not just email) hub. i would like
> to able to mix up messages (RSS, XMPP, RFC822) and process them. one
> of the reasons why i want to move protocols out as components is that
> i'd like to see james add support for other protocols using third
> party libraries such as vysper.
Yes, I have something similar in mind for information retrieval.
When it comes to server side handling though (routing, storing),
servers for the different channels (email, XMPP, SMS, Atom, Twitter)
show very different behavior in terms of CPU and memory consumption,
message flow, monitoring etc. Don't know if its worthwhile to put this
all into one server.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Wed, Sep 17, 2008 at 12:42 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Bernd Fondermann ha scritto:
>>
>> On Tue, Sep 16, 2008 at 21:17, Robert Burrell Donkin
>> <ro...@gmail.com> wrote:
>>>>>
>>>>> [...]
>>>>> how freely can avalon and spring components be mixed?
>>
>> [...]
>> 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.
>
> Cool!
> I think this kind of use cases are what can make JAMES attractive for many.
> Having a doc on how easy (and being sure it is easy ;-) ) to implement such
> a thing in JAMES is something that give a feeling of JAMES flexibility.
this is related to the total information management stuff
i'd like to see james become a mail (not just email) hub. i would like
to able to mix up messages (RSS, XMPP, RFC822) and process them. one
of the reasons why i want to move protocols out as components is that
i'd like to see james add support for other protocols using third
party libraries such as vysper.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Stefano Bagnara <ap...@bago.org>.
Bernd Fondermann ha scritto:
> On Tue, Sep 16, 2008 at 21:17, Robert Burrell Donkin
> <ro...@gmail.com> wrote:
>>>> [...]
>>>> how freely can avalon and spring components be mixed?
> [...]
> 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.
Cool!
I think this kind of use cases are what can make JAMES attractive for
many. Having a doc on how easy (and being sure it is easy ;-) ) to
implement such a thing in JAMES is something that give a feeling of
JAMES flexibility.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, Sep 16, 2008 at 21:17, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Tue, Sep 16, 2008 at 8:07 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>>
>>> On Tue, Sep 16, 2008 at 5:58 PM, Bernd Fondermann
>>> <be...@googlemail.com> wrote:
>>>>
>>>> On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <ap...@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 layer
>>>>>> 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. :-)
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Sep 16, 2008 at 8:07 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Tue, Sep 16, 2008 at 5:58 PM, Bernd Fondermann
>> <be...@googlemail.com> wrote:
>>>
>>> On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <ap...@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 layer
>>>>> 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.
does the existing pheonix deployment have any advantages over the spring one?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Tue, Sep 16, 2008 at 5:58 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <ap...@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 layer
>>>> 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.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Sep 16, 2008 at 5:58 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <ap...@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 layer
>>> 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?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Bernd Fondermann <be...@googlemail.com>.
On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <ap...@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.
>> 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 layer
>> 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.
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Tue, Sep 16, 2008 at 8:18 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Sep 15, 2008 at 11:16 PM, Stefano Bagnara <ap...@bago.org> wrote:
>>>
>>> Robert Burrell Donkin ha scritto:
>>>>
>>>> On Mon, Sep 15, 2008 at 9:11 PM, Stefano Bagnara <ap...@bago.org>
<snip>
>>>>> ATM I'd probably choose the new layer type (-package).
>>>>> ----
>>>>> sar-deployment
>>>>> spring-avalon-package
>>>>> phoenix-package
>>>>
>>>> is spring deployed through a SAR?
>>>
>>> No, but it depends on the content of the sar (including the config.xml,
>>> that
>>> currently is duplicated in its own folder).
>>
>> so AIUI the packages would contain only container binding code.
>> deployment would depend on both packages and understand how to build
>> both types of container. sounds good.
>>
>> which module would contain the avalon specific bindings?
>
> In the above tree all of the code is in the sar-deployment.
> phoenix-package simply takes the sar and prepare packages adding the
> phoenix-bin content.
> spring-avalon-package would add spring and the avalon-spring-bridge-library.
>
> Once all of our components will be free from avalon then we will be able to
> introduce a spring-deployment (or spring-package) with no dependencies on
> avalon-spring-bridge-library and sar-deployment.
sounds like a plan :-)
> In my opinion we could even decide that spring-avalon-package will be our
> only new distribution and stop working on phoenix.
i keep thinking back to conversations about james i've had at various
apachecons. i think that the james mail application needs to focus
much more on a single basic default configuration which can be
integration tested. if there is no need to support experimental and
extension features in phoenix then i think it can be easily
maintained.
but i think it makes sense to emphasize the spring deployment for
developers and extenders.
>To mantain 2 deployments without having tests is an effort.
integration tests are something that can be address and needs to be.
the framework used in IMAP can - with a little work - be apply to
integration testing the james application. a set of basic test scripts
for each supported protocol can be created and used to test each. for
more advanced features and configuration we don't support
out-of-the-box for phoenix.
> I use phoenix and its ability to run
> multiple sars in the same contaier with isolated classloaders but I bet I'm
> an isolated case and most james users simply start phoenix with our bundled
> james.sar and nothing else.
phoenix has proved very stable in production use but slows development
of advanced features. with a little investment up front, the
maintainence of a core featureset on pheonix shouldn't be such a major
task.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Sep 15, 2008 at 11:16 PM, Stefano Bagnara <ap...@bago.org> wrote:
>> Robert Burrell Donkin ha scritto:
>>> On Mon, Sep 15, 2008 at 9:11 PM, Stefano Bagnara <ap...@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
>>>>> 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 layer
>>>>> 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.
>>> makes sense
>>>
>>>> ATM I'd probably choose the new layer type (-package).
>>>> ----
>>>> sar-deployment
>>>> spring-avalon-package
>>>> phoenix-package
>>> is spring deployed through a SAR?
>> No, but it depends on the content of the sar (including the config.xml, that
>> currently is duplicated in its own folder).
>
> so AIUI the packages would contain only container binding code.
> deployment would depend on both packages and understand how to build
> both types of container. sounds good.
>
> which module would contain the avalon specific bindings?
In the above tree all of the code is in the sar-deployment.
phoenix-package simply takes the sar and prepare packages adding the
phoenix-bin content.
spring-avalon-package would add spring and the avalon-spring-bridge-library.
Once all of our components will be free from avalon then we will be able
to introduce a spring-deployment (or spring-package) with no
dependencies on avalon-spring-bridge-library and sar-deployment.
In my opinion we could even decide that spring-avalon-package will be
our only new distribution and stop working on phoenix. To mantain 2
deployments without having tests is an effort. I use phoenix and its
ability to run multiple sars in the same contaier with isolated
classloaders but I bet I'm an isolated case and most james users simply
start phoenix with our bundled james.sar and nothing else.
>>>> BTW you are the ant build expert here, so do it as you feel it's better.
>>>> In
>>>> m2 we're using named dependencies so both solutions works the same.
>>> it's not an ant limitation but a self-imposed rule of the layering game
>> You already told me, I know this. Maybe this is an english vs italian issue.
>> In italian a "limit" can be self imposed.
>
> "an ant limitation" implies that the fault lies with ant rather than a
> limit impose by the current build
From now on, if I'll use "ant limit" I will always refer to the limit
of our build based on ant. It's shorter to tell. I'll try to not use the
short form, if I remember.
>> I use "ant build" with specific reference to our current build based on ant.
>> I know ant can do anything that can be done in maven. It is the same as "you
>> can do in c anything you can do in c++".
>> [...]
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Sep 15, 2008 at 11:16 PM, Stefano Bagnara <ap...@bago.org> wrote:
> Robert Burrell Donkin ha scritto:
>>
>> On Mon, Sep 15, 2008 at 9:11 PM, Stefano Bagnara <ap...@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
>>>> 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 layer
>>>> 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.
>>
>> makes sense
>>
>>> ATM I'd probably choose the new layer type (-package).
>>> ----
>>> sar-deployment
>>> spring-avalon-package
>>> phoenix-package
>>
>> is spring deployed through a SAR?
>
> No, but it depends on the content of the sar (including the config.xml, that
> currently is duplicated in its own folder).
so AIUI the packages would contain only container binding code.
deployment would depend on both packages and understand how to build
both types of container. sounds good.
which module would contain the avalon specific bindings?
>>> BTW you are the ant build expert here, so do it as you feel it's better.
>>> In
>>> m2 we're using named dependencies so both solutions works the same.
>>
>> it's not an ant limitation but a self-imposed rule of the layering game
>
> You already told me, I know this. Maybe this is an english vs italian issue.
> In italian a "limit" can be self imposed.
"an ant limitation" implies that the fault lies with ant rather than a
limit impose by the current build
> I use "ant build" with specific reference to our current build based on ant.
> I know ant can do anything that can be done in maven. It is the same as "you
> can do in c anything you can do in c++".
>
>> IMHO james server is so complex from a coupling perspective that
>> layering needs to be imposed to give an understandable structure. the
>> rules of the layering may be expected to evolve with time.
>
> If it was for me we probably wouldn't have this self imposed limit,
it's hopefully just a stage. it's only because the james component
structure is so bad that it's necessary. once components have been
factored
> but I'm fine with it as long as we don't have to put in hacks to satisfy self
> imposed limits.
i'd much rather have temporary code hacks than modularisation hacks
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Stefano Bagnara <ap...@bago.org>.
Robert Burrell Donkin ha scritto:
> On Mon, Sep 15, 2008 at 9:11 PM, Stefano Bagnara <ap...@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
>>> 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 layer
>>> 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.
>
> makes sense
>
>> ATM I'd probably choose the new layer type (-package).
>> ----
>> sar-deployment
>> spring-avalon-package
>> phoenix-package
>
> is spring deployed through a SAR?
No, but it depends on the content of the sar (including the config.xml,
that currently is duplicated in its own folder).
>> BTW you are the ant build expert here, so do it as you feel it's better. In
>> m2 we're using named dependencies so both solutions works the same.
>
> it's not an ant limitation but a self-imposed rule of the layering game
You already told me, I know this. Maybe this is an english vs italian
issue. In italian a "limit" can be self imposed.
I use "ant build" with specific reference to our current build based on
ant. I know ant can do anything that can be done in maven. It is the
same as "you can do in c anything you can do in c++".
> IMHO james server is so complex from a coupling perspective that
> layering needs to be imposed to give an understandable structure. the
> rules of the layering may be expected to evolve with time.
If it was for me we probably wouldn't have this self imposed limit, but
I'm fine with it as long as we don't have to put in hacks to satisfy
self imposed limits.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Sep 15, 2008 at 9:11 PM, Stefano Bagnara <ap...@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
>> 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 layer
>> 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.
makes sense
> ATM I'd probably choose the new layer type (-package).
> ----
> sar-deployment
> spring-avalon-package
> phoenix-package
is spring deployed through a SAR?
> BTW you are the ant build expert here, so do it as you feel it's better. In
> m2 we're using named dependencies so both solutions works the same.
it's not an ant limitation but a self-imposed rule of the layering game
IMHO james server is so complex from a coupling perspective that
layering needs to be imposed to give an understandable structure. the
rules of the layering may be expected to evolve with time.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Avalon, Pheonix And Layers
Posted by Stefano Bagnara <ap...@bago.org>.
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
> 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 layer
> 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.
ATM I'd probably choose the new layer type (-package).
----
sar-deployment
spring-avalon-package
phoenix-package
----
BTW you are the ant build expert here, so do it as you feel it's better.
In m2 we're using named dependencies so both solutions works the same.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org