通過錯誤堆疊資訊和原始碼分析錯誤來源
本文副標題:解決 NoSuchMethodError 異常
java.lang.NoSuchMethodError: org.slf4j.MDC.getCopyOfContextMap()Ljava/util/Map
-------------------------------------------------------
今天在一臺機器上配置完 spring-activemq 後,可以無障礙的執行測試程式碼。但是,完全相同的程式碼提交後在另一臺機器死活跑不通。主要的錯誤堆疊資訊如下
Caused by: java.lang.NoSuchMethodError: org.slf4j.MDC.getCopyOfContextMap()Ljava/util/Map;
at org.apache.activemq.util.MDCHelper.getCopyOfContextMap(MDCHelper.java:30)
at org.apache.activemq.thread.PooledTaskRunner.<init>(PooledTaskRunner.java:42)
Java.lang.NoSuchMethodError 的 javadoc 註釋如下:
/**
* Thrown if an application tries to call a specified method of a
* class (either static or instance), and that class no longer has a
* definition of that method.
* <p>
* Normally, this error is caught by the compiler; this error can
* only occur at run time if the definition of a class has
* incompatibly changed.
*
* @author unascribed
* @version %I%, %G%
* @since JDK1.0
*/
通過註釋( this error can only occur at run time if the definition of a class has incompatibly changed. )可以初步推斷是因為版本不相容導致的。
NOTE: 錯誤資訊裡方法名後的 Ljava/util/Map 代表的是該方法的返回值型別。
再結合所缺失方法(org.slf4j.MDC.getCopyOfContextMap)的 Javadoc:
/**
* Return a copy of the current thread's context map, with keys and values of
* type String. Returned value may be null.
*
* @return A copy of the current thread's context map. May be null.
* @since 1.5.1
*/
public static Map getCopyOfContextMap() {
從 @since 1.5.1 可以看出,該方法需要高於1.5.1 的 slf4j 版本。
在工程 pom 下檢視所依賴的 slf4j 版本發現所使用的是 1.5.11,從版本看是沒有問題的。那麼錯誤究竟從哪兒來的?從同事那裡知道之前碰到過這個問題,當時解決的方法是將 JBoss 的版本從5.0.0換到了5.1.0。試了一下,用這個辦法確實可以解決問題。但是,我並不滿足於只是解決了問題,如果只是這樣,那麼前面的分析都白費了。
我想驗證的是:Jboss 5.0.0 依賴的 sfl4j 版本是1.5.1之前的,而jboss 5.1.0 依賴的是slf4j 1.5.1之後的某個版本。經過一翻對比,確實證實了這個猜測。以下來自 jboss 根目錄下的 jar-versions.xml :
jboss 5.0.0 用的 slf4j 是 1.5.0
<jar name="slf4j-api.jar" specVersion="5.0.0.GA" specVendor="JBoss (http://www.jboss.org/)" specTitle="JBoss" implVersion="1.5.0" implVendor="JBoss Inc." implTitle="slf4j-api" implVendorID="http://www.jboss.org/" implURL="http://www.jboss.org/" sealed="false" md5Digest="d0841573796aa6b6dcf311e7e8f07a95"/>
jboss 5.1.0 用的 slf4j 是 1.5.6
<jar name="slf4j-api.jar" specVersion="5.1.0.GA" specVendor="JBoss (http://www.jboss.org/)" specTitle="JBoss" implVersion="1.5.6" implVendor="JBoss Inc." implTitle="slf4j-api" implVendorID="http://www.jboss.org/" implURL="http://www.jboss.org/" sealed="false" md5Digest="63720afbf77db737e305c85388302650"/>
通過這次的分析也可以看出,工程中依賴的 jar 包如果跟 jboss 自身依賴的 jar 版本衝突,會優先使用 jboss 的 jar。
最後,這個案例帶給我的最大收穫是通過錯誤堆疊資訊以及原始碼可以更快的分析出錯誤的來源。
相關文章
- Go 錯誤堆疊資訊之 CockroachDB errors 庫GoError
- Laravel/Lumen 自定義錯誤日誌格式過濾堆疊資訊Laravel
- StackOverflowError堆疊溢位錯誤Error
- 使用Error Stack跟蹤Oracle錯誤堆疊資訊ErrorOracle
- 利用Decorator和SourceMap優化JavaScript錯誤堆疊優化JavaScript
- 深入理解 JavaScript 錯誤和堆疊追蹤JavaScript
- JavaScript 錯誤處理和堆疊追蹤淺析JavaScript
- 【原創】mysql 錯誤緩衝堆疊薦MySql
- 如何優雅地檢視 JS 錯誤堆疊?JS
- Laravel Excpetions(錯誤處理) 原始碼分析Laravel原始碼
- thinkphp console 命令列列印錯誤呼叫堆疊PHP命令列
- JavaScript錯誤資訊JavaScript
- 錯誤處理:如何通過 error、deferred、panic 等處理錯誤?Error
- 執行指令碼寫入中間表錯誤返回錯誤資訊指令碼
- exp/imp出現錯誤通過expdp/impdp來解決
- 通過錯誤的sql來測試推理sql的解析過程SQL
- 記錄一次根據錯誤資訊無法定位錯誤的錯誤
- mysql 原始碼安裝過程中錯誤總結MySql原始碼
- 通過錯誤的sql來測試推理sql的解析過程(二)SQL
- IIS 錯誤程式碼分析手冊
- HTTP錯誤提示資訊表HTTP
- thinkphp原始碼分析(四)—錯誤及異常處理篇PHP原始碼
- 監控Java層和JNI Native層Crash,分析.so庫報錯的堆疊資訊Java
- Promise基礎(消化錯誤和丟擲錯誤)Promise
- android 解碼混淆過的堆疊資訊Android
- 通過觸發器尋找密碼錯誤使用者觸發器密碼
- Nginx常見錯誤程式碼總結和分析方法Nginx
- 一個備庫中ORA錯誤資訊的分析
- 通過ORA錯誤反思sql語句規範SQL
- 錯誤和異常 (一):錯誤基礎知識
- 這些錯誤你都犯過嗎?來看看9大XMind初學者常見錯誤!
- MySQL 跳過同步錯誤MySql
- 異常錯誤資訊處理
- jdon框架日誌資訊錯誤框架
- VBScript 錯誤資訊一覽 (轉)
- MySQL 錯誤程式碼MySql
- Windows 錯誤程式碼Windows
- MySQL error 錯 誤 碼MySqlError