Jetty 是一个开源的servlet容器,它为基于Java的web内容,例如JSP和servlet提供运行环境。Jetty是使用Java语言编写的,它的 API以一组JAR包的形式发布。开发人员可以将Jetty容器实例化成一个对象,可以迅速为一些独立运行(stand-alone)的Java应用提供网络和web连接。由于网上关于Jetty的中文资料比较少,本文将其官方文档翻译成中文供初学者学习。英文原文可以参考:http://wiki.eclipse.org/Jetty/Reference/Jetty_Architecture
鸟瞰Jetty
Jetty最上层的体系结构
Jetty Server是处于一组Connectors(接收Http连接)及一组Handler(从连接进行请求并产生响应)并采用线程池进行工作的一个工具。
Jetty请求/响应接口继承自Servlet API,如果相应的Handlers被配置上的话,应该能够支持Servlet API的所具备的所有特征。例如,请求中的会话API是不可用的除非请求经过SessionHandler的处理,且Servlet本身的一些理念也通过ServletHandler实现了。如果Servlet本身是不必要的,就不需要使用Servlet的请求/响应API了。因此,你可以完全采用Connector及Handlers来构建一个Jetty服务器,而不用借助于Servlets.
配置Jetty的任务就是要构建一系列的connectors和handlers及提供个人的一些配置。由于Jetty的组件都是一些POJOs,你可以通过以下几种技术方式来组装和配置这些组件:
l 通过代码的方式,可以参考Jetty 7 Latest Source XRef
l 采用Jetty XML方式
l 使用Jetty本身的WebApp and Context Deployers.
设计模式
Jetty本身的实现采用了很多通用标准的设计模式,许多抽象的概念如Connectors、Handlers及Buffers均采用接口的方式来实现,对接口一般化的处理则采用了抽象类的方式进行实现如AbstractConnector, AbstractHandler and AbstractBuffer.
JSR77草案中提倡使用的生命周期管理也在Jetty组件中以LifeCycle接口及AbastraceLifeCycle方式来体现,并作为了其基础组件。
Jetty提供基于字符串、字节数组及NIO缓冲方式的自身IO缓存。可以提供更好的可扩展性、简化NIO层的复杂性及支持更高级的特性。
Connectors
Connectors表示一个协议链,用来接受连接,解析请求并产生响应。基于不同的协议、调度模型及IO形成不同类型的Connectors,最常用的有以下几种:
l SocketConnector:用于忙链接请求不多或者没有NIO的方式
l BlockingChannelConnector:用于有NIO的方式且忙链接请求较多的方式
l SelectChannelConnector:用于空闲链接较多或者异步处理 AJAX请求
l SslSocketConnector:没有NIO的SSL方式
l SslSelectChannelConnector:非阻塞的NIO支持的SSL方式
l AJPConnector:对apache mod_jk及mod_proxy_ajp的AJP协议的支持
Handlers
![]()
Handler是用于处理接收请求的组件,handler的核心API是handle方法:
public void handle(String target, Request baseRequest, HttpServletRequest request, HttpServletResponse response)
throws IOException, ServletException
各个参数的含义:
l target–请求的目标,为URI或者是一个名称;
l baseRequest–原始的未经包装的请求对象;
l request–请求对象或者被包装过的请求。如果有需要可以通过HttpConnection.getCurrentConnection()方法来访问该对象;
l response–响应对象或者是被包装过的请求,如果有需要可以通过HttpConnection.getCurrentConnection()方法来访问该对象;
实现了该方法可以处理请求,将请求传递至另外一个handler(或servlet)或者修改、重新包装该请求并进行传递。在此主要介绍三种类型的handlers:
l 协调整合型Handlers-这种类型的Handlers能够将请求路由至另外一个Handlers(如HandlerCollection,ContextHandlerCollection)
l 过滤型Handlers-这种类型的Handlers用于强化或处理请求,并传至另一个Handlers(如HandlerWrapper,ContextHandler,SessionHandler)
l 生成型Handlers-这种类型的Handlers用于产生所需的内容(如ResourceHandler和ServletHandler)
内嵌的Handlers及序列性的Handlers
你可以组装不同的Handlers用于处理不同的请求,如嵌套型、顺序型或者二者的结合。
l 序列型Handlers执行时,不必依赖于下一次的调用,而且不必依赖于handlers的顺序。它在处理请求并产生响应时不需与其它Handlers的交互,这种的主要类是HandlersCollection.
l 内嵌型Handlers也被称为before/invokeNext/after模式,它的主要代表类是Handler Wrapper.内嵌型Handlers要比序列型的更具通用性。
请参考Writing a Jetty Handler如何写一个具体的Handler。
Servlets
ServletHandler是一个处理器,用于将请求传递至配置好的Filters,再通过URI映射好的Servlet而产生具体内容。
ServletHandler一般是被部署在servletContext中,因为它可以提供便捷的将URIs与Servlets进行映射的方法。
Filters和Servlets也可以使用请求转发器将请求路由至另外一个Context或当前Context中的其它的Servlet。
Context
Contexts是将一组特定URI路径或虚拟主机下的Handlers组织在一起的处理器,一个典型的Context包括以下几个方面:
1、一个上下文路径用于定义该请求能够被context处理;(如/myapp)
2、对于静态资源访问的基本路径(如docroot)
3、用于获取需要装载基本类的地址(如docroot/WEB-INF/classes)
4、虚拟主机名
Contexts有以下几种实现:
l ContextHandler
l ServletHandler
l WebApplication Context
Web应用的上下文是集安全、会话及Servlets于一身的处理器,可以通过web.xml进行配置。
Web Applications
WebAppContext继承自servletContext,可以支持标准的Web应用的框架,而且可以通过web应用的WEB-INF中的web.xml进行会话、安全、监听器、过滤器、Servlets或JSP配置。
本质上WebAppContext就是一个方便性的类,采用构造、配置其它Handler的方式来完成一个Web应用的标准配置。
配置可以采用插件式的Configuration类或者WebXmlConfiguration来完成。