Bug 1280345 - [ENG](6.1.z) JAXB initialisation error - Several pairs of classes have the same XML type
[ENG](6.1.z) JAXB initialisation error - Several pairs of classes have the sa...
Product: JBoss BPMS Platform 6
Classification: JBoss
Component: Fuse Integration (Show other bugs)
Unspecified Unspecified
urgent Severity unspecified
: CR1
: 6.1.5
Assigned To: Edson Tirelli
Jiri Petrlik
Dawn Eisner
Depends On:
Blocks: 1281579 1281586
  Show dependency treegraph
Reported: 2015-11-11 09:23 EST by Petr Široký
Modified: 2016-10-14 10:18 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1267906
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker ENTESB-4090 Blocker Closed [Integration Pack - EAP] JAXB initialisation error - Several pairs of classes have the same XML type 2016-05-31 05:20 EDT

  None (edit)
Description Petr Široký 2015-11-11 09:23:31 EST
+++ This bug was initially created as a clone of Bug #1267906 +++

Description of problem:
The kie remote rest and jms rest is not working from switchyard components.

The switchyard components use the kie-remote-client to make this functionality working.

From Drools 6.2.0 this functionality is not working because the kie-remote-client. The reason is because this artifact can not be in the same classpath than the drools artifacts.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
git clone -c http.sslverify=false https://gitlab.mw.lab.eng.bos.redhat.com/jbossqe-soa/jbossqe-fsw-it.git

cd jbossqe-fsw-it

git checkout JBQA-9702_create-remote-bpms-api-test

mvn clean install -Pjboss-eap,bxms -pl :remote-bpms-api-test -am -Ddisable.groovy.compiler=true -Dversion.bom.fuse=6.2.1.redhat-020 -Dversion.switchyard=2.0.1.redhat-621020 -Dversion.fuse.integration=1.1.0.redhat-020

Actual results:

Expected results:

Additional info:

--- Additional comment from JBoss Product and Program Management on 2015-10-01 07:20:08 EDT ---

Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

--- Additional comment from Alessandro Lazarotti on 2015-10-01 10:15:44 EDT ---

David see that Drools 6.2 (BRMS 6.1) does not support Remote API. It only targets 
runtime engine executions. 

For Drools 6.3 (BRMS 6.2) we expect to have the features for kie-remote-clients properly available in drools-karaf-features.xml and jars being properly "OSGFied":


The related BZ for this enhancement is :

Is not Fuse 6.2.1 supposed to be tested with BxMS 6.2 instead of 6.1 ? Why the tests are using Drools 6.2 instead of 6.3 ? Or this is a confusion about what mean Drools 6.2 versus BxMS 6.2 ?

I set this BZ as a blocker for BxMS 6.2.

--- Additional comment from David Virgil on 2015-10-01 10:49:57 EDT ---

Hi Alessandro.

The tests done by the qe have been with the previous fuse ER. The previous Fuse 6.2.1 ER tests were using our 1.1.x Fuse Integration Branch that was compatible with the 6.2.x Drools branch.

The tests done by the qe, are included here:


The tests are done using EAP 6.4

This error is happening in version 6.2.x and 6.3.x of drools.

--- Additional comment from Alessandro Lazarotti on 2015-10-01 10:50:54 EDT ---

what I said above is true for Fuse deployment, but by the mvn cmd it seems that you are testing in EAP. If it is the case, so we need to look a fix even for BxMS 6.1

--- Additional comment from JBoss Product and Program Management on 2015-10-01 14:02:36 EDT ---

This bug report previously had all acks and release flag approved.
However since at least one of its acks has been changed, the
release flag has been reset to ? by the bugbot (pm-jboss). The
ack needs to become approved before the release flag can become
approved again.

--- Additional comment from Marco Rietveld on 2015-10-26 09:19:08 EDT ---

Work on this BZ has been tabled pending the outcome of a discussion among the BxMS and Fuse PM's and other involved parties.

--- Additional comment from Marco Rietveld on 2015-11-05 14:01:15 EST ---



fuse-bxms-integ master:

fuse-bxms-integ 1.2.x:

--- Additional comment from Edson Tirelli on 2015-11-05 14:59:30 EST ---

Additional commits:

6.3.x: http://github.com/droolsjbpm/drools/commit/d84285c7a

master: http://github.com/droolsjbpm/drools/commit/55e49ccf2
Comment 3 Marco Rietveld 2015-11-25 07:57:46 EST
Fixed. This is fuse-specific problem for community 6.2.x/product 6.1.x, and not related to the drools/jbpm code. 


