DataOnDemand_Roo_DataOnDemand init() has poor messaging for ConstraintViolationException

Issue is when the DataOnDemand class persists test entity data. If a constraint fails, it doesn't tell you the path/field. Somewhat amusing because the code logs all kinds of other information, except what you really want to know, which is what field failed validation.

Consider the generated code:
try

{ obj.persist(); }

catch (ConstraintViolationException e) {
StringBuilder msg = new StringBuilder();
for (Iterator<ConstraintViolation<?>> iter = e.getConstraintViolations().iterator(); iter.hasNext()

{ ConstraintViolation<?> cv = iter.next(); msg.append("[").append(cv.getConstraintDescriptor()).append(":").append(cv.getMessage()).append("=").append(cv.getInvalidValue()).append("]"); }

throw new RuntimeException(msg.toString(), e);
}
I guess this code bothers is trying to ensure a consistent error message across JSR303 vendors. The irony here is that the reference implementation, hibernate validator, does a much better job with the error message, if the code where to just call toString() on the ConstraintViolation object. From org.hibernate.validator.engine.ConstraintViolationImpl:

public String toString() {
final StringBuilder sb = new StringBuilder();
sb.append( "ConstraintViolationImpl" );
sb.append( "

{interpolatedMessage='" ).append( interpolatedMessage ).append( '\'' ); sb.append( ", propertyPath=" ).append( propertyPath ); sb.append( ", rootBeanClass=" ).append( rootBeanClass ); sb.append( ", messageTemplate='" ).append( messageTemplate ).append( '\'' ); sb.append( '}

' );
return sb.toString();
}

In particular, it logs the propertyPath, which is what you need to track down the problem. You could also just make a trivial change to the generated code to get the path in there:

msg.append("[").append(cv.getConstraintDescriptor()).append(":").append(cv.getPropertyPath()).append(":").append(cv.getMessage()).append("=").append(cv.getInvalidValue()).append("]");

Note the addition of cv.getPropertyPath to the msg.