This part of the reference documentation covers all the technologies that are absolutely integral to the Spring Framework.
翻译 ：参考文档的这一部分涵盖了Spring框架中必不可少的所有技术。
Foremost amongst these is the Spring Framework’s Inversion of Control (IoC) container. A thorough treatment of the Spring Framework’s IoC container is closely followed by comprehensive coverage of Spring’s Aspect-Oriented Programming (AOP) technologies. The Spring Framework has its own AOP framework, which is conceptually easy to understand and which successfully addresses the 80% sweet spot of AOP requirements in Java enterprise programming.
翻译：其中最重要的是Spring框架的控制反转(IoC)容器。彻底了解Spring框架的IoC容器之后，将对Spring的面向方面编程(AOP)技术进行全面的覆盖。Spring框架有自己的AOP框架，在概念上很容易理解，并且成功地解决了企业级编程中对Java AOP的 80%的需求。
Coverage of Spring’s integration with AspectJ (currently the richest — in terms of features — and certainly most mature AOP implementation in the Java enterprise space) is also provided.
翻译：本文还介绍了Spring与AspectJ的集成(目前在特性方面是最丰富的-当然还有Java企业空间中最成熟的AOP实现)。
第一章、IoC容器
This chapter covers Spring’s Inversion of Control (IoC) container.
翻译：本章介绍Spring的反转控制(IoC)容器。
1.1. Introduction to the Spring IoC Container and Beans
翻译：SpringIOC容器和Bean简介
This chapter covers the Spring Framework implementation of the Inversion of Control (IoC) principle. IoC is also known as dependency injection (DI). 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.
翻译：本章介绍了Spring框架实现控制反转（IoC）的原理。IoC也称为依赖注入(DI)。它是对象定义仅通过构造函数参数、工厂方法的参数、或对象构造实例化后或从工厂方法返回后设置的属性注入其依赖的过程。（即它们所使用的其他对象）。然后容器在创建bean时注入这些依赖关系。这个过程基本上是bean本身控制实例化或使用通过直接构造类或（如服务定位器模式）机制来定位其依赖项的逆向（因此叫做控制翻转）。
The org.springframework.beans and org.springframework.context packages are the basis for Spring Framework’s IoC container. The BeanFactory interface provides an advanced configuration mechanism capable of managing any type of object. ApplicationContext is a sub-interface of BeanFactory. It adds:
翻译：org.springframework.beans 和org.springframework.context包是Spring 框架IOC容器的基础。BeanFactory 接口提供了一种高级配置机制，能够管理任何类型的对象。ApplicationContext 是BeanFactory 的子接口。补充：
- Easier integration with Spring’s AOP features
翻译：更容易与Spring的AOP集成的特性
- Message resource handling (for use in internationalization)
翻译：消息资源处理(用于国际化)
- Event publication
翻译：事件发布
- Application-layer specific contexts such as the WebApplicationContext for use in web applications.
翻译：特定于应用层的上下文，如WebApplicationContext ，用于Web应用程序。
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. For more information on using the BeanFactory instead of the ApplicationContext, see The BeanFactory.
翻译：简而言之，BeanFactory 提供了配置框架和基本功能，ApplicationContext 添加了更多特定于企业的功能。ApplicationContext 是一个完整的BeanFactory 的扩展集，在本章中只用于描述Spring的IoC容器。有关使用BeanFactory 而不是ApplicationContext的更多信息，请参见BeanFactory。
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中，构成应用程序主干并由SpringIoC容器管理的对象称为bean。bean是实例化、组装和由SpringIoC容器管理其他操作的对象。否则bean只是应用程序中许多对象之一。bean及其之间的依赖关系反映在容器使用的配置元数据中。
1.1. Container Overview
翻译：容器概述
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 object.
翻译：org.springframework.context.ApplicationContext接口表示SpringIoC容器，负责实例化、配置和组装bean。容器通过读取配置元数据来实例化、配置和组装哪些对象的结构。配置元数据以XML、Java注释或Java代码表示。它让你将构成应用程序的对象和这些对象之间丰富的相互依赖关系传递出来。
Several implementations of the ApplicationContext interface are supplied with Spring. In stand- alone applications, it is common to create an instance of ClassPathXmlApplicationContext or FileSystemXmlApplicationContext. While XML has been the traditional format for defining configuration metadata, you can instruct the container to use Java annotations or code as the metadata format by providing a small amount of XML configuration to declaratively enable support for these additional metadata formats.
翻译：Spring提供了几个ApplicationContext接口的实现。在独立应用程序中，常见的做法是创建ClassPathXmlApplicationContext 或FileSystemXmlApplicationContext的实例。虽然XML一直是定义配置元数据的传统格式，但您可以指示容器使用Java注释或代码作为元数据格式，通过提供少量的xml配置，以声明方式启用对这些附加元数据的支持。
In most application scenarios, explicit user code is not required to instantiate one or more instances of a Spring IoC container. For example, in a web application scenario, a simple eight (or so) lines of boilerplate web descriptor XML in the web.xml file of the application typically suffices (see Convenient ApplicationContext Instantiation for Web Applications). If you use the Spring Tool Suite (an Eclipse-powered development environment), you can easily create this boilerplate configuration with a few mouse clicks or keystrokes.
翻译：在大多数应用程序场景中，不需要显式的使用代码来实例化SpringIoC容器的一个或多个实例。例如，在web应用程序场景中，在应用程序的web.xml文件中，一个简单的八行（或更多）样板web描述符xml通常就足够了（请参见方便的web应用程序的applicationContext实例化）。如果您使用Spring工具套件（一个Eclipse-powered开发环境），您可以通过几下鼠标单击或击键轻松创建此样板配置。
The following diagram shows a high-level view of how Spring works. Your application classes are combined with configuration metadata so that, after the ApplicationContext is created and initialized, you have a fully configured and executable system or application.
翻译：下图显示了Spring工作原理的高级视图。应用程序类与配置元数据相结合，以便在创建和初始化ApplicationContext 之后，您有一个完全配置和可执行的系统或应用程序。
| |
Figure 1. The Spring IoC container //springIOC容器
1.2.1. Configuration Metadata
翻译：配置元数据
As the preceding diagram shows, the Spring IoC container consumes a form of configuration metadata. This configuration metadata represents how you, as an application developer, tell the Spring container to instantiate, configure, and assemble the objects in your application.
翻译：如上面的图表所示，SpringIoC容器使用一种配置元数据形式。此配置元数据展示了作为应用程序开发人员你告诉Spring 容器如何在应用程序中实例化、配置和组装对象。
Configuration metadata is traditionally supplied in a simple and intuitive XML format, which is what most of this chapter uses to convey key concepts and features of the Spring IoC container.
翻译：传统上，配置元数据是以简单直观的XML格式提供的，这是本章的大部分内容用来传达SpringIoC容器的关键概念和特性
XML-based metadata is not the only allowed form of configuration metadata. The Spring IoC container itself is totally decoupled from the format in which this configuration metadata is actually written. These days, many developers choose Java-based configuration for their Spring applications.
翻译：基于XML的元数据不是唯一允许的配置元数据形式。SpringIOC容器本身与实际编写此配置元数据的格式完全分离。现在，许多开发人员为他们的Spring应用程序选择基于Java的配置。
For information about using other forms of metadata with the Spring container, see:
翻译：有关在Spring容器中使用其他形式的元数据的信息，请参阅
- Annotation-based configuration: Spring 2.5 introduced support for annotation-based configuration metadata.
翻译：基于注释的配置：Spring2.5引入了对基于注释的配置元数据的支持。
- Java-based configuration: Starting with Spring 3.0, many features provided by the Spring JavaConfig project became part of the core Spring Framework. Thus, you can define beans external to your application classes by using Java rather than XML files. To use these new features, see the @Configuration, @Bean, @Import, and @DependsOn annotations.
翻译：基于Java的配置：从Spring3.0开始，Spring JavaConfig项目提供的许多特性成为核心Spring框架的一部分。因此，您可以在应用类之外使用Java而不是XML文件定义bean。要使用这些新特性，请参阅 @Configuration, @Bean, @Import,和 @DependsOn 注释。
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 <bean/> elements inside a top-level <beans/> element. Java configuration typically uses @Bean-annotated methods within a @Configuration class.
翻译：Spring配置由至少一个并且通常由多个容器必须进行管理的bean定义组成。基于XML的配置元数据将这些bean配置为在顶层元素<beans/>内部的<bean/>元素。Java配置通常在带有@Configuration注释的类中使用带@Bean注释的方法。
These bean definitions correspond to the actual objects that make up your application. Typically, you define service layer objects, data access objects (DAOs), presentation objects such as Struts Action instances, infrastructure objects such as Hibernate SessionFactories, JMS Queues, and so forth. 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. However, you can use Spring’s integration with AspectJ to configure objects that have been created outside the control of an IoC container. See Using AspectJ to dependency-inject domain objects with Spring.
翻译：这些bean定义对应于构成应用程序的实际对象。通常定义服务层对象、数据访问对象(DAO)、表示对象(如Struts Action)实例、基础设施对象(如Hibernate SessionFacors、JMS队列等)。通常，人们不会在容器中配置细粒度的域对象，因为创建和加载域对象通常是DAO 和业务逻辑的责任。但是，您可以使用Spring与AspectJ的集成来配置在IoC容器控制之外创建的对象 。参见使用AspectJ与Spring一起注入域对象。
The following example shows the basic structure of XML-based configuration metadata:
翻译：下面的示例显示了基于XML的配置元数据的基本结构：
The value of the id attribute refers to collaborating objects. The XML for referring to collaborating objects is not shown in this example. See Dependencies for more information.
翻译：ID属性的值是指协作对象。在此示例中没有显示用于引用协作对象的XML。有关详细信息，请参见依赖关系。
1.2.1. Instantiating a Container
翻译：容器的实例化
The location path or paths supplied to an ApplicationContext constructor are resource strings that let the container load configuration metadata from a variety of external resources, such as the local file system, the Java CLASSPATH, and so on.
翻译：提供给ApplicationContext构造函数的绝对路径或相对路径是资源字符串，它让容器从各种外部资源（如本地系统文件）中加载配置元数据，以此类推
| |
After you learn about Spring’s IoC container, you may want to know more about Spring’s Resource abstraction (as described in Resources), which provides a
Z convenient mechanism for reading an InputStream from locations defined in a
URI syntax. In particular, Resource paths are used to construct applications
contexts, as described in Application Contexts and Resource Paths.
翻译：在了解了Spring的IoC容器之后，您可能想了解更多关于Spring抽象资源的知识。它提供了一个方便的利用URI语法定位读取InputStream 的机制。特别是，资源路径用于构造应用程序上下文，如Application Contexts and Resource Paths中所述。
The following example shows the service layer objects (services.xml) configuration file:
翻译：下面的示例显示服务层对象(services.xml)配置文件：
The following example shows the data access objects daos.xml file:
翻译：以下示例显示了数据访问对象daos.xml文件：
| |
In the preceding example, the service layer consists of the PetStoreServiceImpl class and two data access objects of the types JpaAccountDao and JpaItemDao (based on the JPA Object-Relational Mapping standard). The property name element refers to the name of the JavaBean property, and the ref element refers to the name of another bean definition. This linkage between id and ref elements expresses the dependency between collaborating objects. For details of configuring an object’s dependencies, see Dependencies.
翻译：在前面的示例中，服务层由PetStoreServiceImpl 类和JpaAccountDao 、JpaItemDao 两个数据访问对象类型的类组成(基于JPA对象-关系映射标准)。property name元素是指JavaBean属性的名称，ref 元素是指另一个bean定义的名称。id和ref元素之间的链接表示协作对象之间的依赖关系。有关配置对象依赖关系的详细信息，请参阅依赖项。
Composing XML-based Configuration Metadata
翻译：组合基于xml的配置元数据
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配置文件都表示体系结构中的逻辑层或模块。
You can use the application context constructor to load bean definitions from all these XML fragments. This constructor takes multiple Resource locations, as was shown in the previous section. Alternatively, use one or more occurrences of the <import/> element to load bean definitions from another file or files. The following example shows how to do so:
翻译：您可以使用应用程序上下文构造函数从所有这些XML片段加载bean定义。此构造函数采用多个资源位置，如上一节所示。使用一个或多个<import/>元素从另一个或多个文件加载bean定义。下面的示例演示如何做到这一点：
| |
In the preceding example, external bean definitions are loaded from three files: services.xml, messageSource.xml, and themeSource.xml. All location paths are relative to the definition file doing the importing, so services.xml must be in the same directory or classpath location as the file doing the importing, while messageSource.xml and themeSource.xml must be in a resources location below the location of the importing file. As you can see, a leading slash is ignored. However, given that these paths are relative, it is better form not to use the slash at all. The contents of the files being imported, including the top level <beans/> element, must be valid XML bean definitions, according to the Spring Schema.
翻译：在前面的示例中，外部bean定义是从三个文件加载的：services.xmll、messageSource.xml和themeSource.xml。所有位置路径都与执行导入的文件相关，因此services.xml必须位于与导入文件相同的目录或类路径位置，而 messageSource.xml和themeSource.xml 必须位于导入文件位置下方的资源位置。如您所见，前面的斜杠将被忽略。但是，考虑到这些路径是相对的，最好不要使用斜杠。导入的元素(包括顶层<beans/>元素)必须是依照Spring Schema 规则有效的XML bean定义。
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 adifferent, 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: URLs（例如classpath:../services.xml），不建议使用此引用，运行时解析过程将选择“最近”的classpath根目录，然后查看其父目录。类路径配置更改可能导致选择不同的，不正确的目录。
翻译：您可以始终使用完全限定的资源位置而不是相对路径：例如，file:C:/config/services.xml或classpath:/config/services.xml.。但是，请注意，您正在耦合。您的应用程序配置到特定的绝对位置。对于这样的绝对位置，通常最好保持间接性-例如，通过解析的“${…}”占位符。d在运行时针对JVM系统属性。
The namespace itself provices the import directive feature. Further configuration features beyond plain bean definitions are available in a selection of XML namespaces provided by Spring — for example, the context and util namespaces.
翻译：名称空间本身具有导入指令特性。在Spring提供的xml命名空间中，除了普通bean定义之外，还有更多的配置特性可用。
The Groovy Bean Definition DSL
翻译：GroovyBean定义DSL（Domain Specific Language 特定于域的语言）
As a further example for externalized configuration metadata, bean definitions can also be expressed in Spring’s Groovy Bean Definition DSL, as known from the Grails framework. Typically, such configuration live in a ".groovy" file with the structure shown in the following example:
翻译：作为外部化配置元数据的另一个示例，也可以在Spring的GroovyBean定义DSL中表示bean定义，正如Grails框架所知道的那样。通常情况下，这样的配置配置位于“.groovy”文件中，其结构如下面的示例所示：
| |
This configuration style is largely equivalent to XML bean definitions and even supports Spring’s XML configuration namespaces. It also allows for importing XML bean definition files through an importBeans directive.
翻译：这种配置风格在很大程度上等同于XMLbean定义，甚至支持Spring的XML配置命名空间。它还允许通过importBeans 指令导入xml bean定义文件。
1.2.2. Using the Container
翻译：容器的使用
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<T> requiredType), you can retrieve instances of your beans.
翻译：ApplicationContext 是高级工厂的接口，它能够维护不同bean及其依赖项的注册表。通过使用T getBean(String name, Class<T> requiredType)，您可以检索bean的实例。
The ApplicationContext lets you read bean definitions and access them, as the following example shows:
翻译：ApplicationContext 允许您读取bean定义并访问它们，如下例所示：
With Groovy configuration, bootstrapping looks very similar. It has a different context implementation class which is Groovy-aware (but also understands XML bean definitions). The following example shows Groovy configuration:
翻译：使用Groovy配置，引导看起来非常相似。它有一个不同的上下文实现类，它是Groovy感知的(但也理解XMLbean定义)。下面的示例是HowsGroovy配置：
 | |
