Spring Security 2.0.1 釋出

釋出 | Ben Alex | 2008 年 5 月 2 日 | ...

Spring Security 2.0.1 現已可用。

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

Spring Security 2.0.1 為最近釋出的 2.0.0 版本提供了一些修復。它還在 OSGi 支援、擴充套件名稱空間配置和加密強度令牌生成方面提供了一些進一步的改進。它完全向後相容 2.0.0,並且可以作為 JAR 替代品直接使用。

完善全貌:Spring、OSGi 和 SpringSource 應用平臺

工程 | Adrian Colyer | 2008年5月1日 | ...

** 5月2日更新,包含案例研究:- 詳見此帖子底部 ** 我相信閱讀本部落格的大多數人昨天都看到了 SpringSource 應用平臺的釋出公告。如果沒有,請務必檢視 Rob 的部落格文章,其中描述了一些動機、程式設計模型和路線圖。

有一些常見的疑問,我想在這篇文章中直接解決。之後,我將描述另外兩個激動人心的公告,它們補充了 SpringSource 應用平臺本身,但昨天沒有登上頭條:……

介紹SpringSource Application Platform

工程 | Rob Harrop | 2008 年 4 月 30 日 | ...

經過數月緊張的編碼,我很高興地宣佈 SpringSource Application Platform 1.0 的 beta 版本釋出。

2007 年初,我們開始討論替代單體式、重量級應用程式伺服器的可能方案,企業 Java 已與這些伺服器形影不離。客戶正在尋找一個輕量級、模組化且足夠靈活的平臺,以滿足其開發和部署需求。

Spring 和 Tomcat 的組合表明,開發人員和運維人員可以在生產環境中成功使用一個輕量級的平臺。儘管這種組合取得了成功,但缺乏模組化和對非 Web 應用程式的顯式支援限制了其適用性和靈活性。

我們著手構建 SpringSource Application Platform 以滿足這些需求並消除這些限制。

Platform 的核心是 Dynamic Module Kernel (DMK)。DMK 是一個基於 OSGi 的核心,充分利用了 OSGi 平臺的模組化和版本控制功能。DMK 基於 Equinox 並擴充套件了其在配置和庫管理方面的功能,同時為 Platform 提供了核心功能。

SpringSource Application Platform Architecture

為了保持最小的執行時佔用空間,OSGi bundle 由 DMK 配置子系統按需安裝。這使得應用程式可以安裝到執行中的 Platform 中,並且其依賴項可以從外部儲存庫中滿足。這不僅消除了手動安裝所有應用程式依賴項的繁瑣工作,而且最大限度地減少了記憶體使用。

DMK 本身需要一套最小的 bundle 來執行,並透過一個 **profile** 進行配置,以精確控制載入的附加模組集。例如,DMK 不需要 Tomcat,但預設的 Platform profile 包含 Tomcat 以允許部署 Web 應用程式。如果您想在沒有 Tomcat 的情況下執行 Platform,只需編輯 profile 即可,它就不會被安裝。(如果您嘗試這樣做,請記住,刪除 Web 支援意味著 Web 模組將不再部署,因此請刪除 pickup 目錄中的內容,以免 Platform 在啟動時嘗試安裝 Admin 和 splash 螢幕應用程式。)預設的 Platform 配置(安裝了管理控制檯)僅佔用 15MB 記憶體。

我對企業 Java 的一個長期不滿是,應用程式經常被塞進牽強的孤島,並且缺乏對不同應用程式型別的顯式支援。考慮一個線上商店的應用程式。該應用程式有一個 Web 前端、一個訊息驅動的訂單處理模組、一個批處理驅動的庫存重新排序模組和一個 B2B Web 服務模組。如今,許多此類應用程式將被打包成 WAR 或 EAR,並且模組將非常相似,對模組型別差異的支援很少。有趣的是,許多人會將此稱為 Web 應用程式,而不是帶有 Web 模組的應用程式。

在 SpringSource Application Platform 中,應用程式是模組化的,每個模組都有一個 **personality**,用於描述它是什麼型別的模組:Web、批處理、Web 服務等。Platform 以特定於 personality 的方式部署每個 personality 的模組。例如,Web 模組在 Tomcat 中使用 Web 上下文進行配置。應用程式中的每個模組都可以獨立於其他模組進行更新,同時保持作為大型應用程式一部分的身份。無論您構建哪種型別的應用程式,程式設計模型仍然是標準的 Spring 和 Spring DM。

