Glyn 在他最近的部落格文章中介紹了 OSGi “uses” 指令。在這篇部落格中，我想更深入地探討 uses 約束違規的原因，並提供一些診斷應用程式中 uses 問題的技巧。

對於大多數示例，我將使用原始的 Equinox 而不是 dm Server。原因在於 uses 約束並非 dm Server 特有，而是與所有 OSGi 使用者相關。在這篇部落格的最後，我將演示 dm Server 中內建的一些智慧約束失敗診斷。

依賴約束不匹配

uses 違規最常見的原因是一個或多個依賴約束不匹配。舉個例子，考慮下面的三個清單

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0)"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 1
Export-Package: eclipselink;version="1.0.0"

Manifest-Version: 1.0
Bundle-Name: EclipseLink 2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: eclipselink
Bundle-Version: 2
Export-Package: eclipselink;version="2.0.0"

這裡您可以看到一個 spring 捆綁包和兩個 eclipselink 捆綁包。顯然，這些不是真正的捆綁包。spring 捆綁包匯入了範圍為 [1.0, 2.0) 的 eclipselink 包。顯然，只有 eclipselink_1 捆綁包可以滿足此約束。現在，考慮來自兩個不同應用程式的這些清單

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[1.0, 1.0]"

Manifest-Version: 1.0
Bundle-Name: App2 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app2
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="[2.0, 2.0]"

這裡我們可以看到 app1 匯入了範圍 [1.0, 1.0] 的 eclipselink，app2 匯入了範圍 [2.0, 2.0] 的 eclipselink。如果我將這些捆綁包安裝到 Equinox 中，然後嘗試啟動應用程式捆綁包，控制檯會顯示類似以下內容

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
2       RESOLVED    spring_2.5.5
3       RESOLVED    eclipselink_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app1_1.0.0
6       INSTALLED   app2_1.0.0

這裡我們可以看到 spring 和 eclipselink 捆綁包都已解析。app1 捆綁包已啟動，但 app2 捆綁包無法啟動。要找出原因，我們可以使用 diag 命令

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [6]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

這裡我們可以看到 app2 捆綁包無法解析，因為它匯入的 spring.orm.hibernate 存在包 uses 衝突。這意味著 app2 中對 spring.orm.hibernate 的匯入無法滿足，因為它的其他匯入之一與可能提供 spring.orm.hibernate 的捆綁包（在本例中是 spring 捆綁包）上的 uses 約束髮生衝突。

診斷此問題的第一步是找出 spring.orm.hibernate 捆綁包的可能提供者。從我們的用例中我們知道唯一可能的提供者是 spring 捆綁包，但如果您不知道提供者，可以使用 packages 命令找到它們

osgi> packages spring.orm.hibernate
spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [2]>
  file:/Users/robharrop/dev/resdiag/uses/app1/bin [5] imports

這表明 spring.orm.hibernate 包由捆綁包 2 匯出。有了這些知識，我們可以找出捆綁包 2 中 spring.orm.hibernate 包的 uses 指令中列出的包

osgi> headers 2
Bundle headers:
 Bundle-ManifestVersion = 2
 Bundle-Name = Spring Bundle
 Bundle-SymbolicName = spring
 Bundle-Version = 2.5.5
 Export-Package = spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
 Import-Package = eclipselink;version="[1.0, 2.0)"
 Manifest-Version = 1.0

這裡我們可以看到 uses 中唯一的包是 eclipselink 包，所以它一定是罪魁禍首。確實，我們可以看到 Spring 捆綁包需要範圍為 [1.0, 2.0) 的 eclipselink，而 app2 需要範圍為 [2.0, 2.0] 的 eclipselink - 這兩個範圍是互斥的，這意味著 app2 無法與 spring 捆綁包連線到相同版本的 eclipselink。

在 uses 列表很長的情況下，您可以透過找出列出的哪些包具有多個供應商來縮小可能的違規範圍。必須始終有多個供應商才能看到 uses 約束違規。

版本不匹配並非依賴約束不匹配的唯一原因。約束可能由於屬性以及版本而不匹配。

安裝順序問題

如果我們回到之前的示例，並更改 spring 捆綁包的清單，使其能夠接受版本 2.0 的 eclipselink 包，並放寬 app1 的範圍，使其能夠接受 1.0 以上的任何版本，我們應該能夠解決這個問題

