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 <mrdon@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 <musachy@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 <mrdon@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 <musachy@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 <gielen@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 <musachy@gmail.com> wrote: >>>>>>> It is good that you brought this up, because the double object factory >>>>>>> is annoying and creates a lot of unexpected situations(problems with >>>>>>> class reloading and OSGi). Having just one container would make it >>>>>>> easier for everybody, users and s2 developers, if it can be pulled >>>>>>> off. >>>>>>> >>>>>>> This kind of change could be too big for a 2.x release I think >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>>>> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >>>>>>>> >>>>>>>> -bp >>>>>>>> >>>>>>>> >>>>>>>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >>>>>>>> >>>>>>>>> ah I see what you mean. yes that would be a good idea, I think that >>>>>>>>> would work as long as all the containers have what we need, which I am >>>>>>>>> not sure if it is in the spec or not (havent read it), like: >>>>>>>>> >>>>>>>>> * create/inject objects and statics (duh) >>>>>>>>> * lookup all implementation by type >>>>>>>>> >>>>>>>>> that's all I can think off the top of my head. >>>>>>>>> >>>>>>>>> musachy >>>>>>>>> >>>>>>>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>>>>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>>>>>>>> >>>>>>>>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>>>>>>>> >>>>>>>>>> -bp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>>>>>>>> >>>>>>>>>>> this is not related to the application itself, you can still use any >>>>>>>>>>> IoC you want. This is for the IoC that is used internally to wire >>>>>>>>>>> struts internals together, which at the moment is an old version of >>>>>>>>>>> guice which is in xwork. >>>>>>>>>>> >>>>>>>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>>>>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>>>>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>>>>>>>> but I still want to try to stay as current as possible on Struts. >>>>>>>>>>>> (*Chris*) >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>>>>>>>> >>>>>>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>>>>>>>> that. >>>>>>>>>>>>> >>>>>>>>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>>>>>>>> layout would be best: >>>>>>>>>>>>> >>>>>>>>>>>>> Base >>>>>>>>>>>>> | >>>>>>>>>>>>> | >>>>>>>>>>>>> _________ >>>>>>>>>>>>> | | >>>>>>>>>>>>> | | >>>>>>>>>>>>> Struts App >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>>>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>>>>>>>> injector will contain all of the private objects that should not be >>>>>>>>>>>>> accessible to the application. The App injector will contain all the >>>>>>>>>>>>> application objects like Actions and such. >>>>>>>>>>>>> >>>>>>>>>>>>> -bp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>>>>>>>> comes to Sun APIs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> musachy >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>>>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>>>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>>>>>>>> -bp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> what do you think? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> musachy >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: 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
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 <musachy@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 <mrdon@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 <musachy@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 <gielen@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 <musachy@gmail.com> wrote: >>>>>> It is good that you brought this up, because the double object factory >>>>>> is annoying and creates a lot of unexpected situations(problems with >>>>>> class reloading and OSGi). Having just one container would make it >>>>>> easier for everybody, users and s2 developers, if it can be pulled >>>>>> off. >>>>>> >>>>>> This kind of change could be too big for a 2.x release I think >>>>>> >>>>>> musachy >>>>>> >>>>>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>>> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >>>>>>> >>>>>>> -bp >>>>>>> >>>>>>> >>>>>>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >>>>>>> >>>>>>>> ah I see what you mean. yes that would be a good idea, I think that >>>>>>>> would work as long as all the containers have what we need, which I am >>>>>>>> not sure if it is in the spec or not (havent read it), like: >>>>>>>> >>>>>>>> * create/inject objects and statics (duh) >>>>>>>> * lookup all implementation by type >>>>>>>> >>>>>>>> that's all I can think off the top of my head. >>>>>>>> >>>>>>>> musachy >>>>>>>> >>>>>>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>>>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>>>>>>> >>>>>>>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>>>>>>> >>>>>>>>> -bp >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>>>>>>> >>>>>>>>>> this is not related to the application itself, you can still use any >>>>>>>>>> IoC you want. This is for the IoC that is used internally to wire >>>>>>>>>> struts internals together, which at the moment is an old version of >>>>>>>>>> guice which is in xwork. >>>>>>>>>> >>>>>>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>>>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>>>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>>>>>>> but I still want to try to stay as current as possible on Struts. >>>>>>>>>>> (*Chris*) >>>>>>>>>>> >>>>>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>>>>>>> >>>>>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>>>>>>> that. >>>>>>>>>>>> >>>>>>>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>>>>>>> layout would be best: >>>>>>>>>>>> >>>>>>>>>>>> Base >>>>>>>>>>>> | >>>>>>>>>>>> | >>>>>>>>>>>> _________ >>>>>>>>>>>> | | >>>>>>>>>>>> | | >>>>>>>>>>>> Struts App >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>>>>>>> injector will contain all of the private objects that should not be >>>>>>>>>>>> accessible to the application. The App injector will contain all the >>>>>>>>>>>> application objects like Actions and such. >>>>>>>>>>>> >>>>>>>>>>>> -bp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>>>>>>> >>>>>>>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>>>>>>> comes to Sun APIs. >>>>>>>>>>>>> >>>>>>>>>>>>> musachy >>>>>>>>>>>>> >>>>>>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>>>>>>> -bp >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> what do you think? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> musachy >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: 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
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 <mrdon@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 <musachy@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 <gielen@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 <musachy@gmail.com> wrote: >>>>> It is good that you brought this up, because the double object factory >>>>> is annoying and creates a lot of unexpected situations(problems with >>>>> class reloading and OSGi). Having just one container would make it >>>>> easier for everybody, users and s2 developers, if it can be pulled >>>>> off. >>>>> >>>>> This kind of change could be too big for a 2.x release I think >>>>> >>>>> musachy >>>>> >>>>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >>>>>> >>>>>>> ah I see what you mean. yes that would be a good idea, I think that >>>>>>> would work as long as all the containers have what we need, which I am >>>>>>> not sure if it is in the spec or not (havent read it), like: >>>>>>> >>>>>>> * create/inject objects and statics (duh) >>>>>>> * lookup all implementation by type >>>>>>> >>>>>>> that's all I can think off the top of my head. >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>>>>>> >>>>>>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>>>>>> >>>>>>>> -bp >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>>>>>> >>>>>>>>> this is not related to the application itself, you can still use any >>>>>>>>> IoC you want. This is for the IoC that is used internally to wire >>>>>>>>> struts internals together, which at the moment is an old version of >>>>>>>>> guice which is in xwork. >>>>>>>>> >>>>>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>>>>>> but I still want to try to stay as current as possible on Struts. >>>>>>>>>> (*Chris*) >>>>>>>>>> >>>>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>>>>>> >>>>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>>>>>> layout would be best: >>>>>>>>>>> >>>>>>>>>>> Base >>>>>>>>>>> | >>>>>>>>>>> | >>>>>>>>>>> _________ >>>>>>>>>>> | | >>>>>>>>>>> | | >>>>>>>>>>> Struts App >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>>>>>> injector will contain all of the private objects that should not be >>>>>>>>>>> accessible to the application. The App injector will contain all the >>>>>>>>>>> application objects like Actions and such. >>>>>>>>>>> >>>>>>>>>>> -bp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>>>>>> >>>>>>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>>>>>> comes to Sun APIs. >>>>>>>>>>>> >>>>>>>>>>>> musachy >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>>>>>> wrote: >>>>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>>>>>> -bp >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>>>>>> >>>>>>>>>>>>>> what do you think? >>>>>>>>>>>>>> >>>>>>>>>>>>>> musachy >>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: 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
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 <musachy@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 <gielen@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 <musachy@gmail.com> wrote: >>>> It is good that you brought this up, because the double object factory >>>> is annoying and creates a lot of unexpected situations(problems with >>>> class reloading and OSGi). Having just one container would make it >>>> easier for everybody, users and s2 developers, if it can be pulled >>>> off. >>>> >>>> This kind of change could be too big for a 2.x release I think >>>> >>>> musachy >>>> >>>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >>>>> >>>>> -bp >>>>> >>>>> >>>>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >>>>> >>>>>> ah I see what you mean. yes that would be a good idea, I think that >>>>>> would work as long as all the containers have what we need, which I am >>>>>> not sure if it is in the spec or not (havent read it), like: >>>>>> >>>>>> * create/inject objects and statics (duh) >>>>>> * lookup all implementation by type >>>>>> >>>>>> that's all I can think off the top of my head. >>>>>> >>>>>> musachy >>>>>> >>>>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>>>>> >>>>>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>>>>> >>>>>>> -bp >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>>>>> >>>>>>>> this is not related to the application itself, you can still use any >>>>>>>> IoC you want. This is for the IoC that is used internally to wire >>>>>>>> struts internals together, which at the moment is an old version of >>>>>>>> guice which is in xwork. >>>>>>>> >>>>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>>>>> but I still want to try to stay as current as possible on Struts. >>>>>>>>> (*Chris*) >>>>>>>>> >>>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>>>>> >>>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>>>>> layout would be best: >>>>>>>>>> >>>>>>>>>> Base >>>>>>>>>> | >>>>>>>>>> | >>>>>>>>>> _________ >>>>>>>>>> | | >>>>>>>>>> | | >>>>>>>>>> Struts App >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>>>>> injector will contain all of the private objects that should not be >>>>>>>>>> accessible to the application. The App injector will contain all the >>>>>>>>>> application objects like Actions and such. >>>>>>>>>> >>>>>>>>>> -bp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>>>>> >>>>>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>>>>> comes to Sun APIs. >>>>>>>>>>> >>>>>>>>>>> musachy >>>>>>>>>>> >>>>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>>>>> wrote: >>>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>>>>> -bp >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>>>>> >>>>>>>>>>>>> what do you think? >>>>>>>>>>>>> >>>>>>>>>>>>> musachy >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: 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
I am almost positive WAS V7 does not have working implementation of JSR299 :( (I will try to
dig more). Looking on Ballot results for this JSR, It seems IBM is the only one who voted
against this JSR.
I think if there is going to be an implementation of this JSR, It will be probably WAS V7.1.
--- On Mon, 12/7/09, Rene Gielen <gielen@it-neering.net> wrote:
> From: Rene Gielen <gielen@it-neering.net>
> Subject: Re: Announcing first shot on a JSR299/CDI/WebBeans support plugin for Struts2
> To: "Struts Developers List" <dev@struts.apache.org>
> Received: Monday, December 7, 2009, 7:58 PM
> AFAIK WS7 is JEE5 only. Do they have
> a working JSR299 implemntation? If
> yes, a test might be interesting.
>
> Struts Two wrote:
> > Now that Websphere application server is available for
> free for development purposes, are there any plans to test
> this against Websphere?
> >
> > You can check the following site for free download of
> Webshpere :
> >
> > http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/index.html
> >
> > (originally posted in a thread by Martin Cooper
> >
> > --- On Mon, 12/7/09, Musachy Barroso <musachy@gmail.com>
> wrote:
> >
> >> From: Musachy Barroso <musachy@gmail.com>
> >> Subject: Re: Announcing first shot on a
> JSR299/CDI/WebBeans support plugin for Struts2
> >> To: "Struts Developers List" <dev@struts.apache.org>
> >> Received: Monday, December 7, 2009, 7:42 PM
> >> sweet. when xwork finally lands on
> >> struts I will start looking at
> >> replacing "our guice", with the api from jsr-330
> and using
> >> guice as
> >> the default implementation, that should go nicely
> with this
> >> plugin.
> >>
> >> musachy
> >>
> >> On Mon, Dec 7, 2009 at 11:29 AM, Rene Gielen
> <rgielen@apache.org>
> >> wrote:
> >>> I've put my initial works on a Struts2 CDI
> plugin into
> >> the sandbox. It
> >>> implements a JEE6 compliant ObjectFactory,
> making
> >> Actions etc. being wired
> >>> up by the EE container, with all the good
> stuff like
> >> scoped managed beans,
> >>> EJBs and such.
> >>>
> >>> The plugin is built against current S2 trunk
> >> (2.2.0-SNAPSHOT). It uses JBoss
> >>> Weld (the JSR299 RI) for building and testing,
> as well
> >> as an early version
> >>> of Weld-SE for testing. The latter dependency
> is not
> >> yet in a maven
> >>> repository, but the build process will
> bootstrap it
> >> from subversion when the
> >>> bootstrap profile is enabled:
> >>> mvn -Pbootstrap install
> >>> Please note that the bootstrap build of
> Weld-SE
> >> enforces use of Maven 2.0.10
> >>> - don't ask me why ... ;)
> >>>
> >>> I've also put together the inevitable
> NumberGuess
> >> example as a S2
> >>> implementation, using and demonstrating the
> >> CDI-plugin. It works nicely
> >>> against Glassfish V3 full profile preview,
> JBoss
> >> should work as well.
> >>> I've got some further ideas for transaction
> management
> >> helper interceptor,
> >>> as well as some thoughts on how a @PreDestroy
> >> lifecycle method might be
> >>> supported in Actions. I also plan to add some
> useful
> >> documentation to the
> >>> wiki.
> >>>
> >>> Any feedback highly appreciated, have fun with
> it :)
> >>>
> >>> Plugin:
> >>> https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-plugin/
> >>> Example:
> >>> https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-example/
> >>>
> >>> Regards,
> >>> - Rene
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >>> For additional commands, e-mail: dev-help@struts.apache.org
> >>>
> >>>
> >>
> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> >> For additional commands, e-mail: dev-help@struts.apache.org
> >>
> >>
> >
> >
> >
> __________________________________________________________________
> > Yahoo! Canada Toolbar: Search from anywhere on the
> web, and bookmark your favourite sites. Download it now
> > http://ca.toolbar.yahoo.com.
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________________________________________
Looking for the perfect gift? Give the gift of Flickr!
http://www.flickr.com/gift/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
I don't know about dropping Object factory, in this case it would just delegate to the jsr 330 implementation. But getting rid of the double object factory problem would be very nice. On Mon, Dec 7, 2009 at 12:06 PM, Rene Gielen <gielen@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 <musachy@gmail.com> wrote: >>> It is good that you brought this up, because the double object factory >>> is annoying and creates a lot of unexpected situations(problems with >>> class reloading and OSGi). Having just one container would make it >>> easier for everybody, users and s2 developers, if it can be pulled >>> off. >>> >>> This kind of change could be too big for a 2.x release I think >>> >>> musachy >>> >>> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >>>> >>>> -bp >>>> >>>> >>>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >>>> >>>>> ah I see what you mean. yes that would be a good idea, I think that >>>>> would work as long as all the containers have what we need, which I am >>>>> not sure if it is in the spec or not (havent read it), like: >>>>> >>>>> * create/inject objects and statics (duh) >>>>> * lookup all implementation by type >>>>> >>>>> that's all I can think off the top of my head. >>>>> >>>>> musachy >>>>> >>>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>>>> >>>>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> >>>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>>>> >>>>>>> this is not related to the application itself, you can still use any >>>>>>> IoC you want. This is for the IoC that is used internally to wire >>>>>>> struts internals together, which at the moment is an old version of >>>>>>> guice which is in xwork. >>>>>>> >>>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>>>> but I still want to try to stay as current as possible on Struts. >>>>>>>> (*Chris*) >>>>>>>> >>>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>>>> >>>>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>>>> that. >>>>>>>>> >>>>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>>>> layout would be best: >>>>>>>>> >>>>>>>>> Base >>>>>>>>> | >>>>>>>>> | >>>>>>>>> _________ >>>>>>>>> | | >>>>>>>>> | | >>>>>>>>> Struts App >>>>>>>>> >>>>>>>>> >>>>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>>>> injector will contain all of the private objects that should not be >>>>>>>>> accessible to the application. The App injector will contain all the >>>>>>>>> application objects like Actions and such. >>>>>>>>> >>>>>>>>> -bp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>>>> >>>>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>>>> comes to Sun APIs. >>>>>>>>>> >>>>>>>>>> musachy >>>>>>>>>> >>>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>>>> wrote: >>>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>>>> -bp >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>>>> >>>>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>>>> >>>>>>>>>>>> what do you think? >>>>>>>>>>>> >>>>>>>>>>>> musachy >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
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 <musachy@gmail.com> wrote: >> It is good that you brought this up, because the double object factory >> is annoying and creates a lot of unexpected situations(problems with >> class reloading and OSGi). Having just one container would make it >> easier for everybody, users and s2 developers, if it can be pulled >> off. >> >> This kind of change could be too big for a 2.x release I think >> >> musachy >> >> On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >>> >>> -bp >>> >>> >>> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >>> >>>> ah I see what you mean. yes that would be a good idea, I think that >>>> would work as long as all the containers have what we need, which I am >>>> not sure if it is in the spec or not (havent read it), like: >>>> >>>> * create/inject objects and statics (duh) >>>> * lookup all implementation by type >>>> >>>> that's all I can think off the top of my head. >>>> >>>> musachy >>>> >>>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>>> >>>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>>> >>>>> -bp >>>>> >>>>> >>>>> >>>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>>> >>>>>> this is not related to the application itself, you can still use any >>>>>> IoC you want. This is for the IoC that is used internally to wire >>>>>> struts internals together, which at the moment is an old version of >>>>>> guice which is in xwork. >>>>>> >>>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>>> but I still want to try to stay as current as possible on Struts. >>>>>>> (*Chris*) >>>>>>> >>>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>>> >>>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>>> that. >>>>>>>> >>>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>>> layout would be best: >>>>>>>> >>>>>>>> Base >>>>>>>> | >>>>>>>> | >>>>>>>> _________ >>>>>>>> | | >>>>>>>> | | >>>>>>>> Struts App >>>>>>>> >>>>>>>> >>>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>>> injector will contain all of the private objects that should not be >>>>>>>> accessible to the application. The App injector will contain all the >>>>>>>> application objects like Actions and such. >>>>>>>> >>>>>>>> -bp >>>>>>>> >>>>>>>> >>>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>>> >>>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>>> comes to Sun APIs. >>>>>>>>> >>>>>>>>> musachy >>>>>>>>> >>>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>>> wrote: >>>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>>> -bp >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>>> >>>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>>> >>>>>>>>>>> what do you think? >>>>>>>>>>> >>>>>>>>>>> musachy >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
AFAIK WS7 is JEE5 only. Do they have a working JSR299 implemntation? If yes, a test might be interesting. Struts Two wrote: > Now that Websphere application server is available for free for development purposes, are there any plans to test this against Websphere? > > You can check the following site for free download of Webshpere : > > http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/index.html > > (originally posted in a thread by Martin Cooper > > --- On Mon, 12/7/09, Musachy Barroso <musachy@gmail.com> wrote: > >> From: Musachy Barroso <musachy@gmail.com> >> Subject: Re: Announcing first shot on a JSR299/CDI/WebBeans support plugin for Struts2 >> To: "Struts Developers List" <dev@struts.apache.org> >> Received: Monday, December 7, 2009, 7:42 PM >> sweet. when xwork finally lands on >> struts I will start looking at >> replacing "our guice", with the api from jsr-330 and using >> guice as >> the default implementation, that should go nicely with this >> plugin. >> >> musachy >> >> On Mon, Dec 7, 2009 at 11:29 AM, Rene Gielen <rgielen@apache.org> >> wrote: >>> I've put my initial works on a Struts2 CDI plugin into >> the sandbox. It >>> implements a JEE6 compliant ObjectFactory, making >> Actions etc. being wired >>> up by the EE container, with all the good stuff like >> scoped managed beans, >>> EJBs and such. >>> >>> The plugin is built against current S2 trunk >> (2.2.0-SNAPSHOT). It uses JBoss >>> Weld (the JSR299 RI) for building and testing, as well >> as an early version >>> of Weld-SE for testing. The latter dependency is not >> yet in a maven >>> repository, but the build process will bootstrap it >> from subversion when the >>> bootstrap profile is enabled: >>> mvn -Pbootstrap install >>> Please note that the bootstrap build of Weld-SE >> enforces use of Maven 2.0.10 >>> - don't ask me why ... ;) >>> >>> I've also put together the inevitable NumberGuess >> example as a S2 >>> implementation, using and demonstrating the >> CDI-plugin. It works nicely >>> against Glassfish V3 full profile preview, JBoss >> should work as well. >>> I've got some further ideas for transaction management >> helper interceptor, >>> as well as some thoughts on how a @PreDestroy >> lifecycle method might be >>> supported in Actions. I also plan to add some useful >> documentation to the >>> wiki. >>> >>> Any feedback highly appreciated, have fun with it :) >>> >>> Plugin: >>> https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-plugin/ >>> Example: >>> https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-example/ >>> >>> Regards, >>> - Rene >>> >>> >> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> > > > __________________________________________________________________ > Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites. Download it now > http://ca.toolbar.yahoo.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
Yes, replacing Guice 1-pre with Guice 2 would be the great. I've got some comments, though - will put them to the Struts 2.2 + Guice 2 thread. Musachy Barroso wrote: > sweet. when xwork finally lands on struts I will start looking at > replacing "our guice", with the api from jsr-330 and using guice as > the default implementation, that should go nicely with this plugin. > > musachy > > On Mon, Dec 7, 2009 at 11:29 AM, Rene Gielen <rgielen@apache.org> wrote: >> I've put my initial works on a Struts2 CDI plugin into the sandbox. It >> implements a JEE6 compliant ObjectFactory, making Actions etc. being wired >> up by the EE container, with all the good stuff like scoped managed beans, >> EJBs and such. >> >> The plugin is built against current S2 trunk (2.2.0-SNAPSHOT). It uses JBoss >> Weld (the JSR299 RI) for building and testing, as well as an early version >> of Weld-SE for testing. The latter dependency is not yet in a maven >> repository, but the build process will bootstrap it from subversion when the >> bootstrap profile is enabled: >> mvn -Pbootstrap install >> Please note that the bootstrap build of Weld-SE enforces use of Maven 2.0.10 >> - don't ask me why ... ;) >> >> I've also put together the inevitable NumberGuess example as a S2 >> implementation, using and demonstrating the CDI-plugin. It works nicely >> against Glassfish V3 full profile preview, JBoss should work as well. >> >> I've got some further ideas for transaction management helper interceptor, >> as well as some thoughts on how a @PreDestroy lifecycle method might be >> supported in Actions. I also plan to add some useful documentation to the >> wiki. >> >> Any feedback highly appreciated, have fun with it :) >> >> Plugin: >> https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-plugin/ >> Example: >> https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-example/ >> >> Regards, >> - Rene >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: 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
Now that Websphere application server is available for free for development purposes, are there
any plans to test this against Websphere?
You can check the following site for free download of Webshpere :
http://www.ibm.com/developerworks/downloads/ws/wasdevelopers/index.html
(originally posted in a thread by Martin Cooper
--- On Mon, 12/7/09, Musachy Barroso <musachy@gmail.com> wrote:
> From: Musachy Barroso <musachy@gmail.com>
> Subject: Re: Announcing first shot on a JSR299/CDI/WebBeans support plugin for Struts2
> To: "Struts Developers List" <dev@struts.apache.org>
> Received: Monday, December 7, 2009, 7:42 PM
> sweet. when xwork finally lands on
> struts I will start looking at
> replacing "our guice", with the api from jsr-330 and using
> guice as
> the default implementation, that should go nicely with this
> plugin.
>
> musachy
>
> On Mon, Dec 7, 2009 at 11:29 AM, Rene Gielen <rgielen@apache.org>
> wrote:
> > I've put my initial works on a Struts2 CDI plugin into
> the sandbox. It
> > implements a JEE6 compliant ObjectFactory, making
> Actions etc. being wired
> > up by the EE container, with all the good stuff like
> scoped managed beans,
> > EJBs and such.
> >
> > The plugin is built against current S2 trunk
> (2.2.0-SNAPSHOT). It uses JBoss
> > Weld (the JSR299 RI) for building and testing, as well
> as an early version
> > of Weld-SE for testing. The latter dependency is not
> yet in a maven
> > repository, but the build process will bootstrap it
> from subversion when the
> > bootstrap profile is enabled:
> > mvn -Pbootstrap install
> > Please note that the bootstrap build of Weld-SE
> enforces use of Maven 2.0.10
> > - don't ask me why ... ;)
> >
> > I've also put together the inevitable NumberGuess
> example as a S2
> > implementation, using and demonstrating the
> CDI-plugin. It works nicely
> > against Glassfish V3 full profile preview, JBoss
> should work as well.
> >
> > I've got some further ideas for transaction management
> helper interceptor,
> > as well as some thoughts on how a @PreDestroy
> lifecycle method might be
> > supported in Actions. I also plan to add some useful
> documentation to the
> > wiki.
> >
> > Any feedback highly appreciated, have fun with it :)
> >
> > Plugin:
> > https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-plugin/
> > Example:
> > https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-example/
> >
> > Regards,
> > - Rene
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> > For additional commands, e-mail: dev-help@struts.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
>
__________________________________________________________________
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your favourite sites.
Download it now
http://ca.toolbar.yahoo.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
sweet. when xwork finally lands on struts I will start looking at replacing "our guice", with the api from jsr-330 and using guice as the default implementation, that should go nicely with this plugin. musachy On Mon, Dec 7, 2009 at 11:29 AM, Rene Gielen <rgielen@apache.org> wrote: > I've put my initial works on a Struts2 CDI plugin into the sandbox. It > implements a JEE6 compliant ObjectFactory, making Actions etc. being wired > up by the EE container, with all the good stuff like scoped managed beans, > EJBs and such. > > The plugin is built against current S2 trunk (2.2.0-SNAPSHOT). It uses JBoss > Weld (the JSR299 RI) for building and testing, as well as an early version > of Weld-SE for testing. The latter dependency is not yet in a maven > repository, but the build process will bootstrap it from subversion when the > bootstrap profile is enabled: > mvn -Pbootstrap install > Please note that the bootstrap build of Weld-SE enforces use of Maven 2.0.10 > - don't ask me why ... ;) > > I've also put together the inevitable NumberGuess example as a S2 > implementation, using and demonstrating the CDI-plugin. It works nicely > against Glassfish V3 full profile preview, JBoss should work as well. > > I've got some further ideas for transaction management helper interceptor, > as well as some thoughts on how a @PreDestroy lifecycle method might be > supported in Actions. I also plan to add some useful documentation to the > wiki. > > Any feedback highly appreciated, have fun with it :) > > Plugin: > https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-plugin/ > Example: > https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-example/ > > Regards, > - Rene > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
I've put my initial works on a Struts2 CDI plugin into the sandbox. It implements a JEE6 compliant ObjectFactory, making Actions etc. being wired up by the EE container, with all the good stuff like scoped managed beans, EJBs and such. The plugin is built against current S2 trunk (2.2.0-SNAPSHOT). It uses JBoss Weld (the JSR299 RI) for building and testing, as well as an early version of Weld-SE for testing. The latter dependency is not yet in a maven repository, but the build process will bootstrap it from subversion when the bootstrap profile is enabled: mvn -Pbootstrap install Please note that the bootstrap build of Weld-SE enforces use of Maven 2.0.10 - don't ask me why ... ;) I've also put together the inevitable NumberGuess example as a S2 implementation, using and demonstrating the CDI-plugin. It works nicely against Glassfish V3 full profile preview, JBoss should work as well. I've got some further ideas for transaction management helper interceptor, as well as some thoughts on how a @PreDestroy lifecycle method might be supported in Actions. I also plan to add some useful documentation to the wiki. Any feedback highly appreciated, have fun with it :) Plugin: https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-plugin/ Example: https://svn.apache.org/repos/asf/struts/sandbox/trunk/struts2-cdi-example/ Regards, - Rene --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
Actually it's against Contexts and Dependency Injection, JSR 299. Of course it implicitly uses JSR330, but the BeanManager stuff is part of the JSR299 API, with JBoss Weld being the RI. Notice the javax.enterprise package prefixes of the imports :) I'll commit the classical NumberGuess example as S2 app in a minute or so. Brian Pontarelli schrieb: > It looks like this code is against the JEE WebBeans injection stuff (299). The JSR that Guice will be implementing is 330, which is a JSE injection model. > > -bp > > > On Dec 7, 2009, at 9:35 AM, Wes Wannemacher wrote: > >> Is this 299 or 330? I have been meaning to read the spec, and this >> confused me... On jcp.org, there is a DI spec that is JSR330, is that >> the one we're talking about? JSR299 seems to refer to JSF. >> >> -Wes >> >> On Mon, Dec 7, 2009 at 11:32 AM, <rgielen@apache.org> wrote: >>> Author: rgielen >>> Date: Mon Dec 7 16:32:40 2009 >>> New Revision: 887991 >>> >>> URL: http://svn.apache.org/viewvc?rev=887991&view=rev >>> Log: >>> Initial work on a CDI / JSR299 plugin >>> >> [snip] >> >> -- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
It looks like this code is against the JEE WebBeans injection stuff (299). The JSR that Guice will be implementing is 330, which is a JSE injection model. -bp On Dec 7, 2009, at 9:35 AM, Wes Wannemacher wrote: > Is this 299 or 330? I have been meaning to read the spec, and this > confused me... On jcp.org, there is a DI spec that is JSR330, is that > the one we're talking about? JSR299 seems to refer to JSF. > > -Wes > > On Mon, Dec 7, 2009 at 11:32 AM, <rgielen@apache.org> wrote: >> Author: rgielen >> Date: Mon Dec 7 16:32:40 2009 >> New Revision: 887991 >> >> URL: http://svn.apache.org/viewvc?rev=887991&view=rev >> Log: >> Initial work on a CDI / JSR299 plugin >> > [snip] > > -- > 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
Nevermind, I think I've figured it out... The JSR 299 description is somewhat ambiguous here - http://www.jcp.org/en/jsr/all the description reads - 299, Web Beans, Description: The purpose of this specification is to unify the JSF managed bean component model with the EJB component model, resulting in a significantly simplified programming model for web-based applications. After downloading both (330 and 299) and figuring out what's going on, I'm set now. -Wes On Mon, Dec 7, 2009 at 11:35 AM, Wes Wannemacher <wesw@wantii.com> wrote: > Is this 299 or 330? I have been meaning to read the spec, and this > confused me... On jcp.org, there is a DI spec that is JSR330, is that > the one we're talking about? JSR299 seems to refer to JSF. > > -Wes > > On Mon, Dec 7, 2009 at 11:32 AM, <rgielen@apache.org> wrote: >> Author: rgielen >> Date: Mon Dec 7 16:32:40 2009 >> New Revision: 887991 >> >> URL: http://svn.apache.org/viewvc?rev=887991&view=rev >> Log: >> Initial work on a CDI / JSR299 plugin >> > [snip] > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > -- 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
Is this 299 or 330? I have been meaning to read the spec, and this confused me... On jcp.org, there is a DI spec that is JSR330, is that the one we're talking about? JSR299 seems to refer to JSF. -Wes On Mon, Dec 7, 2009 at 11:32 AM, <rgielen@apache.org> wrote: > Author: rgielen > Date: Mon Dec 7 16:32:40 2009 > New Revision: 887991 > > URL: http://svn.apache.org/viewvc?rev=887991&view=rev > Log: > Initial work on a CDI / JSR299 plugin > [snip] -- 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
Is there an update on when the Struts 2 archetypes will be available? Bruce Lukasz Lenart wrote: > > 2009/11/13 Musachy Barroso <musachy@gmail.com>: >> Any plans to deploy them now that 2.1.8.1 is out? After voting on them >> of course :) > > Next week I've been planing to start a vote, if I learn how Maven > release process is working ;-) > > -- View this message in context: http://old.nabble.com/Archetypes-tp25792028p26667138.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
Hi friends, any clue? Srikanth VSGoud wrote: > > Hi Friends, > I am using struts 2.1.6. Facing problem with error messages. > When i use 'regex' validator in validation.xml file than > 1. when i clicked on submit button for the first time. > It is showing error messages like > Customer name is required. > Allow alphabets only. > the above message 'Allow alphabets only must show when some invalid data > enter in the field other than alphabets. > > 2. with out entering data again i clicked submit button. > than know error messages are > Customer name is required. > Allow alphabets only. > Customer name is required. > Allow alphabets only. Repated twice. > > if i clicked again thrice......... > > And my code in xml file is, and using default theme > > > <field name="customer.name"> > <field-validator type="requiredstring" short-circuit="true"> > true > <message key="error.cusname.req"></message> > </field-validator> > <field-validator type="regex" > > <![CDATA[(^[a-zA-Z ]+$)]]> > <message key="error.cusname.fv"></message> > </field-validator> > </field> > > if i remove regex than it is working fine. > > Could u tell me how to reolve this issue. > > Srikanth Goud > -- View this message in context: http://old.nabble.com/problem-with-regex-validator-tp26608364p26626095.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
Hi Friends,
I am using struts 2.1.6. Facing problem with error messages.
When i use 'regex' validator in validation.xml file than
1. when i clicked on submit button for the first time.
It is showing error messages like
Customer name is required.
Allow alphabets only.
the above message 'Allow alphabets only must show when some invalid data
enter in the field other than alphabets.
2. with out entering data again i clicked submit button.
than know error messages are
Customer name is required.
Allow alphabets only.
Customer name is required.
Allow alphabets only. Repated twice.
if i clicked again thrice.........
And my code in xml file is, and using default theme
<field name="customer.name">
<field-validator type="requiredstring" short-circuit="true">
true
<message key="error.cusname.req"></message>
</field-validator>
<field-validator type="regex" >
<![CDATA[(^[a-zA-Z ]+$)]]>
<message key="error.cusname.fv"></message>
</field-validator>
</field>
if i remove regex than it is working fine.
Could u tell me how to reolve this issue.
Srikanth Goud
--
View this message in context: http://old.nabble.com/problem-with-regex-validator-tp26608364p26608364.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
Hi,
maybe You are hitting max GET size?
But that's just a guess.
Best greetings,
Paweł Wielgus.
2009/12/1 LS <lakshmi_kannan@merck.com>:
>
> Hi All,
>
> I am using Struts2 redirectAction result type as follows -
>
> <result name="y" type="redirectAction">
> x_viewReport.action
> true
> ${projectId}
> ${contractId}
> ${workOrderId}
> ${contactId}
> ${samplePlanId}
> ${selectionCriteria}
> ${barcodes}
> </result>
>
> Barcodes parameter is an user input and if it exceeds 118 barcodes, each
> barcode separated by a newline character, then there is an OGNL error as
> follows -
>
> 2009-12-01 11:15:17,723 ERROR [com.opensymphony.xwork2.ObjectFactory]
> (http-127.0.0.1-8080-2) Unable to set parameter [barcodes] in result of type
> [org.apache.struts2.dispatcher.ServletActionRedirectResult]
> Caught OgnlException while setting property 'barcodes' on type
> 'org.apache.struts2.dispatcher.ServletActionRedirectResult'. - Class:
> ognl.ObjectPropertyAccessor
> File: ObjectPropertyAccessor.java
> Method: setProperty
> Line: 132 - ognl/ObjectPropertyAccessor.java:132:-1
> Â Â Â Â at
> com.opensymphony.xwork2.ognl.OgnlUtil.internalSetProperty(OgnlUtil.java:392)
> Â Â Â Â at com.opensymphony.xwork2.ognl.OgnlUtil.setProperty(OgnlUtil.java:143)
> Â Â Â Â at
> com.opensymphony.xwork2.ognl.OgnlReflectionProvider.setProperty(OgnlReflectionProvider.java:91)
> Â Â Â Â at
> com.opensymphony.xwork2.ObjectFactory.buildResult(ObjectFactory.java:221)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.createResult(DefaultActionInvocation.java:208)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:355)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:265)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:163)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:249)
> Â Â Â Â at
> org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:148)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:93)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:235)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:89)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:128)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> org.apache.struts2.interceptor.ProfilingActivationInterceptor.intercept(ProfilingActivationInterceptor.java:104)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:267)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:126)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:138)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:148)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:128)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:176)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> rosetta.rpm.controller.interceptor.BreadcrumbInjectorInterceptor.intercept(BreadcrumbInjectorInterceptor.java:54)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> rosetta.rpm.controller.interceptor.MaterialPermissionInterceptor.intercept(MaterialPermissionInterceptor.java:57)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> rosetta.commons.interceptor.UserInterceptor.intercept(UserInterceptor.java:67)
> Â Â Â Â at
> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
> Â Â Â Â at
> org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:52)
> Â Â Â Â at
> org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:468)
> Â Â Â Â at
> org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:395)
> Â Â Â Â at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> Â Â Â Â at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> Â Â Â Â at
> org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
> Â Â Â Â at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
> Â Â Â Â at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
> Â Â Â Â at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
> Â Â Â Â at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
> Â Â Â Â at
> org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
> Â Â Â Â at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
> Â Â Â Â at
> org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
> Â Â Â Â at
> org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
> Â Â Â Â at
> org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
> Â Â Â Â at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> Â Â Â Â at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
> Â Â Â Â at
> org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
> Â Â Â Â at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
> Â Â Â Â at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
> Â Â Â Â at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
> Â Â Â Â at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
> Â Â Â Â at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
> Â Â Â Â at java.lang.Thread.run(Thread.java:619)
> Caused by: ognl.NoSuchPropertyException:
> org.apache.struts2.dispatcher.ServletActionRedirectResult.barcodes
> Â Â Â Â at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:132)
> Â Â Â Â at
> com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:28)
> Â Â Â Â at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1656)
> Â Â Â Â at ognl.ASTProperty.setValueBody(ASTProperty.java:101)
> Â Â Â Â at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177)
> Â Â Â Â at ognl.SimpleNode.setValue(SimpleNode.java:246)
> Â Â Â Â at ognl.Ognl.setValue(Ognl.java:476)
> Â Â Â Â at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:192)
> Â Â Â Â at
> com.opensymphony.xwork2.ognl.OgnlUtil.internalSetProperty(OgnlUtil.java:385)
> Â Â Â Â ... 78 more
>
> --
>
> I am seeing this OGNL error for all the parameters, not only for barcodes.
>
> If there are <= 118 barcodes, it works fine.
> Is there a max length limit on the parameter values on redirect?
> I am seeing this issue only during redirects. If I access the action
> directly, then there is no issue.
>
> Any suggestions would be greatly appreciated. Thanks!
>
> --
> View this message in context: http://old.nabble.com/Strtus2-RedirectAction-result-type---Parameter-Max-length-tp26597762p26597762.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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
I am reading the spec and I am rather impressed, I thought it would be a simple thing but it is really comprehensive. I doubt we will have a use case that won't be covered there. musachy On Tue, Dec 1, 2009 at 10:49 AM, Musachy Barroso <musachy@gmail.com> wrote: > It is good that you brought this up, because the double object factory > is annoying and creates a lot of unexpected situations(problems with > class reloading and OSGi). Having just one container would make it > easier for everybody, users and s2 developers, if it can be pulled > off. > > This kind of change could be too big for a 2.x release I think > > musachy > > On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >> We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. >> >> -bp >> >> >> On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: >> >>> ah I see what you mean. yes that would be a good idea, I think that >>> would work as long as all the containers have what we need, which I am >>> not sure if it is in the spec or not (havent read it), like: >>> >>> * create/inject objects and statics (duh) >>> * lookup all implementation by type >>> >>> that's all I can think off the top of my head. >>> >>> musachy >>> >>> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>>> >>>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>>> >>>> -bp >>>> >>>> >>>> >>>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>>> >>>>> this is not related to the application itself, you can still use any >>>>> IoC you want. This is for the IoC that is used internally to wire >>>>> struts internals together, which at the moment is an old version of >>>>> guice which is in xwork. >>>>> >>>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>>> but I still want to try to stay as current as possible on Struts. >>>>>> (*Chris*) >>>>>> >>>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>>> >>>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>>> that. >>>>>>> >>>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>>> layout would be best: >>>>>>> >>>>>>> Base >>>>>>> | >>>>>>> | >>>>>>> _________ >>>>>>> | | >>>>>>> | | >>>>>>> Struts App >>>>>>> >>>>>>> >>>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>>> and any Struts objects that can be used by the application. The Struts >>>>>>> injector will contain all of the private objects that should not be >>>>>>> accessible to the application. The App injector will contain all the >>>>>>> application objects like Actions and such. >>>>>>> >>>>>>> -bp >>>>>>> >>>>>>> >>>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>>> >>>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>>> about it, like what is the status of the jsr and will the API >>>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>>> license and in maven central? which is usually a pain point when it >>>>>>>> comes to Sun APIs. >>>>>>>> >>>>>>>> musachy >>>>>>>> >>>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>>> wrote: >>>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>>> plug in Spring/Guice/etc easily. >>>>>>>>> >>>>>>>>> -bp >>>>>>>>> >>>>>>>>> >>>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>>> >>>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>>> >>>>>>>>>> what do you think? >>>>>>>>>> >>>>>>>>>> musachy >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
Hi All,
I am using Struts2 redirectAction result type as follows -
<result name="y" type="redirectAction">
x_viewReport.action
true
${projectId}
${contractId}
${workOrderId}
${contactId}
${samplePlanId}
${selectionCriteria}
${barcodes}
</result>
Barcodes parameter is an user input and if it exceeds 118 barcodes, each
barcode separated by a newline character, then there is an OGNL error as
follows -
2009-12-01 11:15:17,723 ERROR [com.opensymphony.xwork2.ObjectFactory]
(http-127.0.0.1-8080-2) Unable to set parameter [barcodes] in result of type
[org.apache.struts2.dispatcher.ServletActionRedirectResult]
Caught OgnlException while setting property 'barcodes' on type
'org.apache.struts2.dispatcher.ServletActionRedirectResult'. - Class:
ognl.ObjectPropertyAccessor
File: ObjectPropertyAccessor.java
Method: setProperty
Line: 132 - ognl/ObjectPropertyAccessor.java:132:-1
at
com.opensymphony.xwork2.ognl.OgnlUtil.internalSetProperty(OgnlUtil.java:392)
at com.opensymphony.xwork2.ognl.OgnlUtil.setProperty(OgnlUtil.java:143)
at
com.opensymphony.xwork2.ognl.OgnlReflectionProvider.setProperty(OgnlReflectionProvider.java:91)
at
com.opensymphony.xwork2.ObjectFactory.buildResult(ObjectFactory.java:221)
at
com.opensymphony.xwork2.DefaultActionInvocation.createResult(DefaultActionInvocation.java:208)
at
com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:355)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:265)
at
com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:163)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:249)
at
org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:148)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:93)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:235)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:89)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:128)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
org.apache.struts2.interceptor.ProfilingActivationInterceptor.intercept(ProfilingActivationInterceptor.java:104)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:267)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:126)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:138)
at
com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:148)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:128)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:176)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
rosetta.rpm.controller.interceptor.BreadcrumbInjectorInterceptor.intercept(BreadcrumbInjectorInterceptor.java:54)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
rosetta.rpm.controller.interceptor.MaterialPermissionInterceptor.intercept(MaterialPermissionInterceptor.java:57)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
rosetta.commons.interceptor.UserInterceptor.intercept(UserInterceptor.java:67)
at
com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:236)
at
org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:52)
at
org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:468)
at
org.apache.struts2.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:395)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
at
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
at
org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
at
org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: ognl.NoSuchPropertyException:
org.apache.struts2.dispatcher.ServletActionRedirectResult.barcodes
at ognl.ObjectPropertyAccessor.setProperty(ObjectPropertyAccessor.java:132)
at
com.opensymphony.xwork2.ognl.accessor.ObjectAccessor.setProperty(ObjectAccessor.java:28)
at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1656)
at ognl.ASTProperty.setValueBody(ASTProperty.java:101)
at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177)
at ognl.SimpleNode.setValue(SimpleNode.java:246)
at ognl.Ognl.setValue(Ognl.java:476)
at com.opensymphony.xwork2.ognl.OgnlUtil.setValue(OgnlUtil.java:192)
at
com.opensymphony.xwork2.ognl.OgnlUtil.internalSetProperty(OgnlUtil.java:385)
... 78 more
--
I am seeing this OGNL error for all the parameters, not only for barcodes.
If there are <= 118 barcodes, it works fine.
Is there a max length limit on the parameter values on redirect?
I am seeing this issue only during redirects. If I access the action
directly, then there is no issue.
Any suggestions would be greatly appreciated. Thanks!
--
View this message in context: http://old.nabble.com/Strtus2-RedirectAction-result-type---Parameter-Max-length-tp26597762p26597762.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
It is good that you brought this up, because the double object factory is annoying and creates a lot of unexpected situations(problems with class reloading and OSGi). Having just one container would make it easier for everybody, users and s2 developers, if it can be pulled off. This kind of change could be too big for a 2.x release I think musachy On Tue, Dec 1, 2009 at 10:44 AM, Brian Pontarelli <brian@pontarelli.com> wrote: > We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. > > -bp > > > On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: > >> ah I see what you mean. yes that would be a good idea, I think that >> would work as long as all the containers have what we need, which I am >> not sure if it is in the spec or not (havent read it), like: >> >> * create/inject objects and statics (duh) >> * lookup all implementation by type >> >> that's all I can think off the top of my head. >> >> musachy >> >> On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >>> >>> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >>> >>> -bp >>> >>> >>> >>> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >>> >>>> this is not related to the application itself, you can still use any >>>> IoC you want. This is for the IoC that is used internally to wire >>>> struts internals together, which at the moment is an old version of >>>> guice which is in xwork. >>>> >>>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>>> but I still want to try to stay as current as possible on Struts. >>>>> (*Chris*) >>>>> >>>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>>> >>>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>>> that. >>>>>> >>>>>> The real question is how to setup the Injector's. I tend to think this >>>>>> layout would be best: >>>>>> >>>>>> Base >>>>>> | >>>>>> | >>>>>> _________ >>>>>> | | >>>>>> | | >>>>>> Struts App >>>>>> >>>>>> >>>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>>> and any Struts objects that can be used by the application. The Struts >>>>>> injector will contain all of the private objects that should not be >>>>>> accessible to the application. The App injector will contain all the >>>>>> application objects like Actions and such. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>>> >>>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>>> about it, like what is the status of the jsr and will the API >>>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>>> license and in maven central? which is usually a pain point when it >>>>>>> comes to Sun APIs. >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>>> wrote: >>>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>>> plug in Spring/Guice/etc easily. >>>>>>>> >>>>>>>> -bp >>>>>>>> >>>>>>>> >>>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>>> >>>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>>> >>>>>>>>> what do you think? >>>>>>>>> >>>>>>>>> musachy >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
We could probably make a list and verify. I think the API should be pretty comprehensive about a lot of those things. -bp On Dec 1, 2009, at 11:42 AM, Musachy Barroso wrote: > ah I see what you mean. yes that would be a good idea, I think that > would work as long as all the containers have what we need, which I am > not sure if it is in the spec or not (havent read it), like: > > * create/inject objects and statics (duh) > * lookup all implementation by type > > that's all I can think off the top of my head. > > musachy > > On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >> I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. >> >> The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. >> >> -bp >> >> >> >> On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: >> >>> this is not related to the application itself, you can still use any >>> IoC you want. This is for the IoC that is used internally to wire >>> struts internals together, which at the moment is an old version of >>> guice which is in xwork. >>> >>> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>>> I wouldn't have a problem with it as long as I can still swap in my trusty >>>> Spring IoC container, I can't see my team moving away from it any time soon, >>>> but I still want to try to stay as current as possible on Struts. >>>> (*Chris*) >>>> >>>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>>> >>>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>>> that. >>>>> >>>>> The real question is how to setup the Injector's. I tend to think this >>>>> layout would be best: >>>>> >>>>> Base >>>>> | >>>>> | >>>>> _________ >>>>> | | >>>>> | | >>>>> Struts App >>>>> >>>>> >>>>> The Base injector will contain the JEE objects (request, response, etc.) >>>>> and any Struts objects that can be used by the application. The Struts >>>>> injector will contain all of the private objects that should not be >>>>> accessible to the application. The App injector will contain all the >>>>> application objects like Actions and such. >>>>> >>>>> -bp >>>>> >>>>> >>>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>>> >>>>>> good point Brian, that has came up also. I have a couple of concerns >>>>>> about it, like what is the status of the jsr and will the API >>>>>> (annotations) will be under a decent (read ASF compatible license) >>>>>> license and in maven central? which is usually a pain point when it >>>>>> comes to Sun APIs. >>>>>> >>>>>> musachy >>>>>> >>>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>>> wrote: >>>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>>> Guice annotations. I'd also make the injector pluggable so that people can >>>>> plug in Spring/Guice/etc easily. >>>>>>> >>>>>>> -bp >>>>>>> >>>>>>> >>>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>>> >>>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>>> be that hard. Less code to maintain, and we get more >>>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>>> into xwork to avoid classpath conflicts. >>>>>>>> >>>>>>>> what do you think? >>>>>>>> >>>>>>>> musachy >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
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 <musachy@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 <thechrispratt@gmail.com> wrote: >>> I wouldn't have a problem with it as long as I can still swap in my trusty >>> Spring IoC container, I can't see my team moving away from it any time soon, >>> but I still want to try to stay as current as possible on Struts. >>> (*Chris*) >>> >>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>> >>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>> that. >>>> >>>> The real question is how to setup the Injector's. I tend to think this >>>> layout would be best: >>>> >>>> Base >>>> | >>>> | >>>> _________ >>>> | | >>>> | | >>>> Struts App >>>> >>>> >>>> The Base injector will contain the JEE objects (request, response, etc.) >>>> and any Struts objects that can be used by the application. The Struts >>>> injector will contain all of the private objects that should not be >>>> accessible to the application. The App injector will contain all the >>>> application objects like Actions and such. >>>> >>>> -bp >>>> >>>> >>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>> >>>>> good point Brian, that has came up also. I have a couple of concerns >>>>> about it, like what is the status of the jsr and will the API >>>>> (annotations) will be under a decent (read ASF compatible license) >>>>> license and in maven central? which is usually a pain point when it >>>>> comes to Sun APIs. >>>>> >>>>> musachy >>>>> >>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>> wrote: >>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>> Guice annotations. I'd also make the injector pluggable so that people can >>>> plug in Spring/Guice/etc easily. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>> >>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>> be that hard. Less code to maintain, and we get more >>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>> into xwork to avoid classpath conflicts. >>>>>>> >>>>>>> what do you think? >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
ah I see what you mean. yes that would be a good idea, I think that would work as long as all the containers have what we need, which I am not sure if it is in the spec or not (havent read it), like: * create/inject objects and statics (duh) * lookup all implementation by type that's all I can think off the top of my head. musachy On Tue, Dec 1, 2009 at 10:38 AM, Brian Pontarelli <brian@pontarelli.com> wrote: > I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. > > The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. > > -bp > > > > On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: > >> this is not related to the application itself, you can still use any >> IoC you want. This is for the IoC that is used internally to wire >> struts internals together, which at the moment is an old version of >> guice which is in xwork. >> >> On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >>> I wouldn't have a problem with it as long as I can still swap in my trusty >>> Spring IoC container, I can't see my team moving away from it any time soon, >>> but I still want to try to stay as current as possible on Struts. >>> (*Chris*) >>> >>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>> >>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>> that. >>>> >>>> The real question is how to setup the Injector's. I tend to think this >>>> layout would be best: >>>> >>>> Base >>>> | >>>> | >>>> _________ >>>> | | >>>> | | >>>> Struts App >>>> >>>> >>>> The Base injector will contain the JEE objects (request, response, etc.) >>>> and any Struts objects that can be used by the application. The Struts >>>> injector will contain all of the private objects that should not be >>>> accessible to the application. The App injector will contain all the >>>> application objects like Actions and such. >>>> >>>> -bp >>>> >>>> >>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>> >>>>> good point Brian, that has came up also. I have a couple of concerns >>>>> about it, like what is the status of the jsr and will the API >>>>> (annotations) will be under a decent (read ASF compatible license) >>>>> license and in maven central? which is usually a pain point when it >>>>> comes to Sun APIs. >>>>> >>>>> musachy >>>>> >>>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>> wrote: >>>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>>> Guice annotations. I'd also make the injector pluggable so that people can >>>> plug in Spring/Guice/etc easily. >>>>>> >>>>>> -bp >>>>>> >>>>>> >>>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>>> >>>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>>> be that hard. Less code to maintain, and we get more >>>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>>> into xwork to avoid classpath conflicts. >>>>>>> >>>>>>> what do you think? >>>>>>> >>>>>>> musachy >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
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 <martinc@apache.org> wrote: > On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso <musachy@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 <thechrispratt@gmail.com> wrote: >>> I wouldn't have a problem with it as long as I can still swap in my trusty >>> Spring IoC container, I can't see my team moving away from it any time soon, >>> but I still want to try to stay as current as possible on Struts. >>> (*Chris*) >>> >>> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >>> >>>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>>> that. >>>> >>>> The real question is how to setup the Injector's. I tend to think this >>>> layout would be best: >>>> >>>> Base >>>> | >>>> | >>>> _________ >>>> | | >>>> | | >>>> Struts App >>>> >>>> >>>> The Base injector will contain the JEE objects (request, response, etc.) >>>> and any Struts objects that can be used by the application. The Struts >>>> injector will contain all of the private objects that should not be >>>> accessible to the application. The App injector will contain all the >>>> application objects like Actions and such. >>>> >>>> -bp >>>> >>>> >>>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>>> >>>> > good point Brian, that has came up also. I have a couple of concerns >>>> > about it, like what is the status of the jsr and will the API >>>> > (annotations) will be under a decent (read ASF compatible license) >>>> > license and in maven central? which is usually a pain point when it >>>> > comes to Sun APIs. >>>> > >>>> > musachy >>>> > >>>> > On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>>> wrote: >>>> >> I'd suggest using Guice trunk and the JSR annotations rather than the >>>> Guice annotations. I'd also make the injector pluggable so that people can >>>> plug in Spring/Guice/etc easily. >>>> >> >>>> >> -bp >>>> >> >>>> >> >>>> >> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>> >> >>>> >>> I have talked to a couple of people before and everyone seems to agree >>>> >>> that using guice instead of our internal IoC container (guice pre 1.0 >>>> >>> I think), would be a good idea. I don't have any experience with guice >>>> >>> 2.0, but looking at the docs it seems like porting our stuff would not >>>> >>> be that hard. Less code to maintain, and we get more >>>> >>> features/improvements. If we go with this idea, guice would be shaded >>>> >>> into xwork to avoid classpath conflicts. >>>> >>> >>>> >>> what do you think? >>>> >>> >>>> >>> musachy >>>> >>> >>>> >>> --------------------------------------------------------------------- >>>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> >>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>> >>>> >> >>>> >> >>>> >> --------------------------------------------------------------------- >>>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> >> For additional commands, e-mail: dev-help@struts.apache.org >>>> >> >>>> >> >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> > For additional commands, e-mail: dev-help@struts.apache.org >>>> > >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
I was actually talking about expanding it out like Chris mentioned. I don't see any reason why those who want to use the container that Struts is using shouldn't be able to. Since the annotations and APIs will be standard across Guice and Spring with the JSR, it seems like it would be possible to allow the application and framework to use the same DI container, just different Injectors. The default could be Guice but allow Spring to be pluggable (or even discoverable). As long as the internals of Struts are compliant, it should work fine. This also provides the benefit of configuration reduction in web.xml and a more comprehensive solution. It would also get Struts out of the business of building objects and requiring additional configuration and plugins for different DI containers. I would guess it would clean up the double ObjectFactory issues as well. -bp On Dec 1, 2009, at 11:31 AM, Musachy Barroso wrote: > this is not related to the application itself, you can still use any > IoC you want. This is for the IoC that is used internally to wire > struts internals together, which at the moment is an old version of > guice which is in xwork. > > On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: >> I wouldn't have a problem with it as long as I can still swap in my trusty >> Spring IoC container, I can't see my team moving away from it any time soon, >> but I still want to try to stay as current as possible on Struts. >> (*Chris*) >> >> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >> >>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>> that. >>> >>> The real question is how to setup the Injector's. I tend to think this >>> layout would be best: >>> >>> Base >>> | >>> | >>> _________ >>> | | >>> | | >>> Struts App >>> >>> >>> The Base injector will contain the JEE objects (request, response, etc.) >>> and any Struts objects that can be used by the application. The Struts >>> injector will contain all of the private objects that should not be >>> accessible to the application. The App injector will contain all the >>> application objects like Actions and such. >>> >>> -bp >>> >>> >>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>> >>>> good point Brian, that has came up also. I have a couple of concerns >>>> about it, like what is the status of the jsr and will the API >>>> (annotations) will be under a decent (read ASF compatible license) >>>> license and in maven central? which is usually a pain point when it >>>> comes to Sun APIs. >>>> >>>> musachy >>>> >>>> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>> wrote: >>>>> I'd suggest using Guice trunk and the JSR annotations rather than the >>> Guice annotations. I'd also make the injector pluggable so that people can >>> plug in Spring/Guice/etc easily. >>>>> >>>>> -bp >>>>> >>>>> >>>>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>>>> >>>>>> I have talked to a couple of people before and everyone seems to agree >>>>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>>>> I think), would be a good idea. I don't have any experience with guice >>>>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>>>> be that hard. Less code to maintain, and we get more >>>>>> features/improvements. If we go with this idea, guice would be shaded >>>>>> into xwork to avoid classpath conflicts. >>>>>> >>>>>> what do you think? >>>>>> >>>>>> musachy >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>>> For additional commands, e-mail: dev-help@struts.apache.org >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
On Tue, Dec 1, 2009 at 10:31 AM, Musachy Barroso <musachy@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 <thechrispratt@gmail.com> wrote: >> I wouldn't have a problem with it as long as I can still swap in my trusty >> Spring IoC container, I can't see my team moving away from it any time soon, >> but I still want to try to stay as current as possible on Struts. >> (*Chris*) >> >> On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: >> >>> They'll be part of the Guice distribution and under ASLv2 since Guice uses >>> that. >>> >>> The real question is how to setup the Injector's. I tend to think this >>> layout would be best: >>> >>> Base >>> | >>> | >>> _________ >>> | | >>> | | >>> Struts App >>> >>> >>> The Base injector will contain the JEE objects (request, response, etc.) >>> and any Struts objects that can be used by the application. The Struts >>> injector will contain all of the private objects that should not be >>> accessible to the application. The App injector will contain all the >>> application objects like Actions and such. >>> >>> -bp >>> >>> >>> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >>> >>> > good point Brian, that has came up also. I have a couple of concerns >>> > about it, like what is the status of the jsr and will the API >>> > (annotations) will be under a decent (read ASF compatible license) >>> > license and in maven central? which is usually a pain point when it >>> > comes to Sun APIs. >>> > >>> > musachy >>> > >>> > On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >>> wrote: >>> >> I'd suggest using Guice trunk and the JSR annotations rather than the >>> Guice annotations. I'd also make the injector pluggable so that people can >>> plug in Spring/Guice/etc easily. >>> >> >>> >> -bp >>> >> >>> >> >>> >> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>> >> >>> >>> I have talked to a couple of people before and everyone seems to agree >>> >>> that using guice instead of our internal IoC container (guice pre 1.0 >>> >>> I think), would be a good idea. I don't have any experience with guice >>> >>> 2.0, but looking at the docs it seems like porting our stuff would not >>> >>> be that hard. Less code to maintain, and we get more >>> >>> features/improvements. If we go with this idea, guice would be shaded >>> >>> into xwork to avoid classpath conflicts. >>> >>> >>> >>> what do you think? >>> >>> >>> >>> musachy >>> >>> >>> >>> --------------------------------------------------------------------- >>> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> >> For additional commands, e-mail: dev-help@struts.apache.org >>> >> >>> >> >>> > >>> > --------------------------------------------------------------------- >>> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> > For additional commands, e-mail: dev-help@struts.apache.org >>> > >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
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 <brian@pontarelli.com> wrote: > They'll be part of the Guice distribution and under ASLv2 since Guice uses that. > > The real question is how to setup the Injector's. I tend to think this layout would be best: > > Base > | > | > _________ > | | > | | > Struts App > > > The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects that can be used by the application. The Struts injector will contain all of the private objects that should not be accessible to the application. The App injector will contain all the application objects like Actions and such. > > -bp > > > On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: > >> good point Brian, that has came up also. I have a couple of concerns >> about it, like what is the status of the jsr and will the API >> (annotations) will be under a decent (read ASF compatible license) >> license and in maven central? which is usually a pain point when it >> comes to Sun APIs. >> >> musachy >> >> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> wrote: >>> I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. >>> >>> -bp >>> >>> >>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >>> >>>> I have talked to a couple of people before and everyone seems to agree >>>> that using guice instead of our internal IoC container (guice pre 1.0 >>>> I think), would be a good idea. I don't have any experience with guice >>>> 2.0, but looking at the docs it seems like porting our stuff would not >>>> be that hard. Less code to maintain, and we get more >>>> features/improvements. If we go with this idea, guice would be shaded >>>> into xwork to avoid classpath conflicts. >>>> >>>> what do you think? >>>> >>>> musachy >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>>> For additional commands, e-mail: dev-help@struts.apache.org >>>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >>> For additional commands, e-mail: dev-help@struts.apache.org >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
this is not related to the application itself, you can still use any IoC you want. This is for the IoC that is used internally to wire struts internals together, which at the moment is an old version of guice which is in xwork. On Tue, Dec 1, 2009 at 10:28 AM, Chris Pratt <thechrispratt@gmail.com> wrote: > I wouldn't have a problem with it as long as I can still swap in my trusty > Spring IoC container, I can't see my team moving away from it any time soon, > but I still want to try to stay as current as possible on Struts. > (*Chris*) > > On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: > >> They'll be part of the Guice distribution and under ASLv2 since Guice uses >> that. >> >> The real question is how to setup the Injector's. I tend to think this >> layout would be best: >> >> Base >> | >> | >> _________ >> | | >> | | >> Struts App >> >> >> The Base injector will contain the JEE objects (request, response, etc.) >> and any Struts objects that can be used by the application. The Struts >> injector will contain all of the private objects that should not be >> accessible to the application. The App injector will contain all the >> application objects like Actions and such. >> >> -bp >> >> >> On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: >> >> > good point Brian, that has came up also. I have a couple of concerns >> > about it, like what is the status of the jsr and will the API >> > (annotations) will be under a decent (read ASF compatible license) >> > license and in maven central? which is usually a pain point when it >> > comes to Sun APIs. >> > >> > musachy >> > >> > On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> >> wrote: >> >> I'd suggest using Guice trunk and the JSR annotations rather than the >> Guice annotations. I'd also make the injector pluggable so that people can >> plug in Spring/Guice/etc easily. >> >> >> >> -bp >> >> >> >> >> >> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: >> >> >> >>> I have talked to a couple of people before and everyone seems to agree >> >>> that using guice instead of our internal IoC container (guice pre 1.0 >> >>> I think), would be a good idea. I don't have any experience with guice >> >>> 2.0, but looking at the docs it seems like porting our stuff would not >> >>> be that hard. Less code to maintain, and we get more >> >>> features/improvements. If we go with this idea, guice would be shaded >> >>> into xwork to avoid classpath conflicts. >> >>> >> >>> what do you think? >> >>> >> >>> musachy >> >>> >> >>> --------------------------------------------------------------------- >> >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> >>> For additional commands, e-mail: dev-help@struts.apache.org >> >>> >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> >> For additional commands, e-mail: dev-help@struts.apache.org >> >> >> >> >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> > For additional commands, e-mail: dev-help@struts.apache.org >> > >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
I wouldn't have a problem with it as long as I can still swap in my trusty Spring IoC container, I can't see my team moving away from it any time soon, but I still want to try to stay as current as possible on Struts. (*Chris*) On Tue, Dec 1, 2009 at 10:21 AM, Brian Pontarelli <brian@pontarelli.com>wrote: > They'll be part of the Guice distribution and under ASLv2 since Guice uses > that. > > The real question is how to setup the Injector's. I tend to think this > layout would be best: > > Base > | > | > _________ > | | > | | > Struts App > > > The Base injector will contain the JEE objects (request, response, etc.) > and any Struts objects that can be used by the application. The Struts > injector will contain all of the private objects that should not be > accessible to the application. The App injector will contain all the > application objects like Actions and such. > > -bp > > > On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote: > > > good point Brian, that has came up also. I have a couple of concerns > > about it, like what is the status of the jsr and will the API > > (annotations) will be under a decent (read ASF compatible license) > > license and in maven central? which is usually a pain point when it > > comes to Sun APIs. > > > > musachy > > > > On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> > wrote: > >> I'd suggest using Guice trunk and the JSR annotations rather than the > Guice annotations. I'd also make the injector pluggable so that people can > plug in Spring/Guice/etc easily. > >> > >> -bp > >> > >> > >> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: > >> > >>> I have talked to a couple of people before and everyone seems to agree > >>> that using guice instead of our internal IoC container (guice pre 1.0 > >>> I think), would be a good idea. I don't have any experience with guice > >>> 2.0, but looking at the docs it seems like porting our stuff would not > >>> be that hard. Less code to maintain, and we get more > >>> features/improvements. If we go with this idea, guice would be shaded > >>> into xwork to avoid classpath conflicts. > >>> > >>> what do you think? > >>> > >>> musachy > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > >>> For additional commands, e-mail: dev-help@struts.apache.org > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > >> For additional commands, e-mail: dev-help@struts.apache.org > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > > For additional commands, e-mail: dev-help@struts.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > >
They'll be part of the Guice distribution and under ASLv2 since Guice uses that.
The real question is how to setup the Injector's. I tend to think this layout would be best:
Base
|
|
_________
| |
| |
Struts App
The Base injector will contain the JEE objects (request, response, etc.) and any Struts objects
that can be used by the application. The Struts injector will contain all of the private objects
that should not be accessible to the application. The App injector will contain all the application
objects like Actions and such.
-bp
On Dec 1, 2009, at 10:59 AM, Musachy Barroso wrote:
> good point Brian, that has came up also. I have a couple of concerns
> about it, like what is the status of the jsr and will the API
> (annotations) will be under a decent (read ASF compatible license)
> license and in maven central? which is usually a pain point when it
> comes to Sun APIs.
>
> musachy
>
> On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> wrote:
>> I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations.
I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily.
>>
>> -bp
>>
>>
>> On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote:
>>
>>> I have talked to a couple of people before and everyone seems to agree
>>> that using guice instead of our internal IoC container (guice pre 1.0
>>> I think), would be a good idea. I don't have any experience with guice
>>> 2.0, but looking at the docs it seems like porting our stuff would not
>>> be that hard. Less code to maintain, and we get more
>>> features/improvements. If we go with this idea, guice would be shaded
>>> into xwork to avoid classpath conflicts.
>>>
>>> what do you think?
>>>
>>> musachy
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>>> For additional commands, e-mail: dev-help@struts.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
>> For additional commands, e-mail: dev-help@struts.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
> For additional commands, e-mail: dev-help@struts.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org
For additional commands, e-mail: dev-help@struts.apache.org
good point Brian, that has came up also. I have a couple of concerns about it, like what is the status of the jsr and will the API (annotations) will be under a decent (read ASF compatible license) license and in maven central? which is usually a pain point when it comes to Sun APIs. musachy On Tue, Dec 1, 2009 at 9:54 AM, Brian Pontarelli <brian@pontarelli.com> wrote: > I'd suggest using Guice trunk and the JSR annotations rather than the Guice annotations. I'd also make the injector pluggable so that people can plug in Spring/Guice/etc easily. > > -bp > > > On Dec 1, 2009, at 10:33 AM, Musachy Barroso wrote: > >> I have talked to a couple of people before and everyone seems to agree >> that using guice instead of our internal IoC container (guice pre 1.0 >> I think), would be a good idea. I don't have any experience with guice >> 2.0, but looking at the docs it seems like porting our stuff would not >> be that hard. Less code to maintain, and we get more >> features/improvements. If we go with this idea, guice would be shaded >> into xwork to avoid classpath conflicts. >> >> what do you think? >> >> musachy >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org >> For additional commands, e-mail: dev-help@struts.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
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
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
supposedly this is located on an apache server .. did you check all the mirrors? if you can tell me where you pushed the docs i could contact the admin do you have a backup bruce? Martin Gainty ______________________________________________ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: wsmoak@gmail.com > Date: Mon, 30 Nov 2009 15:27:18 -0700 > Subject: Re: Request Rights To New Struts 2 Documentation Wiki > To: dev@struts.apache.org > > On Mon, Nov 30, 2009 at 3:22 PM, phillips1021 <bphillips@ku.edu> wrote: > > > Now that I know what I had done is lost for good, I'll try to create those > > wiki pages again. > > With the old wiki we would get the equivalent of an 'svn diff' in > email for every change. Is there anything like that for Confluence > that might have the text that was lost? > > -- > Wendy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org > For additional commands, e-mail: dev-help@struts.apache.org > _________________________________________________________________ Hotmail: Trusted email with powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141665/direct/01/
call me paranoid, but a server called "Brutus" cannot be trusted :) musachy On Mon, Nov 30, 2009 at 2:00 PM, Wes Wannemacher <wesw@wantii.com> wrote: > Bruce, > > Just got an email that the Confluence database had a brief period of > data loss between the 26th and 27th. Apparently, a database restore > that was meant for one database, restored all databases... Seems like > your problem was just a one-off occurrence and shouldn't happen again. > > -Wes > > On Sun, Nov 29, 2009 at 5:58 PM, phillips1021 <bphillips@ku.edu> wrote: >> >> Yes - I added two links on that page and then added a page for one of the >> links (Struts 2 filter in web.xml). >> >> I also added content for the constants page. >> >> If that data's gone, then I'll try to re-add that information again. >> >> Bruce >> >> Musachy Barroso wrote: >>> >>> that is kind of weird, web.xml page does not exists yet: >>> >>> http://cwiki.apache.org/confluence/pages/createpage.action?spaceKey=S2NewDocDraft&title=web.xml&linkCreation=true&fromPageId=5964660 >>> >>> is that the one you edited? >>> >>> On Sun, Nov 29, 2009 at 12:06 PM, phillips1021 <bphillips@ku.edu> wrote: >>>> >>>> In the new space. >>>> >>>> I changed web.xml, added two new pages under web.xml, and constants.xml. >>>> >>>> I know I saved them because I went back later in the day and did a few >>>> more >>>> edits. >>>> >>>> Bruce >>>> >>>> did you make changes in the new space or the current doc space? what >>>> pages did you change? >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://old.nabble.com/Request-Rights-To-New-Struts-2-Documentation-Wiki-tp26372987p26565501.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 >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> 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/Request-Rights-To-New-Struts-2-Documentation-Wiki-tp26372987p26567292.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 >> >> > > > > -- > 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
On Mon, Nov 30, 2009 at 3:22 PM, phillips1021 <bphillips@ku.edu> wrote: > Now that I know what I had done is lost for good, I'll try to create those > wiki pages again. With the old wiki we would get the equivalent of an 'svn diff' in email for every change. Is there anything like that for Confluence that might have the text that was lost? -- Wendy --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@struts.apache.org For additional commands, e-mail: dev-help@struts.apache.org
Wes - thanks for the note. I lost quite a bit of work then as those were the days I added the new pages. Now that I know what I had done is lost for good, I'll try to create those wiki pages again. Bruce Bruce, Just got an email that the Confluence database had a brief period of data loss between the 26th and 27th. Apparently, a database restore that was meant for one database, restored all databases... Seems like your problem was just a one-off occurrence and shouldn't happen again. -Wes -- View this message in context: http://old.nabble.com/Request-Rights-To-New-Struts-2-Documentation-Wiki-tp26372987p26583107.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