使用 AppFuse 的七個理由

[url]http://www.ibm.com/developerworks/cn/java/j-appfuse/[/url]

使用 AppFuse 快速構建 J2EE 應用 [url]http://www.ibm.com/developerworks/cn/java/j-lo-appfuse/[/url]

AppFuse 是一個開放原始碼的專案和應用程式，它使用了在 Java 平臺上構建的開放原始碼工具來幫助我們快速而高效地開發 Web 應用程式。我最初開發它是為了減少在為客戶構建新 Web 應用程式時所花費的那些不必要的時間。從核心上來說，AppFuse 是一個專案骨架，類似於通過嚮導建立新 Web 專案時 IDE 所建立的東西。當我們使用 AppFuse 建立一個專案時，它會提示我們將使用開放原始碼框架，然後才建立專案。它使用 Ant 來驅動測試、程式碼生成、編譯和部署。它提供了目錄和包結構，以及開發基於 Java 語言的 Web 應用程式所需要的庫。
與大部分 “new project” 嚮導不同，AppFuse 建立的專案從最開始就包含很多類和檔案。這些檔案用來實現特性，不過它們同時也會在您開發應用程式時被用作示例。通過使用 AppFuse 啟動新專案，我們通常可以減少一到兩週的開發時間。我們不用擔心如何將開放原始碼框架配置在一起，因為這都已經完成了。我們的專案都已提前配置來與資料庫進行互動，它會部署到應用伺服器上，並對使用者進行認證。我們不必實現安全特性，因為這都早已整合了。
當我最初開發 AppFuse 時，它只支援 Struts 和 Hibernate。經過幾年的努力，我發現了比 Struts 更好的 Web 框架，因此我還新增了為這些 Web 框架使用的選項。現在，AppFuse 可以支援 Hibernate 或 iBATIS 作為永續性框架。對於 Web 框架來說，我們可以使用 JavaServer Faces（JSF）、Spring MVC、Struts、Tapestry 或 WebWork。
AppFuse 提供了很多應用程式需要的一些特性，包括：
認證和授權
使用者管理
Remember Me（這會儲存您的登入資訊，這樣就不用每次都再進行登入了）
密碼提醒
登記和註冊
SSL 轉換
E-mail
URL 重寫
皮膚
頁面修飾
模板化佈局
檔案上載
這種 “開箱即用” 的功能是 AppFuse 與其他 CRUD 代 框架的區別之一（CRUD 取自建立、檢索、更新 和刪除 幾個操作的英文首字母），包括 Ruby on Rails、Trails 和 Grails。上面提到的這些框架，以及 AppFuse，都讓我們可以從資料庫表或現有的模型物件中生成主頁/細節頁。
圖 1 闡述了一個典型 AppFuse 應用程式的概念設計：

圖 1. 典型的 AppFuse 應用程式
[img]http://www.ibm.com/developerworks/cn/java/j-appfuse/appfuse_application.gif[/img]

清單 1 給出了我們在建立 devworks 專案時所使用的命令列互動操作，同時還給出了所生成的結果。這個專案使用了 WebWork 作為自己的 Web 框架（請參考下面 參考資料 一節給出的連結）。

清單 1. 使用 AppFuse 建立新專案
alotta:~/dev/appfuse mraible$ ant new
Buildfile: build.xml
clean:
[echo] Cleaning build and distribution directories

init:
new:
[echo]
[echo] +-------------------------------------------------------------+
[echo] | -- Welcome to the AppFuse New Application Wizard! -- |
[echo] | |
[echo] | To create a new application, please answer the following |
[echo] | questions. |
[echo] +-------------------------------------------------------------+

[input] What would you like to name your application [myapp]?
devworks
[input] What would you like to name your database [mydb]?
devworks
[input] What package name would you like to use [org.appfuse]?
com.ibm
[input] What web framework would you like to use [webwork,tapestry,spring,js
f,struts]?
webwork
[echo] Creating new application named 'devworks'...
[copy] Copying 359 files to /Users/mraible/Work/devworks
[copy] Copying 181 files to /Users/mraible/Work/devworks/extras
[copy] Copying 1 file to /Users/mraible/Work/devworks
[copy] Copying 1 file to /Users/mraible/Work/devworks

