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
_______________________________________________
beanvalidation-dev mailing list
beanvalidation-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/beanvalidation-dev