Red Hat

In Relation To Hibernate Validator

In Relation To Hibernate Validator

It has just been a couple of weeks since the 6.0.0.Beta1 release but we needed a new version matching Bean Validation 2.0.0.Beta2.

Hibernate Validator 6 is going to be the reference implementation of Bean Validation 2.0 and, as such, we coordinate releases so you can test the latest additions as soon as possible.

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new since Beta1

Bean Validation 2.0.0.Beta2 support

The main goal of this version is to upgrade to Bean Validation 2.0.0.Beta2.

We fixed a couple of bugs and also introduced a few new features.

Support for non generic types in value extraction

Our value extraction framework (which is the basis of our new container element validation implementation) only supported generic types until now.

We alleviated this restriction by introducing a new type attribute to the ExtractedValue annotation allowing to define the type of the extracted value even in the absence of a type argument providing the information.

Thus, it is now possible to define value extractors as below:

@UnwrapByDefault
public class OptionalIntValueExtractor implements ValueExtractor<@ExtractedValue(type = Integer.class) OptionalInt> {

    @Override
    public void extractValues(OptionalInt originalValue, ValueReceiver receiver) {
        receiver.value( null, originalValue.isPresent() ? originalValue.getAsInt() : null );
    }
}

And that’s indeed what we do in Hibernate Validator to support OptionalInt, OptionalLong and OptionalDouble.

Addition of container element information via the node builder API

The node builder API allows you to define a property path for a constraint violation using the ConstraintValidatorContext.

It is now possible to define container element information for existing node types supporting them or to define container element nodes:

public static class Validator implements ConstraintValidator<MyConstraint, MyBean> {

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        context.disableDefaultConstraintViolation();

        context.buildConstraintViolationWithTemplate( context.getDefaultConstraintMessageTemplate() )
                .addContainerElementNode( "myNode1", Map.class, 1 )
                        .inIterable()
                        .atKey( "key" )
                .addConstraintViolation();

        context.buildConstraintViolationWithTemplate( context.getDefaultConstraintMessageTemplate() )
                .property( "myNode2" )
                        .inContainer( List.class, 0 )
                        .inIterable()
                        .atKey( "key" )
                .addConstraintViolation();

        return false;
    }
}

CDI improvements

Value extractors defined in the XML configuration are now managed beans.

We also fixed an issue that could occur if you were using a managed ParameterNameProvider.

And a few other things

  • @SafeHtml now supports defining accepted protocols (think allowing the data protocol for images) and has an improved programmatic API.

  • The @Min / @Max, @DecimalMin / @DecimalMax validators were split to have one validator per type and avoid reflection at runtime.

The complete list of fixed issues can be found in the release notes.

Getting 6.0.0.Beta2

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Beta2. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 is currently in the Public Review phase, the Public Review Ballot will take place at the beginning of June. The Proposed Final Draft is planned to be released shortly thereafter, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Hibernate Validator 6 is still under active development. We’ll keep you posted with our progress.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. This Beta1 release is coordinated with the 2.0.0.Beta1 release (Public Review Draft) of the Bean Validation specification.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new since Alpha2

Bean Validation 2.0.0.Beta1 support

The main goal of this version is to upgrade to Bean Validation 2.0.0.Beta1.

This was mainly small adjustments to be on par with the latest changes in the specification but we also added a couple of features related to the validation of container elements (think List<@NotBlank String>).

Metadata API support for container element constraints

Until now, the container element constraints were not exposed via the metadata API. You can now obtain them via the API:

// Given a class User with a property declared as Map<@Valid AddressType, @NotNull Address> addresses

PropertyDescriptor propertyDescriptor = validator
        .getConstraintsForClass( User.class )
        .getConstraintsForProperty( "addresses" );

List<ContainerElementTypeDescriptor> containerElementTypeDescriptors =
        propertyDescriptor.getContainerElementTypes();

ContainerElementTypeDescriptor mapKeyDescriptor = containerElementTypeDescriptors.get( 0 );
ContainerElementTypeDescriptor mapValueDescriptor = containerElementTypeDescriptors.get( 1 );

// get the type argument index corresponding to this container element
assert mapKeyDescriptor.getTypeArgumentIndex() == 0;
assert mapValueDescriptor.getTypeArgumentIndex() == 1;

// get the constraint descriptors for this container element
assert mapKeyDescriptor.getConstraintDescriptors().size() == 0;
assert mapValueDescriptor.getConstraintDescriptors().size() == 1;

// indicates if the validation is cascaded
assert mapKeyDescriptor.isCascaded() == true;
assert mapValueDescriptor.isCascaded() == false;