install:
[echo] Copying WebWork JARs to ../../lib
[copy] Copying 6 files to /Users/mraible/Work/devworks/lib
[echo] Adding WebWork entries to ../../lib.properties
[echo] Adding WebWork classpath entries
[echo] Removing Struts-specific JARs
[delete] Deleting directory /Users/mraible/Work/devworks/lib/struts-1.2.9
[delete] Deleting directory /Users/mraible/Work/devworks/lib/strutstest-2.1.3
[echo] Deleting struts_form.xdt for XDoclet
[delete] Deleting directory /Users/mraible/Work/devworks/metadata/templates
[echo] Deleting Struts merge-files in metadata/web
[delete] Deleting 7 files from /Users/mraible/Work/devworks/metadata/web
[echo] Deleting unused Tag Libraries and Utilities
[delete] Deleting 2 files from /Users/mraible/Work/devworks/src/web/org/appfu
se/webapp
[echo] Modifying appgen for WebWork
[copy] Copying 12 files to /Users/mraible/Work/devworks/extras/appgen
[echo] Replacing source and test files
[delete] Deleting directory /Users/mraible/Work/devworks/src/web/org/appfuse/
webapp/form
[delete] Deleting directory /Users/mraible/Work/devworks/src/web/org/appfuse/
webapp/action
[copy] Copying 13 files to /Users/mraible/Work/devworks/src
[delete] Deleting directory /Users/mraible/Work/devworks/test/web/org/appfuse
/webapp/form
[delete] Deleting directory /Users/mraible/Work/devworks/test/web/org/appfuse
/webapp/action
[copy] Copying 5 files to /Users/mraible/Work/devworks/test
[echo] Replacing web files (images, scripts, JSPs, etc.)
[delete] Deleting 1 files from /Users/mraible/Work/devworks/web/scripts
[copy] Copying 34 files to /Users/mraible/Work/devworks/web
[delete] Deleting: /Users/mraible/Work/devworks/web/WEB-INF/validator-rules-c
ustom.xml
[echo] Modifying Eclipse .classpath file
[echo] Refactoring build.xml
[echo] ----------------------------------------------
[echo] NOTE: It's recommended you delete extras/webwork as you shouldn't ne
ed it anymore.
[echo] ----------------------------------------------
[echo] Repackaging info written to rename.log
[echo]
[echo] +-------------------------------------------------------------+
[echo] | -- Application created successfully! -- |
[echo] | |
[echo] | Now you should be able to cd to your application and run: |
[echo] | > ant setup test-all |
[echo] +-------------------------------------------------------------+

BUILD SUCCESSFUL
Total time: 15 seconds
在建立一個新專案之後，我們就得到了一個類似於圖 2 所示的目錄結構。Eclipse 和 Intellij IDEA 專案檔案都是作為這個過程的一部分建立的。

圖 2. 專案的目錄結構
[img]http://www.ibm.com/developerworks/cn/java/j-appfuse/project_directory_structure.jpg[/img]

這個目錄結構與 Sun 為 Java 2 Platform Enterprise Edition（J2EE）Web 應用程式推薦的目錄結構非常類似。在 2.0 版本的 AppFuse 中，這個結構會變化成適合 Apache Maven 專案的標準目錄結構（有關這兩個目錄介紹的內容，請參看 參考資料 中的連結）。AppFuse 還會從 Ant 遷移到 Maven 2 上，從而獲得相關下載的能力和對生成 IDE 專案檔案的支援。目前基於 Ant 的系統要求提交者維護專案檔案，而 Maven 2 可以通過簡單地使用專案的 pom.xml 檔案生成 IDEA、Eclipse 和 NetBeans 專案檔案。（這個檔案位於您專案的根目錄中，是使用 Maven 構建應用程式所需要的主要元件）。它與利用 Ant 所使用的 build.xml 檔案非常類似。）
現在我們對 AppFuse 是什麼已經有一點概念了，在本文剩下的部分中，我們將介紹使用 AppFuse 的 7 點理由。即使您選擇不使用 AppFuse 來開始自己的專案，也會看到 AppFuse 可以為您提供很多樣板程式碼，這些程式碼可以在基於 Java 語言的 Web 應用程式中使用。由於它是基於 Apache 許可證的，因此非常歡迎您在自己的應用程式中重用這些程式碼。


