Because you don't want to use separate containers. In Guice you can have child-parent injector relationships. My thought is to just have a single DI container that builds everything. Struts no longer has any concept of an ObjectFactory and doesn't create actions or anything like that. It would just invoke actions created by the DI container.
Plus, if folks are asking for access to internals, this makes it simpler. You could also take the JCatapult approach and just have a single injector for everything. I personally like that approach the best, but Struts has had issues with public API breakage in the past and that would no longer be allowed if you have a single Injector. That is unless you roll a major version and follow a strict runtime compatibility methodology for a single major version's lineage. -bp On Dec 1, 2009, at 11:34 AM, Martin Cooper wrote: > On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso <musa...@gmail.com> wrote: >> this is not related to the application itself, you can still use any >> IoC you want. This is for the IoC that is used internally to wire >> struts internals together, which at the moment is an old version of >> guice which is in xwork. > > If it's "internal use only", so to speak, then why do we care about > whether it's JSR annotations versus Guice annotations, and why would > we want to make it pluggable? Those are things that app authors might > care about, but not something we need to complicate the internal > implementation with. > > -- > Martin Cooper > > >> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispr...@gmail.com> wrote: >>> I wouldn't have a problem with it as long as I can still swap in my trusty >>> Spring IoC container, I can't see my team moving away from it any time soon, >>> but I still want to try to stay as current as possible on Struts. >>> (*Chris*) >>> >>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli >>> <br...@pontarelli.com>wrote: >>> >>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>> that. >>>> >>>> The real question is how to setup the Injector's. I tend to think this >>>> layout would be best: >>>> >>>> Base >>>> | >>>> | >>>> _________ >>>> | | >>>> | | >>>> Struts App >>>> >>>> >>>> The Base injector will contain the JEE objects (request, response, etc.) >>>> and any Struts objects that can be used by the application. The Struts >>>> injector will contain all of the private objects that should not be >>>> accessible to the application. The App injector will contain all the >>>> application objects like Actions and such. >>>> >>>> -bp >>>> >>>> >>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>> >>>>> good point Brian, that has came up also. I have a couple of concerns >>>>> about it, like what is the status of the jsr and will the API >>>>> (annotations) will be under a decent (read ASF compatible license) >>>>> license and in maven central? which is usually a pain point when it >>>>> comes to Sun APIs. >>>>> >>>>> musachy >>>>> >>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <br...@pontarelli.com> >>>> wrote: >>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>> Guice annotations. I'd also make the injector pluggable so that people can >>>> plug in Spring/Guice/etc easily. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>> >>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>> be that hard. Less code to maintain, and we get more >>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>> into xwork to avoid classpath conflicts. >>>>>>> >>>>>>> what do you think? >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> 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
