-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael,
Michael Ludwig wrote:
> But then, this is without any filters. Let's add a filter.
>
> included HTML
> before include
> after include
>
> This is wrong. The output order is mangled. What happened?
Is this the filter you wrote in your other thread? Maybe you are not
printing your output at the right time. Or maybe you aren't flushing
buffers at the right time.
> I can make the included HTML page display correctly even in the face
> of my filter by adding the following statement directly before the
> include();
>
> out.flush();
>
> But is it the servlet's obligation to flush() the buffer before doing an
> include? The documentation for RequestDispatcher doesn't say anything to
> that effect.
Ideally, the buffer itself is always in order, and flushing the buffer
merely pushes everything out of the buffer back to the client. Since you
are doing some of your own buffering, you need to make sure that
everything is sane in that buffer.
> I can also make the included HTML page display correctly despite the
> filter by resorting to res.getOutputStream() instead of res.getWriter()
> in my servlet code. But it should work either way, shouldn't it?
That is definitely odd.
> Let's scroll back a little. What filter did I set up that provoked
> this odd behaviour? The filter is trivial, I don't think it matters.
> The decisive issue seems to be what's going on in the subclass of
> HttpServletResponseWrapper which is a helper to the filter.
>
> public ServletOutputStream getOutputStream() throws IOException {
> // getResponse().getOutputStream();
> return this.stream;
> }
>
> public PrintWriter getWriter() throws IOException {
> // getResponse().getWriter();
> return this.writer;
> }
>
> You see there are calls to the underlying response object, which are
> commented out. When I comment these lines back in, everything works
> fine. No need to flush the buffer before the include, to resort to SOS
> instead of PW, or to JSP instead of HTML.
Then you should definitely do this ;)
> So these calls on the underlying object seem to have something to do
> with the behaviour observed. Can anyone explain what's going on?
I'll bet that since the response hasn't had the writer/outputstream
choice made, the DefaultServlet makes a random decision. If your wrapper
response has made a different choice, things can get fouled up.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkk0N9MACgkQ9CaO5/Lv0PBPmgCfWNV2iez1hpXOra+GdlIRRPPe
pnYAnA2f+dmBcmuk42sxt2n/4bbfQIvb
=5Fi1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
