spring 容器的基础 XmlBeanFactory

时间:2022-04-19 12:12:36

1、BeanFactory

  Spring Bean 的创建是典型的工厂模式,这一系列的Bean 工厂,也即IOC 容器为开发者管理对象间的依赖关系提供了很多便利和基础服务,在Spring 中有许多的IOC 容器的实现供用户选择和使用,其相互关系如下:

spring 容器的基础 XmlBeanFactory

  其中BeanFactory 作为最顶层的一个接口类,它定义了IOC 容器的基本功能规范,BeanFactory 有三个重要的子类:ListableBeanFactory、HierarchicalBeanFactory 和AutowireCapableBeanFactory。但是从类图中我们可以发现最终的默认实现类是DefaultListableBeanFactory,它实现了所有的接口。那为何要定义这么多层次的接口呢?查阅这些接口的源码和说明发现,每个接口都有它使用的场合,它主要是为了区分在Spring 内部在操作过程中对象的传递和转化过程时,对对象的数据访问所做的限制。例如ListableBeanFactory 接口表示这些Bean 是可列表化的,而HierarchicalBeanFactory 表示的是这些Bean 是有继承关系的,也就是每个Bean 有可能有父Bean。AutowireCapableBeanFactory 接口定义Bean 的自动装配规则。这三个接口共同定义了Bean 的集合、Bean 之间的关系、以及Bean 行为

  在BeanFactory 里只对IOC 容器的基本行为作了定义,根本不关心你的Bean 是如何定义怎样加载的。正如我们只关心工厂里得到什么的产品对象,至于工厂是怎么生产这些对象的,这个基本的接口不关心。而要知道工厂是如何产生对象的,我们需要看具体的IOC 容器实现,Spring 提供了许多IOC 容器的实现。比如GenericApplicationContext , ClasspathXmlApplicationContext 等。ApplicationContext 是Spring 提供的一个高级的IOC 容器,它除了能够提供IOC 容器的基本功能外,还为用户提供了以下的附加服务。从ApplicationContext 接口的实现,我们看出其特点:

1、支持信息源,可以实现国际化。(实现MessageSource 接口)
2、访问资源。(实现ResourcePatternResolver 接口,后面章节会讲到)
3、支持应用事件。(实现ApplicationEventPublisher 接口)

2、BeanDefinition

  SpringIOC 容器管理了我们定义的各种Bean 对象及其相互的关系,Bean 对象在Spring 实现中是以BeanDefinition 来描述的,其继承体系如下:

spring 容器的基础 XmlBeanFactory

3、BeanDefinitionReader

  Bean 的解析过程非常复杂,功能被分的很细,因为这里需要被扩展的地方很多,必须保证有足够的灵活性,以应对可能的变化。Bean 的解析主要就是对Spring 配置文件的解析。这个解析过程主要通过BeanDefintionReader 来完成,最后看看Spring 中BeanDefintionReader 的类结构图:

spring 容器的基础 XmlBeanFactory

  在XmlBeanDefinitionReader中主要包含以下几步的处理:

(1):通过继承AbstractBeanDefinitionReader中的方法,来使用ResourceLoader将资源文件路劲转换为对应的Resource文件。

(2):通过DocumentLoader对Resource文件进行转换,将Resource文件转换为Document文件。

(3):通过实现接口BeanDefinitionDocumentReader的DefaultBeanDefinitionDocumentReader类对 Document 进行解析,并使用BeanDefinitionParserDelegate对Element进行解析。

基于Xml 的IOC 容器的初始化

  IOC 容器的初始化包括BeanDefinition 的Resource 定位、加载和注册这三个基本的过程。我们以ApplicationContext 为例讲解,ApplicationContext 系列容器也许是我们最熟悉的,因为Web 项目中使用的XmlWebApplicationContext 就属于这个继承体系,还有ClasspathXmlApplicationContext等,其继承体系如下图所示:

spring 容器的基础 XmlBeanFactory

  ApplicationContext 允许上下文嵌套,通过保持父上下文可以维持一个上下文体系。对于Bean 的查找可以在这个上下文体系中发生,首先检查当前上下文,其次是父上下文,逐级向上,这样为不同的Spring应用提供了一个共享的Bean 定义环境。

1、寻找入口

  还有一个我们用的比较多的ClassPathXmlApplicationContext,通过main()方法启动:

//1.
ApplicationContext app = new ClassPathXmlApplicationContext("application.xml");
//2.
public ClassPathXmlApplicationContext(String configLocation) throws BeansException {
this(new String[] {configLocation}, true, null);
}
//3.
public ClassPathXmlApplicationContext(
String[] configLocations, boolean refresh, @Nullable ApplicationContext parent)
throws BeansException { super(parent);
setConfigLocations(configLocations);
if (refresh) {
refresh();
}
}

  还有像AnnotationConfigApplicationContext 、FileSystemXmlApplicationContext 、XmlWebApplicationContext 等都继承自父容器AbstractApplicationContext 主要用到了装饰器模式和策略模式,最终都是调用refresh()方法。

2、获得配置路径

  通过分析ClassPathXmlApplicationContext 的源代码可以知道, 在创建ClassPathXmlApplicationContext 容器时,构造方法做以下两项重要工作:首先,调用父类容器的构造方法(super(parent)方法)为容器设置好Bean 资源加载器。然后, 再调用父类AbstractRefreshableConfigApplicationContext 的setConfigLocations(configLocations)方法设置Bean 配置信息的定位路径。通过追踪ClassPathXmlApplicationContext 的继承体系, 发现其父类的父类AbstractApplicationContext 中初始化IOC 容器所做的主要源码如下:

public abstract class AbstractApplicationContext extends DefaultResourceLoader
implements ConfigurableApplicationContext {
//静态初始化块,在整个容器创建过程中只执行一次
static {
//为了避免应用程序在Weblogic8.1 关闭时出现类加载异常加载问题,加载IOC 容
//器关闭事件(ContextClosedEvent)类
ContextClosedEvent.class.getName();
}
public AbstractApplicationContext() {
this.resourcePatternResolver = getResourcePatternResolver();
}
public AbstractApplicationContext(@Nullable ApplicationContext parent) {
this();
setParent(parent);
}
//获取一个Spring Source 的加载器用于读入Spring Bean 配置信息
protected ResourcePatternResolver getResourcePatternResolver() {
//AbstractApplicationContext 继承DefaultResourceLoader,因此也是一个资源加载器
//Spring 资源加载器,其getResource(String location)方法用于载入资源
return new PathMatchingResourcePatternResolver(this);
}
...
}

  AbstractApplicationContext 的默认构造方法中有调用PathMatchingResourcePatternResolver 的构造方法创建Spring 资源加载器:

