Would it be possible to write the internal code to use the JSR-330 API and supply Guice as the default, rather than tying the system directly to Guice? It seems like there would be an advantage to allowing the internal and external injections to potentially share an injection library rather than taking up twice the memory to do the same thing. (*Chris*)
On Wed, Nov 28, 2012 at 7: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 > >
