親愛的Spring社群，

我們很高興地宣佈 Spring Web Flow 2 正式上市。 下載 | 文件

Spring Web Flow 是 Spring Portfolio 中專注於提供構建和執行富 Web 應用程式的基礎設施的專案。作為 Spring 專案，Web Flow 基於 Spring Web MVC 框架提供：

• 用於定義可重用控制器模組的特定領域語言，稱為 flows
• 用於管理對話狀態的高階控制器引擎
• 用於使用 Ajax 構建富使用者介面的一流支援
• 用於結合 Spring 使用 JavaServerFaces 的一流支援

Web Flow 2 發行版的模組及其與 Spring Framework 的關係如下所示：

Web Flow 2 的內容

Spring Web MVC

Spring Web MVC 框架是 Spring Framework 發行版的模組，它使用經過驗證的模型檢視控制器（MVC）範例為使用 Spring 開發 Web 應用程式提供了基礎。Web Flow 發行版的每個模組都建立在這個基礎上。

Spring Web Flow

Web Flow 模組是 MVC 的擴充套件，允許您使用 特定領域語言 定義控制器。這種語言旨在模擬需要多次伺服器請求才能完成的使用者互動，或者可以從不同上下文呼叫。

Spring JavaScript

Spring JavaScript 是一個 JavaScript 抽象框架，可以輕鬆編寫非侵入性 JavaScript，以逐步增強網頁的行為。該框架包含一個公共 JavaScript API 以及一個基於 Dojo Toolkit 的實現。Spring.js 旨在簡化常見企業場景中 Dojo 的使用，同時保留其在高階用例中的全部功能。

Spring JavaScript 可以與任何伺服器端框架協同工作。Web Flow 2 發行版包括 Spring JavaScript 和 Spring Web MVC 之間方便的整合，用於處理 Ajax 請求。

Spring Faces

Spring Faces 模組包含 Spring 對 JavaServerFaces 的支援。這種支援允許您在熟悉的 Spring MVC 和 Web Flow Controller 環境中使用 JSF 作為檢視技術。透過這種架構方法，您可以結合 JSF UI 元件模型的優勢和 Web MVC 架構的優勢。Spring Faces 還包含一個基於 Spring JavaScript 的輕量級元件庫，用於以漸進的方式宣告式地啟用 Ajax 和客戶端驗證行為。

Web Flow 2 發行版的主題

除了引入新的 Spring Faces 和 Spring Javascript 模組外，Web Flow 2 發行版還解決了兩個主要主題：整合和簡潔性。

整合

在所有模組中，Web Flow 2 發行版都增加了許多有趣的整合，讓您可以豐富您的 Web 應用程式。這些整合支援：

• 使用 Spring Security 以宣告式的方式保護您的 flows
• 使用 Tiles 進行 JSP 頁面組合和 Ajax 部分渲染
• 在使用 JSF 時，使用 Facelets 進行頁面組合和佈局
• 在使用 JSF 時，使用 Apache Trindad 和 JBoss RichFaces 元件庫
• 以漸進且非侵入性的方式使用 Dojo 部件系統；如果客戶端沒有 JavaScript，則會優雅降級。

簡潔性

Web Flow 2 中的 flow 定義語言得到了極大的簡化，同時整體功能也更加強大。這些簡化包括：

• 與版本 1 的 flow 定義相比，版本 2 的 flow 定義的程式碼行數總體減少了約 50%（示例：版本 2 對比 版本 1）
• 使用表示式語言（EL）呼叫操作的簡潔語法，支援 Unified EL 和 OGNL
• 宣告式的模型繫結和驗證，支援約定優於配置
• 透過 flow 定義繼承，在 flow 和 state 級別上支援重用
• 增強的模組化，允許將 flow 及其依賴資源打包成一個獨立的單元

釋出說明

• Web Flow 2 需要 Java 1.4 或更高版本，並在所有主流 Java EE 平臺（包括 Tomcat、Jetty、Websphere、WebLogic 和 JBoss）上執行。

• Web Flow 2 需要 Spring Framework 2.5.4 或更高版本。

• Web Flow 2 已獲得 SpringSource 的“Platform Ready”認證，適合在 OSGi 啟用的 Web 應用程式中運行於 SpringSource dm Server。

入門

• 要開始使用 Web Flow，請 下載發行版 並 試用參考應用程式。在進行過程中，請參考 文件 以熟悉功能集。

• 要開始使用 Maven 或 Ant+Ivy 等構建系統，請從 Maven Central Repository 訪問 Web Flow 構件。

• 要在 SpringSource Application Platform 上的 OSGi 環境中使用 Web Flow，請 下載平臺 並從 SpringSource Enterprise Bundle Repository 獲取 Web Flow 捆綁包。

