Tomcat详细分析

合集下载

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源码分析

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实验报告

中南民族大学管理学院学生实验报告课程名称: 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中的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启动原理源码分析

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⽆响应问题及解决⽅法 问题描述 ⽣产环境下有⼏台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架构及源码解析

很多开源应用服务器都是集成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.关注数据库增量,对⽤户操作响应时间的影响。

Tomcat结构分析

Tomcat结构分析

关键 词
T o mc a t 是 当今 最广 泛使 用 的 s e r v l e t 和J S P容 器 ,在 T o mc a t 内部 ,J S P通 过 J a s p e r J S P编译器被 翻 译成 s e r v l e t ,因此本 文 以 T o mc a t 4 . 1 . 1 2为基 础 ,分析 T o mc a t 的s e r v l e t 容 器 ,它被称 之为 C a t a l i n a ,同
其中 l s a t N a m e = F r a n k s &f i r s t Na me = Mi c h a e l是 P OS T 方法 的请 求 体 。HR p p r o c e s s o r的 p a r s e R e q u e s t 、
收稿 日期:2 0 1 3 . 0 8 . 0 7
P OS T/ e x a mp l e s / d e f a u l t j . s p HT T P / 1 . 1
Ac c e p t : t e x t / p l a i n ; t e x t / h t ml
Acc e ptΒιβλιοθήκη ・ ・ La n gua ge: e n ・ - gb
2 0 1 3年 l 2月
第 4期






p a r s e H e a d e r s 和p a r s e C o n n e c t i o n方法分别语法分析请求、语法分析请求头部和语法分析连接而填充请求
对 象 和 响应对 象 的各 个域 。
p a r s e R e q u e s t 分析 H T T P 请求 的第一行 , 从上例 , . p a r s e R e q u e s t 分析出请 求方法 ( P O S T) 、 协议( H T T P / 1 . 1 ) 、

Tomcat与Apache集成的研究

Tomcat与Apache集成的研究

nt a — n es t ab指令查看 8 t 0端 口号是 否已经被 占用 ,并将有关进 程关闭。若 安装成功 ,输入 ht:l a ot 以看到 A ah t /ol s可 p/c h p ce的
测试 页 面 。
()在 A ah 4 pc e服务器 的 m d l oue s目录下 放人 J K插 件文
电脑 编 程 技 巧 与 维 护

T m a 与 A ah 集成 的研 究 o Ct p ce
孙 仁鹏
( 南京信息职业技术学院计 算机 与软件学院 ,南京 204) 10 6

要 : 为 了提 升 网站 的访 问速 度和 提 高稳 定 性 ,提 出 了将 T m a 与 A ah o ct p ce集成 和 集群 的 解 决 方 案 。详 细 分析 了
软件开发与设计
到不 同性 能的服务器上 ,减 轻了单个 服务器 的压力 。
() 高 可 靠 性 :当 一 台 服 务 器 发 生 故 障 ,集 群 系统 会 自 5 动 把 作 任 务 转 交 给 别 的 服 务 器 ,对 用 户 提 供 透 明不 间 断 的 【
服务。
分发控制器等通信的参数 ,存放 在 cn of目录下 ,内容如下 : w re. tw rel舟指定连接 的 T m a 名单 ,多个 用逗 okri= okr 1 s o ct
d ti . eal s
Ke r s o a ; a h y wo d :T mc t Ap c e; ne r t n;C u tr I tg a i o ls e
既然 T m a 本 身 已经提供 了 H F o ct T P服务 ,为什 么还要 引 人与 A ah pc e或者其 他的一些专 门的 HI’ , P服务器集成 呢?原 ’ I

性能典型问题分析总结

性能典型问题分析总结

性能测试典型问题总结版本编制:胜利软件测试组审核:批准:■Victory Soft软律胜利油田胜利软件有限责任公司She ngLi Oil Field Victorysoft Co., Ltd.2013年12月目录1 应用程序经常崩溃.................................................... 3..2 内存溢出............................................................ 6...3 应用程序运行比较慢.................................................. 7..4 无法支持大量用户并发.............................................. 1..05 如何计算系统的最大并发数.......................................... 1..2编写目的:本文记录在性能测试过程中遇到的典型问题及解决方法,仅供参考,同时希望大家能积极总结项目中的问题及解决方法,丰富典型问题库,实现公司内的知识共享。

