Tomcat详细分析
Tomcat单点登录配置及源码分析
Tomcat单点登录配置及源码分析我们上网的时候，一定遇到过类似这样的情况，例如使用网易邮箱时进行了登录操作，之后再访问网易的博客系统时，发现自动以之前的ID登录了。
这种实现在计算机中称为SSO(Single Sign On),即我们常说的单点登录。
这种在关联网站间共享认证信息，避免需要在多个系统中重复输入帐户信息的行为，是SSO要解决的。
对于许多应用，可能会独立部署等情况，所以常会采用cas的形式，来实现SSO。
我们今天要了解的，是作为在同一个Tomcat中部署的应用之间，如何实现SSO，避免重复登录。
预备：首先，有几点预备知识需要先了解一下。
1.在Tomcat架构设计中，不同的Container中包含了Peipline。
各个Pipeline中可以添加多种不同形式的Valve。
例如我们之前提到的AccessLogValveTomcat的AccessLogValve介绍2.Tomcat中session的实现，最常用的是Cookie Session, 通过将名为JSESSIONID的cookie写回浏览器，实现session。
我们在前面的文章里也描述过。
深入Tomcat源码分析Session3.关于认证的一些内容，可以参考介绍过的Basic认证。
你可能不了解的Basic认证环境：有了这些准备之后，我们开始进行环境的搭建和实验。
以Tomcat自带的几个应用为例，我们启动Tomcat后，访问这两个应用：docs、examples 我们看到，默认是不需要登录的，都可以直接访问。
此时，在docs应用的web.xml中增加如下配置：Security ConstraintProtected Area/*tomcatBASICSSO Testtomcat此时重启Tomcat，再次请求docs应用，发现需要验证了。
同样，再修改examples应用的web.xml，限制对于其直接访问，在文件中增加如下内容： /*。
Tomcat7源码分析
Tomcat源码解析
来看下StandardService的startInternal方法：
Tomcat源码解析
启动Tomcat各级容器会依次先启动 StandardEngine --> StandardHost --> StandardContext（代表一个WebApp应用）, 因为我们比较关心我们的Web应用是在哪里 被初始化回调的，所以重点看下 StandardContext的startInternal()方法。
Tomcat源码解析
StandardWrapper容器默认情况下配置 了StandardWrapperValve阀门，主要是找到 当前请求的需要拦截的过滤器Filter及初始化 当前请求的Servlet对象，最终会封装在 FilterChain对象中，责任链方式执行。
Tomcat源码解析
StandardWrapperValve的invoke()方法的核 心代码如下。
目录
1、背景介绍 2、Tomcat源码目录结构 3、Tomcat体系结构 4、Tomcat源码解析
背景介绍
自从JSP发布之后，推出了各式各样的JSP 引擎。Apache Group在完成GNUJSP1.0的开 发之后，开始考虑在SUN的JSWDK基础上开发 一个可以直接提供Web服务的JSP服务器，当 然同时也支持Servlet，这样Tomcat就诞生了。 Tomcat是jakarta项目中的一个重要的子项目， 其被JavaWorld杂志的编辑选为2001年度最具 创新的java产品，同时它又是sun公司官方推荐 的servlet和jsp容器。
Tomcat源码解析
Http11Protocol 类完全路径 org.apache.coyote.http11.Http11Protocol，这是支 持HTTP的BIO实现。Http11Protocol包含了 JIoEndpoint对象及Http11ConnectionHandler对象。 Http11ConnectionHandler对象维护了一个 Http11Processor对象池，Http11Processor对象会 调用CoyoteAdapter完成HTTP Request的解析和分 派。 JIoEndpoint维护了两个线程，Acceptor请求接 收线程及Executor请求处理线程池。Acceptor是接 收Socket，然后从 Executor请求处理线程池中找出 空闲的线程处理socket，如果 Executor请求处理线 程池没有空闲线程，请求会被放入阻塞队列等待有 空闲线程。
JSP实验报告
中南民族大学管理学院学生实验报告课程名称： JSP程序设计年级： 2010专业：姓名：学号：指导教师：实验地点：管理学院综合实验室学年至学年度第学期第一章 JSP简介实验 Tomcat服务器的安装与配置一、实验目的本实验的目的是让学生掌握怎样设置Web服务目录、怎样访问Web服务目录下的JSP 页面、怎样修改Tomcat服务器的端口号。
二、实验要求1、将下载的apache-tomcat-6.0.13.zip解压到硬盘某个分区，比如D。
2、在硬盘分区D下新建一个目录，名字为student，见stuent设置为Web服务目录，并为该Web服务目录指定名字为good的虚拟目录。
3、修改端口号为5678.在server.xml文件中找到修改端口号的部分，将端口号修改为5678.4、启动Tomcat服务器。
5、用文本编辑器编写一个简单的JSP页面biao.jsp，并保存到Web服务目录student中。
6、用浏览器访问Web服务目录student中的jsp页面biao.jsp。
三、实验内容1、Tomcat安装成功并运行2、编码实现乘法表3.代码四、实验结果biao.jsp页面五、实验结果分析1、默认的端口号为8080，若修改，在conf目录下的server.xml文件中修改端口号。
2、设置虚拟目录。
在conf目录下的server.xml中</Host>前加入：<Context path=”/**” docBase=”路径” debug=”0” reloadable=”true/”>3、Tomcat服务器必须保持启动。
第二章 JSP页面与JSP标记实验1 JSP页面的基本结构一、实验目的本实验的目的是让学生掌握怎样在JSP页面中使用成员变量，怎样使用Java程序片、Java表达式。
二、实验要求本实验将用户输入的单词按字典顺序。
需要编写两个JSP页面，名字分别为inputWord.jsp和showDictionary.jsp。
tomcat中的logging.properties配置具体分析
tomcat中的logging.properties配置具体分析Tomcat默认使用JULI日志系统Tomcat 日志信息分为两类：一是运行中的日志，它主要记录运行的一些信息，尤其是一些异常错误日志信息。
二是访问日志信息，它记录的访问的时间，IP ，访问的资料等相关信息。
一Cataline引擎的日志文件，文件名catalina.日期.logTomcat下内部代码抛出的日志，文件名localhost.日期.log（jsp 页面内部错误的异常，org.apache.jasper.runtime.HttpJspBase.service类抛出的，日志信息就在该文件！）Tomcat下默认manager应用日志，文件名manager.日期.log 控制台输出的日志，Linux下默认重定向到catalina.out二Access日志（Servlet.xml配置）日志的级别分为如下 7 种：SEVERE (highest value) > WARNING > INFO > CONFIG > FINE > FINER > FINEST (lowest value)Tomcat使用的日志配置文件：$CATALINA_BASE/conf/logging.properties以tomcat-6.0.29为例：#配置tomcat的日志输出方式，这里表示文件输出和控制台输出.handlers = /doc/df17730159.html,.apache.juli.FileHandler, java.util.logging.ConsoleHandler/doc/df17730159.html,.apache.juli.FileHand ler.level = FINE #日志级别例：/doc/df17730159.html,.apache.juli.FileHand ler.level = FINE #设置 catalina 日志的级别为： FINE/doc/df17730159.html,.apache.juli.FileHand ler.level = OFF #禁用 catalina 日志的输出/doc/df17730159.html,.apache.juli.FileHand ler.level = ALL#输出 catalina 所有的日志消息均输出/doc/df17730159.html,.apache.juli.FileHand ler.directory = ${catalina.base}/logs #日志输出目录，此设置表示tomcat日志输出到tomcat\logs目录下/doc/df17730159.html,.apache.juli.FileHand ler.prefix = catalina. #日志输出前缀，后面跟日期信息(yyyy-MM-dd) 注：tomcat_6.0.29输出4种不同的日志：catalina、localhost、manager、host-managerjava.util.logging.ConsoleHandler.level = FINE #控制台日志输出级别java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter #控制台日志输出格式化类，Formatter 为格式化 LogRecords 提供支持。
SpringBoot内置Tomcat启动原理源码分析
SpringBoot内置Tomcat启动原理源码分析1、获取SpringBoot内置Tomcat⾃动配置类： 在SpringBoot项⽬中引⼊spring-boot-starter-web依赖，就默认使⽤Tomcat容器，该依赖中引⼊spring-boot-starter-tomcat、spring-webmvc，就引⼊了tomtcat核⼼依赖和springMvc相关jar包，这样就间接地引⼊了tomcat。
在执⾏SpringBoot项⽬启动类的main()⽅法，启动SpringBoot项⽬的过程中会加载各个jar包下META-INF/spring.factories的⽂件，在该⽂件中包含着⾃动配置的⼦路径，在refresh()⽅法中的invokeBeanFactoryPostProcessors()中⾸先会对启动类上的 @SpringBootApplication 注解进⾏解析，最终调⽤ AutoConfigurationImportSelector类中的 getAutoConfigurationEntry() 加载 META-INF/spring.factories ⽂件中的⾃动配置类，得到⾃动配置类的全路径,其中 org.springframework.boot.autoconfigure.web.servlet.ServletWebServerFactoryAutoConfiguration 为tomcat⾃动配置类。
具体加载流程见:protected AutoConfigurationEntry getAutoConfigurationEntry(AnnotationMetadata annotationMetadata) {if (!isEnabled(annotationMetadata)) {return EMPTY_ENTRY;}AnnotationAttributes attributes = getAttributes(annotationMetadata);// 1、得到META-INF/spring.factories⽂件中配置的所有⾃动配置类List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);// 移除重复的配置类configurations = removeDuplicates(configurations);// 获取需要排除的⾃动配置类，eg:注解属性中的exculde的配置类Set<String> exclusions = getExclusions(annotationMetadata, attributes);// 检查需要被排除的配置类，因为有些不是⾃动配置类，需要抛异常checkExcludedClasses(configurations, exclusions);// 移除需要排除的配置类configurations.removeAll(exclusions);// 根据 META-INF/spring-autoconfigure-metadata.properties 中配置的规则过虑掉⼀部分配置类(根据@ConditionalOnXXX注解进⾏过滤)configurations = getConfigurationClassFilter().filter(configurations);// 获取符合条件的配置类后，触发 AutoConfigurationImportEvent 事件fireAutoConfigurationImportEvents(configurations, exclusions);// 将符合条件和需要排除的配置类封装进 AutoConfigurationEntry 对象中返回return new AutoConfigurationEntry(configurations, exclusions);}2、ServletWebServerFactoryAutoConfiguration - tomcat⾃动配置类分析3、创建tomcat⼯⼚@Configuration(proxyBeanMethods = false)@ConditionalOnClass({ Servlet.class, Tomcat.class, UpgradeProtocol.class })@ConditionalOnMissingBean(value = ServletWebServerFactory.class, search = SearchStrategy.CURRENT)static class EmbeddedTomcat {@BeanTomcatServletWebServerFactory tomcatServletWebServerFactory(ObjectProvider<TomcatConnectorCustomizer> connectorCustomizers,ObjectProvider<TomcatContextCustomizer> contextCustomizers,ObjectProvider<TomcatProtocolHandlerCustomizer<?>> protocolHandlerCustomizers) {// 创建⽣产tomcat的⼯⼚TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();factory.getTomcatConnectorCustomizers().addAll(connectorCustomizers.orderedStream().collect(Collectors.toList()));factory.getTomcatContextCustomizers().addAll(contextCustomizers.orderedStream().collect(Collectors.toList()));factory.getTomcatProtocolHandlerCustomizers().addAll(protocolHandlerCustomizers.orderedStream().collect(Collectors.toList()));return factory;}} 4、创建tomcat容器 在SpringBoot启动过程中会调⽤ AbstractApplicationContext.refresh() ⽅法，在该⽅法会调⽤onRefresh()⽅法，这个⽅法是个模板⽅法，最终会交给⼦类实现，在使⽤内置tomcat的SpringBoot项⽬中，最终会调⽤ ServletWebServerApplicationContext 实现(AbstractApplicationContext是GenericWebApplicationContext，ServletWebServerApplicationContext 是GenericWebApplicationContext)，最终调⽤ServletWebServerApplicationContext 的createWebServer()⽅法创建 webServer。
深入分析Tomcat无响应问题及解决方法
深⼊分析Tomcat⽆响应问题及解决⽅法 问题描述 ⽣产环境下有⼏台tomcat,但突然某个时候发现所有的请求都不能响应了,由于我们的web server使⽤的是nginx,会将请求反向到tomcat上,所以起初怀疑是nginx就没有收到请求,但查看⽇志后发现,nginx中⼤量出现499的返回,这说明问题还是出在tomcat上. 问题排查 ⾸先我想到的是不是CPU跑满了,虽说CPU没有报警但还是本能的top命令看下系统负载,发现系统只有0.x的负载,cpu,内存消耗都是正常的. 由于CPU没有出现异常,所以应该不是GC出现了问题,但还是检查了下GC log,果然GC也没问题 此时必须让jstack上场了,果然在使⽤jstack后发现很多线程都是WAITING状态"http-nio-127.0.0.1-801-exec-498" daemon prio=10 tid=0x00002ada7c14f800 nid=0x16a6 waiting on condition [0x00002ada9c905000] ng.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00000007873e6990> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043) at org.apache.http.pool.PoolEntryFuture.await(PoolEntryFuture.java:133) at org.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:282) at org.apache.http.pool.AbstractConnPool.access$000(AbstractConnPool.java:64) at org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:177) at org.apache.http.pool.AbstractConnPool$2.getPoolEntry(AbstractConnPool.java:170) at org.apache.http.pool.PoolEntryFuture.get(PoolEntryFuture.java:102) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:240) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:227) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:173) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:195) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:85) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:108) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:186) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:82) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:106) at com.weimai.utils.HttpClientUtil.doGet(HttpClientUtil.java:105) at com.weimai.utils.HttpClientUtil.doGet(HttpClientUtil.java:87) at com.weimai.utils.WeiBoUtil.checkUser(WeiBoUtil.java:214) at erInfoController.newWeiboLogin(UserInfoController.java:1223) at sun.reflect.GeneratedMethodAccessor390.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at ng.reflect.Method.invoke(Method.java:606) 此时意识到问题应该出现http连接上,马上⽤netstat查看下801端⼝的连接状态,果然发现很多请求都是CLOSE_WAIT,这⾥简单解释下CLOSE_WAIT状态,如果我们的client程序处于CLOSE_WAIT状态的话,说明套接字是被动关闭的,整个流程应该是这样 因为如果是server端主动断掉当前连接的话,那么双⽅关闭这个TCP连接共需要四个packet server -> FIN -> client server <- ACK <- client 这时候server端处于FIN_WAIT_2状态,⽽我们的程序处于CLOSE_WAIT状态 server <- FIN <- client 这时client发送FIN给server,client就置为LAST_ACK状态。
tomcat架构及源码解析
很多开源应用服务器都是集成tomcat作为web container的，而且对于tomcat 的servlet container这部分代码很少改动。
这样，这些应用服务器的性能基本上就取决于Tomcat处理HTTP请求的connector模块的性能。
本文首先从应用层次分析了tomcat所有的connector种类及用法，接着从架构上分析了connector 模块在整个tomcat中所处的位置，最后对connector做了详细的源代码分析。
并且我们以Http11NioProtocol为例详细说明了tomcat是如何通过实现ProtocolHandler接口而构建connector的。
通过本文的学习，应该可以轻松做到将tomcat做为web container集成到第三方系统，并且自定义任何你想要的高性能的HTTP连接器1 Connector介绍1.1 Connector的种类Tomcat源码中与connector相关的类位于org.apache.coyote包中，Connector 分为以下几类：∙Http Connector, 基于HTTP协议，负责建立HTTP连接。
它又分为BIO Http Connector与NIO Http Connector两种，后者提供非阻塞IO与长连接Comet支持。
∙AJP Connector, 基于AJP协议，AJP是专门设计用来为tomcat与http 服务器之间通信专门定制的协议，能提供较高的通信速度和效率。
如与Apache服务器集成时，采用这个协议。
∙APR HTTP Connector, 用C实现，通过JNI调用的。
主要提升对静态资源（如HTML、图片、CSS、JS等）的访问性能。
现在这个库已独立出来可用在任何项目中。
Tomcat在配置APR之后性能非常强劲。
1.2 Connector的配置对Connector的配置位于conf/server.xml文件中。
性能分析——精选推荐
性能分析性能结果分析是性能测试中的⼀个重要部分，同时也是⼀个难点。
由于不同的软件系统，不同的性能指标，结果分析⽅法都是不⼀样的。
需要具体问题具体分析。
下⾯将阐述⼀些性能分析的⽅法与建议。
1 性能分析的⽬的1）找出系统瓶颈（硬件、软件）2）提出性能优化⽅案3）达到合理的硬件和软件配置4）使系统资源使⽤达到最⼤平衡2 常见性能瓶颈征兆在性能测试执⾏过程中，我们需要观察和了解系统的运⾏状态，如果出现以下征兆，则表⽰系统可能存在瓶颈。
1) 持续缓慢：应⽤程序⼀直特别慢，改变负载，对整体响应时间影响很少；2) 随着时间推进越来越慢：负载不变，随着时间推进越来越慢，可能到达某个阈值，系统被锁定或出现⼤量错误⽽崩溃；3) 随着负载增加越来越慢：每增加若⼲⽤户，系统明显变慢，⽤户离开系统，系统恢复原状；4) 零星挂起或异常错误：可能是负载或某些原因，⽤户看到页⾯⽆法完成并挂起，⽆法消除；5) 可预见的锁定：⼀旦出现挂起或错误，就加速出现，直到系统完全锁定。
通常要重启系统才解决。
6) 突然混乱：系统⼀直运⾏正常，可能是⼀个⼩时或三天之后，系统突然出项⼤量错误或锁定。
3 性能数据解读建议性能分析过程也是⼀个解读数据的过程，读懂了数据你就能知道问题出在何处。
随着经验的累积将会很容易判断问题的根源，甚⾄在开发阶段就能对可能出现问题的点打预防针。
性能指标类型标准性能瓶颈征兆分析⼯具TPS及其波动范围1.Tps符合性能⽬标2.Tps轨迹波动平稳1.TPS有明显的⼤幅波动，不稳定。
例如TPS轨迹缓慢下降，缓慢上升后骤降，呈瀑布型，呈矩形，分时间段有规律的波动，⽆规律的波动等。
这些TPS的波动轨迹反映出被测试的性能点存在性能瓶颈，需要性能测试⼯程师与开发⼯程师查找性能瓶颈的原因。
2. TPS轨迹⽐较平稳，但是也存在波动现象。
该类波动不明显，很难直接确定是否存在性能瓶颈。
我们需要根据其他指标来进⾏判断。
Jmeter/loadrunner响应时间90%平均事务响应时间<性能⽬标1.关注⾼峰负载时，⽤户操作响应时间；2.关注数据库增量，对⽤户操作响应时间的影响。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
Tomcat分享
一、Tomcat简介
Tomcat是一个开源的轻量级应用服务器，主要用作Serlvet容器。
它是Apache Jakarta项目中的一个核心项目，在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。
二、Tomcat体系结构
a)Tomcat的六大组件
i.Server：整个Catalina Servlet容器，它是一个单例，可以包含一个或
多个Service。
ii.Service：存活在Server内部的中间组件，可以由一个或多个Connector 组成，但是只能有一个Engine引擎，通过它可以将这些Connector
组件绑定到唯一的Engine引擎上。
iii.Connector：每一个Connector在指定的端口上侦听客户的请求，并将获得的请求交给Engine处理，从Engine处获得回应并返回给客户端。
iv.Engine：它是某个Service中的请求处理机，负责接收和处理来自Connector的请求并将响应结果返回给适合的Connector。
Engine下
可以配置多个虚拟机，每个虚拟机都有一个域名，当Engine获得一
个请求时，它将根据请求信息中的信息把该请求匹配到某个Host上，
然后在该Host配置的环境下处理该请求。
v.Host：一个Host代表一个Virtual Host(虚拟主机)，每个虚拟主机都有对应的域名。
每个虚拟机下都可一部署一个或多个web
application，每个web application对应一个Context，并拥有一个
Context path。
当Host 获得一个针对某个特定的Host的请求时,将
在该Host 的环境下把请求匹配到某个Context 上,然后把请求交给
该Context 来处理。
vi.Context：一个Context对应一个web application，运行在特定的Host 中。
b)Tomcat组件关系图
c)Tomcat工作流程
i.当HTTP请求被发送到本机的tomcat指定端口时，由监听改端口的
Connector获得请求。
ii.Connector把该请求交给它所在的Service中的Engine来处理，Connector等待Engine的响应结果。
iii.Engine获得Connector发送过来的请求后，分析请求信息匹配它所拥有的所有虚拟主机Host。
iv.Engine匹配指定的Host(如果没有找到匹配的Host，这把匹配默认的Host)。
v.Host获得请求后，匹配它所拥有的所有Context(最长匹配)，如果匹配不到就把请求交给路径为“”的Context去处理。
vi.Context经过一系列的处理，把处理后的响应信息返回给Host。
vii.Host把响应信息返给Engine。
viii.Engine把响应信息返回给Connector。
ix.Connector把响应信息返回给客户端。
d)Tomcat主要的组件类和接口
.apache.catalina.Lifecycle：通用的组件声明周期接口，一般Toamcat
的组件都要实现这个接口(但不是必须的)，这个接口是所有组件提供
相同的start和stop方法。
.apache.catalina.LifecycleListener：该接口用于监听一些重要事件(包括实现了Lifecycle接口组件产生的start和stop事件)。
.apache.catalina.Container：容器接口用于从客户端获得请求并且
处理请求并回复给客户端的对象。
容器可以支持(可选)pipeline，以
便能在运行时按配置的顺序处理请求。
.apache.catalina. ContainerListener：容器事件监听(注：start，stop 是正常的生命周期事件(LiftcycleEevent)不是容器事件)。
.apache.catalina.Pipeline：Pipleline是Value的集合，当invoke方
法被调用时，它会按指定的顺序调用Value，它总是要求有一个Value
必须处理传递的request并产生response，否则就把request传递到下
一个Value。
一般一个容器仅绑定一个Pipleline实例,容器会把处理
request 的功能封装到一个容器绑定的Valve 里(这个Valve 应该在Pipleline 最后被执行)。
为了完成这个功能,Pipleline 提供了setBasic()方法以保证Valve 被最后执行,而其他Valve 按顺序被调用。
.apache.catalina.Value：Value是被绑定在一个Container上的请求
处理组件，一组Value被按顺序绑定在一个Pipleline上。
.apache.catalina.Server：Server是整个Catalina容器的入口点，可
以包含多个Service和顶层资源元素一般来说实现Server接口的类也应该同时实现Lifecycle接口，当start()和stop()方法被调用的时候调用Service 相应的方法。
.apache.catalina. Service：Service 是一个或多个共享同以
Container 的Connectiors 的集合。
JVM 可以包含一个或多个
Service 实例,但它们相互之间是完全独立的,它们仅共享JVM 的资源。
.apache.catalina.Engine：Engine 是一个容器,是Cataline 的
Servlet 的入口点。
当发布一个连接到Web Server 的Cataline 时可能不使用Engine,因为Connectior 将使用Web Server 的资源决定使用哪个Context 处理Request。
附属于Engine 的子容器根据
Engine 实现的不同可能是Host 或Context(单个Servlet Context)。
如果使用了Engine,在Cataline 的层次中它就是顶层容器,因此
setParent()应改抛出IllegalArgumentException 异常。
.apache.catalina. Host：Host 是一个容器,它代表一个虚拟主机。
当
发布一个连接到Web Server 的Cataline 时可能不使用Host，因为Connectior 将使用Web Server 的资源决定使用哪个Context 处理Request。
Host 所附属的父容器通常，是Engine,附属于Host 的子容器通常是Context(单个Servlet Context)。
Host 接口里面的方法多数都是关于修改Host 属性及设定默认的Context。
.apache.catalin. Context：Context 是一个容器,它代表一个ServletContext,一个Cataline Engline 中的单个的Web Application。
Context 所附属的父容器是Host,附属于Context 的子容器是
Wrapper(代表单个Servlet)。
Context 接口里面多数是关于Web
Application 的设置的方法,我们可以参考Web.xml 文件研究里面的方法,里面多数方法都是如何读取Web.xml 文件里的资源。
.apache.catalina.Wrapper：Wrapper 是一个容器,它代表单个Servlet。
Wrapper 管理Servlet 的生命周期,包括调用init()和destory()方法。
Wrapper 所附属的父容器是Context,没有附属于Wrapper 的
子容器,方法addChild()应该抛出IllegalArgumentException 异常Wrapper 接口里面的方法都是关于读取Servlet 的属性,可以参考Web.xml 文件里面关于<servlet>标签的定义。