how to contribute extensions from another language server?

[martinlippert]

I would like to write an extension to the lsp4xml language server that implements some Spring-specific things. The first issue I would like to tackle is to contribute a way to lookup an XSD namespace from the project classpath.

How do I contribute this extension to the lsp4xml language server? I know that I can implement the Java-based SPI, but how is my extension being found at runtime by the lsp4xml language server extension for VSCode or Eclipse, for example?

JDT.LS does something like dynamically looking up extensions and loading them into the OSGi runtime. Is something like that available for the lsp4xml language server, too?

[angelozerr]

@martinlippert I'm so happy that you create this issue!

but how is my extension being found at runtime by the lsp4xml language server extension for VSCode or Eclipse, for example?

• for vscode it will be available for 0.9.2, see https://github.com/redhat-developer/vscode-xml#custom-xml-extensions
• for Eclipse this feature is available in WWD, see https://github.com/eclipse/wildwebdeveloper/blob/master/RELEASE_NOTES.md#xml-language-server-extension-support

You can find a very basic lsp4xml extension with completion in

• https://github.com/angelozerr/lsp4xml-extensions-maven which extend completion for test scope for maven. See https://github.com/angelozerr/lsp4xml-extensions-maven/blob/88ab0ea9abc06c9ea873915df22f807dd9b45a18/org.eclipse.lsp4xml.extensions.maven/src/main/java/org/eclipse/lsp4xml/extensions/maven/MavenCompletionParticipant.java#L35
• https://github.com/angelozerr/vscode-xml-maven the vscode extension which consume lsp4xml-extensions-maven

For the moment it's not possible to communicate inside the completion participant with another Language Server because it requires to:

• access to LanguageClient instance in completion participant
• cast this LanguageClient instance in completion participant into the proper interface which adds a custom request (STSLanguageClient) (ex : ((STSLanguageClient)languageClient).searchSTS(...)
• the cast to STSLanguageClient will work only when XMLServerLauncher will be the capability to add this STSLanguageClient dynamically when launcher is created.
• on client side vscode-xml must give the capability to delegate the searchSTS request to the Spring Tools language client

But this requires microsoft/vscode-languageserver-node#526

I think vscode-xml could provides this binding features at the first step.

[BoykoAlex]

Don't think this can implemented without XML LS and Spring Boot LS talking to each other. microsoft/vscode-languageserver-node#526 has been idle for some time now but I'd go with the command registration/execution approach.
In other words XML LS sends request to execute a command to the client. Client looks up a command (registered by Boot LS) and executes it on the Boot LS. The result is then sent as response via a few hops back to XML LS.
RE: STSLanguageClient... What if we add xml/executeClientCommand to the XmlLanguageClient? It'd be something rather generic, a request from server to client to execute a command (string) with parameters (any[]') and response just Object'. Don't think it'd be a problem adding handling in VSCode for the request above... Should be doable in lsp4e with a patch probably.
These are my thoughts about this for now. Am I overthinking this, missing or misunderstanding anything?

[angelozerr]

These are my thoughts about this for now. Am I overthinking this, missing or misunderstanding anything?

If I understand correctly, you want to manage communication with command like vscode-java provides. I think we can start with this feature.

Have you the intention that Spring Boot vscode depends on vscode-xml ?

[martinlippert]

@angelozerr Ideally I think we don't want the Spring Boot vscode extension to depend on the vscode-xml in a way that requires users to have both installed. I think the overall design here would be:

• the Spring Boot vscode contributes an extension to the vscode-xml
• if there is no vscode-xml installed, just nothing would happen here
• if there is vscode-xml installed, our extension would be used by vscode-xml

In case vscode-xml is around, our extension would call out to the Spring Boot vscode extension via the command mechanism that Alex described above - which basically means (from an abstract point of view) that our vscode-xml extension would call out to the Spring Boot language server to get some information - and once it got the information back, proceed with its work (resolving namespaces in our concrete case).

The underlying problem for us here is that our namespace resolver implementation need to know the Java project context and the classpath of the project to lookup stuff (mappings and concrete XSD files). But the generic XML language server has no knowledge of that, therefore our namespace resolver would need to reach out to someone (the Spring Boot language server, in our case) to collect that information.

Another side note: our plan is to use the same extension for the XML language server in Eclipse as well as VSCode... :-)

[angelozerr]

@angelozerr Ideally I think we don't want the Spring Boot vscode extension to depend on the vscode-xml in a way that requires users to have both installed.

