From a runtime perspective I can see how a single constraint violation can make sense as well.

Hi all, While working on a bug in the RI [1], I came across a TCK test which made me curious: ValidationRequirementTest#testClassLevelConstraints() [2]. The test is based on the following types: @SecurityCheck(groups = { Default.class, TightSecurity.class }) public interface Citizen { ... } @SecurityCheck(groups = Default.class) public abstract class Person implements Citizen { ... } public class Woman extends Person { ... } The test validates an instance of Woman which violates the @SecurityCheck constraint(s), but expects only one violation of the type @SecurityCheck. Since the constraint is given twice in the hierarchy (and with different member values), I'd have expected two violations here. I spoke to Emmanuel and we agree that the test seems wrong. The RI passes that test due to the bug mentioned above, but it'd be interesting to know how this is handled in the Apache implementation and why it's passing there. If no one objects, I'll adapt the TCK test to expect two @SecurityCheck violations. --Gunnar [1] https://hibernate.onjira.com/browse/HV-665 [2] https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/sr... _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev