Re: [bv-dev] Constraint given several times
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> 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