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 Mon, 10 Aug 2009 08:30:09 GMT
Norman Maurer wrote:
> 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?"

Transactions and JMX support are the only feature I can think of.

  Bernd


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


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