java

关注公众号 jb51net

关闭
首页 > 软件编程 > java > java工厂实例区别

java工厂实例BeanFactoryPostProcessor和BeanPostProcessor区别分析

作者:江南一点雨

这篇文章主要为大家介绍了BeanFactoryPostProcessor和BeanPostProcessor区别示例分析,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪

引言

研究 Spring 源码的小伙伴可能会发现,Spring 源码中有很多名称特别相近的 Bean,我就不挨个举例了,今天我是想和小伙伴们聊一聊 Spring 中 BeanFactoryPostProcessor 和 BeanPostProcessor 两个处理器的区别。

我将从以下几个方面来和小伙伴们分享。

1. 区别

这两个接口说白了都是 Spring 在初始化 Bean 时对外暴露的扩展点,因为 Spring 框架提供的功能不一定能够满足我们所有的需求,有的时候我们需要对其进行扩展,那么这两个接口就是用来做扩展功能的。

其实不用看源码,单纯从字面上看,大家应该也能理解个差不多:

BeanFactoryPostProcessor 是针对 BeanFactory 的处理器。

BeanPostProcessor 则是针对 Bean 的处理器。

我们先来看下 BeanFactoryPostProcessor 接口:

@FunctionalInterface
public interface BeanFactoryPostProcessor {
 void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException;
}

可以看到,这里的参数实际上就是一个 BeanFactory,在这个地方,我们可以对 BeanFactory 进行修改,重新进行定制。例如可以修改一个 Bean 的作用域,可以修改属性值等。

再来看看 BeanPostProcessor 接口:

public interface BeanPostProcessor {
 @Nullable
 default Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
  return bean;
 }
 @Nullable
 default Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
  return bean;
 }
}

可以看到,这里是两个方法,这两个方法都有一个 bean 对象,说明这里被触发的时候,Spring 已经将 Bean 初始化了,然后才会触发这里的两个方法,我们可以在这里对已经到手的 Bean 进行额外的处理。其中:

总结一下:

在 Spring 中,BeanFactoryPostProcessor 和 BeanPostProcessor 是两个不同的接口,它们在 Bean 的生命周期中扮演不同的角色。

一言以蔽之,BeanFactoryPostProcessor 主要用于修改 Bean 的定义,而 BeanPostProcessor 主要用于增强或修改 Bean 的实例。

2. 代码实践

2.1 BeanFactoryPostProcessor

BeanFactoryPostProcessor 在 Spring 容器中有一个非常典型的应用。

当我们在 Spring 容器中配置数据源的时候,一般都是按照下面这样的方式进行配置的。

首先创建 db.properties,将数据源各种信息写入进去:

db.username=root
db.password=123
db.url=jdbc:mysql:///db01?serverTimezone=Asia/Shanghai

然后在 Spring 的配置文件中,首先把这个配置文件加载进来,然后就可以在 Spring Bean 中去使用对应的值了,如下:

<context:property-placeholder location="classpath:db.properties"/>
<bean class="com.alibaba.druid.pool.DruidDataSource" id="dataSource">
    <property name="username" value="${db.username}"/>
    <property name="password" value="${db.password}"/>
    <property name="url" value="${db.url}"/>
</bean>

但是大家知道,对于 DruidDataSource 来说,毫无疑问,它要的是具体的 username、password 以及 url,而上面的配置很明显中间还有一个转换的过程,即把 ${db.username}${db.password} 以及 ${db.url} 转为具体对应的值。那么这个转换是怎么实现的呢?

这就得分析 <context:property-placeholder location="classpath:db.properties"/> 配置了,小伙伴们知道,这个配置实际上是一个简化的配置,点击去可以看到真正配置的 Bean 是 PropertySourcesPlaceholderConfigurer,而 PropertySourcesPlaceholderConfigurer 恰好就是 BeanFactoryPostProcessor 的子类,我们来看下这里是如何重写 postProcessBeanFactory 方法的:

源码比较长,松哥这里把一些关键部分列出来和小伙伴们展示:

@Override
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
 if (this.propertySources == null) {
     //这里主要是如果没有加载到 properties 文件,就会尝试从环境中加载
 }
    //这个就是具体的属性转换的方法了
 processProperties(beanFactory, new PropertySourcesPropertyResolver(this.propertySources));
 this.appliedPropertySources = this.propertySources;
}
/**
 * 这个属性转换方法中,对配置文件又做了一些预处理,最后调用 doProcessProperties 方法处理属性
 */
