java.lang.IllegalStateException: Response already committed

Splash Forums PrettyFaces Users java.lang.IllegalStateException: Response already committed

This topic contains 15 replies, has 3 voices, and was last updated by  Christian Kaltepoth 5 years, 1 month ago.

Viewing 15 posts - 1 through 15 (of 16 total)
  • Author
    Posts
  • #18316

    Arun Kumar
    Participant

    The environment Weblogic 10.3.6, JSF 2.0, Prettyfaces – 3.3.3

    web.xml:

    <web-app …>

    <context-param>

    <param-name>com.ocpsoft.pretty.BASE_PACKAGES</param-name>

    <param-value>none</param-value>

    </context-param>

    <filter>

    <filter-name>Pretty Filter</filter-name>

    <filter-class>com.ocpsoft.pretty.PrettyFilter</filter-class>

    </filter>

    <filter-mapping>

    <filter-name>Pretty Filter</filter-name>

    <url-pattern>/*</url-pattern>

    <dispatcher>FORWARD</dispatcher>

    <dispatcher>REQUEST</dispatcher>

    <dispatcher>ERROR</dispatcher>

    </filter-mapping>

    </web-app>

    pretty-config.xml:

    <url-mapping id=”form-map”>

    <pattern value=”/#{ /forms.*/ path }” />

    <view-id value=”#{forms.computeViewPath}” />

    </url-mapping>

    faces-config.xml:

    <lifecycle>

    <phase-listener>com.ocpsoft.pretty.faces.event.MultiPageMessagesSupport</phase-listener>

    </lifecycle>

    The error I’m getting is –

    Root cause of ServletException.

    java.lang.IllegalStateException: Response already committed

    at weblogic.servlet.internal.ServletResponseImpl.objectIfCommitted(ServletResponseImpl.java:1629)

    at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:637)

    at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:602)

    at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:128)

    at javax.servlet.http.HttpServletResponseWrapper.sendError(HttpServletResponseWrapper.java:128)

    at com.ocpsoft.pretty.faces.application.PrettyRedirector.send404(PrettyRedirector.java:110)

    at com.ocpsoft.pretty.faces.config.dynaview.DynaviewEngine.processDynaView(DynaviewEngine.java:108)

    at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.afterPhase(PrettyPhaseListener.java:109)

    at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:185)

    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)

    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)

    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)

    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)

    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)

    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)

    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)

    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)

    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)

    at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)

    at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)

    at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)

    at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)

    at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:380)

    at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)

    at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)

    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)

    at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:145)

    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)

    at weblogic.servlet.internal.RequestDispatcherImpl.invokeServlet(RequestDispatcherImpl.java:527)

    at weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:253)

    at com.ocpsoft.pretty.PrettyFilter.doFilter(PrettyFilter.java:119)

    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)

    at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)

    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)

    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3730)

    at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3696)

    at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)

    at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)

    at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2273)

    at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2179)

    at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1490)

    at weblogic.work.ExecuteThread.execute(ExecuteThread.java:256)

    at weblogic.work.ExecuteThread.run(ExecuteThread.java:221)

    >

    The last line in the debug log comes from the ‘forms’ bean the function looks like this (edited for brevity):

    public String computeViewPath() {

    StringBuilder returnPath = new StringBuilder();

    logger.debug(“Return path: ” + returnPath.toString()); // I get this output which looks correct

    return returnPath.toString();

    }

    I saw an earlier post by Chritian regarding a similar issue and Phase, but I haven’t been able to find any documentation about RENDER_VIEW phase etc. I have also tried commenting out the <lifecycle> MultiPageMessagesSupport section from faces-config.xml

    #22449

    Could you tell us which value your dynaview method returns when this exceptions occurs? I think this is important for getting to know what is happening here.

    #22450

    I just checked the code. Actually this error happens in a code branch that handles exceptions thrown while forwarding to the viewId returned by the dynaview method. But unfortunately, due to the error you are seeing, we don’t see the cause for this.

    I just added an additional log statement to the code. Could you perhaps give 3.3.4-SNAPSHOT a try? Please see the following page for all details on how to use the snapshots:

    https://github.com/ocpsoft/prettyfaces/wiki/Snapshots

    #22451

    Arun Kumar
    Participant

    Christian, thanks for your help.

    I have used 3.3.4-SNAPSHOT in the pom.xml and used the same version in pretty-config.xml (without SNAPSHOT)

    I now get the following error. The first line shows the return value of my dynaview bean:

    Returning: /forms/home.jsf #This is the value that my dynaview returns

    ERROR [[ACTIVE] ExecuteThread: ’11’ for queue: ‘weblogic.kernel.Default (self-tuning)’] (DynaviewEngine.java:107) – Failed to process dynaview

    javax.faces.FacesException: javax.servlet.ServletException

    at com.sun.faces.context.ExternalContextImpl.dispatch(ExternalContextImpl.java:544)

    at com.ocpsoft.pretty.faces.config.dynaview.DynaviewEngine.processDynaView(DynaviewEngine.java:101)

    at com.ocpsoft.pretty.faces.event.PrettyPhaseListener.afterPhase(PrettyPhaseListener.java:109)

    at com.sun.faces.lifecycle.Phase.handleAfterPhase(Phase.java:185)

    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:103)

    at com.sun.faces.lifecycle.RestoreViewPhase.doPhase(RestoreViewPhase.java:107)

    at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:114)

    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:308)

    at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)

    at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)

    at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:301)

    at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)

    at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)

    Caused by: java.lang.NullPointerException

    at com.sun.faces.context.flash.ELFlash.doLastPhaseActions(ELFlash.java:604)

    at com.sun.faces.context.ExternalContextImpl.responseFlushBuffer(ExternalContextImpl.java:853)

    at com.sun.faces.application.view.JspViewHandlingStrategy.buildView(JspViewHandlingStrategy.java:151)

    at com.sun.faces.lifecycle.RenderResponsePhase.execute(RenderResponsePhase.java:96)

    at com.sun.faces.lifecycle.Phase.doPhase(Phase.java:97)

    at com.sun.faces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:135)

    at javax.faces.webapp.FacesServlet.service(FacesServlet.java:309)

    #22452

    Ew yuck! That looks like a JSF bug! Are you using the Flash Scope at all?

    #22453

    Arun Kumar
    Participant

    No just searched all the code and there isn’t any getFlash or even #{flash..} in either java or xhtml.

    #22454

    Arun Kumar
    Participant

    Ok here are a few more things I tried after reading up about this. I turned off all filters except for Pretty Faces. Then inside pretty-config.xml I added this:

    <url-mapping id=”home”>

    <pattern value=”/forms/home” />

    <view-id value=”/forms/home.jsf” />

    </url-mapping>

    Also tried pattern value=”/forms/home$”

    But even this causes the same original error (when trying to navigate to ctx/forms/home) , and I can confirm that it is not going into dynaview Bean. Not sure if this helps or clarifies anything.

    Thanks again for both your help.

    #22455

    What happens if you create just a very simple, bare minimal app with PrettyFaces and one view file on weblogic. Do you have the same problem?

    #22456

    Hey Arun,

    I think we already hat similar bug reports. At least the exception sounds familiar. :)

    If I remember correctly it was a Mojarra bug. Which version are you using?

    And perhaps have a look at the other posts regarding this:

    http://ocpsoft.org/support/search.php?q=doLastPhaseActions

    #22457

    Arun Kumar
    Participant

    Just an update. I went crazy tearing everything down, and it was finally when I took everything out that I realized that it was a missing .xhtml page! Its strange though that there wouldn’t be a simpler way to tell from the log files that a file did not exist. This was why trying not just dynaview, but rewrite, and finally my own custom filter all failed with more or less the same error. Anyway this issue has been resolved, there are a few posts through google about these errors showing up on a 404 error, but it took me a while to figure it out. I just hope this helps someone facing a similar issue.

    Thanks again for all your help.

    #22458

    Hey Arun,

    thanks for giving this update for the issue your had. I’m sorry to hear that it caused so much trouble. However I think this is really a Mojarra issue. I had a look at the Mojarra source back then and there was some strange stuff happening there (see my post in one of the threads regarding this).

    However. I hope this will help others who run into that issue.

    Thanks

    Christian

    #22459

    Arun Kumar
    Participant

    Hi Christian,

    I took a look at your comments in the other post about it probably being an issue with Mojara 2.1.2. It does seem like a 404 error ought not throw up all these other errors.

    In the case of my project since this is a WAR targeted for WL 10.3.6 (so much for cross-platform Java) apparently WL requires JSF 2.0 to be deployed as a shared library on the server before it can referenced by any applications. I can’t even use another version of JSF, only the WL provided one.

    I opened the shared library jsf-2.0.war in (wlserver/common/deployable-libraries) and found it only contained 4 libraries in WEB-INF/lib – glassfish.jsf_1.0.0.0_2-0-4.jar, glassfish.jstl_1.2.0.1.jar, javax.jsf_1.0.0.0_2-0.jar, wls.jsf.di.jar

    Opening the glassfish.jsf..jar showed me the com.sun.faces.* packages which is where the error is being thrown up. So I guess my question is, is this glassfish.jsf the Mojarra reference implementation? I guess if that is the case then I am stuck with the error and will have to find a way to handle the error gracefully in my code, though its ugly having to do that for a standard library, especially one that cannot be replaced or upgraded.

    Thanks for all your help,

    arun

    #22460

    Yes, in this case the server is using Mojarra, which is the JSF reference implementation.

    Do you perhaps see a line like this in your log messages:

    INFO: Initializing Mojarra 2.1.3 (FCS b01) for context '/something'

    Just to get a clear view on this bug: Does it only throw these exceptions if your dynaview method returns a view that doesn’t exist (results in a 404)? So everything works with a valid viewId? Or does it fail for valid viewIds too?

    #22461

    Arun Kumar
    Participant

    I grepped all the log files and there is no reference to “Mojarra” in any of them. Yes this error is only thrown when a file does not exist. It works with valid view-ids and was working fine in other cases.

    If it will help I can write up a simple test case demonstrating the error and upload the file somewhere. But it will take me a couple of days to get to doing that.

    #22462

    Arun Kumar
    Participant

    Christian,

    Not sure how I missed it earlier, maybe I was grepping the wrong log files. But yes I do see – “INFO: Initializing Mojarra 2.0.4 (FCS b07) for context…” in my live server console window.

Viewing 15 posts - 1 through 15 (of 16 total)

You must be logged in to reply to this topic.

Comments are closed.