tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: costin: fix reverted
Date Wed, 06 Nov 2002 15:43:01 GMT
Remy Maucherat wrote:

>> Can you point me to the code doing this extra processing ?
>> I'm a bit confused:
>> - for jsps ( with flush-in-release ) that just can't work, since the
>> flush is already done by the jsp page.
>> - the comment ( or the message ) in forward is probably wrong.
>> - my bigger question is when is the response not a facade ? My
>> understanding
>> is that facades are used all the time, so the second part of the if will
>> never happen
> That code was already there before the facades. I don't think it is used
> anymore, but would leave it anyway in 4.1.x (it could be removed in 5).

I already reverted the patch in 4.1.x - it's too dangerous for the 
stable tree.

So you are saying that forward() used to do a flush, but it was
changed when facades where added to just set the flag - to improve
the error handling. Sounds consistent with the behavior we have now.

Could you add a little comment ( or at least remove the debug message
that says 'flushing' ) ? The new behavior ( no real flush ) seems 


>> I do see your point - if forward() flushes then the extra error
>> processing is broken. That's another argument to not do the flush() in
>> release() :-) And it does explain who is generating the stack trace.
> The error page and status report processing is in
> ErrorReport/DispatcherValve. That's where the stack trace is output
> unless the response has been committed (by flushing usually).

>> I have a feeling we just need to clear the error flags after the jsp
>> error page - I'm pretty sure the jsp error page was executed and the data
>> is in the out buffer. Somehow the servlet error processing kicks in and
>> overrides the jsp error page.
> Yes, that's likely the right explanation.
> Remy

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

View raw message