protected void processProperties(ConfigurableListableBeanFactory beanFactoryToProcess,
  final ConfigurablePropertyResolver propertyResolver) throws BeansException {
 propertyResolver.setPlaceholderPrefix(this.placeholderPrefix);
 propertyResolver.setPlaceholderSuffix(this.placeholderSuffix);
 propertyResolver.setValueSeparator(this.valueSeparator);
 StringValueResolver valueResolver = strVal -&gt; {
  String resolved = (this.ignoreUnresolvablePlaceholders ?
    propertyResolver.resolvePlaceholders(strVal) :
    propertyResolver.resolveRequiredPlaceholders(strVal));
  if (this.trimValues) {
   resolved = resolved.trim();
  }
  return (resolved.equals(this.nullValue) ? null : resolved);
 };
 doProcessProperties(beanFactoryToProcess, valueResolver);
}
protected void doProcessProperties(ConfigurableListableBeanFactory beanFactoryToProcess,
  StringValueResolver valueResolver) {
 BeanDefinitionVisitor visitor = new BeanDefinitionVisitor(valueResolver);
 String[] beanNames = beanFactoryToProcess.getBeanDefinitionNames();
 for (String curName : beanNames) {
  // Check that we're not parsing our own bean definition,
  // to avoid failing on unresolvable placeholders in properties file locations.
  if (!(curName.equals(this.beanName) &amp;&amp; beanFactoryToProcess.equals(this.beanFactory))) {
   BeanDefinition bd = beanFactoryToProcess.getBeanDefinition(curName);
   try {
    visitor.visitBeanDefinition(bd);
   }
   catch (Exception ex) {
    throw new BeanDefinitionStoreException(bd.getResourceDescription(), curName, ex.getMessage(), ex);
   }
  }
 }
 // New in Spring 2.5: resolve placeholders in alias target names and aliases as well.
 beanFactoryToProcess.resolveAliases(valueResolver);
 // New in Spring 3.0: resolve placeholders in embedded values such as annotation attributes.
 beanFactoryToProcess.addEmbeddedValueResolver(valueResolver);
}

上面第三个 doProcessProperties 方法我要稍微和小伙伴们说两句:

使用 PropertySourcesPlaceholderConfigurer 对配置中的占位符进行处理,虽然我们只是在 DruidDataSource 中用到了相关变量,但是系统在处理的时候,除了当前这个配置类之外,其他的 Bean 都要处理(因为你可以在任意 Bean 中注入那三个变量)。

这就是 BeanFactoryPostProcessor 一个经典实践,即在 Bean 初始化之前,把 Bean 定义时候的一些占位符给改过来。

2.2 照猫画虎

上面的源码看完了,如果小伙伴们还觉得不过瘾,我们自己也来写一个试试。

我自己的需求是这样,假设我配置 Bean 的时候,按照下面这种方式来配置:

<bean class="org.javaboy.bean.User">
    <property name="username" value="^username"/>
</bean>

这里的 ^username 是我自定义的一个特殊的占位符,这个占位符表示 javaboy,我希望最终从 Spring 容器中拿到的 User Bean 的 username 属性值是 javaboy。

为了实现这个需求,我可以自定义一个 BeanFactoryPostProcessor,如下:

public class MyPropBeanFactoryPostProcessor implements BeanFactoryPostProcessor {
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        String[] beanDefinitionNames = beanFactory.getBeanDefinitionNames();
        for (String beanDefinitionName : beanDefinitionNames) {
            BeanDefinition beanDefinition = beanFactory.getBeanDefinition(beanDefinitionName);
            BeanDefinitionVisitor beanDefinitionVisitor = new BeanDefinitionVisitor(strVal -> {
                if ("^username".equals(strVal)) {
                    return "javaboy666";
                }
                return strVal;
            });
            beanDefinitionVisitor.visitBeanDefinition(beanDefinition);
        }
    }
}

这个 Bean 基本上是照着前面 2.1 小节的 Bean 来写的。我跟大家来大致说一下我的逻辑:

