We are not unfamiliar with how beans are configured. After all, it has been involved in the previous article, although it is relatively superficial. But it also introduces how to write an XML configuration file to tell the Spring container how to create beans, how to inject dependencies, and so on. The key points are as follows:
1. < Bean > element is used to configure Bean; It has two important XML attributes, id and class: id is used to specify the unique identifier of the Bean; Class is used to specify the type of Bean, and its value is the fully qualified class name.
2. < property > element is used to configure dependency injection through attributes; It has three important XML attributes: name, value and ref: name is used to specify the attribute name of the Bean; Value is used to specify the literal value of the injection; ref is used to specify the injected Bean reference.
So if com Dream package has some existing classes:
1 public class Music { 2 private String musicName = null; 3 4 public String getMusicName() { 5 return this.musicName; 6 } 7 8 public void setMusicName(String musicName) { 9 this.musicName = musicName; 10 } 11 }
1 public class Player { 2 private Music playingMusic = null; 3 4 public Music getPlayingMusic() { 5 return this.playingMusic; 6 } 7 8 public void setPlayingMusic(Music playingMusic) { 9 this.playingMusic = playingMusic; 10 } 11 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music" class="com.dream.Music"> 3 <property name="musicName" value="Persistent"/> 4 </bean> 5 <bean id="player" class="com.dream.Player"> 6 <property name="playingMusic" ref="music"/> 7 </bean> 8 </beans>
This configuration can tell the Spring container to create music and player beans and inject the dependencies required by the beans through attributes. That is, through the < property > element, inject "persistence" into the musicName attribute of music and the playingMusic attribute of player. These configurations are familiar to everyone, so there is no need to describe them. But what we don't know is that we can also use p-namespace instead of < property > element to describe dependency injection. For this, the XML configuration file needs to be modified as follows:
1 <beans xmlns:p="http://www.springframework.org/schema/p" 2 /* Omit namespace and XSD Schema file declaration */> 3 <bean id="music" class="com.dream.Music" p:musicName="Persistent"/> 4 <bean id="player" class="com.dream.Player" p:playingMusic-ref="music"/> 5 </beans>
The new configuration introduces the p-namespace xmlns: P=“ http://www.springframework.org/schema/p "After that, two changes were made:
1. Use p:musicName = "persistence" instead of < property > element to inject the literal value of "persistence".
2. Use p: playingmusic ref = "music" instead of the < property > element to inject the Bean reference.
What's going on?
Originally, the p-namespace can replace the < property > element and describe dependency injection through attributes in a concise and compact way of XML attributes. Therefore, literal value injection can be described by p-namespace: the attribute name of p:Bean = "literal value". That is, start with P:, then take the attribute name of the bean, the equal sign and the literal value; Bean reference injection can be described with p-namespace: P: attribute name of bean - ref = "ID of bean to be injected". That is, start with P:, then add the attribute name of the bean, the suffix - ref, the equal sign, and the ID of the bean to be injected.
Therefore, the modified configuration uses the p-namespace "p:musicName =" persistence "instead of < property name =" musicname "value =" persistence "/ > to describe the injection of the literal value of" persistence "; Replace < property name = "playingmusic" ref = "music" / > with p-namespace ， P: playingmusic ref = "music" / > to describe the injection of this Bean reference.
So we know that the p-namespace can replace the injection of dependency description of < property > elements in a concise and compact way. As for which of the p-namespace and < property > elements is better, there is no final conclusion, which depends on personal preference. However, once selected, it is best to maintain the unity of the whole project; Don't use the < property > element here, use the p-namespace there.
Constructor Inject
Many times, we want to complete the creation and assembly of beans through constructors in one step. In order to meet this demand, Spring provides some support, so that we can provide some information to the XML configuration file and tell the Spring container to call other constructors with some parameters instead of the default constructor when creating beans; Thus, it can inject the dependencies required by the Bean through the constructor while creating the Bean, and complete the creation and assembly of the Bean.
So if com Dream package has some existing classes:
1 public class Music { 2 private String musicName = null; 3 4 public Music(String musicName) { 5 this.musicName = musicName; 6 } 7 }
1 public class Player { 2 private Music playingMusic = null; 3 4 public Player(Music playingMusic) { 5 this.playingMusic = playingMusic; 6 } 7 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music" class="com.dream.Music"> 3 <constructor-arg type="java.lang.String" value="Persistent"/> 4 </bean> 5 <bean id="player" class="com.dream.Player"> 6 <constructor-arg type="com.dream.Music" ref="music"/> 7 </bean> 8 </beans>
You can see that constructor injection is configured with < constructor Arg > elements; It has three important XML attributes: type, value and ref. Type is used to specify the parameter type of the constructor, and its value is the fully qualified class name; Value is used to specify the literal value of the injection; ref is used to specify the injected Bean reference. Before calling the constructor of the class to create a Bean, the Spring container will first check the XML configuration information to see how many parameters the constructor to be called has, what type each parameter is and what value it has; After that, the Spring container calls the qualified constructor according to the information provided by the configuration file to complete the creation and assembly of the Bean.
After the Spring Bean constructor is created, it needs to read the information of the String configuration of the Spring Bean constructor. Therefore, the Spring container passes the String "persistence" to the qualified constructor according to the information provided by the configuration file, and completes the creation and assembly of the Bean after calling; It is found that the constructor to be called for the creation of player Bean has a parameter of music type. Therefore, the Spring container passes the music Bean to the qualified constructor according to the information provided by the configuration file, and completes the creation and assembly of the Bean after calling.
At this point, you may be confused: "if the configured constructor has multiple parameters of the same type, how can the Spring container know which value to pass to which parameter when calling the constructor to complete the creation and assembly of beans?"
For this problem, we can introduce the index attribute of < constructor Arg > element to solve it. The index attribute can specify the parameter index of the constructor, indicating the number of parameters of the constructor configured. The value of the first parameter is 0, the value of the second parameter is 1, the value of the third parameter is 2, and so on. When the Spring container creates a Bean, it will pass the corresponding parameter values to the constructor in the order of parameter index to create the Bean. Naturally, the problem that dependency cannot be injected correctly because there are more than one parameter of the same type is solved.
In addition, in addition to the parameter index, we can also use the name attribute of the < constructor Arg > element to solve this problem. The name attribute is used to specify the parameter name of the constructor, indicating that the parameter value should be passed to the parameter with a certain value. The parameter names of constructors must be different, so this problem can be solved. There is only a limitation on the use of the name attribute. We need to open the debug flag to compile the code. Otherwise, the Spring container cannot know the parameter name of the constructor, and the constructor cannot be called by passing the parameter value through the parameter name.
Also, just as p-namespace can replace < property > elements, Spring also provides c-namespace to replace < constructor Arg > elements. In this case, you can modify the XML configuration file as follows:
1 <beans xmlns:c="http://www.springframework.org/schema/c" 2 /* Omit namespace and XSD Schema file declaration */> 3 <bean id="music" class="com.dream.Music" c:musicName="Persistent"/> 4 <bean id="player" class="com.dream.Player" c:playingMusic-ref="music"/> 5 </beans>
The new configuration introduces the c-namespace xmlns: C=“ http://www.springframework.org/schema/c "After that, two changes were made:
1. Use c:musicName = "persistence" instead of < constructor Arg > element to inject the literal value of "persistence".
2. Use C: playingmusic ref = "music" instead of the < constructor Arg > element to inject the Bean reference.
What's going on?
Originally, c-namespace can replace < constructor Arg > element and describe dependency injection through constructor in a concise and compact way of XML attribute. Therefore, literal value injection can be described in c-namespace: the parameter name of C: constructor = "literal value". That is, start with C:, then take the parameter name of the constructor, the equal sign and the literal value; Bean reference injection can be described in c-namespace: C: parameter name of constructor - ref = "ID of bean to be injected". That is, start with C:, then take the parameter name of the constructor, the suffix - ref, the equal sign, and the ID of the bean to be injected.
Therefore, the modified configuration uses c-namespace c:musicName = "persistence" instead of < constructor Arg type = "Java. Lang. string" value = "persistence" / > to describe the injection of the literal value of "persistence"; Use the c-namespace C: playingmusic ref = "music" instead of < constructor Arg type = "com. Dream. Music" ref = "music" / > to describe the injection of this Bean reference.
After reading this, you may have noticed: "the c-namespace uses the parameter name, and the Spring container needs the debugging flag to obtain the parameter name. If the debugging flag is not enabled when compiling the code, isn't there a problem with this configuration?"
Yes, indeed. Therefore, the c-namespace also supports parameter indexes. As follows:
1 <beans xmlns:c="http://www.springframework.org/schema/c" 2 /* Omit namespace and XSD Schema file declaration */> 3 <bean id="music" class="com.dream.Music" c:_0="Persistent"/> 4 <bean id="player" class="com.dream.Player" c:_0-ref="music"/> 5 </beans>
After the parameter index is introduced, the original {c:musicName = "persistent" becomes} c:_0 = "persistent", the original "C: playingmusic ref =" music "becomes" c:_0-ref="music" . That is, the original parameter name becomes underscore + index. The underscore in front of the index is required because XML does not allow attribute names to start with numbers. After the parameter index is introduced, when the Spring container creates a Bean, it will pass the corresponding parameter values to the constructor in the order specified by the parameter index, and complete the creation and assembly of the Bean after calling.
So we know that the Spring container can inject dependencies both through attributes and constructors. As for whether to use attribute injection or construct function injection, it is a matter of personal preference. Generally speaking, constructor injection is usually used for strong dependency (that is, the dependency that the program can run normally only after the injection is completed), and attribute injection is usually used for optional dependency (that is, the dependency that the program can run normally regardless of whether the injection is completed or not).
Static factory method injection
There are always times when our class has some static methods specially used to create objects, commonly known as static factory methods. If we want to create a Bean through the static factory method, we just need to provide some information to the configuration file and tell the Spring container to call the static factory method to complete the creation and assembly of the Bean.
So if com Dream package has some existing classes:
1 public class Music { 2 private String musicName = null; 3 4 public Music(String musicName) { 5 this.musicName = musicName; 6 } 7 8 public static Music staticFactory(String musicName) { 9 return new Music(musicName); 10 } 11 }
1 public class Player { 2 private Music playingMusic = null; 3 4 public Player(Music playingMusic) { 5 this.playingMusic = playingMusic; 6 } 7 8 public static Player staticFactory(Music playingMusic) { 9 return new Player(playingMusic); 10 } 11 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music" class="com.dream.Music" factory-method="staticFactory"> 3 <constructor-arg type="java.lang.String" value="Persistent"/> 4 </bean> 5 <bean id="player" class="com.dream.Player" factory-method="staticFactory"> 6 <constructor-arg type="com.dream.Music" ref="music"/> 7 </bean> 8 </beans>
You can see that a factory method attribute is added to the < Bean > element to specify the static factory method of the class; The class to which the static factory method belongs is specified by the class attribute, and the required parameters are specified by the < constructor Arg > element. Of course, if the Bean created by the static factory method has properties, dependency injection can also be specified through the < property > element.
Therefore, this configuration is used to tell the Spring container that the music Bean needs to call com dream. The staticFactory method of music class is created, and the literal value of "persistence" needs to be injected when calling; The player Bean needs to call com dream. The staticFactory method of the player class is created, and the Bean reference music needs to be injected when calling.
Instance factory method injection
In addition to static factory methods, factory methods also have instance factory methods. If we want to create a Bean through the instance factory method, we just need to provide some information to the configuration file and tell the Spring container to call the instance factory method of a Bean to complete the creation and assembly of the Bean.
So if com Dream package has some existing classes:
1 public class Music { 2 private String musicName = null; 3 4 public Music() { 5 } 6 7 public Music(String musicName) { 8 this.musicName = musicName; 9 } 10 11 public Music instanceFactory(String musicName) { 12 return new Music(musicName); 13 } 14 }
1 public class Player { 2 private Music playingMusic = null; 3 4 public Player() { 5 } 6 7 public Player(Music playingMusic) { 8 this.playingMusic = playingMusic; 9 } 10 11 public Player instanceFactory(Music playingMusic) { 12 return new Player(playingMusic); 13 } 14 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music_1" class="com.dream.Music"/> 3 <bean id="music_2" factory-bean="music_1" factory-method="instanceFactory"> 4 <constructor-arg type="java.lang.String" value="Persistent"/> 5 </bean> 6 7 <bean id="player_1" class="com.dream.Player"/> 8 <bean id="player_2" factory-bean="player_1" factory-method="instanceFactory"> 9 <constructor-arg type="com.dream.Music" ref="music_2"/> 10 </bean> 11 </beans>
Four beans are configured here: music_1，music_2，player_1，player_2. Among them, music_2，player_2 is created through the instance factory method.
When configuring the instance factory method, the factory method attribute is required to specify the instance factory method, the factory Bean attribute specifies the Bean to which the instance factory method belongs, and the < constructor Arg > element specifies the parameters required by the instance factory method. Of course, if the Bean created by the instance factory method has properties, dependency injection can also be specified through the < property > element.
Therefore, this configuration is used to tell the Spring container: music_2 this Bean needs to call music_1. The instanceFactory instance factory method of this Bean is created, and the literal value of "persistence" needs to be injected when calling; player_2 this Bean needs to call player_1. The instanceFactory instance factory method of this Bean is created, and music needs to be injected when calling_ 2 this Bean reference.
NULL value injection
The injection of NULL values can be described by < NULL > elements as follows:
1 <bean id="player_1" class="com.dream.Player"> 2 <constructor-arg type="com.dream.Music"> 3 <null /> 4 </constructor-arg> 5 </bean>
1 <bean id="player_2" class="com.dream.Player"> 2 <property name="playingMusic"> 3 <null /> 4 </property> 5 </bean>
Set injection
Java provides many types of collections, such as List, Set, Map, and so on. Naturally, Spring provides some support for configuring the injection of collections.
So if com Dream package has some existing classes:
1 public class Music { 2 private List<String> musicNameList = null; 3 4 public List<String> getMusicNameList() { 5 return this.musicNameList; 6 } 7 8 public void setMusicNameList(List<String> musicNameList) { 9 this.musicNameList = musicNameList; 10 } 11 }
1 public class Player { 2 private List<Music> playingMusicList = null; 3 4 public List<Music> getPlayingMusicList() { 5 return this.playingMusicList; 6 } 7 8 public void setPlayingMusicList(List<Music> playingMusicList) { 9 this.playingMusicList = playingMusicList; 10 } 11 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music_1" class="com.dream.Music"/> 3 <bean id="music_2" class="com.dream.Music"> 4 <property name="musicNameList"> 5 <list> 6 <value>Persistent</value> 7 <value>Have you all your life</value> 8 </list> 9 </property> 10 </bean> 11 <bean id="player" class="com.dream.Player"> 12 <property name="playingMusicList"> 13 <list> 14 <ref bean="music_1"/> 15 <ref bean="music_2"/> 16 </list> 17 </property> 18 </bean> 19 </beans>
You can see that the collection of List type can be configured with < List > elements. There is a < value > element at the bottom, which is used to configure the literal value set; There is a < ref > element used to configure the Bean reference collection. You can see these at a glance. There is no need to elaborate. The point is, does Spring also provide alternatives such as p-namespace and c-namespace to simplify the configuration of collections?
Of course. You should know that p-namespace and c-namespace do not support collections. Therefore, Spring in Spring util XML elements are defined in the XSD schema file to describe creation information such as collections. This requires the introduction of Spring util The XSD schema file is modified as follows:
1 <beans /* Omit namespace and XSD schema file declarations */ 2 xmlns:util="http://www.springframework.org/schema/util" 3 xsi:schemaLocation=" 4 /* Omit namespace and XSD schema file declarations */ 5 http://www.springframework.org/schema/util 6 http://www.springframework.org/schema/util/spring-util.xsd"> 7 8 <bean id="music_1" class="com.dream.Music" /> 9 <bean id="music_2" class="com.dream.Music"> 10 <property name="musicNameList" ref="utilMusicNameList"/> 11 </bean> 12 <bean id="player" class="com.dream.Player"> 13 <property name="playingMusicList" ref="utilPlayingMusicList" /> 14 </bean> 15 16 <util:list id="utilMusicNameList"> 17 <value>Persistent</value> 18 <value>Have you all your life</value> 19 </util:list> 20 <util:list id="utilPlayingMusicList"> 21 <ref bean="music_1" /> 22 <ref bean="music_2" /> 23 </util:list> 24 25 </beans>
You can see spring util The XSD schema file defines the < util: List > element, which is used to configure how to create a List type collection. There is a < value > element at the bottom, which is used to configure the literal value set; There is a < ref > element used to configure the Bean reference collection. Therefore, this configuration creates two sets of List type: the id of one set is utilMusicNameList; The id of a collection is utilPlayingMusicList. After that, inject the set utilMusicNameList into music_2. Inject the set utilPlayingMusicList into the playingMusicList attribute of player to complete the injection of the set.
If com Dream package has some existing classes:
1 public class Music { 2 private Set<String> musicNameSet = null; 3 4 public Set<String> getMusicNameSet() { 5 return this.musicNameSet; 6 } 7 8 public void setMusicNameSet(Set<String> musicNameSet) { 9 this.musicNameSet = musicNameSet; 10 } 11 }
1 public class Player { 2 private Set<Music> playingMusicSet = null; 3 4 public Set<Music> getPlayingMusicSet() { 5 return this.playingMusicSet; 6 } 7 8 public void setPlayingMusicSet(Set<Music> playingMusicSet) { 9 this.playingMusicSet = playingMusicSet; 10 } 11 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music_1" class="com.dream.Music" /> 3 <bean id="music_2" class="com.dream.Music"> 4 <property name="musicNameSet"> 5 <set> 6 <value>Persistent</value> 7 <value>Have you all your life</value> 8 </set> 9 </property> 10 </bean> 11 <bean id="player" class="com.dream.Player"> 12 <property name="playingMusicSet"> 13 <set> 14 <ref bean="music_1" /> 15 <ref bean="music_2" /> 16 </set> 17 </property> 18 </bean> 19 </beans>
You can see that sets of type Set can be configured with < Set > elements. There is a < value > element at the bottom, which is used to configure the literal value Set; There is a < ref > element used to configure the Bean reference collection. You can see these at a glance. There is no need to elaborate. The point is that collections of type Set can also be configured using the util element. As follows:
1 <beans /* Omit namespace and XSD schema file declarations */ 2 xmlns:util="http://www.springframework.org/schema/util" 3 xsi:schemaLocation=" 4 /* Omit namespace and XSD schema file declarations */ 5 http://www.springframework.org/schema/util 6 http://www.springframework.org/schema/util/spring-util.xsd"> 7 8 <bean id="music_1" class="com.dream.Music" /> 9 <bean id="music_2" class="com.dream.Music"> 10 <property name="musicNameSet" ref="utilMusicNameSet"/> 11 </bean> 12 <bean id="player" class="com.dream.Player"> 13 <property name="playingMusicSet" ref="utilPlayingMusicSet" /> 14 </bean> 15 16 <util:set id="utilMusicNameSet"> 17 <value>Persistent</value> 18 <value>Have you all your life</value> 19 </util:set> 20 <util:set id="utilPlayingMusicSet"> 21 <ref bean="music_1" /> 22 <ref bean="music_2" /> 23 </util:set> 24 25 </beans>
You can see spring util The XSD schema file defines the < util: Set > element, which is used to configure how to create sets of type Set. There is a < value > element at the bottom, which is used to configure the literal value Set; There is a < ref > element used to configure the Bean reference collection. Therefore, this configuration creates two sets of type Set: the id of one Set is utilMusicNameSet; The id of a collection is utilPlayingMusicSet. After that, inject the Set utilMusicNameSet into music_2. Inject the Set utilPlayingMusicSet into the playingMusicSet property of player to complete the injection of the Set.
If com Dream package has some existing classes:
1 public class Music { 2 private Map<String, String> musicNameMap = null; 3 4 public Map<String, String> getMusicNameMap() { 5 return this.musicNameMap; 6 } 7 8 public void setMusicNameMap(Map<String, String> musicNameMap) { 9 this.musicNameMap = musicNameMap; 10 } 11 }
1 public class Player { 2 private Map<Music, Music> playingMusicMap = null; 3 4 public Map<Music, Music> getPlayingMusicMap() { 5 return this.playingMusicMap; 6 } 7 8 public void setPlayingMusicMap(Map<Music, Music> playingMusicMap) { 9 this.playingMusicMap = playingMusicMap; 10 } 11 }
The Bean can be configured as follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music_1" class="com.dream.Music" /> 3 <bean id="music_2" class="com.dream.Music"> 4 <property name="musicNameMap"> 5 <map> 6 <entry key="Persistent" value="Persistent" /> 7 <entry key="Have you all your life" value="Have you all your life" /> 8 </map> 9 </property> 10 </bean> 11 <bean id="player" class="com.dream.Player"> 12 <property name="playingMusicMap"> 13 <map> 14 <entry key-ref="music_1" value-ref="music_1" /> 15 <entry key-ref="music_2" value-ref="music_2" /> 16 </map> 17 </property> 18 </bean> 19 </beans>
You can see that the collection of map type can be configured with < Map > elements and < entry > elements< The entry > element has a key attribute, which is used to configure the dictionary key of literal value; There is a key ref attribute, which is used to configure the dictionary key referenced by the Bean; There is a value attribute, which is used to configure the dictionary value of literal value; There is a value ref attribute, which is used to configure the dictionary value of the Bean reference. You can see these at a glance. There is no need to elaborate. The point is that collections of map type can also be configured using util elements. As follows:
1 <beans /* Omit namespace and XSD schema file declarations */ 2 xmlns:util="http://www.springframework.org/schema/util" 3 xsi:schemaLocation=" 4 /* Omit namespace and XSD schema file declarations */ 5 http://www.springframework.org/schema/util 6 http://www.springframework.org/schema/util/spring-util.xsd"> 7 8 <bean id="music_1" class="com.dream.Music" /> 9 <bean id="music_2" class="com.dream.Music"> 10 <property name="musicNameMap" ref="utilMusicNameMap"/> 11 </bean> 12 <bean id="player_1" class="com.dream.Player"> 13 <property name="playingMusicMap" ref="utilPlayingMusicMap" /> 14 </bean> 15 16 <util:map id="utilMusicNameMap"> 17 <entry key="Persistent" value="Persistent" /> 18 <entry key="Have you all your life" value="Have you all your life" /> 19 </util:map> 20 <util:map id="utilPlayingMusicMap"> 21 <entry key-ref="music_1" value-ref="music_1" /> 22 <entry key-ref="music_2" value-ref="music_2" /> 23 </util:map> 24 25 </beans>
You can see spring util The XSD schema file defines the < util: Map > element, which is used to configure how to create a collection of map types. There is a < entry > element at the bottom, which is used to configure the key value pairs of the dictionary collection. Therefore, this configuration creates two sets of map types: the id of one set is utilMusicNameMap; The id of a collection is utilPlayingMusicMap. After that, inject the set utilMusicNameMap into music_2. Inject the set utilPlayingMusicMap into the playingMusicMap attribute of player to complete the injection of the set.
Delayed assembly
According to the normal process, after the Spring container completes the creation of the Bean, it starts to inject the dependency of the Bean through the attributes of the Bean to complete the assembly of the Bean. However, sometimes we don't want the Spring container to inject dependencies immediately after the Bean is created, but we want to wait until it is used. At this time, you need to use deferred assembly and tell the Spring container to wait until the Bean is used before injecting the dependencies required by the Bean. As follows:
1 <beans /* Omit namespace and XSD Schema file declaration */> 2 <bean id="music" class="com.dream.Music" lazy-init="true"> 3 <property name="musicName" value="Persistent"/> 4 </bean> 5 <bean id="player" class="com.dream.Player" lazy-init="true"> 6 <property name="playingMusic" ref="music"/> 7 </bean> 8 </beans>
This configuration uses the lazy init attribute of the < Bean > element to tell the Spring container whether to delay the assembly of the Bean. If the lazy init attribute is equal to true, after the Spring container creates a Bean, it will only wait until the Bean is used to inject dependencies; If the lazy init attribute is equal to false, the Spring container will start injecting dependencies immediately after creating the Bean. The lazy init attribute is equal to false by default. Here, we set the lazy init attribute to true to tell the Spring container to delay assembling the dependencies required by music and player beans.
In addition, we can also set the default lazy init attribute of the root element < beans >, telling the Spring container that all beans should be assembled late, as shown below:
1 <beans default-lazy-init="true" 2 /* Omit namespace and XSD Schema file declaration */> 3 <bean id="music" class="com.dream.Music"> 4 <property name="musicName" value="Persistent"/> 5 </bean> 6 <bean id="player" class="com.dream.Player"> 7 <property name="playingMusic" ref="music"/> 8 </bean> 9 </beans>
Specify ID
All along, we have used the id attribute of the < Bean > element to specify the unique identifier of the Bean. But what we don't know is that in addition to the id attribute, we can also use the name attribute to configure the same information. As follows:
1 <bean id="music_1" name="music_2,music_3,music_4" class="com.dream.Music"/>
We specify the value of the id attribute as music_1. Specify the value of name attribute as music_2,music_3,music_4 . Therefore, the Bean has four unique identifiers: music_1，music_2，music_3 and music_4. At the same time, we have also noticed that there is a significant difference between the id attribute and the name attribute: the id attribute can only specify a unique identifier; The name attribute is different. You can specify multiple unique identifiers at the same time. The identifiers are separated by commas, semicolons or spaces.
In addition, Spring also provides the < alias > element to specify the alias of the Bean. As follows:
1 <bean id="music_1" class="com.dream.Music"/> 2 <alias name="music_1" alias="music_2" />
The < alias > element has two attributes: name and alias: the name attribute is used to specify the unique identifier of the Bean; The alias property is used to specify the alias of the Bean. Therefore, this configuration can tell the Spring container to give the id music_ Alias the Bean of 1 music_2. After that, we can use music_1. Music can also be used_ 2 reference the Bean
So far, we have completed more introduction on how to configure beans. The next chapter should talk about how to solve the ambiguity of Bean in automatic assembly. Welcome to continue reading, thank you!