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
