shale-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (SHALE-277) Shale is eating 500s errors
Date Fri, 15 Sep 2006 23:09:31 GMT
     [ 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

        

Mime
View raw message