javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-2048

Facelets: Component tree is always recreated after a failover

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Trivial Trivial
    • Resolution: Incomplete
    • Affects Version/s: 2.1.1
    • Fix Version/s: None
    • Component/s: facelets
    • Labels:
      None
    • Environment:

      Partial state saving should be disabled:
      <context-param>
      <param-name>javax.faces.PARTIAL_STATE_SAVING</param-name>
      <param-value>false</param-value>
      </context-param>

      Description

      With partial state saving disabled, Facelets tags are executed over a component tree that was restored from state during the restore_view phase. The issue is that DefaultFacelet.apply() will always think that the component tree is 'stale' after a failover, and all components will be re-created. This results in a loss of state.

      DefaultFacelet.apply() calls DefaultFacelet.refresh() before any tags are executed. The purpose of the call is to clear UIViewRoot's children whose "APPLIED_KEY" timestamp is older than the creation time of the Facelet itself. This would normally happen only if the document was modified and the Facelet tag tree was re-parsed between two requests.

      However, in the case of a failover, the the Facelet tag tree is always re-parsed because the Facelet cache is not there (it is stored on the Application map, which does not survive failover). The "APPLIED_KEY" timestamp on the UIViewRoot's children corresponds to the tag execution time from a previous (pre-failover) request, so the Facelet will be always 'newer' than the components, and the entire
      component tree will be always rebuilt.

        Activity

        Hide
        Manfred Riem added a comment -

        Can you provide a simple application (with sources) that demonstrates the problem and detailed steps on how to reproduce the problem?

        Show
        Manfred Riem added a comment - Can you provide a simple application (with sources) that demonstrates the problem and detailed steps on how to reproduce the problem?
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Lowering priority because of no response

        Show
        Manfred Riem added a comment - Lowering priority because of no response
        Hide
        Manfred Riem added a comment -

        Closing because of inactivity

        Show
        Manfred Riem added a comment - Closing because of inactivity

          People

          • Assignee:
            Unassigned
            Reporter:
            mst_70
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: