前言

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

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注解，后面把包升级就解决了