Spring MVC and WebFlux handling of method validation errors #30644
Comments
rstoyanchev
added
in: web
Remove throwIfViolationsPresent and replace with static factory methods on MethodValidationException taking MethodValidationResult, which makes handling more explicit and allows choice of what exception to raise. Update MethodValidationResult to expose the target, the method, and forReturnValue flag, so the code handling an exception will have access to all details. See gh-30644
- Update method order - Do not automatically create MessageSource arguments in WebExchangeBindException constructor as they're more likely to be created via getDetailMessageArguments with MessageSource passed in. See gh-30644
This deprecates static methods in MethodArgumentNotValidException which is not a great vehicle for such methods. See gh-30644
To handle method validation errors in ResponseEntityExceptionHandler, MethodValidationException and associated types should not depend on Bean Validation. To that effect: 1. MethodValidationResult and ParameterValidationResult no longer make the underlying ConstraintViolation set available, and instead expose only the adapted validation errors (MessageSourceResolvable, Errors), analogous to what SpringValidatorAdapter does. And likewise MethodValidationException no longer extends ConstraintViolationException. 2. MethodValidationPostProcessor has a new property adaptConstraintViolations to decide whether to simply raise ConstraintViolationException, or otherwise to adapt the ConstraintViolations and raise MethodValidationException instead, with the former is the default for compatibility. 3. As a result, the MethodValidator contract can now expose methods that return MethodValidationResult, which provided more flexibility for handling, and it allows MethodValidationAdapter to implement MethodValidator directly. 4. Update Javadoc in method validation classes to reflect this shift, and use terminology consistent with Spring validation in classes without an explicit dependency on Bean Validation. See gh-30644
Extract classes from ~.validation.beanvalidation without a direct dependency on beanvalidation. See gh-30644
rstoyanchev
changed the title
rstoyanchev
changed the title
|
There is now a new The new exception is handled in By default for RFC 7807, the detail of |
|
From the documentation it's not clear - does this mean that the old |
The new
MethodValidationExceptionintroduced as part of #29825 needs to have default handling in Spring MVC and WebFlux, including RFC 7807 support, similar to the handling ofBindExceptionbut reflecting errors for multiple method parameters / or return value, represented withParameterValidationResultandParameterErrors.The text was updated successfully, but these errors were encountered: