Initial Draft of the Bean Validation Specification Released

Posted by Charles Humble on Apr 09, 2008

Sections

Development

Topics

JCP Standards ,

Java

Tags

Validation

In most enterprise applications data constraints will exist in two places:
1. In the model (typically as database schema constraints).
2. In the application code.
Both are important. Database constraints allow reuse of the underlying data model in the event that the application code needs to be migrated. Application level validation is able to provide finer grained control (is this a valid email address? is the customer's date of birth in the future?) than can be easily achieved with model level constraints, and can also more readily provide meaningful error messages to the users of the application. Application level validation may in itself reside in multiple places, resulting in a large amount of duplication of effort across the different application tiers. In a typical web application, for example, JavaScript is executed in the browser for simple field level validations and the serverside layer is used for more complex business rule validations. It would be highly desirable to be able to centralize the validation definitions in one place and share the definitions across the different layers.

Led by Hibernate Validator lead developer Emmanuel Bernard, JSR-303 aims to standardize the constraints metadata model for Java EE 6. An early draft of the specification has been released and the expert group are keen to solicit feedback. As part of this a forum has been set up, and Bernard has begun to publish a series of articles (part 1, part 2) on the Hibernate blog describing how the API works.

Unsurprisingly given its parentage, JSR-303 is heavily influenced by the JBoss' Hibernate Validations although a number of the other validator frameworks (Xwork and the Apache Commons Validator for instance) have also influenced the specification. It uses annotations for the majority of cases and provides standard APIs for runtime validation and to query the metadata. Each constraint annotation must define a message of type String which is used to create an error message. Error messages support internationalisation. Constraints may be declared on an object's fields, getters, class, superclass and interfaces and validating an object will validate all of its constraints. For example the following code creates a String called street1 which has a maximum length of fifty characters and is mandatory:

@NotEmpty @Max(50)
private String street1;

The framework is designed to be extensible so that an application can easily define its own additional set of constraints. From the first blog entry:

"A constraint is comprised of:
• an annotation
• a constraint validation implementation
While the annotation expresses the constraint on the domain model, the validation implementation decides whether a given value passes the constraint or not."

As well as supporting instance validation the specification supports validation of an object graph, so for example if a bean ClientDetails contains an Address bean with one or more @Valid annotations the validator will validate the contents of the Address bean when the ClientDetails bean is validated.

One significant difference between the spec and the Hibernate Validator is the concept of groups, which provide a means for creating subsets of validations. Groups have an associated sequence (set via an @GroupSequence annotation) so that a developer can force one set of constraints to pass without error before the next set executes. Groups also allow a partial validation of the JavaBean. The draft specification suggests two scenarios where this might be useful:

"• the second group depends on a stable state to run properly
• the second group is a heavy consumer of time, CPU or memory and should be avoided if possible"

A number of different pieces of technology in the Java EE 6 platform should be able to take advantage of JSR-303. For example DDL updates when generated via an ORM tool, entity validation on insertion/update by the Java Persistence API, the new WebBeans API, and JavaServerFaces components all look to be obvious candidates.

1. Back to top

   Blog entry on groups

   by Emmanuel Bernard

   I have just written a blog entry on groups here.
   
   
   Emmanuel Bernard

   Reply

2. Back to top

   XML Forms support?

   by Martin Probst

   It would be highly interesting if there was an implementation that could automatically map from JSR-303 metadata to other validation schemes, e.g. XML Forms types, client side JavaScript etc.
   
   Anything like that?

   Reply

3. Back to top

   Re: XML Forms support?

   by Emmanuel Bernard

   The spec is written in such a way and exposes metadata APIs so that your client side JS library, your XML Forms type consumer and so on can go and extract the info from the domain model. The next step is to talk to the JPA 2 and JSF 2 expert groups to match this integration in the respective specifications.
   Specific converters are not part of the spec because as you pointed out there are gazillions of validation schemes :)

   Reply

• Older >