Tomcat 7.0.19 和 Mojarra 2.1.2 ViewExpiredException
我很长时间以来一直在我的项目中使用 Tomcat 6.0.26。现在，我需要在这个项目中使用 EL 2.2，因此我将其移至 Tomcat 7.0.19，没有进行任何其他更改（使用 Mojarra 2.1.2-b04 和 RichFaces 4.0.0）。当我启动它时，一切都很好，直到我尝试任何 a4j:commandButton 或 h:commandButton 它抛出 ViewExpiredException 即使应用程序启动不到一分钟（作为信息，我在 web.xml 中强制设置了 30 分钟会话超时） 。
使应用程序工作的唯一方法是更改此设置：
<context-param>
<param-name>javax.faces.STATE_SAVING_METHOD</param-name>
<param-value>client</param-value>
</context-param>
它是服务器，我将其更改为客户端，但服务器设置最好保留数据服务器端，并且不要' t 在每次请求时将其传输给客户端。
编辑：看起来服务器到客户端修复了ViewExpiredException的问题，但网站上的用户登录功能不再起作用。它登录到用户主目录，但在单击任何链接后，它会执行与用户不是记录器相同的操作（我使用 SessionScoped ManagedBean 来保存用户信息）。
有人有这个错误吗？
谢谢你，
亚历克斯。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
当视图不再位于会话中时，您将收到一个
ViewExpiredException。所描述的症状表明会话 cookie 没有得到维护，因此每个请求都以某种方式迫使服务器创建一个全新的会话。我无法在针对 Tomcat 7.0.19 的准系统 Mojarra 2.1.2 项目上本地重现您的问题。会话保持得非常好。我在第一个请求上看到
JSESSIONID的Set-Cookie响应标头，并且看到JSESSIONID的Cookie请求标头> 在同一浏览器会话中的每个后续请求上。这就是它应该如何工作的。所以这个问题至少与Mojarra 2.1.2或Tomcat 7.0.19没有直接关系。您可以使用 Firebug 自行查看和跟踪
JSESSIONIDcookie。这是我要做的第一件事。您应该检查是否是浏览器拒绝发回Cookie请求标头（我不认为是这种情况），或者是服务器发送了新的Set-每次都会收到 cookie响应标头（我认为就是这种情况）。如果确实是服务器每次都重新创建会话，即使浏览器已发送了Cookie标头，那么这只能意味着存在不正确的HttpSession#invalidate()调用代码库中强制执行此操作的某个位置。运行调试器来确定罪魁祸首。You will get a
ViewExpiredExceptionwhen 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-Cookieresponse header forJSESSIONIDon the first request and I see theCookierequest header forJSESSIONIDon 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
JSESSIONIDcookie yourself. That's the first thing I would do. You should check if it's the browser who refuses to send theCookierequest header back (I don't think that this is the case), or that it's the server who sends a newSet-cookieresponse 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 theCookieheader, then that can only mean that there's an incorrectHttpSession#invalidate()call somewhere in the code base which forces that. Run a debugger to naildown the culprit.