[hibernate-dev] Modules for WildFly -> wrong Infinispan being injected?

[Sanne Grinovero]

I'm attempting to update Hibernate Search to use the latest Infinispan
7.0.0.Alpha4.

One of the notable changes in this Infinispan version is that the class

  org.infinispan.configuration.parsing.Parser60

was dropped, having now only a Parser70 implementation (which forces
you to rewrite all configuration files in a new format).

In my direct dependencies I'm listing exclusively Infinispan modules
having slot=7.0, so to load Infinispan dependencies from the custom
modules provided by the latest Infinispan tag.
Still I'm getting this exception when running our Arquillian integration tests:

Caused by: java.util.ServiceConfigurationError:
org.infinispan.configuration.parsing.ConfigurationParser: Provider
org.infinispan.configuration.parsing.Parser60 not a subtype
   at java.util.ServiceLoader.fail(ServiceLoader.java:231) [rt.jar:1.7.0_51]
   at java.util.ServiceLoader.access$300(ServiceLoader.java:181)
[rt.jar:1.7.0_51]
   at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:369)
[rt.jar:1.7.0_51]
   at java.util.ServiceLoader$1.next(ServiceLoader.java:445) [rt.jar:1.7.0_51]
   at org.infinispan.commons.util.ServiceFinder.addServices(ServiceFinder.java:60)
   at org.infinispan.commons.util.ServiceFinder.load(ServiceFinder.java:42)
   at org.infinispan.configuration.parsing.ParserRegistry.<init>(ParserRegistry.java:52)
   at org.hibernate.search.infinispan.impl.InfinispanConfigurationParser.<init>(InfinispanConfigurationParser.java:37)
[hibernate-search-infinispan-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
   at org.hibernate.search.infinispan.DefaultCacheManagerService.start(DefaultCacheManagerService.java:86)
[hibernate-search-infinispan-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
   at org.hibernate.search.engine.service.impl.StandardServiceManager$ServiceWrapper.startService(StandardServiceManager.java:255)
[hibernate-search-engine-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]

Parser60 is nowhere to be found across the dependencies I'm explicitly
listing; I'm guessing it's being injected on the classpath via the
dependency to Hibernate:main ?

Infinispan has similar integration tests for the modules, and this
wasn't catched there so I assume the difference of "being an Hibernate
application" could be something to explore.

I think this is probably not a new issue, but could have been hidden
previously: until previous Alpha releases of Infinispan a Parser60 was
actually being included, so I think in that case the explicit
dependency would have taken priority - by design or by luck. Also,
previous Infinispan releases had a less dramatic approach and would
include older parser implementations to keep backwards compatibility.

I'm confused at this point; I don't think it's expected for an
Hibernate user to get Infinispan classes on its classpath; I
understand Hibernate might need to load 2nd level cache, but this
should be an internal detail not exposed to modules consuming the ORM,
right?

I don't think I have ways to put exclusions in place, so I'm stuck;
hopefully I'm doing something wrong in my branch HSEARCH-1594 .. I'll
check again tomorrow but if someone is willing to have a look at what
I'm doing that would be great.

Sanne