tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Curwen" <>
Subject RE: using an error page for JSP pages and buffer flushing
Date Wed, 28 Apr 2004 21:24:13 GMT
> Am I off-topic again:)?

Not off-topic, but you're kind of repeating what I've just said. ;)

more below...

> -----Original Message-----
> From: Yansheng Lin [] 
> Sent: Wednesday, April 28, 2004 3:55 PM
> To: 'Tomcat Users List'
> Subject: RE: using an error page for JSP pages and buffer flushing
> 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.  

I don't have a problem with 'buffer overflow' in the classic sense (of
it being a bad thing when it occurs, and a potential wedge-point for
hacks).  My problem is absolutely related to buffer size, since it goes
away when I specify an arbitrarily large buffer.

> > 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.

Yes precisely, that's exactly what's happening. And it's not *me*
commiting the response, it's the container when it flushes the buffer. 

> 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:).

As do I. But flushing the buffer means that this central mechanism won't
always work... in those cases when the container inappropriately(?)
tries to forward to the centrally configured error page, even after the
response is committed. I was just kinda surprised by this behaviour.  It
makes no difference to the end-user, they see a partial HTML page. But
it's certainly(?) possible for the container to determine if a response
is commited, and thus avoid doing something *it knows will fail*.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message