In Relation To

We are happy to announce the release of Hibernate Validator 5.2.0.Beta1. This time a whole bunch of Hibernate team members (Davide, Emmanuel, Gunnar, Sanne and myself) joined forces to make this release happen. Thanks everyone!

In total we were able to resolve 30 issues. Here are some highlights.

Ability to provide external ClassLoader

There are several cases in which Hibernate Validator needs to load resources or classes:

• XML descriptors (META-INF/validation.xml as well as XML constraint mappings)
• Classes specified by name in XML descriptors
• ValidationMessages resource bundle

By default Hibernate Validator tries to load these resources via the current thread context classloader. If that’s not successful, Hibernate Validator’s own class loader will used as a fall-back. For cases where this strategy is not appropriate (e.g. modularized environments such as OSGi), you can now provide an external class loader during bootstrapping:

Validator validator = Validation.byProvider( HibernateValidator.class )
    .configure()
    .externalClassLoader( classLoader )
    .buildValidatorFactory()
    .getValidator();

Hibernate Validator features.xml for Apache Karaf

As a side effect of the class loader improvements we were able to write some OSGi integration tests between Apache Karaf and Hibernate Valdiator. The tests themselves are not so important, but we decided to release the required Karaf features.xml file as part of our regular build artifacts. You can view the first version of this file here.

Programmatic constraint mapping via ConstraintMappingContributor

In Hibernate Validator you can, as a provider specific feature, programmatically define constraint mappings. So far this feature was tied to a programmatic bootstrapping of the ValidatorFactory itself. However, often you are not bootstrapping the factory yourself, but work with the default factory as configured via META-INF/validation.xml. In these cases you can now add one or more programmatic constraint mappings by implementing a ConstraintMappingContributor:

public static class MyConstraintMappingContributor implements ConstraintMappingContributor {

        @Override
        public void createConstraintMappings(ConstraintMappingBuilder builder) {
                builder.addConstraintMapping()
                        .type( Marathon.class )
                                .property( "name", METHOD )
                                        .constraint( new NotNullDef() )
                                .property( "numberOfHelpers", FIELD )
                                        .constraint( new MinDef().value( 1 ) );

                builder.addConstraintMapping()
                        .type( Runner.class )
                                .property( "paidEntryFee", FIELD )
                                        .constraint( new AssertTrueDef() );
        }
}

In order for this ConstraintMappingContributor to get picked up by the bootstrap process, you then need to specify the fully-qualified class name of the contributor implementation in META-INF/validation.xml, using the property key hibernate.validator.constraint_mapping_contributor.

ConstraintDefinitionContributor with resource bundles

We introduced ConstraintDefinitionContributor already in the Alpha1 release, but it so far only allowed you to contribute constraints. Default messages via a resource bundle were not covered. This has changed, and you can just place a ContributorValidationMessages.properties and/or its locale-specific specializations at the root your JAR. Hibernate Validator will aggregate the entries from all the bundles with this name found on the classpath.

Where do I get it?

Maven artifacts for this release are in the JBoss Maven repository (GAV org.hibernate:hibernate-validator:5.2.0.Beta1) and on SourceForge.

Feedback and questions are welcome via the Hibernate Validator forum or on stackoverflow using the hibernate-validator tag. If that is not enough, check out the other ways you can get in contact with us.

Enjoy!