james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Eric MacAdie <e...@MacAdie.net>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Mon, 16 Mar 2009 16:41:18 GMT
Robert Burrell Donkin wrote:
> On 3/12/09, Bernd Fondermann <bf_jak@brainlounge.de> 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

I do not like the idea of using JEE. I am running a couple of James 
servers on VPS accounts with 256 MB of memory. Maybe JEE is no longer 
the memory-hog that it used to be, but keeping James as small as 
possible would be a good thing for me.

Eric MacAdie

To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message