commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jesse Glick (JIRA)" <commons-...@jakarta.apache.org>
Subject [jira] Commented: (JELLY-235) nested exceptions are displayed incorrectly with JellyException
Date Mon, 07 Aug 2006 18:29:15 GMT
    [ http://issues.apache.org/jira/browse/JELLY-235?page=comments#action_12426279 ] 
            
Jesse Glick commented on JELLY-235:
-----------------------------------

On a related note: the logic for extracting a detail message from the cause is not very helpful.
Example: in my servlet error page I see

---%<---
exception

javax.servlet.ServletException: file:/[....].jelly:6:66: <j:forEach> org/apache/commons/collections/iterators/ArrayIterator
[....]

root cause

org.apache.commons.jelly.JellyTagException: file:/[....].jelly:6:66: <j:forEach> org/apache/commons/collections/iterators/ArrayIterator
	org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:712)
	org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
[.....]

note The full stack trace of the root cause is available in the Apache Tomcat/5.5.17 logs.
---%<---

Hmm. Not very informative. What is wrong with ArrayIterator? Not of the right type? Hard to
guess. Need to go look at the server logs, where I see

---%<---
Caused by: java.lang.NoClassDefFoundError: org/apache/commons/collections/iterators/ArrayIterator
        at org.apache.commons.jelly.expression.ExpressionSupport.evaluateAsIterator(ExpressionSupport.java:106)
        at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:89)
        at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:262)
---%<---

Now that immediately tells me what is going on. The crucial info is the exception class name:
NoClassDefFoundError.

The problem in Jelly is here:

---%<---
public JellyException(Throwable cause, String fileName, String elementName, int columnNumber,
int lineNumber) {
    this(cause.getLocalizedMessage(), cause, fileName, elementName, columnNumber, lineNumber);
}
public JellyException(String reason, Throwable cause, String fileName, String elementName,
int columnNumber, int lineNumber) {
    super( (reason==null?cause.getClass().getName():reason) );
    // ....
---%<---

A NCDFE has as its message (and, by default, also its localizedMessage) the class name that
could not be found. Since reason != null, that is used as the detail message also for the
JellyException. But this is not as informative as it should be.

I would therefore recommend changing the code to e.g.

---%<---
public JellyException(Throwable cause, String fileName, String elementName, int columnNumber,
int lineNumber) {
    this(cause.toString(), cause, fileName, elementName, columnNumber, lineNumber);
}
public JellyException(String reason, Throwable cause, String fileName, String elementName,
int columnNumber, int lineNumber) {
    super( (reason==null?cause.toString():reason) );
    // ....
---%<---

This would ensure that by default, the exception detail message shown in the web page includes
*both* the detail message and class name of the original exception.

> nested exceptions are displayed incorrectly with JellyException
> ---------------------------------------------------------------
>
>                 Key: JELLY-235
>                 URL: http://issues.apache.org/jira/browse/JELLY-235
>             Project: Commons Jelly
>          Issue Type: Improvement
>          Components: core / taglib.core
>    Affects Versions: 1.0
>            Reporter: Kohsuke Kawaguchi
>         Attachments: JELLY.diff
>
>
> JellyException has some built-in support for nested exceptions. In particular, when it
displays a stack trace, it tries to also displays the nested exception, which is great.
> What's not so great is that when JDK 1.4 added this on its own, both Jelly and JDK try
to display the nested exceptions, and you ended up seeing O(n^2) stack traces for n-level
nested exception.
> Imagine a situation where N JellyExceptions are nested inside each other.
> With the following current printStackTrace:
> {code}
>     public void printStackTrace() {
>         super.printStackTrace();
>         if (cause != null) {
>             System.out.println("Root cause");
>             cause.printStackTrace();
>         }
>     }
> {code}
> Outer JellyException prints its stack trace first (in which JDK prints out all the nested
exceptions),
> and then JellyException prints the stack trace of the inner JellyException. Then this
same step is repeatedly, causing an output like this:
> {noformat}
> JellyExpception 3
> Caused by JellyException 2
> Caused by JellyException 1
> Root cause:
> JellyException 2
> Caused by JellyException 1
> Root cause:
> JellyException 1
> {noformat}
> See the attached patch for one possible fix.
> Personally, I don't mind if JellyException choose to completely stop trying to print
out the nested exception on its own, and simply delegate everything to JDK. This will make
the output worse on JDK 1.3 and earlier, but the # of people using those is shrinking every
day.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message