In a previous blog post we learned about the default input sources that are used by Helidon SE. The list of input sources is different based on which artifacts are on the classpath of our application. When we write tests for code in our application that uses the default configuration created by Config.create()
we must take into account that different input sources are used. Also here it is based on the artifacts that are on the classpath. That means that different files with configuration data are loaded, eg. a file application-test.conf
when we have the artifact helidon-config-hocon
and a file application-test.yml
if the artifact helidon-config-yaml
is on the classpath.
Continue reading →
When we use Helidon SE we can use the Config
class to pass configuration properties to our application. The static method create()
creates a default configuration. The Config
class is then configured to support different input sources. This configuration reads configuration properties from the following sources in order:
-
Java system properties,
-
system environment variables,
-
a file on the classpath that has the name application.properties
(based on default config parser that is part of the artifact helidon-config
).
The last input source behaves differently based on which classes that can parse a configuration file are on the classpath of our application. If we use the helidon-config
artifact on the classpath then the configuration file read is application.properties
. To read a JSON formatted configuration file we must add the helidon-config-hocon
artifact to the classpath. The file that is read is application.json
. With the same artifact we can read a HOCON formatted configuration file that is named application.conf
. Finally if we add the helidon-config-yaml
artifact to the classpath we can read a YAML formatted configuration file that is named application.yaml
or application.yml
. Helidon SE will only read one configuration file from the classpath with the following order of preference:
Continue reading →