[jira] Resolved: (SHALE-277) Shale is eating 500s errors

["Craig McClanahan (JIRA)" <ji...@apache.org>]

     [ 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