Hey,

We are upgrading the version of WildFly that we are deploying our EAR to from WildFly (28.0.1) -> (35.0.1).

We have hibernate persistence configuration in a JAR within the EAR lib folder that is being picked up.

Each persistence-unit contains the hibernate.jndi.class property that points to our own class that implements InitialContextFactory.

Previously WildFly 28 would log:
Finding class package.MyInitialContextFactory from Module "deployment.app.ear" from Service Module Loader

WildFly 35 now logs
Finding class package.MyInitialContextFactory from Module "org.jboss.as.jpa" version 35.0.1.Final from local module loader

WildFly seems to be trying to pull the class from the wrong Module.

WildFly Forum Discussion - https://groups.google.com/d/msgid/wildfly/c1bbc3e5-fca7-4182-a77a-507a7fb130bbn%40googlegroups.com?utm_medium=email&utm_source=footer

Scott Marlow was able to replicate this and reported

I don't see the likely cause from the exception call stack. I was able to reproduce (mvn clean install -Dtest=jboss.as.test.integration.jpa.jndi.JNDITestCase) it locally via https://github.com/scottmarlow/wildfly/commits/jndi_failure_hibernate.jndi.class (https://github.com/scottmarlow/wildfly/commit/f1fec0b4343ae470d8db468db352f6c05a9ffd39).

Can you please create a tracking WFLY issue for this problem via https://issues.redhat.com/projects/WFLY/issues and let me know the issue link here. Please also mention this (https://groups.google.com/d/msgid/wildfly/c1bbc3e5-fca7-4182-a77a-507a7fb130bbn%40googlegroups.com?utm_medium=email&utm_source=footer) discussion as well.

Thanks for reporting this!

Scott

Regards,
Lawrence