Spring Boot3 应用打包成 War 包的详细指南

大家好，欢迎来到IT知识分享网。

在当今的互联网软件开发领域，Spring Boot 框架以其便捷高效的特性深受开发者喜爱。通常情况下，Spring Boot 应用默认会被打包成可执行的 JAR 文件，这种方式内置了诸如 Tomcat、Jetty 等 Servlet 容器，极大地简化了应用的部署流程。然而，在一些特定场景中，比如企业级环境下需要将应用部署到独立的 Tomcat 服务器时，将 Spring Boot3 应用打包成 War 包就成为了一项必要的技能。本文将为广大互联网软件开发人员详细介绍如何将 Spring Boot3 应用成功打包成 War 包。

为何选择将 Spring Boot3 应用打包成 War 包

（一）部署到外部 Servlet 容器的需求

当我们的应用需要运行在独立的 Tomcat、WebLogic 等 Servlet 容器中时，War 包是一种标准的格式选择。以企业级项目为例，很多公司内部已经搭建好了统一的 Tomcat 服务器集群，为了便于管理和维护，要求所有的 Web 应用都以 War 包的形式进行部署。这种情况下，将 Spring Boot3 应用打包成 War 包就显得尤为重要。

（二）资源集中管理的优势

在企业环境中，运维团队往往需要统一管理多个应用的部署。通过将应用打包成 War 包，可以方便地将多个应用部署到同一台服务器上，实现资源的集中管理。例如，一个大型企业有多个不同功能的互联网应用，如电商平台、客户管理系统、办公自动化系统等，这些应用都可以打包成 War 包，然后部署到同一台高性能的服务器上，通过合理配置服务器资源，提高资源利用率，降低运维成本。

（三）兼容性需求的考量

部分遗留系统或特定的中间件可能仅支持 War 包的部署方式。一些传统的金融机构或政府部门，其内部的业务系统经过多年的发展，底层架构较为复杂，其中一些中间件只识别 War 包格式。如果我们基于 Spring Boot3 开发的新应用需要与这些遗留系统或特定中间件进行集成，就必须将其打包成 War 包以满足兼容性要求。

Spring Boot3 应用打包成 War 包的详细步骤

（一）修改项目的 pom.xml 文件

设置打包类型为 war

打开项目的 pom.xml 文件，找到<packaging>标签，将其值修改为war，即<packaging>war</packaging>。这一步操作明确告诉 Maven 构建工具，我们希望将项目打包成 War 包格式。

排除 Spring Boot 的内嵌 Tomcat 依赖

为了避免与外部 Tomcat 服务器产生冲突，我们需要在构建配置中排除 Spring Boot 自带的内嵌 Tomcat 依赖。在 pom.xml 文件中添加如下依赖配置：

<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <scope>provided</scope> </dependency>

这里的<scope>provided</scope>表示该依赖仅在编译和测试阶段有效，在打包时会被排除。这样，在部署到外部 Tomcat 服务器时，就不会出现因重复依赖导致的冲突问题。

添加项目名称（可选）

如果希望在访问项目时设置特定的 URL 前缀，可以在 pom.xml 中添加项目名称。例如，若将 War 包命名为myapp，那么访问项目的 URL 前缀可能就是/myapp。需要注意的是，如果不想要前缀，可以将 War 包命名为ROOT。同时，这要和项目的 Java 配置文件中设置的context-path路径保持一致。例如，在application.properties文件中设置
server.servlet.context-path=/myapp，那么 War 包的名称也应该与之对应。

（二）改写应用的启动类

让应用的启动类继承
SpringBootServletInitializer类，并覆盖configure方法。以下是一个示例代码：

package com.example.demo; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.boot.builder.SpringApplicationBuilder; import org.springframework.boot.web.servlet.support.SpringBootServletInitializer; @SpringBootApplication public class DemoApplication extends SpringBootServletInitializer { @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { return application.sources(DemoApplication.class); } public static void main(String[] args) { SpringApplication.run(DemoApplication.class, args); } }

通过继承
SpringBootServletInitializer并重写configure方法，能够使 Spring Boot 应用适应外部 Servlet 容器的启动机制，确保应用在外部 Tomcat 服务器上能够正常启动运行。

（三）执行打包操作

在完成上述配置后，我们就可以进行打包操作了。在项目的根目录下，打开命令行终端，执行 Maven 命令mvn clean package -Dmaven.test.skip=true。这条命令的作用是先清理项目的构建目录，然后进行打包操作，同时跳过测试用例的执行（如果项目中的测试用例较多，执行测试可能会花费较长时间，通过-Dmaven.test.skip=true可以加快打包速度）。

打包成功后，生成的 War 包会存放在项目的target目录下。War 包的名称通常遵循{artifactId}-{version}.war的格式，其中{artifactId}是项目在 pom.xml 中定义的 artifactId，{version}是项目的版本号。例如，如果项目的 artifactId 是myspringbootapp，版本号是1.0.0，那么生成的 War 包名称就是myspringbootapp-1.0.0.war。

将 War 包部署到 Tomcat 服务器的相关注意事项

（一）配置 Tomcat 服务器

修改 Tomcat 的端口号

