In Relation To Gunnar Morling

In Relation To Gunnar Morling

Recently I had the chance to give a talk on Bean Validation 1.1 at Berlin Expert Days (BED-Con), a nice mid-sized conference (2 days, 500 attendees) hosted at Freie Universität in Berlin. As in the last years, BED-Con was a great experience with awesome people and many insightful talks in the fields of Java EE, NoSQL, Continuous Delivery etc. I really can recommend this event which is planned to take place next year again.

My talk on Bean Validation went very well and I got lots of questions on the new functionality. In particular the possibility to use constraints on method parameters and return values (method validation) seems to be a helpful feature for many. You can find my slides which discuss the new features on the conference web site (in German, though).

I also used the opportunity to listen to some talks around client side web applications using HTML 5 and REST. There's a lot of activity going on in this field right now, and it appears like a new framework is released every day.

An interesting question to me is how Bean Validation as Java based technology fits into this picture. Bean Validation provides an API for retrieving constraint meta-data from models which could be used to perform a client-side validation of data entered by the user. It would surely be interesting to see how this could be leveraged to expose constraint meta-data e.g. via a REST service and use it on the client with frameworks such as AngularJS. Maybe this is even done by some frameworks already?

These releases catch up with the proposed final draft of the Bean Validation 1.1 specification, which was handed over to the JCP just yesterday. Check out the announcement for an overview of what has changed feature-wise since the last Beta releases. We addressed 4 issues in the TCK and 16 issues in Hibernate Validator.

As there shall be no blog post without at least a little bit of source code, let's have a closer look at one of the new features, the XML-based configuration of method constraints, implemented with HV-373.

The final release of Bean Validation 1.1 is coming soon; in the mean time we'll work on more tests for the TCK, fix bugs as required in Hibernate Validator and polish the documentation.

You want to help? Nothing easier than that, just check out the proposed final draft of the specification and play around with all the new features using Hibernate Validator.

You found a bug? You think the implementation doesn't correctly obey to the specification? That's great! We look forward to your report in our issue tracker. You can also reach us via e-mail or in the commmunity forum.

Also related to method validation, there is now support for cross-parameter constraints.
These come in handy when several parameters of a method or constructor need to be validated
together, similar to traditional class-level constraints. The following shows an example:

Opposed to constraints on individual parameters, cross-parameter constraints are specified
on the method itself. To make it easy for readers of your code to differentiate
cross-parameter constraints from return value constraints, it's recommended to choose a name
which clearly expresses the constraint's purpose.

As you can see, this looks very similar to a normal Bean Validation constraint annotation.
The only difference is that the @CrossParameterConstraint meta-annotation is used to
specify the constraint's validator. The validator must support Object[] as validated type:

As this validator operates on an array of objects representing the method arguments to be
validated, it is required to check the number and types of arguments first. The advantage
of this approach is that it allows to implement generic cross-parameter constraints which
are not specific to one method:

One of the big themes in Bean Validation 1.1 is the integration with CDI. The 5.0.0.Alpha2
release brings initial support for this. So it's possible now to have dependencies injected
into constraint validator implementations via CDI:

But that's not all. When invoking a method on a CDI managed bean which has parameter or
return value constraints, automatically an interceptor kicks in, which validates the
arguments and return value. If either is invalid, a ConstraintViolationException will be
thrown. This protects the method implementation from illegal argument values and the caller
from illegal return values. So you'll never have to write code like this again:

Finally, there is support for the conversion of the validated groups during cascaded
validation, a long standing feature request
with the Bean Validation spec. Remember, when annotating an element (e.g. a property or
method parameter) with @Valid, validation will be propagated to the referenced object(s).

With help of the new ConvertGroup annotation it is now possible to define which group or
sequence on the cascaded element shall be validated when a given group is validated on the
parent. Let's look at an example:

When validating a User object with the default group, for the associated addresses the
constraints in the BasicPostal group will be validated. When validating a User object
with the Complete group, this will lead to a validation of the constraints in the
FullPostal group on the user's addresses.

This feature should help with cascaded validations throughout different layers of an
application which all define different validation groups.

While these are the major changes of the release, there are some more notable ones,
e.g. minor modifications to the metadata API,
some changes around ConfigurationSource as
well as several bugfixes. Not related to Bean Validation 1.1, we finished the works to clearly
separate API, SPI and internal parts of the code base. The
changelog has all the details
for you.

While we're heavily working on Hibernate Validator 5 in order to implement revision 1.1 of
the Bean Validation spec, we decided to do a maintenance release of Hibernate Validator
4.3, the reference implementation of Bean Validation 1.0.

We fixed a couple of bugs, most notably HV-591.
This caused an error when applying the @Email constraint to long strings. Interestingly,
this is by far the most reported bug we've had so far in Hibernate Validator
withaltogetherfourduplicates. I'm wondering who choses an email
address with over 60 characters, but we can validate it now :) Check out the
change log for a complete
overview of all issues fixed in 4.3.1.

As usual, both releases can be retrieved from SourceForge
(4.3.1.Final,
5.0.0.Alpha2).
The Maven coordinates are org.hibernate:hibernate-validator:4.3.1.Final respectively
org.hibernate:hibernate-validator:5.0.0.Alpha2. Your feedback is welcome in the
forum, the
issue tracker and our
mailing list. The new features are not
described in the Hibernate Validator reference guide yet, so you might be interested in the
latest specification draft.

If you have any ideas or proposals around the Bean Validation 1.1 spec, don't hesitate to
engage directly with the expert group.