Question on adapting glsp-vscode-integration workflow example

[glsp-bot]

Hi all,

I currently experiment with GLSP. For this purpose, I managed to get the worfklow example (external server) running from https://github.com/eclipse-glsp/glsp-vscode-integration. Furthermore, I tried to adapt this example with my own language and got stuck on the maybe last step of the server initialization.

General setup:

• Server side: Eclipse GLSP 0.9.0.RC1 from Github as source code in Eclipse RCP, including the workflow example as well as my own example

• Client side: VS Code with the glue code from https://github.com/eclipse-glsp/glsp-vscode-integration (master branch), also with the workflow and my own example

For the running workflow example, I get two interesting debug/info log messages on the server side:

• 9336 [Thread-5] INFO er.launch.DefaultGLSPServerLauncher - Starting GLSP server connection for client /127.0.0.1:51757

• 9381 [pool-1-thread-1] DEBUG sp.server.jsonrpc.DefaultGLSPServer - process ActionMessage [action=initializeClientSession, clientId=workflow-diagram_0]

For my own example however, only the first message '[...] Starting GLSP server for client [...]' gets logged---but not the second one. That means to me, the server does not get the 'initializeClientSession' message due to some reason. Debugging on client side (I'm not very firm with TS/JS right now) seems to show the same behavior as for the workflow example, i.e., initializeGLSPClient() in GlspDiagramEditorContext is successfully executed and a message seems to be sent to the server. However on the server side, process(ActionMessage) in DefaultGLSPServer gets not called at all.

Are there any ideas what I might have missed to bind or to configure? Amongst other things, I am very unsure about all the IDs on the client side and how much they influence the communication with the server. For example, I did not found anything on server side matching the client ID settings PORT_ARG_KEY = 'WF_GLSP', readonly id = 'glsp.workflow', extensionPrefix = 'workflow' (all part of workflow-glsp-diagram-editor-context.ts), and 'viewType': 'workflow.glspDiagram' (tsconfig.json), thus, I just adapted these ones by a pure guess (diagramType matches). The server side looks quite good from my point of view, but who knows.

Is the client side even from the right Github repo? In the last post from Rob someone pointed to https://github.com/eclipse-glsp/glsp-client, where the workflow example looks very different.

Best,
Joerg

original thread by Joerg Holtmann

[tortmayr]

Hi,

your general setup looks fine to me.

Amongst other things, I am very unsure about all the IDs on the client side and how much they influence the communication with the server. For example, I did not found anything on server side matching the client ID settings PORT_ARG_KEY = 'WF_GLSP', readonly id = 'glsp.workflow', extensionPrefix = 'workflow' (all part of workflow-glsp-diagram-editor-context.ts), and 'viewType': 'workflow.glspDiagram' (tsconfig.json), thus, I just adapted these ones by a pure guess (diagramType matches). The server side looks quite good from my point of view, but who knows.

Let me try to clarify some of the IDs and their usage.

• PORT_ARG_KEY: You can ignore this, this ID is no longer used and has been replaced with the GLSPEnvVariable.getServerPort() function. Looks like we forgot to remove this unused constant. Sorry for that.

• id = 'glsp.workflow': This is a client-side only id and does not affect the server communication at all. The id can be arbitrary but must be unique across all `GlspDiagramEditorContext's.

• extensionPrefix = 'workflow': The extension prefix is also just used on the client side. It is used for programatically accessing the vscode API and registering stuff like commands or keyboard contexts. If you have a look at the package.json(https://github.com/eclipse-glsp/glsp-vscode-integration/blob/0fe499f6abc246e1c2cb0a31edf333c7525b13d4/example/workflow/extension/package.json#L43) you can see that the extension prefix is used here as well. This means if you change the extension prefix you have to adapt the package.json as well (e.g. 'command': 'myExtensionPrefix.diagram.fit').

• 'viewType': 'workflow.glspDiagram': This is also only used on the client side. In the package.json (https://github.com/eclipse-glsp/glsp-vscode-integration/blob/0fe499f6abc246e1c2cb0a31edf333c7525b13d4/example/workflow/extension/package.json#L36) we declare that .wf types have the viewtype workflow.glspDiagram'. The viewtype composes of the extensionprefix and the '.glspDiagram' suffix. InGlspDiagramEditorContext` we then register a corresponding editor provider(https://github.com/eclipse-glsp/glsp-vscode-integration/blob/0fe499f6abc246e1c2cb0a31edf333c7525b13d4/packages/vscode-integration/src/glsp-diagram-editor-context.ts#L60). This way VSCode knows that .wf files should be opened with the custom GLSP Editor.

Is the client side even from the right Github repo? In the last post from Rob someone pointed to https://github.com/eclipse-glsp/glsp-client, where the workflow example looks very different.

The glsp-client repository contains the workflow example 'core' (https://github.com/eclipse-glsp/glsp-client/tree/master/examples/workflow-glsp) (i.e. sprotty/glsp configuration and bindings). Typically you also need to write some glue code to integrate this core package into the surrounding application (e.g. Theia, VSCode or Eclipse). In the glsp-client repository we provide a sample integration (https://github.com/eclipse-glsp/glsp-client/tree/master/examples/workflow-standalone) using plain html and js.
For VSCode this is done by integrating the workflow example core into a webview. If you have a look at the main.ts file in the workflow example webview directory you can see that we import the package @eclipse-glsp-examples/workflow-glsp
(https://github.com/eclipse-glsp/glsp-vscode-integration/blob/0fe499f6abc246e1c2cb0a31edf333c7525b13d4/example/workflow/webview/src/main.ts#L19).

[glsp-bot]

[Joerg Holtmann]

Hi,
thanks for your detailed explanations! These gave me the hint that I missed to configure/bind many things on the client side as part of the webview, so now I have a plan what to do next (instead of looking at IDs)! :-)