Re: Problems with Tiles 2 and WS 5
Stone, Sam ha scritto: 1) changed all my tiles-defs to use tiles-config_2_0.dtd instead of 1.1 I hope you validated the XML file, did you? 2) changed all my tiles:insert statements to tiles:insertDefinition That's wrong, you have to change in or or . Ciao Antonio - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [1.3] Is there any "init" method for a Command based requestProcessor
This seems to be required anyway as Spring integration to struts uses a per (struts) module application context. 2006/12/18, Niall Pemberton <[EMAIL PROTECTED]>: On 12/18/06, nicolas de loof <[EMAIL PROTECTED]> wrote: > Hello, > > I'm trying to create a custom "CreateAction" command to be plugged in the > CoR RequestProcessor of Struts 1.3 > This command will handle Spring autowiring of commands, but requires > initiali acces to the servletContext to get the Spring > WebApplicationContext. > > I can make this "init" from the first command execution based on > ServletActionContext, but I would find better to make this init on time for > every commands invocation. > > Is there any support for such an init process ? There isn't - but why not just look up the spring WebApplicationContext each time? Niall > Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I double dare you :) Don Brown wrote: Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on "expressions" in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an "enemy project" but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and "interceptors" to deal with tag objects, not pure text - Tag "interceptors" or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive.
Re: OGNL performance detrimental to Struts 2
Well, I dare you then: http://issues.apache.org/struts/browse/WW-1566 :) Don Chris Brock wrote: Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on "expressions" in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an "enemy project" but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and "interceptors" to deal with tag objects, not pure text - Tag "interceptors" or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive.
Re: OGNL performance detrimental to Struts 2
Don't dare me. I'm pretty ambitious. I wrote MVEL 1.0 in three days. Don Brown-2 wrote: > > I'd like it to be possible for a Struts developer to swap in a new EL, > perhaps MVEL, if they didn't like OGNL for some reason. If you can > create a patch to make that happen, I would consider it my early > Christmas present :) > > Don > > Chris Brock wrote: >> Why do you think it would be so terribly difficult? What does MVEL not >> support that is currently supported by OGNL that would not be fixable by >> a >> few tweaks to MVEL's syntax? >> >> Generally, MVEL's API architecture follows the same pattern as OGNL, >> supports type coercion, conversion, projections, etc. >> >> Not to mention that MVEL is now an active project and OGNL is not, and of >> course the performance advantage in MVEL which is only getting better by >> the >> day. >> >> >> Don Brown-2 wrote: >> >>> If you can find a way to completely replace OGNL by MVEL, I'd be very >>> interested to see it. :) >>> >>> Don >>> >>> Chris Brock wrote: >>> I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on "expressions" in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: > I'm still not getting all of the hand wringing that is going on in > this > thread about ognl. There is what I think a perfectly reasonable > solution > that will help finish up those last remaining bits that ognl needs to > really be production ready. > > Despite whatever we want to call it you could theoretically view it as > just another interpreter. I may be from an "enemy project" but I'm > still > willing/able to make the changes necessary for this to work. > > I've tried on a few occasions to engage whoever I can in the ognl > world > to > make this possible but haven't gotten any good responses yet. This > isn't > a > hard problem to solve, so it's frustrating watching everyone implement > new > property path interpreters /debate ognl when the answer is right > there... > ;/ > > > Don Brown wrote: > > >> I wrote a simple Struts 2 TemplateEngine that renders tags in pure >> Java, as opposed to the Freemarker that is used currently. I'm >> seeing >> performance improvements between 3 and 4 times faster than the old >> tags. This engine is based on the design I layed out previously [1]. >> It is better suited to simple tag rendering where the Freemarker >> version is better suited for HTML-heavy tag output and customization. >> >> The Java engine: >> - Allows the tag generator and "interceptors" to deal with tag >> objects, not pure text >> - Tag "interceptors" or handlers have full control over the output >> - Serialization of tag objects into text can be customized >> - Is fast - 3 to 4 times faster than the Freemarker engine >> >> Anyways, if nothing else, it shows there are things we can do to >> drastically speed up the tags w/o throwing out OGNL. If you only use >> the simple theme, this might be an attractive option that gives you >> more customization and speed. >> >> I'm kinda up in the air as to where to put this. I'm leaning toward >> committing it to the sandbox as then it would be clear it is >> experimental, especially since not all tags and themes are >> implemented. >> >> Don >> >> [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html >> >> On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: >> >> >>> Very interesting... I wonder how much of the performance hit was due >>> to >>> Freemarker and how much OGNL. Could you package this application in >>> a >>> war and attach it to a JIRA ticket? I'd love to have it for future >>> comparisons. >>> >>> Don >>> >>> dice wrote: >>> >>> They are my stats Ted. The stats are posted below along with my sample >>> JSP >>> >>> code. I only tried the textfield tag but looking at the ftl and vm >>> files for >>> >>> the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from >>> core >>>
Re: OGNL performance detrimental to Struts 2
I'd like it to be possible for a Struts developer to swap in a new EL, perhaps MVEL, if they didn't like OGNL for some reason. If you can create a patch to make that happen, I would consider it my early Christmas present :) Don Chris Brock wrote: Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on "expressions" in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an "enemy project" but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and "interceptors" to deal with tag objects, not pure text - Tag "interceptors" or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: name="nestedBean.attribute1"/> name="nestedBean.attribute2"/>
Re: No mapping found for dependency
The exception is thrown because, for some reason, the bean selector configuration provider isn't providing a factory for the default mapping of ActionMapper. Is your new configuration provider preempting it somehow? Don Ted Husted wrote: On the ticket for generating ActionConfigs for all potential alias methods, the initial unit tests are passing, but when integrating the provider into the runtime code, an exception is being thrown that I don't understand. The exception crops up when integrating the code with the FilterDispatcher. I expect some annotation is needed someplace :) com.opensymphony.xwork2.inject.DependencyException: com.opensymphony.xwork2.inject.ContainerImpl$MissingDependencyException: No mapping found for dependency [type=org.apache.struts2.dispatcher.mapper.ActionMapper, name='default'] in public static void org.apache.struts2.dispatcher.FilterDispatcher.setActionMapper(org.apache.struts2.dispatcher.mapper.ActionMapper). at com.opensymphony.xwork2.inject.ContainerImpl.addInjectorsForMembers(ContainerImpl.java:135) at com.opensymphony.xwork2.inject.ContainerImpl.addInjectorsForMethods(ContainerImpl.java:104) at com.opensymphony.xwork2.inject.ContainerImpl.injectStatics(ContainerImpl.java:89) at com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:494) at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:140) at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:52) at org.apache.struts2.dispatcher.Dispatcher.init_MethodConfigurationProvider(Dispatcher.java:347) at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:421) at org.apache.struts2.config.MethodConfigurationProviderTest.setUp(MethodConfigurationProviderTest.java:68) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: com.opensymphony.xwork2.inject.ContainerImpl$MissingDependencyException: No mapping found for dependency [type=org.apache.struts2.dispatcher.mapper.ActionMapper, name='default'] in public static void org.apache.struts2.dispatcher.FilterDispatcher.setActionMapper(org.apache.struts2.dispatcher.mapper.ActionMapper). at com.opensymphony.xwork2.inject.ContainerImpl.createParameterInjector(ContainerImpl.java:217) at com.opensymphony.xwork2.inject.ContainerImpl.getParametersInjectors(ContainerImpl.java:207) at com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.(ContainerImpl.java:260) at com.opensymphony.xwork2.inject.ContainerImpl$3.create(ContainerImpl.java:108) at com.opensymphony.xwork2.inject.ContainerImpl$3.create(ContainerImpl.java:106) at com.opensymphony.xwork2.inject.ContainerImpl.addInjectorsForMembers(ContainerImpl.java:132) ... 26 more Modified: struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java struts/struts2/trunk/core/src/main/java/org/apache/struts2/dispatcher/Dispatcher.java struts/struts2/trunk/core/src/test/java/org/apache/struts2/config/ClasspathConfigurationProviderTest.java struts/struts2/trunk/core/src/test/java/org/apache/struts2/config/MethodConfigurationProviderTest.java Modified: struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java URL: http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java?view=diff&rev=488116&r1=488115&r2=488116 == --- struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java (original) +++ struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java Sun Dec 17 20:16:56 2006 @@ -3,53 +3,237 @@ import com.opensymphony.xwork2.config.ConfigurationProvider; import com.opensymphony.xwork2.config.Configuration; import com.opensymphony.xwork2.config.ConfigurationException; +import com.opensymphony.xwork2.config.RuntimeConfiguration; +import com.opensymphony.xwork2.config.entities.ActionConfig; +import com.opensymphony.xwork2.config.entities.PackageConfig; import com.opensymphony.xwork2.inject.ContainerBuilder; import com.opensymphony.xwork2.util.location.LocatableProperties; +import com.opensymphony.xwork2.ObjectFactory; +import java.util.*; +import java.lang.reflect.Method; /** * MethodConfigurationProvider creates Ac
Re: OGNL performance detrimental to Struts 2
Me too. On 12/18/06, Don Brown <[EMAIL PROTECTED]> wrote: If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: > I think the problem is that the Tapestry solution is simply a property > accessor package, which doesn't really meet the needs of the established > WebWork community which relies on "expressions" in addition to properties to > accomplish tasks. > > That being said, my project (MVEL) stands willing to step in and assist. I > think it's performance and flexibility speak for itself: > http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
No mapping found for dependency
On the ticket for generating ActionConfigs for all potential alias methods, the initial unit tests are passing, but when integrating the provider into the runtime code, an exception is being thrown that I don't understand. The exception crops up when integrating the code with the FilterDispatcher. I expect some annotation is needed someplace :) com.opensymphony.xwork2.inject.DependencyException: com.opensymphony.xwork2.inject.ContainerImpl$MissingDependencyException: No mapping found for dependency [type=org.apache.struts2.dispatcher.mapper.ActionMapper, name='default'] in public static void org.apache.struts2.dispatcher.FilterDispatcher.setActionMapper(org.apache.struts2.dispatcher.mapper.ActionMapper). at com.opensymphony.xwork2.inject.ContainerImpl.addInjectorsForMembers(ContainerImpl.java:135) at com.opensymphony.xwork2.inject.ContainerImpl.addInjectorsForMethods(ContainerImpl.java:104) at com.opensymphony.xwork2.inject.ContainerImpl.injectStatics(ContainerImpl.java:89) at com.opensymphony.xwork2.inject.ContainerBuilder.create(ContainerBuilder.java:494) at com.opensymphony.xwork2.config.impl.DefaultConfiguration.reload(DefaultConfiguration.java:140) at com.opensymphony.xwork2.config.ConfigurationManager.getConfiguration(ConfigurationManager.java:52) at org.apache.struts2.dispatcher.Dispatcher.init_MethodConfigurationProvider(Dispatcher.java:347) at org.apache.struts2.dispatcher.Dispatcher.init(Dispatcher.java:421) at org.apache.struts2.config.MethodConfigurationProviderTest.setUp(MethodConfigurationProviderTest.java:68) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) Caused by: com.opensymphony.xwork2.inject.ContainerImpl$MissingDependencyException: No mapping found for dependency [type=org.apache.struts2.dispatcher.mapper.ActionMapper, name='default'] in public static void org.apache.struts2.dispatcher.FilterDispatcher.setActionMapper(org.apache.struts2.dispatcher.mapper.ActionMapper). at com.opensymphony.xwork2.inject.ContainerImpl.createParameterInjector(ContainerImpl.java:217) at com.opensymphony.xwork2.inject.ContainerImpl.getParametersInjectors(ContainerImpl.java:207) at com.opensymphony.xwork2.inject.ContainerImpl$MethodInjector.(ContainerImpl.java:260) at com.opensymphony.xwork2.inject.ContainerImpl$3.create(ContainerImpl.java:108) at com.opensymphony.xwork2.inject.ContainerImpl$3.create(ContainerImpl.java:106) at com.opensymphony.xwork2.inject.ContainerImpl.addInjectorsForMembers(ContainerImpl.java:132) ... 26 more Modified: struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java struts/struts2/trunk/core/src/main/java/org/apache/struts2/dispatcher/Dispatcher.java struts/struts2/trunk/core/src/test/java/org/apache/struts2/config/ClasspathConfigurationProviderTest.java struts/struts2/trunk/core/src/test/java/org/apache/struts2/config/MethodConfigurationProviderTest.java Modified: struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java URL: http://svn.apache.org/viewvc/struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java?view=diff&rev=488116&r1=488115&r2=488116 == --- struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java (original) +++ struts/struts2/trunk/core/src/main/java/org/apache/struts2/config/MethodConfigurationProvider.java Sun Dec 17 20:16:56 2006 @@ -3,53 +3,237 @@ import com.opensymphony.xwork2.config.ConfigurationProvider; import com.opensymphony.xwork2.config.Configuration; import com.opensymphony.xwork2.config.ConfigurationException; +import com.opensymphony.xwork2.config.RuntimeConfiguration; +import com.opensymphony.xwork2.config.entities.ActionConfig; +import com.opensymphony.xwork2.config.entities.PackageConfig; import com.opensymphony.xwork2.inject.ContainerBuilder; import com.opensymphony.xwork2.util.location.LocatableProperties; +import com.opensymphony.xwork2.ObjectFactory; +import java.util.*; +import java.lang.reflect.Method; /** * MethodConfigurationProvider creates ActionConfigs for potential action - * methods without a corresponding action. - * - * The provider iterates over the set of namespaces and the set of actionNames - * in a Configuration and retrieves each ActionConfig. - * For each ActionConfig that invokes the default "execute" method, - * the prov
Re: OGNL performance detrimental to Struts 2
Why do you think it would be so terribly difficult? What does MVEL not support that is currently supported by OGNL that would not be fixable by a few tweaks to MVEL's syntax? Generally, MVEL's API architecture follows the same pattern as OGNL, supports type coercion, conversion, projections, etc. Not to mention that MVEL is now an active project and OGNL is not, and of course the performance advantage in MVEL which is only getting better by the day. Don Brown-2 wrote: > > If you can find a way to completely replace OGNL by MVEL, I'd be very > interested to see it. :) > > Don > > Chris Brock wrote: >> I think the problem is that the Tapestry solution is simply a property >> accessor package, which doesn't really meet the needs of the established >> WebWork community which relies on "expressions" in addition to properties >> to >> accomplish tasks. >> >> That being said, my project (MVEL) stands willing to step in and assist. >> I >> think it's performance and flexibility speak for itself: >> http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language >> >> >> Jessek wrote: >> >>> I'm still not getting all of the hand wringing that is going on in this >>> thread about ognl. There is what I think a perfectly reasonable solution >>> that will help finish up those last remaining bits that ognl needs to >>> really be production ready. >>> >>> Despite whatever we want to call it you could theoretically view it as >>> just another interpreter. I may be from an "enemy project" but I'm still >>> willing/able to make the changes necessary for this to work. >>> >>> I've tried on a few occasions to engage whoever I can in the ognl world >>> to >>> make this possible but haven't gotten any good responses yet. This isn't >>> a >>> hard problem to solve, so it's frustrating watching everyone implement >>> new >>> property path interpreters /debate ognl when the answer is right >>> there... >>> ;/ >>> >>> >>> Don Brown wrote: >>> I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and "interceptors" to deal with tag objects, not pure text - Tag "interceptors" or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: > Very interesting... I wonder how much of the performance hit was due > to > Freemarker and how much OGNL. Could you package this application in a > war and attach it to a JIRA ticket? I'd love to have it for future > comparisons. > > Don > > dice wrote: > >> They are my stats Ted. The stats are posted below along with my >> sample >> > JSP > >> code. I only tried the textfield tag but looking at the ftl and vm >> > files for > >> the other tags I can't see how the results would be any different. >> >> Perhaps an interim solution could be to remove the use of OGNL from >> > core > >> functionality that doesn't require it. eg. Is it really necessary to >> > access > >> UIBean attributes from the theme templates using OGNL? >> >> PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 >> > tags in > >> JSP Tag files and performance was still impressive. >> >> >> >> >> Technology - Hits per second with 1 user / 10 users: >> >> Struts 1 - 109 / 191 >> Stripes - 88 / 140 >> WW2/SAF2 with default FreeMarker templates - 12 / 7 >> WW2/SAF2 with Velocity templates - 22 / 15 >> JSF - 27 / 40 >> >> >> Sample JSP: >> >> >> >> >> >> >> >
Re: OGNL performance detrimental to Struts 2
If you can find a way to completely replace OGNL by MVEL, I'd be very interested to see it. :) Don Chris Brock wrote: I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on "expressions" in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an "enemy project" but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: I wrote a simple Struts 2 TemplateEngine that renders tags in pure Java, as opposed to the Freemarker that is used currently. I'm seeing performance improvements between 3 and 4 times faster than the old tags. This engine is based on the design I layed out previously [1]. It is better suited to simple tag rendering where the Freemarker version is better suited for HTML-heavy tag output and customization. The Java engine: - Allows the tag generator and "interceptors" to deal with tag objects, not pure text - Tag "interceptors" or handlers have full control over the output - Serialization of tag objects into text can be customized - Is fast - 3 to 4 times faster than the Freemarker engine Anyways, if nothing else, it shows there are things we can do to drastically speed up the tags w/o throwing out OGNL. If you only use the simple theme, this might be an attractive option that gives you more customization and speed. I'm kinda up in the air as to where to put this. I'm leaning toward committing it to the sandbox as then it would be clear it is experimental, especially since not all tags and themes are implemented. Don [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: Very interesting... I wonder how much of the performance hit was due to Freemarker and how much OGNL. Could you package this application in a war and attach it to a JIRA ticket? I'd love to have it for future comparisons. Don dice wrote: They are my stats Ted. The stats are posted below along with my sample JSP code. I only tried the textfield tag but looking at the ftl and vm files for the other tags I can't see how the results would be any different. Perhaps an interim solution could be to remove the use of OGNL from core functionality that doesn't require it. eg. Is it really necessary to access UIBean attributes from the theme templates using OGNL? PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 tags in JSP Tag files and performance was still impressive. Technology - Hits per second with 1 user / 10 users: Struts 1 - 109 / 191 Stripes - 88 / 140 WW2/SAF2 with default FreeMarker templates - 12 / 7 WW2/SAF2 with Velocity templates - 22 / 15 JSF - 27 / 40 Sample JSP: name="nestedBean.attribute1"/> name="nestedBean.attribute2"/> name="nestedBean.attribute3"/> name="nestedBean.attribute4"/> name="nestedBean.attribute5"/> name="nestedBean.attribute6"/> name="nestedBean.attribute7"/> name="nestedBean.attribute8"/> name="nestedBean.attribute9"/> Ted Husted-3 wrote: On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote: Do you have the performance numbers that you can share? I'd really be interested in them. There are some interesting numbers here * http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html (be sure to read to the *end* of the commnets). We might want to come up with a set of test pages that thorougly exercise the core tags, so that we can run our
Re: OGNL performance detrimental to Struts 2
I'm not sure what you mean by "property accessor". The Tapestry community is just as tied down/used to using ognl expressions as much as any other. Tapestry-prop is a side project Howard created for very specific consulting engagements where the performance overhead of ognl was unacceptable for some clients. I think it's a mistake to throw ognl out at this point. The expression language is awesome, it just needs a performance boost. (it's also been out and about being used for years) Chris Brock wrote: > > I think the problem is that the Tapestry solution is simply a property > accessor package, which doesn't really meet the needs of the established > WebWork community which relies on "expressions" in addition to properties > to accomplish tasks. > > That being said, my project (MVEL) stands willing to step in and assist. > I think it's performance and flexibility speak for itself: > http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language > -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7940406 Sent from the Struts - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with Tiles 2 and WS 5
I'll try to hit both questions 1) The answer to your first question is easy: http://svn.apache.org/repos/asf/struts/sandbox/trunk/ 2) a) yes, a lot has changed. Tiles2 is a revolution, not an evolution b) yes, we now require 1.5, though the plan is to provide retro weaver distributions. I can't say I've tried them though c) TilesContext is now managed by the TilesContainer, and yes, they are both created by configured factories. If you don't specify one in your configuration, defaults will be used. d) your changes look good to me e) if you want to try the most recent versions of the snapshots, they are located in the maven snapshot repo: http://people.apache.org/repo/m2-snapshot-repository/ f) I believe that the log message "INFO: CONFIG FILES DEFINED IN WEB.XML" was removed after the container refactoring was complete, yet you're using the context_factory configuration that was added during that refactoring. . .that would lead me to believe that you're using a snapshot that doesn't necessarily match the binary. Try using the '2.0-r480013-SNAPSHOT' version in the repo. Let me know how it goes! Thanks for trying out the bleeding edge. David Stone, Sam wrote: I got my entire app working on Websphere 5 (servlet 1.2, jsp 2.3, jdk 1.4.2) using the tiles-core-2.0-SNAPSHOT.jar from 9/14/2006 (filesize: 128880, CRC: 3F46E3BF). I did have to use jstl.jar and standard.jar (not the 1.1.2 versions) because of this WebSphere environment. I'd like to either: A) find the source code for this exact build OR B) migrate to the latest Tiles 2 snapshot For option A: can anybody help me pin down this source code? Option B --- I see a lot has change since Sep 2006. First and foremost is that Tiles 2 is now built on JDK 1.5. I also see that tiles:insert has become tiles:insertDefinition and that TilesContext now is factory generated. I am having little luck migrating and getting not much to go on log-message-wise. This is what I've tried: 1) changed all my tiles-defs to use tiles-config_2_0.dtd instead of 1.1 2) changed all my tiles:insert statements to tiles:insertDefinition 3) added the following to my web.xml: org.apache.tiles.CONTEXT_FACTORY org.apache.tiles.context.enhanced.EnhancedContextFactory 4) retrotranslated the current tiles-core-2.0-SNAPSHOT.jar and tiles-api-2.0-SNAPSHOT.jar and put these into my web-inf/lib directory and removed the old jar. 5) Retrotranslated and tossed in the current xml-apis-1.0.b2.jar as well None of my pages come up and I get no messages. All I see in the log is messages to the effect that initDefinitionsFactory has started (I think). INFO: CONFIG FILES DEFINED IN WEB.XML INFO: initializing definitions factory... When I purposely mess up a definition I get a message directing me to the problem so I think this is working. What steps have I missed? If the taglib included in the current jar going to work for me? Any advice is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I think the problem is that the Tapestry solution is simply a property accessor package, which doesn't really meet the needs of the established WebWork community which relies on "expressions" in addition to properties to accomplish tasks. That being said, my project (MVEL) stands willing to step in and assist. I think it's performance and flexibility speak for itself: http://wiki.mvflex.org/index.php?title=MVFLEX_Expression_Language Jessek wrote: > > I'm still not getting all of the hand wringing that is going on in this > thread about ognl. There is what I think a perfectly reasonable solution > that will help finish up those last remaining bits that ognl needs to > really be production ready. > > Despite whatever we want to call it you could theoretically view it as > just another interpreter. I may be from an "enemy project" but I'm still > willing/able to make the changes necessary for this to work. > > I've tried on a few occasions to engage whoever I can in the ognl world to > make this possible but haven't gotten any good responses yet. This isn't a > hard problem to solve, so it's frustrating watching everyone implement new > property path interpreters /debate ognl when the answer is right there... > ;/ > > > Don Brown wrote: >> >> I wrote a simple Struts 2 TemplateEngine that renders tags in pure >> Java, as opposed to the Freemarker that is used currently. I'm seeing >> performance improvements between 3 and 4 times faster than the old >> tags. This engine is based on the design I layed out previously [1]. >> It is better suited to simple tag rendering where the Freemarker >> version is better suited for HTML-heavy tag output and customization. >> >> The Java engine: >> - Allows the tag generator and "interceptors" to deal with tag >> objects, not pure text >> - Tag "interceptors" or handlers have full control over the output >> - Serialization of tag objects into text can be customized >> - Is fast - 3 to 4 times faster than the Freemarker engine >> >> Anyways, if nothing else, it shows there are things we can do to >> drastically speed up the tags w/o throwing out OGNL. If you only use >> the simple theme, this might be an attractive option that gives you >> more customization and speed. >> >> I'm kinda up in the air as to where to put this. I'm leaning toward >> committing it to the sandbox as then it would be clear it is >> experimental, especially since not all tags and themes are >> implemented. >> >> Don >> >> [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html >> >> On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: >>> Very interesting... I wonder how much of the performance hit was due to >>> Freemarker and how much OGNL. Could you package this application in a >>> war and attach it to a JIRA ticket? I'd love to have it for future >>> comparisons. >>> >>> Don >>> >>> dice wrote: >>> > They are my stats Ted. The stats are posted below along with my sample >>> JSP >>> > code. I only tried the textfield tag but looking at the ftl and vm >>> files for >>> > the other tags I can't see how the results would be any different. >>> > >>> > Perhaps an interim solution could be to remove the use of OGNL from >>> core >>> > functionality that doesn't require it. eg. Is it really necessary to >>> access >>> > UIBean attributes from the theme templates using OGNL? >>> > >>> > PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 >>> tags in >>> > JSP Tag files and performance was still impressive. >>> > >>> > >>> > >>> > >>> > Technology - Hits per second with 1 user / 10 users: >>> > >>> > Struts 1 - 109 / 191 >>> > Stripes - 88 / 140 >>> > WW2/SAF2 with default FreeMarker templates - 12 / 7 >>> > WW2/SAF2 with Velocity templates - 22 / 15 >>> > JSF - 27 / 40 >>> > >>> > >>> > Sample JSP: >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >> name="nestedBean.attribute1"/> >>> > >> name="nestedBean.attribute2"/> >>> > >> name="nestedBean.attribute3"/> >>> > >> name="nestedBean.attribute4"/> >>> > >> name="nestedBean.attribute5"/> >>> > >> name="nestedBean.attribute6"/> >>> > >> name="nestedBean.attribute7"/> >>> > >> name="nestedBean.attribute8"/> >>> > >> name="nestedBean.attribute9"/> >>> > >>> > >>> > >>> > >>> > >>> > Ted Husted-3 wrote: >>> > >>> >> On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >>> >> >>> >>> Do you have the performance numbers that you can share? I'd really >>> be >>> >>> interested in them. >>> >>> >>> >> There are some interesting numbers here >>> >> >>> >> * >>> >> >>> http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html >>> >> >>> >> (be sure to read to the *end* of the commnets). >>> >> >>> >> We might want to come up with a set of test pages that thorougly >>> >
Problems with Tiles 2 and WS 5
I got my entire app working on Websphere 5 (servlet 1.2, jsp 2.3, jdk 1.4.2) using the tiles-core-2.0-SNAPSHOT.jar from 9/14/2006 (filesize: 128880, CRC: 3F46E3BF). I did have to use jstl.jar and standard.jar (not the 1.1.2 versions) because of this WebSphere environment. I'd like to either: A) find the source code for this exact build OR B) migrate to the latest Tiles 2 snapshot For option A: can anybody help me pin down this source code? Option B --- I see a lot has change since Sep 2006. First and foremost is that Tiles 2 is now built on JDK 1.5. I also see that tiles:insert has become tiles:insertDefinition and that TilesContext now is factory generated. I am having little luck migrating and getting not much to go on log-message-wise. This is what I've tried: 1) changed all my tiles-defs to use tiles-config_2_0.dtd instead of 1.1 2) changed all my tiles:insert statements to tiles:insertDefinition 3) added the following to my web.xml: org.apache.tiles.CONTEXT_FACTORY org.apache.tiles.context.enhanced.EnhancedContextFactory 4) retrotranslated the current tiles-core-2.0-SNAPSHOT.jar and tiles-api-2.0-SNAPSHOT.jar and put these into my web-inf/lib directory and removed the old jar. 5) Retrotranslated and tossed in the current xml-apis-1.0.b2.jar as well None of my pages come up and I get no messages. All I see in the log is messages to the effect that initDefinitionsFactory has started (I think). INFO: CONFIG FILES DEFINED IN WEB.XML INFO: initializing definitions factory... When I purposely mess up a definition I get a message directing me to the problem so I think this is working. What steps have I missed? If the taglib included in the current jar going to work for me? Any advice is appreciated. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
Personally, I have only WW2 apps with the ajax theme in production and there is no intention of upgrading anytime soon. I would also be surprised if any of the other committers have projects based on the ajax theme in production. /Ian Ted Husted wrote: On 12/18/06, Ian Roughley <[EMAIL PROTECTED]> wrote: > On the other hand, ripping the ajax tags out would affect backwards > compatibility. Are a lot of users out there using these tags? Could > the migration be simple or would it involve too much effort? I have never gotten much of an answer whenever I queries the users for who was using the ajax tags. Usually, about 3-4 weeks after a new change was made I would get some feedback. Personally, it would seem that most people are either (a) not using them, or (b) rolling their own. I'm not sure how much backward compatibility would be affected - as if the same attributes that are used now could be used in the ajax plug-in tags. So if you are upgrading you'd just need to ensure that the plug-in is there. I haven't checked lately, but I think there is quiet a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes, new dojo version, new tags). If we extract the ajax support into a struts-dojo plugin, it would pave the way for alternative plugins. If the change in ajax support is an issue for someone, then they could roll another plugin based on the struts-dojo plugin. Likewise for other ajax libaries. The key question is whether the Struts committers are using the Ajax theme and how the change is going to affect the applications we have in production. We can't drag around code that people are not going to support, and we can't support code that we don't use ourselves. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JIRA comment spam deletion tool
When removing SPAM from our Struts JIRA, please use this tool: https://issues.apache.org/struts/secure/admin/cleancommentspam.jsp This page is only available to JIRA administrators and if you are a Struts committer, you should have access. If not, let me know. Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
On 12/18/06, Ian Roughley <[EMAIL PROTECTED]> wrote: > On the other hand, ripping the ajax tags out would affect backwards > compatibility. Are a lot of users out there using these tags? Could > the migration be simple or would it involve too much effort? I have never gotten much of an answer whenever I queries the users for who was using the ajax tags. Usually, about 3-4 weeks after a new change was made I would get some feedback. Personally, it would seem that most people are either (a) not using them, or (b) rolling their own. I'm not sure how much backward compatibility would be affected - as if the same attributes that are used now could be used in the ajax plug-in tags. So if you are upgrading you'd just need to ensure that the plug-in is there. I haven't checked lately, but I think there is quiet a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes, new dojo version, new tags). If we extract the ajax support into a struts-dojo plugin, it would pave the way for alternative plugins. If the change in ajax support is an issue for someone, then they could roll another plugin based on the struts-dojo plugin. Likewise for other ajax libaries. The key question is whether the Struts committers are using the Ajax theme and how the change is going to affect the applications we have in production. We can't drag around code that people are not going to support, and we can't support code that we don't use ourselves. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
OGNL isn't a subproject of Struts, and so there's not anything we do about changing OGNL from here. AFAIK, everyone in the Struts and WebWork projects have been treating OGNL as black box. The place to start would be by posting to the OGNL developers forum. * http://forums.opensymphony.com/forum.jspa?forumID=16 perhaps accompanied by a JIRA ticket * http://jira.opensymphony.com/browse/OGNL Of course, the forum does seem to be abandoned, but it would still be the place to post a detailed description of what you'd like to do. Once the post is made there, either the OGNL group or the OpenSymphony group would be able respond. -Ted. On 12/18/06, Jessek <[EMAIL PROTECTED]> wrote: I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an "enemy project" but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: > > I wrote a simple Struts 2 TemplateEngine that renders tags in pure > Java, as opposed to the Freemarker that is used currently. I'm seeing > performance improvements between 3 and 4 times faster than the old > tags. This engine is based on the design I layed out previously [1]. > It is better suited to simple tag rendering where the Freemarker > version is better suited for HTML-heavy tag output and customization. > > The Java engine: > - Allows the tag generator and "interceptors" to deal with tag > objects, not pure text > - Tag "interceptors" or handlers have full control over the output > - Serialization of tag objects into text can be customized > - Is fast - 3 to 4 times faster than the Freemarker engine > > Anyways, if nothing else, it shows there are things we can do to > drastically speed up the tags w/o throwing out OGNL. If you only use > the simple theme, this might be an attractive option that gives you > more customization and speed. > > I'm kinda up in the air as to where to put this. I'm leaning toward > committing it to the sandbox as then it would be clear it is > experimental, especially since not all tags and themes are > implemented. > > Don > > [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html > > On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: >> Very interesting... I wonder how much of the performance hit was due to >> Freemarker and how much OGNL. Could you package this application in a >> war and attach it to a JIRA ticket? I'd love to have it for future >> comparisons. >> >> Don >> >> dice wrote: >> > They are my stats Ted. The stats are posted below along with my sample >> JSP >> > code. I only tried the textfield tag but looking at the ftl and vm >> files for >> > the other tags I can't see how the results would be any different. >> > >> > Perhaps an interim solution could be to remove the use of OGNL from >> core >> > functionality that doesn't require it. eg. Is it really necessary to >> access >> > UIBean attributes from the theme templates using OGNL? >> > >> > PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 >> tags in >> > JSP Tag files and performance was still impressive. >> > >> > >> > >> > >> > Technology - Hits per second with 1 user / 10 users: >> > >> > Struts 1 - 109 / 191 >> > Stripes - 88 / 140 >> > WW2/SAF2 with default FreeMarker templates - 12 / 7 >> > WW2/SAF2 with Velocity templates - 22 / 15 >> > JSF - 27 / 40 >> > >> > >> > Sample JSP: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Ted Husted-3 wrote: >> > >> >> On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >> >> >> >>> Do you have the performance numbers that you can share? I'd really >> be >> >>> interested in them. >> >>> >> >> There are some interesting numbers here >> >> >> >> * >> >> >> http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html >> >> >> >> (be sure to read to the *end* of the commnets). >> >> >> >> We might want to come up with a set of test pages that thorougly >> >> exercise the core tags, so that we can run our own direct comparisons >> >> of S1, S2, et al. >> >> >> >> Of course, the peformance is the still same as WebWork 2, which is >> >> driving some serious applications
Re: We need to clean up the Struts 2 AJAX tags (was Re: Additional UI tags)
Don Brown wrote: As much as I absolutely hate to say it, I think we need to resolve this ajax tag issue before 2.0 goes GA. The AJAX support of Struts 2 gets so much attention by the community that to have a brittle, poorly supported feature that we hope to remove in the next release will only bring confusion and rejection of Struts 2 as a whole. agreed. If we created a new tag library, our current tags should be able to be very much simplified as a lot of the attributes would go away. The new tags would be much clearer and easier to pick up without having to explain themes and why certain attributes only work in certain situations. Yes - much easier to explain tags. On the other hand, ripping the ajax tags out would affect backwards compatibility. Are a lot of users out there using these tags? Could the migration be simple or would it involve too much effort? I have never gotten much of an answer whenever I queries the users for who was using the ajax tags. Usually, about 3-4 weeks after a new change was made I would get some feedback. Personally, it would seem that most people are either (a) not using them, or (b) rolling their own. I'm not sure how much backward compatibility would be affected - as if the same attributes that are used now could be used in the ajax plug-in tags. So if you are upgrading you'd just need to ensure that the plug-in is there. I haven't checked lately, but I think there is quiet a difference from WW2 to Struts2 for the ajax tags (i.e. new attributes, new dojo version, new tags). Don Ian Roughley wrote: The wrappers around the beans are there to provide accessors to new attributes needed by the ajax tags. If we were to extract the tags into a separate taglib or library, I don't think we would need the wrappers. The additionally required attributes would be contained on the new classes in the new library. This would also remove the dependency of s2 on each ajax library we use (i.e. for dojo we need an additional attribute x & y, for prototype maybe we use y and add new attributes a & b). But I like the idea :) It would also help with the more frequent dojo updates. /Ian Ted Husted wrote: Meanwhile, what about Don's suggestion that we keep the wrappers but drop the theme and put the tags into their own library or plugin? We'd need to do something like that first, regardless of where the code ultimately lives. -Ted. On 12/14/06, Musachy Barroso <[EMAIL PROTECTED]> wrote: Probably a better integration in some places...but it would definitely be worth considering not to duplicate what others are doing. musachy Don Brown wrote: > Well, if there is an external project that already does everything we > want, then why don't we just use them? I'm all for minimizing > duplication. What value does having our own ajax tag library provide? > > Don - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OGNL performance detrimental to Struts 2
I'm still not getting all of the hand wringing that is going on in this thread about ognl. There is what I think a perfectly reasonable solution that will help finish up those last remaining bits that ognl needs to really be production ready. Despite whatever we want to call it you could theoretically view it as just another interpreter. I may be from an "enemy project" but I'm still willing/able to make the changes necessary for this to work. I've tried on a few occasions to engage whoever I can in the ognl world to make this possible but haven't gotten any good responses yet. This isn't a hard problem to solve, so it's frustrating watching everyone implement new property path interpreters /debate ognl when the answer is right there... ;/ Don Brown wrote: > > I wrote a simple Struts 2 TemplateEngine that renders tags in pure > Java, as opposed to the Freemarker that is used currently. I'm seeing > performance improvements between 3 and 4 times faster than the old > tags. This engine is based on the design I layed out previously [1]. > It is better suited to simple tag rendering where the Freemarker > version is better suited for HTML-heavy tag output and customization. > > The Java engine: > - Allows the tag generator and "interceptors" to deal with tag > objects, not pure text > - Tag "interceptors" or handlers have full control over the output > - Serialization of tag objects into text can be customized > - Is fast - 3 to 4 times faster than the Freemarker engine > > Anyways, if nothing else, it shows there are things we can do to > drastically speed up the tags w/o throwing out OGNL. If you only use > the simple theme, this might be an attractive option that gives you > more customization and speed. > > I'm kinda up in the air as to where to put this. I'm leaning toward > committing it to the sandbox as then it would be clear it is > experimental, especially since not all tags and themes are > implemented. > > Don > > [1] - http://www.mail-archive.com/dev@struts.apache.org/msg25065.html > > On 12/13/06, Don Brown <[EMAIL PROTECTED]> wrote: >> Very interesting... I wonder how much of the performance hit was due to >> Freemarker and how much OGNL. Could you package this application in a >> war and attach it to a JIRA ticket? I'd love to have it for future >> comparisons. >> >> Don >> >> dice wrote: >> > They are my stats Ted. The stats are posted below along with my sample >> JSP >> > code. I only tried the textfield tag but looking at the ftl and vm >> files for >> > the other tags I can't see how the results would be any different. >> > >> > Perhaps an interim solution could be to remove the use of OGNL from >> core >> > functionality that doesn't require it. eg. Is it really necessary to >> access >> > UIBean attributes from the theme templates using OGNL? >> > >> > PS: I emulated the Struts 2 themes in Struts 1 by wrapping Struts 1 >> tags in >> > JSP Tag files and performance was still impressive. >> > >> > >> > >> > >> > Technology - Hits per second with 1 user / 10 users: >> > >> > Struts 1 - 109 / 191 >> > Stripes - 88 / 140 >> > WW2/SAF2 with default FreeMarker templates - 12 / 7 >> > WW2/SAF2 with Velocity templates - 22 / 15 >> > JSF - 27 / 40 >> > >> > >> > Sample JSP: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > Ted Husted-3 wrote: >> > >> >> On 12/13/06, Ian Roughley <[EMAIL PROTECTED]> wrote: >> >> >> >>> Do you have the performance numbers that you can share? I'd really >> be >> >>> interested in them. >> >>> >> >> There are some interesting numbers here >> >> >> >> * >> >> >> http://javajmc.blogspot.com/2006/10/webwork-and-stripes-simple-performance.html >> >> >> >> (be sure to read to the *end* of the commnets). >> >> >> >> We might want to come up with a set of test pages that thorougly >> >> exercise the core tags, so that we can run our own direct comparisons >> >> of S1, S2, et al. >> >> >> >> Of course, the peformance is the still same as WebWork 2, which is >> >> driving some serious applications. We also know exactly where lies the >> >> bottleneck. We need to fix or replace OGNL. >> >> >> >> -Ted. >> >> >> >> >> >> >> > >> > >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/OGNL-performance-detrimental-to-Struts-2-tf2804655.html#a7933372 Sent from the Struts - Dev mailing list archive at Nabble.com.
Re: [1.3] Is there any "init" method for a Command based requestProcessor
On 12/18/06, nicolas de loof <[EMAIL PROTECTED]> wrote: Hello, I'm trying to create a custom "CreateAction" command to be plugged in the CoR RequestProcessor of Struts 1.3 This command will handle Spring autowiring of commands, but requires initiali acces to the servletContext to get the Spring WebApplicationContext. I can make this "init" from the first command execution based on ServletActionContext, but I would find better to make this init on time for every commands invocation. Is there any support for such an init process ? There isn't - but why not just look up the spring WebApplicationContext each time? Niall Nico. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[1.3] Is there any "init" method for a Command based requestProcessor
Hello, I'm trying to create a custom "CreateAction" command to be plugged in the CoR RequestProcessor of Struts 1.3 This command will handle Spring autowiring of commands, but requires initiali acces to the servletContext to get the Spring WebApplicationContext. I can make this "init" from the first command execution based on ServletActionContext, but I would find better to make this init on time for every commands invocation. Is there any support for such an init process ? Nico.
Re: NPE in prepareContinuation()
What version of xwork are you using? Can you debug into this code and tell us what's null? I looked at the latest xwork1 trunk (that method didn't exist in xwork2 trunk) and the only thing that would throw a nullpointerexception is if the stack or the context of the stack were null. Without debugging into it, it's hard to say. Tom Bob Lee wrote: Any idea what would trigger this? We don't use continuations. java.lang.NullPointerException com.opensymphony.xwork.DefaultActionInvocation.prepareContinuation( DefaultActionInvocation.java:248) com.opensymphony.xwork.DefaultActionInvocation.createAction( DefaultActionInvocation.java:236) com.opensymphony.xwork.DefaultActionInvocation.init( DefaultActionInvocation.java:309) com.opensymphony.xwork.DefaultActionInvocation.( DefaultActionInvocation.java:70) com.opensymphony.xwork.DefaultActionInvocation.( DefaultActionInvocation.java:63) com.opensymphony.xwork.DefaultActionProxyFactory.createActionInvocation( DefaultActionProxyFactory.java:28) com.opensymphony.xwork.DefaultActionProxy.prepare(DefaultActionProxy.java :150) com.opensymphony.xwork.DefaultActionProxy.(DefaultActionProxy.java :73) com.opensymphony.xwork.DefaultActionProxyFactory.createActionProxy( DefaultActionProxyFactory.java:39) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
