sessionExpiredException problem with RF 3.2.1.GA

[lmk]

hello,

after 3.2.1.GA migration I can't get any JSF view,
for ajax request no happening
for JSF request

/login.jsfThe expected view was not returned for the view identifier: /login.jsf

I add vainly 2 context parameter as shown on FAQ and RF wiki, viewCompatibility and versionTracking..

environement: myfaces 2.2.1,facelets 1.1.14..

it works fine with 3.2.1.CR8.

thanks !

[pepiino]

Hi
I can report probably the same problem:
After the view is rendered first time, each request(action) (doesn't matter if ajax or regular) ends with error:

/pages/Schedule.faces The expected view was not returned for the view identifier: /pages/Schedule.faces

caused by an exception

javax.faces.application.ViewExpiredException: /pages/Schedule.facesThe expected view was not returned for the view identifier: /pages/Schedule.faces
 at org.apache.myfaces.lifecycle.RestoreViewExecutor.execute(RestoreViewExecutor.java:88)
 at org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
 at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
 at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.ajax4jsf.webapp.BaseXMLFilter.doXmlFilter(BaseXMLFilter.java:154)
 at org.ajax4jsf.webapp.BaseFilter.handleRequest(BaseFilter.java:260)
 at org.ajax4jsf.webapp.BaseFilter.processUploadsAndHandleRequest(BaseFilter.java:366)
 at org.ajax4jsf.webapp.BaseFilter.doFilter(BaseFilter.java:493)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:265)
 at org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
 at org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:124)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at org.acegisecurity.wrapper.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:81)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at cz.smarcoms.bizzy.core.app.security.BranchCheckFilter.doFilter(BranchCheckFilter.java:84)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
 at org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:275)
 at org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:149)
 at org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198)
 at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
 at org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
 at org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
 at org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
 at org.tuckey.web.filters.urlrewrite.RewrittenUrl.doRewrite(RewrittenUrl.java:176)
 at org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:728)
 at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
 at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
 at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
 at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
 at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
 at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
 at java.lang.Thread.run(Thread.java:595)

After some debugging I have found following:

1) It happens only with STATE_SAVING_METHOD set to 'server' (default value)

2) Problem seems to be with jsf view sequence id. AjaxStateHolder uses sequence id prefixed with 'j_id' (for example 'j_id1') and this is used as key in map of viewVersions. But when application tries to get view state, it asks for sequence id as integer - without that prefix (stored somewhere, probably in view state on server, I don't know JSF internals much :)

3) When I did some more debugging through code in the places where the sequence id is created, I've found that Richfaces creates prefixed variant, uses it in map (as expected) but myfaces fails to store it and gets new value from faces context (so maybe myfaces bug?)
I'll try to explain :

This is part of code from org.apache.myfaces.application.jsp.JspStateManagerImpl
(parent of AjaxStateManager from richfaces)
Fallowing method is called from overriden writeState(FacesContext facesContext, SerializedView serializedView) in AjaxStateManager.
When the method is called, parameter contains right value - serializedView._structure = "j_id3", for example (our sequence id) - but method jumps in to part of code marked with comment and generates new sequence id from faces context (ant its integer, e.g. 3).
So in state is saved only integer value and when another request comes, application fails to find view to restore.

public void writeState(FacesContext facesContext,
 SerializedView serializedView) throws IOException
 {
 if (log.isTraceEnabled()) log.trace("Entering writeState");

 UIViewRoot uiViewRoot = facesContext.getViewRoot();
 //save state in response (client)
 RenderKit renderKit = getRenderKitFactory().getRenderKit(facesContext, uiViewRoot.getRenderKitId());
 ResponseStateManager responseStateManager = renderKit.getResponseStateManager();

 if (isLegacyResponseStateManager(responseStateManager))
 {
 responseStateManager.writeState(facesContext, serializedView);
 }
 else if (!isSavingStateInClient(facesContext))
 {
//===============THIS IS THE PLACE, WHERE PROBLEM HAPPENS===========================
 Object[] state = new Object[2];
 state[JSF_SEQUENCE_INDEX] = Integer.toString(getNextViewSequence(facesContext), Character.MAX_RADIX);
 responseStateManager.writeState(facesContext, state);
 }
 else
 {
 Object[] state = new Object[2];
 state[0] = serializedView.getStructure();
 state[1] = serializedView.getState();
 responseStateManager.writeState(facesContext, state);
 }

 if (log.isTraceEnabled()) log.trace("Exiting writeState");

 }

I'm not sure if it's richfaces or myfaces problem (looks like bug in myfaces but i don't know JSF internals and specification well). Should I fill issue in jira? Or should I report it to apache myfaces project? :)

Our application setup:
richfaces 3.2.1GA
myfaces 1.2.3
facelets 1.1.14
tomcat 6.0.16

[lmk]

ouf! Im not alone !!

[jordan.parker]

I'm running into this same issue.

My environment:
MyFaces 1.2.3
Facelets 1.1.14
RichFaces 3.2.1.GA

I didn't have this issue with RichFaces 3.2.1.CR8.

[ijaooo]

Some insight into the problem:

it seems like the Ajax request is sending the wrong javax.faces.ViewState ID parameter which causes a javax.faces.application.ViewExpiredException.

I'm using Richfaces 3.2.1 with Seam 2.0.1 on JBoss 4.2.2, JSF 1.2 RI.

[guarf]

I change the State_Saving_Method from server to client and it works fine.

<context-param>
 <param-name>javax.faces.STATE_SAVING_METHOD</param-name>
 <param-value>client</param-value>
 </context-param>

I don't know if this is a good choice.

Netbeans 6.1
Richfaces 3.2.1 GA
Facelets 1.1.14
myFaces 1.2.2

[sergeysmirnov]

The last post (about JSF RI) has nothing common with the other ones from this thread. We cannot reproduce it. The additional info from your side is required.

The problem with MyFaces happens because of the optimization made according to the https://issues.apache.org/jira/browse/MYFACES-1753 . This issue is not trivial. Will take time to figure our how to workaround.

[darkmarine]

Same problem here.
Using RF 3.2.1 together with MyFaces 1.2.3 , Tomahawk 1.16 and acegi-security 1.0.7.

The first requested page is rendered normal, but clicking on any link on the page throws a ViewExpiredException.
I use the default server-side state saving method.

With the last used version RF 3.1.4 i do not have this exception.

[sergeysmirnov]

Even no exceptions, the RichFaces did not work correctly after the MyFaces changed that key behaviour.

[rajarchu]

Yes the problem is with RF 3.2.0 only.. ViewExpiredException..
has i was working with RF3.1.4 it was working perfectly but when i worked with new version it says the exception.

[sergeysmirnov]

"rajarchu" wrote:
Yes the problem is with RF 3.2.0 only.. ViewExpiredException..
has i was working with RF3.1.4 it was working perfectly but when i worked with new version it says the exception.

3.1.4 works the same way as 3.2.0 or 3.2.1, I.e, far away from perfect. Missing exception does not mean everything work perfect.

3.2.0, instead of 3.1.4, support only JSF 1.2. JSF 1.2 specification directs to throw exception if the session cannot be restored.

[jagal]

Same problem for me.
Using RF 3.2.1GA, MyFaces 1.2.3, Tomahawk 1.16.

With RF 3.2.0SR1 I didn't have this problem.

I change the javax.faces.STATE_SAVING_METHOD to client and it works, but It's not a good workaround.

is there a planification for this problem ?

[pepiino]

Issue in jira is fixed http://jira.jboss.com/jira/browse/RF-3604.
Check 3.2.2 snapshots http://snapshots.jboss.org/maven2/org/richfaces/ui/richfaces-ui/3.2.2-SNAPSHOT/
(You will have to do a little search to get all three needed). We are using build from 03-Jun-2008 and problem doesn't happen anymore.