-
Notifications
You must be signed in to change notification settings - Fork 1
Client Server API
Language that are registered here are always xtext languages.
Since we are in the semantics repository we can use java ServiceLoader to add new ILSSetups, which register a language.
interface ILSSetup {
def Injector doLSSetup()
}
class SCTXLSSetup implements ILSSetup {
override doLSSetup() {
return SCTXIdeSetup.doSetup()
}
}
A language that wants to be included in the LS can implement this interface. Registering SCTXLSSetup via ServiceLoader allows to register all available languages like this:
for (contribution: KielerServiceLoader.load(ILSSetupContribution)) {
contribution.LSSetup.doLSSetup()
}
This is called in the LSCreator class.
Have a look at one of the LSSetups defined in the semantic or have a look at the AbstractLsCreator so see how the pragmatics languages are registered.
This is a LanguageServerExtension. It has to be used in the de.cau.cs.kieler.language.server plugin. Since the language-server-plugin should not have dependencies to all plugins that define a language server extension dependency inversion is used to prevent that. A ServiceLoader via dependency inversion does exactly that.
Here is such an example extension, the KiCoolLanguageServerExtension:
package de.cau.cs.kieler.kicool.ide.language.server
/**
* @author really fancy name
*
*/
@Singleton
class KiCoolLanguageServerExtension implements ILanguageServerExtension, CommandExtension, ILanguageClientProvider {
// fancy extension stuff
KeithLanguageClient client
// A language server extension must implement the initialize method,
// it is however only called if the extension is registered via a language.
// This should never be the case, so this is never called.
override initialize(ILanguageServerAccess access) {
this.languageServerAccess = access
}
// implement ILanguageClientProvider
override setLanguageClient(LanguageClient client) {
this.client = client as KeithLanguageClient
}
// implement ILanguageClientProvider
override getLanguageClient() {
return this.client
}
}
The CommandExtension defines all commands (requests or notifications) that are send from client to server. An example how this looks like can be seen in the code snippet Example CommandExtension is an example how to define a server side extension interface.
The ILanguageClientProvider should be implemented by an extension that plans to send messages from the server to the client.
This language server extension is provided by a corresponding contribution, which is later used to access it:
package de.cau.cs.kieler.kicool.ide.language.server
import com.google.inject.Injector
import de.cau.cs.kieler.language.server.ILanguageServerContribution
/**
* @author really fancy name
*
*/
class KiCoolLanguageServerContribution implements ILanguageServerContribution {
override getLanguageServerExtension(Injector injector) {
return injector.getInstance(KiCoolLanguageServerExtension)
}
}
Create a file called de.cau.cs.kieler.language.server.ILanguageServerContribution in <plugin>/META-INF/services/ (in this example this is de.cau.cs.kieler.kicool.ide). The name of the file refers to the contribution interface that should be used to provide the contribution. The content of the file is the following:
de.cau.cs.kieler.kicool.ide.language.server.KiCoolLanguageServerContribution
This is the fully qualified name of the contribution written earlier.
The language server uses all LanguageServerExtensions like this:
var iLanguageServerExtensions = <Object>newArrayList(languageServer) // list of all language server extensions
for (lse : KielerServiceLoader.load(ILanguageServerContribution)) { // dynamically load all contributions to add LS extensions
iLanguageServerExtensions.add(lse.getLanguageServerExtension(injector))
}
The resulting list of implementions is used to add the extensions to the language server.
The interfaces used for dynamic registration are in the semantics repository. If you define a pragmatics LS extension you have to statically add these extensions to your list, as seen in the LSCreator:
override getLanguageServerExtensions() {
constraints = injector.getInstance(LayeredInteractiveLanguageServerExtension) // Not in semantics
rectPack = injector.getInstance(RectpackingInteractiveLanguageServerExtension) // Not in semantics
iLanguageServerExtensions = newArrayList(constraints, rectPack)
for (lse : KielerServiceLoader.load(ILanguageServerContribution)) {
iLanguageServerExtensions.add(lse.getLanguageServerExtension(injector))
}
return iLanguageServerExtensions
}
See the example above for ServiceLoader and initial stuff.
What is still missing are the contents of the CommandExtension implemented by the KiCoolLanguageServerExtension. This is an interface defining all additional commands. The CommandExtension looks like this.
package de.cau.cs.kieler.kicool.ide.language.server
import java.util.concurrent.CompletableFuture
import org.eclipse.lsp4j.jsonrpc.services.JsonRequest
import org.eclipse.lsp4j.jsonrpc.services.JsonSegment
/**
* Interface to the LSP extension commands
*
* @author really fancy name
*
*/
@JsonSegment('keith/kicool')
interface CommandExtension {
/**
* Compiles file given by uri with compilationsystem given by command.
*/
@JsonRequest('compile')
def CompletableFuture<CompilationResults> compile(String uri, String clientId, String command, boolean inplace);
/**
* Build diagram for snapshot with id index for file given by uri. Only works, if the file was already compiled.
*/
@JsonRequest('show')
def CompletableFuture<String> show(String uri, String clientId, int index)
/**
* Returns all compilation systems which are applicable for the file at given uri.
*
* @param uri URI as string to get compilation systems for
* @param filter boolean indicating whether compilation systems should be filtered
*/
@JsonRequest('get-systems')
def CompletableFuture<Object> getSystems(String uri, boolean filterSystems)
}
This defines three json-rpc commands: keith/kicool/compile, keith/kicool/show, keith/kicool/get-systems. These are implemented in KiCoolLanguageServerExtension (since it implements the CommandExtension as seen above).
Not only messages from client to server but rather messages from server to client might be needed.
Messages that can be sent from server to client are defined in the KeithLanguageClient:
/**
* LanguageClient that implements additional methods necessary for server client communication in KEITH.
*
* @author really fancy name
*
*/
@JsonSegment("keith")
interface KeithLanguageClient extends LanguageClient {
@JsonNotification("kicool/compile")
def void compile(Object results, String uri, boolean finished);
@JsonNotification("kicool/cancel-compilation")
def void cancelCompilation(boolean success);
// Not only notifications, but also server client requests should be possible, but currently there is no use case for that.
}
These messages can be caught on the client side by defining the message that is caught like this:
lsClient.onNotification(externalStepMessageType /* this is a string */, (message: SimulationStepMessage) => {
this.handleStepMessage(message)
})
or like this:
lsClient.onNotification(
"general/replaceContentInFile",
this.handleReplaceContentInFile.bind(this)
);
In both cases, a message type (string) and a handler are needed.
The method should receive all parameters specified in the KeithLanguageClient interface on the server side.
Such a notification from server to client is sent like this:
future.thenAccept([
// client is the KeithLanguageClient registered in a LanguageServerExtension that implements a ILanguageClientProvider
// compile is the command defined in the KeithLanguageClientInterface
client.compile(new CompilationResults(this.snapshotMap.get(uri)), uri, finished)
])
Not needed anymore. This is done by VS Code.