Hi Neil,
On 2/20/2011 1:14 PM, Neil Bartlett wrote:
<stuff deleted>
If you are only seeing the proxy services when calling
ServiceTracker.open(true), then it suggests something is going wrong.
It sounds like a bug either in your code or in the framework's
compatibility checking.
Thanks for the response.
Unfortunately, we are seeing proxy services only when calling
ServiceTracker.open(true).
Here's the code in RemoteServiceAdmin [1]. See the method
private Object createProxy(Bundle requestingBundle,
ServiceReference serviceReference, IRemoteService
remoteService,
Map<String, Version> interfaceVersions)
Which creates the proxy (from within the service factory).
I can't tell what (if anything) is wrong with this code...and could use
some assistance with figuring out whether it's something in our code, or
something in the framework that's going wrong. What the code in
createProxy is doing is
1) Creating a new ProxyClassLoader instance, passing in the Bundle
that's requesting the remote service proxy (requestingBundle) (line 1521)
2) ProxyClassLoader.loadClass impl simply turns around and calls
requestingBundle.loadClass(name) (line 1578)
3) This ProxyClassLoader is used to create the proxy (line 1523)
Is the creation/use of this delegating ProxyClassLoader resulting in
requiring ServiceTracker.open(true) rather than ServiceTracker.open()?
It seems to me it's what's necessary to implement the proxying/class
compatibility strategy outlined in 122.5.6...i.e. using the classloader
of the bundle requesting the proxy (requestingBundle) to load service
interface classes for the proxy creation. Is there some other way to
implement this strategy that I'm not getting?
I guess I would need to know...what would indicate some problem with
framework compatibility checking? Are the compatibility checking rules
specified somewhere?
Thanks,
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
_______________________________________________
OSGi Developer Mail List
[email protected]
https://mail.osgi.org/mailman/listinfo/osgi-dev