为了避免端口冲突，确保 Tomcat 服务器的端口号与项目配置文件中设置的端口一致。例如，在 Spring Boot 项目的application.properties文件中设置了server.port=8180，那么就需要在 Tomcat 的conf/server.xml文件中找到<Connector>标签，将其port属性值修改为8180，如下所示：

<Connector port="8180" protocol="org.apache.coyote.http11.Http11NioProtocol" connectionTimeout="20000" redirectPort="8443" />

指定 Tomcat 的 JDK 版本（如果需要）

如果 Tomcat 服务器需要使用特定版本的 JDK，可以在 Tomcat 的启动文件中进行配置。在 Windows 系统下，打开 Tomcat 安装目录下的bin/setclasspath.bat文件；在 Linux 系统下，打开bin/setclasspath.sh文件。例如，若要指定使用
/data/java/jdk_17/jdk-17.0.10版本的 JDK，可以在setclasspath.sh文件中添加如下配置：

修改 Tomcat 启动窗口名称（可选）

当服务器上同时运行多个 Tomcat 实例时，为了便于区分不同的项目，可以修改 Tomcat 的启动窗口名称。在 Windows 系统下，打开 Tomcat 安装目录下的bin/catalina.bat文件，找到set _EXECJAVA=”%_RUNJAVA%”这一行，在其下方添加title Tomcat – myapp（这里的myapp可以替换为你自己的项目标识）。这样，在启动 Tomcat 时，命令行窗口的标题就会显示为Tomcat – myapp，方便识别。

（二）处理可能出现的问题

上下文路径（Context Path）问题：在部署 War 包时，可能会遇到上下文路径配置不正确的问题。例如，访问项目时出现 404 错误，原因可能是外部容器的路径与内嵌服务器存在差异。此时，需要确保在项目的配置文件中设置的
server.servlet.context-path与 War 包部署到 Tomcat 后的访问路径一致。同时，要注意 War 包的名称与上下文路径的对应关系，如果 War 包名称为myapp.war，那么在没有额外配置的情况下，访问路径可能就是/myapp。

依赖冲突问题：虽然我们在打包时排除了 Spring Boot 的内嵌 Tomcat 依赖，但在实际部署过程中，仍可能出现其他依赖冲突的情况。尤其是当项目中引入了大量的第三方库时，不同库之间可能对某些类的版本有不同的要求。解决这类问题的方法是仔细检查项目的依赖树，可以使用 Maven 的dependency:tree命令查看项目的依赖关系，找出冲突的依赖并进行版本调整。

外部化配置问题：在将 Spring Boot 应用打包成 War 包部署到外部 Tomcat 服务器时，应避免在 War 包中硬编码敏感配置信息，如数据库连接字符串、密码等。建议使用环境变量、外部配置文件或配置服务来管理这些配置信息。例如，可以将数据库连接配置放在一个独立的application – external.properties文件中，然后在 Tomcat 的启动脚本中通过环境变量指定该配置文件的路径，这样在不同的部署环境下可以方便地修改配置而无需重新打包应用。

日志配置问题：由于 Tomcat 有自己的日志配置规范，将 Spring Boot 应用部署到 Tomcat 后，可能需要调整 Spring Boot 的日志配置以适应 Tomcat 环境。可以在项目的src/main/resources目录下创建一个logback – tomcat.xml文件，在其中重新配置日志的输出格式、输出级别、日志文件的存储位置等。例如，设置日志输出到 Tomcat 的logs目录下，并按照每天生成一个新的日志文件的方式进行配置：

<configuration> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${catalina.base}/logs/myapp.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>${catalina.base}/logs/myapp.%d{yyyy - MM - dd}.log.gz</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder> <pattern>%d{yyyy - MM - dd HH:mm:ss} [%thread] %-5level %logger{36} - %msg%n</pattern> </encoder> </appender> <root level="info"> <appender - ref ref="FILE" /> </root> </configuration>

健康检查与监控问题：如果在 Spring Boot 应用中使用了 Spring Boot Actuator 来进行健康检查和监控，在部署到 Tomcat 后，可能需要调整端点路径以适应 Tomcat 部署的上下文路径。例如，原本在 JAR 包部署时，健康检查的端点路径是/actuator/health，部署到 Tomcat 后，可能需要根据上下文路径调整为/myapp/actuator/health（假设上下文路径为/myapp）。同时，要确保 Tomcat 服务器的安全配置允许访问这些监控端点，避免出现安全漏洞。

总结

将 Spring Boot3 应用打包成 War 包并部署到外部 Tomcat 服务器，虽然相较于直接使用 JAR 包部署会稍微复杂一些，但在特定的企业级和兼容性需求场景下，却是非常必要的技能。通过本文详细介绍的修改 pom.xml 文件、改写启动类、执行打包操作以及部署到 Tomcat 服务器的注意事项等步骤，相信广大互联网软件开发人员能够顺利地将 Spring Boot3 应用以 War 包的形式进行部署，为项目的稳定运行和高效管理提供有力支持。在实际操作过程中，遇到问题不要慌张，仔细排查每一个配置环节和可能出现的错误，通过不断实践和总结经验，提升自己在 Java 应用部署方面的技术能力。

希望本文能对您在 Spring Boot3 应用打包成 War 包的工作中有所帮助，如有任何疑问或建议，欢迎在评论区留言交流。让我们一起在互联网软件开发的道路上不断探索前进！