public PathMatchingResourcePatternResolver(ResourceLoader resourceLoader) {
Assert.notNull(resourceLoader, "ResourceLoader must not be null");
//设置Spring 的资源加载器
this.resourceLoader = resourceLoader;
}

  在设置容器的资源加载器之后,接下来ClassPathXmlApplicationContext 执行setConfigLocations()方法通过调用其父类AbstractRefreshableConfigApplicationContext 的方法进行对Bean 配置信息的定位,该方法的源码如下:

public void setConfigLocations(@Nullable String... locations) {
if (locations != null) {
Assert.noNullElements(locations, "Config locations must not be null");
this.configLocations = new String[locations.length];
for (int i = ; i < locations.length; i++) {
this.configLocations[i] = resolvePath(locations[i]).trim();
}
}
else {
this.configLocations = null;
}
}

  通过这两个方法的源码我们可以看出,我们既可以使用一个字符串来配置多个Spring Bean 配置信息,也可以使用字符串数组,即下面两种方式都是可以的:

ClassPathResource res = new ClassPathResource("a.xml,b.xml");
//多个资源文件路径之间可以是用” , ; \t\n”等分隔。
ClassPathResource res =new ClassPathResource(new String[]{"a.xml","b.xml"});

  至此,SpringIOC 容器在初始化时将配置的Bean 配置信息定位为Spring 封装的Resource。

3、开始启动

  SpringIOC 容器对Bean 配置资源的载入是从refresh()函数开始的,refresh()是一个模板方法,规定了IOC 容器的启动流程, 有些逻辑要交给其子类去实现。它对Bean 配置资源进行载入ClassPathXmlApplicationContext 通过调用其父类AbstractApplicationContext 的refresh()函数启动整个IOC 容器对Bean 定义的载入过程,现在我们来详细看看refresh()中的逻辑处理:

@Override
public void refresh() throws BeansException, IllegalStateException {
synchronized (this.startupShutdownMonitor) {
// Prepare this context for refreshing.
//1、调用容器准备刷新的方法,获取容器的当时时间,同时给容器设置同步标识
prepareRefresh();
// Tell the subclass to refresh the internal bean factory.
//2、告诉子类启动refreshBeanFactory()方法,Bean 定义资源文件的载入从
//子类的refreshBeanFactory()方法启动
ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();
// Prepare the bean factory for use in this context.
//3、为BeanFactory 配置容器特性,例如类加载器、事件处理器等
prepareBeanFactory(beanFactory);
try {
// Allows post-processing of the bean factory in context subclasses.
//4、为容器的某些子类指定特殊的BeanPost 事件处理器
postProcessBeanFactory(beanFactory);
// Invoke factory processors registered as beans in the context.
//5、调用所有注册的BeanFactoryPostProcessor 的Bean
invokeBeanFactoryPostProcessors(beanFactory);
// Register bean processors that intercept bean creation.
//6、为BeanFactory 注册BeanPost 事件处理器.
//BeanPostProcessor 是Bean 后置处理器,用于监听容器触发的事件
registerBeanPostProcessors(beanFactory);
// Initialize message source for this context.
//7、初始化信息源,和国际化相关.
initMessageSource();
// Initialize event multicaster for this context.
//8、初始化容器事件传播器.
initApplicationEventMulticaster();
// Initialize other special beans in specific context subclasses.
//9、调用子类的某些特殊Bean 初始化方法
onRefresh();
// Check for listener beans and register them.
//10、为事件传播器注册事件监听器.
registerListeners();
// Instantiate all remaining (non-lazy-init) singletons.
//11、初始化所有剩余的单例Bean
finishBeanFactoryInitialization(beanFactory);
// Last step: publish corresponding event.
//12、初始化容器的生命周期事件处理器,并发布容器的生命周期事件
finishRefresh();
}
catch (BeansException ex) {
if (logger.isWarnEnabled()) {
logger.warn("Exception encountered during context initialization - " +
"cancelling refresh attempt: " + ex);
}
// Destroy already created singletons to avoid dangling resources.
//13、销毁已创建的Bean
destroyBeans();
// Reset 'active' flag.
//14、取消refresh 操作,重置容器的同步标识.
cancelRefresh(ex);
// Propagate exception to caller.
throw ex;
}
finally {
// Reset common introspection caches in Spring's core, since we
// might not ever need metadata for singleton beans anymore...
//15、重设公共缓存
resetCommonCaches();
}
}
}

  refresh()方法主要为IOC 容器Bean 的生命周期管理提供条件,Spring IOC 容器载入Bean 配置信息从其子类容器的refreshBeanFactory() 方法启动, 所以整个refresh() 中“ConfigurableListableBeanFactory beanFactory = obtainFreshBeanFactory();”这句以后代码的都是注册容器的信息源和生命周期事件,我们前面说的载入就是从这句代码开始启动。refresh()方法的主要作用是:在创建IOC 容器前,如果已经有容器存在,则需要把已有的容器销毁和关闭,以保证在refresh 之后使用的是新建立起来的IOC 容器。它类似于对IOC 容器的重启,在新建立好的容器中对容器进行初始化,对Bean 配置资源进行载入。

4、创建容器

  obtainFreshBeanFactory()方法调用子类容器的refreshBeanFactory()方法,启动容器载入Bean 配置信息的过程,代码如下:

protected ConfigurableListableBeanFactory obtainFreshBeanFactory() {
  //这里使用了委派设计模式,父类定义了抽象的refreshBeanFactory()方法,具体实现调用子类容器的refreshBeanFactory()方法
     refreshBeanFactory();
ConfigurableListableBeanFactory beanFactory = getBeanFactory();
if (logger.isDebugEnabled()) {
logger.debug("Bean factory for " + getDisplayName() + ": " + beanFactory);
}
return beanFactory;
}

  AbstractApplicationContext 类中只抽象定义了refreshBeanFactory()方法,容器真正调用的是其子类AbstractRefreshableApplicationContext 实现的refreshBeanFactory()方法,方法的源码如下:

@Override
protected final void refreshBeanFactory() throws BeansException {
//如果已经有容器,销毁容器中的bean,关闭容器
if (hasBeanFactory()) {
destroyBeans();
closeBeanFactory();
}
try {//创建IOC 容器,其实这里就是创建了一个
DefaultListableBeanFactory beanFactory = createBeanFactory();
beanFactory.setSerializationId(getId());
//对IOC 容器进行定制化,如设置启动参数,开启注解的自动装配等
customizeBeanFactory(beanFactory);
//调用载入Bean 定义的方法,主要这里又使用了一个委派模式,在当前类中只定义了抽象的loadBeanDefinitions 方法,具体的实现调用子类容器
        loadBeanDefinitions(beanFactory);
synchronized (this.beanFactoryMonitor) {
this.beanFactory = beanFactory;
}
}
catch (IOException ex) {
throw new ApplicationContextException("I/O error parsing bean definition source for " + getDisplayName(), ex);
}
}

  在这个方法中,先判断BeanFactory 是否存在,如果存在则先销毁beans 并关闭beanFactory,接着创建DefaultListableBeanFactory,并调用loadBeanDefinitions(beanFactory)装载bean 定义。

