tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
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.

Costin






--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message