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 08:18:09 GMT
Hi Bernd,

first off thank you for your comments. I think you stated the most
important point, we need some developers who will work on it ;)
I would be willing to help, getting this stuff done. But I'm still not
100% sure if we should go with Guice or Spring. Guice is more
lightweight but is "really" only a DI Framework. No J2EE stuff at all.
If we don't need (or want) any of this J2EE stuff I'm +1 for using
Guice. If we want to get Transactionmanagement, Remoting etc for free
go with Spring.
So I think the first question is "What features we want to get from
the Framework?"

I don't have enough knowledge of OSGI to say anthing about pros and cons of it.

Bye,
Norman



2009/8/10 Bernd Fondermann <bf_jak@brainlounge.de>:
> 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.
>
> For an application like James, setting onto one lightweight, imperative
> component model like Guice seems to be appropriate.
>
> 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.
>
> 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.
>
>  Bernd
>
> ---------------------------------------------------------------------
> 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