记录两次问题排查过程

一、引入了一个第三方的jar包提供的能力，需要把三个官方的jar（transmittable、aspectJ等）引入项目，我放在了resource目录下，新建了一个lib。启动时对三个jar执行-javaagent命令。之前都没问题。同时该项目的测试和预发环境镜像也可以正常启动，但是prod环境报错镜像里找不到这三个jar。在镜像文件里对应路径下，又能找到三个文件名，遂不解。
起初以为是账号对镜像文件的权限不够，在dockerfile中加上命令

chmod 777 -R /绝对路径

递归赋权。赋权后变成了读写权限，但是依旧镜像无法启动，报错还是找不到jar。
思来想去，同事帮我排查发现jar的大小不对，在打包过程中被篡改了，而在本地启动时，IDEA可能阻止了这一操作。在部署过程中，编译镜像时篡改了对应jar包。具体原因可能是pom文件中写了build相关操作，为了dubbo打包时候只打相关文件。

<build>
        <plugins>
            <plugin>
                <groupId>org.springframework.boot</groupId>
                <artifactId>spring-boot-maven-plugin</artifactId>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-resources-plugin</artifactId>
                <version>3.1.0</version>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <version>2.6</version>
                <executions>
                    <execution>
                        <phase>package</phase>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                        <configuration>
                            <classifier>client</classifier>
                            <includes>
                                <include>/service/*
                                /vo/*
                                /result/*
                                /exception/*
                                /enums/dubbo/*
                                /model/*
                            
                            
                                /service/impl
                            
                        
                    
                
            
        

于是找到解决办法，在src目录平级的地方新建lib目录，将jar包移到对应目录下，完美解决。

结论：
和项目代码逻辑无关的jar，还是单独和src平级放置，避免编译打包阶段出现jar篡改，如果不对比jar的大小，很难发现被篡改了。

二、还是引入第三方jar包。
在代码中http调用使用了mica第三方包装好的功能，HttpRequest，最后结果是asMap(Object.class)。引入之前，这个接收没问题，返回结果是Map,其中key1对应的value1也是HashMap。
但是当引入这个第三方jar的时候，这个asMap就有问题了，返回结果还是Map，但是key1对应的value1变成了scala中的HashMap，报了类型转换错误。
但其实在项目中并没有引入scala相关的依赖，遂用mavenHelper插件协助排查。发现kafka这个功能内部会继续依赖scala，而我们引入的第三方jar中也引入了kafka依赖，两个版本不一样，发生了冲突，scala版本也发生了冲突。
于是exclude第三方jar包中的kafka相关依赖，解决问题。
但是还是不知道为什么会影响到asMap这个方法，没有去深究。

结论：
引入第三方jar之后，如果有报错一定要检查是否有依赖冲突，合理利用mavenHelper插件，检测各种依赖。

总会有各种意想不到的bug和问题，总是在解决各种bug和问题的路上。。。。