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

Reply via email to