幾周前，我發(fā)布了一個有關(guān)從Java EE 5遷移到7的博客 。這主要是關(guān)于如何使用新的Java EE 7改進(jìn)Java EE 5代碼。 現(xiàn)在，在本文中，我將對應(yīng)用程序服務(wù)器端的遷移路徑進(jìn)行一些研究。

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

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

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

序幕

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

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

• 已實現(xiàn)Java EE 7完整配置文件
• 強大的CLI管理服務(wù)器
• 團(tuán)隊已經(jīng)熟悉Wildfly隨附的Java EE實現(xiàn)

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

戰(zhàn)略

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

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

功能凍結(jié)

顧名思義，您將凍結(jié)項目以執(zhí)行必要的調(diào)整以遷移應(yīng)用程序。 處理復(fù)雜性可能更容易，但另一方面，它會延遲業(yè)務(wù)功能并創(chuàng)建不可協(xié)商的期限。 要說服利益相關(guān)者采用這種策略是非常困難的，但是如果您有能力，那就去做。

組合式

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

第一步

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

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

走的路

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

類加載

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

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

Wildfly引入了基于模塊的類加載，而不是通常的分層方法。 通常，除非使用文件描述符明確聲明，否則部署在Wildfly中的應(yīng)用程序?qū)o權(quán)訪問Application Server庫。 對于Java EE應(yīng)用程序，這些模塊會自動加載。

更換服務(wù)器時，以下是與類加載相關(guān)的最常見問題：

• 坐在其他應(yīng)用程序上的缺少庫。
• 在服務(wù)器上已刪除或更新的庫上進(jìn)行中繼。
• 應(yīng)用程序上使用的庫現(xiàn)在是新服務(wù)器的一部分。

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

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

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

jboss部署結(jié)構(gòu)

<?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>

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

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

常規(guī)配置

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

在Wildfly中，大多數(shù)配置都進(jìn)入configuration/standalone.xml ，但是我從未編輯過該文件。 Wildfly附帶了非常強大的命令行界面（CLI），可讓您編寫幾乎所有需要在服務(wù)器上執(zhí)行的更改的腳本。 以下是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

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

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

數(shù)據(jù)源

在JBoss 4.x中，設(shè)置數(shù)據(jù)源只需要您將數(shù)據(jù)庫驅(qū)動程序復(fù)制到lib文件夾，并使用數(shù)據(jù)源連接詳細(xì)信息創(chuàng)建*-ds.xml文件。

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

安全

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

JNDI綁定

通常在JBoss 4.x中使用@LocalBinding為您的EJB定義確切的JNDI名稱。 但是Java EE 7按作用域引入了標(biāo)準(zhǔn)JNDI名稱，這意味著您應(yīng)該遵循約定來查找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;

當(dāng)Wildfly啟動時，您還可以在日志中檢查標(biāo)準(zhǔn)綁定：

Wildfly JNDI標(biāo)準(zhǔn)綁定

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

最后的話

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

另外，不要小看這項工作。 使您的應(yīng)用程序與正在開發(fā)的新功能保持一致，以及更改服務(wù)器，需要您花費時間和精力來確保一切都不會中斷。 除非我們談?wù)摰氖欠浅Ｐ〉膽?yīng)用程序，否則肯定不會花1周的時間。 我們花了將近2年的時間才能將應(yīng)用程序遷移到100萬行以上。 但是，請謹(jǐn)慎對待這些數(shù)字。 這些非常取決于您的團(tuán)隊動態(tài)。

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

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

總結(jié)

以上是生活随笔為你收集整理的应用程序服务器迁移：从JBoss EE5到Wildfly EE7的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。