james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: container and component model [Re: libs in spring deployment [Re: [jira] Commented: (JAMES-834)...]
Date Mon, 16 Mar 2009 18:04:53 GMT
On Mon, Mar 16, 2009 at 4:41 PM, Eric MacAdie <eric@macadie.net> wrote:
> Robert Burrell Donkin wrote:
>> On 3/12/09, Bernd Fondermann <bf_jak@brainlounge.de> wrote:


>>> 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.

the JEE option is really about gaining access to a good container
kernel - in a modern JEE container, the weight comes from the plugins.
james would need to ship with just the email plugins.

- robert

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

View raw message