Introduction to JSR 303-bean Validation and best practices

Introduction to JSR 303-bean Validation and best practices

The JSR 303–bean Validation is a data validation specification that determines the final scenario in November 2009. December 2009 Java EE 6 was released, and Bean Validation was included as an important feature. This article introduces the main features of Bean Validation and demonstrates how to use bean Validation correctly in the Java development process with some examples.

2 Reviews:

Andapeng, software engineer, IBM

Yang Le, software engineer, IBM

Ong Zhihong, software engineer, IBM

May 24, 2011

• Content

Develop and deploy your next application on the IBM Bluemix cloud platform.

Get started with your trial

About Bean Validation

At any time, when you are dealing with the business logic of an application, data validation is something you have to consider and face. The application must have some means to ensure that the input data is semantically correct. In the usual case, the application is layered and different layers are done by different developers. Many times the same data validation logic appears on different layers, which leads to code redundancy and some management issues, such as semantic consistency. To avoid this situation, it is best to bind the validation logic to the appropriate domain model.

Bean Validation defines the corresponding metadata model and API for JavaBean validation. The default metadata is Java Annotations, which allows you to overwrite and extend the original metadata information by using XML. In the application, you @NotNull @Max @ZipCode can ensure the correctness of the data Model (JavaBean) by using Bean Validation or your own defined constraint, for example. Constraint can be attached to fields, getter methods, classes, or interfaces above. For some specific needs, users can easily develop customized constraint. Bean Validation is a runtime data validation framework that verifies that the error message is returned immediately after validation.

Download JSR 303–bean Validation Specification http://jcp.org/en/jsr/detail?id=303

Hibernate Validator is a reference implementation of Bean Validation. Hibernate Validator provides the implementation of all the built-in constraint in the JSR 303 specification, in addition to some additional constraint. To learn more about Hibernate Validator, see http://www.hibernate.org/subprojects/validator.html

Back to top of page

Constraint table 1 in Bean Validation. Built-in constraint in Bean Validation

Constraint	More Information
@Null	The annotated element must be anull
@NotNull	The annotated element must not be anull
@AssertTrue	The annotated element must be atrue
@AssertFalse	The annotated element must be afalse
@Min(value)	The annotated element must be a number whose value must be greater than or equal to the specified minimum value
@Max(value)	The annotated element must be a number whose value must be less than or equal to the specified maximum value
@DecimalMin(value)	The annotated element must be a number whose value must be greater than or equal to the specified minimum value
@DecimalMax(value)	The annotated element must be a number whose value must be less than or equal to the specified maximum value
@Size(max, min)	The size of the annotated element must be within the specified range
@Digits (integer, fraction)	The annotated element must be a number whose value must be within an acceptable range
@Past	The annotated element must be a past date
@Future	The annotated element must be a future date
@Pattern(value)	The annotated element must conform to the specified regular expression

Table 2. Hibernate Validator Additional constraint

Constraint	More Information
@Email	The annotated element must be an e-mail address
@Length	The size of the annotated string must be within the specified range
@NotEmpty	The annotated string must be non-empty
@Range	The annotated element must be within the appropriate range

A constraint is usually composed of annotation and the corresponding constraint validator, which are a one-to-many relationship. This means that there can be multiple constraint validator corresponding to a annotation. At run time, the Bean Validation framework itself validates the data by selecting the appropriate constraint validator based on the type of the annotated element.

In some cases, more complex constraint are needed in the user's application. Bean Validation provides a mechanism for extending constraint. There are two ways to do this, one is to combine existing constraint to generate a more complex constraint, and the other is to develop a new constraint.

Back to top of page

Create a simple app that contains validation logic (based on JSP)

In this article, you demonstrate how to apply Bean Validation in Java development by creating a fictitious order management system (JSP-based web App). This streamlined system allows users to create and retrieve orders.

System design and application of the technology Figure 1. System architecture

Figure 1 is a structure diagram of the report management system and is a typical MVC (Model-view-controller) application. The controller is responsible for receiving and processing requests, and the Servlet plays the role of controller to process requests, business logic, and move to the appropriate JSP page. Validates the data in the Servlet. JSP plays the role of view as a graphical interface to present the data in model to facilitate user interaction. Models are the data model for the operation of this system, and we simplify this part to not persist the data.

Data Model Figure 2. Data model

Figure 2 shows the data model of the order management system.

Declares the JavaBean Listing 1 for contraint. Order.java