1 应用程序经常崩溃1.1. 服务器重启动后,无法访问应用程序问题描述:客户的机器设置了晚上自动更新补丁功能,更新后,机器重启;第二天客户上班不能访问我们的应用程序。

解决措施:定位:我们项目组员发现服务器上的咱们的应用程序的服务没有开启,同时查看系统升级配置,怀疑是否升级引起。

解决方案:把应用程序的服务,注册在操作系统的服务里面,设置成自动启动,这样服务器机器重启也不会影响应用程序的正常访问。

【如何将应用程序注册为系统服务】一、应用程序具有服务功能(能响应服务控制台的查询请求)第一种方法:使用instsrv.exe (windows 2003 资源工具包带有),指令格式:instsrv 服务显示名应用程序路径第二种方法:在注册表中手工添加,在下新建一个项,项名为欲显示的服务名(也可以为任意字符,仅供识别),在这个项下新建如下键值:"DisplayName"=(字符串值)服务显示名"Description"=(字符串值)服务描述"ImagePath"=(可扩充字符串值)应用程序路径"ObjectName"=(字符串值)"LocalSystem""Type"=(dword 值)10(16 进制)"Start"=(dword 值)2(16 进制)"ErrorControl"=(dword 值)1(16 进制)二、应用程序不具有服务功能(不能响应服务控制台的查询请求)大多数应用程序都不具有服务功能,这样按照上述方法加进去的应用程序在服务刚启动时能够启动,但一当服务控制台无法接收到应用程序的反馈信息,便会终止程序,因此要使用srvany.exe (同样,在win2003 资源工具包中)1、instsrv.exe 服务显示名srvany.exe2、在下,找到刚添加的服务名,在其下新建项Parameters ,再在其下新建字符串值,名Application ,值为应用程序路径。

tomcat 日志生成规则

tomcat 日志生成规则

tomcat 日志生成规则Tomcat日志生成规则Tomcat是一种常用的Java Web应用服务器,它可以提供对Java Servlet、JavaServer Pages(JSP)和Java WebSocket等技术的支持。

在使用Tomcat时,我们可以通过查看Tomcat日志来了解应用程序的运行情况以及错误信息,以便及时排查和解决问题。

一、日志生成规则概述Tomcat的日志生成规则是由其内部的日志模块控制的。

在Tomcat 的配置文件中,我们可以设置日志的级别、输出格式、存储位置等参数。

根据这些配置,Tomcat会在特定的时间点或事件触发时生成相应的日志记录。

二、日志级别Tomcat的日志级别包括以下几种:DEBUG、INFO、WARN、ERROR和FATAL。

不同级别的日志记录对应着不同的重要程度和详细程度。

在生产环境中,一般会将日志级别设置为INFO或WARN,这样可以确保重要的信息和异常都能被记录下来,而避免生成过多的无关日志。

三、日志输出格式Tomcat的日志输出格式可以通过修改配置文件来自定义。

常见的日志输出格式包括以下几种元素:1. 时间戳:记录日志的时间。

2. 日志级别:记录日志的级别。

3. 线程ID:记录生成该日志的线程的ID。

4. 类名和方法名:记录生成该日志的代码所在的类和方法。

5. 日志内容:记录具体的日志信息。

四、日志存储位置Tomcat的日志存储位置可以通过配置文件进行设置。

一般情况下,Tomcat会将日志文件存储在指定的目录下,并按照日期或大小进行切割。

这样可以方便地管理和查看日志文件,同时也可以避免单个日志文件过大而影响系统性能。

五、日志记录的事件Tomcat会在以下几种事件触发时生成相应的日志记录:1. 服务器启动和关闭:记录服务器的启动和关闭信息。

2. 应用程序部署和卸载:记录应用程序的部署和卸载信息。

3. 请求和响应:记录请求的URL、请求方法、响应状态码等信息。

tomcat 的安全审计日志

tomcat 的安全审计日志

tomcat 的安全审计日志
Tomcat的安全审计日志在Web应用的安全管理中占据着重要的地位。

通过对安全审计日志的监控和分析,管理员可以实时了解系统的安全状况,及时发现并处理潜在的安全威胁。

Tomcat的安全审计日志主要包括访问日志、操作日志和安全事件日志等。

访问日志记录了用户对Web应用的访问情况,包括访问时间、访问IP、访问页面等信息,通过分析访问日志可以发现异常的访问行为,如频繁的访问、非法的访问等。

操作日志则记录了用户对Web应用的操作情况,如登录、注销、修改配置等操作,通过操作日志可以追溯用户的操作轨迹,便于问题的排查和追责。

安全事件日志则记录了系统中发生的安全事件,如用户认证失败、访问被拒绝等事件,这些事件是评估系统安全性的重要依据。

在实际应用中,为了更好地满足安全审计的需求,可以对Tomcat的安全审计日志进行定制化配置。

例如,可以通过配置AccessLogValve来开启访问日志,并设置日志的输出格式和输出位置。

同时,可以通过开发自定义的日志记录模块来记录操作日志和安全事件日志,以满足特定的安全审计需求。

除了配置日志记录外,还需要对日志进行定期的分析和审计。

通过分析日志可以发现系统的安全漏洞和异常行为,及时采取相应的措施进行修复和防范。

同时,还需要制定相应的安全策略和流程,确保日志的安全性和可靠性,避免日志被篡改或泄露。

总之,Tomcat的安全审计日志是保障Web应用安全的重要手段之一,通过对日志的监控和分析,可以及时发现并处理潜在的安全威胁,确保系统的稳定性和安全性。

程序运行现状分析报告

程序运行现状分析报告

程序运行现状分析报告1. 引言本报告旨在对程序的运行现状进行全面分析,以便了解程序在当前环境下的性能表现和存在的问题。

通过分析现状,我们可以对程序的优化方向和改进方案进行合理规划。

2. 程序概述本程序是一个基于Java开发的企业资源管理系统,用于管理企业的各类资源、业务和人员。

程序使用了Spring框架作为开发基础,并集成了数据库等多种技术实现各项功能。

3. 程序运行环境程序目前运行在一台配置较高的服务器上,服务器配备了8核处理器、16GB内存和500GB硬盘,并安装了Ubuntu Server操作系统和MySQL 数据库。

程序使用Tomcat作为应用服务器,并通过Nginx进行反向代理和负载均衡。

4. 程序的性能评估4.1 响应时间通过对程序进行压力测试,得到了一组响应时间数据,并绘制成如下的折线图:![折线图](response_time.png)从图中可以看出,程序的响应时间整体较稳定,但在高峰期间会有轻微的升高。

响应时间主要受到网络延迟、数据库查询和业务逻辑处理等因素的影响。

4.2 并发处理能力通过模拟多个用户同时访问程序,并观察服务器的系统负载情况,得到了如下的负载曲线图:![负载曲线图](load.png)从图中可以看出,程序在并发请求较高时,服务器的负载会呈现线性增长的趋势。

当服务器负载达到一定程度时,会出现性能下降、响应时间延长的情况。

4.3 内存占用情况通过监测程序运行过程中的内存使用情况,得到了如下的内存占用曲线图:![内存占用曲线图](memory.png)从图中可以看出,程序的内存占用较为稳定,在正常范围内波动。

在程序执行大量数据库查询时,内存占用会略微增加,但仍然在可接受范围内。

5. 程序存在的问题与改进方案根据以上的性能评估结果,我们总结了程序存在的主要问题,并提出相应的改进方案:5.1 响应时间略高虽然程序的响应时间整体较为稳定,但仍然存在高峰期间响应时间略高的情况。

解析Tomcat的启动脚本--startup.bat

解析Tomcat的启动脚本--startup.bat

