Jetty架构

概览

Jetty Server是一个Connector集合和一个Handler集合间的管道，Connector用于接收HTTP连接，Handler服务来自连接的请求并作出响应，Jetty Server使用来自一个线程池的线程来处理这些工作。

当Jetty请求/响应源自Servlet API时，Servelet API的完整特征只有你配置适当的handler才是可用的。例如，在请求中的session API只有当请求被传递给一个Session Handler时才被激活。如果servlet不被要求，只有很少的开销用于servlet请求/响应API。因此你能构建一个仅用connector和handler的Jetty Server，不用servlet。
配置Jetty的工作是构建一个connector和handler的网络，并提供他们各自的配置。由于Jetty这句践是简单的POJO（Plain Old Java Object），你能完成通过各种方法完成组件的集成和配置：
 1）代码；
 2）使用Jetty XML；
 3）使用依赖注入框架：Spring或者XBean；
 4）使用Jetty WebApp和Context Deployer。

模式

Jetty的实现使用了一些标准模式。最抽象的概念例如Connector、Handler和Buffer都通过接口定义。对这些接口的通常处理是提供一个抽象的实现，例如：AbstractConnector、AbstractHandler和AbstractBuffer。

激发大部分Jetty组件的生命周期的JSR77被表示为LifeCycle接口和它的实现AbstractLifeCycle，作为许多Jetty组件的基类。
Jetty在String之上提供它自己的IO缓存抽象。这为Jetty提供更大的便捷，同时也隐藏了一些NIO层和他的高级特征的复杂性。

Connector

这个图有点过时，作为连接接口已经抽取出HttpConnector，允许AJP协议支持。
连接器代表协议处理器，负责接收连接、解析请求和产生响应。不同类型的连接器的使用是基于协议、调度模式和使用的IO API：

 1）SocketConnector：为少量忙连接或者当NIO不可用时
 2）BlockingChannelConnector：当NIO可用时为少量忙连接
 3）SelectChannelConnector：为一些大部分空闲的连接或者Ajax请求的异步处理
 4）SslSocketConnector：没有NIO的SSL
 5）SslSelectChannelConnector：非阻塞NIO支持的SSL
 6）AJPConnector：AJP协议支持，为来自apache mod_jk或者mod_proxy_ajp的连接

Handler

Handler是处理收到请求的组件。Handler的核心API是handle方法：

public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response) throws IOException, ServletException

参数：
 1）target：请求的目标，一个URI或者一个name；
 2）baseRequest：原始的未封装的请求对象；
 3）request：Request对象或者请求的包装者。如有必要，你能用HttpConnection.getCurrentConnection()方法得到Request对象；
 4）response：Response对象或者请求的包装者。如有必要，你能用HttpConnection.getCurrentConnection()方法得到Response对象。
这个方法的实现能处理请求，传递请求到另一个handler（或者servlet）或者他可以修改和/或包装请求，然后传递它。存在3中类型的Handler：
 1）协调Handler：传递请求到其它handler的handler（HandlerCollection、ContextHandlerCollection）
 2）过滤Handler：增强一个请求并传递它到其它Handler的Handler（HandlerWrapper、ContextHandler、SessionHandler）
 3）生产Handler：产生内容的Handler（ResourceHandler 、ServletHandler）

嵌套Handler和Handler顺序调用

你能组合多个handler处理一个请求的不同方面，通过嵌套他们、依次调用它们、或者两种方式的融合。

顺序调用Handler履行的行为不依赖next调用，也不依赖handler顺序。它们处理一个请求并产生一个响应，不和其它handler交互。为这个模型，主要的类是Handler Collection。
嵌套handler根据before/invokeNext/after模式来调用。为嵌套handler，主要的类是Handler Wrapper。嵌套handler比顺序调用更为通用。
更多信息请看”写自定义的handlers“。

Servlet Handler

ServletHandler是一个Handler，通过传递请求到任何配置的filter，然后通过URI模式匹配到一个Servlet，最后生成结果。

ServletHandler通常被部署在一个servlet Context的范围内，ContextHandler为映射URI到Servlet提供了便利的方法。
Filter和Servlet也能使用一个RequestDispatcher重定向一个请求到另一个上下文或者另一个在当前上下文中的servlet。

Context

Context是handler，用于将特定URI上下文路径或者一个虚拟主机下的其它handler组织在一起。通常一个context具有：
 1）一个上下文路径，定义哪个请求被上下文处理（例如：/myapp）
 2）静态内容的资源路径（一个文档根路径）
 3）一个类加载器，获取指定到上下文的类（通常为docroot/WEB-INF/classes）
 4）虚拟主机名
Context实现包括：
 1）ContextHandler
 2）Servlet Context
 3）Web Application Context
一个Web Application Context在一个单元融合多个handler，包括安全、连接和servlet，你能使用web.xml配置。

Web应用

WebApp上下文是servlet上下文的派生，支持web应用的标准化布局和session、security、listener、filter、servlet和JSP的配置，配置使用web.xml文件，通常在web应用的WEB-INF 目录下。

本质上WebAppContext是一个便利的类，帮助其它handler的构造和配置以达到一个标准web应用配置。配置实际上被Configuration类（其中最主要的是WebXmlConfiguration）的可插拔实现完成。