I can't think of any bug, and I hope there isn't any because that code looks like voodoo to me. Using the same container for both is arguable, as I said before I am not sold either way.If you have a resource constrained environment there are other things that we can do to reduce the size, which I have had in mind but never had any motivation to do, like remove all deprecated code, and extract the non simple tags into a plugin (these are the low hanging fruits).
IMO, do we have a *lot* to gain from it? probably not, but I am always in favor of eliminating any code that we have and is well done by other libraries On Mon, Dec 7, 2009 at 3:33 PM, Don Brown <mr...@twdata.org> wrote: > Well, two things: sharing an IoC container with the app is almost > always a bad idea in the long run, and two, maybe it is just me in a > resource-constrained environment, but 651kb is definitely a big deal, > especially if it brings in other dependencies like google collections. > The fact that Struts 2 is almost 5 megs means it is a no-go for me to > use in our embedded OSGi container. I was hoping to get it back down > under 2 megs, but with Guice 2, that would be quite unlikely. What > features exactly do we need or how many bugs have cropped up in our DI > container that we would be avoiding? > > Don > > On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <musa...@gmail.com> wrote: >> We could have just one container (no double object factory), and >> probably the same one could be used for s2 and the app (still to be >> seen if feasible or not), get any new features that get added or are >> in jsr 330, and we don't have maintain our own implementation when >> there is a lib that already does it, like we usually do. Also, guice 2 >> main jar is 651 kbs, so I don't see much of a problem there. >> >> musachy >> >> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote: >>> 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 >>> >>> >> >> --------------------------------------------------------------------- >> 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