Manifest-Version: 1.0
Bundle-Name: Spring Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: spring
Bundle-Version: 2.5.5
Export-Package: spring.orm.hibernate;version="2.5.5";uses:="eclipselink"
Import-Package: eclipselink;version="[1.0, 2.0]"

Manifest-Version: 1.0
Bundle-Name: App1 Bundle
Bundle-ManifestVersion: 2
Bundle-SymbolicName: app1
Bundle-Version: 1.0.0
Import-Package: spring.orm.hibernate,eclipselink;version="1.0"

安裝捆綁包並啟動應用程式捆綁包表明這種改變產生了很大的不同

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       RESOLVED    eclipselink_2.0.0
4       ACTIVE      app1_1.0.0
5       ACTIVE      app2_1.0.0

現在兩個應用程式捆綁包都可以啟動。不幸的是，還有一個更微妙的問題等待著我們。根據安裝順序，這組捆綁包可能仍然無法一起執行。為了說明這一點，讓我們將 spring、eclipselink_1 和 app1 作為一次事務安裝，並啟動 app1

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0

現在，讓我們安裝 eclipselink_2 和 app2

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       INSTALLED   app2_1.0.0

app2 捆綁包無法啟動。diag 的輸出告訴我們原因

osgi> diag app2
file:/Users/robharrop/dev/resdiag/uses/app2/bin [5]
  Package uses conflict: Import-Package: spring.orm.hibernate; version="0.0.0"

uses 約束又回來了。執行上一節中確定的診斷步驟將無濟於事，因為沒有依賴約束不匹配——我們知道這一點，因為第一次這些捆綁包解析得很好。

這裡的問題是解析順序。捆綁包分兩個不同的塊安裝和解析。第一個塊包括 spring、eclipselink_1 和 app1，第二個塊包括 eclipselink_2 和 app2。當第一個塊被解析（由於啟動 app1 捆綁包）時，spring 捆綁包會將其對 eclipselink 包的匯入連線到 eclipselink_1 捆綁包。這可以透過控制檯確認

osgi> bundle app1
file:/Users/robharrop/dev/resdiag/uses/app1/bin [3]
  Id=3, Status=ACTIVE      Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/3/data
  No registered services.
  No services in use.
  No exported packages
  Imported packages
    spring.orm.hibernate; version="2.5.5"<file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]>
    eclipselink; version="1.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink1/bin [2]>
  No fragment bundles
  Named class space
    app1; bundle-version="1.0.0"[provided]
  No required bundles

請注意，匯入的包部分顯示 eclipselink 版本 1.0.0 是從 eclipselink_1 捆綁包匯入的。當第二個塊安裝時，app2 捆綁包無法解析，因為它需要版本 2.0.0 的 eclipselink，但 spring 已經連線到版本 1.0.0 的 eclipselink。當所有捆綁包作為一個塊安裝和解析時，OSGi 解析器將嘗試滿足所有約束，包括確保 spring.orm.hibernate 上的 uses 約束能夠滿足。

要解決此問題，我們無需更改我們的捆綁包。相反，我們可以將捆綁包重新安裝到一個塊中，或者我們可以觸發對 spring 捆綁包的重新整理——實際上是要求 OSGi 重新執行解析過程。現在 eclipselink_2 捆綁包已安裝，我們可以預期會有不同的結果

osgi> refresh spring

osgi> ss

Framework is launched.

id      State       Bundle
0       ACTIVE      org.eclipse.osgi_3.4.0.v20080605-1900
1       RESOLVED    spring_2.5.5
2       RESOLVED    eclipselink_1.0.0
3       ACTIVE      app1_1.0.0
4       RESOLVED    eclipselink_2.0.0
5       ACTIVE      app2_1.0.0

osgi> bundle spring
file:/Users/robharrop/dev/resdiag/uses/spring/bin [1]
  Id=1, Status=RESOLVED    Data Root=/opt/springsource-dm-server-1.0.0.RELEASE/lib/configuration/org.eclipse.osgi/bundles/1/data
  No registered services.
  No services in use.
  Exported packages
    spring.orm.hibernate; version="2.5.5"[exported]
  Imported packages
    eclipselink; version="2.0.0"<file:/Users/robharrop/dev/resdiag/uses/eclipselink2/bin [4]>
  No fragment bundles
  Named class space
    spring; bundle-version="2.5.5"[provided]
  No required bundles

