java 从 JBoss 4.2.x 升级到 JBoss 5.x、6.x、7.x 和 WildFly 8.x 的好处（和提示）？

Benefits (and tips) of an upgrade from JBoss 4.2.x to JBoss 5.x, 6.x, 7.x and WildFly 8.x?

提问by haylem

Please assume that I do not need to worry about development time and costs: I am interested in general technical benefits (improved performance? improved APIs?) and new features.

请假设我不需要担心开发时间和成本：我对一般技术优势（改进的性能？改进的 API？）和新功能感兴趣。

I am currently working on products using 4.2.x, and we consider a major shift for versions that are a long time ahead and need to converge.

我目前正在研究使用 4.2.x 的产品，我们考虑对需要融合很长时间的版本进行重大转变。

I had a brief look at the release notes of each version and some articles about each release for 5.x, 6.x, 7.x and 8.x. But I would be glad to have first-hand feedback from people who have made the switch.

我简要地查看了每个版本的发行说明以及有关 5.x、6.x、7.x 和 8.x 的每个版本的一些文章。但我很高兴能从做出转变的人那里得到第一手的反馈。

I noticed there are some important changes surrounding messaging (switching from JBoss MQ to JBoss Messenging), and that for JBoss 7.x it seems to change a fair bit its configuration layer. Then there's a lot more going on when switching to JBoss/WildFly 8.x.

我注意到围绕消息传递（从 JBoss MQ 切换到 JBoss Messenging）有一些重要的变化，而且对于 JBoss 7.x，它的配置层似乎发生了相当大的变化。当切换到 JBoss/WildFly 8.x 时，还有很多事情要做。

Please recommend good articles pointing at pitfalls if you can. I found a few for migrations to JBoss 5.x, but not that many for 6.x or even 7.x, and someone else is evaluating 8.x for us now. Feel free to recommend alternatives as well if you think they are relevant, though I'd prefer to focus only on JBoss.

如果可以，请推荐指出陷阱的好文章。我找到了一些用于迁移到 JBoss 5.x 的，但用于 6.x 甚至 7.x 的并不多，而且其他人现在正在为我们评估 8.x。如果您认为相关的替代方案也可以随意推荐，但我更愿意只关注 JBoss。

For information, we use a mix of JPF- and OSGi-enabled (using Eclipse Equinox) plugin-based systems, with clients developed in Swing (some deployed via WebStart).

有关信息，我们混合使用启用 JPF 和 OSGi（使用 Eclipse Equinox）的基于插件的系统，以及在 Swing 中开发的客户端（一些通过 WebStart 部署）。

Update:Though this question brought some great answers already, I think it deserves an update for WildFly (and actually, our internal projects delayed making the switch from 4.2.x to 7.x as originally planned to wait for WildFly). New thoughts and answers are welcome.

更新：虽然这个问题已经带来了一些很好的答案，但我认为它值得 WildFly 更新（实际上，我们的内部项目推迟了从 4.2.x 到 7.x 的转换，因为原计划等待 WildFly）。欢迎新的想法和答案。

采纳答案by Dave

I've upgraded from JBoss 4 to 5 and from experience the following are the most important to note:

我已经从 JBoss 4 升级到 5，根据经验，以下是最需要注意的：

• JBoss 5 (and 6 and 7) are not as forgiving as JBoss 4 with XML files. You must make sure that all your deployment descriptor XML files are valid. You may be using DTDs in some files - I recommend upgrading these to use XML schema instead.
• Some libraries may cause incompatibilities. This can be particularly true if you access web services and/or do XML parsing
• If you precompile your JSPs in JBoss 4, you probably won't be able to in JBoss 6/7.
• JBoss 4 and 5 use different message queue implementations. If you have any message queues or topics defined you will need to redefine them.
• JBoss TreeCache is no longer used. If you use this for caching purposes, you will need to change to use the new JBoss cache instead.
• JBoss 5 security is different. If your remote clients require secured access to JBoss, you will need to configure them differently.

• JBoss 5（以及 6 和 7）不像 JBoss 4 那样对 XML 文件宽容。您必须确保所有部署描述符 XML 文件都是有效的。您可能在某些文件中使用 DTD - 我建议将它们升级为使用 XML 模式。
• 某些库可能会导致不兼容。如果您访问 Web 服务和/或进行 XML 解析，则尤其如此
• 如果您在 JBoss 4 中预编译您的 JSP，您可能无法在 JBoss 6/7 中进行。
• JBoss 4 和 5 使用不同的消息队列实现。如果您定义了任何消息队列或主题，则需要重新定义它们。
• 不再使用 JBoss TreeCache。如果将其用于缓存目的，则需要更改为使用新的 JBoss 缓存。
• JBoss 5 的安全性是不同的。如果您的远程客户端需要对 JBoss 的安全访问，您将需要对其进行不同的配置。

