目前，您会使用 JBoss 或 Glassfish（或其他）作为新项目的 Java EE 服务器吗？

Would you, at present date, use JBoss or Glassfish (or another) as Java EE server for a new project?

提问by

If you started a new Java EE project today which is to be finished in about a year, which application server would you choose and why?

如果您今天开始一个新的 Java EE 项目，该项目将在大约一年内完成，您会选择哪个应用服务器，为什么？

Part of your answer should include your arguments for your decision. And also how much experience you have with the Java EE server you choose and with the other available servers on the market. These are interesting as we all get a sense of the investigation and thought that was put into your answer.

你的部分答案应该包括你的决定的论据。以及您对自己选择的 Java EE 服务器以及市场上其他可用服务器的使用经验。这些很有趣，因为我们都了解了您的答案中的调查和想法。

采纳答案by Rob Williams

I have used WebLogic, WebSphere, JBoss, GlassFish, Resin, Jetty, Tomcat, and a few others over the last 10+ years. So, if I were considering a new project, I would ask myself a few questions first. One thing that I would not question anymore is that I would flat refuse to use JSPs unless I was tortured until I cried for my mommy.

在过去的 10 多年里，我使用过 WebLogic、WebSphere、JBoss、GlassFish、Resin、Jetty、Tomcat 和其他一些。所以，如果我正在考虑一个新项目，我会先问自己几个问题。我不会再质疑的一件事是，除非我被折磨到为我的妈妈哭泣，否则我会坚决拒绝使用 JSP。

Do I have to be compatible/deploy to a specific product because of someone's mandate? Is there no way to ignore them or convince them otherwise? If so, there's your answer.

由于某人的要求，我是否必须兼容/部署到特定产品？有没有办法无视他们或以其他方式说服他们？如果是这样，那就是你的答案。

Do I have to use EJBs? Really? Avoid them if at all possible--they are really only needed for very large, enterprise-class systems. Remember that they are merely tools, and big ones at that (can anyone say "Golden Sledgehammer"?). They are heavily overused, so really, really question whether you need them. If you do need them, then that removes several of your options including my favorite, Jetty.

我必须使用 EJB 吗？真的吗？如果可能，请避免使用它们——实际上只有非常大的企业级系统才需要它们。请记住，它们只是工具，而且是大工具（有人能说“金大锤”吗？）。它们被严重过度使用，所以真的，真的很怀疑你是否需要它们。如果您确实需要它们，那么这将删除您的几个选项，包括我最喜欢的 Jetty。

Do you have to use any of the other major J2EE technologies like JMS, ESB, etc? If so, and you really can't do without, then you are again constrained to a full-blown J2EE container. Carefully think and investigate before you commit to BPM, for example, and avoid AquaLogic BPM at (almost) all costs--it is ugly in the extreme.

您是否必须使用任何其他主要的 J2EE 技术，如 JMS、ESB 等？如果是这样，而且您确实离不开，那么您又将受限于成熟的 J2EE 容器。例如，在您致力于 BPM 之前仔细思考和调查，并且（几乎）不惜一切代价避免 AquaLogic BPM——它在极端情况下是丑陋的。

If you really must use a full-blown J2EE container, consider open-source first because it is more robust, better supported, and more cost-effective. They have larger customer bases and more open support interaction, so they tend to get better fixes faster. However, Resin is immature and I would avoid it relative to GlassFish or JBoss--I found it problematic to deploy and support. I would prefer JBoss because of its wider customer base, maturity, etc. GlassFish is harder to incorporate into an automated build/deployment process, but it might be nicer for some of its specific features (if you need them).

如果您确实必须使用成熟的 J2EE 容器，请首先考虑开源，因为它更健壮、支持更好且更具成本效益。他们拥有更大的客户群和更开放的支持互动，因此他们往往能更快地获得更好的修复。但是，Resin 还不成熟，相对于 GlassFish 或 JBoss，我会避免使用它——我发现部署和支持存在问题。我更喜欢 JBoss，因为它有更广泛的客户群、成熟度等。GlassFish 更难整合到自动化构建/部署过程中，但它的某些特定功能可能更好（如果您需要它们）。

Do I have a special reason to need Apache? Then lean towards Tomcat, perhaps plus something.

