Bug 1266831 - Spring package split into remote and embedded
Summary: Spring package split into remote and embedded
Keywords:
Status: VERIFIED
Alias: None
Product: JBoss Data Grid 6
Classification: JBoss
Component: Infinispan
Version: 6.6.0
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ER3
: 6.6.0
Assignee: Tristan Tarrant
QA Contact: Martin Gencur
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-09-28 06:57 UTC by Sebastian Łaskawiec
Modified: 2023-05-31 23:39 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker ISPN-5903 0 Major Resolved Spring package split 2017-08-16 06:09:22 UTC

Description Sebastian Łaskawiec 2015-09-28 06:57:51 UTC
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 09:35:08 UTC
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 12:09:48 UTC
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):

<dependency>
  <groupId>org.infinispan</groupId>
  <artifactId>infinispan-remote</artifactId>
  <version>6.4.0-redhat-SNAPSHOT</version>
  </dependency>
<dependency>
  <groupId>org.infinispan</groupId>
  <artifactId>infinispan-spring4-remote</artifactId>
  <version>6.4.0-redhat-SNAPSHOT</version>
</dependency>


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