我在客户站点部署了war文件。 War文件包含lib文件夹，其中包含依赖的jar，例如
/lib/app-01.jar /lib/spring-2.5.1.jar /lib/somefile-1.2.jar ... ...
如果我们需要更新，请将app-01.jar称为app-02.jar，有没有优雅的解决方案？这些依赖的jar如何作为行业标准打包到WAR文件中？
打包那些没有版本号的依赖罐子是个好主意吗？ e.g。
/lib/app.jar /lib/spring.jar /lib/somefile.jar ... ...
编辑说明： 实际上，War已部署到Windows或Linux平台上的Webshpere，WebLogic，Tomcat。并且客户的IT部门参与部署
答案 0 :(得分：2)
最优雅的解决方案可能就是生成一场新战争并进行部署。
原因如下：
如果您担心正常运行时间，某些应用程序服务器支持并排部署。这意味着您可以部署新版本并在旧版本的同时进行更新。当没有人使用它时，请停止旧的。 （我在WebLogic上使用它，就像5年前一样，所以我认为这是一个常见的功能）。但是，只有在部署新的.WAR版本时，此类功能才有效。
可能是使用Maven，Ant或Gradle生成的WAR，因此更改依赖关系版本并执行mvn package通常比解压WAR更快且更不容易出错，更改它并再次压缩它
所有应用程序服务器都提供“热替换”功能，通过刷新类加载器来工作。它很适合开发，但在生产中它可能会有问题（类加载器泄漏可能很常见，由不正确的初始化或错误的编程实践引起的问题可能会给你带来意想不到的错误，比如有两个版本的类）
关于JAR文件名：我建议将版本保留在文件名中。 大多数JAR包含META-INF / Manifest.mf中的版本信息。但是如果由于某种原因你必须知道哪些版本正在使用你的应用程序...打开每个JAR文件以查看清单中的版本是很多工作。
作为最后的建议。如果你不使用任何自动构建工具......采用一个（看看Gradle，这很好）。更新库版本通常包括更改构建文件上的版本号并执行gradle deploy之类的操作。即使您不是开发人员，也是负责开发人员的人，拥有自动构建将帮助您进行部署和更新。
答案 1 :(得分：0)
在Tomcat中，我不认为在文件解压缩后战争是相关的。您可以忽略战争并将新的/更改的文件提取到正确的webapp目录（与战争同名的目录）。