Operating System: All
Created an attachment (id=304)
File containing a simple test code to illustrate the problem
Excerpt from the Servlet 2.5 Spec
Forces any content in the buffer to be written to the client. A call to this
method automatically commits the response, meaning the status code and headers
will be written.
Hum....I did try your unit test and the flush happens properly. I've also
verufies with the TCK team we have test for it:
TCK does have a few tests cover flushBuffer method:
verifying content, header after calling flushBuffer;
verifying IllegalArgumentException thrown calling
sendError or send Indirect after flushBuffer called
I did test your web-app with Jetty and Tomcat, and got the same result
Closing as invalid.
Sorry, for the long delay. I'll reopen the issue as discussed with
Jeanfrancois. Hope I can find some time to attach a new test code very soon.
Ok go ahead and re-open the bug (I will investigate more), but what I
read here make sense. Now I don't understand why Jetty and Tomcat gives
the same result. I need to take a closer look at the Spec
Heiko Wagner wrote:
> I have been debugging the flushBuffer() method. I according to my findings
there is a problem with the filtering subsystem, that causes the buffer content
not to be written upon call to flushBuffer(). The data is sent when the service
method is left. The Servlet 2.5 spec imposes two requirements:
> Forces any content in the buffer to be written to the client. A call to this
> method automatically commits the response, meaning the status code and
> will be written.
> 1) If the request has not been committed, it must be committed, thus writing
> This is working. The flushBuffer() causes the header to be written to the
internal buffer and isCommitted() returns true.
> (This might make the TCK believe that anything is working properly)
> 2) The method must ensure that all data, that has been buffered, must
be "written to the client". So it is also required that the actual data is sent
over the wire.
> This is not working. The data send is triggered by the exit from the service
method, but not from the flushBuffer().
> I hope this clears up the problems I encountered. I modified my test code a
bit and set the content length of the response object, since this is a
requirement of the http spec. So my suggestion would be to reopen the issue and
add my fixed test code. I also could add a war for convenience. Can you agree
Try to enable it in build 23.
Updated the wrong issue Still marking it as started.
Fixed. Thanks for the unit test.
Checking in DefaultProcessorTask.java;
new revision: 1.9; previous revision: 1.8