You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Xavier Cho (JIRA)" <de...@myfaces.apache.org> on 2014/02/14 14:04:19 UTC

[jira] [Commented] (MYFACES-3840) UIViewRoot uses different id while saving and restoring states.

    [ https://issues.apache.org/jira/browse/MYFACES-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13901401#comment-13901401 ] 

Xavier Cho commented on MYFACES-3840:
-------------------------------------

Sorry for the late response. It seems that it's the famous 'chicken-egg' problem with using view scope with component binding, as described (and fixed) by this Mojarra issue :

-  https://java.net/jira/browse/JAVASERVERFACES-1492

When PSS is enabled and a managed bean with a component binding is itself view scoped or depends on one, new instance of the view scoped bean is created as existing instance cannot be referenced, as the view attributes is not yet restored when _vdl.buildView (context, view);_ is invoked in _DefaultFaceletsStateManagementStrategy:222_ (2.2.0).

> UIViewRoot uses different id while saving and restoring states.
> ---------------------------------------------------------------
>
>                 Key: MYFACES-3840
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3840
>             Project: MyFaces Core
>          Issue Type: Bug
>    Affects Versions: 2.2.0-beta
>            Reporter: Xavier Cho
>            Assignee: Leonardo Uribe
>
> After I upgraded to 2.2.0-beta, every postback requests which requires @ViewScoped managed beans fails as they lose states after the initial request.
> I couldn't spend sufficient time to investigate so not perfectly sure if it's not caused by some misconfiguration on my end.
> Though, after a quick debugging, I found that in the DefaultFaceletsStateManagementStrategy class, state of an UIViewRoot instance is saved using its client ID in saveStateOnMapVisitTree:976, but it tries to restore it using its view ID in restoreView:301, thus failing to restore the state.
> Is this behavior normal? If so, what possible configuration could cause it to use different IDs between saving and restoring state?



--
This message was sent by Atlassian JIRA
(v6.1.5#6160)