1.8. Container Extension Points 容器扩展点

 Spring Framework Documentation (5.3.10)

Core	IoC Container, Events, Resources, i18n, Validation, Data Binding, Type Conversion, SpEL, AOP.

   Core Technologies

1. The IoC Container

1.1. Introduction to the Spring IoC Container and Beans（Spring IoC容器和bean简介）

1.2. Container Overview （容器概览）

1.3. Bean Overview （Bean概览）

1.4. Dependencies(依赖)

1.5. Bean Scopes（Bean作用域）

1.6. Customizing the Nature of a Bean （自定义bean的性质）

1.7. Bean Definition Inheritance（Bean定义继承）

1.8. Container Extension Points （容器扩展点）

---

下载此文档精编完整版

No.	内容	下载地址	文档内容目录
1	中英双语精编版 第一部分	PDF下载	内容目录
2	中英双语精编版 第二部分	PDF下载	内容目录
3	中文精编版 第一部分	PDF下载	内容目录
4	中文精编版 第二部分	PDF下载	内容目录

更多章节内容，请点击查看：  Core Technologies

---

1.8. Container Extension Points 容器扩展点

Typically, an application developer does not need to subclass ApplicationContext implementation classes. Instead, the Spring IoC container can be extended by plugging in implementations of special integration interfaces. The next few sections describe these integration interfaces.

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

1.8.1. Customizing Beans by Using a BeanPostProcessor 使用BeanPostProcessor自定义Bean

The BeanPostProcessor interface defines callback methods that you can implement to provide your own (or override the container’s default) instantiation logic, dependency resolution logic, and so forth. If you want to implement some custom logic after the Spring container finishes instantiating, configuring, and initializing a bean, you can plug in one or more custom BeanPostProcessor implementations.

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

You can configure multiple BeanPostProcessor instances, and you can control the order in which these BeanPostProcessor instances run by setting the order property. You can set this property only if the BeanPostProcessor implements the Ordered interface. If you write your own BeanPostProcessor, you should consider implementing the Ordered interface, too. For further details, see the javadoc of the BeanPostProcessor and Ordered interfaces. See also the note on programmatic registration of BeanPostProcessor instances.

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

BeanPostProcessor instances operate on bean (or object) instances. That is, the Spring IoC container instantiates a bean instance and then BeanPostProcessor instances do their work. BeanPostProcessor instances are scoped per-container. This is relevant only if you use container hierarchies. If you define a BeanPostProcessor in one container, it post-processes only the beans in that container. In other words, beans that are defined in one container are not post-processed by a BeanPostProcessor defined in another container, even if both containers are part of the same hierarchy. To change the actual bean definition (that is, the blueprint that defines the bean), you instead need to use a BeanFactoryPostProcessor, as described in Customizing Configuration Metadata with a BeanFactoryPostProcessor.

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

The org.springframework.beans.factory.config.BeanPostProcessor interface consists of exactly two callback methods. When such a class is registered as a post-processor with the container, for each bean instance that is created by the container, the post-processor gets a callback from the container both before container initialization methods (such as InitializingBean.afterPropertiesSet()  or any declared init method) are called, and after any bean initialization callbacks. The post-processor can take any action with the bean instance, including ignoring the callback completely. A bean post-processor typically checks for callback interfaces, or it may wrap a bean with a proxy. Some Spring AOP infrastructure classes are implemented as bean post-processors in order to provide proxy-wrapping logic.

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

An ApplicationContext automatically detects any beans that are defined in the configuration metadata that implements the BeanPostProcessor interface.

The ApplicationContext registers these beans as post-processors so that they can be called later, upon bean creation. Bean post-processors can be deployed in the container in the same fashion as any other beans.

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

Note that, when declaring a BeanPostProcessor by using an @Bean factory method on a configuration class, the return type of the factory method should be the implementation class itself or at least the org.springframework.beans.factory.config.BeanPostProcessor interface, clearly indicating the post-processor nature of that bean. Otherwise, the ApplicationContext cannot autodetect it by type before fully creating it. Since a BeanPostProcessor needs to be instantiated early in order to apply to the initialization of other beans in the context, this early type detection is critical.

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

