Juergen Hoeller 的最新部落格宣佈 Spring 3.0 的第一個里程碑版本釋出。主要亮點包括添加了 REST 支援、Spring Expression Language (EL) 以及遷移到 Java 5 及更高版本。部落格文章包含詳細資訊。

下載 | Subversion | JIRA | 論壇

我很高興地宣佈 Spring Framework 3.0 M1 終於可以下載了！

此版本包含幾項重大更改，包括啟動主要的 3.0 主題，例如 EL 和 REST 支援

• 修訂的專案佈局和構建系統，採用基於模組的原始碼
• 更新了整個程式碼庫以符合Java 5 程式碼風格（泛型、可變引數）
• 更新到 JUnit 4.5 和 JRuby 1.1
• 引入了 Spring EL 解析器 (org.springframework.expression 包)
• 引入了對 bean 定義中的 #{...} 表示式的支援
• 引入了用於嵌入表示式的啟用表示式的 @Value 註解
• 在 MVC 處理器中引入了用於 URI 模板處理的 @PathVariable 註解
• 在 MVC 處理器中引入了對 @RequestParam 預設值的支援
• 在 MVC 處理器中引入了用於 HTTP 頭部訪問的 @RequestHeader 註解
• 引入了 AbstractAtomFeedView 和 AbstractRssFeedView 基類
• 引入了 <spring:url> 和 <spring:param> JSP 標籤

以及各種小的增強功能。

請注意，Spring Framework 3.0 需要 Java 5 或更高版本以及 J2EE 1.4 或更高版本。我們將以 Java 6 和 Java EE 5 作為主要平臺級別進行構建——但請放心，我們將保留對支援 Java 5 的 J2EE 1.4 伺服器的相容性，例如 WebLogic 9 和 WebSphere 6.1。

我們還刪除/棄用了一些過時的類。更多資訊…

本週在 SpringOne Americas 大會上，我們剛剛宣佈了一款名為 SpringSource tc Server 的新產品。Springsource tc Server 是一個基於 Apache Tomcat 的企業級 Web 應用伺服器。

儘管 SpringSource 不是第一家圍繞 Apache Tomcat 構建產品的公司（WebSphere Community Edition 和 JBoss 都在其 J2EE 應用伺服器中嵌入了 Tomcat 版本，JBoss Web 2.1.1 的開發者版本也嵌入了 Tomcat），但 tc Server 的獨特之處在於它保留了 Tomcat servlet/JSP 程式設計模型。為 Tomcat 編寫的應用可 100% 移植到…

親愛的 Spring 社群，

我很高興地宣佈我們已經發布了 Spring IDE 2.2.1。此版本主要是錯誤修復和維護版本，但也包含一些重要的使用者級更改。

在Spring IDE 部落格獲取更多資訊

請關注未來一週來自 SpringOne 的更多工具相關公告。

OSGi 聯盟決定透過在公共登錄檔中列出特定於供應商的 manifest 頭部來容納它們。目的是避免供應商之間以及供應商與 OSGi 自身頭部之間的衝突。

登錄檔目前包含 OSGi 自己的頭部、SpringSource dm Server 引入的頭部，以及 bnd 工具使用的兩個頭部。

引言

這是三篇系列部落格中的第二篇，描述了在 SpringSource dm Server™ 中構建和部署 GWT 應用的分步方法。第一篇部落格介紹了從示例 GWT 應用建立簡單 WAR 檔案的過程。下一篇部落格將介紹如何將我們在第 1 部分中建立的 WAR 檔案轉換為“共享庫” WAR。這意味著我們將把應用程式的 GWT 依賴項外部化到一個 OSGi bundle 中，以便任何數量的 GWT 應用程式都可以共享它。您可以將其視為透過 GWT 遠端能力擴充套件我們的 dm Server。

正如在第 1 部分中提到的，在這第二篇部落格文章中我沒有使用 Spring Framework，而是專注於使用 SpringSource dm Server™ 和 SpringSource Tool Suite 來部署“純粹的” GWT。

另請參閱第 1 部分，瞭解 GWT StockWatcher 示例的背景和我正在使用的軟體。

快速回顧

在第 1 部分中，我們從頭開始將 GWT StockWatcher 示例應用程式構建為一個 Eclipse 專案，然後將程式碼生成到一個 Dynamic Web 專案中，再將其部署到 dm Server 中。最後，我們將 Dynamic Web 專案匯出為一個 WAR 檔案，並在 STS 外部進行部署。

這裡描述的分步方法將基於我們在第 1 部分中所做的工作，而不是從頭開始。我們在第 1 部分中唯一要改變的事情是移除對以下內容的顯式依賴：gwt-servlet.jar庫。

步驟 1：將我們的 GWT 依賴項轉換為 OSGi bundle

首先，再介紹一些背景。“共享庫”方法的整體概念是使用 OSGi bundle 之間的顯式匯入和匯出在 dm Server 內建立依賴項對映。對於像我們的 StockWatcher 示例這樣的小型 WAR，這主要只是一個有趣的學術練習。然而，考慮到許多商業 Web 專案都是以大型 WAR 檔案形式交付的，其中包含了數十甚至數百個依賴的 jar 檔案，將這些依賴項分解為可共享資源不僅從佔用空間的角度來看是合理的，而且還顯著減輕了應用程式的打包、版本控制和維護的痛苦。

