Java plugins not working?

Hi,
since today we somehow have trouble to debug java applications correctly in Gitpod’s online IDE (local VSCode works fine)

  1. The code lense for run/debug main methods is not available anymore and right clicking on tha mein method and clicking “Run Java” results in a No delegateCommandHandler for vscode.java.resolveMainMethod Source: Debugger for Java(Extension) error message
  2. Trying to attach a debugger to a running Java process results in No delegateCommandHandler for vscode.java.startDebugSession Source: Debugger for Java(Extension) error message

I checked the debug extension and it had no update since one month so I don’t think the problem stems from there.
Locally everything works fine.

Another thing that is strange: as soon as I start a JVM in debug mode in Gitpod’s online IDE I get the repeated ‘Debugger failed to attach: handshake failed - connection prematurally closed’ message whereas on a local VScode instance nothing is printed

All these things are reproducable with the Spring petclinic example on your homepage.
Any ideas why this is happening?

Kind regards,
Thomas

-.- Ignore what I said. The Debugger extension seems to had a new release yesterday (0.36.0) which is marked as beta. In the VSCode Marketplace somehow it shows 0.36.0 to have been released one month ago, therefore I thought nothing had changed. Reversing the debugger extension to version 0.35.0 fixes the problem.

I will just pin the extension version to 0.35.0 to make sure this does not happen again -.-
Sorry for bothering you

2 Likes

@Sandared This is indeed a bug, thanks for reporting. Will fix ASAP. Please continue using version 0.35.0 in the meantime.

3 Likes

That’s awesome :slight_smile: Thank you!

If you can upvote github release is missing for 0.36.0 · Issue #1083 · microsoft/vscode-java-debug · GitHub it would help.

Hi @akosyakov maybe I’m blind, but I can’t find a way to upvote the issue? Or is that done by emojis (I did see that in other GitHub projects)

Ran into this recently. I just started evaluating Gitpod. The first time I tried the Java debugger, it didn’t work, producing this error. Then the second time, it worked fine. Then, each time after that, it didn’t work, producing this same error again. I created a GitHub issue just a minute ago and came here to see if I could get eyes on it. Sounds like it may already be being looked into though.

It does sound weird though that this is just a “the new version doesn’t work well” problem because it didn’t work the first time for me. I’m assuming it wouldn’t downgrade the extension the second time I opened the workspace, and then upgrade it again each time I opened the workspace after that.

I notice that there was a file present in the repo that I cloned called .gitpod.yml. The Spring folks appear to have Gitpod support already in at least this sample repo.

That file has a vscode.extensions which is a list of strings, one of which looks like the debugger extension:

But the version of the extension installed is v0.36.0. Does that mean Gitpod defaults to using the latest version of an extension, even if it’s a preview version? If so, perhaps that’s a bit too ambitious, and it should instead use the latest stable version of extensions.

Update:

The Java debugger extension devs considered my issue to be a duplicate, so I closed it. But the issue they say it duplicated was also closed (Unable run or debug the spring boot application in VSCodium · Issue #1080 · microsoft/vscode-java-debug · GitHub). Reading through that issue, I don’t understand what the problem is (I don’t know what VSCodium is, I’m just trying out Gitpod lol) or what is to be done next and by whom.

I explained here: No delegateCommandHandler for vscode.java.startDebugSession when starting Debugger in Gitpod · Issue #1088 · microsoft/vscode-java-debug · GitHub

We published 0.37.0 version, since GH releases were fixed, now it should work again, please try. Sorry for the inconvenience.

No problem. It was a good way to learn how Gitpod works at a deeper level. I ended up being able to work around this problem by manually downgrading the extension to 0.35.0. I haven’t yet learned how to check this version into the repo so that each time I start my workspace, it uses that version.

Just to clarify: the issue was resolved, you can install latest extension from OpenVSX and it should work.

Yep, I tried that today too. Brand new workspace for Java works out of the box with version 0.37.0 of the debugger extension.

main problem is gitpod downloads extensions everytime a workspace has started

atm angular language services is borked on open vsx causing me enough issues, Having to download the vsix, put it in my git repo and install manually

why can’t gitpod just save the extensions to storage like it used to?

its not the first time this has happened, last time it was omnisharp from open vsx,
we can’t rely on extensions always being available on open vsx, what if open vsx was down for a few days?

why can’t gitpod just save the extensions to storage like it used to?

Each workspace is a new machine. VS Code is designed to install anything latest by default. It will be hard to change design decisions in upstream and will be also different from how VS Code work even on desktop. Whenever you restart it will auto update there too.

its not the first time this has happened, last time it was omnisharp from open vsx,
we can’t rely on extensions always being available on open vsx, what if open vsx was down for a few days?

We work very closely now with OpenVSX to ensure availability. We also run a caching proxy which can operate without OpenVSX for 3 days. Yesterday OpenVSX was not reachable 3 times for 30 mins Gitpod did not stop working. The issue was already reported to Eclipse and they look for the cause.

The real issue is that auto publishing to OpenVSX by the service account does not smoke test extensions before pushing them. We will try to address it: smoke test extension with latest OpenVSCode server before publishing · Issue #507 · open-vsx/publish-extensions · GitHub

hi

thanks for the reply

  1. cache will be no use to self hosted users
  2. if an extension is messed up as is the case currently for angular language services

this means a previously working workspace can no longer function properly because the extension has gone

cache will be no use to self hosted users

Could you check this issue: Allow usage of private osix registry via the extension ui + gitpod file · Issue #5031 · gitpod-io/gitpod · GitHub? The proxy is a part of installation, so it should be possible to have own proxy for self-hosted. Please comment your user case there.

this means a previously working workspace can no longer function properly because the extension has gone

For restarted workspaces we should have full workspace backup eventually (cc @csweichel ), which will preserve extensions. For new workspace it cannot work anyway. We should ensure that OpenVSX is available and published extensions there are good.