部署到Web容器，捆绑Web容器或嵌入Web容器

Question

我正在开发一个应用程序，需要尽可能简单地为最终用户安装。虽然最终用户可能会遇到Linux用户（或销售工程师），但他们对Tomcat，Jetty等一无所知，我认为他们也不应该这样做。

所以我看到了3种部署应用程序的方法。我还应该声明这是我必须部署的第一个具有Web界面的应用程序，所以我之前没有真正面对过这个问题。

首先将应用程序部署到现有Web容器中。由于我们只部署到Suse或RedHat这看起来很容易。但是，我们对在一个Web容器中运行多个应用程序的想法并不重视。这使得删除一个应用程序变得更加困难。

下一个选项是捆绑Tomcat或Jetty，让启动/关闭脚本启动捆绑的Web容器。

或者第3，嵌入..这可能会提供与第二个选项相同的用户体验。

我很好奇其他人在面对这个问题时所做的事情，以便在最终用户身上尽可能地证明这一点。

我几乎排除了部署到现有Web容器，因为我们经常喜欢设置每个应用程序资源限制和CPU亲和力，我认为这会影响部署到Web容器/应用服务器的所有应用程序，而不仅仅是特定的应用程序

谢谢。

Answer 1

部署多个war文件（或者在完整的Java EE应用程序服务器的情况下为ear文件）这个想法曾经是一个承诺，但实际上并没有很好地发挥作用。

一个主要问题是，尽管取得了重大进展，但EAR战争的热重新加载仍然存在问题。内存泄漏，资源泄漏，类加载器问题......它们不断发生。因此，最安全的重新部署方法是重新启动整个servlet容器或应用程序服务器，但这会删除其上运行的所有其他应用程序。

将多个应用程序部署到单个AS的第二个问题是它们之间只有一层薄薄的隔离。应用程序可以从其他应用程序访问JNDI中的资源。这可能不是合作应用程序的问题，但对于可能彼此敌对的应用程序来说，这确实是一个问题。

通常，servlet容器不能替代多任务，隔离操作系统。

随着Xen等廉价高效虚拟化产品的推出，每个servlet容器只需一个应用程序（实际上是捆绑它们）并将它们部署到Xen客户端似乎是一个更好的选择。

这样做的另一个好处是，它提供了一个更简单的路径来升级应用程序所依赖的库。如果您考虑将Tomcat 6的固定安装作为部署平台，那么单个应用程序不能仅从Tomcat 7升级到Servlet 3.0，因为这将影响在同一Tomcat上运行的所有其他应用程序。这对于像JBoss AS这样的完整Java EE堆栈来说更为重要，因为这些堆栈会增加更多的库。

在实践中，这通常意味着使用运行多个应用程序的固定Tomcat，您可以简单地从不升级您的应用程序以利用Tomcat提供的更新的库/ apis，因为总有一些其他应用程序由于某种原因或其他无法升级。这很快就会降成一场噩梦。

Answer 2

查看Hudson build engine.

它既可以部署到现有的Web容器，也可以只使用“java -jar hudson.war”运行。对于Windows，如果以管理员权限运行，它可以将自身注册为服务。

它使用专为此用途而设计的Winstone servlet container来完成此操作。

Answer 3

在我看来，将web应用程序与servlet容器（Tomcat或Jetty）一起分发并不是一种罕见的选择。您获得的是：完全控制Web应用程序的配置，最终用户不关心配置详细信息。但是，缺点之一是增加了安装包的大小。