Some useful resources are:

一些有用的资源是：

http://java.dzone.com/articles/migrating-jboss-4-jboss-5http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga

http://java.dzone.com/articles/migrating-jboss-4-jboss-5 http://venugopaal.wordpress.com/2009/02/02/jboss405-to-jboss-5ga

Officially JBoss 6 is only certified for the Java EE Web Profile, so if you use "legacy" features such as EJB 2.x, they will potentially not be supported in the future. Depending on the lifecycle of your application, this may or may not be a problem. JBoss 6 currently supports EJB2.1 fully, but it is not certified against this.

官方 JBoss 6 仅针对 Java EE Web Profile 进行了认证，因此如果您使用“遗留”功能（例如 EJB 2.x），它们将来可能不受支持。根据应用程序的生命周期，这可能是也可能不是问题。JBoss 6 目前完全支持 EJB2.1，但它没有经过认证。

I have also found that JBoss 5 handles memory a lot better that JBoss 4. With JBoss 4 I see a lot more PermGen errors than I do with JBoss 5.

我还发现 JBoss 5 比 JBoss 4 处理内存要好得多。在 JBoss 4 中，我看到的 PermGen 错误比在 JBoss 5 中多得多。

回答by McDowell

I can only speak from production experience with JBoss 5.1.0 and some investigation of version 6.

我只能从 JBoss 5.1.0 的生产经验和对版本 6 的一些调查中发言。

JBoss 5 is Java EE 5and JBoss 6 and 7 are Java EE 6. The disparity in API features is best documented in those specs. JBoss 6 is likely to have a very short shelf-life; it is only certified for the Java EE 6 web profileand bugfixes are being targeted at version 7 (in its 3rd beta at time of writing).

JBoss 5 是Java EE 5，JBoss 6 和 7 是Java EE 6。API 功能的差异在这些规范中得到了最好的记录。JBoss 6 的保质期很可能很短；它仅针对 Java EE 6 Web 配置文件进行了认证，并且错误修复针对版本 7（在撰写本文时为第 3 个测试版）。

I think you'd get better answers on the JBoss community forum.

我认为您会在 JBoss 社区论坛上得到更好的答案。

回答by Philippe Marschall

We upgraded from JBoss AS 5 to JBoss AS 7 and are eying towards WildFly AS 8.1. Right now we can't migrate to 8 because there is no MQ Series JMS 2 RAR.

我们从 JBoss AS 5 升级到 JBoss AS 7，并着眼于 WildFly AS 8.1。现在我们无法迁移到 8，因为没有 MQ 系列 JMS 2 RAR。

Some of the differences:

一些差异：

• The configuration is so much better and simpler. It's no longer spread over 20 XML files in which you configure aspects in XML files. Instead everything is one central place. All ports are configured in one central place, there is no longer an XSL file that transforms server.xml. You can make sense of the configuration file without knowing the implementation details of classes. It's hard to appreciate this if you've never configured a JBoss 5.x.
• The class loading model looks sane and you get a lot of control through jboss-deployment-structure.xml
• The centralized logging (Slf4j, JUL, JCL, Log4j, …) is really nice.
• The EJB client library looks much more cleaned up. It's down to 10 JARs from 20, half of them are even OSGi bundles (our client is an Eclipse RCP application).
• The EJB client maven dependency mess is gone, instead you now get a BOM POM.
• You get a BOM POM for the server APIs.
• Faster start up and less memory usage. We deploy 80 EJBs and the MQ Series RAR in 6 seconds without much tuning. Our live dataset is somewhere above 200 MB.
• The deployments folder is empty by default
• The (lack of) quality of XNIO is scary. In 7.x it's only used for EJB remoting and we hit several show stopper bugs (deadlocks, double free, socket handle leaks, …). In 8.x it is used for servlets as well instead of Tomcat. There are still a lot of very basic servlet bugs being fixed in undertow.

