- 浏览: 1843474 次
- 性别:
- 来自: 深圳
文章分类
- 全部博客 (665)
- 闲话 (17)
- ruby (1)
- javascript (40)
- linux (7)
- android (22)
- 开发过程 (11)
- 哥也读读源代码 (13)
- JVM (1)
- ant (2)
- Hibernate (3)
- jboss (3)
- web service (17)
- https (4)
- java基础 (17)
- spring (7)
- servlet (3)
- 杂记 (39)
- struts2 (10)
- logback (4)
- 多线程 (2)
- 系统诊断 (9)
- UI (4)
- json (2)
- Java EE (7)
- eclipse相关 (4)
- JMS (1)
- maven (19)
- 版本管理 (7)
- sso (1)
- ci (1)
- 设计 (18)
- 戒烟 (4)
- http (9)
- 计划 (4)
- HTML5 (3)
- chrome extensions (5)
- tomcat源码阅读 (4)
- httpd (5)
- MongoDB (3)
- node (2)
最新评论
-
levin_china:
勾选了,还是找不到
用spring annotation声明的bean,当打包在jar中时,无法被扫描到 -
GGGGeek:
我用的maven-3.5.0,还没有遇到这种情况,使用jar ...
用spring annotation声明的bean,当打包在jar中时,无法被扫描到 -
GGGGeek:
受益匪浅,从组织项目结构,到技术细节,讲的很到位,只是博主不再 ...
一个多maven项目聚合的实例 -
Aaron-Joe-William:
<?xml version="1.0" ...
hibernate逆向工程 -
li272355201:
http://archive.apache.org/dist/ ...
tomcat源码阅读(一)——环境搭建
上一篇博客说到,ApplicationContext将解析BeanDefinition的工作委托给BeanDefinitionReader组件,这篇就接着分析一下BeanDefinition的解析过程
这是解析过程最外围的代码,过程是很清晰的,首先要获取到配置文件的路径,这在之前已经完成了。然后将每个配置文件的路径,作为参数传给BeanDefinitionReader的loadBeanDefinitions方法里
这个方法又调用了重载方法
这个方法就比较长了,不过分析一下,流程还是很清晰的。
BeanDefinitionReader不能直接加载配置文件,需要把配置文件封装成Resource,然后才能调用重载方法loadBeanDefinitions()。所以这个方法其实就是2段,第一部分是委托ResourceLoader将配置文件封装成Resource,第二部分是调用loadBeanDefinitions(),对Resource进行解析
而这里的ResourceLoader,就是前面的XmlWebApplicationContext,因为ApplicationContext接口,是继承自ResourceLoader接口的
Resource也是一个接口体系,在web环境下,这里就是ServletContextResource
接下来进入重载方法loadBeanDefinitions()
这里就不用说了,就是把每一个Resource作为参数,继续调用重载方法。读spring源码,会发现重载方法特别多
还是重载方法,不过这里对传进来的Resource又进行了一次封装,变成了编码后的Resource,问题不大
这个就是loadBeanDefinitions()的最后一个重载方法,比较长,可以拆看来看
这第一部分,是处理线程相关的工作,把当前正在解析的Resource,设置为当前Resource
这里是第二部分,是核心,首先把Resource还原为InputStream,然后调用实际解析的方法doLoadBeanDefinitions()。可以看到,这种命名方式是很值得学习的,一种业务方法,比如parse(),可能需要做一些外围的工作,然后实际解析的方法,可以命名为doParse()。这种doXXX()的命名方法,在很多开源框架中都有应用,比如logback等
接下来就看一下这个doLoadBeanDefinitions()方法
抛开处理异常的若干catch体,只看实体部分
这个流程也是很清晰的,首先确认校验模式,然后委托documentLoader,将InputStream读取成标准的Document对象,然后调用registerBeanDefinitions(),进行解析工作
这里注意两点
首先这个Document对象,是W3C定义的标准XML对象,跟spring无关。
其次这个registerBeanDefinitions方法,我觉得命名有点误导性。因为这个时候实际上解析还没有开始,怎么直接就注册了呢。比较好的命名,我觉得可以是parseAndRegisterBeanDefinitions()
接下来就看一下这个核心方法registerBeanDefinitions
这个方法也很清楚,同样要注意2个事
首先,BeanDefinitionReader组件,也不是自己完成解析的,它要委托给BeanDefinitionDocumentReader来完成(BeanDefinitionDocumentReader还会有一次委托)。
其次,可以看到实际解析的方法registerBeanDefinitions()前后,还各有一个计数,这里调用了getRegistry()方法,来得到一个BeanRegistry。这里实际取到的是DefaultListableBeanFactory,因为这个类实现了BeanRegistry接口。(DefaultListableBeanFactory是一个非常重要的类,它不仅是BefanFactory的默认实现,而且大部分的ApplicationContext实现,内部都持有一个它的实例)
接下来就进入registerBeanDefinitions()方法看看
处理完外围事务之后,进入doRegisterBeanDefinitions()方法,这种命名规范,上文已经介绍过了
这个方法也比较长,拆开来看
如果配置文件中<beans>元素,配有profile属性,就会进入这一段,不过一般都是不会的
然后这里创建了BeanDefinitionParserDelegate对象,preProcessXml()和postProcessXml()都是空方法,核心就是parseBeanDefinitions()方法。这里又把BeanDefinition解析和注册的工作,委托给了BeanDefinitionParserDelegate对象,在parseBeanDefinitions()方法中完成
总的来说,解析工作的委托链是这样的:XmlWebApplicationContext-->XmlBeanDefinitionReader-->DefaultBeanDefinitionDocumentReader-->BeanDefinitionParserDelegate
XmlWebApplicationContext作为最外围的组件,发起解析的请求。
XmlBeanDefinitionReader将配置文件路径封装为Resource,读取出w3c定义的Document对象,然后委托给DefaultBeanDefinitionDocumentReader。
DefaultBeanDefinitionDocumentReader就开始做实际的解析工作了,但是涉及到bean的具体解析,它还是会继续委托给BeanDefinitionParserDelegate来做
接下来在parseBeanDefinitions()方法中发生了什么,以及BeanDefinitionParserDelegate类完成的工作,在下一篇博客中继续说明
protected void loadBeanDefinitions(XmlBeanDefinitionReader reader) throws IOException { String[] configLocations = getConfigLocations(); if (configLocations != null) { for (String configLocation : configLocations) { reader.loadBeanDefinitions(configLocation); } } }
这是解析过程最外围的代码,过程是很清晰的,首先要获取到配置文件的路径,这在之前已经完成了。然后将每个配置文件的路径,作为参数传给BeanDefinitionReader的loadBeanDefinitions方法里
public int loadBeanDefinitions(String location) throws BeanDefinitionStoreException { return loadBeanDefinitions(location, null); }
这个方法又调用了重载方法
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; } }
这个方法就比较长了,不过分析一下,流程还是很清晰的。
BeanDefinitionReader不能直接加载配置文件,需要把配置文件封装成Resource,然后才能调用重载方法loadBeanDefinitions()。所以这个方法其实就是2段,第一部分是委托ResourceLoader将配置文件封装成Resource,第二部分是调用loadBeanDefinitions(),对Resource进行解析
而这里的ResourceLoader,就是前面的XmlWebApplicationContext,因为ApplicationContext接口,是继承自ResourceLoader接口的
Resource也是一个接口体系,在web环境下,这里就是ServletContextResource
接下来进入重载方法loadBeanDefinitions()
public int loadBeanDefinitions(Resource... resources) throws BeanDefinitionStoreException { Assert.notNull(resources, "Resource array must not be null"); int counter = 0; for (Resource resource : resources) { counter += loadBeanDefinitions(resource); } return counter; }
这里就不用说了,就是把每一个Resource作为参数,继续调用重载方法。读spring源码,会发现重载方法特别多
public int loadBeanDefinitions(Resource resource) throws BeanDefinitionStoreException { return loadBeanDefinitions(new EncodedResource(resource)); }
还是重载方法,不过这里对传进来的Resource又进行了一次封装,变成了编码后的Resource,问题不大
public int loadBeanDefinitions(EncodedResource encodedResource) throws BeanDefinitionStoreException { Assert.notNull(encodedResource, "EncodedResource must not be null"); if (logger.isInfoEnabled()) { logger.info("Loading XML bean definitions from " + encodedResource.getResource()); } Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get(); if (currentResources == null) { currentResources = new HashSet<EncodedResource>(4); this.resourcesCurrentlyBeingLoaded.set(currentResources); } if (!currentResources.add(encodedResource)) { throw new BeanDefinitionStoreException( "Detected cyclic loading of " + encodedResource + " - check your import definitions!"); } try { InputStream inputStream = encodedResource.getResource().getInputStream(); try { InputSource inputSource = new InputSource(inputStream); if (encodedResource.getEncoding() != null) { inputSource.setEncoding(encodedResource.getEncoding()); } return doLoadBeanDefinitions(inputSource, encodedResource.getResource()); } finally { 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(); } } }
这个就是loadBeanDefinitions()的最后一个重载方法,比较长,可以拆看来看
Assert.notNull(encodedResource, "EncodedResource must not be null"); if (logger.isInfoEnabled()) { logger.info("Loading XML bean definitions from " + encodedResource.getResource()); } Set<EncodedResource> currentResources = this.resourcesCurrentlyBeingLoaded.get(); if (currentResources == null) { currentResources = new HashSet<EncodedResource>(4); this.resourcesCurrentlyBeingLoaded.set(currentResources); } if (!currentResources.add(encodedResource)) { throw new BeanDefinitionStoreException( "Detected cyclic loading of " + encodedResource + " - check your import definitions!"); }
这第一部分,是处理线程相关的工作,把当前正在解析的Resource,设置为当前Resource
try { InputStream inputStream = encodedResource.getResource().getInputStream(); try { InputSource inputSource = new InputSource(inputStream); if (encodedResource.getEncoding() != null) { inputSource.setEncoding(encodedResource.getEncoding()); } return doLoadBeanDefinitions(inputSource, encodedResource.getResource()); } finally { inputStream.close(); } }
这里是第二部分,是核心,首先把Resource还原为InputStream,然后调用实际解析的方法doLoadBeanDefinitions()。可以看到,这种命名方式是很值得学习的,一种业务方法,比如parse(),可能需要做一些外围的工作,然后实际解析的方法,可以命名为doParse()。这种doXXX()的命名方法,在很多开源框架中都有应用,比如logback等
接下来就看一下这个doLoadBeanDefinitions()方法
protected int doLoadBeanDefinitions(InputSource inputSource, Resource resource) throws BeanDefinitionStoreException { try { int validationMode = getValidationModeForResource(resource); Document doc = this.documentLoader.loadDocument( inputSource, getEntityResolver(), this.errorHandler, validationMode, isNamespaceAware()); return registerBeanDefinitions(doc, resource); } catch (BeanDefinitionStoreException ex) { throw ex; } catch (SAXParseException ex) { throw new XmlBeanDefinitionStoreException(resource.getDescription(), "Line " + ex.getLineNumber() + " in XML document from " + resource + " is invalid", ex); } catch (SAXException ex) { throw new XmlBeanDefinitionStoreException(resource.getDescription(), "XML document from " + resource + " is invalid", ex); } catch (ParserConfigurationException ex) { throw new BeanDefinitionStoreException(resource.getDescription(), "Parser configuration exception parsing XML from " + resource, ex); } catch (IOException ex) { throw new BeanDefinitionStoreException(resource.getDescription(), "IOException parsing XML document from " + resource, ex); } catch (Throwable ex) { throw new BeanDefinitionStoreException(resource.getDescription(), "Unexpected exception parsing XML document from " + resource, ex); } }
抛开处理异常的若干catch体,只看实体部分
int validationMode = getValidationModeForResource(resource); Document doc = this.documentLoader.loadDocument( inputSource, getEntityResolver(), this.errorHandler, validationMode, isNamespaceAware()); return registerBeanDefinitions(doc, resource);
这个流程也是很清晰的,首先确认校验模式,然后委托documentLoader,将InputStream读取成标准的Document对象,然后调用registerBeanDefinitions(),进行解析工作
这里注意两点
首先这个Document对象,是W3C定义的标准XML对象,跟spring无关。
其次这个registerBeanDefinitions方法,我觉得命名有点误导性。因为这个时候实际上解析还没有开始,怎么直接就注册了呢。比较好的命名,我觉得可以是parseAndRegisterBeanDefinitions()
接下来就看一下这个核心方法registerBeanDefinitions
public int registerBeanDefinitions(Document doc, Resource resource) throws BeanDefinitionStoreException { BeanDefinitionDocumentReader documentReader = createBeanDefinitionDocumentReader(); documentReader.setEnvironment(this.getEnvironment()); int countBefore = getRegistry().getBeanDefinitionCount(); documentReader.registerBeanDefinitions(doc, createReaderContext(resource)); return getRegistry().getBeanDefinitionCount() - countBefore; }
这个方法也很清楚,同样要注意2个事
首先,BeanDefinitionReader组件,也不是自己完成解析的,它要委托给BeanDefinitionDocumentReader来完成(BeanDefinitionDocumentReader还会有一次委托)。
其次,可以看到实际解析的方法registerBeanDefinitions()前后,还各有一个计数,这里调用了getRegistry()方法,来得到一个BeanRegistry。这里实际取到的是DefaultListableBeanFactory,因为这个类实现了BeanRegistry接口。(DefaultListableBeanFactory是一个非常重要的类,它不仅是BefanFactory的默认实现,而且大部分的ApplicationContext实现,内部都持有一个它的实例)
接下来就进入registerBeanDefinitions()方法看看
public void registerBeanDefinitions(Document doc, XmlReaderContext readerContext) { this.readerContext = readerContext; logger.debug("Loading bean definitions"); Element root = doc.getDocumentElement(); doRegisterBeanDefinitions(root); }
处理完外围事务之后,进入doRegisterBeanDefinitions()方法,这种命名规范,上文已经介绍过了
protected void doRegisterBeanDefinitions(Element root) { String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE); if (StringUtils.hasText(profileSpec)) { Assert.state(this.environment != null, "environment property must not be null"); String[] specifiedProfiles = StringUtils.tokenizeToStringArray(profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS); if (!this.environment.acceptsProfiles(specifiedProfiles)) { return; } } // any nested <beans> elements will cause recursion in this method. In // order to propagate and preserve <beans> default-* attributes correctly, // keep track of the current (parent) delegate, which may be null. Create // the new (child) delegate with a reference to the parent for fallback purposes, // then ultimately reset this.delegate back to its original (parent) reference. // this behavior emulates a stack of delegates without actually necessitating one. BeanDefinitionParserDelegate parent = this.delegate; this.delegate = createHelper(readerContext, root, parent); preProcessXml(root); parseBeanDefinitions(root, this.delegate); postProcessXml(root); this.delegate = parent; }
这个方法也比较长,拆开来看
String profileSpec = root.getAttribute(PROFILE_ATTRIBUTE); if (StringUtils.hasText(profileSpec)) { Assert.state(this.environment != null, "environment property must not be null"); String[] specifiedProfiles = StringUtils.tokenizeToStringArray(profileSpec, BeanDefinitionParserDelegate.MULTI_VALUE_ATTRIBUTE_DELIMITERS); if (!this.environment.acceptsProfiles(specifiedProfiles)) { return; } }
如果配置文件中<beans>元素,配有profile属性,就会进入这一段,不过一般都是不会的
BeanDefinitionParserDelegate parent = this.delegate; this.delegate = createHelper(readerContext, root, parent); preProcessXml(root); parseBeanDefinitions(root, this.delegate); postProcessXml(root); this.delegate = parent;
然后这里创建了BeanDefinitionParserDelegate对象,preProcessXml()和postProcessXml()都是空方法,核心就是parseBeanDefinitions()方法。这里又把BeanDefinition解析和注册的工作,委托给了BeanDefinitionParserDelegate对象,在parseBeanDefinitions()方法中完成
总的来说,解析工作的委托链是这样的:XmlWebApplicationContext-->XmlBeanDefinitionReader-->DefaultBeanDefinitionDocumentReader-->BeanDefinitionParserDelegate
XmlWebApplicationContext作为最外围的组件,发起解析的请求。
XmlBeanDefinitionReader将配置文件路径封装为Resource,读取出w3c定义的Document对象,然后委托给DefaultBeanDefinitionDocumentReader。
DefaultBeanDefinitionDocumentReader就开始做实际的解析工作了,但是涉及到bean的具体解析,它还是会继续委托给BeanDefinitionParserDelegate来做
接下来在parseBeanDefinitions()方法中发生了什么,以及BeanDefinitionParserDelegate类完成的工作,在下一篇博客中继续说明
发表评论
-
小读spring ioc源码(五)——BeanDefinitionDocumentReader
2012-07-28 13:11 2816上一篇博客说到,BeanDefinition的解析,已经走到了 ... -
小读spring ioc源码(三)——XmlWebApplicationContext初始化的整体过程
2012-07-12 16:54 2923上一篇说到,ContextLoader ... -
小读spring ioc源码(二)——ContextLoaderListener
2012-06-25 18:41 2872实际开发中,比较多的项目是web项目,这时候加载spring, ... -
小读spring ioc源码(一)——整体介绍
2012-06-18 22:59 2603最近在读spring ioc的源码,用EA画了几张比较清楚的类 ... -
读logback源码系列文章(八)——记录日志的实际工作类Encoder
2011-10-17 20:34 3012本系列的博客从logback怎么对接slf4j开始,逐步介绍了 ... -
读logback源码系列文章(七)——配置的实际工作类Action
2011-10-11 22:59 3564上篇博客介绍了ContextInitializer类如何把框架 ... -
读logback源码系列文章(六)——ContextInitializer
2011-10-09 21:46 6833放了一个长假回来啦,继续写本系列博客 这篇博客我们接着上一篇 ... -
读logback源码系列文章(五)——Appender
2011-09-16 21:03 13847明天要带老婆出国旅游 ... -
读logback源码系列文章(四)——记录日志
2011-09-12 02:22 4434今天晚上本来想来写一下Logger怎么记录日志,以及Appen ... -
读logback源码系列文章(三)——创建Logger
2011-09-07 21:35 6214上一篇博客介绍了logback的StaticLoggerBin ... -
读logback源码系列文章(二)——提供ILoggerFactory
2011-09-07 20:07 6661上篇博客介绍了logback是 ... -
读logback源码系列文章(一)——对接slf4j
2011-08-29 02:43 7537以前也读过一些开源项目的源码,主要是spring和ant,不过 ...
相关推荐
《Spring IOC源码解析(一)——整体介绍》 在深入理解Spring框架的过程中,源码分析是不可或缺的一环。本文将对Spring的IOC(Inversion of Control,控制反转)容器的源码进行初步探讨,旨在帮助读者从整体上把握...
### Spring IoC源码解读 #### 一、Spring IoC 容器概述 Spring框架的核心功能之一便是依赖注入(Dependency Injection, DI),而这一功能主要通过IoC容器来实现。在Spring框架中,IoC容器负责管理应用对象的生命...
### Spring源码分析_Spring_IOC:深入理解Spring的IOC容器机制 #### 基本概念与核心作用 在探讨Spring框架的核心组件之一——IOC(Inversion of Control,控制反转)容器之前,首先需要理解它在Spring框架中的角色...
在本文中,我们将深入探讨Spring IOC的概念、工作原理,并通过源码分析来理解其实现方式。 首先,控制反转(IOC)是指将对象的创建和管理权限交由一个外部容器(即Spring容器)来负责,而不是由代码本身直接控制。...
5. **IoC容器**:Spring的IoC容器是基于Java集合框架的,通过反射和实例化Bean来管理对象生命周期。`DefaultListableBeanFactory`是默认的Bean工厂实现,`BeanDefinitionReader`读取配置信息并注册到Bean工厂。 6. ...
总之,"Spring_0700_IOC_Collections"涵盖了Spring框架中关于IoC容器处理集合依赖的重要知识,包括XML配置、Java配置、注解注入以及源码分析等多个方面。通过学习这部分内容,开发者可以更深入地理解Spring的IoC机制...
3. **IoC(控制反转)与DI(依赖注入)**:在Spring中,bean的创建和初始化由Spring容器控制,这就是所谓的控制反转。依赖注入则是通过容器将bean所需的服务或对象传递给它,而不是由bean自己去查找。这大大提高了...
### Spring源码底层分析知识点详解 #### 一、Spring框架简介 Spring框架是一个开源的Java平台,用于构建企业级应用程序和服务。它通过提供强大的依赖注入(Dependency Injection, DI)、面向切面编程(Aspect-...
Spring框架是Java开发中不可或缺的一部分,它以其IoC(Inversion of Control)和AOP(Aspect Oriented Programming)的核心特性,极大地简化了企业级应用的开发。本文将深入探讨Spring框架的源码,帮助开发者更好地...
Spring框架是Java开发中不可或缺的一部分,它以其IoC(Inversion of Control,控制反转)和AOP(Aspect Oriented Programming,面向切面编程)两大核心特性,极大地简化了企业级应用的开发工作。本篇文章将深入探讨...
Spring核心容器IOC原理实例解析是通过BeanFactory、BeanDefinition和BeanDefinitionReader等接口来实现的。这些接口提供了一些基本的方法来管理Bean对象,例如获取Bean实例、判断Bean是否存在、获取Bean的别名等。...
标题“Spring_0700_IOC_Collections”暗示了我们即将探讨的是Spring框架中的依赖注入(IOC,Inversion of Control)与集合对象的处理。在这个主题下,我们将深入理解Spring如何管理容器中的集合类型,如List、Set、...
简单的说,在web容器中,通过ServletContext为Spring的IOC容器提供宿主环境,对应的建立起一个IOC容器的体系。其中,首先需要建立的是根上下文,这个上下文持有的对象可以有业务对象,数据存取对象,资源,事物管理...
在本篇讨论中,我们将深入探究Spring框架2.5.6版本中的IoC(Inversion of Control,控制反转)容器。IoC是Spring的核心特性,它使得开发者能够更灵活地管理对象及其依赖关系,从而降低了代码间的耦合度。本文将通过...
在深入探讨Spring的XML解析原理之前,让我们先理解Spring框架的核心概念:控制反转(Inversion of Control,简称IOC)和依赖注入(Dependency Injection,简称DI)。Spring通过IOC和DI实现了对象之间的解耦,使得...
在Spring框架中,IoC(Inversion of Control,控制反转)是核心设计理念之一,它通过管理对象(Bean)的生命周期和依赖关系,将控制权从应用代码转移到框架。BeanFactory和ApplicationContext是实现IoC的主要接口,...
的开源项目,简化了Spring的IoC容器和AOP,API名字都是仿照Spring,所以临摹了一下IoC,后续打算临摹下它的AOP。 我的项目地址为 ,目前只实现了IoC容器,后续将会有更新AOP实现 大体结构 项目是以使用...
Bean工厂是Spring管理对象的主要容器,而IoC和DI则是Spring如何实现解耦和提高代码可维护性的关键机制。通过使用XML配置文件,我们可以声明Bean的定义,包括它们的属性、依赖关系以及生命周期方法。 接下来,我们来...