[
https://issues.apache.org/jira/browse/MYFACES-3840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13858855#comment-13858855
]
Leonardo Uribe commented on MYFACES-3840:
-----------------------------------------
"... It seems there are lot of such problems with the combination, compared to
PrimeFaces 4.0 + Mojarra 2.2.4 ...". I doubt that, because at the moment this
is the first report that of incompatibility. Note the way how @ViewScoped works
was changed between 2.1.x and 2.2.x.
But it is also probably that the issue has been fixed in some point of the
time, so please try with the latest 2.2.x snapshot at:
https://repository.apache.org/content/groups/snapshots/org/apache/myfaces/core/
The fact that use partial or full state saving does not affect the issue could
be proof that there is a bug in PrimeFaces. It is probably primefaces creates a
component or something, forcing a call to createUniqueId() before the time it
is valid to call it, which changes the order the ids are generated. I need a
simple helloworld example that can reproduce the issue in order to investigate
it further. It could be good if you can try with 2.1.13 + PF 3.5, to check if
there was a fix that caused the problem.
> 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)
