[jira] Commented: (ADFFACES-291) The StateManagerImpl fails to verify the viewId of the restored view matches the request viewId.

["Adam Winer (JIRA)" <ad...@incubator.apache.org>]

    [ http://issues.apache.org/jira/browse/ADFFACES-291?page=comments#action_12450245 ] 
            
Adam Winer commented on ADFFACES-291:
-------------------------------------

Sent e-mail to Gary to get clarification on how this can occur.  I'm reluctant to implement this;  it's not obvious the described use case is valid, and there's no inherent reason why restoreView() absolutely has to restore the exact same view ID, so implementing this might break existing code.

> 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