請注意，重新整理 spring 導致 app2 捆綁包解析。spring 中 eclipselink 包的連線已更改，由 eclipselink_2 捆綁包中版本 2.0.0 的匯出滿足。

dm Server 中的 Uses 約束

當您在 dm Server 中遇到 uses 約束違規時，我們已經嘗試為您執行一些分析步驟，特別是識別可能不匹配的依賴約束

Could not satisfy constraints for bundle 'app2' at version '1.0.0'.
 Cannot resolve: app2
  Resolver report:
    Bundle: app2_1.0.0 - Uses Conflict: Import-Package: spring.orm.hibernate; version="0.0.0"
      Possible Supplier: spring_2.5.5 - Export-Package: spring.orm.hibernate; version="2.5.5"
        Possible Conflicts: eclipselink

Uses 約束在企業庫中很常見，手動診斷失敗可能是一個真正的噩夢。特別是，當匯出的包在其 uses 子句中列出 10 個或更多包時，確定可能的衝突可能非常耗時。因此，自動化診斷是必須的，我希望不斷改進 dm Server 中的診斷程式碼，以便處理常見錯誤變得微不足道。

在下一個版本中，我們計劃將診斷工具直接內建到我們的 dm Server Eclipse 工具中，這樣大部分問題將由 dm Server 自動診斷。

我很高興地宣佈，這是自SpringSource收購G2One以來，Grails的首個釋出。Grails 1.0.4包含一系列改進以及底層Grails關鍵庫的升級，可從Grails下載頁面下載。更具體地說，Grails 1.0.4集成了大約一週前釋出的最新的Spring 2.5.6版本。

除了這些改進之外，本次釋出還有幾個有趣的新特性。首先是增加了一個更好地支援GORM中Hibernate使用者型別定義的對映的特性。您現在可以對映自定義使用者型別……

我很高興地宣佈，SpringSource已收購G2One，該公司是Grails和Groovy的幕後推手。

為什麼？

Grails與Spring和SpringSource技術非常契合。Grails建立在Spring之上。它提供了另一種採用Spring的方式，Spring是企業Java的事實標準組件模型。Spring（和Java）的所有強大功能都隱藏在每個基於Grails的應用程式的表面之下——這是Grails能夠擴充套件到企業級應用的關鍵原因，也是對Spring強大和靈活性的驗證。

與Spring一樣，Grails是一項簡化開發者生活並提高其生產力的技術。正如我們新的標語對抗Java複雜性的武器所反映的，簡化一直是我們作為公司和技術人員的核心。

介紹

1. 使用 SpringSource Tool Suite 從頭開始構建並以 WAR 檔案形式將 GWT StockWatcher 示例應用程式部署到 dm Server 中。
2. 使用 “共享庫” 方法部署：如何從 WAR 中移除 GWT 依賴項並將其作為 OSGi 捆綁包部署到 dm Server 中。
3. 使用 “共享服務” 方法部署：我們將單個 WAR 檔案轉換為 OSGi 服務，這些服務可以被其他應用程式共享並熱插拔。

背景

這篇部落格假設您已安裝 SpringSource Tool Suite 1.1.1（我使用的是 Eclipse 3.4 版本）、  dm Server 1.0.0 和 GWT 1.5。它還假設您對 Java 程式設計有很好的理解，並且對 Javascript 和 Ajax 有基本的瞭解。

為了演示中使用的路徑，我在/Users/bcorrie/gwt/workspace建立了一個新的 Eclipse 工作區。我已在下方包含了可以下載的壓縮專案，其中包含一個我定義的GWT_ROOT_INSTALL變數。要使用我的專案，當您匯入它們時，請導航到“Preferences”->“Java”->“Build Path”->“Classpath Variables”並定義您自己的GWT_ROOT_INSTALL…

不是11月4日的奧巴馬/麥凱恩對決。正如您可能在SD Times上讀到的那樣，SpringSource已與SAP、愛立信、諾基亞、飛利浦和IBM一同當選Java SE/EE JCP執行委員會。我將是SpringSource的代表。

這並不是說JCP的規模能與總統競選相提並論。但這對於SpringSource來說是一個重要的時刻，它反映了SpringSource團隊在企業Java領域多年來的辛勤工作和領導力。更重要的是，我相信我們的當選將有助於我們使Java更加強大。

從第一本書到……

更新於 2008 年 10 月 28 日：添加了最新的示例連結和第三個示例連結

