sts4: `boot-java.live-information.automatic-tracking.on` is not working on vscode.

Describe the bug boot-java.live-information.automatic-tracking.on is not working as described on vscode.

To Reproduce

  1. set boot-java.live-information.automatic-tracking.on to true
  2. open a springboot project. e.g. spring-petclinic
  3. debug the project, live hover information is not shown.
  4. at this time, if you manually run command manage live spring boot process connections, and pick the correct process, it fails after several retries.

Sample https://github.com/spring-projects/spring-petclinic

I remember long time ago it was working well and live information was shown by default. And I find this commit https://github.com/spring-projects/sts4/commit/2cecd451e6c05aead15df1f7a3387428ca58daf0 changed its default value from true to false. So what was the purpose to turn it off?

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 16 (16 by maintainers)

Most upvoted comments

With regards to the process ID: In case we can determine the process ID directly, we could also go down the path to directly tell the language server to connect live hovers for that process. For that case, I would tend to add a specific command param that contains the process ID - instead of reconstructing the name of the command that the language server generates for a Java process that it finds on the machine. That identifier was only be meant to be generated by the language server, then sent to the client, and sent back from the client to the language server (in case you want to connect manually to that specific process). The exact syntax of this generated name is not well defined and can change between platforms, JVMs, etc. So reconstructing that on the client side is dangerous.

Instead, we could introduce the process ID as a command param directly into this game and therefore allow the language server to pick the exact process when the command to connect live hovers arrive.

The language server could also include the process ID as a separate param in the generated command (for completeness). Happy to discuss this in further detail anytime @BoykoAlex

But one of the biggest problems of vscode we learn from user feedbacks is feature exposure. Since we can detect whether actuator is in classpaths, I’m thinking about, is there any chance that we change default value of boot-java.live-information.automatic-tracking.on back to “true”?

Yes, we can switch that to true. Makes sense to me. @BoykoAlex Feel free to make that change.

if it is possible to get the process ID from the debug session?

Yes, technically we can.

If it’s launched in internalConsole, Java debugger is responsible to spawn the process and thus knows its process ID. If it’s launched in integrated or external terminal, vscode will send pid or shellPid to debugger. See RunInTerminalResponse section in DAP specs.

So we can perserve the pid on debugger side, and client side can use DebugSession.customRequest(..) to get the pid. (cc: @testforstephen)