Servlet 容器中的 Java Web 应用程序与独立的

Java web application in a Servlet container vs. standalone

提问by alexantd

What are the advantages of building a small Java web app to run in a Servlet container (like Tomcat) vs. building a standalone Java app with a built-in web server and running it behind a reverse proxy?

构建一个在 Servlet 容器（如 Tomcat）中运行的小型 Java Web 应用程序与构建具有内置 Web 服务器的独立 Java 应用程序并在反向代理后面运行相比有哪些优势？

I've been playing with Java for about a year. I've noticed that to launch Tomcat takes time, and it's not always possible to do a hot-redeploy due to class loader issues. The Servlet API seems somewhat convoluted to me, especially from the perspective of configuration and of RESTful design (which it doesn't really fully support).

我已经使用 Java 大约一年了。我注意到启动 Tomcat 需要时间，并且由于类加载器问题，并不总是可以进行热重新部署。Servlet API 对我来说似乎有些复杂，尤其是从配置和 RESTful 设计的角度来看（它并没有真正完全支持）。

On the other hand, I've noticed that my IDE can compile and run a standalone app at lightning speed. Configuring Apache for reverse-proxying is a piece of cake, and embedded Jetty seems to handle whatever I can throw at it. I don't need Servlets when I can use Restlet, Wicket, etc. Being able to know better how my app works (because it's not integrated with a huge app server) feels empowering. The stack traces are shorter. Download size is smaller. End-user configuration is easier. I'm guessing performance is likely to be better because there are fewer software layers involved.

另一方面，我注意到我的 IDE 可以以闪电般的速度编译和运行一个独立的应用程序。为反向代理配置 Apache 是小菜一碟，嵌入式 Jetty 似乎可以处理我可以扔的任何东西。当我可以使用 Restlet、Wicket 等时，我不需要 Servlet。能够更好地了解我的应用程序是如何工作的（因为它没有与一个巨大的应用程序服务器集成）感觉很强大。堆栈跟踪更短。下载大小较小。最终用户配置更容易。我猜性能可能会更好，因为涉及的软件层较少。

However, I am reminded of the saying that what sounds too good to be true usually is. So my question is, why would I not want to make my web apps standalone? What does a Servlet container give me and/or my end users that we really need but don't know about?

然而，我想起了这句话，听起来好得令人难以置信通常是这样。所以我的问题是，为什么我不想让我的网络应用程序独立？Servlet 容器为我和/或我的最终用户提供了哪些我们真正需要但不知道的东西？

采纳答案by ykaganovich

There are 2 separate questions in here:

这里有两个单独的问题：

1. Should I be using an embedded server, or deploy into a container?

   I don't think you should be seeing a big difference one way or the other. There's slightly more code to startup a Jetty server programmatically, and configuration is easier to do programmatically. Even though IDE support for web app configuration and deployment is getting better, it's still worse than for standalone applications (this is kinda by definitions, since there's a superset of things to support).

   On the other hand, app servers give you some nice benefits like built-in management, built-in ability to run as a service, etc.

   You could even use a hybrid approach: use an embedded server to develop locally, then deploy into a container in production. But that's a bit weird: if you go through the trouble of making a proper WAR file, IDEs should really be able to handle deployment into a container adequately.

   BTW, it's weird that you have issues with hot-redeploy; Tomcat shouldn't be having issues with it unless you're running into some strange corner case...

2. Should I be using Servlet API?

   This is orthogonal from #1. You could very well embed Jetty and implement Servlets. You could also use Restlet API inside Tomcat through a ServerServlet http://www.restlet.org/documentation/1.0/faq#02.

   I personally find the Servlet API to be pretty straight-forward.You get nice things like concurrency and state management. I don't quite know what that means that RESTful design is not supported, but if Restlets address your requirements better, then use that...

1. 我应该使用嵌入式服务器，还是部署到容器中？

   我认为您不应该以一种或另一种方式看到很大的差异。以编程方式启动 Jetty 服务器的代码略多，并且以编程方式进行配置更容易。尽管 IDE 对 Web 应用程序配置和部署的支持越来越好，但它仍然比独立应用程序更糟糕（这有点像定义，因为有一个超集需要支持）。

   另一方面，应用服务器为您提供了一些不错的好处，例如内置管理、内置作为服务运行的能力等。

   您甚至可以使用混合方法：使用嵌入式服务器在本地进行开发，然后在生产中部署到容器中。但这有点奇怪：如果您在制作合适的 WAR 文件时遇到了麻烦，IDE 真的应该能够充分处理部署到容器中的问题。

   顺便说一句，您在热重新部署方面遇到问题很奇怪；Tomcat 不应该有问题，除非你遇到了一些奇怪的极端情况......

2. 我应该使用 Servlet API 吗？

   这是与#1 正交的。您可以很好地嵌入 Jetty 并实现 Servlet。您还可以通过 ServerServlet http://www.restlet.org/documentation/1.0/faq#02在 Tomcat 中使用 Restlet API 。

   我个人认为 Servlet API 非常简单。你会得到像并发和状态管理这样的好东西。我不太清楚这意味着不支持 RESTful 设计，但是如果 Restlets 更好地满足您的要求，那么使用它......

回答by Mike Baranczak

Embedded Jetty can be a good choice if you don't need the full Servlet stack. Unlike Tomcat, Jetty makes it easy to get rid of the parts you're not using (JSP, JNDI, whatever).

