[UnsupportedConfigDataLocationException] Can not mount external configuration file

[sant1ago-da-hanoi]

Currently, I'm using 4.0.0-RC1 and can not start the app if the application.yml file is being mounted from another directory.

My docker-compose.yml:

services:
  backend:
    image: my-backend:latest
    container_name: my-backend
    ports:
      - "8080:8080"
    environment:
      - SPRING_PROFILES_ACTIVE=dev
      - TZ=Asia/Ho_Chi_Minh
    volumes:
      # - /var/www/env/my-backend/:/opt/app/:ro
      - /var/www/env/my-backend/application-dev.yml:/app/config/application-dev.yml:ro
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/api/actuator/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s

Given error:

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 =========|_|==============|___/=/_/_/_/

 :: Spring Boot ::            (v4.0.0-RC1)

18:34:28.229 [main] INFO  sant1ago_dev.RuntimeApplication - Starting RuntimeApplication v0.0.1-SNAPSHOT using Java 25 with PID 1 (/app/my-backend.jar started by root in /app)
18:34:28.240 [main] INFO  sant1ago_dev.RuntimeApplication - The following 1 profile is active: "dev"
18:34:37.636 [main] INFO  o.s.d.r.c.RepositoryConfigurationDelegate - Multiple Spring Data modules found, entering strict repository configuration mode
18:34:37.650 [main] INFO  o.s.d.r.c.RepositoryConfigurationDelegate - Bootstrapping Spring Data JPA repositories in DEFAULT mode.
18:34:37.921 [main] INFO  o.s.d.r.c.RepositoryConfigurationDelegate - Finished Spring Data repository scanning in 189 ms. Found 0 JPA repository interfaces.
18:34:38.401 [main] INFO  o.s.d.r.c.RepositoryConfigurationDelegate - Multiple Spring Data modules found, entering strict repository configuration mode
18:34:38.407 [main] INFO  o.s.d.r.c.RepositoryConfigurationDelegate - Bootstrapping Spring Data Redis repositories in DEFAULT mode.
18:34:38.512 [main] INFO  o.s.d.r.c.RepositoryConfigurationDelegate - Finished Spring Data repository scanning in 56 ms. Found 0 Redis repository interfaces.
18:34:42.219 [ForkJoinPool.commonPool-worker-1] INFO  c.tngtech.archunit.core.PluginLoader - Detected Java version 25
18:34:53.801 [main] WARN  o.s.b.w.s.s.c.AnnotationConfigServletWebServerApplicationContext - Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'meterRegistryPostProcessor' defined in class path resource [org/springframework/boot/micrometer/metrics/autoconfigure/MetricsAutoConfiguration.class]: org.springframework.boot.context.config.UnsupportedConfigDataLocationException: Unsupported config data location 'optional:file:./;optional:file:./config/;optional:file:./config/*/'
18:34:53.972 [main] INFO  o.s.b.a.l.ConditionEvaluationReportLogger -

Error starting ApplicationContext. To display the condition evaluation report re-run your application with 'debug' enabled.
18:34:54.177 [main] ERROR o.s.boot.SpringApplication - Application run failed
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'meterRegistryPostProcessor' defined in class path resource [org/springframework/boot/micrometer/metrics/autoconfigure/MetricsAutoConfiguration.class]: org.springframework.boot.context.config.UnsupportedConfigDataLocationException: Unsupported config data location 'optional:file:./;optional:file:./config/;optional:file:./config/*/'
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:611)
        at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:526)
        at org.springframework.beans.factory.support.AbstractBeanFactory.lambda$doGetBean$0(AbstractBeanFactory.java:333)
        at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.getSingleton(DefaultSingletonBeanRegistry.java:371)
        at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:331)
        at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:201)
        at org.springframework.context.support.PostProcessorRegistrationDelegate.registerBeanPostProcessors(PostProcessorRegistrationDelegate.java:277)
        at org.springframework.context.support.AbstractApplicationContext.registerBeanPostProcessors(AbstractApplicationContext.java:801)
        at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:604)
        at org.springframework.boot.web.server.servlet.context.ServletWebServerApplicationContext.refresh(ServletWebServerApplicationContext.java:143)
        at org.springframework.boot.SpringApplication.refresh(SpringApplication.java:765)
        at org.springframework.boot.SpringApplication.refreshContext(SpringApplication.java:454)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:321)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1374)
        at org.springframework.boot.SpringApplication.run(SpringApplication.java:1363)
        at sant1ago_dev.RuntimeApplication.main(RuntimeApplication.java:46)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
        at java.base/java.lang.reflect.Method.invoke(Method.java:565)
        at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:106)
        at org.springframework.boot.loader.launch.Launcher.launch(Launcher.java:64)
        at org.springframework.boot.loader.launch.JarLauncher.main(JarLauncher.java:40)
Caused by: java.util.concurrent.CompletionException: org.springframework.boot.context.config.UnsupportedConfigDataLocationException: Unsupported config data location 'optional:file:./;optional:file:./config/;optional:file:./config/*/'
        at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323)
        at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359)
        at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364)
        at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1791)
        at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1781)
        at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511)
        at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1450)
        at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2019)
        at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
