Open
Description
Currently application.properties
and application.yaml
files are loaded from the classpath and the first match wins. This makes it hard to bundle common properties into jar files. It would be nice if we could find a way for jars to also contribute properties without needing to implement a EnvironmentPostProcessor
.
There are a few things we need to be careful of:
- What order to we load the resources and how do we make sure a developer can override a contributed value
- We don't want to increase startup time (for example by doing a full classpath search)
- We can't break back-compatibility
- We need to be mindful of
spring.config.import=classpath:
Metadata
Metadata
Assignees
Labels
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
mbhave commentedon Jan 7, 2021
Ordering will be tricky with this one. If two jars happen to provide
application.properties
files with the same value, we need a way to determine which one will win.alex-lx commentedon Jan 18, 2021
Would using an
order
property in application.properties be a simple way?philwebb commentedon Jan 28, 2021
We should look into the use-case behind #25033 when we fix this one.
stategen commentedon Feb 2, 2021
@philwebb & @wilkinsona ,thanks for your great work!
--spring.config.intergration-location=classpath*:/sink//[application.yml]
, in my pull request #25082, similar #25080the dependency jar's configs just to reduce the duplicate or mistake works by the the project who use it.
so the rule: lowest order and can be overrided by any, not care conflicts(use map value),not overrides higher/outside value, limit 2 wildcards ,endswith '*/' or filename and filtered by '/fold/' .
the rule will never break back-compatibility.
and with a new arg to ensure never break back-compatibility.
In my real project(240 jars) with the update i pulled, the startup time is not slow,just normally.
I perfer to use spring in xml(
<resource import="classpth*:">
), but more and more cloud-framework only provide with spring-boot'style config,there is really no back-way to use spring-bootstategen commentedon Feb 2, 2021
wilkinsona commentedon Feb 2, 2021
We should also consider #25084 when looking at this.
12 remaining items
wilkinsona commentedon Aug 9, 2021
#27544 is another one to consider when looking at this.
victorherraiz-santander commentedon Aug 19, 2022
could it be possible to allow merging default properties instead of replacing them?
https://docs.spring.io/spring-boot/docs/current/api/org/springframework/boot/SpringApplication.html#setDefaultProperties-java.util.Map-
Adding a new method to allow add instead of replace?
After that, something like defining some known property files in the jars could contribute to configure defaults.
At the moment I am doing something like:
LPS-179319 springboot known issue, don't use application.properties i…
LPS-179319 springboot known issue, don't use application.properties i…
@PulsarMessage
annotation to set default topic and schema for class spring-projects/spring-pulsar#417Nico-Strecker commentedon Sep 20, 2023
can i somehow weaken the priority of a profile @wilkinsona ?
I want to include properties of my application-customprofile.yml but only if they are not defined in my application.yml
Edit: That seems to work
Application
Library:
or Library fancy:
might help someone 😄