[bv-dev] Validator#validateValue() with incompatible Object specified

[Matt Benson]

I would add that other recent discussions have borne out my
interpretation of the ExecutableValidator javadoc in saying that
incompatible parameter/return values should raise
IllegalArgumentExceptions. I would see this as a precedent in the case
of #validateValue().

Matt

On Fri, Mar 30, 2018 at 10:17 AM, Matt Benson <mbenson at apache.org> wrote:
> Hi, this comes from TCK
> ValidateValueTest#testValidIsNotHonoredValidateValue() . The test
> asserts that no constraint violations (and no exceptions) will be
> generated when specifying an Order as a proposed value for a property
> that includes a Set of Orders. The name of the test suggests to me,
> however, that the Validator is expected to transparently treat the
> Order as a single-element Set and simply show that validation of that
> set is not cascaded. Is this the case, or is the test actually showing
> that any incompatible value will be treated as raising no violations
> (and is therefore imperfectly named)? In either case, where does the
> specification dictate this behavior? Apache BVal has always raised an
> IllegalArgumentException if the specified value is not compatible, but
> its justification for having done so appears to be an artifact of an
> incorrect interpretation of the Javadoc of #validateValue(): "not a
> valid object property" was mistakenly applied to the "value" parameter
> instead of to the "propertyName" parameter as a careful reading
> reveals (IMO) is proper. But this exposes what seems to be an omission
> in the spec: what *is* the proper behavior when validation of an
> incompatible value is requested? And let's not forget the unclear
> nature of the test in question: is "order" a compatible value by
> virtue of being checked against a Set of its type (and, if so, why?),
> or is "order" an incompatible value that the Validator quietly
> abstains from checking at all?
>
> Thanks,
> Matt