Caused by: org.springframework.boot.context.config.UnsupportedConfigDataLocationException: Unsupported config data location 'optional:file:./;optional:file:./config/;optional:file:./config/*/'
        at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:98)
        at org.springframework.boot.context.config.ConfigDataImporter.resolve(ConfigDataImporter.java:107)
        at org.springframework.boot.context.config.ConfigDataImporter.resolve(ConfigDataImporter.java:99)
        at org.springframework.boot.context.config.ConfigDataImporter.resolveAndLoad(ConfigDataImporter.java:87)
        at org.springframework.boot.context.config.ConfigDataEnvironmentContributors.withProcessedImports(ConfigDataEnvironmentContributors.java:130)
        at org.springframework.boot.context.config.ConfigDataEnvironment.processInitial(ConfigDataEnvironment.java:249)
        at org.springframework.boot.context.config.ConfigDataEnvironment.processAndApply(ConfigDataEnvironment.java:236)
        at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:97)
        at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.applyTo(ConfigDataEnvironmentPostProcessor.java:147)
        at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.applyTo(ConfigDataEnvironmentPostProcessor.java:113)
        at org.springframework.modulith.core.ApplicationModuleDetectionStrategyLookup.getStrategy(ApplicationModuleDetectionStrategyLookup.java:86)
        at org.springframework.modulith.core.ApplicationModules.<init>(ApplicationModules.java:132)
        at org.springframework.modulith.core.ApplicationModules.<init>(ApplicationModules.java:96)
        at org.springframework.modulith.core.ApplicationModules.lambda$of$21(ApplicationModules.java:696)
        at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1724)
        at org.springframework.modulith.core.ApplicationModules.of(ApplicationModules.java:693)
        at org.springframework.modulith.core.ApplicationModules.of(ApplicationModules.java:234)
        at org.springframework.modulith.core.ApplicationModules.of(ApplicationModules.java:216)
        at org.springframework.modulith.runtime.autoconfigure.SpringModulithRuntimeAutoConfiguration$ApplicationModulesBootstrap.initializeApplicationModules(SpringModulithRuntimeAutoConfiguration.java:215)
        at org.springframework.modulith.runtime.autoconfigure.SpringModulithRuntimeAutoConfiguration$ApplicationModulesBootstrap.lambda$new$0(SpringModulithRuntimeAutoConfiguration.java:200)
        at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1789)

I tried:

• SPRING_CONFIG_ADDITIONAL_LOCATION
• SPRING_CONFIG_IMPORT
• SPRING_CONFIG_LOCATION

And none of them work.

Is this a bug? Or did i do something wrong?

[wilkinsona]

Thanks for the report and for trying the RC. Did this work with earlier version of Spring Boot, for example with 3.5.x?

I can see from the stack trace that the problem's being triggered by some code in Spring Modulith calling ConfigDataEnvironmentPostProcessor. That must be happening after Boot's successfully performed its own preparation of the environment so the question is why it's failing here when it succeeded earlier.

It appears to be happening on a thread managed by the fork-join pool and I suspect that's the cause. It could affect the config data location resolvers that are discovered and trigger that failure that you're seeing. If this theory's correct, the fix would have to be made in Spring Modulith to call one of the overloads of applyTo that takes a ResourceLoader.

/cc @odrotbohm

[sant1ago-da-hanoi]

Thanks for the report and for trying the RC. Did this work with earlier version of Spring Boot, for example with 3.5.x?

I can see from the stack trace that the problem's being triggered by some code in Spring Modulith calling ConfigDataEnvironmentPostProcessor. That must be happening after Boot's successfully performed its own preparation of the environment so the question is why it's failing here when it succeeded earlier.

It appears to be happening on a thread managed by the fork-join pool and I suspect that's the cause. I could affect the config data location resolvers that are discovered and trigger that failure that you're seeing. If this theory's correct, the fix would have to be made in Spring Modulith to call one of the overloads of applyTo that takes a ResourceLoader.

/cc @odrotbohm

It does mate, my project does work with SB 3.5.x, currently working with 3.5.5, I also tested with 3.4.1 and 3.5.7, they are all good.

[wilkinsona]

Please share a minimal sample that works with 3.5.7 and fails when upgraded to 4.0.0-RC1.

[odrotbohm]

I think I remember running into this issue, too, but I forgot what the exact context was.

@wilkinsona – Can you elaborate on what kind of ResourceLoader you'd expect to be handed in there? The calling code doesn't have any kind of context in which such an instance would already be present, as it might ultimately originate from a static method call in user code. In other words, we're trying to pick up configuration property values from any location that Boot would see if the application was executed. So, ultimately, the best I could hand in is a DefaultResourceLoader which the current method call ends up in anyway.

It appears to be happening on a thread managed by the fork-join pool and I suspect that's the cause. It could affect the config data location resolvers that are discovered and trigger that failure that you're seeing.

We obtain the executor we use to parallelize the bootstrap from ConfigurableBeanFactory.getBootstrapExecutor(). I had hoped that this would make us pick up all customizations made by the container.

[sant1ago-da-hanoi]

Please share a minimal sample that works with 3.5.7 and fails when upgraded to 4.0.0-RC1.

Everything is the same except the pom.xml which contains the version of Spring Boot, Spring Modulith, Spring Cloud...

[wilkinsona]

Everything is the same

The same as what? Sorry if I've missed something but I don't see a link to a sample that uses either 3.5.7 or 4.0.0-RC1.

[wilkinsona]

Can you elaborate on what kind of ResourceLoader you'd expect to be handed in there?

Given the current lack of sample, I'm only going on some educated guesses at the moment.

The log shows that the application is running as an uber jar so the application's classes and resources will have been loaded by Boot's LaunchedClassLoader. My working assumption is that we then end up using the system class loader when looking for spring.factories entries as that's the TCCL of the thread in the ForkJoin pool. If that's right, a ResourceLoader that's using the ClassLoader of ApplicationModuleDetectionStrategyLookup.

Let's pause for now until we have a sample that reproduces the problem and we can test the above theory.