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 17:47:50 GMT
I just tested - adding 'removeAttribute' in PageContextImpl after
the error page solves the problem.

The problem was pretty simple:
 - exception happens 
 - jsp error page called and executed
 - normal servlet exception handling is now processing the exception
 - output is reset by the error handler.

I'm pretty sure cleaning the exception after the jsp error page
is the right thing to do. I don't know how will this deal with
the case where an exception happens in the error page - but 
I can add code to verify the exception is the same ( i.e. remove
only if the throwable is the same )


Costin Manolache wrote:

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