正文

Tomcat Server

IP云
IP云V管理员/2 阅读
09/13
提示：扫一扫查出行
【扫一扫了解最新限行尾号】
复制提示

Tomcat Server的组成部分:

站在框架的顶层的是Server和Service
Server:servletcontainer

Service:Service是这样一个集合：它由一个或者多个Connector组成，以及一个Engine，负责处理所有Connector所获得的客户请求

在Container这个层， 我们包含了3种容器： Engin, Host, Context.

Connector:一个Connector将在某个指定端口上侦听客户请求，并将获得的请求交给Engine来处理，从Engine处获得回应并返回客户

（Connector: Tomcat都是在容器里面处理问题的， 而容器又到哪里去取得输入信息呢？
Connector就是专干这个的。 他会把从socket传递过来的数据， 封装成Request, 传递给容器来处理。）

Engin: 收到service传递过来的需求， 处理后， 将结果返回给service( service 是通过 connector 这个媒介来和Engin互动的 ).
   Host: Engin收到service传递过来的需求后，不会自己处理， 而是交给合适的Host来处理。
Host在这里就是虚拟主机的意思， 通常我们都只会使用一个主机，既“localhost”本地机来处理。

Context:Host接到了从Host传过来的需求后， 也不会自己处理， 而是交给合适的Context来处理。

一个Context对应于一个Web Application，一个WebApplication由一个或者多个Servlet组成
Context在创建的时候将根据配置文件$CATALINA_HOME/conf/web.xml和$WEBAPP_HOME/WEB-INF/web.xml载入Servlet类
当Context获得请求时，将在自己的映射表(mappingtable)中寻找相匹配的Servlet类
如果找到，则执行该类，获得请求的回应，并返回.

Context的部署配置文件web.xml的说明:
一个Context对应于一个Web App，每个Web App是由一个或者多个servlet组成的
当一个Web App被初始化的时候，它将用自己的ClassLoader对象载入“部署配置文件web.xml”中定义的每个servlet类
它首先载入在$CATALINA_HOME/conf/web.xml中部署的servlet类
然后载入在自己的Web App根目录下的WEB-INF/web.xml中部署的servlet类
web.xml文件有两部分：servlet类定义和servlet映射定义
每个被载入的servlet类都有一个名字，且被填入该Context的映射表(mapping table)中，和某种url-pattern对应
当该Context获得请求时，将查询mapping table，找到被请求的servlet，并执行以获得请求回应
分析一下所有的Context共享的web.xml文件，在其中定义的servlet被所有的Web App载入

Tomcat Server处理一个http请求的过程

假设来自客户的请求为：
http://localhost:8080/wsota/wsota_index.jsp

1) 请求被发送到本机端口8080，被在那里侦听的Coyote HTTP/1.1 Connector获得
2) Connector把该请求交给它所在的Service的Engine来处理，并等待来自Engine的回应
3) Engine获得请求localhost/wsota/wsota_index.jsp，匹配它所拥有的所有虚拟主机Host
4) Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机）
5) localhost Host获得请求/wsota/wsota_index.jsp，匹配它所拥有的所有Context
6) Host匹配到路径为/wsota的Context（如果匹配不到就把该请求交给路径名为""的Context去处理）
7) path="/wsota"的Context获得请求/wsota_index.jsp，在它的mapping table中寻找对应的servlet
8) Context匹配到URL PATTERN为*.jsp的servlet，对应于JspServlet类
9) 构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet或doPost方法
10)Context把执行完了之后的HttpServletResponse对象返回给Host
11)Host把HttpServletResponse对象返回给Engine
12)Engine把HttpServletResponse对象返回给Connector
13)Connector把HttpServletResponse对象返回给客户browser

<!-- 概述：conf包下的web.xml   
该文件是所有的WEB APP共用的部署配置文件，       
每当一个WEB APP被DEPLOY，该文件都将先被处理，然后才是WEB APP自己的/WEB-INF/web.xml-->

<!-- JspServlet  当请求的是一个JSP页面的时候（*.jsp）该servlet被调用       
它是一个JSP编译器，将请求的JSP页面编译成为servlet再执行       
URL PATTERN MAPPING : *.jsp        -->    
我们可以简单地这么理解tomcat的框架，它是一种自上而下， 容器里又包含子容器的这样一种结构。
容器和组件的关系：  需求被传递到了容器里面， 在合适的时候， 会传递给下一个容器处理。
   而容器里面又盛装着各种各样的组件， 我们可以理解为提供各种各样的增值服务。
   manager: 当一个容器里面装了manager组件后，这个容器就支持session管理了， 事实上在tomcat里面的session管理， 就是靠的在context里面装的manager component.
   logger: 当一个容器里面装了logger组件后， 这个容器里所发生的事情， 就被该组件记录下来啦！ 我们通常会在logs/ 这个目录下看见 catalina_log.time.txt 以及 localhost.time.txt 和localhost_examples_log.time.txt。 这就是因为我们分别为：engin, host以及context(examples)这三个容器安装了logger组件， 这也是默认安装， 又叫做标配 ：）
   loader: loader这个组件通常只会给我们的context容器使用， loader是用来启动context以及管理这个context的classloader用的。作为监听器之一，ContextConfig会被启动. ContextConfig就是用来配置web.xml的。 比如这个Context有多少Servlet， 又有多少Filter， 就是在这里给Context装上去的。
5.9.1 defaultConfig. 每个context都得配置 tomcat/conf/web.xml 这个文件。
5.9.2 applicationConfig 配置自己的 WEB-INF/web.xml 文件