[Quarkus] Can't debug Quarkus application

[svor]

While testing vscode-quarkus extension I detected a problem: if execute Quarkus: Debug Current Quarkus Project command, I see a message:
ERROR There is no debug configuration for undefined
in the browser console and the debugger doesn't execute, but the configuration was generated in launch.json file:

   {
      "preLaunchTask": "quarkus:dev",
      "type": "java",
      "request": "attach",
      "hostName": "localhost",
      "name": "Debug Quarkus application",
      "port": 5005
   }

If try to run this configuration from Debug view, I see a message that Task 'quarkus:dev' terminated with exit code 127.

Probably this problem can be related to add support integratedTerminal for debugging eclipse-theia/theia#6103

Che remote plugin with vscode-quarkus extension

apiVersion: v2
publisher: redhat
name: quarkus
version: 1.1.1
type: VS Code extension
displayName: Quarkus Tools
title: Quarkus Tools by Red Hat
description: This plug-in provides support for Quarkus development via a Quarkus language server and a Quarkus jdt.ls extension.
icon: https://www.eclipse.org/che/images/logo-eclipseche.svg
repository: https://github.com/redhat-developer/vscode-quarkus
category: Language
firstPublicationDate: "2019-11-05"
spec:
  containers:
    - image: "docker.io/eclipse/che-remote-plugin-runner-java11:next"
      name: vscode-quarkus
      memoryLimit: "1500Mi"
      volumes:
      - mountPath: "/home/theia/.m2"
        name: m2
  extensions:
    - https://github.com/microsoft/vscode-java-debug/releases/download/0.20.0/vscode-java-debug-0.20.0.vsix
    - https://download.jboss.org/jbosstools/static/jdt.ls/stable/java-0.50.0-1825.vsix
    - https://download.jboss.org/jbosstools/vscode/snapshots/vscode-quarkus/vscode-quarkus-1.1.1-158.vsix

[tsmaeder]

@svor does it work if you ad the "console": "internal console" attribute to the launch config?

[svor]

@tsmaeder It is not possible to add the console attribute to the launch configuration which has value of "request" attribute as "attach", we could do that if the configuration has "request": "launch" attribute. So, probably I was mistaken when wrote that this is related to eclipse-theia/theia#6103

[tsmaeder]

Could very well be a duplicate of #15117

[tsmaeder]

This might be a place to look. redhat-developer/vscode-quarkus@04e7652#diff-0dbbad2f7cd76714b5a5e9cba1b5495fR113 Suspicion: we are missing an environment variable.

[benoitf]

setting milestone 7.5.0 as it's your sprint @tsmaeder

[tolusha]

TODO:

• Support background tasks eclipse-theia/theia#6534
• Support background tasks eclipse-theia/theia#6534

[amisevsk]

Shouldn't "preLaunchTask": "quarkus:dev", be "preLaunchTask": "mvn quarkus:dev",?

[svor]

@amisevsk quarkus:dev is task's name, the command is mvn quarkus:dev. Into debug configuration we have to put the name.

[amisevsk]

@svor Ah apologies, I misunderstood.

[tsmaeder]

The problem is that the pre-Launch task needs to be run in the dev container instead of the Theia sidecar

[tsmaeder]

We propose to add configuration to the devfile that allows to execute tasks that are contributed by a VS Code extension in a different container, like:

task: "quarkus:dev"-> execute in: "quarkus-dev-machine".
Where "quarkus-dev-machine" is the alias of a component.

[tsmaeder]

This needs to be addressed by the platform team.

[sunix]

By default, I would run the task in the container where the extension is running.

[skabashnyuk]

@sunix are you working on this task at this moment?

[tsmaeder]

@skabashnyuk because we would need to be able to configure the container to execute in in the devfile.

[svor]

@tsmaeder
I think the current task has two parts:
The first one (probably it is for platform team) is to make it possible to configure devfile to mark VS Code tasks (not commands) which should be executed in special container. As for me the structure should be like

tasks:
-
  label:
  component:

The second part is to adapt task runner process on che-theia side. In that part we should analyze workspace configuration and execute tasks in related container

[sunix]

To me, it sounds too complicated for the user to understand what this is about.
What I suggest:

• By default either:
  1. component/container should be the one that is hosting the extension. (my prefered option)
  2. or we ask the user to choose the container where to run it.
• if the devfile contains a command/task with the same name/label, it would use this one.

[skabashnyuk]

I like the @sunix proposal. Removing the platform team label since it does not look like we need an extension to devfile format at this moment.

CC @l0rd

[tsmaeder]

@sunix the component that registers the task is exactly not the one that should be executing it, in this concrete case.
I don't like that we need to push a decision to the user that we (or at least the author of a devfile) could make for her. Not sure the devfile is the correct location for this, but it would be great if we could preprocess contributions (turn them off, redirect execution to a particular container).

[sunix]

@sunix the component that registers the task is exactly not the one that should be executing it, in this concrete case.

By default yes it should: it is the only container where we are 100% sure that all the system dependencies are met. Quarkus extension would run on Java11 container and it is the only container where we are sure that it would have java and maven. Same if you take a openshift-connector and this extension would like to run oc commands, the container where the plugin is running is the only one where you are sure that you have oc installed.
It would work on any devfile. That's why it should be the default option.

I don't like that we need to push a decision to the user that we (or at least the author of a devfile) could make for her. Not sure the devfile is the correct location for this, but it would be great if we could preprocess contributions (turn them off, redirect execution to a particular container).

OK let's just don't give the user the ability to choose. Having that say, here is my new proposal:

• component/container where to run the task should be the one that is hosting the extension.
• if the devfile contains a command/task with the same name/label, it would use this one.

In concrete case, it's hard to tell if a devfile would have a dedicated runtime container to debug the app. If a devfile author is starting from nothing, he would just add his Quarkus project repository and the Che Quarkus plugin. Just with this devfile he should be able to start the Quarkus app in devmode and debug it. This is what would be possible if we execute the task in the container that is hosting the extension.
Then if he has a dedicated dev container, and want the Quarkus devmode task to be executed in this dedicated dev container, it is fine to tell him to adapt a devfile like https://github.com/redhat-developer-demos/quarkus-reactjs-postit-app/blob/a2d94f0b64f6fac6346af3a6ba6e7200feff2a6b/devfile.yaml#L111
And rename start DEVMODE quarkus-backend to quarkus:dev. Something we can document in the quarkus Che plugin documentation or welcome pane.

[tsmaeder]

2 Steps:

1. Establish connection between tasks & containers that contribute them. Run tasks in that container.
2. Introduce label matching for commands/tasks
3. Maybe introduce explicit syntax for redirecting tasks to containers.

[sunix]

currently on 1.

• vscode quarkus should probably use https://code.visualstudio.com/api/extension-guides/task-provider
• see if we can detect the container hosting the extension providing a task-provider in Che

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.

[karstengresch]

Any news on this? The problem still persists, it seems.

[l0rd]

@sunix this issue is assigned to you. Are you working on it?

[sunix]

@l0rd no I am not working on it. I had started to have a look when language team was merged with the plugins team and I moved to a community role.

So this is not working because it is using the task provided by the vscode extension. At the moment, to debug quarkus app, we would suggest users to use a task defined in the devfile like this: https://github.com/eclipse-che/che-devfile-registry/blob/main/devfiles/quarkus/devfile.yaml#L101-L117

  -
    name: Attach remote debugger
    actions:
    - type: vscode-launch
      referenceContent: |
        {
          "version": "0.2.0",
          "configurations": [
            {
              "type": "java",
              "request": "attach",
              "name": "Attach to Remote Quarkus App",
              "hostName": "localhost",
              "port": 5005
            }
          ]
        }

@ericwill How would we prioritize this ?

[ericwill]

There is a workaround present for this right? I'd say it should be taken as part of sprint 205 (in ~3 weeks from now).

[karstengresch]

At the moment, to debug quarkus app, we would suggest users to use a task defined in the devfile like this: https://github.com/eclipse-che/che-devfile-registry/blob/main/devfiles/quarkus/devfile.yaml#L101-L117

  -
    name: Attach remote debugger
    actions:
    - type: vscode-launch
      referenceContent: |
        {
          "version": "0.2.0",
          "configurations": [
            {
              "type": "java",
              "request": "attach",
              "name": "Attach to Remote Quarkus App",
              "hostName": "localhost",
              "port": 5005
            }
          ]
        }

Thanks for that, @sunix. Actually this is the config that comes with the default Quarkus template on CRW. I actually asked for the current status because I cannot confirm this workaround is working:

Created a breakpoint, started Quarkus in dev + debug mode, called a service (getting-started quarkus example with one additional sysout line) - IDE doesn't interrupt... :-|

[svor]

Thanks for that, @sunix. Actually this is the config that comes with the default Quarkus template on CRW. I actually asked for the current status because I cannot confirm this workaround is working:
Created a breakpoint, started Quarkus in dev + debug mode, called a service (getting-started quarkus example with one additional sysout line) - IDE doesn't interrupt... :-|

@karstengresch which CRW version do you have? Could you please share a link to the devfile

[sunix]

@karstengresch if you don't have the exact same issue described in this issue, it may be another problem and it may have already been fixed.