SQL Zone is brought to you in partnership with:

I've been a zone leader with DZone since 2008, and I'm crazy about community. Every day I get to work with the best that JavaScript, HTML5, Android and iOS has to offer, creating apps that truly make at difference, as principal front-end architect at Avego. James is a DZone Zone Leader and has posted 639 posts at DZone. You can read more from them at their website. View Full User Profile

Hibernate Validator 4: Model Validation Made Easy

  • submit to reddit

Version 4.0 of Hibernate Validator has been released recently, which is now the reference implementation for JSR 303: Bean Validation. The real benefit to this release is that you can now annotate your domain model with various constraints, rather than needing to write your model validation yourself. For people who want to take a model driven development approach, this is a big time saver.

The Hibernate Validator documentation has the perfect image to illustrate this. Rather than having custom validation at each step along the way, the domain model contains all the constraints, and therefore validation rules exist in one single place.


There are a number of build in constraint annotations available such as those you'd expect - @notNull, @notEmpty, @min, and @max.

public class Driver extends Person {
@Min(value = 18, message = "You have to be 18 to drive a car", groups = DriverChecks.class)
public int age

There are also some others like @email, which checks if the string is an email format and @future, which validates a date to ensure that it is in the future. A useful list of the built-in constraints is provided here. Naturally, your domain model may have constraints that don't exist in this list - there's instructions on how to create your own constraint annotations here

New In Hibernate Validator

Hibernate Validator 4 is based on a new codebase, with tons of useful features. Any of the constraints that you use can be put together to compose new constraints. Violation messages can be attached to your constraints, and you can return more than one of these messages if you wish. 

Because the framework complies to the Bean Validation JSR, it integrates with Java Persistence API 2 and Java Server Faces 2. As you use other Java libraries that take advantage of JSR 303, that code can also be aware of the constraints that you specify. 

This framework looks great, and the importance of a common approach to bean validation cannot be understated. A single approach cuts down on the amount of duplicate code - the more frameworks that use this JSR for their validation, the better. 




Andrew Arrigoni replied on Thu, 2009/10/22 - 10:16am

So, what does integration on the Client/JSF2 really mean? Is it checked in an AJAX fashion or are the constraints turned into pure client-side Javascript? I'd love it if it was the latter. If you can read the restraints on your modelled fields during JSF2 rendering, create appropriate JavaScript code and tie it to the View directly, that would be absolutely killer.

sd giant replied on Thu, 2009/10/22 - 12:54pm in response to: Andrew Arrigoni

@StormTAG, you just came really close to describing JBoss Seam, which is at its core a pre-wired Hibernate-JSF (with a Facelet library called RichFaces on top) stack.  You still have some work to do on the JSF end creating layout templates so the errors display properly, but Seam is wired together to do exactly what you are suggesting.  Obviously if Seam can do it, and Hibernate-JSF stack could be wired to do it as well...

Andrew Arrigoni replied on Thu, 2009/10/22 - 1:50pm in response to: sd giant

@sdgiant I believe, but am not sure, that Seam does this via AJAX. Partially submit the form, run validation rules on the server side, then re-render the portions of the page that apply (like any error messages.) This works fine and I'm actually using this functionality with RichFaces in a couple of places in a prototype I'm building.

 What I was more specifically asking was if the restraints defined with a JSR 303 implementation could be converted to pure JavaScript and run completely on the client side with no AJAX submission or response via JSF2. Obviously it would also be checked on the server-side once the form was actually submitted (and likely checked yet again when it was persisted) but being able to do certain validations purely on the client side without an AJAX call would eliminate a large amount of potential AJAX calls. Less AJAX calls, less server resources needed, less cost, more profit. :)

sd giant replied on Fri, 2009/10/23 - 2:07am

@StormTAG, ahhhh, excellent point.  You are right about partial page submits with AJAX.  I don't know the answer to whether Hibernate Validator 4 can be used to produce a pure Javascript model for validation using JSF or some other Faclet model. 

 It would be VERY cool if it did, but I have to say I would be surprised if there was a way to product pure JS using that stack.  Seems like everything I've seem in that realm leans towards AJAX.

Andrew Arrigoni replied on Fri, 2009/10/23 - 7:32am

@sdgiant, To be honest, so would I. But for some of the built in constraints (pattern, min, max, not null, not empty, etc.) it would be relatively easy to provide a JavaScript implementation. Then it would be a matter of weaving it into the clients side with the messages and all the rest.

AJAX is great and all but in a lot of ways, the Web is moving to a "smarter-client" mentality. Being able to provide pure-client validation and server-side validation all in one annotation would be a killer feature, IMO.

john green green replied on Sun, 2009/10/25 - 8:49am

This works fine and I'm actually using nike shoes chinathis functionality with RichFaces in a couple of places in a prototype I'm building.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.