Override property with my profile dev in Spring Boot 2.4

Question

I tried to override the property

kafka.servers=s101lbakafpep1:9092,s102lbakafpep2:9092,s101lbakafpep3:9092

defined in my src/main/resources/config/application-kafka.properties file

with this value

kafka.servers=localhost:9092

defined in my src/main/resources/application-dev.properties file

I tried every combination possible reading the spring boot doc changing in my application.properties the order of

spring.profiles.active=config,health,planete,dgfip,mapping,kafka,dev
spring.profiles.active=dev,config,health,planete,dgfip,mapping,kafka

using spring.config.use-legacy-processing to true or false or .include, it's always the kafka config that wins

It's not working since i changed spring boot version to 2.4

Answer 1

Thanks for the very helpful hint @gviczai, solved my problem loading and overriding configs from YAML files. I completely missed the following sentence in the documentation which made my unit tests fail because values have not been overridden as it was the case with Spring Boot 2.3.

Imports can be considered as additional documents inserted just below the document that declares them. They follow the same top-down ordering as regular multi-document files: An import will only be imported once, no matter how many times it is declared.

So if you want to override imported values a new document has to be started after the import (--- in yaml, #--- in properties).

# imported-config.yaml
my-key: my-value

# application.yaml
spring:
    config:
        import:
            - classpath:imported-config.yaml

# before starting a new document the value can not be modified, it would still be "my-value"
my-key: here-overriding-does-not-work
---
# after the start of the new document the value can be modified
my-key: my-overridden-value

Answer 2

In Spring Boot 2.4, configuration file handling is completely rethought and rewritten. Long story short: Forget the legacy profile-dependent documents. From now on, you have to use only one big application.properties file, but it can be divided into various profile-activated sections. These sections then can come from other files or even documents from URLs - see cloud-config.

And the main rule is: definitions BELOW always overwrite definitions ABOVE. So be careful with the order the sections (thus profiles) follow each other! ;)

You can separate the sections with "#---" and you can define which profile activates the section by providing "spring.config.activate.on-profile=<your_profile>"

So, in your case your application.properties should look like this:

my.property=anything
...
server.name=myserver
#in your 'default' section, you can activate any profile, so it will be active by default
spring.profiles.active=kafka
#---
spring.config.activate.on-profile=kafka
spring.config.import=application-kafka.properties
#---
spring.config.activate.on-profile=dev
spring.config.import=application-dev.properties
#---
spring.config.activate.on-profile=cloud
spring.config.import=optional:configserver:http://my.config.server:8080/cloud-config

Of course, you can use yaml file if you prefer. In this case the document separator is the standard "---".

Read more about this new paradigm of config file processing here: https://spring.io/blog/2020/08/14/config-file-processing-in-spring-boot-2-4

(And I guess 'kafka' profile wins over 'dev' because 'k' is AFTER 'd' in the abc... BTW, I think it is better not to name the imported documents according to the legacy profile-dependent "application-<profile>.properties" naming convention, because it may interfere with the profile-handling code. Better to be safe than sorry.)

Tip: Note, that in the same 'document' (a section in the same file considered a document) even the spring.config.import can overwrite previous values. So if you need to import multiple sources within the same section, use a comma-separated list:

spring.config.import=classpath:config/kafka.properties,classpath:db/postgres.properties