<div dir="ltr">Hi John,<div><br></div><div class="gmail_extra"><div class="gmail_quote">2016-05-19 12:32 GMT+02:00 John Hendrikx <span dir="ltr"><<a href="mailto:hjohn@xs4all.nl" target="_blank">hjohn@xs4all.nl</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi list,<br>
<br>
I'm currently trying to use JSR-303 validation inside a project with a<br>
complicated hierarchical structure that needs validation. What I find<br>
is that even in custom validators, the ConstraintValidatorContext is<br>
limiting me in what paths I can construct to indicate the proper error<br>
location.<br>
<br>
For example, when my custom rule is called as part of an iteration, and<br>
I want to add another level of iteration in the path like so:<br>
<br>
.addPropertyNode("y").inIterable().atKey("z")<br>
<br>
...it will overwrite the current iterable part of the path (allowing me<br>
to modify the "parent" context it looks like). So instead of getting:<br>
<br>
root["x"]["z"].y<br>
<br>
It removes the ["x"] and results in: root["z"].y which is clearly wrong.<br></blockquote><div><br></div><div>Currently, Bean Validation does not support cascaded validation of directly nested collections (say a Map<String, List<Long>>). So a violation of a constraint would never result in a path with two adjacent indexes (e.g. ["x"]["z"]) and it's not possible to create such path using the API either.</div><div><br></div><div>Could you share your bean types and the path you'd like to create? I suppose it involves such nested collection?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
If I add a dummy property node first, I can atleast see the root iterable:<br>
<br>
.addPropertyNode("$DUMMY$")<br>
.addPropertyNode("y").inIterable().atKey("z")<br>
<br>
Results in: root["x"].$DUMMY$["z"].y<br>
<br>
I also think it is a shame that nested Iterables are not supported.<br>
Hierarchical structures can have constructs like Map<String, List<X>><br>
and currently annotating X has no effect at all.<br></blockquote><div><br></div><div>I suppose the reason why it wasn't supported so far is the lack of control over the depth of cascaded validation.</div><div><br></div><div>Associations are only traversed if advised so by means of the @Valid annotation. So if you have a field "private List<Foo> foos" in your bean, there is a place to put the @Valid annotation to - the field definition.</div><div><br></div><div>But prior to Java 8, there would have been no satisfactory way to express this in case of nested collections. Now, with the advent of type-level annotations, there actually is: Map<String, @Valid List<Foo>>. So it's something we might consider in a BV 2.0 (which would be centered around migration to Java 8).</div><div><br></div><div>--Gunnar</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
--John<br>
<br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org" target="_blank">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</blockquote></div><br></div></div>