幾周前，我發布了一個有關從Java EE 5遷移到7的博客 。這主要是關于如何使用新的Java EE 7改進Java EE 5代碼。 現在，在本文中，我將對應用程序服務器端的遷移路徑進行一些研究。

如果您使用的是Java EE 5，則很有可能正在使用以下服務器之一：

• JBoss 4倍或5倍
• 玻璃魚 2x
• Weblogic 10倍
• Websphere 7倍

還有許多其他支持Java EE 5的服務器，您可以在此處檢出它們。

序幕

我最終獲得了我在JBoss 4x上的大部分經驗，因為當時我正在工作的公司已經在他們的大多數項目中大量使用了它。 我對此事幾乎沒有任何表決權，只是與JBoss保持公司的發展方向。

當我們決定將我們的一個客戶端關鍵應用程序從Java EE 5遷移到7時，我們面臨著使用哪個應用程序服務器的難題。 自從我擔任技術管理職務以來，我現在能夠影響這一決定。 由于以下原因，我們最終選擇了Wildfly ：

• 已實現Java EE 7完整配置文件
• 強大的CLI管理服務器
• 團隊已經熟悉Wildfly隨附的Java EE實現

即使本文討論了JBoss和Wildfly ，但某些原則仍然適用于Application Server。 因此，我希望這對其他Application Server用戶也有用。 當前，我們正在使用Wildfly 8.2.0，但本文中討論的內容也應與最新的Wildfly版本一起使用。

戰略

執行Application Server遷移，尤其是涉及服務器之間相距甚遠的遷移，絕非易事。 遷移路徑并不十分簡單，因為每個應用程序最終都會使用Application Server的不同功能。 更糟糕的是，該應用程序甚至可能正在實現這些功能所支持的業務代碼，而這些功能可能在目標遷移服務器中不可用。

無論如何，在進行遷移項目時可以遵循兩種策略：

功能凍結

顧名思義，您將凍結項目以執行必要的調整以遷移應用程序。 處理復雜性可能更容易，但另一方面，它會延遲業務功能并創建不可協商的期限。 要說服利益相關者采用這種策略是非常困難的，但是如果您有能力，那就去做。

組合式

另一個選擇是保持開發持續進行并同時進行遷移。 這對企業來說是最好的，但是需要更多的紀律和計劃。 您始終可以將應用程序分區并將其拆分為模塊，然后少量遷移。 這是我通常使用的策略。

第一步

您可能需要一些時間才能完全遷移您的應用程序。 在此期間，您需要保持舊服務器以及新服務器的運行。 為此，您需要更新和復制環境。 就像分支代碼一樣，但是在運行時。

您使用的支持工具可能也需要更新。 新服務器的Maven插件，即Jenkins部署，無論與Application Server進行交互。 這是一項艱巨的任務，因為管理所有這些額外環境和分支的復雜性并不容易。

走的路

考慮遷移時，您需要擔心幾個細節。 這不是一個詳盡的列表，但可能是您將會遇到的最常見的主題。

類加載

如果您沒有遇到ClassNotFoundException ， NoClassDefFoundError或ClassCastException您可能要考慮玩彩票并中獎！

對于JBoss 4.x Classloader尤其如此。 當時，類加載是（仍然是，但甚至超過）一項昂貴的操作，因此JBoss使用了一種稱為UnifiedClassLoader東西。 這意味著應用程序之間沒有真正的隔離。 EAR檔案可能會相互查看以加載庫。 當然，這是要管理的主要難題。 最糟糕的部分是當您必須使用JBoss服務器將應用程序部署到客戶中時。 如果您無法控制它，則當前部署可能與您自己的部署發生沖突。

Wildfly引入了基于模塊的類加載，而不是通常的分層方法。 通常，除非使用文件描述符明確聲明，否則部署在Wildfly中的應用程序將無權訪問Application Server庫。 對于Java EE應用程序，這些模塊會自動加載。

更換服務器時，以下是與類加載相關的最常見問題：

• 坐在其他應用程序上的缺少庫。
• 在服務器上已刪除或更新的庫上進行中繼。
• 應用程序上使用的庫現在是新服務器的一部分。

要解決此問題，您需要通過添加刪除必需的庫來調整項目依賴項。 這里沒有分步指南。 每種情況都需要進行分析并相應解決。 這有點像試圖解開一個滿是結的弦。

如果您使用的是Dependency Plugin ，那么您可以使用mvn dependency:tree和mvn dependency:analyze來幫助您。

Wildfly還為您提供了一個特定的描述符文件jboss-deployment-structure.xml ，通過添加或刪除依賴項或更改類加載器的行為，您可以微調類的加載。 這是一個例子：

jboss部署結構

<?xml version="1.0" encoding="UTF-8"?> <jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.2"><ear-subdeployments-isolated>false</ear-subdeployments-isolated><deployment><dependencies><module name="org.jboss.msc" export="true"/><module name="org.jboss.as.naming" export="true"/><module name="org.jboss.as.server" export="true"/><module name="deployment.app-client.jar" export="true"/><module name="deployment.app-ear.ear.app-entity.jar" export="true"/></dependencies></deployment> </jboss-deployment-structure>

此自定義描述符正在添加來自其他部署的依賴關系，即app-client.jar ，甚至是app-ear.ear.app-entity.jar中另一個EAR的子部署。

最后，我的建議是嘗試遵守標準，僅在絕對必要時才引入其他庫。 這肯定會減少您的類加載問題，并使將來更輕松地遷移到服務器的新版本甚至更改為另一臺服務器。

