Some Reply-To issue
Emmanuel Bernard wrote:
James Strachan wrote:
We're in the middle of building a special kind of container, Geronimo. Given time, Geronimo could end up being an Avalon container. Or it could have an optional Avalon module so some adapter/service could allow any existing Avalon container (or PicoContainer) to drop right in and so it could end up reusing any of the plethora of containers out there (off the top of my head there is... Phoenix, Plexus, ECM, Fortress, Merlin, Loom, DNA, JContainer, PicoContainer, NanoContainer - which are all different Avalon, ex-Avalon or PicoContainer implementations).
I'm pretty sure we'll eventually support (somehow) Avalon & Pico components in some way. Interoperability is a goal. Lets just leave the implementation time to grow first and make decisions based on whats best for Geronimo the container. JMX, Avalon and Pico are 3 component models I'd like us to support - lets keep the container open first though until it gets the basic requirements (JTA, EJB, MDB, Web) sorted out.
James,
Avalon principes and container implementation choices should be separated.
When I had a look at Avalon framework, I was please to find a standard way to see and manage components. Leo already starts a + and - list, so I won't do my own list, but I think using Avalon principles to build a *component based* J2EE compliant projet with pluggable implementation capabilities (as I can see in the mainling list), is a good idea. Avalon guys already think about these kind of issues. I'm not experienced enough, but It seems to be far more easy to start Geronimo implems over Avalon than doing one and refactor later.
If you think that available container impelmentations is not *standardized* enough to start Geronimo on it, feel free to implement a Geronimo one to start the project.
Emmanuel
