容器扩展点

通常，应用程序开发人员不需要子类化 ApplicationContext 实现类。相反，可以通过插入特殊集成接口的实现来扩展 Spring IoC 容器。接下来的几节将描述这些集成接口。

使用 BeanPostProcessor 自定义 Bean

BeanPostProcessor 接口定义了回调方法，您可以实现这些方法来提供您自己的（或覆盖容器的默认）实例化逻辑、依赖项解析逻辑等。如果您希望在 Spring 容器完成实例化、配置和初始化 bean 之后实现一些自定义逻辑，您可以插入一个或多个自定义 BeanPostProcessor 实现。

您可以配置多个 BeanPostProcessor 实例，并且可以通过设置 order 属性来控制这些 BeanPostProcessor 实例的运行顺序。只有当 BeanPostProcessor 实现了 Ordered 接口时，您才能设置此属性。如果您编写自己的 BeanPostProcessor，您也应该考虑实现 Ordered 接口。有关更多详细信息，请参阅 BeanPostProcessor 和 Ordered 接口的 javadoc。另请参阅关于 以编程方式注册 BeanPostProcessor 实例 的说明。

BeanPostProcessor 实例作用于 bean（或对象）实例。也就是说，Spring IoC 容器实例化一个 bean 实例，然后 BeanPostProcessor 实例执行它们的工作。 BeanPostProcessor 实例的作用域是每个容器。这只有在您使用容器层次结构时才相关。如果您在一个容器中定义一个 BeanPostProcessor，它只对该容器中的 bean 进行后处理。换句话说，在一个容器中定义的 bean 不会被另一个容器中定义的 BeanPostProcessor 进行后处理，即使这两个容器是同一层次结构的一部分。 要更改实际的 bean 定义（即定义 bean 的蓝图），您需要使用 BeanFactoryPostProcessor，如 使用 BeanFactoryPostProcessor 自定义配置元数据 中所述。

org.springframework.beans.factory.config.BeanPostProcessor 接口由正好两个回调方法组成。当此类被注册为容器的后处理器时，对于容器创建的每个 bean 实例，后处理器在容器初始化方法（例如 InitializingBean.afterPropertiesSet() 或任何声明的 init 方法）被调用之前和任何 bean 初始化回调之后，都会从容器获得回调。后处理器可以对 bean 实例执行任何操作，包括完全忽略回调。bean 后处理器通常检查回调接口，或者它可以用代理包装一个 bean。一些 Spring AOP 基础设施类被实现为 bean 后处理器，以提供代理包装逻辑。

ApplicationContext 会自动检测配置元数据中定义的所有实现 BeanPostProcessor 接口的 bean。ApplicationContext 将这些 bean 注册为后处理器，以便它们可以在以后创建 bean 时被调用。Bean 后处理器可以像任何其他 bean 一样部署到容器中。

请注意，当在配置类上使用 @Bean 工厂方法声明 BeanPostProcessor 时，工厂方法的返回类型应该是实现类本身或至少是 org.springframework.beans.factory.config.BeanPostProcessor 接口，清楚地表明该 bean 的后处理器性质。否则，ApplicationContext 无法在完全创建它之前通过类型自动检测到它。由于 BeanPostProcessor 需要尽早实例化才能应用于上下文中其他 bean 的初始化，因此这种早期类型检测至关重要。

以编程方式注册 BeanPostProcessor 实例

虽然 BeanPostProcessor 注册的推荐方法是通过 ApplicationContext 自动检测（如前所述），但您可以使用 addBeanPostProcessor 方法以编程方式将其注册到 ConfigurableBeanFactory。当您需要在注册之前评估条件逻辑，甚至在层次结构中跨上下文复制 bean 后处理器时，这会很有用。但是请注意，以编程方式添加的 BeanPostProcessor 实例不遵循 Ordered 接口。在这里，注册顺序决定了执行顺序。另请注意，以编程方式注册的 BeanPostProcessor 实例总是优先于通过自动检测注册的实例进行处理，无论是否存在任何显式排序。
BeanPostProcessor 实例和 AOP 自动代理

