A hack for this is to use the syntax:
request.getRequestDispatcher(page).include(request, response);
The failing of this is the page is written to the response and not the body.
That can be fixed by passing the current out in the request and having a set
of included page tags (on the included page) dump their body content to the
out in the request and not the response. It's annoying but it works.
-Jeff Ward
-----Original Message-----
From: Eduardo Pelegri-Llopart [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 22, 2001 1:00 PM
To: [EMAIL PROTECTED]
Subject: Re: BodyTags don't allow jsp:includes?
Is is a bug in JSP 1.1. Arguably the biggest one, and motivated by
constraints on the underlying Servlet infrastructure.
This is fixed in Servlet 2.3 & JSP 1.2. A very good reason to move to
the platforms supporting the new specs.
Sorry, we knew it was a hard imposition but it was the least of several
evils.
- eduard/o
Garrick Toubassi wrote:
>
> I am running into an issue whereby it appears that BodyTags don't seem to
> allow jsp:includes in them (exception attached). It seems like this makes
> BodyTags basically useless with a JSP body content, because restricting
> people to not use jsp:include is unreasonable and certainly very subtle.
> For instance, Tomcat comes with an "iteration example". If you add a
simple
> jsp:include in the index.jsp ($TOMCAT_HOME/webapps/iteration/index.jsp):
>
> <tlt:iteration name="departmentName" type="String"
> group="<%= org.getDepartmentNames()%>">
> <tr>
> <td> <jsp:include page="test.jsp" flush="true"/><a
> href="list.jsp?deptName=<%= departmentName %>"><%= departmentName
> %></a></td>
> </tr>
> </tlt:iteration>
>
> You get the following exception:
>
> java.io.IOException: Illegal to flush within a custom tag
> at javax.servlet.jsp.tagext.BodyContent.flush(BodyContent.java:87)
> at
>
org.apache.jasper.runtime.PageContextImpl.include(PageContextImpl.java:407)
> at
>
_0002findex_0002ejspindex_jsp_3._jspService(_0002findex_0002ejspindex_jsp_3.
> java:116)
> at
> org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:119)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
>
org.apache.jasper.servlet.JspServlet$JspServletWrapper.service(JspServlet.ja
> va:177)
> at
> org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:309)
> at
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:382)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
> at
> org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:387)
> at org.apache.tomcat.core.Handler.service(Handler.java:263)
> at
> org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:371)
> at
>
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:78
> 6)
> at
> org.apache.tomcat.core.ContextManager.service(ContextManager.java:732)
> at
>
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection(HttpC
> onnectionHandler.java:210)
> at
> org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:407)
> at
> org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
> at java.lang.Thread.run(Thread.java:484)
>
> Has anybody seen this issue before or have any comments on if it is the
> "desired" behavior? Seems like a bug to me.
>
> thanks
>
> gt
