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