本系列基于最新5.3.10版本，大部分内容copy于官方文档…
官方文档地址
内容较杂，建议粗略过一遍，熟悉下概念即可，后续结合实际开发详解。
典型的企业应用程序不包含单个对象（或 Spring 用语中的 bean）。即使是最简单的应用程序也有一些对象，它们协同工作以呈现最终用户所看到的应用程序。下一节将解释如何从定义多个独立的 bean到完全实现的应用程序，其中对象如何协作以实现目标。
1.1 依赖注入(DI)依赖注入 (DI) 是一个过程，其中对象仅通过构造函数参数、工厂方法的参数或在对象实例被构造或从工厂方法返回。然后容器在创建 bean 时注入这些依赖项。这个过程基本上是 bean 本身的逆过程（因此得名，控制反转），通过使用类的直接构造或服务定位器模式自行控制其依赖项的实例化或位置。
DI 原则使代码更清晰，当对象提供依赖关系时，解耦更有效。该对象不查找其依赖项，也不知道依赖项的位置或类。因此，您的类变得更容易测试，特别是当依赖项位于接口或抽象基类上时，这允许在单元测试中使用存根或模拟实现。
DI 存在两种主要变体：基于构造函数的依赖注入和基于 Setter 的依赖注入。
1.1.1 基于构造函数的依赖注入基于构造函数的 DI 是通过容器调用具有多个参数的构造函数来完成的，每个参数代表一个依赖项。调用static带有特定参数的工厂方法来构造 bean 几乎是等效的，本讨论将static类似地处理构造函数和工厂方法的参数。
以下示例显示了UserInfo类依赖一个Dept属性，通过构造函数注入：
@Data
public class UserInfo {
public UserInfo() {
}
String username;
Integer pwd;
Dept dept;
public UserInfo(Dept dept) {
this.dept = dept;
}
}
接着在XML中，我们可以通过
- 一个
元素表示构造方法的一个参数，且使用时不区分顺序。 - 通过
元素的index属性可以指定该参数的位置索引，位置从0开始。 元素还提供了type属性用来指定参数的类型，避免字符串和基本数据类型的混淆。
构造函数参数解析
构造函数参数解析通过使用参数的类型匹配。如果 bean 定义的构造函数参数中不存在潜在的歧义，那么在构建bean时构造函数参数的顺序就是将这些参数提供给适当的构造函数的顺序。
比如以下类：
package x.y;
public class ThingOne {
public ThingOne(ThingTwo thingTwo, ThingThree thingThree) {
// ...
}
}
假设ThingTwo和ThingThree类不通过继承相关，则不存在潜在的歧义。因此，以下配置工作正常，不需要在`元素中显式指定构造函数参数索引或类型 。
当另一个 bean 被引用时，类型是已知的，并且可以发生匹配（就像前面的例子一样）。当使用简单类型时，例如
比如以下类：
package examples;
public class ExampleBean {
// Number of years to calculate the Ultimate Answer
private final int years;
// The Answer to Life, the Universe, and Everything
private final String ultimateAnswer;
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}
构造函数参数类型匹配
在上述场景中，如果您通过type属性显式指定构造函数参数的类型，则容器可以使用简单类型的类型匹配，如下例所示：
构造函数参数索引
您可以使用该index属性显式指定构造函数参数的索引，如以下示例所示：
除了解决多个简单值的歧义之外，指定索引还可以解决构造函数具有两个相同类型参数的歧义。
该索引是从 0 开始的。
构造函数参数名称
您还可以使用构造函数参数名称进行值消歧，如以下示例所示：
请记住，要使这项工作开箱即用，您的代码必须在启用调试标志的情况下进行编译，以便 Spring 可以从构造函数中查找参数名称。如果您不能或不想使用调试标志编译代码，则可以使用 @ConstructorProperties JDK 注释显式命名构造函数参数。示例类必须如下所示：
package examples;
public class ExampleBean {
// Fields omitted
@ConstructorProperties({"years", "ultimateAnswer"})
public ExampleBean(int years, String ultimateAnswer) {
this.years = years;
this.ultimateAnswer = ultimateAnswer;
}
}
总结：
如果为Bean对象注入依赖时，通过构造参数输入时，需要有参构造，还需要各种声明，灵活性差，仅靠重载限制太多。一般实际不会用这么方式。
1.1.2 基于 Setter 的依赖注入基于 Setter 的 DI 是通过容器在调用无参数构造函数或无参数static工厂方法来实例化bean 后调用 bean 上的 setter 方法来完成的。
以下示例显示了一个只能使用纯 setter 注入进行依赖注入的类，在依赖注入时，会调用Setter方法进行注入。
ApplicationContext支持基于构造函数和Setter的 DI注入其管理的Bean对象。
但是，大多数 Spring 用户不直接（即以编程方式）使用这些类，而是使用 XMLbean 定义、带注释的组件（即用@Component、 @Controller等注释的类）或@Bean基于 Java 的@Configuration类中的方法。这些源然后在内部转换为实例Bean Definition并用于加载整个 Spring IoC 容器实例。
1.1.3 依赖解析过程容器执行bean依赖解析如下：
使用ApplicationContext对所有 bean 的配置元数据进行创建和初始化。配置元数据可以由 XML、Java 代码或注解指定。
对于每个 bean，它的依赖关系以属性、构造函数参数或静态工厂方法的参数（如果您使用它而不是普通构造函数）的形式表示。在实际创建 bean 时，将这些依赖关系提供给 bean。
每个属性或构造函数参数都是要设置的值的实际定义，或者是对容器中另一个 bean 的引用。
作为值的每个属性或构造函数参数都从其指定格式转换为该属性或构造函数参数的实际类型。默认情况下，Spring 可以将以字符串格式提供的值转换为所有内置类型，例如int、 long、String、boolean等。
Spring 容器在创建容器时验证每个 bean 的配置。但是，在实际创建 bean 之前不会设置 bean 属性本身。创建容器时会创建单例范围并设置为预实例化（默认）的 Bean。范围在Bean Scopes中定义。否则，仅在请求时才创建 bean。创建 bean 可能会导致创建 bean 图，因为 bean 的依赖项及其依赖项的依赖项（等等）被创建和分配。请注意，这些依赖项之间的解析不匹配可能会出现较晚 — 即，在第一次创建受影响的 bean 时。
1.1.4 循环依赖什么是循环依赖？
顾名思义，循环依赖就是A依赖B，B又依赖A，两者之间的依赖关系形成了一个圆环，通常是由于不正确的编码所导致。
例如：A类通过构造函数注入需要B类的实例，B类通过构造函数注入需要A类的实例。如果您将类 A 和 B 的 bean 配置为相互注入，则 Spring IoC 容器在运行时检测到此循环引用，并抛出一个BeanCurrentlyInCreationException。
如何解决？
一种可能的解决方案是编辑一些类的源代码，以便由 setter 而不是构造函数来配置。或者，避免构造函数注入并仅使用 setter 注入。也就是说，虽然不推荐，但是可以通过setter注入来配置循环依赖。
与典型情况（没有循环依赖）不同，bean A 和 bean B 之间的循环依赖迫使其中一个 bean 在完全初始化之前注入另一个 bean（经典的鸡和蛋场景）。
如果不存在循环依赖，当一个或多个协作 bean 被注入依赖 bean 时，每个协作 bean 在注入依赖 bean 之前都已完全配置。这意味着，如果 bean A 依赖 bean B，则 Spring IoC 容器在调用 bean A 上的 setter 方法之前完全配置 bean B。换句话说，bean 被实例化（如果它不是预实例化的单例)，设置它的依赖，并调用相关的生命周期方法（如配置的init方法 或InitializingBean回调方法）。
依赖注入的例子
以下示例将基于 XML 的配置元数据用于基于 setter 的 DI。Spring XML 配置文件的一小部分指定了一些 bean 定义，如下所示：
以下示例显示了相应的ExampleBean类：
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
public void setBeanOne(AnotherBean beanOne) {
this.beanOne = beanOne;
}
public void setBeanTwo(YetAnotherBean beanTwo) {
this.beanTwo = beanTwo;
}
public void setIntegerProperty(int i) {
this.i = i;
}
}
在前面的示例中，setter 被声明为与 XML 文件中指定的属性匹配。以下示例使用基于构造函数的 DI：
以下示例显示了相应的ExampleBean类：
public class ExampleBean {
private AnotherBean beanOne;
private YetAnotherBean beanTwo;
private int i;
public ExampleBean(
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
this.beanOne = anotherBean;
this.beanTwo = yetAnotherBean;
this.i = i;
}
}
bean 定义中指定的构造函数参数用作ExampleBean.
现在考虑这个例子的一个变体，其中不使用构造函数，而是告诉 Spring 调用static工厂方法来返回对象的实例：
以下示例显示了相应的ExampleBean类：
public class ExampleBean {
// a private constructor
private ExampleBean(...) {
...
}
// a static factory method; the arguments to this method can be
// considered the dependencies of the bean that is returned,
// regardless of how those arguments are actually used.
public static ExampleBean createInstance (
AnotherBean anotherBean, YetAnotherBean yetAnotherBean, int i) {
ExampleBean eb = new ExampleBean (...);
// some other operations...
return eb;
}
}
static工厂方法的参数由
如上一节所述，可以将 bean 属性和构造函数参数定义为对其他托管 bean（协作者）的引用或作为内联定义的值。为此，Spring 的基于 XML 的配置元数据支持其
在value所述的属性
以下示例使用p命令空间进行更简洁的 XML 配置：
前面的 XML 更简洁。但是，拼写错误是在运行时而不是设计时发现的，除非您在创建 bean 定义时使用支持自动属性完成的 IDE（例如IntelliJ IDEA或Spring Tools for Eclipse）。强烈建议使用此类 IDE 帮助。
您还可以配置一个java.util.Properties实例，如下所示：
jdbc.driver.className=com.mysql.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/mydb
Spring 容器通过使用 JavaBeans机制将
idref元素
所述idref元件是一个简单的防错方法对通过id（一个字符串值-而不是参考）在该容器另一个bean的一个
前面的 bean 定义片段与以下片段完全等效（在运行时）：
第一种形式比第二种形式更可取，因为使用idref标记可以让容器在部署时验证引用的命名 bean 是否实际存在。在第二个变体中，不对传递给beantargetName属性的值执行验证client。只有在client实际实例化 bean时才会发现拼写错误（最有可能是致命的结果）。如果client bean 是原型bean，则可能只有在部署容器很久之后才能发现此错误和由此产生的异常。
对其他 Bean 的引用
ref元素是在
通过标记的bean属性指定目标 bean是最通用的形式，它允许创建对同一容器或父容器中的任何 bean 的引用，无论它是否在同一 XML 文件中。bean属性的值 可以id与目标bean的属性相同，也可以与目标bean的name属性中的值之一相同。以下示例显示了如何使用ref元素：
通过parent属性指定目标 bean会创建对当前容器的父容器中的 bean 的引用。parent 属性的值可以id与目标 bean的属性或目标 bean 属性中的值之一相同name。目标 bean 必须在当前容器的父容器中。您应该主要在具有容器层次结构并且希望使用与父 bean 同名的代理将现有 bean 包装在父容器中时使用此 bean 引用变体。以下清单显示了如何使用该parent属性：
在local上属性ref元素在4.0豆XSD不再支持，因为它没有提供比普通值bean参考了。升级到 4.0 架构时更改现有ref local引用ref bean。
内部 bean 定义不需要定义的 ID 或名称。如果指定，容器不会使用这样的值作为标识符。容器scope在创建时也会忽略标志，因为内部 bean 始终是匿名的，并且始终与外部 bean 一起创建。不可能独立访问内部 bean 或将它们注入除封闭 bean 之外的协作 bean 中。
作为一个极端情况，可以从自定义范围接收销毁回调——例如，对于包含在单例 bean 中的请求范围内的 bean。内部 bean 实例的创建与其包含的 bean 相关联，但销毁回调让它参与请求范围的生命周期。这不是一个常见的场景。内部 bean 通常只是共享它们包含的 bean 的作用域。
，
administrator@example.org support@example.org development@example.org just some string
映射键或值或集合值的值也可以是以下任何元素：
bean | ref | idref | list | set | map | props | value | null
Spring 容器还支持合并集合。应用程序开发人员可以定义父，，
，，
关于合并的这一节讨论了父子 bean 机制。不熟悉父和子 bean 定义的读者可能希望在继续之前阅读 相关部分。
以下示例演示了集合合并：
administrator@example.com support@example.com sales@example.com support@example.co.uk
请注意在bean 定义的merge=true属性的 Properties集合的值设置继承父所有属性元素 这一合并行为同样适用于 集合合并的限制 您不能合并不同的集合类型（例如 aMap和 a List）。如果您确实尝试这样做，Exception则会抛出适当的。merge必须在较低的继承子定义上指定该属性。merge在父集合定义上指定属性是多余的，不会导致所需的合并。 强类型集合 随着 Java 5 中泛型类型的引入，您可以使用强类型集合。也就是说，可以声明一个Collection类型，使其只能包含（例如）String元素。如果您使用 Spring 将强类型依赖注入Collection到 bean 中，则可以利用 Spring 的类型转换支持，以便在将强类型Collection 实例的元素添加到Collection. 以下 Java 类和 bean 定义显示了如何执行此操作： 当bean的accounts属性something准备注入时，关于强类型元素类型的泛型信息Map Null 和空字符串值 Spring 将属性等的空参数视为空参数Strings。以下基于 XML 的配置元数据片段将email属性设置为空 String值 ("")。 前面的示例等效于以下 Java 代码： 该元素处理null值。以下清单显示了一个示例： 上面的配置相当于下面的Java代码： 带有 p 命名空间的 XML 快捷方式 p-namespace 允许您使用bean元素的属性（而不是嵌套 元素）来描述协作 bean 的属性值，或两者兼而有之。 Spring 支持具有命名空间的可扩展配置格式，这些格式基于 XML 模式定义。beans本章讨论的配置格式是在 XML Schema 文档中定义的。但是，p 命名空间并未在 XSD 文件中定义，仅存在于 Spring 的核心中。 以下示例显示了两个解析为相同结果的 XML 片段（第一个使用标准 XML 格式，第二个使用 p 命名空间）： 该示例显示了email在 bean 定义中调用的 p 命名空间中的一个属性。这告诉 Spring 包含一个属性声明。如前所述，p 命名空间没有模式定义，因此您可以将属性的名称设置为属性名称。 下一个示例包括另外两个 bean 定义，它们都引用了另一个 bean： 此示例不仅包括使用 p 命名空间的属性值，而且还使用特殊格式来声明属性引用。第一个 bean 定义用于 p 命名空间不如标准 XML 格式灵活。例如，声明属性引用的格式与以 结尾的属性冲突Ref，而标准 XML 格式则不然。我们建议您谨慎选择您的方法并将其传达给您的团队成员，以避免同时使用所有三种方法生成 XML 文档。 带有 c 命名空间的 XML 快捷方式 与带有 p-namespace的XML Shortcut类似，Spring 3.1 中引入的 c-namespace 允许内联属性来配置构造函数参数而不是嵌套constructor-arg元素。 以下示例使用c:命名空间执行与 from Constructor-based Dependency Injection 相同的操作： 该c:命名空间使用相同的约定作为p:一个（尾部-ref的bean引用），供他们的名字设置构造函数的参数。同样，它需要在 XML 文件中声明，即使它没有在 XSD 模式中定义（它存在于 Spring 核心中）。 对于构造函数参数名称不可用的极少数情况（通常如果字节码是在没有调试信息的情况下编译的），您可以使用参数索引的回退，如下所示： 由于 XML 语法，索引表示法需要存在前导_，因为 XML 属性名称不能以数字开头（即使某些 IDE 允许）。相应的索引符号也可用于 实际上，构造函数解析 机制在匹配参数方面非常有效，因此除非您确实需要，否则我们建议在整个配置中使用名称表示法。 复合属性名称 您可以在设置 bean 属性时使用复合或嵌套的属性名称，只要路径中除最终属性名称之外的所有组件都不是null. 考虑以下 bean 定义： 所述something豆具有fred属性，该属性具有bob属性，其具有sammy 特性，并且最终sammy属性被设置为值123。为了使其工作，fred属性 ofsomething和bob属性fred不能null在 bean 被构造之后。否则，NullPointerException抛出 a。 如果一个 bean 是另一个 bean 的依赖项，这通常意味着一个 bean 被设置为另一个 bean 的属性。通常，您使用基于 XML 的配置元数据中的元素来完成此操作。但是，有时 bean 之间的依赖关系不那么直接。例如，当需要触发类中的静态初始化程序时，例如数据库驱动程序注册。depends-on在初始化使用此元素的 bean 之前，该属性可以显式地强制初始化一个或多个 bean。以下示例使用该depends-on属性来表达对单个 bean 的依赖： 要表达对多个 bean 的依赖，请提供 bean 名称列表作为depends-on属性值（逗号、空格和分号是有效的分隔符）： 该depends-on属性可以指定初始化时依赖项，并且仅在单例bean的情况下，还可以指定相应的销毁时依赖项。depends-on在给定的 bean 本身被销毁之前，首先销毁与给定 bean定义关系的依赖 bean 。这样，depends-on也可以控制关机顺序。 默认情况下，ApplicationContext实现会在初始化过程中急切地创建和配置所有单例bean。通常，这种预实例化是可取的，因为可以立即发现配置或周围环境中的错误，而不是在几小时甚至几天之后。当这种行为不可取时，您可以通过将 bean 定义标记为延迟初始化来防止单例 bean 的预实例化。一个延迟初始化的 bean 告诉 IoC 容器在它第一次被请求时创建一个 bean 实例，而不是在启动时。 在 XML 中，此行为由 元素lazy-init上的属性控制 当前面的配置被 使用时ApplicationContext，lazybean 在ApplicationContext启动时不会被预先实例化，而not.lazybean 会被预先实例化。 但是，当延迟初始化 bean 是未延迟初始化的单例 bean 的依赖项时，它ApplicationContext会在启动时创建延迟初始化 bean，因为它必须满足单例的依赖项。延迟初始化的 bean 被注入到其他地方没有延迟初始化的单例 bean 中。 您还可以通过使用元素default-lazy-init上的属性来控制容器级别的延迟初始化 Spring 容器可以自动装配协作 bean 之间的关系。您可以让 Spring 通过检查ApplicationContext. 自动装配具有以下优点： 自动装配可以显着减少指定属性或构造函数参数的需要。（本章其他地方讨论的其他机制，例如 bean 模板 ，在这方面也很有价值。） 自动装配可以随着对象的发展更新配置。例如，如果您需要向类添加依赖项，则无需修改配置即可自动满足该依赖项。因此，自动装配在开发过程中特别有用，当代码库变得更稳定时，不会否定切换到显式装配的选项。 使用基于 XML 的配置元数据时（请参阅依赖注入），您可以使用元素的autowire属性为 bean 定义指定自动装配模式 使用byType或constructor自动装配模式，您可以连接数组和类型化集合。在这种情况下，提供容器内与预期类型匹配的所有自动装配候选者以满足依赖关系。Map如果预期的键类型是 ，您可以自动装配强类型实例String。自动装配Map 实例的值由与预期类型匹配的所有 bean 实例组成，并且 Map实例的键包含相应的 bean 名称。 自动装配的局限性和缺点 自动装配在整个项目中一致使用时效果最佳。如果通常不使用自动装配，开发人员可能会使用它来连接一两个 bean 定义，这可能会让人感到困惑。 考虑自动装配的局限性和缺点： property和constructor-arg设置中的显式依赖项始终覆盖自动装配。您不能自动装配简单属性，例如基元 Strings、 和Classes（以及此类简单属性的数组）。此限制是有意设计的。 自动装配不如显式装配精确。虽然，如前面的表中所述，Spring 小心避免在可能产生意外结果的歧义的情况下进行猜测。不再明确记录 Spring 管理的对象之间的关系。 可能无法从 Spring 容器生成文档的工具中使用接线信息。 容器内的多个 bean 定义可能与要自动装配的 setter 方法或构造函数参数指定的类型相匹配。对于数组、集合或 Map实例，这不一定是问题。但是，对于期望单个值的依赖项，这种歧义不会被任意解决。如果没有唯一的 bean 定义可用，则抛出异常。 在后一种情况下，您有多种选择： 放弃自动装配以支持显式装配。 如下一节所述，通过将其autowire-candidate属性设置为 来避免对 bean 定义进行自动装配。false 通过将primary其 使用基于注解的配置实现更细粒度的控制，如基于注解的容器配置 中所述。 从自动装配中排除 Bean 在每个 bean 的基础上，您可以从自动装配中排除一个 bean。在 Spring 的 XML 格式中，将元素的autowire-candidate属性设置 该autowire-candidate属性旨在仅影响基于类型的自动装配。它不会影响按名称的显式引用，即使指定的 bean 未标记为自动装配候选者，也会解析。因此，如果名称匹配，按名称自动装配仍然会注入一个 bean。 您还可以根据对 bean 名称的模式匹配来限制自动装配候选者。顶级 这些技术对于您永远不想通过自动装配注入其他 bean 的 bean 很有用。这并不意味着不能使用自动装配来配置被排除的 bean 本身。相反，bean 本身不是自动装配其他 bean 的候选者。 在大多数应用场景中，容器中的大部分 bean 都是单例的。当单例 bean 需要与另一个单例 bean 协作或非单例 bean 需要与另一个非单例 bean 协作时，您通常通过将一个 bean 定义为另一个 bean 的属性来处理依赖关系。 当bean生命周期不同时就会出现问题。假设单例 bean A 需要使用非单例（原型）bean B，可能在 A 上的每次方法调用上。容器只创建单例 bean A 一次，因此只有一次设置属性的机会。容器无法在每次需要时为 bean A 提供 bean B 的新实例。 一个解决方案是放弃一些控制反转。您可以通过实现接口来使 bean A实现ApplicationContextAware接口，并通过在每次getBean(“B”) bean A 需要时调用容器来请求（通常是新的）bean B 实例。以下示例显示了这种方法： 前面是不可取的，因为业务代码知道并耦合到 Spring framework。方法注入是 Spring IoC 容器的一个有点高级的特性，可以让你干净地处理这个用例。 查找方法注入 查找方法注入是容器覆盖容器管理 bean 上的方法并返回容器中另一个命名 bean 的查找结果的能力。查找通常涉及原型 bean，如上一节中描述的场景。Spring framework 通过使用来自 CGLIB 库的字节码生成来动态生成覆盖该方法的子类来实现此方法注入。 要使这种动态子类化工作，Spring bean 容器子类化的类不能是final，要覆盖的方法也不能final是 。 对具有abstract方法的类进行单元测试需要您自己对类进行子类化并提供该abstract方法的存根实现。 组件扫描也需要具体的方法，这需要具体的类来获取。 另一个关键限制是查找方法不适用于工厂方法，尤其不适@Bean用于配置类中的方法，因为在这种情况下，容器不负责创建实例，因此无法在上创建运行时生成的子类苍蝇。 对于CommandManager前面代码片段中的类，Spring 容器动态覆盖了该createCommand() 方法的实现。该CommandManager班没有任何Spring的依赖，因为返工例所示： 在包含要注入的方法（CommandManager在本例中为 the）的客户端类中，要注入的方法需要以下形式的签名： 如果方法是abstract，则动态生成的子类实现该方法。否则，动态生成的子类会覆盖原始类中定义的具体方法。考虑以下示例： 标识为的 bean在需要bean的新实例时commandManager调用它自己的createCommand()方法myCommand。myCommand如果确实需要，您必须小心地将bean部署为原型。如果是单例，myCommand 则每次都返回相同的bean实例。 或者，在基于注解的组件模型中，您可以通过@Lookup注解声明一个查找方法，如下例所示： 或者，更惯用的是，您可以依靠目标 bean 根据查找方法的声明返回类型进行解析： 请注意，您通常应该使用具体的存根实现声明此类带注释的查找方法，以便它们与 Spring 的组件扫描规则兼容，其中默认情况下会忽略抽象类。此限制不适用于显式注册或显式导入的 bean 类。 访问不同范围的目标 bean 的另一种方法是ObjectFactory/ Provider注入点。参见Scoped Beans as Dependencies。 您可能还会发现ServiceLocatorFactoryBean（在 org.springframework.beans.factory.config包中）很有用。 任意方法替换 使用基于 XML 的配置元数据，您可以使用该replaced-method元素为已部署的 bean 将现有方法实现替换为另一个方法实现。考虑下面的类，它有一个computevalue我们想要覆盖的方法： 实现org.springframework.beans.factory.support.MethodReplacer 接口的类提供了新的方法定义，如以下示例所示： 用于部署原始类并指定方法覆盖的 bean 定义类似于以下示例： 您可以在元素内使用一个或多个元素 来指示被覆盖的方法的方法签名。仅当方法重载并且类中存在多个变体时，才需要参数的签名。为方便起见，参数的类型字符串可以是完全限定类型名称的子字符串。例如，以下所有匹配 java.lang.String： 因为参数的数量通常足以区分每个可能的选择，所以这个快捷方式可以节省大量输入，让您只输入与参数类型匹配的最短字符串。administrator=administrator@example.com
sales=sales@example.com
support=support@example.co.uk
，和
元素的特定情况下，与List集合类型（即ordered 值集合的概念）相关联的语义得到维护。父级的值在所有子级列表的值之前。在的情况下Map，Set和Properties集合类型，没有顺序存在。因此，没有排序的语义在背后的关联的集合类型的效果Map，Set以及Properties实现类型，容器内部使用。
public class SomeClass {
private Map
exampleBean.setEmail("");
exampleBean.setEmail(null);
1.4.5. 自动装配
模式 描述 no （默认）没有自动装配。Bean 引用必须由ref元素定义。对于较大的部署，不建议更改默认设置，因为明确指定协作者可以提供更好的控制和清晰度。在某种程度上，它记录了系统的结构。 byName 按属性名称自动装配。Spring 查找与需要自动装配的属性同名的 bean。例如，如果一个 bean 定义被设置为按名称自动装配并且它包含一个master属性（即它有一个 setMaster(…)方法），Spring 会查找一个名为的 bean 定义master并使用它来设置属性。 byType 如果容器中只存在一个属性类型的 bean，则让属性自动装配。如果存在多个，则会引发致命异常，这表明您不能byType为该 bean使用自动装配。如果没有匹配的 bean，则不会发生任何事情（未设置属性）。 constructor 类似于byType但适用于构造函数参数。如果容器中没有一个构造函数参数类型的 bean，则会引发致命错误。 // a class that uses a stateful Command-style class to perform some processing
package fiona.apple;
// Spring-API imports
import org.springframework.beans.BeansException;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
public class CommandManager implements ApplicationContextAware {
private ApplicationContext applicationContext;
public Object process(Map commandState) {
// grab a new instance of the appropriate Command
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
protected Command createCommand() {
// notice the Spring API dependency!
return this.applicationContext.getBean("command", Command.class);
}
public void setApplicationContext(
ApplicationContext applicationContext) throws BeansException {
this.applicationContext = applicationContext;
}
}
package fiona.apple;
// no more Spring imports!
public abstract class CommandManager {
public Object process(Object commandState) {
// grab a new instance of the appropriate Command interface
Command command = createCommand();
// set the state on the (hopefully brand new) Command instance
command.setState(commandState);
return command.execute();
}
// okay... but where is the implementation of this method?
protected abstract Command createCommand();
}
public abstract class CommandManager {
public Object process(Object commandState) {
Command command = createCommand();
command.setState(commandState);
return command.execute();
}
@Lookup("myCommand")
protected abstract Command createCommand();
}
public abstract class CommandManager {
public Object process(Object commandState) {
Command command = createCommand();
command.setState(commandState);
return command.execute();
}
@Lookup
protected abstract Command createCommand();
}
与查找方法注入相比，一种不太有用的方法注入形式是能够用另一种方法实现替换托管 bean 中的任意方法。您可以安全地跳过本节的其余部分，直到您真正需要此功能。public class MyValueCalculator {
public String computevalue(String input) {
// some real code...
}
// some other methods...
}
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 ...;
}
}
java.lang.String
String
Str
