Support running command before attaching debugger

[fbricon]

It's possible to debug tests running from a Maven build by calling mvn -Dmaven.surefire.debug test, then attaching the debugger to a remote Java process on port 5005, like

{
    "type": "java",
    "name": "Debug (Attach) to Maven tests",
    "request": "attach",
    "hostName": "localhost",
    "port": 5005
}

So this requires 2 separate actions from the user. Ideally, one would define a new 'surefire-debug' task for mvn -Dmaven.surefire.debug test and add "preLaunchTask": "surefire-debug" to the launch configuration. The problem is running that command doesn't return an exit code, since it's waiting for a debugger to attach, so the prelaunch task never finishes and the debugger never kicks in: you're stuck. So it'd be nice if the debugger detected port 5005 is responding, before the preLaunchTask finishes. If preLaunchTasks absolutely must finish before the debugger kicks in, then we might need to have a preLaunchCommand (or whatever better name) instead. Debugger bootstrap waits until port 5005 responds following execution of preLaunchCommand, then proceeds.

[fbricon]

@aeschli does it make sense to generalize that feature request to vscode itself?

cc @gorkem

[gorkem]

We probably need a new a concept like debugTask on the launch that can delegate the running of the debugged application to a task. /cc @weinand

[testforstephen]

@fbricon @gorkem duplicate with https://github.com/Microsoft/vscode-java-debug/issues/33, the preLaunchTask works with mvnDebug tomcat7:run, but it seems you need click the debug button twice.

1. click the first time it will show Listening for transport dt_socket at address: 8000,
2. click the second time the debugger will attach to the port and the mvn process will continue to run.

[weinand]

For node.js debugging we've solved the problem by allowing any program/script to be used in a launch configuration. The only requirement is that the program/script opens a debug port at the end and then the debugger can attach to it.

Example:

first a regular config for a node.js program:

        {
            "type": "node",
            "request": "launch",
            "name": "Launch test.js",
            "program": "${workspaceFolder}/test.js"
        }

Here program is a node.js program passed to a runtimeExecutable. If the runtimeExecutable is not specified we assume "node.exe".

And in the following we set runtimeExecutable to a command "mocha" that runs node.js tests:

        {
            "type": "node",
            "request": "launch",
            "name": "Launch mocha tests",
            "runtimeExecutable": "mocha"
        }

(you can find this in our docu here)

So we have basically generalised the launch config to support two phases:

• first a program is launched in debug mode and serves a debug port
• then the debugger attaches to that port

Maybe you could use a similar approach for Java, e.g. something like this:

{
    "type": "java",
    "name": "Debug Maven tests",
    "request": "launch",
    "runtimeExecutable": "mvn",
    "runtimeArgs": [ "-Dmaven.surefire.debug", "test" ],
    "port": 5005
}

[testforstephen]

@weinand Thanks for the suggestion. Got it.

if java debugger sends mvn -Dmaven.surefire.debug test command by runInTerminalRequest to vscode, vscode will execute it in integrated terminal. But because the mvn command doesn't return an exit code, vscode doesn't need wait the process to exit and will send the process id back. The debugger itself need poll the debug port to see if the launching operation is ready. Right?

[weinand]

Yes, your understanding is correct. Here are some additional details:

There are basically two ways a DA can run a target (the mvn -Dmaven.surefire.debug test in this case):

• it can run the target directly as a sub-process of the DA and track the exit code, process ID, and any output itself (this is the default behaviour used in the node-debug when no console attribute is specified).
• it can use the runInTerminalRequest to delegate the execution to VS Code (and use the user configured shell etc.). In theory the process ID is returned from VS Code to the DA, but it practice VS Code does not know the process ID and it doesn't know the exit code either.

This means the DA cannot really know whether the launching of the target was successful and whether the target is ready for debugging. For this reason the DA starts trying repeatedly to attach to the debug port (and it times out after 20 seconds).

Please note that the DA makes no difference between launching a regular java runtime (e.g. java ...) and launching of a command like mvn -Dmaven.surefire.debug test. So for node-debug there was no additional code needed for supporting arbitrary tools like test runners.

[testforstephen]

Understand, i think i got the answer. Thanks again. Currently we have taken the first way to launch normal java program. And plan to try the second way for those programs with input/output requirement.

[testforstephen]

find no resource to finish it yet, add it to backlog.

[Eskibear]

Any updates? Here is a scenario that by specifying prelaunchtask to execute "mvnDebug" in the "attach" config, I want to debug in one-click. But prelaunchTask seems not to work with background command, as mentioned in https://github.com/Microsoft/vscode-maven/issues/49#issuecomment-417039278

And any ideas about the use case for mvnDebug users?

[testforstephen]

If the preLaunchTask points to a server mode or background task, you should use problemMatcher filter to tell VSCode it's ready. Then the Java debugger has the chance to attach to the mvnDebug port.

Below is the tasks.json spring-boot sample:

        {
            "label": "mvnDebug",
            "type": "shell",
            "command": "mvnDebug spring-boot:run",
            "isBackground": true,
            "problemMatcher": [{
                "pattern": [{
                    "regexp": "\\b\\B",
                    "file": 1,
                    "location": 2,
                    "message": 3
                }],
                "background": {
                    "activeOnStart": true,
                    "beginsPattern": "^.*Preparing to execute Maven in debug mode.*",
                    "endsPattern": "^.*Listening for transport dt_socket at address.*"
                }
            }]
        }

And launch.json sample:

        {
            "type": "java",
            "name": "Debug (Attach)",
            "request": "attach",
            "hostName": "localhost",
            "port": "8000",
            "preLaunchTask": "mvnDebug"
        }

[IcedAnt]

This is a good workaround but there's still the issue of the VS Code popup telling you that errors exist and you have to click "Debug Anyway" to continue.

Maybe we can get a "successMatcher" instead, that attaches the debugger automatically when it matches "endsPattern"?