It seems that the ability to associate a cache with a specific classloader has been removed in 7.0 by this commit: https://github.com/infinispan/infinispan/commit/39a21a025db2e0f85019b93d0... I don't fully understand the reason for the removal. WildFly previously relied on this mechanism to define the classloader from which Infinispan should load any classes when building its configuration. In general, WF builds its configuration using object instances instead of class names, so normally this isn't a problem. However, there isn't always such a mechanism (e.g. https://issues.jboss.org/browse/ISPN-3979) However, now that ConfigurationBuilder.classloader(...) is gone, the classloader used to build a Configuration is effectively hardcoded (usually as this.getClass().getClassLoader()). This directly affects the ability for a WildFly using to configure a cache with querying. IndexingConfigurationBuilder.validate(...) previously used the configured classloader to validate that the query module is loadable. https://github.com/infinispan/infinispan/blob/6.0.x/core/src/main/java/or... However, this is now hardcoded to use the classloader that loaded the IndexingConfigurationBuilder class itself. https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o... The WF distribution uses distinct modules for infinispan-core vs infinispan-query. Consequently, if your cache don't need querying, the query module is not loaded. WF8 let the user configure a cache with query support via <distributed-cache ... module="org.infinispan.query"/>. Currently, however, the only way we can satisfy the validation logic in IndexingConfigurationBuilder.validate(...) is to bloat our core "org.infinispan" module with the infinispan-query module and its dependencies. I don't want to do that. Is there some way we can re-enable the ability to configure a cache with a classloader that still satisfies the reasons for its original removal? GlobalConfigurationBuilder still supports the ability to configure a classloader, why remove this from ConfigurationBuilder? That said, however, the IndexingConfigurationBuilder validation itself is wrong. Ultimately, the infinispan-query module will be loaded by the classloader with which the GlobalConfiguration was built (i.e. the default classloader of the cache), so really, at the very least, the validation logic in IndexingConfigurationBuilder.validate(...) should reflect this. I've opened https://issues.jboss.org/browse/ISPN-4639 to track this specific bug. Thoughts? _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev