前言

最近业务部门接手供方的项目过来二开,其中有个认证实现因为业务需要,需要替换原有供方实现的逻辑。大概伪代码如下。供方提供的接口以及默认实现形如下

public interface AuthCodeService {
    default Boolean check() {
        return true;
    }

}

@Service("authCodeService")
public class AuthCodeImpl implements AuthCodeService {

    public Boolean check() {
        // doBiz
        return true;
    }
}

业务的替换实现如下

@Service
public class BizAuthCodeImpl implements AuthCodeService {

    public Boolean check() {
        // doOtherBiz
        return true;
    }
}

然而项目运行的时候,发现走的认证逻辑始终是供方的逻辑,而非业务重写后的逻辑。

平时因为跟业务的技术负责人走得比较近,他就私下找我交流一下思路。一开始我给他提的建议是说在你定制的业务类上加@Primary试下,他说他加了但没效果。

于是我就跟他说不然你直接改供方源码的默认实现,他给的答复供方没提供源码,只提供jar。我就跟他说,这也可以改,你项目创建一个和供方实现一模一样的类,就是包名和类名一模一样,利用类的加载顺序实现。技术负责人又觉得这样不好。

后面那个技术负责人想了一个方式,就是他将业务定制bean名称和供方提供的bean名称一样,形如下

@Service("authCodeService")
public class BizAuthCodeImpl implements AuthCodeService {

    public Boolean check() {
        // doOtherBiz
        return true;
    }
}

然后项目启动,直接报了如下错

org.springframework.context.annotation.ConflictingBeanDefinitionException: Annotation-specified bean name 'authCodeService' for bean class 

他就跟我说这个异常怎么修复,铺垫了这么久,引来了今天要聊的话题,同名bean异常报错如何修复

解决思路

首先抛出一个观点,在同个spring容器中,是不能出现同名的bean,因此解决的思路要么搞成不同的spring容器,要么就是排除多个同名的bean,只保留自己想要的那个。要么就是将bean改个名字。今天介绍的思路就是排除同名bean,只保留自己想要的bean

实现方法

1、方法一:通过@ComponentScan进行排除

示例配置

在springboot的启动类上加上形如下内容

@ComponentScan(basePackages = {"com.github.lybgeek"},excludeFilters = {@ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE,classes = AuthCodeImpl.class)})

这边有个注意点是当你启动类上同时存在@SpringBootApplication和@ComponentScan注解时,@ComponentScan注解指定的扫描包路径会覆盖@SpringBootApplication的包路径。

我将第一种方案告诉业务技术负责人后,他试了一下,果然没报错,但是后面出现一个问题,他说@SpringBootApplication的属性exclude()失效了,导致他项目要排除的自动装配类失效了。于是就有了第二种方案

2、方法二:自定义TypeExcludeFilter

我们点开@SpringBootApplication,可以看到如下内容

@ComponentScan(excludeFilters = { @Filter(type = FilterType.CUSTOM, classes = TypeExcludeFilter.class),
        @Filter(type = FilterType.CUSTOM, classes = AutoConfigurationExcludeFilter.class) })
public @interface SpringBootApplication {

既然@SpringBootApplication和@ComponentScan同时标注在启动类上会有一定冲突,我们就遵循@SpringBootApplication提供的扩展方案就好了,自己写一个TypeExcludeFilter进行排除

实现步骤

1、自定义TypeExcludeFilter
public class CustomTypeExcludeFilter extends TypeExcludeFilter {

    @Override
    public boolean match(MetadataReader metadataReader, MetadataReaderFactory metadataReaderFactory) throws IOException {
         String className = metadataReader.getClassMetadata().getClassName();
         return AuthCodeImpl.class.getName().equals(className);

    }
}
2、将自定义TypeExcludeFilter注入到spring容器 中

这边有个特别需要注意的细节点,因为TypeExcludeFilter是要排除bean的,因此他注入的时机至少要在其他bean注入之前,具体来说就是在容器上下文refresh执行之前,就得完成注入。在refresh之前执行的扩展点有很多,我们就挑一个,我们以实现ApplicationContextInitializer为例

public class CustomTypeExcludeFilterApplicationContextInitializer implements ApplicationContextInitializer {
    @Override
    public void initialize(ConfigurableApplicationContext applicationContext) {
        DefaultListableBeanFactory defaultListableBeanFactory = (DefaultListableBeanFactory) applicationContext.getBeanFactory();
        BeanDefinitionBuilder beanDefinitionBuilder = BeanDefinitionBuilder.genericBeanDefinition(CustomTypeExcludeFilter.class);
        AbstractBeanDefinition beanDefinition = beanDefinitionBuilder.getBeanDefinition();

        defaultListableBeanFactory.registerBeanDefinition("customTypeExcludeFilter",beanDefinition);
    }
}
3、将ApplicationContextInitializer 的实现类放在/META-INF/spring.factories
org.springframework.context.ApplicationContextInitializer=\
com.github.lybgeek.context.CustomTypeExcludeFilterApplicationContextInitializer

按照上面三步执行,就可以排除自己想排除的bean

总结

当项目中出现同名bean冲突时,如果可以的话,就尽量换个其他bean名称来解决

后面业务负责人并没有采用我上述的方案,我们回归业务负责人他们项目诉求,他们的需求是要他们自定义认证的逻辑能生效,而非解决同名bean冲突。

业务负责人他们最后的方案是通过加@Primary注解解决,他之前加了觉得没生效,是因为他们项目引的自定义认证逻辑的旧包,那个旧包没加@Primary注解,后面把包升级就解决了


linyb极客之路
330 声望191 粉丝