[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by David Ward (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1004?page=com.atlassian.jira.plugi... ]
David Ward updated DROOLS-1004:
-------------------------------
Description:
There appear to be some classloading errors in kie-server.war 6.3.0.Final-redhat-5 being deployed on JBoss EAP 6.4.4.
*First, you get multiple jaxb and parser warnings like this:*
{code}
11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
{code}
The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
*Second, there can be missing osgi classes:*
If kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
, you end up with errors like this in the log when the KieContainer is being installed:
{code}
Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 77 more
Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 81 more
{code}
The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.osgi.core"/>
<module name="org.osgi.enterprise"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
was:
There appear to be some classloading errors in kie-server.war.
First, you get multiple warnings like this:
{code}
11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
{code}
The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
Second, if kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
, you end up with errors like this in the log when the KieContainer is being installed:
{code}
Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 77 more
Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 81 more
{code}
The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.osgi.core"/>
<module name="org.osgi.enterprise"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
> classloading errors in kie-server
> ---------------------------------
>
> Key: DROOLS-1004
> URL: https://issues.jboss.org/browse/DROOLS-1004
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Maciej Swiderski
>
> There appear to be some classloading errors in kie-server.war 6.3.0.Final-redhat-5 being deployed on JBoss EAP 6.4.4.
> *First, you get multiple jaxb and parser warnings like this:*
> {code}
> 11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
> {code}
> The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
> The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
> *Second, there can be missing osgi classes:*
> If kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
> http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
> , you end up with errors like this in the log when the KieContainer is being installed:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 77 more
> Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 81 more
> {code}
> The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="org.osgi.core"/>
> <module name="org.osgi.enterprise"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by David Ward (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1004?page=com.atlassian.jira.plugi... ]
David Ward updated DROOLS-1004:
-------------------------------
Description:
There appear to be some classloading errors in kie-server.war.
First, you get multiple warnings like this:
{code}
11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
{code}
The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
Second, if kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
, you end up with errors like this in the log when the KieContainer is being installed:
{code}
Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 77 more
Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 81 more
{code}
The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.osgi.core"/>
<module name="org.osgi.enterprise"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
was:
There appear to be some classloading errors in kie-server.war.
First, you get multiple warnings like this:
{{11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'}}
The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
bq. The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
Second, if kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
, you end up with errors like this in the log when the KieContainer is being installed:
{{Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 77 more
Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 81 more}}
The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.osgi.core"/>
<module name="org.osgi.enterprise"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
> classloading errors in kie-server
> ---------------------------------
>
> Key: DROOLS-1004
> URL: https://issues.jboss.org/browse/DROOLS-1004
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Maciej Swiderski
>
> There appear to be some classloading errors in kie-server.war.
> First, you get multiple warnings like this:
> {code}
> 11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
> 11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'
> {code}
> The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
> The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
> Second, if kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
> http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
> , you end up with errors like this in the log when the KieContainer is being installed:
> {code}
> Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
> at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
> at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
> at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 77 more
> Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
> at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
> ... 81 more
> {code}
> The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-deployment-structure>
> <deployment>
> <dependencies>
> <module name="org.osgi.core"/>
> <module name="org.osgi.enterprise"/>
> </dependencies>
> </deployment>
> </jboss-deployment-structure>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by David Ward (JIRA)
David Ward created DROOLS-1004:
----------------------------------
Summary: classloading errors in kie-server
Key: DROOLS-1004
URL: https://issues.jboss.org/browse/DROOLS-1004
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.3.0.Final
Reporter: David Ward
Assignee: Maciej Swiderski
There appear to be some classloading errors in kie-server.war.
First, you get multiple warnings like this:
{{11:58:47,603 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-api.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-core-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,606 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-impl-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-core.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,644 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015960: Class Path entry jaxb-impl.jar in /opt/eap/standalone/deployments/kie-server.war/WEB-INF/lib/jaxb-xjc-2.2.11.jar does not point to a valid jar for a Class-Path reference.
11:58:47,713 WARN [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015893: Encountered invalid class name 'org.xmlpull.mxp1.MXParser,org.xmlpull.mxp1_serializer.MXSerializer' for service type 'org.xmlpull.v1.XmlPullParserFactory'}}
The above was noticed as part of CLOUD-421. Please refer to the jira issue and note Kev's comment, {quote}"The jaxb jars are duplicates that are unnecessary in the EAP deployments however the upstream war file contains all dependencies. Removing the jaxb jars from within the kie-server.war/WEB-INF/lib directory will likely work however I'm loathed to do this since we would need to verify this through the BRMS QE team.
bq. The warning about the parser is caused by the kie-server.war/WEB-INF/lib/xpp3_min-1.1.4c.jar"{quote}
Second, if kjar model classes contain certain annotations, it seems to trigger the kie-server to try to load osgi classes. For example, annotating kjar model classes with Position, PropertyReactive, and Remotable as per this test case:
http://git.app.eng.bos.redhat.com/git/xpaas-qe.git/tree/test-brms/src/tes...
, you end up with errors like this in the log when the KieContainer is being installed:
{{Caused by: java.lang.NoClassDefFoundError: org/osgi/util/tracker/ServiceTrackerCustomizer
at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.8.0_65]
at java.lang.ClassLoader.defineClass(ClassLoader.java:760) [rt.jar:1.8.0_65]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:361) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:482) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 77 more
Caused by: java.lang.ClassNotFoundException: org.osgi.util.tracker.ServiceTrackerCustomizer from [Module "deployment.kie-server.war:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:459) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:408) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:389) [jboss-modules.jar:1.3.7.Final-redhat-1]
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:134) [jboss-modules.jar:1.3.7.Final-redhat-1]
... 81 more}}
The above was noticed as part of CLOUD-418. To get around this issue, I had to add a kie-server.war/WEB-INF/jboss-deployment-structure.xml like so:
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure>
<deployment>
<dependencies>
<module name="org.osgi.core"/>
<module name="org.osgi.enterprise"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (DROOLS-1003) incongruous security granularity in kie-server
by David Ward (JIRA)
David Ward created DROOLS-1003:
----------------------------------
Summary: incongruous security granularity in kie-server
Key: DROOLS-1003
URL: https://issues.jboss.org/browse/DROOLS-1003
Project: Drools
Issue Type: Bug
Components: kie server
Affects Versions: 6.3.0.Final
Reporter: David Ward
Assignee: Maciej Swiderski
The KIE Server provides two endpoints: HTTP/REST and JMS. By default, there is a "kie-server" role that one must have to perform operations through either endpoint. But by having this role, you can do *anything* in a very coarse-grained fashion.
Luckily, the HTTP/REST endpoint can be modified by changing the kie-server.war/WEB-INF/web.xml, and adding/modifying the security constraints. For OpenShift purposes, this has been done to disallow creating and disposing containers, while still allowing for reading status and executing rules. This is because REST url-patterns can be filtered per various operations and also with different http-methods. (See attached web.xml for an example.)
However, the JMS endpoint has no such capability. There is only one request queue with appserver security on it on a coarse-grained level, and no way to filter the messages as can be done via the HTTP/REST endpoint.
I have an idea that might help? Clients invoke the server via serializing and sending in Command objects, and those objects themselves are fine-grained (they are named things like "CallContainerCommand" and "DisposeContainerCommand"). If the incoming messages could propagate some kind of property of who the caller was, then the server-side could do a isCallerInRole/isUserInRole to determine if that user is authorized to invoke that particular command before doing so. Just a brainstorming idea.
Here is an example of the server handling the commands:
https://github.com/droolsjbpm/droolsjbpm-integration/blob/6.2.x/kie-serve...
The desired goal would be that developers (like myself) would not have to edit the kie-server.war/WEB-INF/web.xml, and that the same level of security granularity would already be available out-of-the-box for both the HTTP/REST and JMS interfaces. All that would be left for us would be to grant users the appropriate roles.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5820) Rename urn:delivery-active schema namespace to urn:delivery
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5820?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-2301 to WFLY-5820:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5820 (was: JBEAP-2301)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Clustering
EJB
(was: Clustering)
(was: EJB)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.ER2 (Beta))
> Rename urn:delivery-active schema namespace to urn:delivery
> -----------------------------------------------------------
>
> Key: WFLY-5820
> URL: https://issues.jboss.org/browse/WFLY-5820
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR4
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> This schema is no longer just used for the delivery active flag, but also for associating a delivery group. The current schema name is confusing.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1188) Exiting CLI requires stty sane command to be issued on Linux
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1188?page=com.atlassian.jira.plugi... ]
Ståle Pedersen edited comment on WFCORE-1188 at 12/8/15 7:07 PM:
-----------------------------------------------------------------
Hi, i've debugged a bit and it seems that jboss-cli call Console.stop() in æsh correctly, but it calls System.exit(..) before all of the threads in æsh have finished with the cleanup which is why the terminal is not reset correctly.
Adding a Thread.sleep(200) to CliLauncher before System.exit(..) fixes the issue and verifies what i'm seeing.
was (Author: stalep):
Hi, i've debugged a bit and it seems that jboss-cli call Console.stop() in æsh correctly, but it calls System.exit(..) before all of the threads in æsh have finished with the cleanup which is why the terminal is not reset correctly.
> Exiting CLI requires stty sane command to be issued on Linux
> ------------------------------------------------------------
>
> Key: WFCORE-1188
> URL: https://issues.jboss.org/browse/WFCORE-1188
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.4.Final
> Environment: Fedora 23
> Linux 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 GNU/Linux
> openjdk version "1.8.0_65"
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
> Reporter: James Perkins
> Assignee: Alexey Loubyansky
>
> The PR https://github.com/wildfly/wildfly-core/pull/1268/ seemed to have introduced a regression where some times (seems to be most in my case) {{stty sane}} is required to get a shell back to normal. My guess is it's the aesh upgrade, but I'm not certain on that so I'll start the JIRA here and it can be moved to AESH if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1188) Exiting CLI requires stty sane command to be issued on Linux
by Ståle Pedersen (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1188?page=com.atlassian.jira.plugi... ]
Ståle Pedersen commented on WFCORE-1188:
----------------------------------------
Hi, i've debugged a bit and it seems that jboss-cli call Console.stop() in æsh correctly, but it calls System.exit(..) before all of the threads in æsh have finished with the cleanup which is why the terminal is not reset correctly.
> Exiting CLI requires stty sane command to be issued on Linux
> ------------------------------------------------------------
>
> Key: WFCORE-1188
> URL: https://issues.jboss.org/browse/WFCORE-1188
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Affects Versions: 2.0.4.Final
> Environment: Fedora 23
> Linux 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 GNU/Linux
> openjdk version "1.8.0_65"
> OpenJDK Runtime Environment (build 1.8.0_65-b17)
> OpenJDK 64-Bit Server VM (build 25.65-b01, mixed mode)
> Reporter: James Perkins
> Assignee: Alexey Loubyansky
>
> The PR https://github.com/wildfly/wildfly-core/pull/1268/ seemed to have introduced a regression where some times (seems to be most in my case) {{stty sane}} is required to get a shell back to normal. My guess is it's the aesh upgrade, but I'm not certain on that so I'll start the JIRA here and it can be moved to AESH if necessary.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5818) Quick redeploy vulnerable to CacheRegistry entry loss
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5818?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-5818.
------------------------------
Resolution: Rejected
> Quick redeploy vulnerable to CacheRegistry entry loss
> -----------------------------------------------------
>
> Key: WFLY-5818
> URL: https://issues.jboss.org/browse/WFLY-5818
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added.
> This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR:
> https://github.com/wildfly/wildfly/pull/8465
> Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5819) EJB clustering 1.1 schema propagates unused clustered attribute
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5819?page=com.atlassian.jira.plugin.... ]
Paul Ferraro moved JBEAP-2299 to WFLY-5819:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-5819 (was: JBEAP-2299)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: Clustering
EJB
(was: Clustering)
(was: EJB)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.CR4
(was: 7.0.0.ER2 (Beta))
> EJB clustering 1.1 schema propagates unused clustered attribute
> ---------------------------------------------------------------
>
> Key: WFLY-5819
> URL: https://issues.jboss.org/browse/WFLY-5819
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.CR4
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
>
> Version 1.1 of the ejb clustering schema includes an obsolete "clustered" attribute which should have been removed entirely.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5818) Quick redeploy vulnerable to CacheRegistry entry loss
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-5818:
----------------------------------
Summary: Quick redeploy vulnerable to CacheRegistry entry loss
Key: WFLY-5818
URL: https://issues.jboss.org/browse/WFLY-5818
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 10.0.0.CR4
Reporter: Paul Ferraro
Assignee: Paul Ferraro
On deploy, CacheRegistry adds its local entry to the cache, and on undeploy removes it entry. However, we use a topology change listener to remove entries for crashed members (since these nodes will not have removed their local entry). However, since the listener is triggered asynchronously, it is possible that the topology change fired in response to an undeploy execute *after* the redeployed CacheRegistry starts - which would cause erroneous removal of the local entry that was added.
This manifests itself as an intermittent failure of the RegistryTestCase as seen in this PR:
https://github.com/wildfly/wildfly/pull/8465
Not surprisingly, this issue only surfaces in the windoze runs, which, according to [~ctomc], execute faster than the linux runs.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months