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>