5、载入配置路径

  AbstractRefreshableApplicationContext 中只定义了抽象的loadBeanDefinitions 方法,容器真正调用的是其子类AbstractXmlApplicationContext 对该方法的实现,AbstractXmlApplicationContext的主要源码如下:loadBeanDefinitions() 方法同样是抽象方法, 是由其子类实现的, 也即在AbstractXmlApplicationContext 中。

@Override
protected void loadBeanDefinitions(DefaultListableBeanFactory beanFactory) throws BeansException, IOException {
// Create a new XmlBeanDefinitionReader for the given BeanFactory.
//创建XmlBeanDefinitionReader,即创建Bean 读取器,并通过回调设置到容器中去,容器使用该读取器读取Bean 配置资源
XmlBeanDefinitionReader beanDefinitionReader = new XmlBeanDefinitionReader(beanFactory); // Configure the bean definition reader with this context's
// resource loading environment.
//为Bean 读取器设置Spring 资源加载器,AbstractXmlApplicationContext 的
//祖先父类AbstractApplicationContext 继承DefaultResourceLoader,因此,容器本身也是一个资源加载器
beanDefinitionReader.setEnvironment(this.getEnvironment());
beanDefinitionReader.setResourceLoader(this);
//为Bean 读取器设置SAX xml 解析器
beanDefinitionReader.setEntityResolver(new ResourceEntityResolver(this)); // Allow a subclass to provide custom initialization of the reader,
// then proceed with actually loading the bean definitions.
//当Bean 读取器读取Bean 定义的Xml 资源文件时,启用Xml 的校验机制
initBeanDefinitionReader(beanDefinitionReader);
//Bean 读取器真正实现加载的方法
loadBeanDefinitions(beanDefinitionReader);
}
protected void initBeanDefinitionReader(XmlBeanDefinitionReader reader) {
reader.setValidating(this.validating);
}
//Xml Bean 读取器加载Bean 配置资源
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws BeansException, IOException {
//获取Bean 配置资源的定位
Resource[] configResources = getConfigResources();
if (configResources != null) {
//Xml Bean 读取器调用其父类AbstractBeanDefinitionReader 读取定位的Bean 配置资源
reader.loadBeanDefinitions(configResources);
}
// 如果子类中获取的Bean 配置资源定位为空,则获取ClassPathXmlApplicationContext
// 构造方法中setConfigLocations 方法设置的资源
String[] configLocations = getConfigLocations();
if (configLocations != null) {
//Xml Bean 读取器调用其父类AbstractBeanDefinitionReader 读取定位
//的Bean 配置资源
reader.loadBeanDefinitions(configLocations);
}
}
@Nullable
protected Resource[] getConfigResources() {
return null;
}

  以XmlBean 读取器的其中一种策略XmlBeanDefinitionReader 为例。XmlBeanDefinitionReader 调用其父类AbstractBeanDefinitionReader 的reader.loadBeanDefinitions()方法读取Bean 配置资源。由于我们使用ClassPathXmlApplicationContext 作为例子分析,因此getConfigResources 的返回值为null,因此程序执行reader.loadBeanDefinitions(configLocations)分支。

6、分配路径处理策略

  在XmlBeanDefinitionReader 的抽象父类AbstractBeanDefinitionReader 中定义了载入过程。AbstractBeanDefinitionReader 的loadBeanDefinitions()方法源码如下:

public int loadBeanDefinitions(String location, @Nullable Set<Resource> actualResources) throws BeanDefinitionStoreException {
//获取在IOC 容器初始化过程中设置的资源加载器 这里就是ApplicationContext ,走else
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 {
//将指定位置的Bean 配置信息解析为Spring IOC 容器封装的资源
//加载多个指定位置的Bean 配置信息
Resource[] resources = ((ResourcePatternResolver) resourceLoader).getResources(location);
//委派调用其子类XmlBeanDefinitionReader 的方法,实现加载功能
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.
//将指定位置的Bean 配置信息解析为Spring IOC 容器封装的资源
//加载单个指定位置的Bean 配置信息
Resource resource = resourceLoader.getResource(location);
//委派调用其子类XmlBeanDefinitionReader 的方法,实现加载功能
int loadCount = loadBeanDefinitions(resource);
if (actualResources != null) {
actualResources.add(resource);
}
if (logger.isDebugEnabled()) {
logger.debug("Loaded " + loadCount + " bean definitions from location [" + location + "]");
}
return loadCount;
}
}

  对AbstractBeanDefinitionReader 的loadBeanDefinitions()方法源码分析可以看出该方法就做了两件事:首先,调用资源加载器的获取资源方法resourceLoader.getResource(location),获取到要加载的资源。其次,真正执行加载功能是其子类XmlBeanDefinitionReader 的loadBeanDefinitions()方法。在loadBeanDefinitions()方法中调用了AbstractApplicationContext 的getResources()方法,跟进去之后发现getResources()方法其实定义在ResourcePatternResolver 中,此时,我们有必要来看一下ResourcePatternResolver 的全类图:

spring 容器的基础 XmlBeanFactory

  从上面可以看到ResourceLoader 与ApplicationContext 的继承关系,可以看出其实际调用的是DefaultResourceLoader 中的getSource() 方法定位Resource , 因为ClassPathXmlApplicationContext 本身就是DefaultResourceLoader 的实现类,所以此时又回到了ClassPathXmlApplicationContext 中来。其实就是在容器初始化设置资源加载器的时候:

public PathMatchingResourcePatternResolver(ResourceLoader resourceLoader) {
Assert.notNull(resourceLoader, "ResourceLoader must not be null");
this.resourceLoader = resourceLoader;
}

7、解析配置文件路径

  XmlBeanDefinitionReader 通过调用ClassPathXmlApplicationContext 的父类DefaultResourceLoader 的getResource()方法获取要加载的资源,其源码如下