昨晚，我在費城 Spring 使用者組發表了“SpringSource dm Server 簡介”演講。在這次演講中，我建立了一個名為 GreenPages 的小型應用程式，展示了 dm Server 的所有主要方面。我向與會者承諾，我將在此處釋出該應用程式和幻燈片。

在 dm Server GA 版釋出後的幾周裡，許多人都在詢問如何最好地開始使用 dm Server，所以我用這篇文章來收集所有相關資訊……

在本文中，我們概述了Spring Batch 2.0的主要主題，並重點介紹了與1.x版本的變化。新版本的開發工作正在順利進行，上週釋出了M2版本，並且我們獲得了大量關注，因此現在似乎是提供一些指標的好時機。

Spring Batch 2.0 主題

新版本的四個主要主題是

• Java 5和Spring 3.0
• 非順序執行
• 可伸縮性
• 配置：註解和XML名稱空間

Spring Batch 2.0.0.M2的專案物理佈局沒有任何變化（相同的舊下載，相同的Java包基本佈局）。我們沒有刪除任何功能，但我們藉此機會修改了幾個API，並且有一些小的更改……

如果您為SpringSource dm Server或任何其他OSGi平臺構建應用程式，您遲早會遇到“uses”指令。除非您清楚地理解該指令的目的，否則您將不知道何時編寫它，並且當某個bundle由於“uses”衝突而無法解析時，您將只能猜測。本文應讓您全面瞭解“uses”指令，何時使用它，以及如何除錯“uses”衝突。

Bundle解析

OSGi的設計使得一旦bundle被“解析”，您通常不應該遇到由於型別……導致的類轉換異常以及類似問題。

幾周前，Filip Hanik 和我舉辦了“最佳化和調整 Apache Tomcat”系列網路研討會的第二部分。您可以透過 SpringSource 網站的網路研討會部分獲取網路研討會的錄音和幻燈片副本。同一頁面上還有所有以前的 SpringSource 網路研討會的連結，以及 Covalent 網路研討會存檔。

我們無法在問答環節中回答所有問題，所以，正如承諾的那樣，以下是剩餘問題和我們的答案。

• 如何識別 Tomcat 應用程式中的記憶體洩漏？

  您幾乎肯定需要使用分析器來識別記憶體洩漏的根本原因。最新的 Sun JDK 包含 jhat 和 jmap 等工具。還有許多其他分析器可用，包括免費和商業的。Filip 和我在調查 Tomcat 記憶體洩漏時使用 YourKit，因為 YourKit 為開源開發者提供免費許可證。

• 重新部署如何導致記憶體洩漏？

  這通常發生在 Tomcat 載入的類保留對 Web 應用程式載入的類的引用時。當 Web 應用程式停止時，Tomcat 類載入器繼續保留對 Web 應用程式載入的類的引用。這個類保留對 Web 應用程式的類載入器的引用，而 Web 應用程式的類載入器又保留對其載入的所有類的引用。因此，Web 應用程式類載入器及其載入的所有類都不符合垃圾回收的條件。這會導致記憶體洩漏。典型的根本原因是 JDBC 驅動程式和日誌框架。

• 更改 Tomcat 使用的 JVM 的最佳方法是什麼？

  要使用的 JVM 透過 JAVA_HOME（完整 JDK）或 JRE_HOME（僅 JRE）環境變數設定。設定它的正確位置將取決於您的環境，特別是如果 Tomcat 配置為在系統啟動時自動啟動。如果您可以自由選擇設定位置，則根據您的作業系統使用 setenv.bat 或 setenv.sh。

• 您推薦特定的 JVM 嗎？

  不，我們不推薦。您選擇的 JVM 供應商取決於您的作業系統。

• 我應該使用哪個聯結器將 Apache httpd 連線到 Tomcat？

  我們推薦 mod_proxy_http，mod_jk 緊隨其後。通常，mod_proxy_ajp 不如 mod_proxy_http 或 mod_jk 穩定。請注意，mod_jk2 已被棄用，不應再使用。

• 使用 SSL 時，maxKeepAliveRequests 的正確設定是什麼？

  使用 SSL 時，應啟用 HTTP keep alive，因為 SSL 握手對於每個請求來說都是一個相對昂貴的操作。

• 如果我們在 Solaris 上執行 Tomcat，您是否不建議使用本機 APR 聯結器？

  是的，我們不建議。我們從客戶那裡收到的反饋是 APR 聯結器在 Solaris 上不穩定。

