vm.install.path does not seem to be recognized

[pF-luis]

Server Connector v0.26.12 Runtime Server Protocol UI v0.24.8 VS Code 1.79.2 (Linux)

Running within amazon corretto java 17 dev container. Everything seems to be working fine. I need Java 17 to use the java language support extension but then my current jboss cannot run on java 17 so I installed java 8 in parallel.

Now I wanted to point the RSP to use the java 8 installation on my jboss server, so I've set the vm.install.path as suggested on other issues and on the error hint within vscode itself.

My rsp configuration looks like this:

{
  "args.override.boolean": "false",
  "args.program.override.string": "-mp \"/workspaces/runtimes/pboss/modules\" org.jboss.as.standalone -b localhost --server-config=standalone.xml",
  "args.vm.override.string": "\"-Dprogram.name=rsp:JBoss EAP 7.4\" -server -Xms1303m -Xmx1303m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Dorg.jboss.resolver.warning=true -Djava.net.preferIPv4Stack=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true \"-Dorg.jboss.boot.log.file=/workspaces/runtimes/pboss/standalone/log/boot.log\" \"-Dlogging.configuration=file:/workspaces/runtimes/pboss/standalone/configuration/logging.properties\" \"-Djboss.home.dir=/workspaces/runtimes/pboss\" -Dorg.jboss.logmanager.nocolor=true  --add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED --add-modules=java.se -Djboss.http.port=\"8080\"",
  "id": "JBoss EAP 7.4",
  "id-set": "true",
  "jboss.server.host": "localhost",
  "jboss.server.port": "8080",
  "org.jboss.tools.rsp.server.typeId": "org.jboss.ide.eclipse.as.eap.74",
  "server.autopublish.enabled": "true",
  "server.autopublish.inactivity.limit": "1000",
  "server.home.dir": "/workspaces/runtimes/pboss",
  "server.timeout.shutdown": "120000",
  "server.timeout.startup": "120000",
  "vm.install.path": "/usr/lib/jvm/java-8-amazon-corretto/",
  "wildfly.publish.restart.pattern": "\\.class$|\\.jar$",
  "wildfly.server.config.file": "standalone.xml",
  "wildfly.server.deploy.directory": "",
  "deployables": {
  [...]
  }
}

The error message states the following

Unable to start the server:  Extension backend error - server can not be started: server jboss eap 7.4 is not compatible with discovered java version 17.0.6. this server requires a java version between 1.8 and 15 inclusive. you may change a server's launch vm by setting the 'vm.install.path' property in a server's rsp configuration file.

Not sure where I am wrong, seems to be I've set everything up properly.

Any hints would be appreciated, Thanks!

[robstryker]

So, this is strange.

First, I can't replicate it. Second, you can see here: https://github.com/redhat-developer/rsp-server/blob/db1a3299580983f61ce20016c0e6a0efef1c37d8/runtimes/bundles/org.jboss.tools.rsp.server.wildfly/src/main/java/org/jboss/tools/rsp/server/wildfly/servertype/JBossVMRegistryDiscovery.java#L24

the first thing we do is try to get this attribute from the definition. If it has a value, we return it (whether valid or not). If it doesn't, we return null.

Then, here: https://github.com/redhat-developer/rsp-server/blob/db1a3299580983f61ce20016c0e6a0efef1c37d8/runtimes/bundles/org.jboss.tools.rsp.server.wildfly/src/main/java/org/jboss/tools/rsp/server/wildfly/servertype/JBossVMRegistryDiscovery.java#L40

if the path is null, we just return the default (ie the java 17). Otherwise, we try to add this path to the list of VMs and discover its version and other stuff.

Eventually we trace into where we actually add it to the model:

https://github.com/redhat-developer/rsp-server/blob/db1a3299580983f61ce20016c0e6a0efef1c37d8/runtimes/bundles/org.jboss.tools.rsp.server.wildfly/src/main/java/org/jboss/tools/rsp/server/wildfly/servertype/JBossVMRegistryDiscovery.java#L88

If the passed-in path is null (which it shouldn't be at this point) we'll use the default java installation (ie the java 17). Otherwise, we'll check its valid (is a folder, has a java binary file under it, etc etc) and then get its version by running java -version on it (which is many layers deeper than this code). The end result of this call is, if we know the jvm is added to the model, we return true, and if it couldn't be added to the model we return false. In the event we return false to ensuring this vm is added to the model, we return a null vm to the caller.

Long story short, if the path is invalid, we end up returning a null vm, not the java 17 vm. In this case, the error message would look like Server {0} can not find a valid virtual machine to use.

The only way we return the default vm is if the path is null, ie, the vm.install.path attribute is empty or not set.

Have you tried repeating this? Creating the server over again?

[pF-luis]

Here you can see my server config, the vm.install.path within the configuration and down below in the Terminal what's at that location The error message displays the error behavior I mentioned, that it wants to use the default jdk(version 17) instead of the jdk I provided via vm.install.path

In case I provide a wrong path like seen in the next screenshot, I can reproduce your described error pattern