好訊息是，建立這些依賴項的大部分工作已經完成。 SpringSource Enterprise Bundle Repository 包含了大多數常用庫的“bundle 化”版本。然而，在撰寫本文時，我們的 GWT 依賴項就是一個需要您自己將其轉換為 bundle 的庫示例…

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

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

依賴約束不匹配

uses 衝突最常見的原因是一個或多個依賴約束之間的不匹配。舉例來說，考慮下面的三個 manifest：

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 bundle 和兩個 eclipselink bundle。顯然，這些不是真實的 bundle。spring bundle 匯入了 eclipselink 包，範圍是 [1.0, 2.0)。顯然，只有 eclipselink_1 bundle 可以滿足這個約束。現在，考慮來自兩個不同應用程式的這些 manifest：

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。如果我將這些 bundle 安裝到 Equinox 中，然後嘗試啟動應用程式 bundle，控制檯將顯示如下內容：

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 bundle 都已解析。 app1 bundle 已經啟動，但 app2 bundle 無法啟動。要找出原因，我們可以使用 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 bundle 無法解析，因為其匯入的 spring.orm.hibernate 存在包 uses 衝突。這意味著 app2 對 spring.orm.hibernate 的匯入無法滿足，因為它的其他匯入之一與可能提供 spring.orm.hibernate 的 bundle（在本例中是 spring bundle）的 uses 約束衝突。

診斷此問題的第一步是找出 spring.orm.hibernate bundle 的可能提供者。我們從我們的用例中知道唯一的可能提供者是 spring bundle，但如果您不知道提供者，可以使用 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 包是由 bundle 2 匯出的。有了這個知識，我們可以找出 bundle 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 bundle 需要範圍 [1.0, 2.0) 的 eclipselink，而 app2 需要範圍 [2.0, 2.0] 的 eclipselink——這兩個範圍是互斥的，這意味著 app2 不能連線到與 spring bundle 相同版本的 eclipselink。

在 uses 列表很長的情況下，您可以透過找出哪些列出的包有多個提供者來縮小可能的衝突範圍。要出現 uses 約束衝突，必須始終存在多個提供者。

版本不匹配不是依賴約束不匹配的唯一原因。約束可能因為屬性和版本而不匹配。

安裝順序問題

如果我們回顧前面的示例，並更改 spring bundle 的 manifest，使其能夠接受版本 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"

安裝 bundle 並啟動應用程式 bundle 顯示此更改產生了很大的影響：

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

現在兩個應用程式 bundle 都可以啟動了。不幸的是，還有一個更微妙的問題等待著我們。根據安裝順序的不同，這組 bundle 可能仍然無法一起執行。為了說明這一點，讓我們將 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 bundle 無法啟動。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 約束又回來了。按照上一節中確定的診斷步驟操作在此處將無濟於事，因為沒有依賴約束不匹配的問題——我們知道這一點，因為這些 bundle 第一次解析時一切正常。

這裡的問題是解析順序。這些 bundle 分成兩個不同的批次安裝和解析。第一批包括 spring、eclipselink_1 和 app1，第二批包括 eclipselink_2 和 app2。當第一批解析時（啟動 app1 bundle 的結果），spring bundle 透過其對 eclipselink 包的匯入連線到 eclipselink_1 bundle。這可以使用控制檯進行確認：

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 bundle 匯入的。當第二批安裝時，app2 bundle 無法解析，因為它需要版本 2.0.0 的 eclipselink，但 spring 已經連線到版本 1.0.0 的 eclipselink。當所有 bundle 作為一批安裝和解析時，OSGi 解析器將嘗試滿足所有約束，包括確保 spring.orm.hibernate 上的 uses 約束可以滿足。

要解決這個問題，我們不需要更改我們的 bundle。相反，我們可以將 bundle 作為一批重新安裝，或者我們可以針對 spring bundle 觸發重新整理——這相當於要求 OSGi 重新執行解析過程。現在 eclipselink_2 bundle 已安裝，我們可以預期這將產生不同的結果：

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 bundle 解析。 spring 中 eclipselink 包的連線已更改為由 eclipselink_2 bundle 的版本 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 自動診斷。

我很高興宣佈 Grails 自 SpringSource 收購 G2One 以來的第一個版本釋出。Grails 1.0.4 包含多項改進以及 Grails 所依賴的關鍵庫的升級，可從 Grails 下載頁面下載。更具體地說，Grails 1.0.4 包含了大約一週前釋出的最新的 Spring 2.5.6 版本。

除了這些改進之外，此版本中還有一些有趣的新功能。第一個是添加了一個功能，可以更好地支援 GORM 中 Hibernate 使用者型別定義的對映。您現在可以對映自定義使用者型別…

親愛的 Spring 社群，
我們很高興地宣佈 Spring Integration 1.0.0.RC2 現已釋出。
下載 | 參考文件 | JavaDoc

欲瞭解更多資訊，請檢視 Spring Integration 論壇中的公告，並務必訪問Spring Integration 主頁。

Mark Fisher
Spring Integration 專案負責人