[jboss-jira] [JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module

[John Farrelly (JIRA)]

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

John Farrelly commented on WFLY-5922:
-------------------------------------

I also added the exclusion to my sub-deployment, but {{javax.orb.api}} was still used.

{code:xml}
    <sub-deployment name="myapp-ejb3-1.0.0.jar">
        <exclusions>
            <module name="javax.orb.api" />
            <module name="org.omg.api" />
        </exclusions>
        <dependencies>
                <module name="org.apache.xerces" />
                <module name="org.apache.xalan" />
        </dependencies>
    </sub-deployment>
{code}

Is there any additional debug level I could set to see if there's some transitive dependency that is pulling in {{javax.orb.api}} despite it's exclusion?  I've enabled {{TRACE}} logging for {{org.jboss.modules}}, but it doesn't say why the {{javax.orb.api}} module is being included in my application.

> Cannot exclude java.orb.api module
> ----------------------------------
>
>                 Key: WFLY-5922
>                 URL: https://issues.jboss.org/browse/WFLY-5922
>             Project: WildFly
>          Issue Type: Bug
>          Components: Class Loading
>    Affects Versions: 10.0.0.CR4
>         Environment: Red Hat Enterprise Linux Server release 7.1 (Maipo)
> Linux 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
>            Reporter: John Farrelly
>            Assignee: David Lloyd
>            Priority: Blocker
>
> We use Orbacus as our CORBA implementation, and in our application we wish to use CORBA classes only from the orbacus module, and not the JDK/WildFly bundled CORBA.
> In the {{jboss-deployment-structure.xml}} file of our {{ear}} file, we have the following:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
>     <ear-subdeployments-isolated>false</ear-subdeployments-isolated>
>     <deployment>
>         <exclusions>
>             <module name="javax.orb.api" />
>             <module name="org.omg.api" />
>         </exclusions>
>         <dependencies>
>             <module name="com.ooc.orbacus" export="true"/>
>             <module name="org.apache.commons.logging" export="true" />
>             <module name="org.apache.commons.collections" export="true" />
>             <module name="org.apache.log4j" export="true" />
>             <module name="org.dom4j" export="true" />
>             <module name="org.jdom" export="true" />
>             <module name="javax.faces.api" slot="mojarra-2.1.23" export="true"/>
>             <module name="com.sun.jsf-impl" slot="mojarra-2.1.23" export="true"/>
>             <module name="org.jboss.ejb-client" export="true" />
>             <module name="org.jboss.remote-naming" export="true" />
>             <module name="org.jboss.remoting3" export="true" />
>             <module name="org.apache.xerces" />
>             <!-- dependency for richfaces -->
>             <module name="com.google.guava" slot="11.0.2" export="true"/>
>         </dependencies>
>     </deployment>
> ...
> {code}
> However, despite excluding the {{javax.orb.api}} module, I can see that {{org.omg.PortableServer.Servant}} is loaded from that module instead of being loaded from our {{com.ooc.orbacus}} module.  This causes our application to fail.
> Debugging through the jboss module loader, I can see that it considers both {{javax.orb.api}} and {{com.ooc.orbacus}} as prodivers of the {{org/omg/PortableServer}} path.  I am not sure why {{javax.orb.api}} is being considered when it has been excluded in the deployment descriptor for the application.



--
This message was sent by Atlassian JIRA
(v6.4.11#64026)