上面这几行代码基本上就是照着 2.1 小节敲的,最后,我们把 MyPropBeanFactoryPostProcessor 注册到 Spring 容器中就行了:

<bean class="org.javaboy.bean.User">
    <property name="username" value="^username"/>
</bean>
<bean class="org.javaboy.bean.MyPropBeanFactoryPostProcessor"/>

看下执行效果:

2.3 BeanPostProcessor

BeanPostProcessor 主要是对一个已经初始化的 Bean 做一些额外的配置,这个接口中包含两个方法,执行时间如下图:

我写一个简单例子我们来验证下:

public class UserService implements InitializingBean {

    public UserService() {
        System.out.println("UserService&gt;Constructor");
    }

    public void init() {
        System.out.println("UserService&gt;init");
    }
    @Override
    public void afterPropertiesSet() throws Exception {
        System.out.println("UserService&gt;afterPropertiesSet");
    }
}

再开发一个 BeanPostProcessor:

public class MyBeanPostProcessor implements BeanPostProcessor {
    @Override
    public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("postProcessBeforeInitialization:beanName"+beanName+";beanClass:"+bean.getClass());
        return BeanPostProcessor.super.postProcessBeforeInitialization(bean, beanName);
    }

    @Override
    public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
        System.out.println("postProcessAfterInitialization:beanName"+beanName+";beanClass:"+bean.getClass());
        return BeanPostProcessor.super.postProcessAfterInitialization(bean, beanName);
    }
}

然后我们将这两个 Bean 都注册到 Spring 容器中:

<bean class="org.javaboy.bean.MyBeanPostProcessor"/>
<bean class="org.javaboy.bean.UserService" id="us" init-method="init">
</bean>

最后启动容器,来看下控制台打印的内容:

可以看到,跟我们所预想的是一样的。在 MyBeanPostProcessor 中,第一个参数其实就是已经初始化的 Bean 了,如果想在这里针对 Bean 做任何修改都是可以的。

2.4 典型应用

BeanPostProcessor 其实有很多经典的应用,我在写文章的时候,想到一个地方,就是我们在 SpringMVC 中做数据验证的时候,往往只需要加几个注解就可以了(对此不熟悉的小伙伴可以在公众号后台回复 ssm 有松哥录制的 ssm 入门视频),那么这个注解是在哪里进行的校验的呢?就是 BeanPostProcessor,我们来看一眼源码:

public class BeanValidationPostProcessor implements BeanPostProcessor, InitializingBean {
 @Nullable
 private Validator validator;
 private boolean afterInitialization = false;
 public void setAfterInitialization(boolean afterInitialization) {
  this.afterInitialization = afterInitialization;
 }
 @Override
 public void afterPropertiesSet() {
  if (this.validator == null) {
   this.validator = Validation.buildDefaultValidatorFactory().getValidator();
  }
 }
 @Override
 public Object postProcessBeforeInitialization(Object bean, String beanName) throws BeansException {
  if (!this.afterInitialization) {
   doValidate(bean);
  }
  return bean;
 }
 @Override
 public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
  if (this.afterInitialization) {
   doValidate(bean);
  }
  return bean;
 }
 /**
  * Perform validation of the given bean.
  * @param bean the bean instance to validate
  * @see jakarta.validation.Validator#validate
  */
 protected void doValidate(Object bean) {
        //...
 }
}

这段代码其实很好懂,可以看到,我们可以控制是在具体是在 postProcessBeforeInitialization 还是 postProcessAfterInitialization 方法中进行数据校验。

好了,现在小伙伴们应该搞懂 BeanFactoryPostProcessor 和 BeanPostProcessor 的区别了吧?

3. 小结

我再把前文的小结内容拿过来,小伙伴们现在看是不是更清晰了?

在 Spring 中,BeanFactoryPostProcessor 和 BeanPostProcessor 是两个不同的接口,它们在 Bean 的生命周期中扮演不同的角色。

一言以蔽之,BeanFactoryPostProcessor 主要用于修改 Bean 的定义,而 BeanPostProcessor 主要用于增强或修改 Bean 的实例。

以上就是BeanFactoryPostProcessor和BeanPostProcessor区别示例分析的详细内容,更多关于BeanFactoryPostProcessor BeanPostProcessor区别的资料请关注脚本之家其它相关文章!

您可能感兴趣的文章:
阅读全文