【发布时间】：2019-04-04 16:18:51
【问题描述】：
作为 JSF 2.3，@ManagedBean 和其他 javax.faces.bean.* 注释已被弃用并被 JavaEE 6 CDI 取代。
我成功地制作了一个示例 JSF 项目，并使用服务器实现“glassfish.jsf.jar”将其部署到 WebLogic，并且在 WEB-INF/lib 中没有实现 JSF 或 CDI。
但我害怕有时会被服务器实现卡住，因为我的应用程序在不同的应用程序服务器中工作时表现不同，所以我认为如果我能控制 JSF 实现会更好。
过去 4 天我一直在寻找一种方法来使用自定义 JSF 实现（Mojarra 或 MyFaces），使用新的 CDI 注释或任何其他 DI 框架，但没有运气。
如果我想摆脱 @ManagedAnnotations，我必须使用 JSF 和 CDI 的 JavaEE 服务器实现。
我的问题：有没有办法在我的 WAR 中包含我首选的 JSF 和 CDI 实现，这些实现将部署到不同的应用程序服务器，如 WebLogic 和 WildFly。
注意：我从 2013 年找到了一个 old question，答案为否，但我想知道这个答案是否仍然有效
2018 年 2 月 11 日编辑： 我成功地在 Tomcat 服务器上安装了一个带有嵌入式 JSF (Mojarra) 和 CDI (Weld) 的项目，没有任何问题。我想是因为Tomcat是Servlet Container所以没有冲突。
我认为我的问题是因为我的嵌入式 CDI 和 Weld 的服务器实现版本之间存在冲突。我找不到让我的应用程序像黑盒一样的解决方案。
我使用了这个 weblogic.xml 假的
<prefer-application-packages>
<package-name>!javax.servlet.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>!javax.servlet.*</resource-name>
</prefer-application-resources>
【问题讨论】：
-
我知道 WildFly 允许动态交换 JSF 实现。这可能会解决您的部分麻烦。然而，两台服务器都被锁定在 CDI 实现中（实际上它应该是 Weld 在两者中），因为需要非常特定的服务器端实现来内部处理 EJB 支持、拦截器、挂钩到服务器生命周期等。我无法想象服务器可以轻松替换 CDI老实说执行。 （几乎）所有 EE 技术都以某种方式与 CDI 集成，充其量您需要供应商特定的 API/SPI 供服务器处理。
-
@Siliarus 我也“无法想象服务器可以轻松取代 CDI 实现”，但我要求在做出决定之前确定。我无法理解像这样在 CDI 和 JSF 之间建立粘合剂的好处，因为如果当前的服务器实现有问题，升级就不容易了。 Weblogic 不提供一年后的版本。
-
我想说的是 WildFly，它通常是最新的并且易于升级到新版本。
-
@Siliarus 我们有两个客户的问题。其中之一使用 WebLogic 而没有任何改变的意图，因此，应用程序将在不同的实现和/或 JSF 和 CDI 版本上运行。我认为最好使用 JSF2.2 和 Spring 来避免任何未来的问题，你怎么看？
-
我不熟悉 Spring 来判断。尽管您的客户真的需要最新的实施版本吗？毕竟规格不会经常变化......