解析Tomcat的启动脚本--startup.bat 概述我们通常使⽤ Tomcat 中的 startup.bat 来启动 Tomcat. 但是这其中⼲了⼀些什么事呢?⼤家都知道⼀个 Java 程序需要启动的话, 肯定需要 main ⽅法, 那么这个 main ⽅法在哪呢?Tomcat 脚本中⼜是配置了⼀些什么参数呢, 什么情况下 Tomcat 会启动失败呢?带着⼀些列的疑问我们来分析 Tomcat 的三个最重要的启动脚本:startup.batcatalina.batsetclasspath.batstartup.bat 脚本该脚本主要做了以下⼏件事:设置 CATALINA_HOME 环境变量的值找到 catalina.bat 脚本调⽤ catalina.bat 脚本, 并把参数传过去贴出简化版本的 startup.bat 脚本的内容@echo offrem 执⾏这个命令之后, 增加或者改动的环境变量只限于匹配到 endlocal 命令或者到达⽂件末尾.setlocalrem 假设 CATALINA_HOME 环境变量没有定义rem 取当前⽬录的路径值, 赋给 CURRENT_DIR 变量, 就是 ./apache-tomcat-x.x.xx/binset "CURRENT_DIR=%cd%"rem 如果 CATALINA_HOME 变量值不是 "" 的话, 调到 gotHome 标签处if not "%CATALINA_HOME%" == "" goto gotHomerem 如果 CATALINA_HOME 是 "" 的话, 设置 CATALINA_HOME 变量值为当前⽬录的路径值(./apache-tomcat-x.x.xx/bin) set "CATALINA_HOME=%CURRENT_DIR%"rem 判断当前路径下的是否有 bin\catalina.bat, 也就是 ./apache-tomcat-x.x.xx/bin/bin/catalina.batrem 如果存在的话, 直接调到 okHome 标签处, 显然是不存在的if exist "%CATALINA_HOME%\bin\catalina.bat" goto okHomerem 不存在的话, CATALINA_HOME 取上级⽬录的值, 也就是(./apache-tomcat-x.x.xx/)cd ..set "CATALINA_HOME=%cd%"rem 进⼊ CURRENT_DIR(./apache-tomcat-x.x.xx/bin)cd "%CURRENT_DIR%":gotHomerem 通过上⾯的设置, CATALINA_HOME 的值已经是: ./apache-tomcat-x.x.xx/rem 所以整理是可以找到 catalina.bat 脚本的, 直接调到 okHome 标签处if exist "%CATALINA_HOME%\bin\catalina.bat" goto okHomeecho The CATALINA_HOME environment variable is not defined correctlyecho This environment variable is needed to run this programgoto end:okHomerem 设置 EXECUTABLE 变量指向为 catalina.bat 脚本set "EXECUTABLE=%CATALINA_HOME%\bin\catalina.bat"rem 检查⽬标可执⾏⽂件(catalina.bat)是否存在, 通常情况下是存在的, 直接调到 okExec 标签处rem 如果不存在的话, 直接退出. 启动 Tomcat 结束if exist "%EXECUTABLE%" goto okExececho Cannot find "%EXECUTABLE%"echo This file is needed to run this programgoto end:okExecrem 获取剩余的没有⽤ shift 取出来的命令⾏参数, 并保存它们在 CMD_LINE_ARGSset CMD_LINE_ARGS=:setArgsrem 如果第⼀个命令⾏参数是空的话, 跳到 doneSetArgs 标签处rem "%1" : 表⽰执⾏命令之后的第⼀个参数if ""%1""=="""" goto doneSetArgsrem 第⼀个参数不是空的话, 拼接到 CMD_LINE_ARGS 变量set CMD_LINE_ARGS=%CMD_LINE_ARGS% %1rem 这个命令可以⾃⾏百度shiftgoto setArgs:doneSetArgsrem 上⾯设置了 EXECUTABLE 变量的值是指向了 catalina.bat 脚本, 这个利⽤ call 命令执⾏调⽤, 并把参数传进去rem 接下来, 咱们看 catalina.bat 脚本的内容rem 完整的命令: ./apache-tomcat-x.x.xx/bin/catalina.bat startcall "%EXECUTABLE%" start %CMD_LINE_ARGS%:end要想理解脚本中的⼀些命令, ⾸先来了解⼀下常⽤的命令(我们⽤的 Window 版的)rem : 该命令后的代码不会被执⾏, 相当于注释@echo off : 关闭命令的显⽰, 如果没有设置, 执⾏了哪些命令都会显⽰出来echo : 输出后⾯的内容setlocal : 执⾏这个命令之后, 增加或者改动的环境变量的作⽤范围只限于匹配到 endlocal 命令或者到达⽂件末尾.set : 设置⼀个变量:xxx : 定义⼀个标签goto : 跳转到制定的标签处call : 执⾏命令我们来⼀⾏⾏分析 startup.bat 脚本set "CURRENT_DIR=%cd%"%cd% : 表⽰⽂件所在的⽬录的路径如果我们解压的 Tomcat 所在的⽬录为 D:/apache-tomcat-x.x.x/ . 因为 startup.bat 命令在 bin ⽬录下, 所以此时 %cd% 表⽰的⽬录是 D:/apache-tomcat-x.x.x/binif not "%CATALINA_HOME%" == "" goto gotHome我们通常情况下不会配置 CATALINA_HOME 这个环境变量的, 所以这⾥不会调到 gotHome 标签处.set "CATALINA_HOME=%CURRENT_DIR%"直接把当前⽬录假设为 CATALINA_HOME 的值if exist "%CATALINA_HOME%\bin\catalina.bat" goto okHome然后通过固定的格式来判断⼀下是否有 catalina.bat 脚本, 当然这⾥是肯定不会存在的, 因为 CATALINA_HOME = D:/apache-tomcat-x.x.x/bincd ..set "CATALINA_HOME=%cd%"因为 Tomcat 的⽬录格式是固定的, 所以这⾥直接进⼊上级⽬录(cd ..), 然后设置 CATALINA_HOME 的值为上级⽬录(D:/apache-tomcat-x.x.x ).if exist "%CATALINA_HOME%\bin\catalina.bat" goto okHomeecho The CATALINA_HOME environment variable is not defined correctlyecho This environment variable is needed to run this programgoto end继续往下看, 这⾥⼜⼀次判断了⼀下 catalina.bat 在这样的⽬录结构是是否能找到, 如果我们解压完 Tomcat 后, 把 startup.bat放在⾮ Tomcat 的 bin ⽬录下之后, 这⾥是找不到的, 就直接 goto end, 退出 Tomcat 的启动.好了, 这⾥我们直接调到 okHome 标签处.:okHomeset "EXECUTABLE=%CATALINA_HOME%\bin\catalina.bat"好了, 这⾥很简单, 设置⼀个 EXECUTABLE 变量的值指向 catalina.bat 脚本.if exist "%EXECUTABLE%" goto okExececho Cannot find "%EXECUTABLE%"echo This file is needed to run this programgoto end⼜⼀次的检查了⼀下这个脚本是否存在, 存在的话, 直接调到 okExec 标签处, 可以执⾏了.如果没有通过检查的话, 依旧退出启动, 并打印错误信息.:okExecset CMD_LINE_ARGS=:setArgsif ""%1""=="""" goto doneSetArgsset CMD_LINE_ARGS=%CMD_LINE_ARGS% %1shiftgoto setArgs先设置了⼀个 CMD_LINE_ARGS 变量, 并且其值暂且为空这⾥出现了⼀个 ""%1""=="""", 拆开看就是判断 "%1" 是否等于 "". 那么 "%1" ⼜是什么呢?这是 window 批处理的⼀个语法, 表⽰的是执⾏命令之后的第⼀个参数, 对于这⾥, 我们并没有传递什么参数, 所以这⾥的 "%1"是 ""(空).直接跳转到 doneSetArgs 标签处.如果不是空的话, 就拼在后⾯呗.这⾥这个 shift 命令意思就是移除⼀个参数, 举个例⼦就知道了:@echo offecho "%1"shiftecho "%1"建⼀个 test.bat 批处理程序, 然后把上⾯代码复制进去, 在 cmd 中执⾏并给它两个参数下⾯是执⾏结果, 这⾥⼤家可以把 @echo off 去掉再执⾏, 验证⼀下这个命令的作⽤PS D:\> .\test Hello World"Hello""World"PS D:\>这样, ⼤家应该可以理解了.继续分析:doneSetArgscall "%EXECUTABLE%" start %CMD_LINE_ARGS%:end在上⾯设置了 EXECUTABLE = %CATALINA_HOME%\bin\catalina.bat , 所以这⾥实际上是调⽤了 catalina.bat 这个脚本, 然后传递⼀个 start 参数给它.如果我们在 cmd 中运⾏ startup.bat 并且后⾯跟着⼀些参数的话, 这⾥也⼀起传递过去了.这⾥实际上就是执⾏了: %CATALINA_HOME%\bin\catalina.bat start总结这个脚本还是挺简单的, ⽬的就是找到 catalina.bat 并调⽤它.以上就是本⽂的全部内容,希望本⽂的内容对⼤家的学习或者⼯作能带来⼀定的帮助,下篇继续介绍Tomcat相关知识--《》,有兴趣的朋友可以看下。

tomcat加载jar异常问题的分析与解决

tomcat加载jar异常问题的分析与解决

tomcat加载jar异常问题的分析与解决现象描述:项⽬使⽤springboot启动⼀个web项⽬,在启动阶段看到console中出现了异常“1.10.3-1.4.3\hdf5.jar 系统找不到指定的⽂件”,虽然这些异常不影响项⽬的正常运⾏,但作为⼀个严谨的技术⼈员,看到这些异常就像见到仇⼈⼀样,⼀定要除之⽽后快。

java.io.FileNotFoundException: D:\.m2\repository\org\bytedeco\javacpp-presets\hdf5-platform\1.10.3-1.4.3\hdf5.jar (系统找不到指定的⽂件。

)at java.util.zip.ZipFile.open(Native Method)at java.util.zip.ZipFile.<init>(ZipFile.java:225)at java.util.zip.ZipFile.<init>(ZipFile.java:155)at java.util.jar.JarFile.<init>(JarFile.java:166)at java.util.jar.JarFile.<init>(JarFile.java:130)at pat.JreCompat.jarFileNewInstance(JreCompat.java:188)at org.apache.tomcat.util.scan.JarFileUrlJar.<init>(JarFileUrlJar.java:65)at org.apache.tomcat.util.scan.JarFactory.newInstance(JarFactory.java:49)at org.apache.tomcat.util.scan.StandardJarScanner.process(StandardJarScanner.java:374)at org.apache.tomcat.util.scan.StandardJarScanner.processURLs(StandardJarScanner.java:309)at org.apache.tomcat.util.scan.StandardJarScanner.doScanClassPath(StandardJarScanner.java:266)at org.apache.tomcat.util.scan.StandardJarScanner.scan(StandardJarScanner.java:229)at org.apache.jasper.servlet.TldScanner.scanJars(TldScanner.java:262)at org.apache.jasper.servlet.TldScanner.scan(TldScanner.java:104)at org.apache.jasper.servlet.JasperInitializer.onStartup(JasperInitializer.java:101)at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5204)at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1421)at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1411)at java.util.concurrent.FutureTask.run$$$capture(FutureTask.java:266)at java.util.concurrent.FutureTask.run(FutureTask.java)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)at ng.Thread.run(Thread.java:748)2019-03-29 18:09:08.303 WARN 16940 --- [ost-startStop-1] o.a.tomcat.util.scan.StandardJarScanner : Failed to scan [file:/D:/.m2/repository/org/bytedeco/javacpp-presets/hdf5-platform/1.10.3-1.4.3/hdf5-linux-x86.jar] from classloader hierarchy java.io.FileNotFoundException: D:\.m2\repository\org\bytedeco\javacpp-presets\hdf5-platform\1.10.3-1.4.3\hdf5-linux-x86.jar (系统找不到指定的⽂件。

TOMCAT 开启访问日志功能(ACCESS LOG)

TOMCAT 开启访问日志功能(ACCESS LOG)

修改位置如下图具体的解释如下Access Log Valve用来创建日志文件,格式与标准的web server日志文件相同。

可以使用用日志分析工具对日志进行分析,跟踪页面点击次数、用户会话的活动等。

Access Log Valve 的很多配置和行为特性与File Logger相同,包括每晚午夜自动切换日志文件。

Access Log Valve可以和任何Catalina容器关联,记录该容器处理的所有请求。

例子如下:<Valve className="org.apache.catalina.valves.AccessLogValve"directory="logs"prefix="localhost_access_log."suffix=".txt"pattern="%{X-Forwarded-For-Pound}i%l%u%t"%r"%s%b%T"%{HTTP_X_UP_CALLING_LINE_ID}i""%{x-up-calling-line-id}i""%{User-Agent}i""resolveHosts="false"/>className实现的Java类名。

必须被设置成org.apache.catalina.valves.AccessLogValve。

directory 存放日志文件的目录,可以是相对路径或者绝对路径。

如果使用相对路径,是指相对于$CATALINA_HOME的路径。

如果不指定directory属性,缺省值是“logs”(相对于$CATALINA_HOME)pattern需要记录的请求/响应不同信息域的格式布局。

如果是“common”或者“combine”,说明选择标准格式。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 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>标签的定义。

相关文档
最新文档