Hibernate Validator Migration Guide

5.1.x

 

5.1.0.CR1

  • The @Mod10Check and @Mod11Check constraints introduced in 5.1.0.Beta1 got an overhaul. Indeces are now always inclusive (especially the endIndex) and are always relative to the validated value, independent of ignoreNonDigitCharacters. Also checkDigitPositon got renamed into checkDigitIndex.

 

5.1.0.Alpha1

  • The programmatic constraint declaration API raises a ValidationException now in case the same element (type, property, method etc.) is configured more than once within the mappings used to configure one validator factory. While this was possible before, it was not recommended as it may have caused issues when e.g. configuring conflicting annotation ignore options (HV-716). Instead select any element to be configured once and apply all required configurations subsequently.
  • When building Hibernate Validator from the sources yourself, you need to use now JDK 7 and Maven 3.0.3 or later. Note that the created binaries are still Java 6 compatible (HV-619, HV-797).

 


 

5.0.x

 

5.0.1.Final

No migration concerns.

 

5.0.0.Final

No migration concerns.

 

5.0.0.CR5

The Hibernate Validator CDI portable extension has been extracted from the main JAR into a separate module (HV-778). To make use of the extension, the dependency org.hibernate:hibernate-validator-cdi:5.0.0.CR5 must be added to the classpath.

 

5.0.0.CR4

No migration concerns.

 

5.0.0.CR3

 

  • @ValidateExecutable is reamed to @ValidateOnExecution and the ExecutableType.IMPLICIT is introduced - BVAL-437
  • MethodDescriptor# areParametersConstrained got renamed into MethodDescriptor# hasConstrainedParameters and MethodDescriptor# isReturnValueConstrained into MethodDescriptor#hasConstrainedReturnValue - BVAL-432
  • XML config element <validated-executables></validated> is renamed to <default-validated-executable-types></default> and matching BootstrapConfiguration#getValidatedExecutableTypes to BootstrapConfiguration#getDefaultValidatedExecutableTypes - BVAL-435

 

5.0.0.CR2

No migration concerns.

 

5.0.0.CR1

 

  • Methods of ParamterNameProvider inerface return now List instead of String[] -  BVAL-409
  • @CrossParamterConstraint got replaced by @SupportValidationTarget - BVAL-391

 

5.0.0.Beta1

 

  • Renamed javax.validation.MethodValidator  to ExecutableValidator; j.v.Validator#forMethods() renamed to forExecutables() (BVAL-355)
  • Made methods j.v.ExecutableValidator#validateConstructorParameters() and validateConstructorReturnValue() more usable (BVAL-358)
  • Deprecated org.hibernate.validator.messageinterpolation.ValueFormatterMessageInterpolator; the validated value can now be used within EL expressions (BVAL-223)
  • Removed annotation javax.validation.cdi.MethodValidated (BVAL-376)
  • Removed Maven archetype (HV-650)

5.0.0.Alpha2

 

  • This release requires Bean Validaton 1.1.0.Beta2
  • Methods for method validation moved from javax.validation.Validator to MethodValidator (BVAL-310)
  • javax.validation.ConfigurationSource renamed to BootstrapConfiguration (BVAL-293)
  • Removed types deprecated in Hibernate Validator 4.3.0 (HV-584)

5.0.0.Alpha1

 

  • This release requires Bean Validaton 1.1 as a dependency (more concretely 1.1.0.Alpha1)
  • The custom method validation feature has been replaced by the method validation specfied by Bean Validation 1.1
  • The deprecated classes and methods from HV-561 have been removed. This means if you are using any of the affected APIs you will need to migrate

 


 

4.3.x

 

This section describes changes made in different releases of version 4.3.0. It helps you to migrate from version 4.2.0.Final to 4.3.0.Final (yet to be released) or between releases of version 4.3.0. Hibernate Validator 4.3 requires Java 6!

 

4.3.0.Beta1

 

