Tomcat主要组件

• Tomcat体系结构图

  

  • Server组件

    • 启动一个server实例（即一个JVM），它监听在8005端口以接收shutdown命令

    • Server的定义不能使用同一个端口，这意味着如果在同一个物理机上启动了多个Server实例，必须配置它们使用不同的端口

    <Server port="8005" 
    shutdown="SHUTDOWN">
    
    // port:  接收shutdown指令的端口，默认为8005
    // shutdown： 发往此Server用于实现关闭tomcat实例的命令字符串，默认为SHUTDOWN
    

  • Service组件

    • Service主要用于关联一个引擎和与此引擎相关的连接器，每个连接器通过一个特定的端口和协议接收请求并将其转发至关联的引擎进行处理

    • 困此，Service要包含一个引擎、一个或多个连接器

    <Service name="Catalina">
    
    // name： 此服务的名称，默认为Catalina
    

  • Connector组件

    • 支持处理不同请求的组件，一个引擎可以有一个或多个连接器，以适应多种请求方式

    • 默认只开启了处理Http协议的连接器

    • 如果需要使用其他协议，需要在Tomcat中配置该协议的连接器

    • 在Tomcat中连接器类型通常有4种：

      • HTTP连接器

      • SSL连接器

      • AJP 1.3连接器

      • proxy连接器

      <Connector port="8888" protocol="HTTP/1.1"
      connectionTimeout="20000"
      redirectPort="8443"   />
      // port：监听的端口
      // protocol：连接器使用的协议，默认为HTTP/1.1
      // connectionTimeout：等待客户端发送请求的超时时间，单位为毫秒
      // redirectPort：如果某连接器支持的协议是HTTP，当接收客户端发来的HTTPS请求时，则转发至此属性定义的端口
      // maxThreads：支持的最大并发连接数，默认为200个
      

  • Engine组件

    • Engine是Servlet处理器的一个实例，即servlet引擎，定义在server.xml中的Service标记中

    • Engine需要defaultHost属性来为其定义一个接收所有发往非明确定义虚拟主机的请求的host组件

    <Engine name="Catalina"
    defaultHost="localhost"> 
    
    // name：Engine组件的名称
    // defaultHost：Tomcat支持基于FQDN(Fully Qualified Domain Name 全限定域名)的虚拟主机，这些虚拟主机可以通过在Engine容器中定义多个不同的Host组件来实现
    // 但如果此引擎的连接器收到一个发往非非明确定义虚拟主机的请求时则需要将此请求发往一个默认的虚拟主机进行处理，因此，在Engine中定义的多个虚拟主机的主机名称中至少要有一个跟defaultHost定义的主机名称同名
    

  • Host组件

    • 位于Engine容器中用于接收请求并进行相应处理的虚拟主机。通过该容器可以运行Servlet或者JSP来处理请求

    <Host name="localhost"    appBase="webapps"
    unpackWARs="true"   autoDeploy="true"> 
    
    // name：虚拟主机的名称，Tomcat通过在请求URL中的域名与name中的值匹配，用于查找能够处理该请求的虚拟主机。如果未找到则交给在Engine中defaultHost指定的主机处理
    // appBase：此Host的webapps目录，即指定存放web应用程序的目录的路径
    // autoDeploy：在Tomcat处于运行状态时放置于appBase目录中的应用程序文件是否自动进行deploy；默认为true
    // unpackWARs：在启用此webapps时是否对WAR格式的归档文件先进行展开；默认为true
    

  • Context组件

    • Context是Host的子标签，代表指定一个Web应用，它运行在某个指定的虚拟主机（Host）上

    • 每个Web应用都是一个WAR文件，或文件的目录

    <Context path="/test"
    docBase="D:\mashibing.war" />
    
    // path：context path既浏览器访问项目的访问路径
    // docBase：相应的Web应用程序的存放位置
    // 也可以使用相对路径，起始路径为此Context所属Host中appBase定义的路径
    

  • Tomcat处理请求过程

    

    • 1、用户访问 localhost:8080/test/index.jsp，请求被发送到 Tomcat，被监听 8080 端口并处理 HTTP/1.1 协议的 Connector 获得

    • 2、Connector把该请求交给它所在的Service的Engine来处理，并等待Engine的回应

    • 3、Engine获得请求localhost/test/index.jsp，匹配所有的虚拟主机Host

    • 4、Engine匹配到名为localhost的Host虚拟主机来处理/test/index.jsp请求（即使匹配不到会请求交给默认Host处理），Host会根据/test匹配它所拥有的所有的Context

    • 5、匹配到的Context获得请求/index.jsp

    • 6、构造HttpServletRequest对象和HttpServletResponse对象，作为参数调用JspServlet的doGet（）或doPost（）, 执行业务逻辑、数据存储等程序

    • 7、Context把执行完之后的结果通过HttpServletResponse对象返回给Host

    • 8、Host把HttpServletResponse返回给Engine

    • 9、Engine把HttpServletResponse对象返回Connector

    • 10、Connector把HttpServletResponse对象返回给客户Browser

