Adding a mechanism to control language server lifecycle beyond 'open editors'

[kdvolder]

One of our use-cases extends the LSP with some custom protocol, this is meant to drive a tree-like information view that isn't tied to a specific file or open editor.

This project does almost exactly what we want (i.e support LSP protocol, and provides means to add additional 'custom' protocol).

But we are struggling with the fact that implementation / apis availabe in the current implementation will trigger server shutdown/disconnect when there are no more open editors (i.e. when `connectedDocuments.isEmpty()' in LanguageServerWrapper).

This is a bit problematic for our use-case because we don't want our 'information display view' to stop working when all editors are closed.

So what we'd like is to have some additional mechanism (i.e. new 'official' API) that allows acquiring a 'lease' on a languageserver connection that remains active and keeps the language server alive until it is explicitly disposed.

This would allow us to:

• obtain a connection to language server to communicate using the custom protocol (or standard protocol)
• tie the lifetime of this lease to the lifecycle of the view

I'd be interested in discussing about how this might look and in developing it as a PR against this repo.

What do you all think about this?

As to some initial thoughts from me:

I think the right place of this api would probably be in LanguageServiceAccessor. While that class is marked as 'internal api' it has the right kinds of things in it. I would just want to add a method their that specifically supports our use case. I.e. it allows to obtain a LanguageServerLease (this api class/interface has to be created) based on project and a LanguageServerDefinition.

The details of this api would have to be agreed upon ofcourse, and I would do the work of implementing and submitting a PR to implement it.

[angelozerr]

This project does almost exactly what we want (i.e support LSP protocol, and provides means to add additional 'custom' protocol).

That's great! We use LSP4IJ in our https://github.com/redhat-developer/intellij-quarkus/ and we add custom protocol in:

• QuarkusLanguageClient
• QuteLanguageClient

But we are struggling with the fact that implementation / apis available in the current implementation will trigger server shutdown/disconnect when there are no more open editors (i.e. when `connectedDocuments.isEmpty()' in LanguageServerWrapper).

This is a bit problematic for our use-case because we don't want our 'information display view' to stop working when all editors are closed.

I agree with you, it is annoying. This behaviour comes from the LSP4E (LSP support in Eclipse IDE) because LSP4IJ has been created from LSP4E source. You are not alone in complaining about this issue, see #489

For the moment you can use the hack explained at #489 (comment)

I'd be interested in discussing about how this might look and in developing it as a PR against this repo.

Today LSP4IJ have some default behaviour but we have more and more adoptors who want to customize those behaviours with an LSP API. I have marked those issues with the api-customization label

I have started something (no PR for the moment) to investigate how to provide those LSP API but I'm very busy with our Quarkus Tooling (which is our priority) but I promise you that I will try to do my best to push my work for LSP API. My idea is to initialize those LSP API and I hope adaptors will contribute to improve it. But as it is an LSP API, we must be sure that API will not change (no remove of API, just add API).

I'd be interested in discussing about how this might look and in developing it as a PR against this repo.

I love contribution :) But let me time to initialize LSP API and after that any PR are welcome! For the moment to fix your issue, please use the hack described at #489 (comment)

[angelozerr]

@kdvolder just one question, which language server do you want to integrate with LSP4IJ?

[angelozerr]

@kdvolder see my draft PR which provides the capability to customize the enabled of LSP formatting #543

Even if it doesn't cover your issue please give me feedback if you like the API. For your case we could add a method in the LSPCustomizationServerSupport like shouldStopServerWhenFileAreClosed, but before doing that we need to initialize this API, find the better name, etc.

Any feedback are welcome! Thanks.

[kdvolder]

just one question, which language server do you want to integrate with LSP4IJ?

Technically, it isn't actually a 'language server' (yet) since its exclusively using custom protocol which is not in support of any 'editor features'. It is a server that will support IDE integrations with the 'Tanzu Platform' and it will provide a view showing both the user's local applications as defined in local tanzu config files as well as how these relate to their actual applications deployed and running in their cluster.

Initially this will be focused on providing information displays (kind of like a 'project explorer view' but showing information about tanzu applications). Longer term this may also evolve to dip into 'real LSP' things and provide editor features (content assist, validation, hovers, etc) while editing the config files (which are yaml files).

I think the workaround you suggested will work for us. But I also found a more 'hacky' workaround that I might use instead (TBD). Using some 'reflection hackery' I called into the private 'connect' method on the LanguageServerWrapper and register a 'dummy temp file'. This keeps the ls alive and allows me 'precise control' over when to 'release my lease' (i.e. when to 'disconnect the dummy file'). So in terms of functionality that is slightly 'better' than just setting a really long timeout. Though I suppose in terms of its hacky and fragile nature its rather worse.

Anyhow the API I would like is something that works kind of like that a: 'lease' (here represented by a hacky 'dummy file') that puts an additional 'claim' on the ls and keeps it alive as long as that claim is not explicitly 'released'.

As to custom protocol I was already able to do what I want with existing apis (LanguageServerAccessor + LanguageServerWrapper). But I understand you probably consider these as internal apis. Formalizing a public api to do that sort of thing seems like a good idea and I would certainly support that. So I will take some time to look at your PR and provide some feedback soon. Probably sometime early next week.

Cheers and thanks for your very positive and welcoming response to my query.

[angelozerr]

Technically, it isn't actually a 'language server' (yet) since its exclusively using custom protocol which is not in support of any 'editor features'. It is a server that will support IDE integrations with the 'Tanzu Platform' and it will provide a view showing both the user's local applications as defined in local tanzu config files as well as how these relate to their actual applications deployed and running in their cluster.

Initially this will be focused on providing information displays (kind of like a 'project explorer view' but showing information about tanzu applications). Longer term this may also evolve to dip into 'real LSP' things and provide editor features (content assist, validation, hovers, etc) while editing the config files (which are yaml files).

Thanks for your explanation, it looks like exciting challenge.

I think the workaround you suggested will work for us. But I also found a more 'hacky' workaround that I might use instead (TBD). Using some 'reflection hackery' I called into the private 'connect' method on the LanguageServerWrapper and register a 'dummy temp file'. This keeps the ls alive and allows me 'precise control' over when to 'release my lease' (i.e. when to 'disconnect the dummy file'). So in terms of functionality that is slightly 'better' than just setting a really long timeout. Though I suppose in terms of its hacky and fragile nature its rather worse.

We need really provide some API to avoid using Java reflection. The first step is to provide API liek I have started in my PR and after that, I think you could create a PR to support your need (with a generic mean).

As to custom protocol I was already able to do what I want with existing apis (LanguageServerAccessor + LanguageServerWrapper).

This code comes from LSP4E and I don't master the whole code. I'm trying to clean up step by step, but it takes some times and it ishard to provide a clean API. It is the reason why I think it is a bad idea to use those classes, but today it exists only this way.

Cheers and thanks for your very positive and welcoming response to my query.

You are welcome!

[angelozerr]

@kdvolder pay attention about using LanguageServiceAccessor, the signature will change in 0.7.0,see my comments at #543 (comment)

[angelozerr]

I close this discussion in favor of #556