[color=red][b]理由 1：測試[/b][/color]
測試是在軟體開發專案中很少被給予足夠信任的一個環節。注意我並不是說在軟體開發的一些刊物中沒有得到足夠的信任！很多文章和案例研究都給出了測試優先的開發方式和足夠的測試覆蓋面以提高軟體的質量。然而，測試通常都被看作是一件只會延長專案開發時間的事情。實際上，如果我們使用測試優先的方法在編寫程式碼之前就開始撰寫測試用例，我相信我們可以發現這實際上會加速 開發速度。另外，測試優先也可以使維護和重用更加 容易。如果我們不編寫程式碼來測試自己的程式碼，那麼就需要手工對應用程式進行測試 —— 這通常效率都不高。自動化才是關鍵。
當我們首次開始使用 AppFuse 時，我們可能需要閱讀這個專案 Web 站點上提供的快速入門指南和教程（請參看 參考資料 中的連結）。這些教程的編寫就是為了您可以首先編寫測試用例；它們直到編寫介面和/或實現之後才能編譯。如果您有些方面與我一樣，就會在開始編寫程式碼之前就已經編寫好測試用例了；這是真正可以加速編寫程式碼的惟一方式。如果您首先編寫了程式碼的實現，通過某種方式驗證它可以工作，那麼您可能會對自己說，“哦，看起來不錯 —— 誰需要測試呢？我還有更多的程式碼需要編寫！”這種情況不幸的一面是您通常都會做一些事情 來測試自己的程式碼；您簡單地跳過了可以自動化進行測試的地方。
AppFuse 的文件展示瞭如何測試應用程式的所有 層次。它從資料庫層開始入手，使用了 DbUnit（請參看 參考資料）在執行測試之前提前使用資料來填充自己的資料庫。在資料訪問（DAO）層，它使用了 Spring 的 AbstractTransactionalDataSourceSpringContextTests 類（是的，這的確是一個類的名字！）來允許簡單地載入 Spring 上下文檔案。另外，這個類對每個 testXXX() 方法封裝了一個事務，並當測試方法存在時進行回滾。這種特性使得測試 DAO 邏輯變得非常簡單，並且不會對資料庫中的資料造成影響。
在服務層，jMock （請參看 參考資料）用來編寫那些可以消除 DAO 依賴的真正 單元測試。這允許進行驗證業務邏輯正確的快速測試；我們不用擔心底層的永續性邏輯。

在 Web 層，測試會驗證操作（Struts/WebWork）、控制元件（Spring MVC）、頁面（Tapestry）和管理 bean（JSF）如我們所期望的一樣進行工作。Spring 的 spring-mock.jar 可以非常有用地用來測試所有這些框架，因為它包含了一個 Servlet API 的模擬實現。如果沒有這個有用的庫，那麼測試 AppFuse 的 Web 框架就會變得非常困難。
UI 通常是開發 Web 應用程式過程中最為困難的一部分。它也是顧客最經常抱怨的地方 —— 這既是由於它並不是非常完美，也是由於它的工作方式與我們期望的並不一樣。另外，沒有什麼會比在客戶面前作演示的過程中看到看到異常堆疊更糟糕的了！您的應用程式可能會非常可怕，但是客戶可能會要求您做到十分完美。永遠不要讓這種事情發生。Canoo WebTest 可以對 UI 進行測試。它使用了 HtmlUnit 來遍歷測試 UI，驗證所有的元素都存在，並可以填充表單的域，甚至可以驗證一個假想的啟用 Ajax 的 UI 與我們預期的工作方式一樣。（有關 WebTest 和 HTMLUnit 的連結請參看 參考資料。）
為了進一步簡化 Web 的測試，Cargo（請參看 參考資料）對 Tomcat 的啟動和停止（分別在執行 WebTest 測試之前和之後）進行了自動化。

[color=red][b]理由 2：整合[/b][/color]
正如我在本文簡介中提到的一樣，很多開放原始碼庫都已經預先整合到 AppFuse 中了。它們可以分為以下幾類：
編譯、報告和程式碼生成：Ant、Ant Contrib Tasks、Checkstyle、EMMA、Java2Html、PMD 和 Rename Packages
測試框架：DbUnit、Dumbster、jMock、JUnit 和 Canoo WebTest
資料庫驅動程式：MySQL 和 PostgreSQL
永續性框架：Hibernate 和 iBATIS
IoC 框架：Spring
Web 框架：JSF、Spring MVC、Struts、Tapestry 和 WebWork
Web 服務：XFire
Web 工具：Clickstream、Display Tag、DWR、JSTL、SiteMesh、Struts Menu 和 URL Rewrite Filter
Security：Acegi Security
JavaScript 和 CSS：Scriptaculous、Prototype 和 Mike Stenhouse 的 CSS Framework
除了這些庫之外，AppFuse 還使用 Log4j 來記錄日誌，使用 Velocity 來構建 e-mail 和選單模板。Tomcat 可以支援最新的開發，我們可以使用 1.4 或 5 版本的 Java 平臺來編譯或構建程式。我們應該可以將 AppFuse 部署到任何 J2EE 1.3 相容的應用伺服器上；這已經經過了測試，我們知道它在所有主要版本的 J2EE 伺服器和所有主要的 servlet 容器上都可以很好地工作。
圖 3 給出了上面建立的 devworks 專案的 lib 目錄。這個目錄中的 lib.properties 檔案控制了每個依賴性的版本號，這意味著我們可以簡單地通過把這些包的新版本放到這個目錄中並執行諸如 ant test-all -Dspring.version=2.0 之類的命令來測試這些包的新版本。

圖 3. 專案依賴性
[img]http://www.ibm.com/developerworks/cn/java/j-appfuse/project_lib_directory.jpg[/img]

預先整合這些開放原始碼庫可以在專案之初極大地提高生產效率。儘管我們可以找到很多文件介紹如何整合這些庫，但是定製工作示例並簡單地使用它來開發應用程式要更加簡單。
除了可以簡化 Web 應用程式的開發之外，AppFuse 讓我們還可以將 Web 服務簡單地整合到自己的專案中。儘管 XFire 也在 AppFuse 下載中一起提供了，不過如果我們希望，也可以自己整合 Apache Axis（請參看 參考資料 中有關 Axis 整合的教程）。另外，Spring 框架和 XFire 可以一起將服務層作為 Web 服務非常簡單地呈現出來，這就為我們提供了開發面向服務架構的能力。
另外，AppFuse 並不會將我們限定到任何特定的 API 上。它只是簡單地對可用的最佳開放原始碼解決方案重新進行打包和預先整合。AppFuse 中的程式碼可以處理這種整合，並實現了 AppFuse 的基本安全性和可用性特性。只要可能，就會減少程式碼，以便向 AppFuse 的依賴框架新增一個特性。例如，AppFuse 自帶的 Remember Me 和 SSL 切換特性最近就因為類似的特性而從 Acegi Security 中刪除了。

