自 OmniFaces 2.5 FacesViews 以来,@ConversationScoped bean 的行为与@RequestScoped 相同

@ConversationScoped bean behaves as @RequestScoped since OmniFaces 2.5 FacesViews

我尝试将我的 Java EE 7 / JSF 2.2 应用程序升级到 Omnifaces 2.6。目前我是 运行 2.4 版。 在那之后,我注意到在使用 @ConversationScoped 和 Ajax-Requests 时有一个奇怪的行为。调用时,本应在请求后渲染的区域被清空(服务端无异常,响应状态码200)。

接下来,我有一种基于@ConversationScoped的向导实现。它包含一个名为 ViewManager 的 class,它本身有一个视图列表。初始化工作正常,此列表已填满。但是当第一个 form/view 被提交时,它以某种方式被清除(设置为空)。这个 setter 在初始化之后永远不会被调用,所以它没有被我的代码改变。不知何故视图管理器实例仍然可用,只是视图管理器中的这个视图列表为空,这有点奇怪。

使用 omnifaces 2.4,一切正常(这就是为什么我没有添加我的向导的一些代码)。我检查了变更日志并注意到使用 ExtensionlessURLs 时的 MultiViews 配置。不知道为什么这会影响我的问题,但我试过了……但没有成功。 我不知道可能是什么问题,所以也许你可以帮助我。

提前致谢:)

在 OmniFaces 中,FacesViews 无扩展 URLs 功能在 2.5 版中进行了大修,以支持 so-called 多视图,您可以在 this blog.[=20= 上阅读]

在此大修期间,我在 FacesViewsViewHandler 中犯了一个向后兼容性错误,其中 <h:form> 操作 URL 被操纵以包含 MultiViews 功能的虚拟文件夹。查询字符串参数已从原始操作 URL 中删除,并且未重新添加。

@ConversationScoped 依赖 cid 请求参数出现在 <h:form> 操作 URL 中,如 /context/page?cid=1 中一样。因此,这变成了 /context/page,因此对话不会在回传中保留。

我将在下一个 OmniFaces 版本中解决这个问题,现在您可以通过将以下上下文参数添加到 web.xml.

来恢复所需的行为
<context-param>
    <!-- Workaround for disappearing @ConversationScoped ?cid= parameter -->
    <!-- This can be removed in next OmniFaces version after 2.6 -->
    <param-name>org.omnifaces.FACES_VIEWS_VIEW_HANDLER_MODE</param-name>
    <param-value>BUILD_WITH_PARENT_QUERY_PARAMETERS</param-value>
</context-param>

此参数触发构建 URL 的不同方式,从而显式保留原始操作 URL 中的整个查询字符串。