On 2/20/2011 5:12 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.
>
> Could our problem be because of the use of a ServiceFactory at all?
No. There are 2 checks:
1) Are the client bundle and the registering bundle (note that in both
cases it the bundle context used which established the bundle) wired
to the same service type?
In the case of RSA's registration of a ServiceFactory (for creating
proxies of a remote service), the service type (Class) is not even
loaded. It's only actually loaded when the
ServiceFactory.getService(Bundle...) is called later. So in this case,
how can the framework compare the types (since no Classes have actually
been loaded at this point)?
If (1) passes then the client bundle will see the service and can
request the service object. If the service object is a service
factory, then the framework will request the factory to manufacture
the service object.
2) The service object manufactured by the factory must be an
instanceof all the types under which the service was originally
registered.
> I notice that when I use ServiceTracker.open() none of our
> ServiceFactory.getService code is even *called* (and so no proxy
> service classes are even *loaded*).
This is because check (1) is failing.
Right. But given that a ServiceFactory is registered (by the
distribution system on RSA.importService), and the service types haven't
been loaded, how could/should it pass?
> So it seems that the class
> compatibility check that's going on must be somehow based upon the
> ServiceFactory instance...and it's failing that check simply because
> it's a service factory (and not because of actual class
> incompatibility...as the service interface class hasn't even been
> loaded via the ServiceFactory.getService call).
>
> Shouldn't ServiceFactorys be treated specially WRT the class
> compatibility check that's going on in the framework? (since they
> don't implement the service interfaces at all)? Or if this is
> expected for ServiceFactorys...does this make it impossible to use a
> ServiceFactory/this approach for ensuring class compatibility? If
> the latter (this approach won't work) it would be good to remove
> some of the prose suggesting this approach for achieving proxy
> service class compatibility from 122.5.6.
It is generally assumed that the bundle which registered the service
is also the same bundle which implements the service factory. So if
the client bundle and the registering bundle are wired to the same
service types (check (1)), then the factory (assuming check (2)
passes) will be using the types which are the proper types for the
client.
But in this case (RSA.importService) I think that assumption is
violated...because the bundle that implements the service factory (RSA
impl) is not the same bundle that registered the service (i.e. the
topology manager impl...i.e. org.eclipse.ecf.osgi.services.distribution).
RSA impls are a special beast. So they have to be more careful.
I see that :).
I think this all comes down to what bundle's context is used to
register the service? Is that bundle wired to the same service type as
the client bundle?
Right...but I guess I don't understand who any/either bundle can be
wired to the service type...since with a ServiceFactory the service type
classes haven't even been necessarily loaded. I understand in the
typical (local) case the service classes have at least been loaded prior
to the ServiceFactory registration, but in this case/RSA they haven't been.
I suppose that prior to the proxy ServiceFactory registration, I could
load the service type classes by the topology manager bundle...would
that allow the necessary checks to succeed?
Thanks,
Scott
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
