Add inlined conf file support to launch.script

[philwebb]

ba2ea30#commitcomment-10652388

[aantono]

Also, a neat trick that we are using, is to embed the jvm.options file into the archive itself. We place it into src/resources/jvm.options location as a text file and later extract the content in the bash script like this:

jvm_opts=`unzip -p $jarfile jvm.options 2>/dev/null`
echo "Starting application using the following jvm.options: $jvm_opts"

That gets also added to the startup command line. This way applications can have an ability to ship/store the static pre-defined JVM system properties in their code/bundle and store them in the version control. This is very helpful for configuring XML parsers, JodaTime TZ handlers and other things of that nature, that are driven via -D arguments.

[philwebb]

The build plugins now support a embeddedLaunchScriptProperties which can be used as a general purpose mechanism to replace parts of the init script. I was thinking we could just add something like we already have for mode. The mode flag also allows overrides when running the app:

$ mode="service" ./myapp.jar

Something similar for JAVA_OPTS would allow local overrides:

$ JAVA_OPTS="-X..." ./myapp.jar

[aantono]

That sounds like a good way to handle...
The only reason we embed jvm.options in the jar, is for the never-changing static configuration. We use a specific instance of javax.xml.parsers.DocumentBuilderFactory, javax.xml.parsers.SAXParserFactory, org.joda.time.DateTimeZone.Provider and some other things. Those are not environment specific, just different from the standard configuration of those libraries or settings.

For us the rule of thumb is: if it varies from env to env, like memory footprint, set it via JAVA_OPTS variable, if it is static, put those props into jvm.options in the build.

[philwebb]

Perhaps we need a couple of variables in the script? One for static options and one for overrides. BTW you can also use embeddedLaunchScript in your build file to embed a completely custom script.

[aantono]

Yeah, that probably would be a better option. This way the static startup system properties can be defined in one place in the build.gradle or pom.xml build file and then used for all the places where the application is started, like bootRun task, and for generating the self-executable and being transformed into the embeddedLaunchScriptProperties which will be placed into the launch script {{static_jvm_ops}} template variable, as opposed to JAVA_OPTS externally set ENV variable.

[davidrabinowitz]

@philwebb Please notice that in many cases setting the environment variables is not done by the developers but by the deployer/devops/etc by manipulating the environment variables and the command line arguments.

It would be helpful to have two environment variables like tomcat has - JAVA_OPTS for start and stop, and another (SPRING_BOOT_OPTS?) only for start - similar to CATALINA_OPTS

[joshiste]

Isn't this issue obsolete after f0bb60b?

[philwebb]

Thanks to @joshiste this should be sorted now.

[JustinKSU]

@philwebb pull request #3243 did allow you to create a conf file the same name as the .jar file to pass JVM parameters. However, this has a few downsides. Every time you build a new version you need to create a new .conf file with the same version in the filename. Also there is no way to bundle the JVM parameters with your Maven artifact.

I think adding "javaOpts" to embeddedLaunchScriptProperties would be powerful. It would be important that this change only append JAVA_OPTS not replace those defined in the environment or by the .conf file.

A single executable .jar file with JVM options built-in allows for simpler deployments. Would you be willing to re-open this issue so I could do a pull request against it?