Just a follow up on this...it turns out that removing the test to load
from the registering bundle is not always correct...in fact, it causes
Spring-OSGi to fail.
The issue for them is that the registering module DOES have access to
the service interface, but it is ALSO available on the class path. For
them they are passing the first test, but they fail the second since the
class gets returned from the class path (actually from
org.apache.maven.surefire.booter.IsolatedClassLoader)...
Needless to say, we need to think about this issue some more...
-> richard
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?
Thank you...
Regards,
Rajini