Programmatically registering BeanPostProcessor instances While the recommended approach for BeanPostProcessor registration is through ApplicationContext auto-detection (as described earlier), you can register them programmatically against a ConfigurableBeanFactory by using the addBeanPostProcessor method. This can be useful when you need to evaluate conditional logic before registration or even for copying bean post processors across contexts in a hierarchy. Note, however,that BeanPostProcessor instances added programmatically do not respect the Ordered interface. Here, it is the order of registration that dictates the order of execution. Note also that BeanPostProcessor instances registered programmatically are always processed before those registered through auto-detection, regardless of any explicit ordering.

以编程方式注册BeanPostProcessor实例 虽然推荐的BeanPostProcessor注册方法是通过ApplicationContext自动检测（如前所述），但您可以使用addBeanPostProcessor方法以编程方式针对可配置的BeanFactory注册它们。当您需要在注册之前计算条件逻辑，甚至在层次结构中跨上下文复制bean后处理器时，这非常有用。但是，请注意，以编程方式添加的BeanPostProcessor实例不准许Ordered接口。在这里，注册的顺序决定了执行的顺序。还请注意，以编程方式注册的BeanPostProcessor实例总是在通过自动检测注册的实例之前进行处理，而不考虑任何显式排序（explicit ordering）。

BeanPostProcessor instances and AOP auto-proxying Classes that implement the BeanPostProcessor interface are special and are treated differently by the container. All BeanPostProcessor instances and beans that they directly reference are instantiated on startup, as part of the special startup phase of the ApplicationContext. Next, all BeanPostProcessor instances are registered in a sorted fashion and applied to all further beans in the container. Because AOP auto-proxying is implemented as a BeanPostProcessor itself, neither BeanPostProcessor instances nor the beans they directly reference are eligible for auto-proxying and, thus, do not have aspects woven into them. For any such bean, you should see an informational log message: Bean someBean is not eligible for getting processed by all BeanPostProcessor interfaces (for example: not eligible for auto-proxying). If you have beans wired into your BeanPostProcessor by using autowiring or @Resource (which may fall back to autowiring), Spring might access unexpected beans when searching for type-matching dependency candidates and, therefore, make them ineligible for auto-proxying or other kinds of bean post-processing. For example, if you have a dependency annotated with @Resource where the field or setter name does not directly correspond to the declared name of a bean and no name attribute is used, Spring accesses other beans for matching them by type.

BeanPostProcessor实例和AOP自动代理 实现BeanPostProcessor接口的类是特殊的，容器会对它们进行不同的处理。作为ApplicationContext特殊启动阶段的一部分，所有直接引用的BeanPostProcessor实例和bean都在启动时实例化。接下来，以有序方式注册所有BeanPostProcessor实例，并将其应用于容器中的所有其他bean。因为AOP自动代理是作为BeanPostProcessor本身实现的，所以无论是BeanPostProcessor实例还是它们直接引用的Bean都不符合自动代理的条件，因此，它们没有被织入的切面（aspects woven into them）。 对于任何这样的bean，您都应该看到一条信息性日志消息：bean someBean不符合由所有BeanPostProcessor接口处理的条件（例如：不符合自动代理的条件）。 如果您使用自动装配或@Resource（可能会返回到自动装配）将bean装配到BeanPostProcessor中，Spring在搜索类型匹配的依赖候选项时可能会访问意外的bean，因此，使它们不符合自动代理或其他类型的bean后处理的条件。例如，如果您有一个用@Resource注解的依赖项，其中字段或setter名称不直接对应于bean的声明名称，并且没有使用name属性，那么Spring将访问其他bean以按类型匹配它们。

The following examples show how to write, register, and use BeanPostProcessor instances in an ApplicationContext.

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