On Wed, Nov 28, 2012 at 4:39 PM, Dave Newton <davelnew...@gmail.com> wrote:
> IMO I'd rather see the internal mechanism be able to evolve and make use of
> vetted improvements instead of remaining in the land of Guice of 5+ years
> ago. Newer Guice has more capabilities.

I would like to mention the new incubator project Onami:
http://onami.incubator.apache.org

It is focusing on Guice components - I see some synergy here. And a
few of the components are really cool.

Cheers
Christian


> Dave
>  On Nov 28, 2012 10:27 AM, "Jeff Black" <jeffrey.bl...@yahoo.com> wrote:
>
>> Perhaps I am too old and have been in the consulting business too long,
>> but to change the internal DI facility -- which is working beautifully --
>> merely for the sake of changing seems to be an unnecessary risk.
>>
>>
>> My two cents.
>>
>> Jeff
>>
>>
>> ________________________________
>>  From: Rene Gielen <gie...@it-neering.net>
>> To: Struts Developers List <dev@struts.apache.org>
>> Sent: Wednesday, November 28, 2012 3:58 AM
>> Subject: Re: Plan for Struts 3
>>
>> Konstantin,
>>
>> you make a valid point that JSR 330 by itself is no solution to our
>> problems with internal injection. As I tried to explain in another post
>> to this thread, we have to differentiate between internal injection and
>> injection abstraction towards user side.
>>
>> As for how to evolve internal injection, integrating Guice would be the
>> option to go. Your points about the limits of class bound annotations
>> are valid, and that is why we have to decide for a concrete DI
>> implementation rather than a standard (though it is nice if it
>> introduces a standard on it's back). This is why Guice would make sense,
>> since it would support our mechanism of offering configuration options
>> apart from classes, via property injection and binding configuration
>> done in struts.xml, so without the need for DI framework specific
>> configuration files besides our own config.
>>
>> - René
>>
>> Am 28.11.12 09:01, schrieb Konstantin Priblouda:
>> > Hi guys,
>> >
>> > JSR 330 is cool and shall be definitely supported  -   but you still
>> need fallback metadata mechanism.
>> > Drawback of annotatioj is that it is class bound,   and thus you can
>> not  have two of something without
>> > subclassing.  Neither can you  reconfigure classes coming as jar
>> dependency.
>> >
>> > Just EUR 0.02  from picocontainer developer.
>> >
>> > regadrs,
>> >
>> > ----[ Konstantin Pribluda http://www.pribluda.de ]----------------
>> > JTec quality components: http://www.pribluda.de/projects/
>> >
>> >
>> > ________________________________
>> >  From: Paul Benedict <pbened...@apache.org>
>> > To: Struts Developers List <dev@struts.apache.org>
>> > Sent: Wednesday, November 28, 2012 8:31 AM
>> > Subject: Re: Plan for Struts 3
>> >
>> > Well I know that XWork had its only dependency injection support, but now
>> > that Java has a standard dependency injection mechanism, we should
>> > definitely go with that. Also it keeps on getting developed with each new
>> > EE so it's something we should support as a first-class citizen.
>> >
>> > On Wed, Nov 28, 2012 at 12:53 AM, Lukasz Lenart <lukaszlen...@apache.org
>> >wrote:
>> >
>> >> 2012/11/28 Paul Benedict <pbened...@apache.org>:
>> >>> What about dropping XWork injection support for JSR 330 (Commons DI)?
>> >>
>> >> You mean what we have now and use Guice as an internal DI mechanism ?
>> >>
>> >>
>> >> Regards
>> >> --
>> >> Łukasz
>> >> + 48 606 323 122 http://www.lenart.org.pl/
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>> >> For additional commands, e-mail: dev-h...@struts.apache.org
>> >>
>> >>
>>
>> --
>> René Gielen
>> IT-Neering.net
>> Saarstrasse 100, 52062 Aachen, Germany
>> Tel: +49-(0)241-4010770
>> Fax: +49-(0)241-4010771
>> Cel: +49-(0)163-2844164
>> http://twitter.com/rgielen
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
>> For additional commands, e-mail: dev-h...@struts.apache.org



--
http://www.grobmeier.de
https://www.timeandbill.de

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Reply via email to