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? - robert --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
