On Tue, Sep 16, 2008 at 21:17, Robert Burrell Donkin <[EMAIL PROTECTED]> wrote: > On Tue, Sep 16, 2008 at 8:07 PM, Stefano Bagnara <[EMAIL PROTECTED]> wrote: >> 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.
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
