Home » Archived » Eclipse Communications Framework (ECF) » Mutiple DistributionProviders for a the same component(Works separately, but not together)
|
Re: Mutiple DistributionProviders for a the same component [message #1769358 is a reply to message #1769357] |
Mon, 31 July 2017 01:47 |
Scott Lewis 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 |
Nirmal Sasidharan 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 #1769479 is a reply to message #1769446] |
Tue, 01 August 2017 01:18 |
Scott Lewis Messages: 1038 Registered: July 2009 |
Senior Member |
|
|
Nirmal Sasidharan wrote on Mon, 31 July 2017 13:41That'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 |
Nirmal Sasidharan 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 |
Nirmal Sasidharan 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
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 |
Scott Lewis Messages: 1038 Registered: July 2009 |
Senior Member |
|
|
Nirmal Sasidharan wrote on Tue, 01 August 2017 14:03Cool! 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 |
Scott Lewis 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 #1769818 is a reply to message #1769813] |
Thu, 03 August 2017 16:30 |
Scott Lewis Messages: 1038 Registered: July 2009 |
Senior Member |
|
|
Nirmal Sasidharan wrote on Thu, 03 August 2017 11:16Scott 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
|
|
|
|
|
Goto Forum:
Current Time: Sat Nov 09 02:54:49 GMT 2024
Powered by FUDForum. Page generated in 0.25241 seconds
|