Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7.1
    • Fix Version/s: 1.8DR#2, 1.8
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces
    • Affects:
      Documentation (User Guide, Ref. Guide, etc.)

      Description

      JSF state saving is a mechanism that aids in failover implementation. On any page, the component structure and state are saved to either the client or to the session, but a key that enables restoring the state is always written to the client. In this way, the client request can be redirected to a failover server, and as long as the session has been duplicated, the original page state and structure can be restored for the request.

      Currently, we maintain the component state and structure in our own proprietary way which necessitates propagating the entire framework object structure to the failover node.

        Issue Links

          Activity

          Hide
          Greg Dick added a comment -

          Progress on this issue is at about 80-90%. State is being saved in the session, the key to restoring state is being written to the client, and the key is found and identified if passed back in a request and can be used to restore state. State is apparently restored. Apparently is the term used because it's not completely obvious if it is restored or not, none of our applications seem to require it.

          At this stage one remaining issue is that when the form is restored, the id changes, and something causes all the forms children to be rendered. Currently these aren't being diff'd out, with the result that the update contains all the children, meaning that if you are typing something in an input text, it's erased. There have been a couple of changes that could be responsible for this changed behaviour so I'm still working on that.

          Show
          Greg Dick added a comment - Progress on this issue is at about 80-90%. State is being saved in the session, the key to restoring state is being written to the client, and the key is found and identified if passed back in a request and can be used to restore state. State is apparently restored. Apparently is the term used because it's not completely obvious if it is restored or not, none of our applications seem to require it. At this stage one remaining issue is that when the form is restored, the id changes, and something causes all the forms children to be rendered. Currently these aren't being diff'd out, with the result that the update contains all the children, meaning that if you are typing something in an input text, it's erased. There have been a couple of changes that could be responsible for this changed behaviour so I'm still working on that.
          Hide
          Greg Dick added a comment -

          That problem turned out to be that the view state key was changing in the form. It turns out that ICEfaces updates can only be applied to an element with an id so the code ascends the hierarchy until it finds the first element with an id (which is the form) and inserts that into the update queue. This causes all the children of the form to be sent.

          The solution to this problem was to encase the <input> tag containing the View state key in a div tag that has an id. I don't want to monkey with the results of the JSF code that is generating the <input> tag.

          Moving on to the next problem, trying the code in the auction monitor example application. Again the application has some form of problem where the body tag is modified and the entire page is resent. This problem was traced back to the UIXHtmlComponent representing the DIV tags for "chat_content" and "auction_content". This component is not saving its state properly, and as a result, the rendered ID wasn't being preserved. This was causing the DOM id's in the old and new DOM to be different resulting in the parent node (body) being sent. Note that the ID of the component itself is correctly restored, but not the rendered ID.

          There may be some components that don't support saveState and restoreState at all, plus perhaps some that don't support the methods properly. The following packages are suspect in that they exist, but a search doesn't reveal any saveState or restoreState methods. It well may be that they don't need to support these methods, etc.

          component\src\com\icesoft\faces\component\

          drag-drop
          gmap
          input rich text
          menu-bar
          menu-popup
          panel divider
          panel tool tip
          output style

          however output style is definitely a problem, as the DOM (in auction Monitor application) before state saving has 7 elements, and the DOM after restoration has 5 elements with the 2 missing elements being links to style files.

          May need to get some component support for this operation.

          Show
          Greg Dick added a comment - That problem turned out to be that the view state key was changing in the form. It turns out that ICEfaces updates can only be applied to an element with an id so the code ascends the hierarchy until it finds the first element with an id (which is the form) and inserts that into the update queue. This causes all the children of the form to be sent. The solution to this problem was to encase the <input> tag containing the View state key in a div tag that has an id. I don't want to monkey with the results of the JSF code that is generating the <input> tag. Moving on to the next problem, trying the code in the auction monitor example application. Again the application has some form of problem where the body tag is modified and the entire page is resent. This problem was traced back to the UIXHtmlComponent representing the DIV tags for "chat_content" and "auction_content". This component is not saving its state properly, and as a result, the rendered ID wasn't being preserved. This was causing the DOM id's in the old and new DOM to be different resulting in the parent node (body) being sent. Note that the ID of the component itself is correctly restored, but not the rendered ID. There may be some components that don't support saveState and restoreState at all, plus perhaps some that don't support the methods properly. The following packages are suspect in that they exist, but a search doesn't reveal any saveState or restoreState methods. It well may be that they don't need to support these methods, etc. component\src\com\icesoft\faces\component\ drag-drop gmap input rich text menu-bar menu-popup panel divider panel tool tip output style however output style is definitely a problem, as the DOM (in auction Monitor application) before state saving has 7 elements, and the DOM after restoration has 5 elements with the 2 missing elements being links to style files. May need to get some component support for this operation.
          Hide
          Mark Collette added a comment -

          There was a NPE, on the second postback, with state saving turned on.

          On the initial GET, context.getExternalContext().getRequestParameterMap().get("javax.faces.RenderKitId") is null, as expected. On the initial postback, it returns "ICEfacesRenderKit", as expected. But, on the second postback, it return "", which the code didn't account for. It assumes null or a valid renderKitId. I changed the ICEfaces code to treat an empty String like a null.

          Subversion 17883
          icefaces\core\src\com\icesoft\faces\application\D2DViewHandler.java

          Show
          Mark Collette added a comment - There was a NPE, on the second postback, with state saving turned on. On the initial GET, context.getExternalContext().getRequestParameterMap().get("javax.faces.RenderKitId") is null, as expected. On the initial postback, it returns "ICEfacesRenderKit", as expected. But, on the second postback, it return "", which the code didn't account for. It assumes null or a valid renderKitId. I changed the ICEfaces code to treat an empty String like a null. Subversion 17883 icefaces\core\src\com\icesoft\faces\application\D2DViewHandler.java

            People

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

              Dates

              • Created:
                Updated:
                Resolved: