Hi,

I believe that the test is correct, since the redefinition of default group sequences is local to the type hosting @GroupSequence, i.e. it's not propagated to associated elements (referenced properties, method parameters or return values). Please check out http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-validationroutine-graphvalidation and examples 5.29 - 5.32 which show a comparable situation (only for regular bean validation, not for method validation).

For OrderServiceWithRedefinedDefaultGroupSequence this means, that @GroupSequence({ Basic.class, OrderServiceWithRedefinedDefaultGroupSequence.class }) only applies to the constraints hosted on the methods of that class itself, but not to the constraints on the Item class as we traverse to it. As the default group is requested, validation of the constraints on OrderServiceWithRedefinedDefaultGroupSequence will stop after the Basic group, but for Item, all constraints of its default group (which isn't re-defined) are validated. Hence the @Size constraint is expected within the set of constraint violations.

--Gunnar


2018-04-04 15:23 GMT+02:00 Guillaume Smet <guillaume.smet@gmail.com>:
Hi Matt,

On Tue, Apr 3, 2018 at 11:22 PM, Matt Benson <mbenson@apache.org> wrote:
Hello, I am encountering failures on three tests from
MethodValidationTest in the TCK:

* #constructorParameterValidationWithRedefinedDefaultGroupSequence()
* #methodParameterValidationWithRedefinedDefaultGroupSequence()
* #methodReturnValueValidationWithRedefinedDefaultGroupSequence()

In each case I am failing to pick up a @Size constraint from the
Default group of an Item parameter or Order return value. However, due
to the group sequence redefinition of Basic, Default on the bean class
in question I am confused as to why I am expected to pick up the
failures from the Default group after having encountered a @NotNull
constraint violation in the Basic group. Thanks for any help here.

I would tend to agree with you. (The fact that Item also has a different Basic group does not help to understand the issue though).

- For each group
  - For each parameter, apply constraints
  - For each cascading parameter, cascade

This in no particular order if there is no group sequence. If a group sequence is defined, we should exit as soon as we have a violation for a given group

Currently, the RI does:
- For each group
  - For each parameter, apply constraints
    - exit as soon as I have a constraint if group sequence
- For each group
  - For each cascading parameter, cascade
    - exit as soon as I have a constraint if group sequence

In the aforementioned case:
1/ we apply the Basic constraints for the parameter constraints
2/ we exit as soon as we have a violation, we don't validate the Default group
3/ we apply cascading
   - no violation for the Basic group
   - we validate the default group
   - we exit as soon as we have a violation

As per spec, I think we should exit just after 2/

Gunnar, any insights?

--
Guillaume

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