我需要 Apache 有什么特殊原因吗？然后倾向于Tomcat，也许再加上一些东西。

Can I make do with just servlets? Then I would use Jetty--it is the lightest, fastest, easiest, most flexible solution. If I am leaning against being able to use Jetty, I would question all my assumptions of why. YAGNI applies.

我可以只使用 servlet 吗？然后我会使用 Jetty——它是最轻、最快、最简单、最灵活的解决方案。如果我反对能够使用 Jetty，我会质疑我对原因的所有假设。YAGNI 适用。

Best is to use StringTemplate/WebStringTemplate on Jetty: a clean, robust, fast, maintainable solution with no licensing fees, solid reputation and support, etc. That is where I start nowadays.

最好是在 Jetty 上使用 StringTemplate/WebStringTemplate：一个干净、健壮、快速、可维护的解决方案，没有许可费用、良好的声誉和支持等。这就是我现在开始的地方。

Most applications/systems choose lots of fancy J2EE features when all they really need is servlets and JDBC with some decent architecture/design. Question why you think you need more.

大多数应用程序/系统选择了许多花哨的 J2EE 特性，而它们真正需要的只是具有一些不错的体系结构/设计的 servlet 和 JDBC。质疑为什么你认为你需要更多。

Of the full-blown containers, I would avoid WebLogic and WebSphere unless you are supporting a MAJOR public website (my current employer's website is deployed on WebLogic and it gets eleven+ million hits per month, others have been comparable). WebLogic's real claim-to-fame is their relatively easy clustering, but avoid their proprietary vendor-lock-in features at (almost) all cost. WebSphere is simply a nightmare that I would avoid literally at all cost--I refuse to do projects involving WebSphere after having done a couple in the past. Neither product is worth the massive licensing fees, unless you truly have a special need that drives the use of a proprietary feature. In a decade as a senior architect/engineer for lots of Fortune 500 companies, I have yet to see such a need. On the other hand, I have seen LOTS of pain due to picking such proprietary products.

在成熟的容器中，我会避​​免使用 WebLogic 和 WebSphere，除非你支持一个主要的公共网站（我目前雇主的网站部署在 WebLogic 上，它每月获得 11 多万次点击，其他网站可与之媲美）。WebLogic 真正声名鹊起的是它们相对容易的集群，但（几乎）不惜一切代价避免其专有的供应商锁定功能。WebSphere 只是一个我会不惜一切代价避免的噩梦——我在过去做过几个项目后拒绝做涉及 WebSphere 的项目。这两种产品都不值得支付巨额的许可费用，除非您确实有特殊需要推动使用专有功能。在为许多财富 500 强公司担任高级架构师/工程师的十年里，我还没有看到这样的需求。另一方面，

Even for the really large, high traffic, public websites, the proprietary products are still questionable. I would rather spend that multi-million dollars per year of licensing fees on some good hardware and some quality time from a handful of really good consultants to address a simple scalability solution. The extra millions per year could then be used to produce something worthy of selling on that nice website...

即使对于真正的大型、高流量、公共网站，其专有产品仍然值得怀疑。我宁愿每年将数百万美元的许可费花在一些好的硬件上，并从少数真正优秀的顾问那里花一些时间来解决简单的可扩展性解决方案。每年额外的数百万美元可以用来生产值得在那个不错的网站上销售的东西......

EDIT: another piece to consider...

编辑：另一件要考虑的......

I have recently encountered Terracotta. I am rethinking everything, and looking to deploy it in a significant system soon. In particular, Terracotta does clustering better than anything else, so I would NO LONGER recommend WebLogic for its clustering.

我最近遇到了兵马俑。我正在重新考虑一切，并希望尽快将其部署到一个重要的系统中。特别是，Terracotta 的集群比其他任何东西都好，所以我不再推荐 WebLogic 来进行集群。

回答by johnstok

I've been using jBoss for 3-4 years.

我已经使用 jBoss 3-4 年了。

Arguments for jBoss:

jBoss 的参数：

1. Open source.
2. Commercial support available.
3. Large, active user community.

1. 开源。
2. 提供商业支持。
3. 庞大、活跃的用户社区。

Arguments against jBoss:

反对 jBoss 的论据：

1. No general-access, supported Java EE 5 container release.
2. Lots of documentation but verbose; can be hard to find the answers to "How do I do x?"
3. Administrative tools for 4.x poor compared to other commercial offerings.

1. 无一般访问、受支持的 Java EE 5 容器版本。
2. 大量文档但冗长；可能很难找到“我如何做 x？”的答案。
3. 与其他商业产品相比，4.x 的管理工具较差。

回答by Brian Matthews

The first question I usually ask myself is "Can I do this with Tomcat?". If the answer is no because I need JMS or JTA then I resort to an application server.

我通常问自己的第一个问题是“我可以用 Tomcat 做到这一点吗？”。如果答案是否定的，因为我需要 JMS 或 JTA，那么我会求助于应用程序服务器。

I used WebLogic 8 about 3 years ago happy with WebLogic's ease of use and the licensing/cost model. We used it for two projects one was a web service and the other was a portal. We did not encounter any problems with WebLogic or WebLogic Portal in either of those projects.

大约 3 年前，我使用 WebLogic 8 对 WebLogic 的易用性和许可/成本模型感到满意。我们将它用于两个项目，一个是 Web 服务，另一个是门户。在这两个项目中，我们都没有遇到 WebLogic 或 WebLogic Portal 的任何问题。

For the last two years I was working with WebSphere. Any time I negotiated with IBM it was always ended up costing twice as much as a WebLogic equivalent but corporate policy dictated WebSphere had to be used. I found the learning curve on WebSphere to be considerably steeper than WebLogic and our build/deploy/test life-cycle was so time consuming that we used Tomcat in the development environment. But the the biggest issue I had with WebSphere was when we encountered a bug that forced us to upgrade to the next patch release only to run into new problem parsing web.xml. It took a 48hr shift to work through all that.

在过去的两年里，我一直在使用 WebSphere。每次我与 IBM 谈判时，结果总是比 WebLogic 等价物高出两倍，但公司政策规定必须使用 WebSphere。我发现 WebSphere 的学习曲线比 WebLogic 陡峭得多，而且我们的构建/部署/测试生命周期非常耗时，以至于我们在开发环境中使用了 Tomcat。但是我在使用 WebSphere 时遇到的最大问题是我们遇到了一个错误，该错误迫使我们升级到下一个补丁版本，结果却在解析 web.xml 时遇到了新问题。完成所有这些工作需要 48 小时轮班。

At the moment though I am using JBoss. About 3 months ago I was about to embark on my new project with Tomcat and Jetspeed 2, But I noticed that Jetspeed 2 seems a bit stagnant right now and JBoss Portal 2.7.0 was just released with JSR 286/Portlet 2.0 support. I gave JBoss a spin and found it very easy to set-up and administer. The build/deploy/test cycle is very quick and I rarely have to restart the server unless I have changed a Spring XML file somewhere.

虽然目前我正在使用 JBoss。大约 3 个月前，我正准备开始我的 Tomcat 和 Jetspeed 2 新项目，但我注意到 Jetspeed 2 现在似乎有点停滞不前，而 JBoss Portal 2.7.0 刚刚发布，支持 JSR 286/Portlet 2.0。我试了一下 JBoss，发现它很容易设置和管理。构建/部署/测试周期非常快，除非我在某处更改了 Spring XML 文件，否则我很少需要重新启动服务器。

回答by Ed.T

I might include your preferred OS as a decision criteria. It should make it easier to support if you are using the same vendor for OS and app server. If you already have a relationship with one or both vendors consider if they are good to deal with.

我可能会将您首选的操作系统作为决策标准。如果您对操作系统和应用程序服务器使用相同的供应商，它应该更容易支持。如果您已经与一个或两个供应商建立了关系，请考虑他们是否适合处理。

From a technical perspective I would choose GlassFish because it has support for more recent innovations. I do not think JBoss is bad in anyway it simply isn't as up-to-date.

从技术角度来看，我会选择 GlassFish，因为它支持更新的创新。我不认为 JBoss 不好，因为它根本不是最新的。

Most of my experience is on WebLogic but I have used JBoss and GlassFish. I just released a new site on a complete Sun open source stack (OpenSolaris, GlassFish, MySQL) and it was a great experience with only minor frustrations.

我的大部分经验都在 WebLogic 上，但我使用过 JBoss 和 GlassFish。我刚刚在完整的 Sun 开源堆栈（OpenSolaris、GlassFish、MySQL）上发布了一个新站点，这是一次很棒的体验，只有轻微的挫败感。

回答by duffymo

I still think that WebLogic is the best Java EE app server on the market. I think it's worth it if you can afford those license fees.

我仍然认为 WebLogic 是市场上最好的 Java EE 应用服务器。如果您能负担得起这些许可费，我认为这是值得的。

I've been surprised to see how far you can go by combining Tomcat, OpenEJB, and ActiveMQ. That would seem to me to be a low-cost alternative.

我很惊讶地看到组合 Tomcat、OpenEJB 和 ActiveMQ 可以走多远。在我看来，这似乎是一种低成本的替代方案。

I'd also look into the Spring dm Server. It's based on Tomcat, but I think the OSGi piece they've added in could be everywhere in short order. If it's done with the same quality as the Spring framework, it'll be very good indeed.

我还会研究 Spring dm 服务器。它基于 Tomcat，但我认为他们添加的 OSGi 部分可以在短时间内随处可见。如果它以与 Spring 框架相同的质量完成，它确实会非常好。

回答by Guy Pardon

An alternative: use no appserver at all.

另一种选择：根本不使用应用程序服务器。

Check out http://www.atomikos.com/Publications/J2eeWithoutApplicationServer.

查看 http://www.atomikos.com/Publications/J2eeWithoutApplicationServer。

For web projects, keep a light web container if you have to, combined with something like Wicket to avoid the complexity of JSP/JSF or struts.

对于 web 项目，如果必须的话，保留一个轻量级的 web 容器，结合像 Wicket 这样的东西来避免 JSP/JSF 或 struts 的复杂性。

HTH Guy

男人

回答by Guy Pardon

The term "application server" is ambiguous. With GlassFish v3, you can start small with, say, a traditional web container and evolve (using OSGi and simple "add container" functionality) to add anything you'd like : JPA, JAX-RS, EJB's, JTA, JMS, ESB, etc... Yet it's the same product, same admin interface, etc. Does this qualify as an application server to you? -Alexis (Sun)

术语“应用程序服务器”含糊不清。使用 GlassFish v3，您可以从一个传统的 Web 容器开始，然后发展（使用 OSGi 和简单的“添加容器”功能）以添加您喜欢的任何内容：JPA、JAX-RS、EJB、JTA、JMS、ESB等等... 然而，它是相同的产品、相同的管理界面等等。这对您来说是否有资格作为应用程序服务器？-亚历克西斯（太阳）

回答by Nazrul

Checkout GlassFish 3.1! Built on top of the modular, Java EE 6 based GlassFish v3 kernel, version 3.1 delivers clustering, centralized administration and high availability.

结帐 GlassFish 3.1！3.1 版构建在模块化、基于 Java EE 6 的 GlassFish v3 内核之上，提供集群、集中管理和高可用性。

Refer to http://blogs.oracle.com/nazrul/entry/glassfish_3_1for more details.

有关更多详细信息，请参阅http://blogs.oracle.com/nazrul/entry/glassfish_3_1。

回答by gert

Another point that was not discussed here is performance. If this is a concern because of the type of service or because of the number of users, then the following will be applicable:

这里没有讨论的另一点是性能。如果这是由于服务类型或用户数量而引起的问题，那么以下将适用：

• Tomcat seems to be slower than Glassfish
• Glassfish seems to be slower than Resin
• Resin is much slower than G-WAN + Java

• Tomcat 似乎比 Glassfish 慢
• Glassfish 似乎比 Resin 慢
• Resin 比 G-WAN + Java 慢很多

Note that G-WAN relies on the JVM alone: it does not use any further containers (unless specified explicitly) so you might reserve it to performance-critical portions of your web applications.

请注意，G-WAN 仅依赖于 JVM：它不使用任何其他容器（除非明确指定），因此您可以将其保留给 Web 应用程序的性能关键部分。

As G-WAN supports other languages (C, C++, C#, D, Objective-C), you may even process some parts of the applications in raw C while keeping Java for other tasks.

由于 G-WAN 支持其他语言（C、C++、C#、D、Objective-C），您甚至可以使用原始 C 处理应用程序的某些部分，同时保留 Java 用于其他任务。