You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Dave Cherkassky <dc...@djinnsoft.com> on 2009/04/29 20:57:02 UTC

Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

A long question:

First, I have a Servlet that writes to response.getOutputStream().  Here's a snippet:
  public class AuditTrailServlet extends HttpServlet {
    public void doGet( HttpServletRequest request, HttpServletResponse response )
      response.setContentType( "application/vnd.ms-excel" );
      response.setHeader( "Content-Disposition", "attachment; filename=" + fileName );

      ResultSet rs = ...;
      for ( int row = 0 ; rs.next(); row++ ) {
        // iterate over each row in the ResultSet
        for( int col = 0; fieldNameIt.hasNext(); col++ ) {
          // iterate over each column in the results, write to spreadsheet
          
          // custom code.
          // let us assume this block has a bug that occasionally throws a NullPointerException, 
          // but only after a bunch of cells are written first.
          
          response.getOutputStream().write( /* excel byte[] */ );
          
          // more custom code.
        }
      }
      rs.close();
  
      response.setStatus( HttpServletResponse.SC_OK );
    }
  }

Second, I have the following in the web.xml file, to tell tomcat to use a custom error page:
  <error-page>
    <exception-type>java.lang.Throwable</exception-type>
    <location>/myError.jsp</location>
  </error-page>

Last, here's myError.jsp:
  <%@ page isErrorPage='true' %>
  <html>
  <body>
  <h1>System Error</h1>
  <p>
  You have encountered a system error.
  </p>
  
  <%-- custom error processing that can't be done in a static .html page --%>
  
  </body>
  </html>


So, it all seems standard and straight-forward, right?



However, instead of seeing a nice custom error page when the NPE happens, I get the "ugly" Tomcat error page, and
the following in the Tomcat logs:
  java.lang.IllegalStateException: getOutputStream() has already been called for this response
  at org.apache.catalina.connector.ResponseBase.getWriter(ResponseBase.java:709)
  at org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:127)
  at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:128)
  at org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:121)
  at org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:137)
  at org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:153)
  at org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:148)
  at org.apache.jsp.error_jsp._jspService(error_jsp.java:284)


Yes, I know -- I *am* using Tomcat 4.1 (rather than the latest and greatest) for various legacy and political reasons.


But my question is this:
- Is this a known bug?  Or am I doing something wrong with either the servlet, the web.xml or with the jsp page?

Thanks,
-- 
Dave Cherkassky
  VP of Software Development
  DJiNN Software Inc.
  416.504.1354

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,

On 5/4/2009 12:36 PM, Dave Cherkassky wrote:
> My typical naming convention is to use "out" as a variable for
> OutputStream.  But of course that's not the case here -- "out" is a Writer!

Yup. Now, upgrade! ;) You can tell your politicians that TC 4.1 will
"soon" be unsupported and that it's really time to move up (and it
really is... I recently moved from 4.1 to 5.5 and it really was a breeze).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkn/TwoACgkQ9CaO5/Lv0PBI7wCgj8ZB/UjNIP8Q2ZdWgtK0BmNJ
1TwAoJ1a5bje/OR/umBCFvqlRC5ndV7p
=PODB
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Dave Cherkassky <dc...@djinnsoft.com>.
Chris, you are 100% right.

I got caught up in my own assumptions.

When I examined Tomcat's generated java class, I saw code like this:
  out.print( "...." );

My typical naming convention is to use "out" as a variable for OutputStream.  But of course that's not the case here -- "out" is a Writer!


