`HandlerMethodValidator` should support simple Cross-Parameter constraints about spring-framework

[jmax01]

Example added.

[rstoyanchev]

Thanks for the report. It would help a lot if you could provide snippets, or a small sample to experiment with.

[jmax01]

Thanks for the report. It would help a lot if you could provide snippets, or a small sample to experiment with.

I will post one later today.

Note that it will simply be a GetMapping method with 2 arguments that have constraints and a method level cross-parameter constraint whose isValid method always returns false.

[jmax01]

Workaround added.

[rstoyanchev]

Thanks for the sample.

For cross-parameter validation, the property path has the method node and then a cross-parameter node, but no other useful info on which parameters were validated or what the argument values were. Is that because the ConstraintValidator implementation is empty and just returns false? In other words is the validator able to and expected to update the context in a way that would expose more information in the resulting ConstraintViolation?

At any rate, a cross-parameter violation does not fit into the current model where a MethodValidationResult holds value results (violations of parameter constraints) or bean results (violations of nested object field constraints) both of which aggregate violations for a specific method parameter.

We could create a CrossParameterValidationResult that holds basic MessageSourceResolvable's prepared from the annotation name and the target class/method name, but I'm not sure if we can get anything more useful than that.

[jmax01]

I 100% agree that the current model doesn't fit.

The challenge in my mind is, at the end of the day, we need a single exception type that holds all method argument ConstraintViolations.

This exception type should contain violations of cross-parameter constraints and violations of individual arguments annotated with @Constraints or annotated with @Valid.

This would provide a complete solution for handling pre-method execution ConstraintViolations.

The MethodValidationResult and MethodValidationException names imply this functionality but currently require a lot of finagling to achieve it (ConstraintViolation manipulation in the case of cross-parameter constraints and the requirement to have additional @Constraints on the method for '@Valid` to be evaluated ).

Thanks for the sample.

For cross-parameter validation, the property path has the method node and then a cross-parameter node, but no other useful info on which parameters were validated or what the argument values were. Is that because the ConstraintValidator implementation is empty and just returns false? In other words, is the validator able to and expected to update the context in a way that would expose more information in the resulting ConstraintViolation?

At any rate, a cross-parameter violation does not fit into the current model where a MethodValidationResult holds value results (violations of parameter constraints) or bean results (violations of nested object field constraints) both of which aggregate violations for a specific method parameter.

We could create a CrossParameterValidationResult that holds basic MessageSourceResolvable's prepared from the annotation name and the target class/method name, but I'm not sure if we can get anything more useful than that.

[rstoyanchev]

the requirement to have additional @Constraints on the method for '@Valid` to be evaluated

I'm not sure what you mean. @Valid does not need anything else to trigger validation. It is true that if there are no @Constraints at all on method parameter, then it is validated on its own, raising MethodArgumentNotValidException, which is designed to be very similar to MethodValidationException and one can be adapted to the other. This is covered in the docs.

You do raise a point that with method level @Constraints, currently we assume they are for the return value, but it may be for cross-parameter validation. If this is what you are pointing out, then yes, we do need to update that.

ConstraintViolation manipulation in the case of cross-parameter constraints

For the rest, I proposed above a CrossParameterValidationResult held in MethodValidationResult in addition to ParameterValidationResults. However, I don't see a way to tell which specific parameters were involved, which means we can't aggregate cross-parameter violations in any way. So we might just expose a list of MessageSourceResolvables from MethodValidationResult that represent cross-param violations.