On 2/20/2011 4:08 PM, Scott Lewis wrote:
On 2/20/2011 3:15 PM, BJ Hargrave wrote:<stuff deleted>
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? 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*). 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.
Thanks,
Scott
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
