First, injecting the Container (or Injector as it is called) is allowed in the JSR and the API is abstracted well enough that it shouldn't cause major concerns.
On the flip-side, I contend that those instances are broken and can be fixed. I also don't agree that 330 is too narrow. It should support everything that XWork does and more, considering XWork is Guice 0.0. I'm not sure what Gavin's objections are, but perhaps someone should shoot Bob, Kevin or Rod an email and get their thoughts on this. -bp On Dec 8, 2009, at 9:24 PM, Don Brown wrote: > Remember, there are quite a few places that have the Container > instance injected, as they need to query it directly. JSR 330 is too > narrowly scoped to fully abstract DI, as folks like Gavin have been > quick to point out. > > Don > > On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli <br...@pontarelli.com> wrote: >> I believe that the simplest route would be to collapse everything into a >> single core JAR, which includes the workflow and other core APIs. This JAR >> would would use the JSR 330 annotations and a provide a couple of Module >> implementations. I would then have the Struts servlet filter wire everything >> up as needed using a JSR 330 compliant implementation. >> >> -bp >> >> >> On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote: >> >>> Since the XWork code is now owned by Apache (right?), you could split >>> it into two jars (workflow and DI). Then deprecate the DI artifact >>> unless someone here as aspirations to continue such support. Split in >>> two, this would hopefully also address Don's concern of the code base >>> being too big. >>> >>> Lastly, because Bob Lee is a Struts committer, you should get pretty >>> good support from him on. >>> >>> Paul >>> >>> On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli <br...@pontarelli.com> >>> wrote: >>>> XWork is more than DI. If drives the workflow under the hoods of Struts. >>>> We would need all of that code in addition to the DI. The idea is to drop >>>> the DI part of XWork and replace it with Guice 2.1 (which should support >>>> JSR 330) and just pull in the rest of it. >>>> >>>> -bp >>>> >>>> >>>> On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote: >>>> >>>>> Then what was the point of getting the IP for XWork? >>>>> >>>>> On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli <br...@pontarelli.com> >>>>> wrote: >>>>>> JSR 299 is EE while 330 is SE. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote: >>>>>> >>>>>>> I've been loosely following the thread. It sounds like three DI >>>>>>> projects are being/will be supported: >>>>>>> * XWork >>>>>>> * Guice >>>>>>> * JSR-299/JSR-330 >>>>>>> >>>>>>> Why three? I can understand the last because it's EE, but the other >>>>>>> two are proprietary. >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart >>>>>>> <lukasz.len...@googlemail.com> wrote: >>>>>>>> In my opinion, current DI support is sufficient (it can be made more >>>>>>>> readable, but that's it ;-), I really don't get it what's the problem >>>>>>>> with >>>>>>>> double ObjectFactory issue??? >>>>>>>> >>>>>>>> >>>>>>>> Regards >>>>>>>> -- >>>>>>>> Lukasz >>>>>>>> http://www.lenart.org.pl/ >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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 >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> 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 >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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 >> >> > > --------------------------------------------------------------------- > 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
