6 Replies Latest reply: Mar 28, 2013 7:17 AM by jmsjr RSS

    Relationship between javax.faces.STATE_SAVING_METHOD and distributable

    jmsjr
      What is the relationship, if any, between:
       <context-param>
        <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
        <param-value>xxxx</param-value>
       </context-param>
      and the
      <distributable/>
      in WEB-INF/web.xml ?

      Let's assume for now that there is only 1 web-app, and that web-app is a JSF webapp.
      And let's say all managed beans are @ViewScoped, and there are NO @SessionScoped beans.

      If javax.faces.STATE_SAVING_METHOD is client, and the WAR is marked as distributable, there is really nothing for the container to replicate within a cluster since the session is stored in the client browser ( e.g. subsequent postbacks will have the browser send the state and on render response, the state is sent back to the browser for further postbacks to the same view ).

      Now if there ARE @SessionScoped beans but javax.faces.STATE_SAVING_METHOD is STILL client, and WAR is still marked as distributable ... does the picture change ? My understanding is the container still does not need to replicate the session across the cluster because they are still stored on the client.

      So sort of confused.
      Are they related, or are they orthogonal concepts ?
      Anyone care to explain ?

      Thanks.
        • 1. Re: Relationship between javax.faces.STATE_SAVING_METHOD and distributable
          EJP
          <distributable/> means that everything that is ever put into an HttpSession is Serializable. There are other things in an HttpSession besides what JSF may or may not put there, and if the container is clustered the HttpSession will be replicated regardless of what JSF may or may not do.
          • 2. Re: Relationship between javax.faces.STATE_SAVING_METHOD and distributable
            jmsjr
            EJP wrote:
            <distributable/> means that everything that is ever put into an HttpSession is Serializable. There are other things in an HttpSession besides what JSF may or may not put there, and if the container is clustered the HttpSession will be replicated regardless of what JSF may or may not do.
            Thanks. Questions though:

            1) Are JSF managed beans replicated across the cluster even if javax.faces.STATE_SAVING_METHOD is client ? .. or to ask in a different way ... under what circumstances will JSF managed beans be replicated even if javax.faces.STATE_SAVING_METHOD is client ?

            In short, I am struggling to understand what is the relationship ( if there is any ) between javax.faces.STATE_SAVING_METHOD ( specially when the state saving method is client ) and clustering.

            2) What are other things that a container may put into an HttpSession that were not directly added by the webapp ?

            Edited by: jmsjr on 27-Mar-2013 23:39
            • 3. Re: Relationship between javax.faces.STATE_SAVING_METHOD and distributable
              gimbal2
              jmsjr wrote:
              1) Are JSF managed beans replicated across the cluster even if javax.faces.STATE_SAVING_METHOD is client ? .. or to ask in a different way ... under what circumstances will JSF managed beans be replicated even if javax.faces.STATE_SAVING_METHOD is client ?

              In short, I am struggling to understand what is the relationship ( if there is any ) between javax.faces.STATE_SAVING_METHOD ( specially when the state saving method is client ) and clustering.
              It should make no difference; the difficulty in clustering is replicating the HttpSession. A more important feature of JSF 2.1 and clustering is its ability to be completely stateless, which is a brand spanking new feature
              >
              2) What are other things that a container may put into an HttpSession that were not directly added by the webapp ?
              Generally the container doesn't put anything in there, except for perhaps an authentication token if you use server managed authentication.
              • 4. Re: Relationship between javax.faces.STATE_SAVING_METHOD and distributable
                jmsjr
                gimbal2 wrote:
                jmsjr wrote:
                1) Are JSF managed beans replicated across the cluster even if javax.faces.STATE_SAVING_METHOD is client ? .. or to ask in a different way ... under what circumstances will JSF managed beans be replicated even if javax.faces.STATE_SAVING_METHOD is client ?

                In short, I am struggling to understand what is the relationship ( if there is any ) between javax.faces.STATE_SAVING_METHOD ( specially when the state saving method is client ) and clustering.
                It should make no difference; the difficulty in clustering is replicating the HttpSession.
                ... Which is what I would like to know ... as I am someone ( or well most developers should ) who would like to know what happens under the hood. My understanding is this:

                1) If javax.faces.STATE_SAVING_METHOD is client, and the managed bean is @ViewScoped ... then the managed bean is NOT replicated because:
                1a) The @ViewScoped managed bean is NOT in the HttpSession anyway, because ...
                1b) The @ViewScoped managed bean is serialized from the server to the browser on RENDER_REPONSE, and from browser to server on post back.
                A more important feature of JSF 2.1 and clustering is its ability to be completely stateless, which is a brand spanking new feature
                OK .. I was just reading that:

                http://balusc.blogspot.com.au/2013/02/stateless-jsf.html

                ... but like one of the posters to the blog, I don't get it ( again ). I guess because I am thinking from the point of view of what I have running at the moment, where all my managed beans are all @ViewScoped, and thus requires state.

                So to use stateless JSF, all your managed beans must be @RequestScoped .. but that would mean rewriting a lot of XHTML pages to ensure it works with @RequestScoped.

                Now I cannot recall anymore why I went with @ViewScoped vs @RequestScoped, but I believe it has to do with validation, where if the validation fails, the original input that failed validation is "lost" ( e.g. no longer in the input control ) on render response, but @ViewScoped seems to keep the component input, even it failed validation.

                Maybe it was a bug with the Mojarra implementation that JBoss is using... Anyway. This stateless JSF is for another thread.


                >>
                gimbal2 wrote:
                2) What are other things that a container may put into an HttpSession that were not directly added by the webapp ?
                Generally the container doesn't put anything in there, except for perhaps an authentication token if you use server managed authentication.
                jmsjr wrote:
                1) Are JSF managed beans replicated across the cluster even if javax.faces.STATE_SAVING_METHOD is client ? .. or to ask in a different way ... under what circumstances will JSF managed beans be replicated even if javax.faces.STATE_SAVING_METHOD is client ?

                In short, I am struggling to understand what is the relationship ( if there is any ) between javax.faces.STATE_SAVING_METHOD ( specially when the state saving method is client ) and clustering.
                It should make no difference; the difficulty in clustering is replicating the HttpSession. A more important feature of JSF 2.1 and clustering is its ability to be completely stateless, which is a brand spanking new feature
                2) What are other things that a container may put into an HttpSession that were not directly added by the webapp ?
                Generally the container doesn't put anything in there, except for perhaps an authentication token if you use server managed authentication.
                • 5. Re: Relationship between javax.faces.STATE_SAVING_METHOD and distributable
                  gimbal2
                  In stead of guessing and believing, why don't you start researching all those doubts you have and make them certainties? Until then you're ice-skating uphill on this matter to be honest. How will you ever figure out how things work "under the hood" when you don't even understand their real purpose yet?
                  • 6. Re: Relationship between javax.faces.STATE_SAVING_METHOD and distributable
                    jmsjr
                    Individually, their intended purpose is clear ... it's when they are combined together that I got confused.
                    I guess after all this, and looking back .. they are unrelated ... as one is about the view state, and the other is about managed bean scope.
                    I'll have to reread the spec again. Thanks.