ICEfaces
  1. ICEfaces
  2. ICE-1330

Seam: Identity.logout causes problems.

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.5.3, 1.6DR#1
          • Fix Version/s: 1.6DR#3, 1.6
          • Component/s: None
          • Labels:
            None
          • Environment:
            Seam 1.1.6 and ICEfaces 1.5.3 or 1.6DR

            Description

            http://jira.jboss.com/jira/browse/JBSEAM-806

            You can duplicate this by just creating a Seam-gen project, and logging in, then out.

            In 1.5.3

            java.lang.IllegalStateException: Cannot create a session after the response has been committed
            at org.apache.catalina.connector.Request.doGetSession(Request.java:2214)
            at org.apache.catalina.connector.Request.getSession(Request.java:2024)
            at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:831)
            at org.apache.catalina.connector.RequestFacade.getSession(RequestFacade.java:842)
            at com.icesoft.faces.env.ServletEnvironmentRequest.copyServletRequestData(ServletEnvironmentRequest.java:179)
            at com.icesoft.faces.env.ServletEnvironmentRequest.<init>(ServletEnvironmentRequest.java:110)
            at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.setupPersistentContext(PersistentFacesServlet.java:522)
            at com.icesoft.faces.webapp.xmlhttp.PersistentFacesServlet.service(PersistentFacesServlet.java:427)
            at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
            at org.jboss.seam.servlet.SeamExceptionFilter.doFilter(SeamExceptionFilter.java:43)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
            at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
            at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
            at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
            at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
            at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
            at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
            at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
            at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
            at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
            at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
            at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
            at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
            at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
            at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
            at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
            at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
            at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
            at java.lang.Thread.run(Thread.java:619)


            In 1.5.2, we fixed the issue where logout was handled by a partial submit, by catching an IllegalStateException in that code path, and throwing a RedirectException if a logout redirect was requested. This was caught by the BlockingServlet, specifically, and a redirect was issued on the ServletResponse object.

            In the seam-gen case, I think this solution has to be duplicated from within the PersistentFacesServlet handling GET requests.


            In 1.6 DR. The code path works if there is NOT a navigation rule in pages.xml, but fails if there is.

            You just get a message in the browser to the effect that:

            /logoutHead/index.seam&rvn=1) is not available

            http://localhost:8080/logoutHead/index.seam&rvn=1

            Which I think has to do with our encoding the redirectViewNumber in the URL, a new requirement for the 1.6 tree.


              Issue Links

              blocks

              New Feature - A new feature of the product, which has yet to be developed. ICE-1810 Support Integration with JBoss Seam

              • Major - Major loss of function.
              • Closed
              duplicates

              Bug - A problem which impairs or prevents the functions of the product. ICE-8499 Seam: Identity.logout causes Cannot create a session after the response has been committed

              • Major - Major loss of function.
              • Open

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Greg Dick added a comment -

                Actually, this isn't restricted to logout, this is any Seam link tag that embeds an action method with an outcome that causes a redirect. This can be common..

                The pieces are as follows:

                1) Seam anchor tag. <s:link action="#

                {jumpingBean.jumpTo}

                " value="Jump via Seam link" />

                This link gets encoded as a link on the page:
                <a href="/1330-logout/home.seam?actionMethod=home.xhtml%3AjumpingBean.jumpTo&" .... />

                The mechanism is that a get request invokes an action, whose response is interpreted by the navigationHandler to cause a redirection.

                2) Here's the section in pages.xml

                <page view-id="*">
                <navigation>
                <rule if-outcome="jumpTo">
                <redirect view-id="/jumpTo.xhtml" />
                </rule>
                </navigation>
                </page>

                So that's a fairly common and uncomplicated thing.

                The reason this fails is that a BridgeFacesContext is created for the new ViewId (created by the GET request) which has a reference to a DOMResponseWriter which is only filled in during the renderResponse phase. In processing this request, we never reach this phase, since a redirect means that the responseComplete flag is set. Thus, during some post processing in the SingleViewServlet, it encounters this null DOMResponseWriter.

                The ideal solution is to create a Noop DOMResponseWriter object so the reference is never null. But the BridgeFacesContext has a reference to DOMResponseWriter (not ResponseWriter) and indeed does use extended methods in the class. The constructor of the DOMResponseWriter requires other references that really are only available when the method setting the ResponseWriter is called, in the RenderResponse phase. So I think the least offensive test is to just skip the offending instruction if the reponseWriter is null.

                if (responseWriter != null)

                { domSerializer = new PushModeSerializer(responseWriter.getDocument(), commandQueue); }

                Normally, I would agree that this just defers errors until later, but in this case, the whole thing will be replaced in the next Get request anyway.

                Note that this isn't a problem when the main mechanism for handling actions is through partial submits in an ICEfaces normal Ajax fashion.

                Show
                Greg Dick added a comment - Actually, this isn't restricted to logout, this is any Seam link tag that embeds an action method with an outcome that causes a redirect. This can be common.. The pieces are as follows: 1) Seam anchor tag. <s:link action="# {jumpingBean.jumpTo} " value="Jump via Seam link" /> This link gets encoded as a link on the page: <a href="/1330-logout/home.seam?actionMethod=home.xhtml%3AjumpingBean.jumpTo&" .... /> The mechanism is that a get request invokes an action, whose response is interpreted by the navigationHandler to cause a redirection. 2) Here's the section in pages.xml <page view-id="*"> <navigation> <rule if-outcome="jumpTo"> <redirect view-id="/jumpTo.xhtml" /> </rule> </navigation> </page> So that's a fairly common and uncomplicated thing. The reason this fails is that a BridgeFacesContext is created for the new ViewId (created by the GET request) which has a reference to a DOMResponseWriter which is only filled in during the renderResponse phase. In processing this request, we never reach this phase, since a redirect means that the responseComplete flag is set. Thus, during some post processing in the SingleViewServlet, it encounters this null DOMResponseWriter. The ideal solution is to create a Noop DOMResponseWriter object so the reference is never null. But the BridgeFacesContext has a reference to DOMResponseWriter (not ResponseWriter) and indeed does use extended methods in the class. The constructor of the DOMResponseWriter requires other references that really are only available when the method setting the ResponseWriter is called, in the RenderResponse phase. So I think the least offensive test is to just skip the offending instruction if the reponseWriter is null. if (responseWriter != null) { domSerializer = new PushModeSerializer(responseWriter.getDocument(), commandQueue); } Normally, I would agree that this just defers errors until later, but in this case, the whole thing will be replaced in the next Get request anyway. Note that this isn't a problem when the main mechanism for handling actions is through partial submits in an ICEfaces normal Ajax fashion.
                Hide
                Permalink
                Greg Dick added a comment -

                Checked in BridgeFacesContext svn version 13423.

                I see that the FacesContext is no longer written to expect a DOMResponseWriter, but the proper ResponseWriter. This should more easily allow a no-op ResponseWriter to be created, which would reduce the risk of having a null response writer to null, really. That would be pretty low priority change, though.

                Show
                Greg Dick added a comment - Checked in BridgeFacesContext svn version 13423. I see that the FacesContext is no longer written to expect a DOMResponseWriter, but the proper ResponseWriter. This should more easily allow a no-op ResponseWriter to be created, which would reduce the risk of having a null response writer to null, really. That would be pretty low priority change, though.
                Hide
                Permalink
                Greg Dick added a comment -

                This has been fixed.

                Show
                Greg Dick added a comment - This has been fixed.

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Greg Dick
                  • Votes:
                    1 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: