Bean Validation has an abstract configuration component called a Service Provider Interface (SPI), which allows it to integrate with Spring Framework and Guice. Any custom constraint validator implementation can inject any dependency. Any dependency injection container that integrates with Bean Validation framework has the responsibility to instantiate a ValidatorFactory instance.
Bean Validation delegates the management of the lifecycle to the various supported containers, including CDI. Any type of MessageInterpolator, TraversableResolver, ConstraintValidatorFactory instances are also managed from a dependency injection framework.
In environments where there is no default integration or a standalone Java SE runtime, the application is required to configure ValidatorFactory and a custom ConstraintValidatorFactory instance. The application may choose to use a dependency injection framework such as JBoss Weld, Guice, or the Spring Framework.
Bean Validation 1.1 integrates with the JPA 2.0 or better and developers get this support for free as it is defined by the Java EE 7 specification. Again there is a choice if the integration is part of CDI container and it is provided as an entity injection mechanism that is hidden from the application or part of the JPA provider itself before objects are flushed to the database through the persistence session.
In Java EE 7, the Bean Validator must make available the JNDI paths: java:comp/ValidatorFactory for the default ValidatorFactory, and java:comp/Validator for the Validator instance.
Similar to JNDI injection, any CDI container operating under Java EE 7 must allow injection of the default ValidatorFactory instance. So the following code snippet is completely legal in both the Full and Web profiles:
@Inject private ValidatorFactory validatorFactory; @Inject private Validator validator;
Java EE 7, however, does cater for alternative Bean Validation providers with the @Qualifier annotation assuming that there is an instance of a factory located somewhere else in the system. The developer would ensure there is an obvious @Producer CDI managed bean in their application.
Bean Validation 1.1 has integration with JAX-RS 2.0 in the Java EE 7 specification. It also integrates with Java Server Faces. Incidentally, JAX-RS support is a special application of Method-level constraint validation. A provider method-level constraint intercepts JAX-RS request and responses.
The Bean Validator specification has some rules on this standard implementation and how it responds to validation failures. The following are the rules:
- Violations on constraints on parameters to a RESTful endpoint generate a HTTP error response code in the 400 – 499 range
- Violations on constraints on the return value to a RESTful endpoint generate a HTTP error response code in the 500 – 599 range
The following is an example of JAX-RS planning resource from Chapter 8, RESTful Services JAX-RS 2.0, with constraints applied to the request and response:
@Path("plans")
public PlanningResource {
@Path("{id}")
@GET
@Produces(MediaType.APPLICATION_JSON)
@NotNull
public Response getPlanList(
@PathParam("id")
@Size( min=8, max=12)
@SecureIdChecker String id ) {
List<Plan> plans = findPlanCollectionById(id);
Collections.sort( plans
new AscendingDateOrderComparator() );
GenericEntity entity =
new GenericEntity<List<Plan>>(plans);
return Response.ok(entity).build();
}
}This concludes the chapter on Bean Validation. For more details, please inspect this handbook's source code and read the specification for clarity.