Is there something which needs to be discussed with the EG?
I'm not sure, so far nothing is said about group sequence re-definitions with respect to method validation in the spec. I think some more clarification is needed here.
Maybe we could start to define a couple of unit tests and see what happens. This would help to nail down the expectations for group sequence re-definitions and method validation.
+1. Actually this group sequence re-definition thing is the part of the spec I'm having the hardest time with. In particular the behavior with re-defined sequences in sub-types. Writing tests is a good idea.
Group sequence re-definition really only occurs for cascaded parameters/return values, right?
Does it? I think also constraints directly assigned to a parameter/return value could be put into a group and thus be subject to a re-defined default group sequence, e.g.:
@GroupSequence({SomeGroup.class, Foo.class})
public class Foo {
void bar(@NotNull(groups=SomeGroup.class} bar) { ... }
void baz(@NotNull(groups=OtherGroup.class} baz) { ... }
}
Here I think only the constraint at the bar() method should be evaluated when performing a method validation for the default group.
I'm not sure, so far nothing is said about group sequence re-definitions with respect to method validation in the spec. I think some more clarification is needed here.
+1. Actually this group sequence re-definition thing is the part of the spec I'm having the hardest time with. In particular the behavior with re-defined sequences in sub-types. Writing tests is a good idea.
Does it? I think also constraints directly assigned to a parameter/return value could be put into a group and thus be subject to a re-defined default group sequence, e.g.:
@GroupSequence({SomeGroup.class, Foo.class}) public class Foo { void bar(@NotNull(groups=SomeGroup.class} bar) { ... } void baz(@NotNull(groups=OtherGroup.class} baz) { ... } }
Here I think only the constraint at the bar() method should be evaluated when performing a method validation for the default group.