[infinispan-dev] Removal of ConfigurationBuilder.classLoader(...)

[Dan Berindei]

Hi Paul

As we discussed on IRC yesterday, our plan is to support multiple
CacheManagers using the same JGroups transport with FORK. If each
deployment has its own CacheManager, there's no need for a cache-specific
classloader.

That being said, ISPN-4639 and ISPN-3979 are indeed bugs and we should fix
them for Beta2.

Cheers
Dan


On Wed, Aug 13, 2014 at 6:29 PM, Paul Ferraro <paul.ferraro at redhat.com>
wrote:

> 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/39a21a025db2e0f85019b93d09052b4772abbaa8
>
> 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/org/infinispan/configuration/cache/IndexingConfigurationBuilder.java#L141
>
> 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/org/infinispan/configuration/cache/IndexingConfigurationBuilder.java#L183
>
> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140819/fcfcf670/attachment.html