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:

public class Person < @NotNull private String firstName; @NotNull private String lastName; @Valid @NotNull private Person boss; public @NotNull String saveItem( @Valid @NotNull Person person, @Max( 23 ) BigDecimal age ) < // . >>

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:

 javax.validation validation-api 1.1.0.Final  javax.el javax.el-api 3.0.0  org.glassfish javax.el 3.0.0/version>

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

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:

 org.hibernate hibernate-validator 5.0.2.Final

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

Using Apache BVal as bean validation provider

 org.apache.bval bval-jsr 1.1.2

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:

// Interface implemented by both JAX-RS and JAX-WS services: @WebService(targetNamespace = "http://bookworld.com") @Path("/") public interface BookWorld < @POST @Produces("text/xml") @Consumes("text/xml") @Valid BookWithValidation echoBook(@Valid BookWithValidation book); >@WebService(endpointInterface = "org.apache.cxf.systest.jaxrs.validation.spring.BookWorld", serviceName = "BookWorld") public class BookWorldImpl implements BookWorld < @Override public BookWithValidation echoBook(BookWithValidation book) < return book; >>

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

Bean Validation 1.1 and JAX-RS 2.0

Server

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:

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.

Validation of non-singleton service objects

The non-singleton service objects are created in CXF JAXRSInvoker therefore its subclass org.apache.cxf.jaxrs.validation.JAXRSBeanValidationInvoker needs to be registered if these objects need to be validated.

Register it either in a jaxrs:invoker block when using Spring or Blueprint or with a "jaxrs.invoker" servlet init parameter when using CXFNonSpringJaxrsServlet.

Configuring Bean Validation 1.1 using JAXRSServerFactoryBean

JAXRSServerFactoryBean sf = new JAXRSServerFactoryBean(); sf.setResourceClasses( . ); sf.setResourceProvider( . ); sf.setProvider(new ValidationExceptionMapper()); sf.setInInterceptors(Arrays. < Interceptor< ? extends Message >>asList(new new JAXRSBeanValidationInInterceptor())); sf.setOutInterceptors(Arrays. < Interceptor< ? extends Message >>asList(new JAXRSBeanValidationOutInterceptor())); sf.create();

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 , and 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.

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.

Client Proxies

CXF 3.1.9 introduces an org.apache.cxf.jaxrs.client.validation.JAXRSClientBeanValidationFeature which can be used to validate the request parameters of a JAX-RS proxy method.

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

@POST @Path("/books") public Response addBook( @NotNull @Pattern(regexp = "\\d+") @FormParam("id") String id, @NotNull @Size(min = 1, max = 50) @FormParam("name") String name) < // do some work return Response.created().build(); >

Validating complex input parameters

@POST @Path("/books") public Response addBook( @Valid Book book ) < // do some work return Response.created().build(); >

This example assumes that class Book has validation constraints defined:

public class Book < @NotNull @Pattern(regexp = "\\d+") private String id; @NotNull @Size(min = 1, max = 50) private String name; // . >

Validating return values (non-Response)

@GET @Path("/books/") @Override @NotNull @Valid public Book getBook(@PathParam("bookId") String id)

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

Validating return values (Response)

@GET @Path("/books/") @Valid @NotNull public Response getBookResponse(@PathParam("bookId") String id)

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.

Privacy Policy - (edit page) (add comment)
Apache CXF, CXF, Apache, the Apache feather logo are trademarks of The Apache Software Foundation.
All other marks mentioned may be trademarks or registered trademarks of their respective owners.