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