从Spring Framework 5.1开始，Spring需要JDK 8+ (Java SE 8+)，并提供对JDK 11 LTS的开箱即用支持。建议将Java SE 8 update 60作为Java 8的最低补丁版本，但通常建议使用最新的补丁版本。

The Spring Framework is divided into modules. Applications can choose which modules they need. At the heart are the modules of the core container, including a configuration model and a dependency injection mechanism. Beyond that, the Spring Framework provides foundational support for different application architectures, including messaging, transactional data and persistence, and web.

spring分为许多模块，应用可以选择他们需要的模块。它的核心模块是core container（也就是核心容器），包括配置模块和DI依赖注入。除此之外，Spring框架还为不同的应用程序体系结构提供基础支持，包括消息传递、事务数据和持久性以及web。

在学习框架的时候，你不仅仅需要知道他是怎么使用和怎么做的，更需要了解他遵循的原则：

• Provide choice at every level. 提供每个层次的选择，Spring允许您尽可能晚地推迟设计决策。例如你可以通过配置切换持久性提供程序（可能指的是类似数据源之类的）和基础设施以及第三方api集成。
• Accommodate diverse perspectives.Spring embraces flexibility and is not opinionated about how things should be done. It supports a wide range of application needs with different perspectives.意思是spring是灵活多变的，支持广泛的应用程序需求。
• Maintain strong backward compatibility. 具有强大的向后兼容性。Spring的发展已经被小心地管理，在不同的版本之间很少有中断的变化。Spring支持精心选择的JDK版本和第三方库，以方便维护依赖于Spring的应用程序和库。
• Care about API design.关心api的设计。Spring团队投入了大量的思想和时间来开发直观的api，这些api可以支持多个版本和许多年。
• Set high standards for code quality. 为代码质量设置高标准。它是少数几个可以声明干净的代码结构且包之间没有循环依赖关系的项目之一。

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

IoC（控制反转）容器，事件，资源，i18n，验证，数据绑定，类型转换，表达式，面向切面编程

It is a process whereby objects define their dependencies (that is, the other objects they work with) only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse (hence the name, Inversion of Control) of the bean itself controlling the instantiation or location of its dependencies by using direct construction of classes or a mechanism such as the Service Locator pattern.

项目的依赖（对象）仅通过构造器参数，工厂方法参数或者通过构造器或工厂方法返回的实例对象的set方法来定义他们的依赖（属性）。容器在bean对象创建时，将依赖注入到bean对象中。这个过程通过使用类的直接构造或服务定位模式机制，从根本上反转了bean本身控制实例化或依赖的位置

• org.springframework.beans和 org.springframework.context是SpringIoC容器的基础
• BeanFactory接口提供了能够管理任何类型对象的高级配置机制。
• ApplicationContext时BeanFactory的一个子接口，他包含了：
  • 更容易与AOP特性集成 Easier integration with Spring’s AOP features
  • 消息资源处理 Message resource handling
  • 事件发布 Event publication
  • 特定于应用程序的Context（例如WebApplicationContext应用在web应用中） Application-layer specific contexts such as the WebApplicationContext for use in web applications.

In short, the BeanFactory provides the configuration framework and basic functionality, and the ApplicationContext adds more enterprise-specific functionality. The ApplicationContext is a complete superset of the BeanFactory and is used exclusively in this chapter in descriptions of Spring’s IoC container.

所以说，BeanFactory提供了配置框架和基础功能，ApplicationContext增加了更多特定功能。ApplicationContext时BeanFactory的一个完整超集，它在本章描述Spring的IoC容器时专用。

In Spring, the objects that form the backbone of your application and that are managed by the Spring IoC container are called beans. A bean is an object that is instantiated, assembled, and otherwise managed by a Spring IoC container. Otherwise, a bean is simply one of many objects in your application. Beans, and the dependencies among them, are reflected in the configuration metadata used by a container.

在Spring中，构成应用程序主干并由Spring IoC容器管理的对象称为bean。bean是由Spring IoC容器实例化、组装和管理的对象。另外，bean只是应用程序中的众多对象之一。bean及其之间的依赖关系反映在容器使用的配置元数据中。

• Service Locator Pattern：服务定位模式，一种设计模式。当我们希望使用JNDI查找来定位各种服务时，选择此种设计模式。这种设计模式使用了缓存技术。
  • 第一次需要服务时，服务定位器在JNDI中查找并缓存服务对象。
  • 再次查找相同的服务时，将在缓存中完成，提高了程序的性能
• JNDI

The org.springframework.context.ApplicationContext interface represents the Spring IoC container and is responsible for instantiating, configuring, and assembling the beans. The container gets its instructions on what objects to instantiate, configure, and assemble by reading configuration metadata. The configuration metadata is represented in XML, Java annotations, or Java code. It lets you express the objects that compose your application and the rich interdependencies between those objects.

ApplicationContext这个接口就代表IoC容器，它负责实例化、配置和组装bean。容器通过读取配置文件的元数据来获取要实例化、配置和组装哪些对象的指令。配置文件支持xml,Java注解和纯Java代码。它允许您表达组成应用程序的对象以及这些对象之间丰富的相互依赖关系。

这个描述就是说对象的实例化，分配和管理由容器来负责，你只需要将这些信息用xml配置文件或注解或Java代码配置即可

• 基于注解的配置：spring2.5+
• 基于Java的配置：spring3.0+

Spring configuration consists of at least one and typically more than one bean definition that the container must manage. XML-based configuration metadata configures these beans as elements inside a top-level element. Java configuration typically uses @Bean-annotated methods within a @Configuration class.

你可以在xml配置文件中使用标签或在带有@Configuration注解的java类中使用@Bean来定义Bean

Typically, one does not configure fine-grained domain objects in the container, because it is usually the responsibility of DAOs and business logic to create and load domain objects.

通常，不会在容器中配置细粒度域对象，因为通常由DAOs和业务逻辑负责创建和加载域对象，这时可以使用Spring与AspectJ的集成来配置在IoC容器控制之外创建的对象。

基于xml配置元数据的基本结构：

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

    <bean id="..." class="...">  
        <!-- collaborators and configuration for this bean go here -->
    </bean>

    <bean id="..." class="...">
        <!-- collaborators and configuration for this bean go here -->
    </bean>

    <!-- more bean definitions go here -->

</beans>

• The id attribute is a string that identifies the individual bean definition. 用来标识单个bean
• The class attribute defines the type of the bean and uses the fully qualified classname. 这个bean对应类的全限定名

It can be useful to have bean definitions span multiple XML files. Often, each individual XML configuration file represents a logical layer or module in your architecture.

让bean定义跨越多个XML文件可能很有用。通常，每个单独的XML配置文件表示体系结构中的逻辑层或模块。

<beans>
    <import resource="services.xml"/>
    <import resource="resources/messageSource.xml"/>
    <import resource="/resources/themeSource.xml"/>

    <bean id="bean1" class="..."/>
    <bean id="bean2" class="..."/>
</beans>

It is possible, but not recommended, to reference files in parent directories using a relative “…/” path. Doing so creates a dependency on a file that is outside the current application. In particular, this reference is not recommended for classpath: URLs (for example, classpath:../services.xml), where the runtime resolution process chooses the “nearest” classpath root and then looks into its parent directory. Classpath configuration changes may lead to the choice of a different, incorrect directory.You can always use fully qualified resource locations instead of relative paths: for example, file:C:/config/services.xml or classpath:/config/services.xml. However, be aware that you are coupling your application’s configuration to specific absolute locations. It is generally preferable to keep an indirection for such absolute locations — for example, through “${…}” placeholders that are resolved against JVM system properties at runtime.

此处提示最好不要使用相对路径，你可以使用绝对路径(不建议)，和classpath，但是不要将配置文件耦合在系统的绝对路径，因为换了操作系统（在服务器部署）时很可能出问题。

The ApplicationContext is the interface for an advanced factory capable of maintaining a registry of different beans and their dependencies. By using the method T getBean(String name, Class requiredType), you can retrieve instances of your beans.

The ApplicationContext lets you read bean definitions and access them, as the following example shows:

通过ApplicationContext接口的getBean方法获取Bean对象的实例。

ApplicationContext context = new ClassPathXmlApplicationContext("services.xml", "daos.xml");

// retrieve configured instance
PetStoreService service = context.getBean("petStore", PetStoreService.class);

// use configured instance
List<String> userList = service.getUsernameList();

A Spring IoC container manages one or more beans. These beans are created with the configuration metadata that you supply to the container (for example, in the form of XML `` definitions).

一个springIoC容器管理着一个或多个bean对象，这些bean对象由你提供给容器的配置元数据创建生成。

Within the container itself, these bean definitions are represented as BeanDefinition objects, which contain (among other information) the following metadata:

在容器内部，这些bean定义表示为BeanDefinition对象，包含着以下元数据：