Thanks for your help,
-- 
Dave Cherkassky
  VP of Software Development
  DJiNN Software Inc.
  416.504.1354


Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dave,
> 
> On 4/29/2009 10:41 PM, Dave Cherkassky wrote:
>> 1) I agree with you for includes and forwards, but for errors?  I would
>> have thought that the definition of "error" is that something went
>> wrong, and Tomcat should start from scratch and just render the error
>> page.  I didn't think of it as really a forward...
>>
>> 2) So you are suggesting that writing out to the
>> response.getOutputStream() as I go is wrong?  Instead, I need to:
>> a. buffer my output locally
>> b. once I am sure that it can all be created correctly, *then* I write
>> out the buffer to the response?
> 
> The buffer isn't the problem, as Pid suggests. If it were, you'd be
> getting a different error (something like "Response already committed").
> 
> The problem is that your servlet calls response.getOutputStream() and
> your error page (a JSP) calls response.getWriter(). The servlet spec
> says this is a no-no, so you get this exception thrown. It's not really
> your fault per se, but that's what's happening.
> 
> Do you have the option of generating your Excel document to memory
> (ByteArrayOutputStream) or a temporary file before streaming it to the
> client? That would be ideal, as you could wait until the entire document
> was generated before trying to send it (or any of the "Content-Type"
> headers, which would be helpful). If an error occurs, the user gets an
> error page instead of an error page disguised as an Excel document.
> 
> If the document you generate is huge, and you *must* stream it, well,
> then, you just have to do a better job of error handling in your
> servlet, then. Just catch Throwable or RuntimeException or whatever and
> take appropriate action (whatever that means... maybe putting an error
> directly in the Excel file like "OMG something bad happened... file
> truncated").
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkn7VS8ACgkQ9CaO5/Lv0PAPVwCdGEsKrB1kTjAfngKtp0HDnO6s
> X9gAoKwLjyViqjF2FtSALiCsqjT/dvFa
> =iThm
> -----END PGP SIGNATURE-----
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 5/1/2009 5:34 PM, Mark Thomas wrote:
> Long story short.
> 
> Old error handling: Reset the response. Leave usingWriter flag alone.
> New error handling: Reset the buffer. Reset usingWriter flag.

Gotcha. You're right: I hadn't read /everything/ in the bug. I thought I
had read enough (which was more than just the description, I promise :)

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkn/To8ACgkQ9CaO5/Lv0PByawCfYahCb8+dydkIwkxyR0Qo6dyL
r+sAnRjHTOg1c7x9jSCAZsbwSckqF8i7
=Ahm5
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Mark Thomas <ma...@apache.org>.
Dave Cherkassky wrote:
> Chris,
> 
> Your interpretation is correct.  I am not having any troubles with headers.

There is method to my madness ;)
You need to read the bug and associated svn commits in detail.

> So I think that this line of investigation is a dead end.

Long story short.

Old error handling: Reset the response. Leave usingWriter flag alone.
New error handling: Reset the buffer. Reset usingWriter flag.

Tomcat 4 is using the old method. Hence the problem you are seeing.

Mark


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Dave Cherkassky <dc...@djinnsoft.com>.
Chris,

Your interpretation is correct.  I am not having any troubles with headers.

So I think that this line of investigation is a dead end.

Thanks,
-- 
Dave Cherkassky
  VP of Software Development
  DJiNN Software Inc.
  416.504.1354

Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mark,
> 
> On 5/1/2009 4:21 PM, Mark Thomas wrote:
>> As I replied a couple of days ago. This is almost certainly a known
>> Tomcat issue.
>>
>> http://markmail.org/message/dmsf24ppd2nopvnz
> 
> My interpretation of the OP was that the exception ("getOutputStream
> already called") was unexpected. The custom header thing hadn't (yet)
> come up.
> 
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkn7W4MACgkQ9CaO5/Lv0PB5pgCfWkwTtUWzTbrZYyEqeF8aZxQ5
> yP4AnRpmZcckIoZTQ/s4efMHDjluYBfK
> =pXBO
> -----END PGP SIGNATURE-----
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mark,

On 5/1/2009 4:21 PM, Mark Thomas wrote:
> As I replied a couple of days ago. This is almost certainly a known
> Tomcat issue.
> 
> http://markmail.org/message/dmsf24ppd2nopvnz

My interpretation of the OP was that the exception ("getOutputStream
already called") was unexpected. The custom header thing hadn't (yet)
come up.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkn7W4MACgkQ9CaO5/Lv0PB5pgCfWkwTtUWzTbrZYyEqeF8aZxQ5
yP4AnRpmZcckIoZTQ/s4efMHDjluYBfK
=pXBO
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Mark Thomas <ma...@apache.org>.
Folks,

As I replied a couple of days ago. This is almost certainly a known
Tomcat issue.

http://markmail.org/message/dmsf24ppd2nopvnz

Mark




---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,

On 4/29/2009 10:41 PM, Dave Cherkassky wrote:
> 1) I agree with you for includes and forwards, but for errors?  I would
> have thought that the definition of "error" is that something went
> wrong, and Tomcat should start from scratch and just render the error
> page.  I didn't think of it as really a forward...
> 
> 2) So you are suggesting that writing out to the
> response.getOutputStream() as I go is wrong?  Instead, I need to:
> a. buffer my output locally
> b. once I am sure that it can all be created correctly, *then* I write
> out the buffer to the response?

