[vscode-spring-boot] Connect to launched spring boot app directly

[BoykoAlex]

Currently app boot launched from vscode can either be connected to show live hovers manually via the command or by enabling boot-java.live-information.automatic-tracking.on which turns on resources consuming spring boot process tracker machinery on the LS side.
If it is possible to extract the PID of the launched spring boot app the direct connection to the app can be established without having spring boot process tracker working on the LS side.

PID from VSCode: #733 (comment)
Discuss with @martinlippert the connect/reconnect/disconnect commands: #733 (comment)

Also new preference setting might be needed to automatically connect on startup as well removing boot-java.live-information.automatic-tracking.on and other settings related to process tracking from VSCode UI.

(cc: @martinlippert @Eskibear)

[BoykoAlex]

Hello @testforstephen! Can you recommend any good way to get process id corresponding to the java process launched for the DebugSession? Think it'd be great to get the PID somehow with DebugSession.customRequest(..) as @Eskibear suggested here #733 (comment)
I have also tried to add a DAP message tracker via VSCode.debug.registerDebugAdapterTrackerFactory('*', new DapTrackerFactory()); which could have helped getting PID from the response to runInTerminal DAP request. However, as you can see from the response below only the shell process id is present and optional PID is missing. If you could add the PID in the response that would probably be a sufficient solution as well i think.
Thanks in advance @testforstephen for taking a look at this stuff!

-> DAP message: {
  "command": "runInTerminal",
  "arguments": {
    "kind": "integrated",
    "title": "Java Debug Console",
    "cwd": "/Users/aboyko/Documents/workspace-spring-tool-suite-4-4.9.0.RELEASE/spring-petclinic",
    "args": [
      "/Library/Java/JavaVirtualMachines/jdk1.8.0_151.jdk/Contents/Home/bin/java",
      "-agentlib:jdwp=transport=dt_socket,server=n,suspend=y,address=localhost:51400",
      "-Dspring.jmx.enabled=true",
      "-Dspring.application.admin.enabled=true",
      "-Dspring.boot.project.name=spring-petclinic",
      "-cp",
      "/var/folders/ks/1ds4bg156ls0xbgcgxfdh2x80000gq/T/cp_acp3co4qhbse8eq8fsy3xdga9.jar",
      "org.springframework.samples.petclinic.PetClinicApplication"
    ],
    "env": {}
  },
  "seq": 2,
  "type": "request"
}
lib/debug-config-provider.ts:70
<- DAP message: {
  "type": "response",
  "seq": 3,
  "command": "runInTerminal",
  "request_seq": 2,
  "success": true,
  "body": {
    "shellProcessId": 87826
  }
}

[testforstephen]

However, as you can see from the response below only the shell process id is present and optional PID is missing.

When handling runInTerminal DAP request, the Java process running on the terminal is owned by VS Code client. And the value "shellProcessId" you see is actually returned by VS Code client. Java Debugger cannot get the PID directly as well. The shellProcessId should be the parent process of the actual Java process, how about using it to find the right Java process?

[BoykoAlex]

@testforstephen I suppose you're suggesting getting a child process id (java process pid) from the parent process id (shellProcessId) doing something like you've done here https://github.com/microsoft/vscode-java-debug/blob/5fc394dfa3aadb3489662ea478e4089ba85b7199/src/processTree.ts: Getting all processes with the platform specific shell command and then picking the one with ppid === shellProcessId). Is this correct?

I thought you have the pid of the java process here: https://github.com/microsoft/java-debug/blob/a0e31fc8bda7dbe604ef94aabd769bfb0a26bbbc/com.microsoft.java.debug.core/src/main/java/com/microsoft/java/debug/core/adapter/handler/LaunchWithDebuggingDelegate.java#L109
from VirtualMachine.process(). Or is this not the launched java app process?

[testforstephen]

yes, you can refer to processTree.ts code to find the child process of shellProcessId.

When launched in terminal, the debugger will spell out the Java command line first and send it to the terminal (shell). It's the terminal that starts the Java process, and the debugger attaches to that process via a local socket port. You will see VirtualMachine.process() returns null.

When launched in internalConsole, the Java process is started by the debugger using Java API Runtime.getRuntime().exec(), and VirtualMachine.process() has value.

[BoykoAlex]

@testforstephen Any chance you could add support for me to call: DebugSession.customRequest('shellProcessId'). i.e. custom request handler for shellProcessId command with no args. Hopefully IDebugContext has the shell process id. The reason is that DAP response to runInTerminal request comes without any data about the DebugSession to which the shell pid corresponds. With DebugSession.customRequest('shellProcessId') this issue will be solved.

(I've attempted to add it myself but wasn't able to do it properly - was getting "Unrecognized request..." for my message)

Tried adding in DapAdapter:
registerHandler(new PidHandler());

where PidHandler:

public class PidHandler implements IDebugRequestHandler {

    @Override
    public List<Requests.Command> getTargetCommands() {
        return Arrays.asList(Requests.Command.PID);
    }

    @Override
    public CompletableFuture<Messages.Response> handle(Requests.Command command, Requests.Arguments arguments, Messages.Response response,
                                                       IDebugAdapterContext context) {
        response.body = new PidBody(context.getDebuggeeProcess().pid());
        return CompletableFuture.completedFuture(response);
    }

    public static class PidBody extends Responses.ResponseBody {
        public long pid;
        PidBody(long pid) {
            this.pid = pid;
        }
    }

}

[testforstephen]

@BoykoAlex I add a PR at Java debugger side. microsoft/java-debug#399

[martinlippert]

@BoykoAlex Isn't this already done as part of the latest release of the Spring Boot extension for VSCode?

[BoykoAlex]

Yes, this all done now and even released.