Hibernate JPA ClassCastException when moving application from JBoss 7 to WildFly 8

Question

I have a somewhat crufty piece of software that is currently running under Java 7 and JBoss 7.1.2. As a first step to bringing this up to current times, I'm trying to bump this up to running under Java 8 and WildFly 8.2.1.

I've managed to get most things working, but am running into an issue with Hibernate / JPA versions. My application is packaged as an EAR file with two WAR files, along with a few JAR files. One of the WAR files is using Hibernate 4.3.x and JPA 2.1 and appears to be working ok, but the other WAR file (mostly 3rd party code) is using Hibernate 3.6.x and JPA 2.0.

Somehow someone managed to magically make that all work under JBoss 7.1.x, but I've bene unable to repeat that magic under WildFly 8.2.x and keep getting exceptions such as the following:

org.springframework.web.util.NestedServletException: Request processing failed; nested exception is org.springframework.webflow.execution.FlowExecutionException: Exception thrown in state 'ipaidLoginForm' of flow 'login'
[...]
Caused by: java.lang.ClassCastException: org.hibernate.jpa.HibernatePersistenceProvider cannot be cast to javax.persistence.spi.PersistenceProvider
    at javax.persistence.Persistence$1.isLoaded(Persistence.java:92)
    at org.hibernate.validator.internal.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:56)
    at org.hibernate.validator.internal.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:137)
    at org.hibernate.validator.internal.engine.resolver.CachingTraversableResolverForSingleValidation.isReachable(CachingTraversableResolverForSingleValidation.java:46)
    at org.hibernate.validator.internal.engine.ValidatorImpl.isReachable(ValidatorImpl.java:1396)
    ... 75 more

I have been trying just about every combination I can think of to include / exclude versions of Hibernate and JPA. I believe the solution should be the exclude the WildFly built-in Hibernate and JPA and use the two versions that are bundled in my two WARs.

My jboss-deployment-structure.xml file looks like this:

<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.0">
    <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
    <deployment>
        <exclusions>
            <module name="org.hibernate" />
            <module name="javax.persistence.api" />
            <module name="org.jboss.resteasy.resteasy-jackson-provider" />
        </exclusions>
        <dependencies>
            <module name="javax.servlet.jstl.api" export="true" />
            <module name="org.jboss.resteasy.resteasy-jackson2-provider" services="import" />
            <module name="com.fasterxml.jackson.jaxrs.jackson-jaxrs-json-provider" />
        </dependencies>
    </deployment>
</jboss-deployment-structure>

The WAR file that is not working has the following persistence.xml:

<persistence xmlns="http://java.sun.com/xml/ns/persistence"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"
        version="2.0">

    <persistence-unit name="CasPersistence" transaction-type="RESOURCE_LOCAL">
        <provider>org.hibernate.ejb.HibernatePersistence</provider>
        <class>org.jasig.cas.services.AbstractRegisteredService</class>
        <class>org.jasig.cas.services.RegexRegisteredService</class>
        <class>org.jasig.cas.services.RegisteredServiceImpl</class>
        <class>org.jasig.cas.ticket.TicketGrantingTicketImpl</class>
        <class>org.jasig.cas.ticket.ServiceTicketImpl</class>
        <class>org.jasig.cas.ticket.registry.support.JpaLockingStrategy$Lock</class>
        <!-- DriveSync specific change - Add proper for hibernate cache -->
        <properties>
            <property name="hibernate.cache.region.factory_class" value="net.sf.ehcache.hibernate.EhCacheRegionFactory"/>
        </properties>
    </persistence-unit>
</persistence>

Somehow, the WAR file that is working doesn't seem to have a persistence.xml at all? I'm not sure if that is normal?

Any suggestions, even just pointing in the right direction, would be hugely appreciated!

Does this answer your question? [hibernate.jpa.HibernatePersistenceProvider cannot be cast to javax.persistence.spi.PersistenceProvider](https://stackoverflow.com/questions/31395133/hibernate-jpa-hibernatepersistenceprovider-cannot-be-cast-to-javax-persistence-s) — XtremeBaumer, May 25 '23 at 07:22

score 1 · Accepted Answer · answered May 25 '23 at 16:21

1

I think the issue is that you haven't isolated your subdeployments thus you are getting the 2 hibernate and jpa versions to collide. https://www.mastertheboss.com/jbossas/jboss-as-7/jboss-as-7-classloading/ might help in your case

answered May 25 '23 at 16:21

ehsavoie

3,126
1
16
14

Thank you for the link! I believe this does indeed point to the issue I'm running into. I haven't yet been able to get everything working, but at least the above document explains the problem! – Tony Hill May 26 '23 at 13:55
So, the final, working solution I ended up with, after multiple attempts to isolate subdeployments, was just to split things into two separate EAR files. One EAR contained our in-house code, the other EAR contained the mostly-3rd-party code. – Tony Hill May 31 '23 at 03:45

score 0 · Answer 2 · answered May 25 '23 at 08:43

Not familiar with that specific pair of versions, but upgrading from one JBoss container to another version is rarely as simple as dropping your ear in the new version and starting it up.

Most likely you're going to have to do a LOT of rewriting and rewiring of dependencies, as there have been big changes in the classloader architecture between versions.

Which will also give you a chance (mandated even) to upgrade your Spring and Hibernate versions and bringing them all to the same version numbers.

Which upgrades may end up requiring more rewriting. E.g. when I was involved in a similar project (different JBoss versions) we ended up having to rewrite the entire transaction handling mechanism of the application, rearchitecture the various wars and ejb jars (changing which classes went where), etc. etc..

Hibernate JPA ClassCastException when moving application from JBoss 7 to WildFly 8

2 Answers2