Well, Lance, congratulations :-) You've run into one of murky areas, which
we're trying *very* hard to fix.
Here's how it works. Each page has its own buffered writer into which all the
html output and output from other tags (useBean) etc goes into. When the buffer
size is reached, it is either flushed (if autoFlush is true) or an IOException
is thrown (if autoFlush is false). Also, the first time is when
response.getWriter() is obtained by the per-page buffered writer. This is all
fine and dandy until you go from one JSP to another JSP or servlet using
RequestDispatcher. Also another reason for this type of buffering is so that
you can make sure most of the real output is buffered until you are sure there
are no exceptions. That way the buffer is not flushed until the buffer size is
reached. IF there was an error earlier then the buffer is cleared and the
errorpage output can be sent to the browser.
When you do an include, there is no obvious way of communicating the buffered
writer to the receiving active source (its possible for JSPs but not for
servlets). That is why the JSP 1.0 spec pretty much insisted that the "flush"
attribute of the jsp:include directive can only be true. That is, the per-page
buffered writer *has* (and will only) be flushed before calling rd.include().
If you are using JSP 1.0 final, and you are saying <jsp:include page="...."
flush="true"/> and it doesn't get you the expected output in the correct order,
then I'd file a bug with the servlet/jsp engine vendor. Did you see this
problem with the JSWDK 1.0 final release? Can you try it, if you haven't used
it?
Lance Lavandowska wrote:
> Thanks, Anil, for pointing these facts out.
>
> So, does the fact that each page has its own buffer have an impact on how
> the html is produced to the browser? I can see how the calling page may
> hold its buffered output while the called page flushes its buffer. But
> then how come explicitly calling "out.flush()" before doing the include
> didn't help?
>
> Isn't the <jsp:include .../> tag essentially the same thing as rd.include?
> Well, it is less typing and easier to read, but it hasn't changed the
> results.
>
> The java generated from the jsp is correct, but the html output is wrong
> (as described originally).
>
> Lance Lavandowska
> Software Engineer
> http://www.AgDomain.Com
>
> -----Original Message-----
> From: Anil Vijendran <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Date: Friday, August 20, 1999 2:50 PM
> Subject: Re: RequestDispatcher().include() problem
>
> >Lance,
> >
> >Each JSP page uses its own buffer. This is unrelated to the stream that
> the
> >Servlet Engine uses.
> >
> >Why don't you just use <jsp:include page="my.jsp"..../> instead of
> rd.include()
> >?
> >
> >Lance Lavandowska wrote:
> >
> >> I'm not sure if this is a buffering issue or what, but I am getting
> >> improper display from a jsp page that uses an rd.include inside of a
> >> table. Following are some "code fragments".
> >>
> >> The jsp page looks like this:
> >> <Table>
> >> <% rd("my.jsp").include(req, resp); %>
> >>
> >> <TR>
> >>
> >> where the included my.jsp prints out a couple table rows.
> >>
> >> The java that gets generated looks like this:
> >> out.print("<Table>\n");
> >> <% rd("my.jsp").include(req, resp); %>
> >> out.print("\n\n<TR>\n");
> >>
> >> everything cool so far.
> >>
> >> But when the html is generated, the rows printed by my.jsp are *above*
> the
> >> <Table>:
> >>
> >> <TR><TD>1</TD></TR>
> >> <TR><TD>2</TD></TR>
> >> <Table>
> >>
> >> <TR>
> >>
> >> I've tried putting an out.flush() and out.println() before the
> rd.include
> >> (to make it flush the PrintWriter) but neither one changed the final
> html.
> >>
> >> I would appreciate any suggestions.
> >>
> >> Lance Lavandowska
> >> Software Engineer
> >> http://www.AgDomain.Com
> >>
> >>
> ==========================================================================
> =
> >> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> >> of the message "signoff JSP-INTEREST". For general help, send email to
> >> [EMAIL PROTECTED] and include in the body of the message "help".
> >> For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
> >
> >--
> >Peace, Anil +<:-)
> >
> >=========================================================================
> ==
> >To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> >of the message "signoff JSP-INTEREST". For general help, send email to
> >[EMAIL PROTECTED] and include in the body of the message "help".
> >For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
> >
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
> For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
--
Peace, Anil +<:-)
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
For JSP FAQ, http://www.esperanto.org.nz/jsp/jspfaq.html
