[jira] [Comment Edited] (WW-4433) ConventionUnknownHandler change breaks exception handling in interceptors.
[
https://issues.apache.org/jira/browse/WW-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484722#comment-14484722
]
Lukasz Lenart edited comment on WW-4433 at 4/8/15 5:07 AM:
---
Just implement {{com.opensymphony.xwork2.UnknownHandler}} interface and throw
{{NoSuchMethodException}} - that's all and now register the new handler like
this http://struts.apache.org/docs/unknown-handlers.html
BTW. you can help testing 2.3.23 http://markmail.org/thread/oqtssgeesejrobko
was (Author: lukaszlenart):
Just implement {{com.opensymphony.xwork2.UnknownHandler}} interface and throws
{{NoSuchMethodException}} - that's all and now register the new handler like
this http://struts.apache.org/docs/unknown-handlers.html
BTW. you can help testing 2.3.23 http://markmail.org/thread/oqtssgeesejrobko
> ConventionUnknownHandler change breaks exception handling in interceptors.
> --
>
> Key: WW-4433
> URL: https://issues.apache.org/jira/browse/WW-4433
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors, Documentation, Plugin - Convention
>Affects Versions: 2.3.20
>Reporter: Joseph Wolschon
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 2.3.23
>
>
> Struts 2.3.20 appears to have caused a regression that prevents exceptions
> thrown from convention-plugin actions from reaching
> ExceptionMappingInterceptor. This breaks exception handling when using the
> convention-plugin.
> To Reproduce:
> * Generate a project struts2-archetype-convention archetype using 2.3.20
> * Throw exception in the action. With 2.3.20, a blank page is shown.
> * Change to 2.3.16.3 and you will get the standard struts2 error page.
> The breaking change appears to have been made in WW-4331. This causes error
> interceptor code to break (showing a blank page when exceptions are thrown)
> as DefaultActionInvocation does not catch an exception from the default
> UnknownHandler implementation execution, which would previously re-throw the
> original exception back up for the interceptors to catch.
> Workaround:
> We've created our own UnknownHandler implementation that just throws a new
> NoSuchMethodException, allowing DefaultActionInvocation to re-throw the
> original exception so that our error interceptor can again catch it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4433) ConventionUnknownHandler change breaks exception handling in interceptors.
[
https://issues.apache.org/jira/browse/WW-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484722#comment-14484722
]
Lukasz Lenart commented on WW-4433:
---
Just implement {{com.opensymphony.xwork2.UnknownHandler}} interface and throws
{{NoSuchMethodException}} - that's all and now register the new handler like
this http://struts.apache.org/docs/unknown-handlers.html
BTW. you can help testing 2.3.23 http://markmail.org/thread/oqtssgeesejrobko
> ConventionUnknownHandler change breaks exception handling in interceptors.
> --
>
> Key: WW-4433
> URL: https://issues.apache.org/jira/browse/WW-4433
> Project: Struts 2
> Issue Type: Bug
> Components: Core Interceptors, Documentation, Plugin - Convention
>Affects Versions: 2.3.20
>Reporter: Joseph Wolschon
>Assignee: Lukasz Lenart
>Priority: Minor
> Fix For: 2.3.23
>
>
> Struts 2.3.20 appears to have caused a regression that prevents exceptions
> thrown from convention-plugin actions from reaching
> ExceptionMappingInterceptor. This breaks exception handling when using the
> convention-plugin.
> To Reproduce:
> * Generate a project struts2-archetype-convention archetype using 2.3.20
> * Throw exception in the action. With 2.3.20, a blank page is shown.
> * Change to 2.3.16.3 and you will get the standard struts2 error page.
> The breaking change appears to have been made in WW-4331. This causes error
> interceptor code to break (showing a blank page when exceptions are thrown)
> as DefaultActionInvocation does not catch an exception from the default
> UnknownHandler implementation execution, which would previously re-throw the
> original exception back up for the interceptors to catch.
> Workaround:
> We've created our own UnknownHandler implementation that just throws a new
> NoSuchMethodException, allowing DefaultActionInvocation to re-throw the
> original exception so that our error interceptor can again catch it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4433) ConventionUnknownHandler change breaks exception handling in interceptors.
[ https://issues.apache.org/jira/browse/WW-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14484637#comment-14484637 ] Alireza Fattahi commented on WW-4433: - Me too ! Looking for workaround code ! > ConventionUnknownHandler change breaks exception handling in interceptors. > -- > > Key: WW-4433 > URL: https://issues.apache.org/jira/browse/WW-4433 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors, Documentation, Plugin - Convention >Affects Versions: 2.3.20 >Reporter: Joseph Wolschon >Assignee: Lukasz Lenart >Priority: Minor > Fix For: 2.3.23 > > > Struts 2.3.20 appears to have caused a regression that prevents exceptions > thrown from convention-plugin actions from reaching > ExceptionMappingInterceptor. This breaks exception handling when using the > convention-plugin. > To Reproduce: > * Generate a project struts2-archetype-convention archetype using 2.3.20 > * Throw exception in the action. With 2.3.20, a blank page is shown. > * Change to 2.3.16.3 and you will get the standard struts2 error page. > The breaking change appears to have been made in WW-4331. This causes error > interceptor code to break (showing a blank page when exceptions are thrown) > as DefaultActionInvocation does not catch an exception from the default > UnknownHandler implementation execution, which would previously re-throw the > original exception back up for the interceptors to catch. > Workaround: > We've created our own UnknownHandler implementation that just throws a new > NoSuchMethodException, allowing DefaultActionInvocation to re-throw the > original exception so that our error interceptor can again catch it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4433) ConventionUnknownHandler change breaks exception handling in interceptors.
[ https://issues.apache.org/jira/browse/WW-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483750#comment-14483750 ] David Williams commented on WW-4433: ok cool. Thanks! Has anybody posted the code for the workaround? I would like to add the workaround to my code and test it. > ConventionUnknownHandler change breaks exception handling in interceptors. > -- > > Key: WW-4433 > URL: https://issues.apache.org/jira/browse/WW-4433 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors, Documentation, Plugin - Convention >Affects Versions: 2.3.20 >Reporter: Joseph Wolschon >Assignee: Lukasz Lenart >Priority: Minor > Fix For: 2.3.23 > > > Struts 2.3.20 appears to have caused a regression that prevents exceptions > thrown from convention-plugin actions from reaching > ExceptionMappingInterceptor. This breaks exception handling when using the > convention-plugin. > To Reproduce: > * Generate a project struts2-archetype-convention archetype using 2.3.20 > * Throw exception in the action. With 2.3.20, a blank page is shown. > * Change to 2.3.16.3 and you will get the standard struts2 error page. > The breaking change appears to have been made in WW-4331. This causes error > interceptor code to break (showing a blank page when exceptions are thrown) > as DefaultActionInvocation does not catch an exception from the default > UnknownHandler implementation execution, which would previously re-throw the > original exception back up for the interceptors to catch. > Workaround: > We've created our own UnknownHandler implementation that just throws a new > NoSuchMethodException, allowing DefaultActionInvocation to re-throw the > original exception so that our error interceptor can again catch it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4433) ConventionUnknownHandler change breaks exception handling in interceptors.
[ https://issues.apache.org/jira/browse/WW-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483723#comment-14483723 ] David Williams commented on WW-4433: ok cool. Thanks! Has anybody posted the code for the workaround? I would like to add the workaround to my code and test it. > ConventionUnknownHandler change breaks exception handling in interceptors. > -- > > Key: WW-4433 > URL: https://issues.apache.org/jira/browse/WW-4433 > Project: Struts 2 > Issue Type: Bug > Components: Core Interceptors, Documentation, Plugin - Convention >Affects Versions: 2.3.20 >Reporter: Joseph Wolschon >Assignee: Lukasz Lenart >Priority: Minor > Fix For: 2.3.23 > > > Struts 2.3.20 appears to have caused a regression that prevents exceptions > thrown from convention-plugin actions from reaching > ExceptionMappingInterceptor. This breaks exception handling when using the > convention-plugin. > To Reproduce: > * Generate a project struts2-archetype-convention archetype using 2.3.20 > * Throw exception in the action. With 2.3.20, a blank page is shown. > * Change to 2.3.16.3 and you will get the standard struts2 error page. > The breaking change appears to have been made in WW-4331. This causes error > interceptor code to break (showing a blank page when exceptions are thrown) > as DefaultActionInvocation does not catch an exception from the default > UnknownHandler implementation execution, which would previously re-throw the > original exception back up for the interceptors to catch. > Workaround: > We've created our own UnknownHandler implementation that just throws a new > NoSuchMethodException, allowing DefaultActionInvocation to re-throw the > original exception so that our error interceptor can again catch it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
unsubscribe
unsubscribe
[jira] [Commented] (WW-4481) Deprecated warning gives no context
[ https://issues.apache.org/jira/browse/WW-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483013#comment-14483013 ] Hudson commented on WW-4481: SUCCESS: Integrated in Struts-JDK6-master #905 (See [https://builds.apache.org/job/Struts-JDK6-master/905/]) WW-4481 Adds context to deprecations warning (lukaszlenart: rev 6021995bfbad1cbf0e6dc16b2d3e19cf9b65011d) * xwork-core/src/main/java/com/opensymphony/xwork2/ognl/SecurityMemberAccess.java > Deprecated warning gives no context > --- > > Key: WW-4481 > URL: https://issues.apache.org/jira/browse/WW-4481 > Project: Struts 2 > Issue Type: Bug > Components: Value Stack >Affects Versions: 2.3.23 >Reporter: Jasper Rosenberg >Assignee: Lukasz Lenart >Priority: Critical > Fix For: 2.3.23 > > > I released 2.3.22 and immediately had my log files fill up with this warning: > WARN [SecurityMemberAccess] Support for accessing static methods is > deprecated! Please refactor your application! > I was surprised because I thought I had actually removed all static > references, but I can't find what I missed because this warning has no > context. Can you please add the information about the expression being > evaluated so I can track down the usage? Thanks. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4484) Upgrade to FreeMarker 2.3.22
[ https://issues.apache.org/jira/browse/WW-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483012#comment-14483012 ] Hudson commented on WW-4484: SUCCESS: Integrated in Struts-JDK6-master #905 (See [https://builds.apache.org/job/Struts-JDK6-master/905/]) WW-4484 Upgrades Freemarker (lukaszlenart: rev 4651f3750117b281c200b1f011250a11606d60c4) * pom.xml > Upgrade to FreeMarker 2.3.22 > > > Key: WW-4484 > URL: https://issues.apache.org/jira/browse/WW-4484 > Project: Struts 2 > Issue Type: Improvement >Affects Versions: 2.3.20 >Reporter: Daniel Dekany >Assignee: Lukasz Lenart > Fix For: 2.3.23 > > > You are still using 2.3.19 from 3 years ago. There were many improvements > since then. Even if many users don't care about new features, they still > benefit from the more helpful error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (WW-4482) Conversion annotation ignored for ServletAction parameter
[
https://issues.apache.org/jira/browse/WW-4482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14483014#comment-14483014
]
Hudson commented on WW-4482:
SUCCESS: Integrated in Struts-JDK6-master #905 (See
[https://builds.apache.org/job/Struts-JDK6-master/905/])
WW-4482 Fallbacks to non-collection evaluation for non-collection param
(lukaszlenart: rev 4a08f070f101dbe8a74b7ed53794d645274ee9da)
* xwork-core/src/main/java/com/opensymphony/xwork2/util/TextParseUtil.java
> Conversion annotation ignored for ServletAction parameter
> -
>
> Key: WW-4482
> URL: https://issues.apache.org/jira/browse/WW-4482
> Project: Struts 2
> Issue Type: Bug
> Components: Expression Language, Value Stack
>Affects Versions: 2.3.20
>Reporter: Jasper Rosenberg
>Assignee: Lukasz Lenart
>Priority: Critical
> Fix For: 2.3.23
>
>
> This definitely worked before 2.3.20, but unfortunately I haven’t been able
> to track down the actual source of the bug introduced for 2.3.20. My best
> guess is that it was introduced when the code was refactored to support
> Collections.
> Basically I have an Action, with a setter and getter for state that uses a
> custom type convertor like so:
> {code:java}
> /** @return the state. */
> @TypeConversion(converter = "com.myco.typeconvertor.RegionTypeConvertor")
> public RegionI getState() {
> return state;
> }
> {code}
> When I submit the action, this type convertor is correctly used to turn the
> “state” post parameter into a RegionI object which is injected into the
> Action. So far so good.
> However, the result looks like:
> {code:xml}
>
> confirmAccount
> ${streetAddress}
> ${city}
> ${state}
> ${postalCode}
> ...
>
> {code}
> And in the latest release, when it evaluates $\{state} it uses the default
> type convertor (in this case for an enum because the concrete class is a
> USState enum), rather than the com.myco.typeconvertor.RegionTypeConvertor
> specified on both the getter and setter for state in the action.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482989#comment-14482989
]
Jasper Rosenberg commented on WW-4485:
--
Awesome, I really appreciate you making time for this so quickly.
> New cacheKey is too expensive to create
> ---
>
> Key: WW-4485
> URL: https://issues.apache.org/jira/browse/WW-4485
> Project: Struts 2
> Issue Type: Bug
> Components: Core Actions, Expression Language
>Reporter: Jasper Rosenberg
>Assignee: Lukasz Lenart
>Priority: Blocker
> Labels: ognl
> Fix For: 2.5
>
>
> So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
> rollback because load on the servers went through the roof. Looking at the
> stack traces, the issue was tons of threads doing this:
> {noformat}
> at java.lang.Class.getEnclosingMethod0(Native Method)
> at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
> at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
> at java.lang.Class.getCanonicalName(Class.java:1377)
> at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
> at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
> at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
> at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
> at
> com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
> {noformat}
> The problem is that the change to buildCacheKey() for
> https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
> how often it is called.
> I'd like to suggest replacing the current buildCacheKey() implementation with
> this:
> {code:java}
> private static Object buildCacheKey(Class targetClass, String
> propertyName) {
> return new CacheKey(targetClass, propertyName);
> }
>
> private static final class CacheKey {
> private final Class clazz;
> private final String propertyName;
> public CacheKey(Class clazz, String propertyName) {
> this.clazz = clazz;
> this.propertyName = propertyName;
> }
>
> public boolean equals(Object obj) {
> CacheKey cacheKey = (CacheKey) obj;
> return clazz.equals(cacheKey.clazz)
> && propertyName.equals(cacheKey.propertyName);
> }
>
> public int hashCode() {
> return clazz.hashCode() * 31 + propertyName.hashCode();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart resolved WW-4485.
---
Resolution: Fixed
Assignee: Lukasz Lenart
OGNL 3.0.11 is underway to the Central :)
> New cacheKey is too expensive to create
> ---
>
> Key: WW-4485
> URL: https://issues.apache.org/jira/browse/WW-4485
> Project: Struts 2
> Issue Type: Bug
> Components: Core Actions, Expression Language
>Reporter: Jasper Rosenberg
>Assignee: Lukasz Lenart
>Priority: Blocker
> Labels: ognl
> Fix For: 2.5
>
>
> So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
> rollback because load on the servers went through the roof. Looking at the
> stack traces, the issue was tons of threads doing this:
> {noformat}
> at java.lang.Class.getEnclosingMethod0(Native Method)
> at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
> at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
> at java.lang.Class.getCanonicalName(Class.java:1377)
> at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
> at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
> at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
> at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
> at
> com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
> {noformat}
> The problem is that the change to buildCacheKey() for
> https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
> how often it is called.
> I'd like to suggest replacing the current buildCacheKey() implementation with
> this:
> {code:java}
> private static Object buildCacheKey(Class targetClass, String
> propertyName) {
> return new CacheKey(targetClass, propertyName);
> }
>
> private static final class CacheKey {
> private final Class clazz;
> private final String propertyName;
> public CacheKey(Class clazz, String propertyName) {
> this.clazz = clazz;
> this.propertyName = propertyName;
> }
>
> public boolean equals(Object obj) {
> CacheKey cacheKey = (CacheKey) obj;
> return clazz.equals(cacheKey.clazz)
> && propertyName.equals(cacheKey.propertyName);
> }
>
> public int hashCode() {
> return clazz.hashCode() * 31 + propertyName.hashCode();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482959#comment-14482959
]
Jasper Rosenberg commented on WW-4485:
--
Looks good! Please push a new release at your convenience. Thanks!
> New cacheKey is too expensive to create
> ---
>
> Key: WW-4485
> URL: https://issues.apache.org/jira/browse/WW-4485
> Project: Struts 2
> Issue Type: Bug
> Components: Core Actions, Expression Language
>Reporter: Jasper Rosenberg
>Priority: Blocker
> Labels: ognl
> Fix For: 2.5
>
>
> So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
> rollback because load on the servers went through the roof. Looking at the
> stack traces, the issue was tons of threads doing this:
> {noformat}
> at java.lang.Class.getEnclosingMethod0(Native Method)
> at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
> at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
> at java.lang.Class.getCanonicalName(Class.java:1377)
> at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
> at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
> at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
> at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
> at
> com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
> {noformat}
> The problem is that the change to buildCacheKey() for
> https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
> how often it is called.
> I'd like to suggest replacing the current buildCacheKey() implementation with
> this:
> {code:java}
> private static Object buildCacheKey(Class targetClass, String
> propertyName) {
> return new CacheKey(targetClass, propertyName);
> }
>
> private static final class CacheKey {
> private final Class clazz;
> private final String propertyName;
> public CacheKey(Class clazz, String propertyName) {
> this.clazz = clazz;
> this.propertyName = propertyName;
> }
>
> public boolean equals(Object obj) {
> CacheKey cacheKey = (CacheKey) obj;
> return clazz.equals(cacheKey.clazz)
> && propertyName.equals(cacheKey.propertyName);
> }
>
> public int hashCode() {
> return clazz.hashCode() * 31 + propertyName.hashCode();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482931#comment-14482931
]
Jasper Rosenberg commented on WW-4485:
--
Thanks, I will get right on testing it.
Also, as an aside, I realized that there actually was a regression issue
introduced by WW-4113 as well. Before, if a class had been loaded by different
class loaders, then it was cached twice in ognl, which I think is the safest
behavior. After WW-4113, because it was using the class's name, the same class
name from different class loaders would be only cached once, with the first one
in winning.
> New cacheKey is too expensive to create
> ---
>
> Key: WW-4485
> URL: https://issues.apache.org/jira/browse/WW-4485
> Project: Struts 2
> Issue Type: Bug
> Components: Core Actions, Expression Language
>Reporter: Jasper Rosenberg
>Priority: Blocker
> Labels: ognl
> Fix For: 2.5
>
>
> So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
> rollback because load on the servers went through the roof. Looking at the
> stack traces, the issue was tons of threads doing this:
> {noformat}
> at java.lang.Class.getEnclosingMethod0(Native Method)
> at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
> at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
> at java.lang.Class.getCanonicalName(Class.java:1377)
> at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
> at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
> at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
> at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
> at
> com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
> {noformat}
> The problem is that the change to buildCacheKey() for
> https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
> how often it is called.
> I'd like to suggest replacing the current buildCacheKey() implementation with
> this:
> {code:java}
> private static Object buildCacheKey(Class targetClass, String
> propertyName) {
> return new CacheKey(targetClass, propertyName);
> }
>
> private static final class CacheKey {
> private final Class clazz;
> private final String propertyName;
> public CacheKey(Class clazz, String propertyName) {
> this.clazz = clazz;
> this.propertyName = propertyName;
> }
>
> public boolean equals(Object obj) {
> CacheKey cacheKey = (CacheKey) obj;
> return clazz.equals(cacheKey.clazz)
> && propertyName.equals(cacheKey.propertyName);
> }
>
> public int hashCode() {
> return clazz.hashCode() * 31 + propertyName.hashCode();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482923#comment-14482923
]
Lukasz Lenart commented on WW-4485:
---
Sorry to hear that, I have pushed your changes into GitHub, can you test
3.0.11-SNAPSHOT? So then I will be able to push a new release
> New cacheKey is too expensive to create
> ---
>
> Key: WW-4485
> URL: https://issues.apache.org/jira/browse/WW-4485
> Project: Struts 2
> Issue Type: Bug
> Components: Core Actions, Expression Language
>Reporter: Jasper Rosenberg
>Priority: Blocker
> Labels: ognl
> Fix For: 2.5
>
>
> So we pushed ognl 3.0.10 to production this afternoon, and promptly had to
> rollback because load on the servers went through the roof. Looking at the
> stack traces, the issue was tons of threads doing this:
> {noformat}
> at java.lang.Class.getEnclosingMethod0(Native Method)
> at java.lang.Class.getEnclosingMethodInfo(Class.java:1059)
> at java.lang.Class.isLocalOrAnonymousClass(Class.java:1449)
> at java.lang.Class.getCanonicalName(Class.java:1377)
> at ognl.OgnlRuntime.buildCacheKey(OgnlRuntime.java:1944)
> at ognl.OgnlRuntime.getGetMethod(OgnlRuntime.java:1926)
> at ognl.OgnlRuntime.hasGetMethod(OgnlRuntime.java:1985)
> at ognl.OgnlRuntime.hasGetProperty(OgnlRuntime.java:2045)
> at
> com.opensymphony.xwork2.ognl.accessor.CompoundRootAccessor.getProperty(CompoundRootAccessor.java:141)
> {noformat}
> The problem is that the change to buildCacheKey() for
> https://issues.apache.org/jira/browse/WW-4113 is way to expensive considering
> how often it is called.
> I'd like to suggest replacing the current buildCacheKey() implementation with
> this:
> {code:java}
> private static Object buildCacheKey(Class targetClass, String
> propertyName) {
> return new CacheKey(targetClass, propertyName);
> }
>
> private static final class CacheKey {
> private final Class clazz;
> private final String propertyName;
> public CacheKey(Class clazz, String propertyName) {
> this.clazz = clazz;
> this.propertyName = propertyName;
> }
>
> public boolean equals(Object obj) {
> CacheKey cacheKey = (CacheKey) obj;
> return clazz.equals(cacheKey.clazz)
> && propertyName.equals(cacheKey.propertyName);
> }
>
> public int hashCode() {
> return clazz.hashCode() * 31 + propertyName.hashCode();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (WW-4484) Upgrade to FreeMarker 2.3.22
[ https://issues.apache.org/jira/browse/WW-4484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482761#comment-14482761 ] Hudson commented on WW-4484: SUCCESS: Integrated in Struts-JDK6-develop #139 (See [https://builds.apache.org/job/Struts-JDK6-develop/139/]) WW-4484 Upgrades Freemarker (lukaszlenart: rev 4651f3750117b281c200b1f011250a11606d60c4) * pom.xml > Upgrade to FreeMarker 2.3.22 > > > Key: WW-4484 > URL: https://issues.apache.org/jira/browse/WW-4484 > Project: Struts 2 > Issue Type: Improvement >Affects Versions: 2.3.20 >Reporter: Daniel Dekany >Assignee: Lukasz Lenart > Fix For: 2.3.23 > > > You are still using 2.3.19 from 3 years ago. There were many improvements > since then. Even if many users don't care about new features, they still > benefit from the more helpful error messages. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
