一、引入了一個第三方的jar包提供的能力，需要把三個官方的jar（transmittable、aspectJ等）引入項(xiàng)目，我放在了resource目錄下，新建了一個lib。啟動時對三個jar執(zhí)行-javaagent命令。之前都沒問題。同時該項(xiàng)目的測試和預(yù)發(fā)環(huán)境鏡像也可以正常啟動，但是prod環(huán)境報錯鏡像里找不到這三個jar。在鏡像文件里對應(yīng)路徑下，又能找到三個文件名，遂不解。
起初以為是賬號對鏡像文件的權(quán)限不夠，在dockerfile中加上命令

chmod 777 -R /絕對路徑

遞歸賦權(quán)。賦權(quán)后變成了讀寫權(quán)限，但是依舊鏡像無法啟動，報錯還是找不到j(luò)ar。
思來想去，同事幫我排查發(fā)現(xiàn)jar的大小不對，在打包過程中被篡改了，而在本地啟動時，IDEA可能阻止了這一操作。在部署過程中，編譯鏡像時篡改了對應(yīng)jar包。具體原因可能是pom文件中寫了build相關(guān)操作，為了dubbo打包時候只打相關(guān)文件。

<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/*</include>
                                <include>/vo/*</include>
                                <include>/result/*</include>
                                <include>/exception/*</include>
                                <include>/enums/dubbo/*</include>
                                <include>/model/*</include>
                            </includes>
                            <excludes>
                                <exclude>/service/impl</exclude>
                            </excludes>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>

于是找到解決辦法，在src目錄平級的地方新建lib目錄，將jar包移到對應(yīng)目錄下，完美解決。

結(jié)論：
和項(xiàng)目代碼邏輯無關(guān)的jar，還是單獨(dú)和src平級放置，避免編譯打包階段出現(xiàn)jar篡改，如果不對比jar的大小，很難發(fā)現(xiàn)被篡改了。

二、還是引入第三方j(luò)ar包。
在代碼中http調(diào)用使用了mica第三方包裝好的功能，HttpRequest，最后結(jié)果是asMap(Object.class)。引入之前，這個接收沒問題，返回結(jié)果是Map<String,Object>,其中key1對應(yīng)的value1也是HashMap。
但是當(dāng)引入這個第三方j(luò)ar的時候，這個asMap就有問題了，返回結(jié)果還是Map，但是key1對應(yīng)的value1變成了scala中的HashMap，報了類型轉(zhuǎn)換錯誤。
但其實(shí)在項(xiàng)目中并沒有引入scala相關(guān)的依賴，遂用mavenHelper插件協(xié)助排查。發(fā)現(xiàn)kafka這個功能內(nèi)部會繼續(xù)依賴scala，而我們引入的第三方j(luò)ar中也引入了kafka依賴，兩個版本不一樣，發(fā)生了沖突，scala版本也發(fā)生了沖突。
于是exclude第三方j(luò)ar包中的kafka相關(guān)依賴，解決問題。
但是還是不知道為什么會影響到asMap這個方法，沒有去深究。

結(jié)論：
引入第三方j(luò)ar之后，如果有報錯一定要檢查是否有依賴沖突，合理利用mavenHelper插件，檢測各種依賴。

總會有各種意想不到的bug和問題，總是在解決各種bug和問題的路上。。。。文章來源地址http://www.zghlxwxcb.cn/news/detail-553287.html

到了這里，關(guān)于記錄兩次問題排查過程的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！