我正在维护越来越多的基于Cocoon-2.1的Web应用程序[ http://cocoon.apache.org/2.1/] ，部署在Tomcat servlet容器[ http://tomcat.apache.org/]中 ，用Apache http服务器代理[ http://httpd.apache.org/docs/2.2/] 。 我在概念上正在苦苦寻找在Tomcat中部署多个Web应用程序的最佳方式。 由于我不是Java程序员，而且我们没有任何系统pipe理员，所以我必须弄清楚自己最明智的做法是什么。 我的设置已经通过2个场景演变，我正在考虑第三个不同的web应用程序的最大分离。
[1] 1个Tomcat实例，1个Cocoon实例，多个webapps
-tomcat |_ webapps |_ webapp1 |_ webapp2 |_ webapp[n] |_ WEB-INF (with Cocoon libs) 这是我的第一个方法：只需将所有Web应用程序放入单个Tomcat容器内的单个Cocoon webapps文件夹中即可。 这似乎运行良好，我没有遇到任何内存问题。
然而，这带来了可维护性的缺点，因为一些Cocoon组件经常更新，这往往会影响到webapp编码。 因此，更新Cocoon变得很笨重：因为所有的webapps共享相同的Cocoon组件库，更新其中一个将会要求所有web应用程序中的代码被同时更新。
为了隔离Web应用程序，我转到了第二种情况。
[2] 1个Tomcat实例，每个webapp都在其专用的Cocoon环境中
-tomcat |_ webapps |_ webapp1 | |_ WEB-INF (with Cocoon libs) |_ webapp1 | |_ WEB-INF (with Cocoon libs) |_ webapp[n] |_ WEB-INF (with Cocoon libs)
这种方法将所有的webapps分离到自己的Cocoon环境中，在一个Tomcat容器中运行。 理论上，这个工作正常：所有的webapps都可以独立更新。
但是，这很快就会导致PermGenSpace错误。 似乎我可以通过增加Tomcat的内存分配来解决这个问题，但是我意识到这不是一个结构性的解决scheme，而以这种方式重载一个Tomcat就容易出现未来的内存错误。
这让我想到了第三种情况。
[3]多个Tomcat实例，每个实例在其专用的Cocoon环境中都有一个webapp
-tomcat |_ webapps |_ webapp1 |_ WEB-INF (with Cocoon libs) -tomcat |_ webapps |_ webapp2 |_ WEB-INF (with Cocoon libs) -tomcat |_ webapps |_ webapp[n] |_ WEB-INF (with Cocoon libs)
我没有尝试过这种方法，但是正在考虑$ CATALINA_BASEvariables。 一个Tomcat发行版可以与不同的$ CATALINA_BASE环境实例化，每个环境都指向一个拥有自己的webapp的Cocoon实例。 我想知道这种方法是否可以避免方法[2]的结构性记忆相关问题，还是同样的问题适用？
另一方面，这种方法会使Apache http前端的pipe理复杂化，因为这将需要不同Tomcat实例的AJP连接器在不同的端口上进行监听。 因此，只要添加新的webapp（在自己的Tomcat实例中），就必须更新和重新载入Apache的workerconfiguration。 似乎没有办法重新加载worker.properties，而无需重新启动整个Apache HTTP服务器。
是否有另外一种更加dynamic的方式来“模块化”多个Tomcat服务的web应用程序，或者可以改进其中的一种情况？
任何想法，build议，build议非常感谢。
罗恩
我已经完成了你所提到的一切，现在我们已经走了一个完全不同的方向。 我们有一个JEos虚拟机映像，我们使用一个瘦身的虚拟化操作系统，我们克隆每个新的应用程序。 从内存/ CPU /磁盘的angular度来看，这不是最有效率的，但是从“哪个端口/目录是所有东西都被钩住了”保存了我的理智。
基本上，服务器决定我们正在使用的应用程序，而不是端口/目录/你有什么。
显然这是行不通的，如果你只有一台机器或者你已经被虚拟化了。 在这种情况下，我build议使用常见的CATALINA_BASE，并将每个新应用程序指向新的CATALINA_HOME。 一个端口编号约定（例如十进制）在这种情况下可以节省您的理智（相信我）。