Red Hat Bugzilla – Bug 806208
drools-camel depends on cxf 2.4.1 and needs to downgrade to 2.2.12-patch-02)
Last modified: 2014-10-26 21:12:22 EDT
Description of problem: drools-camel depends on cxf 2.4.1 This issue is to find out the possiblity to downgrade to cxf product version 2.2.12-patch-02. Noticed that cxf version in EAP 5.1.2 is 2.2.12-patch-02. Since BRMS 5.3 needs to include drools-camel(See Bug 797068), this issue is to look for the possiblity to downgrade the cxf version in drools. Version-Release number of selected component (if applicable): BRMS 5.3.0 ER5 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I checked some things: guvnor 5.3.x depends on cxf 2.4.1+ drools-camel 5.3.x depends on cxf 2.4.1+ and camel-cxf 2.4.0+ camel-cxf 2.4.0 depends on cxf 2.2.9+. Before 5.3.x, drools-camel and guvnor used a different cxf version. drools-camel 5.2.x used cxf 2.2.9+ guvnor 5.2.x used cxf 2.3.1+ (and did not work with cxf 2.2.9 IIRC) Long story short: Before 5.3 it was a complex, broken mess. guvnor 5.2 required at least 2.3.1 to run properly without bugs, so I don't think we can downgrade below that. guvnor 5.3 and drools-camel 5.3 could only be persuaded to work on the same version by upgrading the cxf version to 2.4.1. I suggest to follow the standard practice of using the highest version (so cxf 2.4.1) at runtime. Is that possible?
jdc proposes to overwrite the CXF version in the guvnor and drools-camel-server war. The drools-camel jar is probably only used as part as the drools-camel-server war (I am not sure why they are 2 separate artifacts in the first place).
Since the above automatically happens (cxf is included in the wars) - nothing needs to happen on .org side? (correct me if I am wrong)
Ok, please fix this in the WAR that goes both inside the stand alone as well as deployable package that way we dont need to have the user do this.
drools-camel-server is really just an example war. It does not make sense to productize that as it can never be used as-is: in fact, it contains a test.drl file because it's a hello world war really. So back to square 1. - EAP bundled CXF version is impossible to change (would mean recertify) - Drools-camel requires a higher version (otherwise it has bugs) How can we solve this?
Here's the solution Lukas, Prakash and me came up with: In the product builds, only some zips should contain drools-camel.jar with cxf-2.4.1.jar (and other dependencies that drools-camel needs): - standalone.zip: No - deployable.zip: -- jboss-brms-engine.zip: Yes (drools-camel + the cxf jar that drools-camel needs) -- jboss-brms-manager.zip: n/a -- jboss-jbpm-console.zip: n/a -- jboss-jbpm-engine.zip: Yes (drools-camel + the cxf jar that drools-camel needs) QA will create a test with a custom war that includes jars from jboss-brms-engine.zip with a test camel REST config and test if it works.
To sum up the discussion Geoffrey, Prakash and me just had, this is what needs to happen. Ryan, Julian: 1) There is no need to alter EAP in any way. (Except for converting it to use CXF by default.) 2) Please bundle drools-camel.jar (+ dependencies) inside jboss-jbpm-engine.zip; otherwise users won't be able to launch their processes from Camel. (Which is a PRD requirement.) Lee, please: 3) Document how to create your own web app using drools-camel.jar. For the specific instructions on how to do it, do please ask me in an e-mail, which I consider a better place to explain this. I am assigning the issue to Julian, since I think the ball is on the productization side of the court right now.
Resolved with revision 10873 of: brms-p/pom.xml brms-p/drools-camel/pom.xml brms-p/drools-camel/src/main/assembly/brms-camel.xml Commit message: Move the drools-camel artifact and dependencies so that we can only include it in the jboss-brms-engine.zip, but exclude it elsewhere. XXX: This means that jboss-brms-engine.zip now contains multiple versions of some jars.
(In reply to comment #8) > XXX: This means that jboss-brms-engine.zip now contains multiple versions > of some jars. Which JARs? What causes this?
> XXX: This means that jboss-brms-engine.zip now contains multiple versions > of some jars. It should have the highest version of those jars, because: - Putting multiple versions of the same jar on the same classpath will shadow one of them arbitrair (or at least the classes with the same full name) - Using a lower version of a jar than required will cause errors at runtime.
Julian, Lee, If the customer's war gets deployed to EAP 5.1 with the CXF extension installed, it should also these jars to run properly on that EAP 5.1 with CXF: cxf-rt-bindings-corba-2.4.1.jar cxf-rt-management-2.4.1.jar cxf-rt-transports-jms-2.4.1.jar However, for EAP 5.1 without CXF, Tomcat, ... those jars are not needed (and overhead really). More info in https://bugzilla.redhat.com/show_bug.cgi?id=806232
Update status to ON_QA. Please verify them against ER6.
Hi Geoffrey, thanks for the heads. I take it this means it is no longer necessary for customers to create their own web app using drools-camel.jar? Thanks Lee
Server contains 2.2.12-patch-02 and Guvnor contains 2.4.1. This is what we intended, thus VERIFIED.
@lee: They still need to create their own webapp war, similar to how drools-camel-server-example (formerly known as drools-camel-server) does it. For 5.4, porcelli did build a GUI to generate such a war.
Thanks Geoffrey, I just got your email about this aswell, thanks again.