恭喜 WebLogic 團隊釋出了 WebLogic 10 預覽版，該版本通過了 Java EE 5 CTS。很高興看到 BEA 在經歷了 J2EE 1.4 的失策之後，重新回到了他們快速行動的傳統。

這對於 Spring 社群來說是一個有趣的訊息，因為 WebLogic 10 內部使用了 Pitchfork。Pitchfork 專案是一個由 Interface21 領導並與 BEA 合作開發的開源專案，它在 Spring 之上實現了 EJB 3.0 攔截和 JSR-250 注入。它被用於 WebLogic 10 EJB 容器內部以及伺服器的其他部分，以滿足新的…

考慮到 Rod 最近關於 Interface 名稱起源的部落格、最近關於 Acegi Security 改名的討論串，以及去年底同事 Ben Hale 關於撰寫“Acegi”名稱起源部落格的建議，我決定是時候寫一篇了！

首先，發音是：“ah-see-gee”。既然我們已經解決了這個問題，下面來說說它來自哪裡

• 回到上世紀 90 年代初，我創辦了一個電子佈告欄系統 (BBS)。我仍然記得使用我的第一臺 300 波特調變解調器，並親眼看著字元以和我閱讀速度相同的速度出現！無論如何，BBS 需要一個名字，我非常喜歡“Midnight BBS”（或者是“Lightning BBS”？）。在嘗試向澳大利亞 BBS 註冊機構註冊我喜歡的名字後，我接到電話被告知該名稱已被佔用。我搜索了另一個名字，沒有發現衝突，並更改了所有的螢幕（有人還記得 Avatar 嗎？）。然後我去用新名字註冊 BBS，儘管其他人剛剛搶在我之前註冊了同一個名字。當時澳大利亞大約有 800 個 BBS——競爭非常激烈！所以，我決定選擇一個保證原創的名字：取自英文字母的第 1、3、5、7 和 9 個字元。於是 Acegi BBS 就誕生了。
• 那是 BBS 的鼎盛時期。它擁有來自澳大利亞各地的呼叫者，也是我們區號中第一個擁有 CD-ROM 似乎無限容量的 BBS。我成為了 Fidonet 的 3:624 網路協調員，並協助在我們區域分發“echomail”。不久之後，人們開始寄送抬頭為“Acegi BBS”的支票，因為他們想要更高的檔案下載限制和訪問 Fidonet 的 netmail。
• 因為我需要兌現名字中包含“Acegi”的支票，所以在 1993 年初我們決定註冊一個公司名稱。Acegi Computer Technology 被選中，人們也樂意相應地填寫支票抬頭。
• 大約在 1995 年，我因工作搬到了悉尼。撥號上網剛剛開始在澳大利亞向公眾開放（調變解調器接入每小時仍然需要大約 5 美元！）。由於 BBS 的大多數使用者來自特定的本地區域，而我正要離開那個區域，所以我把 Acegi BBS 交給了一個朋友繼續運營。他後來也搬家了，又把 BBS 轉給了另一個朋友。之後我就失去了聯絡。我在 Google 上搜索了“Acegi BBS”，甚至找到了一個1995 年的舊記錄。
• 到了 1996 年，我需要一個公司來處理我的 IT 專案，於是 Acegi Technology Pty Limited 誕生了。自那以後，它一直運營至今。
• 大約在 2003 年 11 月，我寫下了最終成為 Acegi Security 的東西。我把它打包成 ZIP 檔案發給了 Rod 和 Juergen。我提議新專案命名為“Spring Security”。然而，他們當時沒有時間全面審查，所以建議我先簡單地將其釋出為“_____ Security System for Spring”。於是，我在名稱前加上了“Acegi”。截至今天，在 Google 上搜索“Acegi”大約有 66 萬個結果，其中幾乎所有都與這個安全框架有關。

現在怎麼辦？名稱的下一階段是一個“分叉”。雖然 Acegi Technology Pty Limited 將繼續運營，但 Acegi Security 將更名為“Spring Security”。我們進行改名有幾個充分的理由。然而，這不僅僅是一個改名行動。實際上，這是一個重新定位，將 Acegi Security 更深入地整合到 Spring 的產品組合中。

