Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1207318

Summary: Clean up JARs providing duplicate classes in WEB-INF/lib
Product: [Retired] JBoss BRMS Platform 6 Reporter: Jiri Locker <jlocker>
Component: Business CentralAssignee: manstis
Status: CLOSED EOL QA Contact: Jiri Locker <jlocker>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.1.0CC: kverlaen, manstis
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-27 20:03:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Duplicat classes report from BRMS
none
Bash script generating duplicate classes report none

Description Jiri Locker 2015-03-30 17:04:40 UTC
Created attachment 1008620 [details]
Duplicat classes report from BRMS

Description of problem:
There are several JAR files in business-central.war/WEB-INF/lib that provide duplicate classes. It should be possible to remove at least some of them. Having duplicate class files on classpath is Bad Thing and may cause various compatibility issues.

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

How reproducible:
-

Steps to Reproduce:
1. Run attached Bash script in WEB-INF/lib, see report.

Actual results:
avalon-framework-4.1.4.jar + avalon-framework-api-4.3.1.jar
- share a lot of classes

closure-compiler-r1741.jar + js-1.7R2.jar + rhino-1.7R4.jar
- share some classes

(!) commons-io-2.1.0.redhat-4.jar + uberfire-nio2-model-0.5.0.CR13-redhat-1.jar
- share following:
org/apache/commons/io/FilenameUtils.class
org/apache/commons/io/IOCase.class

jaxrs-api-2.3.7.Final.jar + jboss-jaxrs-api_1.1_spec-1.0.1.Final-redhat-3.jar
- duplicate spec jars

js-1.7R2.jar + rhino-1.7R4.jar
- same libs

relaxngDatatype-20020414.jar + relaxngDatatype-2011.1.jar
- same libs

stax-api-1.0.1.jar + stax-api-1.0-2.jar
- same libs

xmlpull-1.1.3.1.jar + xpp3_min-1.1.4c.jar
- share following:
org/xmlpull/v1/XmlPullParser.class
org/xmlpull/v1/XmlPullParserException.class

Expected results:
Dependencies on different versions of the same artifact should be unified. Some overlays may be unavoidable?

Additional info:

Comment 1 Jiri Locker 2015-03-30 17:07:18 UTC
Created attachment 1008621 [details]
Bash script generating duplicate classes report

Usage: run ./duplicate-classes.sh in WEB-INF/lib with no arguments. View classes-jars-report.txt.

Comment 2 manstis 2015-06-01 08:57:42 UTC
Petr, this has probably already been tackled with the work you've been doing. Would you mind taking a look? Thanks, Mike

Comment 3 Petr Široký 2015-06-01 20:55:07 UTC
Some of these duplications were fixed recently, but there are still some remaining. I'll take a look at those and fix them as well.

Comment 4 Petr Široký 2015-09-23 15:30:42 UTC
Some fixes were done directly in jbpm-designer where they originated:

6.3.x commits:
https://github.com/droolsjbpm/jbpm-designer/commit/9007ee6f3dca8
https://github.com/droolsjbpm/jbpm-designer/commit/b8fb077cb6e78

There is still few more duplicated classes that need to be fixed.

Comment 5 Petr Široký 2015-09-24 16:10:38 UTC
Additional commit, removing duplicated JAXRS api jar from Tomcat distro.

(6.3.x)
https://github.com/droolsjbpm/kie-wb-distributions/commit/b165b256696b8b

Comment 6 Petr Široký 2015-09-24 22:10:05 UTC
One more commit:

(6.3.x)
https://github.com/droolsjbpm/jbpm-designer/commit/47549896082dd0ef1


I also found out that we can't fix the duplicated classes in the following use case

xmlpull-1.1.3.1.jar + xpp3_min-1.1.4c.jar
- share following:
org/xmlpull/v1/XmlPullParser.class
org/xmlpull/v1/XmlPullParserException.class

These are both dependencies of XStream and according to XStream developers this would need to fixed in those deps, which likely won't happen. The classes are identical, so it should not cause any runtime issues. See http://scm.xstream.codehaus.narkive.com/8j7QHtCd/jira-xstr-689-xstream-defines-1-4-2-defines-dependencies-on-xmlpull-and-xpp3-min-which-contain, there is reply from one of the XStream developers:

"
Unfortunately the xpp3_min jar contains only half of the required stuff of the official xmlpull API. Without the xmlpull jar the instantiation of the XppDriver (actually the XppReader) will fail, because the XmlPullParserFactory is missing.

It would be nice to get an xpp3_min jar that either contains nothing of xmlpull or all of it. However, as long as this is not available, nothing can be done.

If you use the Xpp3Driver directly, you can exclude the xmlpull dependency yourself. In that case the factory is not required.
"

Comment 7 Petr Široký 2015-10-01 21:47:54 UTC
Just a quick update: I am in a process of testing following Maven enforcer rule: http://www.mojohaus.org/extra-enforcer-rules/banDuplicateClasses.html which would catch these duplications during buildtime. If everything goes well I will add that rule and then we should be able to get rid of these kind of issues once and for all.

Comment 8 Petr Široký 2015-12-08 09:41:51 UTC
Update: Fixing the issues found by the enforcer rule is proving to be far more difficult than expected. I am about half way done, with changes stashed locally. I will be continuing with this work, but I don't know when this will be done.