In previous versions of JBoss EAP 6, when multiple sub-deployments in an EAR referred to a single non-module jar via Class-Path manifest entries, it was added to the first sub-deployment's classloader.
This caused Class loading problems as the classes in the utility jar would be located in the wrong classloader.
This version of the product creates a new deployment module for the utility jar, and has all dependant deployments use it. As a result, the Classloading problems no longer occur.
ManifestClassPathProcessor handles the processing of Class-Path entries in deployments. The handling of those entries in sub-deployments is broken.
https://github.com/doctau/examples/tree/master/war-manifest-classpath builds an EAR containing a utility JAR and two WARs, where both WARs refer to the jar via Class-Path manifest headers. The jar is not in the EAR's library directory nor in application.xml
The resulting module setup will result in the jar being added to the first WAR's module, and the remaining WAR(s) depending on a separate "jar classloader". All WARs should depend on the single shared jar classloader.
When ManifestClassPathProcessor.handlingExistingClassPathEntry() runs for the first war, it will call createAdditionalModule(), which calls createResourceRoot(). The "deploymentUnit.addToAttachmentList(Attachments.RESOURCE_ROOTS, resourceRoot)" adds it to the resource roots for that WAR.
When handlingExistingClassPathEntry() runs for the second (and subsequent) WAR, it will already be in the additionalModules list, so "target.addToAttachmentList(Attachments.CLASS_PATH_ENTRIES, moduleSpecification.getModuleIdentifier())" gets run.
I believe the step of adding it to the CLASS_PATH_ENTRIES attachment needs to happen on the first WAR (so it is added as a module dependency), and it should not be added to the DU RESOURCE_ROOTS so it is not in the WAR's own classloader.
Stuart Douglas <email@example.com> updated the status of jira WFLY-939 to Resolved
This is the upstream PR:
Reproduced and verified on EAP 6.3.0.ER1.