SpringMVC的Tomcat两种部署方式

王路飞的挚友

已于 2024-10-05 15:01:40 修改

阅读量2.1k

点赞数 9

分类专栏： JAVA 文章标签： spring

于 2024-06-18 21:21:46 首次发布

本文链接：https://blog.csdn.net/m0_71796330/article/details/139769220

版权

JAVA 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

文章目录

写在前面

你是否被SpringMVC部署感到困扰过？你是否对Tomcat的配置感到困扰？
今天它来了!!!
前置条件，下载tomcat并配置环境变量，找到符合自己JAVA语言版本的tomcat，请注意自己的Tomcat版本的兼容性!!!.
Tomcat各种版本的适配
 Tomcat环境变量配置

第一种部署方式

如果第一次配置的话需要按照步骤来进行

点开编辑配置
点开编辑配置
编辑配置模版

在这里插入图片描述

找到Tomcat本地服务器

在这里插入图片描述

确定之后是这样的

在这里插入图片描述

选择部署方式

在这里插入图片描述
选择第二个，这是开发阶段的版本

确定之后就可以直接部署项目了。

点击运行，然后直接就能访问到部署的项目

在这里插入图片描述

第二种部署方式

打包操作

因为SpringMVC打包的是war包，所以需要执行依次clean compile package 步骤（需要注意的是执行package之前需要把test模块排除在外
在这里插入图片描述
最终得到一个war的压缩包以及一个未被压缩的war目录文件

开始部署

将未压缩的目录文件拷贝到已安装的Tomcat的目录的webapps下
D:\install_software\Idea\apache-tomcat-8.5.100\apache-tomcat-8.5.100\webapps 在这里插入图片描述
这里容易遗漏的是，需要打开conf目录下的web.xml文件，找到以下内容

<servlet>
        <servlet-name>default</servlet-name>
        <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
        <init-param>
            <param-name>debug</param-name>
            <param-value>0</param-value>
        </init-param>
        <init-param>
            <param-name>listings</param-name>
            <param-value>false</param-value>
        </init-param>
        <load-on-startup>1</load-on-startup>
    </servlet>

将<param-value>false</param-value> 改成 <param-value>true</param-value>

最后一步

双击运行bin目录下的startup.bat批处理脚本
在这里插入图片描述

至此已经完成了SpringMVC的部署了

打开任意一个可访问的浏览器运行，输入项目的IP 和端口号加上war文件名 /index.jsp就能愉快的访问到项目了。
如：localhost:8080/bw_hotel-0.1/index.jsp

示例：
在这里插入图片描述

直接运行部署（非打包部署）
过程：直接将Web项目的文件夹结构（包含WEB-INF、META-INF、jsp、class文件等）复制到Tomcat的webapps目录下。Tomcat服务器启动时，会自动检测并加载这些目录下的应用。

优点：
快速简便：无需额外的打包步骤，直接复制文件即可。
易于调试：对于开发环境来说，修改代码后无需重新打包，Tomcat支持热部署，可以直接看到修改效果。
缺点：
不适合生产环境：因为所有源代码和配置文件都直接暴露在外，不够安全。
管理不便：不利于版本控制和回滚，也不便于在多服务器间迁移。

打包部署（WAR包部署）
过程：将Web项目打包成一个WAR（Web Archive）文件，然后将这个WAR文件放置到Tomcat的webapps目录下，Tomcat会自动解压并部署这个WAR包。
优点：
安全性高：源代码和配置文件都被压缩在WAR包内，外部不易直接访问。
便于管理：WAR包是标准的Java Web部署单元，方便版本管理和回滚，也便于自动化部署流程。
易于迁移：可以在不同的环境中快速部署同一版本的应用。
缺点：
部署速度：相比直接运行部署，需要解压WAR包，部署过程稍慢。
调试不便：修改代码后需要重新打包部署，开发阶段不如直接运行部署灵活。

总结
打包部署（WAR包部署）直接运行部署适用于快速开发和调试阶段，便于快速迭代。
则更适合生产环境和版本控制，提供了更好的安全性和可维护性。
选择哪种部署方式取决于当前的工作阶段和需求，开发环境可能更倾向于直接运行部署以提高效率，而生产环境则通常采用打包部署以保证安全和管理的便利性。