Remy Maucherat wrote: >> In any case, I expect this to have caused some weird behavior >> for normal forward - since forward doesn't seem to really flush/close >> as it was supposed to do ( unless response is not facade - does >> this case ever happen ? ). A bit strange no other test detected that, >> normal servlets don't have flush/close that the jsp page had. > > No, that wouldn't work. > forward does a fake flush/close, because some further error page > processing may occur (based on the status code, for example). > > I think we'll have to do the commit in the JSP error page itself (and > call close right away in the case, rather than flush). I hope it's doable.
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 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. 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. Costin -- To unsubscribe, e-mail: <mailto:tomcat-dev-unsubscribe@;jakarta.apache.org> For additional commands, e-mail: <mailto:tomcat-dev-help@;jakarta.apache.org>
