|Re: ECF proxies when using Gemini Blueprint [message #1007392 is a reply to message #1007273]
||Tue, 05 February 2013 17:36
| Scott Lewis
Registered: July 2009
Here's my impressions of what's happening. I haven't looked at this closely yet, so please take this with a grain of salt.
In this posting
Joerg Saini posts this:
Joerg Saini wrote on Thu, 31 January 2013 08:09
When using DS the proxy is created by ECF and in particular org.eclipse.ecf.remoteservice.AbstractRemoteService$ProxyClassLoader. The createProxy() methods seem overly likely (even though I haven't verified through a debug session yet).
The generated instance implements the following interfaces:
When using Blueprint the proxy creation appears to be handled through Gemini Blueprint only, involving the org.eclipse.gemini.blueprint.context.support.internal.classloader.ChainedClassLoader.
In this case the generated proxy implements the interfaces:
Should the proxy creation have been delegated to ECF in the second case? Is there a way to cause this?
I'll put together a post to the Gemini forum as well.
My belief is that this issue that Joerg identifies in proxy creation...is affecting you (Konstantinos) in a similar way...i.e. you are unable to cast the proxy to IRemoteServiceProxy...which is an ECF remote service interface. This interface (IRemoteServiceProxy) is automatically added to a proxy by ECF's proxy creation code (unless disabled through proxy).
This *appears* to me that the Gemini importer is somehow intercepting the remote service import...which must be done by ECF's RemoteServiceAdmin implementation, so that the appropriate proxy is created. Instead...it seems that the remote service import is done by Gemini's importer, and ECF's RemoteServiceAdmin is not used.
If this is correct, I don't know why the Gemini import would do this...as the OSGi Remote Service Admin spec provides for 'config providers' that are uniquely identified...meaning that it should be possible for both ECF's and Gemini's remote service implementation to coexist...and not conflict with one another.
Konstantinos...I assume that the ECF remote service examples run properly for you when run without Gemini...is that correct? If that's true, then it lends some evidence for my hypothesis that the Gemini Remote Service importer is creating the proxy, rather than the ECF code (which should be doing it).
For Gemini folks: Is there some description and/or code references for the Gemini Remote Service Admin implementation? Or perhaps debugging/tracing that can be turned on...so that the Gemini remote services import processing can be turned on?
|Re: ECF proxies when using Gemini Blueprint [message #1007452 is a reply to message #1007392]
||Tue, 05 February 2013 21:54
| Konstantinos Mavridis
Registered: November 2012
Hello Glyn, Scott,|
Thanks for the insight. I put together the modified example in an attempt to help debug this and I'll keep looking into it, though my knowledge on the involved technologies is currently limited.
Scott, I can verify that the problem is on the consumer-side proxy. The examples work fine without Gemini, in fact they work even when the server-side uses Gemini and the consumer-side uses a service tracker or declarative service.
A question here, since you mentioned a "Gemini Remote Service Admin"; is there an implementation of Remote Service Admin (chapter 122) within Gemini as well?
Powered by FUDForum
. Page generated in 0.10477 seconds