對於那些還沒聽說過 Spring 產品組合的人，未來幾個月你們會聽到更多相關資訊。Spring 實際上是一個由相關產品組成的家族，它們在技術和文化層面具有可比性。Spring 產品組合中的每個產品都具有一致的架構質量、關鍵設計模式、程式碼庫、文件、測試覆蓋率、友好的社群、開源許可、整合的示例、釋出路線圖以及來自 Interface21 的商業服務（如深入培訓和支援）的可用性…)

Spring 2.0.1 引入了 AbstractRoutingDataSource。我認為它值得關注，因為（根據客戶常問的問題）我預感有相當一部分“自制”的解決方案正在流傳。考慮到它實現起來微不足道但又容易被忽視，現在我有幾個理由來清理一下我的團隊部落格角落了。

其基本思想是，一個路由 DataSource 充當中間層——而“真正”的 DataSource 可以在執行時根據查詢鍵動態確定。一個潛在的用例是確保標準 JTA 不支援的特定於事務的隔離級別。為此，Spring 提供了一個實現：IsolationLevelDataSourceRouter…

上個月參加 Spring Experience 大會玩得很開心。一個愉快的驚喜是 Spring IDE 團隊最近所做的工作範圍。我在會議上幾次遇到 Spring IDE 開發者 Christian Dupuis，似乎每次他都實現了一個新功能…)

即將釋出的 Spring IDE 2.0 版本是全面更新，以匹配 Spring 2.0 中的新特性。Spring IDE 團隊在兩個重要專案上取得了巨大進展：XML 擴充套件名稱空間和 AOP 增強。（順便說一下，如果你想知道我為什麼有一段時間沒有發文，那是因為我花了很多時間在 InfoQ 上撰寫一篇 Spring 2.0 更新文章…)

一段時間以來，我一直對以客戶端為中心、基於 Web 的使用者介面很感興趣。這些第四代框架的特點是其基於元件、事件驅動的程式設計模型，並專注於將表現層邏輯完全駐留在客戶端。以這種方式針對 Web 瀏覽器通常需要使用 JavaScript 或 Flash，這本身就帶來了一些獨特的挑戰。

如果我們能用 Java 程式設計並自動生成 JavaScript 或 Flash 執行時模組，就可以解決其中的許多挑戰。目前實現這一目標的兩個知名產品分別是 Google Web Toolkit (GWT) 和 Open Laszlo。兩者都在 OSI 批准的許可下可用，並且擁有活躍的社群，同時也有各自獨特的複雜性。一個需要考慮的問題是它們在多大程度上實現了提供一個針對 Web 瀏覽器部署的透明 Java 開發環境的目標。這個考慮因素涉及多個方面，包括 IDE 支援、除錯整合、反射能力、執行時元件繫結等等。所有這些…)

最近我一直在與一位客戶合作處理 WAS 6.1 相關的工作。鑑於我們有很多在 WAS 上使用 Spring 的使用者，並且我需要測試應用程式，我決定是時候在我的一臺工作筆記本上安裝並執行 WAS 了。我說“一臺”是因為我目前同時使用我的 Mac（安裝 OSX）和我的 ThinkPad（安裝 Ubuntu）——最近我主要在使用 ThinkPad，因為我可以讓 Oracle XE 和 WAS 在無需使用 Parallels 這樣的虛擬機器工具的情況下執行。我仍然更喜歡 Mac，但老實說，日常使用上差別不大——我只是想念一些更有用的 Mac 工具，比如 Spotlight、Quicksilver、TextMate 和 NewsFire。

總之，回到主題——在 Ubuntu 上安裝 WAS 6.1。我使用的是 Ubuntu Edgy，我的第一次安裝嘗試完全失敗了，我怎麼也想不明白原因。幸運的是，快速 Google 搜尋找到了這篇文章。我完全不知道/bin/sh被連結到了 dash 而不是 bash——他們到底是怎麼想的。我不太喜歡建議的解決方案，即執行安裝程式，讓它失敗，然後更改安裝目錄中的所有指令碼。相反，我只是重新連結了/bin/sh透過一個快速的sudo unlink /bin/sh然後是sudo ln -s /bin/bash /bin/sh。之後，安裝程式就像做夢一樣順利執行，我在大約 15 分鐘內就完成了 WAS 安裝並啟動了。

即使我的 ThinkPad 同時執行著 Oracle XE，WAS 執行得也相當快。WAS 最好的地方之一是它提供的工具（管理控制檯、命令列工具）非常強大。管理控制檯的效能尤其引人注目——許多其他伺服器的控制檯速度慢得令人痛苦。