在 1.0 Platform 版本中,我們支援 **web** 和 **bundle** personality,這使您能夠構建複雜的 Web 應用程式。未來的版本將根據後續詳述包含對更多 personality 的支援。

構建應用程式

Platform 支援三種形式的應用程式打包

  1. Java EE WAR
  2. 原始 OSGi bundle
  3. 平臺歸檔 (PAR)

Platform 直接支援標準的 WAR 檔案。在部署時,WAR 檔案將被轉換為 OSGi bundle 並安裝到 Tomcat 中。所有標準的 WAR 合約都得到遵守,您現有的 WAR 檔案應該可以直接部署而無需更改。

任何符合 OSGi 標準的 bundle 都可以直接部署到 Platform 中,並可以充分利用對 `Import-Package` 和 `Require-Bundle` 所引用的任何依賴項進行的即時配置。

PAR 格式是為 Platform 打包和部署應用程式的推薦方法。PAR 只是一個 OSGi bundle(模組)的集合,這些 bundle 被分組到一個標準的 JAR 檔案中,並帶有一個唯一標識應用程式的名稱和版本。PAR 檔案作為單個單元部署到 Platform。Platform 將提取 PAR 中的所有模組並進行安裝。第三方依賴項將根據需要即時安裝。

與直接將 bundle 部署到 Platform 相比,PAR 格式有三個主要優勢。首先,它更簡單。一箇中等規模的企業應用程式可能包含 12 個以上的 bundle - 手動部署這些 bundle 將非常繁瑣。其次,PAR 檔案為應用程式中的所有 bundle 形成了一個顯式的範圍,防止使用重疊型別或服務的應用程式之間發生衝突。此範圍還用於一些高階功能,例如載入時織入,以確保一個應用程式的織入不會干擾另一個應用程式的織入。最後,PAR 形成了一個邏輯分組,用於定義哪些模組是應用程式的一部分以及應用程式有哪些第三方依賴項。此分組由管理工具用於提供應用程式的詳細檢視。典型的 PAR 應用程式如下所示:

PAR File Structure

應用程式中模組之間的依賴關係通常使用 Import-PackageExport-Package 來表示。對第三方庫的依賴也可以透過相同的方式表達,但對於許多庫而言,這可能會耗時且容易出錯。在使用 Hibernate 等庫時,通常需要匯入比預期更多的包。為了解決這個問題,您可以使用 Require-Bundle,但這存在一些語義上的不足之處,例如拆分包(split packages),即一個邏輯包被拆分到兩個或多個類載入器中,導致執行時出現問題。Platform 引入了兩種新的機制來引用第三方依賴:Import-BundleImport-LibaryImport-Bundle 類似於 Require-Bundle,但它避免了拆分包以及 Require-Bundle 的其他問題。Import-Library 提供了一種機制,可以用一個宣告來引用一組包(例如 Spring Framework 中的所有包)匯出的所有包

Bundle-SymbolicName: com.myapp.dao.jdbc
Bundle-Version: 1.0.0
Import-Bundle: org.apache.commons.dbcp;version="1.2.2.osgi"
Import-Library: org.springframework.spring;version="2.5.4.A"

在這裡,我有一個依賴於 Commons DBCP bundle 和 Spring Framework 庫的模組 bundle。Spring Framework 庫包含使用 Spring 在應用程式中所需的所有 bundle。

`Import-Library` 和 `Import-Bundle` 在後臺會展開為 `Import-Package`,因此與標準的 OSGi 語義一致。

Platform 理解模組的 personality,並能從中推斷出如何配置模組的執行環境。在部署 Web 模組時,典型的 Spring MVC 應用程式所需的所有 Servlet 基礎設施都會自動建立,從而無需在應用程式中重新建立這些樣板程式碼。在 1.0 最終釋出版中,將為 Web 模組 personality 新增更多智慧功能,以支援 Spring Web Flow 等其他技術。

無論您選擇哪種打包格式,程式設計模型都只是 Spring Framework 和 Spring Dynamic Modules,其他 Spring Portfolio 產品執行在其之上。

可服務性

