Analysis of tomcat architecture <1>

Yes, recently a little busy for a long time do not look at the source code
today, speaking under tomcat's overall architecture and process flow analysis, we all know that is a tomcat servlet container, do what the question is, why have a tomcat servlet container
or So what is the theoretical basis for
me to write a servlet first

I'll write a simple servlet, the servlet then he tied it under the tomcat webapp directory into the war about to start to try


and access paths can be found on our hellow
this time

localhost:8080/testDemo/testDemo/
主机  ：占用的端口/ 我的那个应用 /我的servlet

========================>

tomcat是一个web容器 这句话我们该怎么去理解
一个web 应用到底有那些方式部署到我们的tomcat上

Based on these two questions,

I deleted a part of the contents of this folder at this time. At this time, I can still access my servlet. I found that after the war package was decompressed, it was finally a .class file
. So another question is to be thrown at this time.

	一个war 最后就是class
	一个jar 最后也是class
	似乎是一样的
	呢么此时我一个web应用打成jar扔到tomcat下就可以了， 
	为什么此时会打成war而扔到tomcat呢，而不直接打成jar呢

站在tomcat的角度上来结局这个问题 就是
我们知道.jar 在java中大多数情况都是一种依赖，
比如说是给别人用的，呢么我tomcat启动后 发现webapp目录下有一个
.jar ,他怎么判断 此时这个.jar是给别人用的呢 还是一个web项目
所以 tomcat就创建了.war  
也就是说 如果此时是一个.jar的话 我tomcat 不做处理 ，如果是一个.war的话
我就来部署他
如果说我看到这个文件是以.war结尾的 呢么我就对这个war进行部署

tomcat underlying source code is written so I'm not hearsay ah

good question back to the previous `

一个web 应用到底有那些方式部署到我们的tomcat上

The result is 3

Now that the war package deployment and folder deployment are understood, the folder deployment is to decompress the war
. What is the problem? What is the descriptor deployment?

我们在学习servlet的时候除了吧war文件夹放到tomcat的webapp下，
我们还可以以另外一种方式来部署应用  我们可以写一个<context>节点

I always generate this folder under target every time I hit war

在tomcat中使用context节点部署工程	
我此时在tomcat的service.xml 配置这个Context,
  path表示访问这个项目的名字 ，docbase表示此时文件夹的路径 
  意思是通过路径找到项目内容 然后我去部署项目中内容

Still this content, when we put this war under the tomcat webapp, we are equivalent to moving the content of the project to tomcat, that is to say, at this time, I manually move the content of the project to tomcat,
so at this time for For tomcat, I only need to know the content of the project.
That is to say, the docBase at this time points to the address of my war.

我用context节点代表
表示我此时定义一个应用[名字]  应用的内容就是 在docBase
所谓的内容要么通过文件夹/war找到项目内容
要么通过地址找到项目内容[项目的地址，这个项目下可以有很多Servlet ]

I find your content and then I will deploy your project.
Context represents an application, which is essentially an interface in tomcat

So at this timeTomcat是一个Servlet容器

Let's take a look at several important containers in this Container

Context-----应用----容器
				List<Servlet>

3. Engine (自然讲Host也是需要管理的啊) 
		List<Host>管理虚拟主机
2.Host
	List<Context> //
	是Context 的父层节点 主要启的作用是将应用进行隔离
	localhost是虚拟主机 也就是我们访问的localhost
	此时再定义多个虚拟主机   同样的一个应用部署在 不同的虚拟主机
				根据域名判断---》虚拟主机--->找应用
				所以此时虚拟主机的目的就是将应用进行隔离
				进行解耦啊对吧，就是说将我们的请求基于业务下进行的拆分 或者说是基于应用来拆分（看图）
1.Context我也说了 
		List<Servlet>

唯一的难点就是在于这个wrapper
	wrapper 在host和Context中间
			一个Context 会有好多servlet
当一个Servlet实现了SingleThreadModel这个接口的时候,
,每一个请求都是一个实例，也就是说此时每一个请求都会配置一个Servlet
 如果不实现这个接口 代表所有请求公用一个Servlet
 如果此时使用 三层的话 代表我Context下面的Servlet很乱
 所以说此时单独抽象一个wrapper 
 这个wrapper实际上对应的就是 某一个Servlet类
这个wrapper 有2个属性
		属性	List<Servlet>
	    属性	Servlet[实现接口]
	    如果此时一个Servlet实现了SingleThreadModel 这个接口  就会用List<Servlet>
	    如果没有实现的话 就会用这个属性 意思是就只有一个Servlet实例
	   ===========================================>
	   而此时我Context 存 List<wrapper >

此时这也就是tomcat的容器架构图

 继续抛问题， 
 此时tomcat这么设计 吧这些东西分层了
呢么此时对于每一个容器
只是存了些对象的话并没有什么用
所以说此时会涉及到另外一个组件 叫做管道PipeLine(水管),管道中有很多阀门
value 阀门
此时在每一个容器里面都有一个管道
							
管道中真正重要的是这个阀门，这个阀门有自定义的，也有默认的
这些默认的阀门有一个重要的作用就是 相当于一个桥梁
将请求从Engine传到host上

所以说此时的 tomcat架构 

This valve is similar to a filter.


For example, at this time, I create a TestValve and configure it under Host. At this time, when the request passes through the host of localhost, the invoke method in the Value
--------------- ------------------------------------------------->
Summarize a version.

I now have a request. Tomcat will first encapsulate the request into a request
and then hand the request to the Engine container.

When creating an instance of StandardEngine, it will set one by default.pipeline.setBasic(new StandardEngineValve());

At this time, this Basic means that the request is passed to the Host, which is what this valve realizes.

每个Pipeline都是有特定的Valve，而且是在管道的最后一个执行，
这个Valve叫BaseValve，也就是此时的BaseValve  作用就是说将请求进行传递

呢么此时再抛一个问题，我定义一个Servlet就会有一个doget方法,呢么我这个doget方法
是谁来执行的，并且执行doget()我此时需要吧一个实现类传递给你

 呢么问题来了 这些接口的实现类是什么
	doget方法到底是谁来执行的

tomcat中有org.apache.catalina.connector.Request  这个类 但是

在调试servlet程序时，遇到调试窗口右上侧显示RequestFacade和ResponseFacade
此时tomcat这边用到了门面模式
也就是说此时 doget(request,response) 
传递的此参数是RequestFacade和ResponseFacade
因为此时tomcat不想吧某些东西暴露出来

 当我们的请求
		  走到最后面的阀门的时候	  这个阀门里面就会调用
		  wrapper----->生成一个servlet实例 然后调用value 	就会调用他这个doget（）方法

at this timeservlet = wrapper.allocate(); 这里就吧servlet给我们找到了