鑑於 Rod 最近關於 Interface 名稱由來的部落格，以及最近一篇質疑 Acegi Security 更名的文章，以及去年年底我的同事 Ben Hale 建議我寫一篇關於 "Acegi" 名稱由來的部落格，我認為現在可能是時候這樣做了！

首先，發音：是 "ah-see-gee"。現在我們已經知道了這一點，讓我們來看看它是從哪裡來的

• 早在 1990 年代初期，我創建了一個 電子佈告欄系統。 我仍然記得使用我的第一個 300 baud 數據機，並且實際上以我可以閱讀的速度觀看字元出現！無論如何，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 的網路郵件。
• 因為我需要兌現抬頭有 "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"。但是，他們當時沒有時間完全審查它，因此建議我直接將它作為 "Spring 的 _____ 安全系統" 發布。因此，我在名稱中添加了 "Acegi" 作為字首。 截至今天，在 Google 上搜尋 "Acegi" 大約有 660,000 個結果，幾乎所有結果都與安全框架有關。

接下來去哪裡？ 下一個階段的名稱是 "fork"。雖然 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，似乎每次他都實現了一個新功能...

即將發布的 2.0 版本的 Spring IDE 是一個全面的更新，可以匹配 Spring 2.0 中的新功能。 並且 Spring IDE 團隊正在兩個重要項目上取得重大進展：XML 擴展命名空間和 AOP 增強功能。 （順便說一句，如果您想知道我為什麼有一段時間沒有發布文章，我花了很多時間在 InfoQ 上撰寫一篇 Spring 2.0 更新文章...

一段時間以來，我一直對以客戶端為中心的基於 Web 的用戶界面感興趣。 這些第 IV 代框架的特點是它們基於元件、事件驅動的程式設計模型，並且專注於完全駐留在客戶端上的呈現邏輯。 以這種方式定位 Web 瀏覽器通常需要使用 JavaScript 或 Flash，這本身就帶來了許多獨特的挑戰。

如果我們可以用 Java 程式設計並自動產生 JavaScript 或 Flash 運行時模組，則可以解決許多這些挑戰。 今天實現這一目標的兩個著名產品分別是 Google Web Toolkit (GWT) 和 Open Laszlo。 兩者都在 OSI 批准的許可證下可用，並且擁有活躍的社群，以及它們自己獨特的複雜性。 一個考慮因素是它們在多大程度上滿足了提供一個透明的基於 Java 的開發環境的目標，該環境針對 Web 瀏覽器部署。 這個考慮因素有幾個方面，包括 IDE 支援、偵錯整合、反射能力、運行時 widget 綁定等。 所有這些...

最近我一直在與一位客戶在 WAS 6.1 上進行一些工作。 由於我們在 WAS 上有許多 Spring 用戶，並且我需要測試該應用程式，因此我決定是時候在我的其中一台工作筆記型電腦上運行一個 WAS 副本了。 我說 "其中一台" 是因為我目前同時在我的 Mac（使用 OSX）和我的 ThinkPad（使用 Ubuntu）上工作——最近我一直在使用 ThinkPad，因為我可以在沒有像 Parallels 這樣的 VM 工具的情況下運行 Oracle XE 和 WAS。 我仍然更喜歡 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 編譯器會添加程式碼來建立並拋出它，方法是引入一個橋接方法。 橋接方法是編譯器將產生並添加到你的類別中的合成方法，以確保在面對泛型類型時的類型安全。

在上面顯示的情況中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…

前幾天我和一些客戶在現場，他們問我關於單元測試和 Mock 物件。 我決定寫下我們討論的一些內容，作為建立用於單元測試的依賴項（協作者）的教學。 我們討論了兩個選項，Stub 和 Mock 物件，並提供了一些簡單的例子來說明用法以及兩種方法的優缺點。

在單元測試中，Mock 或 Stub 被測試類別的協作者是很常見的，這樣測試才能獨立於協作者的實作。 能夠做到這一點也是很有用的…

上個月，Rod Johnson 在三次澳大利亞 Spring 用戶組會議上發表了一個題為“Spring 2.0 的新功能和酷炫功能”的演講。 Rod 在這些會議中提到我會提供他的演示文稿，所以這裡有。

還有一些其他人最近通過電子郵件發給我的演示文稿。 沒有任何特定的順序，這是最新的

• 如果你正在尋找 Rod 的另一個演講“使用 AOP 簡化企業應用程式”，你可以直接從雪梨 Java 用戶組網站下載它。
• 我在兩次澳大利亞企業 Java 會議上發表的 Real Object Oriented (ROO) 演講將不會公開。 這些幻燈片已被我在Spring Experience上發表的更近期和更詳細的演講所取代。
• 我在 The Spring Experience 上的“快速跳入真實物件導向 (ROO) 應用程式”的演講將很快在此部落格上發布。 我目前正在製作一個與之搭配的影片。
• 我關於 Acegi Security 1.0.3 的新 ACL 功能的報導，將在我的 "超越唾手可得的成果：網域存取控制清單”的演講中一併發布。 同時，Acegi Security SVN 現在包含範例應用程式 (SEC-415)。

對於那些參加過演講的人，我希望你喜歡它們。

幾週前，我發表了一篇關於 Spring 名稱由來的部落格。 我們也收到很多關於 Interface21 這個名稱由來的問題。

對於任何讀過我的書或考慮過 Spring 設計的人來說，interface 部分並不令人意外。 它既使用了介面的 OO 概念（我一直對此深愛），也使用了系統介面的概念。 例如，將 Web 介面放到現有的綠屏系統上 - 這正是我第一次想到公司名稱時正在做的事情。

到目前為止，一切都很好。 真正的問題是數字。

與 Spring 這個名稱一樣，一些理論比真實的解釋更有趣。 所以讓我們從我聽到的關於 21 的理論開始……