I'm moving this over from the jsf-impl issue tracker issue 293:
View ID passed to ViewHandler.restoreView during RestoreView phase impl is raw
request URI, not derived view ID
I've found a difference in the implementation of MyFaces and the Sun RI that I
need some clarification on. I think this may be a bug in the Sun RI.
Firstly, the JSF specification, in section 2.2.1, describes an algorithm for
deriving the view ID from the request URI. The net effect is that a request
URI like /foo/bar/page.faces becomes /foo/bar/page.jspx (or whatever extension
is configured for the backing rendering mechanism for the page).
When I inspect the implementation of the Sun RI, the RestoreView lifecycle
phase implementation does not directly apply this algorithm on the request URI
before handing the purported view ID to ViewHandler.restoreView or
ViewHandler.createView. The Sun RI ViewHandlerImpl, however, does apply the
algorithm to the view ID. But at that point, the ViewHandlerImpl really
receives a request URI and not a view ID as per the spec.
When I inspect the implementation of MyFaces, the LifecycleImpl does the
translation of the view ID before calling ViewHandler.restoreView or
The net effect is that a bridge that uses a custom lifecycle impl. based
strictly on the Sun RI will not work with the MyFaces implementation of
ViewHandlerImpl. In particular, restoreView will fail since, under the covers,
MyFaces is further translating request URI's to view ID's, such that the state
would be stored with a key formed from /foo/bar/page.jsp but retreived with a
key formed from /foo/bar/page.faces (no translation since the bridge is passing
the raw request URI to ViewHandler.restoreView, per the Sun RI implementation).