- 背景
- 现象一:引入了一个包A,服务突然起不来了,后台有报错信息,Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type 'xxx' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}
- 现象二:多次重启服务,有一定的概率能够启动(初步怀疑是包冲突)
- 启动不了的时候,报错的bean写法如下
-
package mypackage; @Slf4j @MyComponent @RequiredArgsConstructor(onConstructor = @__(@Autowired)) public class MyBean{ XXX }
-
- 上述他使用自己定义的注意,然后通过自定义的beanDefinitionRegistar扫描这类bean
public class MyComponentConfigRegister implements ImportBeanDefinitionRegistrar { public void registerBeanDefinitions(@NotNull AnnotationMetadata importingClassMetadata, @NotNull BeanDefinitionRegistry registry) { //获取到所有包含这些注解的类之后,我们添加到spring容器中去即可 Set<Class<?>> annotated = new Reflections(new ConfigurationBuilder().forPackage("mypackage").setScanners(Scanners.values())).get(TypesAnnotated.with(MyComponent.class).asClass()); }
- 初步追查,bean找不到问题
- 现象很简单,spring中最常见的问题了,少了一个bean;背景也只自定义一个beanDefinitionRegsitar扫描背@MyComponent注明的类。
- debug这个MyComponentConfigRegister 。发现了一个很奇怪的问题,
- 核心代码, Set<Class<?>> annotated = new Reflections(new ConfigurationBuilder().forPackage("mypackage").setScanners(Scanners.values())).get(TypesAnnotated.with(MyComponent.class).asClass());
- 扫描出来的annotated就是没有MyBean这个类
- 可以观察到他的反射包使用的是Reflections类,来自jar包reflections
- 问题是,为啥包里面没有有这个类MyBean,通过Reflections就是扫描不到呢??
- debug过程中,另外发现一个问题,同一个包路径下的类,MyBean1,就是可以被扫描到,但是Mybean就是不行。
package mypackage; @Slf4j @MyComponent @RequiredArgsConstructor(onConstructor = @__(@Autowired)) public class MyBean1{ XXX }
- 继续追查,Reflections获取不到反射的问题
- debug Reflections类,在他的scan方法里面初见端倪,
- 处理mybean的时候,会报错误,invalid constant type: 18
- 因为,日志级别是trace,所以服务器日志上看不到这个错误信息。
- 继续追查,invalid constant type: 18,是什么问题
- stackoverflow上已经有类似的问题,Reflections - Java 8 - invalid constant type - Stack Overflow
- 帖子的结论很简单:Reflections依赖的javassist版本太低了,不支持java8的特性。例如stream的使用
- 至此,问题定位到。而且Mybean的写法和MYbean1的写法中区别就是,myBean使用了stream,所以Reflections在扫描的时候报错了。
- 问题解决:
- 升级Reflections依赖的javassit的版本
- 继续:
- 到这里问题应该解决了,发布代码问题也确实解决了。
- 但是,,,好像还有一个遗留的疑问,最开始的时候,为啥重启多次也能解决呢。
- 看看最初的版本依赖,,其第一个有问题的jar包路径更短。理论上是100%错误,不应该重启多次就好
- 最终发现,2个包的坐标不一样,他们的groupid不一致导致的,2个jar包不会报冲突,在jvm启动时加载那个jar包都有一定的几率,