> 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?

I think this is key here. In 5.4.2, the spec says:

> Groups defining a sequence and groups composing a sequence must not be involved in a cyclic dependency:
> * either directly or indirectly
> * either through cascaded sequence definitions or group inheritance
> If a group containing such a circularity is evaluated, a GroupDefinitionException is raised.

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.

--Gunnar

2018-03-29 11:18 GMT+02:00 Guillaume Smet <guillaume.smet@gmail.com>:

Hi Matt,

I must admit that I don't see either what the problem should be.

The exception in HV is coming from:
https://github.com/hibernate/hibernate-validator/blob/master/engine/src/main/java/org/hibernate/validator/internal/engine/groups/DefaultValidationOrder.java#L115
which didn't help me either to understand the issue as the method is quite cryptic.

Gunnar, any idea?

--
Guillaume

On Wed, Mar 28, 2018 at 5:30 PM, Matt Benson <mbenson@apache.org> wrote:
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/#constraintdeclarationvalidationprocess-groupsequence-redefiningdefaultgroup
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev

_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev