JAVA_OPTS are not picked up by spawned JVM

[nolondil]

We have our own certificate for the JVM and setting the path to the trust store and password in the JAVA_OPTS make it visible within the SBT Shell.

But running the reStart the link to those is lost and the JVM fail to validate the certificates, we can work around that by adding the path in the javaOptions of the reStart but it would be better to leverage the JAVA_OPTS directly (or pass the same JVM arguments from the sbt shell to the reStart with extra define in reStart / javaOptions)

[jrudolph]

Afaik JAVA_OPTS is not provided by the JVM but is a feature of some startup scripts (like sbt's itself). The proper way to define these in sbt would indeed be to set `javaOptions` explicitly. Automatically inheriting runtime options from the build tool to the application seems like a questionable feature to me (and a somewhat accidental side-effect is that works when you use `run` to run Java apps in-process inside of sbt). Jérôme Amiguet ***@***.***> schrieb am Do., 29. Aug. 2024, 10:42:

…

We have our own certificate for the JVM and setting the path to the trust store and password in the JAVA_OPTS make it visible within the SBT Shell. But running the reStart the link to those is lost and the JVM fail to validate the certificates, we can work around that by adding the path in the javaOptions of the reStart but it would be better to leverage the JAVA_OPTS directly (or pass the same JVM arguments from the sbt shell to the reStart with extra define in reStart / javaOptions) — Reply to this email directly, view it on GitHub <#117>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAACNDBOJQLGIUMHD2TPYCLZT3NGXAVCNFSM6AAAAABNJ5MRDOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQ4TGOBRGQ4DGMY> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[nolondil]

As far as I understand, Zulu is also adding the JAVA_OPTS when running java outside an sbt shell 🤷🏻‍♂️

FWIW, as we need to link specific certificates to the JVM, this is how we could still make those trust store visible in our shared code (without being specific):

val trustStorePath = sys.env.getOrElse("TRUSTSTOREPATH", "NO_PATH")
val trustStorePwd = sys.env.getOrElse("TRUSTSTOREPWD", "NO_PWD")

    reStart / javaOptions ++= Seq(
      s"-Djavax.net.ssl.trustStore=$trustStorePath",
      S"-Djavax.net.ssl.trustStorePassword=$trustStorePwd
    )