DB数据源之SpringBoot+MyBatis踏坑过程（一）
liuyuhang原创，未经允许进制转载
系列目录
DB数据源之SpringBoot+Mybatis踏坑过程实录（一）
DB数据源之SpringBoot+MyBatis踏坑过程（二）手工配置数据源与加载Mapper.xml扫描
DB数据源之SpringBoot+MyBatis踏坑过程（三）手工+半自动注解配置数据源与加载Mapper.xml扫描
DB数据源之SpringBoot+MyBatis踏坑过程（四）没有使用连接池的后果
DB数据源之SpringBoot+MyBatis踏坑过程（五）手动使用Hikari连接池
DB数据源之SpringBoot+MyBatis踏坑过程（七）手动使用Tomcat连接池
mysql连接查看
DB数据源之SpringBoot+MyBatis踏坑过程（六）mysql中查看连接，配置连接数量
1.体验SpringBoot
笔者最近新入手的项目，正在使用Springboot，以前一直使用自己构建的架构，
但是感觉SpringBoot的火爆程度，不得不去学习，毕竟后边还有分布式SpringCloud
即使是注册中心闭源了（还有更多的解决方案不是么）
入手以后，最开始觉得是十分方便的，在网上随便找一篇入门的文章，半小时不到
就搭建起来了，来个Controller的HelloWorld，轻松完成。
感觉SpringBoot好简单的
第二天就打脸，那些宣传SpringBoot配置简单的出来压马路的时候想啥呢都。。。
2.SpringBoot打脸
列举一些遇到的问题概述
2.1.首先，SpringBoot是使用maven构建的，而我接手别人的电脑
根本没找到maven配置path，也没上网查，直接：
cmd maven -v，maven - v，maven -version ，maven - version四个命令下去，都是错
（原谅我以前没有怎么动过maven）
问题不在于是否学过maven，是有太多问题没有考虑过。
①myeclipse不同版本对于maven配置的隶属关系是不同的，有些在maven主选项内
有些则是在MyEclipse下的Maven4MyEclipse内
②用maven竟然是好使的，我以为本机安装并配置好了maven，然而MyEclipse自带maven插件
③自带插件的maven目录竟然非常的深，搜maven竟然没有，原来在系统盘用户目录下的 .m2下
注意，这里有个英文的句号
④MyEclipse创建Maven项目的时候，会有选择Catalogs的选项，版本众多不说，没有哪个文章
仔细说明这个选择的到底是什么，原来只是项目的构建模式而已，比如曾经有过的：
将project转为webProject，还有将webProject转为Hibernate项目这种
⑤MyEcplise创建Maven项目的时候，会有选择Catalogs的选项，而该选项会有假死情况，一直
去下载更新Catalogs，而由于网络或者节点或者未知的原因，一直更新，一直更新失败，
导致MyEclipse（Eclipse也试过）出现严重的内存泄漏（java8的更严重），然后就down了
⑥Maven的mirror问题。。。。不是阿里的库能下到所有的东西，公司里有个旧项目有mail的包，
阿里的库就是下不成功，最后换成了默认的库才成功
2.2.SpringBoot的加载依靠的是注解，和曾经的xml配置不同，这里出现了好多个坑
①xml配置是要读取该文件的，而是否读取成功，有没有读取都有个报错提示
②SpringBoot的默认注解配置，是否读取我们并不知道，有些注解是否工作我们也不知道
③版本不同，注解内容不同，本质上走的还是相同的东西，有些注解甚至取消了，或者一个拆成俩
④习惯优于配置，那习惯上为啥parent中没有各种starter，没有mybatis
⑤pom引入的版本，既然不在parent中，引入的其他东西要考虑版本，版本确实是个闹心的东西
⑥pom中的build resource是否成功了，application.properties中的配置是否正确读取了，一概不知
（当然并不是没有办法验证以上问题，只是曾经不曾想需要去验证，一般性的忽略掉了）
还有一些其他的小问题，如springboot中集成的是tomcat8，而建立maven项目中jsp为何报错
为此额外引入了tomcat7，包冲突报错。。。
java8和java7用的parent版本不同，版本不同注解配置不同，好伤心。。。
2.3.Mabatis的坑也不少，网上的大家的编码方式和我平时的编码方式都是完全不同的
①别人的工作模式
给定架构以后要写的代码如下：
获取sessionFactory
获取session
获取mapper接口
使用接口(或注解，或使用mapper.xml中的配置)
②我的工作模式
给定架构以后要写的代码如下:
从缓存中获取单例sessionFactory的session(多线程情况下调用多例的)
调用session原生api，传mapper.xml的命名空间+id+参数
小项目，用不上事务，也不用mapper接口，也不用接口实现类，方便和代码行数少，文件数少
但是没有我这么配置的啊（大家为何如此趋同），以前用spring。xml配置的时候指定mapper扫描的包即可了
而用注解进行配置扫描，都是扫描mapper接口的，在application.properties中可以配置xml的location
但是让我十分失望（上述原因，我根本不知道配置的location是否正确，还是properties文件是否正确加载）
于是产生了以下几个结果（不贴代码，不贴报错内容，免得别人喜欢抄袭）
①Mapped Statements collection does not contain value
这让我作何感想，是mapper的引用命名空间错了，还是传递参数错了，还是mapper.xml压根没扫，
还是sessionfactory没有扫描mapper，还是application.properties中location配置有错，还是配置文件没加载
最后的结果竟然是application.properties本身并没有加载成功,于是网上找该文件加载，提供了三种方式：
一曰@value，二曰eviourment，三曰从SpringApplication的入口main函数中获取context对象
三种都试了，三种都无法加载，同名文章看了几十个，看的我吐血
②null of url
从application.properties中获取的url竟然没有？当然我是从某次数据源加载中出现这个错误判断出来的
那个注解上的perfix干啥去了，springboot启动日志中写对了为配置的包，然而说
“No MyBatis mapper was found in '[com.mapper]' package.”几个意思？
为了获得这个错误，我将mybatis的mapper.xml扫描写到了java代码中，宁可进行全手写配置了，
这样才得出这个结论来。
说到底，因为什么，说不清。
当然还有很多其他结果，就不远程公司电脑去截图了，麻烦，也非重点
数据源的获取蛮简单个事情，为了修改可以从缓存，从网上，从集群中获取数据源，也可以写死，也可以
写到配置文件，写到xml文件中
在此建议，如果springboot数据源上有坑的朋友们，
先写死数据源，写死mybatis配置，能让项目继续进行下去，再考虑springboot的优化配置模式
（我认为没啥用，只是大家都这么用，作为结果并无不同，领导永远看不见你做的工作，又不是界面）
因为，项目给的时间还是有限的，先进行下去，不是每个项目都有集群，都有分布式，领导要你解释代码
所以，先搭好架构，不影响团队继续项目放第一位才对。
说到底，虽然吐槽了很多，肯定有我做的不对的地方，版本不熟悉，配置有错误的地方肯定有
只是，处理这些问题竟然让我用掉了接近六个小时，有点闹心啊！
3.还是明天更吧，睡好觉才不会死
明天继续更，
①对于Springboot下用一个靠谱的方式获得application.properties配置文件，或其他配置文件的内容
这个应该是个很有用的内容
②对于Springboot下用一个靠谱的方式加载数据源，要事务管理的，绕道吧，我不想写的那么麻烦
（数据库本身有事务管理，并不是所有业务都是互联网业务，也不是所有业务都是大型集群数据库操作）
所以，在目的上，任务的甘特图应该是这样的（图难看对付看吧），我也在小公司哈，别吐槽。
|| -------到这里的时候先让架构能用，哪怕都写死，接口和使用方式不变即可
|| -------从此开始做后续优化和更改，不影响其他人工作才对
我（处理springboot架构与工具封装） || =====================================
A（处理web业务） ||===============================
C（处理DB业务） ||===============================
D（处理非web非DB架构） || =====================================
以上！休息！
