Spring创建Bean的过程
beans包提供了以编程方式管理和操作bean的基本功能 而context包增加了ApplicationContext 它以一种更加面向框架的方式增强了BeanFactory的功能
context包的基础是位于ntext包中的ApplicationContext接口 它是由BeanFactory接口派生而来的 提供了BeanFactory的所有功能 为了以一种更面向框架的方式工作 使用分层和继承关系的上下文 context包还提供了一下的功能
a MessageSource 对I N消息的访问
b 资源访问 例如URL和文件
c 事件传递给是吸纳了ApplicationListener接口的bean
d 载入多个(有继承关系）上下文 使得每一个上下文都专注于一个特定的层是 比如应用的web层
国际化支持
ApplicationContext扩展了MessageSource接口 因而提供了messaging的功能(I N或者国际化) 同NestingMessageSource一起使用 还能处理分级的信息 这些是spring提供的处理信息的基本接口
当一个ApplicationContext被加载时 它会自动查找在context中定义的MessageSource bean 这个bean必须交做messageSource 如果找了这样一个bean 所有对上述方法的调用将被委托给找到的messageSource 如果没有找到messageSource ApplicationContext将会尝试查找他的父亲是否包含有同名的bean 如果有 它将把找到的bean作为MessageSource 如果他没有找到任何的信息处理源 他会创建一个StaticMessageSource
Spring目前提供了两个MessageSource的实现 他们是
ResourceBundleMessageSource和StaticMessageSource 两者都实现了NestingMessageSource一边能够处理嵌套的信息 StaticMessageSource很少被使用 但是他提供了编程的方式向source增加信息 我们经常使用的是ResourceBundleMessageSource
在Spring中使用资源
ApplicationContext继承了ResourceLoader接口 在这个接口中 定义了getResource()方法 如下
Resource getResource(String location)
该方法返回一个资源句柄 这个句柄应该总是一个可重复使用的资源描述符 允许多次调用getInputStream();
getResource()方法的参数是一个资源访问地址 例如
file:\c:/test data
classpath:test data(从classpath路径中查找test dat文件并返回他的资源句柄)
WEB INF/test dat
注意 getResource()方法返回的Resource句柄并不意味着资源实际存在 你需要调用Resource接口的exists()方法判断资源是否存在
Resource提供了与协议无关的特性
事件传递
ApplicationContext中的时间处理是通过AppcationEvent类和ApplicationListener接口来提供的 如果上下文中部署了一个实现了ApplicationListener接口的bean 每次一个ApplicationEvent发布到ApplicationContext时 那个bean就会被通知 实质撒谎功能 这是标准的Observer设计模式
Spring提供的三个标准事件
a ContextRefreshedEvent
当ApplicationContext已经初始化或刷新后发送的事件 这里初始化意味着 所有的bean被装载 singleton被预实例化 以及ApplicationContext已经准备好
b ContextClosedEvent
当使用ApplicationContext的close()方法结束上下文的时候发送的事件 这里意味着 singleton被销毁
c RequestHandledEvent
一个与web相关的事件 告诉所有的bean一个HTTP请求已经被响应了（这个时间将会在一个请求结束后被发送—) 注意 这个时间只能应用于使用了Spring的DispatcherServlet的web应用
=========================================================================================
LifeCycle
InitializingBean/init method
实现 springframework beans factory InitializingBean接口允许一个bean在他的所有必需的属性被BeanFactory设置后 来执行初始化的工作
当然可以使用init method来取代实现这个接口 以让应用不与sprin *** 生耦合
如果一个bean既实现了InitializingBean 又指定了init method 则spring会先调InitializingBean的方法 在调init method指定的方法
DisposableBean/destroy method
实现 springframework beans factory DisposableBean接口允许一个bean 可以在包含他的BeanFactory销毁的时候得到一个回调
注意 BeanFactory对bean的管理默认是单实例的 如果bean不是单示例的 spring就不能管理他的生命周期
BeanFactoryAware
对于实现了 springframework beans factory BeanFactoryAware接口的类 当它被BeanFactory创建后 它会拥有一个指向创建他的BeanFactory的引用
BeanNameAware
如果一个bean实现了 springframework beans factory BeanNameAware接口 并且被部署到一个BeanFactory中 那么BeanFactory就会通过这个接口来调用bean 以便通知这个bean他被部署的id 这个回调发生在普通的bean属性设置之后 在初始化回调之前 比如InitializingBean的afterProperteis方法（或者自定义的init method)
Bean的生命周期如下
Bean的构造
调用setXXX()方法设置Bean的属性
调用BeanNameAware的setBeanName();
调用BeanFactoryAware的setBeanFactory()方法
调用BeanPostProcessor的postProcessBeforeInitialization()方法
调用InitializingBean的afterPropertiesSet()方法
调用自定义的初始化方法
调用BeanPostProcessor类的postProcessAfterInitialization()方法
调用DisposableBean的destroy()方法
调用自定义的销毁方法
========================================================================================
扩展Spring的Ioc框架
Spring框架的IoC组件被设计为可扩展的 通常应用开发者并不需要子类化各个BeanFactory或ApplicationContext的实现类 通过插入特定接入接口的实现 Spring的IoC容器就可以不受限制的进行扩展
BeanPostProcessor:在创建bean之后调用
BeanFactoryPostProcessors 在创建bean之前调用
如果想在spring容器完成一个bean的实例化后 再对他进行初始化之前或之后执行一些自定义的逻辑 可以插入一个或多个BeanPostProcessor的实例
springframewonfig BeanPostProcessor接口包含了两个回调方法 当一个类作为容器的后置处理器(post processor）被注册后 对于由容器创建的每个bean实例 在任一个初始化方法（例如afterProperties和利用init method声明的方法）调用前后后置处理器会从容器中分别获取一个回调 后置处理器可以随意对这个bean实例执行他所期望的动作 也包括完全忽略这个回调
BeanFactory和ApplicationContext对待bean后置处理器稍有不同
ApplicationContext会自动检测任何提供给他的在配置元数据中定义实现了BeanPostProcessor接口的bean 并把它们注册为后置处理器 然后在容器创建bean的适当时候调用它 部署一个后置处理器同部署其他的bean并没有什么区别 无需其他的动作 而另一方面 当使用BeanFactory的时候 bean后置处理器鼻息编写代码显示的去注册
我们看到的下一个扩展点是
springframewonfig BeanFactoryPostProcessor 出一个主要的区别外 这个接口的寓意类似于BeanPostProcessor BeanFactoryPostProcessor作用于bean的定义上（例如 提供给容易的配置元数据） 也就是说 Spring IoC容器允许BeanFactoryPostProcessor在容易实际实例化任何bean之前读取配置元数据并可能修改它
Spring包含了许多已有的bean工厂后置处理器 例如PropertyResourceConfigure和PropertyPlaceHolderConfigure以及 BeanNameAutoProxyCreator
在一个BeanFactory中 应用BeanFactoryPostProcessor需要手工编码实现 而ApplicationContext则会检测部署在它之上实现了BeanFactoryPostProcessor接口的bean 并在适当的时候自动把它们用做bean工作后置处理器 部署一个后置处理器同部署其他的bean并没有什么区别 无需其他的动作
PropertyPlaceholderConfigurer
作为一个bean工厂后置处理器的实现 可以用来将BeanFactory定义中的一些属性值放置到另一个单独的Java Properties格式的文件中 这就允许用户在部署应用的时候定制一些关键属性（例如数据库URL 用户名和密码） 而不用对主XML定义文件或容器所用文件进行复杂和危险的修改
PropertyOverrideConfigurer
类似于PropertyPlaceholderConfigurer 但是与后者相比 前者对于bean属性可以有却兴致或者根本没有值 如果起覆盖左右的Properties文件没有某个bean属性的内容 那么将使用却行的上下文定义
bean工厂的定义并不会议室到被覆盖 所以仅仅擦看XML定义文件并不能立刻明显的知道覆盖配置是否被起作用了 在多个PropertyOverrideConfigurer对一个bean属性定义了不同的值的时候 最后一个将取胜
***他使用beanName propertyName来指定值 而且不需要在bean中进行配置
注册用户自定义的PropertyEditors
a 当用字符串值设置bean的属性时 BeanFactory实质上使用了标准的JavaBeans的PropertyEditor将这些String转换为属性的复杂类型 Spring预先注册了很多定制的PropertyEditor（比如 将一个字符串表示我的classname转换成阵阵的Class对象）
b 要编写一个属性编辑器 可以实现PropertyEditor接口 更为简便的方式是从PropertyEditorSupport类继承
要使用自定义的PropertyEditors 必须使用 springframewonfig CustomEditorConfigurer来注册自定义的属性编辑器
FactoryBean可以用来做代理
springframework beans factory FactoryBean
**要想得到FactoryBean本身 需要在beanName前面加上& 即&beanName
*********BeanFactory和ApplicationContext的区别*********
ApplicationContext是在ApplicationContext初始化的时候就把所有的bean都创建好了 并存放在缓存中
lishixinzhi/Article/program/Java/ky/201311/28565
