Hi all, I'm having trouble recognizing what about TestEntity is supposed to trigger the GroupDefinitionException in #testInvalidDefinitionOfDefaultSequenceInEntity() (for convenience, TestEntity is at [1]). The name of the test case suggests that the problem would be on TestEntity's own @GroupSequence, which aside from the order of the specified groups looks more or less like example 5.11 near [2]. This suggests that the test case is imperfectly named (the name also seems misaligned with the accompanying @SpecAssertions) and the focus intends to be on the Complete group of which validation is attempted as the last activity of the test. Complete again looks topographically identical to example 5.10 in the previous section of the specification, which suggests that there is nothing inherently wrong with it. I can appreciate that, when taking TestEntity's redefinition of Default into account, Complete's sequence evaluates to [ TimeConsumingChecks, TestEntity, TimeConsumingChecks]. This is clearly repetitive/redundant, but is it really to be considered cyclical? Is there any danger of infinite recursion and, if so, how? Is there some other problem I have missed here? Thanks, Matt [1] https://github.com/beanvalidation/beanvalidation- tck/blob/2.0/tests/src/main/java/org/hibernate/beanvalidation/tck/tests/ constraints/groups/groupsequence/TestEntity.java [2] http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidatio nprocess-groupsequence-redefiningdefaultgroup _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

I.e. you have a cycle between TimeConsumingChecks in the Complete group sequence (once the re-defined default group sequence has been expanded). In that light the method name is indeed a bit misleading, and I wonder whether we have a simpler test in the TCK which just asserts that @GroupSequence({ TimeConsumingChecks, TestEntity, TimeConsumingChecks }) triggers the exception. I didn't check the assignments of the assertion ids.

If not that, what else would you consider as a cycle in the context of group sequence definitions then? This sequence definition here says: "validate TimeConsumingChecks *before* TestEntity" and "validate TimeConsumingChecks *after* TestEntity", aborting after the first group found with violated constraints. There's no way to implement this.

I think the issue is that Guillaume and I are viewing the group sequence as a simple, ordered set of instructions, whereas you, Gunnar, are viewing it more as a dependency graph. I will confess that I am having difficulty rising to your challenge of providing an example that would be indisputably cyclical without having sat down at a computer or with pen and paper to postulate one. In the meantime I wonder if there is anything in the spec to encourage this "dependency graph" interpretation of what a group sequence is. Having said that, it is probably true that a user who had set up such a situation as this had done so unintentionally. OTOH, the second attempt at validating the time consuming checks would be a noop in any case.

Gunnar is expressing the intent correctly as far as memory serves. I did want a *non ambiguous* partiall order behavior in sequences. The example makes it ambiguous. But groups and group sequences are probably in the top 3 of the most complicated piece of specification in the whole Java EE ecosystem. Not proud of it but it works as expected for all real life code of which thus test is not a representative :) Emmanuel On 30 Mar 2018, at 15:48, Matt Benson <mbenson(a)apache.org&gt; wrote: I think the issue is that Guillaume and I are viewing the group sequence as a simple, ordered set of instructions, whereas you, Gunnar, are viewing it more as a dependency graph. I will confess that I am having difficulty rising to your challenge of providing an example that would be indisputably cyclical without having sat down at a computer or with pen and paper to postulate one. In the meantime I wonder if there is anything in the spec to encourage this "dependency graph" interpretation of what a group sequence is. Having said that, it is probably true that a user who had set up such a situation as this had done so unintentionally. OTOH, the second attempt at validating the time consuming checks would be a noop in any case. Matt On Fri, Mar 30, 2018, 8:36 AM Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: > > On Fri, Mar 30, 2018 at 2:57 PM, Gunnar Morling <gunnar(a)hibernate.org&gt; > wrote: >> >> If not that, what else would you consider as a cycle in the context of >> group sequence definitions then? >> >> This sequence definition here says: "validate TimeConsumingChecks >> *before* TestEntity" and "validate TimeConsumingChecks *after* TestEntity", >> aborting after the first group found with violated constraints. There's no >> way to implement this. > > > Not saying it makes sense but I could imagine validating > TimeConsumingChecks then TestEntity then TimeConsumingChecks again. > > If we consider this a cyclic dependency, then the test is indeed valid. > The name is not very descriptive but it's not wrong either. > > -- > Guillaume > _______________________________________________ > 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 _______________________________________________ beanvalidation-dev mailing list beanvalidation-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/beanvalidation-dev