// get the potential nested container elements
assert mapKeyDescriptor.getContainerElementTypes().size() == 0;
assert mapValueDescriptor.getContainerElementTypes().size() == 0;

Support for group conversions in container elements

We added support for cascaded validation of container elements a while ago but we did not support group conversions. They are now supported.

public class User {

    private Map<@Valid AddressType, @Valid @ConvertGroup(from = Default.class, to = BasicChecks.class) Address> addresses;
}

Polished support for the new built-in annotations

The error messages were missing for the new built-in annotations, we fixed it. Note that several translations need an update so if you speak a language other than English, German, French or Ukrainian, don’t hesitate to step up to the plate and send a pull request.

We also added support for @Positive and @Negative to the JavaMoney types.

And, finally, we added support for these new constraints to the annotation processor.

And a few other things

  • @SafeHtml now supports relative URLs thanks to the new baseURI attribute.

  • We fixed a few things to support the latest JDK 9 early access releases.

The complete list of 23 fixed issues can be found in the release notes.

Getting 6.0.0.Beta1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Beta1. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 is currently in the Public Review phase, the Public Review Ballot will take place at the beginning of June. The Proposed Final Draft is planned to be released shortly thereafter, so if you spot any remaining issues or shortcomings in the spec draft, please let us know as soon as possible.

Hibernate Validator 6 is still under active development. We’ll keep you posted with our progress.

As the Bean Validation 2.0 spec is making good progress, you may want to try out the features of the new spec revision with your existing Java EE applications.

WildFly, as a compatible Java EE 7 implementation, comes with Bean Validation 1.1 and its reference implementation Hibernate Validator 5 out of the box. In the following we’ll show you how easy it is to upgrade the server’s modules to the latest Bean Validation release, using a patch file provided by Hibernate Validator.

Getting the patch files

First download the patch file of the Hibernate Validator version you want to upgrade to. The latest release of Hibernate Validator at this point is 6.0.0.Alpha2 which implements the 2.0.0.Alpha2 release of Bean Validation. You can simply fetch the patch file for this release from Maven Central. If you are interested in the latest 5.x release of Hibernate Validator - which is the current stable implementation of Bean Validation 1.1 - you’d grab this file instead.

Both patches can be applied to WildFly 10.1 instances. Generally, we provide patch files for the latest stable version of WildFly at the time of the Hibernate Validator release.

Applying and undoing the patch

Once you’ve downloaded the patch file, change to the installation directory of your WildFly instance and run the following command to apply the patch:

./bin/jboss-cli.sh --command="patch apply hibernate-validator-modules-6.0.0.Alpha2-wildfly-10.1.0.Final-patch.zip"

Now (re-)start WildFly and you can begin to experiment with the new features of Hibernate Validator 6 and Bean Validation 2.0, such as the validation of container elements (think List<@Email String> emails), support for the Java 8 date/time API or the new built-in constraints such as @NotEmpty or @Email.

The nice thing of the patch mechanism is that patches aren’t actually modifying the patched WildFly instance. Any modules contained in the patch are just added in a separate "overlays" directory.

So in case you want go back to the version of Hibernate Validator originally coming with the server, just run this command to undo the patch:

./bin/jboss-cli.sh --command="patch rollback --reset-configuration=true"

You can learn more about the WildFly patching infrastructure in general here and here.

Bonus: Fully automated update for integration tests

In case you are running integration tests for your applications using the fabulous Arquillian framework, you can add the following configuration to your pom.xml. This will first download and extract WildFly, then download the patch file and apply it to the unzipped server:

...
<properties>
    <wildfly.version>10.1.0.Final</wildfly.version>
    <wildfly.core.version>1.0.1.Final</wildfly.core.version>
    <hibernate.validator.version>6.0.0.Alpha2</hibernate.validator.version>
</properties>
...
<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>3.0.0</version>
            <executions>
                <execution>
                    <id>unpack-wildfly</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>unpack</goal>
                    </goals>
                    <configuration>
                        <artifactItems>
                            <artifactItem>
                                <groupId>org.wildfly</groupId>
                                <artifactId>wildfly-dist</artifactId>
                                <version>${wildfly.version}</version>
                                <type>tar.gz</type>
                                <overWrite>false</overWrite>
                                <outputDirectory>${project.build.directory}</outputDirectory>
                            </artifactItem>
                        </artifactItems>
                    </configuration>
                </execution>
                <execution>
                    <id>copy-patch</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>copy</goal>
                    </goals>
                    <configuration>
                        <artifactItems>
                            <artifactItem>
                                <groupId>org.hibernate.validator</groupId>
                                <artifactId>hibernate-validator-modules</artifactId>
                                <version>${hibernate.validator.version}</version>
                                <classifier>wildfly-${wildfly.version}-patch</classifier>
                                <type>zip</type>
                                <outputDirectory>${project.build.directory}</outputDirectory>
                            </artifactItem>
                        </artifactItems>
                    </configuration>
                </execution>
            </executions>
        </plugin>
        <plugin>
            <groupId>org.wildfly.plugins</groupId>
            <artifactId>wildfly-maven-plugin</artifactId>
            <version>1.1.0.Final</version>
            <dependencies>
                <!-- Contains the patch command -->
                <dependency>
                    <groupId>org.wildfly.core</groupId>
                    <artifactId>wildfly-patching</artifactId>
                    <version>${wildfly.core.version}</version>
                </dependency>
            </dependencies>
            <executions>
                <!-- Currently the WF Maven plug-in cannot apply offline commands,
                     although patch itself wouldn't require a running server;
                     see https://issues.jboss.org/projects/WFMP/issues/WFMP-11 -->
                <execution>
                    <id>start-wildfly-for-patching</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>start</goal>
                    </goals>
                </execution>
                <execution>
                    <id>apply-patch-file</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>execute-commands</goal>
                    </goals>
                    <configuration>
                        <fail-on-error>false</fail-on-error>
                        <commands>
                            <command>patch apply --path ${project.build.directory}/hibernate-validator-modules-${hibernate.validator.version}-wildfly-${wildfly.version}-patch.zip</command>
                        </commands>
                    </configuration>
                </execution>
                <execution>
                    <id>shutdown-wildfly-for-patching</id>
                    <phase>pre-integration-test</phase>
                    <goals>
                        <goal>shutdown</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <jbossHome>${project.build.directory}/wildfly-${wildfly.version}/</jbossHome>
            </configuration>
        </plugin>
    </plugins>
</build>
...

Applying this configuration will give you a WildFly instance with the latest release of Bean Validation and Hibernate Validator which you then can use as a deployment target for your integration tests, employing the latest Bean Validation 2.0 features. You can find a complete Maven project with a simple Arquillian test on GitHub in the hibernate-demos repository.

As you see it’s not difficult to upgrade WildFly 10 to Bean Validation 2.0, so don’t hesitate and give it a try. Your feedback on the new spec revision is always welcome on the mailing list or in the forum.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. This Alpha2 release is coordinated with the 2.0.0.Alpha2 release of the Bean Validation specification.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

If you missed the Alpha1 release, consulting its announcement might be beneficial to you before continuing your reading.

What’s new since Alpha1

Improved container element validation support

Container element validation support is the big new feature of Bean Validation 2.0 and it got some more love during this cycle.

Programmatic API and XML support

To obtain the equivalent of:

public class FishTank {

    private Optional<@Valid FishTankModel> model;

    private Map<@Size(min = 3, max = 10) String, @Min(1) Integer> fishCountByType;
}

it is now possible to declare container element type constraints and cascaded validation either via an XML mapping configuration (which is part of the Bean Validation 2.0 specification):

[...]
    <bean class="com.acme.FishTank" ignore-annotations="false">
        <field name="model">
            <containerElementType>
                <valid />
            </containerElementType>
        </field>
        <field name="fishCountByType">
            <containerElementType typeArgumentIndex="0">
                <constraint annotation="javax.validation.constraints.Size">
                    <element name="min">
                        <value>3</value>
                    </element>
                    <element name="max">
                        <value>10</value>
                    </element>
                </constraint>
            </containerElementType>
            <containerElementType typeArgumentIndex="1">
                <constraint annotation="javax.validation.constraints.Min">
                    <element name="value">
                        <value>1</value>
                    </element>
                </constraint>
            </containerElementType>
        </field>
    </bean>
[...]

or via the (implementation specific) programmatic API:

ConstraintMapping newMapping = config.createConstraintMapping();
newMapping
    .type( FishTank.class )
        .property( "model", FIELD )
            .containerElementType()
                .valid()
        .property( "fishCountByType", FIELD )
            .containerElementType( 0 )
                .constraint( new SizeDef().min( 3 ).max( 10 ) )
            .containerElementType( 1 )
                .constraint( new MinDef().value( 1 ) );

Other improvements

We also made a couple of more minor improvements:

  • the TYPE_ARGUMENT node type has been renamed to CONTAINER_ELEMENT (type argument don’t make sense for annotated array elements)

  • we allow per context custom value extractors

  • we allow value extractors to be contributed using the service loader mechanism

  • we allow to specify value extractors using XML configuration

  • we explore the parent classes and interfaces to search the ValueExtractor definition

