前言
最近业务部门接手供方的项目过来二开，其中有个认证实现因为业务需要，需要替换原有供方实现的逻辑。大概伪代码如下。供方提供的接口以及默认实现形如下
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注解，后面把包升级就解决了