[bv-dev] TCK expects tolerance of mismatched constraint and constraint validator

[Guillaume Smet]

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 at apache.org> wrote:

> Similarly, ZeroConstraintValidator is declared as targeting @Negative.
>
> On Mar 16, 2018 1:44 PM, "Matt Benson" <mbenson at apache.org> wrote:
>
>> On Mar 16, 2018 1:39 PM, "Matt Benson" <mbenson at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180319/3f1f1bac/attachment.html