Sorry I don't understand, you mean that you have your own vscode-xml which starts XML Language Server LemMinx ? Why you want to do that?

The underlying problem for us here is that our namespace resolver implementation need to know the Java project context and the classpath of the project to lookup stuff (mappings and concrete XSD files). But the generic XML language server has no knowledge of that, therefore our namespace resolver would need to reach out to someone (the Spring Boot language server, in our case) to collect that information.

At first LemMinx provides URIResolverExtension API that you can implement and you can contribute it. Here an extension sample for resolving XML catalog namespace

lemminx/org.eclipse.lemminx/src/main/java/org/eclipse/lemminx/extensions/catalog/XMLCatalogURIResolverExtension.java

Line 51 in 7fe05f1

if (!CATALOG_NAMESPACE_URI.equals(publicId)) {

If you expose a JDT LS command from Spring Boot LS which provides information for the Java classpath project, the XML Language Server could consume in your custom namespace resolver implemented by LemMinx URIResolverExtension, no?

I think it's shame to have 2 XML Language Server which will be started (on by vscode-xml and one by your vscode-xml) because we will have double XML parsing file. Or perhaps I don't understand correctly your idea?

[martinlippert]

Sorry I don't understand, you mean that you have your own vscode-xml which starts XML Language Server LemMinx ? Why you want to do that?
I think it's shame to have 2 XML Language Server which will be started (on by vscode-xml and one by your vscode-xml) because we will have double XML parsing file. Or perhaps I don't understand correctly your idea?

Nooooo.... :-)

I don't want to run a separate XML language server (by no means). The idea is to contribute an extension to the XML language server (as you described) and let the XML language server use that extension.

Let me clarify on the comment above about the "dependency":
If the user has the XML extension installed (in VSCode or Eclipse), we contribute our extension and enhance the namespace resolving. If the user does NOT have the XML extension installed, we do nothing. We just don't want to force users to install the XML extension if they instal the Spring Boot extension - like you could do with a dependency on the vscode extension level. Makes sense?

[angelozerr]

Nooooo.... :-)

I don't want to run a separate XML language server (by no means). The idea is to contribute an extension to the XML language server (as you described) and let the XML language server use that extension.

Great!

Let me clarify on the comment above about the "dependency":
If the user has the XML extension installed (in VSCode or Eclipse), we contribute our extension and enhance the namespace resolving.

Ok we have the same idea :)

If the user does NOT have the XML extension installed, we do nothing.

It means that you will loose your namespace resolving feature?

We just don't want to force users to install the XML extension if they instal the Spring Boot extension

Is there any reason to do that? For the user it's transparent the vscode-xml installation will be done when you will install Spring Boot, no?

• like you could do with a dependency on the vscode extension level. Makes sense?

Yes!

[BoykoAlex]

Great thanks for the quick feedback. I'll go with the command registration approach for comm between XML and Boot LS. Once there is a working prototype the shape of the solution would be much clearer and we could collaborate on polishing it up :-)

[angelozerr]

Great thanks for the quick feedback. I'll go with the command registration approach for comm between XML and Boot LS. Once there is a working prototype the shape of the solution would be much clearer and we could collaborate on polishing it up :-)

Great!

I think we should have a work on vscode-xml side too.

[angelozerr]

@BoykoAlex I need this custom command support for our internal extension (referenced grammars which show referenced XSD, DTD in the outline). Have you the intention to provide a PR for this support or do you prefer I implement it?

Thanks for your feedback.

[BoykoAlex]

@angelozerr yes, I'll create a draft PR for this today. It'd definitely need corrections. The intention of the PR is to merely show stuff our Spring XML extension needs, then we can figure out perhaps how best to wrap it in some nice API. It is going to be a PR for the XML server and for WWD XML, haven't worked on the VSCode side yet (not worried about it) but planning to

[angelozerr]

This issue is fixed with the following PRs:

• Support for 'xml/executeClientCommand` access to server from extension #905 on LemMinX side
• Support 'xml/executeClientCommand' request redhat-developer/vscode-xml#339 on vscode-xml side

You can find doc about XML command :

• on LemMinxX side https://github.com/eclipse/lemminx/blob/master/docs/LemMinX-Extensions.md#command-service
• on vscode-xml side https://github.com/redhat-developer/vscode-xml/blob/master/docs/Extensions.md#commands

Kudos to @BoykoAlex who has implemented those 2 PRs.