ICEfaces
  1. ICEfaces
  2. ICE-1141

Seam: PersistentFacesState.render() causes IllegalStateException "No page context active"

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.5.1
          • Fix Version/s: 1.6DR#3, 1.6
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            Operating System: Windows XP
            Platform: PC

            Description

            noted several places in the forum:
            http://www.icefaces.org/JForum/posts/list/3190.page
            http://www.icefaces.org/JForum/posts/list/3292.page

            It seems that using AJAX push in Seam causes the following stack exception:

             15:37:20,197 ERROR [PhaseListenerManager] Exception in PhaseListener
            RENDER_RESPONSE(6) beforePhase.
            java.lang.IllegalStateException: No page context active
            at org.jboss.seam.core.FacesPage.instance(FacesPage.java:87)
            at
            org.jboss.seam.jsf.AbstractSeamPhaseListener.beforeRender(AbstractSeamPhaseListener.java:219)
            at org.jboss.seam.jsf.SeamPhaseListener.beforePhase(SeamPhaseListener.java:51)
            at
            org.apache.myfaces.lifecycle.PhaseListenerManager.informPhaseListenersBefore(PhaseListenerManager.java:70)
            at org.apache.myfaces.lifecycle.LifecycleImpl.render(LifecycleImpl.java:373)
            at
            com.icesoft.faces.webapp.xmlhttp.PersistentFacesState.render(PersistentFacesState.java:180)

            ...

              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

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Ted Goddard added a comment -

                Assigning to Greg.

                Show
                Ted Goddard added a comment - Assigning to Greg.
                Hide
                Permalink
                Ted Goddard added a comment -

                This is due to the fact that Seam requires an execute() to take place prior to the render.

                Show
                Ted Goddard added a comment - This is due to the fact that Seam requires an execute() to take place prior to the render.
                Hide
                Permalink
                Ted Goddard added a comment -

                svn commit core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java core/src/com/icesoft/
                faces/webapp/xmlhttp/FileUploadServlet.java -m "exposing execute() method so that Seam applications
                can invoke it (ICE-1141)"
                Sending core/src/com/icesoft/faces/webapp/xmlhttp/FileUploadServlet.java
                Sending core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java
                Transmitting file data ..
                Committed revision 13265.

                Show
                Ted Goddard added a comment - svn commit core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java core/src/com/icesoft/ faces/webapp/xmlhttp/FileUploadServlet.java -m "exposing execute() method so that Seam applications can invoke it ( ICE-1141 )" Sending core/src/com/icesoft/faces/webapp/xmlhttp/FileUploadServlet.java Sending core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java Transmitting file data .. Committed revision 13265.
                Hide
                Permalink
                Ted Goddard added a comment -

                Commited same change to 1.5 branch.

                svn commit core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java core/src/com/icesoft/
                faces/webapp/xmlhttp/FileUploadServlet.java -m "exposing execute() method so that Seam applications
                can invoke it (ICE-1141)"
                Sending core/src/com/icesoft/faces/webapp/xmlhttp/FileUploadServlet.java
                Sending core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java
                Transmitting file data ..
                Committed revision 13267.

                Show
                Ted Goddard added a comment - Commited same change to 1.5 branch. svn commit core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java core/src/com/icesoft/ faces/webapp/xmlhttp/FileUploadServlet.java -m "exposing execute() method so that Seam applications can invoke it ( ICE-1141 )" Sending core/src/com/icesoft/faces/webapp/xmlhttp/FileUploadServlet.java Sending core/src/com/icesoft/faces/webapp/xmlhttp/PersistentFacesState.java Transmitting file data .. Committed revision 13267.
                Hide
                Permalink
                Ken Fyten added a comment -

                This issue needs to be analyzed along with other Seam related issues and distilled to root causes.

                Show
                Ken Fyten added a comment - This issue needs to be analyzed along with other Seam related issues and distilled to root causes.
                Hide
                Permalink
                Greg Dick added a comment -

                As mentioned above, this requires a call to execute() before trying to render() from the server. Generally Seam expects to be able to re-initialize itself at the front end of a request from a client at the end of the restoreView phase. In the case of a server initiated render, this isn't the case. We manually do this by calling execute() before calling render().

                This issue isn't closed because the traditional methods of initiating a render from code on the server:

                • having JSF inject an application scoped instance of RenderManager loaded in a Web app classloader
                • having the RenderManager manage the Renderer types to initiate rendering via a ThreadGroup

                isn't immediately duplicable in Seam becase a Seam managed RenderManager instance appears to be loaded by EJB classloading, and this instance cannot directly render() because it can't find RendererFactory (s) loaded by a different classloader.

                Show
                Greg Dick added a comment - As mentioned above, this requires a call to execute() before trying to render() from the server. Generally Seam expects to be able to re-initialize itself at the front end of a request from a client at the end of the restoreView phase. In the case of a server initiated render, this isn't the case. We manually do this by calling execute() before calling render(). This issue isn't closed because the traditional methods of initiating a render from code on the server: having JSF inject an application scoped instance of RenderManager loaded in a Web app classloader having the RenderManager manage the Renderer types to initiate rendering via a ThreadGroup isn't immediately duplicable in Seam becase a Seam managed RenderManager instance appears to be loaded by EJB classloading, and this instance cannot directly render() because it can't find RendererFactory (s) loaded by a different classloader.
                Hide
                Permalink
                Greg Dick added a comment -

                Ok, this issue is well known, and resolved. The issues named earlier with respect to RenderManager issues are continued in the new bug case for rendermanager, #1377.

                Show
                Greg Dick added a comment - Ok, this issue is well known, and resolved. The issues named earlier with respect to RenderManager issues are continued in the new bug case for rendermanager, #1377.

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Philip Breau
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    0 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: