Why using LoggingStreamConnectionProviderProxy?

[angelozerr]

I'm implementing an LSP console in IJ by mimicing the LSP4E LoggingStreamConnectionProviderProxy, but the main problem with this code is that it doesn't format correctly the JSON request / responses / notfication like vscode does.

It is very hard to read messages and IMHO I think LSP4E should have the same format for LSP logs than vscode to provide teh capability to compare LSP traces between Eclipse IDE and vscode (I did that for IJ).

I wonder why we need LoggingStreamConnectionProviderProxy since we log the message here https://github.com/eclipse/lsp4e/blob/9f06f405409541d2015438a7e153ef674b30e85f/org.eclipse.lsp4e/src/org/eclipse/lsp4e/LanguageServerWrapper.java#LL281C6-L281C16. Calling message.toString() format correctly the LSP request / reponses / notification:

[mickaelistria]

the main problem with this code is that it doesn't format correctly the JSON request / responses / notfication like vscode does.

Indeed, this logger is supposed to happen at protocol level; before the messages are parsed by LSP4J. This is pretty useful for cases where the server sends a message that cannot be processed by LSP4J (imagine LSP4J has a bug or an incompatibility with the latest spec used by the server, like it happened relatively often, which prevents it from turning a message from the stream into a proper LSP message).
In case an error happen during parsing, it is logged by the LoggingStreamConnectionProviderProxy , but maybe not by logMessage.

[angelozerr]

This is pretty useful for cases where the server sends a message that cannot be processed by LSP4J (imagine LSP4J has a bug or an incompatibility with the latest spec used by the server, like it happened relatively often, which prevents it from turning a message from the stream into a proper LSP message).

I have never seen this kind of problem.

The LSP console is very helpfull when you implement a language server to check for instance that your custom code action defines some custom data, etc, and too to discover some bugs. In lemminx project we spend our ime, please share your LSP traces when a user report an issues. Without having this format feature, it will be very hard to study the problem.

[mickaelistria]

I have never seen this kind of problem.

Lucky you ;)

Without having this format feature, it will be very hard to study the problem.

You can always copy the json parts into a json friendly editor and format them. The formatting is not part of the payload of the protocol and when inspecting transport level issues, changing the formatting can hide bugs. Formatting becomes useful when investigating LSP-level messages; and LSP console is probably covering only that part and not the former.
Do you have information about the kind of files the LSP console supports? I imagine the LSPConsole itself may be the one proposing the formatting. If the format is suitable to both cases, then we could try to make LSP4E use it.

[angelozerr]

You can always copy the json parts into a json friendly editor and format them.

It is awfull because you have a lot of messages.

Do you have information about the kind of files the LSP console supports?

vscode manages with a clean mean those messages

[mickaelistria]

I suspect the log format is the one defined in https://github.com/microsoft/language-server-protocol-inspector ; and clients such as LSP Console or lsp-viewer do process this log and take care of the formatted rendering . A contribution to produce that log format in LSP4E would be welcome.

[angelozerr]

No the LSP console of vscode is inside in vscode

[angelozerr]

I discovered that LSP4J provide a tracing class which formats (almost correctly) the LSP messages like vscode https://github.com/eclipse-lsp4j/lsp4j/blob/main/org.eclipse.lsp4j.jsonrpc/src/main/java/org/eclipse/lsp4j/jsonrpc/TracingMessageConsumer.java

In my case (for IJ) I have adapted it and it works like a charm.