Provide extension-friendly way to register method handlers for GenericEndpoint

[ruspl-afed]

ATM the only way to register method handlers for GenericEndpoint is annotation. That means that Language Client implementor has limited capabilites to support LSP extension or particular server, because there is no way to delegate the handling of method outside the LanguageClient hierarchy. @JsonDelegate does not help as well - as it just allow to connect another hierarchy - in any case everything should be in place during compile time.

The JsonRpcMethodProvider can help to declare methods, but the should be a way to connect it with handlers as well.

[jonahgraham]

Is this issue different than #371 - especially see comments near the end starting at https://github.com/eclipse/lsp4j/issues/371#issuecomment-541557097

[ruspl-afed]

Is this issue different than #371 - especially see comments near the end starting at #371 (comment) Thanks for reference, I missed that.

It is related, yes. But unlike #371 this one is not a question but rather a kind of requirement :) The component that doesn't support dynamic extension registration looks not really friendly for OSGi and Eclipse. In other words @angelozerr suggested a great way to hack LSP4J and (thanks to him again!) we can try to use this for a while, but it really should be a part of LSP4J main flow.

[angelozerr]

In other words @angelozerr suggested a great way to hack LSP4J and (thanks to him again!) we can try to use this for a while, but it really should be a part of LSP4J main flow.

I totally agree, I would like that LSP4J provides this support without my ugly hack.

@spoenemann suggested me to see how XText LS adds extensible services in https://github.com/eclipse/lsp4j/issues/371#issuecomment-538351680, but I think the register of services in lazy mode (like I have done with my hack) should improve the start of the XText LS.

[ruspl-afed]

@angelozerr on the LS client side it is also not easy to extend the protocol handling. Too much things in LSP4J relies on static method discovery from the given local/remote hierarchy. And LSP4E allows to override a lot of static parts but hides the wiring https://git.eclipse.org/r/plugins/gitiles/lsp4e/lsp4e/+/master/org.eclipse.lsp4e/src/org/eclipse/lsp4e/LanguageServerWrapper.java#241 Submitted https://bugs.eclipse.org/bugs/show_bug.cgi?id=558676 for LSP4E with suggestion to make it configurable.

[angelozerr]

@angelozerr on the LS client side it is also not easy to extend the protocol handling.

With LSP4E you can implement your own LanguageClient by extending LanguageClientImpl to manage custom services (JBoss Tools does that for instance to consume custom microprofile/projectInfo services support collect of Quarkus properties https://github.com/jbosstools/jbosstools-quarkus/blob/a9cce51b82cdf8a4fe5d0754e3dc58c45bda8f7c/plugins/org.jboss.tools.quarkus.lsp4e/src/org/jboss/tools/quarkus/lsp4e/QuarkusLanguageClient.java#L66).

I would like to manage extensible custom services for:

• JDT LS extension to register custom services by using standard LSP protocol instead of using IDelegateCommandHandler

• LSP4XML (XML Language Server) to register a custom service like getClassAttributeValuePosition(int offset) and consumes it in TypeScript for https://github.com/redhat-developer/vscode-xml/issues/212#issuecomment-567084053

[ruspl-afed]

With LSP4E you can implement your own LanguageClient by extending LanguageClientImpl to manage custom services

@angelozerr Yes and No. Yes - I can extend LanguageClientImpl to some extent :) No - I do not see a way to override extremely static call Launcher.createLauncher to participate to the message handling https://git.eclipse.org/r/plugins/gitiles/lsp4e/lsp4e/+/master/org.eclipse.lsp4e/src/org/eclipse/lsp4e/LanguageServerWrapper.java#241

[jonahgraham]

The DAP code in LSP4E had a similar issue, see Bug 549125 - the summary is that calling DSPLauncher.createLauncher is in its own protected method.

[ruspl-afed]

@jonahgraham yes, this is terrible anti-pattern to declare static functions inside public interface. And it is much worse to use and replicate it. Our discussion here clearly demonstrates why. Unfortunally, Java syntax allows to create things like this. It will be great to establish a pipeline check to detect and forbid such a construction.

[jonahgraham]

Great - I look forward to a PR with a suggested solution. @spoenemann and/or @svenefftinge are the ones to convince (LSP4J project leads)

[spoenemann]

I won't object a PR that provides more extensibility if it helps to solve real use cases.

[ruspl-afed]

Thanks! The use case is described in more details here, I will need some time to prepare a PR. Do you have Oomph setup published? I do not see it in the list of projects

[spoenemann]

No, we don't have an Oomph setup yet. See Contributing.md for contributing via Eclipse.

[ruspl-afed]

Workaround suggested for LSP4E https://git.eclipse.org/r/#/c/163465/