Tomcat运行原理，使用IDEA整合tomcat，创建并编译部署动态web工程

0. Tomcat运行原理

重要参考：
Tomcat运行原理
web服务器专栏

0.1. Tomcat服务器的本质

Tomcat是运行在JVM中的一个进程，也是一个servlet容器，用来帮助我们接收浏览器的请求和返回响应；
Web工程是一堆资源文件和方法，但是没有main方法，无法自动运行；
将Web工程部署到Tomcat，就是希望Tomcat调用Web工程中写好的方法，为客户端返回需要的资源和数据；
Tomcat一定有main方法，可以调用Web工程中写好的方法；
部署到Tomcat服务器的Web工程必须按照约定的目录结构和规定的接口来进行编写。

0.2. Tomcat 服务器体系结构

在一个tomcat中部署多个web工程，及一台主机启动多个tomcat服务

1.Service组件：
Service主要用于关联一个引擎和与此引擎相关的连接器，
每个连接器通过一个特定的端口和协议接收入站请求交将其转发至关联的引擎进行处理。
例如：8080端口对应HTTP协议、8443端口对应HTTPS协议。
注：同一台主机启动多个Tomcat服务时，不同server的相同功能连接器不能使用同一个端口。
这意味着如果在同一个主机上启动了多个Server实例，必须配置它们使用不同的端口，例如server1的HTTP的Connector端口为默认值8080，server2的HTTP的Connector端口需要重新设置，比如配置为8081。

注：Tomcat服务器主要有两大核心模块组成：连接器和容器

Tomcat 连接器
2.Connector组件
Tomcat service用来接收用户的请求，然后封装请求传递给容器处理。 为不同协议的请求分别定义好对应的连接器，用来正确接收来自于客户端的请求。
一个引擎可以有一个或多个连接器，以适应多种请求方式。

Tomcat中的四种容器
3.Engine组件
tomcat engine是一个完整的Servlet容器，其下面拥有多个虚拟主机，它的责任就是将用户请求分配给一个虚拟主机处理。
Tomcat Engine容器
4.Host组件
tomcat中一个Host代表一个虚拟主机，位于Engine容器中，一个虚拟主机上可以有多个应用，Host负责安装和展开这些应用，其子容器为Context。
5.Context组件
Tomcat中一个Context用于标识tomcat实例中的一个Web应用程序，代表ServletContext，管理多个Servlet，理论上只要有Context就可以运行Servlet了，其子容器为Wrapper。
6.Wrapper
Wrapper 代表一个 Servlet，它负责管理一个 Servlet，包括的 Servlet 的装载、初始化、执行以及资源回收。
Tomcat Wrapper容器

何为Servlet?，servlet就是一个类，只不过这个类能够接受和处理请求，并且做出响应，该类需要在web.xml中配置。

0.3.Tomcat 处理一个HTTP请求的过程

用户在浏览器中输入网址localhost:8080/test/index.jsp，请求被发送到本机端口8080，被在那里监听的Coyote HTTP/1.1 Connector获得；

Connector把该请求交给它所在的Service的Engine（Container）来处理，并等待Engine的回应；

Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host；
Engine匹配到名为localhost的虚拟主机（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）；

名为localhost的虚拟主机获得请求/test/index.jsp，匹配它所拥有的所有Context。
Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为“ ”的Context去处理）；

path=“/test”的Context获得请求/index.jsp，在它的mapping table中寻找出对应的Servlet。
Context匹配到URL Pattern为*.jsp的Servlet，对应于JspServlet类；
构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet()或doPost(),执行业务逻辑、数据存储等；

Context把执行完之后的HttpServletResponse对象返回给Host；
Host把HttpServletResponse对象返回给Engine；
Engine把HttpServletResponse对象返回Connector；
Connector把HttpServletResponse对象返回给客户Browser

1. idea部署tomcat服务器

2. 创建动态web工程，选择application server

3. 修改web工程的tomcat服务器配置信息

update resources-只更新web资源
update classes and resources-更新字节码文件及web资源，用于热部署。即当修改html/jsp等前端文件时，服务器会自动更新修改，在浏览器端刷新页面即可显示更新信息。
redeploy-重新部署服务，但服务器不重启。即当servlet filter listener等服务器文件更新时，需重新部署服务才能生效。
restart server-重启服务器。

因此, on ‘update’ action 选择 重新部署 redeploy；on frame deactivation 选择 热部署 update classes and resources。

application context设置编译部署后的web工程 test1.war对应的访问路径为**/test1**（test1:war exploded是部署在服务器中的web工程，先给动态web工程打war包，再进行部署）
此时访问web工程资源的url为：http://localhost:8080/test1/资源

4. idea中的web工程目录解析

此处少了一个web-inf以及web-xml文件，是idea的版本导致的。
注：web.xml是我们创建的动态web工程的配置文件。

创建web-xml之后的目录：

web工程: 
	src: 存放java源代码 .java文件，下设不同package
	web: 
		web资源
		web-info(受服务器保护，浏览器不能直接访问)
			lib-存放第三方jar包
			web.xml 为整个web工程的配置部署描述文件，servlet listener filter session等配置信息
		index.jsp 在浏览器中输入工程名时，默认访问的资源

5. idea中的web工程 经过编译部署后的目录解析

重要：一个B/S工程最终运行的是这个web工程 编译、部署后的结果，即访问编译、部署后的web资源文件、字节码文件等。

因此，我们要了解web工程编译部署后的目录，它和idea中的web工程目录有所不同。

写访问路径URL时，要以编译部署结果为准，不能以工程中的路径为准。

从图中可知，book:war exploded工程编译、部署后的路径为Output directory。
原工程路径：

对应的编译、部署结果：

可以发现：
工程中的src目录在编译部署后到了WEB-INF下的classes目录；
工程中的web目录下的静态资源pages目录、static目录在编译部署后到了工程目录下
且编译部署后的路径中无src、web目录。

此前我们已经设置过web工程book:war exploded的映射访问路径为**/book**，如下图所示。

因此，pages目录对应的URL为编译部署后的地址/book/pages，而不是原工程中地址/book/web/pages。
即我们常说的 “工程路径直接映射到web下的静态资源”。
(注：斜杠在浏览器中被解析为http://主机:port/)

6. 通过新建library管理项目jar包

给当前web工程，新建libraries，用于管理jar包