[color=red][b]理由 3：自動化[/b][/color]
Ant 使得簡化了從編譯到構建再到部署的自動化過程。Ant 是 AppFuse 中的一等公民，這主要是因為我發現在命令列中執行操作比從 IDE 中更加簡單。我們可以使用 Ant 實現編譯、測試、部署和執行任何程式碼生成的任務。
儘管這種能力對於有些人來說非常重要，但是它並不適用於所有的人。很多 AppFuse 使用者目前都使用 Eclipse 或 Intellij IDEA 來構建和測試自己的專案。在這些 IDE 中執行 Ant 的確可以工作，但是這樣做的效率通常都不如使用 IDE 內建的 JUnit 支援來執行測試效率高。
幸運的是，AppFuse 支援在 IDE 中執行測試，不過管理這種特性對於 AppFuse 開發人員來說就變得非常困難了。最大的痛苦在於 XDoclet 用來生成 Hibernate 對映檔案和 Web 框架所使用的一些工件（例如 ActionForms 和 Struts 使用的 struts-config.xml）。IDE 並不知道需要生成的程式碼，除非我們配置使用 Ant 來編譯它們，或者安裝了一些可以認識 XDoclet 的外掛。
這種對知識的缺乏是 AppFuse 2.0 切換到 JDK 5 和 Maven 2 上的主要原因。JDK 5、註釋和 Struts 2 將讓我們可以擺脫 XDoclet。Maven 2 將使用這些生成的檔案和動態類路徑來生成 IDE 專案檔案，這樣對專案的管理就可以進行簡化。目前基於 Ant 的編譯系統已經為不同的層次生成了一些工件（包括 dao.jar、service.jar 和 webapp.war），因此切換到 Maven 的模型上應該是一個非常自然的調整。
除了 Ant 之外（它對於編譯、測試、部署和報告具有豐富的支援），對於 CruiseControl 的支援也構建到了 AppFuse 中。CruiseControl 是一個 Continuous Integration 應用程式，讓我們可以在原始碼倉庫中程式碼發生變化時自動執行所有的測試。extras/cruisecontrol 目錄包含了我們為基於 AppFuse 的專案快速、簡單地設定 Continuous Integration 時所需要的檔案。
設定 Continuous Integration 是軟體開發週期中我們首先要做的事情之一。它不但激發程式設計師去編寫測試用例，而且還通過 “You broke the build!” 遊戲促進了團隊之間的合作和融合。


[color=red][b]理由 4：安全特性和可擴充套件性[/b][/color]
AppFuse 最初是作為我為 Apress 編寫的書籍 Pro JSP 中示例應用程式的一部分開發的。這個示例應用程式展示了很多安全特性和用於簡化 Struts 開發的特性。這個應用程式中的很多安全特性在 J2EE 的安全框圖中都不存在。使用容器管理認證（CMA）的認證方法非常簡單，但是 Remember Me、密碼提示、SSL 切換、登記和使用者管理等功能卻都不存在。另外，基於角色的保護方法功能在非 EJB 環境中也是不可能的。
最初，AppFuse 使用自己的程式碼和用於 CMA 的解決方案完全實現了這些特性。我在 2004 年年初開始學習 Spring 時就聽說過有關 Acegi Security 的知識。我對 Acegi 所需要的 XML 的行數（175）與 web.xml 中所需要的 CMA 的行數（20）進行了比較，很快就決定丟棄 Acegi 了，因為它太過複雜了。
一年半之後 —— 在為另外一本書 Spring Live 中編寫了一章有關使用 Acegi Security 的內容之後 —— 我就改變了自己的想法。Acegi 的確（目前仍然）需要很多 XML，但是一旦我們理解了這一點，它實際上是相當簡單的。當我們最終作出改變，使用 Acegi Security 的特性來全部取代 AppFuse 的特性之後，我們最終刪除了大量的程式碼。類之上的類都已經沒有了，“Acegi handles that now” 中消失的部分現在全部進入了 CVS 的 Attic 中了。
Acegi Security 是 J2EE 安全模型中曾經出現過的最好模型。它讓我們可以實現很多有用的特性，這些特性在 Servlet API 的安全模型中都不存在：認證、授權、角色保護方法、Remember Me、密碼加密、SSL 切換、使用者切換和登出。它讓我們還可以將使用者證照儲存到 XML 檔案、資料庫、LDAP 或單點登入系統（例如 Yale 的 Central Authentication Service (CAS) 或者 SiteMinder）中。
AppFuse 對很多與安全性相關的特性的實現從一開始都是非常優秀的。現在 AppFuse 使用了 Acegi Security，這些特性 —— 以及更多特性 —— 都非常容易實現。Acegi 有很多地方都可以進行擴充：這是它使用巨大的 XML 配置檔案的原因。正如我們已經通過去年的課程對 Acegi 進行整合一樣，我們已經發現對很多 bean 的定義進行定製可以更加緊密地與 AppFuse 建立聯絡。
Spring IoC 容器和 Acegi Security 所提供的簡單開發、容易測試的程式碼和鬆耦合特性的組合是 AppFuse 是這麼好的一種開發平臺的主要原因。這些框架都是不可插入的，允許生成乾淨的可測試程式碼。AppFuse 整合了很多開放原始碼專案，依賴注入允許對應用程式層進行簡單的整合。