@Override
public Resource getResource(String location) {
Assert.notNull(location, "Location must not be null"); for (ProtocolResolver protocolResolver : this.protocolResolvers) {
Resource resource = protocolResolver.resolve(location, this);
if (resource != null) {
return resource;
}
}
//如果是类路径的方式,那需要使用ClassPathResource 来得到bean 文件的资源对象
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 方式,使用UrlResource 作为bean 文件的资源对象
URL url = new URL(location);
return (ResourceUtils.isFileURL(url) ? new FileUrlResource(url) : new UrlResource(url));
}
catch (MalformedURLException ex) {
// No URL -> resolve as resource path.
//如果既不是classpath 标识,又不是URL 标识的Resource 定位,则调用
//容器本身的getResourceByPath 方法获取Resource
return getResourceByPath(location);
}
}
}

  DefaultResourceLoader 提供了getResourceByPath()方法的实现,就是为了处理既不是classpath标识,又不是URL 标识的Resource 定位这种情况。在ClassPathResource 中完成了对整个路径的解析。这样,就可以从类路径上对IOC 配置文件进行加载,当然我们可以按照这个逻辑从任何地方加载,在Spring 中我们看到它提供的各种资源抽象,比如ClassPathResource、URLResource、FileSystemResource 等来供我们使用。上面我们看到的是定位Resource 的一个过程,而这只是加载过程的一部分。例如FileSystemXmlApplication 容器就重写了,通过子类的覆盖,巧妙地完成了将类路径变为文件路径的转换。getResourceByPath()方法

@Override
protected Resource getResourceByPath(String path) {
  if (path.startsWith("/")) {
    path = path.substring();
  }
  //这里使用文件系统资源对象来定义bean 文件
  return new FileSystemResource(path);
}

8、开始读取配置内容

  继续回到XmlBeanDefinitionReader 的loadBeanDefinitions(Resource …)方法看到代表bean 文件的资源定义以后的载入过程。

public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException {
     。。。。。。。try {//将资源文件转为InputStream 的IO 流
InputStream inputStream = encodedResource.getResource().getInputStream();
try {
//从InputStream 中得到XML 的解析源
InputSource inputSource = new InputSource(inputStream);
if (encodedResource.getEncoding() != null) {
inputSource.setEncoding(encodedResource.getEncoding());
}
//这里是具体的读取过程
return doLoadBeanDefinitions(inputSource, encodedResource.getResource());
}
finally {//关闭从Resource 中得到的IO 流
inputStream.close();
}
}
catch (IOException ex) {
throw new BeanDefinitionStoreException(
"IOException parsing XML document from " + encodedResource.getResource(), ex);
}
finally {
currentResources.remove(encodedResource);
if (currentResources.isEmpty()) {
this.resourcesCurrentlyBeingLoaded.remove();
}
}
}
//从特定XML 文件中实际载入Bean 配置资源的方法
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource)
throws BeanDefinitionStoreException {
try {
//将XML 文件转换为DOM 对象,解析过程由documentLoader 实现
Document doc = doLoadDocument(inputSource, resource);
//这里是启动对Bean 定义解析的详细过程,该解析过程会用到Spring 的Bean 配置规则
return registerBeanDefinitions(doc, resource);
}
  。。。。。。。。。
}
 

  通过源码分析,载入Bean 配置信息的最后一步是将Bean 配置信息转换为Document 对象,该过程由documentLoader()方法实现。

9、准备文档对象

  DocumentLoader 将Bean 配置资源转换成Document 对象的源码如下:

@Override
//使用标准的JAXP 将载入的Bean 配置资源转换成document 对象
public Document loadDocument(InputSource inputSource, EntityResolver entityResolver,
ErrorHandler errorHandler, int validationMode, boolean namespaceAware) throws Exception {
//创建文件解析器工厂
DocumentBuilderFactory factory = createDocumentBuilderFactory(validationMode, namespaceAware);
if (logger.isDebugEnabled()) {
logger.debug("Using JAXP provider [" + factory.getClass().getName() + "]");
}
//创建文档解析器
DocumentBuilder builder = createDocumentBuilder(factory, entityResolver, errorHandler);
//解析Spring 的Bean 配置资源
return builder.parse(inputSource);
}
protected DocumentBuilderFactory createDocumentBuilderFactory(int validationMode, boolean namespaceAware)
throws ParserConfigurationException {
//创建文档解析工厂
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
factory.setNamespaceAware(namespaceAware);
//设置解析XML 的校验
if (validationMode != XmlValidationModeDetector.VALIDATION_NONE) {
factory.setValidating(true);
if (validationMode == XmlValidationModeDetector.VALIDATION_XSD) {
// Enforce namespace aware for XSD...
factory.setNamespaceAware(true);
try {
factory.setAttribute(SCHEMA_LANGUAGE_ATTRIBUTE, XSD_SCHEMA_LANGUAGE);
}
catch (IllegalArgumentException ex) {
ParserConfigurationException pcex = new ParserConfigurationException(
"Unable to validate using XSD: Your JAXP provider [" + factory +
"] does not support XML Schema. Are you running on Java 1.4 with Apache Crimson? " +
"Upgrade to Apache Xerces (or Java 1.5) for full XSD support.");
pcex.initCause(ex);
throw pcex;
}
}
} return factory;
}
 

上面的解析过程是调用JavaEE 标准的JAXP 标准进行处理。至此Spring IOC 容器根据定位的Bean 配置信息,将其加载读入并转换成为Document 对象过程完成。接下来我们要继续分析Spring IOC 容器将载入的Bean 配置信息转换为Document 对象之后,是如何将其解析为Spring IOC 管理的Bean 对象并将其注册到容器中的。

10、分配解析策略

  XmlBeanDefinitionReader 类中的doLoadBeanDefinition()方法是从特定XML 文件中实际载入Bean 配置资源的方法,该方法在载入Bean 配置资源之后将其转换为Document 对象,接下来调用registerBeanDefinitions() 启动Spring IOC 容器对Bean 定义的解析过程,registerBeanDefinitions()方法源码如下:

//按照Spring 的Bean 语义要求将Bean 配置资源解析并转换为容器内部数据结构
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException {
//得到BeanDefinitionDocumentReader 来对xml 格式的BeanDefinition 解析
BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader();
//获得容器中注册的Bean 数量
int countBefore = getRegistry().getBeanDefinitionCount();
//解析过程入口,这里使用了委派模式,BeanDefinitionDocumentReader 只是个接口,
//具体的解析实现过程有实现类DefaultBeanDefinitionDocumentReader 完成
documentReader.registerBeanDefinitions(doc, createReaderContext(resource));
//统计解析的Bean 数量
return getRegistry().getBeanDefinitionCount() - countBefore;
}

  Bean 配置资源的载入解析分为以下两个过程:首先,通过调用XML 解析器将Bean 配置信息转换得到Document 对象,但是这些Document 对象并没有按照Spring 的Bean 规则进行解析。这一步是载入的过程其次,在完成通用的XML 解析之后,按照Spring Bean 的定义规则对Document 对象进行解析,其解析过程是在接口BeanDefinitionDocumentReader 的实现类DefaultBeanDefinitionDocumentReader 中实现。

