<div dir="ltr">Hi,<div><br></div><div style>As discussed with Hardy the test is updated now to expect two violations.</div><div style><br></div><div style>Btw. we released Beta3 of the TCK yesterday [1] (including this change). So for those of you working on implementations of the spec it's the perfect time to checkout tests new tests and let us know if any of the tests are problematic etc.</div>
<div style><br></div><div style>We've basically assertions for all new functionality added in 1.1, with ~83% of these assertions already covered by tests (as measured with the coverage tool [2]).</div><div style><br></div>
<div style>Speaking about tooling, the audit.xml file containing all the assertions is generated now from the actual spec text using an XSL transformation. That way wording and structure of the TCK match 100% with the spec, but this change caused some re-arrangement of existing tests. This should have no influence on implementations, the actual tests are the same as before.</div>
<div style><br></div><div style>--Gunnar</div><div style><br></div><div style>[1] <a href="http://in.relation.to/Bloggers/InUnisonReleaseOfBeanValidationTCK110Beta3AndHibernateValidator500Beta1">http://in.relation.to/Bloggers/InUnisonReleaseOfBeanValidationTCK110Beta3AndHibernateValidator500Beta1</a></div>
<div style><br></div><div style>[2] <a href="http://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/#d0e438">http://docs.jboss.org/hibernate/beanvalidation/tck/1.1/reference/html_single/#d0e438</a></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/6 Hardy Ferentschik <span dir="ltr"><<a href="mailto:hardy@hibernate.org" target="_blank">hardy@hibernate.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
>From a runtime perspective I can see how a single constraint violation can make sense as well.<br>
We have a single instance of Woman validating the Default group. I can see how only one violation<br>
makes sense. The problem is the metadata. It would not be defined which constraint meta data you<br>
would get when inspecting the constraint violation. The one from Citizen or the one from Person.<br>
<br>
I am wondering whether the group parameter contributes to constraint equality or whether it should be<br>
excluded.<br>
<br>
If there are no other objections I am ok with updating this behaviour and test, but I can see the merit in<br>
the current behaviour as well.<br>
<br>
--Hardy<br>
<div><div class="h5"><br>
<br>
On 5 Jan 2013, at 4:42 PM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>> wrote:<br>
<br>
> Hi all,<br>
><br>
> 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:<br>
><br>
> @SecurityCheck(groups = { Default.class, TightSecurity.class })<br>
> public interface Citizen { ... }<br>
><br>
> @SecurityCheck(groups = Default.class)<br>
> public abstract class Person implements Citizen { ... }<br>
><br>
> public class Woman extends Person { ... }<br>
><br>
> The test validates an instance of Woman which violates the @SecurityCheck constraint(s), but expects only one violation of the type @SecurityCheck.<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> If no one objects, I'll adapt the TCK test to expect two @SecurityCheck violations.<br>
><br>
> --Gunnar<br>
><br>
> [1] <a href="https://hibernate.onjira.com/browse/HV-665" target="_blank">https://hibernate.onjira.com/browse/HV-665</a><br>
> [2] <a href="https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/constraints/application/ValidationRequirementTest.java#L60" target="_blank">https://github.com/beanvalidation/beanvalidation-tck/blob/master/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/constraints/application/ValidationRequirementTest.java#L60</a><br>
</div></div>> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div><br></div></div>