Yes, the PersistenceUtil API is pretty basic and you can't do much about that.
And you're right about Hibernate not being the only JPA provider in
the classpath. I didn't think of this case.
What would be possible is to do what WebLogic did ie have a specific
TraversableResolver when the validation is triggered by ORM directly.
It wouldn't help the case of the other validation calls though.
On Mon, Oct 9, 2017 at 5:00 PM, Emmanuel Bernard <email@example.com> wrote:
> If you can detect that this is not an entity class, then you could cache this information in a bounded cache (weak key). It should help a lot. But I don't think PersistenceUtil has such API and if you use Hibernate specific APIs, you are never guaranteed than you are the only JPA provider in the classpath unless you look for them or the app server tells you. Tricky optimisation.
>> On 9 Oct 2017, at 16:24, Guillaume Smet <firstname.lastname@example.org> wrote:
>> OK so we can't really do anything about it.
>> I tuned HV to be a bit more efficient and avoid an additional cache
>> lookup on cascade with the JPA TraversableResolver (the isCascadable()
>> method always returns true so we don't need to cache it).
>> It might be a good idea to discuss with the ORM people to see if we
>> can be a bit more efficient in the Hibernate case. There is a TODO in
>> our code about introducing some specific optimizations.
>> On Mon, Oct 9, 2017 at 11:56 AM, Emmanuel Bernard
>> <email@example.com> wrote:
>>> The reason was to be able to validate entities outside of explicit JPA calls and not cross the lazy loading boundaries.
>>> It would become a very big overhead to load data from the database for validation.
>> beanvalidation-dev mailing list
> beanvalidation-dev mailing list
beanvalidation-dev mailing list