Cool, thanks for testing.

schrieveslaach (9ce2318b) at 04 Oct 10:09

When I use the new setup method via lspconfig then I get the error below.

https://github.com/mfussenegger/nvim-jdtls/?tab=readme-ov-file#via-lspconfig

Error executing vim.schedule lua callback: ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:171: attempt to index field 'handl
ers' (a nil value)                                                                                                                       
stack traceback:                                                                                                                         
        ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:171: in function 'init_config'                                       
        ...al/share/nvim/lazy/sonarlint.nvim/lua/sonarlint/java.lua:166: in function ''                                                  
        vim/_editor.lua: in function ''                                                                                                  
        vim/_editor.lua: in function <vim/_editor.lua:0>                                                                                 

I couldn't figure out how to delay or postpone sonarlint configuration after the nvim-jdtls has done it's init setup.

schrieveslaach (1d49a469) at 04 Oct 10:09

Fixes #36

schrieveslaach (e6b8ac4d) at 03 Oct 10:19

After changing my dotfiles to use also the new jdtls initialization, I could reproduce your recent error. Now, it should be working fine. Can you give it another try?

schrieveslaach (9ce2318b) at 03 Oct 10:07

I found another approach that's get rid of the dependency on language/status. Do you mind to check if this is working with new jdtls setup. With the old setup it works.

schrieveslaach (0eda4467) at 02 Oct 10:06

@azdanov, can you try !27 (merged) to see it that fixes the issue?

Fixes #36

schrieveslaach (12a749c8) at 30 Sep 11:17

schrieveslaach (6a3f95e0) at 30 Sep 11:10

schrieveslaach (eb3d9c16) at 30 Sep 11:08

schrieveslaach (7feaa7ad) at 28 Sep 11:01

schrieveslaach (1281dbb4) at 28 Sep 10:57

Yes, that could be done to prevent the crashing. What bothers me though, that a client can crash the server and currently sonarlint-language-server relies on the client to not crash the server (see also my comment here).

Let's see how they respond.

Meanwhile, you should be able to prevent the crash in your local sonarlint.nvim conf:

         require("sonarlint").setup({
            server = {
               -- …
               init_options = {
                  connections = vim.empty_dict(),
                  rules = vim.empty_dict(),
                  automaticAnalysis = true,
               },
            },
         })

FYI: https://github.com/SonarSource/sonarlint-language-server/pull/532

diff --git a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
index bf0bdd38..b8a76ef6 100644
--- a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
+++ b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
@@ -19,6 +19,7 @@
  */
 package org.sonarsource.sonarlint.ls;
 
+import java.util.Collections;
 import java.util.Map;
 
 public record SonarLintLanguageServerInitializationOptions(
@@ -31,7 +32,7 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> additionalAttributes,
   String clientNodePath,
   boolean focusOnNewCode,
-  boolean automaticAnalysis,
+  Boolean automaticAnalysis,
   String omnisharpDirectory,
   String csharpOssPath,
   String csharpEnterprisePath,
@@ -41,4 +42,16 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> rules,
   Map<String, Object> connections) {
 
+  public SonarLintLanguageServerInitializationOptions {
+    if (rules == null) {
+      rules = Collections.emptyMap();
+    }
+    if (connections == null) {
+      connections = Collections.emptyMap();
+    }
+    if (automaticAnalysis == null) {
+      automaticAnalysis = Boolean.TRUE;
+    }
+  }
+
 }

This change did the trick. Digging into the diff of the release revealed to me that sonarlint-language-server relies on the client to initialize some maps. I'll create a PR and see if they'll merge it.

I can confirm that I'm running into the same issue. I created a fix for the NPE locally and tried to see if that is enough and if this local fix could be upstreamed. Here is the fix:

diff --git a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
index bf0bdd38..3a797b72 100644
--- a/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
+++ b/src/main/java/org/sonarsource/sonarlint/ls/SonarLintLanguageServerInitializationOptions.java
@@ -19,6 +19,7 @@
  */
 package org.sonarsource.sonarlint.ls;
 
