Hi,
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 ...
Regards
Felix
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
