java - 是否值得从JBoss 5.1升级到JBoss 7.1

Question

当前，我们的生产环境运行JBoss 5.1，我们一直在争论是否值得将其迁移到JBoss 7.1。如果这是一次简单的服务器升级，那将不是问题。但是，不幸的是，我们将不得不更改配置，这将需要一些努力。另外，我们的服务器在集群中运行，我读到JBoss 7.1具有更多的集群支持。

那么值得吗？

谢谢

Answer 1

我们目前处在相同的情况。

积极方面似乎有很多事情:

我们将不得不从5.1迁移到一点。我们需要完整的资料，并且没有太多的OSS替代品(GlassFish以及Geronimo)。由于PCI-DSS禁止我们使用EoL软件，因此仅凭这一点就可以出售迁移产品。

配置是如此的好和简单。它不再散布在您在XML文件中配置方面的20个XML文件中，而是集中在一个中心位置。所有端口都配置在一个中央位置，不再存在转换server.xml的XSL文件。您可以在不了解类的实现细节的情况下理解配置文件。如果您从未配置过JBoss，就很难理解这一点。

EJB远程处理不再为每个套接字使用线程。

删除不需要的子系统非常容易。

类放置模型看起来很健全，并且通过jboss-deployment-structure.xml得到了很多控制

EJB客户端库看起来要清理得多。它从20个减少到10个JAR，其中一半甚至是OSGi捆绑包(我们的客户端是Eclipse RCP应用程序)。

虽然我们对Java EE 6并不感到兴奋，但用@Singleton bean替换了我们的一些SLSB，而用计时器EJB替换了我们的一些SAR确实很有趣。

启动速度更快，内存使用量更少(至少对于空服务器或小型部署而言)。我们尚未测试大型部署。

部署文件夹默认为空

我们仍然需要研究的事情:

我们对Infinispan的性能有些担心。当前，我们使用JBoss Cache的TreeCache API。虽然有用于Infinispan的适配器提供相同的API，但一些理论测试显示写入性能较差。这仅适用于Infinispan的tree API。

不再支持

ExternalContext，我们目前使用它来从.bindings文件

中填充JNDI树

JMX控制台已经不存在了，如果您需要在此基础上进行任何调整，编辑实际上有一个JMX-Console端口可用AS7-2227

我们不在集群中运行，因此我无法对此发表评论。

对我们来说，最大的努力可能就是迁移所有与JBoss交互的Shell脚本(安装，集成测试等)。

更新

我们已经迁移了，这绝对是值得的。对以上几点的一些更新:

即使是大型部署，调整量也很小。

集中式日志记录(Slf4j，JUL，JCL，Log4j等)非常好。

7.1有很多错误，对我们来说是无法使用的，因此我们使用7.2/EAP 6.1，并计划升级到7.3/EAP 6.2。仍有相当多的错误，但我们可以解决它们。我们特别期待对管理界面进行基于角色的访问控制，这将使我们能够以最小的权限运行脚本。

将不会有受支持的GlassFish 4版本，该版本会在生产版本上加上很大的问号。

EJB远程处理安全性不够灵活。因为以前我们将经过身份验证的和未经身份验证的EJB调用混合在一起，所以我们不得不采取一些变通办法–不再可能。

来自JBoss的JEE 6 BOM POM是一个混合袋。从理论上讲，这很好，因为它可以管理您所有JEE依赖项的版本。在实践中，坐标值与artifactIdId中的版本一样令人恐惧，当我们迁移到JEE 7时，这会很烦人。另外，当您要包括用于测试的JEE API的实现时，它也不是很有用。

Infinispan树API性能不是问题。

我们用DMR脚本替换了JMX-Console脚本。

更新2

使用基于SSL的EJB远程处理时，有一个deadlock。即使在EAP 6.2中也存在此死锁。现在我们到了从WildFly向AS 7反向移植功能的补丁集的时候了。