Hi, A user of Hibernate Validator reported an interesting case here: https://hibernate.atlassian.net/browse/HV-1489 . The fact is that a method implemented in WebLogic is suboptimal but I think there is an interesting point here anyway. In the spec, we say that when we find a JPA implementation in the classpath, we enable the JPATraversableResolver. This adds an overhead even for unmanaged entities as there is no way to tell if an object is a managed entity or a plain bean. In EclipseLink, they override the traversable resolver in the context when validating the object on persist and I think it might be good idea: their JPA resolver is only used when persisting entities and when other objects are validated, the default traversable resolver is used - in the case of our user, it uses our JPATraversableResolver which leads to the issue he reported. There is another advantage to this approach: the TraversableResolver is in the JPA implementation so it can use optimized calls to internal classes, instead of relying on the JPA API. The problem with such an approach is that the user can't override the traversable resolver set by the JPA provider. There is another trade-off: if the user tries to validate an entity outside of the JPA persist listener, it won't use the specific JPA resolver. I wasn't there when this section was added so I'm not sure what was exactly the rationale for it. I think we might have underestimated the overhead of our approach. We have a cache but the cache is per validation call so if you end up validating each object only once per call (and it's probably the most common case), the cache doesn't bring anything to you (except an additional overhead). -- Guillaume