Che: Cannot register LSP editor for jdt urls

[tsmaeder]

In the jdt.ls plugin, we use url schemes to route requests for resources in jar files to jdt.ls. This cannot be achieved by matching *.class files via a regex, since we're talking, for example about a Readme.txt file.
Since the regex in org.eclipse.che.api.languageserver.LanguageServerConfig.RegexProvider.getLanguageRegexes() is only applied to the file name, not the whole uri/path, we cannot achieve this with a language regex.
Document filters provided for this.

[dkuleshov]

The description is not clear, could you please change it to make it more understandable.

This cannot be achieved by matching *.class files via a regex, since we're talking, for example about a Readme.txt file.

Why can't it be achieved?

Since the regex in org.eclipse.che.api.languageserver.LanguageServerConfig.RegexProvider.getLanguageRegexes() is only applied to the file name, not the whole uri/path

That's not true. I see this, it says that we use regular expression against a string that represents a workspace path, not a file name (which is the opposite to "only applied to the file name, not the whole uri/path").

[tsmaeder]

Yes it's true, see LanguageRegexesInitializer.

[tsmaeder]

We are using a protocol extension to fetch source for file in jars. We want to route this request to jdt.ls, in our case. Other language servers may add their own url schemes.

[dkuleshov]

Well, my logic is simple, your statement is "regex is only applied to the filename", however I see that it's also applied to workspace paths, I provide arguments and conclude that the statement is false which means that either description is not full or I misunderstand it.

If you could take a deeper look into LanguageRegexesInitializer class you could see that the real mapping here looks like LanguageServer <-> FileType, while regular expressions are just an intermediate step. FileType class has name patterns and extensions (no uri/path patterns) inside, so using document filters instead of regular expression will give us the same FileType and will not fix the problem. There is an issue related to FileType that may fix this problem as well.

But in general, I still have a feeling that I don't understand the problem, it would be great if you could make the description and the definition of done clearer, especially taking into account that it is a blocker. Perhaps a detailed real life use case example. Thank you.

[gorkem]

@dkuleshov jdt.ls returns a special scheme jdt:// for .class files on dependency jars. IDE needs to invoke some logic on the language server to retrieve the contents of the .class file when it encounters the jdt:// scheme. That is why @tsmaeder needs a way to map a scheme to a language server.

[dkuleshov]

@gorkem I might be wrong, but here what I think:

• Che IDE initially operates with FileType instances, there is FileType <-> LanguageServerEditorProvider or FileType <-> LanguageServer associations for example. So when we want to know which language server to call we first identify FileType and then eventually we know the server. But FileType has no path regular expressions or scheme inside, so we can't associate a language server with a file type based on scheme even if a language server configuration has scheme defined.

• In general regular expressions that we configure in LanguageServerConfig operates with strings, so there should not be any difference between matching ".java$" and "jdt://.class$" if we configure corresponding regular expression.

• We have no proper support for URI neither on a server side nor on a client side, instead we mostly use workspace path and filesystem path entities which does not respect URI schemes.

• It is important to distinguish when we need scheme to map corresponding language server (do we really need scheme here?) and when we have scheme inside of JSON-RPC requests for the logic that is needed to be invoked on already defined language server. Those two cases are completely unrelated i think.

• If I understand correctly, in order to make IDE and server side properly respect URI we need to reorganize client side (the part related to FileTypes) as well as to replace our wsPath/fsPath approach with the one that works with URIs.

• If we introduce DocumentFilters on server side we must use them on the client side as well, that in itself an excellent idea. The problem is that though on server side it will require minor changes (almost nothing), on client side we have a mess of several different approaches - mime types, file types, content types, may be some others, so adding one more identification entity will make life much harder and I hardly imagine a simple way how we can do that.

So I see two different tasks here:

• Unify client side resource identification: add document filters support and remove/rework stale approaches (FileTypeRegistry etc.).
• Replace wsPath/fsPath approach with URIs for both server and client sides

@vparfonov please correct me if I'm wrong somewhere

[vparfonov]

@dkuleshov Good explanation nothing to add form my side

[gorkem]

Of the two tasks you have mentioned do we need to do one or the other? Also I am under the impression that replacing wsPath/fsPath approach is a smaller effort. Is that true?

[dkuleshov]

@gorkem I'm still not sure that I completely understand the problem but I think that

Unify client side resource identification: add document filters support and remove/rework stale approaches (FileTypeRegistry etc.).

should be enough to register servers by their schemas and path regex, while the second task is more of a general improvement and in some way ideological change.

I apologize, it seems I was not clear enough, in fact I don't think that replacement for current wsPath/fsPath approach is a smaller effort. Technically it should not be a problem, however it will include changes in many server and client side components, so that will probably take several weeks to implement and especially to test it.

Perhaps if @tsmaeder could provide an example of a client side code in jdt.ls branch that uses or expected to use schemas and URIs I could be more specific on estimations and requirements.

[gazarenkov]

Why it qualified as a bug?
Even if it should be improved/reworked (not sure since regexp template looks generic enough to cover URI, if needed), this behavior is quite expected.

[vparfonov]

out of date