<div dir="ltr">Hey Matt,<div><br></div><div>I think you're giving too much bonus to the original authors of that test method and their well-meaning intentions ;) IMO the test is simply incorrect, for sure the intention was not that a single Order should implicitly be handled as a single-element Set<Order>.</div><div><br></div><div>The reason it doesn't fail with the RI is simply the fact that the RI is actually doing what the test seeks to ensure: @Valid isn't applied by validateValue(), i.e. the algorithm never gets to the point where it'd make use of the given value to recursively validate the constraints of the "orders" property. Were validateValue() be invoked for another property with a local constraint, a ClassCastException would occur when trying to feed the non-matching value to the ConstraintValidator.</div><div><br></div><div>Can you open a BVTCK issue for fixing this test? A Set<Order> containing the Order object should be passed to validateValue().</div><div><br></div><div>Regarding the expected behaviour, indeed the spec doesn't mandate something specifically. I don't think it's a big problem, though, because the non-matching value will cause an exception in one or another way anyways. Theoretically we could mandate a specific IllegalArgumentException in that case, but that'd require an instanceof check up front, and I don't think I wanted to impose this to implementations. I'd rather leave it as is; of course an implementation is free to do such check, as Apache Bval was doing it.</div><div><br></div><div>As far as ExecutableValidator is concerned, there it says to raise an exception if "parameters don't match with each other". This leaves some leeway on the exact checks to implement and also here I'd prefer to keep it that way, instead of enforcing potentially costly checks at the spec level.</div><div><br></div><div>--Gunnar</div><div class="gmail_extra"><br><div class="gmail_quote">2018-03-30 17:33 GMT+02:00 Matt Benson <span dir="ltr"><<a href="mailto:mbenson@apache.org" target="_blank">mbenson@apache.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would add that other recent discussions have borne out my<br>
interpretation of the ExecutableValidator javadoc in saying that<br>
incompatible parameter/return values should raise<br>
IllegalArgumentExceptions. I would see this as a precedent in the case<br>
of #validateValue().<br>
<span class="HOEnZb"><font color="#888888"><br>
Matt<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Mar 30, 2018 at 10:17 AM, Matt Benson <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>> wrote:<br>
> Hi, this comes from TCK<br>
> ValidateValueTest#<wbr>testValidIsNotHonoredValidateV<wbr>alue() . The test<br>
> asserts that no constraint violations (and no exceptions) will be<br>
> generated when specifying an Order as a proposed value for a property<br>
> that includes a Set of Orders. The name of the test suggests to me,<br>
> however, that the Validator is expected to transparently treat the<br>
> Order as a single-element Set and simply show that validation of that<br>
> set is not cascaded. Is this the case, or is the test actually showing<br>
> that any incompatible value will be treated as raising no violations<br>
> (and is therefore imperfectly named)? In either case, where does the<br>
> specification dictate this behavior? Apache BVal has always raised an<br>
> IllegalArgumentException if the specified value is not compatible, but<br>
> its justification for having done so appears to be an artifact of an<br>
> incorrect interpretation of the Javadoc of #validateValue(): "not a<br>
> valid object property" was mistakenly applied to the "value" parameter<br>
> instead of to the "propertyName" parameter as a careful reading<br>
> reveals (IMO) is proper. But this exposes what seems to be an omission<br>
> in the spec: what *is* the proper behavior when validation of an<br>
> incompatible value is requested? And let's not forget the unclear<br>
> nature of the test in question: is "order" a compatible value by<br>
> virtue of being checked against a Set of its type (and, if so, why?),<br>
> or is "order" an incompatible value that the Validator quietly<br>
> abstains from checking at all?<br>
><br>
> Thanks,<br>
> Matt<br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div></div>