实现 BeanPostProcessor 接口的类是特殊的，并且被容器区别对待。所有 BeanPostProcessor 实例以及它们直接引用的 bean 都在启动时实例化，作为 ApplicationContext 特殊启动阶段的一部分。接下来，所有 BeanPostProcessor 实例都以排序的方式注册并应用于容器中的所有后续 bean。因为 AOP 自动代理本身就是作为 BeanPostProcessor 实现的，所以 BeanPostProcessor 实例以及它们直接引用的 bean 都不能进行自动代理，因此不会有切面织入到它们中。 对于任何此类 bean，您应该看到一条信息性日志消息：Bean someBean is not eligible for getting processed by all BeanPostProcessor interfaces (for example: not eligible for auto-proxying)。 如果您通过自动装配或 @Resource（可能会回退到自动装配）将 bean 注入到 BeanPostProcessor 中，Spring 在搜索类型匹配的依赖项候选时可能会访问意外的 bean，从而使它们不适用于自动代理或其他类型的 bean 后处理。例如，如果您有一个用 @Resource 注解的依赖项，其中字段或 setter 名称不直接对应于 bean 的声明名称，并且没有使用名称属性，Spring 会访问其他 bean 以按类型匹配它们。

以下示例展示了如何在 ApplicationContext 中编写、注册和使用 BeanPostProcessor 实例。

示例：Hello World，BeanPostProcessor 风格

第一个示例说明了基本用法。该示例展示了一个自定义 BeanPostProcessor 实现，它在容器创建每个 bean 时调用其 toString() 方法，并将结果字符串打印到系统控制台。

以下清单显示了自定义 BeanPostProcessor 实现类的定义：

  • Java

  • Kotlin

package scripting;

import org.springframework.beans.factory.config.BeanPostProcessor;

public class InstantiationTracingBeanPostProcessor implements BeanPostProcessor {

	// simply return the instantiated bean as-is
	public Object postProcessBeforeInitialization(Object bean, String beanName) {
		return bean; // we could potentially return any object reference here...
	}

	public Object postProcessAfterInitialization(Object bean, String beanName) {
		System.out.println("Bean '" + beanName + "' created : " + bean.toString());
		return bean;
	}
}
package scripting

import org.springframework.beans.factory.config.BeanPostProcessor

class InstantiationTracingBeanPostProcessor : BeanPostProcessor {

	// simply return the instantiated bean as-is
	override fun postProcessBeforeInitialization(bean: Any, beanName: String): Any? {
		return bean // we could potentially return any object reference here...
	}

	override fun postProcessAfterInitialization(bean: Any, beanName: String): Any? {
		println("Bean '$beanName' created : $bean")
		return bean
	}
}

以下 beans 元素使用 InstantiationTracingBeanPostProcessor：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:lang="http://www.springframework.org/schema/lang"
	xsi:schemaLocation="http://www.springframework.org/schema/beans
		https://www.springframework.org/schema/beans/spring-beans.xsd
		http://www.springframework.org/schema/lang
		https://www.springframework.org/schema/lang/spring-lang.xsd">

	<lang:groovy id="messenger"
			script-source="classpath:org/springframework/scripting/groovy/Messenger.groovy">
		<lang:property name="message" value="Fiona Apple Is Just So Dreamy."/>
	</lang:groovy>

	<!--
	when the above bean (messenger) is instantiated, this custom
	BeanPostProcessor implementation will output the fact to the system console
	-->
	<bean class="scripting.InstantiationTracingBeanPostProcessor"/>

</beans>

请注意 InstantiationTracingBeanPostProcessor 是如何仅仅被定义的。它甚至没有名称，而且，因为它是一个 bean，所以您可以像注入任何其他 bean 一样注入它。（前面的配置还定义了一个由 Groovy 脚本支持的 bean。Spring 动态语言支持在 动态语言支持 一章中详细介绍。）

以下 Java 应用程序运行上述代码和配置：

  • Java

  • Kotlin

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.ClassPathXmlApplicationContext;
import org.springframework.scripting.Messenger;

public final class Boot {

	public static void main(final String[] args) throws Exception {
		ApplicationContext ctx = new ClassPathXmlApplicationContext("scripting/beans.xml");
		Messenger messenger = ctx.getBean("messenger", Messenger.class);
		System.out.println(messenger);
	}

}
import org.springframework.beans.factory.getBean

fun main() {
	val ctx = ClassPathXmlApplicationContext("scripting/beans.xml")
	val messenger = ctx.getBean<Messenger>("messenger")
	println(messenger)
}

上述应用程序的输出类似于以下内容：

Bean 'messenger' created : org.springframework.scripting.groovy.GroovyMessenger@272961 org.springframework.scripting.groovy.GroovyMessenger@272961

示例：AutowiredAnnotationBeanPostProcessor

结合自定义 BeanPostProcessor 实现使用回调接口或注解是扩展 Spring IoC 容器的常用方法。一个示例是 Spring 的 AutowiredAnnotationBeanPostProcessor — 一个随 Spring 分发提供的 BeanPostProcessor 实现，它自动装配注解的字段、setter 方法和任意配置方法。

