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