bval-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GianMaria Romanato (JIRA)" <>
Subject [jira] [Created] (BVAL-158) ExecutableValidator invokes method if it looks like a getter
Date Thu, 21 Jun 2018 15:14:00 GMT
GianMaria Romanato created BVAL-158:

             Summary: ExecutableValidator invokes method if it looks like a getter
                 Key: BVAL-158
             Project: BVal
          Issue Type: Bug
          Components: method validation
    Affects Versions: 1.1.2
            Reporter: GianMaria Romanato

When ExecutableValidator is used to validate the input parameters of a method that:
 * has no input parameters
 * returns a value that is annotated @Valid
 * is named  "get"-something

the implementation of the validator seems to assume that the method is a getter for a property,
and even if the user code has only invoked ExecutableValidator.validateParameters() the validator
decides to apply cascaded validation and invokes the given method to obtain the return value
and validate it.

This behaviour can be demonstrated by the following snippet which results in the RuntimeException
being raised by the validation.
public class BValTest {
    public static void main(String[] args) throws NoSuchMethodException, SecurityException
        ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
        javax.validation.Validator validator = factory.getValidator();
        ExecutableValidator methodValidator = validator.forExecutables();
        BValTest p = new BValTest();
        Method method = p.getClass().getDeclaredMethod("getAll", null);
        Set<ConstraintViolation<BValTest>> result = methodValidator.validateParameters(p,
method, new Object[0]);
    public List<Object> getAll() {
        throw new RuntimeException("Gotcha");

This is especially problematic for AOP interceptors: if an AOP interceptor is used to support
bean validation on annotated methods, in the above scenario the AOP interceptor will pass
the intercepted method to BVal, which will then invoke such method and therefore the AOP interceptor
again, which in turn will invoke BVal again, resulting in an endless invocation call stack
and ultimately in a stack overflow error.

I have read the specification and I could not find any reference to the fact that validateParameters()
should apply cascaded validation to the return value of the method, and  invoke the method
to achieve this.

This problem only appears if the method looks like a getter for a property. Renaming getAll()
in the above snippet to something different e.g. doAll() removes the problem.

There are therefore two workarounds for this issue:
 * work around 1: don't call validateParameters() if the method has no input parameter
 * work around 2: make sure your methods with no-args do not start with "get*" so that they
are not confused with getters.


This message was sent by Atlassian JIRA

View raw message