In Relation To

I am happy to announce the first beta release of Hibernate Validator 4.2. You can download this release as usual from the JBoss Maven Repository or from SourceForge.

As announced earlier, the highlight of the 4.2 release is the implementation of method level constraints (HV-347) as described in Appendix C of the Bean Validation specification. Many thanks to Gunnar for implementing this new feature. Method level validation allows to apply constraints to method parameters or return values like this:

public @NotNull String saveItem(@Valid @NotNull Item item, @Max(23) BigDecimal price)

To validate these constraints you would get hold of a MethodValidator via the Validator.unwrap() method:

MethodValidator validator = Validation.byProvider( HibernateValidator.class )
    .configure()
    .buildValidatorFactory()
    .getValidator()
    .unwrap( MethodValidator.class );

and use one of the following methods of this new interface:

public interface MethodValidator {
    public <T> Set<MethodConstraintViolation<T>> validateParameter(T object, Method method, Object parameterValue, int parameterIndex, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateParameters(T object, Method method, Object[] parameterValues, Class<?>... groups);
    public <T> Set<MethodConstraintViolation<T>> validateReturnValue(T object, Method method, Object returnValue, Class<?>... groups);
}

The returned MethodConstraintViolation is derived from ConstraintViolation and provides additional method level validation specific information. For example it can contain the method name and index of the parameter which caused the constraint violation. The documentation for this feature is still work in progress and will be completed in the following releases.

We except that the new MethodValidator API is in particular interesting when used in conjunction with APIs or frameworks like Contexts and Dependency Injection (JSR-299) or aspect oriented frameworks. With the help of these frameworks it is very simple to create an interceptor/aspect which automatically triggers validation of all method invocations and throws a MethodConstraintViolationExcepion in case of any validation errors. Let us know how you are going to use this new API.

Next to method level validation we also introduced boolean composition for composed constraints (HV-390). So far composing constraints were always a conjunction of all specified constraints. With this release Hibernate Validator introduces the @ConstraintComposition annotation together with the CompositionType enum. This allows you to define composing constraints like this:

@ConstraintComposition(OR)
@Pattern(regexp = "K")
@Size(min = 2, max = 10)
@ReportAsSingleViolation
@Target({ METHOD, FIELD })
@Retention(RUNTIME)
@Constraint(validatedBy = { })
public @interface PatternOrSize {
	public abstract String message() default "OR";
	public abstract Class<?>[] groups() default { };
	public abstract Class<? extends Payload>[] payload() default { };
}

This is yet another contribution from the community. Thanks a lot for your support :)

Another new feature worth mentioning is the new ValueFormatterMessageInterpolator which allows you to interpolate the validated value in the message templates. To enable this new interpolator use the configuration API:

Validation.byProvider( HibernateValidator.class ).configure().messageInterpolator( new ValueFormatterMessageInterpolator() ).buildValidatorFactory();

Using the message parameter validatedValue and an optional format string you can interpolate the validated value. As example take a custom @Future constraint message - "${validatedValue:%1$td.%1$tm.%1$ty} is not in the future", which would interpolate into something like "13.01.11 is not in the future".

One note regarding backwards compatibility. Due to BVTCK-12 resp. HV-395 the javax.validation.Path implementation of Hibernate Validator needed some changes. The good news is, however, that unless you iterate over the Path instance returned by Constraint.getPropertyPath() you are not affected by this change.

Also the programmatic configuration of generic constraints has changes and looks like this now:

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

We also added a new type parameter to ConstraintDef which simplifies the creation of definition types for custom constraints. It is now not longer necessary to provide methods for standard constraint attributes such as message(). If you are using a custom ConstraintDef you will have to retrofit your implementation.

Of course this release contains also a whole range of other bug fixes and improvements. You can view the full changelog here. Thanks to Kevin who helped to fix many of these issues. To point out one of his contributions have a look at HV-307 which adds support for Joda Time types such as DateTime. These types can be annotated with @Past and @Future just as the standard JDK date types.

We are looking forward to your feedback on the Validator Forum. For bug reports please use the issue tracker.