当前位置： 文江博客话题详情

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

发布于 2024-11-11 15:57:17 字数 701 浏览 3 评论 0原文

请假设我不需要担心开发时间和成本：我对一般技术优势（改进的性能？改进的 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 的切换，按原计划等待对于野蝇）。欢迎新的想法和答案。

原文

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.

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.

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.

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.

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.

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).

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.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（5）

极度宠爱 2024-11-18 15:57:18

只是想让升级到最新版本后可能面临 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>

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.

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

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

</scanning>
回复 原文
美人迟暮 2024-11-18 15:57:17

我已经从 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/migration-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 时多得多。

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

  • 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.

Some useful resources are:

https://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.

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.

回复 原文
薄情伤 2024-11-18 15:57:17

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

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

我认为您可以在 JBoss 社区论坛上获得更好的答案。

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

JBoss 5 is Java EE 5 and 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 profile and bugfixes are being targeted at version 7 (in its 3rd beta at time of writing).

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

回复 原文
彩扇题诗 2024-11-18 15:57:17

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

一些区别：

  • 配置更好、更简单。它不再分布在 20 个 XML 文件中，您可以在 XML 文件中配置方面。相反，一切都是一个中心位置。所有端口都在一个中心位置进行配置，不再有转换 server.xml 的 XSL 文件。您可以在不了解类的实现细节的情况下理解配置文件。如果您从未配置过 JBoss 5.x，则很难理解这一点。
  • 类加载模型看起来很正常，并且您可以通过 jboss-deployment-struction.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。 Undertow 中仍然修复了许多非常基本的 servlet 错误。

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

  • 将 JNDI 名称更改为 EE 6 标准化名称
  • 从 JBoss Cache 迁移到 Infinispan（我们的部分代码已迁移到平面 API，某些部分仍然使用树 API）
  • 安全性稍微不太灵活（你不能再修复经过身份验证和未经身份验证的调用）
  • 一些可怕的代码依赖于远程 JNDI 的详细信息
  • EJB 客户端的配置不同
  • 所有用于安装、部署、启动、停止的脚本......
  • ExternalContext 消失了，我们必须替换 我们用不同的方法
  • 用 @StartUp EJB 替换了 SAR 中的 MBean
  • 对 Cocoon 进行了一些丑陋的修改

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

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.

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.

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

The AS 7.x series has a lot of 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.

回复 原文
赢得她心 2024-11-18 15:57:17

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

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

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

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

回复 原文
~没有更多了~

关于作者

黑寡妇

暂无简介

0 文章
0 评论
24 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

離殇

文章 0 评论 0

小姐丶请自重

文章 0 评论 0

Aik

文章 0 评论 0

国产ˉ祖宗

文章 0 评论 0

猥琐帝

文章 0 评论 0

半仙

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文