tomcat8改了jar加載順序的踩坑記錄

記錄一次調(diào)試經(jīng)歷

起因

相同的jar，服務(wù)器正常而本地起的項(xiàng)目一直報(bào)下圖中的錯(cuò)。

解釋

首先，這段代碼是hibernate執(zhí)行有參數(shù)的hql的過程中報(bào)錯(cuò)的，最上面那層，對(duì)string進(jìn)行強(qiáng)轉(zhuǎn)導(dǎo)致的。

看hql及java對(duì)象，發(fā)現(xiàn)，參數(shù)為string，而參數(shù)對(duì)應(yīng)的java對(duì)象中的字段類型是BigDcimal。猜測(cè)可能是問題出現(xiàn)的原因，但相關(guān)的代碼沒有找到，繼續(xù)看代碼、調(diào)試

堆棧信息中 bind()方法的作用（和報(bào)錯(cuò)有關(guān)的），從 中獲取type和value，對(duì)value進(jìn)行強(qiáng)轉(zhuǎn)，其中type是在設(shè)置參數(shù)階段設(shè)置的，如下圖，先根據(jù)映射關(guān)系找對(duì)應(yīng)的java對(duì)象中的類型，找不到采用value.getclass();

org.hibernate.impl.AbstractQueryImpl中，

中間結(jié)論

我本地沒問題，代碼就是那么寫的，報(bào)錯(cuò)是應(yīng)該的，那服務(wù)器是怎么跑通的？

繼續(xù)

趁早上沒人，遠(yuǎn)程調(diào)試下服務(wù)器項(xiàng)目，過程中，想到是否有人重寫了hibernate的源碼導(dǎo)致的，搜一下，果然。。。

hibernate源碼

重寫的代碼，修改了下，保證了對(duì)參數(shù)是string的兼容。

聯(lián)想一下，tomcat的jar包加載順序從8起發(fā)生了改變，不再像之前按照字母順序，先加載的生效。而8之后，該用別的方式，該方式導(dǎo)致不同操作系統(tǒng)結(jié)果不同，雖然兩者都用的8，而我是mac，它是linux。。。當(dāng)時(shí)看到那篇博客就覺得有坑，沒想到坑來的這么快。

至于不同操作系統(tǒng)具體的加載方式，需要看tomcat源碼，還沒看～～～

結(jié)論

由于生效的class不同，導(dǎo)致本地和服務(wù)器的結(jié)果不同，不想看源碼的話，可以先把hibernate的重復(fù)類刪掉；應(yīng)該是可以對(duì)源碼進(jìn)行修改，比如改成按照字母順序

不得不吐槽下，tomcat改jar加載順序是為啥呢，原來的按照字母順序多么清晰明了。

好了，以上就是這篇文章的全部內(nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)億速云的支持。