Re: [virgo-dev] Would you like to try debugging a Gemini Blueprint issue

[Dmitry Sklyut <dmitry@xxxxxxxxxxx>]

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

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.xsd
http://www.springframework.org/schema/osgi http://www.springframework.org/schema/osgi/spring-osgi-2.0.xsd";>


Instead of reference
<reference 
id="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.

ala.

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.


Regards,

-- 
Dmitry Sklyut
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Tuesday, February 5, 2013 at 1:08 PM, Scott Lewis wrote:

> Hi Glyn and Geminers,
> 
> I looked at the forum posting that Glyn points to, and created a reply [1].
> 
> My current take on things is that for some reason I don't yet understand, Gemini's importer is being used to create proxies..rather than ECF's Remote Service Admin implementation...and so the proxy being created is not as expected by the client code (i.e. it doesn't implement IRemoteServiceProxy...which is an ECF interface implemented by all proxies). But I don't know what Gemini is doing (yet), so am not sure.
> 
> Just to introduce myself to this list, I'm the ECF project lead and am largely responsible for ECF's implementation of OSGi remote services and Remote Service Admin. There's documentation for things starting here [2]. I've just joined this list (gemini-dev), but my 'home list' is ecf-dev :).
> 
> Hopefully we can jointly diagnose and fix this user's use case. Is there someone available on this list that is familiar with Gemini's remote service importer?
> 
> Thanks,
> 
> Scott
> 
> [1] http://www.eclipse.org/forums/index.php/mv/msg/452390/1007392/#msg_1007392
> [2] http://wiki.eclipse.org/ECF#OSGi_Remote_Services
> 
> 
> On 2/5/2013 8:41 AM, Glyn Normington wrote:
> > An issue has cropped up when Gemini Blueprint is used with ECR. I currently don't have time to dig into. A simple testcase has been provided on github, so if you are a bit of an expert on Gemini Blueprint, or would like to become more expert, please dive in. I'm happy to discuss findings of course. 
> > 
> > http://www.eclipse.org/forums/index.php?t=rview&goto=1007273#msg_1007273
> > 
> > Regards,
> > Glyn 
> 
> 
> _______________________________________________
> virgo-dev mailing list
> virgo-dev@xxxxxxxxxxx (mailto:virgo-dev@xxxxxxxxxxx)
> https://dev.eclipse.org/mailman/listinfo/virgo-dev