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" <peter.hermsdorf@xxxxxxxxx>
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
|