简说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给加上，就不会有问题了