You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@struts.apache.org by Musachy Barroso <mu...@gmail.com> on 2009/12/01 18:33:20 UTC
struts 2.2 and guice
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
Re: struts 2.2 and guice
Posted by Wes Wannemacher <we...@wantii.com>.
On Tue, Dec 8, 2009 at 11:22 PM, Don Brown <mr...@twdata.org> wrote:
> It isn't about needing a "struts-light", it is adding unnecessary
> bulk. When I was more active, I spent a lot of time trying to kick
> out dependencies, tighten up our weak API's, and overall simplify
> interactions with the framework. If you look at the framework space
> right now, your best bet for a server-side framework is either Grails
> or possibly Wicket. GWT is increasingly taking over as well. Let's
> be honest - Struts 2 can't compete with Grails for features and the UI
> component power of Wicket or GWT. Where it is good, however, is being
> a small, flexible framework that can integration with just about
> anything. If we lose this, I'm not sure when I would recommend it.
>
[snip]
I am a bit behind here, but we aren't talking about getting rid of the
ObjectFactory abstraction and adopting JSR 330 solely for that
purpose? If you ask me, I would think that if the Java community is
standardizing DI, we should follow suit, internally, as well as making
DI available as a pluggable feature the same way we have done in the
past.
I think one of the biggest barriers of entry is the Container
currently. Working on Struts 2 / XWork is hard and the learning curve
is steep, and I think a big part of that is our Container. Unless you
play around with it and see how it's used everywhere, it is
intimidating and part of the reason (I think) why we don't see more
patches in JIRA.
As far as GWT and Wicket, I don't think we should even compare. The
flexibility of our tag library is beyond what I've seen from either of
those. I'm not saying they aren't good, but the value stack
abstraction and ability to bind data to form fields non-invasively
makes it much easier to implement Ajax in some places and server-side
manipulation in others. I find struts to be advanced enough for my
liking, while still being easy enough that I can be productive.
As for Grails, I can't really say, I haven't gotten too much into it yet.
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Don Brown <mr...@twdata.org>.
It isn't about needing a "struts-light", it is adding unnecessary
bulk. When I was more active, I spent a lot of time trying to kick
out dependencies, tighten up our weak API's, and overall simplify
interactions with the framework. If you look at the framework space
right now, your best bet for a server-side framework is either Grails
or possibly Wicket. GWT is increasingly taking over as well. Let's
be honest - Struts 2 can't compete with Grails for features and the UI
component power of Wicket or GWT. Where it is good, however, is being
a small, flexible framework that can integration with just about
anything. If we lose this, I'm not sure when I would recommend it.
Don
On Wed, Dec 9, 2009 at 5:08 AM, Wes Wannemacher <we...@wantii.com> wrote:
> Don,
>
> I would argue the opposite... I understand that you are going to have
> trouble in a resource-constrained environment, and as Musachy mentions
> later in the thread, there are things we could dump to regain space...
> But! Most of our users aren't resource-constrained... At least, if
> they are, they aren't complaining about it. If we moved infrequently
> used interceptors, results and all their supporting classes into
> plugins (which would be pretty easy, mostly due to your hard work),
> then that would just make it more difficult for the vast majority of
> users.
>
> If you want to start a struts2-lite project, I'd be happy to jump in
> and help out, but I think that resource-constrained environments are
> the exception, not a rule to live by.
>
> -Wes
>
> On Mon, Dec 7, 2009 at 6:33 PM, Don Brown <mr...@twdata.org> wrote:
>> Well, two things: sharing an IoC container with the app is almost
>> always a bad idea in the long run, and two, maybe it is just me in a
>> resource-constrained environment, but 651kb is definitely a big deal,
>> especially if it brings in other dependencies like google collections.
>> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
>> use in our embedded OSGi container. I was hoping to get it back down
>> under 2 megs, but with Guice 2, that would be quite unlikely. What
>> features exactly do we need or how many bugs have cropped up in our DI
>> container that we would be avoiding?
>>
>> Don
>>
>> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>> We could have just one container (no double object factory), and
>>> probably the same one could be used for s2 and the app (still to be
>>> seen if feasible or not), get any new features that get added or are
>>> in jsr 330, and we don't have maintain our own implementation when
>>> there is a lib that already does it, like we usually do. Also, guice 2
>>> main jar is 651 kbs, so I don't see much of a problem there.
>>>
>>> musachy
>>>
>>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>>> instead of our own. Is there some feature we need that Guice 2 has?
>>>> If not, we are basically sucking in a pretty significantly sized
>>>> library for no apparent reason. I tried to use Struts 2 on a project
>>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>>> went a bit crazy with the shading. I'd generally advise against
>>>> adding more bulk without obvious gains.
>>>>
>>>> Don
>>>>
>>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
>>
>>
>
>
>
> --
> Wes Wannemacher
>
> Head Engineer, WanTii, Inc.
> Need Training? Struts, Spring, Maven, Tomcat...
> Ask me for a quote!
>
> ---------------------------------------------------------------------
> 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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
I can't think of any bug, and I hope there isn't any because that code
looks like voodoo to me. Using the same container for both is
arguable, as I said before I am not sold either way.If you have a
resource constrained environment there are other things that we can do
to reduce the size, which I have had in mind but never had any
motivation to do, like remove all deprecated code, and extract the non
simple tags into a plugin (these are the low hanging fruits).
IMO, do we have a *lot* to gain from it? probably not, but I am always
in favor of eliminating any code that we have and is well done by
other libraries
On Mon, Dec 7, 2009 at 3:33 PM, Don Brown <mr...@twdata.org> wrote:
> Well, two things: sharing an IoC container with the app is almost
> always a bad idea in the long run, and two, maybe it is just me in a
> resource-constrained environment, but 651kb is definitely a big deal,
> especially if it brings in other dependencies like google collections.
> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
> use in our embedded OSGi container. I was hoping to get it back down
> under 2 megs, but with Guice 2, that would be quite unlikely. What
> features exactly do we need or how many bugs have cropped up in our DI
> container that we would be avoiding?
>
> Don
>
> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
>> We could have just one container (no double object factory), and
>> probably the same one could be used for s2 and the app (still to be
>> seen if feasible or not), get any new features that get added or are
>> in jsr 330, and we don't have maintain our own implementation when
>> there is a lib that already does it, like we usually do. Also, guice 2
>> main jar is 651 kbs, so I don't see much of a problem there.
>>
>> musachy
>>
>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>> instead of our own. Is there some feature we need that Guice 2 has?
>>> If not, we are basically sucking in a pretty significantly sized
>>> library for no apparent reason. I tried to use Struts 2 on a project
>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>> went a bit crazy with the shading. I'd generally advise against
>>> adding more bulk without obvious gains.
>>>
>>> Don
>>>
>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
what we are proposing/talking is to use only JSR 330, which is the
spec. The actual implementation (default) would be guice.
musachy
On Tue, Dec 8, 2009 at 3:12 PM, Paul Benedict <pb...@apache.org> 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
> <lu...@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
Re: struts 2.2 and guice
Posted by Don Brown <mr...@twdata.org>.
On Wed, Dec 9, 2009 at 11:34 AM, Paul Benedict <pb...@apache.org> wrote:
> Lastly, because Bob Lee is a Struts committer, you should get pretty
> good support from him on.
Don't count on it. Bob has moved on from Struts 2, so I would count
on anything beyond moral support. :)
Don
>
> Paul
>
> On Tue, Dec 8, 2009 at 5:37 PM, Brian Pontarelli <br...@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 <br...@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
>>>>> <lu...@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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <br...@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 <br...@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 <br...@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
>>>>>>> <lu...@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
Re: struts 2.2 and guice
Posted by Don Brown <mr...@twdata.org>.
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 <br...@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 <br...@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 <br...@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
>>>>>> <lu...@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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <br...@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 <br...@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
>>>>> <lu...@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
Re: struts 2.2 and guice
Posted by Paul Benedict <pb...@apache.org>.
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 <br...@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 <br...@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
>>>> <lu...@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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <br...@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
>>> <lu...@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
Re: struts 2.2 and guice
Posted by Paul Benedict <pb...@apache.org>.
Then what was the point of getting the IP for XWork?
On Tue, Dec 8, 2009 at 5:30 PM, Brian Pontarelli <br...@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
>> <lu...@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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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
> <lu...@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
Re: struts 2.2 and guice
Posted by Paul Benedict <pb...@apache.org>.
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
<lu...@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
Re: struts 2.2 and guice
Posted by Lukasz Lenart <lu...@googlemail.com>.
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/
Re: struts 2.2 and guice
Posted by Frans Thamura <fr...@meruvian.org>.
will this mean that struts 2.2 will support MVP
or any idea to put GWT also :)
F
Re: struts 2.2 and guice
Posted by Wes Wannemacher <we...@wantii.com>.
Don,
I would argue the opposite... I understand that you are going to have
trouble in a resource-constrained environment, and as Musachy mentions
later in the thread, there are things we could dump to regain space...
But! Most of our users aren't resource-constrained... At least, if
they are, they aren't complaining about it. If we moved infrequently
used interceptors, results and all their supporting classes into
plugins (which would be pretty easy, mostly due to your hard work),
then that would just make it more difficult for the vast majority of
users.
If you want to start a struts2-lite project, I'd be happy to jump in
and help out, but I think that resource-constrained environments are
the exception, not a rule to live by.
-Wes
On Mon, Dec 7, 2009 at 6:33 PM, Don Brown <mr...@twdata.org> wrote:
> Well, two things: sharing an IoC container with the app is almost
> always a bad idea in the long run, and two, maybe it is just me in a
> resource-constrained environment, but 651kb is definitely a big deal,
> especially if it brings in other dependencies like google collections.
> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
> use in our embedded OSGi container. I was hoping to get it back down
> under 2 megs, but with Guice 2, that would be quite unlikely. What
> features exactly do we need or how many bugs have cropped up in our DI
> container that we would be avoiding?
>
> Don
>
> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
>> We could have just one container (no double object factory), and
>> probably the same one could be used for s2 and the app (still to be
>> seen if feasible or not), get any new features that get added or are
>> in jsr 330, and we don't have maintain our own implementation when
>> there is a lib that already does it, like we usually do. Also, guice 2
>> main jar is 651 kbs, so I don't see much of a problem there.
>>
>> musachy
>>
>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>> instead of our own. Is there some feature we need that Guice 2 has?
>>> If not, we are basically sucking in a pretty significantly sized
>>> library for no apparent reason. I tried to use Struts 2 on a project
>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>> went a bit crazy with the shading. I'd generally advise against
>>> adding more bulk without obvious gains.
>>>
>>> Don
>>>
>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Andreas Joseph Krogh <an...@officenet.no>.
On Thursday 10. December 2009 20.27.32 Gabriel Belingueres wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browser window, and then
> allow better support for the back button. Even with conversation
> support the pages still need to pass along at least one request
> parameter: the conversation id, so in general terms you end up writing
> the same thing only that instead of passing actual data as request
> parameters you pass only a key to some other abstraction.
>
> Some conversation implementations are not compelling at all. See the
> struts2scopeplugin for example, it stores only one conversation per
> user session which is of course useless for multi-window apps.
>
> I've been researching the conversation features in JBoss Seam and
> Spring Web Flow, which I think are the 2 more important frameworks
> supporting it. The most sophisticated one is SFW which pretty much
> abstract the whole page and actions interactions (the flow) into one
> file, that is an XML file describing a FSM of the states the app is in
> a given time. For that thing to work, the request parameter that the
> app pass along in the pages is a composite between the conversation id
> and the "continuation id" (a fancy name for naming the current state
> in the flow FSM the app is in.)
>
> Also the conversation scope is the basis for other features like
> supporting the handy session-per-conversation pattern in ORMs.
>
> What I finally mean is that I seriously consider conversation scope
> support something important (at least for the kind of apps I work in.)
All the wizards I've made the last years are AJAX-based and each "step" in the wizard knows its index (position) and the next/prev step so it can render nice next/previous buttons and handle "reload page" nicely. My response to "What if the user hits the back-button or ctrl+clicks a link" is "Doctor it hurts when I do this (bangs fist against head)", which means; Dont do that.
So the bottom line is - yes I agree that the functionality of conversation-scope is important, but it's not necessarily that hard to implement. I especially do not like having to configure a lot of XML for my wizards to work (like SWF).
--
Andreas Joseph Krogh <an...@officenet.no>
Senior Software Developer / CTO
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Trollåsen | somebody else doing it wrong, without |
NORWAY | comment. |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Andreas Joseph Krogh <an...@officenet.no>.
On Thursday 10. December 2009 17.37.04 Alex Siman wrote:
>
> What if application needs expirable and parallel (say 5 instances at a time)
> wizard?
The point is that you have to save the state using the session (or DB or other persistent storage, but I assume that's more trouble than it's worth) some way or another. Then you can generate a unique key to scope the requested wizards in a map in the session-scoped-model for the specific action and make a mechanism so that this key (unique for each instance of the wizard) is passed for every request. Having instances of a wizard expire requires more work, but should not be magic either. You can f.ex. schedule a Quartz-job using Spring to run every x minute and reap expired wizard-instances which then must register themselves, a static in-memory map should be sufficient, when created.
--
Andreas Joseph Krogh <an...@officenet.no>
Senior Software Developer / CTO
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Trollåsen | somebody else doing it wrong, without |
NORWAY | comment. |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by chengas123 <be...@gmail.com>.
I thought I'd add my 2 cents. I'm trying to port a plugin to Struts and have
been totally stumped on how to get an instance of the object I need because
Struts uses a proprietary framework. If we were using Guice, I'd have no
problem because of the plethora of docs and other users. So I'd strongly
vote in favor of using Guice rather than the current implementation. Also,
some of that code is like magic, so I wouldn't ever want to have to make a
change to it. Guice on the otherhand is well-supported, so if there's a bug
I have more confidence in it getting resolved quickly. To me whether we
should support the JSR is a non-issue. Guice almost certainly will end up
supporting any standard. Maybe we will have to upgrade Guice versions to
add that support in the future, but the upgrade path will be much easier and
clearer if we are already using Guice. I don't understand the size
argument. Even my cell phone has 4 GB of disk space.
andreak wrote:
>
> On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote:
>> guys, can you start a different thread for this? :)
>
> You have a point there, talk about hijacking a thread:-)
>
> --
> Andreas Joseph Krogh <an...@officenet.no>
> Senior Software Developer / CTO
> ------------------------+---------------------------------------------+
> OfficeNet AS | The most difficult thing in the world is to |
> Rosenholmveien 25 | know how to do a thing and to watch |
> 1414 Trollåsen | somebody else doing it wrong, without |
> NORWAY | comment. |
> | |
> Tlf: +47 24 15 38 90 | |
> Fax: +47 24 15 38 91 | |
> Mobile: +47 909 56 963 | |
> ------------------------+---------------------------------------------+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/struts-2.2-and-guice-tp26594350p26803368.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Andreas Joseph Krogh <an...@officenet.no>.
On Thursday 10. December 2009 20.28.48 Musachy Barroso wrote:
> guys, can you start a different thread for this? :)
You have a point there, talk about hijacking a thread:-)
--
Andreas Joseph Krogh <an...@officenet.no>
Senior Software Developer / CTO
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Trollåsen | somebody else doing it wrong, without |
NORWAY | comment. |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Dale Newfield <da...@newfield.org>.
Chris Pratt wrote:
> That seems like a very imperfect fix for an almost impossible problem.
> Having an extra parameter on the link won't stop a user from right clicking
> on the link and saying "open in another window" and having 2 "conversations"
> with the same conversation key.
If the link followed in such a way is from one page of the wizard to
another, you're right. If the link followed in such a way is to the
"start wizard" page, presumably that (or even in the submission of the
first form of a wizard) is where a new conversation is created, so the
two windows could be part of two parallel wizards.
-Dale
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Chris Pratt <th...@gmail.com>.
That seems like a very imperfect fix for an almost impossible problem.
Having an extra parameter on the link won't stop a user from right clicking
on the link and saying "open in another window" and having 2 "conversations"
with the same conversation key. To my knowledge there's just no way to
accomplish it cleanly and completely, so you might as well embrace the way
the web works and go with it rather than trying to swim upstream. But
that's just one man's opinion.
(*Chris*)
On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres <belingueres@gmail.com
> wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browser window, and then
> allow better support for the back button. Even with conversation
> support the pages still need to pass along at least one request
> parameter: the conversation id, so in general terms you end up writing
> the same thing only that instead of passing actual data as request
> parameters you pass only a key to some other abstraction.
>
> Some conversation implementations are not compelling at all. See the
> struts2scopeplugin for example, it stores only one conversation per
> user session which is of course useless for multi-window apps.
>
> I've been researching the conversation features in JBoss Seam and
> Spring Web Flow, which I think are the 2 more important frameworks
> supporting it. The most sophisticated one is SFW which pretty much
> abstract the whole page and actions interactions (the flow) into one
> file, that is an XML file describing a FSM of the states the app is in
> a given time. For that thing to work, the request parameter that the
> app pass along in the pages is a composite between the conversation id
> and the "continuation id" (a fancy name for naming the current state
> in the flow FSM the app is in.)
>
> Also the conversation scope is the basis for other features like
> supporting the handy session-per-conversation pattern in ORMs.
>
> What I finally mean is that I seriously consider conversation scope
> support something important (at least for the kind of apps I work in.)
>
> Regards
> Gabriel
>
> 2009/12/10 Andreas Joseph Krogh <an...@officenet.no>:
> > On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
> >>
> >> Wes Wannemacher wrote:
> >> >
> >> > "Everything is tied to either the request
> >> > or the session, I can't build wizard-style views"
> >> >
> >> Yeah, we need wizards sometimes.
> >
> > I would argue that it would be nice to have, but not a must. Most
> implementations I've seen of "conversation"-scope are rather messy and don't
> provide anything beyond what you can achieve with
> ScopedModelDriver(scope=session) and some custom-code. I've built several,
> robust, wizard-like UIs using Struts2 without any problems.
> >
> > --
> > Andreas Joseph Krogh <an...@officenet.no>
> > Senior Software Developer / CTO
> > ------------------------+---------------------------------------------+
> > OfficeNet AS | The most difficult thing in the world is to |
> > Rosenholmveien 25 | know how to do a thing and to watch |
> > 1414 Trollåsen | somebody else doing it wrong, without |
> > NORWAY | comment. |
> > | |
> > Tlf: +47 24 15 38 90 | |
> > Fax: +47 24 15 38 91 | |
> > Mobile: +47 909 56 963 | |
> > ------------------------+---------------------------------------------+
> >
> > ---------------------------------------------------------------------
> > 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
>
>
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
guys, can you start a different thread for this? :)
On Thu, Dec 10, 2009 at 11:27 AM, Gabriel Belingueres
<be...@gmail.com> wrote:
> Granted, most people implement wizards this way, but the most
> compelling use of storing state in conversation scope (IMO) is to
> allow correct behavior when a user clones a browser window, and then
> allow better support for the back button. Even with conversation
> support the pages still need to pass along at least one request
> parameter: the conversation id, so in general terms you end up writing
> the same thing only that instead of passing actual data as request
> parameters you pass only a key to some other abstraction.
>
> Some conversation implementations are not compelling at all. See the
> struts2scopeplugin for example, it stores only one conversation per
> user session which is of course useless for multi-window apps.
>
> I've been researching the conversation features in JBoss Seam and
> Spring Web Flow, which I think are the 2 more important frameworks
> supporting it. The most sophisticated one is SFW which pretty much
> abstract the whole page and actions interactions (the flow) into one
> file, that is an XML file describing a FSM of the states the app is in
> a given time. For that thing to work, the request parameter that the
> app pass along in the pages is a composite between the conversation id
> and the "continuation id" (a fancy name for naming the current state
> in the flow FSM the app is in.)
>
> Also the conversation scope is the basis for other features like
> supporting the handy session-per-conversation pattern in ORMs.
>
> What I finally mean is that I seriously consider conversation scope
> support something important (at least for the kind of apps I work in.)
>
> Regards
> Gabriel
>
> 2009/12/10 Andreas Joseph Krogh <an...@officenet.no>:
>> On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>>>
>>> Wes Wannemacher wrote:
>>> >
>>> > "Everything is tied to either the request
>>> > or the session, I can't build wizard-style views"
>>> >
>>> Yeah, we need wizards sometimes.
>>
>> I would argue that it would be nice to have, but not a must. Most implementations I've seen of "conversation"-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems.
>>
>> --
>> Andreas Joseph Krogh <an...@officenet.no>
>> Senior Software Developer / CTO
>> ------------------------+---------------------------------------------+
>> OfficeNet AS | The most difficult thing in the world is to |
>> Rosenholmveien 25 | know how to do a thing and to watch |
>> 1414 Trollåsen | somebody else doing it wrong, without |
>> NORWAY | comment. |
>> | |
>> Tlf: +47 24 15 38 90 | |
>> Fax: +47 24 15 38 91 | |
>> Mobile: +47 909 56 963 | |
>> ------------------------+---------------------------------------------+
>>
>> ---------------------------------------------------------------------
>> 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
Re: struts 2.2 and guice
Posted by Gabriel Belingueres <be...@gmail.com>.
Granted, most people implement wizards this way, but the most
compelling use of storing state in conversation scope (IMO) is to
allow correct behavior when a user clones a browser window, and then
allow better support for the back button. Even with conversation
support the pages still need to pass along at least one request
parameter: the conversation id, so in general terms you end up writing
the same thing only that instead of passing actual data as request
parameters you pass only a key to some other abstraction.
Some conversation implementations are not compelling at all. See the
struts2scopeplugin for example, it stores only one conversation per
user session which is of course useless for multi-window apps.
I've been researching the conversation features in JBoss Seam and
Spring Web Flow, which I think are the 2 more important frameworks
supporting it. The most sophisticated one is SFW which pretty much
abstract the whole page and actions interactions (the flow) into one
file, that is an XML file describing a FSM of the states the app is in
a given time. For that thing to work, the request parameter that the
app pass along in the pages is a composite between the conversation id
and the "continuation id" (a fancy name for naming the current state
in the flow FSM the app is in.)
Also the conversation scope is the basis for other features like
supporting the handy session-per-conversation pattern in ORMs.
What I finally mean is that I seriously consider conversation scope
support something important (at least for the kind of apps I work in.)
Regards
Gabriel
2009/12/10 Andreas Joseph Krogh <an...@officenet.no>:
> On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>>
>> Wes Wannemacher wrote:
>> >
>> > "Everything is tied to either the request
>> > or the session, I can't build wizard-style views"
>> >
>> Yeah, we need wizards sometimes.
>
> I would argue that it would be nice to have, but not a must. Most implementations I've seen of "conversation"-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems.
>
> --
> Andreas Joseph Krogh <an...@officenet.no>
> Senior Software Developer / CTO
> ------------------------+---------------------------------------------+
> OfficeNet AS | The most difficult thing in the world is to |
> Rosenholmveien 25 | know how to do a thing and to watch |
> 1414 Trollåsen | somebody else doing it wrong, without |
> NORWAY | comment. |
> | |
> Tlf: +47 24 15 38 90 | |
> Fax: +47 24 15 38 91 | |
> Mobile: +47 909 56 963 | |
> ------------------------+---------------------------------------------+
>
> ---------------------------------------------------------------------
> 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
Re: struts 2.2 and guice
Posted by Alex Siman <al...@gmail.com>.
What if application needs expirable and parallel (say 5 instances at a time)
wizard?
andreak wrote:
>
> On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>>
>> Wes Wannemacher wrote:
>> >
>> > "Everything is tied to either the request
>> > or the session, I can't build wizard-style views"
>> >
>> Yeah, we need wizards sometimes.
>
> I would argue that it would be nice to have, but not a must. Most
> implementations I've seen of "conversation"-scope are rather messy and
> don't provide anything beyond what you can achieve with
> ScopedModelDriver(scope=session) and some custom-code. I've built several,
> robust, wizard-like UIs using Struts2 without any problems.
>
> --
> Andreas Joseph Krogh <an...@officenet.no>
> Senior Software Developer / CTO
> ------------------------+---------------------------------------------+
> OfficeNet AS | The most difficult thing in the world is to |
> Rosenholmveien 25 | know how to do a thing and to watch |
> 1414 Trollåsen | somebody else doing it wrong, without |
> NORWAY | comment. |
> | |
> Tlf: +47 24 15 38 90 | |
> Fax: +47 24 15 38 91 | |
> Mobile: +47 909 56 963 | |
> ------------------------+---------------------------------------------+
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
>
--
View this message in context: http://old.nabble.com/struts-2.2-and-guice-tp26594350p26730390.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Andreas Joseph Krogh <an...@officenet.no>.
On Thursday 10. December 2009 15.31.15 Alex Siman wrote:
>
> Wes Wannemacher wrote:
> >
> > "Everything is tied to either the request
> > or the session, I can't build wizard-style views"
> >
> Yeah, we need wizards sometimes.
I would argue that it would be nice to have, but not a must. Most implementations I've seen of "conversation"-scope are rather messy and don't provide anything beyond what you can achieve with ScopedModelDriver(scope=session) and some custom-code. I've built several, robust, wizard-like UIs using Struts2 without any problems.
--
Andreas Joseph Krogh <an...@officenet.no>
Senior Software Developer / CTO
------------------------+---------------------------------------------+
OfficeNet AS | The most difficult thing in the world is to |
Rosenholmveien 25 | know how to do a thing and to watch |
1414 Trollåsen | somebody else doing it wrong, without |
NORWAY | comment. |
| |
Tlf: +47 24 15 38 90 | |
Fax: +47 24 15 38 91 | |
Mobile: +47 909 56 963 | |
------------------------+---------------------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
On Dec 9, 2009, at 2:47 PM, Wes Wannemacher wrote:
> Don,
>
> I started another thread to talk about the API issue, but for this I
> want to give you my take. The "Managed Beans" JSR I started reading
> the other day does offer a few useful features that we don't have. One
> is the "conversation" scope, which I think Struts 2 could really
> benefit from. That's usually the first thing I have to hear from
> WebWork / Struts 2 users - "Everything is tied to either the request
> or the session, I can't build wizard-style views"
I've always wondered about these things. I tend to use the request and page storage just because it seems simple and provides we with back button protections cheaply. I've wondered how complex they are to implement server side and the benefits of doing it on the server. The obvious one is security. Are there any others?
>
> Another benefit is that our current DI is limiting... In every case
> that I've used the Container directly, it was because I wanted to pick
> one instance out of a few possible implementation candidates. It's
> sort of silly that you have to grab the Container to say - "give me
> the implementation of interface X called 'foo'"
Guice and the JSR have a number of things to help with this now.
-bp
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Alex Siman <al...@gmail.com>.
Wes Wannemacher wrote:
>
> "Everything is tied to either the request
> or the session, I can't build wizard-style views"
>
Yeah, we need wizards sometimes.
--
View this message in context: http://old.nabble.com/struts-2.2-and-guice-tp26594350p26728156.html
Sent from the Struts - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Wes Wannemacher <we...@wantii.com>.
Don,
I started another thread to talk about the API issue, but for this I
want to give you my take. The "Managed Beans" JSR I started reading
the other day does offer a few useful features that we don't have. One
is the "conversation" scope, which I think Struts 2 could really
benefit from. That's usually the first thing I have to hear from
WebWork / Struts 2 users - "Everything is tied to either the request
or the session, I can't build wizard-style views"
Another benefit is that our current DI is limiting... In every case
that I've used the Container directly, it was because I wanted to pick
one instance out of a few possible implementation candidates. It's
sort of silly that you have to grab the Container to say - "give me
the implementation of interface X called 'foo'"
-Wes
On Mon, Dec 7, 2009 at 5:55 PM, Don Brown <mr...@twdata.org> wrote:
> Late to the party, but I'm not clear why you would want to use Guice 2
> instead of our own. Is there some feature we need that Guice 2 has?
> If not, we are basically sucking in a pretty significantly sized
> library for no apparent reason. I tried to use Struts 2 on a project
> here, and was a bit shocked at the size of the jar nowadays...seems we
> went a bit crazy with the shading. I'd generally advise against
> adding more bulk without obvious gains.
>
> Don
>
--
Wes Wannemacher
Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Paul Benedict <pb...@apache.org>.
Don,
> JSR 330 is not the magic bullet here.
Agreed, but I would have to say it would be foolish not to support it.
As companies perform internal tech evaluations, people will eventually
realize "standard" DI injection is not supported: "Oh, our company has
to learn XWork DI? What the heck is XWork?" Well, that could be seen
as a negative and affect adoption. A FUTURE scenario, but one likely
to occur one day.
I don't care what DI container runs JSR-330, but it should be the job
of Struts 2 to allow *swappable* implementations through a Bridge
adapter. Will our users have the choice of Apache's Open Web Beans
[1]? I hope so.
Likewise, Commons Validator 2.0 will be a JSR-303 Bean Validation
implementation. Same lesson to be learned here.
[1] http://incubator.apache.org/openwebbeans/
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
Without too long of a reply, here are a few thoughts:
- Solid, unchanging public APIs are possible
- Refactoring and using the latest technologies is the only way to survive
- This would not break separation or dictate it for that matter
- It would force necessary clean up
The benefit is that as Java 7 and JEE6 roll out and JSR 330 possibly gains momentum (which I believe is guaranteed), people will look to the frameworks to support them. Here's a few others that Struts should be using:
303 - Bean validation
315/316 - Async support
I'm sure there are others as well.
-bp
On Dec 8, 2009, at 9:13 PM, Don Brown wrote:
> Ok, here is how it works at Atlassian and most every software project
> I've been involved in - changing core dependencies is hard. It is
> especially hard if you needed to fork said dependencies, which we've
> had to do quite often at Atlassian. If a green-field Struts 2
> application decided, hey, let's just use Guice 2 just like Struts,
> then what happens down the line when Struts 2 goes to Guice 2.1, which
> is incompatible? What if that app needed to customize Guice 2.0 or
> build specific functionality deep into the library? Now, if they
> wanted to upgrade Struts 2? They'd be stuck until they could upgrade
> their version of Guice 2?
>
> This is not a hypothetical situation. At Atlassian, we have apps like
> JIRA that are 7 or 8 years old. JIRA, for example, uses a forked
> version of PicoContainer 1.0 they had to customize for various
> reasons. Why would they spend a month or two upgrading PicoContainer
> without gain when they could be building kick-ass features? For this
> reason, Confluence is running Spring 2.0, Hibernate 2, and WebWork
> 2.1.7-atlassian-2. It isn't that these products can never change
> dependencies, just the cost is really high for little to no gain, and
> if one major upgrade requires another, it is all the more reason not
> to do the upgrade at all.
>
> JSR 330 is not the magic bullet here. Yes, services would then not be
> tied to a specific DI container, but all the configuration and direct
> DI container usage sure would be, and in Struts 2, we have heaps.
> Furthermore, this gives breaks the abstraction between the framework
> and the host app. We already have enough problems in Struts 2 because
> we lack an proper API. Externalizing our DI only exasperates this
> problem. We might as well encourage devs to copy/paste Struts 2 into
> their project because upgrading sure will be a pain.
>
> Again, there are significant costs to this proposal, and I have yet to
> hear a substantial, real-world benefit. Earlier, we went so far as to
> define our own logging API because we wanted to keep that boundary
> between the app and the framework. Sometimes, strict boundaries are a
> very good thing.
>
> Don
>
> On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
>> Why do you say that and do you have specific examples? JCatapult uses a single container and it is actually effective and very helpful. This allows you to easily get access to the public API of JCatapult and also to override anything you want. It also makes things faster and lighter weight. There are many applications and developers using it without major issues.
>>
>> I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will.
>>
>> I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the "owner". The webapp would declare its primary DI provider and then Struts would just wire up using that.
>>
>> The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this.
>>
>> -bp
>>
>>
>> On Dec 7, 2009, at 4:33 PM, Don Brown wrote:
>>
>>> Well, two things: sharing an IoC container with the app is almost
>>> always a bad idea in the long run, and two, maybe it is just me in a
>>> resource-constrained environment, but 651kb is definitely a big deal,
>>> especially if it brings in other dependencies like google collections.
>>> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
>>> use in our embedded OSGi container. I was hoping to get it back down
>>> under 2 megs, but with Guice 2, that would be quite unlikely. What
>>> features exactly do we need or how many bugs have cropped up in our DI
>>> container that we would be avoiding?
>>>
>>> Don
>>>
>>> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>> We could have just one container (no double object factory), and
>>>> probably the same one could be used for s2 and the app (still to be
>>>> seen if feasible or not), get any new features that get added or are
>>>> in jsr 330, and we don't have maintain our own implementation when
>>>> there is a lib that already does it, like we usually do. Also, guice 2
>>>> main jar is 651 kbs, so I don't see much of a problem there.
>>>>
>>>> musachy
>>>>
>>>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>>>> instead of our own. Is there some feature we need that Guice 2 has?
>>>>> If not, we are basically sucking in a pretty significantly sized
>>>>> library for no apparent reason. I tried to use Struts 2 on a project
>>>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>>>> went a bit crazy with the shading. I'd generally advise against
>>>>> adding more bulk without obvious gains.
>>>>>
>>>>> Don
>>>>>
>>>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> 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
Re: struts 2.2 and guice
Posted by Don Brown <mr...@twdata.org>.
Ok, here is how it works at Atlassian and most every software project
I've been involved in - changing core dependencies is hard. It is
especially hard if you needed to fork said dependencies, which we've
had to do quite often at Atlassian. If a green-field Struts 2
application decided, hey, let's just use Guice 2 just like Struts,
then what happens down the line when Struts 2 goes to Guice 2.1, which
is incompatible? What if that app needed to customize Guice 2.0 or
build specific functionality deep into the library? Now, if they
wanted to upgrade Struts 2? They'd be stuck until they could upgrade
their version of Guice 2?
This is not a hypothetical situation. At Atlassian, we have apps like
JIRA that are 7 or 8 years old. JIRA, for example, uses a forked
version of PicoContainer 1.0 they had to customize for various
reasons. Why would they spend a month or two upgrading PicoContainer
without gain when they could be building kick-ass features? For this
reason, Confluence is running Spring 2.0, Hibernate 2, and WebWork
2.1.7-atlassian-2. It isn't that these products can never change
dependencies, just the cost is really high for little to no gain, and
if one major upgrade requires another, it is all the more reason not
to do the upgrade at all.
JSR 330 is not the magic bullet here. Yes, services would then not be
tied to a specific DI container, but all the configuration and direct
DI container usage sure would be, and in Struts 2, we have heaps.
Furthermore, this gives breaks the abstraction between the framework
and the host app. We already have enough problems in Struts 2 because
we lack an proper API. Externalizing our DI only exasperates this
problem. We might as well encourage devs to copy/paste Struts 2 into
their project because upgrading sure will be a pain.
Again, there are significant costs to this proposal, and I have yet to
hear a substantial, real-world benefit. Earlier, we went so far as to
define our own logging API because we wanted to keep that boundary
between the app and the framework. Sometimes, strict boundaries are a
very good thing.
Don
On Wed, Dec 9, 2009 at 4:38 AM, Brian Pontarelli <br...@pontarelli.com> wrote:
> Why do you say that and do you have specific examples? JCatapult uses a single container and it is actually effective and very helpful. This allows you to easily get access to the public API of JCatapult and also to override anything you want. It also makes things faster and lighter weight. There are many applications and developers using it without major issues.
>
> I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will.
>
> I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the "owner". The webapp would declare its primary DI provider and then Struts would just wire up using that.
>
> The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this.
>
> -bp
>
>
> On Dec 7, 2009, at 4:33 PM, Don Brown wrote:
>
>> Well, two things: sharing an IoC container with the app is almost
>> always a bad idea in the long run, and two, maybe it is just me in a
>> resource-constrained environment, but 651kb is definitely a big deal,
>> especially if it brings in other dependencies like google collections.
>> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
>> use in our embedded OSGi container. I was hoping to get it back down
>> under 2 megs, but with Guice 2, that would be quite unlikely. What
>> features exactly do we need or how many bugs have cropped up in our DI
>> container that we would be avoiding?
>>
>> Don
>>
>> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>> We could have just one container (no double object factory), and
>>> probably the same one could be used for s2 and the app (still to be
>>> seen if feasible or not), get any new features that get added or are
>>> in jsr 330, and we don't have maintain our own implementation when
>>> there is a lib that already does it, like we usually do. Also, guice 2
>>> main jar is 651 kbs, so I don't see much of a problem there.
>>>
>>> musachy
>>>
>>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>>> instead of our own. Is there some feature we need that Guice 2 has?
>>>> If not, we are basically sucking in a pretty significantly sized
>>>> library for no apparent reason. I tried to use Struts 2 on a project
>>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>>> went a bit crazy with the shading. I'd generally advise against
>>>> adding more bulk without obvious gains.
>>>>
>>>> Don
>>>>
>>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
Why do you say that and do you have specific examples? JCatapult uses a single container and it is actually effective and very helpful. This allows you to easily get access to the public API of JCatapult and also to override anything you want. It also makes things faster and lighter weight. There are many applications and developers using it without major issues.
I wonder how many users are actually swapping out the ObjectFactory at this point and wouldn't be fine with either Guice or Spring? There is also nothing stopping other DI containers from implementing JSR 330 and I would expect most will.
I think the way to approach this is to have struts get out of the business of DI completely. If everything in Struts uses the JSR annotations and APIs, then Struts is really just a component of the web app and not really the "owner". The webapp would declare its primary DI provider and then Struts would just wire up using that.
The JSR also supports tiered injectors, which could be used to isolate Struts. If Struts defines generic modules, the webapp can easily place all those modules in a child injector if it wants. Or if could place it the main injector if it wants access to everything. Struts shouldn't be dictating its place in the webapp, the webapp should be dictating Struts place. Moving to JSR 330 should fix a lot of this.
-bp
On Dec 7, 2009, at 4:33 PM, Don Brown wrote:
> Well, two things: sharing an IoC container with the app is almost
> always a bad idea in the long run, and two, maybe it is just me in a
> resource-constrained environment, but 651kb is definitely a big deal,
> especially if it brings in other dependencies like google collections.
> The fact that Struts 2 is almost 5 megs means it is a no-go for me to
> use in our embedded OSGi container. I was hoping to get it back down
> under 2 megs, but with Guice 2, that would be quite unlikely. What
> features exactly do we need or how many bugs have cropped up in our DI
> container that we would be avoiding?
>
> Don
>
> On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
>> We could have just one container (no double object factory), and
>> probably the same one could be used for s2 and the app (still to be
>> seen if feasible or not), get any new features that get added or are
>> in jsr 330, and we don't have maintain our own implementation when
>> there is a lib that already does it, like we usually do. Also, guice 2
>> main jar is 651 kbs, so I don't see much of a problem there.
>>
>> musachy
>>
>> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>>> Late to the party, but I'm not clear why you would want to use Guice 2
>>> instead of our own. Is there some feature we need that Guice 2 has?
>>> If not, we are basically sucking in a pretty significantly sized
>>> library for no apparent reason. I tried to use Struts 2 on a project
>>> here, and was a bit shocked at the size of the jar nowadays...seems we
>>> went a bit crazy with the shading. I'd generally advise against
>>> adding more bulk without obvious gains.
>>>
>>> Don
>>>
>>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
Re: struts 2.2 and guice
Posted by Don Brown <mr...@twdata.org>.
Well, two things: sharing an IoC container with the app is almost
always a bad idea in the long run, and two, maybe it is just me in a
resource-constrained environment, but 651kb is definitely a big deal,
especially if it brings in other dependencies like google collections.
The fact that Struts 2 is almost 5 megs means it is a no-go for me to
use in our embedded OSGi container. I was hoping to get it back down
under 2 megs, but with Guice 2, that would be quite unlikely. What
features exactly do we need or how many bugs have cropped up in our DI
container that we would be avoiding?
Don
On Tue, Dec 8, 2009 at 10:11 AM, Musachy Barroso <mu...@gmail.com> wrote:
> We could have just one container (no double object factory), and
> probably the same one could be used for s2 and the app (still to be
> seen if feasible or not), get any new features that get added or are
> in jsr 330, and we don't have maintain our own implementation when
> there is a lib that already does it, like we usually do. Also, guice 2
> main jar is 651 kbs, so I don't see much of a problem there.
>
> musachy
>
> On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
>> Late to the party, but I'm not clear why you would want to use Guice 2
>> instead of our own. Is there some feature we need that Guice 2 has?
>> If not, we are basically sucking in a pretty significantly sized
>> library for no apparent reason. I tried to use Struts 2 on a project
>> here, and was a bit shocked at the size of the jar nowadays...seems we
>> went a bit crazy with the shading. I'd generally advise against
>> adding more bulk without obvious gains.
>>
>> Don
>>
>> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
We could have just one container (no double object factory), and
probably the same one could be used for s2 and the app (still to be
seen if feasible or not), get any new features that get added or are
in jsr 330, and we don't have maintain our own implementation when
there is a lib that already does it, like we usually do. Also, guice 2
main jar is 651 kbs, so I don't see much of a problem there.
musachy
On Mon, Dec 7, 2009 at 2:55 PM, Don Brown <mr...@twdata.org> wrote:
> Late to the party, but I'm not clear why you would want to use Guice 2
> instead of our own. Is there some feature we need that Guice 2 has?
> If not, we are basically sucking in a pretty significantly sized
> library for no apparent reason. I tried to use Struts 2 on a project
> here, and was a bit shocked at the size of the jar nowadays...seems we
> went a bit crazy with the shading. I'd generally advise against
> adding more bulk without obvious gains.
>
> Don
>
> On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
>> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>>
>>
>
> ---------------------------------------------------------------------
> 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
Re: struts 2.2 and guice
Posted by Don Brown <mr...@twdata.org>.
Late to the party, but I'm not clear why you would want to use Guice 2
instead of our own. Is there some feature we need that Guice 2 has?
If not, we are basically sucking in a pretty significantly sized
library for no apparent reason. I tried to use Struts 2 on a project
here, and was a bit shocked at the size of the jar nowadays...seems we
went a bit crazy with the shading. I'd generally advise against
adding more bulk without obvious gains.
Don
On Tue, Dec 8, 2009 at 7:09 AM, Musachy Barroso <mu...@gmail.com> wrote:
> 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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
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 <gi...@it-neering.net> 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 <mu...@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 <th...@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-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
Re: struts 2.2 and guice
Posted by Rene Gielen <gi...@it-neering.net>.
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 <mu...@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 <th...@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-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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
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 <mu...@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 <th...@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-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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
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 <th...@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-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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <th...@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-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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
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 <th...@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-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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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 <th...@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-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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
I have mixed feelings about it. making it pluggeable is not a priority
I would say. But if there are standard annotations for it now, then
there is no reason why we shouldn't use them. If the day comes when
guice is no longer supported (I don't really mean it crazybob :)), it
would be easier to find alternatives.
On Tue, Dec 1, 2009 at 10:34 AM, Martin Cooper <ma...@apache.org> wrote:
> On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso <mu...@gmail.com> 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.
>
> If it's "internal use only", so to speak, then why do we care about
> whether it's JSR annotations versus Guice annotations, and why would
> we want to make it pluggable? Those are things that app authors might
> care about, but not something we need to complicate the internal
> implementation with.
>
> --
> Martin Cooper
>
>
>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <th...@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-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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
Because you don't want to use separate containers. In Guice you can have child-parent injector relationships. My thought is to just have a single DI container that builds everything. Struts no longer has any concept of an ObjectFactory and doesn't create actions or anything like that. It would just invoke actions created by the DI container.
Plus, if folks are asking for access to internals, this makes it simpler. You could also take the JCatapult approach and just have a single injector for everything. I personally like that approach the best, but Struts has had issues with public API breakage in the past and that would no longer be allowed if you have a single Injector. That is unless you roll a major version and follow a strict runtime compatibility methodology for a single major version's lineage.
-bp
On Dec 1, 2009, at 11:34 AM, Martin Cooper wrote:
> On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso <mu...@gmail.com> 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.
>
> If it's "internal use only", so to speak, then why do we care about
> whether it's JSR annotations versus Guice annotations, and why would
> we want to make it pluggable? Those are things that app authors might
> care about, but not something we need to complicate the internal
> implementation with.
>
> --
> Martin Cooper
>
>
>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <th...@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-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
Re: struts 2.2 and guice
Posted by Martin Cooper <ma...@apache.org>.
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso <mu...@gmail.com> 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.
If it's "internal use only", so to speak, then why do we care about
whether it's JSR annotations versus Guice annotations, and why would
we want to make it pluggable? Those are things that app authors might
care about, but not something we need to complicate the internal
implementation with.
--
Martin Cooper
> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <th...@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-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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
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 <th...@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-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
Re: struts 2.2 and guice
Posted by Chris Pratt <th...@gmail.com>.
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-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
>
>
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
I don't see a clear distinction between the Struts injector and the
App injector. One thing to keep in mind is that user often request how
to access struts internal stuff, like action mapping etc, which in
theory should not happen, but it does.
musachy
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-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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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-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
Re: struts 2.2 and guice
Posted by Musachy Barroso <mu...@gmail.com>.
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-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
Re: struts 2.2 and guice
Posted by Brian Pontarelli <br...@pontarelli.com>.
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