There are no functional changes between CR1 and this Final release. Some minor issues in the @Min, @Max and @EmailValidator got fixed (HV-335, HV-339) as well as some documentation typos. We also spend some time improving the parsing and validation speed by reviewing and improving some reflection based code (HV-340, HV-341, HV-342). Review the full release notes for details.

Download as usual either from the JBoss Maven repo or from SourceForge.

There are already several issues on the 4.2 roadmap, but we are welcoming ideas and suggestions for the next release on the Validator Forum. One of the major new features will most likely be method-level validation (as specified in Appendix C of the Bean Validation specification) as well.

Stay tuned!

Amendment: Gunnar did a great job summarizing the new features of Hibernate Validator 4.1 on his blog. And of course we covered already most of the new features here as well. See programmatic constraint configuration, ResourceBundleLocator and @ScriptAssert.

Hibernate Validator 4.1.0.CR1 is now available. This is the last milestone build before the Final release. Not much has happened between Beta2 and CR1. The programmatic API as described in the previous release blog entry stayed as is and there were only three minor bug fixes. See release notes for details.

Download as usual either from the JBoss Maven repo or from SourceForge.

Ideas and suggestions are welcome on the Validator forum. Let us know what you want to see in Validator post 4.1.0. In case you find a bug create a jira issue in HV.

Enjoy!

Hibernate Validator 4.1.0.Beta2 is out. A total of 29 issues got resolved since the last release and you can review then in the Jira changelog. Amongst others we added the @ScriptAssert constraints as promised in the previous release blog. Initially we wanted to release 4.1.0.CR directly, but we added a new programmatic constraint configuration API (HV-274) for which we want to first gather some feedback.

The new API is centered around ConstraintMapping which is the entry point to a fluent API allowing the configuration of constraints. The API is comparable to the one described in Emmanuel's blog Hibernate Search Programmatic Mapping API. But let's look at an example:

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

As you can see you can configure constraints on multiple classes and properties using method chaining. The constraint definition classes NotNullDef, SizeDef and MinDef are helper classes which allow to configure constraint parameters in a type-safe fashion. Definition classes exists for all built-in constraints in the org.hibernate.validator.cfg.defs package. For a custom constraint you can either create your own definition class extending ConstraintDef or you can use GenericConstraintDef (we are also thinking about providing another annotation processor which at compile time could generate the required helper classes):

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
    .property( "licensePlate", FIELD )
        .constraint( GenericConstraintDef.class )
            .constraintType( CheckCase.class )
            .param( "value", CaseMode.UPPER );

Last but not least, you can also define cascading constraints as well as the default group sequence of an entity.

ConstraintMapping mapping = new ConstraintMapping();
mapping.type( Car.class )
    .valid( "driver", FIELD )
.type( RentalCar.class)
    .defaultGroupSequence( RentalCar.class, CarChecks.class );

Since the programmatic configuration is not part of the official Bean Validation specification you will have to get hold of HibernateValidatorConfiguration during the bootstrapping process in order to set your ConstraintMapping:

HibernateValidatorConfiguration config = Validation.byProvider( HibernateValidator.class ).configure();
config.addMapping( mapping );
ValidatorFactory factory = config.buildValidatorFactory();
Validator validator = factory.getValidator();

WDYT? Is this API useful? Easy to use? Anything we should consider/change?

If you want to play with this release, you can download it from the JBoss Maven repo or from SourceForge.

Enjoy!

One unsolved problem with Bean Validation is how to apply a constraint on the elements of a collection (or iterable). Think about a User entity with a list of emails (primary, secondary, ...). This could be modeled like this:

public class User {
    @NotEmpty
    private String name;

    @NotEmpty
    @Email
    private List<String> emailList;
    ...
}

The problem is that validating an instance of this User would currently throw an UnexpectedTypeException, since there is no built-in ConstraintValidator<Email, Collection<String>> which could validate emailList (see also HV-264). One way to solve the problem within the current framework is to implement a ConstraintValidator<Email, Iterable<String>>. Great, but it only solves the problem for @Email, not for the generic problem: How can I apply a constraint on all elements of a collection?.

Not thinking about language limitations, the following solution would be nice:

public class User {
    @NotEmpty
    private String name;

