記錄一次調(diào)試經(jīng)歷
起因
相同的jar，服務(wù)器正常而本地起的項(xiàng)目一直報(bào)下圖中的錯(cuò)。
解釋
首先，這段代碼是hibernate執(zhí)行有參數(shù)的hql的過(guò)程中報(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ì)象中的字段類(lèi)型是BigDcimal。猜測(cè)可能是問(wèn)題出現(xiàn)的原因，但相關(guān)的代碼沒(méi)有找到，繼續(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ì)象中的類(lèi)型，找不到采用value.getclass();
org.hibernate.impl.AbstractQueryImpl中，
中間結(jié)論
我本地沒(méi)問(wèn)題，代碼就是那么寫(xiě)的，報(bào)錯(cuò)是應(yīng)該的，那服務(wù)器是怎么跑通的？
繼續(xù)
趁早上沒(méi)人，遠(yuǎn)程調(diào)試下服務(wù)器項(xiàng)目，過(guò)程中，想到是否有人重寫(xiě)了hibernate的源碼導(dǎo)致的，搜一下，果然。。。
hibernate源碼
重寫(xiě)的代碼，修改了下，保證了對(duì)參數(shù)是string的兼容。
聯(lián)想一下，tomcat的jar包加載順序從8起發(fā)生了改變，不再像之前按照字母順序，先加載的生效。而8之后，該用別的方式，該方式導(dǎo)致不同操作系統(tǒng)結(jié)果不同，雖然兩者都用的8，而我是mac，它是linux。。。當(dāng)時(shí)看到那篇博客就覺(jué)得有坑，沒(méi)想到坑來(lái)的這么快。
至于不同操作系統(tǒng)具體的加載方式，需要看tomcat源碼，還沒(méi)看～～～
結(jié)論
由于生效的class不同，導(dǎo)致本地和服務(wù)器的結(jié)果不同，不想看源碼的話(huà)，可以先把hibernate的重復(fù)類(lèi)刪掉；應(yīng)該是可以對(duì)源碼進(jìn)行修改，比如改成按照字母順序
不得不吐槽下，tomcat改jar加載順序是為啥呢，原來(lái)的按照字母順序多么清晰明了。
好了，以上就是這篇文章的全部?jī)?nèi)容了，希望本文的內(nèi)容對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，謝謝大家對(duì)腳本之家的支持。
