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 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: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
