怎么搞wordpress,兰州新站seo,以下不属于专用网页制作工具的是,短期网页设计培训几周前#xff0c;我发布了一个有关从Java EE 5迁移到7的博客 。这主要是关于如何使用新的Java EE 7改进Java EE 5代码。 现在#xff0c;在本文中#xff0c;我将对应用程序服务器端的迁移路径进行一些研究。 如果您使用的是Java EE 5#xff0c;则很有可能正在使用以下服… 几周前我发布了一个有关从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 version1.0 encodingUTF-8?
jboss-deployment-structure xmlnsurn:jboss:deployment-structure:1.2ear-subdeployments-isolatedfalse/ear-subdeployments-isolateddeploymentdependenciesmodule nameorg.jboss.msc exporttrue/module nameorg.jboss.as.naming exporttrue/module nameorg.jboss.as.server exporttrue/module namedeployment.app-client.jar exporttrue/module namedeployment.app-ear.ear.app-entity.jar exporttrue//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 /subsystemundertow/serverdefault-server/ajp-listenerajp:add(socket-bindingajp)/subsystemundertow/serverdefault-server/hostapp \:add( \alias[localhost, ${app.host}] \)/subsystemundertow/serverdefault-server:write-attribute(namedefault-host, valueapp)/subsystemundertow/serverdefault-server/hostapp/filter-refserver-header:add
/subsystemundertow/serverdefault-server/hostapp/filter-refx-powered-by-header:add
/subsystemundertow/serverdefault-server/hostapp/location/:add (\handlerwelcome-content)/subsystemundertow/serverdefault-server/hostdefault-host/filter-refserver-header:remove
/subsystemundertow/serverdefault-server/hostdefault-host/filter-refx-powered-by-header:remove:reload/subsystemundertow/serverdefault-server/hostdefault-host/location/:remove/subsystemundertow/serverdefault-server/hostdefault-host:remove/subsystemundertow/serverdefault-server/hostsegurnet/settingsingle-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(jndiBindingcustom/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(lookupjava: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模块 WildflyApache 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
