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下配置多个项目。

 

写在最后

  哪位大佬如若发现文章存在纰漏之处或需要补充更多内容,欢迎留言!!!

 相关推荐:

 

posted @ 2018-11-15 15:31  Marydon  阅读(8370)  评论(0编辑  收藏  举报