可服務性是整個工程團隊的關鍵考慮因素。我們花費了大量時間來研究日誌訊息的格式和堆疊跟蹤的大小,以確保診斷應用程式問題儘可能容易。每當發現一項重複且耗時的任務時,我們都會尋找一種方法來自動化它或完全消除它。

為了幫助診斷問題,Platform 在日誌和跟蹤訊息之間進行了嚴格的劃分。日誌訊息旨在供終端使用者使用,讓您無需篩選大量跟蹤內容即可獲取最重要的失敗資訊。所有應用程式故障都會顯示並編碼在日誌輸出中 - 程式碼可方便地用於訪問知識庫或支援內容。為了理解這一點為何如此有用,請考慮以下 Platform 啟動輸出:

[2008-04-29 12:12:01.124] main                     <SPKB0001I> Platform starting.
[2008-04-29 12:12:04.037] main                     <SPKE0000I> Boot subsystems installed.
[2008-04-29 12:12:06.013] main                     <SPKE0001I> Base subsystems installed.
[2008-04-29 12:12:07.396] platform-dm-1            <SPPM0000I> Installing profile 'web'.
[2008-04-29 12:12:07.674] platform-dm…

Web 應用程式和 OSGi

工程 | Costin Leau | 2008 年 4 月 29 日 | ...

自 Spring Dynamic Modules 的第一個里程碑以來,執行 OSGi 中 Web 應用程式的請求開始湧入。這可能是最受歡迎的功能之一,而且毫不奇怪,一旦 1.0 最終版釋出,Web 支援就一直是 1.1 分支的主要關注點。我很高興地報告,隨著剛剛釋出的 M2,正如 Juergen 已經暗示的那樣,Spring-DM 不僅支援標準的 war(自 1.1.0 M1 起可用),還支援在 OSGi 中執行的 Spring-MVC 應用程式。在本文中,我想簡要討論典型的 OSGi Web 場景和 Spring-DM 的方法。但首先,

為什麼要在 OSGi 中部署 WAR?

簡單問題:OSGi *原生* 提供版本控制、包連線和熱重載入。想象一下在您的應用程式中利用這些功能:您可以停止將庫嵌入WEB-INF/lib並將它們在 Web 應用程式之間共享,避免 taglibs 重複(同時保持多個版本執行),並即時更新應用程式的特定部分。這尤其有用,因為 Web 應用程式往往是分層的,因此在其生命週期中會經歷大量更改。

為什麼 OSGi 中的 Web 應用程式存在問題?

Servlet 規範圍繞著一個*Web 容器*的概念:一個為 Web 元件提供執行時環境的執行時環境,該環境提供標準服務,如生命週期管理(物件建立和處置、執行緒分配)、併發、HTTP 請求處理等。另一方面,OSGi 平臺也作為具有服務登錄檔、包連線和版本控制(僅舉幾例)的託管環境。為了解決這個問題,OSGi 委員會設計了 compendium 規範的一部分,即 Http Service

如今,可移植性比以往任何時候都更重要

工程 | Juergen Hoeller | 2008 年 4 月 29 日 | ...

昨天,我寫了一篇關於Spring 如何幫助最大化應用程式可移植性的部落格。儘管可移植性問題一直是企業 Java 領域的一個持續性話題,但這篇部落格非常及時。今天,Oracle 宣佈其以 67 億美元收購 BEA Systems 的交易已完成。兩家公司產品集存在大量重疊,因此這必將為 WebLogic 和 OC4J 的客戶群帶來不確定性。WebLogic 和 OC4J 可能都屬於“J2EE 伺服器”類別,但它們是截然不同的產品,具有截然不同的特性。

由於許多企業…

框架層面的可移植性

工程 | Juergen Hoeller | 2008 年 4 月 28 日 | ...

可移植性是 Spring 生態系統中的一個關鍵因素。我們堅信框架級別的可移植性:應用程式元件是針對特定框架(或框架版本)編寫的,例如 Spring 2.5;然後,框架負責適配任何底層託管環境。然而,特定的應用程式框架獨立於託管環境。一個新的框架版本可以部署到已建立的託管平臺版本上,只要環境的基本功能足夠。這種方法…

會議季仍在繼續

工程 | Rod Johnson | 2008年4月24日 | ...

