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

["Leonardo Uribe (JIRA)" <de...@myfaces.apache.org>]

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

Leonardo Uribe commented on MYFACES-3840:
-----------------------------------------

I tried a quick helloworld example with primefaces, and I was not able to reproduce the mentioned no matter if I use the beta or the latest snapshot. 

I also did an step-by-step debug and UIViewRoot always receive the same id (j_id__v_0). It is just not possible to use other id for the view root, unless the code call createUniqueId(...) before restoreView, which is illogical because the expected order is create the view first, set the id and then create other components.

I'm going to close this issue as invalid, because there is no confirmation about the conditions of the issue, so we cannot advance further from this point. Please reopen it again if you can provide hard evidence (test case or example) that the issue is still there. Looking on the svn I can see a fix in UIViewRoot (MYFACES-3747) related to a problem with view scope but the fix was reported and fixed before the beta.

> 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
>
> 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)