Monthly Archives for November 2010

It allows to define validation rules directly on beans using simple annotations. Most cases are covered by the base annotations provided by the standard, and it even includes a way to develop custom validators that can be plugged-in as you see fit.

Once your beans are annotated, you can manually trigger validation as simply as:

Even better, custom validators developed in such a Spring environment can even beneficiate from Spring’s @Autowired injection, freebie!

Hibernate itself also offers an integration with JSR-303 through Hibernate events. Enabling the integration with Hibernate allows validation rules to be executed on those events for your model beans:

pre-insert

pre-update

pre-delete

Will it blend?

At first sight, all of this looks very nice. You get standardized validation directly on your beans and invoking validation is a one-liner.But what happens if you mix all of this together?

In my current project, we wanted to build a custom validator that would check if an e-mail address already existed in the database before saving any instance of our Contact entity using Hibernate. This validator needed a DAO to be injected in order to check for the existence of the e-mail address in the database. To our surprise, what we thought would be a breeze was more of a gale. Spring’s injection did not work at all when our bean was validated in the context of Hibernate’s event-based validation (in our case, the pre-insert event).

At first glance, we did all that was required both sides:

We enabled Spring 3 integration with JSR-303, as per documentation

We enabled Hibernate event-based integration with JSR-303, as per documentation

After some digging, we found out that Hibernate did not use our Spring LocalValidatorFactoryBean, but rather used its own ValidatorFactory. It became quite obvious that it all did not blend that much.

Fortunately, a solution exists, and at this moment does not seem documented. Hence this page!

I’ve created a quick Maven project that I’ve published on GitHub that showcases a full working solution. Refer to the README on GitHub for details.

To summarize the solution, two things are required, in addition to the standard integration steps for both frameworks (Hibernate and Spring).

The key part here is to force Hibernate to use a custom BeanValidationEventListener that will use Spring’s LocalValidatorFactoryBean instead of creating its own. This is the missing piece of the puzzle.

hibernate.properties

javax.persistence.validation.mode=none

In some cases, we found out that Hibernate still adds its own BeanValidationEventListener in addition to the one we define. Obviously, the second event listener (the one created by Hibernate) is not configured correctly so all validations based on injected beans fail with nice little NullPointerException. Specifying this property disables Hibernate automatic configuration process, and the duplicate event listeners all goes away.

Jetbrains are really positioning themselves to become THE IDE of choice for many software developers. With their excellent support for many languages and frameworks, IntelliJ is becoming the one-stop shop for software developers. As software developers, learning a new platform or language often requires a lot of involvement (new concepts, new tools, new IDEs, etc.) Having such a wide support in one IDE eases the learning curve of new tools or technologies, and encourages us to explore!