DB数据源之SpringBoot+Mybatis踏坑过程实录系列（一）

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架构）　　　　　　       || =====================================

 

 

 

以上！休息！