> 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? 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. > 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. RSA impls are a special beast. So they have to be more careful. 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? If not, then check (1) will fail and the client will not see the service because the framework is able to determine a lack of class space consistency. > > Thanks, > > Scott -- 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
