最近原同事接了一个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文件后，执行就正常了
