[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-tabpanelfocusedCommentId=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)
[jira] [Updated] (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 updated WW-4485:
--
Fix Version/s: 2.5
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] [Updated] (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 updated WW-4485:
--
Affects Version/s: (was: 2.5)
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-4433) ConventionUnknownHandler change breaks exception handling in interceptors.
[ https://issues.apache.org/jira/browse/WW-4433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14482689#comment-14482689 ] Lukasz Lenart commented on WW-4433: --- 2.3.22 was pushed for test but some issues were discovered during test period so this version was dropped and now I'm starting with 2.3.23 http://markmail.org/thread/i72dhopvlitfoq4w#query:+page:1+mid:nxq7uet4j75mpqpk+state:results 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-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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-4485) New cacheKey is too expensive to create
[
https://issues.apache.org/jira/browse/WW-4485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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}
result name=selfSignupFlow type=redirectAction
param name=actionNameconfirmAccount/param
param name=streetAddress${streetAddress}/param
param name=city${city}/param
param name=state${state}/param
param name=postalCode${postalCode}/param
...
/result
{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-4481) Deprecated warning gives no context
[ https://issues.apache.org/jira/browse/WW-4481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
unsubscribe
unsubscribe
[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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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)
[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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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)
