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(a)apache.org> wrote:
Similarly, ZeroConstraintValidator is declared as targeting
@Negative.
On Mar 16, 2018 1:44 PM, "Matt Benson" <mbenson(a)apache.org> wrote:
> On Mar 16, 2018 1:39 PM, "Matt Benson" <mbenson(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev