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 Mon, 18 Jun 2007 15:16:10 GMT
Ok, the change has been committed and deployed...let me know if it is 
working now...

-> richard

Richard S. Hall wrote:
> 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