spring-framework

Spring Framework

Tree: a481c7649f

rstoyanchev a481c7649f Refactor to prepare for method validation handling 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	3 years ago
..
src	Refactor to prepare for method validation handling	3 years ago
spring-web.gradle	Merge branch '6.0.x'	3 years ago

rstoyanchev a481c7649f Refactor to prepare for method validation handling

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

3 years ago

src

Refactor to prepare for method validation handling

3 years ago

spring-web.gradle

Merge branch '6.0.x'

3 years ago