Hibernate Validator

`GetterPropertySelectionStrategy` SPI 合同已经调整。`getGetterMethodNameCandidates()` 方法现在返回一个 `List` 而不是一个 `Set`。

Jakarta EE 10

现在使用的 EL 实现是 `org.glassfish.expressly:expressly`

<dependency>
   <groupId>org.glassfish.expressly</groupId>
   <artifactId>expressly</artifactId>
   <version>5.0.0-M1</version>
</dependency>

Jakarta EE 9 (也称为 `jakarta.*` 包的大变更)

XML 命名空间已更改

`@SafeHtml` 约束已删除

默认情况下，表达式语言对自定义违规的禁用

默认情况下，表达式语言对约束的 Bean 方法执行禁用

`@SafeHtml` 约束已删除

默认情况下，表达式语言对自定义违规的禁用

默认情况下，表达式语言对约束的 Bean 方法执行禁用

`@SafeHtml` 已被弃用并标记为将来删除。

`@SafeHtml` 已被弃用并标记为将来删除。

如果您使用的是 CDI 集成，请确保要验证的所有 bean 都具有 Bean Validation 注解（无论是约束、`@Valid` 还是 `@ValidateOnExecution`）。如果需要添加注解，只需在类中添加一个简单的 `@ValidateOnExecution` 即可。此限制在 6.0.10.Final 之前存在，现在由于 CDI 应用程序的启动时间严重回归而再次出现。

我们从 `javax.el` 解析器列表中删除了 `StaticFieldELResolver`。此功能是在 6.x 周期中添加的，从未记录。如果您想从 EL 表达式中调用方法，只需将包含方法的对象注入为变量。

一些验证消息已更改以更一致。也就是说，您应该依赖于约束注解对违规进行分类，而不是依赖于消息。

我们修复了 `JPATraversableResolver` 未正确初始化（因此我们使用默认解析器）的问题：`JPATraversableResolver` 现在在任何 JPA 环境中默认使用，因为它应该这样（因此 Hibernate Validator 不会验证或级联尚未加载的延迟加载属性）。如果您不想要这种行为，可以为您的 `ValidatorFactory` 覆盖 `TraversableResolver`。此回归是在 6.0.3.Final 中引入的。

我们修复了 CDI 扩展，使其能够正确考虑类层次结构中的注解。在 6.0.10.Final 之前，如果所考虑的类本身没有任何与验证相关的注解，但其类层次结构中有，则类层次结构中的注解会被忽略。现在不再是这种情况。注意：如果所考虑的类本身至少有一个与验证相关的注解，则效果良好。

约束验证器负载（在 6.0.8.Final 中引入的孵化功能）已从 `HibernateConstraintValidatorInitializationContext` 移动到 `HibernateConstraintValidatorContext`。有关更多信息，请参见 文档。

为了提高与之前在 WildFly 中提供的版本的兼容性，我们在 6.0 的早期版本中重新引入了几个被移除的东西

Hibernate Validator 现在在尝试对 bean 中不存在的属性或方法执行验证时，在任何情况下都会抛出异常（在此版本之前，如果 bean 完全不受约束，则不会抛出任何错误，并且在验证方法参数时会抛出错误，但在验证返回值时不会）。更一般地说，现在对各种 `Validator#validate…​()` 方法参数的健全性检查始终应用，即使 bean 未受约束。

Hibernate Validator 的组 ID 已从 `org.hibernate` 更改为 `org.hibernate.validator`。分别通过 `org.hibernate.validator:hibernate-validator:6.0.0.Final`、`org.hibernate.validator:hibernate-validator-cdi:6.0.0.Final` 和 `org.hibernate.validator:hibernate-validator-annotation-processor:6.0.0.Final` 引用这些工件。

删除/更改实验性功能，以支持 Bean Validation 2.0 中标准化的等效功能

我们稍微改变了 `javax.el ExpressionFactory` 的初始化方式。在此版本之前，如果您使用的是 `ResourceBundleMessageInterpolator`，HV 可以仅通过对 `javax.el` API 的依赖关系来初始化，因为 `ExpressionFactory` 在引导时未初始化（并且它会在消息插值时失败）。由于我们现在在引导时初始化 `ExpressionFactory`，因此如果使用 `ResourceBundleMessageInterpolator`，还需要使用 `javax.el` 实现。所以，最终，要么您根本不使用 `ResourceBundleMessageInterpolator`，然后您不需要任何 `javax.el` 依赖关系，要么您使用 `ResourceBundleMessageInterpolator` 以及 `javax.el` API 和实现被 HV 要求。

已从公共 API 中删除（实验性的）`ConstraintDefinitionContributor` 概念。相反，在需要以编程方式添加约束定义时，应该使用新的方法 `ConstraintMapping#constraintDefinition()`。此更改使以编程方式定义和声明约束的 API 与 XML 方法一致，从而实现相同的功能。以下元素已被删除

通过 Java 服务加载机制（通过 META-INF/services/javax.validation.ConstraintValidator 文件）添加约束验证器的方法仍然存在。

配置选项 hibernate.validator.constraint_mapping_contributor 已被弃用，取而代之的是 hibernate.validator.constraint_mapping_contributors，它接受以逗号分隔的贡献者列表。常量 o.h.v.HibernateValidatorConfiguration#CONSTRAINT_MAPPING_CONTRIBUTOR 已被弃用，取而代之的是 o.h.v.HibernateValidatorConfiguration#CONSTRAINT_MAPPING_CONTRIBUTORS (HV-1065)

在 5.1.0.Beta1 中引入的 @Mod10Check 和 @Mod11Check 约束进行了全面改进。索引现在始终为包含（尤其是 endIndex），并且始终相对于验证的值，独立于 ignoreNonDigitCharacters。此外，checkDigitPosition 已重命名为 checkDigitIndex。

如果在用于配置一个验证器工厂的映射中多次配置同一个元素（类型、属性、方法等），则程序化约束声明 API 现在会引发 ValidationException。虽然这在以前是可能的，但不建议这样做，因为它可能会在配置冲突的注释忽略选项时导致问题 (HV-716)。相反，选择任何元素只配置一次，然后应用所有必需的配置。

当您自己从源代码构建 Hibernate Validator 时，您现在需要使用 JDK 7 和 Maven 3.0.3 或更高版本。请注意，创建的二进制文件仍然与 Java 6 兼容 (HV-619, HV-797)。

Hibernate Validator CDI 可移植扩展已从主 JAR 中提取到一个单独的模块中 (HV-778)。要使用该扩展，必须将依赖项 org.hibernate:hibernate-validator-cdi:5.0.0.CR5 添加到类路径中。

@ValidateExecutable 已重命名为 @ValidateOnExecution，并引入了 ExecutableType.IMPLICIT - BVAL-437

MethodDescriptor#areParametersConstrained 已重命名为 MethodDescriptor#hasConstrainedParameters，MethodDescriptor#isReturnValueConstrained 已重命名为 MethodDescriptor#hasConstrainedReturnValue - BVAL-432

XML 配置元素 <validated-executables></validated> 已重命名为 <default-validated-executable-types></default>，匹配的 BootstrapConfiguration#getValidatedExecutableTypes 已重命名为 BootstrapConfiguration#getDefaultValidatedExecutableTypes - BVAL-435

ParameterNameProvider 接口的方法现在返回 List 而不是 String[] - BVAL-409

@CrossParameterConstraint 已被 @SupportValidationTarget 取代 - BVAL-391

已将 javax.validation.MethodValidator 重命名为 ExecutableValidator；j.v.Validator#forMethods() 已重命名为 forExecutables() (BVAL-355)

使方法 j.v.ExecutableValidator#validateConstructorParameters() 和 validateConstructorReturnValue() 更易于使用 (BVAL-358)

已弃用 org.hibernate.validator.messageinterpolation.ValueFormatterMessageInterpolator；现在可以在 EL 表达式中使用验证的值 (BVAL-223)

已删除注释 javax.validation.cdi.MethodValidated (BVAL-376)

已删除 Maven 原型 (HV-650)

此版本需要 Bean Validation 1.1.0.Beta2

方法验证方法已从 javax.validation.Validator 移动到 MethodValidator (BVAL-310)

javax.validation.ConfigurationSource 已重命名为 BootstrapConfiguration (BVAL-293)

已删除在 Hibernate Validator 4.3.0 中弃用的类型 (HV-584)

此版本需要 Bean Validaton 1.1 作为依赖项（更具体地说，是 1.1.0.Alpha1）

自定义方法验证功能已被 Bean Validation 1.1 指定的方法验证所取代

已删除来自 HV-561 的已弃用类和方法。这意味着如果您使用任何受影响的 API，则需要迁移

org.hibernate.validator.group.DefaultGroupSequenceProvider 已被弃用，取而代之的是 org.hibernate.validator.group.spi.DefaultGroupSequenceProvider

org.hibernate.validator.resourceloading.ResourceBundleLocator 已被弃用，取而代之的是 org.hibernate.validator.spi.resourceloading.ResourceBundleLocator

org.hibernate.validator.cfg.ConstraintMapping 的构造函数已弃用。现在可以通过 HibernateValidatorConfiguration#createConstraintMapping() 创建 ConstraintMapping 实例

包 org.hibernate.validator.method 及其包含的类已弃用，目前尚无替代方案。在 Hibernate Validator 5 中，将删除此包，以与 Bean Validation 1.1 保持一致。然后，方法级验证方法将通过 javax.validation.Validator 提供。

org.hibernate.validator.internal.util.LazyValidatorFactory 已被弃用，将在 HV 5 中删除