    @NotEmpty
    private List<@Email String> emailList;
     ...
}

Of course this is not possible in the current version of Java. However, there is JSR 308, which allows the above example and which will hopefully be part Java 7. For the Bean Validation specification it makes sense to wait for this feature (see BVAL-202), but should we have a interim solution for Hibernate Validator. This is what HV-296 is about. HV-296 discusses several solutions to the problem. Two solutions I would like to introduce here:

The payload solution

For this solution a custom payload class would be introduced. If this payload is specified on a constraint, the constraints will be applied on the elements of the collection:

public class User {
    @NotEmpty
    private String name;

    @NotEmpty
    @Email(payload=OnElements.class)
    private List< String> emailList; 
    ...
}

This seems to be the least intrusive solution and hopefully within the rules of the specification: Payloads are typically used by validation clients to associate some metadata information with a given constraint declaration. Payloads are typically non-portable.

The @ValidateEach annotation solution

For this solution we would introduce a new annotation @ValidateEach (or maybe @ApplyOn).

@ValidateElements
public @interface ValidateEach {
	Email[] value();
}

@ValidateElements is a marker annotation used by the validator engine to determine annotations used for applying built-in constraints on collections. Our usecase looks like this now:

public class User {
    @NotEmpty
    private String name;

    @NotEmpty
    @ValidateEach(@Email)
    private List< String> emailList;
    ...
}

Problematic with this solution is that for each constraint we have to place the corresponding ValidateEach annotation in its own package. This could be avoided if we give each annotation a distinctive name, for example ValidateEachEmail, ValidateEachSize, etc. Alternatively we could have one single ValidateEach annotation and attributes for each built-in constraint:

@ValidateElements
public @interface ValidateEach {
       Email[] email() default{};
       Size[] size() default {};
       NotNull[] notNull() default {};
       ...
}

This would reduce the required number of annotations, but it would introduce a special case for custom constraints.

You get the full history on how we arrived at these solutions by reading the irc log attached to HV-296. If you have an opinion on the matter, make sure to leave a comment, post on the forum or send an email to hibernate-dev.

Time has not been standing still for Hibernate Validator and I am happy to announce the 4.1.0.Beta1 release of Hibernate Validator. The focus towards the final 4.1.0 release is to add new custom constraints, provide enhancement which go beyond the Bean Validation specification and give the developers an annotation processor to verify the correct placement of constraints. You can see what is already implemented in this beta release by referring to the Jira release notes. The roadmap towards 4.1.0 can be seen here. On the custom constraint side we added @CreditCardNumber, @NotBlank and @URL and are planning to add @ScriptAssert for the next release. We also introduced a new interface ResourceBundleLocator which allows users to make a better use of ResourceBundleMessageInterpolator. Instead of just loading resource bundles from the classpath using ResourceBundle.getBundle, you can now provide a custom implementation of ResourceBundleLocator providing the ResourceBundleMessageInterpolator with the message resource bundles to use:

HibernateValidatorConfiguration configuration = Validation.byProvider(HibernateValidator.class).configure();
ResourceBundleLocator defaultResourceBundleLocator = configure.getDefaultResourceBundleLocator(); 
ResourceBundleLocator myResourceBundleLocator = new MyCustomResourceBundleLocator(defaultResourceBundleLocator);
configuration.messageInterpolator(new ResourceBundleMessageInterpolator(myResourceBundleLocator));

Thanks to the great work of Gunnar Morling developers can now also use the new Hibernate Validator Annotation Processor. By adding the jar file hibernate-validator-annotation-processor-4.1.0.Beta1.jar to the classpath of their IDE project, they can get feedback about invalid placements of constraints. For example @Valid on a primitive type or a @Pattern constraint on a non string attribute. Prerequisite for this to work is that you are using a JDK 6. The configuration of the annotation processor is the same as for the Hibernate Metamodel Generator and can be seen here. The fully qualified name of the processor is org.hibernate.validator.ap.ConstraintValidationProcessor.

It would be great to get some feedback on the usability of the annotation processor. Also let us know which other custom constraints you would like to see in Hibernate Validator. Use the forum to discuss your ideas or create a jira issue in HV.

Enjoy, Hardy

P.S. Download is of course as usual either from the JBoss Maven repo or from SourceForge.