eclipse 使用tomcat运行JavaWeb项目,文件修改后为何不用重启tomcat? (运行web项目的4种方式)探究
1.情景说明
在eclipse中,为什么Java文件修改后,重启tomcat class文件才能生效?
为什么jsp修改后,不需重启tomcat就能立即生效?
为什么静态资源(*.js,*.css,*.html,图片、pdf)等文件修改后,会即时生效?
2.探究eclipse的自动构建功能(Build Automatically)
自动构建的对象:src目录下的所有文件;
src目录被指定用来存放Java源文件(*.java)及配置文件(*.xml,*.properties等),也可以存放其它格式文件。
自动构建功能有2层含义:
其一,Java文件;
当Java文件有变动(Java文件被创建、修改、删除)时,eclipse会自动调用jdk的编译命令,
将Java文件编译成class文件并输出到WEB/INF/classes目录下。
其二,非Java文件(如:配置文件)。
当配置文件有变动(Java文件被创建、修改、删除)时,不管是什么样的文件格式,只要是存在于src目录下,
eclipse都会自动将其复制到WEB/INF/classes目录下。
证明:
测试一:修改LoginAction.java文件
修改前
修改后:
测试二:在src目录下新建一个text文件
WEB-INF/classes目录下同样被复制了一份
关闭自动编译功能,将导致Java文件修改后不会被重新编译, 配置文件不会同步!
测试三:删除配置文件txt
先关闭自动构建功能(取消勾选即可)
在eclipse中,刚才新建的txt文件删除
你会发现:WEB-INF/classes目录下该文件并没有被删除。
重新勾选上 Build Automatically
WEB-INF/classes目录下该文件已经被删除。
3.在eclipse中,项目开发阶段,探究运行JavaWeb项目的常用的4种方式及区别
方式一:选中项目-->右键-->Run As-->Run on Server
方式二:选中项目-->右键-->Debug As-->Debug on Server
方式三:将项目拷贝到tomcat的webapps目录下,启动tomcat;
方式四:修改tomcat的server.xml,在Host标签内配置Context标签,启动tomcat。
探究一:
前提:项目发布在tomcat的webapps目录下;
当文件内容发生变化后,是eclipse将变化后的文件更新至tomcat,还是tomcat自动将更新后的文件拷贝至webapps目录下?
前两种方式,通过eclipse自动将项目发布至tomcat的webapps目录下;
第三种,自己手动将项目拷贝至tomcat的webapps目录下。
测试1:第一种发布方式测试
打开base_login.js
打开webapps下对应的该文件
在eclipse中修改该文件
切换到notepad++,你会发现该文件同样发生了变化
至此,我们还分不清到底时eclipse更新了该文件还是tomcat更新了该文件。
测试2:第三种发布方式测试
在eclipse中修改base_login.js文件后,webapps下对应的该文件并未发生变化!
2018/11/16
测试3:关闭eclipse中负责启动这个项目的tomcat的自动发布功能
切换到server窗口
双击打开你要修改的tomcat,选择第一个(默认为第二个),保存,不用重启tomcat就会生效。
对文件进行修改后,webapps目录下该项目对应的文件并未更新!
结论:
在eclipse中,所有格式的文件发生变化后(文件新增、修改、删除),要想实现将更新后的资源自动发布至tomcat,需要满足2个条件:
其一:通过eclipse将项目发布至tomcat的webapps目录下,判断依据:
对应的服务器下会展示已经发布的项目。
其二:需要开启“当资源发生变化时,自动发布至tomcat的检测功能”(这个是默认选中的)。
第三种方式之所以不能实现实时更新,是因为不能满足第一个条件!
原生的tomcat是没有第二个功能的;
所以说,是eclipse负责将变化后的文件更新至webapps中的对应项目下,
与原生的tomcat服务器无关,它只负责从webapps对应的项目下读取文件!
探究二:
前提:前3种发布方式中,
哪种发布方式,eclipse会自动将class格式文件更新至tomcat?
测试3:debug模式下运行项目(debug as)
打开LoginAction.java
在tomcat的webapps目录下找到并使用Java反编译工具打开该文件
修改该文件
使用反编译工具重新打开对应的文件
tomcat服务器被重新启动
访问这个Java类对应的controller,控制台输出结果:
测试4:普通模式下运行项目(run as)
在eclipse中修改LoginAcion.java文件后,webapps下对应的class文件并未发生变化!
结论:
手动将项目拷贝到webaps目录下进行发布项目,在eclipse对文件进行修改后,并不能实时更新文件,这种方式只适合项目正式运行阶段使用;
只有以Debug as方式发布项目,eclipse才会将class格式文件更新至tomcat。
探究三:
不管是以run as还是debug as的形式发布项目,
当jsp文件发生变化(文件新增、修改、删除)时,eclipse会自动将变化后的文件更新至tomcat的webapps目录下对应文件。
为什么?因为eclipse为tomcat推送的是jsp文件,tomcat负责将jsp转换成servlet,并编译成class文件
测试5:tomcat负责jsp的编译工作
jsp文件被编译后会被放到tomcat的work目录下;
只有请求时才会对jsp文件进行编译;
每个目录下都有jsp文件
因为只请求了登录页面,所以tomcat只对其对应的jsp进行了编译工作
每次对该页面进行请求时,tomcat都会检测对应的jsp文件是否更新,如果已经更新就会对其进行重新编译。
jsp处理流程图
探究四:
配置Context标签发布项目(热部署)的方式,直接启动tomcat即可。
具体方法:在eclipse中修改响应的tomcat的server.xml
在Host标签内添加Context标签
<Context docBase="D:\workspace-eclipse\jkkywpt_pydzk\web" path="/jkkywpt_pydzk"/>
tomcat的Context标签的docBase属性的值指定为web项目的发布目录(WebContent/WebRoot)后,启动tomcat后,
tomcat会直接访问将该目录下的文件并将其加载到tomcat容器中,不会再将项目发布到webapps目录下;
测试6:tomcat不会再将项目发布到webapps目录下
启动tomcat
webapps目录下并未发布该项目
因此,eclipse就省去了将更新后的资源推送到tomcat的webapps目录下的步骤。
测试7:eclipse中tomcat服务器的 “当资源发生变化时,自动发布至tomcat的检测功能”会失效。
关闭tomcat的自动发布功能
普通模式下,启动tomcat
base_login.jsp页面的原标题为aaa
浏览器展示效果
修改标题为测试
刷新页面后
由此,已经证明: eclipse的服务器的自动发布功能已经不起作用了。
测试8:只有在debug模式下运行项目,Java文件修改后会即时生效!
普通模式下,修改LoginAction.java文件
class文件已经更新
页面请求后,控制台并无输出内容
debug模式运行该项目
修改Java文件
浏览器刷新后,控制台输出结果:
由此,可以证明:在eclipse中,只有在debug模式下,无需重启tomcat,Java虚拟机会即时生效。
原理说明:
对于Java类的更新:当监听到class文件被修改后,通过动态修改内存中的字节码,将修改过的class文件再次装载到JVM中;
对于jsp的更新:jsp每次被调用时,tomcat容器都会通过ClassLoader重新加载相应的jsp编译后的class文件并装载到JVM中,
tomcat在调用jsp前,会检测该文件是否被更新,如果被更新,会重新编译这个jsp文件。
注意:
只有在修改方法体内的Java代码这一种情况,不需要重启tomcat!
4.总结
总的来说,文件修改后,之所以不用重启tomcat是因为eclipse的自动构建功能,
自动构建,将文件更新至tomcat的webapps目录下(class文件除外);
普通模式运行下,java文件重新编译后,并不会被推送至webapps目录下;
debug模式运行下,java文件重新编译后,class文件会被推送至webapps目录下,并且被tomcat更新至JVM;
jsp文件之所以不用重启tomcat,也是依赖于eclipse的自动构建功能;
tomcat负责jsp的编译工作。
发布及运行项目,对比说明:
拷贝至webapps下发布项目:
运行方式:将项目拷贝至weapps目录下或者将项目打成的war包再放到weapps目录下
需要说明的是:tomcat并不是从war包解读所需文件,而是将war进行解压,也就是说tomcat本身并识别war包,只是被赋予了一个解压功能而已!
tomcat运行后,自动执行了解压功能
是否指定解压功能依赖于server.xml中Host标签的unpackWARs属性,默认值为true
特点:这种方式只适合在运行阶段使用;
缺点:不适用于开发阶段,无法进行代码调试!
使用eclipse发布项目,并以普通模式运行项目(run):
当Java文件发生变化后,不会即时生效的原因有二:
其一,tomcat里的对应class文件并未更新,
其二,eclipse中,只有debug模式启动项目,Java代码才会即时生效。
特点:适合开发阶段使用,但不建议使用;
缺点:不重启tomcat的前提下,只适合前端调试,修改Java文件,必须重启tomcat。
使用eclipse发布项目,并以debug模式运行项目(debug):
当Java文件发生变化后,可以即时生效的原因有二:
其一,tomcat里的对应class文件被同步更新,
其二,在eclipse中,以debug模式启动项目,Java代码会被更新至Java虚拟机,因此会即时生效。
特点:适合开发阶段使用,大部分人会使用。
当Java文件修改后,eclipse虽然会将更新后的文件更新至tomcat,但是默认会重启tomcat。
如何关闭tomcat重启?见文末推荐。
(因为就算是不重启tomcat,jvm也会即时生效)
缺点有二:
其一,Java文件修改后,会重启tomcat,我们必须等待项目重启后才能操作;(通过上面的方式可以解决);
其二,eclipse会将项目发布至tomcat的webapps目录下,当我们不需要改项目时,需手动将其删除。
配置Context标签发布并运行项目(热部署):
这种方式就是我们常说的热部署!
运行方式:直接启动tomcat(普通模式、debug模式);
特点:适合开发阶段使用, 推崇以debug模式启动项目。
优点:
加载的项目会随着的tomcat的启动和关闭而产生或死亡,不会留下任何痕迹(work文件夹除外);
而将项目发布到tomcat的方式,实际上是将项目发布到tomcat指定的发布目录webapps文件夹,需要将清理webapps文件夹才能保证只加载该项目到tomcat中;
而采用热部署的方式不会直接从WebContent目录下读取项目,不会在tomcat的webapps下产生任何文件;
方便调试、Java代码方法体内代码修改无需重启;
当然了,可以在server.xml下配置多个项目。
本文来自博客园,作者:Marydon,转载请注明原文链接:https://www.cnblogs.com/Marydon20170307/p/9963822.html