Internal means everything consuming the c.o.xwork.Inject annotation and of course the providing mechanism for this one.
As a user, even today I would never ever (ok, unless I really know what I'm doing) consume this annotation. And I don't have to, since Spring, Guice and CDI plugin provide me with javax.inject support within my actions or interceptors. Am 28.11.12 16:58, schrieb Paul Benedict: > Can I get some clarification on "internal mechanism"? I may have > misspoke; I would like Struts users to use Commons DI over XWork > injection. That's something different than the way Struts wires up > itself, right? > > On Wed, Nov 28, 2012 at 9:53 AM, Rene Gielen <gie...@it-neering.net> wrote: >> Also I think our core competence here at Struts is building web >> frameworks, not dependency injection frameworks. The original >> maintainers aren't active any more. The current code is in a state of >> "don't touch, it might blow up without warning". Fiddling out a memory >> leak in the DI code lately took me ages. The fix actually was a three >> liner, but understanding the possible impact and evaluating the risks >> was ... let's put it that way ... an experience. >> >> For that reason improvements on the DI abstraction layer are hard as >> well. Modern containers such as Weld / CDI have more sophistiocated >> lifecycle models which we could support in our abstraction layer, if >> only we were able to map it to the underlying mechanism. I see hard work >> coming up to advance on that topic with the current hand-rolled injector. >> >> But nevertheless - it works, fair enough. To decide whether we are doing >> something worthy with a switch to Guice we need to give it a try (and of >> course volunteers willing to give it a try). The 3.x fork would be the >> perfect playground I guess. >> >> - René >> >> Am 28.11.12 16:39, schrieb Dave Newton: >>> 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. >>> >>> 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 >>> >> >> -- >> 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 >> > > --------------------------------------------------------------------- > 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
