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