Support for the new constraints added to Bean Validation 2.0

In the Alpha2 release of Bean Validation 2.0, we introduced the following new constraints:

  • @NotBlank: check that a char sequence is not blank (i.e. not null, and length of trimmed char sequence > 0)

  • @NotEmpty: check that an element (char sequence, collection, array) is not null and not empty

  • @Email: check that a char sequence is a valid email

  • @Positive: check that a number is positive

  • @Negative: check that a number is negative

We added support for these new constraints to Hibernate Validator.

Performance improvements

We started to run a few benchmarks on Hibernate Validator 6 and we fixed a few performance regressions.

6.0.0.Alpha2 is now significantly faster than 5.4, mostly thanks to the new ValueExtractor design.

Getting 6.0.0.Alpha2

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Alpha2. Note that the group id has changed from org.hibernate (Hibernate Validator 5 and earlier) to org.hibernate.validator (from Hibernate Validator 6 onwards).

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are still under active development. We will release new alphas on a regular basis.

Hibernate Validator 5.4.1.Final

Posted by    |       |    Tagged as Hibernate Validator Releases

A bugfix release

Hibernate Validator 5.4.1.Final is a bugfix release, mostly for corner cases. 5.4.1.Final is a recommended upgrade for everyone.

Here are the most prominent bugfixes of this release:

  • HV-1088 - Fix a concurrency issue in validator initialization that you probably wouldn’t encounter in a normal usage - you’re supposed to use a shared ConstraintValidatorFactory which mitigates the issue

  • HV-1280 - Fix a class loading conflict with Xerces in modular environements (e.g. WildFly)

  • HV-1252 - Fix an issue with the annotation processor and JavaMoney support. Thanks go to Guillaume Husta for this one.

  • HV-1253 - A few TYPE_USE mentions had been mistakenly introduced in 5.4 when backporting from 6 (5.4 still supports Java 6)

We also integrated a new translation, Persian, thanks to Shahram Goodarzi.

And finally, we upgraded our build instructions for the latest JDK 9 early access build.

As usual, you can find the complete list of all addressed issues in the change log.

Getting 5.4.1.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.1.Final.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are under active development. We will release a new alpha in the next few days.

As far as Bean Validation 2.0 is concerned, there are very interesting discussions going on about value extraction which is THE big BV 2.0 feature. Come and join us on Bean Validation website to define the future of Bean Validation.

Today we’ll be talking about Hibernate Validator and how you can provide your own constraints and/or validators in a fully self-contained manner. Meaning packaging it all into its own JAR file, in a way that others can use your library by simply adding it to the classpath.

This functionality is based on Hibernate Validator usage of Java’s ServiceLoader mechanism that allows to register additional constraint definitions. But more on the details later.

What can be a real life scenario for building your own library with constraints and sharing it? Well, let’s say that you are building some library with data classes that user might want to validate. As it may be tough to keep track of all such libraries and write/maintain all those constraints for them - Hibernate Validator provides authors of such libraries a possibility to write and share their own validation extensions. Which can be picked up by Hibernate Validator and used to validate your data classes.

Also this ServiceLoader mechanism allows to solve another problem. As you are trying to be a good developer and provide end users of your library only with the relevant classes and hide implementation details from them, you may not want to expose your validator implementation by mentioning it in the validatedBy() parameter of the @Constraint annotation. By using the approach described in this post you can achieve all these thing.

For our examples we will be creating Maven projects with two modules - one will contain validators and represent a "library" that can be shared, another module will be a consumer of this library and will contain some tests.

Enough of the talking, let’s validate some beans! That’s why we all gathered here, right? :)

Using custom annotations and validators

First let’s consider a case of adding your own constraint annotation and a corresponding validator.

Time, it needs time …​

While Hibernate Validator 5.4 supports a wide range of the Java 8 date/time API (and Bean Validation 2.0 will move this support to the specification level), there are some types not supported, one of them being Duration. This type is not describing a point in time so the regular date/time constraints (@Future / @Past) do not make sense for it. So if for instance we wanted to validate that a given duration has a specified minimum length, a new constraint is needed. Let’s call it @DurationMin.

Our new constraint annotation might look like this:

DurationMin.java
@Documented
@Constraint(validatedBy = { })
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER, TYPE_USE })
@Retention(RUNTIME)
@Repeatable(List.class)
@ReportAsSingleViolation
public @interface DurationMin {

    String message() default "{com.acme.validation.constraints.DurationMin.message}";
    Class<?>[] groups() default { };
    Class<? extends Payload>[] payload() default { };

    long value() default 0;
    ChronoUnit units() default ChronoUnit.NANOS;

