Late to the party, but I'm not clear why you would want to use Guice 2 instead of our own. Is there some feature we need that Guice 2 has? If not, we are basically sucking in a pretty significantly sized library for no apparent reason. I tried to use Struts 2 on a project here, and was a bit shocked at the size of the jar nowadays...seems we went a bit crazy with the shading. I'd generally advise against adding more bulk without obvious gains.
Don On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <musa...@gmail.com> wrote: > I don't know about dropping Object factory, in this case it would just > delegate to the jsr 330 implementation. But getting rid of the double > object factory problem would be very nice. > > On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen <gie...@it-neering.net> wrote: >> I'm a huge fan of moving to Guice 2 internally, although I'm not sure if >> we would want to drop the ObjectFactory abstraction for plain pluggable >> JSR330 DI - as this would imply that Struts 2.2 would not integrate any >> more against Spring 2.x, Guice 1, Plexus, PicoContainer and what not. Do >> we really expect every Struts2 user and his company will be able to move >> to JSR330 compliant DI within the next months? I doubt that, and I'd >> rather not sacrifice our DI abstraction for that reason... >> >> - Rene >> >> >> Musachy Barroso wrote: >>> I am reading the spec and I am rather impressed, I thought it would be >>> a simple thing but it is really comprehensive. I doubt we will have a >>> use case that won't be covered there. >>> >>> musachy >>> >>> On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso <musa...@gmail.com> wrote: >>>> It is good that you brought this up, because the double object factory >>>> is annoying and creates a lot of unexpected situations(problems with >>>> class reloading and OSGi). Having just one container would make it >>>> easier for everybody, users and s2 developers, if it can be pulled >>>> off. >>>> >>>> This kind of change could be too big for a 2.x release I think >>>> >>>> musachy >>>> >>>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <br...@pontarelli.com> >>>> wrote: >>>>> 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 >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> 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
