tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r500716 - in /tomcat/tc6.0.x/trunk: java/org/apache/catalina/core/ java/org/apache/catalina/valves/ webapps/docs/changelog.xml
Date Sun, 28 Jan 2007 16:01:52 GMT
Remy Maucherat wrote:
> wrote:
>> Author: markt
>> Date: Sat Jan 27 16:55:24 2007
>> New Revision: 500716
>> URL:
>> Log:
>> Port fix bug 39088 that prevents infinite loops when an exception is
>> thrown the returns itself for getRootCause(). Also port changes that
>> enable the root cause to be found when the nesting is particularly
>> extreme.
> Arrrrr, my eyes :D :D
> TC 6 already used the clean mechanism (using getCause, which can also
> display a lot more about the exception if proper wrapping was done by
> the application), so reverting to the TC 5.5 hack is super evil. It also
> had a recursion limit which seemed reasonable to me, and is going to be
> more efficient than your check.

I have already done some cleaning and corrected the change log.

There are a couple of problem with getCause. The first is that is
doesn't unwrap a fairly frequent exception for web applications:
SQLException. The second is that it doesn't unwrap a JspException that
has used the JspException(Throwable) constructor.

An alternative approach that has since occurred to me is to modify
JspException in the same way as ServletException so the standard
exception chaining is always used. This would enable getCause to be
used in all cases apart from SQLException and allow a much cleaner
patch whilst retaining improved root cause identification.

Having now just looked at the JavaDoc for JspException in the JSP 2.1
final spec we have to make this change to be spec compliant.
getRootCause has been deprecated in favour of getCause.

I'll make the changes later today.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message