Saturday, March 6, 2010

J2EE 6 - Bean Validation

Validating data is a common task that occurs throughout an application. For example, in the presentation layer of an application, you might want to validate that the number of characters a user enters in a text field is at most 20 characters or that the number a user enters in a numeric field is positive. If you set those constraints, you probably want the same data to be validated before it's used in the business logic of the application and when the data is stored in a database.

Developers often code the same validation logic in multiple layers of an application, something that's time consuming and error-prone. Or they put the validation logic in their data model, cluttering it with what is essentially metadata.

Bean Validation, JSR 303 makes validation simpler and reduces the duplication, errors, and clutter that characterizes the way validation is often handled in enterprise applications. Bean Validation affords a standard framework for validation, in which the same set of validations can be shared by all the layers of an application.

Specifically, Bean Validation offers a framework for validating Java classes written according to JavaBeans conventions. You use annotations to specify constraints on a JavaBean — you can annotate a JavaBean class, field, or property.


You can also extend or override these constraints through XML descriptors. A validator class then validates each constraint. You specify which validator class to use for a given type of constraint.

Here, for example, is part of a class that declares some constraints through Bean Validation annotations:



The @NotNull annotation specifies that the annotated element, addressline1, must not be null. The @Size annotation specifies that the annotated elements, addressline1 and addressline2, must not be longer than the specified maximum, 30 characters.
When an Address object is validated, the addressline1 value is passed to a validator class that is defined for the @NotNull constraint as well as to a validator class defined for the @Size constraint. The addressline2 value is also passed to the validator class for the @Size constraint. The pertinent validator classes perform the validations.

Both the @NotNull and @Size constraints are built into the Bean Validation framework so you do not need to define validator classes for them. However, you can add your own constraints to the built-in constraints, in which case, you need to define validator classes. For example, you can define a constraint named @ZipCode as follows:



Then you can specify the @ZipCode constraint on a class, field, or property just like any other constraint. Here is an example:



When an Address object is validated, the zipCode value is passed to the ZipcodeValidator class for validation. Notice that the constraint definition includes another constraint: @Size(min=5, max=5).

This means that an element annotated by the @ZipCode annotation must be exactly 5 characters in length. The element is validated against this constraint in addition to the primary constraint check that ZipcodeValidator performs.

Bean Validation allows you to create a constraint that is composed of other constraints. In fact, any composing constraint can itself be composed of constraints. Notice too that the constraint definition specifies an error message to be returned if the constraint fails the validation check. Here, the error message is "Wrong zipcode".


You can also use Bean Validation to validate an entire object graph in a straightforward way. An object graph is an object composed of other objects. If you specify the @Valid annotation on the root object of an object graph, it directs the pertinent validator to recursively validate the associated objects in the object graph. Consider the following example:



When an Order object is validated, the Address object and the associated objects in its object graph are validated too.

To meet the objective of sharing the same set of validations across all the layers of an application, Bean Validation is integrated across the Java EE 6 platform.

For example, presentation-layer technologies such as JSF and enterprise-layer technologies such as JPA have access to the constraint definitions and validators available through the Bean Validation framework. You no longer need to specify constraints in multiple places and in multiple ways across the layers of an application.


Source: java.sun.com - J2EE 6 Overview

2 comments:

  1. Nice information, I really appreciate the way you presented.Thanks for sharing..

    http://www.w3cvalidation.net/

    ReplyDelete
  2. thats clearly and nicely explained.! Thanks.

    ReplyDelete