[bv-dev] Value extractors and the TCK

[Gunnar Morling]

Hi Matt,

Great to hear that you're progressing with your implementation!

> Can anyone confirm this interpretation, or better yet show it to me in
the spec?

Yes, you're on the right path ;)

There are two separate aspects here: a) invocation of value extractors in
order to obtain a container's elements and b) rules for constructing
property paths.

On a), value extractors are called to cascade into containers when
processing @Valid (where 2.0 generalizes the 1.1 notion of cascaded
validation, see [1]) and when processing container element constraints
(e.g. List<@Positive Integer>).

On b), the rules are described in [2]. Specifically:

    "If a parameter ... of a ... constructor is traversed:
        * a ... ConstructorNode object is added to the Path
        * ... a ParameterNode object is added to the Path
        * if the parameter ... is a List or an array, the following
          Node object added contains the index value in getIndex().

And:

    "For a container element constraint:
        * if the corresponding value extractor has specified a node name
when
          calling one of the receiver methods, a ContainerElementNode object
          with that name is added to the Path"

I.e. you'll see path nodes with the name returned by a value extractor in
the second case, but not the first. One more case where you will see a node
with that name, is nested cascaded validation (Map<String, List<@Valid
Address>>).

And finally, no node will be appended if the extractor doesn't provide a
node name. This is to suppress addition of a node for wrapper-style
containers such as Optional<@Positive Integer> or @Positive OptionalInt.

Hth,

--Gunnar

[1]
http://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-requirements-graphvalidation
[2] http://beanvalidation.org/2.0/spec/#validationapi-constraintviolation


2018-03-03 0:27 GMT+01:00 Matt Benson <mbenson at apache.org>:

> Hmm, I think I am seeing the difference. The value extractor node would
> show up for constraints validated directly against the container element,
> then I'm extrapolating that legacy containers would cascade validation as
> prior to BV 2 and thus elide this node. Can anyone confirm this
> interpretation, or better yet show it to me in the spec?
>
> Thanks,
> Matt
>
> On Mar 2, 2018 5:17 PM, "Matt Benson" <mbenson at apache.org> wrote:
>
>> Hi all,
>> We are progressing on the Apache BVal implementation of BV 2.0 and I have
>> a question. Taking as a concrete example, CascadingOnContainerElementsTe
>> st#cascading_on_container_element_of_constructor_parameter_is_applied():
>> BarService#<init>(List) annotates the Bar element type of the List
>> parameter, yet the unit test appears to treat this identically to a BV < 2
>> @Valid List, from the perspective of the expected path nodes. I can perhaps
>> accept that, but if that is what is expected by the spec (I don't find this
>> explicitly stated, but that may be my problem), when would the built in
>> list element value extractor be expected to kick in and supply the <list
>> element> node as stated in the spec, and/or when would said node be
>> expected to show up in a path?
>>
>> Thanks,
>> Matt
>>
>
> _______________________________________________
> 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/20180303/11fd09c7/attachment.html