No subdirectories found for mandatory directory location 'file:./config/*/' is thrown when config dir exists

[gmariotti]

Hi, something changed in Spring Boot 2.4.6 and 2.5.0 when the docker image is built using Jib gradle plugin. Previously, our application was able to start without any issue with the following directories structure

/app
|_classes/ (contains the SpringBootApplication)
|_libs/
|_resources/
  |_application.yml
/config
|_ application-kubernetes.yml

but since the update, the application fails with a java.lang.IllegalStateException: No subdirectories found for mandatory directory location 'file:./config/*/'.. Any idea why?

Some extra information:

• The docker image entrypoint is ["java", "-javaagent:newrelic/newrelic.jar", "-cp", "/app/resources:/app/classes:/app/libs/*", "com.olx.SpringBootApplicationKt"]
• Environment variable SPRING_PROFILES_ACTIVE=kubernetes

[wilkinsona]

file:./config/*/ isn't a default mandatory config location so I suspect that something must be configuring it. Given your directory structure, the error message looks correct to me as /config does not have any subdirectories. What's confusing is that I would expect this to have failed with 2.4.5 and earlier, but with a less helpful error message: #26415.

To help us to figure out exactly what's happening, can you please provide a minimal sample that reproduces the problem with 2.4.6 and that works with 2.4.5? You can share it with us by zipping it up and attaching it to this issue or by pushing it to a separate repository on GitHub.

[Prieschl]

I have the same problem since v. 2.4.6/2.5.0. It can be reproduced with a simple default project from start.spring.io (java 11, maven) by adding an empty folder "config" into the project root. It makes no difference if there actually is an application.yml file or not.
demo.zip

[jnaalisv]

Same here; this prevents us from upgrading to 2.4.6. I managed to circumvent this by adding an empty subdirectory to /config, but that's not a preferable solution.

[gmariotti]

@wilkinsona created https://github.com/gmariotti/spring-boot-bug to run it in a local kubernetes cluster

[Mario-Eis]

We are also affected by this and had to stay with version 2.4.5. We configure our application containers by mounting directories containing all config files to /config inside the individual containers.

See: https://docs.spring.io/spring-boot/docs/current/reference/htmlsingle/#features.external-config.files

Spring Boot will automatically find and load application.properties and application.yaml files from the following locations when your application starts:

1. The classpath root
2. The classpath /config package
3. The current directory
4. The /config subdirectory in the current directory
5. Immediate child directories of the /config subdirectory

We use 4. The /config subdirectory in the current directory. So its a /config directory with only an application.yml and several other config files (log, cache,...) that are referenced inside the application.yml. No subdirectories whatsoever. There is no need for them and they would just make the whole thing unnecessary complicated. Not to speak of putting an unnecessary subdirectory in all of our container configurations.

[wilkinsona]

Thanks, @Prieschl and @gmariotti, for the samples. With those I now believe I fully understand the problem.

The problem is that the default optional:file:./config/*/ search location is being treated as if it's mandatory. This branch contains a fix that I'll review with the rest of the team.

A couple of workarounds:

1. Add an empty sub-directory to ./config
2. Set spring.config.location to optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/.

The second option retains all the default config locations other than the one causing the problem. Note that spring.config.location should be set using an environment variable or system property so that it's picked up before configuration file processing begins. When setting it as an environment variable, SPRING_CONFIG_LOCATION should be used.

[johanhaleby]

We also get this error when upgrading to Spring Boot 2.5.0. Setting the "spring.config.location" to optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/ in our application.yaml file doesn't seem to work for us unfortunatley.

[Polve]

Same problem here

[tt4g]

@johanhaleby By the time the application.yml is loaded, spring.config.location will have done its job.
As written in this comment, you have to specify it with the java command argument --spring.config.location=optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/ or the environment variable SPRING_CONFIG_LOCATION=optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/.

[yu-shiba]

This workaround will not work if spring.config.use-legacy-processing is set.
Even if you take the workaround with this set, the per-environment configuration (application-xxxx.yml or application-xxxx.properties) will be ignored.

[yubobo]

Same problem here！

[astellingwerf]

Is this fix planned for 2.5.x too? We need to upgrade to address cve-2021-22118, but this bug blocks us from upgrading.

[snicoll]

@astellingwerf all fixes are obviously merged forward see #26672. Also, there's no need to upgrade to Spring Boot 2.5.x to benefit from the CVE fix.

[astellingwerf]

Thanks @snicoll, you're right, I mentally took a wrong turn there. Upgrading the Spring Boot Gradle plugin or Maven parent to v2.3.11.RELEASE should do the trick.

[amkuio]

Hi, something changed in Spring Boot 2.4.6 and 2.5.0 when the docker image is built using Jib gradle plugin. Previously, our application was able to start without any issue with the following directories structure

/app
|_classes/ (contains the SpringBootApplication)
|_libs/
|_resources/
  |_application.yml
/config
|_ application-kubernetes.yml

but since the update, the application fails with a java.lang.IllegalStateException: No subdirectories found for mandatory directory location 'file:./config/*/'.. Any idea why?

Some extra information:

• The docker image entrypoint is ["java", "-javaagent:newrelic/newrelic.jar", "-cp", "/app/resources:/app/classes:/app/libs/*", "com.olx.SpringBootApplicationKt"]
• Environment variable SPRING_PROFILES_ACTIVE=kubernetes

After upgrading Spring Boot from 2.4.5. to 2.4.6 started getting the same error. Was able to fix it by setting SPRING_CONFIG_LOCATION to optional:classpath:/,optional:classpath:/config/,optional:file:./,optional:file:./config/ in environment variable.
Thanks, @wilkinsona for the workaround. Hope this will be fixed in upcoming releases.

[snicoll]

Hope the will be fixed in upcoming releases.

@amkuio you can figure that out by yourself right now by testing 2.4.7-SNAPSHOT. If that doesn't fix the problem for you, please let us know.

[JV-TMCZ]

Confirming that both 2.4.7-SNAPSHOT and 2.5.1-SNAPSHOT works. Great, thanks.

Currently I just tried
<parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.5.1-SNAPSHOT</version> </parent>

Is there a way to use only one fixed dependency in SNAPTHOT version? Instead of whole parent? which one?
When could we expect these version released?

[TaylorSMarks]

Given 2.4.5 has security issues and that 2.4.6 and 2.5.0 are both broken, it makes sense to immediately release another version.

Maybe release a 2.4.5.1 or something that fixes the security issues and does nothing else. Or release a 2.4.6.1 that just fixes this issue.

[scottfrederick]

Spring Boot 2.4.7 and 2.5.1 will include all fixes that have been identified in 2.4.6 and 2.5.0, including this issue. You can view the project's milestones page to see what will be included in these releases. We will decide the dates for those releases in the next few days.

Given 2.4.5 has security issues

As @snicoll mentioned, you likely don't need a Spring Boot release to mitigate CVEs, as you can override the version of any dependency in your build.

[amkuio]

Hope the will be fixed in upcoming releases.

@amkuio you can figure that out by yourself right now by testing 2.4.7-SNAPSHOT. If that doesn't fix the problem for you, please let us know.

@snicoll Works fine with 2.4.7-SNAPSHOT. Thank you for the update 💯

[borasik]

Same here