5 JSP页面
5.1 什么是JSP
5.1.1 概念
JSP(全称 Java Server Pages)是由 Sun 公司专门为了解决动态生成 HTML文档的技术。
JSP的本质就是Servlet程序。
5.1.2 如何在IDEA创建一个JSP页面
5.1.3 Servlet如何跳转到JSP页面
5.1.3.1 服务器端转发
request.getRequestDispatcher(“/success.jsp”).forward(request,response)，它是只要执行到此语句之后则立刻进行跳转，可以传递request属性。
这种跳转属于无条件跳转，它只能在栈内转，而sendRedirect中则可以任意转，甚至可以输入baidu
public class MyServlet extends HttpServlet {@Overrideprotected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {//super.doGet(req, resp);//resp.sendRedirect("/index/index");req.getRequestDispatcher("/index/index.jsp").forward(req,resp);System.out.println(111);}}
注意：req设置了跳转，则不会再执行下面的打印语句了
5.1.3.2 客户端重定向跳转
- 客户端重定向
response.sendRedirect(“fail.jsp”)
所有页面执行完之后再进行跳转，不能传递request范围的属性，但是可以通过地址重写的方式向跳转页传递参数，因为该方法执行完之后就相当于一次http request的结束，这是服务器会向客户端发送302状态码和新的url，告诉客户端重新发送request请求到新的url，然后客户端照此执行，执行即新的请求响应流程开始，服务器再重新创建HttpServletRequest对象和HttpServletResponse对象，此时两个请求已经不在一个线程了，所以request和response对象都不是开始的那个了；
- 请求头设置
response.setHeader(“refresh”,”2;URL=index.jsp”),2秒后跳转到其他页面；
- 注意
通过以上可以得知，如果现在一个页面中使用了JDBC，则应该在forward跳转之前关闭数据库链接，而使用respose则可以在任意的位置处关闭.
@WebServlet(urlPatterns = "/myServlet")public class MyServlet extends HttpServlet {@Overrideprotected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {//super.doGet(req, resp);resp.sendRedirect("/index/index");//req.getRequestDispatcher("/index/index").forward(req,resp);System.out.println(111);}}
通过重定向的方式是再请求完成后发送一次Response，所以底部的打印语句是会被执行到的。
5.2 JSP的语法
5.2.1 page指定:JSP文件头部声明
<%@ page language=”java” contentType=”text/html; charset=UTF-8” pageEncoding=”UTF-8” %>
这是 jsp 文件的头声明，示这是 jsp 页面
5.2.2 JSP的三种脚本介绍
- 声明脚本(是独立类变量)
格式：<%! java 代码 %>
- 表达式脚本(内容都会被翻译到 _service 方法中)
注意：表达式不要以分号结尾，否则会报错
<%=表达式 %>
- 代码脚本(内容都会被翻译到 service 方法中)
<% java 代码 %>
代码脚本里可以书写任意的 java 语句。
所以 service 方法中可以写的 java 代码，都可以书写到代码脚本中。
5.2.3 JSP中的注释
- java注释
// 单行的java 注释
/
多行 java 代码注释
/
单行注释和多行注释能在翻译后的 java 源代码中看见。
- jsp注释
<%— jsp 注释 —%>
jsp 注释在翻译的时候会直接被忽略掉
- html注释
html 的注释会被翻译到 java 代码中输出到 html 页面中查看
5.3 JSP内置对象
5.3.1 (service方法)九大内置对象
我们打开翻译后的java文件,查看_jspService方法。可以查看有九大对象：
out对象：javax.servlet.jsp.JspWriter
5.3.2 (service方法)四大域对象
- 基本概念
四大域对象经常用来保存数据信息。
pageContext:可以保存数据在同一个jsp页面中使用。
request:可以保存数据在同一个 request 对象中使用。经常用于在转发的时候传递数据。
session:可以保存在一个会话中使用
application(ServletContext):就是 ServletContext对象，网站重启前数据都在。
- 测试步骤
- 测试代码
后台request.setAttribute("language", language);
前端
<body>得到后台返回值：${requestScope.language }<br/>请求：${requestScope.reqParam }<br/></body>
5.3.3 (service方法)两大输出对象
- 手动调用out.flush()
结果
- 原理
5.4 JSP的包含与转发功能
- 静态包含(基本上只适用jsp静态包含功能了)
<%@ include file=”” %>：静态包含是把包含的页面内容原封装不动的输出到包含的位置
- 动态包含
动态包含会把包含的 jsp 页面单独翻译成 servlet 文件，然后在执行到时候再调用翻译的 servlet 程序。并把计算的结果返回。
动态包含是在执行的时候，才会加载。所以叫动态包含。
- 页面转发
有如下代码
<jsp:forward page=”/index2.jsp”></jsp:forward>
访问生成后,点击访问将自动跳转到index2.jsp页面
扩展：静态包含和动态包含的区别
6 apache&nginx和tomcat的使用区别
6.1 通篇概览说明下
总的来说，Apache或者Nginx 是HTTP Server，Tomcat 则是一个Application Server也有人说是Web Server，但本质上它是一个Servlet/JSP应用的容器，顺便说一句，GlassFish以前版本的Servlet容器实现就直接用的Tomcat。
一个 HTTP Server 关心的是 HTTP 协议层面的传输和访问控制，所以在 Apache/Nginx 上你可以看到代理、负载均衡等功能。客户端通过 HTTP Server 访问服务器上存储的资源（HTML 文件、图片文件等等）。通过 CGI 技术，也可以将处理过的内容通过 HTTP Server 分发，但是一个 HTTP Server 始终只是把服务器上的文件如实的通过 HTTP 协议传输给客户端。
而Application Server应用服务器，顾名思义是一个应用的容器。它首先需要支持开发语言的 Runtime环境（对于 Tomcat 来说，就是 Java），保证应用能够在应用服务器上正常运行。其次，需要支持应用相关的规范，例如类库、安全方面的特性。对于 Tomcat 来说，就是需要提供 JSP/Sevlet 运行需要的标准类库、Interface 等。为了方便，应用服务器往往也会集成 HTTP Server 的功能，但是不如专业的 HTTP Server 那么强大，所以Application Server应用服务器往往是运行在 HTTP Server 的背后，执行应用，将动态的内容转化为静态的内容之后，通过 HTTP Server 分发到客户端。
这也是为什么Nginx往往与Tomcat配合使用的原因。
6.2 详细的讲一下吧
6.2.1 Apache(稳定可重写)
Apache HTTP Server（简称Apache）是Apache软件基金会的一个开放源码的网页，它是一个模块化的服务器，可以运行在几乎所有广泛使用的计算机平台上。其属于应用服务器。
优点
- Apache支持模块多，性能稳定，可rewrite
- Apache本身是静态解析，适合静态HTML、图片等，
尤其相对于Tomcat服务器来说处理静态文件是它的优势，速度快
- 其自身不支持动态页面，但可以通过扩展脚本、模块等支持动态页面。
Apche可以支持PHPcgiperl,但是要使用Java的话，你需要Tomcat在Apache后台支撑，将Java请求由Apache转发给Tomcat处理。
缺点：
- 配置相对复杂
- 自身不支持动态页面
6.2.2 Tomcat(Application Server 应用容器)
Tomcat 是Apache 软件基金会（Apache Software Foundation）的Jakarta 项目中的一个核心项目。Tomcat 服务器是一个免费的开放源代码的Web 应用服务器，属于轻量级应用服务器。
Tomcat是应用(Java)服务器，它只是一个Servlet(JSP也翻译成Servlet)容器，可以认为是Apache的扩展，但是可以独立于Apache运行。
其的三个端口
8005：关闭tomcat通信接口
8009：与其他http服务器通信接口，用于http服务器集合
8080：建立http连接 用，如浏览器访问
优点：
- 动态解析容器，处理动态请求，是编译JSP/Servlet的容器
缺点：
- 可以说tomcat 只能用做java服务器;
- tomcat处理html的能力不如apache和nginx，tomcat处理静态内容的速度不如apache和nginx;
tomcat接受的最大并发数有限，连接数过多，会导致tomcat处于”僵尸”状态，对后续的连接失去响应，需要结合nginx一起使用
6.2.3 Nginx(小轻扛并发，负载代理可分发)
Nginx是俄罗斯人编写的十分轻量级的HTTP服务器,Nginx，它的发音为“engine X”，是一个高性能的HTTP和反向代理服务器，同时也是一个IMAP/POP3/SMTP 代理服务器。
优点：占有内存少，
- 并发能力强，
- 易于开发，部署方便，
- 支持多语言通用服务器，
- 处理静态能力极强，处理静态文件能力高于apache三倍以上。
- 反向代理
- 负载均衡
- 动态分离机制，静态请求直接就可以通过Nginx处理，动态请求才转发请求到后台交由Tomcat进行处理。
缺点：
- 可以说nginx 只适合静态和反向代理和分发
6.3 它们之间有什么区别
6.3.1 nginx和tomcat的区别
nginx常用做静态内容服务和代理服务器，直接外来请求转发给后面的应用服务器（tomcat，Django等），tomcat更多用来做一个应用容器，让java web app泡在里面的东西。严格意义上来讲，Apache和nginx应该叫做HTTP Server，而tomcat是一个Application Server是一个Servlet/JSO应用的容器。
客户端通过HTTP Server访问服务器上存储的资源（HTML文件，图片文件等），HTTP Server是中只是把服务器上的文件如实通过HTTP协议传输给客户端。
应用服务器往往是运行在HTTP Server的背后，执行应用，将动态的内容转化为静态的内容之后，通过HTTP Server分发到客户端
注意：nginx只是把请求做了分发，不做处理！6.3.2 nginx和apache的区别
apache是同步多进程模型，一个连接对应一个进程，而nginx是异步的，多个连接（万级别）可以对应一个进程。
nginx轻量级，抗并发，处理静态文件好
apache超稳定，对PHP支持比较简单，nginx需要配合其他后端用，处理动态请求有优势，建议使用前端nginx抗并发，后端apache集群，配合起来会更好6.3.3 各自优缺点
1) nginx相对于apache的优点
轻量级，同样起web 服务，比apache占用更少的内存及资源 抗并发，nginx 处理请求是异步非阻塞的，而apache 则是阻塞型的，在高并发下nginx 能保持低资源低消耗高性能高度模块化的设计，编写模块相对简单提供负载均衡
社区活跃，各种高性能模块出品迅速
2) apache 相对于nginx 的优点
apache的 rewrite（重写） 比nginx 的强大 ;
支持动态页面;
支持的模块多，基本涵盖所有应用;
性能稳定，而nginx相对bug较多。
3) 两者优缺点比较
Nginx 配置简洁, Apache 复杂 ;
Nginx 静态处理性能比 Apache 高 3倍以上 ;
Apache 对 PHP 支持比较简单，Nginx 需要配合其他后端用;Apache 的组件比 Nginx 多 ;
apache是同步多进程模型，一个连接对应一个进程;nginx是异步的，多个连接(万级别)可以对应一个进程;
nginx处理静态文件好,耗费内存少;
动态请求由apache去做，nginx只适合静态和反向;
Nginx适合做前端服务器，负载性能很好;
Nginx本身就是一个反向代理服务器 ，且支持负载均衡6.4 实际怎么结合使用呢？
Tomcat结合Apache、Nginx实现高性能的web服务器
Tomcat虽然是一个servlet和jsp容器，但是它也是一个轻量级的web服务器。它既可以处理动态内容，也可以处理静态内容。不过，tomcat的最大优势在于处理动态请求，处理静态内容的能力不如apache和nginx，并且经过测试发现，tomcat在高并发的场景下，其接受的最大并发连接数是有限制的，连接数过多会导致tomcat处于”僵死”状态，因此，在这种情况下，我们可以利用nginx的高并发，低消耗的特点与tomcat一起使用。因此，tomcat与nginx、apache结合使用共有如下几点原因：
1、tomcat处理html的能力不如Apache和nginx，tomcat处理静态内容的速度不如apache和nginx。
2、tomcat接受的最大并发数有限，连接数过多，会导致tomcat处于”僵尸”状态，对后续的连接失去响应，需要结合nginx一起使用。
通常情况下，tomcat与nginx、Apache结合使用，nginx、apache既可以提供web服务，也可以转发动态请求至tomcat服务器上。但在一个高性能的站点上，通常nginx、apache只提供代理的功能，也就是转发请求至tomcat服务器上，而对于静态内容的响应，则由前端负载均衡器来转发至专门的静态服务器上进行处理。其架构类似于如下图：
在这种架构中，当haproxy或nginx作为前端代理时，如果是静态内容，如html、css等内容，则直接交给静态服务器处理；如果请求的图片等内容，则直接交给图片服务器处理；如果请求的是动态内容，则交给tomcat服务器处理，不过在tomcat服务器上，同时运行着nginx服务器，此时的nginx作为静态服务器，它不处理静态请求，它的作用主要是接受请求，并将请求转发给tomcat服务器的(因为nginx处理并发能力比较强)，除此之外，nginx没有任何作用。
6.5 那就归纳起来
如下这些知识点上文都有描述，如下只是做一些总结
处理静态能力：nginx > apache > tomcat(nginx处理静态能力超过apache三倍)
处理动态： tomcat(java)、apche(php)，nginx不能处理动态请求
nginx优点：内存小轻量级，抗并发；处理静态文件有优势；负载均衡、反向代理、分发请求。
apache优点：相对于tomcat服务器来说处理静态文件是它的优势，速度快。apache是静态解析，适合静态HTML、图片等。相对于不能处理动态请求的nginx，apache超稳定，对PHP支持比较简单，可rewrite。
tomcat：动态解析容器，处理动态请求，是编译JSPServlet的容器。nginx有动态分离机制，静态请求直接就可以通过nginx处理，动态请求才转发请求到后台交由tomcat进行处理。
7 tomcat的使用
7.1 基本说明
参考链接：https://segmentfault.com/a/1190000013122831
7.2 tomcat的安装与目录
- 安装
找到需要用的Tomcat 版本对应的 zip 压缩包，解压到需要安装的目录即可(无需安装_包括Linux的文件夹使用)，安装后的目录介绍
- startup.bat和startup.sh文件的区别？
tomcat的bin文件夹中存在一份.bat文件和相对应的.sh文件，一个是为了在window系统上执行的文件，另一个是linux下的批处理文件。例如：startup.bat和startup.sh。
- startup.bat和catalina.bat的逻辑关系
startup.sh—-调用—->catalina.sh—-引用—->setclasspath.sh(Linux)
startup.bat—-调用—->catalina.bat —-引用—->setclasspath.bat (Windows)
7.3 tomcat的启动与停止(windows系统下)
- 启动
方式一(推荐)：打开命令行——>cd到tomcat的bin目录下—>使用catalina run命令启动
该方式的优点是出现问题时可以及时查看到
方式二: 找到 Tomcat 目录下的 bin 目录下的 startup.bat 文件，双击，就可以启动 Tomcat 服务器
- 校验启动是否成功
打开浏览器，在浏览器地址栏中输入以下地址测试：
http://localhost:8080
http://127.0.0.1:8080
http://真实 ip:8080
当出现如下界面，说明 Tomcat 服务器启动成功
- 启动失败的情况
常见的启动失败的情况有，双击 startup.bat 文件，就会出现一个小黑窗口一闪而来。这个时候，失败的原因基本上都是因为没有配置好 JAVA_HOME 环境变量
- 停止
方式一(推荐):找到tomcat的bin目录下的 shutdown.bat,双击即可停止tomcat服务器
方式二:点击tomcat 服务器窗口的 x 关闭按钮
方式三:把 tomcat 服务器窗口置为当前窗口，然后按快捷键 Ctrl+C
7.4 server.xml文件的说明与使用
7.4.1 server.xml配置文件简介
tomcat.server一个请求的过程
1、用户点击网页内容，请求被发送到本机端口8080，被在那里监听的Coyote HTTP/1.1 Connector获得。
2、Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应。
3、Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host。
4、Engine匹配到名为localhost的Host（即使匹配不到也把请求交给该Host处理，因为该Host被定义为该Engine的默认主机），名为localhost的Host获得请求/test/index.jsp，匹配它所拥有的所有的Context。Host匹配到路径为/test的Context（如果匹配不到就把该请求交给路径名为“ ”的Context去处理）。
5、path=“/test”的Context获得请求/index.jsp，在它的mapping table中寻找出对应的Servlet。Context匹配到URL PATTERN为*.jsp的Servlet,对应于JspServlet类。
6、构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet（）或doPost（）.执行业务逻辑、数据存储等程序。
7、Context把执行完之后的HttpServletResponse对象返回给Host。
8、Host把HttpServletResponse对象返回给Engine。
9、Engine把HttpServletResponse对象返回Connector。
10、Connector把HttpServletResponse对象返回给客户Browser。
7.4.2 一个典型的xml配置项
7.4.3 tomcat.server的核心组件间关联
7.4.3.1 整体关系
核心组件之间的整体关系，在上一部分有所介绍，这里总结一下：
Server元素在最顶层，代表整个Tomcat容器；一个Server元素中可以有一个或多个Service元素。
Service在Connector和Engine外面包了一层，把它们组装在一起，对外提供服务。一个Service可以包含多个Connector，但是只能包含一个Engine。Connector接收请求，Engine处理请求。
Engine、Host和Context都是容器，且 Engine包含Host，Host包含Context。每个Host组件代表Engine中的一个虚拟主机；每个Context组件代表在特定Host上运行的一个Web应用。
7.4.3.2 如何确定请求由谁处理？
当请求被发送到Tomcat所在的主机时，如何确定最终哪个Web应用来处理该请求呢？
- 根据协议和端口号选定Service和Engine
Service中的Connector组件可以接收特定端口的请求，因此，当Tomcat启动时，Service组件就会监听特定的端口。在第一部分的例子中，Catalina这个Service监听了8080端口（基于HTTP协议）和8009端口（基于AJP协议）。当请求进来时，Tomcat便可以根据协议和端口号选定处理请求的Service；Service一旦选定，Engine也就确定。
通过在Server中配置多个Service，可以实现通过不同的端口号来访问同一台机器上部署的不同应用。
- 根据域名或IP地址选定Host
Service确定后，Tomcat在Service中寻找名称与域名/IP地址匹配的Host处理该请求。如果没有找到，则使用Engine中指定的defaultHost来处理该请求。在第一部分的例子中，由于只有一个Host（name属性为localhost），因此该Service/Engine的所有请求都交给该Host处理。
- 根据URI选定Context/Web应用
这一点在Context一节有详细的说明：Tomcat根据应用的 path属性与URI的匹配程度来选择Web应用处理相应请求，这里不再赘述。
- 举例
以请求http://localhost:8080/app1/index.html为例，首先通过协议和端口号（http和8080）选定Service；然后通过主机名（localhost）选定Host；然后通过uri（/app1/index.html）选定Web应用。
7.4.3.3 如何配置多个服务
通过在Server中配置多个Service服务，可以实现通过不同的端口号来访问同一台机器上部署的不同Web应用。
在server.xml中配置多服务的方法非常简单，分为以下几步：
（1）复制
（2）修改端口号：根据需要监听的端口号修改
（3）修改Service和Engine的name属性（Catalina）
（4）修改Host的appBase属性（如webapps2）
（5）Web应用仍然使用自动部署
（6）将要部署的Web应用(WAR包或应用目录)拷贝到新的appBase（webapps同目录下新建）下。
7.5 tomcat部署与配置元素说明
7.5.1 默认访问的项目和地址
- 默认ROOT目录的访问
当我们在浏览器地址栏中输入访问地址如下：
http://ip:port/ ====> 没有工程名的时候,默认访问的是 ROOT工程。
- 默认index.html页面访问
当我们在浏览器地址栏中输入的访问地址如下：
http://ip:port/工程名/ ====> 没有资源名，默认访问 index.html 页面
7.5.2 更改server.xml文件
7.5.3 更改catalina/localhost文件夹
7.6 IDE集成tomcat
- 修改 web 工程对应的 Tomcat 运行实例名称
- 确认Tomcat 实例中有你要部署运行的 web 工程模块
- 可以修改Tomcat 实例启动后默认的访问地址
7.7 扩展：tomcat.server的各级元素
7.7.1 顶层元素
概念：Server元素在最顶层，代表整个 tomcat容器，因此它必须是server.xml中唯一一个最外层的元素。一个Server元素中可以有一个或多个Service元素。
作用：Server的主要任务，就是提供一个接口让客户端能够访问到这个Service集合，同时维护它所包含的所有的Service的声明周期，包括如何初始化、如何结束服务、如何找到客户端要访问的Service。
属性：常见的有两个属性，一个是shutdown代表关闭Server的指令，port属性表示Server接收shutdown指令的端口号，设为-1可以禁掉该端口。
注意：一个“Server”自身不是一个“Container”(容器)，因此在这里你不可以定义诸如“Valves”或者”Loggers”子组件。7.7.2 次顶层元素
概念：该元素由org.apache.catalina.Service接口定义,它包含一个元素,以及一个或多个 ,这些Connector元素共享用同一个Engine元素来处理所有Connector收到的请求。
作用：Service的作用，是在和 外面包了一层，把它们组装在一起，对外提供服务。一个 可以包含多个 ，但是只能包含一个 ；其中Connector的作用是从客户端接收请求，Engine的作用是处理接收进来的请求。
说明：Tomcat可以提供多个Service，不同的Service监听不同的端口，后文会有介绍。7.7.3 连接器
概念：由Connector接口定义，元素代表与客户程序实际交互的给件,它负责接收客户请求,以及向客户返回响应结果。
作用：主要功能：接收连接请求，创建Request和Response对象用于和请求端交换数据；然后分配线程让Engine来处理这个请求，并把产生的Request和Response对象传给Engine。
例子：
说明：
- 通过配置第1个Connector，客户端可以通过8080端口号使用http协议访问Tomcat。其中，protocol属性规定了请求的协议，port规定了请求的端口号，redirectPort表示当强制要求https而请求是http时，重定向至端口号为8443的Connector，connectionTimeout表示连接的超时时间。
在这个例子中，Tomcat监听HTTP请求，使用的是8080端口，而不是正式的80端口；实际上，在正式的生产环境中，Tomcat也常常监听8080端口，而不是80端口。这是因为在生产环境中，很少将Tomcat直接对外开放接收请求，而是在Tomcat和客户端之间加一层代理服务器(如nginx)，用于请求的转发、负载均衡、处理静态文件等；通过代理服务器访问Tomcat时，是在局域网中，因此一般仍使用8080端口。
- 通过配置第2个Connector，客户端可以通过8009端口号使用AJP协议访问Tomcat。AJP协议负责和其他的HTTP服务器(如Apache)建立连接；在把Tomcat与其他HTTP服务器集成时，就需要用到这个连接器。之所以使用Tomcat和其他服务器集成，是因为Tomcat可以用作Servlet/JSP容器，但是对静态资源的处理速度较慢，不如Apache和IIS等HTTP服务器；因此常常将Tomcat与Apache等集成，前者作Servlet容器，后者处理静态资源，而AJP协议便负责Tomcat和Apache的连接。
7.7.4 容器
说明：容器的功能是处理Connector接收进来的请求，并产生相应的响应。Engine、Host和Context都是容器，但它们不是平行的关系，而是父子关系：Engine包含Host，Host包含Context。一个Engine组件可以处理Service中的所有请求，一个Host组件可以处理发向一个特定虚拟主机的所有请求，一个Context组件可以处理一个特定Web应用的所有请求。
每个Service元素只能有一个Engine元素。Engine组件从一个或多个Connector中接收请求并处理，并将完成的响应返回给Connector，最终传递给客户端。
Engine的配置语句如下：
其中，name属性用于日志和错误信息，在整个Server中应该唯一。defaultHost属性指定了默认的host名称，当发往本机的请求指定的host名称不存在时，一律使用defaultHost指定的host进行处理；因此，defaultHost的值，必须与Engine中的一个Host组件的name属性值匹配。
7.7.5 主机
7.7.5.1 Engine与Host
Host是Engine的子容器。Engine组件中可以内嵌1个或多个Host组件，每个Host组件代表Engine中的一个虚拟主机。Host组件至少有一个，且其中一个的name必须与Engine组件的defaultHost属性相匹配。
7.7.5.2 Host的作用
Host虚拟主机的作用，是运行多个Web应用（一个Context代表一个Web应用），并负责安装、展开、启动和结束每个Web应用。
Host组件代表的虚拟主机，对应了服务器中一个网络名实体(如”www.test.com”，或IP地址”116.25.25.25”)；为了使用户可以通过网络名连接Tomcat服务器，这个名字应该在DNS服务器上注册。
客户端通常使用主机名来标识它们希望连接的服务器；该主机名也会包含在HTTP请求头中。Tomcat从HTTP头中提取出主机名，寻找名称匹配的主机。如果没有匹配，请求将发送至默认主机。因此默认主机不需要是在DNS服务器中注册的网络名，因为任何与所有Host名称不匹配的请求，都会路由至默认主机。
7.7.5.3 Host的配置
在第一部分的例子中，Host的配置如下：
下面对其中配置的属性进行说明：
name属性指定虚拟主机的主机名，一个Engine中有且仅有一个Host组件的name属性与Engine组件的defaultHost属性相匹配；一般情况下，主机名需要是在DNS服务器中注册的网络名，但是Engine指定的defaultHost不需要，原因在前面已经说明。
unpackWARs指定了是否将代表Web应用的WAR文件解压；如果为true，通过解压后的文件结构运行该Web应用，如果为false，直接使用WAR文件运行Web应用。
Host的autoDeploy和appBase属性，与Host内Web应用的自动部署有关；此外，本例中没有出现的xmlBase和deployOnStartup属性，也与Web应用的自动部署有关；将在下一节(Context)中介绍。
7.7.6 上下文
7.7.6.1 Context的作用
Context元素代表在特定虚拟主机上运行的一个Web应用。在后文中，提到Context、应用或Web应用，它们指代的都是Web应用。每个Web应用基于WAR文件，或WAR文件解压后对应的目录（这里称为应用目录）。
Context是Host的子容器，每个Host中可以定义任意多的Context元素。
server.xml配置文件中默认没有Context元素的配置。这是因为，Tomcat开启了自动部署，Web应用没有在server.xml中配置静态部署，而是由Tomcat通过特定的规则自动部署。下面介绍一下Tomcat自动部署Web应用的机制。
7.7.6.2 Web应用自动部署
Host的配置
要开启Web应用的自动部署，需要配置所在的虚拟主机；配置的方式就是前面提到的Host元素的deployOnStartup和autoDeploy属性。如果deployOnStartup和autoDeploy设置为true，则 tomcat启动自动部署：当检测到新的Web应用或Web应用的更新时，会触发应用的部署(或重新部署)。二者的主要区别在于，deployOnStartup为true时，Tomcat在启动时检查Web应用，且检测到的所有Web应用视作新应用；autoDeploy为true时，Tomcat在运行时定期检查新的Web应用或Web应用的更新。除此之外，二者的处理相似。
通过配置deployOnStartup和autoDeploy可以开启虚拟主机自动部署Web应用；实际上，自动部署依赖于检查是否有新的或更改过的Web应用，而Host元素的appBase和xmlBase设置了检查Web应用更新的目录。
其中，appBase属性指定Web应用所在的目录，默认值是webapps，这是一个相对路径，代表Tomcat根目录下webapps文件夹。
xmlBase属性指定Web应用的XML配置文件所在的目录，默认值为conf/
例如第一部分的例子中，主机localhost的xmlBase的默认值是
$TOMCAT_HOME/conf/Catalina/localhost。
检查Web应用更新
一个Web应用可能包括以下文件：XML配置文件，WAR包，以及一个应用目录(该目录包含Web应用的文件结构)；其中XML配置文件位于xmlBase指定的目录，WAR包和应用目录位于appBase指定的目录。
Tomcat按照如下的顺序进行扫描，来检查应用更新：
A、扫描虚拟主机指定的xmlBase下的XML配置文件
B、扫描虚拟主机指定的appBase下的WAR文件
C、扫描虚拟主机指定的appBase下的应用目录
Context元素最重要的属性是docBase和path，此外reloadable属性也比较常用。
docBase指定了该Web应用使用的WAR包路径，或应用目录。需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，docBase不在appBase目录中，才需要指定；如果docBase指定的WAR包或应用目录就在docBase中，则不需要指定，因为Tomcat会自动扫描appBase中的WAR包和应用目录，指定了反而会造成问题。
path指定了访问该Web应用的上下文路径，当请求到来时，Tomcat根据Web应用的 path属性与URI的匹配程度来选择Web应用处理相应请求。例如，Web应用app1的path属性是”/app1”，Web应用app2的path属性是”/app2”，那么请求/app1/index.html会交由app1来处理；而请求/app2/index.html会交由app2来处理。如果一个Context元素的path属性为””，那么这个Context是虚拟主机的默认Web应用；当请求的uri与所有的path都不匹配时，使用该默认Web应用来处理。
但是，需要注意的是，在自动部署场景下(配置文件位于xmlBase中)，不能指定path属性，path属性由配置文件的文件名、WAR文件的文件名或应用目录的名称自动推导出来。如扫描Web应用时，发现了xmlBase目录下的app1.xml，或appBase目录下的app1.WAR或app1应用目录，则该Web应用的path属性是”app1”。如果名称不是app1而是ROOT，则该Web应用是虚拟主机默认的Web应用，此时path属性推导为””。
reloadable属性指示tomcat是否在运行时监控在WEB-INF/classes和WEB-INF/lib目录下class文件的改动。如果值为true，那么当class文件改动时，会触发Web应用的重新加载。在开发环境下，reloadable设置为true便于调试；但是在生产环境中设置为true会给服务器带来性能压力，因此reloadable参数的默认值为false。
开发环境：
自动部署举例
最典型的自动部署，就是当我们安装完Tomcat后，$TOMCAT_HOME/webapps目录下有如下文件夹：
当我们启动Tomcat后，可以使用http://localhost:8080/来访问Tomcat，其实访问的就是ROOT对应的Web应用；我们也可以通过http://localhost:8080/docs来访问docs应用，同理我们可以访问examples/host-manager/manager这几个Web应用。
7.7.6.3 server.xml中静态部署Web应用
除了自动部署，我们也可以在server.xml中通过
server.xml中使用Context元素配置Web应用，Context元素应该位于Host元素中。举例如下：
docBase：静态部署时，docBase可以在appBase目录下，也可以不在；本例中，docBase不在appBase目录下。
path：静态部署时，可以显式指定path属性，但是仍然受到了严格的限制：只有当自动部署完全关闭(deployOnStartup和autoDeploy都为false)或docBase不在appBase中时，才可以设置path属性。在本例中，docBase不在appBase中，因此path属性可以设置。
reloadable属性的用法与自动部署时相同。
source：和IDE相关。
7.8 扩展：tomcat.server其他组件
7.8.1 Listener
Listener(即监听器)定义的组件，可以在特定事件发生时执行特定的操作；被监听的事件通常是Tomcat的启动和停止。
监听器可以在Server、Engine、Host或Context中，本例中的监听器都是在Server中。实际上，本例中定义的6个监听器，都只能存在于Server组件中。监听器不允许内嵌其他组件。
监听器需要配置的最重要的属性是className，该属性规定了监听器的具体实现类，该类必须实现了org.apache.catalina.LifecycleListener接口。
下面依次介绍例子中配置的监听器：
- VersionLoggerListener：当Tomcat启动时，该监听器记录Tomcat、Java和操作系统的信息。该监听器必须是配置的第一个监听器。
- AprLifecycleListener：Tomcat启动时，检查APR库，如果存在则加载。APR，即Apache Portable Runtime，是Apache可移植运行库，可以实现高可扩展性、高性能，以及与本地服务器技术更好的集成。
- JasperListener：在Web应用启动之前初始化Jasper，Jasper是JSP引擎，把JVM不认识的JSP文件解析成java文件，然后编译成class文件供JVM使用。
- JreMemoryLeakPreventionListener：与类加载器导致的内存泄露有关。
- GlobalResourcesLifecycleListener：通过该监听器，初始化< GlobalNamingResources>标签中定义的全局JNDI资源；如果没有该监听器，任何全局资源都不能使用。< GlobalNamingResources>将在后文介绍。
- ThreadLocalLeakPreventionListener：当Web应用因thread-local导致的内存泄露而要停止时，该监听器会触发线程池中线程的更新。当线程执行完任务被收回线程池时，活跃线程会一个一个的更新。只有当Web应用(即Context元素)的renewThreadsWhenStoppingContext属性设置为true时，该监听器才有效。
7.8.2 GlobalNamingResources与Realm
Engine组件下定义了Realm组件：
Realm，可以把它理解成“域”；Realm提供了一种用户密码与web应用的映射关系，从而达到角色安全管理的作用。在本例中，Realm的配置使用name为UserDatabase的资源实现。而该资源在Server元素中使用GlobalNamingResources配置：name=”UserDatabase” pathname=”conf/tomcat-users.xml” type=”org.apache.catalina.UserDatabase”/>
GlobalNamingResources元素定义了全局资源，通过配置可以看出，该配置是通过读取$TOMCAT_HOME/ conf/tomcat-users.xml实现的。7.8.3 Valve
Host元素内定义了Valve组件：prefix=”localhost_access_log.” suffix=”.txt”/>
单词Valve的意思是“阀门”，在Tomcat中代表了请求处理流水线上的一个组件；Valve可以与Tomcat的容器(Engine、Host或Context)关联。
不同的Valve有不同的特性，下面介绍一下本例中出现的AccessLogValve。
AccessLogValve的作用是通过日志记录其所在的容器中处理的所有请求，在本例中，Valve放在Host下，便可以记录该Host处理的所有请求。AccessLogValve记录的日志就是访问日志，每天的请求会写到一个日志文件里。AccessLogValve可以与Engine、Host或Context关联；在本例中，只有一个Engine，Engine下只有一个Host，Host下只有一个Context，因此AccessLogValve放在三个容器下的作用其实是类似的。
本例的AccessLogValve属性的配置，使用的是默认的配置；下面介绍AccessLogValve中各个属性的作用：
（1）className：规定了Valve的类型，是最重要的属性；本例中，通过该属性规定了这是一个AccessLogValve。
（2）directory：指定日志存储的位置，本例中，日志存储在$TOMCAT_HOME/logs目录下。
（3）prefix：指定了日志文件的前缀。
（4）suffix：指定了日志文件的后缀。通过directory、prefix和suffix的配置，在$TOMCAT_HOME/logs目录下，可以看到如下所示的日志文件。
（5）pattern：指定记录日志的格式，本例中各项的含义如下：
%h：远程主机名或IP地址；如果有nginx等反向代理服务器进行请求分发，该主机名/IP地址代表的是nginx，否则代表的是客户端。后面远程的含义与之类似，不再解释。
%l：远程逻辑用户名，一律是”-”，可以忽略。
%u：授权的远程用户名，如果没有，则是”-”。
%t：访问的时间。
%r：请求的第一行，即请求方法(get/post等)、uri、及协议。
%s：响应状态，200,404等等。
%b：响应的数据量，不包括请求头，如果为0，则是””-。
例如，下面是访问日志中的一条记录
pattern的配置中，除了上述各项，还有一个非常常用的选项是%D，含义是请求处理的时间(单位是毫秒)，对于统计分析请求的处理速度帮助很大。
开发人员可以充分利用访问日志，来分析问题、优化应用。例如，分析访问日志中各个接口被访问的比例，不仅可以为需求和运营人员提供数据支持，还可以使自己的优化有的放矢；分析访问日志中各个请求的响应状态码，可以知道服务器请求的成功率，并找出有问题的请求；分析访问日志中各个请求的响应时间，可以找出慢请求，并根据需要进行响应时间的优化。
若有收获，就点个赞吧
0 人点赞
