Live Hovers does not show up when running Spring Boot in WSL

When running a Spring Boot project ($ mvn spring-boot:run) in Linux subsystem in windows 10 (WSL bash shell, Ubuntu 16.04 distro), Boot Hints does not show up.

There are no warnings nor errors that I could see in the output box for the Spring Boot Tool VSCode extension (Pivotal.vscode-spring-boot).

Boot Hints show up normally if I run a Spring Boot project in git bash for windows 10, or in cmd on the same computer.

[khe817]

I tried what @kdvolder guided and it worked.

Thank you guys very much for looking into this!

[kdvolder]

I’ve got boot hints working in windows WSL but it requires some manual steps. I don’t know how/if we would be able to make this work automatically. I think the problem is really that from Java’s point of view the linux subsystem follows its own/different logic of where the JVM puts files that allow for jps mechanism to detect JVM processes and to dynamically enable JMX for them.

For example, to run Java stuff from WSL I had to install Java into the Linux subsystem. So this is a totally separate JVM install from the one used to launch the boot-java-language server from vscode running in Windows. The WSL JVM is basically working like its running on Linux and so it will be using the /tmp folder on the Linux filesystem, whereas the JVM used by the language server puts tmp folders in a totally different place. Since process discovery and the whole ‘enable JMX’ mechanics are somehow dependent on files written by the JVM into /tmp this is probably why it doesn’t work. It is unclear if its possible to make it work.

Luckliy, as a user, you can work around this with some manual steps to configure things:

Step 1: Enable the JMX support on a specific port when launching the app. For example I run my app from the WSL with a command like this:

java -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=41383 -Dcom.sun.management.jmxremote.rmi.port=41383 -Djava.rmi.server.hostname=localhost -Dcom.sun.management.jmxremote.local.only=false -jar target/hello*.jar

This will make have JMX enabled and accessible via this JMX_URL: service:jmx:rmi://localhost:41383/jndi/rmi://localhost:41383/jmxrmi.

Step 2) Now to make the live hovers work in vscode we can add this to the workspace settings:

{
    "boot-java.remote-apps": [
        {
            "jmxurl" : "service:jmx:rmi://localhost:41383/jndi/rmi://localhost:41383/jmxrmi",
            "host" : "localhost:8080"
        }
    ]
}

Now, although the vscode extension and (boot language server) isn’t able to discover the running process on its own, it is able to connect to it because we have told it, via the workspace settings where to look for it.

Note: The configuration mechanism was meant mainly to allow for connecting to apps running on cloudfoundry who’s JMX connections are being tunnelled via an ssh tunnel from localhost. The ‘host’ entry isn’t really needed for most of the livehover to work, so even if you put some garbage in there you may not notice anything broken. The host is only used to show a correct hostname in the live urls computed for requestmappings. In the CF scenario there’s would be no need to specify the port, so there isn’t a proper way to set it. On CF the requestmappings are accessed over the normal http port on the CF host.

But when app is run locally in WSL it will probably run answering http connections on some local port (the default would be port 8080 unless user configures it explicitly). It is a bit of a ‘hack’ here that I appended the port 8080 at end of localhost. This makes live requestmapping urls work properly.