我正在运行tomcat 8服务器，我在那里部署了多个tapestry webapps。当我使用maven构建war文件时，所有依赖项（包括tapestry框架jar）都打包到WEB-INF / lib中。所以我在每场战争中都有挂毯。据我所知，tomcat为每个war文件使用不同的类加载器，所以也许我使用的内存资源比所需的多，这是我的关注点。
我所做的是将tapestry jar部署到$ {catalina.base} / lib / tapestry并相应地更新catalina.properties，以便tomcat加载此目录中的jar。此外，我更改了项目的maven依赖项，以便tapestry库不会打包到WEB-INF / lib中。它似乎工作。但我想知道这种工作方式是否有问题可能会在将来带来问题。似乎没有人这样做：我无法在挂毯网站上找到有关这是一个好的或坏的政策及其原因的任何信息。有人知道吗？
答案 0 :(得分：0)
从长远来看，你最好拥有自包含的war文件，每个war文件包含尽可能多的必需依赖项，而不是依赖于“提供的”依赖项或其他类路径依赖项。在某些情况下（但不是很多）您需要将jar放在war文件之外，以便服务器可以在启动时访问它们，但这听起来不像其中一种情况。
将Tapestry jar放在共享位置将是一个完全可以忽略的优化。此外，如果您的某个应用需要不同版本的Tapestry，它可能会在以后出现问题。
另一个潜在的问题是，如果您切换到与Tomcat不同的应用程序服务器（甚至是不同版本的Tomcat）。不同的应用服务器以不同的方式处理类加载，这是您想要应对的最后一类问题。
答案 1 :(得分：0)
不，这没错。我之前做过瘦的战争部署。您可以将所有“很少更改”的依赖项部署到Tomcat lib目录，而不是仅部署Tapestry库。你获得的是部署新版本战争所需的总时间，因为所有代码的大小通常只是包含所有依赖项的整个war文件大小的一小部分。权衡是增加的部署复杂性，即保持单独部署的库与您的应用程序同步，因为最终您也希望对它们进行更改。这种权衡是否值得，取决于您的应用程序的个性化需求以及您的开发和部署速度。一切正常，因为Tomcat实现了类加载器层次结构（https://tomcat.apache.org/tomcat-8.0-doc/class-loader-howto.html）。但是，通过公共类加载器加载类的一个潜在问题是它可能会放大内存泄漏，因为与webapp类加载器不同，只有在容器停止时才会卸载common。