Environment Variables in JAVA_TOOL_OPTIONS

[sirish-bajpai]

I am building a Java/WAR/Tomcat image using:

paketobuildpacks/builder-jammy-buildpackless-base:0.0.126
gcr.io/paketo-buildpacks/ca-certificates:3.6.8
gcr.io/paketo-buildpacks/adoptium:11.2.5
gcr.io/paketo-buildpacks/java:12.0.0

The image is deployed on a kubernetes cluster, which injects all necessary environmental variables in the pod at deployment time.
I am trying to specify a couple of system properties, whose values need to be picked up from environment variables at startup, like so:

JAVA_TOOL_OPTIONS=-Dexample.sys.prop=${EXAMPLE_SYS_PROP}

Kunernets is injecting both JAVA_TOOL_OPTIONS and EXAMPLE_SYS_PROP correctly from configmap/secret as designed.
But the embedded ${EXAMPLE_SYS_PROP} in JAVA_TOOL_OPTIONS is never resolved to its value and passed as is. As a result my app reads the string '${EXAMPLE_SYS_PROP}' instead of the intended value of the env variable.

Is there any way to accomplish this use case ?
I am guessing this should be a fairly common requirement. Is there a simple solution I am missing?
Thanks in advance for any pointers/help.

[dmikusa]

This is the expected behavior because your application is not started using a shell (so env variables are not shell expanded). Java applications are started directly, not through a shell. This is a requirement for running on smaller base images that don't include a shell.

Kunernets is injecting both JAVA_TOOL_OPTIONS and EXAMPLE_SYS_PROP correctly from configmap/secret as designed.

If K8s is injecting both, can you just have it combine the values? It would know the contents of both values at the time it injects them. Then inject the combined values in JAVA_TOOL_OPTIONS instead.

Otherwise, you could include a .profile script and use the profile buildpack to execute the script prior to your application starting up. This would allow you to dynamically adjust env variables at runtime before your app starts.

[sirish-bajpai]

Thanks very much for your input.

If K8s is injecting both, can you just have it combine the values? It would know the contents of both values at the time it injects them. Then inject the combined values in JAVA_TOOL_OPTIONS instead.

Interesting! Although both values are coming from different sources. JAVA_TOOL_OPTIONS from configmap and sysprop from a secret. Will need to do some research how a kube deployment object can combine them.

Otherwise, you could include a .profile script and use the profile buildpack to execute the script prior to your application starting up. This would allow you to dynamically adjust env variables at runtime before your app starts.

This might be better way it seems. Will look into it. Thanks for pointing in this direction.
I still feel that the buildpack which handles env vars (I think [paketo-buildpacks/environment-variables] (https://github.com/paketo-buildpacks/environment-variables)) can resolve env recursively. Save a lot of effort for simple use cases.

Thanks Again!