The most flexible variant is GenericApplicationContext in combination with reader delegates — for example, with XmlBeanDefinitionReader for XML files, as the following example shows:
翻译：最灵活的变体是GenericApplicationContext 与读取器代理例如，使用XmlBeanDefinitionReader 用于xml文件的组合，如下示例所示：
| |
You can also use the GroovyBeanDefinitionReader for Groovy files, as the following example shows:
翻译：还可以使用GroovyBeanDefinitionReader 文件，如下示例所示：
| |
You can mix and match such reader delegates on the same ApplicationContext, reading bean definitions from diverse configuration sources.
翻译：您可以在相同的ApplicationContext中混合和匹配这些读取器代理，从不同的配置源中读取bean定义。
You can then use getBean to retrieve instances of your beans. The ApplicationContext interface has a few other methods for retrieving beans, but, ideally, your application code should never use them. Indeed, your application code should have no calls to the getBean() method at all and thus have no dependency on Spring APIs at all. For example, Spring’s integration with web frameworks provides dependency injection for various web framework components such as controllers and JSF-managed beans, letting you declare a dependency on a specific bean through metadata (such as an autowiring annotation).
翻译：然后可以使用getBean 检索bean的实例。ApplicationContext 接口还有一些其他方法来检索bean，但理想情况下，应用程序代码不应该使用它们。实际上，应用程序代码应该根本不调用getBean()方法，因此根本不依赖SpringAPI。例如，Spring与Web框架的集成提供了对各种Web框架组件（如控制器和JSF受管Bean）的依赖注入，让您声明依赖关系通过元数据（如自动布线注释）的特定Bean。
1.1. Bean Overview
翻译：bean 概述
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 <bean/> definitions).
翻译：SpringIoC容器管理一个或多个bean。这些bean是通过提供给容器的配置元数据创建的(例如，以XML <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的实际实现类。
- Bean behavioral configuration elements, which state how the bean should behave in the container (scope, lifecycle callbacks, and so forth).
翻译：bean行为配置元素，它们说明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中限制池的大小或使用的连接的数量。
This metadata translates to a set of properties that make up each bean definition. The following table describes these properties:
翻译：此元数据转换为组成每个bean定义的一组属性。下表描述了这些属性：
Table 1. The bean definition （bean定义）
| Property（属性） | Explained in…（解释为…） |
| Class | Instantiating Beans（实例化bean） |
| Name | Naming Beans （命名bean） |
| Scope | Bean Scopes （bean作用域） |
| Constructor arguments | Dependency Injection （依赖注入） |
| Properties | Dependency Injection （依赖注入） |
| Autowiring mode | Autowiring Collaborators （自动协作者） |
| Lazy initialization mode | Lazy-initialized Beans （懒加载bean） |
| Initialization method | Initialization Callbacks （初始化回调） |
| Destruction method | Destruction Callbacks （销毁回调） |
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.
翻译：除了包含有关如何创建特定Bean的信息的Bean定义之外，ApplicationContext 实现还允许注册在容器外面创建的现有对象（按用户）。这是通过ApplicationContext的 BeanFactory 通过getBeanFactory()方法来完成的，该方法返回BeanFactory DefaultListableBeanFactory 打开。DefaultListableBeanFactory 通过registerSingleton(..)和registerBeanDefinition(..) 方法支持此注册。然而，典型的应用程序只与通过常规bean定义元数据定义的bean一起工作。
翻译：除了包含有关如何创建特定Bean的信息的Bean定义之外，ApplicationContext 实现还允许注册在容器外面创建的现有对象（按用户）。这是通过ApplicationContext的 BeanFactory 通过getBeanFactory()方法来完成的，该方法返回BeanFactory DefaultListableBeanFactory 打开。DefaultListableBeanFactory 通过registerSingleton(..)和registerBeanDefinition(..) 方法支持此注册。然而，典型的应用程序只与通过常规bean定义元数据定义的bean一起工作。
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
Z 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容器中的状态不一致或两者都不一致。
1.3.1. Naming Beans
翻译：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. As a historical note, in versions prior to Spring 3.1, the id attribute was defined as an xsd:ID type, which constrained possible characters. As of 3.1, it is defined as an xsd:string type. Note that bean id uniqueness is still enforced by the container, though no longer by XML parsers.
翻译：在基于XML的配置元数据中，使用id 属性、name 属性或两者来指定Bean标识符。id 属性使您可以指定一个ID。传统上，这些name 是字母数字(“myBean”、“omeService”等)，但也可以包含特殊字符。如果您想为bean引入其他别名，也可以在name 属性中指定它们，使用逗号(，)、分号(；)或空格分隔。作为历史说明，在Spring3.1之前的版本中，id属性被定义为xsd：id类型，这限制了可能的字符从3.1开始，它被定义为xsd：string类型。注意，bean id唯一性仍然由容器强制执行，尽管不再由XML解析器强制执行。
You are not required to supply a name or an id for a bean. If you do not supply a name or id explicitly, the container generates a unique name for that bean. However, if you want to refer to that bean by name, through the use of the ref element or a Service Locator style lookup, you must provide a name. Motivations for not supplying a name are related to using inner beans and autowiring collaborators.
翻译：为bean提供名称或ID不是必须的。如果没有显式提供名称或id，容器将为该bean生成唯一的名称。但是，如果您想要引用Bean按名称，通过使用ref元素或服务定位器样式查找，必须提供名称。不提供名称的动机与使用inner beans和autowiring collaborators有关
| |
翻译：Bean命名约定
翻译：命名bean时使用标准Java约定。也就是说，Bean的名称以小写字母开头 使用驼峰命名法，例如： accountManager, accountService, userDao, loginController。诸如此类
翻译：命名bean始终是为了使您的配置更易于阅读和理解。此外，如果使用SpringAOP，命名的规范对它在使用一组与名称相关的Bean时帮助很大。
With component scanning in the classpath, Spring generates bean names for unnamed components, following the rules described earlier: essentially, taking the simple class name and turning its initial character to lower-case. However, in the
Z (unusual) special case when there is more than one character and both the first
and second characters are upper case, the original casing gets preserved. These are
the same rules as defined by java.beans.Introspector.decapitalize (which Spring uses here).
翻译：通过在类路径中扫描组件，Spring为未命名的组件生成bean名称，遵循前面描述的规则：本质上，取简单的类名并将其初始字符改为小写。但是，在（不寻常的）特殊情况下，当有多个字符并且第一个和第二个字符都是大写时，原始的大小写将被保留。这些规则与java.beans.Introspector.decapitalize（Spring在这里使用）定义的规则相同。
Aliasing a Bean outside the Bean Definition
翻译：在bean定义之外对bean进行定义别名
In a bean definition itself, you can supply more than one name for the bean, by using a combination of up to one name specified by the id attribute and any number of other names in the name attribute. These names can be equivalent aliases to the same bean and are useful for some situations, such as letting each component in an application refer to a common dependency by using a bean name that is specific to that component itself.
翻译：在bean定义本身中，可以为bean提供多个名称，方法是使用id属性指定的最多一个名称和name属性中任意数量的其他名称的组合。..这些名称可以是相同bean的等效别名，并且在某些情况下非常有用，例如让应用程序中的每个组件通过使用bean名称引用公共依赖项。特定于该组件本身。
Specifying all aliases where the bean is actually defined is not always adequate, however. It is sometimes desirable to introduce an alias for a bean that is defined elsewhere. This is commonly the case in large systems where configuration is split amongst each subsystem, with each subsystem having its own set of object definitions. In XML-based configuration metadata, you can use the <alias/> element to accomplish this. The following example shows how to do so:
翻译：然而，指定bean实际定义的所有别名并不总是足够的。有时需要为在其他地方定义的bean引入别名。这通常是在大型系统中的情况，其中在每个子系统之间划分配置，每个子系统具有自己的一组对象定义。在基于XML的配置元数据中，可以使用<alias/>属性来完成这个任务。下面的示例演示如何做到这一点：
| |
In this case, a bean (in the same container) named fromName may also, after the use of this alias definition, be referred to as toName.
翻译：在这种情况下，在使用这个别名定义之后，名为From Name的bean(在同一个容器中)也可以称为toName。
For example, the configuration metadata for subsystem A may refer to a DataSource by the name of subsystemA-dataSource. The configuration metadata for subsystem B may refer to a DataSource by the name of subsystemB-dataSource. When composing the main application that uses both these subsystems, the main application refers to the DataSource by the name of myApp-dataSource. To have all three names refer to the same object, you can add the following alias definitions to the configuration metadata:
翻译：例如，子系统A的配置元数据可通过名称subsystemA-dataSource来引用数据源。子系统A的配置元数据可通过名称subsystemB-dataSource来引用数据源。在组合使用这两个子系统的主应用程序时，主应用程序以 myApp-dataSource的名称引用DataSource。三个名字引用同一个对象，可以将以下别名定义添加到配置元数据中：
| |
Now each component and the main application can refer to the dataSource through a name that is unique and guaranteed not to clash with any other definition (effectively creating a namespace), yet they refer to the same bean.
翻译：现在，每个组件和主应用程序都可以通过唯一的名称引用DataSource，并且保证不会与任何其他定义发生冲突(有效地创建名称空间)。然而，它们指的是同一个bean。
2289
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
