On 2/20/2011 3:15 PM, BJ Hargrave wrote:
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.
Yes, I understand this.
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.
What we are currently doing to solve this (which is hinted at in
122.5.6) is to register a ServiceFactory for proxy creation...and then
when a given client bundle first requests access to a proxy, the
ServiceFactory.getService method is called by the framework...i.e.
public Object getService(Bundle bundle, ServiceRegistration registration)
In our implementation of ServiceFactory.getService, we use the given
bundle (the client/proxy-requesting Bundle) to then load the service
classes...i.e. via bundle.loadClass(svcInterface). My assumption was
that by using the client bundle to load the service interface classes
that this would guarantee compatibility to the client caller of
getService...i.e. because it is the actual client Bundle that's loading
the service interface classes.
But this doesn't appear to guarantee class compatibility as
expected...which is why I'm writing here. Obviously it could be
something in our implementation...but I can't tell what...as all we're
doing is as described above...using the client bundle.loadClass method
to load the proxy's service interface classes...with the aim of
guaranteeing compatibility (see loadServiceInterfacesViaBundle(Bundle,
String[]) in [1] for that code). One possible issue...we are using the
java Proxy.newProxyInstance(cl, service classes,
InvocationHandler)...but I don't understand why this should be a problem
(i.e. the service classes given to newProxyInstance were/are loaded by
the client bundle).
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
