最近，我致力于在OSGi環境中使Apache Hive工作。 雖然沒有被證明是小菜一碟（軟件對嗎？。。為什么我不感到驚訝？ ），它引導我解決了各種Java和OSGi錯誤。 在這里，我列出了其中一些讓我有些吃力的東西（沒有雙關語），所以我想為了自己的滿意而在它們上面寫一個博客。

java.lang.VerifyError

在初始化OSGi服務組件之一的過程中，我感到很討厭。 由于違規捆綁軟件處于活動狀態，因此無法立即識別出罪魁禍首。 從表面上看，一切看起來都不錯，除了應該在捆綁軟件中存在的服務組件初始化期間啟動的Hive服務器未啟動并正在運行的事實。 OSGi控制臺中快速顯示“ ls”，表明服務組件處于“不滿意”狀態。 最后，一個“ comp”顯示了根本原因，即VerifyError。

如果類的運行時依賴項與編譯時使用的依賴項不同，則可能會發生VerifyError。 例如，如果方法簽名在依賴關系之間更改，則將導致此錯誤。 在已接受的答案的[1]中對此進行了很好的解釋。 事實證明，在兩個捆綁包中公開了一個軟件包的稍有不同的版本，導致Hive捆綁包在編譯環境中的版本上選擇了不同的版本。 正確的OSGi版本控制是解決方案。

java.lang.IncompatibleClassChangeError

在系統中存在兩個軟件包的類似情況下，也會出現此錯誤。 正如[2]清楚地解釋的那樣，在我的案例中，這樣做的原因是在有沖突的軟件包版本之間將接口更改為抽象類。 再次，版本控制節省了一天。

java.lang.LinkageError：xxxx中違反加載程序約束–等等……

現在，這似乎是一個著名的錯誤，特別是在OSGi環境中。 根本原因似乎是由不同的ClassLoader以某種方式進入的兩個類加載的。 例如，說A類對象接受B類對象作為方法參數。 B類由ClassLoader-A加載，該類加載器也加載A類。但是，在方法調用時，由ClassLoader-B加載的B類對象如何作為參數傳遞給已加載的A類對象通過ClassLoader-A。 現在，結果將是一個很大的LinkageError，并帶有非常冗長的錯誤消息。

OSGi中基于圖的類加載結構使其特別有利于此類錯誤。 在我的案例中，罪魁禍首是一個包裝，該包裝已被復制到兩個不同的包中，并且該包中的一個特定類由每個包的單獨的ClassLoader加載，并通過方法調用期間系統中存在的第三個包來聯系。 因此，這是在OSGi中不遵循“導入導出內容”的最佳做法[3]的情況。 這樣做將有助于減少重復的包在捆綁包中的暴露，并有助于為給定的包維護一致的類空間。 因此，這就是這種情況下的解決方案。

包使用沖突：導入包：yyy; 版本=“ xxx”

在鍛煉過程中，我經常將這種不便之處丟在臉上。 在SpringSource上有兩個關于此問題的出色文章[4]，[5]，它們提供了很多幫助。 但是，讓我總結一下我在這個問題上的學習。 簡單來說，如果捆綁包通過直接導入并通過使用約束暴露給同一軟件包的兩個版本，則會出現此錯誤。 該圖最能說明這種情況。

捆綁軟件A直接導入org.foo版本1.0.0。 但是，它也從捆綁軟件B導入捆綁軟件org.bar。但是事實證明，軟件包org.bar也使用org.foo軟件包，盡管它是與捆綁軟件A導入的版本不同的版本（2.0.0）。直接連接到org.foo的1.0.0版本，并且由于使用org.foo的2.0.0版本的org.bar的導入而暴露于org.foo的2.0.0版本。 現在，由于無法將捆綁包連接到同一軟件包的不同版本，因此使用沖突將引起冒犯的導入org.bar作為根本原因。 （例如：程序包使用沖突：導入程序包：org.bar；版本=“ 0.0.0？”）。 解決方案是更改捆綁軟件A或捆綁軟件B中的org.bar軟件包導入版本，以使兩者都指向相同的軟件包版本。 尼爾·巴特利特（Neil Bartlett）撰寫的另一篇很棒的博客可以在[6]中找到。

java.lang.UnsatisfiedLinkError

我的一個工作朋友在嘗試將另一個第三方庫納入我們的OSGi環境時遇到了這個問題。 JavaDocs繼續說這變得“如果Java虛擬機無法找到聲明為native的方法的適當的本地語言定義，則會拋出此錯誤”。 有問題的庫是一個Linux .so（動態鏈接庫）文件，在運行時捆綁ClassLoader時看不到該文件。 通過將庫資源直接包含在捆綁軟件ClassLoader中，我們能夠使其工作。 之前在TCCL（線程上下文類加載器）上設置此資源的嘗試失敗了，這使我們意識到TCCL通常不是捆綁軟件類加載器。 在Equinox OSGi環境下可以很好地閱讀TCCL，請參見[7]。

[1] http://stackoverflow.com/questions/100107/reasons-of-getting-a-java-lang-verifyerror
[2] http://stackoverflow.com/questions/1980452/what-c??auses-java-lang-incompatibleclasschangeerror
[3] http://blog.osgi.org/2007/04/importance-of-exporting-nd-importing.html [4] http://blog.springsource.org/2008/10/20/understanding-the-osgi-uses-directive/ [5] http://blog.springsource.org/2008/11/22/diagnosing-osgi-uses-conflicts/ [6] http://njbartlett.name/2011/02/09/uses-constraints.html [7] http://wiki.eclipse.org/Context 類 Loader_Enhancements

參考： 錯誤學習：來自Source Open博客的JCG合作伙伴 Buddhika Chamith的Java + OSGi 。