Custom constraint causes "target cannot be inferred" exception when used for return value

Description

I have created a CustomMin constraint, which is an exact copy of javax.validation.constraints.Min as follows:

CustomMin.java

I am trying to validate parameters using the ExecutableValidator as follows:

TestValidator.java

The above is causing the following exception:

Environment

I am using hibernate validator 5.0.2 with Java 1.6.0_45-b06-451 on OSX 10.9.1.

Activity

Show:
George Fountopoulos
January 2, 2014, 12:18 PM

Note that if I replace @CustomMin(1) with @Min(1) in TestValidator.java it works fine.

Hardy Ferentschik
January 2, 2014, 8:46 PM

I guess the question is how your ConstraintValidator implementations look like. The implementations for the built-in Min constraints does not provide any cross parameter constraint validator implementations. For this reason the resolution what type of constraint (return value vs cross parameter) is non ambiguous. What do you target with your implementations? Do you have multiple? Do you make use of @SupportedValidationTarget?

George Fountopoulos
January 3, 2014, 12:23 PM

I intent using it as Compound constraint without validator implementation. Shouldn't the target in this case be inferred by the declaration? I do not make use of @SupportedValidationTarget because I do not provide any validator implementation for the constraint.

For example, if I replace the above CustomMin.java with the below CompoundMin.java I still get the same "target cannot be inferred" exception:

CompoundMin.java

Gunnar Morling
January 6, 2014, 9:23 AM
Edited

Hey, I think that's basically a duplicate of HV-726. As suggested by George, we are considering in that issue to derive the target from the composing constraints in case of purely composed constraints. An alternative suggested by Emmanuel was to allow the supported target to be given via @SupportedValidationTarget on the composing constraint definition in the case of a purely composed constraint.

As a workaround, you could just implement a no-op validator which always returns true from isValid() and annotate this validator with @SupportedValidationTarget to specify the supported target. The actual validation would still happen via the composing constraints in this case.

Gunnar Morling
April 22, 2015, 9:13 AM

Assignee

Gunnar Morling

Reporter

George Fountopoulos

Labels

Feedback Requested

None

Feedback Requested By

None

backPortable

None

Suitable for new contributors

Yes, likely

Pull Request

None

backportDecision

None

backportReEvaluate

None

Components

Fix versions

Affects versions

Priority

Major
Configure