tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mel Martinez <melaqu...@yahoo.com>
Subject Re: TC3.2.1 - response commit on included JSPs
Date Fri, 23 Feb 2001 22:55:30 GMT

--- cmanolache@yahoo.com wrote:
> 
> 
> My expectation ( as a java user ) would be that if I
> call 
> out.flush() the data will be written to the final
> destination.
> 

I won't contest that, but I would suggest considering
the idea that the final, or intended destination is
not necessarily the browser.  In the case of an
included resource, it is the calling servlet that is
acting as client to the included resource.  In good OO
design, it should be in the control of that client
what to do with the data that has been 'committed' by
the included resource.

 
> That's easy to change. In any case - the 
> ServletResponse.flushBuffer should go all the way -
> that's
> specified in RD.include(). 
> 

Here is perhaps some clarification, from the proposed
Servlet 2.3 spec. [sec 8.3 Include]:

"The target servlet has access to all aspects of the
request object, but can only write
information to the ServletOutputStream or Writer of
the response object as well as
the ability to commit a response by either writing
content past the end of the response buffer
or explicitly calling the flush method of the
ServletResponse interface. The included
servlet cannot set headers or call any method that
affects the headers of the response. Any
attempt to do so should be ignored."

This implies that our proposed solution of using
JspWriterImpl.flushBuffer() everywhere (in the JSP
finally{} clause and in PageContextImpl.include())
instead of out.flush() is the intended behavior.  I am
not exactly impressed with this design spec, but I'll
accept it.

So that would seem to fix things.  However...

Looking at the Tomcat 3.2.1 code, I see that this
situation is still further broken in this regard
because inside inside the
org.apache.tomcat.facade.RequestDispatcherImpl class
the include() method _explicitely_ (and incorrectly)
calls response.flushBuffer().  I realize from the
comments that it is trying to preserve session info
from being blasted by an included servlet - but that
patch is only needed because the design allows the
included servlet to commit the response!

The problem with that call being there is it
automatically forces the commit - even if the included
resource would not have.  This simply is not
acceptable.

I realize also, from looking around in the CVS
repositories that the 'facade' package is history so I
am not familiar yet with how newer versions of tomcat
implement the include() method.  Have they removed
this offending call?

It becomes clearer and clearer to me that I'm going to
have to swallow upgrading to a newer version of Tomcat
than 3.2.1.  Which version should I jump in on? 
Sigh...

> 
> The java.io comment seems clear to me - all bytes
> should
> go to their intended destination.
> 

The intended destination of a stream is determined by
the calling code, not the included stream itself
because the calling code is the determinant of the
target.

In theory, one could build an include() mechanism that
substitutes a separate buffer (i.e. a
ByteArrayOutputStream) for the servlet output stream
when passing a response object over to the included
resource.  In that scenario, a flush() by an included
resource would properly flush data to the buffer, but
the calling page would still have control over whether
it went to the browser.  

I agree, though that this does not match what the
proposed servlet 2.3. spec (above) allows.  I would
argue that the proposed spec is not necessarily the
best design.

Oh well.  At the moment, I need to get past the broken
RequestDispatcher.include() in TC 3.2.1.

Cheers,

Mel


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - Buy the things you want at great prices! http://auctions.yahoo.com/

Mime
View raw message