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:
old-properties:
an:
old-property: true
another:
custom-property: 1234
A new version of that library redefines the configuration to something like this:
my-library:
a-property: true
another-property: 1234
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.
I looked into how Spring Boot handled the deprecation phase for
logging.file
(which was replaced bylogging.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):
The
@Bean
method now takes care of reading the old value and applying it to the properties:If the new value is also set via config, it will override the value set from the old property.