tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Yansheng Lin" <yansheng....@silvacom.com>
Subject RE: using an error page for JSP pages and buffer flushing
Date Wed, 28 Apr 2004 20:55:17 GMT
Sorry I might've misunderstood your issue.  We have hundreds of jsp pages,
some of them generate very large html documents(>64k).  With the exception
of these pages taking longer than the others, there is no problem with
buffer overflow.  So I am not sure if your problem is related to the buffer
size.  

> ErrorDispatcherValve[localhost]: Exception Processing 
> ErrorPage [exceptionType=java.util.MissingResourceException,
> location=/error/locale.jsp]
> java.lang.IllegalStateException

When an exception occurs, the control is forwarded to the error handler, in
your case: /error/locale.jsp. But if you already committed your response in
your servlet/jsp, you cannot forward the control anywhere.  Otherwise you
would get a IllegalStateException.  Maybe that's what's happening here.

For your second question, I think I asked a similar one a while ago on the
list.  Basically from the answers I got, there is no one best way/mechanism
to handle all the errors.  There is system errors, application errors,
invalid service errors, etc...  For each type of error, you would likely
want to handle them accordingly.  Personally, for application level
exceptions, I use declarative exception handling mechanism for most of the
cases.  I just find it easier to manage them in one place:).

Am I off-topic again:)?

-Yan Lin
Sun Certified J2EE Web Component Developer
http://j2e-translate.sourceforge.net (need help)

-----Original Message-----
From: Mike Curwen [mailto:gb_dev@gb-im.com] 
Sent: April 27, 2004 15:49
To: 'Tomcat Users List'
Subject: RE: using an error page for JSP pages and buffer flushing


> -----Original Message-----
> From: Yansheng Lin [mailto:yansheng.lin@silvacom.com] 
> Sent: Tuesday, April 27, 2004 4:34 PM
> To: 'Tomcat Users List'
> Subject: RE: using an error page for JSP pages and buffer flushing
> 
> 
> I guess the whole issue is implementation specific.  If you 
> don't think any of your error page will exceed 32k, the 
> following directives would be
> sufficient:
> <%@page buffer="32k" %>
> <%@page autoFlush="false" %>

It's not my error page that exceeds 32k, it's any of my pages on which
Exceptions might occur (which is basically all of them).  But some pages
are very small, and other pages (which list the contents of a dynamic
query, which potentially returns many many rows) might be very large.
So I think I'll need to be going through each page and "guess" what my
maximum pagesize would 'usually' be, and set that particular page's
buffer accordingly.  I'll maybe miss some edge cases, but I don't see
another way.  
 
> 
> For the second question, if you just want one error-page for 
> all(most of) the errors, you can wrap all the exceptions in a 
> ServletException and then rethrow it.  And in your web.xml, 
> you only define one error page for ServletException.

I wrote: "So I'd like to handle all sorts of errors with the error-page
mechanism." and I maybe should have been clearer. I don't want one
error-page. I want to use the one mechanism, but *multiple* pages. For
each type of Exception I want to handle separately, I have an error-page
mapped. For all else, use the 'default' error Page. So no, I wouldn't
catch Throwable and wrap it in ServletException.  Though this does lead
to another idea (probably not worth it).

I could catch the Throwable, check if response.isCommited() and if not,
rethrow the exception (and let the container-configured error-pages deal
with it).  If the response was commited though, I could simply do the
"best effort" and send the exception to the output stream, flush and
close it, and consider it "done".  I could only hope that feedback would
show up with whatever malformed HTML had made it out, up to the point in
processing where the error occurred. 

Does that sound like an insane plan?

> 
> -Yan Lin
> Sun Certified J2EE Web Componenet Developer 
> http://j2e-translate.sourceforge.net (need help)
> 
> 
> -----Original Message-----
> From: Mike Curwen [mailto:gb_dev@gb-im.com] 
> Sent: April 27, 2004 13:54
> To: tomcat-user@jakarta.apache.org
> Subject: using an error page for JSP pages and buffer flushing
> 
> 
> I've defined an error page in web.xml:
> 
> <error-page>
>   <exception-type>java.util.MissingResourceException</exception-type>
>   <location>/error/locale.jsp</location>
> </error-page>
> 
> Which works *most* of the time, for displaying that error 
> page when I have that Exception type.  But every so often, I 
> get a partial HTML response, and then the source just stops 
> (cuts off).  In the local_host log I see:
> 
> ErrorDispatcherValve[localhost]: Exception Processing 
> ErrorPage [exceptionType=java.util.MissingResourceException,
> location=/error/locale.jsp]
> java.lang.IllegalStateException
> 
> Which means (I'm assuming) that my JSP buffer has been 
> flushed (which is the partial page that I see in my browser) 
> and the container itself is causing the 
> java.lang.IllegalStateException when it attempts to send me 
> off to the error page.
>  
> I have a couple questions regarding this area:
> 
> 1)  I've attempted to add a <%@ page 
> errorPage="/error/locale.jsp" %> directive, and it seems to 
> do the same thing. So is there no mechanism that "more 
> deftly" handles errors like this?  Or when we use any sort of 
> error-handling, will we have to also adjust our page buffer 
> where necessary?
> 
> 2)  I don't like the idea of limiting myself to a single 
> errorPage per JSP page. There are many types of Exceptions 
> that might occur in a page. Well, perhaps not in a strict 
> model-2 page ;) So I'd like to handle all
> sorts of errors with the error-page mechanism.   Is there an accepted
> 'best practice' in regards to the usage of errorPage (JSP 
> directive) and/or error-page (in web.xml)?
> 
> 
> 
> ------------------------------------------------
> mike curwen                    
> intermediate programmer
> globally boundless
> 
> 204 885-7733  ext 229
> www.globallyboundless.com
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-user-help@jakarta.apache.org
> 


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


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


Mime
View raw message