How to manually specify the custom location of a Typesafe Config configuration file

If you need to manually specify the custom location of a Lightbend Config (HOCON) configuration file when running a Scala or Java application, I can confirm that this java command setting works:

java -Dconfig.file=my_app.conf [the rest of your app parameters]
     -------------------------

Reading the HOCON file in a Scala app

In my case, inside my Scala application I read the HOCON config file like this:

val config: Config = ConfigFactory.load("my_app.conf")

To demonstrate what I mean, here’s the complete java command I use to run a Scala application I’m working on:

java \
  -Xmx1G \
  -Dconfig.file=kbhr_geo.conf \
  -cp "${CLASSPATH}:./scala-library.jar:./KbhrGeo-assembly-1.0.jar" \
  KbhrGeoApp

In that example, kbhr_geo.conf is the name of my Lightbend configuration file, and it’s located in the current directory where I run that command.

Note: Specifying the filename in the app may not be necessary

As I wrote that text I just realized that it may not be necessary to specify the configuration file filename inside the application; that is, as long as I use one of the default filenames that ConfigFactory looks for, I may just be able to do this inside my application:

val config: Config = ConfigFactory.load()

I just thought about that, and I haven’t tested it yet, but since I specify the configuration file location with the -Dconfig.file parameter, I suspect you might not need to declare the name again inside the application.

Per their docs, these are the default filenames that the Lightbend Config library looks for on the CLASSPATH:

• application.conf
• application.json
• application.properties
• reference.conf

ScalikeJdbc configuration file location

As a note to self, this same approach also works when specifying the location of a ScalikeJdbc configuration file, which uses the Lightbend Config library under the covers. In another application I use that same approach to specify the location of the configuration file, and then use this ScalikeJdbc command at the beginning of my application:

DBs.setupAll()

Due to some under-the-covers magic I haven’t read about yet, I can confirm that this approach works with ScalikeJdbc as well.