    /**
     * Defines several {@code @DurationMin} annotations on the same element.
     */
    @Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER, TYPE_USE })
    @Retention(RUNTIME)
    @Documented
    @interface List {
        DurationMin[] value();
    }
}

Now that we have an annotation, we need to create a corresponding constraint validator. To do that you need to implement the ConstraintValidator<DurationMin, Duration> interface, which contains two methods:

  • initialize() - initializes the validator based on annotation parameters

  • isValid() - performs actual validation

An implementation might look like this:

DurationMinValidator.java
public class DurationMinValidator implements ConstraintValidator<DurationMin, Duration> {

    private Duration duration;

    @Override
    public void initialize(DurationMin constraintAnnotation) {
        this.duration = Duration.of( constraintAnnotation.value(), constraintAnnotation.units() );
    }

    @Override
    public boolean isValid(Duration value, ConstraintValidatorContext context) {
        // null values are valid
        if ( value == null ) {
            return true;
        }
        return duration.compareTo( value ) < 1;
    }
}

As we are creating a new constraint annotation, we should also provide a default message for it. This can be done by placing a ContributorValidationMessages.properties property file in the classpath. This property file should contain a key/message pair, where key is the one used in annotation declaration (in our case it’s com.acme.validation.constraints.DurationMin.message) and message is the one you would like to show when validation fails. Our property file looks like so:

ContributorValidationMessages.properties
com.acme.validation.constraints.DurationMin.message = must be greater than or equal to {value} {units}

The bundle ContributorValidationMessages is queried by Hibernate Validator if the standard ValidationMessages bundle doesn’t contain a given message key, allowing library authors to provide default messages for their constraints as part of their JAR.

If you leave everything else as is, your constraint annotation will live its own life without knowing about the presence of validator. Hibernate Validator will not know of the validator as well. So to make sure that Hibernate Validator discovers your DurationMinValidator, you need to create the file META-INF/services/javax.validation.ConstraintValidator and put the fully qualified name of the validator implementation in it:

META-INF/services/javax.validation.ConstraintValidator
com.acme.validation.validators.DurationMinValidator

After all of this, your new constraint annotation on Duration elements can be used like this:

Task.java
public class Task {

    private String taskName;
    @DurationMin(value = 2, units = ChronoUnit.HOURS)
    private Duration timeSpent;

    public Task(String taskName, Duration timeSpent) {
        this.taskName = taskName;
        this.timeSpent = timeSpent;
    }
}

The project structure should look similar to next one:

project structure, align=

The whole source code presented here can be found in the hibernate-demos repository on GitHub.

Use standard constraints for non standard classes

Now let’s consider the case where you would want a standard Bean Validation constraint to support some other type, besides the ones that are already supported.

ThreeTen Extra types validation

As we were talking about date/time related validation, let’s stay on the same topic for this example as well. In this section we will look at ThreeTen Extra types - a great library that provides additional date and time classes to complement those already present in Java.

Bean Validation provides support for validating temporal types via the @Past/@Future annotations. So we would want to use these annotations on ThreeTen Extra types as well. To keep this example simple we will provide validators only for YearWeek and YearQuarter.

Let’s start with implementing ConstraintValidator<Future, YearWeek> interface:

FutureYearWeekValidator.java
public class FutureYearWeekValidator implements ConstraintValidator<Future, YearWeek> {

    @Override
    public void initialize(Future constraintAnnotation) {
    }

    public boolean isValid(YearWeek value, ConstraintValidatorContext context) {
        if ( value == null ) {
            return true;
        }
        return YearWeek.now().isBefore( value );
    }
}

The next step is to provide a list of implemented validators in META-INF/services/javax.validation.ConstraintValidator file:

META-INF/services/javax.validation.ConstraintValidator
com.acme.validation.validators.FutureYearQuarterValidator
com.acme.validation.validators.FutureYearWeekValidator
com.acme.validation.validators.PastYearQuarterValidator
com.acme.validation.validators.PastYearWeekValidator

After this we can package it all in a JAR file and we are ready to use our validators and share them with the world!

In the end our project structure should look similar to this:

project structure, align=

Now you can place @Past/@Future annotations on YearQuarter and YearWeek types like this:

PastEvent.java
public static class PastEvent {

    @Past
    private YearWeek yearWeek;
    @Past
    private YearQuarter yearQuarter;

    public PastEvent(YearWeek yearWeek, YearQuarter yearQuarter) {
        this.yearWeek = yearWeek;
        this.yearQuarter = yearQuarter
    }
}
FutureEvent.java
public static class FutureEvent {