11、将配置载入内存

  BeanDefinitionDocumentReader 接口通过registerBeanDefinitions() 方法调用其实现类DefaultBeanDefinitionDocumentReader 对Document 对象进行解析,解析的代码如下:

@Override
//根据Spring DTD 对Bean 的定义规则解析Bean 定义Document 对象
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) {
//获得XML 描述符
this.readerContext = readerContext;
logger.debug("Loading bean definitions");
//获得Document 的根元素
Element root = doc.getDocumentElement();
doRegisterBeanDefinitions(root);
}
protected void doRegisterBeanDefinitions(Element root) {
//具体的解析过程由BeanDefinitionParserDelegate 实现,
//BeanDefinitionParserDelegate 中定义了Spring Bean 定义XML 文件的各种元素
BeanDefinitionParserDelegate parent = this.delegate;
  //创建BeanDefinitionParserDelegate,用于完成真正的解析过程
this.delegate = createDelegate(getReaderContext(), root, parent); if (this.delegate.isDefaultNamespace(root)) {
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE);
if (StringUtils.hasText(profileSpec)) {
String[] specifiedProfiles = StringUtils.tokenizeToStringArray(
profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS);
if (!getReaderContext().getEnvironment().acceptsProfiles(specifiedProfiles)) {
if (logger.isInfoEnabled()) {
logger.info("Skipped XML bean definition file due to specified profiles [" + profileSpec +
"] not matching: " + getReaderContext().getResource());
}
return;
}
}
}
//在解析Bean 定义之前,进行自定义的解析,增强解析过程的可扩展性
preProcessXml(root);
//从Document 的根元素开始进行Bean 定义的Document 对象
parseBeanDefinitions(root, this.delegate);
//在解析Bean 定义之后,进行自定义的解析,增加解析过程的可扩展性
postProcessXml(root); this.delegate = parent;
} protected void parseBeanDefinitions(Element root, BeanDefinitionParserDelegate delegate) {
//Bean 定义的Document 对象使用了Spring 默认的XML 命名空间
if (delegate.isDefaultNamespace(root)) {
//获取Bean 定义的Document 对象根元素的所有子节点
NodeList nl = root.getChildNodes();
for (int i = ; i < nl.getLength(); i++) {
Node node = nl.item(i);
//获得Document 节点是XML 元素节点
if (node instanceof Element) {
Element ele = (Element) node;
//Bean 定义的Document 的元素节点使用的是Spring 默认的XML 命名空间
if (delegate.isDefaultNamespace(ele)) {
//使用Spring 的Bean 规则解析元素节点
parseDefaultElement(ele, delegate);
}
else {
//没有使用Spring 默认的XML 命名空间,则使用用户自定义的解//析规则解析元素节点
delegate.parseCustomElement(ele);
}
}
}
}
else {
//Document 的根节点没有使用Spring 默认的命名空间,则使用用户自定义的
//解析规则解析Document 根节点
delegate.parseCustomElement(root);
}
} //使用Spring 的Bean 规则解析Document 元素节点
private void parseDefaultElement(Element ele, BeanDefinitionParserDelegate delegate) {
//如果元素节点是<Import>导入元素,进行导入解析
if (delegate.nodeNameEquals(ele, IMPORT_ELEMENT)) {
importBeanDefinitionResource(ele);
}
//如果元素节点是<Alias>别名元素,进行别名解析
else if (delegate.nodeNameEquals(ele, ALIAS_ELEMENT)) {
processAliasRegistration(ele);
}
//元素节点既不是导入元素,也不是别名元素,即普通的<Bean>元素,
//按照Spring 的Bean 规则解析元素
else if (delegate.nodeNameEquals(ele, BEAN_ELEMENT)) {
processBeanDefinition(ele, delegate);
}
else if (delegate.nodeNameEquals(ele, NESTED_BEANS_ELEMENT)) {
// recurse
doRegisterBeanDefinitions(ele);
}
} protected void processBeanDefinition(Element ele, BeanDefinitionParserDelegate delegate) {
// BeanDefinitionHolder 是对BeanDefinition 的封装,即Bean 定义的封装类
BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
//对Document 对象中<Bean>元素的解析由BeanDefinitionParserDelegate 实现
// BeanDefinitionHolder bdHolder = delegate.parseBeanDefinitionElement(ele);
if (bdHolder != null) {
bdHolder = delegate.decorateBeanDefinitionIfRequired(ele, bdHolder);
try {
// Register the final decorated instance.
//向Spring IOC 容器注册解析得到的Bean 定义,这是Bean 定义向IOC 容器注册的入口
BeanDefinitionReaderUtils.registerBeanDefinition(bdHolder, getReaderContext().getRegistry());
}
catch (BeanDefinitionStoreException ex) {
getReaderContext().error("Failed to register bean definition with name '" +
bdHolder.getBeanName() + "'", ele, ex);
}
// Send registration event.
//在完成向Spring IOC 容器注册解析得到的Bean 定义之后,发送注册事件
getReaderContext().fireComponentRegistered(new BeanComponentDefinition(bdHolder));
}
}

  通过上述Spring IOC 容器对载入的Bean 定义Document 解析可以看出,我们使用Spring 时,在Spring 配置文件中可以使用<import>元素来导入IOC 容器所需要的其他资源,Spring IOC 容器在解析时会首先将指定导入的资源加载进容器中。使用<ailas>别名时,Spring IOC 容器首先将别名元素所定义的别名注册到容器中。对于既不是<import>元素,又不是<alias>元素的元素,即Spring 配置文件中普通的<bean>元素的解析由BeanDefinitionParserDelegate 类的parseBeanDefinitionElement()方法来实现。这个解析的过程非常复杂,我们在mini 版本的时候,就用properties 文件代替了。

12、载入<bean>元素

  Bean 配置信息中的<import>和<alias>元素解析在DefaultBeanDefinitionDocumentReader 中已经完成,对Bean 配置信息中使用最多的<bean>元素交由BeanDefinitionParserDelegate 来解析,其解析实现的源码如下:

