|Re: [virgo-dev] Would you like to try debugging a Gemini Blueprint issue (with ECF)?|
Ok...so it seems that what we have here is two extenders...ECF is making proxies for remote services and then then blueprint is proxying some/all services to allow service dependencies to be resolved immediately (essentially extending declarative services).
The problem...for this use case...apparently comes when blueprint proxies the proxy that ECF creates for a remote service. ECF has as a feature the ability to get to the IRemoteServiceProxy interface on the remote service proxy. When blueprint creates it's proxy, this interface is not on the objectclass and so the blueprint proxy doesn't expose it.
So far does this square with your thinking Dmitry?
Now...assuming we're on the right track, question is what to do about it. Possibilities (please add if I'm missing some):
1) ECF could add IRemoteServiceProxy to it's proxy. I'm hesitant to do this, only because the rs/rsa spec says that only what the remote service host puts on the objectclass is what the proxy should have on it's objectclass.
2) Through some option or config, blueprint could be told *not* create a proxy for remote services. There's a OSGi-specified property (service.imported) that means that it's a remote service. Is there something that allows blueprint to be configured to ignore/not automatically create proxies for certain services?
3) Is it possible to extend Blueprint to have it add other interfaces (e.g. IRemoteServiceProxy) during it's proxy construction? If so, I could create an ECF remote services extension for Blueprint to do this for ECF remote services.
And then there are two workarounds...one from blueprint
a) As Dmitry indicated: ServiceReference nativeReference = ((ServiceReferenceProxy)serviceReference).getTargetServiceReference(). Then the ECF proxy could be accessed directly via the nativeReference.
and the other from ECF remote services
b) ECF sets the value of OSGi's 'service.imported' property to an instance of IRemoteService...which for this use case may meet their needs (to make asynchronous remote method calls). What I'm saying is that if blueprint just copies the nativeReference service properties into it's proxy's properties, then client code could simply get the value of 'service.imported' and cast it to IRemoteService...and use that to make async remote calls.
Reactions or further thoughts?
On 2/5/2013 5:58 PM, Dmitry Sklyut wrote: