When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL).

In this case if the configuration file refers to any extension such as a CacheStore, Infinispan will fail to start as it doesn't depend on the modules of its extensions.

This will cause puzzling errors such as :

ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.

For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past:

Explicit classloader support during parsing was introduced in 2013:

• http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html

Then removed again in 2014:

• http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html

I asked for improvements and hoped for someone to take ownership:

• http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html

In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did.

Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL.

My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them.
In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them.

But NadirX doesn't like that, so assigning the issue to him

Alternative ideas:

• allow people to mention module names explicitly in the Infinispan configuration?
• have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI

I favour the second option, especially as it came up before as a dire pratical need for many other situations.