ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like:
* create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <br...@pontarelli.com> wrote: > I was actually talking about expanding it out like Chris mentioned. I don't > see any reason why those who want to use the container that Struts is using > shouldn't be able to. Since the annotations and APIs will be standard across > Guice and Spring with the JSR, it seems like it would be possible to allow > the application and framework to use the same DI container, just different > Injectors. > > The default could be Guice but allow Spring to be pluggable (or even > discoverable). As long as the internals of Struts are compliant, it should > work fine. This also provides the benefit of configuration reduction in > web.xml and a more comprehensive solution. It would also get Struts out of > the business of building objects and requiring additional configuration and > plugins for different DI containers. I would guess it would clean up the > double ObjectFactory issues as well. > > -bp > > > > On Dec 1, 2009, at 11:31 AM, Musachy Barroso 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. >> >> 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
