Clarification regarding executable parameter/return value validation with group sequence redefinition
4:22 p.m.
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.
Matt
8:23 a.m.
Hi Matt,
On Tue, Apr 3, 2018 at 11:22 PM, Matt Benson <mbenson(a)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).
AFAIU the spec (
http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationproces...),
we should do:
- 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
11:06 a.m.
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/#constraintdeclarationvalidationproces...
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(a)gmail.com>:
Hi Matt,
On Tue, Apr 3, 2018 at 11:22 PM, Matt Benson <mbenson(a)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).
AFAIU the spec (http://beanvalidation.org/2.0/spec/#
constraintdeclarationvalidationprocess-validationroutine-
methodconstructorvalidation), we should do:
- 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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev
2456
days inactive
2459
days old
beanvalidation-dev@lists.jboss.org
2 comments
3 participants
participants (3)
-
Guillaume Smet -
Gunnar Morling -
Matt Benson