public class Order {  //must not be null, size is ten  @NotNull  @Size (min = ten, max = ten)  private String orderId;  Must not be empty @NotEmpty  private String customer;  Must be an e-mail address @Email  private String Email;  Must not be empty @NotEmpty  private String address;  Must be not NULL, must be the following four strings ' created ', ' paid ', ' shipped ', ' closed ' one of them//@Status is a custom contraint  @NotNull  @ Status  private String status;  Must not be null  @NotNull  private Date createdate;  Nested validation @Valid  private product product, ... getter and setter  }

Listing 2. Product.java

public class Product {  //must be non-empty @NotEmpty  private String productName;  Must be within the range of 8000 to 10000//@Price is a custom constraint  @Price  private float price; Getter and Setter  }

Listing 3. Orderquery.java

The date indicated by ' to ' must be after the date represented by ' from '//@QueryConstraint is a custom constraint @QueryConstraint public  class orderquery {  private Date from;  Private Date to; ..... omitted ... Getter and Setter  }

Customized constraint

@Priceis a custom constraint, composed of two built-in constraint.

Listing 4. The annotation part of the @Price

@Max and @Min are built-in constraint  @Max (10000)  @Min (8000)  @Constraint (Validatedby = {})  @Documented  @Target ({elementtype.annotation_type, Elementtype.method, Elementtype.field})  @Retention ( retentionpolicy.runtime) Public  @interface Prices {  String message () default "wrong price";  Class<?>[] Groups () default {};  class<? Extends payload>[] Payload () default {};  }

@Statusis a newly developed constraint.

Listing 5. The annotation part of the @Status

@Constraint (Validatedby = {Statusvalidator.class})  @Documented  @Target ({elementtype.annotation_type, Elementtype.method, Elementtype.field})  @Retention (retentionpolicy.runtime) public  @interface Status {  String message () default "Incorrect state, should be ' created ', ' paid ', shipped ', closed ' one of them";  Class<?>[] Groups () default {};  class<? Extends payload>[] Payload () default {};  }

Listing 6. Constraint validator part of the @Status

public class Statusvalidator implements Constraintvalidator<status, string>{  private final string[] All_ STATUS = {"Created", "paid", "shipped", "closed"};  public void Initialize (status status) {  } public  Boolean isValid (String value, Constraintvalidatorcontext Context) {  if (arrays.aslist (All_status). Contains (value))  return true;  return false;  }  }

Back to top of page

Bean Validation API uses examples to create orders

When users create an order record, they need to fill in the following information: order number, customer, email, address, status, product name, product price

Figure 3. Create an Order

To verify this information, use the Bean Validation API

Listing 7. Code Snippets

 protected void DoPost (HttpServletRequest req, HttpServletResponse resp) throws Servletexception, IOException {httpsess  Ion session = Req.getsession ();  Get input information from request String OrderId = (string) req.getparameter ("OrderId");  String customer = (string) req.getparameter ("Customer");  string email = (string) req.getparameter ("email");  String address = (string) req.getparameter ("Address");  String status = (String) req.getparameter ("status");  String productName = (string) req.getparameter ("ProductName");  String productprice = (string) req.getparameter ("Productprice");  Put the Bean in the session order order = New Order ();  Order.setorderid (ORDERID);  Order.setcustomer (customer);  Order.setemail (email);  Order.setaddress (address);  Order.setstatus (status);  Order.setcreatedate (New Date ());  Product Product = new product ();  Product.setname (ProductName);  if (productprice! = null && productprice.length () > 0) product.setprice (float.valueof (Productprice)); Order.setproduct (PRODUCT);  Session.setattribute ("Order", order);  Validatorfactory factory = Validation.builddefaultvalidatorfactory ();  Validator Validator = Factory.getvalidator ();  Set<constraintviolation<order>> violations = validator.validate (Order);  if (violations.size () = = 0) {Session.setattribute ("order", NULL);  Session.setattribute ("errormsg", null);  Resp.sendredirect ("creatsuccessful.jsp");  } else {StringBuffer buf = new StringBuffer ();  ResourceBundle bundle = Resourcebundle.getbundle ("Messages"); for (constraintviolation<order> violation:violations) {buf.append ("-" + bundle.getstring (  Violation.getpropertypath (). toString ());  Buf.append (Violation.getmessage () + "<br>\n");  } session.setattribute ("ErrorMsg", buf.tostring ());  Resp.sendredirect ("createorder.jsp"); }  }

If the user submits the order without filling in any information, the corresponding error message will be displayed on the page

Figure 4. Error message returned after validation

In fact, you can call the JSR 303 API anywhere in the program to verify the data, and then officer the results back.

Listing 8. Call the JSR 303 API for validation

Order order = New Order (); ... Validatorfactory factory = Validation.builddefaultvalidatorfactory ();  Validator Validator = Factory.getvalidator ();  Set<constraintviolation<order>> violations = validator.validate (Order);

...

Back to top of page

Conclusion

The release of JSR 303 makes it easy to automatically bind and validate data, allowing developers to define the data model without having to consider the limitations of the implementation framework. Of course, Bean Validation only provides some of the most basic constraint, in the actual development process, the user can according to their own needs to combine or develop more complex constraint

Reference Learning

• JSR 303 Specification: detailed JSR 303 specification description, where you can find detailed documentation related to the specification and download the relevant implementation code.
• The JSR 303 reference implements Hibernate Validator: Learn how to implement Bean Validator specifically through Hibernate.
• DeveloperWorks Java Technology Zone: Here are hundreds of articles on various aspects of Java programming.

Discuss

• Join DeveloperWorks Chinese community. View developer-driven blogs, forums, groups, and wikis, and communicate with other DeveloperWorks users.

Transferred from: http://www.ibm.com/developerworks/cn/java/j-lo-jsr303/

Introduction to JSR 303-bean Validation and best practices