-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GLSPServer should be able to handle multiple GLSPClient proxies #420
Closed
tortmayr opened this issue
Oct 17, 2021
· 1 comment
· Fixed by eclipse-glsp/glsp-eclipse-integration#45
Closed
GLSPServer should be able to handle multiple GLSPClient proxies #420
tortmayr opened this issue
Oct 17, 2021
· 1 comment
· Fixed by eclipse-glsp/glsp-eclipse-integration#45
Labels
Comments
After reconsideration the second usecase is probably only relevant for the eclipse-integration and should probably be fixed there |
tortmayr
added a commit
to eclipse-glsp/glsp-eclipse-integration
that referenced
this issue
Oct 27, 2021
Server - Update dependencies to consume latest DI rework - Update .tpd file and rename it to `r2021-03` - Adapt existing server code to conform to latest API changes - Align prefix for eclipse-integration specific classes. (Use `Ide` over `Eclipse`) - Update .settings/org.eclipse.jdt.ui.prefs for glsp.ide.editor to ensure that the copyright header for new files has the correct year. - Introduce a wrapper `GLSPClient` implementation (`IdeGLSPClient`) that handles dedicated GLSPClient proxies for each client session and can be connected to the `GLSPServer` (#420) - GLSPDiagramEditor: -- Refactor Browser-URL generation -- Generate applicationID and send to client via url query - Add command to DiagramMenu to open the current DiagramWidget in an external browser for debugging purposes. Client: - Update dependencies to latest glsp nightlies - Adapt code to conform to latest protocol changes - [WF-Example] Retrieve application id from url params - [WF-Example] Update webpack config to webpack 4 and ensure proper source-map generation for debugging Fixes eclipse-glsp/glsp/issues/418 Fixes eclipse-glsp/glsp/issues/420
tortmayr
added a commit
to eclipse-glsp/glsp-eclipse-integration
that referenced
this issue
Oct 27, 2021
Server - Update dependencies to consume latest DI rework - Update .tpd file and rename it to `r2021-03` - Adapt existing server code to conform to latest API changes - Align prefix for eclipse-integration specific classes. (Use `Ide` over `Eclipse`) - Update .settings/org.eclipse.jdt.ui.prefs for glsp.ide.editor to ensure that the copyright header for new files has the correct year. - Introduce a wrapper `GLSPClient` implementation (`IdeGLSPClient`) that handles dedicated GLSPClient proxies for each client session and can be connected to the `GLSPServer` (#420) - GLSPDiagramEditor: -- Refactor Browser-URL generation -- Generate applicationID and send to client via url query - Add command to DiagramMenu to open the current DiagramWidget in an external browser for debugging purposes. Client: - Update dependencies to latest glsp nightlies - Adapt code to conform to latest protocol changes - [WF-Example] Retrieve application id from url params - [WF-Example] Update webpack config to webpack 4 and ensure proper source-map generation for debugging - [WF-Example] Fix webpack build to support codicons (#406) Fixes eclipse-glsp/glsp/issues/418 Fixes eclipse-glsp/glsp/issues/420 Part of eclipse-glsp/glsp/issues/406
tortmayr
added a commit
to eclipse-glsp/glsp-eclipse-integration
that referenced
this issue
Nov 5, 2021
* #418#420 Consume server DI rework Server - Update dependencies to consume latest DI rework - Update .tpd file and rename it to `r2021-03` - Adapt existing server code to conform to latest API changes - Align prefix for eclipse-integration specific classes. (Use `Ide` over `Eclipse`) - Update .settings/org.eclipse.jdt.ui.prefs for glsp.ide.editor to ensure that the copyright header for new files has the correct year. - Introduce a wrapper `GLSPClient` implementation (`IdeGLSPClient`) that handles dedicated GLSPClient proxies for each client session and can be connected to the `GLSPServer` (#420) - GLSPDiagramEditor: -- Refactor Browser-URL generation -- Generate applicationID and send to client via url query - Add command to DiagramMenu to open the current DiagramWidget in an external browser for debugging purposes. Client: - Update dependencies to latest glsp nightlies - Adapt code to conform to latest protocol changes - [WF-Example] Retrieve application id from url params - [WF-Example] Update webpack config to webpack 4 and ensure proper source-map generation for debugging - [WF-Example] Fix webpack build to support codicons (#406) Fixes eclipse-glsp/glsp/issues/418 Fixes eclipse-glsp/glsp/issues/420 Part of eclipse-glsp/glsp/issues/406
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently the GLSP server can only handle one GLSPClient proxy interface that is used globally used by ClientSession to send action messages to their client (frontend). This works perfectly fine for Theia and VScode use cases because here we use one socket connection from the Theia/VScode backend to the GLSP server. However, this does not necessarily work for pure websocket connections (e.g. Eclipse Integration). In this case each client session establishes its own websocket connection and has as a consequence also its dedicated
GLSPClient
instance. This was not an issue up util now because we used on GLSP per client session as a workaround. With #150 this workaround is no longer necessary and the Session concept can be used as intended in the Eclipse integration. However, in order to do so the issue of handling multipleGLSPClient
instances needs to be resolved.I created a simple figure to illustrate the problem. Usecase A is currently supported and Usecase B needs to be supported in order to properly implement the client session concept into the Eclipse integration (and any other implementation that communicates directly via multiple (web) sockets with one GLSPServer
The easies way to do this would be the implementation of a
MultiGLSPClient
facade implementation that is directly connected with the server and then internaly delegates to the corresponding actual GLSPClient interface for each action message.The text was updated successfully, but these errors were encountered: