{"id":6950,"date":"2013-01-14T19:00:12","date_gmt":"2013-01-14T17:00:12","guid":{"rendered":"http:\/\/www.javacodegeeks.com\/?p=6950"},"modified":"2013-06-11T10:14:22","modified_gmt":"2013-06-11T07:14:22","slug":"integrating-bean-validation-with-jax-rs-in-java-ee-6","status":"publish","type":"post","link":"https:\/\/www.javacodegeeks.com\/2013\/01\/integrating-bean-validation-with-jax-rs-in-java-ee-6.html","title":{"rendered":"Integrating Bean Validation with JAX-RS in Java EE 6"},"content":{"rendered":"

JavaBeans Validation (Bean Validation) is a new validation model available as part of Java EE 6 platform. The Bean Validation model is supported by constraints in the form of annotations placed on a field, method, or class of a JavaBeans component, such as a managed bean.<\/p>\n

Several built-in constraints are available in the javax.validation.constraints<\/code> package. The Java EE 6 Tutorial<\/a> lists all the built-in constraints.
\n 
\n 
\n 
\n 
\n 
\nConstraints in Bean Validation are expressed via Java annotations:<\/p>\n

public class Person {\r\n    @NotNull\r\n    @Size(min = 2, max = 50)\r\n    private String name;\r\n    \/\/ ...\r\n}<\/pre>\n
Bean Validation and RESTful web services<\/h2>\n
JAX-RS 1.0 provides great support for extracting request values and binding them into Java fields, properties and parameters using annotations such as @HeaderParam<\/code>, @QueryParam<\/code>, etc. It also supports binding of request entity bodies into Java objects via non-annotated parameters (i.e., parameters that are not annotated with any of the JAX-RS annotations). Currently, any additional validation on these values in a resource class must be performed programmatically.<\/p>\n
The next release, JAX-RS 2.0, includes a proposal to enable validation annotations to be combined with JAX-RS annotations. For example, given the validation annotation @Pattern<\/code>, the following example shows how form parameters could be validated.<\/p>\n
@GET\r\n@Path('{id}')\r\npublic Person getPerson(\r\n        @PathParam('id')\r\n        @Pattern(regexp = '[0-9]+', message = 'The id must be a valid number')\r\n        String id) {\r\n    return persons.get(id);\r\n}<\/pre>\n
However, at the moment, the only solution is to use a proprietary implementation. What is presented next is a solution based on the RESTEasy<\/a> framework from JBoss that complies with the JAX-RS specification and adds a RESTful validation interface through the annotation @ValidateRequest<\/code>.<\/p>\n
The exported interface allows us to create our own implementation. However, there is already one widely used and to which RESTEasy also provides a seamless integration. This implementation is Hibernate Validator<\/a>. This provider can be added to the project through the following Maven dependencies:<\/p>\n
<dependency>\r\n    <groupId>org.jboss.resteasy<\/groupId>\r\n    <artifactId>resteasy-jaxrs<\/artifactId>\r\n    <version>2.3.2.Final<\/version>\r\n    <scope>provided<\/scope>\r\n<\/dependency>\r\n<dependency>\r\n    <groupId>org.jboss.resteasy<\/groupId>\r\n    <artifactId>resteasy-hibernatevalidator-provider<\/artifactId>\r\n    <version>2.3.2.Final<\/version>\r\n<\/dependency><\/pre>\n
Note:<\/strong> without declaring the @ValidateRequest<\/code> at class or method level, no validation will occur despite having applied constraint annotations on the methods, e.g. the example above.<\/p>\n
@GET\r\n@Path('{id}')\r\n@ValidateRequest\r\npublic Person getPerson(\r\n        @PathParam('id')\r\n        @Pattern(regexp = '[0-9]+', message = 'The id must be a valid number')\r\n        String id) {\r\n    return persons.get(id);\r\n}<\/pre>\n
After applying the annotation, the parameter id<\/code> will be automatically validated when a request is made.
\nYou can of course validate entire entities instead of single fields by using the annotation @Valid<\/code>. We could for example have one method that accepts a Person<\/code> object and validates it.<\/p>\n
@POST\r\n@Path('\/validate')\r\n@ValidateRequest\r\npublic Response validate(@Valid Person person) {\r\n    \/\/ ...\r\n}<\/pre>\n
Note:<\/h4>\n
 By default, when validation fails an exception is thrown by the container and a HTTP 500 status is returned to the client. This default behavior can\/should be overridden, allowing us to customize the Response that is returned to the client through exception mappers.<\/p>\n
Internationalization<\/h2>\n
Until now we have been using the default or hard-coded error messages, but this is both a bad practice and not flexible at all. I18n is part of the Bean Validation specification and allows us to specify custom error messages using a resource property file. The default resource file name is ValidationMessages.properties<\/code> and must include pairs of properties\/values like:
 
<\/div> <\/div><\/p>\n
person.id.pattern=The person id must be a valid number\r\nperson.name.size=The person name must be between {min} and {max} chars long<\/pre>\n
Note:<\/h4>\n
 {min}<\/code>, {max}<\/code> refer to properties of the constraint to which the message will be associated with.<\/p>\n
Those defined messages can then be injected on the validation constraints as:<\/p>\n
@POST\r\n@Path('create')\r\n@Consumes(MediaType.APPLICATION_FORM_URLENCODED)\r\npublic Response createPerson(\r\n        @FormParam('id')\r\n        @Pattern(regexp = '[0-9]+', message = '{person.id.pattern}')\r\n        String id,\r\n        @FormParam('name')\r\n        @Size(min = 2, max = 50, message = '{person.name.size}')\r\n        String name) {\r\n    Person person = new Person();\r\n    person.setId(Integer.valueOf(id));\r\n    person.setName(name);\r\n    persons.put(Integer.valueOf(id), person);\r\n    return Response.status(Response.Status.CREATED).entity(person).build();\r\n}<\/pre>\n
To provide translations to other languages, one must create a new ValidationMessages_XX.properties<\/code> file with the translated messages, where XX<\/code> is the code of the language being provided.<\/p>\n
Unfortunately Hibernate Validator provider doesn\u2019t support i18n based on a specific HTTP request. It does not take Accept-Language<\/code> HTTP header into account and always uses the default Locale<\/code> as provided by Locale.getDefault()<\/code>. To be able to change the Locale<\/code> using the Accept-Language<\/code> HTTP header (e.g., changing the language in the browser options), a custom implementation must be provided.<\/p>\n
Custom validator provider<\/h2>\n
The code below intends to address this issue and has been tested with JBoss AS 7.1<\/a>.<\/p>\n
The first thing to do is to remove the Maven resteasy-hibernatevalidator-provider<\/code> dependency, since we are providing our own provider, and add Hibernate Validator dependency:<\/p>\n
<dependency>\r\n    <groupId>org.hibernate<\/groupId>\r\n    <artifactId>hibernate-validator<\/artifactId>\r\n    <version>4.2.0.Final<\/version>\r\n<\/dependency><\/pre>\n
Next create a custom message interpolator to adjust the default Locale<\/code> used.<\/p>\n
public class LocaleAwareMessageInterpolator extends\r\n        ResourceBundleMessageInterpolator {\r\n\r\n    private Locale defaultLocale = Locale.getDefault();\r\n\r\n    public void setDefaultLocale(Locale defaultLocale) {\r\n        this.defaultLocale = defaultLocale;\r\n    }\r\n\r\n    @Override\r\n    public String interpolate(final String messageTemplate,\r\n            final Context context) {\r\n        return interpolate(messageTemplate, context, defaultLocale);\r\n    }\r\n\r\n    @Override\r\n    public String interpolate(final String messageTemplate,\r\n            final Context context, final Locale locale) {\r\n        return super.interpolate(messageTemplate, context, locale);\r\n    }\r\n}<\/pre>\n
The next step is to provide a ValidatorAdapter<\/code>. This interface was introduced to decouple RESTEasy from the real validation API.<\/p>\n
public class RESTValidatorAdapter implements ValidatorAdapter {\r\n\r\n    private final Validator validator;\r\n\r\n    private final MethodValidator methodValidator;\r\n\r\n    private final LocaleAwareMessageInterpolator interpolator = new LocaleAwareMessageInterpolator();\r\n\r\n    public RESTValidatorAdapter() {\r\n        Configuration<?> configuration = Validation.byDefaultProvider()\r\n                .configure();\r\n        this.validator = configuration.messageInterpolator(interpolator)\r\n                .buildValidatorFactory().getValidator();\r\n        this.methodValidator = validator.unwrap(MethodValidator.class);\r\n    }\r\n\r\n    @Override\r\n    public void applyValidation(Object resource, Method invokedMethod,\r\n            Object[] args) {\r\n        \/\/ For the i8n to work, the first parameter of the method being validated must be a HttpHeaders\r\n        if ((args != null) && (args[0] instanceof HttpHeaders)) {\r\n            HttpHeaders headers = (HttpHeaders) args[0];\r\n            List<Locale> acceptedLanguages = headers.getAcceptableLanguages();\r\n            if ((acceptedLanguages != null) && (!acceptedLanguages.isEmpty())) {\r\n                interpolator.setDefaultLocale(acceptedLanguages.get(0));\r\n            }\r\n        }\r\n\r\n        ValidateRequest resourceValidateRequest = FindAnnotation\r\n                .findAnnotation(invokedMethod.getDeclaringClass()\r\n                        .getAnnotations(), ValidateRequest.class);\r\n\r\n        if (resourceValidateRequest != null) {\r\n            Set<ConstraintViolation<?>> constraintViolations = new HashSet<ConstraintViolation<?>>(\r\n                    validator.validate(resource,\r\n                            resourceValidateRequest.groups()));\r\n\r\n            if (constraintViolations.size() > 0) {\r\n                throw new ConstraintViolationException(constraintViolations);\r\n            }\r\n        }\r\n\r\n        ValidateRequest methodValidateRequest = FindAnnotation.findAnnotation(\r\n                invokedMethod.getAnnotations(), ValidateRequest.class);\r\n        DoNotValidateRequest doNotValidateRequest = FindAnnotation\r\n                .findAnnotation(invokedMethod.getAnnotations(),\r\n                        DoNotValidateRequest.class);\r\n\r\n        if ((resourceValidateRequest != null || methodValidateRequest != null)\r\n                && doNotValidateRequest == null) {\r\n            Set<Class<?>> set = new HashSet<Class<?>>();\r\n            if (resourceValidateRequest != null) {\r\n                for (Class<?> group : resourceValidateRequest.groups()) {\r\n                    set.add(group);\r\n                }\r\n            }\r\n\r\n            if (methodValidateRequest != null) {\r\n                for (Class<?> group : methodValidateRequest.groups()) {\r\n                    set.add(group);\r\n                }\r\n            }\r\n\r\n            Set<MethodConstraintViolation<?>> constraintViolations = new HashSet<MethodConstraintViolation<?>>(\r\n                    methodValidator.validateAllParameters(resource,\r\n                            invokedMethod, args,\r\n                            set.toArray(new Class<?>[set.size()])));\r\n\r\n            if (constraintViolations.size() > 0) {\r\n                throw new MethodConstraintViolationException(\r\n                        constraintViolations);\r\n            }\r\n        }\r\n    }\r\n}<\/pre>\n
Warn:<\/h2>\n
 @HttpHeaders<\/code> needs to be injected as the first parameter of the methods that are going to be validated:<\/p>\n
@POST\r\n@Path('create')\r\n@Consumes(MediaType.APPLICATION_FORM_URLENCODED)\r\npublic Response createPerson(\r\n        @Context HttpHeaders headers,\r\n        @FormParam('id')\r\n        @Pattern(regexp = '[0-9]+', message = '{person.id.pattern}')\r\n        String id,\r\n        @FormParam('name')\r\n        @Size(min = 2, max = 50, message = '{person.name.size}')\r\n        String name) {\r\n    Person person = new Person();\r\n    person.setId(Integer.valueOf(id));\r\n    person.setName(name);\r\n    persons.put(id, person);\r\n    return Response.status(Response.Status.CREATED).entity(person).build();\r\n}<\/pre>\n
Finally, create the provider that will select the classes above to be used to validate Bean Validation constraints:<\/p>\n
@Provider\r\npublic class RESTValidatorContextResolver implements\r\n        ContextResolver<ValidatorAdapter> {\r\n\r\n    private static final RESTValidatorAdapter adapter = new RESTValidatorAdapter();\r\n\r\n    @Override\r\n    public ValidatorAdapter getContext(Class<?> type) {\r\n        return adapter;\r\n    }\r\n}<\/pre>\n
Mapping Exceptions<\/h2>\n
The Bean Validation API reports error conditions using exceptions of type javax.validation.ValidationException<\/code> or any of its subclasses. Applications can supply custom exception mapping providers for any exception. A JAX-RS implementation MUST always use the provider whose generic type is the nearest superclass of the exception, with application-defined providers taking precedence over built-in providers.<\/p>\n
The exception mapper may look like:<\/p>\n
@Provider\r\npublic class ValidationExceptionMapper implements\r\n        ExceptionMapper<MethodConstraintViolationException> {\r\n\r\n    @Override\r\n    public Response toResponse(MethodConstraintViolationException ex) {\r\n        Map<String, String> errors = new HashMap<String, String>();\r\n        for (MethodConstraintViolation<?> methodConstraintViolation : ex\r\n                .getConstraintViolations()) {\r\n            errors.put(methodConstraintViolation.getParameterName(),\r\n                    methodConstraintViolation.getMessage());\r\n        }\r\n        return Response.status(Status.PRECONDITION_FAILED).entity(errors)\r\n                .build();\r\n    }\r\n}<\/pre>\n
The above example shows the implementation of an ExceptionMapper<\/code> that maps exceptions of type MethodConstraintViolationException<\/code>. This exception is thrown by Hibernate Validator implementation when the validation of one or more parameters of a method annotated with the @ValidateRequest<\/code> fails. This ensures that the client receives a formatted response instead of just the exception being propagated from the resource.<\/p>\n
Source code<\/h2>\n
The source code used for this post is available on GitHub<\/a>.<\/p>\n
Warn:<\/h4>\n
 rename the resource property file to have the file ValidationMessages.properties<\/code> (i.e., without any suffix) to map to the Locale<\/code> as returned by Locale.getDefault()<\/code>.<\/p>\n
Related Posts<\/strong><\/p>\n