BootstrapConfigFileApplicationListener cant handle optional config locations

[larsgrefer]

Describe the bug

BootstrapConfigFileApplicationListener can't handle spring.config.additional-locations with optional: prefixes.

When setting spring.config.additional-location to optional:file:/foo or optional:/bar,

spring-cloud-commons/spring-cloud-context/src/main/java/org/springframework/cloud/bootstrap/BootstrapConfigFileApplicationListener.java

Lines 701 to 718 in 1a387e1

	private Set<String> getSearchLocations(String propertyName) {
	Set<String> locations = new LinkedHashSet<>();
	if (this.environment.containsProperty(propertyName)) {
	for (String path : asResolvedSet(this.environment.getProperty(propertyName), null)) {
	if (!path.contains("$")) {
	path = StringUtils.cleanPath(path);
	Assert.state(!path.startsWith(ResourcePatternResolver.CLASSPATH_ALL_URL_PREFIX),
	"Classpath wildcard patterns cannot be used as a search location");
	validateWildcardLocation(path);
	if (!ResourceUtils.isUrl(path)) {
	path = ResourceUtils.FILE_URL_PREFIX + path;
	}
	}
	locations.add(path);
	}
	}
	return locations;
	}

will turn these locations into file:optional:file:/foo and file:optional:/bar.

The following code will then decide that the Resource file:optional:file:/foo/application.properties does not exist, (while file:/foo/application.properties would exist)

spring-cloud-commons/spring-cloud-context/src/main/java/org/springframework/cloud/bootstrap/BootstrapConfigFileApplicationListener.java

Lines 501 to 508 in 1a387e1

	if (resource == null || !resource.exists()) {
	if (this.logger.isTraceEnabled()) {
	StringBuilder description = getDescription("Skipped missing config ", location, resource,
	profile);
	this.logger.trace(description);
	}
	continue;
	}

This can cause ordering issues between internal and external configuration files, depending on the execution order of BootstrapConfigFileApplicationListener and ConfigDataEnvironmentPostProcessor (so #1213 will hide this problem)

When BootstrapConfigFileApplicationListener runs first, we get this order:

1. external properties (not found by spring cloud because of this bug)
2. internal properties (found by BootstrapConfigFileApplicationListener)
3. external-properties (found by ConfigDataEnvironmentPostProcessor)
4. internal properties (found by ConfigDataEnvironmentPostProcessor)

When ConfigDataEnvironmentPostProcessor runs first, we get this order:

1. external-properties (found by ConfigDataEnvironmentPostProcessor)
2. internal properties (found by ConfigDataEnvironmentPostProcessor)
3. external properties (not found by spring cloud because of this bug)
4. internal properties (found by BootstrapConfigFileApplicationListener)

In the first case, the internal properites suddenly get precedence before the external ones.

[ryanjbaxter]

But since #1213 this should no longer matter correct?

[spring-cloud-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.

[larsgrefer]

@ryanjbaxter #1213 will hide this, yes

[ryanjbaxter]

After discussing this with the team we view #1213 as a fix for the issue so this can be closed