tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: costin: fix reverted
Date Wed, 06 Nov 2002 15:33:44 GMT
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.


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

View raw message