39

Java EE 应用服务器提供了 tomcat 的所有功能，那么为什么要使用 tomcat（而不是 glassfish，例如它是官方的）？

尤其是当需要 JPA、JAX-RS、JSF 等 Java EE 功能时，因此必须将更多库与应用程序打包在一起，而兼容 EE 的应用程序服务器会开箱即用地提供它？

4

7 回答 7

81

我们脑海中的问题以及我们创建TomEE的全部原因是，人们为什么要选择？

整个“Tomcat 或 JavaEE”的东西已经很累了。

10 年后它仍然出现，人们互相争论哪个更好以及为什么。

这是简短形式的数学：

  • 在 Java EE 6 中，我们 (JCP) 创建了 Web Profile 以正式承认需要具有一组重点技术的更小的运行时。

太好了，我们已经完成了一半，但人们仍在争论“Tomcat还是JavaEE”。解决方案很明确，Tomcat 需要通过 Java EE 认证。Web Profile 的创建正是为了实现这一点。

  • 2011 年，我们 (Apache) 开始开展认证 Apache Tomcat 的工作。获得认证并在 JavaOne 2011 上宣布为 Apache TomEE。最终版本于 4 月宣布。

太棒了，现在我们在那里。

新现状

  • 有一个轻量级的 JavaEE 版本
  • Tomcat有JavaEE认证版本

这一切都发生在过去的两年里。事情变了。

如果你想要Tomcat 和 JavaEE，你可以拥有它。

于 2012-06-30T17:29:02.973 回答
6

人们很少使用普通的Tomcat。他们总是添加大量额外的东西，比如 web 框架、一些 orm、一些 DI 框架等。

您可以为此使用 Spring，但最终结果将是庞大、臃肿的，并且您将被迫进行大量 XML 编程。

现代 Java EE 6 实现非常轻量级（TomEE 和 Resin 仅 25mb）并包含您需要的一切（Web、持久性、DI）。所谓的 Web Profile 不包含任何您很少需要的东西。现代 Java EE 6 服务器在一两秒内启动，这与裸 Tomcat 处于同一级别，但它们实际上提供了您每天所需的工具。

于 2012-06-30T15:09:47.633 回答
5

大多数 Java EE 应用程序服务器都很庞大，带有许多不需要的特性，并且开发/测试周期非常慢（只需查看 java rebel 生产力报告）。如果你真的需要 Java EE 的一些特性，那么你应该使用它，但大多数情况下你可以拥有相同的基本特性（本质上是 servlet 容器，你可以将大部分 Java EE 技术放在一个 tomcat 之上，例如轻量级ejb 容器等）与 tomcat 或任何其他轻量级 servlet 容器。

还要记住，您可以在应用程序服务器之外使用 JPA、JSF、JAX-RS。

TL;DR： Java EE 应用程序服务器显然很慢，不要即时重新加载类并强制执行非常烦人的代码/部署/测试周期（考虑从 20 秒到 8 分钟的任何时间来测试 Java 代码中的一些更改）。大多数人只需要基本功能（本质上是 servlet 容器）。

这是一份关于 2011 年重新部署时间的报告：http: //zeroturnaround.com/java-ee-productivity-report-2011/#redeploy_times

于 2012-06-29T13:43:03.950 回答
3

正如@Miguel Ping 上面所解释的，应用程序服务器包含开发人员不需要的功能。
例如，许多开发人员不需要消息传递代码，因此他们不需要 JMS jar。
其他开发人员可能不需要集群，所以他们不需要集群代码，等等。
由于当今大多数 UI 都面向 Web，必须由应用服务器提供的 Servlet 容器变得越来越重要，因此许多开发人员决定只使用 Servlet 容器（即 tomcat）。
在这种情况下，许多开发人员使用 Spring 框架来替代他们使用普通 Java EE 所拥有的功能（或与 Java EE 集成 - Spring 也可以在应用程序服务器之上运行）。
弹簧芯是轻件，主要提供一个 Depdency Injection/Inversion-Of-Control 容器（替换 Java EE 中的 EJB 容器）。
您可以从 Spring 框架中添加其他模块来为您的应用程序提供更多功能。而在许多应用程序服务器（EJB 3.0 及更低版本的应用程序服务器）中，应用程序服务器正在加载整个堆栈，这也会影响应用程序服务器的启动时间（并且这从个人经验来看，这对开发人员来说非常烦人）。

