A few weeks ago, I published a blog post about how Spring Boot binds configuration values to JavaBeans. Shortly after this post has been published, Stéphane Nicoll reached out to me. We discussed my findings and came to the conclusion that my blog post was built on false assumptions about how configurations should be defined in Spring Boot.
What was I thinking?!
But let me start from the beginning. I started to think about configuration binding for the first time when I experienced problems with setting the spring.datasource.driver-class-name using OS environment variables. This got me thinking how property names relate to environment variable definitions. Furthermore I was keen to find a good best practice on how to define property keys so that they can be set using environment variables. I looked through the docs to find some information about the logic involved when configuration is loaded in Spring Boot from various sources. After I could not find this information, I started to reverse engineer configuration binding. But this just made the confusion worse. And it all resulted in a blog post that doesn’t really help anybody.
So the question is: How should configuration loading be approached in Spring Boot applications? Stéphane told me that the canonical way of defining property names is to use hyphens. But since Spring Boot cannot accommodate one format for every source (i.e. OS env variables on certain OS doesn’t allow you to use dots), there is the relaxed binding to support those property sources. Moreover he introduced me to configuration meta-data, which is a way to tell your IDE about the structure of your configuration. Tools like IntelliJ can then assist you when implementing configurations. What I learned is that you should define your configuration classes first and then think about how that can be mapped to your property sources instead of doing it the other way around. For this reason I’m planning to write a blog post about the best practices for defining and loading configuration in Spring Boot soon.
I’d like to thank Stéphane Nicoll for being such a pleasant person to discuss this matter with.