Bean Validation Feature

 

Introduction

Bean Validation 1.1 (JSR-349), an evolution of Bean Validation 1.0 (JSR-303), introduces declarative constraints (based on Java annotations) to define the expectations for:

  • properties of Java Beans
  • method and constructor parameters
  • method return values

For example:

Bean Validation API has been part of JPA 2.0 (JSR-317) and has proven to be successful and very useful, helping developers to delegate routine validation tasks to the solid, very extensible framework. It is very easy to create own constraints, including complex cross-field ones.

Dependencies

Bean Validation support in Apache CXF is implementation-independent and is built solely using Bean Validation API. The required dependencies are:

A couple of API implementations is available. Please note that if no implementation is detected on the runtime class-path then the constraints validation won't have any effect.

Using Hibernate Validator as bean validation provider

http://www.hibernate.org/subprojects/validator.html

Hibernate Validator is a mature and feature-rich validation provider with the full Bean Validation 1.1 support (as of version 5.x.x which is the reference implementation for JSR 349 - Bean Validation 1.1 API). Add the following dependency:

Hibernate Validator uses Java Expression Language 3.0 in order to provide better validation messages support.

Using Apache BVal as bean validation provider

http://bval.apache.org/

Current stable version of Apache BVal (0.5) doesn't support Bean Validation 1.1 but the upcoming 1.1.0 will have it fully implemented (at the moment 1.1.0-alpha-SNAPSHOT could be used).

<dependency>
    <groupId>org.apache.bval</groupId>
    <artifactId>bval-jsr</artifactId>
    <version>1.1.0-alpha-SNAPSHOT</version>
</dependency>

Common Bean Validation 1.1 Interceptors

JAX-RS and JAX-WS frontends can rely on the following common interceptors to get Bean Validation 1.1 done:

Both interceptors depend on org.apache.cxf.validation.BeanValidationProvider which abstracts away Bean Validation 1.1 API and provides useful utility methods. This provider can be directly injected into the interceptors as a 'provider' property. Injecting the provider is optional, the interceptors will create a default provider instance if it has not been injected.

CXF exception handlers can check if a caught javax.validation.ValidationException is an instance of CXF-specific ResponseConstraintViolationException in order to find whether the failure occurred during the return value validation or not.

The provider can be initialized with javax.validation.ParameterNameProvider or ValidationConfiguration in order to customize the way Bean Validation 1.1 implementation does its work.

Note that interceptors will only be effective if the current service object is a singleton. They will make a best effort of getting hold of a reference to the current service object, which can also be injected directly as a 'serviceObject' property.

Custom interceptors can customize the default processing (for example, see the section on Bean Validation 1.1 in JAX-RS 2.0). Typical customization is to have one of the input parameters or the response value unwrapped before it can be validated.

org.apache.cxf.validation.BeanValidationFeature can be used to register both in and out validation interceptors.

Configuration

The following snippets show how to get Bean Validation 1.1 interceptors activated for both JAX-RS and JAX-WS services using Spring:

Check the next section for more examples specific to JAX-RS.

Bean Validation 1.1 and JAX-RS 2.0

JAX-RS 2.0 specification (Chapter 7) introduces an optional requirement to get Bean Validation 1.1 supported.

Using the common interceptors described in the previous section can be sufficient for JAX-RS 2.0 resource methods having their input parameters and response values validated.

However, if you need a response values wrapped in JAX-RS Response validated or make sure per-request service instances get validated then JAX-RS frontend specific interceptors and the invoker need to be used:

  • org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInInterceptor: validates JAX-RS resource method parameters. At the moment it is nearly identical to the common BeanValidationInInterceptor which it extends. It can also be used as a JAX-RS 2.0 ContainerRequestFilter
  • org.apache.cxf.jaxrs.validation.JAXRSBeanValidationOutInterceptor: validates JAX-RS resource method return values, unwraps JAX-RS Response. It can also be used as a JAX-RS 2.0 ContainerResponseFilter
  • org.apache.cxf.jaxrs.validation.JAXRSBeanValidationFeature can be used to register both in and out validation interceptors.
  • org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInvoker: register it as a jaxrs:invoker if you need non-singleton service objects validated.

Note the default JAX-RS ExceptionMapper (org.apache.cxf.jaxrs.validation.ValidationExceptionMapper) which transforms javax.validation.ValidationException to corresponding HTTP status code has to be registered. Users can register the custom mappers if preferred.

org.apache.cxf.jaxrs.validation.JAXRSParameterNameProvider can be registered directly with the common BeanValidationProvider to get the error messages customized.

JAX-RS 2.0 developers should prefer using JAX-RS frontend specific interceptors when possible to make sure JAX-RS specific fixes are picked up automatically.

Configuring Bean Validation 1.1 using JAXRSServerFactoryBean

Configuring Bean Validation 1.1 using Spring bean definitions XML

Following the similar approach as for JAXRSServerFactoryBean, in case of Spring respective bean definitions should be added under <jaxrs:outInterceptors>, <jaxrs:inInterceptors> and <jaxrs:providers> sections, f.e.:

Validation Exceptions and HTTP status codes

As per JAX-RS 2.0 specification, any input parameter validation violation is mapped to HTTP status code 400 Bad Request and any return value validation violation (or internal validation violation) is mapped to HTTP status code 500 Internal Server Error. This is essentially what org.apache.cxf.jaxrs.validation.ValidationExceptionMapper does.

Icon

The details of validation exceptions are not currently included into the response but only logged. Application developers are encouraged to register custom exception mappers if reporting the validation error details is required.

Customizing Validation Provider

org.apache.cxf.validation.BeanValidationProvider is a wrapper around javax.validation.ValidationFactory and used by CXF validation interceptors.

It is created if it has not been injected. However if one needs to customize javax.validation.ValidationFactory then a custom BeanValidationProvider instance can be injected via the 'provider' property into

the bean validation interceptors.BeanValidationProvider has the default constructor, the one accepting javax.validation.ParameterNameProvider, etc, see the source for more details.

For example, one can customize the way parameters can be described on the JAX-RS path by injecting JAXRSParameterNameProvider into BeanValidationProvider.

Examples

The following examples show JAX-RS resource methods being validated but predefined or custom Bean Validation 1.1 constraints can be applied to JAX-WS service methods exactly the same way.

Validating simple input parameters

Validating complex input parameters

This example assumes that class Book has validation constraints defined:

Validating return values (non-Response)

This example assumes that class Book has validation constraints defined (as in example above).

Validating return values (Response)

Bean Validation and Schema Validation

Web service developers often rely on the schema-based validation.

Bean validation can be used as an alternative form of validation.

However it can also complement the schema-based validation in cases where the current schema is not very strict.