-
Bug
-
Resolution: Done
-
Major
-
10.0.0.CR4
-
None
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:
<?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> ...
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.
- is cloned by
-
-
- Closed
-
