In spring, the specified bean is dynamically replaced based on BeanPostProcessor.

At present, there are too many development frameworks and public components integrated for each system development, and each component uses its own configuration, for example, a single point of login system we are using spring for configuration management. The core bean definition file is packaged in the jar package. When we want to replace one of the bean definitions, it is not easy to directly modify the bean definition file, which will lead to confusion in the framework maintenance. Here, we can use the bean frontend and backend processors in spring for Dynamic Replacement. First, describe the scenario.

There is a jar package that contains an xml file that defines its own series of beans. Another project uses this jar package, but wants to replace one of the beans. The original default bean reads information using the configuration file, but now it wants to change to the database mode. The general method is:

1. Take out the xml file, modify the bean, and put it in the jar package to replace the previous one;

2. Take out the xml file directly, delete the jar package, and put the new xml file in the classpath of the project.

Although these two methods can solve the problem, they are not conducive to the maintenance of the jar package. If the upgrade is made, the project changes will be troublesome. Here, we can use spring BeanPostProcessor to dynamically replace it.

Assume that the bean contained in the xml file defined in the jar package is defined as follows:

<Bean id = "aa" class = "cc. mzone. config. DefaultConfigImpl">... </bean>

The DefaultConfigImpl bean is the object to be replaced. We can write the following classes:

Public class MyConfigImpl extends defaconfigconfigimpl implements BeanPostProcessor {@ Override public Object partition (Object bean, String beanName) throws BeansException {return bean;} @ Override public Object partition (Object bean, String beanName) throws BeansException {if (beanName. equals ("defaultcfg") {// do something return this;} return bean ;}}

Note that we inherit the original DefaultConfigImpl. Of course, you can also write another one without inheriting it. BeanPostProcessor in spring is implemented at the same time. This class is a spring container-level processor and can be made some time before and after bean initialization (initialization here does not refer to class initialization, but relative to bean attribute settings ). We can see that in the postProcessBeforeInitialization method, we perform special processing on the bean named defacfg cfg. Here we directly return the current bean as the replacement instance, thus implementing the Dynamic Replacement of the specified bean, at the same time, it does not damage the original component architecture.

Author's "thisisvoa column"