HTTP协议

• HTTP协议

  • 概念

    • 合同, 共同遵守的规则

    • A给B发送一段信息

      • 内容: what do you wanna eat for dinner; 晚饭想吃什么

      • 规则: 英文 中文 应用层协议 数据如何解析如何使用 http ftp ... ...

      • 方式: 微信 QQ 短信 传输层协议 数据如何发送和接收 tcp udp

      • 地址: 微信号 QQ号 电话号 网络协议 数据接收和发送的位置 ip

  • HTTP协议介绍

    • 什么是超文本

      • html页面上全是文字, 但是浏览器解析之后, 展现出来的页面是非常丰富的

      • 超文本是用超链接的方法，将各种不同空间的文字信息组织在一起的网状文本

      • 超文本更是一种用户界面范式，用以显示文本及与文本之间相关的内容

        

    • 什么是HTTP协议

      • HTTP协议是 Hyper Text Transfer Protocol（超文本传输协议）的缩写, HTTP是万维网（WWW:World Wide Web）的数据通信的基础

      • HTTP是一个简单的请求 - 响应协议，它通常运行在TCP之上，它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应

        

      • HTTP是一个基于TCP/IP通信协议来传递数据（HTML 文件, 图片文件, 查询结果等）

        

  • HTTP协议特点

    • 支持客户 / 服务器模式

      • HTTP协议支持客户端服务端模式，需要使用浏览器作为客户端来访问服务端

    • 简单快速

      • 客户向服务器请求服务时，只需传送请求方法和路径

      • 请求方法常用的有GET、POST等，每种方法规定了客户与服务器联系的类型不同

      • 由于HTTP协议简单，使得HTTP服务器的程序规模小，因而通信速度很快

    • 灵活

      • HTTP允许传输任意类型的数据对象

      • 正在传输的类型由Content-Type（Content-Type是HTTP包中用来表示内容类型的标识）加以标记

    • 无连接

      • 每次请求一次，释放一次连接

      • 所以无连接表示每次连接只能处理一个请求

      • 优点就是节省传输时间，实现简单

      • 我们有时称这种无连接为短连接

      • 对应的就有了长链接，长连接专门解决效率问题

      • 当建立好了一个连接之后，可以多次请求

      • 但是缺点就是容易造成占用资源不释放的问题

      • 当HTTP协议头部中字段Connection：keep-alive表示支持长链接

    • 单向性

      • 服务端永远是被动的等待客户端的请求

    • 无状态

      • HTTP协议是无状态协议

      • 无状态是指协议对于事务处理没有记忆能力

      • 缺少状态意味着如果后续处理需要前面的信息，则它必须重传，这样可能导致每次连接传送的数据量增大

      • 另一方面，在服务器不需要先前信息时它的应答就较快

      • 为了解决HTTP协议无状态，于是，两种用于保持HTTP连接状态的技术就应运而生了，一个是Cookie，而另一个则是Session

  • HTTP协议发展和版本

    • 概念

      • http协议在1991年发布第一个版本版本号为0.9

      • 随后WWW联盟（WWW Consortium-W3C）于1994年成立，http协议被纳入到W3C组织中进行维护和管理

        

    • http1.0

      • 最早在1996年在网页中使用，内容简单，所以浏览器的每次请求都需要与服务器建立一个TCP连接，服务器处理完成后立即断开TCP连接（无连接），服务器不跟踪每个客户端也不记录过去的请求（无状态）,请求只能由客户端发起（单向性）

    • http1.1

      • 到1999年广泛在各大浏览器网络请求中使用，HTTP/1.0中默认使用Connection: close

      • 在 HTTP/1.1 中已经默认使用 Connection: keep-alive（长连接），避免了连接建立和释放的开销，但服务器必须按照客户端请求的先后顺序依次回送相应的结果，以保证客户端能够区分出每次请求的响应内容

      • 不允许同时存在两个并行的响应

      • 1.1中最重要的一个特点是支持“长连接”，即“一次连接可以多次请求”

        

      • HTTP 1.1支持持久连接（HTTP/1.1的默认模式使用带流水线的持久连接），在一个TCP连接上可以传送多个HTTP请求和响应，减少了建立和关闭连接的消耗和延迟

      • 一个包含有许多图像的网页文件的多个请求和应答可以在一个连接中传输，但每个单独的网页文件的请求和应答仍然需要使用各自的连接

      • HTTP 1.1还允许客户端不用等待上一次请求结果返回，就可以发出下一次请求，但服务器端必须按照接收到客户端请求的先后顺序依次回送响应结果，以保证客户端能够区分出每次请求的响应内容，这样也显著地减少了整个下载过程所需要的时间

    • http2.0

      • 长连接

        • 在HTTP/2中，客户端向某个域名的服务器请求页面的过程中，只会创建一条TCP连接，即使这页面可能包含上百个资源

        • 单一的连接应该是HTTP2的主要优势，单一的连接能减少TCP握手带来的时延

        • HTTP2中用一条单一的长连接，避免了创建多个TCP连接带来的网络开销，提高了吞吐量

      • 多路复用 (Multiplexing)

        • HTTP2.0中所有加强性能的核心是二进制传输，在HTTP1.x中，我们是通过文本的方式传输数据

        • 在HTTP2.0中引入了新的编码机制，所有传输的数据都会被分割，并采用二进制格式编码

          

        • 多路复用，连接共享

        • 不同的request可以使用同一个连接传输（最后根据每个request上的id号组合成正常的请求）

        • HTTP2.0中，有两个概念非常重要：帧（frame）和流（stream）

        • 帧是最小的数据单位，每个帧会标识出该帧属于哪个流，流是多个帧组成的数据流

        • 所谓多路复用，即在一个TCP连接中存在多个流，即可以同时发送多个请求，对端可以通过帧中的表示知道该帧属于哪个请求

        • 在客户端，这些帧乱序发送，到对端后再根据每个帧首部的流标识符重新组装

        • 通过该技术，可以避免HTTP旧版本的队头阻塞问题，极大提高传输性能

      • 首部压缩（Header Compression）

        • 由于1.1中header带有大量的信息，并且得重复传输，2.0使用encoder来减少需要传输的hearder大小

      • 服务端推送（Server Push）

        • 在HTTP2.0中，服务端可以在客户端某个请求后，主动推送其他资源

        • 可以想象一下，某些资源客户端是一定会请求的，这时就可以采取服务端push的技术，提前给客户端推送必要的资源，就可以相对减少一点延迟时间

        • 在浏览器兼容的情况下也可以使用prefetch

      • 更安全

        • HTTP2.0使用了tls的拓展ALPN做为协议升级，除此之外，HTTP2.0对tls的安全性做了近一步加强，通过黑名单机制禁用了几百种不再安全的加密算法

          

• HTTP请求

  • HTTP协议的请求

    • 当你在浏览器输入 URL http://www.baidu.com 的时候，浏览器发送一个 Request 去获取 http://www.baidu.com 的 html. 服务器把 Response 发送回给浏览器

    • 浏览器分析 Response 中的 HTML，发现其中引用了很多其他文件，比如图片，CSS文件，JS文件

    • 浏览器会自动再次发送 Request 去获取图片，CSS文件，或者JS文件

    • 等所有的文件都下载成功后，网页就被显示出来了

  • Request 消息分为3部分

    • 第一部分叫 Request line

    • 第二部分叫 Request header

    • 第三部分是 Request body

      • Request header 和 Request body 之间有个空行

  • 请求的主要组成部分

    • 请求行 request Line GET /myProject/img/logo.png HTTP/1.1

      • 请求方式 默认 GET

      • 资源路径

      • 请求使用的协议

    • 请求头 request headers

      • 请求头 键值对

    • 请求体 request body

      • GET方式请求, 数据直接放在URL地址后, 请求体中没有数据

      • POST方式请求, 请求体重会有数据

        

  • 客户端发送一个HTTP请求到服务器的请求消息包括以下格式：

    

    

    

  • 请求行：

    • GET /course/id/18.html?a=3&b=4 HTTP/1.1

    • POST /login HTTP/1.1

  • 请求头：

    • 请求头用于说明是谁或什么在发送请求、请求源于何处，或者客户端的喜好及能力

    • 服务器可以根据请求头部给出的客户端信息，试着为客户端提供更好的响应

    • 请求头中信息的格式为 key：value

    • Host

      • 客户端指定自己想访问的WEB服务器的域名 / IP 地址和端口号

    • Connection

      • 连接方式

      • 如果值是close则表示基于短连接方式，如果该值是keep-alive，网络连接就是持久的，在一定时间范围内是不会关闭，使得对同一个服务器的请求可以继续在该连接上完成

    • Upgrade-Insecure-Requests

      • 服务端是否支持https加密协议

    • Cache-Control

      • 指定请求和响应遵循的缓存机制

    • User-Agent

      • 浏览器表明自己的身份（是哪种浏览器）

      • 例如 Chrome浏览器：Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/81.0.4044.129 Safari/537.36

    • Accept

      • 告诉WEB服务器自己接受什么介质类型，*/* 表示任何类型，type/* 表示该类型下的所有子类型

    • Accept-Encoding

      • 浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate）

    • Accept-Language

      • 浏览器申明自己接收的语言

      • 语言跟字符集的区别：中文是语言，中文有多种字符集，比如 big5，gb2312，gbk 等

    • Accept-Charset

      • 浏览器告诉服务器自己能接收的字符集

    • Referer

      • 浏览器向 WEB 服务器表明自己是从哪个网页 URL 获得点击当前请求中的网址 /URL

    • Refresh

      • 表示浏览器应该在多少时间之后刷新文档，以秒计时

    • Cookie

      • 可向服务端传递数据一种模型

  • 请求体

    • 客户端传递给服务器的数据

    • 比如：表单使用 post 方式提交的数据、上传的文件数据等

      

  • 请求方式

    • GET

      • 向指定的资源发出“显示”请求

      • GET请求中会将请求中传递的数据包含在URL中并在浏览器的地址栏中显示

      • GET请求传递数据时要求数据必须是ASCII字符

    • POST

      • 向指定资源提交数据，请求服务器进行处理（例如提交表单或者上传文件）

      • 数据被包含在请求体中

      • POST请求传递数据时，数据可以试试ASCII字符也可以是字节型数据，默认为字符型

      • POST请求默认情况下不会被浏览器所缓存

    • HEAD

      • 向服务器索要与GET请求相一致的响应，只不过响应体将不会被返回

      • 这一方法可以在不必传输整个响应内容的情况下，就可以获取包含在响应消息头度中的元信息

    • PUT

      • 向指定资源位置上传其最新内容

    • DELETE

      • 请求服务器删除 Request-URI 所标识的资源

    • TRACE

      • 回显服务器收到的请求，主要用于测试或诊断

    • OPTIONS

      • 这个方法可使服务器传回该资源所支持的所有HTTP请求方法

      • 用 ’ * ’ 来代替资源名称，向Web服务器发送 OPTIONS 请求，可以测试服务器功能是否正常运作

    • CONNECT

      • HTTP/1.1协议中预留给能够将连接改为管道方式的代理服务器

      • 通常用于SSL加密服务器的链接（经由非加密的HTTP代理服务器）

  • GET和POST的区别 (重要, 面试常问)

    • GET 在浏览器回退时是无害的，而 POST 会再次提交请求

    • GET 产生的 URL 地址可以被 Bookmark，而 POST 不可以

    • GET 请求会被浏览器主动 cache，而 POST 不会，除非手动设置

    • GET 请求只能进行 url 编码，而 POST 支持多种编码方式

    • GET 请求参数会被完整保留在浏览器历史记录里，而 POST 中的参数不会被保留

    • GET 请求在 URL 中传送的参数是有长度限制的，而 POST 则没有

    • 对参数的数据类型 GET 只接受 ASCII 字符，而 POST 即可是字符也可是字节

    • GET 比 POST 更不安全，因为参数直接暴露在 URL 上，所以不能用来传递敏感信息

    • GET 参数通过 URL 传递，POST 放在 Request body 中

• HTTP响应

  • 响应的主要组成部分

    • 响应行 HTTP/1.1 200

    • 协议

    • 响应状态码

      • 200 >> OK 正常响应 304 重定向 404 请求的资源没有找到 500服务器出现异常没有办法响应

    • 响应头

      

    • 响应体

    • 响应行

      • HTTP/1.1 200

      • 和请求消息相比，响应消息多了一个“响应状态码”，它以“清晰明确”的语言告诉客户端本次请求的处理结果

  • HTTP状态码分类

    • 1xx

      • 信息, 服务器收到请求, 需要请求者继续执行操作

    • 2xx

      • 成功, 操作被成功接收并处理

    • 3xx

      • 重定向, 需要进一步的操作以完成请求

    • 4xx

      • 客户端错误, 请求包含语法错误或者无法完成请求

    • 5xx

      • 服务器错误, 服务器在处理请求的过程中产生了错误

  • HTTP状态码列表

    • 100

      • 继续. 客户端应继续其请求

    • 101

      • 切换协议, 服务器根据客户端的请求切换协议, 只能切换到更高级的协议, 例如切换到HTTP的新版本协议

    • 200

      • 请求成功, 一般用于GET和POST请求

    • 201

      • 已创建, 成功请求并创建了新的资源

    • 202

      • 已接受, 已经接受请求, 但未处理完成

    • 203

      • 非授权信息, 请求成功, 但返回的meta信息不在原始的服务器, 而是一个副本

    • 204

      • 无内容, 服务器成功处理, 但未返回内容, 在未更新网页的情况下, 可确保浏览器继续显示当前文档

    • 205

      • 重置内容, 服务器处理成功, 用户终端 (例如浏览器) 应重置文档视图, 可通过此返回码清除浏览器的表单域

    • 206

      • 部分内容, 服务器成功处理了部分GET请求

    • 300

      • 多种选择, 请求的资源可包括多个位置, 相应可返回一个资源特征与地址的列表用于用户终端 (例如浏览器) 选择

    • 301

      • 永久移动, 请求的资源已被永久移动到新的URL, 返回信息包含新的URI, 浏览器会自动定向到新的URI, 今后任何新的请求都应使用新的URI代替

    • 302

      • 临时移动, 与301类似, 但资源只是临时被移动, 客户端应继续使用原有URI

    • 303

      • 查看其他地址, 与301类似, 使用GET和POST请求查看

    • 304

      • 未修改, 所请求的资源未修改, 服务器返回此状态码时, 不会返回任何资源, 客户端通常会缓存访问过的资源, 通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源

    • 305

      • 使用代理, 所请求的资源必须通过代理访问

    • 306

      • 已经被废弃的HTTP状态码

    • 307

      • 临时重定向, 与302类似, 使用GET请求重定向

    • 400

      • 客户端请求的语法错误, 服务器无法理解

    • 401

      • 请求要求用户的身份认证

    • 402

      • 保留, 将来使用

    • 403

      • 服务器理解请求客户端的请求, 但是拒绝执行该请求

    • 404

      • 服务器无法根据客户端的请求找到资源 (网页), 通过此代码, 网站设计人员可设置 “您所请求的资源无法找到” 的个性页面

    • 405

      • 客户端请求的方法被禁止

    • 406

      • 服务器无法根据客户端的请求的内容特性完成请求

    • 407

      • 请求要求代理的身份认证, 与401类似, 但请求者应当使用代理进行授权

    • 408

      • 服务器等待客户端发送的请求时间过长, 超时

    • 409

      • 服务器完成客户端的PUT请求是可能返回此代码, 服务器处理请求时发生了冲突

    • 410

      • 客户端请求的资源不存在, 410不同于404, 如果资源以前有现在被永久删除了可使用410代码, 网站设计人员可通过301代码指定资源的新位置

    • 411

      • 服务器无法处理客户端发送的不带 Content-Length 的请求信息

    • 412

      • 客户端请求信息的先决条件错误

    • 413

      • 由于请求的实体过大, 服务器无法处理, 因此拒绝请求, 为防止客户端的连续请求, 服务器可能会关闭连接, 如果只是服务器暂时无法处理, 则会包含一个 Retry-After 的响应信息

    • 414

      • 请求的URI过长 (URI通常为网址), 服务器无法处理

    • 415

      • 服务器无法处理请求附带的媒体格式

    • 416

      • 客户端请求的范围无效

    • 417

      • 服务器无法满足Expect的请求头信息

    • 500

      • 服务器内部错误, 无法完成请求

    • 501

      • 服务器不支持请求的功能, 无法完成请求

    • 502

      • 作为网关或者代理工作的服务器尝试执行请求时, 从远程服务器接收到了一个无效的响应

    • 503

      • 由于超载或系统维护, 服务器暂时无法处理客户端的请求, 延时的长度可包含在服务器的 Retry-After 头信息中

    • 504

      • 充当网关或代理的服务器, 未及时从远端服务器获取请求

    • 505

      • 服务器不支持请求的HTTP协议的版本, 无法完成处理

  • 常见状态码及含义

    • 200 - 请求成功，已经正常处理完毕

    • 301 - 请求永久重定向，转移到其它URL

    • 302 - 请求临时重定向

    • 304 - 请求被重定向到客户端本地缓存

    • 400 - 客户端请求存在语法错误

    • 401 - 客户端请求没有经过授权

    • 403 - 客户端的请求被服务器拒绝，一般为客户端没有访问权限

    • 404 - 资源未找到，客户端请求的URL在服务端不存在

    • 500 - 服务端出现异常

  • 响应头

    • 响应头用于告知浏览器当前响应中的详细信息，浏览器通过获取响应头中的信息可以知道应该如何处理响应结果

      • 响应头中信息的格式为 key：value

    • Date

      • 响应的Date使用的是GMT时间格式，表示响应消息送达时间

    • Server

      • 服务器通过这个Server告诉浏览器服务器的类型

    • Vary

      • 客户端缓存机制或者是缓存服务器在做缓存操作的时候，会使用到 Vary 头，会读取响应头中的 Vary 的内容，进行一些缓存的判断

    • Content-Encoding

      • 文档的编码 (Encode) 方式

      • 用 gzip 压缩文档能够显著地减少 HTML 文档的响应时间

    • Content-Length

      • 表示内容长度

      • 只有当浏览器使用持久HTTP连接时才需要这个数据

    • Content-Type

      • 表示响应的文档属于什么MIME类型

      • MIME(Multipurpose Internet Mail Extensions)多用途互联网邮件扩展类型

      • 是设定某种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开

      • 多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式

      • MIME作用

        • HTTP协议所产生的响应中正文部分可以是任意格式的数据，那么如何保证接收方能看得懂发送方发送的正文数据呢？

        • HTTP协议采用MIME协议来规范正文的数据格式

        • 在服务端我们可以设置响应头中Content-Type的值来指定响应类型

  • 响应体

    • 响应体就是响应的消息体，如果是纯数据就是返回纯数据，如果请求的是HTML页面，那么返回的就是HTML代码，如果是JS就是JS代码，如此之类

JAVAWEB项目的开发和部署

• 认识JAVAWEB项目结构

  • 结构

    • -project 项目的根目录

    • -静态资源文件/jsp

    • -WEB-INF 受保护的资源目录

    • -lib jar包目录

    • -classes java字节码目录

    • -web.xml 项目的配置文件

    • -其他资源

  • 层级关系图如下

    • 结构图1

      

    • 结构图2

      

• 使用idea开发JAVAWEB项目

  • 选择 Java Enterprise

    • Project SDK选项 推荐 1.8

    • 如果没有SDK 可以通过后面的 NEW按钮选择自己的JDK安装路径即可 (注意选择的是bin的上一层)

    • Java EE version 推荐JAVA EE 8

    • Application Server 关联Tomcat容器, 如果没有, NEW按钮选择自己的Tomcat安装路径即可 (注意选择的是bin的上一层)

    • Additional Libraries and Freameworks 中 必须勾选 Web Applicaiton(4.0) 选项 同时注意 create web.xml 勾选上

      

  • 自定义项目名, 项目存放路径中注意不要出现 双 \ 和特殊符号中文空格等

    

  • JAVAEE项目结构如下

    • src目录用于定义Java源代码

    • web目录中用于存放一些页面资源 (如果上一步没有勾选Web Applicaiton(4.0)选项), 则不会出现web目录

    • External Libraries 中要出现 JDK1.8 和 Tomcat jsp-api 和 servlet-api 才可以正常编写 JAVAWEB 项目

      

• 使用idea运行项目

  • 在项目中开发一些资源

    • 可以按照下图准备一些项目资源

      

  • 启动项目之前, 先对项目进行配置

    • 点击 Edit Configurations 对项目进行启动之前的配置

      

    • 在 Deployment 中, Deployed at the server startup 里确认要部署的项目是不是我们要运行的项目

    • 在 Application context 中指定我们项目访问的路径名

    • idea 默认是 项目名 + “_war_exploded”, 在这里我们可以对项目的访问名进行修改, 如果不修改, 也OK, 可以一样使用

      

    • 在Server选项中, 勾选 Open browser 中的 After launch 选项, 这样 idea 在启动项目之后可以自动帮助我们打开浏览器并访问 URL 中的资源

    • On Update action :

      • 当代码改变的时候，需要IDEA为你做什么

      • 选项选为 Update classes and resources , 意义为:

        • 更新字节码和其他资源

    • On Frame deactivation :

      • 当失去焦点（比如你最小化了IDEA窗口），需要IDEA为你做什么

      • 选项选为 Update resources, 意义为

        • 更新其他资源

    • HTTP port 默认为 8080 不用修改

    • JMX port 默认为 1099 不用修改

    • 然后点击OK

      

    • 然后点击运行启动即可

      

    • 启动之后 用浏览器打开对应文件, 控制台网络一栏共发现4个有效请求, firstpage.html为我们请求的页面

    • myjs.js mycss.css logo.png 这三个请求和响应是因为 firstpage.html 中引入的 这三个文件, 浏览器自动发送请求获得这三个文件

    • favicon.ico 是在请求 Tomcat 中的"小狮子" 图片, 这里请求失败, 响应码是 404 无所谓, 暂时当它不存在即可, 后续会解释

  • 第一种 Idea部署JAVAWEB项目并运行的方式 (掌握)

    • 在Idea中默认的并不会把web项目真正的部署到Tomcat的webapps目录中，而是通过为每个web项目创建一个独立的Tomcat副本并在Tomcat副本中通过的Tomcat的Context组件完成项目的目录指定，在Context组件的docBase属性中会指定Idea对web项目编译后的目录out/artifacts/…

      

    • 默认部署方式

      • Idea 会在 C:\Users\Administrator\.IntelliJIdea2019.2\system\tomcat 中为每个 Web 项目创建一个独立的 Tomcat 副本

        

      • C:\Users\Administrator\.IntelliJIdea2019.2\system\tomcat\Tomcat_9_0_34_demo_4\conf\Catalina\localhost 目录中生成一个该项目的 xml 文件名称为："项目名.xml"

        

      • Idea 通过执行 Tomcat 的 catalina.bat 启动脚本启动 Tomcat，通过启动参数来指定启动 Tomcat 副本运行指定目录中的 web 项目

        

      • Idea 在启动 Tomcat 之前会先在操作系统中设置一些临时环境变量，这些变量会被 Tomcat 的启动脚本所读取

        

      • CATALINA_BASE

        • 是Tomcat副本的工作目录

      • CATALINA_HOME

        • 是Tomcat的安装目录

      • 在 Catalina.bat 启动脚本运行时，会先去判断脚本中的 CATALINA_HOME 以及 CATALINA_BASE 是否有默认值，如果没有则直接读取系统环境变量中的值作为他们的默认值

      • 由于 Idea 在启动 Tomcat 之前已经设置了临时环境变量，所以 tomcat 在启动后就会运行部署在 Tomcat 副本中的web项目

        

  • 第二种部署方式(了解)

    • 将 web 项目部署到 Tomcat 的 webapps 中

      • 点击项目结构选项

      • 指定输出 artifacts 的目录为 Tomcat 的 webapps 中的 demo 目录

        

      • 在 tomcat 的 webapps 中创建一个目录

        

      • 启动 Tomcat，查看 demo 目录中的内容