[color=red][b]理由 5：使用 AppGen 生成程式碼[/b][/color]
有些人會將程式碼生成稱為程式碼氣味的散播（code smell）。在他們的觀點中，如果我們需要生成程式碼，那麼很可能就會做一些錯事。我傾向於這種確定自己程式碼使用的模式和自動化生成程式碼的能力應該稱為程式碼香味的瀰漫（code perfume）。如果我們正在編寫類似的 DAO、管理器、操作或控制元件，並且不想為它們生成程式碼，那麼這就需要根據程式碼的氣味來生成程式碼。當然，當語言可以為我們提供可以簡化任務的特性時，一切都是那麼美好；不過程式碼生成通常都是一個必需 —— 通常其生產率也非常高 —— 的任務。
AppFuse 中提供了一個基於 Ant 和 XDoclet 的程式碼生成工具，名叫 AppGen。預設情況下，常見的 DAO 和管理器都可以允許我們對任何普通老式 Java 物件（POJO）進行 CRUD 操作，但是在 Web 層上這樣做有些困難。AppGen 有幾個特性可以用來執行以下任務：
（使用 Middlegen 和 Hibernate 工具）從資料庫表中生成 POJO
從 POJO 生成 UI
為 DAO、管理器、操作/控制器和 UI 生成測試
在執行 AppGen 時，您會看到提示說 AppGen 要從資料庫表或 POJO 中生成程式碼。如果在命令列中執行 ant install-detailed，AppGen 就會安裝 POJO 特定的 DAO、管理器以及它們的測試。執行 ant install 會導致 Web 層的類重用通用的 DAO 和預設存在的管理器。
為了闡述 AppGen 是如何工作的，我們在 devworks MySQL 資料庫中建立瞭如清單 2 所示的表：

清單 2. 建立一個名為 cat 的資料庫表

create table cat (
cat_id int(8) auto_increment,
color varchar(20) not null,
name varchar(20) not null,
created_date datetime not null,
primary key (cat_id)
) type=InnoDB;

在 extras/appgen 目錄中，執行 ant install-detailed。這個命令的輸出結果對於本文來說實在太長了，不過我們在清單 3 中給出了第一部分的內容：

清單 3. 執行 AppGen 的 install-detailed 目標

$ ant install-detailed
Buildfile: build.xml

init:
[mkdir] Created dir: /Users/mraible/Work/devworks/extras/appgen/build
[echo]
[echo] +-------------------------------------------------------+
[echo] | -- Welcome to the AppGen! -- |
[echo] | |
[echo] | Use the "install" target to use the generic DAO and |
[echo] | Manager, or use "install-detailed" to general a DAO |
[echo] | and Manager specifically for your model object. |
[echo] +-------------------------------------------------------+

[input] Would you like to generate code from a table or POJO? (table,pojo)
table
[input] What is the name of your table (i.e. person)?
cat
[input] What is the name, if any, of the module for your table (i.e. organization)?

[echo] Running Middlegen to generate POJO...

要對 cat 表使用這個新生成的程式碼，我們需要修改 src/dao/com/ibm/dao/hibernate/applicationContext-hibernate.xml，來為 Hibernate 新增 Cat.hbm.xml 對映檔案。清單 3 給出了我們修改後的 sessionFactory bean 的樣子：

清單 4. 將 Cat.hbm.xml 新增到 sessionFactory bean 中

<bean id="sessionFactory" class="...">
<property name="dataSource" ref="dataSource"/>
<property name="mappingResources">
<list>
<value>com/ibm/model/Role.hbm.xml</value>
<value>com/ibm/model/User.hbm.xml</value>
<value>com/ibm/model/Cat.hbm.xml</value>
</list>
</property>
...
</bean>

在執行 ant setup deploy 之後，我們就應該可以在部署的應用程式中對 cat 表執行 CRUD 操作了：

圖 4. Cat 列表
[img]http://www.ibm.com/developerworks/cn/java/j-appfuse/cat_list.jpg[/img]


圖 5. Cat 表單
[img]http://www.ibm.com/developerworks/cn/java/j-appfuse/cat_detail.jpg[/img]

我們在上面的螢幕快照中看到的記錄都是作為程式碼生成的一部分建立的，因此現在就有測試資料了。


