Play 2 Configuration Substitution not working - scala

I'm not very familiar with play but working on an application whereby the properties are loaded via a .properties file and a variable is passed through the command line.
E.g.
Note this is a play 2.2.3 app
play -Dhost=app123 -Dconfig.file=app.properties run
In the properties file:
app.host=${host}
When I check the configuration loaded at runtime using
Play.configuration
or
ConfigFactory.load
The substitution for app.host does not seem to work - the property is evaluated to ${host} as the literal String (instead of app123).
Is there something that needs to be set for substitution to work?
Thanks!

Reading between the lines of the documentation and code of both Play and the Typesafe Config library, using a file with a .properties extension may preclude substitution from environment variables and/or system properties.
I was able to get your use case to work using a file called application.conf on my Play 2.4 app.
It may well be as simple as renaming your file to app.conf - the format of a standard .properties file is actually valid HOCON, and HOCON is what you need to get property substitution.

Related

How do I specify a config file with play 2.4 and activator

I am building a Scala Play 2.4 application which uses the typesafe activator.
I would like to run my tests 2 times with a different configuration file for each run.
How can I specify alternative config files, or override the config settings?
I currently run tests with the command "./activator test"
You can create different configuration files for different environments/purposes. For example, I have three configuration files for local testing, alpha deployment, and production deployment as in this project https://github.com/luongbalinh/play-mongo
You can specify the configuration for running as follows:
activator run -Dconfig.resource=application.conf
where application.conf is the configuration you want to use.
You can create different configuration files for different environments. To specify the configuration to use it with activator run, use the following command:
activator "run -Dconfig.resource=application.conf"
where the application.conf is the desired configuration. Without the quotes it did not work for me. This is using the same configuration parameters as you use when going into production mode as described here:
https://www.playframework.com/documentation/2.5.x/ProductionConfiguration#Specifying-an-alternate-configuration-file
Important to know is also that config.resource tries to locate the configuration within the conf/ folder, so no need to specify that as well. For full paths not among the resources, use config.file. Further reading is also in the above link.
The quotes need to be used because you do not want to send the -D to activator, but to the run command. Using the quotes, the activator's JVM gets no -D argument but it interprets "run -Dconfig.file=application.conf" and sets the config.file property accordingly, also in the activator's JVM.
This was already discussed here: Activator : Play Framework 2.3.x : run vs. start
Since all the above are partially incorrect, here is my hard wrought knowledge from the last weekend.
Use include "application.conf" not include "application" (which Akka does)
Configs must be named .conf or Play will discard them silently
You probably want -Dconfig.file=<file>.conf so you're not classpath dependent
Make sure your provide the full file path (e.g. /opt/configs/prod.conf)
Example
Here is an example of this we run:
#prod.conf
include "application"
akka.remote.hostname = "prod.blah.com"
# Example of passing in S3 keys
s3.awsAccessKeyId="YOUR_KEY"
s3.awsSecretAccessKey="YOUR_SECRET_KEY"
And just pass it in like so:
activator -Dconfig.file=/var/lib/jenkins/jenkins.conf test
of if you fancy SBT:
sbt -Dconfig.file=/var/lib/jenkins/jenkins.conf test
Dev Environment
Also note it's easy to make a developer.conf file as well, to keep all your passwords/local ports, and then set a .gitignore so dev's don't accidentally check them in.
The below command works with Play 2.5
$ activator -Dconfig.resource=jenkins.conf run
https://www.playframework.com/documentation/2.5.x/ProductionConfiguration

Superseding scala conf file as JVM argument?

I have an application.conf file that is read by my program (via com.typesafe.config) at each run. I would now like to keep only standard settings in that file, and be able to specify a superseding conf file thisrun.conf for each run (i.e. the app should use configs from thisrun.conf and fall back on application.conf for any missing configs).
Can this be done by simply passing the thisrun.conf file as a parameter to the JVM, or do I have to pass it as an argument to my app? A previous question shows how to pass a config file using -Dconfig.file, but this seems to bypass application.conf, rather than supersede it.
I found one way of superseding application.conf with thisrun.conf using the -Dconfig.file argument. Simply put as the first line in thisrun.conf:
include "application.conf"
This way the behavior will be exactly as asked in the question.
I would still be interested if there are other ways of doing the same, that do not require an explicit include of application.conf.

