Skip to content
Advertisement

Backwards compatibility when changing Spring Boot externalized configuration

Is there a recommended way to introduce restructurings/renamings into an externalized configuration while keeping backwards compatibility for consumers still relying on the old configuration structure?

For example, given a library used the following configuration structure defined via @ConfigurationProperties in the past:

JavaScript

A new version of that library redefines the configuration to something like this:

JavaScript

Is there a good way to deprecate the old structure while keeping compatibility for existing consumers for some time? Consumers using the new version of the library should still be able to use old-properties.an.old-property and have that automatically mapped to my-library.a-property.

I’m aware of the functionality to use additional configuration metadata to mark a property as deprecated, but I’m explicitly looking for a way to support both versions to ease migration.

Advertisement

Answer

I looked into how Spring Boot handled the deprecation phase for logging.file (which was replaced by logging.file.name) and as they implemented the fallback directly in code I decided to try something similar by creating the new @ConfigurationProperties in a @Bean method which handles setting the values from old property names if available.

Given the new configuration structure looks like this (using Lombok for brevity):

JavaScript

The @Bean method now takes care of reading the old value and applying it to the properties:

JavaScript

If the new value is also set via config, it will override the value set from the old property.

User contributions licensed under: CC BY-SA
3 People found this is helpful
Advertisement