Re: [infinispan-dev] ISPN-1374 and ModuleProperties, static collections and class loading
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/o...
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(a)jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org