[
https://issues.apache.org/struts/browse/WW-3341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Berthet updated WW-3341:
--------------------------------
Description:
Trying to migrate from 2.0.x to 2.1.8.1, I noticed that the exception handling
from the Dispatcher changed.
Before :
The dispatcher threw a ServletException and it was propagated through the stack
Since 2.1.1 :
The dispatcher catch all Exceptions and call sendError
The problem is that the exception will not go up through the stack as it was
the case before, so nobody in the stack (j2ee filters) will notice this
exception (unless checking requests attributes, which is not a good way).
If you use a javax.servlet.Filter for things such as open-session-in-view, you
will not notice the exception, and maybe fail to rollback your current
transaction, same for exception tracing filters, etc...
It is a severe non-backward-compatible change, it was not mentionned in any of
the changelogs. It seems it has introduced by revision 602665, seems to be
related to the fix for WW-218.
>From Dispatcher.serviceAction javadoc...
"All other errors are reported by throwing a ServletException."
The exception handling has to be clarified, I think propagating a
ServletException is more correct as it relies on the container and allow
filters to take it into account.
was:
Trying to migrate from 2.0.x to 2.1.8.1, I noticed that the exception handling
from the Dispatcher changed.
Before :
The dispatcher threw a ServletException and it was propagated through the stack
Since 2.1.1 :
The dispatcher catch all Exceptions and call sendError
The problem is that the exception will not go up through the stack as it was
the case before, so nobody in the stack (j2ee filters) will notice this
exception (unless checking requests attributes, which is not a good way).
If you use a javax.servlet.Filter for things such as open-session-in-view, you
will not notice the exception, and maybe fail to rollback your current
transaction, same for exception tracing filters, etc...
It is a severe non-backward-compatible change, it was not mentionned in any of
the changelogs. It seems it has introduced by revision 602665, seems to be
related to the fix for WW-218.
The exception handling has to be clarified, I think propagating a
ServletException is more correct as it relies on the container and allow
filters to take it into account.
> Dispatcher catches Exceptions silently since 2.1.1
> --------------------------------------------------
>
> Key: WW-3341
> URL: https://issues.apache.org/struts/browse/WW-3341
> Project: Struts 2
> Issue Type: Bug
> Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.4, 2.1.5, 2.1.6, 2.1.8
> Reporter: Nicolas Berthet
> Priority: Critical
>
> Trying to migrate from 2.0.x to 2.1.8.1, I noticed that the exception
> handling from the Dispatcher changed.
> Before :
> The dispatcher threw a ServletException and it was propagated through the
> stack
> Since 2.1.1 :
> The dispatcher catch all Exceptions and call sendError
> The problem is that the exception will not go up through the stack as it was
> the case before, so nobody in the stack (j2ee filters) will notice this
> exception (unless checking requests attributes, which is not a good way).
> If you use a javax.servlet.Filter for things such as open-session-in-view,
> you will not notice the exception, and maybe fail to rollback your current
> transaction, same for exception tracing filters, etc...
> It is a severe non-backward-compatible change, it was not mentionned in any
> of the changelogs. It seems it has introduced by revision 602665, seems to be
> related to the fix for WW-218.
> From Dispatcher.serviceAction javadoc...
> "All other errors are reported by throwing a ServletException."
> The exception handling has to be clarified, I think propagating a
> ServletException is more correct as it relies on the container and allow
> filters to take it into account.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
