Affects: 6.1.x or higher


I have been migrating from AOP method validation via @Validated to Spring MVC built-in method validation, added in 6.1, for queryString variable with @Constraint annotations on my controller. I have noticed that there is no simple way to extract the cause of newly thrown HandlerMethodValidationException when replacing old handler method for ConstraintViolationException.

Despite the fact that document describes HandlerMethodValidationException is "very similar" to the good old MethodArgumentNotValidException, it lacks of the way to extract the source, ConstraintViolation while with MethodArgumentNotValidException from validating @RequestBody, you could get simply get it through ObjectError or FieldError in the exception.

HandlerMethodValidationException from validating queryString only contains DefaultMessageSourceResolvable. I think if it contains some kind of "ViolationParameterError" or something just like MethodArgumentNotValidException, it would be great to have unifying handler method for any validation exceptions from controller layer.

Comment From: rstoyanchev

For ParameterErrors (nested validation errors), you get FieldErrors adapted from ConstraintViolation in exactly the same way as with MethodArgumentNotValidException. For example this works:

ex.getBeanResults().get(0).getAllErrors().get(0).unwrap(ConstraintViolation.class)

Or if using the Visitor on HandlerMethodException, you can do similar to the above but with a shorter path since you have the specific ParameterErrors instance:

parameterErrors.getAllErrors().get(0).unwrap(ConstraintViolation.class);

It's true, however that for all others (violations directly on method parameters) we expose only a MessageSourceResolvable.

We could maybe expose a lookup method on ParameterValidationResult that takes aMessageSourceResolvable and returns the ConstraintViolation, or add a getConstraintViolations() method that returns List<ConstraingViolation> in the same order as getResolvableErrors().

Comment From: rstoyanchev

There is an now an unwrap(MessageSourceResolvable error, Class<?> sourceType) method on ParameterValidationResult similar to the one on ObjectError.