7 messages in org.apache.shale.issues[jira] Commented: (SHALE-277) Shale i...| From | Sent On | Attachments |
|---|---|---|
| Veit Guna (JIRA) | Sep 10, 2006 11:50 am | |
| Craig McClanahan (JIRA) | Sep 15, 2006 4:09 pm | |
| Veit Guna (JIRA) | Sep 15, 2006 6:31 pm | |
| Craig McClanahan (JIRA) | Sep 15, 2006 6:42 pm | |
| Veit Guna (JIRA) | Sep 16, 2006 3:24 am | |
| Torsten Krah (JIRA) | Oct 17, 2006 8:49 am | |
| Torsten Krah (JIRA) | Nov 6, 2006 2:37 am |
| Subject: | [jira] Commented: (SHALE-277) Shale is eating 500s errors | |
|---|---|---|
| From: | Craig McClanahan (JIRA) (ji...@apache.org) | |
| Date: | Sep 15, 2006 6:42:08 pm | |
| List: | org.apache.shale.issues | |
[ http://issues.apache.org/struts/browse/SHALE-277?page=comments#action_38230 ]
Craig McClanahan commented on SHALE-277: ----------------------------------------
"You can change the default behavior to actually cause a real 500 page, if you
want to" means by the two points mentioned above, right?
Yes.
I will try that.
Just a design thought... wouldn't it be better that shale (taglib) won't change
anything of the default behavior per default? Cost me some time
to figure out, that shale was causing the problem, just because I used one tag
(s:token) of the whole shale framework.
In most cases I would agree with you. However, in this case, once you throw an
exception back to the container (to trigger the standard error page processing),
you *never* get control back ... so we could not guarantee that destroy() would
ultimately get called. At best, we could probably parse the error page
declarations in web.xml and attempt to go to the same pages for the same
exception types (while still allowing destroy() to be called), but the behavior
would still not match perfectly with what a conatiner does -- for example, Shale
does a RequestDispatcher.forward() to the error page (resulting in an HTTP
status of 200), not an HTTP 500.
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