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 Bernd Fondermann <bf...@brainlounge.de> on 2009/12/26 15:43:28 UTC
Re: Remove phoenix-deployment in favor of use pure Spring based
deployment
Norman Maurer wrote:
> Ok because I didn't hear anything against this route I will go ahead
> and try to get this stuff done.
Mmmh. I think you should give this another week or so to sink in. For
example, I am only now checking my email since days. Other might also
want to join in after the holidays. Collecting some more +1s would be
much safer.
Bernd
>
> Bye,
> Norman
>
> 2009/12/22 Dhrubo <dh...@gmail.com>:
>> Friends,
>> Move towards pure Spring away from dead frameworks is highly
>> appreciated. I think the move to a OSGi container may come in next release?
>> Thanks ...dhrubo
>>
>> On Tue, Dec 22, 2009 at 4:22 PM, Norman Maurer <no...@apache.org> wrote:
>>
>>> Hi all,
>>>
>>> as you all prolly know I tried to decouple james in the last couple of
>>> weeks from phoenix / avalon as much as possible. This task is now
>>> complete and James should "just work" within every container /
>>> framework which understand howto handle jsr250 injections. I thought
>>> about using OSGI + Karaf as container for James but I think that would
>>> require many reorganisation within the code to get it work like it
>>> should. So while using OSGI is prolly not the worst move to attract
>>> more users / developers I'm still not 100 % sure if its really a good
>>> idea at all.
>>>
>>> At the moment I tend to just remove the Avalon-Guice Adapter classes
>>> which I create for every component and let just handle spring the
>>> injection stuff. The Log and Configuration injection will get done via
>>> Spring by using a BeanPostProcessor (like its done in the current
>>> spring-avalon-bridge).
>>>
>>> So anyone against this "radical" move ?
>>>
>>> Bye,
>>> Norman
>>>
>>> Ps: This would eliminate the use of Guice again too
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>
>>>
>>
>> --
>> Thanks ... Dhrubo
>> My Book - http://www.apress.com/book/view/1430210095
>>
>> My Blog -
>> http://www.jtraining.com/blogs/blogger/dhrubo/
>>
>> LinkedIn - http://www.linkedin.com/in/dhrubo
>>
>
> ---------------------------------------------------------------------
> 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: Remove phoenix-deployment in favor of use pure Spring based
deployment
Posted by Norman Maurer <no...@googlemail.com>.
Good point.. Anyway I think I will start to work on this these days
(in a sandbox) just because I will have some time ;) If others think
it was a bad idea at the end I will be happy to just > /dev/null it
and threat it as an funny experiment ;)
Thx for the input.
Bye,
Norman
2009/12/26 Bernd Fondermann <bf...@brainlounge.de>:
> Norman Maurer wrote:
>> Ok because I didn't hear anything against this route I will go ahead
>> and try to get this stuff done.
>
> Mmmh. I think you should give this another week or so to sink in. For
> example, I am only now checking my email since days. Other might also
> want to join in after the holidays. Collecting some more +1s would be
> much safer.
>
> Bernd
>
>>
>> Bye,
>> Norman
>>
>> 2009/12/22 Dhrubo <dh...@gmail.com>:
>>> Friends,
>>> Move towards pure Spring away from dead frameworks is highly
>>> appreciated. I think the move to a OSGi container may come in next release?
>>> Thanks ...dhrubo
>>>
>>> On Tue, Dec 22, 2009 at 4:22 PM, Norman Maurer <no...@apache.org> wrote:
>>>
>>>> Hi all,
>>>>
>>>> as you all prolly know I tried to decouple james in the last couple of
>>>> weeks from phoenix / avalon as much as possible. This task is now
>>>> complete and James should "just work" within every container /
>>>> framework which understand howto handle jsr250 injections. I thought
>>>> about using OSGI + Karaf as container for James but I think that would
>>>> require many reorganisation within the code to get it work like it
>>>> should. So while using OSGI is prolly not the worst move to attract
>>>> more users / developers I'm still not 100 % sure if its really a good
>>>> idea at all.
>>>>
>>>> At the moment I tend to just remove the Avalon-Guice Adapter classes
>>>> which I create for every component and let just handle spring the
>>>> injection stuff. The Log and Configuration injection will get done via
>>>> Spring by using a BeanPostProcessor (like its done in the current
>>>> spring-avalon-bridge).
>>>>
>>>> So anyone against this "radical" move ?
>>>>
>>>> Bye,
>>>> Norman
>>>>
>>>> Ps: This would eliminate the use of Guice again too
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
>>>> For additional commands, e-mail: server-dev-help@james.apache.org
>>>>
>>>>
>>>
>>> --
>>> Thanks ... Dhrubo
>>> My Book - http://www.apress.com/book/view/1430210095
>>>
>>> My Blog -
>>> http://www.jtraining.com/blogs/blogger/dhrubo/
>>>
>>> LinkedIn - http://www.linkedin.com/in/dhrubo
>>>
>>
>> ---------------------------------------------------------------------
>> 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