親愛的 Spring 社群：

我們很高興地宣布 Spring Web Flow 2 正式可用。下載 | 文件

Spring Web Flow 是 Spring Portfolio 中的專案，專注於提供構建和運行豐富 Web 應用程式的基礎架構。作為一個 Spring 專案，Web Flow 建構在 Spring Web MVC 框架之上，以提供

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

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

Web Flow 2 中的內容

Spring Web MVC

Spring Web MVC 框架是 Spring Framework 發行版的一個模組，它使用經過驗證的 ModelViewController 範例為使用 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 控制器環境中使用 JSF 作為 View 技術。透過這種架構方法，您可以將 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 以宣告式的方式保護您的流程
• 使用 Tiles 進行 JSP 頁面組合和 Ajax 部分渲染
• 使用 JSF 時，使用 Facelets 進行頁面組合和佈局
• 使用 JSF 時，使用 Apache Trindad 和 JBoss RichFaces 元件庫
• 以漸進且非侵入的方式使用 Dojo 小部件系統；如果用戶端上沒有 JavaScript，則以優雅降級的方式進行

簡化

Web Flow 2 中流程定義語言已大大簡化，同時總體上變得更加強大。這些簡化包括

• 將版本 2 流程定義與其版本 1 等效項進行比較時，程式碼行數總體減少約 50%（範例：版本 2 與 版本 1）
• 使用表達式語言 (EL) 調用動作的簡潔語法，支援 Unified EL 和 OGNL
• 宣告式模型綁定和驗證，支援約定優於配置
• 使用流程定義繼承在流程和狀態層級上支援重用
• 增強的模組化，允許將流程及其相依資源打包在一個獨立的捆綁包中

發布說明

• 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 認證為「平台就緒」，適合在 OSGi 啟用的 Web 應用程式中在 SpringSource dm Server 上運行。

入門

• 透過下載版本和逐步完成參考應用程式開始使用 Web Flow。使用文件作為補充，以熟悉該功能集。

• 若要開始使用 Maven 或 Ant+Ivy 等建置系統，請從 Maven 中央儲存庫存取 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 社群論壇上的 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 工具會自動將您的流程轉換為版本 2 語法

• 使用 Web Flow 問題追蹤器提交錯誤報告和增強功能要求

• 使用 Fisheye 追蹤 Web Flow 原始碼儲存庫的更新

• 從 Spring Project SVN 儲存庫簽出 Web Flow 原始碼

• 透過訂閱 springframework.org 關注即將發布的 Web Flow 2 文章

InfoQ 有一個 討論串，總結了對 SpringSource Application Plaform 公告的回應。Michael Burke 在該執行緒上提出了一個 好問題，可以概括為「忘記圍繞 OSGi 的炒作，如果我將目前打包為 EAR 的應用程式移植到 OSGi 捆綁包，我期望看到什麼好處？」。

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

這是個好問題。OSGi 架構應用程式與傳統 JEE EAR 架構應用程式的主要區別在於，前者具有更佳的模組化能力。所以問題變成，這種更佳的模組化是否能帶來任何好處？如果有的話，又是什麼好處？書名為「設計規則：模組化的力量」的書對此問題進行了非常透徹的闡述。這本書提供了很棒的背景知識，但我感覺 Michael 可能想尋找比書中內容更不理論化的東西...

SpringSource Application Platform 的主要優勢之一是它能夠根據需要佈建相依性。這具有雙重優勢：它確保 Platform 的記憶體佔用空間盡可能小，並且允許在不將所有相依性封裝在單一的部署單元（例如 WAR 檔案）的情況下部署應用程式。要利用這些功能，您需要了解 Platform 的佈建儲存庫，而這篇部落格文章的目的就在於提供這些知識。

佈建儲存庫在哪裡？它如何運作？

• ext 包含 Platform 隨附提供的外部相依性，但它們不是 Platform 本身的一部分。
• subsystems 包含組成 Platform 的所有子系統。
• usr 最初是空的，旨在包含使用者新增的相依性，也就是您的應用程式所依賴但 Platform 尚未提供的任何內容。

執行階段佈建

當 Platform 啟動已部署的應用程式時，它的...

很高興聽到在 JavaOne 的線上和現場有這麼多關於 SpringSource Application Platform 的討論。其中一個最具洞察力的 評論 來自 WebSphere 事務架構師 Ian Robinson

這會影響 WebSphere 嗎？好吧，核心 Spring 框架沒有任何改變。無論 SpringSource Application Platform 的未來如何，核心 Spring 框架專案仍然與 WebSphere 相輔相成。就像炸魚薯條一樣。

SpringSource Application Platform 由 OSGi bundle 構成，並且支援同樣由 OSGi bundle 構成的應用程式。Platform 支援 OSGi 的標準功能，但也支援一些額外的資訊清單標頭。有些人問 為什麼 SpringSource 要新增專有標頭？ 和 新標頭的語意是什麼？，因此這篇文章解釋了背景動機以及 Import-Library 和 Import-Bundle 的語意。

標準 OSGi Bundle 支援

因此，精通 OSGi 的開發人員可以使用 Platform 作為標準 OSGi 容器，並從 Platform 功能中受益，例如

• 能夠使用管理控制台部署 bundle，或者將 bundle 放入 Platform 的 pickup 目錄中，
• 診斷功能，例如解析失敗診斷、應用程式特定追蹤和自動死鎖檢測，
• 與 Spring 和 Spring Dynamic Modules 強力整合，適用於想要使用這些框架的開發人員，以及
• 從儲存庫自動佈建相依性。

企業應用程式的額外需求