• A package-qualified class name: typically, the actual implementation class of the bean being defined.（全限定类名）
• Bean behavioral configuration elements, which state how the bean should behave in the container (scope, lifecycle callbacks, and so forth).（Bean的行为配置元素，作用域，生命周期回调等）
• References to other beans that are needed for the bean to do its work. These references are also called collaborators or dependencies.（对该bean执行其工作所需的其他bean的引用。）
• Other configuration settings to set in the newly created object — for example, the size limit of the pool or the number of connections to use in a bean that manages a connection pool.（在创建bean对象时的其他配置，如连接池的最大数量）

In addition to bean definitions that contain information on how to create a specific bean, the ApplicationContext implementations also permit the registration of existing objects that are created outside the container (by users). This is done by accessing the ApplicationContext’s BeanFactory through the getBeanFactory() method, which returns the BeanFactory DefaultListableBeanFactory implementation. DefaultListableBeanFactory supports this registration through the registerSingleton(..) and registerBeanDefinition(..) methods. However, typical applications work solely with beans defined through regular bean definition metadata.

这段话说我们可以通过ApplicationContext的getBeanFactory方法在容器之外创建对象，但是这种方法不被建议。//此处我找不到getBeanFactory这个方法。

Tip

Bean metadata and manually supplied singleton instances need to be registered as early as possible, in order for the container to properly reason about them during autowiring and other introspection steps. While overriding existing metadata and existing singleton instances is supported to some degree, the registration of new beans at runtime (concurrently with live access to the factory) is not officially supported and may lead to concurrent access exceptions, inconsistent state in the bean container, or both.

bean元数据和手动提供的单例实例需要尽早的注册，为了容器在自动装配和其他内省步骤中正确地推理它们。虽然在一定程度上支持覆盖现有元数据和现有单例实例，但是在运行时注册新bean(与对工厂的实时访问同时进行)不受官方支持，可能会导致并发访问异常，使bean容器中的不一致状态，或者两者都是。

Every bean has one or more identifiers. These identifiers must be unique within the container that hosts the bean. A bean usually has only one identifier. However, if it requires more than one, the extra ones can be considered aliases.

每个bean都有一个或多个标识符。这些标识符在承载bean的容器中必须是惟一的。一个bean通常只有一个标识符。但是，如果需要多个别名，则可以将额外的别名视为别名。

In XML-based configuration metadata, you use the id attribute, the name attribute, or both to specify the bean identifiers. The id attribute lets you specify exactly one id. Conventionally, these names are alphanumeric (‘myBean’, ‘someService’, etc.), but they can contain special characters as well. If you want to introduce other aliases for the bean, you can also specify them in the name attribute, separated by a comma (,), semicolon (;), or white space.

用id配置标识，这个需要使唯一的，同时你还可以使用name来配置bean的别名，并且可以配置多个，你可以用逗号分号和空格来分开多个别名。

When you create a bean by the constructor approach, all normal classes are usable by and compatible with Spring. That is, the class being developed does not need to implement any specific interfaces or to be coded in a specific fashion. Simply specifying the bean class should suffice. However, depending on what type of IoC you use for that specific bean, you may need a default (empty) constructor.

当您通过构造函数方法创建一个bean时，所有的普通类都可以被Spring使用并与Spring兼容。也就是说，正在开发的类不需要实现任何特定的接口，也不需要以特定的方式进行编码。只需指定bean类就足够了。但是，根据您为特定bean使用的IoC类型，您可能需要一个默认(空)构造函数。

The Spring IoC container can manage virtually any class you want it to manage. It is not limited to managing true JavaBeans. Most Spring users prefer actual JavaBeans with only a default (no-argument) constructor and appropriate setters and getters modeled after the properties in the container. You can also have more exotic non-bean-style classes in your container. If, for example, you need to use a legacy connection pool that absolutely does not adhere to the JavaBean specification, Spring can manage it as well.

Spring IoC容器几乎可以管理您希望它管理的任何类。它不仅限于管理真正的javabean。大多数Spring用户更喜欢实际的javabean，它只有一个默认的(无参数的)构造函数，以及根据容器中的属性建模的适当的setter和getter方法。您还可以在容器中包含更多非bean风格的类。例如，如果您需要使用完全不符合JavaBean规范的遗留连接池，Spring也可以管理它。

With XML-based configuration metadata you can specify your bean class as follows:

<bean id="exampleBean" class="examples.ExampleBean"/>
<bean name="anotherExample" class="examples.ExampleBeanTwo"/>

有关构造器注入的细节，请移步注入依赖项[Injecting Dependencies]。

When defining a bean that you create with a static factory method, use the class attribute to specify the class that contains the static factory method and an attribute named factory-method to specify the name of the factory method itself. You should be able to call this method (with optional arguments, as described later) and return a live object, which subsequently is treated as if it had been created through a constructor. One use for such a bean definition is to call static factories in legacy code.

在定义使用静态工厂方法创建的bean时，使用class属性指定包含静态工厂方法的类，使用factory-method属性指定工厂方法本身的名称。您应该能够调用这个方法(带有可选参数，如后面所述)并返回一个活动对象，该对象随后被视为是通过构造函数创建的。这种bean定义的一个用途是在遗留代码中调用静态工厂。

The following bean definition specifies that the bean be created by calling a factory method. The definition does not specify the type (class) of the returned object, only the class containing the factory method. In this example, the createInstance() method must be a static method. The following example shows how to specify a factory method:

下面的bean定义指定通过调用工厂方法来创建bean。定义不指定返回对象的类型(类)，只指定包含工厂方法的类。在本例中，createInstance()方法必须是一个静态方法。下面的例子展示了如何指定一个工厂方法:

import lombok.AllArgsConstructor;
import lombok.Data;
import lombok.NoArgsConstructor;

@Data
@NoArgsConstructor
@AllArgsConstructor
public class User {
    private String name;
    private int age;
}

public class UserFactory {

    public static User getUser(){
        return new User("工厂", 19);
    }
}

public void test(){
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        Object user = context.getBean("user");
        System.out.println(user);   //User(name=工厂, age=19)
    }

A typical enterprise application does not consist of a single object (or bean in the Spring parlance). Even the simplest application has a few objects that work together to present what the end-user sees as a coherent application. This next section explains how you go from defining a number of bean definitions that stand alone to a fully realized application where objects collaborate to achieve a goal.

典型的企业应用程序不包含单个对象(或Spring中的bean)。即使是最简单的应用程序也有几个对象一起工作，以呈现最终用户所看到的一致的应用程序。下一节将解释如何从定义许多独立的bean定义过渡到一个完全实现的应用程序，在这个应用程序中，对象通过协作来实现一个目标。

Dependency injection (DI) is a process whereby objects define their dependencies (that is, the other objects with which they work) only through constructor arguments, arguments to a factory method, or properties that are set on the object instance after it is constructed or returned from a factory method. The container then injects those dependencies when it creates the bean. This process is fundamentally the inverse (hence the name, Inversion of Control) of the bean itself controlling the instantiation or location of its dependencies on its own by using direct construction of classes or the Service Locator pattern.

依赖项注入(DI)是一个过程，在这个过程中，对象仅通过构造函数参数、工厂方法的参数或从工厂方法构造或返回后在对象实例上设置的属性来定义它们的依赖项(即它们与之一起工作的其他对象)。然后容器在创建bean时注入这些依赖项。这个过程基本上是bean本身的逆过程(因此称为控制反转过程)，由对象自己控制实例化或者定位他的依赖，改变为通过直接使用类的构造方法或者使用服务定位模式。

Code is cleaner with the DI principle, and decoupling is more effective when objects are provided with their dependencies. The object does not look up its dependencies and does not know the location or class of the dependencies. As a result, your classes become easier to test, particularly when the dependencies are on interfaces or abstract base classes, which allow for stub or mock implementations to be used in unit tests.

使用DI原则，代码更简洁，并且当对象提供其依赖项时，解耦更有效。对象不查找其依赖项，也不知道依赖项的位置或类。结果，您的类变得更容易测试，特别是当依赖关系在接口或抽象基类上时，这允许在单元测试中使用存根或模拟实现。

Constructor-based DI is accomplished by the container invoking a constructor with a number of arguments, each representing a dependency. Calling a static factory method with specific arguments to construct the bean is nearly equivalent, and this discussion treats arguments to a constructor and to a static factory method similarly. The following example shows a class that can only be dependency-injected with constructor injection:

基于构造函数的DI是通过容器调用带有许多参数的构造函数来完成的，每个参数代表一个依赖项。调用带有特定参数的静态工厂方法来构造bean几乎是等价的，本讨论将参数分别用于构造函数和静态工厂方法。下面的例子展示了一个只能依赖注入构造函数注入的类:

Bean类：

@Data
@NoArgsConstructor
@AllArgsConstructor
public class User {
    private String name;
    private int age;
}

@Data
@NoArgsConstructor
@AllArgsConstructor
public class Score {
    private int English;
    private int Math;
}

XML配置

<bean id="user" class="com.leishida.spring.User">
        <constructor-arg name="name" value="构造器注入"/>
        <constructor-arg name="age" value="18"/>
        <!-- 当对象内部的属性是引用类型时，通过ref引用上面注册的score Bean -->
        <constructor-arg name="score" ref="score"/>
</bean>

测试