其他社群資源

• 閱讀 SpringSource 的 Keith Donald 和 Jeremy Grelle 的 訪談，詳細瞭解 Web Flow 2 發行版的新特性。

• 觀看 Ajaxian.com 的 訪談，其中與 Dion Almaer 討論了發行版和 Spring JavaScript。

• 在 Spring Community Forums 上參與 Web Flow 2 社群。

• 線上探索 Spring Web 參考應用程式。 Spring Travel 應用程式展示了整合的 Web Flow 2 功能集，幷包含在發行版中。 SpringSource Enterprise Bundle Repository 是一個基於 Spring 2.5 和 Spring Web Flow 2.0 構建的生產環境中的實際應用程式。

• 如果您是現有的 Web Flow 1 使用者，請查閱 遷移指南 以幫助您升級到 Web Flow 2。WebFlowUpgrader 工具可以自動將您的 flows 轉換為版本 2 語法。

• 使用 Web Flow issue tracker 提交 bug 報告和增強請求。

• 透過 Fisheye 跟蹤 Web Flow 原始碼倉庫的更新。

• 從 Spring Project SVN Repository 檢出 Web Flow 原始碼。

• 透過 訂閱 springframework.org 以獲取有關 Web Flow 2 的未來文章。

InfoQ 有一個 討論帖 總結了對 SpringSource 應用平臺釋出公告的反應。Michael Burke 在該帖中提出了一個 很棒的問題，可以這樣轉述：“拋開圍繞 OSGi 的炒作，如果我將目前打包為 EAR 的應用程式移植到 OSGi bundles，我能期望看到什麼好處？”

我開始在 InfoQ 帖子中回答這個問題，但我的答案對於評論來說太長了，所以我將在這裡解決。

這個問題問得很好。基於 OSGi 的應用程式與傳統的基於 JEE EAR 的應用程式之間的主要區別在於模組化得到了改進。所以問題變成了，這種改進的模組化是否給我帶來了任何好處，如果帶來了，它們是什麼？《設計規則，模組化的力量》一書對這個問題進行了非常詳盡的論述。它提供了很好的背景知識，但我感覺 Michael 可能正在尋找一些比那本書中更不理論化的東西……

SpringSource Application Platform 的主要優勢之一是其按需供應依賴項的能力。這有兩個好處：它確保平臺記憶體佔用儘可能小，並且允許應用程式在不將所有依賴項封裝在單一部署單元（例如 WAR 檔案）中的情況下進行部署。要利用這些功能，您需要了解平臺的供應儲存庫，而這篇博文將提供這些資訊。

供應儲存庫在哪裡？它是如何工作的？

• ext 包含平臺提供的外部依賴項，但它們本身並非平臺的一部分。
• subsystems 包含構成平臺的所有子系統。
• usr 最初為空，用於包含使用者新增的依賴項，即您的應用程式依賴但平臺尚未提供的任何內容。

執行時供應

當平臺啟動已部署的應用程式時，其...

在 JavaOne 會議期間，在線上和線下，關於 SpringSource Application Platform 的討論非常多。WebSphere 事務架構師 Ian Robinson 的一個最有見地的 評論 之一是：

這一切會影響 WebSphere 嗎？嗯，Spring 核心框架本身沒有任何變化。無論 SpringSource Application Platform 的未來如何，Spring 核心框架專案仍然可以與 WebSphere 互補。就像炸魚薯條一樣。

SpringSource Application Platform 由 OSGi 捆綁包構建而成，並支援同樣由 OSGi 捆綁包構建的應用程式。平臺支援 OSGi 的標準功能，但也支援一些額外的清單頭部。許多人曾問：“為什麼 SpringSource 要新增專有頭部？”以及“新頭部有什麼含義？”，因此本文解釋了背景動機以及 Import-Library 和 Import-Bundle 的含義。

標準 OSGi 捆綁包支援

因此，熟悉 OSGi 的開發者可以將平臺用作標準的 OSGi 容器，並受益於平臺的功能，例如：

• 透過管理控制檯或將捆綁包放入平臺的 pickup 目錄來部署捆綁包的能力；
• 診斷功能，如解析失敗診斷、應用程式特定跟蹤和自動死鎖檢測；
• 與 Spring 和 Spring Dynamic Modules 的強大整合，適用於希望使用這些框架的開發人員；以及
• 從儲存庫自動供應依賴項。

企業應用程式的其他要求

好吧，過程中的一些步驟相對容易，特別是如果遵循了良好的軟體工程實踐並且程式碼已被組織成服務、域和基礎設施元件。這些元件可以轉換為捆綁包，它們之間的依賴關係可以使用 META-INF/MANIFEST.MF 中的標準 OSGi Import-Package 和 Export-Package 頭部來表達。