    @Future
    private YearWeek yearWeek;
    @Future
    private YearQuarter yearQuarter;

    public FutureEvent(YearWeek yearWeek, YearQuarter yearQuarter) {
        this.yearWeek = yearWeek;
        this.yearQuarter = yearQuarter
    }
}

You also can find this example at GitHub.

Conclusion

So, as you can see, custom constraint validators can be built and shared in a fully self-contained way. And it can be done in a few simple steps:

  • create a validator implementing the ConstraintValidator interface

  • reference this validator’s fully qualified name in a META-INF/services/javax.validation.ConstraintValidator file

  • (optional) define custom/default messages by adding a ContributorValidationMessages.properties file

  • package it all as a JAR

  • you are ready to share your constraints, people can add them by simply ading your JAR to the classpath

It is not every day that we announce the first release of a new major version of Hibernate Validator. And today is one of those days: the first alpha of Hibernate Validator 6 has just been released.

Hibernate Validator 6 is going to be the Reference Implementation of Bean Validation 2.0. That’s why we coordinated the releases of the first alphas of these two projects.

It is also a playground used to validate future enhancements of the Bean Validation specification so feedback on the subjects presented here is very welcome!

Note that Hibernate Validator 6 requires JDK 8 or above.

What’s new

New group id

First, starting from 6, the new home of Hibernate Validator is org.hibernate.validator (it used to be org.hibernate).

For instance, the Maven coordinates of this version are:

<dependency>
    <groupId>org.hibernate.validator</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>6.0.0.Alpha1</version>
</dependency>

We published relocation artifacts to make the transition more smooth. Examine the output of your build, if you see messages like "[WARNING] The artifact org.hibernate:hibernate-validator:jar:6.0.0.Alpha1 has been relocated to org.hibernate.validator:hibernate-validator:jar:6.0.0.Alpha1", you are still using the old GAV coordinates and should upgrade to the new ones.

Also make sure to not depend on 5.x and 6.x at the same time (as the group ids are different, the dependency resolution algorithm of your build tool fails to detect that these are two versions of the same logical artifact).

Java 8 goodness

As we now target Java 8 and above, we benefit from the language improvements:

  • all Bean Validation and Hibernate Validator constraints can be used in type use context (e.g. List<@NotBlank String>);

  • all the annotations that could be repeated with a List container are now marked @Repeatable.

Implementation of the new features of the spec

Earlier this week, Gunnar presented on the Bean Validation website the new features introduced in Early Draft 1 of Bean Validation 2.0. They are implemented in Hibernate Validator 6.0.0.Alpha1 so you can already play with them and give us your feedback.

Nested type use constraints and nested cascaded validation

There are some things where Hibernate Validator goes beyond the Early Draft 1 of the spec.

Typically, with Hibernate Validator, type use constraints may be used even on nested types. And so may cascaded validation.

public class Order {

        private Map<@NotNull @Valid Product, @Size(min = 1) List<@NotNull @Valid OrderLine>> lines;

}

In the above example, Hibernate Validator is going to:

  • validate the @NotNull constraint on Product;

  • cascade the validation to Products;

  • validate that for a Product, the list of OrderLines contains at least one element;

  • validate that the lists do not contain any null element;

  • cascade the validation to OrderLines.

As mentioned above, the nested part is new in Hibernate Validator and is not part of the spec yet. If you think it should go in, raise your hand and participate to the discussions. Expect some interesting discussions soon on what the nodes of the property path should look like in the case of nested types validation.

Lambda based constraint definition

We started to explore how lambdas could be integrated into Hibernate Validator and the first outcome of it is lambda based constraint definition. Using the programmatic API, you can define a constraint without writing a ConstraintValidator:

HibernateValidatorConfiguration configuration = Validation
    .byProvider( HibernateValidator.class )
    .configure();

ConstraintMapping constraintMapping = configuration.createConstraintMapping();

constraintMapping
    .constraintDefinition( ValidPassengerCount.class )
        .validateType( Bus.class )
            .with( b -> b.getSeatCount() >= b.getPassengers().size() );

Note that the programmatic API is not part of the specification so, for now, this part is specific to our implementation.

Validation of Duration

In Hibernate Validator 6, we are able to validate a lot more java.time classes and Marko recently introduced support for Duration.

Here is an example of what you can do with it:

public class TrainingSession {
    [...]

    @DurationMin(hours = 1, minutes = 30)
    @DurationMax(days = 1, inclusive = false)
    private Duration duration;

    [...]
}

Again, let us know if you think this feature should go into the spec.

Getting 6.0.0.Alpha1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate.validator:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:6.0.0.Alpha1. As mentioned earlier, the group id has been changed to org.hibernate.validator.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are still under active development. We will release new alphas on a regular basis.