@org.junit.Test
    public void test3(){
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        Object user = context.getBean("user");
        System.out.println(user);   //User(name=构造器注入, age=18, score=Score(English=0, Math=0))
    }

通过构造器注入时可以根据参数索引，类型，名称来注入

通过索引注入

<bean id="user1" class="com.leishida.spring.User">
        <constructor-arg index="0" value="索引"/>
        <constructor-arg index="1" value="18"/>
        <constructor-arg index="2" ref="score"/>
</bean>

通过类型注入

    <bean id="user2" class="com.leishida.spring.User">
        <constructor-arg type="java.lang.String" value="类型"/>
        <constructor-arg type="int" value="18"/>
        <constructor-arg type="com.leishida.spring.Score" ref="score"/>
    </bean>

通过名称匹配上面例子已经写过，此处不再赘述

Setter-based DI is accomplished by the container calling setter methods on your beans after invoking a no-argument constructor or a no-argument static factory method to instantiate your bean.

The following example shows a class that can only be dependency-injected by using pure setter injection. This class is conventional Java. It is a POJO that has no dependencies on container specific interfaces, base classes, or annotations.

基于setter的DI是在调用无参数构造函数或无参数静态工厂方法来实例化bean之后，通过容器调用bean上的setter方法来完成的。

下面的示例显示了一个只能通过使用纯setter注入来依赖注入的类。这个类是传统的Java。它是一个不依赖于容器特定接口、基类或注释的POJO。

使用此种方式，一定要保证类对应的属性上有相应的get方法，否则会注入失败

The ApplicationContext supports constructor-based and setter-based DI for the beans it manages. It also supports setter-based DI after some dependencies have already been injected through the constructor approach. You configure the dependencies in the form of a BeanDefinition, which you use in conjunction with PropertyEditor instances to convert properties from one format to another. However, most Spring users do not work with these classes directly (that is, programmatically) but rather with XML bean definitions, annotated components (that is, classes annotated with @Component, @Controller, and so forth), or @Bean methods in Java-based @Configuration classes. These sources are then converted internally into instances of BeanDefinition and used to load an entire Spring IoC container instance.

ApplicationContext为它管理的bean支持基于构造函数和基于setter的DI。在通过构造函数方法注入了一些依赖项之后，它还支持基于setter的DI。您可以将依赖项配置为BeanDefinition的形式，并将其与PropertyEditor实例一起使用，以便将属性从一种格式转换为另一种格式。但是，大多数Spring用户并不直接使用这些类(也就是说，以编程的方式)，而是使用XML bean定义、带注释的组件(也就是说，使用@Component、@Controller等注释的类)

The container performs bean dependency resolution as follows:

• The ApplicationContext is created and initialized with configuration metadata that describes all the beans. Configuration metadata can be specified by XML, Java code, or annotations.
• For each bean, its dependencies are expressed in the form of properties, constructor arguments, or arguments to the static-factory method (if you use that instead of a normal constructor). These dependencies are provided to the bean, when the bean is actually created.
• Each property or constructor argument is an actual definition of the value to set, or a reference to another bean in the container.
• Each property or constructor argument that is a value is converted from its specified format to the actual type of that property or constructor argument. By default, Spring can convert a value supplied in string format to all built-in types, such as int, long, String, boolean, and so forth.

容器执行bean依赖项解析如下:

• ApplicationContext是用描述所有bean的配置元数据创建和初始化的。配置元数据可以由XML、Java代码或注释指定。
• 对于每个bean，其依赖项都以属性、构造函数参数或静态工厂方法的参数的形式表示(如果您使用该方法而不是普通的构造函数)。这些依赖项是在bean实际创建时提供给bean的。
• 每个属性或构造函数参数都是要设置的值的实际定义，或者是对容器中另一个bean的引用。
• 值的每个属性或构造函数参数都从其指定的格式转换为该属性或构造函数参数的实际类型。默认情况下，Spring可以将以字符串格式提供的值转换为所有内置类型，如int、long、string、boolean等。

这一部分具体讲解了属性注入的具体方法：

P标签的使用：

再使用p命名空间时，需要首先导入约束：

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:p="http://www.springframework.org/schema/p"	<!-- p命名空间约束 -->
       xsi:schemaLocation="http://www.springframework.org/schema/beans
    https://www.springframework.org/schema/beans/spring-beans.xsd">

	<bean id="score" class="com.leishida.spring.Score"></bean>
	<bean id="user4" class="com.leishida.spring.User" p:name="P标签导入" p:age="18" p:score-ref="score"/>

</beans>

**The idref element ** idref元素

The idref element is simply an error-proof way to pass the id (a string value - not a reference) of another bean in the container to a or element. The following example shows how to use it:

idref元素只是将容器中另一个bean的id(字符串值，而不是引用)传递给或元素。

    <bean id="user4" class="com.leishida.spring.User" p:name="P标签导入" p:age="18" p:score-ref="score"/>

    <bean id="user5" class="com.leishida.spring.User">
        <property name="name">
            <idref bean="user4"/>
        </property>
    </bean>

结果：

    @org.junit.Test
    public void test7() {
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        Object user5 = context.getBean("user5");
        System.out.println(user5);  //User(name=user4, age=0, score=null)
    }

可以看到，上面的xml配置和下面的是等同的效果：

    <bean id="user5" class="com.leishida.spring.User">
        <property name="name" value="user4"/>
    </bean>

那它为啥要整个idref。。神经病么，显然不是：

引用其他bean最常用的方式就是通过标签，这个标签允许在同一个容器或父容器中创建对任何bean的引用，他们可以不在同一个xml配置文件之中。你可以使用与引用的bean的相同id或name来指定。

Specifying the target bean through the parent attribute creates a reference to a bean that is in a parent container of the current container. The value of the parent attribute may be the same as either the id attribute of the target bean or one of the values in the name attribute of the target bean. The target bean must be in a parent container of the current one. You should use this bean reference variant mainly when you have a hierarchy of containers and you want to wrap an existing bean in a parent container with a proxy that has the same name as the parent bean. The following pair of listings shows how to use the parent attribute:

这里还有一堆关于父容器的说明：通过parent属性指定目标bean将创建对当前容器的父容器中的bean的引用。父属性的值可以与目标bean的id属性相同，也可以与目标bean的name属性中的一个值相同。目标bean必须位于当前bean的父容器中。您应该主要在容器层次结构中使用此bean引用变体，并且希望将现有的bean与具有与父bean相同名称的代理包装在父容器中。

<!-- in the parent context -->
<bean id="accountService" class="com.something.SimpleAccountService">
    <!-- insert dependencies as required as here -->
</bean>

==========================================================================
<!-- in the child (descendant) context -->
<bean id="accountService" <!-- bean name is the same as the parent bean -->
    class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="target">
        <ref parent="accountService"/> <!-- notice how we refer to the parent bean -->
    </property>
    <!-- insert other configuration and dependencies as required here -->
</bean>

这个部分因为没有具体使用到，所以不清楚他的作用

    <!-- inner bean-->
    <bean id="user6" class="com.leishida.spring.User">
        <property name="score">
            <bean class="com.leishida.spring.Score">
                <property name="english" value="100"/>
                <property name="math" value="90"/>
            </bean>
        </property>
    </bean>

    @org.junit.Test
    public void test8() {
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        Object user6 = context.getBean("user6");
        System.out.println(user6);  //User(name=null, age=0, score=Score(English=100, Math=90))
    }

An inner bean definition does not require a defined ID or name. If specified, the container does not use such a value as an identifier. The container also ignores the scope flag on creation, because inner beans are always anonymous and are always created with the outer bean. It is not possible to access inner beans independently or to inject them into collaborating beans other than into the enclosing bean.

内部bean定义不需要已定义的ID或名称。如果指定，容器将不使用此类值作为标识符。容器还会忽略创建时的范围标志，因为内部bean始终是匿名的，并且始终使用外部bean创建。不可能独立地访问内部bean，也不可能将它们注入到协作的bean中，而不是注入到封闭的bean中。

As a corner case, it is possible to receive destruction callbacks from a custom scope — for example, for a request-scoped inner bean contained within a singleton bean. The creation of the inner bean instance is tied to its containing bean, but destruction callbacks let it participate in the request scope’s lifecycle. This is not a common scenario. Inner beans typically simply share their containing bean’s scope.

作为一种特殊情况，可以从自定义范围接收销毁回调—例如，对于单例bean中包含的请求范围的内部bean。内部bean实例的创建被绑定到它所包含的bean，但是销毁回调让它参与请求作用域的生命周期。这不是一个常见的场景。内部bean通常只是简单地共享其包含bean的范围。

、、

Java类：

@Data
@NoArgsConstructor
public class ComplexObject {
    private Properties email;
    private List list;
    private Map map;
    private Set set;
}

Spring treats empty arguments for properties and the like as empty Strings. The following XML-based configuration metadata snippet sets the email property to the empty String value ("").

Spring将属性的空参数等作为空字符串处理。以下基于xml的配置元数据片段将email属性设置为空字符串值("")。

<bean class="ExampleBean">
    <property name="email" value=""/>
</bean>

The <null/> element handles null values. The following listing shows an example:

<bean class="ExampleBean">
    <property name="email">
        <null/>
    </property>
