NullPointerException during enhancement when using the default BytecodeProvider in Wildfly

Hi @Scott Marlow , my knowledge of JBoss Modules is a bit rusty, but I believe we might need to ensure that the new service is visible?

I suspect adding services="export" on the module.xml of the Hibernate could help? I’m trying to test it but the amount of dependencies that Maven wants me to download… it’s going to take some time :)

I’m NOT sure we’d want to universally export all services to everyone; perhaps - assuming the above suggestion confirms being on the right path - we’d want the specific WildFly module which is performing the enhancement to import this particular service only: narrow the scope to the miminum we need.

Thanks for the suggestion @Scott Marlow, that’s exactly what I did. From my testing, we previously relied on a static method that always returned a new instance of the Byte Buddy implementation for BytecodeProvider. That method now tries loading the service from the current thread’s context ClassLoader, but doesn’t find anything so it defaults to the non-enhancing provider - this eventually causes the test failure further down the line.

Now, I’m not sure why in that call there is no BytecodeProvider service available (specifically this is in EnhancingClassTransformerImpl’s constructor), but looking at logs we later initialize the service through BytecodeProviderInitiator#initiateService that uses Hibernate's custom ClassLoaderService and we are able to find the Byte Buddy provider instance then. My best guess is either we’re supposed to use a different class loader the first time or we should just default to the “enhancing” implementation (i.i. Byte Buddy) for that specific case.

WDYT @Sanne Grinovero?

The two unit tests that are failing are the only tests configured to run with entity bytecode enhancement enabled via WildFly persistence unit property hint :

<property name="jboss.as.jpa.classtransformer" value="true"/>

I think that the test is failing because something changed that causes Hibernate ORM to enhance additional application classes including the Weld (CDI related) proxy classes mentioned in the error message. For example “org/jboss/as/test/integration/jpa/datasourcedefinition/SFSBXPC$Proxy$_$$_Weld$EnterpriseProxy$" which is generated during application deployment to support CDI requirements. This particular generated (Weld) class is for application source file https://github.com/wildfly/wildfly/blob/main/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/jpa/datasourcedefinition/SFSBXPC.java which references application entity classes but is not an entity class itself (it is an EJB bean).

Is it possible that the https://hibernate.atlassian.net/browse/HHH-17643 change is somehow causing some other code in Hibernate ORM to enhance more application classes than we were previously?

My best guess to get to the bottom of understanding why this is happening is to instrument the ORM enhancement code with “prints of class being enhanced” + “Thread.dumpStack()” so we might see the call stack involved with enhancing the datasourcedefinition/SFSBXPC$Proxy$_$$_Weld$EnterpriseProxy$ class.

Small update, ran the tests again with a modified Hibernate version and confirmed we’re finding the Byte Buddy implementation of BytecodeProvider as a service.

@Scott Marlow I tried running the tests with a locally modified version of Hibernate 6.4.3 after removing only the 2 commits related to the Jira we mentioned and indeed it seems that’s the culprit of the error.

Within that Jira we changed how Hibernate determines the default bytecode provider to use: from always defaulting to the Byte Buddy bytecode provider implementation, unless the hibernate.bytecode.provider configuration property was explicitly set to none, we now load the instance through ServiceLoader.load( BytecodeProvider.class ). If no service is found, we now default to the "empty" bytecode provider. Within hibernate-core we expose a provider configuration file that should result in applications defaulting to Byte Buddy even after this change.

This was done to circumvent some issues related to native image compilation, as suggested by @Sanne Grinovero. Do you happen to have an idea why this might be a problem in Wildfly?