[PATCH] Tomcat 4.0.1- Proposed fix for Bugzilla 4609

[Ryan Lubke <Ry...@Sun.COM>]

Hi,

Thought I'd give a shot at patching a bug (4609) I logged.
The basics of the bug is that an IOException is not thrown
if out.close() is called from within a JSP page and 
subsequent calls to write() or println(), etc. are made.

The solution I have affects two classes:
org.apache.jasper.runtime.JspWriterImpl
org.apache.jasper.compiler.JspParseEventListener

The modification to JspWriterImpl was simple:
  -Added a new boolean instance variable called 'closed'
  -When JspWriter.close() is called, set 'closed' to true.
  -Modified the JspWriter.ensureOpen() method.  If
   'closed' is true, or response is null, throw the IOException.

I felt the modification to JspParseEventListener.generateFooter()
was necessary as the page code generated:

    <snip>
    } catch (Throwable t) {
        if (out != null && out.getBufferSize() != 0)
	    out.clearBuffer();
        if (pageContext != null) pageContext.handlePageException(t);
    }
    </snip>

So in this case, now that the IOException is thown, we go into the 
throwable, but the call to out.clearBuffer() generates its own
IOException.  The problem with this is that the stacktrace becomes
inaccurate.  Showing the call to clearBuffer() as the top-most call
on the stack.

So the change I introduced would generate the following code:

    <snip>
    if (out != null && out.getBufferSize() != 0)
    try {
        out.clearBuffer();
    } catch (java.io.IOException ioe) {
        if (t instanceof java.io.IOException) {
            if (!(t.getMessage().equals(ioe.getMessage()))) {
                t = ioe;
            }
        }
    }
    </snip>

So, here if out.clearBuffer() happens to throw an IOException,
check to see if the throwable that brought us to this point
in the code is an IOException as well.  If it is, see if 
the messages are the same, if they aren't, then there
is a new IO issue and set ioe to the throwable which will
be handled by pageContext.handlePageException.  Otherwise
the catch becomes a no-op and pageContext.handlePageException
will use the original throwable.  Hope that made sense.

Anyway,  comments are definately welcome.  Still getting familiar
with the code.

Thanks,
-rl