|
|
|
|
| Re: ECF proxies when using Gemini Blueprint [message #1007392 is a reply to message #1007273] |
Tue, 05 February 2013 17:36   |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Konstantinos.
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
http://www.eclipse.org/forums/index.php/mv/msg/452118/1006481/#msg_1006481
Joerg Saini posts this:
Joerg Saini wrote on Thu, 31 January 2013 08:09When 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:
interface org.eclipse.ecf.examples.remoteservices.hello.IHello,
interface org.eclipse.ecf.examples.remoteservices.hello.IHelloAsync,
interface org.eclipse.ecf.remoteservice.IRemoteServiceProxy
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:
interface org.eclipse.ecf.examples.remoteservices.hello.IHello,
interface org.eclipse.gemini.blueprint.service.importer.ImportedOsgiServiceProxy,
interface org.springframework.aop.IntroductionInfo,
interface java.io.Serializable,
interface org.springframework.core.InfrastructureProxy,
interface org.springframework.aop.SpringProxy
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.
[Scott]
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?
Thanks.
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.03162 seconds
] 
Search
Help
Register
Login
Home
I will however post to gemini-dev to see if anyone else has time to look into this.