You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Larry Isaacs <La...@sas.com> on 2000/04/07 23:05:54 UTC
RE: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compil
er JspParseEventListener.java
Thanks for fixing this. However, the "masking" continues. If I enhance the problem example to define an error page, i.e.:
<%@page errorPage="ErrorPage.jsp" %>
<html><body>
<% out.flush(); %>
Throwing Exception!
<% if (true) throw new JasperException("Just testing!"); %>
</body></html>
the exception is again masked, this time by a "java.lang.IllegalStateException: Cannot forward as OutputStream or Writer has already been obtained" exception.
In this case, do you consider this "masking" to be a bug or is this a fact of life since the JSP spec says "you shall forward to the specified error page" and elsewhere says "forwarding can cause an IllegalStateException"?
The real world example that raised this issue was an error on a JSP page where a jsp:setProperty had a value="<%= whatever %> where the "whatever" was a string where the setter method expected an int. With Apache/JServe/GNUJSP, it worked anyway. Tomcat 3.1 correctly throws an IllegalArgumentException. However, since the offending page defined an error page, the real problem was hidden by the IllegalStateException.
If the developer's JSP testing environment doesn't provide a way to step though Java code, it looks like a lot of hair could be lost trying to find errors like this.
Larry
-----Original Message-----
From: craigmcc@locus.apache.org [mailto:craigmcc@locus.apache.org]
Sent: Thursday, April 06, 2000 8:44 PM
To: jakarta-tomcat-cvs@apache.org
Subject: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
JspParseEventListener.java
craigmcc 00/04/06 17:43:55
Modified: src/share/org/apache/jasper/compiler
JspParseEventListener.java
Log:
Change the error trap at the bottom of a generated JSP page so that it
calls out.clear() instead of out.clearBuffer() before handling the
exception. We don't really care that the response has been committed
already -- what we care about is the exception and the traceback.
Thanks for yet another patch Larry!
PR:192
Submitted by: Larry.Isaacs@sas.com
Revision Changes Path
1.14 +6 -4 jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
Index: JspParseEventListener.java
===================================================================
RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
retrieving revision 1.13
retrieving revision 1.14
diff -u -r1.13 -r1.14
--- JspParseEventListener.java 2000/03/31 19:43:52 1.13
+++ JspParseEventListener.java 2000/04/07 00:43:55 1.14
@@ -1,7 +1,7 @@
/*
- * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v 1.13 2000/03/31 19:43:52 mandar Exp $
- * $Revision: 1.13 $
- * $Date: 2000/03/31 19:43:52 $
+ * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v 1.14 2000/04/07 00:43:55 craigmcc Exp $
+ * $Revision: 1.14 $
+ * $Date: 2000/04/07 00:43:55 $
*
* ====================================================================
*
@@ -329,7 +329,9 @@
writer.println("} catch (Exception ex) {");
writer.pushIndent();
writer.println("if (out.getBufferSize() != 0)");
- writer.pushIndent(); writer.println("out.clear();"); writer.popIndent();
+ writer.pushIndent();
+ writer.println("out.clearBuffer();");
+ writer.popIndent();
writer.println("pageContext.handlePageException(ex);");
writer.popIndent();
writer.println("} finally {");
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
JspParseEventListener.java
Posted by Danno Ferrin <sh...@earthlink.net>.
Larry Isaacs wrote:
>
> Thanks for fixing this. However, the "masking" continues. If I enhance the problem example to define an error page, i.e.:
>
> <%@page errorPage="ErrorPage.jsp" %>
> <html><body>
> <% out.flush(); %>
> Throwing Exception!
> <% if (true) throw new JasperException("Just testing!"); %>
> </body></html>
>
> the exception is again masked, this time by a "java.lang.IllegalStateException: Cannot forward as OutputStream or Writer has already been obtained" exception.
>
> In this case, do you consider this "masking" to be a bug or is this a fact of life since the JSP spec says "you shall forward to the specified error page" and elsewhere says "forwarding can cause an IllegalStateException"?
I think this is just how it'll have to be. The only alternative I can
see is to throw a subclass of illegal state exception with the "masked"
exception stored as a field, where we overload the printStackTrace
methods to show the nested exceptions and expose a method to get at it
(possibly via a standard NestedException interface?)
And GnuJSP has the luxury of ignoring the spec since it is not a
reference implementation.
--Danno
> The real world example that raised this issue was an error on a JSP page where a jsp:setProperty had a value="<%= whatever %> where the "whatever" was a string where the setter method expected an int. With Apache/JServe/GNUJSP, it worked anyway. Tomcat 3.1 correctly throws an IllegalArgumentException. However, since the offending page defined an error page, the real problem was hidden by the IllegalStateException.
>
> If the developer's JSP testing environment doesn't provide a way to step though Java code, it looks like a lot of hair could be lost trying to find errors like this.
>
> Larry
>
> -----Original Message-----
> From: craigmcc@locus.apache.org [mailto:craigmcc@locus.apache.org]
> Sent: Thursday, April 06, 2000 8:44 PM
> To: jakarta-tomcat-cvs@apache.org
> Subject: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
> JspParseEventListener.java
>
> craigmcc 00/04/06 17:43:55
>
> Modified: src/share/org/apache/jasper/compiler
> JspParseEventListener.java
> Log:
> Change the error trap at the bottom of a generated JSP page so that it
> calls out.clear() instead of out.clearBuffer() before handling the
> exception. We don't really care that the response has been committed
> already -- what we care about is the exception and the traceback.
>
> Thanks for yet another patch Larry!
>
> PR:192
> Submitted by: Larry.Isaacs@sas.com
>
> Revision Changes Path
> 1.14 +6 -4 jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
>
> Index: JspParseEventListener.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -r1.13 -r1.14
> --- JspParseEventListener.java 2000/03/31 19:43:52 1.13
> +++ JspParseEventListener.java 2000/04/07 00:43:55 1.14
> @@ -1,7 +1,7 @@
> /*
> - * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v 1.13 2000/03/31 19:43:52 mandar Exp $
> - * $Revision: 1.13 $
> - * $Date: 2000/03/31 19:43:52 $
> + * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v 1.14 2000/04/07 00:43:55 craigmcc Exp $
> + * $Revision: 1.14 $
> + * $Date: 2000/04/07 00:43:55 $
> *
> * ====================================================================
> *
> @@ -329,7 +329,9 @@
> writer.println("} catch (Exception ex) {");
> writer.pushIndent();
> writer.println("if (out.getBufferSize() != 0)");
> - writer.pushIndent(); writer.println("out.clear();"); writer.popIndent();
> + writer.pushIndent();
> + writer.println("out.clearBuffer();");
> + writer.popIndent();
> writer.println("pageContext.handlePageException(ex);");
> writer.popIndent();
> writer.println("} finally {");
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
JspParseEventListener.java
Posted by MANDAR RAJE <ma...@pathfinder.eng.sun.com>.
Hi Larry,
You can't forward after committing the response. The way
around this is that you can have a large buffer and obviate
the need to flush the buffer.
An unfortunate side-effect of this is if you have
a "jsp:inclde" (runtime include) in your JSP page then
your error-page is rendered useless. With the upcoming spec.
hopefully this issue will be resolved.
Mandar.
Larry Isaacs wrote:
>
> Thanks for fixing this. However, the "masking" continues. If I enhance the problem example to define an error page, i.e.:
>
> <%@page errorPage="ErrorPage.jsp" %>
> <html><body>
> <% out.flush(); %>
> Throwing Exception!
> <% if (true) throw new JasperException("Just testing!"); %>
> </body></html>
>
> the exception is again masked, this time by a "java.lang.IllegalStateException: Cannot forward as OutputStream or Writer has already been obtained" exception.
>
> In this case, do you consider this "masking" to be a bug or is this a fact of life since the JSP spec says "you shall forward to the specified error page" and elsewhere says "forwarding can cause an IllegalStateException"?
>
> The real world example that raised this issue was an error on a JSP page where a jsp:setProperty had a value="<%= whatever %> where the "whatever" was a string where the setter method expected an int. With Apache/JServe/GNUJSP, it worked anyway. Tomcat 3.1 correctly throws an IllegalArgumentException. However, since the offending page defined an error page, the real problem was hidden by the IllegalStateException.
>
> If the developer's JSP testing environment doesn't provide a way to step though Java code, it looks like a lot of hair could be lost trying to find errors like this.
>
> Larry
>
> -----Original Message-----
> From: craigmcc@locus.apache.org [mailto:craigmcc@locus.apache.org]
> Sent: Thursday, April 06, 2000 8:44 PM
> To: jakarta-tomcat-cvs@apache.org
> Subject: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
> JspParseEventListener.java
>
> craigmcc 00/04/06 17:43:55
>
> Modified: src/share/org/apache/jasper/compiler
> JspParseEventListener.java
> Log:
> Change the error trap at the bottom of a generated JSP page so that it
> calls out.clear() instead of out.clearBuffer() before handling the
> exception. We don't really care that the response has been committed
> already -- what we care about is the exception and the traceback.
>
> Thanks for yet another patch Larry!
>
> PR:192
> Submitted by: Larry.Isaacs@sas.com
>
> Revision Changes Path
> 1.14 +6 -4 jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java
>
> Index: JspParseEventListener.java
> ===================================================================
> RCS file: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v
> retrieving revision 1.13
> retrieving revision 1.14
> diff -u -r1.13 -r1.14
> --- JspParseEventListener.java 2000/03/31 19:43:52 1.13
> +++ JspParseEventListener.java 2000/04/07 00:43:55 1.14
> @@ -1,7 +1,7 @@
> /*
> - * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v 1.13 2000/03/31 19:43:52 mandar Exp $
> - * $Revision: 1.13 $
> - * $Date: 2000/03/31 19:43:52 $
> + * $Header: /home/cvs/jakarta-tomcat/src/share/org/apache/jasper/compiler/JspParseEventListener.java,v 1.14 2000/04/07 00:43:55 craigmcc Exp $
> + * $Revision: 1.14 $
> + * $Date: 2000/04/07 00:43:55 $
> *
> * ====================================================================
> *
> @@ -329,7 +329,9 @@
> writer.println("} catch (Exception ex) {");
> writer.pushIndent();
> writer.println("if (out.getBufferSize() != 0)");
> - writer.pushIndent(); writer.println("out.clear();"); writer.popIndent();
> + writer.pushIndent();
> + writer.println("out.clearBuffer();");
> + writer.popIndent();
> writer.println("pageContext.handlePageException(ex);");
> writer.popIndent();
> writer.println("} finally {");
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-tomcat/src/share/org/apache/jasper/compiler
JspParseEventListener.java
Posted by Louis Tribble <lo...@metamata.com>.
Larry Isaacs wrote:
>
> Thanks for fixing this. However, the "masking" continues.
> If I enhance the problem example to define an error page
> the exception is again masked, this time by a
> "java.lang.IllegalStateException: Cannot forward as OutputStream or
> Writer has already been obtained" exception.
>
> In this case, do you consider this "masking" to be a bug or
> is this a fact of life since the JSP spec says "you shall
> forward to the specified error page" and elsewhere says "forwarding
> can cause an IllegalStateException"?
>
> The real world example that raised this issue was an error on a JSP
> page where a jsp:setProperty had a value="<%= whatever %> where the
> "whatever" was a string where the setter method expected an int.
> With Apache/JServe/GNUJSP, it worked anyway. Tomcat 3.1 correctly
> throws an IllegalArgumentException. However, since the offending
> page defined an error page, the real problem was hidden by the
> IllegalStateException.
>
> If the developer's JSP testing environment doesn't provide a way to
> step though Java code, it looks like a lot of hair could be lost
xxxxxxxx
has been
> trying to find errors like this.
Now I know when I see IllegalStateException to stick in a try catch
block to dump the _real_ exception, but it cost me the first time,
thinking my includes/forwards were somehow wrong even though they
looked right. In fact, it turned out to be a SQLException with a
10 second fix.
Louis Tribble
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
Louis Tribble louis@metamata.com
Metamata, Inc. http://www.metamata.com
Tools for serious Java developers. +1 510 796 0915
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>