ERROR: Cannot forward. Response already committed.

[Christo Angelov]

Chuck,
Thank you for your previous response.

Guys,
We are porting a large application from WebLogic 6.1 to WebSphere (v.4,
Windows so far). The architecture is Struts-like and requires the following
flow:

1. POST data to a servlet, incl. an ACTION variable
2. The servlet figures out the so called "filler JSP", which is a non-visual
JSP that fills in a form bean with the posted values using jsp:setProperty
3. The appropriate action class is invoked to save the data using that bean
4. The request is forwarded to the target/next JSP, configured with the
specified ACTION
5. The JSP specifies an error page

This all works well in WebLogic, and the architecture makes a lot of sense
to us. But in WebSphere we get lots of the following:

java.lang.IllegalStateException: ERROR: Cannot forward. Response already
committed.
at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(WebAppRequestD
ispatcher.java:92)
at
org.apache.jasper.runtime.PageContextImpl.forward(PageContextImpl.java:498)
at
org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImp
l.java:599)
at _filler_0002dpage2_jsp_4._jspService(filler-page2.jsp :2)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:142)
. . .
at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.dispatch(WebAppRequest
Dispatcher.java:282)
at
com.ibm.servlet.engine.webapp.WebAppRequestDispatcher.forward(WebAppRequestD
ispatcher.java:112)
at
com.ibm.servlet.engine.srt.WebAppInvoker.doForward(WebAppInvoker.java:91)

It looks like the "filler" JSP is already printing to the output. So we
fixed the problem partially by doing "include" instead of "forward" on the
presentation JSP. However, if there is any error on the JSP, we get the
above error in the attempt to forward to the error JSP. And we pretty much
lose the actual exception which occurred on the page and made the servlet
engine try to redirect to the error page.

We have tried to really clean up the "filler" JSP to avoid any whitespace,
but we still get that error. Here is some sample code that illustrates the
problem:

filler-page2.jsp (to handle the POST like a servlet):
<%@ page isErrorPage="false" errorPage="/jsperrhandler.jsp" %>
<jsp:include page="filler-page3.jsp" flush="true"/>
<jsp:forward page="filler-page4.jsp"/>

filler-page3.jsp (the actuall "filler" JSP to capture posted data in a
bean):
<jsp:useBean id="filler" class="Filler" scope="request"/>
<jsp:setProperty name="filler" property="*" />
<%
String[] s = new String[1];
s[0]="filler";
request.setAttribute( "POPULATION", s );
request.setAttribute( "VALIDATION", s );
%>

It seems we cannot forward anymore after page3 was included. Note: WebLogic
is using JSP 1.1 where flush="true" is not required (though default) on
jsp:include. WebSphere is using JSP 1.0 and flush="true" is required!

Any suggestions short of completely re-coding the application architecture
and doing custom exception handling in every page?
Christo

[Todd Kaplinger]

<jsp:include page="filler-page3.jsp" flush="true"/>
<jsp:forward page="filler-page4.jsp"/>

This is your problem. The top level include is flushing the outputstream and
when you try to forward, the exception is thrown.
BTW. Flush is a required attribute and is has to be true for jsp 1.1
(WebSphere 4.0.x).

"Christo Angelov" <cang...@mccrackenfs.com> wrote in message
news:a8t52a$13a0$1...@news.boulder.ibm.com...

[Christo Angelov]

Thanks, Todd.
We think so, too, but the question is if there is a solution other than
completely re-architecting and re-coding the entire Web portion of a large
application that works fine on WebLogic. If not, developing portable J2EE
applications is a myth, and only people who actually try it on a large
application can appreciate the long list of incompatibilities.
I heard about a WebSphere config property for response committing, but I
can't find more info on it.

"Todd Kaplinger" <kapl...@alum.bentley.edu> wrote in message
news:a8th2l$dv0$1...@news.boulder.ibm.com...

[Todd Kaplinger]

Contact WebLogic support since they are the ones doing it incorrectly.

"Christo Angelov" <cang...@mccrackenfs.com> wrote in message

news:a9f1jm$1fh0$1...@news.boulder.ibm.com...

[Todd Kaplinger]

If one writes compliant J2EE code, then it should run on all Application
Servers. The fact that incorrect code runs on BEA and not WebSphere does
not mean that J2EE cross compatibility is failing, it means there is a bug
in one implementation.

"Christo Angelov" <cang...@mccrackenfs.com> wrote in message

news:a9f1jm$1fh0$1...@news.boulder.ibm.com...