[color=red][b]理由 6：文件[/b][/color]
我們可以找到 AppFuse 各個風味的教程，並且它們都以 6 種不同的語言給出了：中文、德語、英語、韓語、葡萄牙語和西班牙語。使用風味（flavor） 一詞，我的意思是不同框架的組合，例如 Spring MVC 加上 iBATIS、Spring MVC 加上 Hibernate 或 JSF 加上 Hibernate。使用這 5 種 Web 框架和兩種持久框架，可以有好幾種組合。有關它們的翻譯，AppFuse 為自己的預設特性提供了 8 種翻譯。可用語言包括中文、荷蘭語、德語、英語、法語、義大利語、葡萄牙語和西班牙語。
除了核心教程之外，還新增了很多教程（請參看 參考資料） 來介紹與各種資料庫、應用伺服器和其他開放原始碼技術（包括 JasperReports、Lucene、Eclipse、Drools、Axis 和 DWR）的整合。


[color=red][b]理由 7：社群[/b][/color]
Apache 軟體基金會對於開放原始碼有一個有趣的看法。它對圍繞開放原始碼專案開發一個開放原始碼社群最感興趣。它的成員相信如果社群非常強大，那麼產生高質量的程式碼就是一個自然的過程。下面的內容引自 Apache 主頁：
“我們認為自己不僅僅是一組共享伺服器的專案，而且是一個開發人員和使用者的社群。”
AppFuse 社群從 2003 年作為 SourceForge 上的一個專案（是 struts.sf.net 的一部分）啟動以來，已經獲得了極大的增長。通過在 2004 年 3 月轉換到 java.net 上之後，它已經成為這裡一個非常流行的專案，從 2005 年 1 月到 3 月成為訪問量最多的一個專案。目前它仍然是一個非常流行的專案（有關 java.net 專案統計資訊的連結，請參看 參考資料），不過在這個站點上它正在讓位於 Sun 贊助的很多專案。
在 2004 年年末，Nathan Anderson 成為繼我之後第一個提交者。此後有很多人都加入了進來，包括 Ben Gill、David Carter、Mika G?ckel、Sanjiv Jivan 和 Thomas Gaudin。很多現有的提交者都已經通過各種方式作出了自己的貢獻，他們都幫助 AppFuse 社群成為一個迅速變化並且非常有趣的地方。
郵件列表非常友好，我們試圖維護這樣一條承諾 “沒有問題是沒有人理會的問題”。我們的郵件列表歸檔檔案中惟一一條 “RTFM” 是從使用者那裡發出的，而不是從開發者那裡發出的。我們絕對信奉 Apache 開放原始碼社群的哲學。引用我最好的朋友 Bruce Snyder 的一句話，“我們為程式碼而來，為人們而留下”。目前，大部分開發者都是使用者，我們通常都喜歡有一段美妙的時間。另外，大部分文件都是由社群編寫的；因此，這個社群的知識是非常淵博的。


[color=red][b]結束語[/b][/color]
我們應該嘗試使用 AppFuse 進行開發，這是因為它允許我們簡單地進行測試、整合、自動化，並可以安全地生成 Web 應用程式。其文件非常豐富，社群也非常友好。隨著其支撐框架越來越好，AppFuse 也將不斷改進。
從 AppFuse 2.0 開始，我們計劃遷移到 JDK 5（仍然支援部署到 1.4）和 Maven 2 上去。這些工具可以簡化使用 AppFuse 的開發、安裝和升級。我們計劃充分利用 Maven 2 的功能來處理相關依賴性。我們將碰到諸如 appfuse-hibernate-2.0.jar 和 appfuse-jsf-2.0.jar 之類的工件。這些工件都可以在 pom.xml 檔案中進行引用，它們負責提取其他相關依賴性。除了在自己的專案中使用 AppFuse 基類之外，我們還可以像普通的框架一樣在 JAR 中對這些類簡單地進行擴充套件，這應該會大大簡化它的升級過程，並鼓勵更多使用者將自己希望的改進提交到這個專案中。
如果沒有其他問題，使用 AppFuse 可以讓您始終處於 Java Web 開發的技術前沿上 —— 就像我們一樣！