Bug 955818 - Class-Path manifest entries for WARs-in-EAR not handled properly
Summary: Class-Path manifest entries for WARs-in-EAR not handled properly
Alias: None
Product: JBoss Enterprise Application Platform 6
Classification: JBoss
Component: Server
Version: 6.0.1
Hardware: Unspecified
OS: Unspecified
Target Milestone: ER1
: EAP 6.3.0
Assignee: Jason Greene
QA Contact:
Depends On:
Blocks: 1323345
TreeView+ depends on / blocked
Reported: 2013-04-23 22:57 UTC by James Livingston
Modified: 2018-12-01 15:30 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
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.
Clone Of:
Last Closed: 2014-06-28 15:41:41 UTC
Type: Bug

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker WFLY-939 0 Major Resolved Class-Path manifest entries for WARs-in-EAR not handled properly 2017-03-17 19:55:49 UTC
Red Hat Knowledge Base (Solution) 357223 0 None None None Never

Description James Livingston 2013-04-23 22:57:03 UTC
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.

Comment 1 JBoss JIRA Server 2013-04-25 00:26:35 UTC
Stuart Douglas <stuart.w.douglas@gmail.com> updated the status of jira WFLY-939 to Resolved

Comment 4 Ivo Studensky 2013-06-13 07:40:38 UTC
This is the upstream PR:

Comment 6 Jan Martiska 2014-04-17 10:38:38 UTC
Reproduced and verified on EAP 6.3.0.ER1.

Note You need to log in before you can comment on or make changes to this bug.