HV-561 introduced several deprecations (see the JavaDoc for a complete deprecation list):

  • org.hibernate.validator.group.DefaultGroupSequenceProvider is deprecated and replaced by org.hibernate.validator.group.spi.DefaultGroupSequenceProvider
  • org.hibernate.validator.resourceloading.ResourceBundleLocator is deprecated and replaced by org.hibernate.validator.spi.resourceloading.ResourceBundleLocator
  • The constructor of org.hibernate.validator.cfg.ConstraintMapping is deprecated. Instances of ConstraintMapping are now created via HibernateValidatorConfiguration#createConstraintMapping()
  • The package org.hibernate.validator.method with its containing classes is deprecated without alternative for now. In Hibernate Validator 5 this package will be removed to align with Bean Validation 1.1. The method level validation methods will then be available via javax.validation.Validator.
  • org.hibernate.validator.internal.util.LazyValidatorFactory is deprecated and will be removed in HV 5

 

4.3.0.Alpha1

 

This is the first release after Hibernate Validator 4.2.0.Final and backwards compatible. However, the used logging framework has changed to JBoss Logging. This means org.jboss.logging:jboss-logging is now a required runtime dependency replacing org.slf4j:slf4j-api. You can still use slf4j, log4j or Java Logging though. JBoss Logging is only an additoal layer which allows to internationalize (i18n) the logging and exception messages as well as provinding unique ids for these messages. Under the hood JBoss Logging will use the logging framework of your choice to log the messages.

 

Hibernate Validator now requires a Java 6 runtime

 


 

4.2.x

 

This section describes changes made in different releases of version 4.2.0. It helps you to migrate from version 4.1.0.Final to 4.2.0.Final or between releases of version 4.2.0.

 

4.2.0.Final

 

This release doesn't introduced modifications which can break your existing code if you have already migrated to version 4.2.0.CR1. If you migrate from version 4.1.0.Final the following sections gives you the changes introduced in the different releases leading to this Final version.

 

For more details you can see the release note here.


4.2.0.CR1

 

  • As you already know Hibernate Validator allows the configuration of constraints programmatically. The main feature of this release is the programmatic API allowing constraint configuration on method (HV-431). To implement this in an unambiguous way we had to make yet some more changes to the programmatic API. Programmatic API looks like this now:

 

 

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
    .property( "manufacturer", FIELD )
        .constraint( new NotNullDef() )
    .property( "licensePlate", FIELD )
        .constraint( new NotNullDef() )
        .constraint( new SizeDef()
            .min( 2 )
            .max( 14 ) )
    .property( "seatCount", FIELD )
        .constraint( new MinDef()
            .value ( 2 ) )
.type( RentalCar.class )
    .property( "rentalStation", METHOD )
        .constraint( new NotNullDef() );

 

 

  • Another minor modification which can impact your existing code (if you migrate from Beta2) is HV-488. If you use the method meta data API you will see that the method of MethodDescriptor named getParameterConstraints() was renamed to getParameterDescriptors() to avoid confusion.

 

For more details you can see the release note here.


4.2.0.Beta2

 

The version Beta1 has introduced the possibility to specify constraints on methods. If you use this functionality the following changes will impact your code.

 

  • A big change introduced in this release is HV-421 which defines the behavior of parameter constraint validation. Generally a logical AND is used to combine all constraints defined within a class hierarchy on a given field or method. Doing the same for method parameter constraints, however, causes ambiguities with the definition of Programming by contract where subtypes may only weaken preconditions defined by supertypes. For this release we chose a conservative alternative which prohibit multiple parameter constraints on the same parameter within a class hierarchy. This mean that the following code isn't correct:

 

 

public interface Foo {
     String sayHello(@NotNull String firstName);
}

public class FooImpl implements Foo {
     String sayHello(@NotNull @Size(max=10) String firstName) {
          return "Hello " + firstName;
     }
}

 

 

  • Another minor modification is that the method MethodValidator#validateParameters() (allowing to validate all parameters of a method) was renamed to MethodValidator#validateAllParameters() (HV-415).

 

For more details you can see the release note here.


4.2.0.Beta1

 

  • BVTCK-12 resp. HV-395 required a change in the javax.validation.Path implementation. Unless you iterate over the Path instance returned by Constraint.getPropertyPath() you are not affected by this change.
  • Programmatic configured generic constraints are now configured like this:

 

 

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Foo.class )
.property( "bar", FIELD ) 
   .genericConstraint( MyConstraint.class )
   .param( "value", 1 );

 

 

  • When creating own subclasses of ConstraintDef is it not necessary anymore to repeat the definitions ofmessage, payload and groups. ConstraintDef uses now self-referential generic types.

 

For more details you can see the release note here.