码农小汪-spring框架学习之5-spring Container Extension Points 容器扩展点

通常开发者无需自己实现 APplicationContext，而是使用插件扩展 Spring IoC容器，插件是某些指定的集成接口的实现

通过两个接口对于容器进行扩展。
一种为Bean后处理器，这种对于Bean进行后处理，进行额外的功能的增强
一种容器后处理器。这种是对IOC容器进行后处理，用于对于容器的增强。
感觉翻译过来好别扭。

Customizing beans using a BeanPostProcessor自定义bean进行增强工作！

这个我们之前好像是看到过的吧，这个玩意！我想我们应该是非常的熟悉啦~

package org.springframework.beans.factory.config;import org.springframework.beans.BeansException;/** * @author Juergen Hoeller * @since 10.10.2003 * @see InstantiationAwareBeanPostProcessor * @see DestructionAwareBeanPostProcessor * @see ConfigurableBeanFactory#addBeanPostProcessor * @see BeanFactoryPostProcessor */public interface BeanPostProcessor    /**     * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet     */    Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException;    /**     * @see org.springframework.beans.factory.InitializingBean#afterPropertiesSet     * @see org.springframework.beans.factory.FactoryBean     */    Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException;}

Bean后处理器是一种特殊的Bean,这种Bean不对外提供服务，无需Id属性。主要是负责都对于容器中的其他Bean 执行后处理器。

容器中一旦实现了自己的后处理器，Bean后处理器就会自动的启动。在容器中每个Bean创建时加入工作。他们的回调机制就是最开始，和最后。也就是会在InitializingBean的after.。。set之前，init()之前。最后再调用自己的After…

一个bean工厂后处理器执行时自动宣布在一个ApplicationContext,以应用更改配置元数据 定义容器。 spring包含许多预定义的bean工厂 后处理器,如PropertyOverrideConfigurer和PropertyPlaceholderConfigurer。 一个自定义BeanFactoryPostProcessor也可以使用, 例如,注册自定义属性编辑器。一个ApplicationContext自动检测任何bean部署到它 实现BeanFactoryPostProcessor接口。 它使用这些bean作为bean工厂 后处理器,在适当的时间。 您可以部署这些后处理器bean 你会其他bean。

一个bean工厂后处理器执行时自动宣布在一个ApplicationContext,以应用更改配置元数据 定义容器。 春天包含许多预定义的bean工厂 后处理器,如PropertyOverrideConfigurer和PropertyPlaceholderConfigurer。 一个自定义BeanFactoryPostProcessor也可以使用, 例如,注册自定义属性编辑器。
一个ApplicationContext自动检测任何bean部署到它 实现BeanFactoryPostProcessor接口。 它使用这些bean作为bean工厂 后处理器,在适当的时间。 您可以部署这些后处理器bean 你会其他bean。

Customizing configuration metadata with a BeanFactoryPostProcessor类名替换.后处理器有点拦截器的感觉，你是不是也是感觉到了！

这个使用的环境挺多的，我也是使用过这个东西的，挺简单的，配置文件中使用出来的话！那就是非常的棒啦！
您使用PropertyPlaceholderConfigurer外部化从bean属性值 使用标准Java定义在一个单独的文件Properties格式。 这样做 使人将应用程序部署到自定义特定于环境的属性 如数据库网址和密码,没有复杂的或修改的风险 主XML定义文件或文件的容器。

考虑下面的基于xml的配置元数据片段,其中DataSource定义用占位符。 从一个例子显示了属性配置 外部Properties文件。 在运行时,一个PropertyPlaceholderConfigurer应用于 将取代一些属性的元数据的数据源。 的值来代替 被指定为占位符的形式${property-name}它遵循蚂蚁/ log4j / JSP EL风格。

这个就在配置文件中去寻找啦

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">    <property name="locations" value="classpath:com/foo/jdbc.properties"/></bean><bean id="dataSource" destroy-method="close"        class="org.apache.commons.dbcp.BasicDataSource">    <property name="driverClassName" value="${jdbc.driverClassName}"/>    <property name="url" value="${jdbc.url}"/>    <property name="username" value="${jdbc.username}"/>    <property name="password" value="${jdbc.password}"/></bean>

与context名称空间在Spring 2.5中引入的,它是可能的配置 财产占位符和一个专门的配置元素。 一个或多个位置 提供一个以逗号分隔的location属性。其实这些配置都差不多，看你自己怎么去配置完成这个功能啦！

<context:property-placeholder location="classpath:com/foo/jdbc.properties"/>

PropertyOverrideConfigurer，是另一个 ben 工厂的 post-processor,类似于PropertyPlaceholderConfigurer，但是有不同之处， bean 源定义可以设置默认值或者根本不设置值。若一个 overriding Properties 文件不包含某个 bean 属性,就使用默认的上下文定义注意 bean 定义并不知道它会被重写，所以使用了重写配置在 XML 配置中并不直观。如果有多个 PropertyOverrideConfigurer 实例为相同的 bean 属性配置了不同的值，最后一个实例配置生效。

使用 FactoryBean 自定义实例化逻辑 感觉用的少啊~但是学嘛，还是看哈。和实际工作无关

对象实现 org.springframework.beans.factory.FactoryBean 接口,则成为它本身的工厂。FactoryBean 接口是 Spring IoC 容器实例化逻辑的扩展点。假如初始化代码非常复杂，此时使用 java 编码比使用 XML 配置更容易表达。这种场景中，就可以自定义 FactoryBean,在类中撰写复杂的初始化程序，并将其作为插件加入到容器中。
FactoryBean 接口有 3 个方法：
Object getObject():返回本工厂创建的对象实例。此实例也许是共享的，依赖于该工厂返回的是单例或者是原型。
boolean isSingleton():如果 FactoryBean 返回的是单例,该方法返回值为true,否则为 false
Class getObjectType():返回对象类型。对象类型是 getObject()方法返回 的对象的类型，如果不知道的类型则返回 null。

The FactoryBean concept and interface is used in a number of places within the Spring Framework; more than 50 implementations of the FactoryBean interface ship with Spring itself.

When you need to ask a container for an actual FactoryBean instance itself instead of the bean it produces, preface the bean’s id with the ampersand symbol ( &) when calling the getBean() method of the ApplicationContext. So for a given FactoryBean with an id of myBean, invoking getBean(“myBean”) on the container returns the product of the FactoryBean; whereas, invoking getBean(“&myBean”) returns the FactoryBean instance itself.