[ http://issues.apache.org/struts/browse/SHALE-277?page=all ]
Craig McClanahan resolved SHALE-277.
------------------------------------
Resolution: Not A Problem
Assignee: Craig McClanahan
As of version 1.0.3, you can control what happens with exceptions at two
different points:
* When the exception occurs (in an event handler ultimately called from Shale),
the default handling caches it in a request scope variable. You can change
this
behavior by creating a bean that implements
org.apache.shale.view.ExceptionHandler,
store it as a request scope attribute under key
FacesConstants.EXCEPTION_HANDLER,
and do something different in the handleException() method.
* At the end of Invoke Application phase, Shale will determine whether any
exceptions
have been accumulated by the default handleException() method. If there have
been
any, it checks for a context init parameter under the symbolic constant
Constants.EXCEPTION_DISPATCH_PATH for the context relative path to an error
handling page (such as "/error.jsp") that control should be forwarded to,
instead of
navigating to the normal page selected by your application. This page will
receive the
same error handling request attributes that the normal container page would,
such as
the exception itself being visible through request attribute
"javax.servlet.error.exception").
Therefore, if you want to mimic the same behavior you should set this context
init parameter
to point to the same page that you've configured exception handling in
web.xml to point at.
The reason for this behavior, by the way, is so that Shale can live up to its
promise to call destroy() if init() was ever called. If this is not done, it
is likely that your application could leave unclosed JDBC connections lying
around, or whatever other resources you might have allocated earlier in the
lifecycle and need to clean up afterwards.
You can change the default behavior to actually cause a real 500 page, if you
want to. Just be aware that you are on your own for cleaning up allocated
resources.
> Shale is eating 500s errors
> ---------------------------
>
> Key: SHALE-277
> URL: http://issues.apache.org/struts/browse/SHALE-277
> Project: Shale
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.0.4-SNAPSHOT, 1.0.3
> Environment: Tomcat 5.5.17 + Myfaces 1.1.3
> Reporter: Veit Guna
> Assigned To: Craig McClanahan
>
> When using shale-core for the s:token tag in my myfaces webapp, shale is
> eating 500 errors. That means if for example
> a Nullpointer Exception occurs, it doesn't let tomcat use the custom error
> page configured in the web.xml for 500 errors.
> If I remove shale-core from my webapp, everything works fine and the custom
> error-page is displayed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/struts/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
