我已经找到了一些有关将JSF技术与Spring Boot集成的教程，但是要使OmniFaces与Spring Boot一起工作似乎是一项相当艰巨的工作。完全将这两者整合在一起是个好主意吗？
最佳答案
首先，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验证(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问题，您现在应该意识到，如果要使用Spring而不是Java EE，最好选择无CDI的OmniFaces 1.1x。最新的1.1x版本是1.14，并且恰好已集成为JoinFaces的一部分。
What is JoinFaces?
This project enables JSF usage inside JAR packaged Spring Boot Application.
It autoconfigures PrimeFaces, PrimeFaces Extensions, BootsFaces, ButterFaces, RichFaces, OmniFaces, AngularFaces, Mojarra and MyFaces libraries to run at embedded Tomcat, Jetty or Undertow servlet containers.
尽管我不是Spring专家，也无法根据自己的经验告诉他们，但是我想说如果您想继续使用Spring Boot + JSF，JoinFaces是您的最佳选择。
请注意，尽管JoinFaces站点表示它支持CDI批注，但这并不意味着它支持CDI实现，它实际上仅支持
javax.inject.*包中的批注。也可以看看:
关于jsf - 如何将OmniFaces与Spring Boot集成，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41416546/