On 09/17/2014 05:28 AM, Emmanuel Bernard wrote:
BTW there can be multiple persistence units deployed per application
if you are trying to tie your cache to the lifecycle of
createContainerEntityManagerFactory, you might be making a mistake.
When applications include a persistence provider(s), we associate the
provider with the application classloader (saved in
PersistenceProviderResolver level cache). This is not tied to the
persistence unit. The call to
PersistenceProvider.createContainerEntityManagerFactory() can happen
before the PersistenceProviderResolver cache is updated with the
So, it is important to understand when Hibernate Validator first calls
Persistence.getProviders(), so that we know to set the cache earlier.
This looked hard to do a few years ago (chicken + egg problem with when
application classloaders are known in WildFly from what I remember).
On Wed 2014-09-17 11:22, Emmanuel Bernard wrote:
> PersistenceProvider implementations are not app specific.
> Hibernate Validator uses
> This in turn is a static reference object that in its method calls
> Persistence.getProviders() *each time* to resolve operations like
> So to answer your question, I think it's after.
> On Fri 2014-09-12 17:02, Scott Marlow wrote:
>> What triggers Hibernate Validator to call
>> PersistenceProviderResolver.getPersistenceProviders()? Does this happen
>> during the call to
>> PersistenceProvider.createContainerEntityManagerFactory() or later after
>> application deployment completes?
>> I'm looking at changing
>> PersistenceProviderResolver.getPersistenceProviders() to cache the
>> results on a per deployment basis but need to know when the first call
>> will be made, so I don't break deployment of persistence providers in
>> the deployed application.
>> hibernate-dev mailing list
> hibernate-dev mailing list