Re: ognl 2.7.3 performance
2009/11/3 Musachy Barroso : > I think I saw it in someone's blog but now I can't find it..did I make > this up? Anyway, I am out of pet projects, so I might just play with a > UEL plugin :) Is it really necessary? Isn't it possible to let EL be used by the container? In Tiles, in JSP support module, we solved the problem using two separated attributes, one for the expression (in OGNL, MVEL and EL [interpreted at Tiles-side]) and one for the value, that can be put either with a string value or with an EL expression. Antonio - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
We also have FreeMarker , Velocity and we have a lot of expression evaluations from Struts code itself. musachy On Tue, Nov 3, 2009 at 12:29 AM, Antonio Petrelli wrote: > 2009/11/3 Musachy Barroso : >> I think I saw it in someone's blog but now I can't find it..did I make >> this up? Anyway, I am out of pet projects, so I might just play with a >> UEL plugin :) > > Is it really necessary? Isn't it possible to let EL be used by the container? > In Tiles, in JSP support module, we solved the problem using two > separated attributes, one for the expression (in OGNL, MVEL and EL > [interpreted at Tiles-side]) and one for the value, that can be put > either with a string value or with an EL expression. > > Antonio > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
2009/11/3 Musachy Barroso : > We also have FreeMarker , Velocity and we have a lot of expression > evaluations from Struts code itself. And in this case you're right, EL at Struts-side is obligatory. But exactly, is a bad idea to use the capability of the container to resolve EL expressions into values? This is just an idea. Antonio - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
I still think that the simplest approach is still to do nothing except for EL and let the view technology do it all (JSP, FTL, VM, etc.). The only time you need anything remotely similar to EL is for getting and setting values out of beans. This is generally not EL handling, but basic JavaBean handling. This topic has come up so many times and I still feel it is a major barrier to entry for Struts. -bp On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote: Well yes, that's by default, but with the new EL api you can plugin a new EL resolver like: JspApplicationContext jspApplicationContext = JspFactory.getDefaultFactory().getJspApplicationContext (servletContext); jspApplicationContext.addELResolver(new CompoundRootELResolver()); and the container will delegate to that resolver. BTW the JUEL plugin is in better shape than I thought, Tom are you out there? musachy On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli wrote: 2009/11/3 Antonio Petrelli : 2009/11/3 Musachy Barroso : We also have FreeMarker , Velocity and we have a lot of expression evaluations from Struts code itself. And in this case you're right, EL at Struts-side is obligatory. But exactly, is a bad idea to use the capability of the container to resolve EL expressions into values? This is just an idea. Another thing, sorry for the noise :-D If EL Expressions are interpreted Struts-side, this means that in JSP tags the attributes that represent expressions should not be "rtexpr" activated. This means that they might not have an expression, so you cannot write: because it is not interpreted as a string, but as an expression illegally placed. So you should do funny things, like string composition, to let it work. Antonio - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
That would be ok except for one thing: the value stack. To support the value stack in those view technologies is the problem. I have tried so many things, and failed in all of them that it is lame. I will finally merge my parameters-binder branch in xwork into trunk, and see if I can get some folks to look at it. With the parameters problem solved, the rest is not *that* hard. On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli wrote: > I still think that the simplest approach is still to do nothing except for > EL and let the view technology do it all (JSP, FTL, VM, etc.). The only time > you need anything remotely similar to EL is for getting and setting values > out of beans. This is generally not EL handling, but basic JavaBean > handling. This topic has come up so many times and I still feel it is a > major barrier to entry for Struts. > > -bp > > > On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote: > >> Well yes, that's by default, but with the new EL api you can plugin a >> new EL resolver like: >> >> JspApplicationContext jspApplicationContext = >> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext); >> jspApplicationContext.addELResolver(new CompoundRootELResolver()); >> >> and the container will delegate to that resolver. BTW the JUEL plugin >> is in better shape than I thought, Tom are you out there? >> >> musachy >> >> On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli >> wrote: >>> >>> 2009/11/3 Antonio Petrelli : 2009/11/3 Musachy Barroso : > > We also have FreeMarker , Velocity and we have a lot of expression > evaluations from Struts code itself. And in this case you're right, EL at Struts-side is obligatory. But exactly, is a bad idea to use the capability of the container to resolve EL expressions into values? This is just an idea. >>> >>> Another thing, sorry for the noise :-D >>> >>> If EL Expressions are interpreted Struts-side, this means that in JSP >>> tags the attributes that represent expressions should not be "rtexpr" >>> activated. >>> This means that they might not have an expression, so you cannot write: >>> >>> because it is not interpreted as a string, but as an expression >>> illegally placed. >>> So you should do funny things, like string composition, to let it work. >>> >>> Antonio >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
It's been a while, but that is really more of an current action stack (I call it the ActionInvocation stack). I recall that I was able to get most of the functionality I needed into JCatapult while still using the FTL/JSP expression languages. -bp On Nov 3, 2009, at 11:10 AM, Musachy Barroso wrote: That would be ok except for one thing: the value stack. To support the value stack in those view technologies is the problem. I have tried so many things, and failed in all of them that it is lame. I will finally merge my parameters-binder branch in xwork into trunk, and see if I can get some folks to look at it. With the parameters problem solved, the rest is not *that* hard. On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli > wrote: I still think that the simplest approach is still to do nothing except for EL and let the view technology do it all (JSP, FTL, VM, etc.). The only time you need anything remotely similar to EL is for getting and setting values out of beans. This is generally not EL handling, but basic JavaBean handling. This topic has come up so many times and I still feel it is a major barrier to entry for Struts. -bp On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote: Well yes, that's by default, but with the new EL api you can plugin a new EL resolver like: JspApplicationContext jspApplicationContext = JspFactory.getDefaultFactory().getJspApplicationContext (servletContext); jspApplicationContext.addELResolver(new CompoundRootELResolver()); and the container will delegate to that resolver. BTW the JUEL plugin is in better shape than I thought, Tom are you out there? musachy On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli wrote: 2009/11/3 Antonio Petrelli : 2009/11/3 Musachy Barroso : We also have FreeMarker , Velocity and we have a lot of expression evaluations from Struts code itself. And in this case you're right, EL at Struts-side is obligatory. But exactly, is a bad idea to use the capability of the container to resolve EL expressions into values? This is just an idea. Another thing, sorry for the noise :-D If EL Expressions are interpreted Struts-side, this means that in JSP tags the attributes that represent expressions should not be "rtexpr" activated. This means that they might not have an expression, so you cannot write: because it is not interpreted as a string, but as an expression illegally placed. So you should do funny things, like string composition, to let it work. Antonio - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: ognl 2.7.3 performance
The parameters binder branch is now merged into xwork trunk (manual merge thanks to svn being a PITA)(for those unaware, this contains some experimental code to set parameters in the actions without using OGNL directly, it is faster, and more secure) . Now we can start playing with other ELs seriously. musachy On Tue, Nov 3, 2009 at 10:20 AM, Brian Pontarelli wrote: > It's been a while, but that is really more of an current action stack (I > call it the ActionInvocation stack). I recall that I was able to get most of > the functionality I needed into JCatapult while still using the FTL/JSP > expression languages. > > -bp > > > On Nov 3, 2009, at 11:10 AM, Musachy Barroso wrote: > >> That would be ok except for one thing: the value stack. To support the >> value stack in those view technologies is the problem. I have tried so >> many things, and failed in all of them that it is lame. I will finally >> merge my parameters-binder branch in xwork into trunk, and see if I >> can get some folks to look at it. With the parameters problem solved, >> the rest is not *that* hard. >> >> On Tue, Nov 3, 2009 at 10:00 AM, Brian Pontarelli >> wrote: >>> >>> I still think that the simplest approach is still to do nothing except >>> for >>> EL and let the view technology do it all (JSP, FTL, VM, etc.). The only >>> time >>> you need anything remotely similar to EL is for getting and setting >>> values >>> out of beans. This is generally not EL handling, but basic JavaBean >>> handling. This topic has come up so many times and I still feel it is a >>> major barrier to entry for Struts. >>> >>> -bp >>> >>> >>> On Nov 3, 2009, at 10:22 AM, Musachy Barroso wrote: >>> Well yes, that's by default, but with the new EL api you can plugin a new EL resolver like: JspApplicationContext jspApplicationContext = JspFactory.getDefaultFactory().getJspApplicationContext(servletContext); jspApplicationContext.addELResolver(new CompoundRootELResolver()); and the container will delegate to that resolver. BTW the JUEL plugin is in better shape than I thought, Tom are you out there? musachy On Tue, Nov 3, 2009 at 8:55 AM, Antonio Petrelli wrote: > > 2009/11/3 Antonio Petrelli : >> >> 2009/11/3 Musachy Barroso : >>> >>> We also have FreeMarker , Velocity and we have a lot of expression >>> evaluations from Struts code itself. >> >> And in this case you're right, EL at Struts-side is obligatory. >> But exactly, is a bad idea to use the capability of the container to >> resolve EL expressions into values? >> This is just an idea. > > Another thing, sorry for the noise :-D > > If EL Expressions are interpreted Struts-side, this means that in JSP > tags the attributes that represent expressions should not be "rtexpr" > activated. > This means that they might not have an expression, so you cannot write: > > because it is not interpreted as a string, but as an expression > illegally placed. > So you should do funny things, like string composition, to let it work. > > Antonio > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> > > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
what he meant was: we are too lazy to maintain code in 2 different repositories :) musachy On Tue, Nov 3, 2009 at 1:40 PM, Wes Wannemacher wrote: > Heh, it was my idea to make it a proper, built-in result type... But, > my motivation for this was that plugins shouldn't depend on other > plugins. I was planning the JQuery plugin in my mind and I wanted > proper support for JSON. Since it was not only a plugin, but an > external plugin, using JSON in a JQuery plugin would have been a bad > example to set. However, we added the ability to specify a > 'load-order' in the struts-plugin.xml file (hence the change to the > DTD between 2.1.6 and 2.1.7). This way, plugins can be guaranteed to > have their configuration loaded before other plugins. The loading > problem was the reason why it was considered a bad practice to have > plugins depend on each other. > > We ended up bringing it over to Apache space for different reasons... > 1 - Musachy wrote it (and I think I might have helped, I can't > remember), he was the most active on it. 2 - The version numbers were > confusing (jsonplugin @ googlecode was version 0.33 IIRC). 3 - If we > changed the Struts APIs, we could break the JSON plugin and Musachy > and I had a tendency to forget to keep the plugin up to date. And, 4 - > It now gets pushed out to the maven repositories. > > -Wes > > On Tue, Nov 3, 2009 at 4:31 PM, Chris Pratt wrote: >> What happened to the whole decision to bring JSON into the core? Is it true >> that all that was done was to move the link from a Google Code URL to a >> harder to find Apache URL? That's not the discussion I remember... >> (*Chris*) >> >> On Tue, Nov 3, 2009 at 1:25 PM, Wes Wannemacher wrote: >> >>> No, Chris, it's definitely still a plugin... >>> >>> David, download the jar from here - >>> >>> http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/ >>> >>> -Wes >>> >>> On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt >>> wrote: >>> > From what I understand, it's no longer a plugin, it's part of the base >>> > Struts functionality. You don't have to do anything extra. All you have >>> to >>> > do is define your result type to be json and struts will know what you >>> mean. >>> > (*Chris*) >>> > >>> > On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks >>> wrote: >>> > >>> >> OK. I removed the original GoogleCode dependency from my project, but >>> >> now it doesn't appear to find *any* such plugin. It's unclear to me >>> >> where the JSON Plugin is located within the Struts framework and how to >>> >> get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that >>> >> doesn't appear to exist in the staging repository with the rest of the >>> >> framework. I'm sure I'm just missing some little tid-bit of >>> information. >>> >> >>> >> Thanks, >>> >> Dave >>> >> >>> >> >>> >> Musachy Barroso wrote: >>> >> > The package name is the same, but the plugin jar is now bundled with >>> s2. >>> >> > >>> >> > musachy >>> >> > >>> >> > On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks >>> >> wrote: >>> >> > >>> >> >> Wes, is this new plugin referenced in a new struts package type? >>> That >>> >> >> seems to be where I'm getting the GoogleCode plugin from. My package >>> >> >> extends "json-default", and, as far as I can tell, this is where the >>> >> >> plugin itself is referenced. >>> >> >> >>> >> >> Thanks again! >>> >> >> Dave >>> >> >> >>> >> >> Wes Wannemacher wrote: >>> >> >> >>> >> >>> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll >>> >> >>> find a struts2-json-plugin in there. It's a port of the one on >>> >> >>> googlecode, so it should be a compatible replacement (a few package >>> >> >>> names changed, but that should be easy to sort out). >>> >> >>> >>> >> >>> -Wes >>> >> >>> >>> >> >>> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks >>> >> wrote: >>> >> >>> >>> >> >>> >>> >> I've been trying to build our application using the 2.1.8.1 >>> candidate. >>> >> There was an older bug that we needed the fix for. That problem >>> seems >>> >> to be resolved. However, I find that the JSONPlugin for Struts >>> from >>> >> Googlecode is broken due to an upgrade of the XWork2 framework. >>> There >>> >> is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin >>> >> relied on that is now gone, apparently. I was wondering if anyone >>> >> knew >>> >> of a workaround for this (or maybe this is just a new, unknown >>> >> problem?). The current version of jsonplugin is 0.34, I believe. >>> >> >>> >> >>> >> com.googlecode >>> >> jsonplugin >>> >> 0.34 >>> >> >>> >> >>> >> Any help is appreciated. >>> >> Thanks, >>> >> Dave >>> >> >>> >> PS - in case it helps, here is a small snippet of stack trace... >>> >> >>> >> java.lang.NoClassDefFoundError: >>> com/opensymphony/xwork2/util/TextUtils >>> >
Re: JSONPlugin breaks in 2.1.8.1
That was the magic jar. Thanks! Wes Wannemacher wrote: > No, Chris, it's definitely still a plugin... > > David, download the jar from here - > > http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/ > > -Wes > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
OK. I removed the original GoogleCode dependency from my project, but now it doesn't appear to find *any* such plugin. It's unclear to me where the JSON Plugin is located within the Struts framework and how to get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that doesn't appear to exist in the staging repository with the rest of the framework. I'm sure I'm just missing some little tid-bit of information. Thanks, Dave Musachy Barroso wrote: > The package name is the same, but the plugin jar is now bundled with s2. > > musachy > > On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks wrote: > >> Wes, is this new plugin referenced in a new struts package type? That >> seems to be where I'm getting the GoogleCode plugin from. My package >> extends "json-default", and, as far as I can tell, this is where the >> plugin itself is referenced. >> >> Thanks again! >> Dave >> >> Wes Wannemacher wrote: >> >>> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll >>> find a struts2-json-plugin in there. It's a port of the one on >>> googlecode, so it should be a compatible replacement (a few package >>> names changed, but that should be easy to sort out). >>> >>> -Wes >>> >>> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks wrote: >>> >>> I've been trying to build our application using the 2.1.8.1 candidate. There was an older bug that we needed the fix for. That problem seems to be resolved. However, I find that the JSONPlugin for Struts from Googlecode is broken due to an upgrade of the XWork2 framework. There is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin relied on that is now gone, apparently. I was wondering if anyone knew of a workaround for this (or maybe this is just a new, unknown problem?). The current version of jsonplugin is 0.34, I believe. com.googlecode jsonplugin 0.34 Any help is appreciated. Thanks, Dave PS - in case it helps, here is a small snippet of stack trace... java.lang.NoClassDefFoundError: com/opensymphony/xwork2/util/TextUtils at com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) at com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) at com.googlecode.jsonplugin.JSONResult.execute(JSONResult.java:184) at com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266) at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165) at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252) 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:237) 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:237) 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:237) at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:179) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:94) at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:235) - To unsubscribe, e-mail: dev-unsubscr..
Re: Amf and amfx support.
The patch seems to be missing in your mail, maybe you want to open a JIRA ticket and attach the patch to it. - René ashish mahamuni schrieb: > Hi there, > > I've created the patch on struts-2.1.8 stable build. > Also, attached the added files with this mail. > Please, have it reviewed and if suitable commit it. I've tested this and its > working fine. > > Regards, > Ashish Mahamuni > > --- On Wed, 28/10/09, Musachy Barroso wrote: > >> From: Musachy Barroso >> Subject: Re: Amf and amfx support. >> To: "Struts Developers List" >> Date: Wednesday, 28 October, 2009, 10:04 PM >> you can always start by creating your >> own plugin. >> >> musachy >> >> On Wed, Oct 28, 2009 at 8:32 AM, ashish mahamuni >> >> wrote: >>> Hi there, >>> >>> I've been working on amf and amfx extension support >> in REST >>> plugin. >>> These are Adobe specific extensions. >>> >>> I've managed to write two more handlers, which uses >> the >>> blazds apis. >>> >>> I want to add this in source code. >>> >>> Do you guys believes its worth to contribute? >>> >>> Regards, >>> Ashish >>> >>> >>> >> - >>> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >>> For additional commands, e-mail: dev-h...@struts.apache.org >>> >>> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> >> >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org -- René Gielen IT-Neering.net Saarstrasse 100, 52062 Aachen, Germany Tel: +49-(0)241-4010770 Fax: +49-(0)241-4010771 Cel: +49-(0)177-3194448 http://twitter.com/rgielen - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
>From what I understand, it's no longer a plugin, it's part of the base Struts functionality. You don't have to do anything extra. All you have to do is define your result type to be json and struts will know what you mean. (*Chris*) On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks wrote: > OK. I removed the original GoogleCode dependency from my project, but > now it doesn't appear to find *any* such plugin. It's unclear to me > where the JSON Plugin is located within the Struts framework and how to > get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that > doesn't appear to exist in the staging repository with the rest of the > framework. I'm sure I'm just missing some little tid-bit of information. > > Thanks, > Dave > > > Musachy Barroso wrote: > > The package name is the same, but the plugin jar is now bundled with s2. > > > > musachy > > > > On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks > wrote: > > > >> Wes, is this new plugin referenced in a new struts package type? That > >> seems to be where I'm getting the GoogleCode plugin from. My package > >> extends "json-default", and, as far as I can tell, this is where the > >> plugin itself is referenced. > >> > >> Thanks again! > >> Dave > >> > >> Wes Wannemacher wrote: > >> > >>> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll > >>> find a struts2-json-plugin in there. It's a port of the one on > >>> googlecode, so it should be a compatible replacement (a few package > >>> names changed, but that should be easy to sort out). > >>> > >>> -Wes > >>> > >>> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks > wrote: > >>> > >>> > I've been trying to build our application using the 2.1.8.1 candidate. > There was an older bug that we needed the fix for. That problem seems > to be resolved. However, I find that the JSONPlugin for Struts from > Googlecode is broken due to an upgrade of the XWork2 framework. There > is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin > relied on that is now gone, apparently. I was wondering if anyone > knew > of a workaround for this (or maybe this is just a new, unknown > problem?). The current version of jsonplugin is 0.34, I believe. > > > com.googlecode > jsonplugin > 0.34 > > > Any help is appreciated. > Thanks, > Dave > > PS - in case it helps, here is a small snippet of stack trace... > > java.lang.NoClassDefFoundError: com/opensymphony/xwork2/util/TextUtils > at > > com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) > at > > com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) > at > com.googlecode.jsonplugin.JSONResult.execute(JSONResult.java:184) > at > > com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362) > at > > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266) > at > > com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165) > at > > com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) > at > > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) > at > > com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252) > 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:237) > 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:237) > 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:237) > at > > com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:179) > at > > com.opensymphony.xwork2.Defaul
Re: [VOTE] Struts 2.1.8.1 Vote
+1 GA (binding) Wes Wannemacher schrieb: > The Struts 2.1.8 test build is now available. > > Release notes: > * [http://cwiki.apache.org/confluence/display/WW/Version+Notes+2.1.8.1] > > Distribution: > * [http://people.apache.org/builds/struts/2.1.8.1/] > > Maven 2 staging repository: > * [http://people.apache.org/builds/struts/2.1.8.1/m2-staging-repository/] > > Once you have had a chance to review the test build, please respond > with a vote on its quality: > > [ ] Leave at test build > [ ] Alpha > [ ] Beta > [ ] General Availability (GA) > > Everyone who has tested the build is invited to vote. Votes by PMC > members are considered binding. A vote passes if there are at least > three binding +1s and more +1s than -1s. > > The vote will remain open for at least 72 hours, longer upon request. > A vote can be amended at any time to upgrade or downgrade the quality > of the release based on future experience. If an initial vote > designates the build as "Beta", the release will be submitted for > mirroring and announced to the user list. Once released as a public > beta, subsequent quality votes on a build may be held on the user > list. > > As always, the act of voting carries certain obligations. A binding > vote not only states an opinion, but means that the voter is agreeing > to help do the work > > In addition to the normal info above, I also want to add that I made > the distro available for easy testing through the struts zone. If you > point your browser here - > > http://struts.zones.apache.org/ > > You can test our reference apps on both tomcat and jetty. > > Thanks for your help! > > -Wes > > -- > Wes Wannemacher > > Head Engineer, WanTii, Inc. > Need Training? Struts, Spring, Maven, Tomcat... > Ask me for a quote! > > - > To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org > For additional commands, e-mail: dev-h...@struts.apache.org > -- René Gielen IT-Neering.net Saarstrasse 100, 52062 Aachen, Germany Tel: +49-(0)241-4010770 Fax: +49-(0)241-4010771 Cel: +49-(0)177-3194448 http://twitter.com/rgielen - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
What happened to the whole decision to bring JSON into the core? Is it true that all that was done was to move the link from a Google Code URL to a harder to find Apache URL? That's not the discussion I remember... (*Chris*) On Tue, Nov 3, 2009 at 1:25 PM, Wes Wannemacher wrote: > No, Chris, it's definitely still a plugin... > > David, download the jar from here - > > http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/ > > -Wes > > On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt > wrote: > > From what I understand, it's no longer a plugin, it's part of the base > > Struts functionality. You don't have to do anything extra. All you have > to > > do is define your result type to be json and struts will know what you > mean. > > (*Chris*) > > > > On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks > wrote: > > > >> OK. I removed the original GoogleCode dependency from my project, but > >> now it doesn't appear to find *any* such plugin. It's unclear to me > >> where the JSON Plugin is located within the Struts framework and how to > >> get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that > >> doesn't appear to exist in the staging repository with the rest of the > >> framework. I'm sure I'm just missing some little tid-bit of > information. > >> > >> Thanks, > >> Dave > >> > >> > >> Musachy Barroso wrote: > >> > The package name is the same, but the plugin jar is now bundled with > s2. > >> > > >> > musachy > >> > > >> > On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks > >> wrote: > >> > > >> >> Wes, is this new plugin referenced in a new struts package type? > That > >> >> seems to be where I'm getting the GoogleCode plugin from. My package > >> >> extends "json-default", and, as far as I can tell, this is where the > >> >> plugin itself is referenced. > >> >> > >> >> Thanks again! > >> >> Dave > >> >> > >> >> Wes Wannemacher wrote: > >> >> > >> >>> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll > >> >>> find a struts2-json-plugin in there. It's a port of the one on > >> >>> googlecode, so it should be a compatible replacement (a few package > >> >>> names changed, but that should be easy to sort out). > >> >>> > >> >>> -Wes > >> >>> > >> >>> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks > >> wrote: > >> >>> > >> >>> > >> I've been trying to build our application using the 2.1.8.1 > candidate. > >> There was an older bug that we needed the fix for. That problem > seems > >> to be resolved. However, I find that the JSONPlugin for Struts > from > >> Googlecode is broken due to an upgrade of the XWork2 framework. > There > >> is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin > >> relied on that is now gone, apparently. I was wondering if anyone > >> knew > >> of a workaround for this (or maybe this is just a new, unknown > >> problem?). The current version of jsonplugin is 0.34, I believe. > >> > >> > >> com.googlecode > >> jsonplugin > >> 0.34 > >> > >> > >> Any help is appreciated. > >> Thanks, > >> Dave > >> > >> PS - in case it helps, here is a small snippet of stack trace... > >> > >> java.lang.NoClassDefFoundError: > com/opensymphony/xwork2/util/TextUtils > >> at > >> > >> > com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) > >> at > >> > >> > com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) > >> at > >> com.googlecode.jsonplugin.JSONResult.execute(JSONResult.java:184) > >> at > >> > >> > com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362) > >> at > >> > >> > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266) > >> at > >> > >> > com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165) > >> at > >> > >> > com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) > >> at > >> > >> > com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) > >> at > >> > >> > com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252) > >> 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:237) > >> at > >> > >> > com.opensymphony.xwo
Re: JSONPlugin breaks in 2.1.8.1
Musachy Barroso wrote: > what he meant was: we are too lazy to maintain code in 2 different > repositories :) > Can't say I blame you. Makes sense to me to have it all in one place, anyway. Great work, by the way! 2.1.8.1 seems to be pretty solid. - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
Thanks, Wes! Wes Wannemacher wrote: > No, Chris, it's definitely still a plugin... > > David, download the jar from here - > > http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/ > > -Wes > > On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt wrote: > >> From what I understand, it's no longer a plugin, it's part of the base >> Struts functionality. You don't have to do anything extra. All you have to >> do is define your result type to be json and struts will know what you mean. >> (*Chris*) >> >> On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks wrote: >> >> >>> OK. I removed the original GoogleCode dependency from my project, but >>> now it doesn't appear to find *any* such plugin. It's unclear to me >>> where the JSON Plugin is located within the Struts framework and how to >>> get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that >>> doesn't appear to exist in the staging repository with the rest of the >>> framework. I'm sure I'm just missing some little tid-bit of information. >>> >>> Thanks, >>> Dave >>> >>> >>> Musachy Barroso wrote: >>> The package name is the same, but the plugin jar is now bundled with s2. musachy On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks >>> wrote: >>> > Wes, is this new plugin referenced in a new struts package type? That > seems to be where I'm getting the GoogleCode plugin from. My package > extends "json-default", and, as far as I can tell, this is where the > plugin itself is referenced. > > Thanks again! > Dave > > Wes Wannemacher wrote: > > >> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll >> find a struts2-json-plugin in there. It's a port of the one on >> googlecode, so it should be a compatible replacement (a few package >> names changed, but that should be easy to sort out). >> >> -Wes >> >> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks >> >>> wrote: >>> >> >>> I've been trying to build our application using the 2.1.8.1 candidate. >>> There was an older bug that we needed the fix for. That problem seems >>> to be resolved. However, I find that the JSONPlugin for Struts from >>> Googlecode is broken due to an upgrade of the XWork2 framework. There >>> is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin >>> relied on that is now gone, apparently. I was wondering if anyone >>> >>> knew >>> >>> of a workaround for this (or maybe this is just a new, unknown >>> problem?). The current version of jsonplugin is 0.34, I believe. >>> >>> >>>com.googlecode >>>jsonplugin >>>0.34 >>> >>> >>> Any help is appreciated. >>> Thanks, >>> Dave >>> >>> PS - in case it helps, here is a small snippet of stack trace... >>> >>> java.lang.NoClassDefFoundError: com/opensymphony/xwork2/util/TextUtils >>>at >>> >>> >>> com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) >>> >>>at >>> >>> >>> com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) >>> >>>at >>> >>> com.googlecode.jsonplugin.JSONResult.execute(JSONResult.java:184) >>> >>>at >>> >>> >>> com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362) >>> >>>at >>> >>> >>> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266) >>> >>>at >>> >>> >>> com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165) >>> >>>at >>> >>> >>> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) >>> >>>at >>> >>> >>> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) >>> >>>at >>> >>> >>> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252) >>> >>>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:237)
Re: JSONPlugin breaks in 2.1.8.1
Wes, is this new plugin referenced in a new struts package type? That seems to be where I'm getting the GoogleCode plugin from. My package extends "json-default", and, as far as I can tell, this is where the plugin itself is referenced. Thanks again! Dave Wes Wannemacher wrote: > We moved that plugin into Apache... Poke around the 2.1.8.1, you'll > find a struts2-json-plugin in there. It's a port of the one on > googlecode, so it should be a compatible replacement (a few package > names changed, but that should be easy to sort out). > > -Wes > > On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks wrote: > >> I've been trying to build our application using the 2.1.8.1 candidate. >> There was an older bug that we needed the fix for. That problem seems >> to be resolved. However, I find that the JSONPlugin for Struts from >> Googlecode is broken due to an upgrade of the XWork2 framework. There >> is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin >> relied on that is now gone, apparently. I was wondering if anyone knew >> of a workaround for this (or maybe this is just a new, unknown >> problem?). The current version of jsonplugin is 0.34, I believe. >> >> >>com.googlecode >>jsonplugin >>0.34 >> >> >> Any help is appreciated. >> Thanks, >> Dave >> >> PS - in case it helps, here is a small snippet of stack trace... >> >> java.lang.NoClassDefFoundError: com/opensymphony/xwork2/util/TextUtils >>at >> com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) >>at >> com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) >>at com.googlecode.jsonplugin.JSONResult.execute(JSONResult.java:184) >>at >> com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362) >>at >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266) >>at >> com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165) >>at >> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) >>at >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) >>at >> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252) >>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:237) >>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:237) >>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:237) >>at >> com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:179) >>at >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) >>at >> org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:94) >>at >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) >>at >> org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:235) >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org >> For additional commands, e-mail: dev-h...@struts.apache.org >> >> >> > > > > - To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
Heh, it was my idea to make it a proper, built-in result type... But, my motivation for this was that plugins shouldn't depend on other plugins. I was planning the JQuery plugin in my mind and I wanted proper support for JSON. Since it was not only a plugin, but an external plugin, using JSON in a JQuery plugin would have been a bad example to set. However, we added the ability to specify a 'load-order' in the struts-plugin.xml file (hence the change to the DTD between 2.1.6 and 2.1.7). This way, plugins can be guaranteed to have their configuration loaded before other plugins. The loading problem was the reason why it was considered a bad practice to have plugins depend on each other. We ended up bringing it over to Apache space for different reasons... 1 - Musachy wrote it (and I think I might have helped, I can't remember), he was the most active on it. 2 - The version numbers were confusing (jsonplugin @ googlecode was version 0.33 IIRC). 3 - If we changed the Struts APIs, we could break the JSON plugin and Musachy and I had a tendency to forget to keep the plugin up to date. And, 4 - It now gets pushed out to the maven repositories. -Wes On Tue, Nov 3, 2009 at 4:31 PM, Chris Pratt wrote: > What happened to the whole decision to bring JSON into the core? Is it true > that all that was done was to move the link from a Google Code URL to a > harder to find Apache URL? That's not the discussion I remember... > (*Chris*) > > On Tue, Nov 3, 2009 at 1:25 PM, Wes Wannemacher wrote: > >> No, Chris, it's definitely still a plugin... >> >> David, download the jar from here - >> >> http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/ >> >> -Wes >> >> On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt >> wrote: >> > From what I understand, it's no longer a plugin, it's part of the base >> > Struts functionality. You don't have to do anything extra. All you have >> to >> > do is define your result type to be json and struts will know what you >> mean. >> > (*Chris*) >> > >> > On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks >> wrote: >> > >> >> OK. I removed the original GoogleCode dependency from my project, but >> >> now it doesn't appear to find *any* such plugin. It's unclear to me >> >> where the JSON Plugin is located within the Struts framework and how to >> >> get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that >> >> doesn't appear to exist in the staging repository with the rest of the >> >> framework. I'm sure I'm just missing some little tid-bit of >> information. >> >> >> >> Thanks, >> >> Dave >> >> >> >> >> >> Musachy Barroso wrote: >> >> > The package name is the same, but the plugin jar is now bundled with >> s2. >> >> > >> >> > musachy >> >> > >> >> > On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks >> >> wrote: >> >> > >> >> >> Wes, is this new plugin referenced in a new struts package type? >> That >> >> >> seems to be where I'm getting the GoogleCode plugin from. My package >> >> >> extends "json-default", and, as far as I can tell, this is where the >> >> >> plugin itself is referenced. >> >> >> >> >> >> Thanks again! >> >> >> Dave >> >> >> >> >> >> Wes Wannemacher wrote: >> >> >> >> >> >>> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll >> >> >>> find a struts2-json-plugin in there. It's a port of the one on >> >> >>> googlecode, so it should be a compatible replacement (a few package >> >> >>> names changed, but that should be easy to sort out). >> >> >>> >> >> >>> -Wes >> >> >>> >> >> >>> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks >> >> wrote: >> >> >>> >> >> >>> >> >> I've been trying to build our application using the 2.1.8.1 >> candidate. >> >> There was an older bug that we needed the fix for. That problem >> seems >> >> to be resolved. However, I find that the JSONPlugin for Struts >> from >> >> Googlecode is broken due to an upgrade of the XWork2 framework. >> There >> >> is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin >> >> relied on that is now gone, apparently. I was wondering if anyone >> >> knew >> >> of a workaround for this (or maybe this is just a new, unknown >> >> problem?). The current version of jsonplugin is 0.34, I believe. >> >> >> >> >> >> com.googlecode >> >> jsonplugin >> >> 0.34 >> >> >> >> >> >> Any help is appreciated. >> >> Thanks, >> >> Dave >> >> >> >> PS - in case it helps, here is a small snippet of stack trace... >> >> >> >> java.lang.NoClassDefFoundError: >> com/opensymphony/xwork2/util/TextUtils >> >> at >> >> >> >> >> com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) >> >> at >> >> >> >> >> com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) >> >> at >> >> com.googlecode.jsonplugin.JSONResult
Re: ognl 2.7.3 performance
2009/11/3 Musachy Barroso :
> Well yes, that's by default, but with the new EL api you can plugin a
> new EL resolver like:
>
> JspApplicationContext jspApplicationContext =
> JspFactory.getDefaultFactory().getJspApplicationContext(servletContext);
> jspApplicationContext.addELResolver(new CompoundRootELResolver());
Maybe I did not explain myself.
In a JSP page, an expression of the type:
${something}
is treated as an expression. If you put such a string in a non-rtexpr
enabled attribute it will give you an error.
> BTW the JUEL plugin...
Leave JUEL and try Tomcat's EL like I did in tiles:
https://svn.eu.apache.org/repos/asf/tiles/framework/trunk/tiles-el
(notice that currently SVN seems down).
You can even load the default container EL implementation.
Take a look in particular at the configuration, because the EL API is
got from java.net repository, and the implementation from Tomcat.
HTH
Antonio
-
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
Re: JSONPlugin breaks in 2.1.8.1
No, Chris, it's definitely still a plugin... David, download the jar from here - http://repo1.maven.org/maven2/org/apache/struts/struts2-json-plugin/2.1.8/ -Wes On Tue, Nov 3, 2009 at 4:23 PM, Chris Pratt wrote: > From what I understand, it's no longer a plugin, it's part of the base > Struts functionality. You don't have to do anything extra. All you have to > do is define your result type to be json and struts will know what you mean. > (*Chris*) > > On Tue, Nov 3, 2009 at 1:17 PM, David C. Hicks wrote: > >> OK. I removed the original GoogleCode dependency from my project, but >> now it doesn't appear to find *any* such plugin. It's unclear to me >> where the JSON Plugin is located within the Struts framework and how to >> get it, now. I tried adding the struts2-plugins 2.1.8.1 jar, but that >> doesn't appear to exist in the staging repository with the rest of the >> framework. I'm sure I'm just missing some little tid-bit of information. >> >> Thanks, >> Dave >> >> >> Musachy Barroso wrote: >> > The package name is the same, but the plugin jar is now bundled with s2. >> > >> > musachy >> > >> > On Tue, Nov 3, 2009 at 11:59 AM, David C. Hicks >> wrote: >> > >> >> Wes, is this new plugin referenced in a new struts package type? That >> >> seems to be where I'm getting the GoogleCode plugin from. My package >> >> extends "json-default", and, as far as I can tell, this is where the >> >> plugin itself is referenced. >> >> >> >> Thanks again! >> >> Dave >> >> >> >> Wes Wannemacher wrote: >> >> >> >>> We moved that plugin into Apache... Poke around the 2.1.8.1, you'll >> >>> find a struts2-json-plugin in there. It's a port of the one on >> >>> googlecode, so it should be a compatible replacement (a few package >> >>> names changed, but that should be easy to sort out). >> >>> >> >>> -Wes >> >>> >> >>> On Mon, Nov 2, 2009 at 4:54 PM, David C. Hicks >> wrote: >> >>> >> >>> >> I've been trying to build our application using the 2.1.8.1 candidate. >> There was an older bug that we needed the fix for. That problem seems >> to be resolved. However, I find that the JSONPlugin for Struts from >> Googlecode is broken due to an upgrade of the XWork2 framework. There >> is a class (com.opensymphony.xwork2.util.TextUtils) that jsonplugin >> relied on that is now gone, apparently. I was wondering if anyone >> knew >> of a workaround for this (or maybe this is just a new, unknown >> problem?). The current version of jsonplugin is 0.34, I believe. >> >> >> com.googlecode >> jsonplugin >> 0.34 >> >> >> Any help is appreciated. >> Thanks, >> Dave >> >> PS - in case it helps, here is a small snippet of stack trace... >> >> java.lang.NoClassDefFoundError: com/opensymphony/xwork2/util/TextUtils >> at >> >> com.googlecode.jsonplugin.SerializationParams.(SerializationParams.java:38) >> at >> >> com.googlecode.jsonplugin.JSONResult.writeToResponse(JSONResult.java:194) >> at >> com.googlecode.jsonplugin.JSONResult.execute(JSONResult.java:184) >> at >> >> com.opensymphony.xwork2.DefaultActionInvocation.executeResult(DefaultActionInvocation.java:362) >> at >> >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:266) >> at >> >> com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165) >> at >> >> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87) >> at >> >> com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237) >> at >> >> com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252) >> 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:237) >> 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:237) >> at >> >> com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195) >> at >> >> com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(Me