</bean>

The p-namespace lets you use the bean element’s attributes (instead of nested `` elements) to describe your property values collaborating beans, or both.

Similar to the [XML Shortcut with the p-namespace], the c-namespace, introduced in Spring 3.1, allows inlined attributes for configuring the constructor arguments rather then nested constructor-arg elements.

与p-namespace的XML快捷方式类似，在Spring 3.1中引入的c-namespace允许配置构造函数参数的内联属性，而不是嵌套的构造函数-参数元素。

You can use compound or nested property names when you set bean properties, as long as all components of the path except the final property name are not null. Consider the following bean definition:

在设置bean属性时，可以使用复合或嵌套属性名，只要路径的所有组件(最后的属性名除外)都不为空。

<bean id="something" class="things.ThingOne">
    <property name="fred.bob.sammy" value="123" />
</bean>

The something bean has a fred property, which has a bob property, which has a sammy property, and that final sammy property is being set to a value of 123. In order for this to work, the fred property of something and the bob property of fred must not be null after the bean is constructed. Otherwise, a NullPointerException is thrown.

something bean有一个fred属性，它有一个bob属性，它有一个sammy属性，而最后那个sammy属性的值被设置为123。为了使其工作，在构造bean之后，fred的属性和fred的bob属性不能为空。否则，将抛出NullPointerException。

The Spring container can autowire relationships between collaborating beans. You can let Spring resolve collaborators (other beans) automatically for your bean by inspecting the contents of the ApplicationContext. Autowiring has the following advantages:

• Autowiring can significantly reduce the need to specify properties or constructor arguments. (Other mechanisms such as a bean template [discussed elsewhere in this chapter]are also valuable in this regard.)
• Autowiring can update a configuration as your objects evolve. For example, if you need to add a dependency to a class, that dependency can be satisfied automatically without you needing to modify the configuration. Thus autowiring can be especially useful during development, without negating the option of switching to explicit wiring when the code base becomes more stable.

Spring容器可以自动创建协作bean之间的关系。通过检查ApplicationContext的内容，您可以让Spring为您的bean自动解析协作者(其他bean)。自动装配有以下优点:

• 自动装配可以大大减少指定属性或构造函数参数的需要。在这方面，本章其他地方讨论的其他机制(如bean模板)也很有价值
• 自动装配可以随着对象的修改更新配置。例如，如果需要向类添加依赖项，则可以自动满足该依赖项，而不需要修改配置。因此，自动装配在开发过程中特别有用，当代码库变得更加稳定时，自动装配可以避免切换到显式连接的选项。

Autowiring works best when it is used consistently across a project. If autowiring is not used in general, it might be confusing to developers to use it to wire only one or two bean definitions.

自动装配在跨项目一致使用时效果最好。如果通常不使用自动装配，那么开发人员使用它来连接一个或两个bean定义可能会感到困惑。

Consider the limitations and disadvantages of autowiring:

• Explicit dependencies in property and constructor-arg settings always override autowiring. You cannot autowire simple properties such as primitives, Strings, and Classes (and arrays of such simple properties). This limitation is by-design.
• Autowiring is less exact than explicit wiring. Although, as noted in the earlier table, Spring is careful to avoid guessing in case of ambiguity that might have unexpected results. The relationships between your Spring-managed objects are no longer documented explicitly.
• Wiring information may not be available to tools that may generate documentation from a Spring container.
• Multiple bean definitions within the container may match the type specified by the setter method or constructor argument to be autowired. For arrays, collections, or Map instances, this is not necessarily a problem. However, for dependencies that expect a single value, this ambiguity is not arbitrarily resolved. If no unique bean definition is available, an exception is thrown.

考虑自动装配的限制和缺点：

• 属性和构造参数设置中的显式依赖项总是覆盖自动装配。您不能自动生成简单的属性，如原语、字符串和类(以及这些简单属性的数组)。这种限制是由设计造成的。
• 自动装配不如直接注入精确。尽管如前面的表中所述，Spring小心地避免猜测，以免产生可能产生意外结果的歧义。被spring管理对象不会被精确地记录下来。
• 连接信息可能对从Spring容器生成文档的工具不可用。（啥意思）
• 容器中的多个bean定义可能与要自动装配的setter方法或构造函数参数指定的类型相匹配。对于数组、集合或映射实例，这不一定是个问题。然而，对于期望单个值的依赖项，这种模糊性不是任意解决的。如果没有唯一的bean定义可用，则抛出异常。

In the latter scenario, you have several options:

