曹工谈Spring Boot：Spring boot中怎么进行外部化配置，一不留神摔一跤；一路debug，原来是我太年轻了
背景
我们公司这边，目前都是spring boot项目，没有引入spring cloud config，也就是说，配置文件，还是放在resources下面的，为了区分多环境，是采用了profile这种方式，大致如下：
上面这里，就定义了3个profile，实际还不止这点，对应了3个环境。
每次启动的时候，只需要（省略无关 jvm 参数）：
java -Dspring.profiles.active=dev -jar xxx.jar
这样来指定要使用的profile即可。
然后每次发测试版本，我们这边就得加1个profile，所以导致我们工作量也是巨大，因为我们这边环境比较多，地址总变。后来，经过开发和测试那边的协调，变成了我们只管jar包，不管测试环境的维护。每次发版本，只发个jar包过去，配置文件里的地址，由测试同学自己配置。
大致变成了如下的样子：
-rw-r--r--. 1 root root 111978406 May 19 13:24 xxx.jar
drwxr-xr-x. 2 root root 120 May 20 13:25 config
[root@localhost cad]# ll config/
total 16
-rw-r--r--. 1 root root 498 May 20 13:31 application.properties
-rw-r--r--. 1 root root 601 May 20 13:31 application.yml
即，在jar包旁边，放上一个config目录，然后在config目录里，放我们的配置文件，至于配置文件里的各种配置，比如数据库ip、redis等等，就由测试同学自己配置了，这样呢，我们的工作量，大大减小。
看起来很棒了，然而，前一阵，测试同学发现一个问题，即，只能在和config同级目录下，执行java -jar，这种情况下，config里面的配置才生效，换个目录执行，config里面的配置就不生效了。
[root@localhost cad]# ll // 这里启动jar包，ok，没问题；换个目录执行，不行！
total 109356
-rw-r--r--. 1 root root 111978406 May 19 13:24 xxx.jar
drwxr-xr-x. 2 root root 120 May 20 13:25 config
还有这种事？我们看看到底怎么回事。
官方文档
24.3 Application Property Files
SpringApplicationloads properties fromapplication.propertiesfiles in the following locations and adds them to the SpringEnvironment:
- A
/configsubdirectory of the current directory- The current directory
- A classpath
/configpackage- The classpath root
这里说，SpringApplication加载application.properties配置文件,从如下位置：
- 当前目录的config子目录下
- 当前目录
- classpath下的config包
- classpath的根路径
我们这里，就是利用了第一点。但是，这个当前目录下的config目录，不是很清楚。当前目录，怎么才算当前目录，我在jar包同级目录算当前目录；换个目录用绝对路径，启动jar包，就不算当前目录了吗？
再往下翻一下看看。
Config locations are searched in reverse order. By default, the configured locations are
classpath:/,classpath:/config/,file:./,file:./config/. The resulting search order is the following:
file:./config/file:./classpath:/config/classpath:/
配置地址被以相反的顺序搜索，默认情况下，地址包括了：classpath:/,classpath:/config/,file:./,file:./config/，因此，被搜索的顺序如下：
file:./config/file:./classpath:/config/classpath:/
这里的第一项，file: ./config，应该就是我们目前的那种情况。
然后文档里，没提到我的问题，可能是太低级。。只能从源码找答案了。
源码分析
通过关键字查找，大致定位源码
我们直接用前面的关键字，搜索一波（记得把maven里设置为下载源码）
果然看到了一处地方：
org.springframework.boot.context.config.ConfigFileApplicationListener#DEFAULT_SEARCH_LOCATIONS
private static final String DEFAULT_SEARCH_LOCATIONS = "classpath:/,classpath:/config/,file:./,file:./config/";
查找这个变量被引用的地方：
org.springframework.boot.context.config.ConfigFileApplicationListener.Loader#getSearchLocations()
private Set<String> getSearchLocations() {
if (this.environment.containsProperty(CONFIG_LOCATION_PROPERTY)) {
return getSearchLocations(CONFIG_LOCATION_PROPERTY);
}
Set<String> locations = getSearchLocations(CONFIG_ADDITIONAL_LOCATION_PROPERTY);
// 1
locations.addAll(
asResolvedSet(ConfigFileApplicationListener.this.searchLocations, DEFAULT_SEARCH_LOCATIONS));
return locations;
}
这里1处，就用到了前面的DEFAULT_SEARCH_LOCATIONS。
接着看看，上面这个函数被调用的地方：
private void load(Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
// 1
getSearchLocations().forEach((location) -> {
boolean isFolder = location.endsWith("/");
Set<String> names = isFolder ? getSearchNames() : NO_SEARCH_NAMES;
// 2
names.forEach((name) -> load(location, name, profile, filterFactory, consumer));
});
}
这里的1处，就是前面的获取config location；这里1处，获取到了集合后，对其进行foreach处理。
2处，这里即会调用一个load函数，看名字就是加载，差不多可以猜到，是加载我们的那几个目录：
private static final String DEFAULT_SEARCH_LOCATIONS = "classpath:/,classpath:/config/,file:./,file:./config/";
好了，可以在这里打个断点，看看到底怎么加载，因为前面的file:./config/是一个相对路径，我们要看看，怎么被解析为绝对路径的。
断点debug，探求谜底
断点我们打在了load方法，运行项目，然后断点果然停在了我们想要的地方：
这个图就不多解释了，直接看圈出来的地方，我们接着要看下面的函数：
private void loadForFileExtension(PropertySourceLoader loader, String prefix, String fileExtension,
Profile profile, DocumentFilterFactory filterFactory, DocumentConsumer consumer) {
DocumentFilter defaultFilter = filterFactory.getDocumentFilter(null);
DocumentFilter profileFilter = filterFactory.getDocumentFilter(profile);
if (profile != null) {
// 1
...
}
//2 Also try the profile-specific section (if any) of the normal file
load(loader, prefix + fileExtension, profile, profileFilter, consumer);
}
- 1处，省略了profile相关内容，我们本次启动，没指定profile
- 2处，继续load
load处代码：
private void load(PropertySourceLoader loader, String location, Profile profile, DocumentFilter filter, DocumentConsumer consumer) {
// 1
Resource resource = this.resourceLoader.getResource(location);
// 2
if (resource == null || !resource.exists()) {
if (this.logger.isTraceEnabled()) {
StringBuilder description = getDescription("Skipped missing config ", location, resource, profile);
this.logger.trace(description);
}
return;
}
...
}
- 1处，将location转换为Resource，这里传入的location为：
file:./config/application.properties - 2处，判断resource是否存在
resourceLoader怎么getResource
这里的resourceLoader，为 org.springframework.core.io.DefaultResourceLoader。这个类，直接实现了org.springframework.core.io.ResourceLoader接口。
这个类，位于spring-core.jar中，基本是核心类了。
其注释写道：
* Default implementation of the {@link ResourceLoader} interface.
* Used by {@link ResourceEditor}, and serves as base class for
* {@link org.springframework.context.support.AbstractApplicationContext}.
* Can also be used standalone.
*
* <p>Will return a {@link UrlResource} if the location value is a URL,
* and a {@link ClassPathResource} if it is a non-URL path or a
* "classpath:" pseudo-URL.
大体翻译：
ResourceLoader接口的默认实现，被ResourceEditor使用，同时，是AbstractApplicationContext的基类。
也能被单独使用。
当传入的value，是一个URL，则封装为一个UrlResource并返回；
当传入的是一个非URL，或者是一个类似于"classpath："这样的，则返回一个ClassPathResource
对其的介绍到此打住。继续前面的代码：
@Override
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
...
// 1
if (location.startsWith("/")) {
return getResourceByPath(location);
} // 2
else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
}
else {
try {
// 3 Try to parse the location as a URL...
URL url = new URL(location);
return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
}
catch (MalformedURLException ex) {
// No URL -> resolve as resource path.
return getResourceByPath(location);
}
}
}
- 1，判断是否以
/开头 - 2，判断是否以classpath开头
- 3，作为参数，看看能不能 被解析为一个URL
然后3处这里，URL，是 jdk 的核心类，里面 debug 进去挺深的，直接执行完这一句之后，我们看看url这个参数的值：
总的来说，这里就是：你给一个字符串，URL按照它的格式，来解析为各个字段：比如，协议，host，port，query等等。但是，不代表这个URL就是可以访问的，如果是file，不代表这个文件就存在。这里只是按照URL的格式去解析而已。
我们继续下一句：
URL url = new URL(location);
// 1
return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
这里1处，判断是否为file，如果是，则会new一个FileUrlResource。
该类的类结构如下：
前面调用了new ,我们看看：
public FileUrlResource(URL url) {
super(url);
}
调用了父类：
/**
* Original URI, if available; used for URI and File access.
*/
@Nullable
private final URI uri;
/**
* Original URL, used for actual access.
*/
private final URL url;
/**
* Cleaned URL (with normalized path), used for comparisons.
*/
private final URL cleanedUrl;
public UrlResource(URL url) {
this.url = url;
this.cleanedUrl = getCleanedUrl(this.url, url.toString());
this.uri = null;
}
总的来说，就是利用你传入的URL，进行clean，然后保存到了cleanedUrl。
我们这里，经过clean后，
- clean后，cleanedUrl的值为：
file:config/application.properties - 原始的：
file:./config/application.properties
差别不大，主要是去掉了开头的./。
至此，我们的FileUrlResource就构造结束了，至此，我们完成了下面这行的解析。
Resource resource = this.resourceLoader.getResource(location);
判断resource是否存在
前面我们看到，FileUrlResource，继承了org.springframework.core.io.AbstractFileResolvingResource接口。
而我们这里调用：
resource.exists()
就会进入其父类的exists方法
org.springframework.core.io.AbstractFileResolvingResource#exists
public boolean exists() {
try {
// 1
URL url = getURL();
if (ResourceUtils.isFileURL(url)) {
//2 Proceed with file system resolution
return getFile().exists();
}
...
}
- 1，获取url
- 2，获取file
- 3，判断是否存在。
其中2处，继续：
@Override
public File getFile() throws IOException {
// 1
File file = this.file;
if (file != null) {
return file;
}
// 2
file = super.getFile();
// 3
this.file = file;
return file;
}
- 1，查询本地是否缓存
- 2，没缓存，则调用super类的getFile去获取
- 3，缓存。
继续进入2处，
org.springframework.core.io.UrlResource#getFile
public File getFile() throws IOException {
// 1
if (this.uri != null) {
return super.getFile(this.uri);
}
else {
// 2
return super.getFile();
}
}
- 1,我们这里uri是null，会进入2处
- 2，调用父类。
org.springframework.core.io.AbstractFileResolvingResource#getFile()
@Override
public File getFile() throws IOException {
// 1
URL url = getURL();
// 2
return ResourceUtils.getFile(url, getDescription());
}
- 1处，获取url
- 2处，获取file。
继续进入2处：
org.springframework.util.ResourceUtils#getFile(java.net.URL, java.lang.String)
public static File getFile(URL resourceUrl, String description) throws FileNotFoundException {
try {
// 1
return new File(toURI(resourceUrl).getSchemeSpecificPart());
}
catch (URISyntaxException ex) {
// Fallback for URLs that are not valid URIs (should hardly ever happen).
return new File(resourceUrl.getFile());
}
}
这里，传入的resourceURL，类型为URL, 在idea中显示为：
file:./config/application.properties
toURI,大家可以大致看下，
org.springframework.util.ResourceUtils#toURI(java.net.URL)
public static URI toURI(URL url) throws URISyntaxException {
return toURI(url.toString());
}
public static URI toURI(String location) throws URISyntaxException {
return new URI(StringUtils.replace(location, " ", "%20"));
}
上面干了啥，就是把路径里的" "换成了"%20"。然后new了一个URI。
URI、URL的差别简述
这两个东西，太学术了，简单理解，就是URI，指代的东西更多，包含的范围更广，URI表示中国的话，URL可能只能表示台湾省。（我他么一颗红心）
总的来说，uri 不一定可以访问，url基本是可以的。
参考：https://www.jianshu.com/p/81dfc203ab4a
最终是如何new file，判断file是否存在的
经过前面的步骤后，
return new File(toURI(resourceUrl).getSchemeSpecificPart());
我们获取了一个URI，然后调用其getSchemeSpecificPart，最终拿到一个String，其值为：
./config/application.properties
然后传入了 File，用于构造一个file。
然后接着调用
java.io.File#exists
public boolean exists() {
// 1
return ((fs.getBooleanAttributes(this) & FileSystem.BA_EXISTS) != 0);
}
然后这里，1处调用了一个native方法：
java.io.WinNTFileSystem#getBooleanAttributes
public native int getBooleanAttributes(File f);
都到native方法了，没法继续了。
但是，最终呢，我们知道，现在的问题，变成了：
File file = new file("./config/application.properties");
file.exists();
new file，传入相对路径，这个相对路径，到底相对于哪里
经过我一番探索，最终写了下面这个测试类，注意，该类使用默认包：
public class Test {
public static void main(String[] args) throws IOException{
// 1
File file = new File("a.txt");
// 2
if (file.exists()) {
System.out.println("file exists.path:" + file.getAbsolutePath());
} else {
// 3
boolean newFile = file.createNewFile();
if (newFile) {
System.out.println("create new file");
} else {
System.out.println("create failed. file exists.path:" + file.getAbsolutePath());
}
}
}
}
- 1，new file，使用了相对路径，即当前路径，模拟之前我们的问题
- 2，判断是否存在
- 3，如果不存在，创建文件。
idea中执行
我目前的idea中，project路径为：
F:\workproject_codes\xxxx
第一次执行，结果：
create new file
说明文件不存在，进行了文件创建。然后我用everything搜索了下该文件，发现：
就在我的project路径下。
然后我在想，为啥会创建到这个地方去？
然后我加了一段代码：
Properties properties = System.getProperties();
for (Map.Entry<Object, Object> entry : properties.entrySet()) {
System.out.println(entry.getKey() + ", " + entry.getValue());
}
发现打印出来的properties中，有一个属性：
user.dir, F:\workproject_codes\saltillo
说明这个地址，就是user.dir搞出来的。
在idea中，user.dir，就是project的路径。
直接和class同级目录下，java执行class
直接执行那个class文件，我放到了centos下的/home/test目录下：
[root@localhost test]# ll
-rw-r--r--. 1 root root 2013 May 20 13:40 Test.class
[root@localhost test]# java Test
这种情况下，创建的file，就是这个目录下。
而且，看了下user.dir,就是当前目录：
[root@localhost test]# java Test|grep user.dir
user.dir, /home/test
和class不在同级目录下，java执行class
切换到上层目录，即home下：
[root@localhost home]# pwd
/home
[root@localhost home]# java -cp test/ Test |grep user.dir
user.dir, /home
...会在本目录下生产a.txt，删除后再次执行：
[root@localhost home]# java -cp test/ Test |grep create
create new file result
看上面，此时的user.dir，就变成了/home目录。
同时，创建了新的文件a.txt，就在当前home目录下。
打成spring boot jar后，在centos运行，结果如何
在spring boot jar包里的main，注释了原来的启动代码，我加了这段代码：
@SpringBootApplication
@EnableTransactionManagement
@EnableAspectJAutoProxy(exposeProxy = true)
@EnableFeignClients
//@Slf4j
@Controller
@EnableScheduling
public class xxx {
private static Logger log= null;
static {
public static void main(String[] args) throws IOException {
Properties properties = System.getProperties();
for (Map.Entry<Object, Object> entry : properties.entrySet()) {
System.out.println(entry.getKey() + ", " + entry.getValue());
}
File file = new File("a.txt");
if (file.exists()) {
System.out.println("file exists.path:" + file.getAbsolutePath());
} else {
boolean newFile = file.createNewFile();
if (newFile) {
System.out.println("create new file");
} else {
System.out.println("create failed. file exists.path:" + file.getAbsolutePath());
}
}
// new SpringApplicationBuilder(xxx.class).web(WebApplicationType.SERVLET).run(args);
}
}
在/root/tt下运行，用java -jar xxx.jar运行后，
user.dir, /root/tt
...
create new file
然后，果然，在/root/tt下，就建了一个a.txt文件。
[root@localhost tt]# ll
total 109412
-rw-r--r--. 1 root root 0 May 20 16:41 a.txt
-rw-r--r--. 1 root root 112035602 May 20 16:40 xxx.jar
[root@localhost tt]# pwd
/root/tt
user.dir是个什么东西
为此，我专门把那个class，拷贝到了root目录下，执行：
[root@localhost ~]# java Test |grep user.dir
user.dir, /root
这，看起来，在哪里运行java，user.dir就是哪儿啊，类似于pwd了。
大家如果直接去网上搜user.dir，基本都是很混乱，各说各的，大家按照上面这样实践下就知道了。
总结
我们已经找到了问题原因了，总的来说，就是spring boot外部化配置时，
file:./config/
这个路径，相对路径，相对的是user.dir。
而user.dir怎么来，就是你在哪个目录下执行java，哪个目录就是user.dir。
题目中这个问题怎么解决，可以直接在java -jar xxx.jar中，加一个参数（注意，这里config是一个目录，注意最后要加一个/）：
java -jar -Dspring.config.location=file:///home/xxx/config/ springbootrestdemo-0.0.1-SNAPSHOT.jar
可参考：
https://www.cnblogs.com/xiaoqi/p/6955288.html
我这边的操作系统，pc是win7，centos是：
[root@localhost tt]# cat /etc/centos-release
CentOS Linux release 7.6.1810 (Core)
ps：经过实测后，发现如果在logback中指定相对路径的话，
<appender name="FILE"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>logs/${APP_NAME}.log</File>
这里的相对路径，也是基于前面的user.dir的。
谢谢大家。
可参考：
https://www.jianshu.com/p/982d8759edde
最新文章
- 前端少侠的ps故事
- setNeedsDisplay，setNeedsLayout
- [转]C#在创建完项目后如何重命名项目名称。
- 矿场搭建（codevs 1996）
- Head First 设计模式系列之一----模板模式（java版）
- 240多个jQuery插件
- eclipse代码注释的设置
- [置顶] NS2中TCP拥塞控制仿真过程中盲点解析
- 消息队列（Message Queue）基本概念（转）
- deepinmind(转)
- iOS学习 plist读取和写入文件
- Java中实现短信发送
- jdk 1.8 开发环境配置
- [BZOJ]1052 覆盖问题(HAOI2007)
- IntelliJ IDEA重启Tomcat
- 对tomcat7模拟并发请求及相关配置参数的含义
- windows环境安装weblogic服务【转】【补】
- 总结几个常用的系统安全设置（含DenyHosts）
- nRF52832-GPIOTE部分
- Java中static关键字概述