You are viewing a plain text version of this content. The canonical link for it is here.
Posted to adffaces-issues@incubator.apache.org by "Matthias Weßendorf (JIRA)" <ad...@incubator.apache.org> on 2007/03/16 08:41:24 UTC
[jira] Updated: (ADFFACES-291) The StateManagerImpl fails to verify
the viewId of the restored view matches the request viewId.
[ https://issues.apache.org/jira/browse/ADFFACES-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matthias Weßendorf updated ADFFACES-291:
----------------------------------------
Affects Version/s: 1.0.1-incubating-core-SNAPSHOT
> The StateManagerImpl fails to verify the viewId of the restored view matches the request viewId.
> ------------------------------------------------------------------------------------------------
>
> Key: ADFFACES-291
> URL: https://issues.apache.org/jira/browse/ADFFACES-291
> Project: MyFaces ADF-Faces
> Issue Type: Bug
> Affects Versions: 1.0.1-incubating-core-SNAPSHOT
> 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.
-
You can reply to this email to add a comment to the issue online.