每個bean都有一個或多個標識符,這些標識符在容器內必須是唯一的。一個bean一般只有一個標識符,如果需要多個的話,額外的可以認為是別名。
基于xml的配置元數據,使用id,name都可以來標識bean。屬性id是一個精確的標識。一般,名稱使用字母數字,特殊字符也可以。如果你想要引進bean的別名,可以使用name屬性,使用逗號,分號或空格隔離。在spring3.1版本之前,id被定義為xsd:ID類型,限制了可能的字符。從3.1開始,被定義為xsd:string類型。bean的id唯一性由容器保證,不在由xml解析器執行。
bean的id和name不是必需的。如果不顯示提供,容器為指定一個唯一的name。然而,如果你想用ref元素或服務定位模式通過name來引用bean,那么必須提供一個name。不提供name的場景適合內部類和自動裝配。
>:-: **bean命名規則**
>
>bean的命名規則使用java實例的屬性命名規則。即小寫字母開頭,駝峰式。例如(不帶引號):'accountManager', 'accountService', 'userDao', 'loginController'。
>
>按規則命名,會使你的配置可讀性更高和便于理解,如果你使用spring aop,bean按規則命名會有很大幫助。
>
>通過類路徑的組件掃描,spring按照以上規則,對未命名的組件生成名稱:本質上就是把簡單類名首字母改成小寫。然而,特殊場景下當類名有多個字母且強兩個都是大寫的時候,則保留原名。這和spring在用的規則`java.beans.Introspector.decapitalize`一樣
>
## Aliasing a bean outside the bean definition
標識一個bean,可以使用屬性id和name,id只能有一個值,name可以有多個值。這些name的值就是bean的別名,別名在某些場景下很有用,如每個模塊可以使用特定的name值來標識引用的公共依賴。
然而,在定義bean的時候把所有的別名都指定是不夠的。有時候需要在別處為bean定義別名。在大型系統中通常是這樣的,配置信息分布在各個子系統中,每個子系統有自己的對象定義。在xml配置元數據中,可以使用`<alias/>`來完成這個操作。
~~~xml
<alias name="fromName" alias="toName"/>
~~~
在上面這個示例中,容器中name為fromName的bean,在使用別名定義之后,toName也引用了此bean。
例如,子系統A通過name為`subsystemA-dataSource`引用數據源。子系統B通過name為`subsystemB-dataSource`引用同樣的數據源。主系統包含這兩個子系統,同時通過`myApp-dataSource`引用同樣的數據源。總共有3個name引用了同樣的數據源對象,要在主系統中添加如下配置
~~~xml
<alias name="subsystemA-dataSource" alias="subsystemB-dataSource"/>
<alias name="subsystemA-dataSource" alias="myApp-dataSource" />
~~~
現在,每個組件和主應用都能使用一個唯一的name來指定同一個DataSource,并保證和其他定義不沖突(有效的創建命名空間)。
> :-: java-configuration
>
> 如果使用java語言配置,可以使用@Bean注解提供別名。參考[@bean](https://docs.spring.io/spring/docs/5.0.6.RELEASE/spring-framework-reference/core.html#beans-java-bean-annotation)
- 正確打開本書的姿勢
- 第一部分 Core
- 1. Ioc container
- 1.1. Introduction to the Spring IoC container and beans
- 1.2. Container overview
- 1.2.1. Configuration metadata
- 1.2.2. Instantiating a container
- 1.2.3. Using the container
- 1.3. Bean overview
- 1.3.1. Naming beans
- 1.3.2. Instantiating beans
- 1.4. Dependencies
- 1.4.1. Dependency Injection
- 1.4.2. Dependencies and configuration in detail
- 1.4.3. Using depends-on
- 1.4.4. Lazy-initialized beans
- 1.4.5. Autowiring collaborators
- 1.4.6. Method injection
- 1.5 Bean Scopes
- 1.6. Customizing the nature of a bean TODO
- 1.7. Bean definition inheritance TODO
- 1.8. Container Extension Points TODO
- 1.9. Annotation-based container configuration
- 1.9.1. @Required
- 1.9.2. @Autowired
- 1.9.3. Fine-tuning annotation-based autowiring with @Primary
- 1.9.4. Fine-tuning annotation-based autowiring with qualifiers TODO
- 1.9.5. Using generics as autowiring qualifiers TODO
- 1.9.6. CustomAutowireConfigurer TODO
- 1.10. Classpath scanning and managed components
- 1.10.1. @Component and further stereotype annotations
- 1.11. Using JSR 330 Standard Annotations TODO
- 1.12. Java-based container configuration
- 1.12.1. Basic concepts: @Bean and @Configuration
- 1.12.2. Instantiating the Spring container using AnnotationConfigApplicationContext
- 2. Resources
- 2.1. Introduction
- 2.2. The Resource interface
- 2.3. Built-in Resource implementations
- 2.3.1. UrlResource
- 2.3.2. ClassPathResource
- 2.3.3. FileSystemResource
- 2.3.4. ServletContextResource
- 2.3.5. InputStreamResource
- 2.3.6. ByteArrayResource
- 2.4. The ResourceLoader
- 2.5. The ResourceLoaderAware interface
- 2.6. Resources as dependencies
- 2.7. Application contexts and Resource paths
- 2.7.1. Constructing application contexts
- 2.7.2. Wildcards in application context constructor resource paths
- 2.7.3. FileSystemResource caveats
- 3. Validation, Data Binding, and Type Conversion
- 4. Spring Expression Language (SpEL)
- 5. Aspect Oriented Programming with Spring
- 5.1. Introduction
- 5.1.1. AOP concepts
- 5.1.2. Spring AOP capabilities and goals
- 5.1.3. AOP Proxies
- 5.2. @AspectJ support
- 5.2.1. Enabling @AspectJ Support
- 5.2.2. Declaring an aspect
- 5.2.3. Declaring a pointcut
- 5.2.4. Declaring advice
- 5.2.5. Introductions TODO
- 5.2.6. Aspect instantiation models TODO
- 5.2.7. Example
- 5.3. Schema-based AOP support TODO
- 5.4. Choosing which AOP declaration style to use TODO
- 5.5. Mixing aspect types TODO
- 5.6. Proxying mechanisms
- 5.6.1. Understanding AOP proxies
- 5.7. Programmatic creation of @AspectJ Proxies
- 5.8. Using AspectJ with Spring applications
- 5.8.1. Using AspectJ to dependency inject domain objects with Spring
- 5.8.2. Other Spring aspects for AspectJ
- 第二部分 Testing
- 第三部分 Data Access
- 1. Transaction Management
- 1.1. Introduction to Spring Framework transaction management
- 1.2 Advantages of the Spring Framework’s transaction support model
- 1.2.1. Global transactions
- 1.2.2. Local transactions
- 1.2.3. Spring Framework’s consistent programming model
- 1.3. Understanding the Spring Framework transaction abstraction
- 1.4. Synchronizing resources with transactions
- 1.4.1. High-level synchronization approach
- 1.4.2. Low-level synchronization approach
- 1.4.3. TransactionAwareDataSourceProxy
- 1.5. Declarative transaction management
- 1.5.1. Understanding the Spring Framework’s declarative transaction implementation
- 1.5.2. Example of declarative transaction implementation
- 1.5.3. Rolling back a declarative transaction
- 1.5.4. Configuring different transactional semantics for different beans
- 1.5.5. tx:advice元素的 settings
- 1.5.6. Using @Transactional
- 1.5.7. Transaction propagation
- 1.5.8. Advising transactional operations
- 1.5.9. Using @Transactional with AspectJ TODO
- 第四部分 web servlet
- 第五部分 Web Reactive
- 第六部分 Integration
- 第七部分 Languages