felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: How to deal with ClassLoader.getSystemClassLoader()
Date Tue, 23 Nov 2010 23:39:06 GMT
On 11/23/10 5:58 PM, Marcel Offermans wrote:
> On 23 Nov 2010, at 23:45 , Bram de Kruijff wrote:
>
>> On Tue, Nov 23, 2010 at 9:54 PM, Richard S. Hall<heavy@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).

Agreed, this is the only way. They must provide a hook for the lookup 
rather than burying it inside and performing it based on assumptions.

Even better if they don't expect to directly use a class at all and 
instead provide a hook for injecting some instance implementing an 
interface, then we could just give them the service we want to use 
rather than them expecting to create their own instance.

-> richard

> 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-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org


Mime
View raw message