Bug 1266831 - Spring package split into remote and embedded
Spring package split into remote and embedded
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan (Show other bugs)
Unspecified Unspecified
unspecified Severity low
: ER3
: 6.6.0
Assigned To: Tristan Tarrant
Martin Gencur
Depends On:
  Show dependency treegraph
Reported: 2015-09-28 02:57 EDT by Sebastian Łaskawiec
Modified: 2018-02-07 19:24 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
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 ISPN-5903 Major Resolved Spring package split 2017-08-16 02:09 EDT

  None (edit)
Description Sebastian Łaskawiec 2015-09-28 02:57:51 EDT
Description of problem:
Connected issue: https://bugzilla.redhat.com/show_bug.cgi?id=1264840

Currently Spring package contains references to both Remote and Embedded JDG classes. This causes many problems like BZ1264840. The best way to deal with it is to split Uber Jar Spring package into two pieces - remote and embedded.
Comment 7 Vaclav Dedik 2015-12-01 04:35:08 EST
Looks like class org.infinispan.commons.logging.BasicLogFactory is loaded twice from two packages, once from infinispan-commons (transitive dependency of infinispan-spring4-remtote) and once from infinispan-remote. The class in infinispan-remote is modified by prefixing org.jboss.logging.BasicLogger with "infinispan." -> infinispan.org.jboss.logging.BasicLogger.

So when spring is loading ConsistentHashV1 from hotrod client, it hits the line where:

private static final BasicLogger log = BasicLogFactory.getLog(ConsistentHashV1.class);

The problem is that it picks up BasicLoggerFactory from infinispan-commons, which returns org.jboss.logging.BasicLogger, but the hotrod client is from infinispan-remote, which means it requires infinispan.org.jboss.logging.BasicLogger. If you exclude infinispan-commons from infinispan-spring4-remote, it works. If you move the dependency declaration of infinispan-spring4-remote in pom.xml below infinispan-remote, it works as well, my guess is that spring picks up the class that is added on the class path first.

So while I think I understand exactly what is going on, I am not yet sure how to fix this, therefore moving target milestone to CR1.
Comment 8 Sebastian Łaskawiec 2015-12-01 07:09:48 EST
Changing severity to low since there is an easy work around:

Switch the order of dependencies (uber jar needs to go first - classpath is being scanned from left to right):


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