[
https://issues.apache.org/jira/browse/MYFACES-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13041756#comment-13041756
]
Leonardo Uribe commented on MYFACES-3162:
-----------------------------------------
Yes, you're right. The solution is very simple, just if
isHandlingStateCachingMechanics(facesContext) returns false take the one passed
as param.
Note myfaces state manager since 2.0.6 and 2.1.0 is
org.apache.myfaces.application.StateManagerImpl, so this param has sense when
it is required to use the previous one
org.apache.myfaces.application.jsp.JspStateManagerImpl or a custom
implementation that relies on the previous behavior, but take into account the
new behavior is preferred because it is more aligned with the spec "intention".
> AJAX Broken when State Caching Mechanics turned off
> ---------------------------------------------------
>
> Key: MYFACES-3162
> URL: https://issues.apache.org/jira/browse/MYFACES-3162
> Project: MyFaces Core
> Issue Type: Bug
> Components: General
> Affects Versions: 2.0.6
> Environment: MyFaces 2.0.6, RichFaces 4.0.Final, Tomcat 6
> Reporter: James G
> Fix For: 2.0.7, 2.1.1
>
> Attachments: MYFACES-3162-1.patch
>
>
> When the web configuration param
> "org.apache.myfaces.HANDLE_STATE_CACHING_MECHANICS" is set to false, after
> the first ajax call, all further ajax calls fail. The failure occurs with a
> ViewExpiredException on the next ajax call. The reason is that the sequence
> number part of the view state is being lost during the first ajax call. (See
> HtmlResponseStateManager.getViewState() where baseState is lost when
> isHandlingStateCachingMechanics(facesContext) returns false.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
