[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] [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=14250096#comment-14250096 ] Senen de Diego edited comment on WW-4433 at 12/17/14 4:42 PM: -- I was going to notify the same bug (spring security exceptions not reaching the FilterSecurityInterceptor) but I see it's already detected and diagnosed. I just want to add a suggestion: I think the OgnlException should be passed as a parameter to UnknownHandlerManager.handleUnknownMethod in order to help the handler decide if it does something or not. was (Author: senen): I was going to notify the same bug (spring security exceptions not reaching the FilterSecurityInterceptor) but I see it's already detected and diagnosed. I just want to add a suggestion: I thing the OgnlException should be passed as a parameter to UnknownHandlerManager.handleUnknownMethod in order to help the handler decide if it does something or not. 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 Priority: Minor Fix For: 2.3.x 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=14250096#comment-14250096 ] Senen de Diego edited comment on WW-4433 at 12/17/14 5:05 PM: -- I was going to notify the same bug (spring security exceptions not reaching the FilterSecurityInterceptor) but I see it's already detected and diagnosed. I just want to add a suggestion: I think the OgnlException should be passed as a parameter to UnknownHandlerManager.handleUnknownMethod in order to help the handler decide if it does something or not. Or better than this: The UnknownHandlerManger should only be called if the exception encapsulated in OgnlException is a NoSuchMethodException. was (Author: senen): I was going to notify the same bug (spring security exceptions not reaching the FilterSecurityInterceptor) but I see it's already detected and diagnosed. I just want to add a suggestion: I think the OgnlException should be passed as a parameter to UnknownHandlerManager.handleUnknownMethod in order to help the handler decide if it does something or not. 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 Priority: Minor Fix For: 2.3.x 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=14247890#comment-14247890
]
Lukasz Lenart edited comment on WW-4433 at 12/16/14 7:31 AM:
-
Now when I'm checking the flow I see the problem but it wasn't in
{{UnknownHandler}}'s default implementation - method must return null to allow
other {{UnknownHandlers}} be invoked ;-)
The problem is in {{DefaultActionInvocation}} which should have re-thrown the
original exception if after examining all the {{UnknownHandlers}} the result is
still null.
{code:java}
// throw the original exception as UnknownHandlers weren't able to handle
invocation as well
if (methodResult == null) {
throw e;
}
{code}
was (Author: lukaszlenart):
Now when I'm checking the flow I see the problem but it wasn't in
{{UnknownHandler}}'s default implementation - method must return null to allow
other {{UnknownHandler}}s be invoked ;-)
The problem is in {{DefaultActionInvocation}} which should have re-thrown the
original exception if after examining all the {{UnknownHandler}}s the result is
still null.
{code:java}
// throw the original exception as UnknownHandlers weren't able to handle
invocation as well
if (methodResult == null) {
throw e;
}
{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
Priority: Minor
Fix For: 2.3.x
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)
