​Scott, Ram,
To follow up on point 1 below, I agree that the current structure is not ideal. We'll have to change it and I'm looking at some related refactoring over the holiday. With respect to point 2 below, ideally a user would have a collection of clients, one of
which is local. The idea here is that there will always be some base capability provided by the local client, but vendors - like RNET - may provide custom servers that the local client can connect to for more services.
Jay
Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings
From: ice-dev-bounces@xxxxxxxxxxx <ice-dev-bounces@xxxxxxxxxxx> on behalf of Scott Lewis <slewis@xxxxxxxxxxxxx>
Sent: Monday, December 12, 2016 2:30 PM
To: ice-dev@xxxxxxxxxxx
Subject: Re: [ice-dev] Enabling ConnectCoreAction
oops, forgot the edef
<endpoint-descriptions xmlns= "http://www.osgi.org/xmlns/rsa/v1.0.0">
<endpoint-description>
<property name="ecf.endpoint.id" value-type="String" value="ecftcp://localhost:60844/server"/>
<property name="ecf.endpoint.id.ns" value-type="String" value="org.eclipse.ecf.core.identity.StringID"/>
<property name="ecf.endpoint.ts" value-type="Long" value="1481564257877"/>
<property name="ecf.exported.async.interfaces" value-type="String" value="*"/>
<property name="ecf.rsvc.id" value-type="Long" value="0"/>
<property name="endpoint.framework.uuid" value-type="String" value="b0a31ea8-91c0-0016-129a-f2fb6ff6f20f"/>
<property name="endpoint.id" value-type="String" value="496ccbc4-9254-4c94-8431-275cd48dc474"/>
<property name="endpoint.service.id" value-type="Long" value="0"/>
<property name="objectClass" value-type="String">
<array>
<value>org.eclipse.ice.core.iCore.ICore</value>
</array>
</property>
<property name="remote.configs.supported" value-type="String">
<array>
<value>ecf.generic.server</value>
</array>
</property>
<property name="remote.intents.supported" value-type="String">
<array>
<value>passByValue</value>
<value>exactlyOnce</value>
<value>ordered</value>
</array>
</property>
<property name="service.imported" value-type="String" value="true"/>
<property name="service.imported.configs" value-type="String">
<array>
<value>ecf.generic.server</value>
</array>
</property>
</endpoint-description>
</endpoint-descriptions>
On 12/12/2016 11:15 AM, Scott Lewis wrote:
Hi Ram,
Ok, I think I've figured out what's going on.
First, for the client, there is one more bundle that has to be present and then also started. That bundle is:
org.eclipse.ecf.osgi.services.distribution
This bundle should be selected/included in the launch config, set to autostart (true), and the start level should be set to 6 (default start level + 2).
The reason this was not necessary in my environment was that I was working off the 2.2.1 branch (at eclipse.org) and had structured things slightly differently in terms of the client's use of the the remote service contract (ICore). With the way that things
are currently structured on your branch the distribution bundle is necessary.
I'm able to then connect the client to the server with your code. I've included the rscore.xml below that I created (didn't have time yet to use the one you just checked in). It shouldn't be much different from yours.
A couple of comments about how things are currently structured:
1) You currently have the ICore service contract and the Core remote service implementation in the same bundle (org.eclipse.ice.core). This becomes problematic in the remote service case because when the Core implementation is started it exports (makes available
for remote access) a local instance, and this should not be done on the client (only the server). What I would suggest is that the ICore service interface be in the org.eclipse.ice.core bundle and that the Core implementation be moved to another bundle (e.g.
org.eclipse.ecf.core.impl) that is *only* present on the server (it's not actually needed on the client, is it?). The bundle that has ICore must be on both client and server, however, and be of the same package version (guaranteeing the proper version of
the service contract is one of the important things that RSA does).
2) If you do need a local instance of ICore on the client, you should make sure that when it's created and registered it is *not* exported by the client. I think 1 is generally a better way to handle this, but if you wish you can add server/client flag to
Core so that it's not exported if it's the client, and is exported if it's the server.
3) You should also probably add some client-side use of ICore service (injected via DS or some other means), so that you can now test the use of the remote service proxy on the client. I did this with RSCore (I think) in my tests. Please just let me know
if you would like help with that.
Thanks,
Scott
On 12/12/2016 10:31 AM, Ramachandran K. Narayanan wrote:
Hello Scott,
Ah ok. I have committed it now. I was changing it often locally and didn't want the local changes to be tracked, so I hadn't committed it earlier.
I have double checked to make sure I haven't missed any other files.
Regards,
Ram
Hi Ram,
I think the /edef/rscore.xml has to be committed also.
On 12/12/2016 6:31 AM, Ramachandran K. Narayanan wrote:
Hi Scott,
I let the missing file slip by, sorry about that. I have just committed it to the repo now. The relevant branch is also remoteosgi.
The error occurs at the importService(new EndpointDescription(props)) call in ConnectCoreHandler. There is not a lot more information beyond that in the stacktrace, unfortunately.
Regards,
Ram
Hi Ram,
From the bundle_error.txt there is this at the bottom of the stack trace:
Caused by: java.lang.NullPointerException
at org.eclipse.ice.client.common.ConnectCoreHandler$1.get(ConnectCoreHandler.java:92)
This seems to suggest some problem in ConnectCoreHandler class...but I can't seem to find ConnectCoreHandler class when I search for it in the remoteosgi branch on your repo. I see it in the client.widgets/plugin.xml, but no class seems to be in the common
source package. Any idea where ConnectCoreHandler is?
FWIW I can still run the Core OSGi server and then the (updated) 2.2.1 branch ICE client that I created and import the ICore service just fine...so we'll figure this out eventually.
On 12/11/2016 3:08 PM, Ramachandran K. Narayanan wrote:
Hello Scott,
So I tried the bundle list. I had just copied over the 'selected_target_plugins' line from your file over to my
ice.product_linux.launch file. It had a few unresolved dependencies at startup (xtext.ui bundles and org.eclipse.swt) which I manually resolved and 'Validate Plugins' didn't give me any errors further.
Unfortunately, I still get the consumerContainerSelector error. Please find attached a snippet of the error in
bundle_error.txt. My changes are also at:
I ensured I was entering the hostname and port correctly. I verified that the
ecf.endpoint.id matched the output from
Core OSGi.launch in the console. I also specified the hostname as 'localhost' and that gave the same error.
If it helps, I will try this on a Windows system as well, if that makes it easier to test our changes. Please let me know if you might need any other information.
Thanking You,
Ram
Hi Ram,
If you have more trouble, please check everything in on branch and let me know how to get it, and I will help further.
On 12/9/2016 2:25 PM, Ramachandran K. Narayanan wrote:
Hello Scott,
Apologies for the late reply. Thanks for the bundles list, I will take a look at this and see if I can get the import to work.
Regards,
Ram
Hi Ram,
Attached is the ice.product_WINDOWS.launch config that I'm able to run on the ICE client and successfully import an ICore remote service...so the set of ECF bundles should be right (see selected_target_plugins). ECF doesn't have any OS-specific code (i.e.
all bundles are same on linux as on windows).
--
Ramachandran K. Narayanan
(Ram)
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev
--
Ramachandran K. Narayanan
(Ram)
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev
--
Ramachandran K. Narayanan
(Ram)
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev
|