[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by John Farrelly (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
John Farrelly updated WFLY-5922:
--------------------------------
Description:
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.
was:
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>
<!-- Make sure jacorb libraries are excluded -->
<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.
> 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)
9 years, 9 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5922:
-----------------------------------
With configuration provided, exclutions would only apply to "root" ear and not to all sub deployments, which is probably why you see this problem.
you will need to add <sub-deployment> with excludes for each ear module that needs excludes
> 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)
9 years, 9 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by John Farrelly (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
John Farrelly updated WFLY-5922:
--------------------------------
Description:
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>
<!-- Make sure jacorb libraries are excluded -->
<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.
was:
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>
<!-- Make sure jacorb libraries are excluded -->
<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.
> 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>
> <!-- Make sure jacorb libraries are excluded -->
> <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)
9 years, 9 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by John Farrelly (JIRA)
[ https://issues.jboss.org/browse/WFLY-5922?page=com.atlassian.jira.plugin.... ]
John Farrelly updated WFLY-5922:
--------------------------------
Description:
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>
<!-- Make sure jacorb libraries are excluded -->
<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.
was:
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>
<!-- Make sure jacorb libraries are excluded -->
<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 ecxluded in the deployment descriptor for the 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>
> <!-- Make sure jacorb libraries are excluded -->
> <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)
9 years, 9 months
[JBoss JIRA] (WFLY-5922) Cannot exclude java.orb.api module
by John Farrelly (JIRA)
John Farrelly created WFLY-5922:
-----------------------------------
Summary: 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>
<!-- Make sure jacorb libraries are excluded -->
<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 ecxluded in the deployment descriptor for the application.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-4296) remove _ds.xml deployment support
by Matt Fellows (JIRA)
[ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.... ]
Matt Fellows commented on WFLY-4296:
------------------------------------
+1 to the voice of those not wishing this to be deprecated.
"Currently only scenario where it kinda works ok is in standalone mode when you are doing application developing."
I'd much prefer for this to be fixed so that deploying a -ds.xml file in the deployments folder does indeed deploy this as a new datasource, (I'm fine with this only working in standalone mode by the way).
"And when you keep this in mind you can see that EE6+ feature http://docs.oracle.com/javaee/7/api/javax/annotation/sql/DataSourceDefini... more than satisfies it."
It does not cope with dynamic datasource definitions. Multitennanted systems which rely on database partitioning (Different database per tennant), and thus require a specific datasource per tennant, decided at runtime, would not be possible if this feature is deprecated (At least as far as I can tell).
I'm sure I'm not in the majority of users with my crazy use case, but nevertheless I'm also sure this is a very important feature to me. Editing the standalone.xml during runtime is not sensible or particularly safe. Running a command via the CLI, is possible, but feels a little icky to run Command Line scripts in Java code. Dropping a templated -ds.xml file into the deployments folder feels safer to me.
> remove _ds.xml deployment support
> ---------------------------------
>
> Key: WFLY-4296
> URL: https://issues.jboss.org/browse/WFLY-4296
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Stefano Maestri
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-5921 at 1/4/16 9:13 AM:
------------------------------------------------------------
BTW - Distributed streams work fine (as normal java.util.stream) when using simple cache.
In general, I don't think it's a good idea for EAP7.x to rely on soon to be deprecated API - so I strongly encourage you to create a fork for EAP7 work.
However, looking at how you are using Infinispan in KeyCloak, it seems to me that you do not actually want to use a non-transactional cache. You should at least be using transaction mode="BATCH", that way individual cache operations work in auto-commit mode. This will also prevent the simple cache optimization from being auto-enabled in WF10.
If the above is satisfactory, please reclose.
was (Author: pferraro):
BTW - Distributed streams work fine (as normal java.util.stream) when using simple cache.
In general, I don't think it's a good idea for EAP7.x to rely on soon to be deprecated API - so I strongly encourage you to create a fork for EAP7 work.
However, looking at how you are using Infinispan in KeyCloak, it seems to me that you do not actually want to use a non-transactional cache. You should at least be using transaction mode="BATCH", that way individual cache operations work in auto-commit mode. This will also prevent the simple cache optimization from being auto-enabled in WF10.
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Paul Ferraro
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5921:
------------------------------------
BTW - Distributed streams work fine (as normal java.util.stream) when using simple cache.
In general, I don't think it's a good idea for EAP7.x to rely on soon to be deprecated API - so I strongly encourage you to create a fork for EAP7 work.
However, looking at how you are using Infinispan in KeyCloak, it seems to me that you do not actually want to use a non-transactional cache. You should at least be using transaction mode="BATCH", that way individual cache operations work in auto-commit mode. This will also prevent the simple cache optimization from being auto-enabled in WF10.
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Paul Ferraro
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (DROOLS-1012) kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1012?page=com.atlassian.jira.plugi... ]
RH Bugzilla Integration commented on DROOLS-1012:
-------------------------------------------------
Kris Verlaenen <kverlaen(a)redhat.com> changed the Status of [bug 1293455|https://bugzilla.redhat.com/show_bug.cgi?id=1293455] from NEW to ASSIGNED
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-1012
> URL: https://issues.jboss.org/browse/DROOLS-1012
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.4.x
>
> Attachments: brms-fuse-integration-master.tgz
>
>
> kie-ci-osgi Activator doesn't register the ClassLoaderResolver on the ServiceRegistry. This implies that when the KieContainer is created in a OSGi environment it is not able to get an instance of the MavenClassLoaderResolver and then cannot create a ClassLoader including all the transitive dependencies of the kjar to be compiled.
> The attached project reproduces this issue. In order to run it, it's enough to do a mvn clean install of the project and issue the following commands in fuse:
> features:addurl mvn:com.redhat/brms-fuse-integration-features/0.0.1-SNAPSHOT/xml/features
> features:install brms-integration-bundle
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months
[JBoss JIRA] (WFLY-5921) Locale cache set to simple cache automatically breaks map reduce
by Stian Thorgersen (JIRA)
[ https://issues.jboss.org/browse/WFLY-5921?page=com.atlassian.jira.plugin.... ]
Stian Thorgersen reopened WFLY-5921:
------------------------------------
Currently we have to support both older version of Infinispan (from EAP 6.4) as well as newer version from WildFly so this doesn't work for us. Once we no longer need to support EAP 6.4 we can probably migrate to distributed streams.
However, that's not really relevant. The issue here is that the cache is being set to simple-cache without giving us the ability to change that. I assume distributed streams won't be available to simple caches either.
> Locale cache set to simple cache automatically breaks map reduce
> ----------------------------------------------------------------
>
> Key: WFLY-5921
> URL: https://issues.jboss.org/browse/WFLY-5921
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Stian Thorgersen
> Assignee: Paul Ferraro
> Priority: Critical
>
> We use the Infinispan subsystem to create/configure caches for Keycloak. In standalone mode Keycloak uses locale-caches, while in clustered mode we use a combination of invalidation caches and distributed caches. In both clustered and non-clustered mode we use map-reduce tasks to delete elements from the cache.
> This has worked just fine until the recent change in CR5 where locale-caches are now set to simple-caches (WFLY-5327). As the caches are now automatically set to simple-caches map-reduce is no longer available. There's also no way to prevent this.
> IMO the changes from WFLY-5327 should be reverted and instead a new simple-cache element should be added, or a simple-cache=true attribute added to the locale-cache element.
> As it stands this change prevents us from upgrading to CR5.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 9 months