Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Problem with Service Endpoint matching when using different network names
Hi Peter,

On 8/14/2018 7:33 AM, Peter Hermsdorf wrote:

Hi Scott,

sorry about the slow reply. :) 
 

Of course you were right with the value for service.exported.configs. After that the server started successfully.

After fiddling around with some endpoint properties the client could successfully connect to the server and the remote service was imported and could be used.

One issue still exists. After client launch the following exception happens (on client side):

<stack deleted>

Some seconds later however the service binding happens nevertheless and the remote call is successful. Maybe a timing or startup issue..


Hmm.   Haven't seen that in my own tests with the example services.   What app environments are your impl and consumer running in? (e.g. RCP, equinox server, etc).  Do you have start levels and if so what are things set at?   I would appreciate if you would open an issue for this here:

https://github.com/ECF/tcpsocketdistributionprovider/issues

..

Till now I was not able to test this setup in our environment, but from what I've seen it should work for us and solve the recent issues regarding service matching with hostnames.

How do you see the project tcpsocket provider regarding further development / maintenance?


That's a good question.    It's reasonably complete now...as it allows multiple services to be exported from a single server socket.   This functionality (multiple services) needs to be tested, however.

One enhancement that might be useful would be to separate out the serialization so that the current object serialization could be replaced with something else (e.g. protobuf) without creating a brand new provider.

Another possible enhancement would be adding and testing sslsocket support.

Yet another would be separating out some sort of authentication.

And it could/will require more testing with bug fixes.

I've got the maven meta-data in to automatically build on travis...it would be nice if it could get built and deployed to maven central eventually.   In short term I would like to produce a github release for 1.0.0.

Do you see the project as a proof of concept or do you think it is useful enough for a broader user base and continue development?


I think it is useful enough to be used as a distribution provider and I would like to continue development.    I also would like a tutorial based upon it so that others could use.

The sticking point for me is that my plate is very full this fall...which is one reason I did the work on it when I did.

If you would like and am able wrt employer, I would welcome contributions (enhancements, issues and fixes, samples, tutorials, docs, etc) from you.   I could make you a team member to do so.

What open points / issues do you see with the current code base? What needs be be fixed / changed / added from your point of view?


Other than the timing issues you discovered, I'm not aware of any obvious bugs but it hasn't been tested that much.  

The things I listed above probably will have to be added eventually, if it's used by multiple folks for more than running the samples. 
 
Thanks,

Scott



Thanks for your information!

Bye Peter


Am 09.08.2018 um 01:26 schrieb Scott Lewis:
Hi Peter

Sorry about the slow reply.  I'm out on a gig.

I think the service.exported.configs prop value should be

ecf.socket.server

As per
https://github.com/ECF/tcpsocketdistributionprovider/blob/master/bundles/org.eclipse.ecf.provider.tcpsocket.common/src/org/eclipse/ecf/provider/tcpsocket/common/TCPSocketConstants.java

RE the genetic provider...it was done long before rsa...and there is the peer services also as discussed.

Hope this helps.

Scott 

