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。