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