3 Replies Latest reply on Jul 18, 2012 8:51 AM by kenfinni

    problem request parameters still alive

    guga.java

      Hi to all,

       

      I'm having a serious problems with scope of request.

       

      For example:

       

      I have a boolean variable with false as default value. I change the value for true, when I go to another page e come back the value of true still appearing. This same project using normal JSF (non-portlet) this scnario works ok.

       

      I'm using JBoss Portlet Bridge 2.3.1, JSF 1.2, Facelets, RichFaces, eXo 3.

       

      Follow attached my web.xml and faces-config

       

      Please some body can help me?

        • 1. Re: problem request parameters still alive
          jeromej

          Hi,

           

          Portlet Bridge 3.1 ? Are you sure ? This version doesn't exist today.

           

          However, JSF 1.2 dont work with Portlet Bridge 3.0, you must migrate to JSF 2

          • 2. Re: problem request parameters still alive
            guga.java

            Sorry, Portlet Bridge version 2.3.1

            • 3. Re: problem request parameters still alive
              kenfinni

              Gustavo,

               

              What you're experiencing is the expected behavior in a portlet environment.

               

              In a portlet the Portlet Bridge makes JSF behave very differently to support portlet lifecycle calls.  In a nutshell, when you change the value from false to true on the page of the portlet that has occurred in an ActionRequest.  The Portlet Bridge is then responsible for retaining that "state" within JSF during every Render or re Render of that page until another ActionRequest is made against that portlet.  This is required because portals can call Render on a portlet many times without that portlet having been involved with user interaction, and this ensures that the content of that portlet does not alter during each of those Render calls.

               

              If you'd like to see functionality to disable this spec compliant feature, then please raise a JIRA for it, and maybe contribute a pull request that would fix it.

               

              Ken