好吧，這個過程中的一些步驟相對容易，尤其是如果遵循了良好的軟體工程實務，並且將程式碼組織到服務、網域和基礎架構元件中。這些元件可以轉換為 bundle，並且可以使用 META-INF/MANIFEST.MF 中的標準 OSGi Import-Package 和 Export-Package 標頭來表達它們之間的相依性。

一個更困難的步驟是表達對企業框架（例如 Spring 和 Hibernate）的相依性。完全可以使用標準 OSGi Import-Package 和 Require-Bundle 標頭來表達這些相依性，如果您目的是建立將在其他 OSGi 容器中執行的 OSGi bundle，那麼您應該這樣做，但這種方法有一些隱藏的成本。

首先，開發人員必須準確決定哪些套件構成給定的框架。僅僅匯入應用程式程式碼使用的套件是不夠的，因為幾個企業框架會在載入應用程式時將進一步的相依性織入到應用程式的位元組碼中。開發人員必須透過試錯來發現要匯入哪些額外的實作套件，以確保織入應用程式的正確行為。

然後是從一個框架版本遷移到下一個框架版本的問題，其中構成框架的確切套件集已變更。織入所需的額外套件通常不是由公共合約定義的，因此可能會發生變更。

此外，產生的套件匯入沒有正確地捕獲設計意圖，這使得在未來維護或擴展應用程式更加困難。

我們真的不想將這些負擔加在使用者身上，因此我們建立了一些額外的 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>，以及當然的分號分隔符，那麼預設範圍包括所有版本。

對於每個程式庫匯入，Platform 會選擇具有給定符號名稱且在 Platform 儲存庫中可用的給定版本範圍內最高版本的程式庫。然後，Platform 會將程式庫匯入替換為一組套件匯入，這些匯入與程式庫的 bundle 匯出的所有套件相符。Platform 會偵測到 bundle 匯入兩個或更多個匯出通用套件的程式庫的情況，發出適當的日誌訊息，並且無法安裝匯入 bundle。

因此，例如，以下標頭匯入 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，則如果沒有具有給定符號名稱且版本在給定範圍內的程式庫，則包含匯入程式庫標頭的 bundle 將無法安裝。但是，如果指定了 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 已經發布！

下載 | 網站 | 變更日誌

此版本著重於錯誤修復和文件改進。

自從我們上週三發布 SpringSource 應用程式平台以來，許多開發人員已經下載了 1.0.0 beta 版本，並開始對平台進行測試。 因此，人們開始詢問：「我如何在平台上部署我的應用程式？我有哪些部署和封裝選項？」此外，開發人員也迫切希望看到可運作的範例。 為回應，S2AP 團隊將在接下來的幾週內發布幾個範例應用程式，展示這些功能等等，但在您親自操作這些範例之前，我想先給您一個概要的…

親愛的 Spring 社群，

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

下載 | 網站 | 變更日誌 | 公告

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

• 引入了一個使用 OXM marshaller 的 Spring JMS MessageConverter
• 引入了一個使用 OXM marshaller 的 Spring MVC View
• 修復了在使用 WSS4J 結合 SAAJ 訊息時的 WS-Security 簽章
• 支援 HTTP 傳輸上的逾時
• 支援 Castor 1.2，請參閱以下說明
• Airline 範例現在使用 Spring Security

以及更多。 請參閱變更日誌以了解詳細資訊。

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

敬祝，

Arjen Poutsma
Spring Web Services Lead

很多人都在問，SpringSource 應用程式平台為 Spring 應用程式做了什麼，使其在 OSGi 下運行良好，並且超越了您可以從 OSGi 和 Spring Dynamic Modules 開箱即用的功能。 Adrian 昨天的文章重點介紹了一些常見問題，現在讓我們看看一些細節。

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

• 載入時編織 (Load-time weaving)
• 類別路徑掃描 (Classpath scanning)
• Thread context classloader 管理

其餘不太有趣的問題包括：JSP 支援、TLD 掃描、註解匹配和資源查詢。 總的來說，需要解決一組相當大的問題，才能使應用程式順利部署。

載入時編織 (Load-time weaving)

載入時編織是在穩健的方式下支援的最棘手的功能之一。 在基本層級，它需要連接到 Equinox ClassLoader，以便可以在 defineClass 呼叫期間附加和使用標準 ClassFileTransformers。 除此之外，LTW 的許多用法都需要訪問一次性的 ClassLoader，可用於檢查類型以決定在編織期間需要發生的事情，而不會影響實際的 ClassLoader。

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

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

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

類別路徑掃描 (Classpath scanning)

對於類別路徑掃描，主要問題是 Equinox 不會公開標準的 jar: 和 file: 資源。 平台在中間放置一個介面卡，以便程式庫看到它們期望的資源協定。 這有一個很好的副作用，使 **很多** 第三方程式庫可以工作 - 這不僅僅是類別路徑掃描的修復。

Thread context classloader 管理

許多第三方程式庫使用 thread context ClassLoader 來訪問應用程式類型和資源。 OSGi 中的每個套件組合都有自己的 ClassLoader，因此，在任何時候只能將一個套件組合公開為 thread context ClassLoader。 這意味著，如果第三方程式庫需要查看分佈在多個套件組合中的類型，它將無法按預期工作。

平台透過建立一個 ClassLoader 來解決此問題，該 ClassLoader 匯入應用程式中每個模組的所有匯出套件。 然後，將此 ClassLoader 公開為 thread context ClassLoader，使第三方程式庫能夠查看應用程式中的所有匯出類型。

這只是平台解決的問題的一小部分，但希望它能讓您了解平台對 Spring Framework 使用者的意義。