Spring Boot 3.0.6 Spring Cloud 2022.0.2 OpenJDK Runtime Environment GraalVM CE 22.3.1 (build 17.0.6+10-jvmci-22.3-b13)

I have a Spring Cloud Config setup:

spring.config:
    import: 'optional:configserver:'

when I run native image with disabled cloud config. application failed

--spring.cloud.config.enabled=false 

19:05:49.237 [main] ERROR org.springframework.boot.SpringApplication -- Application run failed
java.lang.IllegalStateException: Unable to load config data from 'optional:configserver:'
    at org.springframework.boot.context.config.StandardConfigDataLocationResolver.getReferences(StandardConfigDataLocationResolver.java:143)
    at org.springframework.boot.context.config.StandardConfigDataLocationResolver.getReferences(StandardConfigDataLocationResolver.java:128)
    at org.springframework.boot.context.config.StandardConfigDataLocationResolver.resolve(StandardConfigDataLocationResolver.java:121)
    at org.springframework.boot.context.config.ConfigDataLocationResolvers.lambda$resolve$1(ConfigDataLocationResolvers.java:102)
    at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:113)
    at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:102)
    at org.springframework.boot.context.config.ConfigDataLocationResolvers.resolve(ConfigDataLocationResolvers.java:94)
    at org.springframework.boot.context.config.ConfigDataImporter.resolve(ConfigDataImporter.java:106)
    at org.springframework.boot.context.config.ConfigDataImporter.resolve(ConfigDataImporter.java:98)
    at org.springframework.boot.context.config.ConfigDataImporter.resolveAndLoad(ConfigDataImporter.java:86)
    at org.springframework.boot.context.config.ConfigDataEnvironmentContributors.withProcessedImports(ConfigDataEnvironmentContributors.java:115)
    at org.springframework.boot.context.config.ConfigDataEnvironment.processInitial(ConfigDataEnvironment.java:242)
    at org.springframework.boot.context.config.ConfigDataEnvironment.processAndApply(ConfigDataEnvironment.java:229)
    at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:96)
    at org.springframework.boot.context.config.ConfigDataEnvironmentPostProcessor.postProcessEnvironment(ConfigDataEnvironmentPostProcessor.java:89)
    at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEnvironmentPreparedEvent(EnvironmentPostProcessorApplicationListener.java:109)
    at org.springframework.boot.env.EnvironmentPostProcessorApplicationListener.onApplicationEvent(EnvironmentPostProcessorApplicationListener.java:94)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.doInvokeListener(SimpleApplicationEventMulticaster.java:176)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.invokeListener(SimpleApplicationEventMulticaster.java:169)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:143)
    at org.springframework.context.event.SimpleApplicationEventMulticaster.multicastEvent(SimpleApplicationEventMulticaster.java:131)
    at org.springframework.boot.context.event.EventPublishingRunListener.multicastInitialEvent(EventPublishingRunListener.java:136)
    at org.springframework.boot.context.event.EventPublishingRunListener.environmentPrepared(EventPublishingRunListener.java:81)
    at org.springframework.boot.SpringApplicationRunListeners.lambda$environmentPrepared$2(SpringApplicationRunListeners.java:64)
    at java.base@17.0.6/java.lang.Iterable.forEach(Iterable.java:75)
    at org.springframework.boot.SpringApplicationRunListeners.doWithListeners(SpringApplicationRunListeners.java:118)
    at org.springframework.boot.SpringApplicationRunListeners.doWithListeners(SpringApplicationRunListeners.java:112)
    at org.springframework.boot.SpringApplicationRunListeners.environmentPrepared(SpringApplicationRunListeners.java:63)
    at org.springframework.boot.SpringApplication.prepareEnvironment(SpringApplication.java:354)
    at org.springframework.boot.SpringApplication.run(SpringApplication.java:305)
    at com.playtika.services.samples.PlayWebApplication.main(PlayWebApplication.java:20)
Caused by: java.lang.IllegalStateException: File extension is not known to any PropertySourceLoader. If the location is meant to reference a directory, it must end in '/' or File.separator
    at org.springframework.boot.context.config.StandardConfigDataLocationResolver.getReferencesForFile(StandardConfigDataLocationResolver.java:231)
    at org.springframework.boot.context.config.StandardConfigDataLocationResolver.getReferences(StandardConfigDataLocationResolver.java:140)
    ... 30 common frames omitted

Comment From: ijusti

https://github.com/spring-cloud/spring-cloud-config/issues/2170

Comment From: wilkinsona

Thanks for the report, I don't think this is related to Graal and native images as the same failure occurs on the JVM. It also occurs with Spring Boot 2.7.x and Spring Cloud 2021.0.x.

The problem can also be reproduced without Spring Cloud using something like spring.config.import: optional:whatever:. I don't think an unresolvable optional import should cause the application to fail to start.

Comment From: philwebb

I think the current behavior is intentional and designed to prevent misconfiguration. With or without the optional: prefix, Spring Boot expects to be able to find a ConfigDataLocationResolver that can resolve a String into a ConfigDataResource. As it stands, optional: is designed to allow a resolved location to not actually contribute anything.

Comment From: wilkinsona

I think the current behavior is intentional and designed to prevent misconfiguration.

That feels like quite a subtle distinction to me as you'll get different behavior with an optional import depending on where the misconfiguration has been made.

Say you have a ConfigDataLocationResolver that handles example and it can import something at some-path:

  1. spring.config.import = optional:example:some-path will import the data
  2. spring.config.import = optional:example:some-pth will silently import nothing
  3. spring.config.import = optional:exmple:some-path will fail

The difference between 2 and 3 is really subtle and whether or not the optional behavior applies depends on where you made the typo. I think it would be better if optional applied consistently to everything that comes after it.

Comment From: philwebb

With options 1 and 2 we find a ConfigDataLocationResolver and it's up to that instance to determine if some-path or some-pth actually exist. With option 3 we know that there's no possible way to resolve the location unless the classpath changes.

I guess it's possible that someone may by trying to share configuration and one app might have a ConfigDataLocationResolver and another might not. Perhaps that's a strong enough argument in making things consistent. We can add some debug logging to help if folks want to track down why something wasn't imported.

I'm still not sure if we should classify this as a bug or not and which version we should target for the change.

Comment From: bhavesh-bhatt-tech

This issue is happening with spring boot 3.2 as well. This happens specially when applying docker-compose up command, the eureka-client is unable to detect the config server even after replacing the localhost with service name. Tried all combinations.

spring.config.import = http://config-server:8088 OR spring.config.import = http://localhost:8088 OR spring.config.import = http://${HOSTNAME}:8088

Comment From: mhalbritter

If you think there is a bug, please open a new issue, and please attach a sample project with which we can reproduce this issue. Thanks!