Comment 4 Jiri Petrlik 2015-12-16 11:40:54 EST
Verification of this bug requires integration package build.
Comment 6 Jiri Petrlik 2016-01-06 06:32:58 EST
The verification of this bug is currently blocked by this issue [1].

[1] https://issues.jboss.org/browse/ENTESB-4492
Comment 7 Jiri Petrlik 2016-01-06 10:34:57 EST
Commits with fix are missing in BxMS 6.1.5.CR2 tag. They are on master and 6.3.x branches only.
Comment 8 Marco Rietveld 2016-01-06 10:55:48 EST
*No* commits in the BxMS code are required to fix this issue! 

The short story is as follows: the Fuse integration code "hacked" (deeply) internal classes in the kie-remote-client, and when those internal classes changed, the Fuse integration code broke. The fix is simply to remove these hacks. 

The commit that does this can be found here: 


The longer story is that, because of some confusion, I ended up changing BxMS code in order to support functionality that the Fuse integration code was using: however, this "functionality" was 1. _never_ supported and 2. it's questionable if that functionality ever worked in the first place. In an ideal world, I would have reverted all of the commits above, but because of time pressures and other factors, they've been left in. 

I hope this helps.
Comment 9 Jiri Petrlik 2016-01-06 11:36:26 EST
Thank you for help, but I did not find this commit [1] in "intpkg-1.0.0.redhat-620150" tag. This commit is present only in branches 1.2.x and 1.3.x of fuse-bxms-integ. This bugzilla is for BxMS 6.1.5 which corresponds to branches 1.0.x and 1.1.x. The fix seems to be not present here [2].

[1] https://github.com/jboss-integration/fuse-bxms-integ/commit/619c2224
[2] https://github.com/jboss-integration/fuse-bxms-integ/blob/1.0.x/switchyard/switchyard-component-common-knowledge/src/main/java/org/switchyard/component/common/knowledge/config/builder/RemoteConfigurationBuilder.java
Comment 11 Jiri Petrlik 2016-01-07 04:22:44 EST
Hello David,
yes commit is pressent on the branch 1.1.x. Unfortunately it is not cherry picked on branch 1.0.x and the current integration pack was build using brach 1.0.x. Here is the link on integration package [1] for BxMS 6.1.5.CR2.

[1] http://dev138.mw.lab.eng.bos.redhat.com/candidate/intpkg-1.0.0.redhat-620150/
Comment 12 Ryan Zhang 2016-01-07 04:40:38 EST
Yes, I believe that Michael's create the tags from 1.0.x branch which is combination for Fuse 6.2.0+BRMS 6.1.5.
I also can't see the commit in 1.0.x branch though it present in 1.1.x, 1.2.x and 1.3.x.
Comment 13 Alessandro Lazarotti 2016-01-12 11:59:13 EST
We will release today the Patch Update 6.2.1.
The bug is not a blocker and can be delivered for 6.2.2, so no rebuild is necessary.
Comment 14 Alessandro Lazarotti 2016-01-12 11:59:55 EST
>  We will release today the Patch Update 6.2.1.
I mean, 6.1.5
Comment 15 Alessandro Lazarotti 2016-01-12 12:11:35 EST
My bad, since it is the last patch update for BxMS 6.1.5 and Fuse 6.2.0, and it is already fixed for BxMS 6.2.0 + Fuse 6.2.1 (Bug 1267906) - then this is the last chance to have it in the first combination mentioned before.

Let's  rebuild to get it in still for Integration Pack B6.1.5 x F6.2.0 release.
Comment 16 Edson Tirelli 2016-01-13 12:47:08 EST
During the PM call, it was decided that a new tag will be created from branch 1.1.x, that already includes the fix. 

Setting this ticket to MODIFIED.
Comment 17 Ryan Zhang 2016-01-14 05:37:09 EST
(In reply to Edson Tirelli from comment #16)
> During the PM call, it was decided that a new tag will be created from
> branch 1.1.x, that already includes the fix. 
> Setting this ticket to MODIFIED.

OK. Does it mean that we should use the combination build from 1.1.x to replace the one for 1.0.x?

@Michael, could you please prepare the tag based on 1.1.x branch?
Comment 20 Jiri Petrlik 2016-01-19 05:40:36 EST
Verified with Integration package build "1.1.0.redhat-027" and BxMS 6.1.5.

Note You need to log in before you can comment on or make changes to this bug.