bundle的解析過程就是對bundle的mf檔案進行分析,根據配置的依賴關係構造依賴模型。
(原始碼見:resolverimpl.resolvebundles0)
假設有2個bundle,import/export分別是:
bundlea:import pkg.b; export pkg.a; bundleb:import pkg.a; export pkg.b;也就是2個bundle相互依賴
解析步驟(主要部分):
1、假設首先對bundlea解析,先獲取bundlea的所有imports,然後迭代每個import找到匹配的export,並設定import和export的依賴引用關係。
// 設定了依賴引用關係後就知道import是由哪個bundle匯出
export.getexporter().addref(imp.getbundle());
imp.addpossiblesupplier(export); // 找到pkg.b的乙個可能的提供者為bundleb匯出的pkg.b
但是,如果自己也export了相同的包,則會被捨棄,會採用它依賴的export。因此,如果乙個bundle import了乙個同名的包(自己bundle也有,而且不管有沒有export),則永遠不會找到自己包下的類(根據類查詢規則,會在依賴的export下尋找)。也就是說,bundle中包命名一定要注意不要同名。
2、如果export所在的bundle不是已解析(resolved)的,這裡的bundleb還沒有解析,則開始解析bundleb,同步驟1。
當在解析bundleb的import pkg.a時,發現bundlea還不是已解析(resolved)的(正在解析中resolving),又對bundlea進行解析,同步驟1。
但是,當解析到import pkg.b時,發現它已經有提供者了(前面已經找到了匹配的export),就把該bundlea新增到依賴迴圈列表中。
這裡,bundlea解析結束(沒有其他未解析的import了)返回,但狀態還是resolving。接著,發現import pkg.a的提供者bundlea為resolving,又把該bundleb新增到依賴迴圈列表中。
這裡,bundleb解析結束(沒有其他未解析的import了)返回,但狀態還是resolving。
3、迴圈依賴處理
對解析bundlea涉及的依賴環列表進行依賴檢查,如果裡面所有bundle都能正確的找到依賴,則設定它們的狀態為已解析(resolved)。
version:表示bundle或者package的版本物件。對應的還有個versionrange,表示版本範圍。
versionsupplier:版本提供者基類,表示乙個特定版本的bundle或者package(系統可以同時存在多個版本的bundle或者package)。
該物件用來儲存系統所有解析的的exports、bundles和generics(在resolverimpl中實現)。
對於多個版本的情況,是如何處理的呢?實現了comparator介面,在compare中處理排序邏輯,原始碼如下:
// compares two versionsuppliers for descending ordered sorts.
// the versionsuppliers are sorted by the following priorities
// first the resolution status of the supplying bundle.
// second is the supplier version.
// third is the bundle id of the supplying bundle.
public int compare(object o1, object o2)
basedescription:對乙個狀態的基本描述,所有的描述物件都有乙個名稱和版本。
versionconstraint:表示2個bundle(就require bundle而言)或乙個bundle和乙個package之間的關係(就import/export而言)。
方法issatisfiedby(basedescription supplier)用來判斷約束是否滿足。
resolverconstraint:versionconstraint輔助類。
groupingchecker:檢查匯出包「uses」指令的一致性。 這是乙個比較耗時的操作。
Fabric 原始碼解析 原始碼目錄解析
這裡對重要的一些目錄進行說明 bccsp 與密碼學 加密 簽名 證書等等 相關的加密服務 將fabric中用到的密碼學相關的函式抽象成了一組介面,便於拓展。bddtests 一種新型的軟體開發模式 行為驅動開 需求 開發 common 一些公共庫 錯誤處理 日誌處理 賬本儲存 策略以及各種工具等等 ...
Spring原始碼解析之 Aop原始碼解析(2)
spring aop 更多的是oop開發模式的乙個補充,幫助oop以更好的方式來解決對於需要解決業務功能模組之上統一管理 的功能 以一副圖來做為aop功能的說明更直觀些。對於類似系統的安全檢查,系統日誌,事務管理等相關功能,物件導向的開發方法並沒有更好的解決方法 aop引入了一些概念。更多的是spr...
Integer原始碼解析
public class test else integer i3 200 integer i4 200 if i3 i4 else 結果為 原因integer 類會快取 128 到 127 之間的整數 但是如果new interger的話就是不同的物件了 源 分析 如果是在 128到正的127之間...