Add `env JAVA_OPTS="$JAVA_OPTS"` to `exec "$@"` about openjdk-runtime

[meltsufin]

My mistake, sorry. You found the right openjdk image.

[meltsufin]

JAVA_OPTS is set in setup-env.bash, which is only invoked in the docker-entrypoint.bash if the run command starts with java or some other argument that is not an executable. What does your docker run command look like?

[tanin47]

For playframework, we run the bash script generated by sbt dist. The script eventually runs java with a lot of arguments, and, fortunately, the script uses the JAVA_OPTS env.

Here's the script template: https://github.com/sbt/sbt-native-packager/blob/master/src/main/resources/com/typesafe/sbt/packager/archetypes/scripts/bash-template#L297

Here's my docker run command:

CMD ["bin/myappname", "-Dlogger.file=conf/prod.xml", "-Dconfig.file=conf/prod.conf",  "-Dplay.crypto.secret=fakesecret", "-Dhttp.port=8080"]

I make my own docker-entrypoint.bash, and this is how it looks like:

#!/bin/bash
source /setup-env.bash \
  && exec env JAVA_OPTS="$JAVA_OPTS" "$@" 2>&1

[meltsufin]

If there is a way to start the app directly via the java executable, then you wouldn't need the custom CMD or the modified docker-entrypoint.bash. I would recommend looking into that option.

I'm not sure about modifying the actual runtime image the way you suggested to accommodate the Scala Playframework usecase. If the usecase was more generic, it would make more sense, but otherwise, extending the runtime image with a custom Dockerfile seems to be the most appropriate solution.

[meltsufin]

@tanin47 On a second thought, if we simply added export JAVA_OPTS line before the exec "$@" in docker-entrypoint.bash, would it solve your issue?

[tanin47]

If there is a way to start the app directly via the java executable, then you wouldn't need the custom CMD or the modified docker-entrypoint.bash. I would recommend looking into that option.
@tanin47 On a second thought, if we simply added export JAVA_OPTS line before the exec "$@" in docker-entrypoint.bash, would it solve your issue?

This would be helpful. I'll be able to get rid of my docker-entrypoint.bash completely. (One fewer file to maintain)

But I need to verify first whether export works as expected. There is some weird issue with export inside a bash script. I'll try and report back.

Thank you!

[gregw]

@tanin47 The docker-entrypoint has been written as it is so that follows the docker standard practises that easily allow other args and/or commands to be run in the image. I think that it is worth the effort to use the standard docker-entrypoint, potentially with modifications to fit your requirements.

[tanin47]

I confirm that adding export JAVA_OPTS="$JAVA_OPTS" in docker-entrypoint.bash works as well.

I also notice that setup-env.bash is only invoked if the first argument is neither executable or java . Our first argument is executable. This would need to be fixed.

Is there a downside for running setup-env.bash and setting $JAVA_OPTS every time? The users (who use this JDK image) would expect JAVA_OPTS to be set properly regardless how their commands look like.

[gregw]

I don't see any problem running setup-env.bash all of the time. I also think the script should export all the variables it sets. I'll prepare a PR...

[tanin47]

Thank you! This change is super helpful. Please let me know when the image is deployed. I'll test it promptly.

[tanin47]

Is this deployed yet?

[meltsufin]

Yes, and it will be made :latest soon.
For now, try using this image: gcr.io/google-appengine/jetty:9.4-2017-01-26_21_46

[tanin47]

Hmm.. I can't make the jetty image work. Do you have the openjdk version?

[tanin47]

I tested against gcr.io/google-appengine/openjdk:8-2017-01-26_21_19

It seems to work. I only need CMD command and can remove my own docker-entrypoint.bash. Thank you for making this change.