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
|