NoSuchMethodException NoSuchElementException NoSuchBeanDefinitionException

no such
[词典] 没有这样的;
[例句]In an ideal world, there would be no such thing as rubbish
在一个理想世界中,不会有垃圾之类的东西。

java.lang.NoSuchMethodException
java.lang.NoSuchMethodError
java.lang.NoSuchElementException
NoSuchBeanDefinitionException

问题:

Caused by: org.springframework.beans.factory.NoSuchBeanDefinitionException: No qualifying bean of type ‘com.chinasoft.mapper.IProjectManagersMapper’ available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

如何解决:

  1. 很明显IProjectManagersMapper未定义,添加相关的注解@MapperScan(“com.chinasoft.mapper”)
  2. @SpringBootTest @RunWith(SpringRunner.class) @ContextConfiguration
  3. expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {@javax.annotation.Resource
  4. expected at least 1 bean which qualifies as autowire candidate. (期望至少1个bean作为自动搜索候选)Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true)}

java–遇到NoSuchMethodError通用解决思路

错误可能的原因:
有这个类,该类真的没有这个方法
有这个类,而且有好几个,他们之间发生了冲突
参考
https://www.cnblogs.com/xiaoMzjm/p/4566672.html

原因排除:

  1、点击进入报错的代码所在行,在报错的地方打一个debug点,重行启动项目或重现该错误,让程序运行到该行代码:

  2、打开display界面(若没有,请在window–show view里面找出该界面),

  手动敲出xxx.class.getProtectionDomain().getCodeSource(),xxx为报错的类的全类名,鼠标选中该行代码,点击界面右上角的J图标,即会打印出到该类对应的包所在的地址。如下图所示。  

  可以看到,结果为:

  (java.security.CodeSource) (file:/D:/Program%20Files%20(x86)/eclipse/configuration/org.eclipse.osgi/843/0/.cp/lib/core-3.1.1.jar )

  3、接着复制该类的全类名,快捷键Ctrl+Shift+T打开open type界面,查看我们的项目引用到的包中,哪些有这个类:

  我们发现有两个包中有org.eclipse.jdt.internal.compiler.Compiler这个类,分别为:

  包一:ecj.3.5.1.jar

  包二:core-3.1.1.jar

  地址分别为:

  但我们发现,刚刚在display中,我们看到的地址,居然不是来自这上面两个地址(上面两个包的地址都在C盘,DEBUG中的包来自D盘),也就是说,实现运行环境引入的包,并不是在我们自己项目中配置的,因为open typy只能找到自己项目中配的东西。

  那么D盘的这个包,在什么地方引入的呢?

  想想,这个错误是在项目启动时报的,那么除了项目,还有“服务器”可能会引入其他包,那么有没有可能是服务器帮我们引入呢?

  4、打开服务器的Classpath,可以找到服务器确实引入了这个包

  那么我们在服务器的classpath中把这个包“remove”掉。

  5、再次重新启动项目,dubug、卡点、display,这次结果如下:

  发现:实际环境中,现在己经没有引入D盘那个core-3.1.1.jar包了。我们让项目运行下去,发现还是报同样的错——找不到方法。那么接下来我们让项目引用ecj.3.5.1.jar这个包试试。

  6、ctrl+shift+T、双击进入core-3.1.1.jar中Compiler类所在的目录结构:

  提示:左边栏勾上这个标志,即可展开该包所在的目录:

  同理,打开ecj.3.5.1.jar中Compiler类所在的目录结构。

  最后发现,这个jar包都同一个项目下面,而且两个包都有Compiler类,且排在前面的是core-3.1.1.jar,但是core-3.1.1.jar的Compiler类并没有我们想要的方法,所以报错了。但是eclipse在找类的时候,只要按顺序找到一个,就不会往下找了,所以排在下面的ecj-3.5.1.jar并不会被找到,即使里面有Compiler这个类,且有我们想要的方法。

  7、排除core-3.1.1.jar包:

  该项目是maven项目。我们尝试直接在该项目的pom.xml中搜索core这个包是搜索不到的,那么这个core-3.1.1包可能是因为本项目引入其他项目,而其他项目引入core-3.1.1.jar,所以本项目间接把该包引过来了。

  同时,因为该项目是maven项目,可以通过以下该方法排除这个包:

  排除后,该项目的pom.xml变成:

  假如是非maven项目,那么可以直接从lib中除去该包,或从项目根目录下面打开.classpath文件,找到对应的包的配置,删除该行即可。

  通过该pom.xml我们可以知道,之所以会产生jar包冲突,原因有两个:

  1、 本项目A本身引用了ecj-3.5.1.jar包,同时引入了项目B,而项目B引入了core-3.1.1.jar,所以本项目也相当于引入了core-3.1.1.jar,这就是maven项目中常见的jar包冲突。

  2、 那为什么maven没有自动帮我们解决jar包冲突呢,那是因为ecj-3.5.1.jar包和core-3.1.1.jar包的groupId和artifactId都不一样,所以maven认为这是两个jar包,并不冲突,解决的办法就是像上面那样,加入exclusions排除。所以我们在开发一个组件的时候,起名字是一个很重要的问题,如果升级组件连名字也改了,用户会产生很大的不方便。

  再次启动项目,问题解决。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值