james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Norman Maurer <nor...@apache.org>
Subject Re: Container/DI
Date Mon, 10 Aug 2009 16:24:46 GMT
Hi Robert,

comments below ...

2009/8/10 Robert Burrell Donkin <robertburrelldonkin@gmail.com>:
> On Mon, Aug 10, 2009 at 8:47 AM, Bernd Fondermann<bf_jak@brainlounge.de> wrote:
>> Norman Maurer wrote:
>>> Hi all,
>>> so what was the last conclusion about the "next" used Container/DI
>>> Framework ? I think I remember something like Spring/ServiceMix ? What
>>> we want to use ? Is there some final decission ? During my work on
>>> Hupa I used Guice which is really a nice slim DI-Framework. Maybe it
>>> worth to think on Guice too. I think it just depends what we want to
>>> use from the framework, if its just DI Guice is a nice choice. If we
>>> want to use some more J2EE stuff, spring is the way to go IMHO. This
>>> would at least give use some more stuff like TransactionManagement
>>> etc..
>> Guice, as far as I know it, uses an 'imperative' approach to component
>> management. Spring, how I use it generally, uses a declarative approach
>> (wire components via xml). That means, no component is aware of the
>> container it runs in. Only this way, the bridge to James/Spring was
>> possible. Nowadays, Spring also supports annotations, which are more
>> intrusive.
> i've played around with various options and found that annotations are
> the most direct replacement for avalon service provision and lifecycle
> management. i would much prefer to use JSR250 as opposed to either
> spring or guice specific annotations as replacements for these parts
> of the wiring.

Sounds ok and supported by guice (with guicefruit addon) :

>> For an application like James, setting onto one lightweight, imperative
>> component model like Guice seems to be appropriate.
> IMHO though we need to adopt a modern dependency injector, rolling out
> a comprehensive solution to replace avalon would be a lot to take on.
> in particular, replacing the excalibur components would be a lot of
> work for minimal gain.

Right, but I think its important to attract more developers. JAMES
will die, If we don't move forward  :/

>> And, as you know, I think OSGi is fine as a service-level component
>> framework, but it's bad (= really not made) for fine-grained complex
>> component structures like we have. So deciding to go with OSGi would not
>> make these discussions go away.
> +1
> for me, OSGi is an orthogonal issue: i see it as a phoenix replacement
> - allowing extensible, modular applications to be built using james
> components. OSGi+blueprint is an excellent fit for this use case but
> the technology isn't quite there yet. we probably don't need this
> right
> what's needed right now is simple a finely grained dependency injector
> to allow IMAP to be released and fail fast SMTP to be sorted out. i
> have a slight preference for spring (it's very well known) but guice
> is fine by me (though i wonder who easy it would be for system
> administrators to change assembly options with guice)

IMHO administrators should not need to hassle with assembly.xml files.
The administrator should only need to use the "configuration" file and
nothing else..

>> In the very end, and this is the most important thing I want to say, is
>> we need some people (1..n) to actually commits themself to start coding
>> on another component framework, whatever it is.
> +1
> - 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