Hibernate Validator 5.4.0.Final

Posted by    |       |    Tagged as Hibernate Validator Releases

It’s with great pleasure that I announce the final release of Hibernate Validator 5.4.0.

What’s new since 5.4.0.CR1

For those of you following closely this blog, not much to say since 5.4.0.CR1. We fixed a few bugs and polished a few things.

We shod in a small new feature: you can now require a @ScriptAssert constraint violation to be reported on a specific property. In the following example, the constraint violation will be reported on the endDate property rather than at the class level:

@ScriptAssert(lang = "javascript", script = "_this.endDate.after(_this.startDate)", reportOn="endDate")
public class CalendarEvent {

    private Date startDate;
    private Date endDate;

    //...
}

You can find the complete list of all addressed issues in the change log.

New documentation layout

We converted the Hibernate Validator documentation to AsciiDoctor a loooong time ago but we were still using a Docbook output to be able to generate the PDF documentation. AsciiDoctor now has a (still in alpha but already pretty mature) PDF plugin and we decided to take the final step and get rid of our Docbook output.

So our reference documentation now uses a nice AsciiDoctor output and so does our PDF documentation.

We hope you’ll like it. We do!

5.4.0 Retrospective

You might not follow our blog on a regular basis so here is a retrospective of all the good things included in 5.4.0.Final.

JavaMoney support

Hibernate Validator now includes JavaMoney (JSR 354) support. You can use @DecimalMin and @DecimalMax constraints on your MonetaryAmount fields and we also introduced a new @Currency annotation allowing you to constrain the currency used in your MonetaryAmounts.

See our previous blog posts for more information:

This feature was initially contributed by Lukas Niemeier and Willi Schönborn from Zalando. Thanks again.

Annotation processor improvements

A special thank you goes to Marko Bekhta for his work on the annotation processor. Marko invested a lot of time to get the annotation processor on par with the latest Hibernate Validator features. Go validate your constraint definitions at compile time!

WildFly patch

Using WildFly and wanting to use the good things of this new version? We now provide a WildFly patch you can apply on top of your WildFly installation to use 5.4.0.Final.

You can find more information in the 5.4.0.Beta1 release announcement.

And a whole lot of other good things

  • Improvements to the @Email constraint

  • New constraints specific to Polish identification numbers

  • A Ukrainian translation

Getting 5.4.0.Final

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.0.Final.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

Bean Validation 2.0 and Hibernate Validator 6 are under active development. The first alpha will be out in the next few days.

As far as Bean Validation 2.0 is concerned, there are very interesting discussions going on about value extraction which is THE big BV 2.0 feature. Come and join us on Bean Validation website to define the future of Bean Validation.

Hibernate Validator 5.4.0.CR1

Posted by    |       |    Tagged as Hibernate Validator Releases

I am proud to announce the release of Hibernate Validator 5.4.0.CR1. This is a candidate release, please take the time to test it and report any issues you might find so that we can build the best possible 5.4.0.Final.

What’s new

5.4.0.CR1 is a small release built on the shoulders of our previous beta. It contains a couple of nice improvements and bugfixes:

  • We improved the javax.money support with a new annotation @Currency

  • Marko Bekhta finished his work on the annotation processor: we are now on a par with the Hibernate Validator engine features

  • We also fixed a possible overflow issue in java.time validation reported by Stanislav Bashkyrtsev

You can find the complete list of all addressed issues in the change log.

Playing with @Currency

In Beta1, we introduced the ability to validate your Order bean containing a MonetaryAmount property with the @DecimalMin annotation. Starting from CR1, you can also use the @Currency annotation to specify the currencies allowed:

public class Order {

    @NotBlank
    private String name;

    @DecimalMin(value = "0", inclusive = false)
    @Currency("EUR")
    private MonetaryAmount amount;

    public JavaxMoneyOrder(String name, MonetaryAmount amount) {
        this.name = name;
        this.amount = amount;
    }
}

JDK 9 support

As usual, we are working on validating the releases of Hibernate Validator with the latest JDK 9 early access builds.

5.4.0.CR1 is supported on the JDK 9+148 build. However, a blocking issue in JDK 9 prevents it to run on +151. It should be fixed in the next JDK 9 release.

Getting 5.4.0.CR1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.0.CR1.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the usual channels:

What’s next?

The obvious next step is the 5.4.0.Final release.

As far as Bean Validation 2.0 is concerned, there are very interesting discussions going on about value extraction which is THE big BV 2.0 feature. Come and join us on Bean Validation website to define the future of Bean Validation.