• 我們之前嘗試在 Solaris 上遷移到 mod_proxy_http，但遇到了幾個錯誤。這些錯誤是否已解決？

  在不知道確切的錯誤或您使用的版本的情況下，很難發表評論。所有已知的 Apache httpd 問題和當前狀態都可以在 ASF Bugzilla 資料庫中找到。Tomcat 問題也可以在 Bugzilla 中找到。

• 對於預設的阻塞 IO HTTP 聯結器，maxKeepAliveRequests 應該使用什麼值？

  對於高併發環境，將其設定為 1。否則，將其設定為您頁面上的平均物件數，介於 10 到 100 之間。

• 如何配置 JkOptions +DisableReuse？

  JkOptions +DisableReuse 應放置在您的 httpd.conf 檔案中，與其他 mod_jk 設定一起。

• 何時最適合使用非阻塞 IO HTTP 聯結器？

  當您需要支援高併發且保持活動狀態，並且 APR 不可用時，例如，因為它在您的平臺上不穩定。

• 如果我在 Apache Tomcat 前面使用 Apache httpd，效能會更好嗎？

  這取決於。如果您將所有請求代理到 Tomcat，那麼效能會略有下降。如果 httpd 處理一些請求（例如所有靜態內容），那麼您可能會看到一些好處。有許多基準測試試圖證明一個聯結器比另一個聯結器更好。但是，這些基準測試都不太可能代表您的應用程式。唯一確定的方法是在您的環境中，使用真實的負載和使用模式進行測試。

• Tomcat 可以在沒有 Web 伺服器的情況下投入生產使用嗎？

  是的。這是否能為您的環境提供最佳效能將取決於該環境和您的應用程式。與上一個問題一樣，唯一確定的方法是在您的環境中，使用真實的負載和使用模式進行測試。

• 在 Tomcat 前面使用 Apache httpd 會增加安全性嗎？

  您的安裝安全性將取決於許多因素。使用或不使用 Apache httpd 不太可能顯著改變您的安裝安全性。其他因素，例如及時更新補丁和使用防火牆，通常對您的整體安全性水平影響更大。

• 哪個 Apache httpd MPM 提供最佳效能？

  一如既往，這將取決於您的環境，但 httpd 效能調優文件提供了一些有用的通用指南。

• SpringSource ERS 和 Apache Tomcat 之間的效能差異是什麼？

  SpringSource ERS 不僅僅是 Apache Tomcat。從純粹的 Tomcat 角度來看，效能不是差異化因素。ERS 的優勢在於簡單的安裝、易於管理的升級和修補、對多個例項的支援以及所有元件的整合。

• 我的公司使用 Tomcat 和 XYZ 應用程式伺服器。Tomcat 與 XYZ 應用程式伺服器相比如何，以及合併是否有好處？

  會有很多差異，而且重要的差異會因組織而異。首先確定您希望從應用程式伺服器中獲得什麼，然後將該列表與市場進行比較。合併是有好處的。更大的一致性意味著更簡單的維護、更少的培訓等等。但是，也有成本。您需要檢視您的組織及其計劃如何合併（僅新專案、下一次主要釋出的所有專案、現在所有專案等）以比較成本與相關收益。

• 您有 Tomcat 和 XYZ 應用程式伺服器的效能比較資料嗎？

  該領域已釋出各種報告。結果的有用性取決於測試與您的負載匹配的程度。一如既往，唯一確定的方法是在您的環境中，使用真實的負載和使用模式進行測試。

• 負載測試 Tomcat 伺服器的好方法是什麼？

  有多種工具可用於驅動負載，包括免費和商業的。免費工具包括 ab 和 JMeter。

• 為了高可用性和效能，Tomcat 可以配置為為同一個 Web 應用程式啟動多個 JVM 嗎？

  Tomcat 不提供此配置選項。當然，您可以建立多個 Tomcat 例項，在每個例項上安裝您的應用程式，然後跨例項進行負載均衡。

• 有通用的 Tomcat 健康檢查指令碼嗎？

  管理器狀態頁面可能是一個很好的起點。如果需要，您可以使用該 Servlet 的程式碼作為您自己更具體/更廣泛檢查的基礎。如果您確實進行了增強，請考慮將您的增強貢獻回 Apache Tomcat 社群。

• logging.properties 檔案位於何處？

  預設位置是 $CATALINA_BASE/conf。