The buffer isn't the problem, as Pid suggests. If it were, you'd be
getting a different error (something like "Response already committed").

The problem is that your servlet calls response.getOutputStream() and
your error page (a JSP) calls response.getWriter(). The servlet spec
says this is a no-no, so you get this exception thrown. It's not really
your fault per se, but that's what's happening.

Do you have the option of generating your Excel document to memory
(ByteArrayOutputStream) or a temporary file before streaming it to the
client? That would be ideal, as you could wait until the entire document
was generated before trying to send it (or any of the "Content-Type"
headers, which would be helpful). If an error occurs, the user gets an
error page instead of an error page disguised as an Excel document.

If the document you generate is huge, and you *must* stream it, well,
then, you just have to do a better job of error handling in your
servlet, then. Just catch Throwable or RuntimeException or whatever and
take appropriate action (whatever that means... maybe putting an error
directly in the Excel file like "OMG something bad happened... file
truncated").

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkn7VS8ACgkQ9CaO5/Lv0PAPVwCdGEsKrB1kTjAfngKtp0HDnO6s
X9gAoKwLjyViqjF2FtSALiCsqjT/dvFa
=iThm
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Pid <p...@pidster.com>.
Dave Cherkassky wrote:
> PID, thanks for your insight.
> 
> 
> Two comments about that:
> 
> 1) I agree with you for includes and forwards, but for errors?  I would
> have thought that the definition of "error" is that something went
> wrong, and Tomcat should start from scratch and just render the error
> page.  I didn't think of it as really a forward...

It can't start from scratch if you've already written to the output.
It would be like sending (pseudo)

>>snip>>

Status: 200 OK
Content-type: image/gif

2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf
2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf
2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf
2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf2020304msf0sfsfs0fsfsf
202004ladidaadidummlovelybytesUrk!CoughSplutterARGHH!Status: 500\n
Content-type: text/html\n
\n
<html>
etc

<<snip<<

The browser wouldn't understand that the new set of headers mid stream
actually represents an error.

> 2) So you are suggesting that writing out to the
> response.getOutputStream() as I go is wrong?  

If you are not already absolutely certain that the data is good, it's
risky at best.

> Instead, I need to:
> a. buffer my output locally

That would work.

> b. once I am sure that it can all be created correctly, *then* I write
> out the buffer to the response?
> 
> Am I understanding you correctly?

Yes.


p

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Len Popp <le...@gmail.com>.
There's no possible way for Tomcat to "start from scratch". If some
data has already been sent to the client, it can't be called back to
the server. What's sent is sent.

Typically, the HTTP response is buffered because the JSP handler does
that automatically. So if an error occurs before the response headers
are sent to the client, the error page can be sent instead.

I write my servlets so that they do whatever they need to do, gather
the output data, and then write the output page. If errors occur they
generally happen before any output is written.

Another way this is often handled is to just write an error message in
the middle of the web page if an error occurs. But I guess that won't
work for you because you're writing an Excel file, not a web page.
-- 
Len



