[SIRONA-44] use PersistenceProviderResolver to guess jpa provider

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 0.3-incubating
• Assignee: Romain Manni-Bucau
• Reporter: Romain Manni-Bucau
• Created: 22/Mar/15 15:02
• Updated: 22/Mar/15 15:22
• Resolved: 22/Mar/15 15:04

Description

Main from Vernat Emeric on the list:

Hi Sirona and JavaMelody devs,

In the Sirona JPA monitoring, inside SironaPersistence [1], the PersistenceProvider is guessed by trying to load the classes of 11 possible providers: org.apache.openjpa.persistence.PersistenceProviderImpl, org.hibernate.jpa.HibernatePersistenceProvider, etc
The one which is found by the ClassLoader wins.
The JavaMelody JPA monitoring was heavily inspired by Sirona's one as you probably know [2].

My question is: would it be possible and simpler for SironaPersistence to look into javax.persistence.spi.PersistenceProviderResolverHolder.getPersistenceProviderResolver().getPersistenceProviders() instead of loading the classes of providers?

By the way, it seems to me that this change would fix a usage "issue" with WildFly 8.2 because in WildFly, by default:

• Thread.currentThread().getContextClassLoader() does not find the org.hibernate.jpa.HibernatePersistenceProvider class from the WildFly JBoss module,
• while PersistenceProviderResolverHolder.getPersistenceProviderResolver().getPersistenceProviders() returns something like [org.apache.sirona.jpa.SironaPersistence@20abb1, org.hibernate.jpa.HibernatePersistenceProvider@e7f394, org.hibernate.ejb.HibernatePersistence@28b99c].
  (Otherwise, you could read the very long WildFly documentation, or to keep it short you can certainly add a META-INF/MANIFEST.MF file in the webapp resources with "Dependencies: org.hibernate")

Thanks guys and girls,

• Emeric