分享一次自己定位 + 解决问题的经历
问题背景
最近在使用 Java的 Springboot 框架开发一个项目, 遇到2个百思不得其解的问题. 当时被这问题搞懵了, 为了解决这2个bug探索了好几个小时, 最终靠自己沉下心摸索, 然后定位到问题并解决！ 虽然最终发现解决问题很简单, 但是通过自己进行定位，分析问题的过程，然后解决问题,成就感满满, 哈哈, 所以分享一下整个过程~
问题汇总
总共有2个问题:
第一个：写了一个很基础的Controller类然后访问, 结果总是404
第二个: 首先在Maven父工程中写了Swagger的配置, 创建了2个Maven子工程.
- 在子工程A中引入了此父类, 可正常访问swagger的web界面.
- 子工程B也引入了此父类, 子工程B中的Pom.xml配置和子工程A的几乎一样, 但是却无法正常访问swagger的web界面...
实际问题描述
这是第一个问题的描述
- 这是当时写的Controller
- 按照常理来说, 我只要外部访问
http://127.0.0.1:8002/oss/file/w就可以得到预期的返回值了,然而实际结果如下, 返回404错误
3. 开始排查问题
- 使用postman调试接口, postman接口如下
- 因为是多个服务同时启动,所以我首先检查访问的服务是否正确. 经过确认,目标服务的启动端口没错是8002
server.port=8002, 然后postman也访问的也是8002端口 - 确认访问路由是否正确 首先看上去postman请求的路由似乎没毛病, 路由完全匹配.但经过几次实际请求,发现结果还是404后, 手动将代码中的路由又拷贝了一份到postman上, 防止出现眼花或者中文字符导致的问题. 结果并没有发生什么变化, 依旧404 ~
- 怀疑是idea的缓存问题导致的? 抱着这个怀疑态度，尝试重启idea了几次, 结果依旧没变化, 哎,此时心态有点急躁了
- 自己无头绪了, 尝试百度看下
看到这个大神写的帖子后, 突然有点思路了, 于是去检查该应用的 @ComponentScan 注解.单纯看注解写的是没问题, 然后尝试性的去看下文件所在的包, 发现...
- 问题分析
经过排查定位, 问题显而易见, 原因是启动类上的@ComponentScan里面的配置不对导致的!(写包名的时候应该是 com.atguuigu.oss, 但多打了个u变成了com.atguuigu.oss)
由于@ComponentScan里面的配置和实际的包名不对应, 所以该应用启动时, Spring没自动加载正确包名目录下的Controller文件, 所以外部访问会出现404, 顺理成章~
- 尝试解决问题
因为刚才的帖子说: 如果没配置@ComponentScan, Springboot会自动加载启动类所在包下及其子包下的所有组件
- 所以首先将启动类上面的
@ComponentScan(basePackages = "com.atguigu")这句话去掉了, 验证是否正常.经过重启验证, 接口访问正常了, hahaha~
- 刚才的操作, 初见成效了.但是还有个问题就是swagger-ui的web访问问题. 抱着顺藤摸瓜的思路, 猜测访问swagger很有可能也是这个原因导致的!
刚才是直接去掉@ComponentScan的方式解决问题的, 还有一种方法是将@ComponentScan(basePackages = "com.atguigu")里面的配置和包名保持一致即可.
操作结果: 更改后, 新服务的swagger访问成功!!!
今日总结
- 虽然看上去是长篇大论的排查遇到的问题, 然后实际解决的话就改个字母的事(
估计有人该喷怎么这么菜,就因为一个字母, 还需要浪费好几个小时排查问题?) - 想通过本篇文章,分享一下自己遇到问题的解决思路: 循序渐进的排查 + 解决问题~
- 分享几句名言:
- 不识庐山真面目, 只缘身在此山中!
- 山重水复疑无路, 柳暗花明又一村!
因为写这篇文章的时候, 感悟到了这两句诗的内涵, haha~
- 分享下今日感悟
- 如果心情不好, 需要先平复心情, 然后再干别的事情, 否则会事倍功半!
- 遇到事情真的不要心急, 尽量保持心态平和, 这样才能让大脑保持冷静,理性的看待问题. 要有一种 “泰山崩于前而色不变，麋鹿兴于左而目不瞬” 的心态！