Uploaded image for project: 'RESTEasy'
  1. RESTEasy
  2. RESTEASY-1137

Bean Validation handler throws ResteasyViolationException instead of ConstraintViolationException (or a subclass of it)

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 3.0.12.Final
    • 3.0.9.Final
    • None
    • None
    • Hide

      Just try to have an ExceptionMapper for ConstraintViolationException, then add an endpoint that fails validation (Bean Validation) and then you will see that your ExceptionMapper is never called (because ResteasyViolationExceptionMapper gets it instead).

      Show
      Just try to have an ExceptionMapper for ConstraintViolationException, then add an endpoint that fails validation (Bean Validation) and then you will see that your ExceptionMapper is never called (because ResteasyViolationExceptionMapper gets it instead).
    • Compatibility/Configuration, User Experience
    • Workaround Exists
    • Hide

      Creates a ExceptionMapper that maps ResteasyViolationException, instead of ConstraintViolationException, and then make sure the JAX-RS rules regarding Bean Validation are respected. The problem with this workaround is that it adds a dependency to RESTEasy internal classes to the ExceptionMapper, which should be 100% JAX-RS based.

      Show
      Creates a ExceptionMapper that maps ResteasyViolationException, instead of ConstraintViolationException, and then make sure the JAX-RS rules regarding Bean Validation are respected. The problem with this workaround is that it adds a dependency to RESTEasy internal classes to the ExceptionMapper, which should be 100% JAX-RS based.

    Description

      In my application I would like to use a particular error entity in the response message whenever a Bean Validation constraint is violated. Currently RestEasy provides its on error entity, which is ViolationReport, but I want to use my own instead. According to the Bean Validation 1.1 spec, a ConstraintViolationException should be thrown by the validator whenever a constraint is violated, in a JAX-RS scenario one could handle them by having a ExceptionMapper mapping that exact exception. So, I did so, I added my own ExceptionMapper mapping ConstraintViolationException, but I realized that does not work as expected because RestEasy, as the bean validator (together with Hibernate Bean Validation implementation), never throws a ConstraintViolationException when a constraint is violated. Instead of that RestEasy throws its own proprietary exception, which is ResteasyViolationException. If ResteasyViolationException was a subclass of ConstraintViolationException then maybe my ExceptionMapper would work, and that is because there is not any exception mapper mapping ResteasyViolationException directly. RestEasy instead maps ValidationException (in ResteasyViolationExceptionMapper), and then figure outs the specific type of exception within it. JAX-RS states that a JAX-RS implementation must have an exception mapper for ValidationException, which is the super type of ConstraintViolationException. So, in that regard RestEasy is good. However, RestEasy violates Bean Validation when it throws its own exception type, instead of ConstraintViolationException, when a constraint is violated. And, because of that, I cannot deal with that by myself (and change the error entity as I want).

      Here is where the problem is: https://github.com/resteasy/Resteasy/blob/3.0.9.Final/jaxrs/providers/resteasy-validator-provider-11/src/main/java/org/jboss/resteasy/plugins/validation/GeneralValidatorImpl.java#L185

      Possible solution:
      That ResteasyViolationException could be a subclass of ConstraintViolationException.

      Attachments

        Issue Links

          Activity

            People

              rsigal@redhat.com Ronald Sigal
              fabiocarvalho_jira Fábio Carvalho (Inactive)
              Votes:
              3 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: