The framework does not care about the implementation class of a service object. Just the type names under which the service is registered (which are usually interfaces). Class space consistency requires the bundle registering the service (more precisely the bundle whose bundle context is used to register the service) and the bundle getting the service (client bundle) both use the same exact class object for the desired service type. This guarantees that the client bundle can cast the service object to the desired service type.
As an RSA implementation, you need to pay attention to this class space consistency issue. Whatever bundle registers the proxy service *must* be wired to the same service type as the client bundle. Otherwise the client bundle will not be able to get the service since the framework will detect the class space consistency issue. You need to figure out how to solve this. One way may be to dynamically create, install and start a bundle with the proper Import-Package statement for the service type and use that bundle as the "source" of the proxy service. It's context can be used to register the service and its class loader can be used to load the service type. -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Scott Lewis <[email protected]> To: OSGi Developer Mail List <[email protected]> Date: 2011/02/20 17:12 Subject: Re: [osgi-dev] Classloader accessibility and ServiceTracker.open(true) Sent by: [email protected] Hi Neil, On 2/20/2011 1:14 PM, Neil Bartlett wrote: > <stuff deleted> > If you are only seeing the proxy services when calling > ServiceTracker.open(true), then it suggests something is going wrong. > It sounds like a bug either in your code or in the framework's > compatibility checking. Thanks for the response. Unfortunately, we are seeing proxy services only when calling ServiceTracker.open(true). Here's the code in RemoteServiceAdmin [1]. See the method private Object createProxy(Bundle requestingBundle, ServiceReference serviceReference, IRemoteService remoteService, Map<String, Version> interfaceVersions) Which creates the proxy (from within the service factory). I can't tell what (if anything) is wrong with this code...and could use some assistance with figuring out whether it's something in our code, or something in the framework that's going wrong. What the code in createProxy is doing is 1) Creating a new ProxyClassLoader instance, passing in the Bundle that's requesting the remote service proxy (requestingBundle) (line 1521) 2) ProxyClassLoader.loadClass impl simply turns around and calls requestingBundle.loadClass(name) (line 1578) 3) This ProxyClassLoader is used to create the proxy (line 1523) Is the creation/use of this delegating ProxyClassLoader resulting in requiring ServiceTracker.open(true) rather than ServiceTracker.open()? It seems to me it's what's necessary to implement the proxying/class compatibility strategy outlined in 122.5.6...i.e. using the classloader of the bundle requesting the proxy (requestingBundle) to load service interface classes for the proxy creation. Is there some other way to implement this strategy that I'm not getting? I guess I would need to know...what would indicate some problem with framework compatibility checking? Are the compatibility checking rules specified somewhere? Thanks, Scott [1] http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/osgi/bundles/org.eclipse.ecf.osgi.services.remoteserviceadmin/src/org/eclipse/ecf/osgi/services/remoteserviceadmin/RemoteServiceAdmin.java _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
