Re: [jsr-314-open-mirror] [jsr-314-open] [806] Simplify PostRestoreStateEvent delivery requirements

Gang - I recently logged the following spec issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=806 Short summary of the problem for those who don't want to read through the gory details: The specification is currently a bit too specific about when PostRestoreStateEvents should be delivered. The only requirement should be that these events are delivered after the view has been restored, but before we move out of the restore view phase. For example, a reasonable implementation would be to deliver these events in the Lifecycle implementation, after the state manager has returned the restored view. However, the spec does not currently allow this - eg. the spec requires that UIViewRoot.processRestoreState() delivers these events. Of course, UIViewRoot.processRestoreState isn't always called (only used for full state saving), which means that implementations end up having to duplicate this logic elsewhere, such as in whatever state manager is used for partial state saving. This has further fallout for custom state managers - ie. custom state managers that do not call processRestoreState() must duplicate the event delivery logic yet again. This is much more complicated than necessary. My recommendation is that we simplify the requirements such that implementations are free to deal with PostRestoreStateEvent delivery in a saner way. For example, implementations should be able to deliver these events once at the end of the restore view phase (and not be required to implement this logic in UIViewRoot.processRestoreState()). I suspect that this small spec change will lead to simpler code in Mojarra (definitely) and MyFaces (probably, though I haven't looked at the code). Does anyone have concerns about this proposal? Martin, Leonardo - Could you guys comment on whether this change would be acceptable to MyFaces?

Andy