[infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading

[Manik Surtani]

On 13 Sep 2011, at 00:03, Sanne Grinovero wrote:

> Hi,
> I'm not suggesting that the classloader is completely ignored; it is
> indeed evaluated at the first invocation but then if the following
> method is invoked again with a different classloader as argument, it
> will return the previously cached value:
> 
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/org/infinispan/util/ModuleProperties.java#L135
> 
> Note that the method you pointed to is private, and is actually a
> helper for the public methods, which does cache all of it's results in
> static fields.
> 
> So assuming this will be invoked by a single classloader only, indeed
> there are no issues. But is that really the case?
> Wasn't the purpose of the classloader parameter to load extensions
> from a deployed application? If so, it seems I can't deploy two
> different applications both attempting to start an Infinispan
> cachemanager.

Well, why would the class loader in this case make a difference, unless you are in an OSGi environment?  Remember that this isn't used to load application classes.  Just Infinispan module classes.  In this case the OSGi file lookup should be able to handle the appropriate loader for each bundle/module.  Will need to make sure this works for JBoss AS 7 modules too.

> 
> For example, I suspect that you won't be able to deploy an Hibernate
> Search application (or Infinispan Query) and then deploy a Hibernate
> OGM based application in the same container.
> But this is not proven as I didn't try it out, so maybe my assumptions
> about what the goal of this classloader parameter are wrong.

Ah ok, I think I see your problem: that some infinispan modules are bundled with an application, using an application-scoped class loader (a web app)?  Ok, I can see how that could be a problem then.

> So I think that, iff we need to cache this information, it shouldn't
> be cached in a static field, as discussed as well on

Well, the purpose of caching this info is to prevent each new named Cache from re-reading module properties.  Each named cache only reads these properties once at startup, so caching this is useless if this isn't shared across named caches.  Or perhaps we maintain one such module cache per class loader passed in?

Cheers
Manik
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org