Friday, December 30, 2011

Method Validation With Spring 3.1 and Hibernate Validator 4.2

JSR 303 and Hibernate Validator have been some awesome additions to the Java ecosystem, giving you a standard way to validate your domain model across application layers. Combined with the annotations of the Java Persistence API (JPA) you have some very nice tools at your disposal to ensure that only valid data enters your database.

However, one piece of missing functionality was the ability to also validate method calls. For example, wouldn't it be nice if you could use normal JSR 303 annotations to safeguard business layer calls as well?

Of course you can enforce constraints programmatically, e.g. prevent the passing of Null parameters. Spring for instance provides the org.springframework.util.Assert class. However, it would be desirable, if constraints placed on input parameters as well as return values were part of the method contract.

Enter Hibernate Validator 4.2, which was released in June of 2011. It provides now method validation and Gunnar Morling, one of the committers, has an excellent write-up on this on his blog at:
Also, check out the Hibernate validator documentation regarding method validation. Gunnar Morling also provides some preliminary Spring support available at GitHub:
But the news for Spring aficionados is getting even better - Direct support for Method Validation With Hibernate Validator is now available in the lastest Spring 3.1 release that went GA just two weeks ago.

Specifically Spring 3.1 provides the following support in regards to method validation:
In order to get started, make sure that you are using Spring 3.1.0.RELEASE and that you have Hibernate Validator 4.2 in your classpath. That's all what you need to begin using JSR 303 annotations on the method level. For example, now you can annotate your methods using e.g.:

public interface BusinessService {
    @NotNull String convertToUpperCase(@NotEmpty String input);
The @Validated Annotation indicates that the methods in the class are to be included for method validation. Keep in mind that you can specify your own annotation that will be enabling method level validation for the annotated class. Specify your own annotation by calling setValidatedAnnotationType on the MethodValidationPostProcessor.

However, placing the annotations themselves will not enforce the constraints 'automagically'. In fact Spring will be using AOP (Aspect Oriented Programming) Advices under the covers that delegate to Hibernate Validator. The easiest way to enable these advices is to declare a MethodValidationPostProcessor bean in your Spring application context as shown below.
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns=""

 <context:component-scan base-package="com.hillert.spring.validation" />

    <bean id="validator"
    <bean class="org.springframework.validation.beanvalidation.MethodValidationPostProcessor"/>
For more details, I have published a small project over at GitHub that illustrates method level validation using Hibernate Validator:
In order to get get started:
  1. Clone the repository using $ git clone git:// 
  2. $ cd spring-hibernate-validator-sample
  3. Build the sample using Maven $ mvn clean package
  4. Run it with $ mvn exec:java 
The command-line based sample provides a simple String conversion service, that converts Strings to upper-case. You can insert those Strings from the command line. The Service layer will enforce the following constraints using method level Hibernate Validator annotations:
  • The input String must not be empty (not null and not an empty String)
  • The conversion service will never return null
In order to trigger validation exceptions you can enter some special strings:
  • Pressing just enter (no string entered) will cause an empty String parameter to be set
  • Submitting "null" (The String), will cause a null parameter to be set
  • When entering "returnnull", the underlying business method will return Null
The Main method will catch the occurring MethodConstraintViolationExceptions and print some details to the command prompt.

Lastly, the current method validator support via Spring is specifically targetting Hibernate Validator. However, there are standardization efforts underway as part of the Bean Validation 1.1 specification (JSR-349). In order to follow the progress, please follow also

Spring will provide support for JSR-349 as soon as the official standard has been ratified. In order to track inclusion into the Spring framework, please follow also Spring Framework Jira ticket SPR-8199 . As of today this feature should be available in the next Spring 3.2 release.

I hope this blog entry and the accompanying sample have showed you how easy it is to get started with  method level validation using Spring and Hibernate Validator. Please let me know if you have further questions or run into issues.


Javin @ spring interview questions answers said...

Indeed method validation with hibernate validator seems a good option to increase test exposure. Thanks for sharing information.

How to perform ldap authentication using spring Security

Anonymous said...

Does this also work with AspectJ based AOP?

Ilias Tsagklis said...

Hi Gunnar,

Nice blog! Is there an email address I can contact you in private?

ChrisG said...

Hi Gunnar,
Thank you for a great post.

I am trying to adopt your example for a project. I am having difficulty figuring out how to specify validation against Non Default Groups? Any example would be greatly appreciated.

-Chris G.

Gal Levinsky said...

Hi Gunnar,

Excellent post with good references!

Keep on the good work.


JJ said...

Hi Gunnar

Thank you for the post!

Great stuff!

I just started cutting my teeth with the built in Cache and Validation support now with Spring 3.1 and have hit a bit of wall. It seems that if i try to apply Cache and Validation advice on the same method the precedence of the two, by default, results in the Cache advice running before the validation. Wondering if this is wisest? As a result i have to compensate with conditional SPEl expressions in my key attributes to account for null, a little redundant because of course the Validation advice should check this before....

The MethodValidationPostProcessor has no writable property for the order value and seems to have a default value of Integer.Max which would always place it after Caching. Have i missed something, could be, if so what...

Thanks in advance, appreciate your examples, really helpful!