Maintain classpath order in PropertiesLauncher

I think this is safe, judging by the integration tests, but I'm not
putting it in 1.2.x until we've had some feedback on it. The
integration tests actually had a bug that was masking this problem
because they were merging Properties from the whole classpath instead
of picking the first available resource (which is generally what
we do in Spring Boot applications for application.properties for
instance).

Fixes gh-3048
This commit is contained in:
Dave Syer
2015-07-14 10:19:47 +01:00
parent a158baf50f
commit bfa816f2a3
6 changed files with 18 additions and 8 deletions

View File

@@ -17,12 +17,13 @@
package org.springframework.boot.load.it.props;
import java.io.IOException;
import java.util.Properties;
import javax.annotation.PostConstruct;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.io.support.PropertiesLoaderUtils;
import org.springframework.core.io.ClassPathResource;
/**
* Spring configuration.
@@ -37,7 +38,9 @@ public class SpringConfiguration {
@PostConstruct
public void init() throws IOException {
String value = PropertiesLoaderUtils.loadAllProperties("application.properties").getProperty("message");
Properties props = new Properties();
props.load(new ClassPathResource("application.properties").getInputStream());
String value = props.getProperty("message");
if (value!=null) {
this.message = value;
}

View File

@@ -26,7 +26,6 @@ assert out.contains('Hello Embedded Foo!'),
'With loader.path=.,lib should use the application.properties from the local filesystem\n' + out
new File("${basedir}/target/application.properties").withWriter { it -> it << "message: Spam" }
out = exec("java -Dloader.path=target,.,lib -jar ${jarfile}")
assert out.contains('Hello Embedded Spam!'),
'With loader.path=target,.,lib should use the application.properties from the target directory\n' + out