Importing config files across modules
See original GitHub issueI have two modules in the same project, one by another:
A
|-- application.yaml
|-- application-dev.yaml
B
|-- base-application.yaml
|-- base-application-dev.yaml
Been using custom EnvironmentPostProcessor
to load base-
config into A
but with SB 2.4 I wanted to give config.import
a try. But there are a few issues arisen.
(1)
In A/application.yaml
I’ve added the following:
spring:
config:
import: classpath:/base-application.yaml
In A/application-dev.yaml
it’s respectively:
spring:
config:
import: classpath:/base-application-dev.yaml
Trying to start A
fails with Config data location 'classpath:/base-application-dev.yaml' does not exist
. That’s rather confusing considering that it does exist indeed and that classpath:/base-application.yaml
is loaded just fine from the same location. To verify that, I made a typo in the file name and it failed for 'classpath:/bas-application.yaml'
as expected.
Renaming base-application-dev.yaml
to something profile-unrelated like some-file.yaml
still fails with resource does not exist.
(2)
If I don’t change A/application-dev.yaml
at all, I do see that SB takes B/base-application-dev.yaml
into account when loading classpath:/base-application.yaml
and properly loads it. The application starts just fine with all properties. So clearly it does exist in (1). But now the ordering of property sources is not correct. Here’s what it is from environment
:
...
application-dev.yaml
base-application-dev.yaml
base-application.yaml
application.yaml
...
base-dev
overrides dev
but application
overrides base-application
.
Issue Analytics
- State:
- Created 2 years ago
- Comments:10 (6 by maintainers)
As you said initially, there are a few issues here.
One is a bug that’s causing a confusing error message unrelated to modules and precedence of property loading. I’ve now split that out into #26147 so we can address that bug.
The rest of this discussion has to do with a specific problem you are trying to solve and whether your approach will work given the design of Spring Boot’s property loading. Let’s continue that discussion here.
Yeah, that’s an ultimate question in the late discussion here. I’ll close this one then as there are two tickets that cover it now.