Support using LSP4J with WebSockets

[juliandolby]

I needed to support LSP access from Monaco, the browser-based editor from Microsoft. As far as I could tell, WebSockets are the portable way to do that, so I have created a helper class to implement LSP endpoints on WebSockets. It uses javax WebSocket annotation support, and I have tested it using Tomcat. Would there be interest in me contributing this code?

[jonahgraham]

I am interested. If it is easier, perhaps before making a PR you can point us at where your current implementation is?

[cdietrich]

relates to #189

[juliandolby]

My code is here: https:/wala/IDE/blob/master/com.ibm.wala.cast.lsp.tomcat/source/com/ibm/wala/cast/lsp/tomcat/WalaWebSocketServer.java

The code was written in the context of my specific project using LSP, but I tried to generalize the types to make clear it should work for any LanguageServer

[jonahgraham]

To me this looks interesting, for both language server and (my primary interest) debug server. Having full support for this will probably require some API work, but that should make it easier to use for other endpoints too, like @cdietrich mentions for #189.

[juliandolby]

Cool. I am happy to share this code and you can hack it any way you like. I added Eclipse license headers to make that clear.

[jonahgraham]

In the original issue you mentioned contributing the code. Do you plan on doing that? I see you have since added the license header in the previously shared link. I would like to work with you to factor the code out of wala/IDE into LSP4J, but I don't think I will have time to be editing wala/IDE anytime soon :-( First step would be contributing your code as a PR with a test or two?

[juliandolby]

I do indeed plan on contributing it. I'll be happy to make it into a pull request somewhere. Can you suggest a place to add it?

[juliandolby]

I have now refactored the code a bit to extract the LSP WebSocket server to be independent of my specific server.

[jonahgraham]

How about putting it somewhere near Launcher for the generic parts, and the specialization for the language server around LSPLauncher

You can, or I will if you can't, add the specialization for debug protocol in the same style next to DSPLauncher / DebugLauncher

[juliandolby]

One possible issue: this code needs WebSocket annotations from javax.websocket, and I think those might not be part of J2SE. Hence, if we add this code to the same source tree, it might then need J2EE to compile. If that is the case, we may want to make a separate source tree for this code?

[jonahgraham]

Hmm. That is a good point. I am going to have to solicit input on this from other committers/project lead. @spoenemann Do you have any input on this?

[juliandolby]

Maybe it is not too bad... I added my server class to the org.eclipse.lsp4j project, and I only needed to add a compile dependence on the WebSockets api definition. In particular, I added the following line to its build.gradle file, under dependencies:

compile "javax.websocket:javax.websocket-api:1.1"

[jonahgraham]

What does that do to the MANIFEST.MF? Add an Import-package/Require-bundle? Either one seems problematic if that means there is a whole bunch of dependencies pulled in that wouldn't normally be needed.

[juliandolby]

I guess it would do that, but I only built with gradle. The manifest is generated by buildship? To avoid that, I guess we'd need a different project for the WebSocket support.

[juliandolby]

I have now created a new project in the lsp4j repository that includes only the websocket support. that is the only par of the build that needs the javax.websockets api

[jonahgraham]

Thanks. I am now waiting for @spoenemann or someone else to comment before proceeding.

[spoenemann]

Putting this into a separate project sounds good.

You could also have a look at the websocket adapter we did for integrating Xtext with Sprotty:

https:/theia-ide/sprotty/tree/master/server/xtext-diagram/src/main/java/io/typefox/sprotty/server/xtext/websocket

[juliandolby]

My pull request is here: #211

[kguelzau]

👍 is there a schedule for the v0.8.x release? :-)

[spoenemann]

Probably August.

[jonahgraham]

There is a proposal in #471 upgrade websocket implementation to the Jakarta version. I am making this comment here so those who wrote and were interested in this initial version have a chance to comment before the decision is finalized.

cc: @juliandolby @kguelzau @spoenemann