felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Richard S. Hall" <he...@ungoverned.org>
Subject Re: Implementation of ServiceReference.isAssignableTo different in various OSGi framework implementations
Date Fri, 15 Jun 2007 18:15:45 GMT
Rajini Sivaram wrote:
> Hello,
> I am working on SCA-OSGi integration to enable OSGi bundles to form the
> implementation type for Apache Tuscany SCA components. I have run into 
> some
> problems because of the way service references are filtered in Felix.
> This is the scenario. We startup Felix runtime in embedded mode inside
> Tuscany. To intercept an OSGi service, a proxy is registered into the 
> OSGi
> service registry. The interface used by the proxy is of the same 
> classloader
> as the one seen by the requestor bundle (it was loaded using
> requestorBundle.loadClass). The classloader of the system bundle 
> however has
> access to this interface loaded by the application classloader. The
> requestor has a wire for the interface, but the provider (system bundle)
> doesn't. The test performed for ServiceReference.isAssignableTo seems 
> to be
> different for Equinox, Knopflerfish and Felix. In both Equinox and
> Knopflerfish, the proxy service is returned to the requestor bundle when
> getServiceReference is called. Felix, however first tests if the class
> loaded by the provider is the same as the class loaded by the requestor (
> ServiceRegistrationImpl.isClassAccessible()). If the class cannot be 
> loaded
> by the provider, then the class of the registered object is tested. Is 
> the
> first test which prevents bundles from registering services of objects 
> using
> different classloaders strictly necessary? Wouldn't it be sufficient 
> to test
> the class of the object registered?

Yes, you could be right, because if the service object class is loaded 
from the provider, then it should be discovered by the second check 
anyway, right? Thus, it seems like it should only be necessary to do the 
second check which will cover both cases...I think... :-)

Anyone want to venture a guess as to whether my logic is correct? If so, 
I can commit a fix...

-> richard

View raw message