How can an attribute be set programmatically in a reference.conf file?
For example, I am using something like this in Spring to set the attributes of the keystore:
System.setProperty("server.ssl.keyStore", "keystore.jks")
System.setProperty("server.ssl.keyStorePassword", "password123")
Same way, you can override configuration from the reference conf file using system properties, they have the highest precedence order as described here:
https://github.com/lightbend/config#standard-behavior
Please be aware you need to do it before the config is loaded by the class that uses it (via ConfigFactory.load()) and if any other class has already used ConfigFactory, then a call to ConfigFactory.invalidateCaches() will also be required, otherwise the cached value will be used.
Related
If i'm using Java, I can set custom application.properties location with something like this:
#PropertySources({
#PropertySource(value = "file:${APP_CONF_DIR}/application.properties", ignoreResourceNotFound = true)
})
Is there any way to do the same thing in Scala without using "-Dbla.bla=app.config" on application start
The behavior of Lightbend Config around loading application.conf is mostly from ConfigFactory.load(), which will look for application.conf or the file/resource given by Java properties (the -Dconfig.file and friends in your question).
If not interested in setting the alternative to application.conf through Java properties, one can load a different resource from the classpath with ConfigFactory.load("foo") to load foo.conf. Alternatively if one is loading a file, one can use ConfigFactory.load(ConfigFactory.parseFile(file)), where file is a java.io.File.
What does the method load(Config) in class com.typesafe.config.ConfigFactory do? How would the output Config be different from the input Config?
The documentation says that it:
Assembles a standard configuration using a custom Config object rather than loading "application.conf". The Config object will be sandwiched between the default reference config and default overrides and then resolved.
I do not understand what it is saying.
The code shows that:
public static Config load(Config config) {
return load(checkedContextClassLoader("load"), config);
}
It seems to be loading with a checkedContextClassLoader which I don't understand. Can someone give a short understandable explanation of this?
How would the output Config be different from the input Config?
It has the reference config (loaded from reference.conf) as fallback for anything not defined in the input Config, and then overrides from system properties are applied ("Future versions may get overrides in more places. It is not guaranteed that this method only uses system properties.").
It seems to be loading with a checkedContextClassLoader which I don't understand.
I don't think this is an important part. This is simply the default classloader used by the library.
I am new in Akka and I faced the problem below.
I want to externalize the configuration in my App. More specifically, I have some variables that are different per each environment. So I think that I can have specific environment variables (secrets, etc) for each environment.
But what I can do with some variables (non-secrets) which are different per each environment?
What is the difference between, dev.properties, application.conf, deploy.json files?
What is the proper way to load variables from those files?
There's a few options:
Environment variables and using the support for substitution (there is also support for having default in the file and only use the environment vars if they are set). - https://github.com/lightbend/config#optional-system-or-env-variable-overrides
System properties, if you set a system property when you start the JVM, and that system property matches a path in the config file, it overrides the setting
You can point to an alternative application.conf file using a system property - https://github.com/lightbend/config#standard-behavior
If that is not enough you could also do completely custom logic around selecting logic by programmatically creating a Config instance and passing that to the ActorSystem when you create it.
The dev.properties and deploy.json is AFAIK not related to Akka, unless something specifically done in your application.
I am using spring cloud config for loading properties file for my application. I have multiple environments. I notice that the property files are loaded in wrong order. This is what i see in my logs
Located property source: CompositePropertySource [name='configService', propertySources=[MapPropertySource [name='https://github.com/xyz/configrepo.git/gatekeeper-dev.properties'], MapPropertySource [name='https://github.com/xyz/configrepo.git/gatekeeper.properties']]]
It seems that the environment specific property file is loaded first and overridden by the default property file. Is there any way i can control the order in which they are loaded and processed ?
That is the expected order (for good reasons so I am surprised you found a use case where it wasn't convenient). You can't control it except by changing the names of the files and listing them in a comma separated form. For the sake of clarity: profile specific properties always override default ones. Possibly the logs have confused you.
First of all, should I use Lift Props to store specific configurations of my App? Lift documentation explains that you can use this Props to configure the enviroment (production, testing, etc etc.) but never says if you can use them for other purposes.
If there's nothing wrong in using them, how can I store these properties (save them). All the functions that I can see in Props object are getters. E.g if I have a property myapp.myconf1
I would like to do something like:
Prop.save("myapp.myconf1","value1")
Is this possible using Props or should I use other libs like Typesafe config or java props?
Thanks in advance!
The Lift Props object isn't intended to be a read/write store. It's a repository for deployment specific config info (i.e. the settings that are different between your development/test/release environments). The file is stored within the classpath and if you are deploying as WAR file I don't believe there would be any way to change it even if an API existed.
If all you need is to store name value pairs then java props should work fine.