//解析Bean 配置信息中的<Bean>元素,这个方法中主要处理<Bean>元素的id,name 和别名属性
@Nullable
public BeanDefinitionHolder parseBeanDefinitionElement(Element ele, @Nullable BeanDefinition containingBean) {
//获取<Bean>元素中的id 属性值
String id = ele.getAttribute(ID_ATTRIBUTE);
//获取<Bean>元素中的name 属性值
String nameAttr = ele.getAttribute(NAME_ATTRIBUTE);
//获取<Bean>元素中的alias 属性值
List<String> aliases = new ArrayList<>();
//将<Bean>元素中的所有name 属性值存放到别名中
if (StringUtils.hasLength(nameAttr)) {
String[] nameArr = StringUtils.tokenizeToStringArray(nameAttr, MULTI_VALUE_ATTRIBUTE_DELIMITERS);
aliases.addAll(Arrays.asList(nameArr));
} String beanName = id;
//如果<Bean>元素中没有配置id 属性时,将别名中的第一个值赋值给beanName
if (!StringUtils.hasText(beanName) && !aliases.isEmpty()) {
beanName = aliases.remove();
if (logger.isDebugEnabled()) {
logger.debug("No XML 'id' specified - using '" + beanName +
"' as bean name and " + aliases + " as aliases");
}
}
//检查<Bean>元素所配置的id 或者name 的唯一性,containingBean 标识<Bean>
//元素中是否包含子<Bean>元素
if (containingBean == null) {
//检查<Bean>元素所配置的id、name 或者别名是否重复
checkNameUniqueness(beanName, aliases, ele);
}
//详细对<Bean>元素中配置的Bean 定义进行解析的地方
AbstractBeanDefinition beanDefinition = parseBeanDefinitionElement(ele, beanName, containingBean);
if (beanDefinition != null) {
if (!StringUtils.hasText(beanName)) {
try {
if (containingBean != null) {
//如果<Bean>元素中没有配置id、别名或者name,且没有包含子元素
//<Bean>元素,为解析的Bean 生成一个唯一beanName 并注册
beanName = BeanDefinitionReaderUtils.generateBeanName(
beanDefinition, this.readerContext.getRegistry(), true);
}
else {
//如果<Bean>元素中没有配置id、别名或者name,且包含了子元素
//<Bean>元素,为解析的Bean 使用别名向IOC 容器注册
beanName = this.readerContext.generateBeanName(beanDefinition);
// Register an alias for the plain bean class name, if still possible,
// if the generator returned the class name plus a suffix.
// This is expected for Spring 1.2/2.0 backwards compatibility.
//为解析的Bean 使用别名注册时,为了向后兼容
//Spring1.2/2.0,给别名添加类名后缀
String beanClassName = beanDefinition.getBeanClassName();
if (beanClassName != null &&
beanName.startsWith(beanClassName) && beanName.length() > beanClassName.length() &&
!this.readerContext.getRegistry().isBeanNameInUse(beanClassName)) {
aliases.add(beanClassName);
}
}
if (logger.isDebugEnabled()) {
logger.debug("Neither XML 'id' nor 'name' specified - " +
"using generated bean name [" + beanName + "]");
}
}
catch (Exception ex) {
error(ex.getMessage(), ele);
return null;
}
}
String[] aliasesArray = StringUtils.toStringArray(aliases);
return new BeanDefinitionHolder(beanDefinition, beanName, aliasesArray);
} return null;
}
protected void checkNameUniqueness(String beanName, List<String> aliases, Element beanElement) {
String foundName = null; if (StringUtils.hasText(beanName) && this.usedNames.contains(beanName)) {
foundName = beanName;
}
if (foundName == null) {
foundName = CollectionUtils.findFirstMatch(this.usedNames, aliases);
}
if (foundName != null) {
error("Bean name '" + foundName + "' is already used in this <beans> element", beanElement);
} this.usedNames.add(beanName);
this.usedNames.addAll(aliases);
}
//详细对<Bean>元素中配置的Bean 定义其他属性进行解析
//由于上面的方法中已经对Bean 的id、name 和别名等属性进行了处理
//该方法中主要处理除这三个以外的其他属性数据
@Nullable
public AbstractBeanDefinition parseBeanDefinitionElement(
Element ele, String beanName, @Nullable BeanDefinition containingBean) {
//记录解析的<Bean>
this.parseState.push(new BeanEntry(beanName));
//这里只读取<Bean>元素中配置的class 名字,然后载入到BeanDefinition 中去
//只是记录配置的class 名字,不做实例化,对象的实例化在依赖注入时完成
String className = null;
if (ele.hasAttribute(CLASS_ATTRIBUTE)) {
className = ele.getAttribute(CLASS_ATTRIBUTE).trim();
}
//如果<Bean>元素中配置了parent 属性,则获取parent 属性的值
String parent = null;
if (ele.hasAttribute(PARENT_ATTRIBUTE)) {
parent = ele.getAttribute(PARENT_ATTRIBUTE);
} try {
//根据<Bean>元素配置的class 名称和parent 属性值创建BeanDefinition
//为载入Bean 定义信息做准备
AbstractBeanDefinition bd = createBeanDefinition(className, parent); //对当前的<Bean>元素中配置的一些属性进行解析和设置,如配置的单态(singleton)属性等
parseBeanDefinitionAttributes(ele, beanName, containingBean, bd);
//为<Bean>元素解析的Bean 设置description 信息
bd.setDescription(DomUtils.getChildElementValueByTagName(ele, DESCRIPTION_ELEMENT));
//对<Bean>元素的meta(元信息)属性解析
parseMetaElements(ele, bd);
//对<Bean>元素的lookup-Method 属性解析
parseLookupOverrideSubElements(ele, bd.getMethodOverrides());
//对<Bean>元素的replaced-Method 属性解析
parseReplacedMethodSubElements(ele, bd.getMethodOverrides());
//解析<Bean>元素的构造方法设置
parseConstructorArgElements(ele, bd);
    //解析<Bean>元素的<property>设置
parsePropertyElements(ele, bd);
parseQualifierElements(ele, bd);
//为当前解析的Bean 设置所需的资源和依赖对象
bd.setResource(this.readerContext.getResource());
bd.setSource(extractSource(ele)); return bd;
}
catch (ClassNotFoundException ex) {
error("Bean class [" + className + "] not found", ele, ex);
}
catch (NoClassDefFoundError err) {
error("Class that bean class [" + className + "] depends on not found", ele, err);
}
catch (Throwable ex) {
error("Unexpected failure during bean definition parsing", ele, ex);
}
finally {
this.parseState.pop();
} return null;
}

  只要使用过Spring,对Spring 配置文件比较熟悉的人,通过对上述源码的分析,就会明白我们在Spring配置文件中<Bean>元素的中配置的属性就是通过该方法解析和设置到Bean 中去的。注意:在解析<Bean>元素过程中没有创建和实例化Bean 对象,只是创建了Bean 对象的定义类BeanDefinition,将<Bean>元素中的配置信息设置到BeanDefinition 中作为记录,当依赖注入时才使用这些记录信息创建和实例化具体的Bean 对象。上面方法中一些对一些配置如元信息(meta)、qualifier 等的解析,我们在Spring 中配置时使用的也不多,我们在使用Spring 的<Bean>元素时,配置最多的是<property>属性,因此我们下面继续分析源码,了解Bean 的属性在解析时是如何设置的。