From: "Peter Hermsdorf" &lt;peter.hermsdorf@xxxxxxxxx&gt;
Date: Tue, Aug 7, 2018 7:07 am
To: ecf-dev@xxxxxxxxxxx
Subject: Re: [ecf-dev] Problem with Service Endpoint matching when using different network names
Hi Scott,
  thanks again for providing this sample implementation! That makes it very transparent how things work. 

 Actually I thought the ecf-generic provider would work that way ;)

 

 I wasn't able to get the server up and running. Maybe a problem with the launch configuration. See below for the bundles and their states.

 I added a sample service which should by exported by adding something like

 

 @Component(property = {

   "service.exported.interfaces=*",

   "service.exported.configs=ecf.namespace.socket"

   })

 public class HelloService implements IHello{

 

  public HelloService() {

   System.err.println();

  }

  

  @Override

  public void sayHello() {

   System.err.println("Hello");

  }

 

 }

 

 but as said before, the server does not seem to get started. The start code in the Activator does the registration but the RemoteServiceContainerInstantiator.createInstance is never called. 

 Any idea?

 

 Thanks!

 

 Bye Peter

 

 ss

 

 id State Bundle

 0 ACTIVE org.eclipse.osgi_3.12.50.v20170928-1321

   Fragments=22

 2 ACTIVE org.eclipse.equinox.common_3.9.0.v20170207-1454

 5 ACTIVE org.eclipse.ecf.remoteservice.asyncproxy_2.1.0.v20180409-2248

 6 ACTIVE javax.inject_1.0.0.v20091030

 8 ACTIVE org.eclipse.equinox.event_1.4.0.v20170105-1446

 9 ACTIVE javax.annotation_1.2.0.v201602091430

 11 ACTIVE org.eclipse.osgi.util_3.4.0.v20170111-1608

 14 ACTIVE com.ibm.icu_58.2.0.v20170418-1837

 18 ACTIVE org.eclipse.equinox.concurrent_1.1.0.v20130327-1442

 19 ACTIVE org.eclipse.osgi.services_3.6.0.v20170228-1906

 22 RESOLVED org.eclipse.osgi.compatibility.state_1.1.0.v20170516-1513

   Master=0

 23 ACTIVE org.eclipse.equinox.preferences_3.7.0.v20170126-2132

 25 ACTIVE org.apache.batik.css_1.8.0.v20170214-1941

 26 ACTIVE org.eclipse.core.contenttype_3.6.0.v20170207-1037

 27 ACTIVE org.eclipse.core.jobs_3.9.2.v20171030-1027

 31 ACTIVE org.apache.felix.scr_2.0.10.v20170501-2007

 33 ACTIVE org.eclipse.ecf.identity_3.9.0.v20180426-1936

 34 ACTIVE org.eclipse.equinox.registry_3.7.0.v20170222-1344

 41 ACTIVE org.w3c.css.sac_1.3.1.v200903091627

 43 ACTIVE org.eclipse.ecf.provider.tcpsocket.common_1.0.0.qualifier

 48 ACTIVE org.apache.commons.jxpath_1.3.0.v200911051830

 50 ACTIVE org.eclipse.ecf_3.9.0.v20180402-2015

   Fragments=52

 51 ACTIVE org.apache.batik.util_1.8.0.v20170214-1941

 52 RESOLVED org.eclipse.ecf.ssl_1.2.100.v20180301-0132

   Master=50

 58 ACTIVE org.eclipse.core.runtime_3.13.0.v20170207-1030

 68 ACTIVE org.eclipse.ecf.provider.tcpsocket.server_1.0.0.qualifier

 70 ACTIVE org.eclipse.ecf.remoteservice_8.13.0.v20180406-1915

 73 ACTIVE org.eclipse.equinox.app_1.3.400.v20150715-1528

 75 ACTIVE org.eclipse.ecf.provider.remoteservice_4.4.100.v20180516-2213

 76 ACTIVE org.eclipse.ecf.provider_4.8.0.v20180402-2103

 77 ACTIVE org.eclipse.ecf.sharedobject_2.6.0.v20180404-2345

 78 ACTIVE org.apache.felix.gogo.runtime_0.10.0.v201209301036

 79 ACTIVE org.apache.felix.gogo.shell_0.10.0.v201212101605

 80 ACTIVE org.eclipse.equinox.console_1.1.300.v20170512-2111

 81 ACTIVE service.api_1.0.0.qualifier

 82 ACTIVE service.provider_1.0.0.qualifier

 83 ACTIVE org.eclipse.ecf.discovery_5.0.300.v20180306-0211

 84 ACTIVE org.eclipse.ecf.osgi.services.distribution_2.1.200.v20180301-0016

 85 ACTIVE org.eclipse.ecf.osgi.services.remoteserviceadmin.proxy_1.0.100.v20180301-0016

 86 ACTIVE org.eclipse.ecf.osgi.services.remoteserviceadmin_4.6.800.v20180518-0149

 87 ACTIVE org.eclipse.ecf.provider.jmdns_4.3.200.v20180306-0429

 88 ACTIVE org.eclipse.osgi.services.remoteserviceadmin_1.6.200.v20180301-0016

 89 ACTIVE org.eclipse.ecf.remoteservice.eventadmin_1.3.0.v20180426-2032

 90 ACTIVE org.eclipse.ecf.server_2.1.200.v20180302-2006

 91 ACTIVE org.eclipse.equinox.ds_1.5.0.v20170307-1429

 

 

 

 Am 27.07.2018 um 20:08 schrieb Scott Lewis:
 
 
 

 On 7/27/2018 7:22 AM, Peter Hermsdorf wrote: 
 
 
  
  
 Hi Scott, 
  
 
  
 that sounds and looks really promising! I'll need some time to process the information you gave and look at the code and then come back to you. 
  
 
  
 
  
 
 This morning I've added some code to allow properties to set the hostname and port on server side, and to use the ecf.endpoint.id on client side to connect to the given hostname and port. This is working...see TCPSocketServerContainer and TCPSocketClientContainer classes. 
 
 
 
 I've been testing localhost with the LAN-based discovery (zeroconf) so the hostname/port exported in the endpoint description is what is used on the client. If/when other discovery and import is used on the client, then it can do whatever it wants wrt what hostname and port to use to connect to the server. 
 
 
 
 There are some ways that this is limited, but it can be generalized or extended, and I'm hoping it will give a good idea of how to create others. 
 
 
 
 Scott 
 


_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ecf-dev


Back to the top