This is the sixth day of my participation in the More text Challenge. For details, see more text Challenge

Spring provides a container mechanism called BeanFactoryPostProcessor. This mechanism allows us to make changes to the information held by beanDefinitions registered with the container before the container instantiates the corresponding object. This is equivalent to adding a step at the end of the first phase of the container implementation that lets us do some additional operations on the final Bean definition, such as modifying some properties of the bean definition init, adding additional information to the bean definition, and so on.

If to realize spring BeanFactoryPostProcessor custom, we need to implement org. Springframework. Beans. Factory. Config. The spring BeanFactoryPostProcessor interface. A container may have multiple Spring BeanFactoryPostProcessor at the same time, this time may require the implementation class and achieving the org. Spring springframework. Core. Ordered interface, To ensure that each BeanFactoryPostProcessor is executed in a predefined order (if order matters). However, because Spring already provides several ready-made BeanFactoryPostProcessor implementation classes, most of the time, we rarely implement a BeanFactoryPostProcessor ourselves. Among them, Org. Springframework. Beans. Factory. Config. Accomplished and org., springframework. Beans. Factory. Config. The Property The OverrideConfigurer are two of the more common BeanFactoryPostprocessors.

1.PropertyPlaceholderConfigurer

In general, we don’t want to mix information like system administration-related information and business-object-related configuration information into XML configuration files to avoid problems with changing the complex XML configuration files during deployment or maintenance. We will separate some database connection information, mail server information, and other related information into a Properties configuration file, so that you only need to focus on these simple Properties accessory files if changes are made due to system resources.

Accomplished allows us to use a PlaceHolder in the XML configuration file (PlaceHolder), and will these PlaceHolder represents resources separate configuration to a simple properties file to load. Take data source configuration as an example:

<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close">
	<property name="url">
    	<value>${jdbc.url}</value>
    </property>
    <property>
    	<value>${jdbc.driver}</value>
    </property>
    <property>
    	<value>${jdbc.username}</value>
    </property>
    <property>
    	<value>${jdbc.password}</value>
    </property>
    <properry name="maxActive">
    	<value>100</value>
    </properry>
</bean>
Copy the code

Now, all the resources represented by these placeholders are placed in the jdbc.properties file, as shown below:

jdbc.url=jbcd:mysql://...
jdbc.driver=com.mysql.jdbc.Driver
jdbc.username=your username
jdbc.password=your password
Copy the code

The basic mechanics are exactly what they were. When BeanFactory has loaded all the configuration information in the first stage, the property information of the object stored in BeanFactory is still only in the form of placeholders, such as ${jdbcd.url}. When is accomplished as spring BeanFactoryPostProcessor being applied, it will use the properties in the configuration file configuration information to replace placeholders in the corresponding BeanDefinition attribute values. Thus, when the bean is instantiated in the second phase of the container implementation, the property values in the bean definition are finally replaced.

2.PropertyOverrideConfigurer

If these are accomplished do “Ming”, the relatively PropertyOverrideConfigurer do have bit of “undetected. Can be accomplished in the container in the configuration of any bean you want to deal with the property of the definition of information to overlay. For example, in our dataSource definition, maxActive is 100, and if we don’t think that’s appropriate, So can be accomplished in the dataSource. The corresponding properties file do maxActive = 200, to 100 cover.

Accomplished file configuration items, overwrite the original XML bean definitions of property information. But such activity, only look at the XML configuration, simply can not see which bean definition of the property will be overwritten, only check is accomplished to specify the properties configuration file will understand. Basically, this override replacement is transparent to the bean definition.

If you want the container to cover some beans in the definition of property information, we need to follow the rules provide a PropertyOverrideConfigurer using configuration files: beanName. PropertyName = value