On 3/12/09, Bernd Fondermann <[email protected]> wrote: > Robert Burrell Donkin wrote:
<snip> >> i'm proposing a modification to the phoenix container, not creating a >> new one. it doesn't need to be bullet proof, just good enough to allow >> the james code base to move forward. > > Why? Short version: I'm not interested in wasting any more energy tooling for Phoenix Long version: 1 It's a dead container 1A functions stop working in new JVMs 1B developers don't want to learn avalon or phoenix 1C bugs don't get fixed 1D tooling isn't available for third party libraries 2 Avalon-Phoenix isn't good enough 2A Assembly requires poor design choices to be baked in 2B Service Location requires strong coupling to Avalon and adoption of a particular architectural approach 2C too much work is required to assemble services composed from finely grained components 2D service location requires too much effort and requires changes to the configuration document which we are then required to support going forward > I think would should not bother with Phoenix beyond the point of > supporting it as a legacy container. The cost of supporting Phoenix (in it's current form) is IMO too high to continue unless volunteers interested in investing the time required step up Anyone interested? > I could be wrong, but no active > committer is willing to support it much longer, so I lean towards ending > support for it after the next release. As an option, we could already > toss it for the upcoming release. > > For me, there are a few valid wasy to move forward: > > * Switch to Spring completely and only. Right now we have an adapter for > Spring to behave like Phoenix for James components. Removing this > adapter and becoming 'pure Spring' (and retaining all Avalon stuff we > depend on) we would have no Spring specific code within James components. > > * Support other prioprietary wiring framworks like Pico/Nanocontainer. > > * Use some vendor-independent bean wiring framework like JSR-299 (if I > recall the number correctly, I writing this as I'm offline). Form me, a > precondition for going this route would be that we have a FOOS > BSD-licensed container implementation for it. > > I favor the third option. I think it's better to think about separate concerns The annotations really only address service location not service assembly. Spring is IMO a much better option for service assembly than the variety of hand crafted alternative used ATM by James but IMO this choice can be left to components. Service location can also be done by Spring but there are credible alternatives here. JEE or OSGi offer interesting possibilities. For example, Service Mix has a very cool kernel which blends Spring and OSGi. Then again, Felix and Geronimo are both have significant advantages. It would probably be best just to pick one container but IMHO developers would need to step up to help. Volunteers? Robert > > Bernd > > > >> >> - robert >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
