Handle communication between 2 language servers -> language client registry

When a language server requires some Java features (ex: track change of classpath for Spring Tools LS, collect properties computed by scanning some Java annotations from a project for Quarkus LS), it uses JDT LS the Java Language server:

• it registers custom command on JDT LS server by using Eclipse extension point
• the external language server call this custom command.

This issue is about calling this custom command. Here a simple schema which show you how Quarkus LS communicates with JDT LS:

The basic idea is that Quarkus LS request the Quarkus vscode language client and this client call a vscode java workspace command (coming from the vscode-java language client) which call the JDT LS. See https://github.com/redhat-developer/vscode-quarkus/blob/master/src/extension.ts#L49

In other words the 2 language client instances are used to delegate communication between the 2 language servers.

This mechanism is working but it requires some extra glue and it is not very clean. I would like to improve this mechanism to use custom LSP services instead of executing workspace command.

To do that I need that the 2 language client instances can be available in a language client registry to override languageClient#onRequest (from vscode-quarkus) and delegate the request to the other languageClient#sendRequest (vscode-java).

I create this issue here, because it is related to the vscode language client. In other words it should be very fantastic if vscode-languageclient could provide this languageclient registry kind to register a languageclient instance with an id and get a language client instance from an id.

Many thank's for your help. @martinlippert I think you could be interested with this idea.

Start with the communication flow described in src/extension.ts and review the languageClient#onRequest and languageClient#sendRequest entry points. Determine how two language client instances could be registered and retrieved by id, then verify that the custom request can be delegated without the existing workspace-command glue.