Robert Burrell Donkin ha scritto:
On Tue, Sep 16, 2008 at 5:58 PM, Bernd Fondermann
<[EMAIL PROTECTED]> wrote:
On Mon, Sep 15, 2008 at 22:11, Stefano Bagnara <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
