[infinispan-issues] [JBoss JIRA] Updated: (ISPN-1232) Infinispan module loader doesn't work in OSGi environments
Manik Surtani (JIRA)
jira-events at lists.jboss.org
Wed Jul 13 05:13:23 EDT 2011
[ https://issues.jboss.org/browse/ISPN-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Manik Surtani updated ISPN-1232:
--------------------------------
Assignee: Pete Muir (was: Manik Surtani)
Fix Version/s: 5.0.0.FINAL
Priority: Blocker (was: Major)
Forum Reference: http://community.jboss.org/thread/169153?tstart=0 (was: http://community.jboss.org/thread/169153?tstart=0)
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the infinispan-issues
mailing list