重新部署后使用JSF 2防止ViewExpiredException

Question

I have a problem where every time I redeploy my app, any existing sessions are broken and the requests result in a ViewExpiredException . None of the advice in related questions or outside mailing list / forum posts seems to fix this issue. I can redeploy the same WAR file completely unchanged and the behavior is the same.

I'm using Apache MyFaces 2.2.0, Tomcat 7.0.56 and Primefaces 5.0.

The message of the exception is No saved view state could be found for the view identifier: with whatever page would be requested. Primefaces' menubar is used for navigation, which seems to be implemented as a <form> with POST requests. These messages occur both with those navigation options and other AJAX that uses POST.

I have tried:

1. Setting explicit org.apache.myfaces.SECRET and org.apache.myfaces.MAC_SECRET values, as seen in this document .
2. Both client and server values for the javax.faces.STATE_SAVING_METHOD parameter.
3. Ensuring all beans and their transitive fields are serializable. No serialization errors are reported in the logs.
4. Using a filter to add no-cache headers, eg as suggested in this answer .
5. Session persistence is not disabled, that is my context.xml has <Manager pathname="" /> commented out.

Answer 1

尝试：

<Manager className="org.apache.catalina.session.PersistentManager" saveOnRestart="true"/>

Answer 2

It seems that losing sessions is a "feature" of Tomcat since at least version 6 and continuing to version 7 when deploying via WAR file. We have to copy an unpacked directory to avoid losing the sessions, because WAR changes cause an undeploy followed by a deploy , as opposed to a reload .

This bug report states:

There are ways to achieve an update to an application without dropping the sessions. The simplest is probably:
- deploy as an exploded directory rather than a WAR
- update the files
- touch web.xml to trigger a reload

The reason for the current behaviour is to prevent problems when WARs are updated in incompatible ways and anything other than a full undeploy followed by (essentially) a new deployment causes conflicts.

This is still the case in the current Tomcat 7.0 documentation :

Currently, application reloading (to pick up changes to the classes or web.xml file) is not supported when a web application is deployed directly from a WAR file. It only works when the web application is deployed from an unpacked directory.