Tomcat 7.0.19 and Mojarra 2.1.2 ViewExpiredException

Question

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 changed 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.

Answer 1

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.