<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Here is the new proposal<div><br></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; font-size: 14px; "><div class="titlepage" style="font-family: sans-serif; font-size: 14px; "><div style="font-family: sans-serif; font-size: 14px; "><div style="font-family: sans-serif; font-size: 14px; "><h3 class="title" style="font-family: sans-serif; color: rgb(0, 51, 153); font-size: 120%; margin-top: 10px; padding-top: 5px; font-weight: bold; ">3.5.1. Object graph validation</h3></div></div><div style="font-family: sans-serif; font-size: 14px; "></div></div><p style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 0); ">The <tt class="classname" style="font-size: 100%; color: rgb(17, 17, 17); font-family: monospace; ">@Valid</tt> annotation on a given association (i.e. object reference or collection / array of objects), dictates the Bean Validator implementation to apply recursively the bean validation routine on (each of) the associated object(s). This mechanism is recursive: an associated object can itself contain cascaded references.</p><p style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 0); ">Null references are ignored.</p><p style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 0); ">To prevent infinite loops, the Bean Validation implementation must ignore the cascading operation if the associated object instance has already been validated in the current navigation path (starting from the root object).</p><div class="example" style="font-family: sans-serif; font-size: 14px; "><a name="d0e1925" style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 204); "></a><p class="title" style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 0); margin-top: 10px; padding-top: 5px; font-weight: bold; "><b style="font-family: sans-serif; font-size: 14px; ">Example 3.8. Object graph limits</b></p><pre class="programlisting" style="font-size: 100%; padding-top: 5px; padding-right: 5px; padding-bottom: 5px; padding-left: 5px; border-top-style: solid; border-right-style: solid; border-bottom-style: solid; border-left-style: solid; border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; border-left-width: 1px; border-top-color: rgb(204, 204, 204); border-right-color: rgb(204, 204, 204); border-bottom-color: rgb(204, 204, 204); border-left-color: rgb(204, 204, 204); background-color: rgb(244, 244, 244); font-family: monospace; width: auto; ">#assuming the following object graph
Order -(lines)-> Orderline1
Order -(lines)-> Orderline2
Orderline1 -(order)-> Order
Orderline2 -(order)-> Order
Order -(customer)-> User
Order -(shippingAddress)-> Address1
Order -(billingAddress)-> Address2
Address1 -(inhabitant)-> User
Address2 -(inhabitant)-> User
User -(addresses)-> Address1
User -(addresses)-> Address2
#validation branches are as followed
Order -(lines)-> Orderline1
- order is ignored: Order is already present in the branch
Order -(lines)-> Orderline2
- order is ignored: Order is already present in the branch
Order -(customer)-> User -(addresses)-> Address1
- inhabitant is ignored: User is already present in the branch
Order -(customer)-> User -(addresses)-> Address2
- inhabitant is ignored: User is already present in the branch
Order -(shippingAddress)-> Address1 -(inhabitant)-> User
- addresses to Address1 is ignored: Address1 is already present in the branch
Order -(shippingAddress)-> Address1 -(inhabitant)-> User -(addresses)-> Address2
- inhabitant is ignored: User is already present in the branch
Order -(shippingAddress)-> Address2 -(inhabitant)-> User
- addresses to Address2 is ignored: Address2 is already present in the branch
Order -(shippingAddress)-> Address2 -(inhabitant)-> User -(addresses)-> Address1
- inhabitant is ignored: User is already present in the branch
Order -(billingAddress)-> Address1 -(inhabitant)-> User
- addresses to Address1 is ignored: Address1 is already present in the branch
Order -(billingAddress)-> Address1 -(inhabitant)-> User -(addresses)-> Address2
- inhabitant is ignored: User is already present in the branch
Order -(billingAddress)-> Address2 -(inhabitant)-> User
- addresses to Address2 is ignored: Address2 is already present in the branch
Order -(billingAddress)-> Address2 -(inhabitant)-> User -(addresses)-> Address1
- inhabitant is ignored: User is already present in the branch</pre></div><p style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 0); ">The <tt class="classname" style="font-size: 100%; color: rgb(17, 17, 17); font-family: monospace; ">ConstraintViolation</tt> objects, built when a failing constraint on an associated object is found, reflects the path to reach the object from the root validated object (See <a href="http://hibernate.org/~emmanuel/validation/#validationapi-constraintviolation" title="4.2. ConstraintViolation" style="font-family: sans-serif; font-size: 14px; color: rgb(0, 0, 204); ">Section 4.2, “ConstraintViolation”</a>).</p></span></div><div><br><div><div>On Feb 19, 2009, at 10:52, Hardy Ferentschik wrote:</div><br><blockquote type="cite"><div>On Wed, 18 Feb 2009 18:44:52 +0100, Emmanuel Bernard <<a href="mailto:emmanuel@hibernate.org">emmanuel@hibernate.org</a>> wrote:<br><br><blockquote type="cite">in the previous example, we would have two constraint violation reports:<br></blockquote><blockquote type="cite"> - c.b is invalid<br></blockquote><blockquote type="cite"> - d.b is invalid<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Can you tell me on which side you are?<br></blockquote><br>I agree there is a problem. I don't like the idea of getting two constraint violations though.<br>Would it be an alternative to let ConstraintViolation.getPropertyPath() return an array of<br>path strings?<br><br>--Hardy<br><br><br><br></div></blockquote></div><br></div></body></html>