Tomcat 7.0.19 and Mojarra 2.1.2 ViewExpiredException
I was using Tomcat 6.0.26 with my project since long time. Now, I need to use EL 2.2 in this project so I moved it to Tomcat 7.0.19 with no other changes (Using Mojarra 2.1.2-b04 with RichFaces 4.0.0). When I start it up, everything is fine until I try any a4j:commandButton or h:commandButton it throw ViewExpiredException even if the application is started for less than a minute (for info, I've forced 30min session timeout in web.xml).
The only thing makes the application works is by changing this setting :
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
It was server and I cha开发者_JAVA百科nged it to client but the server setting is best to keep data server side and don't transfer it to client on each request.
Edit : Looks like the server to client fix the problem of the ViewExpiredException but the user login function on the website doesn't work anymore. It log into the user home, but after any link is clicked, it does the same like the user is not logger (I use a SessionScoped ManagedBean to keep user information).
Anyone have this bug?
Thank you,
Alex.
You will get a ViewExpiredException
when the view is not in the session anymore. The described symptoms suggests that the session cookie is not maintained and thus every request has somehow forced the server to create a brand new session.
I can't reproduce your problem locally on a barebones Mojarra 2.1.2 project targeted on Tomcat 7.0.19. The session get maintained perfectly fine. I see the Set-Cookie
response header for JSESSIONID
on the first request and I see the Cookie
request header for JSESSIONID
on every subsequent request within the same browser session. That's how it's supposed to work. So the problem is at least not directly related to Mojarra 2.1.2 or Tomcat 7.0.19.
You can use Firebug to see and track the JSESSIONID
cookie yourself. That's the first thing I would do. You should check if it's the browser who refuses to send the Cookie
request header back (I don't think that this is the case), or that it's the server who sends a new Set-cookie
response header everytime (I think that this is the case). If it's indeed the server who re-creates the session everytime even though the browser has sent the Cookie
header, then that can only mean that there's an incorrect HttpSession#invalidate()
call somewhere in the code base which forces that. Run a debugger to naildown the culprit.
精彩评论