Mockito.mock(...) does not work inside an Arquillian integration test anymore about mockito HOT 1 CLOSED

After much trial and error I was able to find a solution for this.

Short version is to add the following to your Arquillian deployment's jboss-deployment-structure.xml:

<jboss-deployment-structure>
    <deployment>
        <dependencies>
            <system export="true">
                <paths>
                    <path name="org/mockito/internal/creation/bytebuddy/inject"/>
                </paths>
            </system>
        </dependencies>
    </deployment>
</jboss-deployment-structure>

Long version:
These lines of code in InlineDelegateButeBuddyMockMaker.java are responsible for reading a file named MockMethodDispatcher.raw, renaming it to MockMethodDispatcher.class and adding it to the classpath for the Bootstrap Class Loader. This initialization is all done at runtime when the first attempt to use a Mock occurs.

When these events are occurring in the context of a Wildfly container, the first class loader encountered is a JBoss Class Loader, and NOT the bootstrap class loader. This classloader has no awareness of the new class file just added to the boostrap class loader's classpath and we get a NoClassDefFoundError.

I tried artificially adding the renamed MockMethodDispatcher.class file to my WAR deployment in the hopes that the JBoss class loaders would then be able to find the class. Unfortunately, this attempt is detected by Mockito and we get an error message that Mockito requires that class to be loaded by the boostrap class loader specifically! You can see this error message here.

What finally worked for me is this directive added to jboss-deployment-structure.xml. That section is usually used to allow Wildfly access to internal JDK packages (e.g. "sun/reflect") and I reasoned that any package mentioned here would trigger a delegation by the JBoss class loader to the bootstrap class loader. Which is precisely what happened and everything started to work again!

from mockito.