• 配置更好，更简单。它不再分布在 20 个 XML 文件中，您可以在其中配置 XML 文件中的方面。相反，一切都是一个中心位置。所有端口都在一个中心位置配置，不再有转换 server.xml 的 XSL 文件。您可以在不了解类的实现细节的情况下理解配置文件。如果您从未配置过 JBoss 5.x，很难体会到这一点。
• 类加载模型看起来很正常，您可以通过 jboss-deployment-structure.xml 获得很多控制
• 集中式日志记录（Slf4j、JUL、JCL、Log4j 等）非常好。
• EJB 客户端库看起来更加整洁。从 20 个 JAR 减少到 10 个，其中一半甚至是 OSGi 包（我们的客户端是一个 Eclipse RCP 应用程序）。
• EJB 客户端 maven 依赖关系已经消失，取而代之的是您现在获得了一个 BOM POM。
• 您将获得服务器 API 的 BOM POM。
• 更快的启动和更少的内存使用。我们在 6 秒内部署了 80 个 EJB 和 MQ 系列 RAR，无需太多调整。我们的实时数据集大约在 200 MB 以上。
• 部署文件夹默认为空
• XNIO 的（缺乏）质量是可怕的。在 7.x 中，它仅用于 EJB 远程处理，我们遇到了几个显示阻止错误（死锁、双重释放、套接字句柄泄漏……）。在 8.x 中，它也用于 servlets 而不是 Tomcat。在 undertow 中仍有许多非常基本的 servlet 错误正在修复。

Changes that we had to do our application:

我们必须对我们的应用程序进行更改：

• change JNDI names to EE 6 standardized names
• migrate from JBoss Cache to Infinispan (part of our code has been migrated to the flat API, some parts still use the tree API)
• security is slightly less flexible (you can no longer fix authenticated and unauthenticated calls)
• some horrible code that relied on details of remote JNDI
• the configuration of the EJB client is different
• all of you scripts for installing, deploying, starting, stopping, …
• ExternalContext is gone, we had to replace it with a different approach
• we replaced MBeans in SARs with @StartUp EJBs
• some ugly hacks for Cocoon

• 将 JNDI 名称更改为 EE 6 标准化名称
• 从JBoss Cache迁移到Infinispan（我们的部分代码已经迁移到flat API，部分仍然使用tree API）
• 安全性稍微不那么灵活（您不能再修复经过身份验证和未经身份验证的调用）
• 一些依赖远程 JNDI 细节的可怕代码
• EJB客户端的配置不同
• 所有用于安装、部署、启动、停止……的脚本
• ExternalContext 不见了，我们不得不用不同的方法替换它
• 我们用@StartUp EJBs 替换了 SARs 中的 MBeans
• Cocoon 的一些丑陋的黑客攻击

The AS 7.x series has a lotof bugs with fixes only available in the EAP series. If you want go to with 7.x instead of 8.x we strongly recommend you buy EAP 6.

AS 7.x 系列有很多错误，只有 EAP 系列才有修复。如果您想使用 7.x 而不是 8.x，我们强烈建议您购买 EAP 6。

回答by Vadzim

Here is an interesting thread on JBoss AS 7 compromises and future, also mentioning issues with AS 5 and AS 6:

这是一个关于 JBoss AS 7 妥协和未来的有趣主题，还提到了 AS 5 和 AS 6 的问题：

http://community.jboss.org/message/613171

http://community.jboss.org/message/613171

回答by karthik m

Just wanted to bring this to anyone's attention who might be facing PermGen bloat issue after upgrading to the latest. The JBoss-6 Microcontainer tries to scan for Jboss specific annotations by loading the classes from all the JARs in the class-path on startup. This causes the PermGen bloating as it starts to load all the unwanted classes. To reduce the amount of scanning, the Microcontainer provides another descriptor hook, by means of jboss-scanning.xml. Add this 'jboss-scanning.xml' to the WEB-INF inside WARs and ass 'jboss-scanning.xml' to the META-INF inside EARs.

只是想让升级到最新版本后可能面临 PermGen 膨胀问题的任何人注意这一点。JBoss-6 微容器尝试通过在启动时加载类路径中所有 JAR 中的类来扫描 Jboss 特定的注释。这会导致 PermGen 膨胀，因为它开始加载所有不需要的类。为了减少扫描量，微容器通过 jboss-scanning.xml 提供了另一个描述符钩子。将此“jboss-scanning.xml”添加到 WAR 内的 WEB-INF 并将“jboss-scanning.xml”添加到 EAR 内的 META-INF。

<scanning xmlns="urn:jboss:scanning:1.0">

    <!-- Purpose: Disable scanning for annotations in contained deployment. -->

</scanning>