Bug: 404 only on `sdk list java`

[momrak]

Bug report

The command sdk list java returns a 404 message (as can be seen in the attached screenshot) To reproduce

Run sdk list java while using sdkman through a proxy. See more info below System info

• Ubuntu 20.04.2 LTS
• zsh 5.8 (x86_64-ubuntu-linux-gnu
• SDKMAN 5.12.2

I have seen some others reporting the same i.e. https://github.com/sdkman/sdkman-cli/issues/772 and I originally added a comment to this issue, but after not receiving any reply I try opening a new issue instead. I add the text with relevant information here:

I use sdkman version: 5.12.2 on a company computer that is airgapped. We set up a proxy for the requests and have changed the environment variable SDKMAN_CANDIDATES_API= and the proxy then points to https://api.sdkman.io/2.

This works perfectly for all candidates except java. I am also able to install java if I look up the version from another "normal" connected computer, so it is only when running sdk list java I get this issue. I attached an image showing the difference when running sdk list maven and sdk list java

I am aware this is not the default supported way of using sdkman, but as it works for all all candidates (at least the ones I have tested), could there be some kind of bug? Do you have any recommendations or fixes I could try in order to get this command to work?

[marc0der]

Hi @momrak, let's see if we can help you resolve your issue.

For starters, could I please ask you to turn on debugging so we can see the exact call that curl is making through Nexus. Debugging can be enabled in the config. Simple run sdk config and edit the file.

[momrak]

Great, thanks @marc0der!

I enabled debugging now, but I cannot see that much more info when running sdk list java after doing this. Is there something else I should run? The HTML from the picture above remains the same, but in addition the following is printed first

No update at this time. Using existing cache: activemq,ant,asciidoctorj,ballerina,bpipe,btrace,concurnas,cuba,cxf,doctoolchain,flink,gaiden,gradle,gradleprofiler,grails,groovy,groovyserv,hadoop,http4k,infrastructor,java,jbake,jbang,jmc,jmeter,jreleaser,karaf,kotlin,kscript,layrry,leiningen,maven,micronaut,mulefd,mvnd,pomchecker,quarkus,sbt,scala,spark,springboot,sshoogr,test,tomcat,vertx,visualvm,webtau,znai
Not refreshing version cache now...

[momrak]

Did you have any further tips on how to proceed with the debugging, @marc0der ?

[marc0der]

Hi @momrak, you could try adding the -v flag to the bash script that invokes curl to get more information.

You might even consider driving this with a config variable and raising it as a PR. I could see this being useful for many others too. If you would be willing to consider this, I'd be happy to give some pointers on our cli-development channel on slack.

[momrak]

Thanks, I'll try that :)

Sure, I could give it a go

[helpermethod]

Hi @momrak!

Another way to enable curl debugging without changing the code is creating a .curlrc in your HOME directory and adding the -v flag to the body, something like

echo '-v' > ~/.curlrc 

[momrak]

Thanks for the tip, @helpermethod :)

@marc0der I added the output of running sdk list java with the verbose flag set on curl.

sdkman-debug.txt

[jauffrey]

Hello all,

I had an equivalent setup with Artifactory being used as a proxy, and the 404 as well (only on java too)

I noticed that some query params are set, so I enabled the "propagate query params" setting in the remote repo configuration and this fixed the issue.

Hope this helps

[momrak]

Thanks a lot, @jauffrey, this seems spot on :) There is an issue for this at sonatype, so I can't check if it works, but I will close the issue as it seems very likely.

@marc0der Not sure where it would fit in the docs and if this use case is too rare to be prioritized, but a small section about using sdkman in an air gapped env mentioning the environment variable SDKMAN_CANDIDATES_API= and a note to make sure the proxy is passing query params (and that a typical issue if its not will be 404 only for java) would be very useful for others in the same situation. :)

[marc0der]

@momrak yes for sure, this might be a good one for our FAQ.