是否值得从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软件,因此仅此一点可能会出售迁移.
配置更好,更简单.它不再分布在20个XML文件中,您可以在其中配置XML文件中的方面,但只有一个中心位置.所有端口都配置在一个中心位置,不再有一个转换server.xml的XSL文件.您可以在不知道类的实现细节的情况下理解配置文件.如果您从未配置过JBoss,那么很难理解这一点.
EJB远程处理不再使用每个套接字的线程.
删除不需要的子系统非常简单.
类loding模型看起来很清晰,你可以通过jboss-deployment-structure.xml获得很多控制权
EJB客户端库看起来更加清理.它从20个减少到10个JAR,其中一半甚至是OSGi捆绑包(我们的客户端是Eclipse RCP应用程序).
虽然我们对Java EE 6用@Singleton bean替换我们的一些SLSB并不感兴趣,而我们的一些带有计时器EJB的SAR肯定看起来很有趣.
更快的启动和更少的内存使用(至少对于空服务器或小型部署).我们还没有测试过大型部署.
默认情况下,deployments文件夹为空

我们仍需要研究的事情:

我们有点担心Infinispan的表现.我们目前使用JBoss Cache的TreeCache API.虽然有一个适用于Infinispan的适配器提供相同的API,但一些理论测试显示出更差的写入性能.这仅适用于Infinispan的树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依赖项的版本.在实践中,artifactId中的版本坐标很糟糕,当我们迁移到JEE 7时会很烦人.当你想要为测试包含一个JEE API的实现时,它也没什么用.
Infinispan树API性能不是问题.
我们用DMR脚本替换了JMX-Console脚本.

更新2