在我上一篇博文中，我介紹了一種建立策略類的方法，該方法充分利用了應用程式中存在的任何泛型元資料。在那篇文章的末尾，我展示了這段程式碼片段

EntitlementCalculator calculator = new DividendEntitlementCalculator();
calculator.calculateEntitlement(new MergerCorporateActionEvent());

你會記得DividendEntitlementCalculator被定義為

public class DividendEntitlementCalculator implements EntitlementCalculator<DividendCorporateActionEvent> {

    public void calculateEntitlement(DividendCorporateActionEvent event) {

    }
}

因此，將MergerCorporateActionEvent的例項傳遞給calculateEntitlement方法是不正確的DividendEntitlementCalculator類。然而，正如我在上一篇博文中所說，這段程式碼可以編譯。為什麼？因為EntitlementCalculator.calculateEntitlement()被定義為接受任何繼承自CorporateActionEvent的型別，所以它應該能夠編譯。那麼在這種情況下，執行時會發生什麼，Java 是如何強制執行型別安全的呢？正如你可能想到的，執行這段程式碼會得到一個ClassCastException，表示你無法將MergerCorporateActionEvent轉換為DividendCoporateActionEvent。透過這種方式，Java 可以為你的應用程式強制執行型別安全——不可能將MergerCorporateActionEvent潛入預期接受DividendCorporateActionEvent的方法中。

這裡真正的問題是：“那個ClassCastException來自哪裡？”答案很簡單——Java 編譯器透過引入一個橋接方法（bridge method），適當地添加了建立並丟擲異常的程式碼。橋接方法是編譯器生成的合成方法，會新增到你的類中，以確保在處理泛型型別時的型別安全。

在上面所示的例子中EntitlementCalculator.calculateEntitlement可以接受與CorporateActionEvent型別相容的任何物件進行呼叫。然而，DividendEntitlementCalculator只接受與DividendCorporateActionEvent型別相容的物件，但是，由於你可以透過DividendEntitlementCalculator介面呼叫EntitlementCalculator，它也必須接受CorporateActionEvent。那麼這在編譯後的類檔案中會變成什麼樣呢？我們有使用者提供的方法

public void calculateEntitlement(DividendCorporateActionEvent event) {
    System.out.println(event);
}

這會轉化為這段位元組碼

public void calculateEntitlement(bigbank.DividendCorporateActionEvent);
  Code:
   Stack=2, Locals=2, Args_size=2
   0:   getstatic       #2; //Field java…

前幾天我在客戶現場，他們問了我關於單元測試和模擬物件的問題。我決定將我們討論的一些內容整理成一個教程，介紹如何為單元測試建立依賴項（協作者）。我們討論了兩種選擇，即 stubbing 和 mock objects，並提供了一些簡單的例子來說明它們的用法以及兩種方法的優缺點。

在單元測試中，通常會對被測類的協作者進行 mock 或 stub，以便測試不依賴於協作者的具體實現。這對於…來說也是一項很有用的能力。)

上個月，Rod Johnson 在三次澳大利亞 Spring 使用者組會議上做了一個題為“Spring 2.0 有什麼新酷特性”的演講。Rod 在會議中提到我會提供他的演講稿，所以就在這裡。

還有一些最近的演講，也有人透過郵件詢問我。按隨機順序，這裡是最新的

• 如果你在尋找 Rod 的另一個演講，“使用 AOP 簡化企業應用程式”，你可以直接從悉尼 Java 使用者組網站下載。
• 我在兩次 Enterprise Java Australia 會議上做的關於 Real Object Oriented (ROO) 的演講不會發布。這些幻燈片已經被我在 The Spring Experience 上做的更近期、更詳細的演講所取代。
• 我在 The Spring Experience 上的演講 "快速瞭解 Real Object Oriented (ROO) 應用程式" 將很快釋出在此部落格上。我目前正在製作配套影片。
• 我的演講 "超越唾手可得的成果：域訪問控制列表" 中關於 Acegi Security 1.0.3 新增的 ACL 功能的內容也將在近期釋出在此。同時，Acegi Security 的 SVN 現在包含示例應用程式 (SEC-415)。

希望參加過這些演講的朋友們喜歡。