jar包冲突引起的反思

最新推荐文章于 2024-06-29 22:09:37 发布

一生奋斗只为梦

最新推荐文章于 2024-06-29 22:09:37 发布

阅读量482

点赞数

分类专栏： Java 开发问题总结文章标签：问题排查思考总结异常

本文链接：https://blog.csdn.net/follyandheart/article/details/77614943

版权

Java 同时被 2 个专栏收录

2 篇文章 0 订阅

订阅专栏

开发问题总结

1 篇文章 0 订阅

订阅专栏

背景：

今天在公司加班撸代码，由于是新工程，引入的jar包不多，表结构有几次调整，加了一些配置，写了很多代码都没有run。最后run的时候报错了。

1.先是报MQ没有初始化XXXListener，检查配置发现properties文件多配置了消费者Topic，但是没有初始化Listener。其实这边暂时不需要消费消息，只需要生产消息，犯了低级错误，很快解决了。

2.再启动时候报错如下：Unable to create a Configuration, because no Bean Validation provider could be found. Add a provider like Hibernate Validator (RI) to your classpath...。后面还有很多其他错误，主要是说Mybatis的DAO类无法解析之类的。

当时解决思路：

1.一开始也发现了上面说的错误，但是排在一行很后面，拉了一半扫了一眼也没仔细看。心里老是想着下面的错误，为什么不能解析DAO，是不是哪里配置不对？检查了DAO的注解和配置都没有问题，中间看了下中间件的文档，还在怀疑是不是由于用的@Resource而不是@Autowired引起的，后来替换成@Autowired看了下也没有解决问题，决定应该不是这个原因。

2.import包，刷新工程重新启动，这次看到了上面说的英文错误。然后google了一下，排行第一的就是stackoverflow，Answer如下：

30 down vote

Add a Bean Validation Provider dependency e.g Hibernate Validator. The Bean Validation API dependency is available on the classpath but the implementation is missing. Add the following to your pom.xml

<dependency>
    <groupId>org.hibernate</groupId>
    <artifactId>hibernate-validator</artifactId>
    <version>5.2.4.Final</version>
</dependency>

然后我就复制了一下加到项目pom配置文件中，但是傻逼了地方没放对（当时脑子不灵光了没注意），启动仍然报错。我就想那应该不是这个原因，然后又仔细去看了看配置也没发现啥问题，中间怀疑是不是jar包冲突了，想了一下，觉得新引入的一个jar包是不是和已有的相互冲突了？然后用idea工具看了下依赖树，果然有很多标红的冲突，就忙着去排除，排除的时候又排除多余的了，又引发了其他错误。

3.过了大概2个小时多，正在焦头烂额的时候，旁边的同事说他搞好了，就是在pom里面加了下上面的依赖，我说我刚刚就加了咋不起作用啊？然后他问我加哪里了，原来我在工程根POM里面的dependencyManagement的dependencies节点加了依赖，但是没有在starter模块引入依赖。可能是当时比较着急大意了，可能是对maven依赖的理解不深入，现在回想起来决定应该是后者。

4.然后我觉得，虽然加validator依赖解决了问题，但是感觉不彻底，我也是确实发现了jar包有冲突。原因是引入的jar包很复杂，又依赖了很多其他jar包。最后根据mvn dependency:tree 命令查看依赖树，和同事发现一个叫middle的间接依赖有问题，在父POM里面在之前加的新jar包依赖下面exclusion一下middle就可以了。

5.这次从发现问题到初步定位问题，再到最后的较彻底解决问题，花费了大概4个多小时，本来打算晚上8点之前搞定就回去，结果拖到晚上12点多点才解决。

反思：
1.注意以后写代码，不要凭感觉大段大段的写代码，加配置，改结构，然后再去启动。而是采用小步快跑的方式，比如加个配置、写差不多一段代码就编译启动，通过后就提交，然后进行下一阶段编码。这样层层递进，出了问题相对容易排查追溯，大不了回滚到之前编译通过的提交处，一次性写的太多，都不知道是哪里出现问题了。

2.代码出了问题不可怕，不要慌慌张张，凭猜想去解决问题。确实，很多问题凭经验或者猜想也可以解决的。但是大多数情况下，还是从第一原理出发，根据日志报错提示，客观理性分析问题到底可能出现在哪里，由什么原因造成的。然后可以用排除法缩小范围，逐步排查。可以百度或者Google，仔细分析，经过思考实在不行，可以请教别人。

3.今天报的错其实并不难，想着要早点回去，一开始并没有耐心认真去看日志，甚至扫到了错误原因，但是看了后面的错误，想凭自己的经验或者说是猜想解决问题。第二次发现了日志提示，搜索到了一种解决方案，但是由于大意或者说是理解不深，配置放错地方，从而否决了提示。导致后面花费了大量时间，进行试错排除，走偏了。

4.这次报出的问题不难，却走了很多弯路，花费了很多时间。本来如果是冷静耐心根据提示来解决，问题可能早就解决了，早点下班了。由于自己的种种原因，导致走偏，浪费了很多时间，确实值得反思，尤其是对于我这种工作了几年的人，真是不应该。因此这里特别记下来，希望自己能够吃一堑长一智，引以为戒。

5.在平时解决问题过程中，要注意反思总结。通过反馈意识到自己的不足，通过总结也督促自己不断前进。