On a per-bean basis, you can exclude a bean from autowiring. In Spring’s XML format, set the autowire-candidate attribute of the `` element to false. The container makes that specific bean definition unavailable to the autowiring infrastructure (including annotation style configurations such as [`@Autowired]

在每个bean的基础上，可以将bean排除在自动装配之外。在Spring的XML格式中，将元素的autowire-candidate属性设置为false。容器使特定的bean定义对自动装配基础设施(包括诸如@Autowired之类的注释样式配置)不可用。

The autowire-candidate attribute is designed to only affect type-based autowiring. It does not affect explicit references by name, which get resolved even if the specified bean is not marked as an autowire candidate. As a consequence, autowiring by name nevertheless injects a bean if the name matches.

utowire-candidate属性被设计为只影响基于类型的自动装配。它不会影响按名称显示的引用，即使指定的bean没有标记为autowire候选bean，也会解析这些引用。因此，如果名字匹配，自动装配仍然会注入一个bean。

You can also limit autowire candidates based on pattern-matching against bean names. The top-level <beans/> element accepts one or more patterns within its default-autowire-candidates attribute. For example, to limit autowire candidate status to any bean whose name ends with Repository, provide a value of *Repository. To provide multiple patterns, define them in a comma-separated list. An explicit value of true or false for a bean definition’s autowire-candidate attribute always takes precedence. For such beans, the pattern matching rules do not apply.

您还可以根据bean名称的正则匹配来限制自动装配候选对象。顶级元素在其default-autowire-candidate属性中接受一个或多个正则表达式。例如，要将autowire候选状态限制为名称以Repository结尾的任何bean，请提供一个值*Repository。要提供多个模式，请在逗号分隔的列表中定义它们。bean定义的autowire-candidate属性的显式值true或false总是优先考虑。对于这样的bean，不适用正则匹配规则。

These techniques are useful for beans that you never want to be injected into other beans by autowiring. It does not mean that an excluded bean cannot itself be configured by using autowiring. Rather, the bean itself is not a candidate for autowiring other beans.

这些技术对于那些您不希望通过自动装配将其注入到其他bean中的bean非常有用。这并不意味着被排除的bean本身不能被用来自动装配，相反，它本身不是其他bean自动装配的一个候选者。（这里有点糊涂了）

A less useful form of method injection than lookup method injection is the ability to replace arbitrary methods in a managed bean with another method implementation. You can safely skip the rest of this section until you actually need this functionality.

与查找方法注入相比，一种不太有用的方法注入形式是能够用另一种方法实现替换托管bean中的任意方法。您可以安全地跳过本节的其余部分，直到您真正需要此功能为止。

With XML-based configuration metadata, you can use the replaced-method element to replace an existing method implementation with another, for a deployed bean. Consider the following class, which has a method called computeValue that we want to override:

对于基于xml的配置元数据，您可以使用replace -method元素将已部署bean的现有方法实现替换为其他方法实现。考虑下面的类，它有一个我们想要重写的叫做computeValue的方法:

public class MyValueCalculator {

    public String computeValue(String input) {
        // some real code...
    }

    // some other methods...
}

A class that implements the org.springframework.beans.factory.support.MethodReplacer interface provides the new method definition, as the following example shows:

一个实现了org.springframework.beans.factory.support.MethodReplacer接口的类提供了新方法的定义，如接下来的例子：

/**
 * meant to be used to override the existing computeValue(String)
 * implementation in MyValueCalculator
 */
public class ReplacementComputeValue implements MethodReplacer {

    public Object reimplement(Object o, Method m, Object[] args) throws Throwable {
        // get the input value, work with it, and return a computed result
        String input = (String) args[0];
        ...
        return ...;
    }
}

The bean definition to deploy the original class and specify the method override would resemble the following example:

部署原始类并指定方法覆盖的bean定义,如以下示例:

<bean id="myValueCalculator" class="x.y.z.MyValueCalculator">
    <!-- arbitrary method replacement -->
    <replaced-method name="computeValue" replacer="replacementComputeValue">
        <arg-type>String</arg-type>
    </replaced-method>
</bean>

<bean id="replacementComputeValue" class="a.b.c.ReplacementComputeValue"/>

You can use one or more <arg-type> elements within the <replaced-method> element to indicate the method signature of the method being overridden. The signature for the arguments is necessary only if the method is overloaded and multiple variants exist within the class. For convenience, the type string for an argument may be a substring of the fully qualified type name. For example, the following all match java.lang.String:

您可以在< replacedmethod />元素中使用一个或多个< argtype />元素来指示被覆盖的方法的方法签名。只有在方法重载且类中存在多个变量时，才需要对参数进行签名。为了方便起见，参数的类型字符串可以是全限定类名的子字符串。例如，以下所有都匹配java.lang.String:

java.lang.String
String
Str

Because the number of arguments is often enough to distinguish between each possible choice, this shortcut can save a lot of typing, by letting you type only the shortest string that matches an argument type.

因为参数的数量通常足以区分每种可能的选择，所以这个快捷方式可以节省大量的输入，因为它允许您只输入与参数类型匹配的最短字符串。

When you create a bean definition, you create a recipe for creating actual instances of the class defined by that bean definition. The idea that a bean definition is a recipe is important, because it means that, as with a class, you can create many object instances from a single recipe.

当您创建一个bean定义时，您将定义一个由该bean定义的类的实际实例化的方法。bean定义是菜谱的想法很重要，因为它意味着，与类一样，您可以从一个菜谱创建多个对象实例。

You can control not only the various dependencies and configuration values that are to be plugged into an object that is created from a particular bean definition but also control the scope of the objects created from a particular bean definition. This approach is powerful and flexible, because you can choose the scope of the objects you create through configuration instead of having to bake in the scope of an object at the Java class level. Beans can be defined to be deployed in one of a number of scopes. The Spring Framework supports six scopes, four of which are available only if you use a web-aware ApplicationContext. You can also create [a custom scope.]

您不仅可以控制要插入到由特定bean定义创建的对象中的各种依赖项和配置值，还可以控制由特定bean定义创建的对象的范围。这种方法强大而灵活，因为您可以选择通过配置创建的对象的范围，而不必在Java类级别上考虑对象的范围。可以将bean定义为部署在多种作用域中的一种。Spring框架支持6种作用域，其中4种只有在您使用web框架时才可用

Only one shared instance of a singleton bean is managed, and all requests for beans with an ID or IDs that match that bean definition result in that one specific bean instance being returned by the Spring container.

To put it another way, when you define a bean definition and it is scoped as a singleton, the Spring IoC container creates exactly one instance of the object defined by that bean definition. This single instance is stored in a cache of such singleton beans, and all subsequent requests and references for that named bean return the cached object. The following image shows how the singleton scope works:

只管理一个单例bean的一个共享实例，所有对具有与该bean定义匹配的ID或ID的bean的请求都会导致Spring容器返回该特定bean实例。

换句话说，当您定义一个bean定义并将其定义为一个单例对象时，Spring IoC容器将仅创建该bean定义定义的对象的一个实例。此单一实例存储在此类单例bean的缓存中，该指定bean的所有后续请求和引用都将返回缓存的对象。下图显示了单例范围的工作方式:

Spring’s concept of a singleton bean differs from the singleton pattern as defined in the Gang of Four (GoF) patterns book. The GoF singleton hard-codes the scope of an object such that one and only one instance of a particular class is created per ClassLoader. The scope of the Spring singleton is best described as being per-container and per-bean. This means that, if you define one bean for a particular class in a single Spring container, the Spring container creates one and only one instance of the class defined by that bean definition. The singleton scope is the default scope in Spring. To define a bean as a singleton in XML, you can define a bean as shown in the following example:

Spring的单例bean概念与GoF(GoF)设计模式书中定义的单例模式不同。单例模式对对象的作用域进行硬编码，这样每个类装入器只能创建一个特定类的实例。Spring单例的范围最好描述为每个容器和每个bean。这意味着，如果您在单个Spring容器中为特定类定义一个bean，那么Spring容器将创建由该bean定义定义的类的一个且仅一个实例。单例范围是Spring的默认范围。要在XML中将bean定义为单例，您可以定义一个bean，如下面的例子所示:

<bean id="accountService" class="com.something.DefaultAccountService"/>

<!-- the following is equivalent, though redundant (singleton scope is the default) -->
<bean id="accountService" class="com.something.DefaultAccountService" scope="singleton"/>

The non-singleton prototype scope of bean deployment results in the creation of a new bean instance every time a request for that specific bean is made. That is, the bean is injected into another bean or you request it through a getBean() method call on the container. As a rule, you should use the prototype scope for all stateful beans and the singleton scope for stateless beans.

bean部署的非单例原型范围导致在每次发出对特定bean的请求时都会创建一个新的bean实例。也就是说，bean被注入到另一个bean中，或者您通过容器上的getBean()方法调用请求它。通常，您应该为所有有状态bean使用原型范围，为无状态bean使用单例范围。

下图说明了Spring原型的作用域:

(A data access object (DAO) is not typically configured as a prototype, because a typical DAO does not hold any conversational state. It was easier for us to reuse the core of the singleton diagram.)

The following example defines a bean as a prototype in XML:

数据访问对象(DAO)通常不配置为原型，因为典型的DAO不包含任何会话状态。我们更容易重用单例图的核心。)

下面的例子在XML中将bean定义为原型:

In contrast to the other scopes, Spring does not manage the complete lifecycle of a prototype bean. The container instantiates, configures, and otherwise assembles a prototype object and hands it to the client, with no further record of that prototype instance. Thus, although initialization lifecycle callback methods are called on all objects regardless of scope, in the case of prototypes, configured destruction lifecycle callbacks are not called. The client code must clean up prototype-scoped objects and release expensive resources that the prototype beans hold. To get the Spring container to release resources held by prototype-scoped beans, try using a custom [bean post-processor], which holds a reference to beans that need to be cleaned up.

In some respects, the Spring container’s role in regard to a prototype-scoped bean is a replacement for the Java new operator. All lifecycle management past that point must be handled by the client. (For details on the lifecycle of a bean in the Spring container, see [Lifecycle Callbacks])

与其他作用域不同，Spring不管理原型bean的完整生命周期。容器实例化、配置或以其他方式组装原型对象并将其交给客户端，而不需要该原型实例的进一步记录。因此，尽管初始化生命周期回调方法在所有对象上都被调用，而与范围无关，但是在原型的情况下，配置的销毁生命周期回调不会被调用。客户机代码必须清理原型作用域的对象，并释放原型bean持有的昂贵资源。为了让Spring容器释放原型作用域bean所持有的资源，可以尝试使用一个自定义bean后处理器，它持有一个需要清理的bean引用。

在某些方面，Spring容器在原型作用域bean方面的角色可以替代Java new操作符。所有超过那个点的生命周期管理都必须由客户端处理。(有关Spring容器中bean生命周期的详细信息，请参阅生命周期回调。)

When you use singleton-scoped beans with dependencies on prototype beans, be aware that dependencies are resolved at instantiation time. Thus, if you dependency-inject a prototype-scoped bean into a singleton-scoped bean, a new prototype bean is instantiated and then dependency-injected into the singleton bean. The prototype instance is the sole instance that is ever supplied to the singleton-scoped bean.

当您使用依赖于原型bean的单例作用域bean时，请注意依赖项是在实例化时解析的。因此，如果您依赖地将一个原型作用域的bean注入到一个单例作用域的bean中，那么一个新的原型bean将被实例化，然后依赖注入到单例bean中。prototype实例是惟一提供给单例作用域bean的实例。

However, suppose you want the singleton-scoped bean to acquire a new instance of the prototype-scoped bean repeatedly at runtime. You cannot dependency-inject a prototype-scoped bean into your singleton bean, because that injection occurs only once, when the Spring container instantiates the singleton bean and resolves and injects its dependencies. If you need a new instance of a prototype bean at runtime more than once, see [Method Injection]

但是，假设您希望单例作用域bean在运行时重复获取原型作用域bean的新实例。您不能依赖地将一个原型作用域的bean注入到您的单例bean中，因为这种注入只发生一次，当Spring容器实例化单例bean并解析和注入它的依赖项时。如果您需要在运行时多次使用原型bean的新实例，请参阅方法注入

The request, session, application, and websocket scopes are available only if you use a web-aware Spring ApplicationContext implementation (such as XmlWebApplicationContext). If you use these scopes with regular Spring IoC containers, such as the ClassPathXmlApplicationContext, an IllegalStateException that complains about an unknown bean scope is thrown.

只有在使用web感知的Spring ApplicationContext实现(如XmlWebApplicationContext)时，请求、会话、应用程序和websocket作用域才可用。如果您将这些作用域与常规的Spring IoC容器(如ClassPathXmlApplicationContext)一起使用，则会抛出一个IllegalStateException，它会报错一个未知的bean作用域。

To support the scoping of beans at the request, session, application, and websocket levels (web-scoped beans), some minor initial configuration is required before you define your beans. (This initial setup is not required for the standard scopes: singleton and prototype.)

How you accomplish this initial setup depends on your particular Servlet environment.

If you access scoped beans within Spring Web MVC, in effect, within a request that is processed by the Spring DispatcherServlet, no special setup is necessary. DispatcherServlet already exposes all relevant state.

为了在请求、会话、应用程序和websocket级别(web范围的bean)上支持bean的作用域，需要在定义bean之前进行一些小的初始配置。(标准范围:单例和原型不需要这个初始设置。)

如何完成这个初始设置取决于特定的Servlet环境。

如果您在Spring Web MVC中访问作用域bean，实际上，在由Spring DispatcherServlet处理的请求中，不需要特殊的设置。DispatcherServlet已经公开了所有相关状态。

If you use a Servlet 2.5 web container, with requests processed outside of Spring’s DispatcherServlet (for example, when using JSF or Struts), you need to register the org.springframework.web.context.request.RequestContextListener ServletRequestListener. For Servlet 3.0+, this can be done programmatically by using the WebApplicationInitializer interface. Alternatively, or for older containers, add the following declaration to your web application’s web.xml file:

如果您使用Servlet 2.5 web容器，并在Spring的DispatcherServlet之外处理请求(例如，在使用JSF或Struts时)，那么您需要注册org.springframework.web.context.request.RequestContextListener 的ServletRequestListener。对于Servlet 3.0+，这可以通过使用WebApplicationInitializer接口以编程方式实现。或者，对于较旧的容器，将以下声明添加到web应用程序的web.xml文件中:

<web-app>
    ...
    <listener>
        <listener-class>
            org.springframework.web.context.request.RequestContextListener
        </listener-class>
    </listener>
    ...
</web-app>

Alternatively, if there are issues with your listener setup, consider using Spring’s RequestContextFilter. The filter mapping depends on the surrounding web application configuration, so you have to change it as appropriate. The following listing shows the filter part of a web application:

另外，如果侦听器设置有问题，可以考虑使用Spring的RequestContextFilter。筛选器映射依赖于周围的web应用程序配置，因此您必须对其进行适当的更改。下面的清单显示了web应用程序的过滤部分:

<web-app>
    ...
    <filter>
        <filter-name>requestContextFilter</filter-name>
        <filter-class>org.springframework.web.filter.RequestContextFilter</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>requestContextFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>
    ...
</web-app>

DispatcherServlet, RequestContextListener, and RequestContextFilter all do exactly the same thing, namely bind the HTTP request object to the Thread that is servicing that request. This makes beans that are request- and session-scoped available further down the call chain.

DispatcherServlet、RequestContextListener和RequestContextFilter都做完全相同的事情，即将HTTP请求对象绑定到服务该请求的线程。这使得在request和session范围内的bean可以在调用链的更底层使用。

请考虑以下bean定义的XML配置:

The Spring container creates a new instance of the LoginAction bean by using the loginAction bean definition for each and every HTTP request. That is, the loginAction bean is scoped at the HTTP request level. You can change the internal state of the instance that is created as much as you want, because other instances created from the same loginAction bean definition do not see these changes in state. They are particular to an individual request. When the request completes processing, the bean that is scoped to the request is discarded.

通过为每个HTTP请求使用LoginAction bean时，Spring容器创建了LoginAction bean的新实例。也就是说，loginAction bean的作用域在HTTP请求级别。您可以随意更改创建的实例的内部状态，因为从相同的loginAction bean定义创建的其他实例在状态中看不到这些更改。它们是特定于个人请求的。当请求完成处理时，作用域为request的bean被丢弃。

When using annotation-driven components or Java configuration, the @RequestScope annotation can be used to assign a component to the request scope. The following example shows how to do so:

在使用注释驱动的组件或Java配置时，可以使用@RequestScope注释将组件分配给请求范围。下面的例子演示了如何做到这一点:

@RequestScope
@Component
public class LoginAction {
    // ...
}

Consider the following XML configuration for a bean definition:

The Spring container creates a new instance of the UserPreferences bean by using the userPreferences bean definition for the lifetime of a single HTTP Session. In other words, the userPreferences bean is effectively scoped at the HTTP Session level. As with request-scoped beans, you can change the internal state of the instance that is created as much as you want, knowing that other HTTP Session instances that are also using instances created from the same userPreferences bean definition do not see these changes in state, because they are particular to an individual HTTP Session. When the HTTP Session is eventually discarded, the bean that is scoped to that particular HTTP Session is also discarded.

通过为单个HTTP会话的生命周期使用UserPreferences bean定义，Spring容器创建了UserPreferences bean的一个新实例。换句话说，userPreferences bean有效地限定在HTTP会话级别的范围内。与请求范围内bean一样,你可以改变内部状态的实例创建尽可能多的你想要的,知道其他HTTP会话实例也使用相同的实例创建userPreferences bean定义看不到这些变化状态,因为他们是特定于一个单独的HTTP会话.当HTTPSession最终被销毁时，作用域为该特定HTTP会话的bean也被销毁。

When using annotation-driven components or Java configuration, you can use the @SessionScope annotation to assign a component to the session scope.

用Java注解实现：

@SessionScope
@Component
public class UserPreferences {
    // ...
}

@ApplicationScope
@Component
public class AppPreferences {
    // ...
}

The Spring container creates a new instance of the AppPreferences bean by using the appPreferences bean definition once for the entire web application. That is, the appPreferences bean is scoped at the ServletContext level and stored as a regular ServletContext attribute. This is somewhat similar to a Spring singleton bean but differs in two important ways: It is a singleton per ServletContext, not per Spring ‘ApplicationContext’ (for which there may be several in any given web application), and it is actually exposed and therefore visible as a ServletContext attribute.

通过为整个web应用程序使用一次AppPreferences bean定义，Spring容器创建了AppPreferences bean的一个新实例。也就是说，appPreferences bean的作用域在ServletContext级别，并存储为一个常规的ServletContext属性。这有点类似于单例bean,但在两个重要方面不同:他为每个ServletContext创建同一个实例，并不是每个spring的容器（在任何给定的web应用程序中都可能有多个）,它实际上是暴露,因此可见ServletContext属性。

The Spring IoC container manages not only the instantiation of your objects (beans), but also the wiring up of collaborators (or dependencies). If you want to inject (for example) an HTTP request-scoped bean into another bean of a longer-lived scope, you may choose to inject an AOP proxy in place of the scoped bean. That is, you need to inject a proxy object that exposes the same public interface as the scoped object but that can also retrieve the real target object from the relevant scope (such as an HTTP request) and delegate method calls onto the real object.

Spring IoC容器不仅管理对象(bean)的实例化，还管理协作者(或依赖项)的连接。如果您想将(例如)一个HTTP Request作用域的bean注入到另一个更长的作用域的bean中，您可以选择注入一个AOP代理来代替作用域的bean。也就是说，您需要注入一个代理对象，它与作用域对象公开相同的公共接口，但也可以从相关作用域(如HTTP请求)检索实际目标对象，并将方法调用委托给实际对象。

You may also use <aop:scoped-proxy> between beans that are scoped as singleton, with the reference then going through an intermediate proxy that is serializable and therefore able to re-obtain the target singleton bean on deserialization.

When declaring <aop:scoped-proxy/> against a bean of scope prototype, every method call on the shared proxy leads to the creation of a new target instance to which the call is then being forwarded.

Also, scoped proxies are not the only way to access beans from shorter scopes in a lifecycle-safe fashion. You may also declare your injection point (that is, the constructor or setter argument or autowired field) as ObjectFactory<MyTargetBean>, allowing for a getObject() call to retrieve the current instance on demand every time it is needed — without holding on to the instance or storing it separately.

As an extended variant, you may declare ObjectProvider<MyTargetBean>, which delivers several additional access variants, including getIfAvailable and getIfUnique.

By default, when the Spring container creates a proxy for a bean that is marked up with the `` element, a CGLIB-based class proxy is created.

默认情况下，当Spring容器为用aop:scoped-proxy/元素标记的bean创建代理时，将创建一个基于cglib的类代理。

CGLIB proxies intercept only public method calls! Do not call non-public methods on such a proxy. They are not delegated to the actual scoped target object.

CGLIB代理只拦截公共方法调用!不要在这样的代理上调用非公共方法。它们没有被委托给实际作用域的目标对象。

Alternatively, you can configure the Spring container to create standard JDK interface-based proxies for such scoped beans, by specifying false for the value of the proxy-target-class attribute of the `` element. Using JDK interface-based proxies means that you do not need additional libraries in your application classpath to affect such proxying. However, it also means that the class of the scoped bean must implement at least one interface and that all collaborators into which the scoped bean is injected must reference the bean through one of its interfaces. The following example shows a proxy based on an interface:

或者，您可以配置Spring容器，为这种作用域bean创建标准的基于JDK接口的代理，方法是为aop:作用域代理/元素的proxy-target-class属性的值指定false。使用基于JDK接口的代理意味着您不需要在应用程序类路径中添加其他库来影响这种代理。但是，这也意味着作用域bean的类必须实现至少一个接口，并且所有注入作用域bean的协作者必须通过它的一个接口引用bean。

<!-- DefaultUserPreferences implements the UserPreferences interface -->
<bean id="userPreferences" class="com.stuff.DefaultUserPreferences" scope="session">
    <aop:scoped-proxy proxy-target-class="false"/>
</bean>

<bean id="userManager" class="com.stuff.UserManager">
    <property name="userPreferences" ref="userPreferences"/>
</bean>

For more detailed information about choosing class-based or interface-based proxying, see [Proxying Mechanisms]

有关选择基于类或基于接口的代理的详细信息，请参阅代理机制

The bean scoping mechanism is extensible. You can define your own scopes or even redefine existing scopes, although the latter is considered bad practice and you cannot override the built-in singleton and prototype scopes.

bean作用域机制是可扩展的。您可以定义自己的作用域，甚至可以重新定义现有的作用域，尽管后者被认为是不好的实践，并且您不能覆盖内置的单例和原型作用域。

After you write and test one or more custom Scope implementations, you need to make the Spring container aware of your new scopes. The following method is the central method to register a new Scope with the Spring container:

在编写和测试一个或多个自定义范围实现之后，您需要让Spring容器知道您的新范围。下面的方法是向Spring容器注册新范围的中心方法:

This method is declared on the ConfigurableBeanFactory interface, which is available through the BeanFactory property on most of the concrete ApplicationContext implementations that ship with Spring.

The first argument to the registerScope(..) method is the unique name associated with a scope. Examples of such names in the Spring container itself are singleton and prototype. The second argument to the registerScope(..) method is an actual instance of the custom Scope implementation that you wish to register and use.

Suppose that you write your custom Scope implementation, and then register it as shown in the next example.

此方法在ConfigurableBeanFactory接口上声明，该接口可通过Spring附带的大多数具体ApplicationContext实现上的BeanFactory属性获得。

registerScope(…)方法的第一个参数是与范围关联的惟一名称。Spring容器中此类名称的例子有singleton和prototype。registerScope(…)方法的第二个参数是您希望注册和使用的自定义范围实现的实际实例。

假设您编写了自定义范围实现，然后在下一个示例中注册它。

The next example uses SimpleThreadScope, which is included with Spring but is not registered by default. The instructions would be the same for your own custom Scope implementations.

下一个示例使用SimpleThreadScope，它包含在Spring中，但默认情况下不注册。对于您自己的自定义范围实现，指令将是相同的。

Scope threadScope = new SimpleThreadScope();
beanFactory.registerScope("thread", threadScope);

You can then create bean definitions that adhere to the scoping rules of your custom Scope, as follows:

然后，您可以创建遵循自定义作用域的作用域规则的bean定义，如下所示:

With a custom Scope implementation, you are not limited to programmatic registration of the scope. You can also do the Scope registration declaratively, by using the CustomScopeConfigurer class, as the following example shows:

使用自定义范围实现，您不局限于范围的程序性注册。您还可以通过使用CustomScopeConfigurer类声明性地进行范围注册，如下面的示例所示:

<?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:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
        https://www.springframework.org/schema/beans/spring-beans.xsd
        http://www.springframework.org/schema/aop
        https://www.springframework.org/schema/aop/spring-aop.xsd">

    <bean class="org.springframework.beans.factory.config.CustomScopeConfigurer">
        <property name="scopes">
            <map>
                <entry key="thread">
                    <bean class="org.springframework.context.support.SimpleThreadScope"/>
                </entry>
            </map>
        </property>
    </bean>

    <bean id="thing2" class="x.y.Thing2" scope="thread">
        <property name="name" value="Rick"/>
        <aop:scoped-proxy/>
    </bean>

    <bean id="thing1" class="x.y.Thing1">
        <property name="thing2" ref="thing2"/>
    </bean>

</beans>

When you place <aop:scoped-proxy/> in a FactoryBean implementation, it is the factory bean itself that is scoped, not the object returned from getObject().

在FactoryBean实现中放置aop:scoped-proxy/时，受作用域限制的是工厂bean本身，而不是从getObject()返回的对象。

A bean definition can contain a lot of configuration information, including constructor arguments, property values, and container-specific information, such as the initialization method, a static factory method name, and so on. A child bean definition inherits configuration data from a parent definition. The child definition can override some values or add others as needed. Using parent and child bean definitions can save a lot of typing. Effectively, this is a form of templating.

bean定义可以包含很多配置信息，包括构造函数参数、属性值和特定于容器的信息，比如初始化方法、静态工厂方法名等等。子bean定义从父定义继承配置数据。子定义可以根据需要覆盖某些值或添加其他值。使用父bean和子bean定义可以节省大量输入。实际上，这是模板的一种形式。

If you work with an ApplicationContext interface programmatically, child bean definitions are represented by the ChildBeanDefinition class. Most users do not work with them on this level. Instead, they configure bean definitions declaratively in a class such as the ClassPathXmlApplicationContext. When you use XML-based configuration metadata, you can indicate a child bean definition by using the parent attribute, specifying the parent bean as the value of this attribute. The following example shows how to do so:

如果您以编程方式使用ApplicationContext接口，则子bean定义由ChildBeanDefinition类表示。大多数用户在这个级别上不使用它们。相反，它们在类(如ClassPathXmlApplicationContext)中声明式地配置bean定义。当您使用基于xml的配置元数据时，您可以通过使用父属性来指示子bean定义，并将父bean指定为该属性的值。下面的例子演示了如何做到这一点:

<bean id="inheritedTestBean" abstract="true"
        class="org.springframework.beans.TestBean">
    <property name="name" value="parent"/>
    <property name="age" value="1"/>
</bean>

<bean id="inheritsWithDifferentClass"
        class="org.springframework.beans.DerivedTestBean"
        parent="inheritedTestBean" init-method="initialize">  <!--	Note the parent attribute.-->
    <property name="name" value="override"/>
    <!-- the age property value of 1 will be inherited from parent -->
</bean>

A child bean definition uses the bean class from the parent definition if none is specified but can also override it. In the latter case, the child bean class must be compatible with the parent (that is, it must accept the parent’s property values).

如果没有指定任何bean，则子bean定义使用来自父定义的bean类，但也可以覆盖它。在后一种情况下，子bean类必须与父类兼容(也就是说，它必须接受父类的属性值)。

A child bean definition inherits scope, constructor argument values, property values, and method overrides from the parent, with the option to add new values. Any scope, initialization method, destroy method, or static factory method settings that you specify override the corresponding parent settings.

子bean定义继承父bean的作用域、构造函数参数值、属性值和方法覆盖，并具有添加新值的选项。您指定的任何范围、初始化方法、销毁方法或静态工厂方法设置都将覆盖相应的父设置。

The remaining settings are always taken from the child definition: depends on, autowire mode, dependency check, singleton, and lazy init.

其余的设置总是取自子定义:依赖、自动装配模式、依赖项检查、单例和惰性初始化。

The preceding example explicitly marks the parent bean definition as abstract by using the abstract attribute. If the parent definition does not specify a class, explicitly marking the parent bean definition as abstract is required, as the following example shows:

前面的示例通过使用抽象属性显式地将父bean定义标记为抽象。如果父定义没有指定类，则需要显式地将父bean定义标记为抽象，如下面的示例所示:

<bean id="inheritedTestBeanWithoutClass" abstract="true">
    <property name="name" value="parent"/>
    <property name="age" value="1"/>
</bean>

<bean id="inheritsWithClass" class="org.springframework.beans.DerivedTestBean"
        parent="inheritedTestBeanWithoutClass" init-method="initialize">
    <property name="name" value="override"/>
    <!-- age will inherit the value of 1 from the parent bean definition-->
</bean>

我自己的例子：

@NoArgsConstructor
@AllArgsConstructor
@Data
public class ParentClass {
    private String name;
    private int age;
}
public class SonClass extends ParentClass {
}

    <bean id="parentClass" class="com.leishida.spring.ParentClass">
        <property name="name" value="parent"/>
        <property name="age" value="35"/>
    </bean>
    <bean id="sonClass" class="com.leishida.spring.SonClass" parent="parentClass">
        <property name="name" value="override"/>
    </bean>

    @org.junit.Test
    public void test10(){
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        Object son = context.getBean("sonClass");
        System.out.println(son);
        //    ParentClass(name=override, age=35)
    }

可以通过parent来继承父Bean的属性，同时也支持重写，如果父Bean没有具体指定类，需要加abstract，子类Bean继承父Bean时使用parent标签说明

The parent bean cannot be instantiated on its own because it is incomplete, and it is also explicitly marked as abstract. When a definition is abstract, it is usable only as a pure template bean definition that serves as a parent definition for child definitions. Trying to use such an abstract parent bean on its own, by referring to it as a ref property of another bean or doing an explicit getBean() call with the parent bean ID returns an error. Similarly, the container’s internal preInstantiateSingletons() method ignores bean definitions that are defined as abstract.

父bean不能单独实例化，因为它是不完整的，而且它也被显式地标记为抽象的。当定义是抽象的时，它只能作为作为子定义的父定义的纯模板bean定义使用。尝试单独使用这样一个抽象的父bean，方法是将它引用为另一个bean的ref属性，或者使用父bean ID执行显式的getBean()调用，这会返回一个错误。类似地，容器的内部preInstantiateSingletons()方法忽略定义为抽象的bean定义。

我们现在给刚才的父Bean加上"abstract=true"试试实例化父bean

    @org.junit.Test
    public void test10(){
        ApplicationContext context = new ClassPathXmlApplicationContext("applicationContext.xml");
        Object son = context.getBean("sonClass");
        System.out.println(son);
        //    ParentClass(name=override, age=35)
        Object parent = context.getBean("parentClass");
        System.out.println(parent); //org.springframework.beans.factory.BeanIsAbstractException:
    }

ApplicationContext pre-instantiates all singletons by default. Therefore, it is important (at least for singleton beans) that if you have a (parent) bean definition which you intend to use only as a template, and this definition specifies a class, you must make sure to set the abstract attribute to true, otherwise the application context will actually (attempt to) pre-instantiate the abstract bean.

默认情况下，ApplicationContext会预先实例化所有的单例对象。因此,它是重要的(至少对单例bean),如果你有一个(父)bean定义你只打算使用作为模板,这个定义指定了一个类,您必须确保设置抽象属性为true,否则应用程序上下文会(试图)pre-instantiate抽象的bean。

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容器。接下来的几节将描述这些集成接口。

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

This first example illustrates basic usage. The example shows a custom BeanPostProcessor implementation that invokes the toString() method of each bean as it is created by the container and prints the resulting string to the system console.

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

The following listing shows the custom BeanPostProcessor implementation class definition:

下面的清单显示了自定义BeanPostProcessor实现类定义:

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;
    }
}

The following beans element uses the InstantiationTracingBeanPostProcessor:

下面的bean元素使用了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 (messenger)时，执行此自定义
    BeanPostProcessor实现将把事实输出到系统控制台
    -->
    <bean class="scripting.InstantiationTracingBeanPostProcessor"/>

</beans>

Using callback interfaces or annotations in conjunction with a custom BeanPostProcessor implementation is a common means of extending the Spring IoC container. An example is Spring’s RequiredAnnotationBeanPostProcessor — a BeanPostProcessor implementation that ships with the Spring distribution and that ensures that JavaBean properties on beans that are marked with an (arbitrary) annotation are actually (configured to be) dependency-injected with a value.

将回调接口或注释与自定义BeanPostProcessor实现结合使用是扩展Spring IoC容器的常见方法。一个例子是Spring的RequiredAnnotationBeanPostProcessor——这是一个随Spring发行版一起发布的BeanPostProcessor实现，它确保使用(任意)注释标记的bean上的JavaBean属性实际上(配置为)被注入了一个值。

The next extension point that we look at is the org.springframework.beans.factory.config.BeanFactoryPostProcessor. The semantics of this interface are similar to those of the BeanPostProcessor, with one major difference: BeanFactoryPostProcessor operates on the bean configuration metadata. That is, the Spring IoC container lets a BeanFactoryPostProcessor read the configuration metadata and potentially change it before the container instantiates any beans other than BeanFactoryPostProcessor instances.

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

You can configure multiple BeanFactoryPostProcessor instances, and you can control the order in which these BeanFactoryPostProcessor instances run by setting the order property. However, you can only set this property if the BeanFactoryPostProcessor implements the Ordered interface. If you write your own BeanFactoryPostProcessor, you should consider implementing the Ordered interface, too. See the javadoc of the [BeanFactoryPostProcessor]and [Ordered] interfaces for more details.

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

You can use the PropertySourcesPlaceholderConfigurer to externalize property values from a bean definition in a separate file by using the standard Java Properties format. Doing so enables the person deploying an application to customize environment-specific properties, such as database URLs and passwords, without the complexity or risk of modifying the main XML definition file or files for the container.

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

Consider the following XML-based configuration metadata fragment, where a DataSource with placeholder values is defined:

考虑以下基于xml的配置元数据片段，其中定义了一个具有占位符值的数据源:

<bean class="org.springframework.context.support.PropertySourcesPlaceholderConfigurer">
    <property name="locations" value="classpath:com/something/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>

The example shows properties configured from an external Properties file. At runtime, a PropertySourcesPlaceholderConfigurer is applied to the metadata that replaces some properties of the DataSource. The values to replace are specified as placeholders of the form ${property-name}, which follows the Ant and log4j and JSP EL style.

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

The actual values come from another file in the standard Java Properties format:

实际值来自另一个标准Java属性格式的文件:

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

Therefore, the ${jdbc.username} string is replaced at runtime with the value, ‘sa’, and the same applies for other placeholder values that match keys in the properties file. The PropertySourcesPlaceholderConfigurer checks for placeholders in most properties and attributes of a bean definition. Furthermore, you can customize the placeholder prefix and suffix.

因此,$ {jdbc。用户名}字符串在运行时被替换为值’sa’，相同的情况也适用于其他与属性文件中的键匹配的占位符值。PropertySourcesPlaceholderConfigurer检查bean定义的大多数属性和属性中的占位符。此外，您还可以自定义占位符前缀和后缀。

With the context namespace introduced in Spring 2.5, you can configure property placeholders with a dedicated configuration element. You can provide one or more locations as a comma-separated list in the location attribute, as the following example shows:

通过Spring 2.5中引入的context命名空间，您可以使用专用的配置元素来配置属性占位符。您可以在location属性中以逗号分隔的列表的形式提供一个或多个位置，如下面的示例所示:

The PropertySourcesPlaceholderConfigurer not only looks for properties in the Properties file you specify. By default, if it cannot find a property in the specified properties files, it checks against Spring Environment properties and regular Java System properties.

PropertySourcesPlaceholderConfigurer不仅在您指定的属性文件中查找属性。默认情况下，如果在指定的属性文件中找不到属性，它会检查Spring环境属性和常规Java系统属性。

You can use the PropertySourcesPlaceholderConfigurer to substitute class names, which is sometimes useful when you have to pick a particular implementation class at runtime. The following example shows how to do so:

您可以使用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}"/>

If the class cannot be resolved at runtime to a valid class, resolution of the bean fails when it is about to be created, which is during the preInstantiateSingletons() phase of an ApplicationContext for a non-lazy-init bean.

如果在运行时不能将类解析为有效的类，则在即将创建bean时，也就是在非lazy-init bean的ApplicationContext的 preInstantiateSingletons()阶段，bean的解析将失败。

The PropertyOverrideConfigurer, another bean factory post-processor, resembles the PropertySourcesPlaceholderConfigurer, but unlike the latter, the original definitions can have default values or no values at all for bean properties. If an overriding Properties file does not have an entry for a certain bean property, the default context definition is used.

Note that the bean definition is not aware of being overridden, so it is not immediately obvious from the XML definition file that the override configurer is being used. In case of multiple PropertyOverrideConfigurer instances that define different values for the same bean property, the last one wins, due to the overriding mechanism.

另一个bean工厂后处理器PropertyOverrideConfigurer类似于PropertySourcesPlaceholderConfigurer，但与后者不同，原始定义可以有缺省值，也可以没有bean属性的值。如果覆盖的属性文件没有某个bean属性的条目，则使用默认的context定义。

注意，bean定义不知道被覆盖，所以从XML定义文件中不能立即看出使用了覆盖配置程序。如果有多个PropertyOverrideConfigurer实例为同一个bean属性定义不同的值，由于覆盖机制，最后一个实例胜出。

Properties file configuration lines take the following format:

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

beanName.property=value

The following listing shows an example of the format:

下面的清单显示了该格式的一个示例:

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

This example file can be used with a container definition that contains a bean called dataSource that has driver and url properties.

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

Compound property names are also supported, as long as every component of the path except the final property being overridden is already non-null (presumably initialized by the constructors). In the following example, the sammy property of the bob property of the fred property of the tom bean is set to the scalar value 123:

也支持复合属性名，只要路径的每个组件(被覆盖的最后一个属性除外)都是非空的(可能是由构造函数初始化的)。在下面的例子中，tom bean的fred属性的bob属性的sammy属性被设置为标量值123:

tom.fred.bob.sammy=123

Specified override values are always literal values. They are not translated into bean references. This convention also applies when the original value in the XML bean definition specifies a bean reference.

指定的重写值总是文字值。它们不会被转换成bean引用。当XML bean定义中的原始值指定一个bean引用时，也适用这种约定。

With the context namespace introduced in Spring 2.5, it is possible to configure property overriding with a dedicated configuration element, as the following example shows:

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

You can implement the org.springframework.beans.factory.FactoryBean interface for objects that are themselves factories.

The FactoryBean interface is a point of pluggability into the Spring IoC container’s instantiation logic. If you have complex initialization code that is better expressed in Java as opposed to a (potentially) verbose amount of XML, you can create your own FactoryBean, write the complex initialization inside that class, and then plug your custom FactoryBean into the container.

您可以实现org.springframe .bean .factory.FactoryBean接口用于本身就是工厂的对象。

FactoryBean接口是一个可插入Spring IoC容器实例化逻辑的点。如果您有复杂的初始化代码，用Java表示比(可能的)冗长的XML更好，那么您可以创建自己的FactoryBean，在该类中编写复杂的初始化，然后将定制的FactoryBean插入容器中。

The FactoryBean interface provides three methods:

• Object getObject(): Returns an instance of the object this factory creates. The instance can possibly be shared, depending on whether this factory returns singletons or prototypes.
• boolean isSingleton(): Returns true if this FactoryBean returns singletons or false otherwise.
• Class getObjectType(): Returns the object type returned by the getObject() method or null if the type is not known in advance.

FactoryBean接口提供了三种方法:

• 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.

FactoryBean的概念和接口在Spring框架的许多地方都有使用。FactoryBean接口的50多个实现都附带了Spring本身。

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