Costin Manolache wrote:
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
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 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>