4:37 p.m.
Infinispan module loader doesn't work in OSGi environments
----------------------------------------------------------
Key: ISPN-1232
URL: https://issues.jboss.org/browse/ISPN-1232
Project: Infinispan
Issue Type: Bug
Components: Core API
Affects Versions: 5.0.0.CR7
Environment: $ uname -ovr
2.6.32-131.4.1.el6.x86_64 #1 SMP Fri Jun 10 10:54:26 EDT 2011 GNU/Linux
Reporter: Craig Ching
Assignee: Manik Surtani
We're trying to upgrade from 4.2.0.Final to 5.0.0.CR7. We run Infinispan in an
Equinox OSGi environment and are having problems loading the query module (and maybe
others, I haven't gotten beyond query at this point). What I've found in my
digging is documented in the "Forum Reference", but, in essence, it appears that
Infinispan 5.0.0.x included it's own module loader that doesn't work in OSGi
environments. The crux of the problem is that Infinispan needs to find
"infinispan-module.properties" in the query jar file, but it can't do that
by trying to load it from the system class loader as it's currently doing. I'm a
bit rusty on loading resources in OSGi, so I'm not exactly sure how to resolve it. I
would have thought that you would include the resource in a package (not the default
package) that you could export from the query module and optionally import in the core
module, but maybe there's a better way.
To get you on the right track, in:
core/src/main/java/org/infinispan/factories/AbstractComponentRegistry.java
this comment:
// Modules must be on the same classloader as Infinispan
// TODO revise this assumption
protected static List<ModuleLifecycle> moduleLifecycles =
ModuleProperties.resolveModuleLifecycles(null);
(null could be a user-specified CL if there were a way to set it)
indicates that modules must be on the same CL as infinispan core. That isn't 100%
true, since this is how it looks up the CL(s) to use (in infinsipan.util.FileLookup):
protected Collection<URL> getAsURLsFromClassLoader(String filename, ClassLoader
userClassLoader) throws IOException {
ClassLoader[] cls = new ClassLoader[] {
userClassLoader, // User defined classes
Util.class.getClassLoader(), // Infinispan classes (not always on TCCL
[modular env])
ClassLoader.getSystemClassLoader() // Used when load time instrumentation is
in effect
};
Collection<URL> urls = new HashSet<URL>();
for (ClassLoader cl : cls) {
if (cl == null)
continue;
try {
urls.addAll(new EnumerationList<URL>(cl.getResources(filename)));
} catch (RuntimeException e) {
// Ignore this as the classloader may throw exceptions for a valid path on
Windows
}
}
return urls;
}
Also as an FYI, this code in ModuleProperties.loadModuleProperties():
Collection<URL> resources = new
FileLookup().lookupFileLocations(MODULE_PROPERTIES_FILENAME, cl);
if (resources == null)
throw new IOException("Could not find " +
MODULE_PROPERTIES_FILENAME
+ " files on classpath for module " + moduleName);
The if (resources == null) condition will never be true because of:
Collection<URL> urls = new HashSet<URL>();
...
return urls;
in FileLookup.getAsURLsFromClassLoader(). If it had, it might have been easier to figure
out what was going wrong.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira