Richard, Thank you very much for providing the fix so quickly. It works now!
Thank you... Regards, Rajini On 6/18/07, Richard S. Hall <[EMAIL PROTECTED]> wrote:
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 >
