IoC 容器的初始化之 BeanDefinition 的 Re

之前我们大概了解 Spring 中关于 IoC 容器的设计与应用。接下来我们就要从源代码出发，详细了解 Spring IoC 容器的实现。

IoC 容器的初始化。

简单来说，IoC 容器的初始化是由前面的 refersh()方法来启动的，这个方法标志是 IoC 容器的正式启动。具体来说， IoC 容器的启动包括 BeanDefinition 的 Resource 资源定位、载入和注册三个基本过程，spring 中将这三个步骤完全解耦，便于我们可能的对着三个过程进行裁剪或扩展，定制自己的 IoC 容器初始化过程。
上一篇文章我们已经介绍过编程式使用 IoC 容器，里面就涉及到了 Resource 定位和载入过程接口的调用。在下面的内容中，我们将以 ApplicationContext 为例，详细分析这三个过程的实现。

• Resource 资源定位

  我们在上一文提到的编程式使用 DefaultListableBeanFactory，首先定义一个 Resouce 来定位容器使用的 BeanDefinition，这里使用的 ClassPathResouce，意味着 Spring 会在类路径中去寻找以文件形式存在的 BeanDefinition 信息。这里的 Resouce 并不能直接由 DefaultListableBeanFactory 使用，而是交由 BeanDefinitionReader 对这些信息进行处理。
  下面我们继续回到 FileSystemXMLApplication。

  • 首先来看一下该类的类结构图：
    FileSystemXMLApplication 类结构图
    从图中可以看到，通过继承 AbstractXmlApplicationContext，其已经具备了 ResourceLoader 读入 Resource 定义的 BeanDefinition 的能力。
  • 接着回到 FileSystemXMLApplication 源码中，其中最主要关注的就跟我们上一篇文章将的两个地方：

    public FileSystemXmlApplicationContext(String[] configLocations, boolean refresh, ApplicationContext parent)
            throws BeansException {
    
        super(parent);
        setConfigLocations(configLocations);
        if (refresh) {
            refresh();
        }
    }  
    
    @Override
    protected Resource getResourceByPath(String path) {
        if (path != null && path.startsWith("/")) {
            path = path.substring(1);
        }
        return new FileSystemResource(path);
    }
    

    • 首先我们可以看到构造方法中调用了 setConfiLocations(configLocations) 这个方法，不难猜想出其应该是在父类中实现了的设置 xml 路径的方法，那么既然有设置，必然就会有获取，我们可以到实现这个方法的父类 AbstractRefreshableConfigApplicationContext 里面看一下。
      AbstractRefreshableConfigApplicationContext 类
    • 果然如我们所猜想，里面有 getConfigLocations() 方法。该方法必然会在 IoC 容器初始化的过程中被调用，我们查找一下该方法被调用的地方。在 AbstractXmlApplicationContext 的 loadBeanDefinitions 方法里面：

      protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
          Resource[] configResources = getConfigResources();
          if (configResources != null) {
              reader.loadBeanDefinitions(configResources);
          }
          String[] configLocations = getConfigLocations();
          if (configLocations != null) {
              reader.loadBeanDefinitions(configLocations);
          }
      }
      

    • 到了这里我们发现了一点端倪，该方法调用之后的步骤，跟我们编程式使用 DefaultListableBeanFactory 一样，都是首先定义了一个 BeanDefinitionReader，这里使用的是 XmlBeanDefinitionReader，然后调用其 loadBeanDefinitions 方法进行处理。接下来我们就进入该方法里面看一下。其最终追踪到的实现代码如下：

      public int loadBeanDefinitions(String location, Set<Resource> actualResources) throws BeanDefinitionStoreException {
          ResourceLoader resourceLoader = getResourceLoader();
          if (resourceLoader == null) {
              throw new BeanDefinitionStoreException(
                      "Cannot import bean definitions from location [" + location + "]: no ResourceLoader available");
          }
      
          if (resourceLoader instanceof ResourcePatternResolver) {
              // Resource pattern matching available.
              try {
                  Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
                  int loadCount = loadBeanDefinitions(resources);
                  if (actualResources != null) {
                      for (Resource resource : resources) {
                          actualResources.add(resource);
                      }
                  }
                  if (logger.isDebugEnabled()) {
                      logger.debug("Loaded " + loadCount + " bean definitions from location pattern [" + location + "]");
                  }
                  return loadCount;
              }
              catch (IOException ex) {
                  throw new BeanDefinitionStoreException(
                          "Could not resolve bean definition resource pattern [" + location + "]", ex);
              }
          }
          else {
              // Can only load single resources by absolute URL.
              Resource resource = resourceLoader.getResource(location);
              int loadCount = loadBeanDefinitions(resource);
              if (actualResources != null) {
                  actualResources.add(resource);
              }
              if (logger.isDebugEnabled()) {
                  logger.debug("Loaded " + loadCount + " bean definitions from location [" + location + "]");
              }
              return loadCount;
          }
      }
      

    • 就跟我们前面说过的，ApplicationContext 扩展了 ResourcePatternResolver 接口，所以我们在上面的代码可以看到两种不同的 getResource 的方法，我们这里先忽略 ResourcePatternResolver 的实现方式，看一下通过 DefaulResouceLoader 的实现过程：

      public Resource getResource(String location) {
          Assert.notNull(location, "Location must not be null");
          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...
                  URL url = new URL(location);
                  return new UrlResource(url);
              }
              catch (MalformedURLException ex) {
                  // No URL -> resolve as resource path.
                  return getResourceByPath(location);
              }
          }
      }
      

    • 前面我们看到，getResourceByPath 方法会被我们的例子子类 FileSystemXmlApplicationContext 实现，这份方法返回的是一个 FileSystemResource 对象，通过这个对象，Spring 可以进行 I/O 的操作，完成 BeanDefinition 的定位。分析到这里已经一目了然了。它实现的就是对 path 进行解析，然后生成一个 FileSystemResource 对象并返回。
  • 如果是其他的 ApplicationContext，那么对生成其他种类的 Resource，比如 ClassPathResource、ServletContextResource 等。作为接口的 Resource 定义了许多与 I/O 操作，这些操作对后面的 BeanDefinition 提供了服务。关于 Resource 的种类，我们可以从其继承关系中看到：
    Resource 继承关系

  我们上面通过 FileSystemXmlApplicationContext 为例子了解了 Resource 定位过程。但是具体的 BeanDefinition 的数据还没有开始读入，这些数据的读入我们将在下一篇文章介绍的 BeanDefinition 的载入和解析来完成。