When using external application properties it's possible to import further configuration data from other locations using spring.config.import (Spring Boot doc). When using spring.config.import the properties in the imported files will take precedence over the properties defined in the file that triggered the import.

In some use cases, it would make sense for the properties in the file importing the additional configuration data to take precedence. For example, we have a template application.yaml for defining services based on Spring Boot. Services then define their specific application.yaml and include the template properties. In this situation it would make sense for the service-specific properties to have precedence over the template properties. Although this can be achieved by changing the load order and default config names and locations it becomes a bit cumbersome if we want to import additional configuration from several files.

Would it make sense to allow the behaviour of spring.config.import to be configurable?

Comment From: philwebb

It's an interesting idea, but I quite hesitant to add any more complexity to the code that handles spring.config.import. I think for now I'd recommend either using an EnvironmentPostProcessor to plug-in your own property support, or import both files from a spring.config.import in your main application.yaml. E:g:

spring:
  config:
    import:
    - "service-template.yaml"
    - "service-specific.yaml"

Comment From: joca-bt

Leaving this note here as it may be helpful for someone else in the future:

It's possible to achieve what I mentioned originally without changing any "load order and default config names and locations" by using multi-documents. Define your application.yaml that is importing templates as

spring.config.import: <template yaml>

---

your overrides

spring.config.import inserts the imported properties just below the current subdocument and thus before your overrides.