environmental variable substitution when including another configuration file in Play 2.2

Is it possible to use environmental variable substitution when including another configuration file?
I would like to have something like that:
include "${HOME}/.foo/credentials.conf"
Configuration documentation mentions locating resources and include substitution but not together.
This works:
include "/home/me/.foo/credentials.conf"
and my HOME is correctly set.
But all attempts to make include "${HOME}/.foo/credentials.conf" so far failed
Background:
I deliberately want to keep credentials and other sensitive data out of our code base but have them available for local dev environments for testing. I am aware of more sophisticated solutions using external storage like hinted here Playframework 2 - Storing your credentials and we use something similar for live and preview environments but these are not suitable for local dev setup.
An alternative is to include credentials file to code base after all but use git ignore to prevent pushing it, but it is fragile solution and risk is someone will eventually push it and compromise credentials.
TBH I'm not even able to include file with absolute path /home/me... anyway approach which will work for you is just using alternative conf file as described in the same doc:
In file /home/me/.foo/credentials.conf you need to include application.conf - Play will fallback it to the file in classpath (this which is under VCS):
include "application.conf"
myCredentials.user="Espinosa"
myCredentials.password="fooBar123"
then run/start your app with this config file locally:
play -Dconfig.file=${HOME}/.foo/credentials.conf ~run
and that's it.
Note: of course it's easier to setup this addition in your IDE (i.e. IntelliJ: Run > Edit configurations) or write a shell script containing this command

Configuration centralization for Play2 Scala; or how to stop hardcoding variables

At the moment, I'm hardcoding several variables like resource names and ports. I would like to move them out of my code.
What are recommended means of implementing a central configuration outside the actual code? Like a file maybe. So that, while the production and development are using same git repository, the configurations would be seperate. I am using Play 2 Framework on Scala.
I would suggest using the Typesafe Config library. It loads and parses files that can be a mix of .properties style, JSON, or extended JSON (called HOCON - "Human-Optimized Config Object Notation"), and is the configuration style used by Play 2 itself (and Akka, Spray, and a quickly growing list of other libraries).
In Play's standard application.conf file you can include files like so:
include "file:///..."
In this file you could override what properties you need to.
Additionally, (as documented in the excellent play docs), one can specify conf files during app startup like so:
Using -Dconfig.file
You can also specify another local configuration file not packaged into the application artifacts:
$ start -Dconfig.file=/opt/conf/prod.conf
Using -Dconfig.url
You can also specify a configuration file to be loaded from any URL:
$ start -Dconfig.url=http://conf.mycompany.com/conf/prod.conf
Note that you can always reference the original configuration file in a new prod.conf file using the include directive, such as:
include "application.conf"
key.to.override=blah
Configuration is likely a mean of taste, but Typesafe Config is one of the common libraries to use in scala/play ecosystem (e.g. it is used in akka).

Do Doxygen config files support variables?

For instance I set the source code path as c:\code\testapp\src. Is this then available as a var I can use - for instance so I can spit out a tag file in a location relative to this, not relative to the working dir of doxygen? I think I'm looking for something like how Ant defines vars for just about everything and these can be re-used; does Doxygen have special vars for any of the config values?
I'm thinking like $PROJECT-NAME or %VERSION% or whatever...
You can use environment variables in the configuration file; the syntax is the same as in a makefile, i.e. $(VAR_NAME)
I am not sure, but I have seen people use variables as part of their build process. For example the lemon graph library uses cmake, sets a variable for the absolute file path in cmake and the doxygen config file includes variables such as #abs_top_srcdir#. Through the build process these variables are replaced with the relevant text.