MyFaces Core
  1. MyFaces Core
  2. MYFACES-1733

[Seam] Server-side state saving not working correctly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6-SNAPSHOT
    • Fix Version/s: 1.2.2
    • Component/s: None
    • Labels:
      None

      Description

      Sometimes when using server-side state-saving some state is fixed and won't ever update.
      I don't know how exactly this is caused, but it occurs a lot when using JBoss Seam.
      It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead.

      Here is how to reproduce reliably with one of the Seam example applications:

      • download and unzip tomcat 5.5.
      • download and unzip JBoss Seam 1.2.1.
      • edit <seam-install-folder>/build.properties and specify the path to tomcat
      • edit <seam-install-folder>/examples/seampay/resources/WEB-INF/web.xml and change state saving method to server.
      • run ant deploy.tomcat from <seam-install-folder>/examples/seampay/
      • open http://localhost:8080/jboss-seam-pay
      • try to click on different accounts.
        => Only the first selection ever will make it. All others are ignored. Change back to client side state saving and everything works ok.

      I tried to look into this, but I am way over my head here with the internals of JSF and MyFaces.

      1. jira1733-patch.zip
        0.7 kB
        Michael Kurz

        Issue Links

          Activity

          Stephen Friedrich created issue -
          Hide
          Matthias Weßendorf added a comment -

          <snip>
          It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead.
          </snip>

          can you give us an URL ?

          Show
          Matthias Weßendorf added a comment - <snip> It is consensus in the Seam community not to ever use myfaces with server-side state saving or even better not to use myfaces, but the RI instead. </snip> can you give us an URL ?
          Hide
          Martin Marinschek added a comment -

          I have never seen this problem without Seam. Can you give us more pointers to discussions on this on the Seam mailing lists? I know MyFaces server-side state-saving pretty well, and it is very similar to what the RI does.

          regards,

          Martin

          Show
          Martin Marinschek added a comment - I have never seen this problem without Seam. Can you give us more pointers to discussions on this on the Seam mailing lists? I know MyFaces server-side state-saving pretty well, and it is very similar to what the RI does. regards, Martin
          Hide
          Stephen Friedrich added a comment -

          It may well be that it is only Seam that triggers the bug - yet there is a strong argument that the bug is in fact in MyFaces server-side state saving:
          The problem goes away if you switch to either client-side state saving or use the RI.

          Martin, if you are familiar with MyFaces' server-side state saving it should not be to hard to find the culprit.
          I gave a reliable way to reproduce the problem - see above.

          Matthias, here are some references to the problem (for what it's worth):

          In previous versions of the Seam reference MyFaces was explicitly mentioned. Now it's in milder form:
          "Some JSF implementations have a broken implementation of server-side state saving that interferes with
          Seam's conversation propagation. If you have problems with conversation propagation during form submissions,
          try switching to client-side state saving."

          The problems manifests in a couple of Jira issues, like this one:
          http://jira.jboss.com/jira/browse/JBSEAM-1293
          Gavin King:
          "Right, this is a known bug in MyFaces. Nothing we can do about it, except get off MyFaces and migrate to the RI (which we already did do)."

          If you search the forum you'll find many people having problem with MyFaces/Seam. Some of the posts are quite old, but the integration problem still persists:

          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73933
          gavin.king@jboss.com
          "Right, this is a known limitation of using Seam with MyFaces, due to how MyFaces does server-side state saving (I'm not going to call it an actual bug in MyFaces, but it is suboptimal)."

          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106197
          pete.muir@jboss.org:
          "Don't use server side state saving, Seam, and MyFaces - it doesn't work. You should use the RI 1.2 if you can - it's much better. You can use JSF 1.2 with facelets in a 2.4 servlet container."

          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=108488
          christian.bauer@jboss.com:
          "Do not use server-side state saving with MyFaces, it's buggy. This has been reported before (search the forum) and your problems with page parameters will go away if you switch to client-side state saving or the JSF reference implementation."

          http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115728
          norman.richards@jboss.com:
          "There were known problems with server side state saving in myfaces. I think you'll need to move to the JSF RI to make it work correctly with seam"

          Show
          Stephen Friedrich added a comment - It may well be that it is only Seam that triggers the bug - yet there is a strong argument that the bug is in fact in MyFaces server-side state saving: The problem goes away if you switch to either client-side state saving or use the RI. Martin, if you are familiar with MyFaces' server-side state saving it should not be to hard to find the culprit. I gave a reliable way to reproduce the problem - see above. Matthias, here are some references to the problem (for what it's worth): In previous versions of the Seam reference MyFaces was explicitly mentioned. Now it's in milder form: "Some JSF implementations have a broken implementation of server-side state saving that interferes with Seam's conversation propagation. If you have problems with conversation propagation during form submissions, try switching to client-side state saving." The problems manifests in a couple of Jira issues, like this one: http://jira.jboss.com/jira/browse/JBSEAM-1293 Gavin King: "Right, this is a known bug in MyFaces. Nothing we can do about it, except get off MyFaces and migrate to the RI (which we already did do)." If you search the forum you'll find many people having problem with MyFaces/Seam. Some of the posts are quite old, but the integration problem still persists: http://www.jboss.com/index.html?module=bb&op=viewtopic&t=73933 gavin.king@jboss.com "Right, this is a known limitation of using Seam with MyFaces, due to how MyFaces does server-side state saving (I'm not going to call it an actual bug in MyFaces, but it is suboptimal)." http://www.jboss.com/index.html?module=bb&op=viewtopic&t=106197 pete.muir@jboss.org: "Don't use server side state saving, Seam, and MyFaces - it doesn't work. You should use the RI 1.2 if you can - it's much better. You can use JSF 1.2 with facelets in a 2.4 servlet container." http://www.jboss.com/index.html?module=bb&op=viewtopic&t=108488 christian.bauer@jboss.com: "Do not use server-side state saving with MyFaces, it's buggy. This has been reported before (search the forum) and your problems with page parameters will go away if you switch to client-side state saving or the JSF reference implementation." http://www.jboss.com/index.html?module=bb&op=viewtopic&t=115728 norman.richards@jboss.com: "There were known problems with server side state saving in myfaces. I think you'll need to move to the JSF RI to make it work correctly with seam"
          Hide
          Matthias Weßendorf added a comment -

          Tested older MyFaces releases (1.1.2; 1.1.5) and the current SNAPSHOT (1.1.6-SNAPSHOT).

          All three versions of MyFaces show the bug;

          Therefore making this ticket "critical"; and added SEAM-prefix, to indicate the relationship to seam, here.

          Show
          Matthias Weßendorf added a comment - Tested older MyFaces releases (1.1.2; 1.1.5) and the current SNAPSHOT (1.1.6-SNAPSHOT). All three versions of MyFaces show the bug; Therefore making this ticket "critical"; and added SEAM-prefix, to indicate the relationship to seam, here.
          Matthias Weßendorf made changes -
          Field Original Value New Value
          Affects Version/s 1.1.4 [ 12312061 ]
          Priority Major [ 3 ] Critical [ 2 ]
          Summary Server-side state saving not working correctly [Seam] Server-side state saving not working correctly
          Affects Version/s 1.1.2 [ 12310960 ]
          Affects Version/s 1.1.3 [ 12311042 ]
          Affects Version/s  1.1.6-SNAPSHOT [ 12312311 ]
          Michael Kurz made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Hide
          Michael Kurz added a comment -

          The problem seems to be that Seam uses a GET-Parameter for navigation. But those parameters are only read by Seam if renderResponse is called in the restore-view-phase. This only happens if no previous state is available (with client state saving) or if there are no POST- or GET-Parameters at all (should happen for server state saving).

          I provided a patch for 1.1.6 where renderResponse is called if there is no special view state parameter. This should fix the server state saving problem with seam.

          Show
          Michael Kurz added a comment - The problem seems to be that Seam uses a GET-Parameter for navigation. But those parameters are only read by Seam if renderResponse is called in the restore-view-phase. This only happens if no previous state is available (with client state saving) or if there are no POST- or GET-Parameters at all (should happen for server state saving). I provided a patch for 1.1.6 where renderResponse is called if there is no special view state parameter. This should fix the server state saving problem with seam.
          Hide
          Michael Kurz added a comment -

          Patch for version 1.1.6 as described above

          Show
          Michael Kurz added a comment - Patch for version 1.1.6 as described above
          Michael Kurz made changes -
          Attachment jira1733-patch.zip [ 12367352 ]
          Hide
          Mario Ivankovits added a comment -

          I don't see how this patch will fix this issue. Did you try it?

          facesContext.getExternalContext().getRequestParameterMap().isEmpty() retruns true only if there is no GET NOR a POST parameter.

          So in case of a postback you'll have at least the minimum view state required to lookup the view state on the server - you'll always have at least one POST parameter, except if you access a view directly, but then there is also no STANDARD_STATE_SAVING_PARAM.

          But maybe I miss something here?
          Sorry then

          Show
          Mario Ivankovits added a comment - I don't see how this patch will fix this issue. Did you try it? facesContext.getExternalContext().getRequestParameterMap().isEmpty() retruns true only if there is no GET NOR a POST parameter. So in case of a postback you'll have at least the minimum view state required to lookup the view state on the server - you'll always have at least one POST parameter, except if you access a view directly, but then there is also no STANDARD_STATE_SAVING_PARAM. But maybe I miss something here? Sorry then
          Hide
          Michael Kurz added a comment -

          I tried it and it works for me.

          The problem is just the other way round. The point is that this special link in the Seam example app is not a postback but MyFaces does not notice this with server state saving enabled. RestoreViewExecutor only calls renderResponse if no parameters exist but Seam specifies some parameters of its own and therefore renderResponse is not called. This further leads to Seam not reading the specified parameter as it only does this if renderResponse was called.

          I hope I made myself clear.

          Show
          Michael Kurz added a comment - I tried it and it works for me. The problem is just the other way round. The point is that this special link in the Seam example app is not a postback but MyFaces does not notice this with server state saving enabled. RestoreViewExecutor only calls renderResponse if no parameters exist but Seam specifies some parameters of its own and therefore renderResponse is not called. This further leads to Seam not reading the specified parameter as it only does this if renderResponse was called. I hope I made myself clear.
          Hide
          Mario Ivankovits added a comment -

          Ah - ok - now I get it - Thanks!
          Yep, then this could work.

          Need to wait for someone else to comment here, but I think the patch should make it.

          Show
          Mario Ivankovits added a comment - Ah - ok - now I get it - Thanks! Yep, then this could work. Need to wait for someone else to comment here, but I think the patch should make it.
          Hide
          Stephen Friedrich added a comment -

          Hm, I don't know JSF internals as well as you, but I just can't understand what is really going on here:
          The "special link" is not special at all. It is a simple link (<a href=...) that specifies a request parameter (rather than a JSF command link that posts a form).
          That's Seam's way of implementing RESTful URLs, but there's very little "seamish" going on here - the app would break as well (bad?) if a html link would be hardcoded here.

          Why at all is code involved that handles a "Restore View" - from my err, preliminary understanding of JSF I would have thought that a new view gets created.

          Show
          Stephen Friedrich added a comment - Hm, I don't know JSF internals as well as you, but I just can't understand what is really going on here: The "special link" is not special at all. It is a simple link (<a href=...) that specifies a request parameter (rather than a JSF command link that posts a form). That's Seam's way of implementing RESTful URLs, but there's very little "seamish" going on here - the app would break as well (bad?) if a html link would be hardcoded here. Why at all is code involved that handles a "Restore View" - from my err, preliminary understanding of JSF I would have thought that a new view gets created.
          Hide
          Michael Kurz added a comment -

          You're right, it is not a special link but MyFaces got confused with the combination of this link and the request parameter with server-state-saving enabled.

          Restore view is just the name of the first phase in the JSF lifecycle.

          Show
          Michael Kurz added a comment - You're right, it is not a special link but MyFaces got confused with the combination of this link and the request parameter with server-state-saving enabled. Restore view is just the name of the first phase in the JSF lifecycle.
          Hide
          Martin Marinschek added a comment -

          Well, in any case, the wording of the spec, taken exactly as it is written, leads to this behaviour here - even though the intent is very clear, and the fix is of course correct.

          Thanks to Michael Kurz for sorting this out.

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Well, in any case, the wording of the spec, taken exactly as it is written, leads to this behaviour here - even though the intent is very clear, and the fix is of course correct. Thanks to Michael Kurz for sorting this out. regards, Martin
          Hide
          Martin Marinschek added a comment -

          Thanks to Michael Kurz for fixing this (please checkout the 1.2 head, if my change there works properly as well).

          regards,

          Martin

          Show
          Martin Marinschek added a comment - Thanks to Michael Kurz for fixing this (please checkout the 1.2 head, if my change there works properly as well). regards, Martin
          Martin Marinschek made changes -
          Fix Version/s  1.1.6-SNAPSHOT [ 12312311 ]
          Assignee Martin Marinschek [ mmarinschek ]
          Fix Version/s 1.2.1-SNAPSHOT [ 12312571 ]
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Leonardo Uribe made changes -
          Fix Version/s  1.1.6-SNAPSHOT [ 12312311 ]
          Fix Version/s 1.2.1 [ 12312895 ]
          Fix Version/s 1.2.1-SNAPSHOT [ 12312571 ]
          Leonardo Uribe made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Leonardo Uribe made changes -
          Fix Version/s 1.2.1 [ 12312895 ]
          Fix Version/s 1.2.2 [ 12312932 ]
          Leonardo Uribe made changes -
          Link This issue is blocked by MYFACES-2160 [ MYFACES-2160 ]
          Leonardo Uribe made changes -
          Link This issue is blocked by MYFACES-2160 [ MYFACES-2160 ]
          Leonardo Uribe made changes -
          Link This issue relates to MYFACES-2160 [ MYFACES-2160 ]

            People

            • Assignee:
              Martin Marinschek
              Reporter:
              Stephen Friedrich
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development