I agree the current situation is far from ideal. For history, here is what EclipseLink does: http://grepcode.com/file/repo1.maven.org/maven2/org.eclipse.persistence/eclipselink/2.6.0/org/eclipse/persistence/internal/jpa/metadata/listeners/BeanValidationListener.java . I'm not sure if their TraversableResolver internals are such a good idea as I don't think what they did will work when cascading to another entity embedded in a given one. But using a specific TraversableResolver is definitely a good idea when dealing with JPA, thus allowing a more simple TraversableResolver to be used in the other cases. Well, with HV, it leads to use a suboptimal one unfortunately for all the other objects as JPA is in the classpath... I tend to agree that maybe it was not such a good idea to include this in the BV spec. The JPA implementations are better placed to do the right thing as they have access to better qualified information and the validation is triggered by them so they can adjust the TraversableResolver. Gunnar Morling interested in your thoughts on this. |