使用 BeanFactoryPostProcessor 自定义配置元数据

我们接下来要看的扩展点是 org.springframework.beans.factory.config.BeanFactoryPostProcessor。此接口的语义与 BeanPostProcessor 相似，但有一个主要区别：BeanFactoryPostProcessor 作用于 bean 配置元数据。也就是说，Spring IoC 容器允许 BeanFactoryPostProcessor 在容器实例化除 BeanFactoryPostProcessor 实例之外的任何 bean 之前 读取配置元数据并可能更改它。

您可以配置多个 BeanFactoryPostProcessor 实例，并且可以通过设置 order 属性来控制这些 BeanFactoryPostProcessor 实例的运行顺序。但是，您只能在 BeanFactoryPostProcessor 实现了 Ordered 接口时设置此属性。如果您编写自己的 BeanFactoryPostProcessor，您也应该考虑实现 Ordered 接口。有关更多详细信息，请参阅 BeanFactoryPostProcessor 和 Ordered 接口的 javadoc。

如果您想更改实际的 bean 实例（即从配置元数据创建的对象），那么您需要使用 BeanPostProcessor（前面在 使用 BeanPostProcessor 自定义 Bean 中描述）。虽然在 BeanFactoryPostProcessor 中处理 bean 实例在技术上是可行的（例如，通过使用 BeanFactory.getBean()），这样做会导致 bean 过早实例化，违反了标准容器生命周期。这可能会导致负面副作用，例如绕过 bean 后处理。 此外，BeanFactoryPostProcessor 实例的作用域是每个容器。这只有在您使用容器层次结构时才相关。如果您在一个容器中定义一个 BeanFactoryPostProcessor，它只应用于该容器中的 bean 定义。一个容器中的 bean 定义不会被另一个容器中的 BeanFactoryPostProcessor 实例进行后处理，即使这两个容器是同一层次结构的一部分。

当 bean 工厂后处理器在 ApplicationContext 中声明时，它会自动运行，以便对定义容器的配置元数据应用更改。Spring 包含许多预定义的 bean 工厂后处理器，例如 PropertyOverrideConfigurer 和 PropertySourcesPlaceholderConfigurer。您还可以使用自定义 BeanFactoryPostProcessor，例如，注册自定义属性编辑器。

ApplicationContext 会自动检测部署到其中的所有实现 BeanFactoryPostProcessor 接口的 bean。它会在适当的时候将这些 bean 用作 bean 工厂后处理器。您可以像部署任何其他 bean 一样部署这些后处理器 bean。

与 BeanPostProcessor 一样，您通常不希望为延迟初始化配置 BeanFactoryPostProcessor。如果没有其他 bean 引用 Bean(Factory)PostProcessor，则该后处理器将根本不会被实例化。因此，将其标记为延迟初始化将被忽略，并且 Bean(Factory)PostProcessor 将被提前实例化，即使您将 <beans /> 元素的声明中的 default-lazy-init 属性设置为 true。

示例：使用 PropertySourcesPlaceholderConfigurer 进行属性占位符替换

您可以使用 PropertySourcesPlaceholderConfigurer 将属性值从 bean 定义外部化到单独的文件中，使用标准的 Java Properties 格式。这样做使部署应用程序的人员能够自定义特定于环境的属性，例如数据库 URL 和密码，而无需修改容器的主要 XML 定义文件或文件的复杂性或风险。

考虑以下基于 XML 的配置元数据片段，其中定义了一个带有占位符值的 DataSource：

<bean class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
	<property name="locations" value="classpath:com/something/jdbc.properties"/>
</bean>

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	<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>

该示例显示了从外部 Properties 文件配置的属性。在运行时，PropertySourcesPlaceholderConfigurer 应用于替换 DataSource 的某些属性的元数据。要替换的值以 ${property-name} 的占位符形式指定，遵循 Ant、log4j 和 JSP EL 样式。

实际值来自另一个标准 Java Properties 格式的文件：

jdbc.driverClassName=org.hsqldb.jdbcDriver jdbc.url=jdbc:hsqldb:hsql://production:9002 jdbc.username=sa jdbc.password=root

因此，${jdbc.username} 字符串在运行时被替换为值“sa”，同样适用于属性文件中匹配键的其他占位符值。PropertySourcesPlaceholderConfigurer 检查大多数属性和 bean 定义属性中的占位符。此外，您可以自定义占位符前缀、后缀、默认值分隔符和转义字符。此外，可以通过 JVM 系统属性（或通过 SpringProperties 机制）设置 spring.placeholder.escapeCharacter.default 属性来全局更改或禁用默认转义字符。

