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