Re: [ice-dev] Enabling ConnectCoreAction

["Billings, Jay Jay" <billingsjj@xxxxxxxx>]

Ram,

Yes, you are correct. You should add them similar to the other handlers/actions. Here's a link to a tutorial on it:

http://www.vogella.com/tutorials/EclipseCommands/article.html#tutorial-commands-and-toolbars

You are also correct that the new code should follow the newer pattern.

Do you need a hand or are you in good shape on this?

Jay

Jay Jay Billings
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings

---

From: ice-dev-bounces@xxxxxxxxxxx <ice-dev-bounces@xxxxxxxxxxx> on behalf of Ramachandran K. Narayanan <knarayanan@xxxxxxxxxxxxx>
Sent: Tuesday, November 29, 2016 4:49 PM
To: ice developer discussions
Subject: Re: [ice-dev] Enabling ConnectCoreAction

 

Hello Jay,

Not a problem at all.

I have been going through the plugin.xml and wanted to know if my outline of the steps I need to take, makes sense. I think I will have to make the changes in o.e.i.client.widgets/plugin.xml

1) Define a command in the 'Commands' section, say, o.e.i.client.widgets.commands.ConnectCore. Basically, I add another command to the extension point org.eclipse.ui.commands.

2) Similar to how CreateItemHandler is defined, I add a handler in the extension point org.eclipse.ui.handlers, where the class would point to something like o.e.i.client.common.ConnectCoreHandler and the commandId would be the previously defined command. So does this entry basically map the Handler to the Command name?

3) Define ConnectCoreHandler similar to other handlers, i.e. it extends from AbstractHandler and defines an execute function. The current code in ConnectCoreAction seems to specify paths to the icon gif to use. I guess that is older code as the newer code specifies similar information in the plugin.xml itself.

So ConnectCoreHandler should follow the new code pattern. I am thinking of defining an execute function which spawns a hostname and port dialog box, but this is just for starters.

I know that the end goal as part of issue 262 is to list the Cores that the client is attached to and to separate the client from the build, those would be the next set of steps, once this works.

Hope this helps.

Regards,

Ram

On Tue, Nov 29, 2016 at 8:33 AM Jay Jay Billings <jayjaybillings@xxxxxxxxx> wrote:

Ram and Scott,

Again, apologies for the delay looking at this. I took the whole holiday off.

Scott, will you consider contributing your work with a pull request to the ICE repo? Our contributing.md document describes the process (but you probably already know it). You can tag bug 262.

Ram, all we really have to do to enable the action is put it in the plugin.xml file using extension points. It connects exactly like CreateItemAction and other Action classes in the client.

Jay

On Mon, Nov 28, 2016 at 7:20 PM, Jay Jay Billings <jayjaybillings@xxxxxxxxx> wrote:

Guys,

Apologies for the delay, but I haven't had a chance to follow up on this thread yet. I will soon.

Jay

On Mon, Nov 28, 2016 at 7:00 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:

Hi Ram,

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 

http://www.vogella.com/tutorials/OSGiServices/article.html#declarativeservices_annotations ?

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

--

Jay Jay Billings

Oak Ridge National Laboratory

Twitter Handle: @jayjaybillings

--

Jay Jay Billings

Oak Ridge National Laboratory

Twitter Handle: @jayjaybillings

_______________________________________________
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