使用 context 命名空间，您可以通过专用的配置元素配置属性占位符。您可以在 location 属性中提供一个或多个位置作为逗号分隔的列表，如下例所示：

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

PropertySourcesPlaceholderConfigurer 不仅在您指定的 Properties 文件中查找属性。默认情况下，如果它无法在指定的属性文件中找到属性，它会检查 Spring Environment 属性和常规 Java System 属性。

对于给定应用程序，应该只定义一个这样的元素，其中包含它所需的属性。只要它们具有不同的占位符语法 (${…​})，就可以配置多个属性占位符。 如果您需要模块化用于替换的属性源，则不应创建多个属性占位符。相反，您应该创建自己的 PropertySourcesPlaceholderConfigurer bean 来收集要使用的属性。

您可以使用 PropertySourcesPlaceholderConfigurer 替换类名，这在有时您必须在运行时选择特定的实现类时很有用。以下示例显示了如何执行此操作：

<bean class="org.springframework.beans.factory.config.PropertySourcesPlaceholderConfigurer">
	<property name="locations">
		<value>classpath:com/something/strategy.properties</value>
	</property>
	<property name="properties">
		<value>custom.strategy.class=com.something.DefaultStrategy</value>
	</property>
</bean>

<bean id="serviceStrategy" class="${custom.strategy.class}"/>

如果类在运行时无法解析为有效类，则在创建 bean 时（对于非延迟初始化 bean 的 ApplicationContext 的 preInstantiateSingletons() 阶段）解析 bean 将失败。

示例：PropertyOverrideConfigurer

PropertyOverrideConfigurer 是另一个 bean 工厂后处理器，它类似于 PropertySourcesPlaceholderConfigurer，但与后者不同的是，原始定义可以具有默认值或根本没有 bean 属性的值。如果覆盖的 Properties 文件没有特定 bean 属性的条目，则使用默认上下文定义。

请注意，bean 定义不知道被覆盖，因此从 XML 定义文件无法立即看出正在使用覆盖配置器。在多个 PropertyOverrideConfigurer 实例为同一 bean 属性定义不同值的情况下，由于覆盖机制，最后一个实例将胜出。

属性文件配置行采用以下格式：

beanName.property=value

以下清单显示了格式示例：

dataSource.driverClassName=com.mysql.jdbc.Driver dataSource.url=jdbc:mysql:mydb

此示例文件可与包含名为 dataSource 的 bean 的容器定义一起使用，该 bean 具有 driverClassName 和 url 属性。

还支持复合属性名称，只要路径中除最终被覆盖属性之外的每个组件都已经非空（大概由构造函数初始化）。在以下示例中，tom bean 的 fred 属性的 bob 属性的 sammy 属性被设置为标量值 123：

tom.fred.bob.sammy=123

指定的覆盖值始终是文字值。它们不会转换为 bean 引用。此约定也适用于 XML bean 定义中的原始值指定 bean 引用的情况。

使用 Spring 2.5 中引入的 context 命名空间，可以通过专用配置元素配置属性覆盖，如下例所示：

<context:property-override location="classpath:override.properties"/>

使用 FactoryBean 自定义实例化逻辑

您可以为本身就是工厂的对象实现 org.springframework.beans.factory.FactoryBean 接口。

FactoryBean 接口是 Spring IoC 容器实例化逻辑的一个可插拔点。如果您有复杂的初始化代码，最好用 Java 而不是（可能）冗长的 XML 来表达，您可以创建自己的 FactoryBean，在该类中编写复杂的初始化，然后将您的自定义 FactoryBean 插入到容器中。

FactoryBean<T> 接口提供了三个方法：

  • T getObject(): 返回此工厂创建的对象实例。该实例可能共享，具体取决于此工厂返回单例还是原型。

  • boolean isSingleton(): 如果此 FactoryBean 返回单例，则返回 true，否则返回 false。此方法的默认实现返回 true。

  • Class<?> getObjectType(): 返回 getObject() 方法返回的对象类型，如果类型未知，则返回 null。

FactoryBean 概念和接口在 Spring Framework 的许多地方都有使用。Spring 本身就包含了 50 多个 FactoryBean 接口的实现。

当您需要向容器请求实际的 FactoryBean 实例本身而不是它生成的 bean 时，在调用 ApplicationContext 的 getBean() 方法时，在 bean 的 id 前加上与号 (&) 符号。因此，对于 id 为 myBean 的给定 FactoryBean，在容器上调用 getBean("myBean") 返回 FactoryBean 的产品，而调用 getBean("&myBean") 返回 FactoryBean 实例本身。