Christopher Schultz schrieb am 20.11.2008 um 10:05:48 (-0500):
> Keep reading for more.
>
> Michael Ludwig wrote:
> >> So, when this code is called from an "include" call to the request
> >> dispatcher, it doesn't appear in your filter's captured output? Or,
> >> it doesn't appear in the final response sent to the browser (or
> >> both)?
> >
> > Both.
>
> Okay, but only when using Writer, right? OutputStream works properly?
Yes, OutputStream worked properly.
> > Closing the stream would flush it, wouldn't it?
>
> It should, but it doesn't hurt to be tidy. I seem to remember C
> library routines that would truncate output if you didn't explicitly
> flush the buffers.
Okay. True, it doesn't hurt to be tidy.
> >> You could even add a method to your wrapper that will tell you
> >> which style of output is being used on the response: output stream
> >> versus writer. Then, you could avoid the try/catch which will make
> >> your code run a bit faster. Faster filters are always better than
> >> slow ones ;)
> See Chuck's response for performance considerations. IMO, since you
> have the opportunity to avoid the exception, you may as well take it.
I may add it. But DefaultServlet will never know about it. It will
continue to first call getOutputStream() and handle the exception by
calling getWriter().
> >>> public void flushBuffer() throws IOException {
> >>> this.buffer.flush();
> >>> }
> >> Flushing a ByteArrayOutputStream doesn't do anything. What you
> >> really want to do is flush all the OutputStream and Writer objects
> >> you've created when calls to getOutputStream and getWriter come in.
> >
> > Okay.
>
> Oh, and then call getResponse().flushBuffer(), too. The caller expects
> that the flush goes all the way back to the real client response.
I don't understand where I should call getResponse().flushBuffer().
In HttpResponseCatcher.flushBuffer(), as above?
> >>> public void write( byte[] b) throws IOException {
> >> Do you get stack traces printing from this method?
> >
> > No.
> >
> >>> public void write( byte[] b, int off, int len) throws IOException {
> >> How about this one?
> >
> > Yes.
>
> That's good. I guess the caller is preferring to use sections of a
> byte buffer instead of just a bare one. That's not surprising, and
> shouldn't itself be an indication of a problem. If you look at the
> code for DefaultServlet, you probably will see calls to write(byte[],
> int, int) and none to write(byte[]).
Yes, that's true. The latter might be implemented in terms of the
former. As the length is already known when calling, the call can also
be made to the real method straight away.
> > Thanks for this suggestion [of using TeeOutputStream]. My intent is
> > simply to understand servlets. On hitting this include oddity, I
> > just decided to track it down, thinking I would learn from it.
> > (Which I'm doing thanks to your help.)
>
> Learning is always good. Hopefully you'll lurk on the list from here
> on out. :)
Sure, time permitting. :-)
> You should post your entire filter next time, if only so André can see
> it ;)
Yes, I'll resubmit it to your scrutiny when it's ready ...
Thanks for all the help.
Michael Ludwig
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