+import java.util.Collections;
 import java.util.Map;
 
 public record SonarLintLanguageServerInitializationOptions(
@@ -41,4 +42,13 @@ public record SonarLintLanguageServerInitializationOptions(
   Map<String, Object> rules,
   Map<String, Object> connections) {
 
+   public SonarLintLanguageServerInitializationOptions {
+      if (rules == null) {
+         rules = Collections.emptyMap();
+      }
+      if (connections == null) {
+         connections = Collections.emptyMap();
+      }
+   }
+
 }

That fixes the error message and the LSP starts. However, there must be more adjustment because I don't get any diagnostics from Sonarlint LS.

schrieveslaach (29ae9ff6) at 18 Sep 06:28

schrieveslaach (067f041f) at 18 Sep 06:14

schrieveslaach (dc570255) at 18 Sep 06:14

With this commit the rule description is converted from HTML to markdown so that the display in the UI looks nicer.

schrieveslaach (067f041f) at 18 Sep 06:12

schrieveslaach (07813986) at 11 Sep 11:44

schrieveslaach (4af5879f) at 11 Sep 07:50

schrieveslaach (157182e4) at 05 Sep 11:20

... and 1 more commit

Oh, … Yes, I messed up the version numbers. I'll check it out.

This issue has been fixed upstream in sonarlint-language-server 4.13. Closing as duplicate of #24 (closed).

schrieveslaach (ec25369c) at 05 Sep 07:46

schrieveslaach (00ad9917) at 04 Sep 17:00

schrieveslaach (76624364) at 04 Sep 11:00

schrieveslaach (fbb02da0) at 04 Sep 10:49

schrieveslaach (e4804832) at 04 Sep 10:48

schrieveslaach (beba2668) at 04 Sep 10:45

... and 1 more commit

schrieveslaach (f22d199c) at 04 Sep 10:44

schrieveslaach (7e642899) at 04 Sep 08:47

schrieveslaach (e5c6181f) at 28 Aug 16:12

My PR on GitHub got closed because this broke the VSCode plugin:

A side effect from this change is that users will keep seeing the notification even though they chose the "don't show again" action in VSCode.

There is a new idea and one has to implement it and there is now an official Jira ticket (SLLS-345).

This issue seems to be related to #29 in which I tried to provide an upstream solution that will notify if something is wrong with the NodeJS binary. However, the PR on GitHub got closed due to wrong assumptions on my end.

Can you check if your NodeJS binary is available on the PATH?

schrieveslaach (f337f660) at 19 Aug 06:50

@metal3d, I'm not sure if such things should be documented here because usually the package-manager instruction own its own are sufficient enough.

I'm also wondering why you need to work with vim.schedule because looking at my sonarlint.nvim setup there is no need for it.

schrieveslaach (23ad1736) at 12 Aug 20:28

With this commit the rule description is converted from HTML to markdown so that the display in the UI looks nicer.

schrieveslaach (c99c9a92) at 12 Aug 19:59

schrieveslaach (44489622) at 12 Aug 16:59

schrieveslaach (de6035ec) at 10 Aug 07:56

schrieveslaach (ac6623ef) at 07 Aug 08:42

... and 1 more commit

schrieveslaach (c97be090) at 02 Aug 20:13

schrieveslaach (5c3e0bb6) at 02 Aug 18:29

schrieveslaach (522b9b8a) at 02 Aug 13:09

FYI: Implemented by ffba8a6c and cc32d4e9.

Implemented by ffba8a6c and cc32d4e9.

This PR implements the handling of connected mode by sonarlint. This is largely inspired by how the vscode plugin does it.

The plugin will prompt the user for a token if necessary and will store it locally (as I've seen other plugins do, like Codeium). A future improvement could be to store those tokens in a more secure place.

Changes

• Updated README.md with instructions for connected mode setup
• Added handler for sonarlint/getTokenForServer in sonarlint.lua
• Created auth.lua to manage SonarLint tokens
• Added Neovim command SonarLintToken to input tokens

Fixes #5.

Implemented by ffba8a6c and cc32d4e9.

Fixes #5

@Alfaixx, I took your MR and included as ffba8a6c into main line. Also, I built on the resolve issue command in cc32d4e9. Thanks for the initial contribution.

As the changes are squashed and merged into mainline, I'll close this MR.

Basically title, perhaps a little bit rocky with the token config and requiring before_init for multiple projects, but it's a start I suppose. Let me know if you'd like me to change anything

Hello,

First of all thanks for your plugin, it's a great help for my everyday work :)

I'm looking for a way to set up the "connected mode" (https://docs.sonarsource.com/sonarqube/latest/user-guide/sonarlint-connected-mode/), but the doc only refers to vscode/eclipse/... Do you know if there's an easy way to setup this connected mode using your plugin ?

Thanks a lot

schrieveslaach (cc32d4e9) at 02 Aug 12:57

... and 1 more commit

schrieveslaach (475127ff) at 02 Aug 07:44

schrieveslaach (74bb9e1e) at 22 Jul 08:22

... and 1 more commit

schrieveslaach (98969ab4) at 15 Jul 18:39

... and 1 more commit

schrieveslaach (689d7acf) at 14 Jul 19:54