常規配置

在JBoss 4.x中，所有配置都分散在不同的文件中： server.xml ， jboss-service.xml ， login-config.xml以及許多其他文件。 您必須手動編輯文件才能更改所需的配置。 這是一項繁瑣的工作，尤其是當您無權訪問服務器并必須記錄一組更改以供他人執行時。

在Wildfly中，大多數配置都進入configuration/standalone.xml ，但是我從未編輯過該文件。 Wildfly附帶了非常強大的命令行界面（CLI），可讓您編寫幾乎所有需要在服務器上執行的更改的腳本。 以下是Undertow配置的示例：

Underwow.cli

/subsystem=undertow/server=default-server/ajp-listener=ajp:add(socket-binding=ajp)/subsystem=undertow/server=default-server/host=app \:add( \alias=["localhost, ${app.host}"] \)/subsystem=undertow/server=default-server:write-attribute(name="default-host", value="app")/subsystem=undertow/server=default-server/host=app/filter-ref=server-header:add /subsystem=undertow/server=default-server/host=app/filter-ref=x-powered-by-header:add /subsystem=undertow/server=default-server/host=app/location="/":add (\handler=welcome-content)/subsystem=undertow/server=default-server/host=default-host/filter-ref=server-header:remove /subsystem=undertow/server=default-server/host=default-host/filter-ref=x-powered-by-header:remove:reload/subsystem=undertow/server=default-server/host=default-host/location="/":remove/subsystem=undertow/server=default-server/host=default-host:remove/subsystem=undertow/server=default-server/host=segurnet/setting=single-sign-on:add(path="/"):reload

這將設置一個名為app的虛擬主機，使其成為默認主機，刪除Wildfly隨附的默認主機并激活Single Sign On。

使用腳本和CLI可以很容易地從頭啟動新服務器。 您應該始終喜歡這種更改服務器上配置的方法。

數據源

在JBoss 4.x中，設置數據源只需要您將數據庫驅動程序復制到lib文件夾，并使用數據源連接詳細信息創建*-ds.xml文件。

在Wildfly中 ，有些棘手，但沒什么大不了的。 將數據源設置為模塊，然后可以使用CLI將數據源連接詳細信息添加到服務器配置中。 我甚至以前也寫過一篇完整的博客文章： 使用Maven配置JBoss / Wildfly數據源 。

安全

JBoss 4.x中的安全性已在conf/login-config.xml 。 Wildfly并沒有引入太多更改，但是如果您需要實現自定義登錄模塊，則依賴項會更改。 我還寫了一篇完整的博客文章： Wildfly的Custom Principal和LoginModule 。

JNDI綁定

通常在JBoss 4.x中使用@LocalBinding為您的EJB定義確切的JNDI名稱。 但是Java EE 7按作用域引入了標準JNDI名稱，這意味著您應該遵循約定來查找EJB。

代替：

本地綁定

@Stateless @Local(UserBusiness.class) @LocalBinding(jndiBinding="custom/UserBusiness") public class UserBusinessBean implements UserBusiness {}...private UserBusiness userBusiness;try {InitialContext context = new InitialContext();userBusiness = (UserBusiness) context.lookup("custom/userBusiness"); } catch(Exception e) {}

您可以：

EJB 3.1綁定

@EJB(lookup="java:global/app-name/app-service/UserBusinessBean") private UserBusiness userBusiness;

當Wildfly啟動時，您還可以在日志中檢查標準綁定：

Wildfly JNDI標準綁定

java:global/segurnet/segurnet-protocol-gu-ejb/UserBusinessBean!com.criticalsoftware.segurnet.protocol.gu.ejb.business.UserBusinessjava:app/app-service/UserBusinessBean!com.app.business.UserBusinessjava:module/UserBusinessBean!com.app.business.UserBusinessjava:global/app-name/app-service/UserBusinessBeanjava:app/app-service/UserBusinessBeanjava:module/UserBusinessBean

其他的東西

這是我也寫過博客文章的更具體的主題，可能也很有趣：

• Spring Batch作為Wildfly模塊
• Wildfly，Apache CXF和@SchemaValidation

最后的話

如前所述，遷移永遠不會遵循直接的路徑。 不過，您可以做一些改進的事情。 編寫測試，測試和測試。 我告訴過你要寫測試嗎？ 在進行任何遷移工作之前，請先執行此操作。 即使遷移的一切看起來都很好，您也可能會在不同版本的Java EE實現之間遇到輕微的行為更改。

另外，不要小看這項工作。 使您的應用程序與正在開發的新功能保持一致，以及更改服務器，需要您花費時間和精力來確保一切都不會中斷。 除非我們談論的是非常小的應用程序，否則肯定不會花1周的時間。 我們花了將近2年的時間才能將應用程序遷移到100萬行以上。 但是，請謹慎對待這些數字。 這些非常取決于您的團隊動態。

我的最終建議：如果您使用的是舊版Java EE版本，則一定要遷移。 在我的博客中了解有關從Java EE 5降級到7的Legacy的信息 。 跳躍并非易事，但是隨著Java EE發行版的每個新版本以及對標準化的關注，每次升級都將減輕痛苦。

翻譯自: https://www.javacodegeeks.com/2015/11/application-server-migration-jboss-ee5-to-wildfly-ee7.html

總結

以上是默认站点為你收集整理的应用程序服务器迁移：从JBoss EE5到Wildfly EE7的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得默认站点網站內容還不錯，歡迎將默认站点推薦給好友。