|Re: [virgo-dev] Would you like to try debugging a Gemini Blueprint issue (with ECF)?|
On Tuesday, February 5, 2013 at 20:07, Scott Lewis wrote:
On 2/5/2013 4:40 PM, Dmitry Sklyut wrote:
Yes...but key point: It's published by ECF remote services (not Gemini blueprint)
Why does blueprint do this? It seems to me that at least according to the Remote Service Admin spec (122), that this proxying-of-the-proxy should not be done for configs that are not Gemini's (i.e. are ECF configs). I believe that's the whole purpose of the remote service configs...i.e. to allow multiple distribution systems to coexist, and *not* interfere with each other.
This can't be part of ECF's remote service admin implementation...as the objectclass property is only specified to have the same service interfaces given in the original remote service publisher (1). And that publisher is not going to have the IRemoteServiceProxy in it's objectclass.
Sent with Sparrow
On Tuesday, February 5, 2013 at 18:50, Scott Lewis wrote:Hi Dmitry,
On 2/5/2013 2:48 PM, Dmitry Sklyut wrote:Scott,
I looked over this issue and here is what can be done (all config examples are based on github example provided in the forum post).
First bad news: I don't think it can be done with vanilla Blueprint xml config.
Good news it can be done with a little help from ECF and change in configuration on the blueprint side.
greedy-proxying is the answer: http://www.eclipse.org/gemini/blueprint/documentation/reference/1.0.2.RELEASE/html/service-registry.html#service-registry:refs:collection:greedy-proxying
BUT for greedy-proxying to work - ECF must publish its proxy with all interfaces advertised in reference.getProperty(Constants.OBJECTCLASS).Including org.eclipse.ecf.remoteservice.IRemoteServiceProxy
Hmm. I'm not sure if I understand what you are saying. ECF's remoteservice admin does create and import the proxy with all interfaces thatare advertised in objectclass. If ECF's remote service admin is used(e.g. as per the ECF examples), this does happen...but it seems to methat Gemini is somehow pre-empting and/or circumventing the operation ofthe ECF Remote Service Admin on the import side (I'm not sure of this,it's just a hypothesis). With ECF's proxy creation and publishing,IRemoteServiceProxy will be automatically added to the proxy...whetheror not it appears in objectclass...and this happens fine in the ECFremote service examples because the proxy creation and publishing isdone via the ECF remote service admin importService call.
I think the best solution should be to let the ECF remote service admincreate and publish the proxy on the consumer/import side. I'm still notsure why this isn't just happening in this case...as it does in theexample code (without Gemini). I think it would/will be muchpreferable to have ECF create and publish the proxy (as it should forECF-exported remote services) than to try to get blueprints impl toimport remote services exported by blueprint (it seems that's what youare attempting to do below...but I might be mistaken about your intentthough). In any event, my reading of the remote service admin specallows multiple distribution providers co-exist and not interfere witheach other...by only responding to the appropriate discovered remoteservices (i.e. those exported via a compatible config).
On blueprint side:
1. use spring osgi namespace and you can change <reference/> to a <list/> and enable greedy-proxying
Instead of <blueprint..></blueprint> use:
<beans xmlns="http://www.springframework.org/schema/beans"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:osgi="http://www.springframework.org/schema/osgi"xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsdhttp://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-2.0.xsd">
Instead of reference<referenceid="host" interface="org.eclipse.ecf.examples.remoteservices.hello.IHello"availability="mandatory"><reference-listener bind-method="bindHello"><ref component-id="consumer" /></reference-listener></reference>
Use list<osgi:list id="hostInListWithGreedy"interface="org.eclipse.ecf.examples.remoteservices.hello.IHello"greedy-proxying="true" cardinality="1..N"><osgi:listener bind-method="bindHello"><ref bean="consumer" /></osgi:listener></osgi:list>
Or use to specify 2 interfaces vs. 1.
<osgi:reference id="host" cardinality="1..1"><osgi:interfaces><value>org.eclipse.ecf.examples.remoteservices.hello.IHello</value><value>org.eclipse.ecf.remoteservice.IRemoteServiceProxy</value></osgi:interfaces><osgi:listener bind-method="bindHello"><ref bean="consumer"/></osgi:listener></osgi:reference>
2. Instead of osgi:reference or osgi:list - use bean configuration(something like this in spring bean style)
<bean id="host2" class="org.eclipse.gemini.blueprint.service.importer.support.OsgiServiceProxyFactoryBean"><property name="availability" value="MANDATORY"/><property name="interfaces"><list><value>org.eclipse.ecf.examples.remoteservices.hello.IHello</value><value>org.eclipse.ecf.remoteservice.IRemoteServiceProxy</value></list></property><property name="listeners"><list><bean class="org.eclipse.gemini.blueprint.config.internal.adapter.OsgiServiceLifecycleListenerAdapter"><property name="bindMethod" value="bindHello"/><property name="targetBeanName" value="consumer"/><!-- or --><property name="target" ref="consumer"/></bean></list></property></bean>
There is a similar bean for <list/> OsgiServiceCollectionProxyFactoryBean that can be configured with greedy-proxying also.
I don't think there is anything blueprint can do to expose org.eclipse.ecf.remoteservice.IRemoteServiceProxy without knowing that it exists if it is not in the OBJECTCLASS property.
Another way forward for now is to get the target service object from within Blueprint proxy.
ServiceReference nativeReference = ((ServiceReferenceProxy)serviceReference).getTargetServiceReference()
This way it is as naked as DS service object.
Hope this is all clear. I forked the blueECF github project and will push changes to it later today.
_______________________________________________virgo-dev mailing list
_______________________________________________ virgo-dev mailing list virgo-dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/virgo-dev
_______________________________________________virgo-dev mailing listvirgo-dev@xxxxxxxxxxxhttps://dev.eclipse.org/mailman/listinfo/virgo-dev