Return-Path: Delivered-To: apmail-struts-dev-archive@www.apache.org Received: (qmail 99992 invoked from network); 7 Dec 2009 20:10:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 7 Dec 2009 20:10:07 -0000 Received: (qmail 38989 invoked by uid 500); 7 Dec 2009 20:10:06 -0000 Delivered-To: apmail-struts-dev-archive@struts.apache.org Received: (qmail 38906 invoked by uid 500); 7 Dec 2009 20:10:06 -0000 Mailing-List: contact dev-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Developers List" Reply-To: "Struts Developers List" Delivered-To: mailing list dev@struts.apache.org Received: (qmail 38896 invoked by uid 99); 7 Dec 2009 20:10:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Dec 2009 20:10:06 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of musachy@gmail.com designates 209.85.160.48 as permitted sender) Received: from [209.85.160.48] (HELO mail-pw0-f48.google.com) (209.85.160.48) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 07 Dec 2009 20:09:57 +0000 Received: by pwi6 with SMTP id 6so4279700pwi.27 for ; Mon, 07 Dec 2009 12:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=QbOETwrZucGFzsCcUafDraPLyNkG2INKz0GvI4eVYiw=; b=SKejVyE//Bh3vnsEOV5S9tJnMc41SSEjDiWIMT6/dQUo+l6+zxWvJsdnnrJukJggXv H0JBezaH3psCqNz9O7ojFGcPKE40JsBaCyTP/vAG8yx1UX7fKgP58wikRCx3j1Hzacal xqk8StLy+SV718fIK2A9R+27KUOBoreiymbs4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=I7iExnRuZ25DVDe3poVzYUvHyAIRY3YBVnU4vFZWxsty6g0pn4CUjtqRsVl+4KDg+a 5YCxy+ADswibxT3V8isbKAoefJXX6lYebFaHQuJXqXlfUQ7BrJlR9RWb3Jv5MIrsRifd 5j+mt6WyF+IhgRTW88+d+jG2DB/urApNtdfyA= MIME-Version: 1.0 Received: by 10.115.115.31 with SMTP id s31mr12822754wam.7.1260216576289; Mon, 07 Dec 2009 12:09:36 -0800 (PST) In-Reply-To: <4B1D605B.8030307@it-neering.net> References: <5EF0AD28-214E-4D5D-B8C1-6ACE6AF9A623@pontarelli.com> <42db7f0a0912011028j41449fa9m9701c8f109e4ec22@mail.gmail.com> <17972874-AF2F-4703-84F6-F531FECCEFB4@pontarelli.com> <4B1D605B.8030307@it-neering.net> Date: Mon, 7 Dec 2009 12:09:36 -0800 Message-ID: Subject: Re: struts 2.2 and guice From: Musachy Barroso To: Struts Developers List Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org 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 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 wro= te: >>> 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 wrote: >>>> We could probably make a list and verify. I think the API should be pr= etty 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 a= m >>>>> 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 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 stand= ard across Guice and Spring with the JSR, it seems like it would be possibl= e 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 we= b.xml and a more comprehensive solution. It would also get Struts out of th= e business of building objects and requiring additional configuration and p= lugins for different DI containers. I would guess it would clean up the dou= ble 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 an= y >>>>>>> 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 wrote: >>>>>>>> I wouldn't have a problem with it as long as I can still swap in m= y 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. >>>>>>>> =A0(*Chris*) >>>>>>>> >>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli wrote: >>>>>>>> >>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since G= uice uses >>>>>>>>> that. >>>>>>>>> >>>>>>>>> The real question is how to setup the Injector's. I tend to think= this >>>>>>>>> layout would be best: >>>>>>>>> >>>>>>>>> =A0 =A0 =A0 =A0Base >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0| >>>>>>>>> =A0 =A0 =A0 =A0 =A0 =A0| >>>>>>>>> =A0 _________ >>>>>>>>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>>>>>>> =A0 | =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| >>>>>>>>> Struts =A0 =A0 =A0 =A0App >>>>>>>>> >>>>>>>>> >>>>>>>>> The Base injector will contain the JEE objects (request, response= , etc.) >>>>>>>>> and any Struts objects that can be used by the application. The S= truts >>>>>>>>> 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 conc= erns >>>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>>> (annotations) will be under a decent (read ASF compatible licens= e) >>>>>>>>>> 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 >>>>>>>>> wrote: >>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather th= an the >>>>>>>>> Guice annotations. I'd also make the injector pluggable so that p= eople 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 wi= th guice >>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff w= ould 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-unsubscribe@struts.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------= ------ >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ----------------------------------------------------------------= ----- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> -----------------------------------------------------------------= ---- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> -------------------------------------------------------------------= -- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------= - >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org