[bv-dev] Clarification regarding executable parameter/return value validation with group sequence redefinition

Gunnar Morling gunnar at hibernate.org
Fri Apr 6 12:06:59 EDT 2018


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 at gmail.com>:

> Hi Matt,
>
> On Tue, Apr 3, 2018 at 11:22 PM, Matt Benson <mbenson at 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 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/20180406/1071d219/attachment.html 


More information about the beanvalidation-dev mailing list