[jboss-jira] [JBoss JIRA] (WFLY-939) Class-Path manifest entries for WARs-in-EAR not handled properly

[RH Bugzilla Integration (JIRA)]

    [ https://issues.jboss.org/browse/WFLY-939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12769700#comment-12769700 ] 

RH Bugzilla Integration commented on WFLY-939:
----------------------------------------------

James Livingston <jlivings at redhat.com> made a comment on [bug 955818|https://bugzilla.redhat.com/show_bug.cgi?id=955818]

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.
                
> Class-Path manifest entries for WARs-in-EAR not handled properly
> ----------------------------------------------------------------
>
>                 Key: WFLY-939
>                 URL: https://issues.jboss.org/browse/WFLY-939
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>            Reporter: James Livingston
>            Assignee: Stuart Douglas
>
> 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.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira