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

[Eskibear]

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 2cecd45 changed its default value from true to false. So what was the purpose to turn it off?

[Eskibear]

VS Code Version: 1.64.2
OS: Windows_NT x64 10.0.22000

Extension version
pivotal.vscode-spring-boot: v1.31.0
redhat.java: v1.3.0

[BoykoAlex]

Your boot app properties requires:

spring.jmx.enabled=true
spring.application.admin.enabled=true

You should be able to connect to the app to see live information after the above properties are set. This is also the reason why automatic connection to process via JMX is off in vscode by default - we need to set these properties somehow when the launch configuration json is created. Eclipse STS variant sets these properties for the launch configuration as command line options hence STS boot LS can connect to the app's process.
There was a change in Spring Boot to set those properties off by default, This the reason why you recall this working before. If you switch back to Boot 2.3 or maybe 2.4 petclinic version, set the above boot-java.live-information.automatic-tracking.on to true it'd work i think.

Long story short we need to contribute our command line options to the java launch config to make this work.

[Eskibear]

Thank you for pointing this out.

You should be able to connect to the app to see live information after the above properties are set.

Yes, then I can enable live information by manually selecting the process. Actually when launching from spring-boot-dashboard extension, above properties are automatically added into launch configuration.

However, with boot-java.live-information.automatic-tracking.on to true, it's still not working automatically. I assume it's a bug of sts-vscode-extension only? (because sts-eclipse works well)

Update: some context information
Recently we've received lots of user complaints about missing features, which in fact has already been implemented in live hover information. This feature is fancy and useful, but it's not easy for users to find and turn on. So the potential fix (if it's a bug) would be very helpful. At least when launching from spring boot dashboard, we should do something to automatically enable live info for them.

[BoykoAlex]

Well... seems like we meant to remove boot-java.live-information.automatic-tracking.on from the UI because of what I've described above but it stayed... Perhaps we should just remove it not to confuse users. Even if we add the boot properties to the java debug/launch config (via VSCode DebugConfigurationProvider it might be possible) there is still a question which process shall we connect to which also might be possible but requires investigation.
(cc: @martinlippert)

[Eskibear]

Interesting. So previously when it was working, how do you determine which process to connect? And what's done in sts-eclipse?

BTW, in spring-boot-dashboard extension, we simply construct a launch configuration with required properties and pass it to java debugger extension.

[BoykoAlex]

We had sort of a "brute force" solution as far as I remember. It was scanning for all java processes running on the system and attempting to connect via JMX and read live info from each all the time every n seconds (that is if I remember this correctly). The performance of this wasn't great and therefore the current solution is let user control when to fetch live data. For this purpose we need to know where to fetch the data from. Thus the extension lets the user pick which java process to connect from the list of running java processes. Eclipse launch API lets us:

1. Customize JVM args and program parameters in the launch config.
2. Notifies when the spring boot is up (i think this is our code not Eclipse's API)
3. Information about the process to connect to. (pid? or a jmx remote url? - need to verify this piece)

Anyway, the above allows to connect to the proper process in the case of Eclipse launch config app start. The VScode bit to achieve the same is yet to be done.

[BoykoAlex]

@Eskibear finally figured it out. It appears that the "brute force" solution is still available via the boot-java.live-information.automatic-tracking.on. However, getting it to work is tricky because specific VM args are required in the launch config. Put the below vmArgs in your launch.json:

"vmArgs": "-Dspring.boot.project.name=spring-petclinic -Dspring.jmx.enabled=true -Dspring.application.admin.enabled=true"

Very important to supply -Dspring.boot.project.name=spring-petclinic (the value is the name of the project). All this machinery to track live processes automatically in VSCode seems to be setup to track boot app processes launched in Eclipse perhaps...

I think at the very least we can supply those 3 parameters above automatically with a VSCode launch extension. I'd try to go even further and connect to only one process rather than track all of them but this is to be determined.

[BoykoAlex]

Should be fixed with 9ef209d

[Eskibear]

Very important to supply -Dspring.boot.project.name=spring-petclinic (the value is the name of the project)

Thanks for the info, and I can confirm that in sts-vscode v1.31.0, the auto-tracking feature gets back to work when providing -Dspring.boot.project.name=spring-petclinic in vmArgs.

[Eskibear]

The fix in 9ef209d is great!
Now it automatically appends required vmArgs if auto-tracking is on and actuator is found in classpaths. Users will see live info automatically, as long as they find the setting and turn it on.
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"?

[BoykoAlex]

Hmm... I'd delegate this decision to @martinlippert.

@Eskibear do you know if it is possible to get the process ID from the debug session? The process id is available on the LS side debug session but seems like this pid never reaches the ui (client side). If we had the pid we could connect directly to the boot app process and this would make auto connect setting to be true by default a no brainer. Otherwise we are faced to turn on process polling by default which may consume quite a bit of cpu.

[Eskibear]

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)

[martinlippert]

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.

[martinlippert]

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

[BoykoAlex]

I have moved the issue of connecting directly to the app here #738

[BoykoAlex]

@Eskibear boot-java.live-information.automatic-tracking.on is on by default with commit 8f3f7d1
If we figure out PID there will be a dedicated preference setting for auto-connect that will also be true by default.