Spring Batch 1.0.0.m4 現在可以透過 s3 Milestone 倉庫獲取（瀏覽地址：http://s3browse.com/explore/maven.springframework.org/milestone/org/springframework/batch）。更多資訊請參閱 Spring Batch 下載頁面（http://static.springframework.org/spring-batch）。
我們調整了釋出計劃，以便擠進一個額外的里程碑版本，Ben 和 Lucas 將專注於此，因此 1.0.0.m5 將在未來 10-14 天內釋出。之後，我們還有時間釋出 rc1，如果需要，還有 rc2 的餘地，然後在預期的 3 月 20 日釋出最終版本。
我們一直非常努力地在 Spring Batch 上工作，為 Spring Portfolio 2.5 釋出列車做準備，我認為現在是向大家更新進展的好時機。在本文中，我將稍微詳細闡述領域建模，以及我們決定提升一些核心領域物件的地位並增加其職責的決定。我還將簡要介紹 1.0 版本之前接下來幾個版本中的一些新特性，以便大家有機會提出意見。
順便說一下，抱歉：內部發生了一些相當重大的變化……
我的上一篇部落格展示了 Spring 如何超越 EJB。BZ Media 和其他機構的研究表明，Apache Tomcat 是領先的開源應用伺服器，市場滲透率達 64%。Spring 和 Tomcat 的主導地位眾所周知。大家可能不太瞭解的是，成千上萬的組織正在使用 Tomcat 作為其中介軟體基礎設施來執行 Spring。這些組織希望有一個公司能夠提供他們所需的成功產品和服務。
今天我們宣佈收購Covalent Technologies。Covalent 不僅帶來了 Apache 的領導地位，我們合併後的公司現在在 Apache Tomcat 和 HTTP 方面也擁有重要的領導地位。兩週前，Sun 為 LAMP 中的“M”支付了 10 億美元。現在，Covalent 出色的 Apache 專業知識和服務成為 SpringSource 的一部分，我們在“A”方面成為了強大的領導者。我們始終追求技術領導地位，因此對於我們與 Covalent 的合作感到非常興奮。在過去幾年裡，Covalent 透過對包括 Tomcat 和 Apache HTTP 在內的 Apache 專案的支援，在市場上贏得了良好的聲譽。其數百家支援客戶包括財富 500 強中一半以上的公司，以及輝瑞、強生、英國電信 (BT)、NASA、英特爾、蘇格蘭皇家銀行和貝爾斯登等家喻戶曉的公司。我們的公告……
Spring 2.5 背後的核心主題之一是全面的基於註解的配置。我們已經討論和撰寫了很多關於 @Autowired、Spring MVC 的 @RequestMapping 以及對使用 JUnit4 或 TestNG 編寫的帶註解測試的新支援。@Autowired 無疑是 Spring 2.5 註解中的核心，可用於服務元件、Web 元件、單元測試——甚至在使用 Spring 的 @Configurable 和 AspectJ 織入時的領域物件。Spring MVC 的 @RequestMapping 也同樣靈活，支援多種處理方法簽名變體。
今天我……
嗯，這比我們最初預期的要花費更長的時間，但我非常高興地宣佈 Spring Dynamic Modules 專案今天達到了 1.0 里程碑版本。當我第一次在 2006 年 9 月發表關於這個主題的文章（“Spring OSGi 支援正在取得進展”）時，最初的規範只是 Spring Framework 相關問題的一個附件，與更廣泛的 OSGi 社群的聯絡才剛剛開始建立。
快進十八個月，Spring Dynamic Modules 已成為 Spring 產品組合中的一個成熟專案，提交者來自 SpringSource、BEA 和 Oracle。BEA 和 Oracle 都正在使用 Spring Dynamic Modules 構建自己的基於 OSGi 的產品（例如，請參閱“WebLogic Event Server - 我們為什麼使用 Spring”），並且 Spring Dynamic Modules 討論組擁有近 1000 名成員。OSGi 聯盟本身已經組建了一個企業專家組……
我很高興地報告（與 Adrian 一起）經過 3 個里程碑版本和 2 個釋出候選版本，Spring Dynamic Modules（以前稱為 Spring OSGi）1.0 版本已經釋出。
自我的上一篇文章（關於 1.0 M1）以來，許多功能得到了改進或新增；我將在未來的文章中詳細討論它們（還有詳細解釋該庫的參考文件），所以這裡只列舉幾個：
- 一致性
我們希望提供一個強大、簡單且一致的程式設計模型。這就是 Spring Dynamic Modules 構建於 Spring 之上並利用其成熟概念、可靠性和普遍性的原因。
- 高度非侵入性
推薦使用 Spring DM 的方法是不要在你的程式碼中使用其類，或在你的 Bundle Manifest 中匯入它們。如果你在程式碼中不使用 Spring，僅用於你的應用程式配置，同樣的規則也適用。Spring DM 為你建立應用程式上下文，因此你無需依賴 Spring 或 Spring DM。而且不必擔心自定義名稱空間或 XML Schema 等問題——我們已經涵蓋了這些。
- OSGi 服務動態生命週期管理
這是 Spring DM 最重要的特性之一——能夠像處理普通 Bean 一樣與 OSGi 服務互動。無需編寫任何程式碼即可釋出和消費 OSGi 服務；我們將為你處理其動態性——你擁有完全的控制權（未來會詳細介紹）。
- 更智慧的整合測試框架
由於我們在內部廣泛使用了 Spring-DM 整合測試，我們改進了預設設定、Maven 整合，並使自動 Manifest 生成比以前更快更智慧。例如，框架會自動確定測試 Bundle 中可用的類，並且不會為其生成匯入。
- 簡單的 Bundle 互動
Andy Piper（部落格）添加了一種簡單、宣告式的方法來根據模組生命週期和 Spring Bean 依賴關係安裝/啟動/停止/更新 Bundle。
- 受管理的啟動/關閉上下文建立
在 OSGi 中，應用程式被分解成各種模組（也稱為 Bundle），它們相互依賴服務。這在模組之間建立了一個依賴樹，這在啟動和關閉期間變得很重要。傳統上可以透過按照依賴順序安裝和啟動 Bundle 來解決這個問題，但這並不能完全解決問題。正如 OSGi 規範所建議的，初始化時間較長的 OSGi 服務（例如連線池）應該依賴於與用於啟動和停止 Bundle 的執行緒不同的執行緒。這意味著如果一個 Bundle 啟動了，並不意味著其服務就可用了。而且並非所有應用程式都準備好在啟動時等待其所需的服務——事實上，很少有應用程式會這樣做。這意味著一個 Bundle 會失敗，因為它依賴於稍後幾毫秒釋出的服務（預設情況下，OSGi 是一個虛擬機器內平臺，事情發生得非常快）。
這種行為並不罕見——事實上，在具有多個 Bundle 的多核平臺啟動時非常常見。Spring DM 透過確定依賴關係（來自 Spring 配置）並在依賴可用後才建立應用程式上下文來解決這個問題。在關閉時也會使用類似的過程，Spring DM 將根據它們的依賴順序停止上下文，這樣你就不必擔心啟動或停止你的 Bundle 了。
- 無執行緒依賴等待
在討論依賴機制時，不能不提到 Hal Hildebrand 實現的用於依賴等待的“無執行緒”方法（我知道這聽起來有點矛盾——我們正在為它想一個好聽的名字）（請參閱他的部落格）。由於各種服務需要可用，模組才能正確啟動，因此需要某種等待/監控機制，傳統上這意味著使用一個執行緒。
然而，在一個 OSGi 平臺上可以有（並且將會出現）多個模組（幾十個輕而易舉）——每個模組使用一個等待執行緒根本無法擴充套件。我們努力改進了這一點，我相信我們提供了一個非常好的解決方案——在等待過程中完全不使用執行緒。這意味著無論部署 3 個 Bundle 還是 300 個，都不會消耗 CPU 時間，除非你的模組實際開始啟動。
Spring Dynamic Modules 不僅僅是將 API“Spring 化”，而是處理一個不同的執行時環境。
關於工具方面，Spring IDE 支援 Spring DM 名稱空間，並且（感謝Christian）還為 Eclipse PDE 提供了 Spring-DM 特定目標，這是 Spring IDE 每夜構建版本中的一個功能（關於安裝和使用該外掛的更多資訊可以在參考文件中找到）。
既然 1.0 已經發布，接下來是什麼？有很多領域需要涵蓋
OSGi 平臺提供了一個專用的Http 服務，但使用它需要編碼。資源載入、JSP 生成和部署等事情可以大大簡化。這是 1.1 版本的主要重點領域。
現代持久化工具提供了高階功能，例如延遲載入，這些功能透過依賴於類生成和代理，打破了 OSGi 環境強制執行的模組化邊界。我們希望解決這個問題，就像 Web 支援一樣，提供平滑的體驗，無論是使用純 JDBC 還是 ORM 工具。
繼持久化問題之後，我們正在尋求在 OSGi 內部進行通用 AOP 的解決方案。這是一個難題，要正確實現它，需要內部 OSGi 平臺的支援。好訊息是，像 Equinox Aspects 這樣的專案已經開闢了道路，並且 OSGi 企業專家組 (EEG) 也已將該問題納入他們的關注範圍。
如果你想了解更多關於 Spring Dynamic Modules 的資訊，請訪問專案頁面和參考文件，並使用我們的郵件列表（論壇很快就會出現）。此外，最近我們製作了一些 OSGi/Spring DM截圖影片，這些影片可在 Spring DM 主頁上找到。第一個影片（由兩部分組成），由我本人制作，展示瞭如何快速建立一個專案來使用 Spring DM 進行整合測試。
為什麼是整合測試？因為使用 Spring DM，這是一個非常簡單快速的過程，也是瞭解 OSGi（尤其是模組化方面）的非常有效的方法。
未來會有更多截圖影片——只需告訴我們你想看什麼，根據請求數量，我們將相應地安排它們。
事不宜遲，“使用 Spring DM 進行 OSGi 整合測試”
Spring 的依賴注入（DI）機制允許配置應用程式上下文中定義的 Bean。如果你想將同樣的想法擴充套件到非 Bean 物件怎麼辦？Spring 對領域物件 DI 的支援利用 AspectJ 織入將 DI 擴充套件到任何物件，即使該物件是由 Web 或 ORM 框架建立的。這使得建立具有豐富領域行為的物件成為可能，因為領域物件現在可以與注入的物件協作。在這篇部落格中，我將討論 Spring 框架在此領域的最新改進。
領域物件 DI 背後的核心思想非常簡單：AspectJ 織入的切面選擇與符合特定規範的任何物件的建立或反序列化對應的連線點。對這些連線點的增強向正在建立或反序列化的物件注入依賴。當然，細節決定成敗。例如，如何選擇與反序列化對應的連線點，或者如何對每個物件僅注入一次依賴？透過提供一些預先編寫的……
招聘資訊是衡量技術實際採用情況的良好指標。它們表明公司是否正在投入資金，從而能夠區分實質與炒作；它們表明開發者獲取和提升相關技能的重要性（這是技術持續發展的重要因素）；並且它們為公司採用特定技術的安全性提供了很好的指導。
因此，Indeed.com（一個招聘資訊聚合網站）的jobtrends 網站是一個重要的資源。它允許跟蹤招聘需求數量隨時間變化的趨勢，並且……
注意：此帖子已編輯，以反映 Spring 遷至Pivotal 的情況。關於 Spring 培訓和認證的最新部落格請參見此處。
自六個月前我加入 SpringSource 擔任培訓總監以來，我一直聽到一個一致的要求。基於對 Spring 技能不斷增長的需求，全球的開發者和顧問正在尋求可量化的方式來展示他們的 Spring 專業知識。同樣，這些需求的招聘經理也要求提供認證計劃，以幫助識別和招聘具備立即可用、基礎 Spring 知識的技術人員。
正如 Spring 專案團隊響應開源社群的需求一樣，我們也做出了回應，並高興地宣佈SpringSource 認證計劃。該計劃將於本月（2008 年 1 月）啟動，首先推出的是 Spring Framework Professional……
