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

[Pete Muir (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-1232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12613920#comment-12613920 ] 

Pete Muir commented on ISPN-1232:
---------------------------------

Talking to David B, we came up with a hack for how to make this work for 5.0 with the intent of reworking OSGi support in 5.1.

Ask any class loaded by the OSGi framework for it's BundleReference (http://www.osgi.org/javadoc/r4v42/org/osgi/framework/BundleReference.html), and from that you can get to the Bundle interface and the BundleContext interface. The BundleContext allows you to iterate over all the bundles in the system. For each bundle you can call Bundle.getResource("/infinispan-module.properties"), and this should give you a URL if it's in the Bundle, even if it isn't exported.

To obtain the BundleReference, you can often simply do: ClassLoader cl = getClass().getClassLoader();. BundleReference br = (BundleReference) cl; as long as your class was loaded by an OSGi framework. So you could do: if (cl instanceof BundleReference); if yes - then youre in OSGi.

If the Bundle.getResource() doesn't give you the result you want, you can also try Bundle.getEntry() or Bundle.findEntries(). There are different rules associated with each API.

> 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