Introduce support for method validation in Spring MVC and Spring WebFlux. This requires changes first at a lower level to enhance MethodValidationInterceptor infrastructure to adapt ConstraintViolations to MessageSourceResolvable errors, further aggregated into a BindingResult for cascaded violations on Object method parameters.

For the full scope of changes on this theme, see #30645.

Comment From: neroncap

Hi! I'm interesting in make some custom validations for the entire @RequestHeader, i was testing this issue and is not possible. It is planned to be included in further versions?

Comment From: rstoyanchev

Yes it is possible as indicated in the summary above, but the goal is to make it better integrated with Spring MVC and WebFlux, and easier to handle validation exceptions.

If you need help to make it work as it is currently, this is not the right place.

Comment From: rstoyanchev

This issue has been re-purposed to match the initial support in 6.1 M1, and the changes for that are now available in 6.1.0-SNAPSHOT. Below is a brief summary of the changes, ahead of a more detailed documentation update in #30643.

spring-context changes

MethodValidationInterceptor now delegates to MethodValidationAdapter, comparable to SpringValidatorAdapter but for method validation. It can return a MethodValidationResult with ConstraintViolations adapted to ParameterValidationResult each containing a list of MessageSourceResolvable errors, also grouped by method parameter, or raise MethodValidationException with the same results. A ParameterValidationResult may also be ParameterErrors, an Errors instance with cascaded violations adapted to field errors.

Spring MVC and WebFlux changes

Spring MVC and WebFlux have been updated to use MethodValidationAdater to apply method validation, and raise an MethodValidationException in case of validation errors. In order to make use of it, remove @Validated on the class level (i.e. opt out of AOP method validation), ensure jakarta.validation.Validator such as LocalValidatorFactoryBean is configured for use in Spring MVC or WebFlux config, and then it should apply to controller methods @Constraint annotations.

Controller methods that have only @Valid parameters, but otherwise no @Constraint annotations directly on the controller method, continue to be validated as they were before by the argument resolver, e.g. leading to MethodArgumentNotValidException. It's only when there are @Constraint annotations that method validation applies, and in that case the argument resolver will not validate and instead defer to method Bean Validation. BindingResult arguments work just the same with method validation. However, in case of additional constraint violations, the method cannot be invoked and MethodValidationException is thrown instead.

Comment From: rstoyanchev

I'm closing this issue as complete. Trying out the changes for 6.1 M1 with an actual application would be much appreciated. In case of feedback, please comment under the umbrella issue #30645, and we'll decide there how to proceed. Also subscribe to to watch the umbrella issue for further updates.