james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernd Fondermann <bf_...@brainlounge.de>
Subject Re: Container/DI
Date Thu, 13 Aug 2009 09:43:01 GMT
Robert Burrell Donkin wrote:
> 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.
> 
>> 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.

... and nobody proposed to replace excalibur, AFAICS. I think this is
already a long time consensus to keep them for now.

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

+1

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



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


Mime
View raw message