13、载入<property>元素

  BeanDefinitionParserDelegate 在解析<Bean>调用parsePropertyElements()方法解析<Bean>元素中的<property>属性子元素,解析源码如下:

14、载入<property>的子元素

  在BeanDefinitionParserDelegate 类中的parsePropertySubElement()方法对<property>中的子元素解析

15、载入<list>的子元素

  在BeanDefinitionParserDelegate 类中的parseListElement()方法就是具体实现解析<property>元素中的<list>集合子元素经过对Spring Bean 配置信息转换的Document 对象中的元素层层解析,Spring IOC 现在已经将XML形式定义的Bean 配置信息转换为Spring IOC 所识别的数据结构——BeanDefinition,它是Bean 配置信息中配置的POJO 对象在Spring IOC 容器中的映射,我们可以通过AbstractBeanDefinition 为入口,看到了IOC 容器进行索引、查询和操作。通过Spring IOC 容器对Bean 配置资源的解析后,IOC 容器大致完成了管理Bean 对象的准备工作,即初始化过程,但是最为重要的依赖注入还没有发生,现在在IOC 容器中BeanDefinition 存储的只是一些静态信息,接下来需要向容器注册Bean 定义信息才能全部完成IOC 容器的初始化过程

16、分配注册策略

  让我们继续跟踪程序的执行顺序,接下来我们来分析DefaultBeanDefinitionDocumentReader 对Bean 定义转换的Document 对象解析的流程中, 在其parseDefaultElement() 方法中完成对Document 对象的解析后得到封装BeanDefinition 的BeanDefinitionHold 对象, 然后调用BeanDefinitionReaderUtils 的registerBeanDefinition() 方法向IOC 容器注册解析的Bean ,BeanDefinitionReaderUtils 的注册的源码如下:

//将解析的BeanDefinitionHold 注册到容器中
public static void registerBeanDefinition(
BeanDefinitionHolder definitionHolder, BeanDefinitionRegistry registry)
throws BeanDefinitionStoreException { // Register bean definition under primary name.
//获取解析的BeanDefinition 的名称
String beanName = definitionHolder.getBeanName();
//向IOC 容器注册BeanDefinition
registry.registerBeanDefinition(beanName, definitionHolder.getBeanDefinition()); // Register aliases for bean name, if any.
//如果解析的BeanDefinition 有别名,向容器为其注册别名
String[] aliases = definitionHolder.getAliases();
if (aliases != null) {
for (String alias : aliases) {
registry.registerAlias(beanName, alias);
}
}
}

  当调用BeanDefinitionReaderUtils 向IOC 容器注册解析的BeanDefinition 时,真正完成注册功能的是DefaultListableBeanFactory。

17、向容器注册

  DefaultListableBeanFactory 中使用一个HashMap 的集合对象存放IOC 容器中注册解析的BeanDefinition,向IOC 容器注册的主要源码如下:

private final Map<String, BeanDefinition> beanDefinitionMap = new ConcurrentHashMap<>(256);
@Override
public void registerBeanDefinition(String beanName, BeanDefinition beanDefinition)
throws BeanDefinitionStoreException { Assert.hasText(beanName, "Bean name must not be empty");
Assert.notNull(beanDefinition, "BeanDefinition must not be null");
//校验解析的BeanDefiniton
if (beanDefinition instanceof AbstractBeanDefinition) {
try {
((AbstractBeanDefinition) beanDefinition).validate();
}
catch (BeanDefinitionValidationException ex) {
throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
"Validation of bean definition failed", ex);
}
} BeanDefinition oldBeanDefinition; oldBeanDefinition = this.beanDefinitionMap.get(beanName);
if (oldBeanDefinition != null) {
if (!isAllowBeanDefinitionOverriding()) {
throw new BeanDefinitionStoreException(beanDefinition.getResourceDescription(), beanName,
"Cannot register bean definition [" + beanDefinition + "] for bean '" + beanName +
"': There is already [" + oldBeanDefinition + "] bound.");
}
else if (oldBeanDefinition.getRole() < beanDefinition.getRole()) {
// e.g. was ROLE_APPLICATION, now overriding with ROLE_SUPPORT or ROLE_INFRASTRUCTURE
if (this.logger.isWarnEnabled()) {
this.logger.warn("Overriding user-defined bean definition for bean '" + beanName +
"' with a framework-generated bean definition: replacing [" +
oldBeanDefinition + "] with [" + beanDefinition + "]");
}
}
else if (!beanDefinition.equals(oldBeanDefinition)) {
if (this.logger.isInfoEnabled()) {
this.logger.info("Overriding bean definition for bean '" + beanName +
"' with a different definition: replacing [" + oldBeanDefinition +
"] with [" + beanDefinition + "]");
}
}
else {
if (this.logger.isDebugEnabled()) {
this.logger.debug("Overriding bean definition for bean '" + beanName +
"' with an equivalent definition: replacing [" + oldBeanDefinition +
"] with [" + beanDefinition + "]");
}
}
this.beanDefinitionMap.put(beanName, beanDefinition);
}
else {
if (hasBeanCreationStarted()) {
// Cannot modify startup-time collection elements anymore (for stable iteration)
synchronized (this.beanDefinitionMap) {
this.beanDefinitionMap.put(beanName, beanDefinition);
List<String> updatedDefinitions = new ArrayList<>(this.beanDefinitionNames.size() + );
updatedDefinitions.addAll(this.beanDefinitionNames);
updatedDefinitions.add(beanName);
this.beanDefinitionNames = updatedDefinitions;
if (this.manualSingletonNames.contains(beanName)) {
Set<String> updatedSingletons = new LinkedHashSet<>(this.manualSingletonNames);
updatedSingletons.remove(beanName);
this.manualSingletonNames = updatedSingletons;
}
}
}
else {
// Still in startup registration phase
this.beanDefinitionMap.put(beanName, beanDefinition);
this.beanDefinitionNames.add(beanName);
this.manualSingletonNames.remove(beanName);
}
this.frozenBeanDefinitionNames = null;
}
//检查是否有同名的BeanDefinition 已经在IOC 容器中注册
if (oldBeanDefinition != null || containsSingleton(beanName)) {
//重置所有已经注册过的BeanDefinition 的缓存
resetBeanDefinition(beanName);
}
}

  至此,Bean 配置信息中配置的Bean 被解析过后,已经注册到IOC 容器中,被容器管理起来,真正完成了IOC 容器初始化所做的全部工作。现在IOC 容器中已经建立了整个Bean 的配置信息,这些BeanDefinition 信息已经可以使用,并且可以被检索,IOC 容器的作用就是对这些注册的Bean 定义信息进行处理和维护。这些的注册的Bean 定义信息是IOC 容器控制反转的基础,正是有了这些注册的数据,容器才可以进行依赖注入。

