On 23 Nov 2010, at 23:45 , Bram de Kruijff wrote: > On Tue, Nov 23, 2010 at 9:54 PM, Richard S. Hall <he...@ungoverned.org> wrote: >> On 11/23/10 15:51, Bram de Kruijff wrote: >>> >>> Hi List, >>> >>> we are embedding a 3rd party library (in this case Apache Cassandra) >>> in a bundle . At startup it uses ClassLoader.getSystemClassLoader to >>> load a resource which fails. >>> >>> 1) Is there a way to intercept this call so that the resource is >>> loaded from the bundle classpath? >> >> No. > > Was afraid you where gonna say that > >>> 2) What would the desired patch on Cassandra be. Eg. ContextClassLoader? >> >> Shouldn't it be using its own bundle class loader? > > My guess is the Cassandra developers are not "OSGi aware" and we are > just wrapping that library. So in general what best practice pattern > should non OSGi projects follow to be "embedable". a) use their own > this.getClass().getClassLoader(), b) use the ContextClassLoader so we > can switch it c) ...
I general they should allow you to plugin a classloader instead of make assumptions that are not overridable. So whenever they load a class, they should allow you to provide a classloader for it. That way, if all classes are on the bundle classpath, you can provide the library with your option a). Even if not all classes are on the bundle classpath, but somehow provided by some other bundle, this gives you enough hooks to attempt to load them on another bundle's classloader (for example when trying to deserialize an object graph that had instances that were private to several bundles that created those instances but did not share the implementation packages). Option b) I would not recommend, as there is no generic way to associate threads with bundles in OSGi, so I would avoid using the context classloader. Greetings, Marcel --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
