[infinispan-issues] [JBoss JIRA] Commented: (ISPN-1232) Infinispan module loader doesn't work in OSGi environments

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: Pete Muir Priority: Blocker Fix For: 5.0.0.FINAL 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.