" if that destination is another character or
byte stream, flush it."
In this case, the destination is the servlet output
stream - and it has to be flushed.
That is only because the particular servlet engine
implementation implements the ServletOutputStream of
the Response object
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
Re: out.flush() sets the 'committed' state in the
response in tc3.2.1 JspWriterImpl.
--- [EMAIL PROTECTED] wrote:
Hi Mel,
First, JspWriter needs to be flushed at the end of
the page - it has a
buffer, and if the buffer is not commited the data
will be lost.
There is a method (
--- [EMAIL PROTECTED] wrote:
Second, while there is a flushBuffer() method in
JspWriterImpl, this method is NOT a part of the
javax.servlet.jsp.JspWriter interface nor is it
public
(it is protected).
We can make it public - and the generated servlets
already depends
on jasper
On Wed, 21 Feb 2001, Mel Martinez wrote:
IMHO out.flush() should not commit the response. Only
response.flushBuffer() should commit the response.
And response.flushBuffer() should not be called from
an inside an 'include' request.
Hi Mel,
First, JspWriter needs to be flushed at the end
Two points come to mind here. First off, I totally
agree that at the end of the page the buffer should be
'committed' to the underlying ServletOutputStream -
but I also believe that the ServletResponse should not
be committed from within a dynamically included
servlet or JSP page - is that
The problem is that flush() must still be executed
as expected,
i.e. if an included JSP or servlet is actually
calling flush(),
it expects the response to be commited.
But does that necessarily mean to commit it to the
browser? Or should it instead just commit it to the
buffer
--- Incze Lajos [EMAIL PROTECTED] wrote:
Maybe it's not correct in general but the JSP 1.1
syntax
contains the flush="true" attribute - obligatory in
case
of jsp:include. So, it's inconvenient but tomcat3 is
an
jsp 1.1 implementation. Am I missing something?
incze
The JSP 1.1 spec
Hi folks,
I've spotted what looks like a bug in the jasper
compiler of TC3.2.1 - if this is old news, just let me
know and I'll shut up.
There are two parts to this:
1) the _jspService() method generated by the jasper
compiler uses a try{ ... }catch{...}finally{...}
block. The finally clause