> 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.
That is only about creating the actual service object and of course it must implement the exact service type. But while the framework cares about that, it also cares about the bundle whose context was used to register the service. Does that bundle have visibility to the exact service type of the service? The framework will make that check before it bothers to call the service factory object. What bundle registered the service which the client wants to obtain? > > 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 -- 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
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
