1.我们重点看看AbstractRefreshableApplicationContext的refreshBeanFactory方法的实现，这个refreshBeanFactory被FileSystemXmlApplicationContext构造函数中的refresh调用。在这个方法中，通过createBeanFactory构建了一个IoC容器供ApplicationContext使用。这个IoC容器就是我们前面提到过的DefaultListableBeanFactory，同时，它启动了loadBeanDefinitions来载入BeanDefinition，这个过程和前面以编程的方式来使用IoC容器（XmlBeanFacoty）的过程非常类似。
protected final void refreshBeanFactory() throws BeansException {
// 这里判断，如果已经建立了BeanFactory，则销毁并关闭该BeanFactory
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
// 这里是创建并设置持有的DefaultListableBeanFactory的地方
// 同时调用loadBeanDefinitions载入BeanDefinition的信息
try {
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
customizeBeanFactory(beanFactory);
loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}
AbstractRefreshableApplicationContext对容器的初始化
// 这就是在上下文中创建DefaultListableBeanFactory的地方，而getInternalParentBeanFacoty()
// 的具体实现可以
// 查看AbstractApplicationContext中的实现，会根据容器已有的双亲IoC容器的信息来生成
// DefaultListableBeanFactory的双亲IoC容器
protected DefaultListableBeanFactory createBeanFactory() {
return new DefaultListableBeanFactory(getInternalParentBeanFactory());
}
createBeanFactory
// 这里是使用BeanDefinitionReader载入Bean定义的地方，因为允许有多种载入方式，虽然用得
// 最多的事XML定义的形式，这里通过一个抽象函数把具体的实现委托给子类来完成
protected abstract void loadBeanDefinitions(DefaultListableBeanFactory beanFactory)
throws BeansException, IOException;
loadBeanDefinitions
// 对于取得Resource的具体过程，我们可以看看DefaultResourceLoader是怎样完成的
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null");
//
if (location.startsWith("/")) {
return getResourceByPath(location);
}
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...
URL url = new URL(location);
return new UrlResource(url);
}
catch (MalformedURLException ex) {
// No URL -> resolve as resource path.
return getResourceByPath(location);
}
}
}
getResource
2.前面我们看到的getResourceByPath会被子类FileSystemXmlApplicationContext实现，这个方法返回的是一个FileSystemResource对象，通过这个对象，Spring可以进行相关的I/O操作，完成BeanDefinition的定位。分析到这里已经一目了然，它实现的就是对path进行解析，然后生成一个FileSystemResource对象并返回，代码清单如下所示。
protected Resource getResourceByPath(String path) {
if (path != null && path.startsWith("/")) {
path = path.substring(1);
}
return new FileSystemResource(path);
}
FileSystemXmlApplicationContext生成FileSystemResource对象
3.如果是其他的ApplicationContext，那么会对应生成其他种类的Resource，比如ClassPathResource、ServletContextResource等。
4.关于Spring中Resource的种类，可以在图1的Resource类的继承关系中了解。作为接口Resource定义了许多与I/O相关的操作，这些操作也都可以从图1种的Resource的接口定义中看到。这些接口对不同的Resource实现代表着不同的意义，是Resource的实现需要考虑的。Resource接口的实现在Spring中的设计如图1所示。
图1 Resource的定义和继承关系
5.从图1中我们可以看到Resource的定位和它的继承关系，通过对前面的实现原理的分析，我们以FileSystemXmlApplicationContext的实现为例子，了解Resource定位问题的解决方案，即以FileSystem方式存在的Resource的定位实现。
6.在BeanDefinition定位完成的基础上，就可以通过返回的Resource对象来进行BeanDefinition的载入了。
7.在定位过程完成以后，为BeanDefinition的载入创造了I/O操作的条件，但是具体的数据还没有开始读入。这些数据的读入将在下面的BeanDefinition的载入和解析中来完成。
8.任然以水桶为例子，这里就像用水桶去打水，要先找到水源。这里完成对Resource的定位，就类似于水源已经找到了，下面就是打水的过程了，类似于把找到的水装到水桶里的过程。找水不简单，但是与打水相比，我们发现打水更需要技巧。