Hi, >From a runtime perspective I can see how a single constraint violation can make sense as well. We have a single instance of Woman validating the Default group. I can see how only one violation makes sense. The problem is the metadata. It would not be defined which constraint meta data you would get when inspecting the constraint violation. The one from Citizen or the one from Person. I am wondering whether the group parameter contributes to constraint equality or whether it should be excluded. If there are no other objections I am ok with updating this behaviour and test, but I can see the merit in the current behaviour as well. --Hardy On 5 Jan 2013, at 4:42 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev