On 11/28/2016 2:55 PM, Ramachandran K. Narayanan wrote:
Hello Scott,
I had a couple of questions regarding the changes.
1) In line 106 in RSCoreConnectAction.java, it says
Client.getDefault() which generates a syntax error as Client
doesn't seem to have it. I am not able to figure out what the
modification should be.
Yeah...I didn't include all the changes to all classes because I
thought that you might want a patch, or a pull request, or something
more complete than an email with attachments. But in any case, all
Client.getDefault() does is return the singleton instance set upon
start...see attached. I think the only thing I changed in Client
was the addition of static getDefault() and getContext() along with
the setting of the instance and context member variables. I'm not
sure if you want to keep Client as it is though, as it serves as the
proxy for the Jersey remote service. With Remote Services the proxy
is created for you upon import. In any event, I'll leave that up to
you.
When the RSCoreConnectAction.run()
method is invoked...see
RSCoreConnectAction.run()...the /edef/rscore.xml
is read, the user-provided hostname and port are
substituted in the appropriate endpoint
description property, and then the
RemoteServiceAdmin.importService(endpointDescription)
is called to connect to the ICore remote host,
and create and register the ICore remote service
proxy.
2) I am able to see where the xml file is processed, but
I am confused as to how I can trigger the
RSCoreConnectAction.run() function. Was this in a driver
file elsewhere? The previous CoreConnectAction.run() is
triggered through ClientWorkbenchWindowAdvisor (which is not
used anywhere) as I had mentioned earlier.
For testing, I added a simple command handler and attached it as a
viewbar button so that I could invoke it and make sure the code in
CoreConnectAction.run() was working properly. This was just for
testing...I've been assuming that you would want to put the connect
action elsewhere in the user interface, but I didn't know where you
would want it to be. I didn't want everyone to be distracted by
the resulting 'franken ui', so I just left it out.
If the patch has this information, I will go through that
instead.
I would rather not include in the patch the UI that I cobbled
together to test.
3) RSCore uses DS annotations. So should I enable
auto-generation of the metadata, as explained in
Yeah you can do that...or if you prefer you can take out the
annotations and use/edit the xml directly. I just have gotten used
to the using the annotations for DS.
Actually the RSCore class (the whole thing) is just intended as an
example...i.e. you can get a hold of ICore proxy instances (created
and registered by ECF) in other ways. I just think that using DS
for the dynamics (the remote service should generally be dynamic,
since it happens at runtime) that DS makes it easy, and I saw that
you are already using DS in other parts of ICE.
Once I enable it, would I need to trigger a build so that
the XML metadata is generated?
Actually, once it's enabled all you should need to do is make a
trivial change to the java code (e.g. insert a space) and then save
it, and the OSGI-INF xml file should be created.
Can I then use it only test the RSCoreConnectAction.run()
function?
Yes, I believe so. The RSCore component does two things: 1) It
has a reference to the
org.osgi.service.remoteserviceadmin.RemoteServiceAdmin service.
This is the OSGi RSA standard service instance (implemented via
ECF). The RSA service is used when run() is invoked to import the
ICore remote service (RSCoreConnectAction line 117) . By 'import'
I mean to connect to remote host, get information about ICore
service, and to create a client-side proxy to the ICore service.
2) To bind the ICore remote service to something once imported via
RSA. You may wish to restructure this so that these two functions
are done in separate parts of the code rather than in a single
class. For example, you might want the ICore proxy instance
injected into some other class/component (2). I just put them
together in RSCore in order to test it quickly. Also, I don't
really know the ICE code well enough to know where/how you wish to
use the ICore proxy.
Note that currently the Core class
exports via the ECF generic provider (rather
than r-osgi). It's not a big deal to change
both the remote service host and consumer to use
either the r-osgi provider, or other providers
(e.g. the Jersey Jax-RS provider).
4) Ah ok. Is it better to use the r-osgi provider rather
than ECF generic?
No, either are fine and for this use case will behave the same.
Other providers require other/additional bundles to be added in both
the Core server and ICE client so given that you already had the ECF
generic provider exporting the ICore service remotely, I just left
it that way.
If you need any more information, please let me know.
If you would rather have a patch...or I've left something else
out...please let me know.
Thanks,
Scott
_______________________________________________
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