Today, we announce the release of two Hibernate Validator versions: the first beta of the 5.4 branch and a maintenance release for our current stable, 5.3.

5.4.0.Beta1

5.4.0.Beta1 contains a lot of good things coming from the Hibernate Validator community:

  • lots of improvements to the annotation processor thanks to Marko Bekhta. For the last 2 months, Marko did a tremendous work getting the annotation processor up to speed: it will now report many more issues you might have with your annotations. We are especially interested in feedback on this feature so that we are sure we don’t report issues for configurations that should just work. So, if you have some time, give it a try on your project and, if you see something fishy, report it to us.

  • another contribution came in the form of the JavaMoney (JSR 354) support, contributed by Lukas Niemeier and Willi Schönborn from Zalando.

  • we now provide a WildFly patch based on WildFly’s patching infrastructure to allow testing a new version of HV on WildFly.

  • a couple of other improvements such as cleanups backported from our 6.0 work, a Ukrainian translation, constraint annotations for the various Polish identification numbers, improvements to the @Email constraint…​

You can find the complete list of all addressed issues in the change log.

More in depth with JavaMoney

The JavaMoney API is now an optional dependency of Hibernate Validator. So adding the following dependencies will make HV capable of validating JavaMoney types:

<dependency>
    <groupId>javax.money</groupId>
    <artifactId>money-api</artifactId>
    <version>1.0.1</version>
</dependency>
<dependency>
    <groupId>org.javamoney</groupId>
    <artifactId>moneta</artifactId>
    <version>1.1</version>
</dependency>

You’ll then be able to validate your Order bean containing a MonetaryAmount property with the @DecimalMin annotation:

public class Order {

    @NotBlank
    private String name;

    @DecimalMin(value = "0", inclusive = false)
    private MonetaryAmount amount;

    public JavaxMoneyOrder(String name, MonetaryAmount amount) {
        this.name = name;
        this.amount = amount;
    }
}

Applying a WildFly patch

The WildFly application server in its latest stable version (10.1.0.Final) embeds Hibernate Validator 5.2.4.Final but you might want to give our new features a try.

WildFly 8 introduced a patching infrastructure that allows you to apply patches to WildFly with a lot of nice features: you can list the applied patches, rollback a specific patch…​

Starting with HV 5.4, we leverage this infrastructure to provide you with the capability to upgrade the core Hibernate Validator modules with an updated version. As the patch overrides the core modules, the new features of 5.4.0.Beta1 are available to all the WildFly components using HV (e.g. Jax-RS for instance).

The patch file can be downloaded from Maven Central or from our distribution.

You can apply the HV 5.4.0.Beta1 update on top of WildFly 10.1.0.Final with the following command:

$JBOSS_HOME/bin/jboss-cli.sh patch apply hibernate-validator-modules-5.4.0.Beta1-wildfly-10.1.0.Final-patch.zip

And if you want to go back to the original version, you can easily revert the update:

$JBOSS_HOME/bin/jboss-cli.sh patch rollback --reset-configuration=true

Getting 5.4.0.Beta1

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.4.0.Beta1.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

5.3.4.Final

Our fourth maintenance release of Hibernate Validator 5.3 comes with a few important bugfixes:

  • HV-1165 - this is a regression introduced in 5.3.0.CR1 when we fixed the type arguments support for Maps: we broke the support for Sets. The issue is now fixed and we added a comprehensive suite of regression tests for all the existing cases.

  • HV-1176 - validation of type arguments constraints on Optional parameters or return value of a method could be ignored if there were no other constraints applied on the method

  • HV-1164 - a bugfix related to dynamic constraint payloads contributed by Sebastian Bayerl

You can find the complete list of all addressed issues in the change log.

Getting 5.3.4.Final

Hibernate Validator 5.3.4.Final is a drop-in replacement of Hibernate Validator 5.3.3.Final.

To get the release with Maven, Gradle etc. use the GAV coordinates org.hibernate:{hibernate-validator|hibernate-validator-cdi|hibernate-validator-annotation-processor}:5.3.4.Final.

Alternatively, a distribution bundle containing all the bits is provided on SourceForge (TAR.GZ, ZIP).

Feedback, issues, ideas?

To get in touch, use the following channels:

What’s next?

We are going to prepare the first Candidate Release of the 5.4 branch in which we will integrate your feedback.

We are also actively working on Bean Validation 2.0 and Hibernate Validator 6 with a strong focus on supporting the new features of Java 8 (and much more!). The more the merrier, so feel free to join us: drop ideas, comment on others' proposals, now is the time to define the future of Bean Validation. You can find all the necessary information on the Bean Validation website.

back to top