struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pontarelli <br...@pontarelli.com>
Subject Re: struts 2.2 and guice
Date Wed, 09 Dec 2009 15:33:30 GMT
First, injecting the Container (or Injector as it is called) is allowed in the JSR and the
API is abstracted well enough that it shouldn't cause major concerns. 

On the flip-side, I contend that those instances are broken and can be fixed. 

I also don't agree that 330 is too narrow. It should support everything that XWork does and
more, considering XWork is Guice 0.0. I'm not sure what Gavin's objections are, but perhaps
someone should shoot Bob, Kevin or Rod an email and get their thoughts on this.

-bp


On Dec 8, 2009, at 9:24 PM, Don Brown wrote:

> Remember, there are quite a few places that have the Container
> instance injected, as they need to query it directly.  JSR 330 is too
> narrowly scoped to fully abstract DI, as folks like Gavin have been
> quick to point out.
> 
> Don
> 
> On Wed, Dec 9, 2009 at 2:47 PM, Brian Pontarelli <brian@pontarelli.com> wrote:
>> I believe that the simplest route would be to collapse everything into a single core
JAR, which includes the workflow and other core APIs. This JAR would would use the JSR 330
annotations and a provide a couple of Module implementations. I would then have the Struts
servlet filter wire everything up as needed using a JSR 330 compliant implementation.
>> 
>> -bp
>> 
>> 
>> On Dec 8, 2009, at 5:34 PM, Paul Benedict wrote:
>> 
>>> Since the XWork code is now owned by Apache (right?), you could split
>>> it into two jars (workflow and DI). Then deprecate the DI artifact
>>> unless someone here as aspirations to continue such support.  Split in
>>> two, this would hopefully also address Don's concern of the code base
>>> being too big.
>>> 
>>> Lastly, because Bob Lee is a Struts committer, you should get pretty
>>> good support from him on.
>>> 
>>> Paul
>>> 
>>> On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli <brian@pontarelli.com>
wrote:
>>>> XWork is more than DI. If drives the workflow under the hoods of Struts.
We would need all of that code in addition to the DI. The idea is to drop the DI part of XWork
and replace it with Guice 2.1 (which should support JSR 330) and just pull in the rest of
it.
>>>> 
>>>> -bp
>>>> 
>>>> 
>>>> On Dec 8, 2009, at 4:32 PM, Paul Benedict wrote:
>>>> 
>>>>> Then what was the point of getting the IP for XWork?
>>>>> 
>>>>> On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli <brian@pontarelli.com>
wrote:
>>>>>> JSR 299 is EE while 330 is SE.
>>>>>> 
>>>>>> -bp
>>>>>> 
>>>>>> 
>>>>>> On Dec 8, 2009, at 4:12 PM, Paul Benedict wrote:
>>>>>> 
>>>>>>> I've been loosely following the thread. It sounds like three
DI
>>>>>>> projects are being/will be supported:
>>>>>>> * XWork
>>>>>>> * Guice
>>>>>>> * JSR-299/JSR-330
>>>>>>> 
>>>>>>> Why three? I can understand the last because it's EE, but the
other
>>>>>>> two are proprietary.
>>>>>>> 
>>>>>>> Paul
>>>>>>> 
>>>>>>> On Tue, Dec 8, 2009 at 4:08 PM, Lukasz Lenart
>>>>>>> <lukasz.lenart@googlemail.com> wrote:
>>>>>>>> In my opinion, current DI support is sufficient (it can be
made more
>>>>>>>> readable, but that's it ;-), I really don't get it what's
the problem with
>>>>>>>> double ObjectFactory issue???
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> --
>>>>>>>> Lukasz
>>>>>>>> http://www.lenart.org.pl/
>>>>>>>> 
>>>>>>> 
>>>>>>> ---------------------------------------------------------------------
>>>>>>> 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


Mime
View raw message