appengine-java-vm-runtime
appengine-java-vm-runtime copied to clipboard
GoogleCloudPlatform
Configuring things.: What's the best way to pass parameters?
So, we had many of our parameters as EnvVars, but to make things work from mvn jetty:run we changed them to System.getProperties. Lots of mvn jetty:run support.
So, I thought, I can just pass -Djetty.SystemPropertiesFile=WEB-INF/my.properties in app.yaml JAVA_OPTS (also do the same for -Djava.util.logging.config.file=WEB-INF/logging.properties).
It turns out that at some point, things changed, and instead of coping the unexploded war, we appear to just copy root.war to webapp/ - so those files are in the war, and not easily accessible.
I was trying to make it so that we only define things once. I can probably just define each property as -DmyProperty.thing1=foo -DmyProperty.thing2=bar, but that will imply a very long JAVA_OPTS, and then redefine them in the plugin.
Is there a better way? And what about logging.properties, there really should be something easy for that?
Maybe you should explore the JDNI standard: http://stackoverflow.com/questions/3804396/how-to-portably-read-configuration-data-from-a-servlet/3804788#3804788 We did not support it in GAE standard, but it something we should look at more now.
On Wed, Mar 2, 2016 at 11:19 PM, Les Vogel [email protected] wrote:
So, we had many of our parameters as EnvVars, but to make things work from mvn jetty:run we changed them to System.getProperties. Lots of mvn jetty:run support.
So, I thought, I can just pass -Djetty.SystemPropertiesFile=WEB-INF/my.properties in app.yaml JAVA_OPTS (also do the same for -Djava.util.logging.config.file=WEB-INF/logging.properties).
It turns out that at some point, things changed, and instead of coping the unexploded war, we appear to just copy root.war to webapp/ - so those files are in the war, and not easily accessible.
I was trying to make it so that we only define things once. I can probably just define each property as -DmyProperty.thing1=foo -DmyProperty.thing2=bar, but that will imply a very long JAVA_OPTS, and then redefine them in the plugin.
Is there a better way? And what about logging.properties, there really should be something easy for that?
— Reply to this email directly or view it on GitHub https://github.com/GoogleCloudPlatform/appengine-java-vm-runtime/issues/197 .
Hmmm I'm not a huge fan of JNDI... it is really rather over complex for a map of map of map... of strings.
In jetty generally we have gone away from both Env vars and System properties as a configuration mechanism. The main reason for this is that they both apply to the entire JVM and thus can often be too course grained, as we can have multiple servers per JVM and multiple contexts per server etc.
Thus our preferred configuration style is to use parameterised XML to do dependency injection as we assemble the POJOs that make up jetty. Typically we can now configure jetty without making any XML changes, but by simply adding pre-prepared XMLs to the command line (typically with a module) and providing parameters via: command line; start.d/ini files; or a foobar.properties file on the command line.
For the compat image we already have a gae.xml file that can be extended and have more properties defined, which can then be injected as attributes on the server.
We also have a root.xml file, that can inject into the context, although I will have to check if all the start properties are available to it. It can inject attributes and/or init params into the context.
Note also for logging.properties, it should be possible to just put that in $JETTY_BASE/resources and have it found the normal way. This is where we put the jetty-logging.properties file that directs the jetty log to java.util.log, so it would make more sense to have the java.util.log there as a resource of the JVM rather than burried as a resource of the webapp (or perhaps we can support either location?)
Note: the logging.properties for java.util.logging is not auto-discovered, auto-loaded by java itself. You have to write code to find and load that file (unlike literally every other java logging framework on the planet)
For compat images logging.properties is configured in appengine-web.xml by setting the java.util.logging system property.
Configuring logging should be handled differently than configuring other aspects of the application.
Having logging initialized early (as early in the JVM as possible) is the best decision with logging.
Let's take the VmRuntimeFileLogHandler as an example, if we configure Jetty and its logging to initialize Jetty and java.util.logging (at the same time) we can have VmRuntimeFileLogHandler present even when other components are attempting to configure themselves at a later point.
This sort of early initialization is already baked into Jetty with jetty-logging.properties and the auto loading of java.util.logging configuration if you use the JavaUtilLog implementation in jetty.
Building on @joakime comments...
Currently the VmRuntimeFileLogHandler is configured in code, in the init method. A moderate amount of code is run before then, so it is essentially running without a well configured log. If something goes wrong before that, it will not be logged.
It would make more sense to configure this core logging in a logging.properties file that is installed in the image next to the jetty-logging.properties file, so all the base logging config would be in one spot and easy to see/understand/modify.
However, I do understand that parsing the appengine-web.xml allows additional system properties to be set that alter the behaviour of the log (log directory and logfile pattern), hence the current need to reload logging configuration. I think it would be better to deprecate those environment variables and only use the logging.properties file for the core configuration (users can replace in a Dockerfile if they want).
Then any logging.properties file specified in appengine-web.xml could potentially be considered as additional logging configuration, that is additively applied (ie can't change the VmRuntimeLogFileHandler).
