Java webapp部署：爆炸式分解还是不爆炸？

战争文件是否应以分解格式部署？还是没有？

这将取决于几个因素：

• 是否要求应用程序服务器管理员在部署后修改 WAR 文件的内容？如果答案是肯定的，特别是在涉及属性或配置文件的情况下，那么您应该使用分解格式。这样可以更轻松地对文件进行更改，而无需重新部署完整的 WAR 文件。
• 如何将更改传播到生产环境？如果您没有预先编译 JSP 文件，并且打算通过将 JSP 复制到包含分解 WAR 文件的区域来部署较新版本的 JSP，那么很明显，重新部署一个巨大的 WAR 文件并不是最佳解决方案。但是，请注意，这将取决于您的部署实践。通常，更容易审核生产中的 WAR 文件是否是从版本控制生成的版本的副本，以及 WAR 文件的单个哈希。如果部署增量更改，您会发现部署的每个文件都需要哈希。
• 您希望应用程序在多长时间内部署并使其可用？这一点是微不足道的，但是有足够的应用程序实例需要几分钟才能启动，因为应用程序服务器正忙于分解 WAR 文件并重新创建必要的工件。如果服务器的行为是在每次重新启动应用程序服务器时爆炸 WAR 文件，这可能会导致长时间停机。由于我不知道 JBoss 的行为或相关特定版本，因此我建议您自行验证这一点，以确保您可以将停机时间限制在可接受的水平。

修改分解内容当然更快、更有效，但一个考虑因素是审核和可追溯性。仅部署 WAR 文件并将其视为“密封”文件的一个优点是，您所做的任何更改都必须在源代码管理系统中捕获。您当然不希望人们能够在没有某种审计跟踪的情况下更改应用程序配置中的任何内容。

Java EE 关注点分离通常意味着 WAR 的开发人员与应用服务器的管理员不是同一个人。如果开发人员没有直接访问权限，这意味着不完全了解应用程序的人正在进行更改。

我并不是在为禁止开发人员修改爆炸式WAR的极端心态辩护，只是指出另一种观点供你考虑。