记一次poi版本升级产生的错误

Posted 2023-05-01

参考技术A 前几天经理说要做一个打印的功能，功能简单，设定打印模板后内容填充再转换html给前台，前台调用打印机就行了。在网上搜了下word内容填充，发现了poi-tl工具包，查看 文档 的时候发现需要poi版本在4.1.1以上：

错误出现在FileImageExtractor类的extract方法调用IOUtils.copy时：

项目poi之前是3.16的，转html没有问题，于是将poi降版本到4.0.0，发现还是报同样的错误，再降版本到3.17，错误神奇的消失了，然后分别查看4.0.0，3.17的IOUtils.copy方法：

对比两个版本的copy方法，可以发现4.0.0的copy方法增加了返回值，3.17则是void的，然后再回到出错的地方，FileImageExtractor类存在于org.apache.poi.xwpf.converter.core包下

这个包在我程序中是1.0.0版本，在pom中ctrl单击core包可以看到它内置了3.8版本的poi

将poi版本更换为3.8可以看到copy方法果然是没有返回值的

也就是说FileImageExtractor类的extract方法在调用IOUtils.copy( in, out )时期待一个没有返回值的copy方法，但是poi 4.1.1却提供了一个return long的copy方法，自然会报NoSuchMethodError。

如果像我这样对poi版本有强制要求并且word转html时需要保存图片时，就只好自己写个继承IImageExtractor的FileImageExtractor和IOUtils类了。

记一次mysql小版本升级

　　最近护网操作比较紧，基线和漏洞检查比较频繁，新扫描出来的mysql漏洞需要修复，没有啥好的修复方法，只剩下升级版本这一条路，生产环境是5.7.12，二进制文件直接解压使用的，看了一下现在最新的版本，5.7.30，好像能解决所有的漏洞问题，直接就干了。

　　mysql的小版本的升级，主要是有两种方式，一种是物理升级，也就是本地停库，替换二进制文件，然后重新启动数据库，执行在线upgrade操作，另一种是逻辑升级，将原有的数据库数据，dump导出为sql文件，然后在新安装的数据库中进行导入操作。

　　考虑到本地环境，数据量比较大，单独硬盘存储，我选择了直接升级操作。

　　主要操作如下：

　　1.下载文件：

　　　　直接访问mysql官方站点下载mysql二进制文件，网络条件受限，下载很慢，整个二进制包660M呢，根本下载不下来，还好国内有站点，选择清华、网易等镜像源，分分钟就将安装包下载下来了。

　　2.上传文件，解压

　　　　直接在指定目录下，解压，生成mysql-5.7.30-log目录

　　3.停库

　　　　由于数据库里面有主从服务，先关闭主库和从库的slave进程，然后关闭日志binlog同步服务，设置innodb的慢关闭，SET GLOBAL innodb_fast_shutdown=0;

　　4.卸载umount，创建软连接

　　　　数据库data目录是单独的挂载，等数据库完全关闭后，执行umount操作，然后将原有的mysql目录重命名（以前直接是做的重命名，没有软连接），将5.7.30目录做软连接，链接到mysql目录上。

　　5.查看命令，启动数据库

　　　　通过which查看mysql等命令的位置，是否能查到，如果查不到，看一下本地path，mount数据目录，然后启动数据库，看日志是否有异常

　　6.执行upgrade操作

　　　　mysql_upgrade直接执行，如果有general_log和slow_log可能会有报错，时间较长，但是无关紧要，毕竟不是真的数据

　　　　升级完成之后，直接关闭数据库，然后重新启动，就完成升级了。

 

　　总体来说，mysql的小版本升级，还是很简单的，我这个操作是比较冒险的，升级前没有做备份操作。