异常问题:
先看问题,今天想把之前有druid的项目,拷贝到一个新项目中,但是莫名其妙的出现了这个问题,就很奇怪哦!
java.lang.NoClassDefFoundError: org/springframework/boot/bind/RelaxedPropertyResolverat org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.getExcludeAutoConfigurationsProperty(AutoConfigurationImportSelector.java:205) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.getExclusions(AutoConfigurationImportSelector.java:199) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]at org.springframework.boot.autoconfigure.AutoConfigurationImportSelector.selectImports(AutoConfigurationImportSelector.java:96) ~[spring-boot-autoconfigure-1.5.22.RELEASE.jar:1.5.22.RELEASE]at org.springframework.context.annotation.ConfigurationClassParser$DefaultDeferredImportSelectorGroup.process(ConfigurationClassParser.java:888) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]at org.springframework.context.annotation.ConfigurationClassParser$DeferredImportSelectorGrouping.getImports(ConfigurationClassParser.java:874) ~[spring-context-5.2.2.RELEASE.jar:5.2.2.RELEASE]
于是上网查了查,是依赖冲突了,网上大部分的解决方案都是继承一下父项目
<parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>2.1.7.RELEASE</version></parent>
没错,加上之后确实好用了。但是总感觉怪怪的,有两个问题哈。
思考问题
- 为什么之前的项目启动没问题呢?
- 总感觉这种方式治标不治本,而且人家就不想继承怎么办嘞。
解决问题1
于是,带着问题开始查资料,无非就是依赖冲突嘛,解决就可以了呗。
首先,先找到冲突的依赖,怎么找呢,问题既是答案
很明显,这个jar包中没有这个类呗。
所以先找到这个jar包
一查就知道了,其实有两个这种jar包,两个版本不通而已,凭经验猜测,肯定是高版本的jar包有这个类呗(其实是去旧的项目中查了下,旧的项目中引入的只有2.2.2.RELEASE的jar包)
所以问题找到了,找到这个1.5.22.RELEASE的依赖,将这个jar包排除掉就可以了呗。
找依赖也很简单
人家工具还说明冲突的地方了,很明显
引入druid-spring-boot-starter 的时候,导致jar包冲突了,谁让他版本小呢,那就把它做掉就行了。
将冲突jar包冲突排除掉之后,启动项目
解决问题2
博主比较倒霉哈,还是有问题
于是有搜了下,解决方案是加个jdbc的依赖
<dependency><groupId>org.springframework</groupId><artifactId>spring-jdbc</artifactId><version>5.2.4.RELEASE</version></dependency>
试了下,确实可以解决问题,嘿嘿,那就懂了,还是依赖本身jar包的问题呗,于是检查了下依赖库,是
mybatis-spring-boot-starter中jdbc的版本太低了,于是开始升级依赖
将版本升到
再启动项目
漂亮完美启动!
这是我依赖的配置,大家可参考
<dependencies><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId><version>2.2.2.RELEASE</version></dependency><dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-test</artifactId><version>2.2.2.RELEASE</version><scope>test</scope><exclusions><exclusion><artifactId>spring-boot-autoconfigure</artifactId><groupId>org.springframework.boot</groupId></exclusion></exclusions></dependency><dependency><groupId>org.mybatis.spring.boot</groupId><artifactId>mybatis-spring-boot-starter</artifactId><version>2.1.2</version></dependency><!----><!--org.springframework--><!--spring-jdbc--><!--5.2.4.RELEASE--><!----><dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>8.0.19</version></dependency><dependency><groupId>org.projectlombok</groupId><artifactId>lombok</artifactId><version>1.16.18</version></dependency><dependency><groupId>com.alibaba</groupId><artifactId>fastjson</artifactId><version>2.0.24</version></dependency><dependency><groupId>com.alibaba</groupId><artifactId>druid</artifactId><version>1.2.1</version></dependency><dependency><groupId>com.alibaba</groupId><artifactId>druid-spring-boot-starter</artifactId><version>1.2.18</version><exclusions><exclusion><artifactId>spring-boot-autoconfigure</artifactId><groupId>org.springframework.boot</groupId></exclusion></exclusions></dependency><dependency><groupId>org.slf4j</groupId><artifactId>slf4j-log4j12</artifactId><version>1.8.0-beta4</version></dependency><dependency><groupId>org.slf4j</groupId><artifactId>slf4j-nop</artifactId><version>1.7.2</version><type>jar</type></dependency></dependencies>
希望本帖子对大家有帮助
补充
对了,还有一个问题就是,我之前的旧项目为什么就好用呢,原因是如果有依赖冲突的话,maven的解决方案是这样的:
比如有如下两个依赖关系:
A -> B -> C -> D(V1)
F -> G -> D(V2)
这个时候项目中就出现了两个版本的D,这时maven会采用最短路径原则,选择V2版本的D,因为V1版本的D是由A包间接依赖的,整个依赖路径长度为3,而V2版本的D是由F包间接依赖的,整个依赖路径长度为2。
假设有如下两个依赖关系:
A -> B -> D(V1)
F -> G -> D(V2)
这个时候因为两个版本的D的依赖路径都是一样长,最短路径原则就失效了。这个时候Maven的解决方案是:按照依赖包在pom.xml中声明的先后顺序,优先选择先声明的包
我是属于第二种。
参考:https://blog.csdn.net/WinWill2012/article/details/71717811