话虽如此，EJB 3.1 现在包含配置文件，例如 - Web 配置文件，它从 Java EE 规范加载了较少数量的部分。此外，Jboss 在JBoss AS 7中引入了一种并行部署机制，可以分析应用程序内部的依赖关系，并执行独立组件的并行部署。
例如，在oVirt开源项目中，我们将启动时间从一个简单的虚拟化环境部署的 1 多分钟缩短到 3 秒左右。
我不知道其他 EJB 3.1 应用程序服务器中是否存在这种机制，但是，如前所述，您可以很容易地定义配置文件或使用已经存在的配置文件，例如web 配置文件（EJB lite）以减少启动时间


。过去 - 人们使用 tomcat 主要是为了减少启动时间和减少加载的模块数量。
Spring 提供了 Java EE 开发的模块化替代方案，可以与 tomcat 一起使用。
. 在 EJB 3.1 的今天，Java EE 也采用了模块化，还有 JBoss AS 7 等应用服务器，由于在部署过程中进行了各种优化，可以将启动时间缩短到几秒钟。

于 2012-06-29T16:31:45.570 回答
3

Tomcat 是一个编写良好的轻量级 servlet 容器，它可以完成大量 JVM Web 应用程序所需的一切。作为直接与浏览器对话的 Web 服务器，它在生产环境中运行良好。对很多人来说，Java EE 的内容太多了，远远超出了构建稳定有用的应用程序所需的内容。这种类型的人寻找具有更少而不是更多的工具，并且重视稳定编写良好的代码高于功能。软件选择的世界是一个市场，而 Tomcat 很好地服务于该市场的一部分。就像在任何市场中一样，您需要查看替代品并选择满足您需求的产品。Tomcat 只是众多替代方案之一。

在这篇论文http://www.people.hbs.edu/cbaldwin/DR2/LaMantia-Cai-MacCormack-Rusnak%20WICSA2008.pdf中有一个 关于设计结构矩阵的有趣观点。他们将它与一个不知名的竞争对手进行比较，发现它设计得很好。如果您有兴趣分析自己的代码，我知道的唯一 DSM 实现是否是 IntelliJ 企业版，但他们确实为您提供了几周的免费试用期。

就个人而言，我相信简单性是支持软件的优点，而 servlet 容器是支持软件，而不是应用程序的一部分。

于 2012-06-30T03:11:33.527 回答
0

在大多数情况下，有关应用程序服务器选择的决定（Tomcat 与 JBoss 等 AS）将根据小型 IT 部门的管理/开发团队的经验和知识做出，而 IMO 是政治问题而不是技术问题。而且，最多部署在tomcat上的项目，往往都是web应用，集成概念少，复杂度低。对于此类项目，通常会使用轻量级容器和框架（Spring、Struts）。但是，如果项目变得越来越复杂和更加分散，那么可伸缩性、“监控”、高可用性（如 JBoss 的@HASingleton）等属性就会出现到位。然后为您的普通 tomcat 配备 3rd 方框架以获取 AS 的所有功能可能会非常痛苦

于 2012-06-30T18:27:18.693 回答
0

They think they're choosing to be lightweight but at the end of the day their applications will be far heavier weight than they would be using Java EE web profile. If they opt for spring, their deployments are likely to be very large with slower build and server start-up times. Developer productivity declines ... If you want your app to be as simple and lightweight as it can be, opt for a Java EE server that supports web profile.

于 2014-07-23T15:14:10.607 回答