从 GlassFish 3 迁移到 Payara 4 - 面临 CDI 启用问题答案

【问题标题】：Migration from GlassFish 3 to Payara 4 - Facing CDI enablement issue从 GlassFish 3 迁移到 Payara 4 - 面临 CDI 启用问题
【发布时间】：2018-05-04 06:20:11
【问题描述】：

我正在研究将应用程序从 GlassFish 3 迁移到 Payara 4 的 POC。我已经在 Payara 中完成了所需的配置设置，例如 jdbc 连接池、队列等。应用程序中有 EJB 组件，但它构建成一个war 文件并在 GlassFish 3 服务器上部署和运行。但是，当我尝试在 Payara 4 上部署时，CDI 错误显示为：

部署期间发生错误：加载应用程序时出现异常：CDI 定义失败：HV000151：覆盖另一个方法的方法不得更改参数约束配置....

错误堆栈跟踪： 引起：javax.validation.ConstraintDeclarationException：HV000151：覆盖另一个方法的方法不得更改参数约束配置，... 在 org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply（OverridingMethodMustNotAlterParameterConstraints.java:24）在 org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:460) 在 org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:378) 在 org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:677)

由于 CDI 启用是 Payara 中添加的新功能，因此在将应用程序从较低版本的 GF 迁移到 Payara 时必须进行一些配置更改，这似乎很难理解。那么有没有办法在 Payara 上实际部署这个 war 文件呢？

【问题讨论】：

标签： jakarta-ee ejb cdi overriding payara

【解决方案1】：

尝试在禁用隐式 CDI 的情况下部署 WAR

在管理控制台中，在部署应用程序时取消选中Implicit CDI选项
从控制台部署时，添加属性implicitCdiEnabled=false，例如asadmin deploy --properties=implicitCdiEnabled=false myapp.war

如果您从 IDE 进行部署或不想在每次部署时禁用隐式 CDI，您可以尝试将 beans.xml 文件添加到应用程序的 WEB-INF 文件夹中，并将 bean-discovery-mode 设置为 @987654327 @，见：https://docs.oracle.com/javaee/7/tutorial/cdi-adv001.htm

解释：在 Payara 4 和 Java EE 7 中，有一个称为隐式 bean 发现的新功能。这意味着如果 JAR/WAR 文件不包含 beans.xml 文件，则某些类会自动转换为 CDI bean。如果您的应用程序不使用 CDI 或使用不支持 CDI 的库，这有时会导致问题。

【讨论】：

我已经从管理控制台部署了 war 文件并取消了隐式 CDI 选项，但仍然面临同样的问题。因为我想启用隐式 CDI，所以我在 beans.xml 文件中将 bean-discovery-mode 设置为 none，我没有遇到这个问题。但是，我在加载应用程序时遇到异常：javax.ejb.CreateException：Singleton Object 的初始化失败。在服务器日志中，我发现 Singleton 类中引用的 Ejb 对象引发了 Null Pointer 异常。所以我想现在 EJBs 对象在 beans.xml 被修改后没有被启动。
看来OverridingMethodMustNotAlterParameterConstraints 的原始错误来自 bean 验证，而不是来自 CDI。您能找到导致异常的代码部分吗？堆栈跟踪表明您的代码覆盖了对其参数具有 bean 验证约束的方法，并修改了覆盖方法中的约束，这是不允许的。堆栈跟踪没有说明您的代码的哪一部分。
我无法分享原始代码。但是，虚拟场景如下：有一个 EJB 接口，其方法如下： public String save(String input);它的实现类覆盖了对其形式参数具有参数约束的方法，例如 -- public String save(@NotNull String input);现在这在 GlassFish3 中有效，但 Payara 抛出了上述错误。在这种情况下，我已经尝试了有/没有约束的两种方式，但我没有收到此错误。由于有很多 ejb 模块，所以我不想更改任何代码，而是想在配置级别处理它。
似乎 Bean 验证规范添加了对在子类型中放置验证的约束：beanvalidation.org/1.1/spec/…。这在 GlassFish 3 中不存在，但适用于 GlassFish 4 和 Payara 4 以及任何 Java EE 7 服务器。我认为您无法在不更改代码的情况下迁移到 Payara 4 - 您需要将约束从实现转移到它们的接口。