昨天,我在德國威斯巴登舉行的 JAX 會議 上發表了開幕主題演講。JAX 是歐洲最大的 Java 會議之一,有超過 2000 名與會者。主題是企業 Java 的未來,我詳細闡述了我 最近一篇關於預測的博文 中的主題,並深入探討了 Java EE 6 的影響 以及應用程式伺服器的未來。
我已 上傳了幻燈片,其中包括對企業 Java 演進過程中一段有趣時期的 8 項預測。這是我第一次在同一場演講中提及約瑟夫·斯大林、莫妮卡·萊溫斯基和蒙提·派森。

Spring Security 2.0 正式釋出:告別“死去的仙女”

工程 | Rod Johnson | 2008年4月17日 | ...

Spring Security 2.0 已釋出。這是 Spring 產品組合向前邁出的重要一步。Spring (Acegi) Security 已是 Java 平臺最廣泛使用的企業安全框架,在 SourceForge 上下載量超過 250,000 次,每次釋出下載量超過 20,000 次。透過大幅簡化使用方法,本次釋出無疑將把採用率提升到一個新的水平。

我特別高興看到這次釋出,原因如下:

  • 這對 Spring 社群來說是一件大事。它(更加)易於使用,同時也更強大。它使許多更多使用者能夠使用最強大的企業 Java 安全解決方案,幾乎消除了採用的障礙。請參閱這篇 教程,瞭解它如何讓保護典型的 Web 應用程式變得更加容易。XML Bean 定義的泛濫已成為過去。
  • 這是 Spring 2.x 工作的一種延續,透過應用自定義 XML 名稱空間的力量來實現激進的預設設定,同時仍然允許定製。
  • 與 Spring 2.5 一樣,它也體現了當前 Spring 產品組合朝著“大幅減少對 XML 的需求”這一趨勢發展。
  • 這是 SpringSource 商業模式價值的證明。我們的收入模式使我們能夠比以往任何時候都投入更多資源來建立開源軟體。如果沒有能力同時聘用 Acegi/Spring Security 的建立者 Ben Alex 和另一位主要貢獻者 Luke Taylor,這次釋出要麼不會發生,要麼會大打折扣。
  • 這對 仙境 來說是件好事。

Acegi/Spring Security 的建立者 Ben Alex 和 Luke Taylor 做得非常出色。Ben 將在下個月的 Java One 大會上就 Spring Security 發表講話。如果…

Spring Security 2.0.0 釋出!

釋出 | Ben Alex | 2008年4月15日 | ...

Spring Security 2.0.0 現已釋出。

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

經過近兩年的開發,Spring Security 2.0.0 現已可供下載。此重要新版本取代了 Acegi Security,成為 Spring 應用程式的官方安全模組。它提供了顯著簡化的配置,以及無數其他新功能,包括 OpenID、NTLM、JSR 250 註釋、AspectJ 切點支援、領域 ACL 增強、RESTful URI 授權、組、分層角色、使用者管理 API、基於資料庫的“記住我”、portlet 認證、其他語言、Web Flow 2.0 支援、Spring IDE 視覺化和自動完成、透過 Spring Web Services 1.5 增強的 WSS 支援等等。

Spring Web Flow 2.0.0.RC1 釋出

釋出 | Keith Donald | 2008 年 4 月 14 日 | ...

親愛的Spring社群,

我們很高興地宣佈 Spring Web Flow 2.0.0.RC1 現已釋出。 下載 | 文件

2.0.0.RC1 引入了多項新功能,並修復了先前里程碑版本報告的所有已知問題。

我們建議您從先前的 Web Flow 2 里程碑版本 升級到 2.0.0.RC1。我們也建議 Web Flow 1 使用者此時開始評估升級到 Web Flow 2,因為 RC1 引入了全面的 2.0 版本文件,以及一個用於自動化轉換 1.0 版本流到 2.0 版本語法的工具。

開始使用 Web Flow 2 的最佳方法是評估分發包中包含的 參考應用程式,並結合 參考指南。 Spring Web Flow 2 需要 Spring Framework 2.5.3 和 Java 1.4 或更高版本。

請參閱下面的 2.0.0 RC1 版本中新增和值得關注的內容

