Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Eclipse Communications Framework (ECF) » Mutiple DistributionProviders for a the same component(Works separately, but not together)
Mutiple DistributionProviders for a the same component [message #1769357] Sun, 30 July 2017 22:30 Go to next message
Nirmal Sasidharan is currently offline Nirmal SasidharanFriend
Messages: 9
Registered: May 2014
Junior Member
I have a sample DS component which exports a service. I want to use the ECF generic provider and JAX-RS provider at the same time.

I am registering it in the properties file as follows:
service.exported.configs=ecf.generic.server,\
ecf.jaxrs.jersey.server
ecf.generic.server.hostname=localhost
ecf.generic.server.port=4445
ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey


The endpoints aren't getting registered when used in this way. However, if I use any one of them independently, it works fine.

As per this page, multiple providers are supported.
https://wiki.eclipse.org/EIG:OSGi_Remote_Services

Any clue why it is not working for me?
Re: Mutiple DistributionProviders for a the same component [message #1769358 is a reply to message #1769357] Mon, 31 July 2017 01:47 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Quote:
I have a sample DS component which exports a service. I want to use the ECF generic provider and JAX-RS provider at the same time.

I am registering it in the properties file as follows:
service.exported.configs=ecf.generic.server,\
ecf.jaxrs.jersey.server
ecf.generic.server.hostname=localhost
ecf.generic.server.port=4445
ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey

The endpoints aren't getting registered when used in this way. However, if I use any one of them independently, it works fine.

As per this page, multiple providers are supported.
https://wiki.eclipse.org/EIG:OSGi_Remote_Services

Any clue why it is not working for me?


After a little sleuthing I believe I have figured out what was going wrong for you. First, it seems that the syntax you use for service.exported.configs=ecf.generic.server,\
ecf.jaxrs.jersey.server

does not result in a String[] of length two when read from a properties file, rather it results in a single String (no comma parsing): ecf.generic.server,ecf.jaxrs.jersey.server

and by OSGi RSA spec the service.exported.configs must be a String or String[] for multiple entries. This behavior for properties files was a little bit of a surprise to me, but fortunately one can specify the properties directly in the component definition rather than in a properties file...e.g.

@Component(immediate = true, property = { "service.exported.interfaces=*",
"ecf.exported.async.interfaces=*", "service.exported.configs=ecf.jaxrs.jersey.server",
"service.exported.configs=ecf.generic.server",
"ecf.generic.server.hostname=localhost",
"ecf.generic.server.port=4888",
"ecf.jaxrs.jersey.server.uri=http://localhost:8282/jersey/is/good" } )

Notice that there are two service.exported.config=<config> entries, and this results in a String[] value for service.exported.configs, which is what is required by RSA.

Unfortunately there is also a small bug in ECF around the container selection logic when there are multiple containers. Here's the bug:

https://bugs.eclipse.org/bugs/show_bug.cgi?id=520342

I've already applied the fix and pushed it to master, so it will be in ECF's next maintenance release (most likely in August).

There is, however, a way for you to correct this behavior in your current version of ECF. All you need to do is

1) Define a subclass of org.eclipse.ecf.osgi.service.remoteserviceadmin.HostContainerSelector:

import java.util.Arrays;
import java.util.Iterator;
import java.util.List;

import org.eclipse.ecf.core.ContainerTypeDescription;
import org.eclipse.ecf.osgi.services.remoteserviceadmin.HostContainerSelector;

public class MyHostContainersSelector extends HostContainerSelector {

public MyHostContainersSelector() {
super(new String[] {}, true);
}

@Override
protected boolean matchHostSupportedConfigTypes(String[] requiredConfigTypes,
ContainerTypeDescription containerTypeDescription) {
if (requiredConfigTypes == null)
return true;
String[] supportedConfigTypes = getSupportedConfigTypes(containerTypeDescription);
if (supportedConfigTypes == null || supportedConfigTypes.length == 0)
return false;
List supportedConfigTypesList = Arrays.asList(supportedConfigTypes);
List requiredConfigTypesList = Arrays.asList(requiredConfigTypes);
supportedConfigTypes
boolean result = false;
for (Iterator i = requiredConfigTypesList.iterator(); i.hasNext();)
result |= supportedConfigTypesList.contains(i.next());
return result;
}
}

Then, register an instance of this class *before* you export your remote services,,,e,g,

bundleContext.registerService(IHostContainerSelector.class, new MyHostContainerSelector(), null);

This should give you the same correct behavior as I just applied for the fix to the bug without having to get the more recent version.

In my tests, with the fix I'm able to export both to the generic and to the jersey providers with the properties as listed in the @Component definition above.

Thanks for using ECF remote services. Please let us know if you need a release quickly with this fix. If so, it might be best to join and post to ecf-dev@eclipse.org mailing list via: https://dev.eclipse.org/mailman/listinfo/ecf-dev as not all the developers monitor this forum as closely.



Re: Mutiple DistributionProviders for a the same component [message #1769446 is a reply to message #1769358] Mon, 31 July 2017 17:41 Go to previous messageGo to next message
Nirmal Sasidharan is currently offline Nirmal SasidharanFriend
Messages: 9
Registered: May 2014
Junior Member
That's simply amazing the time you spent writing this detailed post. Thanks a ton Scott! It's good that you could identify the problem and fix it.

I tried registering my own IHostContainerSelector service. I couldn't quite get it working yet. I see that my service is getting registered, I am not sure if it is somehow too late.
Can it be that the RemoteServiceAdmin constructor is kicking in getting the "defaultHostContainerSelector" you are creating there? I will have a deeper look later today (tonight here in Germany;)).

ECF looks pretty interesting and I don't know how I missed it until now. We have a huge eclipse development setup with several 1000 plugins. I am trying to define a new architecture for our tooling on how we can go from the local IDE concept to a distributed architecture where we reuse the OSGi components from distributed IDEs (using DOSGi) and from cloud (using REST) at the same time. The goal is to have only cloud solutions in the end, but ECF looks like a good transition path for us to have "hybrid" solutions rather than going for a big-bang.

[Updated on: Mon, 31 July 2017 19:50]

Report message to a moderator

Re: Mutiple DistributionProviders for a the same component [message #1769457 is a reply to message #1769446] Mon, 31 July 2017 19:03 Go to previous messageGo to next message
Wim Jongman is currently offline Wim JongmanFriend
Messages: 493
Registered: July 2009
Senior Member

Hi Scott,

Isn't the build automatically triggered and uploaded to [1]?

[1] http://download.eclipse.org/rt/ecf/snapshot/

Cheers,

Wim
Re: Mutiple DistributionProviders for a the same component [message #1769477 is a reply to message #1769457] Tue, 01 August 2017 00:58 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Wim Jongman wrote on Mon, 31 July 2017 15:03
Hi Scott,

Isn't the build automatically triggered and uploaded to [1]?

[1] http://download.eclipse.org/rt/ecf/snapshot/

Cheers,

Wim


Yes the new build is now available at [1] above. The only change was to this bundle (200 maint segment of version rather than 100).

org.eclipse.ecf.osgi.services.remoteserviceadmin_4.5.200.v20170731-0127.jar


Re: Mutiple DistributionProviders for a the same component [message #1769479 is a reply to message #1769446] Tue, 01 August 2017 01:18 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Nirmal Sasidharan wrote on Mon, 31 July 2017 13:41
That's simply amazing the time you spent writing this detailed post. Thanks a ton Scott! It's good that you could identify the problem and fix it.

I tried registering my own IHostContainerSelector service. I couldn't quite get it working yet. I see that my service is getting registered, I am not sure if it is somehow too late.
Can it be that the RemoteServiceAdmin constructor is kicking in getting the "defaultHostContainerSelector" you are creating there? I will have a deeper look later today (tonight here in Germany;)).



The IHostContainerSelector does have to be registered before the first remote services are registered (and then exported by RemoteServiceAdmin). Another approach...as Wim points out...is to use the snapshot build. I expect we will have a maintenance release in August as well.

Quote:


ECF looks pretty interesting and I don't know how I missed it until now. We have a huge eclipse development setup with several 1000 plugins. I am trying to define a new architecture for our tooling on how we can go from the local IDE concept to a distributed architecture where we reuse the OSGi components from distributed IDEs (using DOSGi) and from cloud (using REST) at the same time. The goal is to have only cloud solutions in the end, but ECF looks like a good transition path for us to have "hybrid" solutions rather than going for a big-bang.



fwiw: I feel that one of the most significant advantages of ECF's impl of OSGi remote services is that it completely inherits all the benefits of OSGi services: e.g. separation between api (service interfaces) and implementation, dynamics support, dependency management and injection (e.g. ds/scr).

IMHO OSGi Remote Services/ECF *also* separates the service API from the *distribution* mechanism and transport. This separation allows folks like you to define, implement, consume and version/update services without tightly binding impls or consumers to any particular distribution system.

This seems to me to allow you to not only gradually transition a non-distributed system to a distributed system, but also to choose, evaluate and update transports based upon things like performance, bandwidth, and/or security constraints, without having to rewrite service implementers or consumers. The value of separation of API from impl can be very useful (I assert) to achieve separation (not transparency!) between distribution contract (rpc) and distribution impl (rest+json, tcp+protobuf, mqtt, websockets, etc).




Re: Mutiple DistributionProviders for a the same component [message #1769571 is a reply to message #1769479] Tue, 01 August 2017 18:03 Go to previous messageGo to next message
Nirmal Sasidharan is currently offline Nirmal SasidharanFriend
Messages: 9
Registered: May 2014
Junior Member
Cool! It worked when I used the Snapshot version. Thanks a lot.

I have Apache Karaf as the container and since there was no Karaf feature in the snapshot build, I manually downloaded the org.eclipse.ecf.osgi.services.remoteserviceadmin_4.5.200.xxx jar and installed it into Karaf with a "bundle:install file:". Not so elegant. Do you have a alternate suggestion on how to get it into Karaf before the maintenance build is available?

After using the Snapshot version and deploying my services into Karaf, I could use the REST services. However an eclipse plugin which consumes the remote OSGi services couldn't get it (although I can see the generic and jersey endpoints in the ECF view) . Perhaps the org.eclipse.ecf.osgi.services.remoteserviceadmin plugin in my Eclipse is still outdated. Does the client also use the org.eclipse.ecf.osgi.services.remoteserviceadmin plugin to communicate to a remote service?

Quote:

This seems to me to allow you to not only gradually transition a non-distributed system to a distributed system, but also to choose, evaluate and update transports based upon things like performance, bandwidth, and/or security constraints, without having to rewrite service implementers or consumers. The value of separation of API from impl can be very useful (I assert) to achieve separation (not transparency!) between distribution contract (rpc) and distribution impl (rest+json, tcp+protobuf, mqtt, websockets, etc).


That's a very valid argument and gives me a lot of flexibility in a migration scenario where the contracts are not broken and only implementation changes.

The major hurdle I see in moving from a non-distributed to a distributed setup is to achieve stateless services., esp. when we have huge EMF models. But that has nothing to do with ECF and is an SOA concern.
Re: Mutiple DistributionProviders for a the same component [message #1769579 is a reply to message #1769571] Tue, 01 August 2017 21:09 Go to previous messageGo to next message
Nirmal Sasidharan is currently offline Nirmal SasidharanFriend
Messages: 9
Registered: May 2014
Junior Member
I made sure that my eclipse client also uses the snapshot version. I still can't access the service from eclipse, although I see both the endpoints being discovered.

This is how the "Endpoint Discovery" looks

https://cdn.pbrd.co/images/GDGGZFB.png

and the exception when I run my client with following code.

	@Component(immediate=true)
	public class HelloWorldClient {

		@Reference(cardinality=ReferenceCardinality.AT_LEAST_ONE,policy=ReferencePolicy.DYNAMIC)
		void bindTimeService(HelloWorldService helloWorldService) {
			System.out.println("Discovered HelloWorldService via DS");
			String message = helloWorldService.getMessage();
			 System.out.println("Message received is: " + message);
		}
		
		void unbindTimeService(HelloWorldService helloWorldService) {
			System.out.println("Undiscovered HelloWorldService via DS");
		}
	}


!MESSAGE org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=4;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:importService:No remote service container selected for endpoint=ECFEndpointDescription[{ecf.endpoint.id=http://localhost:8181/jersey, ecf.endpoint.id.ns=ecf.namespace.jaxrs, ecf.endpoint.ts=1501620321763, ecf.generic.server.hostname=localhost, ecf.generic.server.port=4445, ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey, ecf.rsvc.id=1, endpoint.framework.uuid=89de79e0-b2d7-4953-818c-0bb9e80ae731, endpoint.id=ad3759b5-637b-43c5-b6ce-7d16b562a817, endpoint.package.version.com.xxxx.example=0.0.1.SNAPSHOT, endpoint.service.id=181, objectClass=[Ljava.lang.String;@5903531c, remote.configs.supported=[Ljava.lang.String;@2d08c446, remote.intents.supported=[Ljava.lang.String;@7836b24c, service.imported=true, service.imported.configs=[Ljava.lang.String;@15f7399}]. Remote service NOT IMPORTED;severity4;exception=org.eclipse.ecf.osgi.services.remoteserviceadmin.SelectContainerException: No remote service container selected for endpoint=ECFEndpointDescription[{ecf.endpoint.id=http://localhost:8181/jersey, ecf.endpoint.id.ns=ecf.namespace.jaxrs, ecf.endpoint.ts=1501620321763, ecf.generic.server.hostname=localhost, ecf.generic.server.port=4445, ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey, ecf.rsvc.id=1, endpoint.framework.uuid=89de79e0-b2d7-4953-818c-0bb9e80ae731, endpoint.id=ad3759b5-637b-43c5-b6ce-7d16b562a817, endpoint.package.version.com.yyyy.api.example=0.0.1.SNAPSHOT, endpoint.service.id=181, objectClass=[Ljava.lang.String;@5903531c, remote.configs.supported=[Ljava.lang.String;@2d08c446, remote.intents.supported=[Ljava.lang.String;@7836b24c, service.imported=true, service.imported.configs=[Ljava.lang.String;@15f7399}]. Remote service NOT IMPORTED;children=[]]
!STACK 0
org.eclipse.ecf.osgi.services.remoteserviceadmin.SelectContainerException: No remote service container selected for endpoint=ECFEndpointDescription[{ecf.endpoint.id=http://localhost:8181/jersey, ecf.endpoint.id.ns=ecf.namespace.jaxrs, ecf.endpoint.ts=1501620321763, ecf.generic.server.hostname=localhost, ecf.generic.server.port=4445, ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey, ecf.rsvc.id=1, endpoint.framework.uuid=89de79e0-b2d7-4953-818c-0bb9e80ae731, endpoint.id=ad3759b5-637b-43c5-b6ce-7d16b562a817, endpoint.package.version.com.yyyyy.example=0.0.1.SNAPSHOT, endpoint.service.id=181, objectClass=[Ljava.lang.String;@5903531c, remote.configs.supported=[Ljava.lang.String;@2d08c446, remote.intents.supported=[Ljava.lang.String;@7836b24c, service.imported=true, service.imported.configs=[Ljava.lang.String;@15f7399}]. Remote service NOT IMPORTED
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:456)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleECFEndpointAdded(AbstractTopologyManager.java:301)
	at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.handleEndpointAdded(BasicTopologyManagerImpl.java:107)
	at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.endpointChanged(BasicTopologyManagerImpl.java:176)
	at org.eclipse.ecf.internal.osgi.services.distribution.Activator$ProxyEndpointEventListener.deliverSafe(Activator.java:206)
	at org.eclipse.ecf.internal.osgi.services.distribution.Activator$ProxyEndpointEventListener.endpointChanged(Activator.java:183)
	at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$1.dispatchEvent(EndpointDescriptionLocator.java:219)
	at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
	at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
Re: Mutiple DistributionProviders for a the same component [message #1769593 is a reply to message #1769571] Wed, 02 August 2017 05:43 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Nirmal Sasidharan wrote on Tue, 01 August 2017 14:03
Cool! It worked when I used the Snapshot version. Thanks a lot.

I have Apache Karaf as the container and since there was no Karaf feature in the snapshot build, I manually downloaded the org.eclipse.ecf.osgi.services.remoteserviceadmin_4.5.200.xxx jar and installed it into Karaf with a "bundle:install file:". Not so elegant. Do you have a alternate suggestion on how to get it into Karaf before the maintenance build is available?



One way would be to create your own copy of the karaf-feature.xml file here:

http://download.eclipse.org/rt/ecf/latest/karaf-features.xml

and change the maven central reference to the org.eclipse.ecf.osgi.services.remoteserviceadmin 4.5.100 and change it to an http reference to the snapshot version 4.5.200 jar:

http://download.eclipse.org/rt/ecf/snapshot/site.p2/plugins/org.eclipse.ecf.osgi.services.remoteserviceadmin_4.5.200.v20170731-0127.jar

You will likely have to change the version number of the feature that contains this bundle, so that you can update it with the karaf feature installer.

Quote:


After using the Snapshot version and deploying my services into Karaf, I could use the REST services. However an eclipse plugin which consumes the remote OSGi services couldn't get it (although I can see the generic and jersey endpoints in the ECF view) . Perhaps the org.eclipse.ecf.osgi.services.remoteserviceadmin plugin in my Eclipse is still outdated. Does the client also use the org.eclipse.ecf.osgi.services.remoteserviceadmin plugin to communicate to a remote service?



o.e.e.osgi.services.remoteserviceadmin is required by the remote service consumer, but if your version is relatively recent it should work. One question: which remote service are you importing? i.e. the ecftcp one or the REST one, or are you trying/wanting to import both on a single client?

One possibility is that on the Eclipse client you may not have the following bundle started: org.eclipse.ecf.osgi.services.distribution. This bundle holds the RSA topology manager. In the RSA spec the topology manager is responsible for deciding whether to import a discovered remote service. It can be replaced and/or customized, and the one in the bundle above is what is called 'promiscuous' because it imports every service it discovers. But if it's never started...because Eclipse has a lazy start policy...then it can't do anything at all and a discovered endpoint description won't be automatically imported. It sounds like this may be the case for you. One way to check would be to look at Eclipse's OSGi console, and see if the o.e.e.osgi.services.distribution bundle is started before discovery.

Since Eclipse has this lazy-start policy that it applies to us we can't really startup something as potentially dangerous as a promiscuous topology manager automatically.

One other possibility to try for diagnosis: if you can see the endpoint descriptions being discovered you should be able to manually import them in the Endpoint Description view by selecting one, bringing up the context menu and importing it.
Re: Mutiple DistributionProviders for a the same component [message #1769594 is a reply to message #1769579] Wed, 02 August 2017 05:49 Go to previous messageGo to next message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
I should have looked at this before sending my last note.

Nirmal Sasidharan wrote on Tue, 01 August 2017 17:09<stuff deleted>
[code

!MESSAGE org.eclipse.core.runtime.Status[plugin=org.eclipse.ecf.osgi.services.remoteserviceadmin;code=4;message=org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:importService:No remote service container selected for endpoint=ECFEndpointDescription[{ecf.endpoint.id=http://localhost:8181/jersey, ecf.endpoint.id.ns=ecf.namespace.jaxrs, ecf.endpoint.ts=1501620321763, ecf.generic.server.hostname=localhost, ecf.generic.server.port=4445, ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey, ecf.rsvc.id=1, endpoint.framework.uuid=89de79e0-b2d7-4953-818c-0bb9e80ae731, endpoint.id=ad3759b5-637b-43c5-b6ce-7d16b562a817, endpoint.package.version.com.xxxx.example=0.0.1.SNAPSHOT, endpoint.service.id=181, objectClass=[Ljava.lang.String;@5903531c, remote.configs.supported=[Ljava.lang.String;@2d08c446, remote.intents.supported=[Ljava.lang.String;@7836b24c, service.imported=true, service.imported.configs=[Ljava.lang.String;@15f7399}]. Remote service NOT IMPORTED;severity4;exception=org.eclipse.ecf.osgi.services.remoteserviceadmin.SelectContainerException: No remote service container selected for endpoint=ECFEndpointDescription[{ecf.endpoint.id=http://localhost:8181/jersey, ecf.endpoint.id.ns=ecf.namespace.jaxrs, ecf.endpoint.ts=1501620321763, ecf.generic.server.hostname=localhost, ecf.generic.server.port=4445, ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey, ecf.rsvc.id=1, endpoint.framework.uuid=89de79e0-b2d7-4953-818c-0bb9e80ae731, endpoint.id=ad3759b5-637b-43c5-b6ce-7d16b562a817, endpoint.package.version.com.yyyy.api.example=0.0.1.SNAPSHOT, endpoint.service.id=181, objectClass=[Ljava.lang.String;@5903531c, remote.configs.supported=[Ljava.lang.String;@2d08c446, remote.intents.supported=[Ljava.lang.String;@7836b24c, service.imported=true, service.imported.configs=[Ljava.lang.String;@15f7399}]. Remote service NOT IMPORTED;children=[]]
!STACK 0
org.eclipse.ecf.osgi.services.remoteserviceadmin.SelectContainerException: No remote service container selected for endpoint=ECFEndpointDescription[{ecf.endpoint.id=http://localhost:8181/jersey, ecf.endpoint.id.ns=ecf.namespace.jaxrs, ecf.endpoint.ts=1501620321763, ecf.generic.server.hostname=localhost, ecf.generic.server.port=4445, ecf.jaxrs.jersey.server.uri=http://localhost:8181/jersey, ecf.rsvc.id=1, endpoint.framework.uuid=89de79e0-b2d7-4953-818c-0bb9e80ae731, endpoint.id=ad3759b5-637b-43c5-b6ce-7d16b562a817, endpoint.package.version.com.yyyyy.example=0.0.1.SNAPSHOT, endpoint.service.id=181, objectClass=[Ljava.lang.String;@5903531c, remote.configs.supported=[Ljava.lang.String;@2d08c446, remote.intents.supported=[Ljava.lang.String;@7836b24c, service.imported=true, service.imported.configs=[Ljava.lang.String;@15f7399}]. Remote service NOT IMPORTED
at org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin.importService(RemoteServiceAdmin.java:456)
at org.eclipse.ecf.osgi.services.remoteserviceadmin.AbstractTopologyManager.handleECFEndpointAdded(AbstractTopologyManager.java:301)
at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.handleEndpointAdded(BasicTopologyManagerImpl.java:107)
at org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManagerImpl.endpointChanged(BasicTopologyManagerImpl.java:176)
at org.eclipse.ecf.internal.osgi.services.distribution.Activator$ProxyEndpointEventListener.deliverSafe(Activator.java:206)
at org.eclipse.ecf.internal.osgi.services.distribution.Activator$ProxyEndpointEventListener.endpointChanged(Activator.java:183)
at org.eclipse.ecf.osgi.services.remoteserviceadmin.EndpointDescriptionLocator$1.dispatchEvent(EndpointDescriptionLocator.java:219)
at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)
at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)
[/code]



From this, it appears to me that the jersey/jaxrs client provider isn't installed on the Eclipse client. That's essentially the meaning of:

org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:importService:No remote service container selected for endpoint=...

i.e. when it tries to import the service, it can't find the appropriate jersey/jaxrs client distribution provider.

Re: Mutiple DistributionProviders for a the same component [message #1769813 is a reply to message #1769594] Thu, 03 August 2017 15:16 Go to previous messageGo to next message
Nirmal Sasidharan is currently offline Nirmal SasidharanFriend
Messages: 9
Registered: May 2014
Junior Member
Scott Lewis wrote on Wed, 02 August 2017 01:49


From this, it appears to me that the jersey/jaxrs client provider isn't installed on the Eclipse client. That's essentially the meaning of:

org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:importService:No remote service container selected for endpoint=...

i.e. when it tries to import the service, it can't find the appropriate jersey/jaxrs client distribution provider.



Cool. That was exactly the reason. It works as expected now. Thanks a lot for your support.
- Service hosted in Karaf offers JAX-RS and Generic Endpoints
- Webclient communicates with the service usingREST
- Eclipse client communicates using OSGi

Just one question that still remains.
From my eclipse client I am not interested in JAX-RS.

All I do is

@Component(immediate=true)
	public class HelloWorldClient {

		@Reference(cardinality=ReferenceCardinality.AT_LEAST_ONE,policy=ReferencePolicy.DYNAMIC)
		void bindTimeService(HelloWorldService helloWorldService) {
			System.out.println("Discovered HelloWorldService via DS");
			String message = helloWorldService.getMessage();
			 System.out.println("Message received is: " + message);
		}
		
		void unbindTimeService(HelloWorldService helloWorldService) {
			System.out.println("Undiscovered HelloWorldService via DS");
		}
	}


Why did I have to install JAX-RS provider in my eclipse client to get rid of the exception in my previous post?
Re: Mutiple DistributionProviders for a the same component [message #1769818 is a reply to message #1769813] Thu, 03 August 2017 16:30 Go to previous message
Scott Lewis is currently offline Scott LewisFriend
Messages: 1038
Registered: July 2009
Senior Member
Nirmal Sasidharan wrote on Thu, 03 August 2017 11:16
Scott Lewis wrote on Wed, 02 August 2017 01:49


From this, it appears to me that the jersey/jaxrs client provider isn't installed on the Eclipse client. That's essentially the meaning of:

org.eclipse.ecf.osgi.services.remoteserviceadmin.RemoteServiceAdmin:importService:No remote service container selected for endpoint=...

i.e. when it tries to import the service, it can't find the appropriate jersey/jaxrs client distribution provider.



Cool. That was exactly the reason. It works as expected now. Thanks a lot for your support.
- Service hosted in Karaf offers JAX-RS and Generic Endpoints
- Webclient communicates with the service usingREST
- Eclipse client communicates using OSGi

Just one question that still remains.
From my eclipse client I am not interested in JAX-RS.

All I do is

@Component(immediate=true)
	public class HelloWorldClient {

		@Reference(cardinality=ReferenceCardinality.AT_LEAST_ONE,policy=ReferencePolicy.DYNAMIC)
		void bindTimeService(HelloWorldService helloWorldService) {
			System.out.println("Discovered HelloWorldService via DS");
			String message = helloWorldService.getMessage();
			 System.out.println("Message received is: " + message);
		}
		
		void unbindTimeService(HelloWorldService helloWorldService) {
			System.out.println("Undiscovered HelloWorldService via DS");
		}
	}


Why did I have to install JAX-RS provider in my eclipse client to get rid of the exception in my previous post?


The reason is a little involved, but here goes:

First, you are using the default RSA topology manager (it's in org.eclipse.ecf.osgi.services.distribution bundle), it's called the BasicTopologyManager. This topology manager is what's called 'promiscuous' and it's called that because it's default policy is to import every service that's discovered. On your eclipse client, when the service implemented by the jaxrs provider is discovered on that client, the BasicTopologyManager called RemoteServiceAdmin.importService. You can see all this in the stack trace of the error.

When importService is called, one of the first things that ECF's RSA impl does is to select the importing container. This is what generates the exception, as without the implementing provider installed no container can be created, and that error/stack trace is what you are seeing.

I think in your current environment it would probably be ok to have the exception raised, as it shouldn't interfere with the discovery and import of the other remote services exported by other providers.

It is possible to remove this provider and prevent the exception/stack trace though in more structured ways... from replacing or extending the topology manager, to configuring the BasicTopologyManager to ignore some services and allow others, to having your own logic for discovering and deciding whether to import a discovered remote service. All these are reasonable, based upon different use cases for your remote services/topology arrangements/client needs, etc. I can explain any/all of these, as they are all based upon the RSA specification and ECF's extensible impl [1], but you probably don't want to hear much of that for the time being. :)

[1] https://wiki.eclipse.org/EIG:Remote_Services_Admin


Previous Topic:ECF + Karaf + Zookeeper
Next Topic:Remote services lost after one hour
Goto Forum:
  


Current Time: Sat Nov 09 02:54:49 GMT 2024

Powered by FUDForum. Page generated in 0.25241 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top