> 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 distinction not clear?
It is clear - just that 3.2 has a bug ( and fixing it was
not easy because the buffering had problems ). In 3.3 it'll
be fixed, I wasn't aware there is a problem.
> 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 runtime.
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.
It is possible to disable commit when a servlet/jsp is included,
but then we disable a reasonable function (explicit flush() ).
Or we can disable the commit just before the final/implicit out.flush()
- but again we need an explicit API call.
> Where trouble is probably being caused is that when
> flush is being called it also calls
> response.flushBuffer() both directly as well as
> indirectly (through cascaded out.flush() calls). If
> we can prevent that from happening in the 'included'
> case, perhaps that would be enough to fix the problem?
Then how do you distinguish explicit flush() calls ?
And the spec for flush() is clear IMHO - it should propagate
and commit the response.
> I believe the problem here is solely on the jasper
> side. This problem shows up whether running jasper
> inside tomcat or inside weblogic server's servlet
> engine.
There is a lot of "workaround" in jasper for tomcat
buffering problems.
Right now the buffering is more flexible ( including the
ability to probagate a buffer without commiting the response,
better conversions, more control, etc)
> Are the above suggestions useful? I can test them out
> on my own because I have a framework for overriding
> and extending most all jasper behavior through
> subclassing, but I am not a tomcat cvs committer nor
> am I well setup yet to put the changes directly into
> jasper code. I want to get more directly involved,
> but I don't have the luxury of time just yet. Just
> researching this problem is costing a lot of money so
> far.
:-(
I'll try to commit some changes tonight. I'm going to try
with the flushBuffer() - it seems to me this is the right
way to do it ( and you can still do explicit flush() inside an
included jsp and get the expected behavior )
> As for test cases, the problem should show up if you
> try to include a .jsp file and then subsequently in
> the calling page or servlet do something that requires
> an uncommitted response (such as a redirect).
Can you send at least 2-3 JSP pages and a test scenario ?
We need to include this in the nightly tests to make sure
it'll be fixed in the final release.
Costin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