2.0.0.RC1 新增和值得關注的內容

  • 引入了 Web Flow 2 參考指南,提供 PDF 和 HTML 格式。新指南採用“快速參考”風格編寫,幷包含可執行的程式碼示例。您可以在上閱讀,或下載可列印的PDF
  • 增加了從 Web Flow 1 升級到 2 的支援。此分發包中包含一個WebFlowUpgrader工具,能夠將流從 1.0 版本語法轉換為 2.0 版本語法。請參閱參考指南瞭解如何使用此工具的說明。
  • 增加了流定義繼承的支援。透過此功能,一個流可以擴充套件一個或多個流。一個流狀態也可以擴充套件另一個狀態。此功能用於促進共享通用結構的流和狀態之間的重用。
  • 引入了 Spring Portlet MVC 支援。請參閱參考指南的 Portlet 部分以及 booking-mvc-portlet 和 booking-faces-portlet 示例應用程式以獲取示例。
  • 正式引入了新的“Spring Javascript”模組,包含在 spring-js-2.0.0.RC1.jar 中。該模組提供了一個 Javascript 抽象框架,用於以一致的方式應用客戶端行為,例如表單驗證和 Ajax。它還捆綁了一個 ResourceServlet,用於從 jar 檔案(包括 CSS 框架)提供 Javascript 和 CSS。該框架構建的預設 UI 工具包是 Dojo 1。Spring 的 JSF 整合模組稱為“Spring Faces”,它構建在 spring-js 之上,提供了一個輕量級的 JSF 元件庫,用於表單驗證和 Ajax。
  • 增加了 Spring Faces 與 RichFaces JSF 元件庫的整合。Rich Faces 可以與 Spring Faces 元件庫一起使用,也可以獨立使用。我們JIRA 系統提供了一個說明此整合的示例應用程式。
  • 添加了一個“jsf-booking”參考應用程式,該應用程式提供了傳統 JSF Web 應用程式與使用 JSF 作為 UI 元件模型的 Spring Web 應用程式之間的比較。將 jsf-booking 與 booking-faces 進行比較,以瞭解架構方法和實現上的差異。此比較對於有興趣瞭解更多關於 Spring 的 JSF 開發人員尤其重要。
  • 引入了對 Spring MVC 自動模型繫結和驗證的支援。此支援提供了傳統手動 FormAction setupForm 和 bindAndValidate 呼叫的簡潔替代方案。此支援還允許應用程式範圍內註冊資料輸入 Formatters,在許多情況下減少了在檢視之間手動註冊 PropertyEditors 的需要。提供了用於在事件(如取消按鈕點選)時抑制資料繫結的支援。提供了按約定呼叫驗證器的支援。請參閱 booking-mvc 示例。
  • 引入了檢視作用域。檢視作用域在檢視狀態進入時分配,在檢視狀態退出時銷燬。此作用域對於在一系列 Ajax 請求中更新特定於單個檢視的模型很有用。它也是用於管理 JSF 元件狀態的作用域。
  • 增加了對流訊息包的支援。在流的工作目錄中為需要支援的 Locale 建立一個 messages.properties 檔案即可開始使用。
  • 引入了可配置的檢視狀態歷史策略。檢視狀態可以保留其歷史記錄以支援回溯,丟棄其歷史記錄以防止回溯,並使所有先前歷史記錄失效以在不可返回點後禁止回溯。請參閱檢視狀態元素上的新 'history' 屬性。
  • 改進了流執行快照過程。這些改進會在回發時捕獲檢視狀態表單值,以支援在回溯時恢復這些值。這會在使用瀏覽器回退按鈕透過流作用域中儲存的資料進行回退時保留編輯。
  • 透過允許您跳轉到任何狀態來開始測試用例,簡化了流執行測試。請參閱 booking-mvc 和 booking-faces 瞭解流測試用例的示例。
  • 改進了 booking-mvc 作為顯示 @Controllers 和 Flow 的參考應用程式。新的 FlowHandler 概念在 Controller 和 Flow 之間提供了清晰的橋樑,允許這兩種型別的處理程式以結構化的方式進行互動。還改進了參考應用程式 Spring 配置的組織,以說明最佳實踐。
2.0.0 Final 即將到來!盡情享受!

獲取 Spring 新聞通訊

透過 Spring 新聞通訊保持聯絡

訂閱

領先一步

VMware 提供培訓和認證,助您加速進步。

瞭解更多

獲得支援

Tanzu Spring 提供 OpenJDK™、Spring 和 Apache Tomcat® 的支援和二進位制檔案,只需一份簡單的訂閱。

瞭解更多

即將舉行的活動

檢視 Spring 社群所有即將舉行的活動。

檢視所有