You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Norman Maurer <no...@apache.org> on 2009/08/06 21:06:37 UTC
Container/DI
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..
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Fri, Aug 14, 2009 at 12:20 AM, rafael.munoz<ra...@gmail.com> wrote:
>
> Hello
>
> Just to add my humble 2 cents to the discussion. Feel free to discard it as
> I am not a James developer or anything.
>
> I have been using Guice for the past year and it has been a revelation. Very
> easy to use if you have a good grasp of the DI concepts but quite powerful
> too. It pushs all the right buttons (constructor injection, easy
> configuration, annotations, etc). In my opinion, right now, the way to go
> for any project of the size of James is Guice+OSGi. Guice for services
> building and OSGi as services container.
>
> I will be willing to help on the transaction. I guess that for someone as me
> that as not a deep knowledge of the James code base the easy way to help is
> to migrate services/modules to Guice but I will help in whatever the project
> needs.
that'd be really great :-)
how do you want to start?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by "rafael.munoz" <ra...@gmail.com>.
Hello
Just to add my humble 2 cents to the discussion. Feel free to discard it as
I am not a James developer or anything.
I have been using Guice for the past year and it has been a revelation. Very
easy to use if you have a good grasp of the DI concepts but quite powerful
too. It pushs all the right buttons (constructor injection, easy
configuration, annotations, etc). In my opinion, right now, the way to go
for any project of the size of James is Guice+OSGi. Guice for services
building and OSGi as services container.
I will be willing to help on the transaction. I guess that for someone as me
that as not a deep knowledge of the James code base the easy way to help is
to migrate services/modules to Guice but I will help in whatever the project
needs.
regards,
Rafael Muñoz
Bernd Fondermann wrote:
>
> Norman Maurer wrote:
>> Hi Bob,
>>
>> w0h00 I was not aware of that. Thx for sharing this. With this stuff
>> avaible I'm +1 to move from avalon/spring to guice.
>>
>> Anyone who would like to help getting this done ? Or anyone here who
>> think this is a bad idea ? Should I start a VOTE ?
>
> Why not. This would manifest this decision for everyone to see.
>
> Bernd
>
>>
>> Bye,
>> Norman
> <snip/>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
> For additional commands, e-mail: server-dev-help@james.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Container-DI-tp24852594p24962139.html
Sent from the James - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Norman Maurer wrote:
> Hi Bob,
>
> w0h00 I was not aware of that. Thx for sharing this. With this stuff
> avaible I'm +1 to move from avalon/spring to guice.
>
> Anyone who would like to help getting this done ? Or anyone here who
> think this is a bad idea ? Should I start a VOTE ?
Why not. This would manifest this decision for everyone to see.
Bernd
>
> Bye,
> Norman
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
Hi Bob,
w0h00 I was not aware of that. Thx for sharing this. With this stuff
avaible I'm +1 to move from avalon/spring to guice.
Anyone who would like to help getting this done ? Or anyone here who
think this is a bad idea ? Should I start a VOTE ?
Bye,
Norman
Ps: Bob what about helping to get this done with some patches ;) ?
2009/8/10 Bob Lee <cr...@gmail.com>:
> On Mon, Aug 10, 2009 at 1:18 AM, Norman Maurer <no...@apache.org> wrote:
>
>> 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?"
>>
>
> FWIW, Guice has enterprise support. See:
>
> guiceyfruit: http://code.google.com/p/guiceyfruit/
> Warp: http://www.wideplay.com/guicewebextensions2
>
> Bob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Bob Lee <cr...@gmail.com>.
On Mon, Aug 10, 2009 at 1:18 AM, Norman Maurer <no...@apache.org> wrote:
> 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?"
>
FWIW, Guice has enterprise support. See:
guiceyfruit: http://code.google.com/p/guiceyfruit/
Warp: http://www.wideplay.com/guicewebextensions2
Bob
Re: Container/DI
Posted by Bernd Fondermann <bf...@brainlounge.de>.
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...@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
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
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...@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
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
Thx for remember me about properties files and guice, I just committed
a change to hupa todo exactly this.
Bye,
Norman
2009/8/10 Bob Lee <cr...@gmail.com>:
> On Mon, Aug 10, 2009 at 9:24 AM, Norman Maurer <no...@apache.org> wrote:
>
>> > 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.
>>
>> > i've played around with various options and found that annotations are
>> Sounds ok and supported by guice (with guicefruit addon) :
>> http://code.google.com/p/guiceyfruit/wiki/Annotations
>>
>
> You could also use the Guice annotations for now and easily replace them
> with JSR-330 annotations later.
>
>
>> IMHO administrators should not need to hassle with assembly.xml files.
>> The administrator should only need to use the "configuration" file and
>> nothing else..
>
>
> Exactly. Guice makes it trivial to bind values from properties files, for
> example.
>
> Bob
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 10, 2009 at 5:28 PM, Bob Lee<cr...@gmail.com> wrote:
> On Mon, Aug 10, 2009 at 9:24 AM, Norman Maurer <no...@apache.org> wrote:
>
>> > 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.
>>
>> > i've played around with various options and found that annotations are
>> Sounds ok and supported by guice (with guicefruit addon) :
>> http://code.google.com/p/guiceyfruit/wiki/Annotations
>>
>
> You could also use the Guice annotations for now and easily replace them
> with JSR-330 annotations later.
http://code.google.com/p/guiceyfruit/ supports JSR-250 now and
provides the lifecycle support that would be needed to replace the
avalon lifecycle management stuff
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Bob Lee <cr...@gmail.com>.
On Mon, Aug 10, 2009 at 9:24 AM, Norman Maurer <no...@apache.org> wrote:
> > 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.
>
> > i've played around with various options and found that annotations are
> Sounds ok and supported by guice (with guicefruit addon) :
> http://code.google.com/p/guiceyfruit/wiki/Annotations
>
You could also use the Guice annotations for now and easily replace them
with JSR-330 annotations later.
> IMHO administrators should not need to hassle with assembly.xml files.
> The administrator should only need to use the "configuration" file and
> nothing else..
Exactly. Guice makes it trivial to bind values from properties files, for
example.
Bob
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
yep..
Bye,
Norman
2009/8/10 Robert Burrell Donkin <ro...@gmail.com>:
> On Mon, Aug 10, 2009 at 8:14 PM, Norman Maurer<no...@apache.org> wrote:
>> Hi Robert,
>>
>> +1 for replacing the proof of concept with Guice. After this is done I
>> would be interested to see how we could SMTP work with it. Maybe this
>> will make the current SMTP work of me much easier.
>
> would adding it on a new branch in the sandbox be best...?
>
> - 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
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 10, 2009 at 8:14 PM, Norman Maurer<no...@apache.org> wrote:
> Hi Robert,
>
> +1 for replacing the proof of concept with Guice. After this is done I
> would be interested to see how we could SMTP work with it. Maybe this
> will make the current SMTP work of me much easier.
would adding it on a new branch in the sandbox be best...?
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
Hi Robert,
+1 for replacing the proof of concept with Guice. After this is done I
would be interested to see how we could SMTP work with it. Maybe this
will make the current SMTP work of me much easier.
Bye,
Norman
2009/8/10 Robert Burrell Donkin <ro...@gmail.com>:
> On Mon, Aug 10, 2009 at 5:24 PM, Norman Maurer<no...@apache.org> wrote:
>> 2009/8/10 Robert Burrell Donkin <ro...@gmail.com>:
>>> On Mon, Aug 10, 2009 at 8:47 AM, Bernd Fondermann<bf...@brainlounge.de> wrote:
>
> <snip>
>
>>>> 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 :/
>
> i'm arguing about tactics, not strategy
>
> i've already mixed prototype JSR-250 based lifecycle and dependency
> injection into trunk (to make IMAP run) on a per-service basis. this
> has been running fine in my installation for six months now. we could
> just replace the proof-of-concept DI container with guice (or spring,
> if people prefer). that would allow you to use guice for SMTP without
> having to port the rest of the system right away.
>
> - 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
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 10, 2009 at 5:24 PM, Norman Maurer<no...@apache.org> wrote:
> 2009/8/10 Robert Burrell Donkin <ro...@gmail.com>:
>> On Mon, Aug 10, 2009 at 8:47 AM, Bernd Fondermann<bf...@brainlounge.de> wrote:
<snip>
>>> 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 :/
i'm arguing about tactics, not strategy
i've already mixed prototype JSR-250 based lifecycle and dependency
injection into trunk (to make IMAP run) on a per-service basis. this
has been running fine in my installation for six months now. we could
just replace the proof-of-concept DI container with guice (or spring,
if people prefer). that would allow you to use guice for SMTP without
having to port the rest of the system right away.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
Hi Robert,
comments below ...
2009/8/10 Robert Burrell Donkin <ro...@gmail.com>:
> On Mon, Aug 10, 2009 at 8:47 AM, Bernd Fondermann<bf...@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) :
http://code.google.com/p/guiceyfruit/wiki/Annotations
>
>> 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
>
Bye,
Norman
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Robert Burrell Donkin wrote:
> On Mon, Aug 10, 2009 at 8:47 AM, Bernd Fondermann<bf...@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
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Mon, Aug 10, 2009 at 8:47 AM, Bernd Fondermann<bf...@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, 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)
> 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
Re: Container/DI
Posted by Bernd Fondermann <bf...@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
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 6, 2009 at 8:31 PM, Eric MacAdie<er...@macadie.net> wrote:
> Regarding your J2EE comment: I am running James on a VPS account with about
> 300 MB of memory. So I do not want something too memory intensive. Perhaps
> Pico or Guice would be better if they are smaller.
in terms of memory usage, the container usually matter more than the
DI. pheonix is good but more modern alternative containers are
comparable. karaf has a very good shell (much better than remote
manager) but this uses more memory.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Eric MacAdie <er...@MacAdie.net>.
Regarding your J2EE comment: I am running James on a VPS account with
about 300 MB of memory. So I do not want something too memory intensive.
Perhaps Pico or Guice would be better if they are smaller.
Eric MacAdie
---------------------
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..
>
> Bye,
> Norman
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Sat, Aug 8, 2009 at 9:24 PM, Norman Maurer<no...@apache.org> wrote:
> Hi Markus,
>
> for guice you would use diffrent Modules for that. For everyone
> interested in guice check out:
> http://code.google.com/intl/de-DE/events/io/sessions/BigModularJavaGuice.html
I know the basics about Guice, please let me rephrase:
Let's say we have an OSGi bundle for pop3 support in James. I think it
would be natural for that bundle to define its own Guice module to
bind interfaces to implementations inside the bundle. Similarly the
imap and smtp bundles would define their own Guice modules.
What's unclear to me is the role of the "main" james bundle. Sure, the
main bundle could define a Guice module that included the modules
defined by smtp, pop3 and imap. But then how can the pop3 bundle (and
its Guice module) be an optional component in the application?
Maybe Peaberry has an answer to that, need to investigate..
Markus
> Bye,
> Norman
>
> 2009/8/8 Markus Wiederkehr <ma...@gmail.com>:
>> On Sat, Aug 8, 2009 at 12:34 PM, Robert Burrell
>> Donkin<ro...@gmail.com> wrote:
>>> On Thu, Aug 6, 2009 at 8:06 PM, Norman Maurer<no...@apache.org> wrote:
>>>> Hi all,
>>>>
>>>> so what was the last conclusion about the "next" used Container/DI
>>>> Framework ?
>>>
>>> IIRC the last round was won by stefano who proved his point about OSGi
>>> being popular
>>
>> +1 on OSGi. Private bundle class spaces are reason enough IMO.
>>
>>>> I think I remember something like Spring/ServiceMix ?
>>>
>>> ServiceMix moved their OSGi kernel to felix and it's now called Karaf.
>>> karaf does blueprint (a standard developed from spring DM) and
>>> integrates with spring.
>>
>> Blueprint could be a way to wire things but I haven't really looked
>> into it yet. (I'm not very fond of the XML approach.)
>>
>>> but this is a little orthogonal, since karaf is flexible and plays
>>> well with standards
>>
>> As long as it runs in other OSGi containers, too. Personally I would
>> like to deploy James in Equinox.
>>
>>>> What we want to use ?
>>>
>>> personally speaking, i think that decisions about the service layer
>>> should be separated from decisions about AI assembly of those services
>>>
>>> OSGi would be great for the service layer but it'd be a lot of work.
>>> i've been trying to create an OSGified version of avalon but i'm not
>>> sure whether i'll find the time i need to finish the work...
>>>
>>>> Is there some final decission ?
>>>
>>> if only :-/
>>>
>>> IMHO this is killing james as a project. maybe it's time to stop
>>> worrying too much about vetos...
>>
>> Could we list a few reasonable alternatives and have a vote?
>>
>>>> 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.
>>>
>>> guice is cool (the limited annotation based glue i added is a poor-mans-version)
>>
>> Guice sure looks interesting. +1 on annotation based injection.
>>
>> And it does not have to be either OSGi or Guice, see [1]. Peaberry
>> could be worth looking into.
>>
>> I'm not sure how Guice could work with optional bundles though. Let's
>> say we have bundles for smtp, pop3 and imap and some kind of main
>> bundle. Obviously it should be possible to run James without deploying
>> the pop3 bundle, for example. But how would you define Guice modules
>> for that?
>>
>> Markus
>>
>> [1] http://code.google.com/docreader/#p=google-guice&s=google-guice&t=OSGi
>>
>>> some changes would be needed to move from away from avalon's
>>> service-injection model
>>>
>>>> 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..
>>>
>>> spring has the advantage that we have a working bridge for avalon
>>>
>>> - robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Norman Maurer <no...@apache.org>.
Hi Markus,
for guice you would use diffrent Modules for that. For everyone
interested in guice check out:
http://code.google.com/intl/de-DE/events/io/sessions/BigModularJavaGuice.html
Bye,
Norman
2009/8/8 Markus Wiederkehr <ma...@gmail.com>:
> On Sat, Aug 8, 2009 at 12:34 PM, Robert Burrell
> Donkin<ro...@gmail.com> wrote:
>> On Thu, Aug 6, 2009 at 8:06 PM, Norman Maurer<no...@apache.org> wrote:
>>> Hi all,
>>>
>>> so what was the last conclusion about the "next" used Container/DI
>>> Framework ?
>>
>> IIRC the last round was won by stefano who proved his point about OSGi
>> being popular
>
> +1 on OSGi. Private bundle class spaces are reason enough IMO.
>
>>> I think I remember something like Spring/ServiceMix ?
>>
>> ServiceMix moved their OSGi kernel to felix and it's now called Karaf.
>> karaf does blueprint (a standard developed from spring DM) and
>> integrates with spring.
>
> Blueprint could be a way to wire things but I haven't really looked
> into it yet. (I'm not very fond of the XML approach.)
>
>> but this is a little orthogonal, since karaf is flexible and plays
>> well with standards
>
> As long as it runs in other OSGi containers, too. Personally I would
> like to deploy James in Equinox.
>
>>> What we want to use ?
>>
>> personally speaking, i think that decisions about the service layer
>> should be separated from decisions about AI assembly of those services
>>
>> OSGi would be great for the service layer but it'd be a lot of work.
>> i've been trying to create an OSGified version of avalon but i'm not
>> sure whether i'll find the time i need to finish the work...
>>
>>> Is there some final decission ?
>>
>> if only :-/
>>
>> IMHO this is killing james as a project. maybe it's time to stop
>> worrying too much about vetos...
>
> Could we list a few reasonable alternatives and have a vote?
>
>>> 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.
>>
>> guice is cool (the limited annotation based glue i added is a poor-mans-version)
>
> Guice sure looks interesting. +1 on annotation based injection.
>
> And it does not have to be either OSGi or Guice, see [1]. Peaberry
> could be worth looking into.
>
> I'm not sure how Guice could work with optional bundles though. Let's
> say we have bundles for smtp, pop3 and imap and some kind of main
> bundle. Obviously it should be possible to run James without deploying
> the pop3 bundle, for example. But how would you define Guice modules
> for that?
>
> Markus
>
> [1] http://code.google.com/docreader/#p=google-guice&s=google-guice&t=OSGi
>
>> some changes would be needed to move from away from avalon's
>> service-injection model
>>
>>> 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..
>>
>> spring has the advantage that we have a working bridge for avalon
>>
>> - 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Markus Wiederkehr <ma...@gmail.com>.
On Sat, Aug 8, 2009 at 12:34 PM, Robert Burrell
Donkin<ro...@gmail.com> wrote:
> On Thu, Aug 6, 2009 at 8:06 PM, Norman Maurer<no...@apache.org> wrote:
>> Hi all,
>>
>> so what was the last conclusion about the "next" used Container/DI
>> Framework ?
>
> IIRC the last round was won by stefano who proved his point about OSGi
> being popular
+1 on OSGi. Private bundle class spaces are reason enough IMO.
>> I think I remember something like Spring/ServiceMix ?
>
> ServiceMix moved their OSGi kernel to felix and it's now called Karaf.
> karaf does blueprint (a standard developed from spring DM) and
> integrates with spring.
Blueprint could be a way to wire things but I haven't really looked
into it yet. (I'm not very fond of the XML approach.)
> but this is a little orthogonal, since karaf is flexible and plays
> well with standards
As long as it runs in other OSGi containers, too. Personally I would
like to deploy James in Equinox.
>> What we want to use ?
>
> personally speaking, i think that decisions about the service layer
> should be separated from decisions about AI assembly of those services
>
> OSGi would be great for the service layer but it'd be a lot of work.
> i've been trying to create an OSGified version of avalon but i'm not
> sure whether i'll find the time i need to finish the work...
>
>> Is there some final decission ?
>
> if only :-/
>
> IMHO this is killing james as a project. maybe it's time to stop
> worrying too much about vetos...
Could we list a few reasonable alternatives and have a vote?
>> 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.
>
> guice is cool (the limited annotation based glue i added is a poor-mans-version)
Guice sure looks interesting. +1 on annotation based injection.
And it does not have to be either OSGi or Guice, see [1]. Peaberry
could be worth looking into.
I'm not sure how Guice could work with optional bundles though. Let's
say we have bundles for smtp, pop3 and imap and some kind of main
bundle. Obviously it should be possible to run James without deploying
the pop3 bundle, for example. But how would you define Guice modules
for that?
Markus
[1] http://code.google.com/docreader/#p=google-guice&s=google-guice&t=OSGi
> some changes would be needed to move from away from avalon's
> service-injection model
>
>> 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..
>
> spring has the advantage that we have a working bridge for avalon
>
> - 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
Re: Container/DI
Posted by Robert Burrell Donkin <ro...@gmail.com>.
On Thu, Aug 6, 2009 at 8:06 PM, Norman Maurer<no...@apache.org> wrote:
> Hi all,
>
> so what was the last conclusion about the "next" used Container/DI
> Framework ?
IIRC the last round was won by stefano who proved his point about OSGi
being popular
> I think I remember something like Spring/ServiceMix ?
ServiceMix moved their OSGi kernel to felix and it's now called Karaf.
karaf does blueprint (a standard developed from spring DM) and
integrates with spring.
but this is a little orthogonal, since karaf is flexible and plays
well with standards
> What we want to use ?
personally speaking, i think that decisions about the service layer
should be separated from decisions about AI assembly of those services
OSGi would be great for the service layer but it'd be a lot of work.
i've been trying to create an OSGified version of avalon but i'm not
sure whether i'll find the time i need to finish the work...
> Is there some final decission ?
if only :-/
IMHO this is killing james as a project. maybe it's time to stop
worrying too much about vetos...
> 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.
guice is cool (the limited annotation based glue i added is a poor-mans-version)
some changes would be needed to move from away from avalon's
service-injection model
> 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..
spring has the advantage that we have a working bridge for avalon
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org
Re: Container/DI
Posted by Eric MacAdie <er...@MacAdie.net>.
It looks to me like a lot of people in the thread are leaning towards
using Guice.
Eric MacAdie
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..
>
> Bye,
> Norman
>
---------------------------------------------------------------------
To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org