我找到了一些关于将 JSF 技术与 Spring Boot 集成的教程，但让 OmniFaces 与 Spring Boot 一起工作似乎是一项相当复杂的工作。将这两者整合在一起是个好主意吗？
【问题讨论】：
标签： jsf spring-boot integration omnifaces
首先，Java EE 和 Spring 是相互竞争的框架。一般来说，选择其中一种而不是试图混合它们是最容易的。从长远来看，它会减少初学者的困惑，减少互操作性的烦恼。
Java EE 框架面向 Java EE 容器（WildFly、TomEE、Payara 等），而 Spring 框架面向准系统 servlet 容器（Tomcat、Jetty 等）。 JSF 虽然是 Java EE 框架的一部分，但最初不需要太多其他 Java EE 工件作为依赖项，因此它也可以毫不费力地在准系统 servlet 容器中运行。 Java EE 的另一部分只需要 JSTL，手动安装在准系统 servlet 容器中相当简单。
从 JSF 2.0 版开始，添加了一个可选的 Bean Validation (JSR303) 依赖项，它也很容易安装在准系统 servlet 容器中。
从 JSF 版本 2.2 开始，添加了一个可选的 CDI 依赖项，这在 Weld 的情况下也很容易安装在准系统 servlet 容器中。然而，问题来了：Spring 仅部分支持 CDI。支持来自javax.inject.* 的任何内容，但不支持来自javax.enterprise.context.* 的任何内容。这迫使用户或多或少地使用 Spring 管理的 bean 而不是 CDI 管理的 bean。
根据未来的 JSF 2.3 版，JSF 自己的@ManagedBean 工具将被弃用，CDI 依赖项将成为必需，并且将添加更多可选的 Java EE 依赖项：WebSocket (JSR356) 和 JSONP (JSR353)。完全需要 CDI 不能与 Spring 配合得很好，因为它们拒绝完全实现 CDI。
反过来，OmniFaces 完全适合 JSF。 OmniFaces 1.x 面向 JSF 2.0，不需要 CDI。 OmniFaces 1.1x 甚至没有 CDI。 OmniFaces 2.x 以 JSF 2.2 为目标，不同之处在于 CDI 是必需的而不是可选的。这样做是因为 OmniFaces 在设计时考虑到了“最佳实践”，并试图迫使用户转向 CDI 进行 bean 管理，特别是因为 JSF 本身也将朝着需要 CDI 的方向发展，因此 OmniFaces 2.x 用户会更好地为未来做好准备。
鉴于上面解释的 CDI 问题，您现在应该意识到最好选择无 CDI 的 OmniFaces 1.1x，以防您想使用 Spring 而不是 Java EE。最新的 1.1x 版本是 1.14，它恰好被集成为 JoinFaces 的一部分。
什么是 JoinFaces？
这个项目可以在 JAR 打包的 Spring Boot 应用程序中使用 JSF。
它自动配置 PrimeFaces、PrimeFaces Extensions、BootsFaces、ButterFaces、RichFaces、OmniFaces、AngularFaces、Mojarra 和 MyFaces 库以在嵌入式 Tomcat、Jetty 或 Undertow servlet 容器中运行。
虽然我不是 Spring 人，也无法根据自己的经验判断，但如果您想继续使用 Spring Boot + JSF，我想说 JoinFaces 是您的最佳选择。
请注意，虽然 JoinFaces 网站说它支持 CDI 注释，但这并不意味着它支持 CDI 实现，它实际上只支持来自javax.inject.* 包的注释。
【讨论】：