struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Musachy Barroso <musa...@gmail.com>
Subject Re: struts 2.2 and guice
Date Tue, 01 Dec 2009 19:39:34 GMT
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 <musachy@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 <brian@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 <brian@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 <thechrispratt@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 <brian@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 <brian@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-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


Mime
View raw message