You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a spring controller is annotated with @org.springframework.validation.annotation.Validated, an endpoint argument is annotated with JSR 303 validation annotations (e.g. @Valid @NotBlank(message = "SOME_API_ERROR") @RequestParam(name = "fooParam") String fooParam), and a request comes in that violates those JSR 303 annotations, then yet another codepath is executed that ends up causing a javax.validation.ConstraintViolationException to be thrown.
We could handle this in backstopper with ClientDataValidationErrorHandlerListener, as the intention is the same and ClientDataValidationErrorHandlerListener is already setup to deal with the same ConstraintViolations that ConstraintViolationException contains. The result would have less info in the backstopper log message, but it would at least be handled properly instead of falling through to the generic 500 fallback handler.
NOTE: We'd need to make sure that the reusable JSR 303 convention tests cover this case (JSR 303 annotations on arbitrary method arguments) as well as the normal model object case.
The text was updated successfully, but these errors were encountered:
nicmunroe
changed the title
Support handling javax.validation.ConstraintViolationException
Support handling javax.validation.ConstraintViolationException
Mar 31, 2020
If a spring controller is annotated with
@org.springframework.validation.annotation.Validated
, an endpoint argument is annotated with JSR 303 validation annotations (e.g.@Valid @NotBlank(message = "SOME_API_ERROR") @RequestParam(name = "fooParam") String fooParam
), and a request comes in that violates those JSR 303 annotations, then yet another codepath is executed that ends up causing ajavax.validation.ConstraintViolationException
to be thrown.We could handle this in backstopper with
ClientDataValidationErrorHandlerListener
, as the intention is the same andClientDataValidationErrorHandlerListener
is already setup to deal with the sameConstraintViolation
s thatConstraintViolationException
contains. The result would have less info in the backstopper log message, but it would at least be handled properly instead of falling through to the generic 500 fallback handler.NOTE: We'd need to make sure that the reusable JSR 303 convention tests cover this case (JSR 303 annotations on arbitrary method arguments) as well as the normal model object case.
The text was updated successfully, but these errors were encountered: