简说Spring中的资源加载
声明： 本文若有 任何纰漏、错误，请不吝指正！谢谢！
问题描述
遇到一个关于资源加载的问题，因此简单的记录一下，对Spring资源加载也做一个记录。
问题起因是使用了@PropertySource来进行配置文件加载，配置路径时，没有使用关键字classpath来指明从classpath下面来查找配置文件。具体配置如下
@PropertySource("config/application-download.yml", factory=YamlPropertySourceFactory)
这种方式在启动应用时，是没问题的，正常。但是在build时，跑单元测试，出了问题，说无法从ServletContext中找到/config/application-download.yml，然后加上了classpath，再跑了下就没错误了。
于是找到了处理@PropertySource的位置，跟踪代码找到了差异的原因。
源码解释
Spring对于资源，做了一个抽象，那就是Resource，资源的加载使用资源加载器来进行加载，ResourceLoader就是这样一个接口，用于定义对资源的加载行为的。
Spring中几乎所有的ApplicationContext都实现了它，应用十分的广泛。
除了各个ApplicationContext实现了它，它还有个可以独立使用的实现，也就是一会要提到的。
DefaultResourceLoader
这个实现类，是一个在框架外部独立使用版本，一般默认的都不简单 ，这个也不例外。
无论从哪里加载资源，使用DefaultResourceLoader来加载就行了
// org.springframework.core.io.DefaultResourceLoader#getResource
@Override
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
// 这个是提供的SPI使用的，没有采用子类实现的方式
for (ProtocolResolver protocolResolver : getProtocolResolvers()) {
Resource resource = protocolResolver.resolve(location, this);
if (resource != null) {
return resource;
}
}
// 如果以/开头，使用纯路径的方式，比如./config.properties
if (location.startsWith("/")) {
return getResourceByPath(location);
}
// 如果以classpath:开头，创建一个ClassPathResource资源对象
// 底层使用的是Class#getResourceAsStream,ClassLoader#getResourceAsStream
// 或者 ClassLoader#getSystemResourceAsStream，具体有机会再详细解释下这些
else if (location.startsWith(CLASSPATH_URL_PREFIX)) {
return new ClassPathResource(location.substring(CLASSPATH_URL_PREFIX.length()), getClassLoader());
}
else {
try {
// Try to parse the location as a URL...
// 如果上面的判断不满足，直接使用java.net.URL来生成一个URL对象，
// 如果location为null，或者location没有指定协议，或者协议不能被识别
// 就会抛出异常
URL url = new URL(location);
//file:开头的 会使用创建一个FileUrlResource
return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
}
catch (MalformedURLException ex) {
// 没有指定协议
return getResourceByPath(location);
}
}
}
protected Resource getResourceByPath(String path) {
// ClassPathResource的子类
return new ClassPathContextResource(path, getClassLoader());
}
这个类在Spring中被广泛使用，或者更具体的说，这个类的getResource方法，几乎遇到资源相关的加载动作都会调用到它。
各个ApplicationContext应该是加载资源最多的地方了，而AbstractApplicationContext正是继承了DefaultResourceLoader，才有了这中加载资源的能力。
不过DefaultResourceLoader也留给了子类的扩展点，主要是通过重写getResourceByPath这个方法。这里是继承的方式，也可以重写 getResource方法，这个方法在GenericApplicationContext中被重写了， 不过也没有做过多的操作，这里主要是可以在一个context中设置自己的资源加载器，一旦设置了，会将 ApplicationContext中所有的资源委托给它加载，一般不会有这个操作 。
遇到的问题 ，正是因为子类对 getResourceByPath的重写 ，导致了不一样的行为。
经过跟踪源码发现，正常启动应用的时候，实例化的是一个 AnnotationConfigServletWebServerApplicationContext实例 ，这个类继承自ServletWebServerApplicationContext，在ServletWebServerApplicationContext中重写了getResourceByPath
// org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext#getResourceByPath
@Override
protected Resource getResourceByPath(String path) {
if (getServletContext() == null) {
// ServletContext为null，从classpath去查找
return new ClassPathContextResource(path, getClassLoader());
}
// 否则从ServletContext去查找
return new ServletContextResource(getServletContext(), path);
}
而通过 Debug发现，在使用SpirngBootTest执行单元测试，它实例化的是org.springframework.web.context.support.GenericWebApplicationContext
/**
* This implementation supports file paths beneath the root of the ServletContext.
* @see ServletContextResource
* 这里就是直接从ServletContext中去查找资源，一般就是webapp目录下。
*/
@Override
protected Resource getResourceByPath(String path) {
Assert.state(this.servletContext != null, "No ServletContext available");
return new ServletContextResource(this.servletContext, path);
}
并且这里ServletContext不为null，SpringBootTest实例化一个SpringBootMockServletContext对象。
而正常情况下，在处理@PropertySource时，还没能初始化一个ServletContext，因为 @PropertySource的处理是在BeanDefinitionRegistryPostProcessor执行时处理的，早于SpringBoot去初始化Servlet容器。SpringBoot创建Servlet容器是在这里org.springframework.boot.web.servlet.context.ServletWebServerApplicationContext#onRefresh，它的执行时机是晚于处理 BeanFactoryPostProcessor的org.springframework.context.support.AbstractApplicationContext#invokeBeanFactoryPostProcessors，所以 正常运行应用，肯定只会创建一个ClassPathContextResource资源对象，而配置文件在classpath下是存在的，所以可以搜索到。
结论
结论就是不知道SpringBootTest是故意为之呢还是出于什么别的考虑，也不知道除了加上classpath前缀外是否有别的方式能解决这个问题。
不过现在看来，偷懒是不可能的呢了 ，老老实实的 把前缀classpath给加上，就不会有问题了