如果您不需要完整的 Servlet 堆栈，嵌入式 Jetty 可能是一个不错的选择。与 Tomcat 不同，Jetty 可以轻松删除您不使用的部分（JSP、JNDI 等）。

Writing your own HTTP server, on the other hand, is a terrible idea. Sure, it's easy to write something that handles basic requests. But soon you'll find that some clients are having trouble with it because it doesn't support the full protocol specs; or that it crashes when there's more than a few hundred users; or that there's a vulnerability that allows some kid in Malaysia to blow up your printer. So don't re-invent the wheel.

另一方面，编写自己的 HTTP 服务器是一个糟糕的主意。当然，编写处理基本请求的东西很容易。但是很快你就会发现一些客户端遇到了麻烦，因为它不支持完整的协议规范；或者当有超过几百个用户时它会崩溃；或者有一个漏洞可以让马来西亚的某个孩子炸毁您的打印机。所以不要重新发明轮子。

As for your complaint that the Servlet API doesn't support RESTful design - you're missing the point, it was never intended to do that. But there are plenty of REST libraries that run on top ofthe Servlet API.

至于你抱怨 Servlet API 不支持 RESTful 设计——你没有抓住重点，它从来没有打算这样做。但是有很多 REST 库运行在Servlet API之上。

回答by Costi Ciudatu

An embedded Jetty is also a servlet container. I assume your application includes a web.xml where you define a wicket filter / servlet, the RESTlet servlet and their mappings (at least). So you cannot get rid of the Servlet API (or of a servlet container, even if you embed it), but you can hide it as well as possible underneath your frameworks and into some main() method of your own. RESTlet (or Jersey or any JAX-RS implementation) as well as Spring MVC are all based on servlets, so the Servlet API does support REST pretty well, i'd say.

嵌入式 Jetty 也是一个 servlet 容器。我假设您的应用程序包含一个 web.xml，您可以在其中定义一个 wicket 过滤器/servlet、RESTlet servlet 及其映射（至少）。因此，您无法摆脱 Servlet API（或 servlet 容器，即使您将其嵌入），但您可以将其尽可能隐藏在您的框架下并隐藏在您自己的一些 main() 方法中。RESTlet（或 Jersey 或任何 JAX-RS 实现）以及 Spring MVC 都基于 servlet，所以 Servlet API 确实很好地支持 REST，我想说。

P.S. The two approaches do not exclude each other. You can very well work with Jetty during development and then deploy your war into some (non-embeded) container for QA / production. Or... stick with Jetty for production, if that really suits your needs.

PS 这两种方法并不相互排斥。您可以在开发期间很好地使用 Jetty，然后将您的War部署到某个（非嵌入式）容器中以进行 QA/生产。或者...坚持使用 Jetty 进行生产，如果这确实适合您的需求。

回答by Cameron Skinner

Servlet containers often provide a bunch of useful stuff like automatic session management, hot-deploying, frameworks for failover and clustering and so on. It depends on the container, of course, but sometimes these are very useful tools. Sometimes they are not.

Servlet 容器通常提供大量有用的东西，例如自动会话管理、热部署、故障转移和集群框架等。当然，这取决于容器，但有时这些是非常有用的工具。有时他们不是。

EDIT: Just noticed your comment about hot-redeploy. Yes, sometimes the containers are buggy and a pain to work with, and they all tend to have their own quirks. Nevertheless, sometimes they do provide some really good stuff.

编辑：刚刚注意到您对热重新部署的评论。是的，有时容器有问题并且使用起来很痛苦，而且它们都有自己的怪癖。尽管如此，有时他们确实提供了一些非常好的东西。

回答by Maulik Patel

The in-process Servlet containers are the containers which work inside the JVM of Web server, these provides good performance but poor in scalibility.

进程内Servlet容器是工作在Web服务器JVM内部的容器，这些容器提供了良好的性能但扩展性较差。

The out-of-process containers are the containers which work in the JVM outside the web server. poor in performance but better in scalibility In the case of out-of-process containers, web server and container talks with each other by using the some standard mechanism like IPC.

进程外容器是在 Web 服务器之外的 JVM 中工作的容器。性能差但可扩展性更好 在进程外容器的情况下，Web 服务器和容器通过使用一些标准机制（如 IPC）相互对话。

In addition to these types of containers, there is 3rd type which is stand-alone servlet containers. These are an integral part of the web server.

除了这些类型的容器之外，还有第三种类型，即独立的 servlet 容器。这些是 Web 服务器的组成部分。

回答by Greg

if you are having issues with your hot deploy, most likely you aren't cleaning up your external connections or other resources. To handle this, usually you want to implement a listener that will let you know when something is started or stopped.

如果您在热部署时遇到问题，很可能您没有清理外部连接或其他资源。为了解决这个问题，通常你想要实现一个监听器，它会让你知道什么时候开始或停止。

you should probably in your wars implement something like this (tomcat 6):

你可能应该在你的战​​争中实现这样的东西（tomcat 6）：

public class MyTomcatInitCleanupListener implements ServletContextListener
{
    @Override
    public void contextInitialized(ServletContextEvent arg0)
    {
        super.contextInitialized(arg0);
    }

    @Override
    public void contextDestroyed(ServletContextEvent arg0)
    {
        super.contextDestroyed(arg0);
    }
}

for tomcat 7+, you can google "tomcat lifecycle listener"

对于 tomcat 7+，你可以谷歌“tomcat 生命周期监听器”