Application fails to start when an optional config import cannot be resolved

[ijusti]

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

[ijusti]

spring-cloud/spring-cloud-config#2170

[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.

[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.

[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.

[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.