felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: Question about class loading and SCR (see FELIX-624)
Date Wed, 23 Jul 2008 13:17:40 GMT

THe point is actually, that in an OSGi framework multiple bundles might 
be exporting the same package, yet with different versions. The Bundle A 
with Component C referring to service interface I (interface exported by 
Bundles B and D) might use a different interface class object than the 
actual Service S provided by Bundle E.

Here, Bundle A might import the interface I from Bundle B while Bundle E 
might import the service from Bundle D. Thus, the service may actually 
not be bound to Component C.

Of course the service registry of the OSGi framework ensures that 
Service S (registered with interface I imported from Bundle D) is not 
provided to Component C referring to the interface I imported from Bundle B.

Nevertheless it looks better to me to find a method with the interface 
class known to the consumer (Component C) and get a ClassCastException 
in case the Class objects would not match than to no be able to find the 
bind method due to incompatible class objects.

YMMV of course ...


Carsten Ziegeler schrieb:
> Felix Meschberger wrote:
>> Right, this should work as the framework should already guarantee that 
>> the class object used by the service and the class object used by the 
>> abstract class with the bind methods are the same.
>> Nevertheless, I would think, that using the class loader from 
>> Class.getClassLoader() of the class providing the bind (or unbind) 
>> method to be called is probably better than using the bundle providing 
>> the service. Its just cleaner IMHO.
>> That is the assignment of the parameterClass in DependencyManager#734 
>> would be:
>>    parameterClass =
>>        targetClass.getClassLoader().loadClass(parameterClassName)
>> instead of using serviceBundle.loadClass.
>> Of course, we would have to catch (and ignore) the 
>> ClassNotFoundException here, as the loader of the target class might 
>> not have the parameter class because the target class does not have 
>> the bind method we are looking for.
> Hmm, not sure if this is cleaner :) In the end the class loader which 
> exposes
> the service interface is used as this one is exporting the interface. So 
> as we already have exactly this class from this class loader its easier 
> (and faster?) to use this directly than to refetch this.
> I guess in the end it's a matter of taste. I have no real preference as 
> long as its working :)
> Carsten

View raw message