[ http://issues.apache.org/jira/browse/ADFFACES-291?page=comments#action_12450254 ] Gary VanMatre commented on ADFFACES-291: ----------------------------------------
There is an example of this in the Shale sandbox. The welcome (index.jsf) page has a link that raises an exception in a action callback. http://svn.apache.org/viewvc/shale/sandbox/shale-clay-trinidad/ When you use the Shale view controller, it catches exceptions so that the view controller callbacks are still invoked. At the end of invoke application phase, a phase listener will dispatch to a path/page if specified. In this example, it's "/error.jsf". In this testbed, I wanted to show the raised exceptions on a JSF page versus a plain JSP or static html page. That's when I ran into the problem. I found that the target (dispatch) view was not being created but the previous view was restored. Outside of this usecase, I think we could recreate it in an action call back that completed the response (responseComplete) and used the external context to dispatch to another view. There is obviously a better way to programmatically handle navigation but this is an option. I expect that's why the myfaces runtime state manager has this check too. > The StateManagerImpl fails to verify the viewId of the restored view matches > the request viewId. > ------------------------------------------------------------------------------------------------ > > Key: ADFFACES-291 > URL: http://issues.apache.org/jira/browse/ADFFACES-291 > Project: MyFaces ADF-Faces > Issue Type: Bug > Reporter: Gary VanMatre > Attachments: StateManagerImpl.patch > > > The Trinidad state manager is only interested in restoring state when client > side state is activated. There is a scenario in the invoke application phase > that a baking callback or a phase listener might choose to dispatch to > another faces view. Since this delegation is a forward, the client's state > of the previous view still exists in the request. The view state is restored > on the previous view's state. > The myfaces JspStateManagerImpl performs this check in the restoreView > method. > Snippet: > if (restoredViewId == null || !(restoredViewId.equals(viewId))) { -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
