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 15:23:49 GMT
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.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message