溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
記錄一次調試經歷
起因
相同的jar，服務器正常而本地起的項目一直報下圖中的錯。
解釋
首先，這段代碼是hibernate執行有參數的hql的過程中報錯的，最上面那層，對string進行強轉導致的。
看hql及java對象，發現，參數為string，而參數對應的java對象中的字段類型是BigDcimal。猜測可能是問題出現的原因，但相關的代碼沒有找到，繼續看代碼、調試
堆棧信息中 bind()方法的作用（和報錯有關的），從 中獲取type和value，對value進行強轉，其中type是在設置參數階段設置的，如下圖，先根據映射關系找對應的java對象中的類型，找不到采用value.getclass();
org.hibernate.impl.AbstractQueryImpl中，
中間結論
我本地沒問題，代碼就是那么寫的，報錯是應該的，那服務器是怎么跑通的？
繼續
趁早上沒人，遠程調試下服務器項目，過程中，想到是否有人重寫了hibernate的源碼導致的，搜一下，果然。。。
hibernate源碼
重寫的代碼，修改了下，保證了對參數是string的兼容。
聯想一下，tomcat的jar包加載順序從8起發生了改變，不再像之前按照字母順序，先加載的生效。而8之后，該用別的方式，該方式導致不同操作系統結果不同，雖然兩者都用的8，而我是mac，它是linux。。。當時看到那篇博客就覺得有坑，沒想到坑來的這么快。
至于不同操作系統具體的加載方式，需要看tomcat源碼，還沒看～～～
結論
由于生效的class不同，導致本地和服務器的結果不同，不想看源碼的話，可以先把hibernate的重復類刪掉；應該是可以對源碼進行修改，比如改成按照字母順序
不得不吐槽下，tomcat改jar加載順序是為啥呢，原來的按照字母順序多么清晰明了。
好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
