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排除。所以我们在开发一个组件的时候，起名字是一个很重要的问题，如果升级组件连名字也改了，用户会产生很大的不方便。

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