一個更困難的步驟是表達對 Spring 和 Hibernate 等企業框架的依賴。使用標準的 OSGi Import-Package 和 Require-Bundle 頭部來表達這些依賴關係是完全可能的，如果您想建立將在其他 OSGi 容器中執行的 OSGi 捆綁包，那麼您應該這樣做，但這種方法有一些隱藏的成本。

首先，開發人員必須精確地確定構成給定框架的包。僅僅匯入應用程式程式碼使用的包是不夠的，因為許多企業框架在應用程式載入時會在應用程式的位元組碼中注入進一步的依賴關係。開發人員必須透過試錯來發現需要匯入哪些額外的實現包，以確保編織後的應用程式能夠正確執行。

然後是遷移到框架的新版本的工作，其中構成框架的包的精確集已發生更改。編織所需的附加包通常不是由公共契約定義的，因此可能會發生更改。

此外，生成的包匯入未能正確捕獲設計意圖，這使得將來維護或擴充套件應用程式更加困難。

我們真的不想給使用者帶來這些負擔，因此我們建立了一些額外的 SpringSource Application Platform 特定清單頭部，Import-Library 和 Import-Bundle，作為表達對企業框架依賴關係的便捷方式。正如您將在下面看到的，這些頭部只是“語法糖”，它們本身就是標準的 OSGi 包匯入。

Import-Library

    Import-Library: <librarySymbolicName>;version=<versionRange>

如果您不熟悉 OSGi 版本範圍表示法，最常用的形式是最小版本範圍，例如 2，表示“版本 2 或更高版本”，以及“半開”範圍，例如 [2.2.1,2.2.2)，表示 2.2.1（含）和 2.2.2（不含）之間的任何版本。如果省略 version=<versionRange>，並省略分號分隔符，則預設範圍包含所有版本。

對於每個庫匯入，平臺會選擇具有給定符號名稱和給定版本範圍內的最高版本庫。然後，平臺會將庫匯入替換為一組包匯入，這些包匯入匹配該庫捆綁包匯出的所有包。平臺會檢測到捆綁包匯入兩個或多個匯出公共包的庫的情況，會發出適當的日誌訊息，並阻止匯入捆綁包的安裝。

因此，例如，以下頭部匯入了介於 2.5.4（含）和 2.5.5（不含）之間的某個版本的 Spring Framework 庫。

    Import-Library: org.springframework.spring;version="[2.5.4,2.5.5)"

可選庫匯入

    Import-Library: <librarySymbolicName>;version=<versionRange>;resolution:=optional

如果未指定 resolution，或者指定為 mandatory，則包含匯入庫頭部的捆綁包將無法安裝，如果不存在具有給定符號名稱且版本在給定範圍內的庫。但是，如果指定了 resolution:=optional，則在沒有合適的庫可用時，將忽略該庫匯入。

因此，例如，以下頭部從 2.5 版本開始匯入某個版本的 Spring Framework 庫，但如果不存在合適的庫，則會被忽略。

    Import-Library: org.springframework.spring;version="2.5";resolution:=optional

匯入多個庫

    Import-Library: org.foo.p;version="[1,2)",org.bar.q;version="[2,3)"

Import-Bundle

正如您所期望的，對於每個匯入的捆綁包，平臺會選擇具有給定符號名稱和給定版本範圍內的最高版本捆綁包。然後，平臺會將捆綁包匯入替換為一組包匯入，這些包匯入匹配該捆綁包匯出的包。

因此，例如，以下頭部匯入了 Hibernate 物件關係對映 捆綁包。

    Import-Bundle: com.springsource.org.hibernate;version="[3.2.6,3.2.7)"

為什麼不過載 Require-Bundle？

嗯，我們希望 Require-Bundle 保留其標準語義，包括將拆分的包組合在一起的能力。但我們希望 Import-Library 和 Import-Bundle 具有與 Import-Package 相同的底層語義，從而避免拆分包的複雜性。

我們還預計，隨著平臺隨時間的推移而發展，我們將需要向 Import-Library 和 Import-Bundle 新增進一步的指令，這些指令不適合新增到 Require-Bundle。

下一步是什麼？

對於希望利用平臺頭部但需要生成可在其他 OSGi 容器上執行的捆綁包的使用者，我們計劃開發一個工具來替換 Import-Library 和 Import-Bundle...

親愛的 Spring 社群：
我們很高興地宣佈 Spring Batch 1.0.1.RELEASE 已經發布！

下載 | 站點 | 更新日誌

本次釋出主要側重於修復 bug 和改進文件。

