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:
This handles the full state saving case.
This handles the pre-existing UIViewRoot case (ie. UIViewRoot is set before restore view phase is
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:
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.