Details

    • Issuezilla Id:
      806
    • Status Whiteboard:
      Hide

      changelog

      Show
      changelog

      Description

      JSF2 introduces the PostRestoreState system event which is delivered to each component after its state
      has been restored. At the moment these events are delivered from three separate locations:

      1. UIViewRoot.processRestoreState()

      This handles the full state saving case.

      2. RestoreViewPhase.execute()

      This handles the pre-existing UIViewRoot case (ie. UIViewRoot is set before restore view phase is
      executed).

      3. StateManagementStrategyImpl.restoreView()

      This handles the partial state saving case.

      This approach seems more complex than necessary. A simpler approach would be to deliver these
      events from one location - ie. from the lifecycle implementation at the end of the restore view phase.

      A more specific problem that falls out of the current approach is that this places a burden on custom
      StateManagers to also implement this behavior. For example, Trinidad's state manager implementation
      that performs view root caching, see:

      http://myfaces.apache.org/trinidad/devguide/configuration.html#org.apache.myfaces.trinidad.CACHE_
      VIEW_ROOT

      Must (re-)implement its own PostRestoreStateEvent delivery pass.

      This leads to a related problem… PostRestoreStateEvent delivery requires that the UIViewRoot has
      already been connected to the FacesContext via a call to FacesContext.setViewRoot(). However, at the
      point where the StateManager is called to restore the view, the UIViewRoot has yet to be connected.
      The view root is connected to the FacesContext by the lifecycle implementation, after the StateManager
      has restored the view.

      As a result, attempts to deliver PostRestoreStateEvents from custom state managers fail.

      Rather than place the burden on state manager implementations to further duplicate the work of
      delivering PostRestoreViewEvents (which also requires a new responsibility of attaching the view root to
      the FacesContext), the spec should be simplified to state that PostRestoreStateEvents are delivered by
      the lifecycle implementation after the state has been restored.

      1. 806-patch.txt
        12 kB
        Ed Burns
      2. 806-patch.txt
        4 kB
        Ed Burns
      3. changebundle.txt
        17 kB
        Ed Burns

        Activity

        Hide
        Ed Burns added a comment -

        Move back to 2.0 Rev a.

        The Mojarra portion of the fix for this bug has been committed, r8403.

        Show
        Ed Burns added a comment - Move back to 2.0 Rev a. The Mojarra portion of the fix for this bug has been committed, r8403.
        Hide
        Ed Burns added a comment -

        Created an attachment (id=241)
        Fix for this bug, second iteration

        Show
        Ed Burns added a comment - Created an attachment (id=241) Fix for this bug, second iteration
        Hide
        Ed Burns added a comment -

        Fix checked in.

        Show
        Ed Burns added a comment - Fix checked in.
        Hide
        rogerk added a comment -

        changelog

        Show
        rogerk added a comment - changelog
        Hide
        Manfred Riem added a comment -

        Closing resolved issue out

        Show
        Manfred Riem added a comment - Closing resolved issue out

          People

          • Assignee:
            Ed Burns
            Reporter:
            aschwart
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: