-
1. Re: sessionExpiredException problem with RF 3.2.1.GA
pepiino May 30, 2008 10:58 AM (in response to lmk)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 exceptionjavax.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 -
2. Re: sessionExpiredException problem with RF 3.2.1.GA
lmk May 30, 2008 11:06 AM (in response to lmk)ouf! Im not alone !!
-
3. Re: sessionExpiredException problem with RF 3.2.1.GA
jordan.parker May 30, 2008 11:16 AM (in response to lmk)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. -
4. Re: sessionExpiredException problem with RF 3.2.1.GA
ijaooo May 30, 2008 4:33 PM (in response to lmk)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. -
5. Re: sessionExpiredException problem with RF 3.2.1.GA
guarf May 30, 2008 6:05 PM (in response to lmk)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 -
6. Re: sessionExpiredException problem with RF 3.2.1.GA
sergeysmirnov May 30, 2008 6:06 PM (in response to lmk)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. -
7. Re: sessionExpiredException problem with RF 3.2.1.GA
darkmarine Jun 2, 2008 6:04 PM (in response to lmk)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. -
8. Re: sessionExpiredException problem with RF 3.2.1.GA
sergeysmirnov Jun 2, 2008 6:12 PM (in response to lmk)Even no exceptions, the RichFaces did not work correctly after the MyFaces changed that key behaviour.
-
9. Re: sessionExpiredException problem with RF 3.2.1.GA
rajarchu Jun 2, 2008 7:56 PM (in response to lmk)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. -
10. Re: sessionExpiredException problem with RF 3.2.1.GA
sergeysmirnov Jun 2, 2008 8:21 PM (in response to lmk)"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. -
11. Re: sessionExpiredException problem with RF 3.2.1.GA
jagal Jun 5, 2008 3:27 AM (in response to lmk)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 ? -
12. Re: sessionExpiredException problem with RF 3.2.1.GA
pepiino Jun 5, 2008 5:47 AM (in response to lmk)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.