Initial Draft of the Bean Validation Specification Released
1. In the model (typically as database schema constraints).
2. In the application code.
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:
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 properlyA 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.
• the second group is a heavy consumer of time, CPU or memory and should be avoided if possible"
Blog entry on groups
XML Forms support?
Anything like that?
Re: XML Forms support?
Specific converters are not part of the spec because as you pointed out there are gazillions of validation schemes :)
Brandon Holt, Preston Briggs, Luis Ceze, Mark Oskin May 21, 2015
Kai Kreuzer, Olaf Weinmann May 21, 2015