Hi Matt,

Yes, you're right, looks like our implementation has always been too permissive in this regard.

I think I'll make our implementation less permissive and fix the related TCK failures. I've implemented the check in HV and AFAICS you have found all the occurrences of this issue.

Will create a TCK issue and fix.

Guillaume

On Fri, Mar 16, 2018 at 8:18 PM, Matt Benson <mbenson@apache.org> wrote:

Similarly, ZeroConstraintValidator is declared as targeting @Negative.

On Mar 16, 2018 1:44 PM, "Matt Benson" <mbenson@apache.org> wrote:
On Mar 16, 2018 1:39 PM, "Matt Benson" <mbenson@apache.org> wrote:
FrenchAddressListContainer defines @FrenchZipcodeListContainer as a constraint that is validated by FrenchZipcodeConstraintValidator, but that class declares its constraint type parameter as @FrenchZipCode.

Same for FrenchZipcodeMixDirectAnnotationAndListContainer.

Because
that CV type does not override #init() this presumably works in the RI, and the spec is a bit vague on this point, but the interface definition describes type parameter A as "the annotation type handled by an implementation." The spec section ConstraintValidator resolution algorithm also correlates constraint A to the type parameters of the ConstraintValidators described in the resolution rules. Finally, I don't see anything under "What's new in 2.0" to indicate that this should be a legal constraint definition.

Can I get a ruling? :)

Matt

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev