In Java, we often have framework support for importing settings from the file system of our application. If we’re lucky, and we often are, these settings can be customised and overridden by system properties or environment variables.
However, there are a couple of situations where this doesn’t quite apply:
- Very lightweight applications that use no frameworks
- Loading custom settings based on business logic
Though we can shoe-horn heavier frameworks like Spring into the first, or try to force Spring to process properties for us, often we need a lighter solution.
I recently wrote and released Lightweight Config, an open source package to solve this with either
I’ve demonstrated its use in AWS Lambdas in an article on Baeldung.com.
I thought it might be nice to cover a different use case in this article, notably how it might be used to load settings up in a test.
At The Max
I wrote Lightweight Config from the ground up, but I’ve used its predecessors extensively. Originally, it was a test-helper library. Then I created one for loading settings for lambdas.
At full strength, you’d define a
Then a POJO to load the file into:
Then it’s a one liner to load from the yaml into the
Settings object –
Settings settings = ConfigLoader.loadYmlConfigFromResource("settings.yaml", Settings.class)
There are also some hooks that can be applied to plug in custom tags if necessary.
Reading Per Environment Properties
Let’s flip to an example where we just want some Java
.properties loaded into
Properties. One might argue that the POJO approach gives us a better API, but let’s say we’re using something that’s already bound to
Properties, such as an email client, or DB connection pool.
Here’s a snippet of some settings that relate to dev:
Let’s call this file
Now let’s create a parent file with all the global settings in:
Let’s call this file
app.properties and put it in the same directory as contains the
profiles directory mentioned above.
Now we can load both the above files into a
Properties object by:
What happens in this case is that the various placeholders are filled in from environment variables (or system properties if you prefer). Included in this is the
#import statement, which not only describes how a child file is imported, but allows placeholder interpolation into the path of that file.
So, by setting a different
ENV_NAME environment variable, the same loading code could import a different set of per-environment properties into the whole
Properties object being loaded.
It’s a simple syntax/approach that’s flexible enough to use for a variety of things.
I hope it’s useful.