IOC 容器初始化小结

现在通过上面的代码,总结一下IOC 容器初始化的基本步骤:

1、初始化的入口在容器实现中的refresh()调用来完成。

2、对Bean 定义载入IOC 容器使用的方法是loadBeanDefinition(),

  其中的大致过程如下:通过ResourceLoader 来完成资源文件位置的定位,DefaultResourceLoader是默认的实现,同时上下文本身就给出了ResourceLoader 的实现,可以从类路径,文件系统,URL 等方式来定为资源位置。如果是XmlBeanFactory 作为IOC 容器,那么需要为它指定Bean 定义的资源,也就是说Bean 定义文件时通过抽象成Resource 来被IOC 容器处理的, 容器通过BeanDefinitionReader 来完成定义信息的解析和Bean 信息的注册, 往往使用的是XmlBeanDefinitionReader 来解析Bean 的XML 定义文件- 实际的处理过程是委托给BeanDefinitionParserDelegate 来完成的,从而得到bean 的定义信息,这些信息在Spring 中使用BeanDefinition 对象来表示-这个名字可以让我们想到loadBeanDefinition(),registerBeanDefinition()这些相关方法。它们都是为处理BeanDefinitin 服务的,容器解析得到BeanDefinition 以后,需要把它在IOC 容器中注册,这由IOC 实现BeanDefinitionRegistry 接口来实现。注册过程就是在IOC 容器内部维护的一个HashMap 来保存得到的BeanDefinition 的过程。这个HashMap 是IOC 容器持有Bean 信息的场所,以后对Bean 的操作都是围绕这个HashMap 来实现的。然后我们就可以通过BeanFactory 和ApplicationContext 来享受到Spring IOC 的服务了,在使用IOC容器的时候,我们注意到除了少量粘合代码,绝大多数以正确IOC 风格编写的应用程序代码完全不用关心如何到达工厂,因为容器将把这些对象与容器管理的其他对象钩在一起。基本的策略是把工厂放到已知的地方,最好是放在对预期使用的上下文有意义的地方,以及代码将实际需要访问工厂的地方。Spring本身提供了对声明式载入web 应用程序用法的应用程序上下文,并将其存储在ServletContext 中的框架实现。

  最后献上整个容器初始化时序图

spring 容器的基础 XmlBeanFactory

传统的Spring项目中的初始化流程:

  每一个整合spring框架的项目中,总是不可避免地要在web.xml中加入这样一段配置。

<!-- 配置spring核心监听器,默认会以 /WEB-INF/applicationContext.xml作为配置文件 -->
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<!-- contextConfigLocation参数用来指定Spring的配置文件 -->
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/applicationContext*.xml</param-value>
</context-param>

  这段配置有何作用呢,通过ContextLoaderListener源码来分析一下

public class ContextLoaderListener extends ContextLoader implements ServletContextListener

继承ContextLoader有什么作用:

  ContextLoaderListener可以指定在Web应用程序启动时载入Ioc容器,正是通过ContextLoader来实现的,可以说是Ioc容器的初始化工作。

实现ServletContextListener又有什么作用:

  ServletContextListener接口里的函数会结合Web容器的生命周期被调用。因为ServletContextListener是ServletContext的监听者,如果ServletContext发生变化,会触发相应的事件,而监听器一直对事件监听,如果接收到了变化,就会做出预先设计好的相应动作。由于ServletContext变化而触发的监听器的响应具体包括:在服务器启动时,ServletContext被创建的时候,服务器关闭时,ServletContext将被销毁的时候等,相当于web的生命周期创建与效果的过程。

那么ContextLoaderListener的作用是什么:

  ContextLoaderListener的作用就是启动Web容器时,读取在contextConfigLocation中定义的xml文件,自动装配ApplicationContext的配置信息,并产生WebApplicationContext对象,然后将这个对象放置在ServletContext的属性里,这样我们只要得到Servlet就可以得到WebApplicationContext对象,并利用这个对象访问spring容器管理的bean。

  简单来说,就是上面这段配置为项目提供了spring支持,初始化了Ioc容器。而ServletContextListener所触发的动作则是:

/**
* Receives notification that the web application initialization
* process is starting.
*
* <p>All ServletContextListeners are notified of context
* initialization before any filters or servlets in the web
* application are initialized.
*
* @param sce the ServletContextEvent containing the ServletContext
* that is being initialized
*/
public void contextInitialized(ServletContextEvent sce);

  然后进入父类 ContextLoader :

public WebApplicationContext initWebApplicationContext(ServletContext servletContext) {
  //省略代码
  servletContext.setAttribute(WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE, this.context);
  //....省略代码
}

  然后进入:

protected void configureAndRefreshWebApplicationContext(ConfigurableWebApplicationContext wac, ServletContext sc) {
if (ObjectUtils.identityToString(wac).equals(wac.getId())) {
// The application context id is still set to its original default value
// -> assign a more useful id based on available information
String idParam = sc.getInitParameter(CONTEXT_ID_PARAM);
if (idParam != null) {
wac.setId(idParam);
}
else {
// Generate default id...
wac.setId(ConfigurableWebApplicationContext.APPLICATION_CONTEXT_ID_PREFIX +
ObjectUtils.getDisplayString(sc.getContextPath()));
}
} wac.setServletContext(sc);
String configLocationParam = sc.getInitParameter(CONFIG_LOCATION_PARAM);
if (configLocationParam != null) {//这不就是我们上面说的定位资源。设置Bean 配置信息的定位路径的方法吗
wac.setConfigLocation(configLocationParam);
} // The wac environment's #initPropertySources will be called in any case when the context
// is refreshed; do it eagerly here to ensure servlet property sources are in place for
// use in any post-processing or initialization that occurs below prior to #refresh
ConfigurableEnvironment env = wac.getEnvironment();
if (env instanceof ConfigurableWebEnvironment) {
((ConfigurableWebEnvironment) env).initPropertySources(sc, null);
} customizeContext(sc, wac);
//初始化
wac.refresh();
}

  然后完成初始化。