[JBoss JIRA] (WFWIP-319) Can /tmp directory of builder image be cleared?
by Martin Choma (Jira)
[ https://issues.redhat.com/browse/WFWIP-319?page=com.atlassian.jira.plugin... ]
Martin Choma resolved WFWIP-319.
--------------------------------
Resolution: Done
> Can /tmp directory of builder image be cleared?
> -----------------------------------------------
>
> Key: WFWIP-319
> URL: https://issues.redhat.com/browse/WFWIP-319
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jean Francois Denise
> Priority: Optional
>
> This is not XP specific, but I have noticed it during XP work. I am comparing builder images of 7.3.1 and XP and diff is complaining about {{tmp/jboss-eap-7.3.1.GA-image-builder-maven-repository/licenses/}}
> I want to ask if this is necessary to have in builder image. As it is located in /tmp directory I suppose this is just working dir and can be safely deleted?
> {code}
> [jboss@f4e78430d511 licenses]$ pwd
> /tmp/jboss-eap-xp-1.0.0.GA-image-builder-maven-repository/licenses
> [jboss@f4e78430d511 licenses]$ ls
> 'apache license 1.1.txt' 'eclipse public license 1.0.txt' 'gnu lesser general public license v3.0 or later.html' 'mozilla public license 1.1.txt'
> 'apache license 2.0.txt' 'eclipse public license 2.0.txt' 'gnu lesser general public license, version 3.txt' 'mozilla public license 2.0.html'
> 'bsd 3-clause new or revised license.html' 'eclipse public license, version 1.0.txt' 'gnu library general public license v2 only.txt' 'plexus classworlds license.html'
> 'bsd 3-clause no nuclear license.html' 'fsf all permissive license.html' 'gnu library general public license, version 2.txt' 'public domain.txt'
> 'common development and distribution license 1.0.txt' 'gnu general public license v2.0 only, with classpath exception.txt' 'icu license - icu 1.8.1 to icu 57.1.txt' 'the antlr 2.7.7 license.txt'
> 'common development and distribution license 1.1.txt' 'gnu general public license, version 2 with the classpath exception.txt' 'indiana university extreme lab software license 1.1.1.html' 'the asm bsd license.txt'
> 'common development and distribution license.txt' 'gnu general public license, version 2.txt' licenses.css 'the bsd license.txt'
> 'common public license 1.0.txt' 'gnu lesser general public license v2.1 only.txt' licenses.html 'the dom4j license.txt'
> 'creative commons attribution 2.5.html' 'gnu lesser general public license v2.1 or later.html' licenses.xml 'the jaxen license.txt'
> 'creative commons zero v1.0 universal.html' 'gnu lesser general public license v2.1 or later.txt' licenses.xsl 'the jsoup mit license.html'
> 'eclipse distribution license, version 1.0.txt' 'gnu lesser general public license v3.0 only.txt' 'mit license.txt'
> {code}
> [1] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/OpenShift/job...
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2485) UDP is not working after upgarde to 3_6_19 from jgroups-3.4.0.Alpha2
by Janardhan Naidu (Jira)
[ https://issues.redhat.com/browse/JGRP-2485?page=com.atlassian.jira.plugin... ]
Janardhan Naidu commented on JGRP-2485:
---------------------------------------
Hi Ben,
I tried checking the jgroups upgrade to v3.6.19. In RHEL, it works fine i.e., cluster communication is happening without any issues.
And in Windows instance we see the issue(customer communication is not happening for UDP, We don’t see Member joined in logs and we don’t see any specific errors/exceptions also).
So do we need to have any additional properties or additional configurations to be done specific to windows to get it worked?
Can you share the sample/example code which is used to test the cluster communication in windows using jgroups 3.6.19 jars?
Thanks
Janardhan
> UDP is not working after upgarde to 3_6_19 from jgroups-3.4.0.Alpha2
> --------------------------------------------------------------------
>
> Key: JGRP-2485
> URL: https://issues.redhat.com/browse/JGRP-2485
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.19
> Reporter: Janardhan Naidu
> Assignee: Bela Ban
> Priority: Major
> Attachments: noapp.log.D20200619.T053202_NODE1
>
>
> Hi Team,
>
> we just upgraded from jgroups-3.4.0.Alpha2 to 3_6_19. post the UDP cluster communication is not working.
> after upgrade, we were hitting some warning as below and we solved those by changing property_string of UDP.
> *Warnings:*
> *WARNING: JGRP000014: Discovery.timeout has been deprecated: GMS.join_timeout should be used instead*
> [2020-06-17 14:05:49.271] ALL 000000000000 GLOBAL_SCOPE Jun 17, 2020 2:05:49 PM org.jgroups.stack.Configurator resolveAndAssignField
> *WARNING: JGRP000014: Discovery.num_initial_members has been deprecated: will be ignored*
> [2020-06-17 14:05:49.396] ALL 000000000000 GLOBAL_SCOPE Jun 17, 2020 2:05:49 PM org.jgroups.protocols.pbcast.NAKACK init
> *WARNING: use_mcast_xmit should not be used because the transport (TCP) does not support IP multicasting; setting use_mcast_xmit to false*
>
> To solve above warnings, we went through tcp.xml which was shipped using in 3_6_19 jar:
> and now our properties looks like:
> *property_string=UDP*(bind_addr=*hostIP*;bind_port=39061;mcast_addr=239.255.166.17;mcast_port=39060;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING:MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(use_mcast_xmit=true;retransmit_timeout=300,600,1200,2400,4800;discard_delivered_msgs=true):UNICAST:pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true)
>
> *distribution_property_string=TCP*(bind_port=39060;thread_pool_rejection_policy=run):TCPPING(async_discovery=true;initial_hosts=*hostIP*[39060];port_range=0;):MERGE2(min_interval=3000;max_interval=5000):FD_SOCK:FD(timeout=5000;max_tries=48):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(use_mcast_xmit=false;discard_delivered_msgs=true;):pbcast.STABLE(stability_delay=1000;desired_avg_gossip=20000;max_bytes=0):pbcast.GMS(join_timeout=5000;print_local_addr=true)
>
> *lock.protocolStack=UDP*(bind_addr=*hostIP*;bind_port=39062;mcast_addr=239.255.166.17;mcast_port=39069;ip_ttl=32;mcast_send_buf_size=150000;mcast_recv_buf_size=80000):PING:MERGE2(min_interval=5000;max_interval=10000):FD_ALL(interval=5000;timeout=20000):VERIFY_SUSPECT(timeout=1500):pbcast.NAKACK(use_mcast_xmit=true;retransmit_timeout=300,600,1200,2400,4800):UNICAST:pbcast.STABLE(desired_avg_gossip=20000):FRAG(frag_size=8096):pbcast.GMS(join_timeout=5000;print_local_addr=true):CENTRAL_LOCK(num_backups=2)
>
>
> With above properties, we are not seeing any warning or error. But still cluster communication is not working with UDP.
> Please help me in resolving the same
>
> Thank
> Janardhan
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFLY-11115) bumpTimeout method usage in InMemorySessionManager
by Marek Kopecky (Jira)
[ https://issues.redhat.com/browse/WFLY-11115?page=com.atlassian.jira.plugi... ]
Marek Kopecky commented on WFLY-11115:
--------------------------------------
[~swd847] It seems that this issue is fixed in WF20 by UNDERTOW-1419 and can be resolved now. (cc [~manovotn])
> bumpTimeout method usage in InMemorySessionManager
> --------------------------------------------------
>
> Key: WFLY-11115
> URL: https://issues.redhat.com/browse/WFLY-11115
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 14.0.1.Final, 15.0.0.Beta1
> Reporter: Adam Krajcik
> Assignee: Stuart Douglas
> Priority: Major
>
> Possible bug as mentioned in https://developer.jboss.org/thread/278634. As mentioned in the thread, use of bumpTimeout may cause a session that may never expire.
> From [~jstourac]:
> {quote}
> The list of methods where 'bumpTimeout' is actually used in [InMemorySessionManager|https://github.com/undertow-io/undertow/blob/maste...] to following: createSession(), setMaxInactiveInterval(), getAttribute(), getAttributeNames(), setAttribute(), removeAttribute(). From this list usage in following methods is suspicious: getAttribute(), getAttributeNames(), setAttribute(), removeAttribute().
> All occurrences were added by [this commit|https://github.com/undertow-io/undertow/commit/be768b6cb98c13f02df...] with initial session timeout implementation.
> The truth is the [Servlet 4.0, section 7.5|https://javaee.github.io/servlet-spec/downloads/servlet-4.0/servlet-4_0_FINAL.pdf] specification (Servlet 3.1 is almost identical) specifies that timeout depends on user activity only:
> "This means that the only mechanism that can be used to indicate when a client is no longer active is a time out period."
> {quote}
> Response from [~stuartdouglas] from mail:
> {quote}
> We could probably change that to just update the timeout in requestDone().
> {quote}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (WFCORE-5049) Ensure any java.security.Policy is registered before PolicyConfigurationFactory
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFCORE-5049?page=com.atlassian.jira.plug... ]
Darran Lofthouse updated WFCORE-5049:
-------------------------------------
Description:
A PolicyConfigurationFactory may want to consult the Policy so ensure it is installed first.
This comes up within the Jakarta EE TCK where the test PolicyConfigurationFactory consults the underlying registered Policy.
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/...
{code}
12:11:00,728 ERROR [stderr] (MSC service thread 1-3) java.lang.ClassCastException: org.jboss.modules.ModulesPolicy cannot be cast to com.sun.ts.tests.jacc.provider.TSPolicy
12:11:00,728 ERROR [stderr] (MSC service thread 1-3) at com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl.getTSLogger(TSPolicyConfigurationFactoryImpl.java:229)
12:11:00,729 ERROR [stderr] (MSC service thread 1-3) at com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl.getPolicyConfigurationFactory(TSPolicyConfigurationFactoryImpl.java:159)
12:11:00,729 ERROR [stderr] (MSC service thread 1-3) at com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl.<init>(TSPolicyConfigurationFactoryImpl.java:53)
12:11:00,729 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
{code}
was:
A PolicyConfigurationFactory may want to consult the Policy so ensure it is installed first.
This comes up within the Jakarta EE TCK where the test PolicyConfigurationFactory consults the underlying registered Policy.
https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/...
> Ensure any java.security.Policy is registered before PolicyConfigurationFactory
> -------------------------------------------------------------------------------
>
> Key: WFCORE-5049
> URL: https://issues.redhat.com/browse/WFCORE-5049
> Project: WildFly Core
> Issue Type: Task
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 13.0.0.Beta2
>
>
> A PolicyConfigurationFactory may want to consult the Policy so ensure it is installed first.
> This comes up within the Jakarta EE TCK where the test PolicyConfigurationFactory consults the underlying registered Policy.
> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/...
> {code}
> 12:11:00,728 ERROR [stderr] (MSC service thread 1-3) java.lang.ClassCastException: org.jboss.modules.ModulesPolicy cannot be cast to com.sun.ts.tests.jacc.provider.TSPolicy
> 12:11:00,728 ERROR [stderr] (MSC service thread 1-3) at com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl.getTSLogger(TSPolicyConfigurationFactoryImpl.java:229)
> 12:11:00,729 ERROR [stderr] (MSC service thread 1-3) at com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl.getPolicyConfigurationFactory(TSPolicyConfigurationFactoryImpl.java:159)
> 12:11:00,729 ERROR [stderr] (MSC service thread 1-3) at com.sun.ts.tests.jacc.provider.TSPolicyConfigurationFactoryImpl.<init>(TSPolicyConfigurationFactoryImpl.java:53)
> 12:11:00,729 ERROR [stderr] (MSC service thread 1-3) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by Karel Suta (Jira)
[ https://issues.redhat.com/browse/DROOLS-1004?page=com.atlassian.jira.plug... ]
Karel Suta commented on DROOLS-1004:
------------------------------------
Fine for me.
> classloading errors in kie-server
> ---------------------------------
>
> Key: DROOLS-1004
> URL: https://issues.redhat.com/browse/DROOLS-1004
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> 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}
> The jboss-bpmsuite-6.2.0.GA-redhat-1-deployable-eap6.x.zip file (from which we extract the kie-sever.war) is seemingly an EAP-specific build (thus the -eap6.x suffix). So perhaps the fix would be to have the kie-server.war already come pre-configured to contain (or better yet, depend upon the existing modules) jars in EAP for both the above problems (incorrect jaxb/xmlpull references, and missing osgi dependencies).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (JGRP-2274) ASYM_ENCRYPT: deprecate sign_msgs
by Bela Ban (Jira)
[ https://issues.redhat.com/browse/JGRP-2274?page=com.atlassian.jira.plugin... ]
Bela Ban commented on JGRP-2274:
--------------------------------
[~nsawadsky]: the above config doesn't work:
{noformat}
java.security.InvalidAlgorithmParameterException: Unsupported parameter: javax.crypto.spec.IvParameterSpec@d5acec0
at com.sun.crypto.provider.CipherCore.init(CipherCore.java:520) ~[?:?]
at com.sun.crypto.provider.AESCipher.engineInit(AESCipher.java:346) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1442) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1375) ~[?:?]
at org.jgroups.protocols.Encrypt.initCipher(Encrypt.java:262) ~[classes/:?]
at org.jgroups.protocols.Encrypt.code(Encrypt.java:361) ~[classes/:?]
at org.jgroups.protocols.Encrypt.encrypt(Encrypt.java:350) ~[classes/:?]
at org.jgroups.protocols.Encrypt.down(Encrypt.java:149) ~[classes/:?]
{noformat}
> ASYM_ENCRYPT: deprecate sign_msgs
> ---------------------------------
>
> Key: JGRP-2274
> URL: https://issues.redhat.com/browse/JGRP-2274
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Major
> Fix For: 4.0.12
>
>
> In {{ASYM_ENCRYPT}}, signing messages means that the checksum of an encrypted message is computed and used together with the secret key of the sender to sign the message. On the receiver side, the public key of the sender is used to validate the signature.
> However, this is redundant, as decryption of a message will fail if the contents have been changed.
> If needed, signing of messages can be done in a separate protocol.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months
[JBoss JIRA] (DROOLS-1004) classloading errors in kie-server
by Toshiya Kobayashi (Jira)
[ https://issues.redhat.com/browse/DROOLS-1004?page=com.atlassian.jira.plug... ]
Toshiya Kobayashi commented on DROOLS-1004:
-------------------------------------------
Thank you for the reply, [~dward] and [~ksuta] . As Maciej commented before, we cannot do much about jaxb warnings. Is it okay to close this JIRA now?
> classloading errors in kie-server
> ---------------------------------
>
> Key: DROOLS-1004
> URL: https://issues.redhat.com/browse/DROOLS-1004
> Project: Drools
> Issue Type: Bug
> Components: kie server
> Affects Versions: 6.3.0.Final
> Reporter: David Ward
> Assignee: Toshiya Kobayashi
> Priority: Major
>
> 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}
> The jboss-bpmsuite-6.2.0.GA-redhat-1-deployable-eap6.x.zip file (from which we extract the kie-sever.war) is seemingly an EAP-specific build (thus the -eap6.x suffix). So perhaps the fix would be to have the kie-server.war already come pre-configured to contain (or better yet, depend upon the existing modules) jars in EAP for both the above problems (incorrect jaxb/xmlpull references, and missing osgi dependencies).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 2 months