On Wed, Apr 29, 2009 at 22:41, Dave Cherkassky <dc...@djinnsoft.com> wrote:
> PID, thanks for your insight.
>
>
> Two comments about that:
>
> 1) I agree with you for includes and forwards, but for errors?  I would have
> thought that the definition of "error" is that something went wrong, and
> Tomcat should start from scratch and just render the error page.  I didn't
> think of it as really a forward...
>
> 2) So you are suggesting that writing out to the response.getOutputStream()
> as I go is wrong?  Instead, I need to:
> a. buffer my output locally
> b. once I am sure that it can all be created correctly, *then* I write out
> the buffer to the response?
>
> Am I understanding you correctly?
>
> Thanks,
> --
> Dave Cherkassky
>  VP of Software Development
>  DJiNN Software Inc.
>  416.504.1354
>
>
> Pid wrote:
>>
>> Dave Cherkassky wrote:
>>>
>>> A long question:
>>>
>>> First, I have a Servlet that writes to response.getOutputStream(). Here's
>>> a snippet:
>>>  public class AuditTrailServlet extends HttpServlet {
>>>   public void doGet( HttpServletRequest request, HttpServletResponse
>>> response )
>>>     response.setContentType( "application/vnd.ms-excel" );
>>>     response.setHeader( "Content-Disposition", "attachment; filename="
>>> + fileName );
>>>
>>>     ResultSet rs = ...;
>>>     for ( int row = 0 ; rs.next(); row++ ) {
>>>       // iterate over each row in the ResultSet
>>>       for( int col = 0; fieldNameIt.hasNext(); col++ ) {
>>>         // iterate over each column in the results, write to spreadsheet
>>>                  // custom code.
>>>         // let us assume this block has a bug that occasionally throws
>>> a NullPointerException,          // but only after a bunch of cells are
>>> written first.
>>>                  response.getOutputStream().write( /* excel byte[] */ );
>>>                  // more custom code.
>>>       }
>>>     }
>>>     rs.close();
>>>       response.setStatus( HttpServletResponse.SC_OK );
>>>   }
>>>  }
>>>
>>> Second, I have the following in the web.xml file, to tell tomcat to use
>>> a custom error page:
>>>  <error-page>
>>>   <exception-type>java.lang.Throwable</exception-type>
>>>   <location>/myError.jsp</location>
>>>  </error-page>
>>>
>>> Last, here's myError.jsp:
>>>  <%@ page isErrorPage='true' %>
>>>  <html>
>>>  <body>
>>>  <h1>System Error</h1>
>>>  <p>
>>>  You have encountered a system error.
>>>  </p>
>>>   <%-- custom error processing that can't be done in a static .html page
>>> --%>
>>>   </body>
>>>  </html>
>>>
>>>
>>> So, it all seems standard and straight-forward, right?
>>>
>>>
>>>
>>> However, instead of seeing a nice custom error page when the NPE
>>> happens, I get the "ugly" Tomcat error page, and
>>> the following in the Tomcat logs:
>>>  java.lang.IllegalStateException: getOutputStream() has already been
>>> called for this response
>>>  at
>>>
>>> org.apache.catalina.connector.ResponseBase.getWriter(ResponseBase.java:709)
>>>  at
>>>
>>> org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:127)
>>>
>>>  at
>>> org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:128)
>>>  at
>>>
>>> org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:121)
>>>  at
>>>
>>> org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:137)
>>>  at
>>>
>>> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:153)
>>>
>>>  at
>>>
>>> org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:148)
>>>
>>>  at org.apache.jsp.error_jsp._jspService(error_jsp.java:284)
>>>
>>>
>>> Yes, I know -- I *am* using Tomcat 4.1 (rather than the latest and
>>> greatest) for various legacy and political reasons.
>>>
>>>
>>> But my question is this:
>>> - Is this a known bug?  Or am I doing something wrong with either the
>>> servlet, the web.xml or with the jsp page?
>>
>> I'm not sure it's a bug; logically, if you've sent a chunk of the
>> response (and therefore committed the response, sent headers etc)
>> *before* an exception happens how is Tomcat then supposed to tell the
>> client to stop and then display a different page?
>>
>> p
>>
>>
>>
>>> Thanks,
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Dave Cherkassky <dc...@djinnsoft.com>.
PID, thanks for your insight.


