<div dir="ltr"><div style>My personal preference would be #1 as well.</div><div style><br></div><div style>The docs don't say that non-existent nodes are allowed, so IMO it's ok to clarify now that it is not allowed. If code relied on adding non-existent nodes, it relied on behavior not guaranteed explicitly by the spec.</div>
<div style><br></div><div style>--Gunnar</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2013/2/8 Emmanuel Bernard <span dir="ltr"><<a href="mailto:emmanuel@hibernate.org" target="_blank">emmanuel@hibernate.org</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I had the same reserve as you but then reading the JavaDoc made me<br>
realize that the doc mentions properties so it is technically not as<br>
vague as I initially thought.<br>
<span class="HOEnZb"><font color="#888888"><br>
Emmanuel<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri 2013-02-08 11:48, Matt Benson wrote:<br>
> Personally my reason for eschewing option #1 is the possibility of breaking<br>
> existing code.<br>
><br>
> Matt<br>
><br>
><br>
> On Fri, Feb 8, 2013 at 11:22 AM, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>>wrote:<br>
><br>
> > At this time of day I do tend to like option #1 (ie making virtual nodes<br>
> > illegal). Otherwise my preferred option is #4<br>
> > (VirtualElementDescriptor).<br>
> ><br>
> > Out of curiosity for people not preferring option #1. What use case do<br>
> > you see in having virtual nodes?<br>
> ><br>
> > Emmanuel<br>
> ><br>
> > On Fri 2013-02-08 11:08, Matt Benson wrote:<br>
> > > Hmm, a third option for the elementClass of such a descriptor might be<br>
> > > Void.class.<br>
> > ><br>
> > > I prefer option #3, followed by #4.<br>
> > ><br>
> > > Matt<br>
> > ><br>
> > ><br>
> > > On Fri, Feb 8, 2013 at 5:17 AM, Gunnar Morling <<a href="mailto:gunnar@hibernate.org">gunnar@hibernate.org</a>><br>
> > wrote:<br>
> > ><br>
> > > > Hi experts,<br>
> > > ><br>
> > > > One of the remaining issues on our way to 1.1 is BVAL-336 [1], which is<br>
> > > > about what to return from Node#getElementDescriptor() for nodes added<br>
> > by<br>
> > > > the user via the ConstraintViolationBuilder API.<br>
> > > ><br>
> > > > Note that as per the spec only sub paths can be created by the user,<br>
> > i.e.<br>
> > > > user added nodes always represent properties but e.g. no methods or<br>
> > > > parameters. Based on that, it seems right to return the correct<br>
> > > > PropertyDescriptor in case a user adds a node for an existing property.<br>
> > > ><br>
> > > > Things get tricky though when nodes are added for non-existent<br>
> > properties.<br>
> > > > Emmanuel, Hardy and I identified the following options to address this<br>
> > > > situation:<br>
> > > ><br>
> > > > #1 Disallow adding non-existent nodes<br>
> > > ><br>
> > > > In case a user adds a node but no property with that names exist, an<br>
> > > > exception is thrown. The problem is elegantly avoided that way, but we<br>
> > > > might break some 1.0 user code (currently the spec is not really clear<br>
> > > > whether added nodes must exist or not).<br>
> > > ><br>
> > > > #2 return null from getElementDescriptor()<br>
> > > ><br>
> > > > When invoking getElementDescriptor() on a Node representing a<br>
> > non-existent<br>
> > > > property, null could be returned. This seems consistent (there is no<br>
> > > > element), but causes additional null checking when traversing a path.<br>
> > > ><br>
> > > > #3 return a PropertyDescriptor from getElementDescriptor()<br>
> > > ><br>
> > > > Since all user-added nodes represent properties, a PropertyDescriptor<br>
> > > > could be returned. hasConstraints() would return false,<br>
> > > > getConstraintDescriptors() the empty set etc. This would allow to<br>
> > handle<br>
> > > > all nodes and their descriptors uniformly when traversing a path.<br>
> > Question<br>
> > > > is what to return from PropertyDescriptor#getElementClass(). Options<br>
> > are to<br>
> > > > return null (signaling that the property is non-existent) or<br>
> > Object.class.<br>
> > > ><br>
> > > > #4 return a VirtualDescriptor from getElementDescriptor()<br>
> > > ><br>
> > > > We could create a new Kind, VIRTUAL, and an accompanying type<br>
> > > > VirtualDescriptor and return an instance of this. Behavior of the<br>
> > methods<br>
> > > > on the descriptor would be basically the same as in #3; getKind()<br>
> > returning<br>
> > > > Kind.VIRTUAL would allow for a very explicit checking whether the node<br>
> > > > exists or not.<br>
> > > ><br>
> > > > Any feedback on the options (ideally with arguments pro/con) or other<br>
> > > > alternatives are highly welcome. As life goes, Emmanuel's, Hardy's and<br>
> > my<br>
> > > > preferences are equally distributed between these options :)<br>
> > > ><br>
> > > > Thanks,<br>
> > > ><br>
> > > > --Gunnar<br>
> > > ><br>
> > > > [1] <a href="https://hibernate.onjira.com/browse/BVAL-336" target="_blank">https://hibernate.onjira.com/browse/BVAL-336</a><br>
> > > ><br>
> > > ><br>
> > > > _______________________________________________<br>
> > > > beanvalidation-dev mailing list<br>
> > > > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > beanvalidation-dev mailing list<br>
> > > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
> > _______________________________________________<br>
> > beanvalidation-dev mailing list<br>
> > <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> > <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
> ><br>
<br>
> _______________________________________________<br>
> beanvalidation-dev mailing list<br>
> <a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
<br>
_______________________________________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/beanvalidation-dev</a><br>
</div></div></blockquote></div><br></div>