從 JBoss 4.2.x 升級到 JBoss 5.x、6.x、7.x 和 WildFly 8.x 的好處（和提示）？

Question

請假設我不需要擔心開發時間和成本：我對一般技術優勢（改進的性能？改進的 API？）和新功能感興趣。

我目前正在開發使用 4.2.x 的產品，我們考慮對那些需要很長時間並且需要融合的版本進行重大轉變。

我簡要查看了每個版本的發行說明以及關於 5.x、6.x、7.x 和 8.x 的每個版本的一些文章。 但我很高興能從做出轉換的人那里獲得第一手反饋。

我注意到圍繞消息傳遞有一些重要的變化（從 JBoss MQ 切換到 JBoss 消息傳遞），而對於 Z7345F7045E4668138112C100F25517A4 層的配置似乎有所改變。 然后在切換到 JBoss/WildFly 8.x 時還有很多事情要做。

如果可以的話，請推薦指出陷阱的好文章。 我找到了一些遷移到 JBoss 5.x 的工具，但對於 6.x 甚至 7.x 來說並沒有那么多，現在其他人正在為我們評估 8.x。 如果您認為它們相關，也可以隨意推薦替代品，但我更願意只關注 JBoss。

有關信息，我們混合使用了基於 JPF 和 OSGi（使用 Eclipse Equinox）插件的系統，以及在 Swing 中開發的客戶端（一些通過 WebStart 部署）。

更新：雖然這個問題已經帶來了一些很好的答案，但我認為它值得為 WildFly 更新（實際上，我們的內部項目推遲了從 4.2.x 到 7.x 的切換，因為原計划等待 WildFly）。 歡迎新的想法和答案。

Answer 1

我已經從 JBoss 4 升級到 5，根據經驗，以下是最需要注意的：

• JBoss 5（和 6 和 7）不如 JBoss 4 和 XML 文件那樣寬容。 您必須確保所有部署描述符 XML 文件都是有效的。 您可能在某些文件中使用了 DTD - 我建議將這些文件升級為使用 XML 架構。
• 某些庫可能會導致不兼容。 如果您訪問 web 服務和/或執行 XML 解析，則尤其如此
• 如果您在 JBoss 4 中預編譯您的 JSP，您可能無法在 JBoss 6/7 中進行編譯。
• JBoss 4 和 5 使用不同的消息隊列實現。 如果您定義了任何消息隊列或主題，則需要重新定義它們。
• JBoss TreeCache 不再使用。 如果將其用於緩存目的，則需要更改為使用新的 JBoss 緩存。
• JBoss 5 安全性不同。 如果您的遠程客戶端需要對 JBoss 的安全訪問，您將需要對它們進行不同的配置。

一些有用的資源是：

https://dzone.com/articles/migrating-jboss-4-jboss-5 http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga

官方 JBoss 6 僅通過 Java EE Web 配置文件認證，因此如果您使用“舊版”功能，例如 EJB。2 可能不支持它們。 根據您的應用程序的生命周期，這可能是也可能不是問題。 JBoss 6 目前完全支持 EJB2.1，但未對此進行認證。

I have also found that JBoss 5 handles memory a lot better that JBoss 4. With JBoss 4 I see a lot more PermGen errors than I do with JBoss 5.

Answer 2

我只能從 JBoss 5.1.0 的生產經驗和對版本 6 的一些調查中發言。

JBoss 5 is Java EE 5 and JBoss 6 and 7 are Java EE 6 . API 功能的差異在這些規范中得到了最好的記錄。 JBoss 6 可能保質期很短； 它僅針對 Java EE 6 web 配置文件進行了認證，並且錯誤修復針對的是第 7 版（在撰寫本文時的第 3 個測試版）。

我認為您會在 JBoss 社區論壇上獲得更好的答案。

Answer 3

我們從 JBoss AS 5 升級到 JBoss AS 7 並着眼於 WildFly AS 8.1。 現在我們不能遷移到 8，因為沒有 MQ 系列 JMS 2 RAR。

一些不同之處：

• 配置更好，更簡單。 它不再分布在 20 個 XML 文件中，您可以在其中配置 XML 文件中的方面。 相反，一切都是一個中心位置。 所有端口都配置在一個中心位置，不再有轉換 server.xml 的 XSL 文件。 您可以在不知道類的實現細節的情況下理解配置文件。 如果您從未配置過 JBoss 5.x，就很難理解這一點。
• 加載 model 的 class 看起來很正常，您可以通過 jboss-deployment-structure.xml 獲得很多控制權
• 集中式日志記錄（Slf4j、JUL、JCL、Log4j，...）非常好。
• EJB 客戶端庫看起來更加整潔。 從 20 個減少到 10 個 JARs，其中一半甚至是 OSGi 捆綁包（我們的客戶端是 Eclipse RCP 應用程序）。
• EJB 客戶端 maven 依賴混亂消失了，取而代之的是你現在得到一個 BOM POM。
• 您將獲得服務器 API 的 BOM POM。
• 更快的啟動和更少的 memory 使用。 我們在 6 秒內部署了 80 個 EJB 和 MQ 系列 RAR，無需進行太多調整。 我們的實時數據集超過 200 MB。
• 部署文件夾默認為空
• XNIO 的（缺乏）質量是可怕的。 在 7.x 中，它僅用於 EJB 遠程處理，我們遇到了幾個顯示停止錯誤（死鎖、雙重釋放、套接字句柄泄漏……）。 在 8.x 中，它也用於 servlets，而不是 Tomcat。 仍然有很多非常基本的 servlet 錯誤正在被修復。

我們必須對應用程序進行的更改：

• 將 JNDI 名稱更改為 EE 6 標准化名稱
• 從 JBoss Cache 遷移到 Infinispan （我們的部分代碼已經遷移到扁平化的 API，有些部分仍然使用樹形 API）
• 安全性稍微不那么靈活（您不能再修復經過身份驗證和未經身份驗證的調用）
• 一些依賴遠程 JNDI 細節的可怕代碼
• EJB客戶端的配置不同
• 用於安裝、部署、啟動、停止……的所有腳本
• ExternalContext 消失了，我們不得不用不同的方法替換它
• 我們將 SAR 中的 MBean 替換為 @StartUp EJB
• Cocoon 的一些丑陋技巧

AS 7.x 系列有很多錯誤，修復僅在 EAP 系列中可用。 如果您希望 go 使用 7.x 而不是 8.x，我們強烈建議您購買 EAP 6。

Answer 4

只是想讓任何可能在升級到最新版本后面臨 PermGen 膨脹問題的人注意這一點。 JBoss-6 微容器通過在啟動時從類路徑中的所有 JARs 加載類來嘗試掃描 Jboss 特定注釋。 這會導致 PermGen 膨脹，因為它開始加載所有不需要的類。 為了減少掃描量，微容器通過 jboss-scanning.xml 提供了另一個描述符掛鈎。 將此“jboss-scanning.xml”添加到 WAR 內的 WEB-INF，並將“jboss-scanning.xml”添加到 EAR 內的 META-INF。

<scanning xmlns="urn:jboss:scanning:1.0">

    <!-- Purpose: Disable scanning for annotations in contained deployment. -->

</scanning>

Answer 5

這是 JBoss AS 7 妥協和未來的一個有趣線程，還提到了 AS 5 和 AS 6 的問題：

http://community.jboss.org/message/613171