Mojarra 会话中的服务器状态序列化答案

【问题标题】：Server-state serialization in a session in MojarraMojarra 会话中的服务器状态序列化
【发布时间】：2016-08-03 03:59:45
【问题描述】：

翻阅一本书的摘要，我发现了这一点：

在服务器端，状态可以存储为浅拷贝或深拷贝。在浅拷贝中，状态不会在会议。默认情况下，JSF Mojarra 使用浅拷贝。

我真的无法理解。

由于在上述情况下，我们将有-

javax.faces.STATE_SAVING_METHOD 设置为server，

还有一个输入隐藏字段javax.faces.ViewState，其值类似于"2870966362946771868:-8449289062699033744"。

显然，服务器内部一定已经维护了与上述隐藏字段相对应的状态。

但是通过抽象，如果状态没有在会话中序列化，那么它在哪里？

此外，我注意到一件事，如果我的托管 bean(ViewScoped) 没有实现标记接口 Serializable 并将 STATE_SAVING_METHOD 设置为 server，那么在 Mojarra 中，NotSerializablEexception 不会不会发生，而在MyFaces 中会发生。

【问题讨论】：

标签： jsf serialization jsf-2 viewstate mojarra

【解决方案1】：

但是通过抽象，如果状态没有在会话中序列化，那么它在哪里？

它存在对已经在 HTTP 会话中的实例的引用，而这些实例不一定是序列化的。

为此的关键上下文参数是javax.faces.SERIALIZE_SERVER_STATE，在MyFaces 中默认为true，在Mojarra 中默认为false。当设置为true 时，您将很快在错误地不是Serializable 的工件上看到NotSerializableException。否则，您将依赖于服务器配置。例如，Tomcat 默认序列化整个 HTTP 会话，包括在服务器重新启动期间的所有属性。一些服务器，尤其是那些在集群中运行的服务器，甚至可以配置为在运行时序列化整个 HTTP 会话。在这种情况下，您还会在重新启动或故障转移期间看到 NotSerializableException。

Mojarra 计划根据 2.3 将 javax.faces.SERIALIZE_SERVER_STATE 设置默认为 true，特别是因为此设置将主动防止开发人员无法预见的错误，例如分配不可序列化的 JSF 工件实例，例如 UIComponent 甚至 @987654336 @ 作为非请求范围 bean 的属性。否则会导致Stuck thread at UIComponent.popComponentFromEL、Java Threads at 100% CPU utilization using richfaces UIDataAdaptorBase and its internal HashMap 和java.lang.IllegalStateException at com.sun.faces.context.FacesContextImpl.assertNotReleased 等问题。

另一方面，在旧的 MyFaces 版本中，由于在反序列化期间使用错误的类加载器来解析 EJB 代理，此设置破坏了注入可序列化托管 bean 中的 EJB。根据MyFaces issue 3581，这已在 MyFaces 2.0.15 和 2.1.9 中得到修复。另见@EJB in @ViewScoped @ManagedBean causes java.io.NotSerializableException。

【讨论】：