<div dir="ltr"><div><div><div>Hi Matt,<br><br></div>I must admit that I don't see either what the problem should be.<br><br></div>The exception in HV is coming from:<br><a href="https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/groups/DefaultValidationOrder.java#L115">https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/groups/DefaultValidationOrder.java#L115</a><br></div><div>which didn't help me either to understand the issue as the method is quite cryptic.<br><br></div><div>Gunnar, any idea?<br><br>-- <br></div><div>Guillaume<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 28, 2018 at 5:30 PM, Matt Benson <span dir="ltr"><<a href="mailto:mbenson@apache.org" target="_blank">mbenson@apache.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
I'm having trouble recognizing what about TestEntity is supposed to<br>
trigger the GroupDefinitionException in<br>
#<wbr>testInvalidDefinitionOfDefault<wbr>SequenceInEntity() (for convenience,<br>
TestEntity is at [1]). The name of the test case suggests that the<br>
problem would be on TestEntity's own @GroupSequence, which aside from<br>
the order of the specified groups looks more or less like example 5.11<br>
near [2]. This suggests that the test case is imperfectly named (the<br>
name also seems misaligned with the accompanying @SpecAssertions) and<br>
the focus intends to be on the Complete group of which validation is<br>
attempted as the last activity of the test. Complete again looks<br>
topographically identical to example 5.10 in the previous section of<br>
the specification, which suggests that there is nothing inherently<br>
wrong with it. I can appreciate that, when taking TestEntity's<br>
redefinition of Default into account, Complete's sequence evaluates to<br>
[ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is<br>
clearly repetitive/redundant, but is it really to be considered<br>
cyclical? Is there any danger of infinite recursion and, if so, how?<br>
Is there some other problem I have missed here?<br>
<br>
Thanks,<br>
Matt<br>
<br>
[1] <a href="https://github.com/beanvalidation/beanvalidation-tck/blob/2.0/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/constraints/groups/groupsequence/TestEntity.java" rel="noreferrer" target="_blank">https://github.com/<wbr>beanvalidation/beanvalidation-<wbr>tck/blob/2.0/tests/src/main/<wbr>java/org/hibernate/<wbr>beanvalidation/tck/tests/<wbr>constraints/groups/<wbr>groupsequence/TestEntity.java</a><br>
[2] <a href="http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-groupsequence-redefiningdefaultgroup" rel="noreferrer" target="_blank">http://beanvalidation.org/2.0/<wbr>spec/#<wbr>constraintdeclarationvalidatio<wbr>nprocess-groupsequence-<wbr>redefiningdefaultgroup</a><br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
</blockquote></div><br></div>