31

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

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

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

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

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

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

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

4

5 回答 5

24

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

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

一些有用的资源是：

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

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

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

于 2011-06-03T16:56:36.213 回答
9

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

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

我想你会在 JBoss 社区论坛上得到更好的答案。

于 2011-06-01T19:35:53.747 回答
5

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

一些不同之处：

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

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

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

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

于 2014-05-21T13:02:24.540 回答
0

只是想让任何可能在升级到最新版本后面临 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>
于 2013-06-29T18:52:54.710 回答
0

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

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

于 2011-12-27T13:10:04.953 回答