On 2/20/2011 5:03 PM, BJ Hargrave wrote:
> 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?
The RemoteServiceAdmin.importService implementation (in our
org.eclipse.ecf.osgi.services.remoteserviceadmin bundle) registers the
ServiceFactory as part of the importService implementation. The
RemoteServiceAdmin itself is created via a service factory (i.e. by a
topology manager), and so the Bundle that has the TopologyManager (and
creates/gets the RemoteServiceAdmin service) is the one who's context is
used to register the ServiceFactory for the remote service proxy creation.
For our 'BasicTopologyManager' it is in bundle
org.eclipse.ecf.osgi.services.distribution.
How do we assure that this bundle has visibility to any dynamically
discovered remote service interface type? via Dynamic-ImportPackage or
some such?
Scott
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
