Play Framework

fix(launcher): bundle reads conf JVM keys; JMX needs a login and TLS (PF-183)

The Gradle launch paths lift jvm.memory, javaagent.path, agentlib and
jmx.port + jmx.hostname out of application.conf (confJvmArgs). The
bundle launcher read none of them, so an app whose conf asks for
--add-modules=jdk.incubator.vector ran with it under play start and
without it in its Docker image.

bundle-play.sh now derives the same flags (conf_jvm_args, a bash port of
confJvmArgs), resolved for the play id with the %<id>. entry first, and
places them after the JUL default and before the command-line flags, so
the command line still wins. jvm.memory is split without globbing.
BundleLauncherTest runs the launcher and confJvmArgs over the same conf
files and compares the output, so the two cannot drift apart unnoticed.

Behaviour change, in both launch paths: jmx.port + jmx.hostname used to
start an agent with authentication and TLS hard-coded off, as the 1.12
launcher did, and jvm.memory could not turn them on because the agent's
own flags follow it and the JVM keeps the last -D. The agent now demands
a login and TLS unless the conf says the literal word false in
jmx.authenticate or jmx.ssl. The value is normalised rather than passed
through, because the JDK reads anything but "true" as off and a typo
would have opened the agent. The files the protections need are named by
jmx.password.file, jmx.access.file and jmx.ssl.config.file, as files
because a credential given as a -D is readable in ps; the RMI registry
follows jmx.ssl. An app that sets the two keys and nothing else no
longer starts until it adds a password file or the two false lines.

Also fixed: the plugin's conf reader matched whitespace with \s, which
crosses line breaks, so a blank `jvm.memory=` took the next line of
application.conf as its value and the JVM refused it. A blank value is
now unset.

Tests: ConfJvmArgsTest pins the Gradle side (blank values, the default,
only-false-turns-it-off); BundleLauncherTest the launcher. Verified on a
real bundle with no JVM option on the command line: the vector module
and heap size come from jvm.memory; with only the two JMX keys the JVM
refuses to start; with the files the port speaks TLS 1.3 and accepts the
right login only; with both switches false it is open; with no keys
there is no port. Same launcher output on bash 3.2 and bash 5.2.

Bundles built before this ignored these keys, so a conf's existing JVM
settings take effect in production on upgrade; the manual says so.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>