【问题标题】:@ConversationScoped bean behaves as @RequestScoped since OmniFaces 2.5 FacesViews自 OmniFaces 2.5 FacesViews 起,@ConversationScoped bean 的行为与 @RequestScoped 相同
【发布时间】:2017-06-21 17:28:53
【问题描述】:

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

接下来,我有一种基于@ConversationScoped 的向导实现。它拥有一个名为ViewManager 的类,它本身有一个视图列表。初始化工作正常,这个列表被填满。但不知何故,当第一个表单/视图被提交时,它会被清除(设置为 null)。初始化后永远不会调用此设置器,因此我的代码不会更改它。不知何故,视图管理器实例仍然可用,只是视图管理器中的这个视图列表为空,这有点奇怪。

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

提前致谢:)

【问题讨论】:

  • 你在使用 FacesViews 吗? @ConversationScoped 依赖于存在的特定请求参数。从理论上讲,这可能会以某种方式丢失。
  • 据我所知,我使用的是ExtensionlessURLs,仅此而已。 org.omnifaces.FACES_VIEWS_SCAN_PATHS/*.xhtml

标签: jsf cdi jsf-2.2 omnifaces


【解决方案1】:

在 OmniFaces 中,FacesViews 无扩展 URL 功能在 2.5 版中进行了大修,以支持所谓的 MultiViews,您可以在 this blog 上阅读。

在这次大修期间,我在 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 中的整个查询字符串。

【讨论】:

  • 啊,完美!这解决了我所有的问题。非常感谢!
猜你喜欢
  • 2016-04-06
  • 1970-01-01
  • 1970-01-01
  • 2014-06-02
  • 1970-01-01
  • 2011-06-08
  • 2011-07-12
  • 2011-03-11
  • 2015-07-14
相关资源
最近更新 更多