自上週三釋出 SpringSource 應用平臺以來，眾多開發人員下載了 1.0.0 測試版並開始試用該平臺。結果，人們開始詢問：“如何在平臺上部署我的應用程式？我有哪些部署和打包選項？”此外，開發人員迫切希望看到可用的示例。作為回應，S2AP 團隊將在未來幾周釋出幾個示例應用程式，演示這些功能以及更多內容，但在您拿到這些示例之前，我想先給您一個高層次的…

親愛的 Spring 社群：

我很高興地宣佈 Spring Web Services 1.5.1 已經發布！

下載 | 站點 | 更新日誌 | 公告

這是 Spring-WS 1.5 系列的第一個錯誤修復和增強版本。它修復了自 1.5.0 以來報告的所有錯誤，並引入了框架中的各種增強功能

• 引入了使用 OXM 編組器的 Spring JMS MessageConverter
• 引入了使用 OXM 編組器的 Spring MVC View
• 修復了結合 WSS4J 和 SAAJ 訊息使用時的 WS-Security 簽名問題
• 支援 HTTP 傳輸的超時
• 支援 Castor 1.2，請參閱下面的註釋
• Airline 示例現在使用 Spring Security

等等。請參閱更新日誌瞭解詳情。

請注意，由於向後相容性問題，CastorMarshaller 現在需要 Castor 1.2 或更高版本。

乾杯，

Arjen Poutsma
Spring Web Services 負責人

很多人一直在問 SpringSource Application Platform 究竟能為 Spring 應用程式做什麼，使其在 OSGi 上執行良好，這超出了 OSGi 和 Spring Dynamic Modules 開箱即用的功能。Adrian 昨天的帖子重點介紹了一些一般性問題，現在我們來看一些細節。

在 OSGi 上執行 Spring 應用程式面臨的三個最具挑戰性的方面是

• 載入時編織
• 類路徑掃描
• 執行緒上下文類載入器管理

其餘但不太有趣的方面包括：JSP 支援、TLD 掃描、註解匹配和資源查詢。總而言之，有一些相當多的問題需要解決才能使應用程式平穩部署。

載入時編織

載入時編織是支援的一項最棘手的功能。在基本層面上，它需要掛鉤到 Equinox 的 ClassLoader，以便在 defineClass 呼叫期間可以附加和使用標準的 ClassFileTransformers。在此基礎上，許多 LTW 的用法需要訪問一個一次性的 ClassLoader，該 ClassLoader 可用於檢查型別以決定在編織期間需要做什麼，而不會影響實際的 ClassLoader。

這個基本級別的支援實際上是相當容易實現的。困難之處在於，當編織由一個 bundle 中的類驅動，但另一個 bundle 中的類需要被編織時。這在企業應用程式中很常見，其中一個 bundle 包含領域實體，另一個 bundle 包含使用 JPA EntityManager 的型別。Platform 透過確保應用程式中的所有 bundle 都可以使用適當的 ClassFileTransformers 進行編織來處理這種複雜性。

當您開始將編織傳播到其他 bundle 時，您確實需要知道何時停止。如果您只是將編織應用於所有 bundle，那麼應用程式將會相互干擾。Platform 透過顯式地限定編織範圍，使其僅應用於應用程式中的模組，從而防止這種情況發生。

LTW 的另一個問題是它會使重新整理複雜化。當一個 bundle 被重新整理時，OSGi 將重新整理所有依賴於它的 bundle。這意味著，在我上面給出的例子中，重新整理領域 bundle 會導致 EntityManager bundle 被重新整理。然而，重新整理 EntityManager **不會**重新整理領域 bundle，這意味著編織可能不同步。Platform 透過將重新整理傳播到受編織影響的其他 bundle 來處理此問題。

類路徑掃描

對於類路徑掃描，主要問題是 Equinox 不暴露標準的 jar: 和 file: 資源。Platform 在中間放置了一個介面卡，以便庫可以看到它們期望的資源協議。這有一個很好的副作用，就是使**大量**第三方庫能夠工作——這不僅僅是類路徑掃描的修復。

執行緒上下文類載入器管理

許多第三方庫使用執行緒上下文 ClassLoader 來訪問應用程式型別和資源。OSGi 中的每個 bundle 都有自己的 ClassLoader，因此，在任何時候只能公開一個 bundle 作為執行緒上下文 ClassLoader。這意味著，如果第三方庫需要檢視分佈在多個 bundle 中的型別，它將無法按預期工作。

Platform 透過建立一個 ClassLoader 來解決這個問題，該 ClassLoader 匯入您應用程式中每個模組的所有匯出的包。然後，此 ClassLoader 作為執行緒上下文 ClassLoader 公開，使第三方庫能夠看到您應用程式中的所有匯出型別。

這只是 Platform 所解決問題的一小部分，但希望它能讓您對 Platform 對 Spring Framework 使用者意味著什麼有所瞭解。