<div dir="ltr">I think a problem is when you have MyClass, which has an attribute of type MyOtherClass, that finally points to an entity. So we must use the JPATraversableResolver even then to avoid unnecessary initialization.<div><br></div><div>Regards,</div><div>Michael</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 6, 2017 at 11:13 AM, Guillaume Smet <span dir="ltr"><<a href="mailto:guillaume.smet@gmail.com" target="_blank">guillaume.smet@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
A user of Hibernate Validator reported an interesting case here:<br>
<a href="https://hibernate.atlassian.net/browse/HV-1489" rel="noreferrer" target="_blank">https://hibernate.atlassian.<wbr>net/browse/HV-1489</a> .<br>
<br>
The fact is that a method implemented in WebLogic is suboptimal but I<br>
think there is an interesting point here anyway.<br>
<br>
In the spec, we say that when we find a JPA implementation in the<br>
classpath, we enable the JPATraversableResolver. This adds an overhead<br>
even for unmanaged entities as there is no way to tell if an object is<br>
a managed entity or a plain bean.<br>
<br>
In EclipseLink, they override the traversable resolver in the context<br>
when validating the object on persist and I think it might be good<br>
idea: their JPA resolver is only used when persisting entities and<br>
when other objects are validated, the default traversable resolver is<br>
used - in the case of our user, it uses our JPATraversableResolver<br>
which leads to the issue he reported.<br>
<br>
There is another advantage to this approach: the TraversableResolver<br>
is in the JPA implementation so it can use optimized calls to internal<br>
classes, instead of relying on the JPA API.<br>
<br>
The problem with such an approach is that the user can't override the<br>
traversable resolver set by the JPA provider.<br>
<br>
There is another trade-off: if the user tries to validate an entity<br>
outside of the JPA persist listener, it won't use the specific JPA<br>
resolver.<br>
<br>
I wasn't there when this section was added so I'm not sure what was<br>
exactly the rationale for it.<br>
<br>
I think we might have underestimated the overhead of our approach. We<br>
have a cache but the cache is per validation call so if you end up<br>
validating each object only once per call (and it's probably the most<br>
common case), the cache doesn't bring anything to you (except an<br>
additional overhead).<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Guillaume<br>
______________________________<wbr>_________________<br>
beanvalidation-dev mailing list<br>
<a href="mailto:beanvalidation-dev@lists.jboss.org">beanvalidation-dev@lists.<wbr>jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/beanvalidation-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/<wbr>mailman/listinfo/<wbr>beanvalidation-dev</a><br>
</font></span></blockquote></div><br></div>