Vladimir Piskarev

Results 101 comments of Vladimir Piskarev

Hi Frank, Thank you for your suggestion, it sounds interesting. Until someone with a deeper knowledge of the subject replies, here are my two cents: 1. Obviously, this would be...

Interestingly, a simple test case ```java MessageJsonHandler jsonHandler = new MessageJsonHandler(ServiceEndpoints.getSupportedMethods(TextDocumentService.class)); jsonHandler.setMethodProvider(requestId -> "textDocument/completion"); ByteArrayOutputStream output = new ByteArrayOutputStream(); StreamMessageConsumer messageConsumer = new StreamMessageConsumer(output, jsonHandler); CompletionItem completionItem = new CompletionItem("default-context-path");...

> The problems comes from client side with LSP4E in Eclipse IDE and it works with vscode. XML language server uses LSP4J and Eclipse IDE LSP4E too. > > So...

> i wonder if the is OS/Eclipse/System Config/Java Version problem @angelozerr Can you also try to execute the test case from https://github.com/eclipse/lsp4j/issues/616#issuecomment-1125947942 on your workstation?

LSP4J does not (cannot) support additional properties for `MessageActionItem` OOTB. By default, GSON deserialization will just create an instance of `MessageActionItem` and not of your subclass, so all of the...

> One other thing I tried doing was making my own custom method to send the same message to the client, but then it complained I had two methods with...

For the record, the change in `vscode-languageserver-node` was introduced via the following commits: https://github.com/microsoft/vscode-languageserver-node/commit/182dfd85183ad42d626422fdb7907dca7fa8c2b0 and https://github.com/microsoft/vscode-languageserver-node/commit/a93e8b5ee26b7fb28245797adbdb0da585c0fb56.

> => how to resolve? is jakarta.websocket a feasible alternative? so that we can drop the javax one? I don't think so, see #536. Could not we just stick to...

Off the top of my head: * In an ideal world, a project should strive for a stable API, but breaking API changes seem to be unavoidable in the LSP4J...

A related question is whether LSP4J will continue to be versioned as a whole (each "part" having the same version).