最近原同事接了一个java的运维支持事项,对方采用spring boot打包,最终在服务器上提供了可执行的jar包运行。由于种种原因,服务器必须进行重做,但更新完成之后发现jar包无法正常执行,最终基于日志分析是api包中使用了sslv3协议去获取企业微信支持功能。而当前微信开放的协议不支持sslv3,并且已经定位到sslv3是在叫底层的api包中已经封装死了。
手上的源码分析确实是是写死了sslv3,但怎么去更新呢?
为了让整个运行项目影响降低到最小。最优方案是只更新协议确认class,其他不进行操作。
根据手上的资源,sslv3调整时是简单的,怎么让调整的class文件放入spring boot 包中成为了难点。
如果是jar的class文件,确实可以使用类似360压缩等工具去更新。但如果是spring boot打包的可执行文件,这种方案就不奏效了。怎么处理呢?
jar的本质是一个zip压缩格式文件,只是在文件的头部修改了文件魔法值,使用jar命令进行打包本质上与zip文件压缩类似。
当我们把原有可执行jar进行解压后,能获取到一个较为标准的spring boot文件目录。把lib中的底层sslv3协议的jar包更新后,执行文件打包命令就可以获取到一个新的jar包。
第一次执行jar -cvf xxxx.jar * ,文件确实正常打包了。更新Manifest文件后,执行java -jar xxxx.jar 启动时,发现新jar内置的jar包无法正常解析。
怎么处理呢?
经过异常分析,jar如果内置了jar文件,打包时不能启动压缩方案。
最终使用 jar -cvf0 xxxxx.jar * 重选打包,更新完Manifest文件后,执行就正常了