[bv-dev] Questions on TCK SequenceResolutionTest

[Gunnar Morling]

> 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 at 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 at 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/#constraintdeclarationval
>> idationprocess-groupsequence-redefiningdefaultgroup
>> _______________________________________________
>> beanvalidation-dev mailing list
>> beanvalidation-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>>
>
>
> _______________________________________________
> beanvalidation-dev mailing list
> beanvalidation-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/beanvalidation-dev/attachments/20180330/fd038cb3/attachment-0001.html