elasticsearch hign level client 在jdk1.8，jetty中启动失败问题记录

elasticsearch hign level client 6.3.2在jdk1.8，jetty中启动失败问题记录

  由于我司是war包部署在jetty中，启动过程就报了个错误MultiException，linux下的jetty就没有详细的日志，真是一头雾水，也不知道咋了。想到这次服务开发新用到了elasticsearch hign level client 6.3.2，觉得很有可能是这个引起的，询问我司其他项目组用ES时，说也有类似启动失败的问题，当时他们就转为lower level es就没有问题，但是我们时间很赶，改代码就没有时间，这种情况下，做着两手准备，相关人员也是先去改代码，我就负责再去分析下，看了这个错误日志，以为是jetty启动时扫描超过默认时间60秒，就想着改长一点试下，但是也不行，改到10分钟都没有启动起来，想着是不是内存不足，我就手动加了jvm内存，改到4G，也不好使，怎么启动都不行，想着能不能升jetty的版本（因为我同事说升到jetty2018的版本就好了），但是想着生产突然换jetty的版本肯定都有好多反对的声音，这样就只能硬着头皮在分析，分析。突然灵感一闪，是不是我司linux下jetty版本是不是改过，都没有日志，就想着把jetty启动的debug级别的日志打印出来，可惜也没有什么用。这时突然想着本地window系统下把jetty启动下，终于峰回路转有详细日志了，可能是打印在控制台了，没有入日志文件 
MultiException[java.lang.RuntimeException: Error scanning entry META-INF/version
s/9/org/elasticsearch/core/internal/io/Streams.class from jar elasticsearch-core-6.3.2.jar, java.lang.RuntimeException: Error scanning e
ntry META-INF/versions/9/org/elasticsearch/monitor/jvm/JvmPid.class from jar fil
e:elasticsearch-6.3.2.jar]

  找到了elasticsearch和elasticsearch-core下META-INF/version
s/9/下的class加载不了，后面仔细分析了下，觉得这个是jdk1.9编译出来的class文件，也不知道elasticsearch官方出品的jar包里面为啥有jdk1.8和jdk1.9两种class文件。

解决方案，自己手动删除这个versions/9目录，然后改了个版本号手动上传到nexus库。

问题解决，多试总有收获。