Bug 806208
| Summary: | drools-camel depends on cxf 2.4.1 and needs to downgrade to 2.2.12-patch-02) | ||
|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Ryan Zhang <rzhang> |
| Component: | BRE (Expert, Fusion) | Assignee: | Julian Coleman <jcoleman> |
| Status: | VERIFIED --- | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | BRMS 5.3.0.GA | ||
| Target Milestone: | --- | ||
| Target Release: | BRMS 5.3.0.GA | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | Type: | --- | |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 839231 | ||
|
Description
Ryan Zhang
2012-03-23 08:05:59 UTC
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. |