Hibernate and JPA 2.0 with WebLogic Server

I talked a little about utilizing Hibernate/JPA 2 with WebLogic Server in my blog about (Multiple persistence.xml files and JPA). First off, the idea was to utilize JPA 2 and use Hibernate as the provider so that all the persistence logic could be written against JPA. Long-term, this was a mistake, since Hibernate has such advanced features such as their Filters and Interceptors that Hibernate’s API began to slowly creep into the core persistence classes we developed. So even though the initial concept seemed ideal to have this separation where the persistence provider would be hidden from application logic, that quickly changed and it became apparent that much time and effort would have been saved in just using Hibernate as opposed to coupling it with JPA 2.

That being said, in order to get Hibernate to work in WebLogic Server, one of the simplest things to do is create a preclasspath directory that we can place in front of WebLogic libraries in the WebLogic Server startup script. Then additional libraries can be added to this folder that are necessary to implement features where library collisions occur with WebLogic Server weblogic.jar and other default jars (such as saaj-impl.jar). Since the weblogic.jar contains many 3rd party libraries, and older versions than we like to use, we have to place the antlr jar in this preclasspath directory (along with other ones such as commons-lang.jar and saaj-impl.jar). Once we start our WebLogic Server, we start getting errors related to this Oracle Forum post (Thread: Hibernate 3.6 Final (JPA 2.0) + WL 10.3.x :Unable to deploy sample appn) and Can not deploy 3.5 to Weblogic 10.3 server. The error is basically:

java.lang.Throwable: java.lang.NoSuchMethodError: javax.persistence.spi.PersistenceUnitInfo.getValidationMode()Ljavax/persistence/ValidationMode;

The way to simply resolve this is by putting the “hibernate-jpa-2.0-api-1.0.1.Final.jar” into the preclasspath folder in WebLogic Server and restart the server. This appeared to fix the issue, until we actually started doing testing later on in other environments related to the Validation Framework. The following error began to appear (ignore the jar names, I use Apache Shade to combine the multiple hibernate jars into a single jar):

java.lang.AbstractMethodError: null        
at javax.persistence.Persistence$1.isLoaded(Persistence.java:93) ~[hibernate-jpa-2.0-api-1.0.1.Final.jar:1.0.1.Final]        
at org.hibernate.validator.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:61) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:131) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:46) ~[hibernate-full.jar:3.6.9]
at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1242) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:448) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:397) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:361) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:313) ~[hibernate-full.jar:3.6.9]        
at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:139) ~[hibernate-full.jar:3.6.9]

The next step was to upgrade the Hibernate Validator framework jars and also attempt to upgrade the Hibernate jars, but this did not seem to alleviate our issues. Plus, the phase of the project did not allow the upgrade from a Hibernate 3.6.0 to the newer Hibernate 4.* without some serious regression. So with some additional research, the issue seemed to really resolve around what implementation classes were being forced down the WebLogic Server classpath, as opposed to the libraries that were being supplied within the WAR. The following two links were discussions that related to this issue:

@Valid annotation gives java.lang.AbstractMethodError
AbstractMethodError in WebLogic 10.3.4
Validator fails when a non-Hibernate persistence layer is in the classpath

So through these discussions as well as a few other threads that I cannot seem to find now, the resolution was to get rid of the preclasspath library of hibernate-jpa-2.0-api-1.0.1.Final.jar and replace that jar with another spec reference from Geronimo called geronimo-jpa_2.0_spec-1.1.jar. With this replacement, the JPA 2.0 functionality continued to work because of the provided interfaces within the Geronimo API, and the AbstractMethodError disappeared when utilizing the Validator Framework functionality.

Share and Enjoy