环境:intellij idea + spring + maven
项目:spring集成Javaweb(servlet+jsp) 项目名称:ithema_spring_mvc
出现的问题:在写好代码以后,在Tomcat上进行部署的步骤过程中出现各种问题
本文章内容:详解在Tomcat上进行部署项目的过程,Intellij IDEA
一、将javaweb项目部署到Tomcat上的过程
1、首先写好java代码,配置好spring的配置文件applicationContext.xml和网站的配置文件web.xml
2、在idea中工具栏选择:Run-->Edit Configuration
3、如下选择红框中的内容
4、然后选择 红框中的内容,这是真正的部署的关键操作,如下图
5、然后选择 要部署的项目:如下红框所示, 然后 右下角 Apply-->OK
二、出现的问题
1、如下图所示,图中的 Tomcat Server找不到,说明你没有在idea中配置好Tomcat服务器
2、配置服务器的过程如下
(1)首先安装好Tomcat,在此就不多说了,网上一大堆教程
(2)在 idea 中配置Tomcat服务器,如下,选择 File-->setting
然后选择如下图所示:
上图中的 Tomcat Hone 选择到 安装的Tomcat服务器的根目录即可,不用选择到 bin文件上,选择完成后如下:
好了,在idea上配置Tomcat服务器完成,下面在此打开部署web项目的配置:Run-->Edit Configuration,如下,发现最左边还是没有Tomcat Server选项,解决方法如下:
解决方法:选择加号
完成后的效果如下:
注意:上图中最下面的红框提示你还没有将你打包好的 artifacts项目部署到服务器上,那么我们需要将项目部署到服务器上,部署的过程就回到了本文最开始的教程。就是选择上面图片中的Deployment选项卡进行部署。这个也解释了Artifacts可以把项目包装成war包
,有关Artifacts的讲解见下文
注意:上面的tomcat端口步需要和tomcat默认端口一致,可以灵活配置,这个类似VS IIS EXPRESS调试里的动态端口设置,很方便不用担心端口冲突,来回修改。
因为没有在刚添加的服务器上部署web项目,所以转到本文最开始,开始在Deployment选项卡上部署项目。
下一步:
要想运行网站需要配置deployment,类似ASP.NET中的网站发布设置,为什么需要设置呢,Tomcat是运行装idea外部的,只有发布到tomcat的网站目录才能运行web程序,这里属于自动发布到Tomcat目录里,然后才发送tomcat启动命令,就实现了自动启动web程序的功能。这里选择的发布文件格式为“Artifact”.
全部保存好,再运行程序就能看到JSP启动页面了。
最新的springboot已经能完全内嵌tomcat运行了,更加简单.JAVA开发自动有了IDEA已经越来越智能化了.
Idea真的将你的项目自动发布到Tomcat目录里了吗?详见后文
三、将项目打包成Artifacts
在选择完Deployment选项卡,并进行项目部署的时候,可能会出现,在如下如所示的情况,就是在选择完加号+之后,弹出的窗口中没有你要部署的项目,咋办?这说明你没有将你写好的web项目进行打包成Artifacts。好,下面讲解如何将项目打包成Artifacts
1、如下图操作 File-->Project Structure
3、如下,选择你要打包的项目,OK
四、好了,以上就完成配置了,去运行吧
哈哈,出错了
报的错误是:
IEDA中报异常:Caused by: java.lang.NoClassDefFoundError: org/springframework/web/context/WebApplicationContext
这个时候我们通常可能会认为我们没有导包或者包导错了,反复检查都很正常:
解决办法:
1、
2.根据下图操作
3.OK即可解决问题
注:此处摘自:Thinkao~ 的文章:https://blog.csdn.net/wangxinyao1997/article/details/88087564
四、什么是 Artifacts?
写好了javaweb项目后,之前我一直按照网上的方式尝试了很久,也用了一段时间intellij idea ,现在总结一下部署的方法.
1. 查看facets是否配置正确
在 Project Structure 中查看 facets选项卡是否配置好:
不管是不是导入的项目,首先看 Deployment Descriptiors 下的Path,因为这个是web.xml文件的路径,要看路径配置对了没有
然后看,下图中下方红框:Path Relative to Deployment Root 。这个是web项目的根目录,类似于eclipse中的webContent目录
2. Artifacts到底是什么?
Artifacts是一种用于装载项目资产以便于测试,部署,或者分布式软件的解决方案。简单来说就是一个工具包,只要把项目在这里包装就能够放入Tomcat去运行.
3. 创建war包(war包就是web项目打包后的后缀名,比如普通java项目打包后的后缀名是jar包.)
标注1:使用该方式创建的war包是解压好的,也就是可以进行热部署(热部署就是实时更新修改的java代码或者jsp页面等等)的项目,建议开发时选择这个Exploded的方式打包.
标注2:使用Archive打包的web项目时压缩包,后缀名为.war的压缩包,不支持热部署.
标注3:选择from Modules,从模块中选择要打包的项目.
此时打包已经完成:
接着就可以开始配置Tomcat,当然如果你是导入的项目可能需要配置输出目录和jdk,最重要的是配置好web.xml文件和web根目录.
4. 配置Tomcat并部署项目到Tomcat中
此处就是本文最开始将的地方,在此就不在重复了,因为一模一样
5. 项目虽然部署完成了,点击run按钮就可以启动服务器了,但是还可以根据需要进行热部署,我看了网上很多关于热部署的方式,但是都没有将全面或者是方法不可行.
此处详见参考的文章https://blog.csdn.net/qq_33442160/article/details/81367926
6. 项目路径解释
刚刚开始使用intellij idea时还不懂这个配置,启动项目后一直按照原来的方式(本地地址+项目名称)去打开项目,但是一直报错404. 也就是说,按照上图中最下面红框中的内容进行配置的话,有可能会报404错误。解决办法如下图:就是将上图中最下方红框中的配置改成下图所示
默认设置是 / ,意思是你的项目根路径为localhost:8080/ 。
但是localhost:8080/这个不是Tomcat的主页吗?实际上Tomcat根本没有加载这个ROOT项目(Tomcat的主页项目名称),只加载了一个自己部署的项目,如果不习惯可以自己加上项目名称,比如:
不知道啥原因啊,我自己第一次写成上述图片中所示,汇报404错误,但是后来在重新写一下上图中的配置,重新执行,不报错误了!!!!有点奇怪,这个奇怪的地方可以解释,详见下面“七、intellij idea部署web项目时的位置(Tomcat)”
————————————————
版权声明:本文为CSDN博主「可C但是没有必要」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_33442160/article/details/81367926
五、Project Structure详解
六、为什么在Tomcat的webapps目录里面为什么找不到我刚部署的项目
intellij idea 使用Tomcat部署javaweb项目后到Tomcat的webapps目录下找不到项目.
1、首先看下部署项目后webapps的目录
2、在Tomcat的安装路径上进行查看,如下图,这个例子是从网上找的,就是一个示意图,目的是讲解在应该在哪里找自己部署的项目(应该在下图中的位置查找自己发布的项目),但是找不到这项目,为啥呢?继续往下看
3首先说明怎么找到已经部署好的项目,再来解释原因.
3.1 首先点击项目,右键点击Show in Explorer.
2.2
其实,这个out目录就是在你创建项目是指定的输出目录,注意是创建project时,而不是创建Modules。具体如下所示:
那么,这个out输出路径还可以在哪看呢?还可以在你创建的项目中进行查看,如下所示:
为啥查看 artifacts选项卡呢?因为你在服务器上部署的是artifacts项目,所以要查看artifacts的输出位置是在哪里。
2.3
2.4
如上图所示:此时部署的web项目已经找到.
4、
intellij idea使用Tomcat部署项目后并不会把编译后的项目复制到tomcat的webapps目录下,但是它会把编译好的项目路径告诉Tomcat,让Tomcat来找到这个项目,其它的项目比如Tomcat的主页项目ROOT是打不开的,因为intellij idea 只让Tomcat运行了一个项目.
接下来看一下war包的目录结构,也就是整个web项目编译后的目录结构
接着:
5.tomcat有4中部署方式,eclipse的部署方式与IntelliJ idea的部署方式不同.
tomcat部署方式分别是:
(1)利用Tomcat自动部署
项目放到webapps目录下,启动tomcat,就回自动部署
(2)利用控制台进行部署
控制台不是说cmd,而是tomcat启动后进入root页面,有个manager管理部署项目.
进入tomcat的manager控制台的deploy区域进行设置就可以部署
上面这两种都是自己用的,就是平时别人发包过来,然后丢进去,启动tomcat就部署,但是开发工具没有用上面两种.
web项目不是必须放在webapps文件夹里面才能部署的,放在其它位置为也可以部署,
eclipse默认放在工作空间的.metadata文件夹,可以修改到其它地方,一般配置在webapps文件夹.
而idea是配置到out文件夹,就是输出目录.
————————————————
版权声明:本文为CSDN博主「可C但是没有必要」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/qq_33442160/article/details/81347319
七、intellij idea部署web项目时的位置(Tomcat)
在idea中运行tomcat,把项目部署运行起来,然后我去tomcat目录下去看,找不到我部署的项目 那我的项目是怎么运行起来的?
说明一下:这里是使用tomcat 部署成war exploded 而不是war包。war exploded模式是直接把文件夹、jsp页面 、classes等等移到Tomcat 部署文件夹里面,进行加载部署。因此这种方式支持热部署,一般在开发的时候也是用这种方式。在平时开发的时候,使用热部署的话,应该对Tomcat进行相应的设置,这样的话修改的jsp界面什么的东西才可以及时的显示出来。
如上,将两处都修改成Update resources即可。
webapps下面文件夹都翻了一遍,都没有发现部署的项目。
去work文件夹下也看了一遍,是空的。
后来发现,在idea中配置的tomcat,在运行时idea不会把项目放到自己的webapps路径下,而是复制三份文件到 ${user.home}/.IntelliJIdea/system/tomcat 目录下的各自项目。
我们进入该目录,看到如下(名称是通过我们的项目名转化而来):
也就是说每个项目都有属于自己的一份tomcat配置,互不干扰。
我们进入其中一个项目下,看到如下:(在自己的tomcat安装目录下是看不到日志的,日志在这里,还有一些配置文件)
每个项目的配置文件夹中有一个 /conf/Catalina/localhost/ROOT.xml 文件,内容如下:
其中,path是指在访问此项目时,是否需要添加额外的路径,如果为空,则直接使用域名或者ip就可以访问到该项目:127.0.0.1。这个值在ieda中的Run/Debug Configurations中可以配置:(即Application context)
如果现在我在Application context加上:/springSecurityDemo
Server这边会自动加入:springSecurityDemo/
这时候,我们运行tomcat之后,在conf/Catalina/localhost没有发现ROOT.xml,而是springSecurityDemo.xml文件,内容如下:
这时候项目的访问路径是:http://localhost:8145/springSecurityDemo/
docBase是指要运行的项目的部署位置,/myProject/springSecurityDemo 就是我的项目源代码的位置,build是由gradle构建后生成的,gradle build完成之后生成的项目,结构
如下:
而idea启动tomcat的命令在这里:
整个项目运行过程是:首先gradle build项目,将构建结果写到项目的build目录下,然后idea复制一份tomcat的conf、logs和work文件夹到${user.home}/.IntelliJIdea/system/tomcat 中,之后启动tomcat安装目录下的catalina.sh文件,tomcat读取配置文件,找到项目位置,然后就运行起来了。
-------------------------------------------------------------------------------------
如果是使用tomcat 部署成是war包。那么会不会就能在自己安装的tomcat中找到呢?
刚开始我将项目改为war部署的方式,但是运行之后tomcat中始终没有项目的文件。后来发现如果将当前的Application context设置为’/’,那么
tomcat也不会将项目部署到webapps中,因为这个相当于你项目的根路径。后来经过实践,发现这个Application context就是你项目在webapps路径下项目的根目录名。
本文摘自:
liuguoxionglang:https://blog.csdn.net/liuguoxionglang/article/details/79389338