We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things.
-bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