Two comments about that:

1) I agree with you for includes and forwards, but for errors?  I would have thought that the definition of "error" is that something went wrong, and Tomcat should start from scratch and just render the error page.  I didn't think of it as really a forward...

2) So you are suggesting that writing out to the response.getOutputStream() as I go is wrong?  Instead, I need to:
a. buffer my output locally
b. once I am sure that it can all be created correctly, *then* I write out the buffer to the response?

Am I understanding you correctly?

Thanks,
-- 
Dave Cherkassky
  VP of Software Development
  DJiNN Software Inc.
  416.504.1354


Pid wrote:
> Dave Cherkassky wrote:
>> A long question:
>>
>> First, I have a Servlet that writes to response.getOutputStream(). 
>> Here's a snippet:
>>  public class AuditTrailServlet extends HttpServlet {
>>    public void doGet( HttpServletRequest request, HttpServletResponse
>> response )
>>      response.setContentType( "application/vnd.ms-excel" );
>>      response.setHeader( "Content-Disposition", "attachment; filename="
>> + fileName );
>>
>>      ResultSet rs = ...;
>>      for ( int row = 0 ; rs.next(); row++ ) {
>>        // iterate over each row in the ResultSet
>>        for( int col = 0; fieldNameIt.hasNext(); col++ ) {
>>          // iterate over each column in the results, write to spreadsheet
>>                   // custom code.
>>          // let us assume this block has a bug that occasionally throws
>> a NullPointerException,          // but only after a bunch of cells are
>> written first.
>>                   response.getOutputStream().write( /* excel byte[] */ );
>>                   // more custom code.
>>        }
>>      }
>>      rs.close();
>>  
>>      response.setStatus( HttpServletResponse.SC_OK );
>>    }
>>  }
>>
>> Second, I have the following in the web.xml file, to tell tomcat to use
>> a custom error page:
>>  <error-page>
>>    <exception-type>java.lang.Throwable</exception-type>
>>    <location>/myError.jsp</location>
>>  </error-page>
>>
>> Last, here's myError.jsp:
>>  <%@ page isErrorPage='true' %>
>>  <html>
>>  <body>
>>  <h1>System Error</h1>
>>  <p>
>>  You have encountered a system error.
>>  </p>
>>  
>>  <%-- custom error processing that can't be done in a static .html page
>> --%>
>>  
>>  </body>
>>  </html>
>>
>>
>> So, it all seems standard and straight-forward, right?
>>
>>
>>
>> However, instead of seeing a nice custom error page when the NPE
>> happens, I get the "ugly" Tomcat error page, and
>> the following in the Tomcat logs:
>>  java.lang.IllegalStateException: getOutputStream() has already been
>> called for this response
>>  at
>> org.apache.catalina.connector.ResponseBase.getWriter(ResponseBase.java:709)
>>  at
>> org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:127)
>>
>>  at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:128)
>>  at
>> org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:121)
>>  at
>> org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:137)
>>  at
>> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:153)
>>
>>  at
>> org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:148)
>>
>>  at org.apache.jsp.error_jsp._jspService(error_jsp.java:284)
>>
>>
>> Yes, I know -- I *am* using Tomcat 4.1 (rather than the latest and
>> greatest) for various legacy and political reasons.
>>
>>
>> But my question is this:
>> - Is this a known bug?  Or am I doing something wrong with either the
>> servlet, the web.xml or with the jsp page?
> 
> I'm not sure it's a bug; logically, if you've sent a chunk of the
> response (and therefore committed the response, sent headers etc)
> *before* an exception happens how is Tomcat then supposed to tell the
> client to stop and then display a different page?
> 
> p
> 
> 
> 
>> Thanks,
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Pid <p...@pidster.com>.
Dave Cherkassky wrote:
> A long question:
> 
> First, I have a Servlet that writes to response.getOutputStream(). 
> Here's a snippet:
>  public class AuditTrailServlet extends HttpServlet {
>    public void doGet( HttpServletRequest request, HttpServletResponse
> response )
>      response.setContentType( "application/vnd.ms-excel" );
>      response.setHeader( "Content-Disposition", "attachment; filename="
> + fileName );
> 
>      ResultSet rs = ...;
>      for ( int row = 0 ; rs.next(); row++ ) {
>        // iterate over each row in the ResultSet
>        for( int col = 0; fieldNameIt.hasNext(); col++ ) {
>          // iterate over each column in the results, write to spreadsheet
>                   // custom code.
>          // let us assume this block has a bug that occasionally throws
> a NullPointerException,          // but only after a bunch of cells are
> written first.
>                   response.getOutputStream().write( /* excel byte[] */ );
>                   // more custom code.
>        }
>      }
>      rs.close();
>  
>      response.setStatus( HttpServletResponse.SC_OK );
>    }
>  }
> 
> Second, I have the following in the web.xml file, to tell tomcat to use
> a custom error page:
>  <error-page>
>    <exception-type>java.lang.Throwable</exception-type>
>    <location>/myError.jsp</location>
>  </error-page>
> 
> Last, here's myError.jsp:
>  <%@ page isErrorPage='true' %>
>  <html>
>  <body>
>  <h1>System Error</h1>
>  <p>
>  You have encountered a system error.
>  </p>
>  
>  <%-- custom error processing that can't be done in a static .html page
> --%>
>  
>  </body>
>  </html>
> 
> 
> So, it all seems standard and straight-forward, right?
> 
> 
> 
> However, instead of seeing a nice custom error page when the NPE
> happens, I get the "ugly" Tomcat error page, and
> the following in the Tomcat logs:
>  java.lang.IllegalStateException: getOutputStream() has already been
> called for this response
>  at
> org.apache.catalina.connector.ResponseBase.getWriter(ResponseBase.java:709)
>  at
> org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:127)
> 
>  at org.apache.jasper.runtime.JspWriterImpl.initOut(JspWriterImpl.java:128)
>  at
> org.apache.jasper.runtime.JspWriterImpl.flushBuffer(JspWriterImpl.java:121)
>  at
> org.apache.jasper.runtime.PageContextImpl.release(PageContextImpl.java:137)
>  at
> org.apache.jasper.runtime.JspFactoryImpl.internalReleasePageContext(JspFactoryImpl.java:153)
> 
>  at
> org.apache.jasper.runtime.JspFactoryImpl.releasePageContext(JspFactoryImpl.java:148)
> 
>  at org.apache.jsp.error_jsp._jspService(error_jsp.java:284)
> 
> 
> Yes, I know -- I *am* using Tomcat 4.1 (rather than the latest and
> greatest) for various legacy and political reasons.
> 
> 
> But my question is this:
> - Is this a known bug?  Or am I doing something wrong with either the
> servlet, the web.xml or with the jsp page?

I'm not sure it's a bug; logically, if you've sent a chunk of the
response (and therefore committed the response, sent headers etc)
*before* an exception happens how is Tomcat then supposed to tell the
client to stop and then display a different page?

p



> Thanks,


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Re: Servlets that use response.getOutputStream(): do they play nicely with Tomcat's error pages?

Posted by Mark Thomas <ma...@apache.org>.
Dave Cherkassky wrote:
> Yes, I know -- I *am* using Tomcat 4.1 (rather than the latest and
> greatest) for various legacy and political reasons.
> 
> 
> But my question is this:
> - Is this a known bug?  Or am I doing something wrong with either the
> servlet, the web.xml or with the jsp page?

That looks like https://issues.apache.org/bugzilla/show_bug.cgi?id=42409

This was fixed in 6.0.x but not any earlier version.

It is unlikely it would get backported to 4.1.x. If you wanted to patch it
yourself, the 6.0.x patch is http://svn.apache.org/viewvc?rev=721921&view=rev

HTH,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org