<div dir="auto">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?<div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Matt</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mar 2, 2018 5:17 PM, "Matt Benson" <<a href="mailto:mbenson@apache.org">mbenson@apache.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Hi all,<div dir="auto">We are progressing on the Apache BVal implementation of BV 2.0 and I have a question. Taking as a concrete example, CascadingOnContainerElementsTe<wbr>st#cascading_on_container_<wbr>element_of_constructor_<wbr>parameter_is_applied(): </div><div dir="auto">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?</div><div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto">Matt</div></div>
</blockquote></div></div>