一、Jetty目次分解

二、根基设置

1、修改Jetty的端口

Jetty默认利用8080端口，要让它利用其他端口（如7070），那么编辑start.d（Wondows系统是start.ini文件），找到jetty.http.port行，修改为：

## Connector port to listen on
jetty.http.port=7070

生存并退出，再重启Jetty。

2、修改webapps目次

Jetty下的webapps是默认的Web项目标陈设目次，假如想修改此目次，可修改start.d设置文件（start.ini），移除以下行的注释标记“#”

# jetty.deploy.monitoredDir=webapps

并把内容修改到你指定的目次。生存并退出，再重启Jetty。

三、Jetty的模块化架构

Jetty运行于模块化的架构之上，这意味着Jetty的成果是以模块的方法运行的，好比HTTP、HTTPS、SSL、日志logging、JMX、JNDI、WebSocket等模块。常用的模块如HTTP、JSP和WebSocket模块都是默认就激活的，而其他如HTTPS、JMX等模块则需要手动激活。

1、单个模块的分解

Jetty的modules子目次列出了所有的模块，这些模块是扩展名为.mod的文件，它声明白要被激活的JAR文件（在Jetty的lib子目次下）和XML设置文件（在Jetty的etc子目次下），软件开发，以及其他要作为模块被激活的资源。好比，可以查察modules子目次的logging.mod文件的内容，可以看到，它声明白设置文件是etc/jetty-logging.xml，所需的JAR包在lib/logging处，别的logs目次是必需的。

[ xml]
etc/jetty-logging.xml
[files]
logs/
[lib]
lib/logging/**.jar
resources/

2、通过呼吁行激活模块

激活Jetty的模块有两种方法。第一种方法是通过呼吁行激活：

java -jar start.jar --add-to-startd=logging

上面的呼吁会在Jetty目次下建设logging.ini文件，相关的设置可以在此文件中查到。设置日志后，可以再次启动Jetty，并可以查察到日志模块是激活了的。

3、通过设置文件start.ini激活模块

第二种方法是通过设置文件start.ini激活模块

--module=logging

这种方法和前一种相似，且更常用。

4、设置模块

正如上面提到的，mod文件声明白相关的XML设置文件，在Jetty的etc子目次下，可以通过这些设置文件来设置模块。好比日志模块声明白相关的设置文件是jetty-logging.xml，可以通过修改此设置文件来调解日志。

四、接管请求

Jetty 作为一个独立的 Servlet 引擎可以独立提供 Web 处事，可是它也可以与其他 Web 应用处事器集成，所以它可以提供基于两种协议事情，一个是 HTTP，一个是 AJP 协议。假如将 Jetty 集成到 Jboss 可能 Apache，那么就可以让 Jetty 基于 AJP 模式事情。下面别离先容 Jetty 如何基于这两种协议事情，软件开发，而且它们如何成立毗连和接管请求的。

1、基于HTTP

2、基于AJP

3、NIO处理惩罚方法

Jetty 成立客户端毗连处处理惩罚客户端的毗连也支持 NIO 的处理惩罚方法，个中 Jetty 的默认 connector 就是 NIO 方法。

关于 NIO 的事情道理可以参考 developerworks 上关于 NIO 的文章，凡是 NIO 的事情原型如下：

Selector selector = Selector.open(); 
ServerSocketChannel ssc = ServerSocketChannel.open(); 
ssc.configureBlocking( false ); 
SelectionKey key = ssc.register( selector, SelectionKey.OP_ACCEPT ); 
ServerSocketChannel ss = (ServerSocketChannel)key.channel(); 
SocketChannel sc = ss.accept(); 
sc.configureBlocking( false );
SelectionKey newKey = sc.register( selector, SelectionKey.OP_READ ); 
Set selectedKeys = selector.selectedKeys();

建设一个 Selector 相当于一个调查者，打开一个 Server 端通道，把这个 server 通道注册到调查者上而且指定监听的事件。然后遍历这个调查者调查到事件，取出感乐趣的事件再处理惩罚。这里有个最焦点的处所就是，我们不需要为每个被调查者建设一个线程来监控它随时产生的事件。而是把这些被调查者都注册一个处所统一打点，然后由它把触发的事件统一发送给感乐趣的措施模块。这里的焦点是可以或许统一的打点每个被调查者的事件，所以我们就可以把处事端上每个成立的毗连传送和接管数据作为一个事件统一打点，这样就不须要每个毗连需要一个线程来维护了。

这里需要留意的处所时，许多人认为监听 SelectionKey.OP_ACCEPT 事件就已经长短阻塞方法了，其实 Jetty 仍然是用一个线程来监听客户端的毗连请求，当接管到请求后，把这个请求再注册到 Selector 上，然后才长短阻塞方法执行。这个处所尚有一个容易引起误解的处所是：认为 Jetty 以 NIO 方法事情只会有一个线程来处理惩罚所有的请求，甚至会认为差异用户会在处事端共享一个线程从而会导致基于 ThreadLocal 的措施会呈现问题，其实从 Jetty 的源码中可以或许发明，真正共享一个线程的处理惩罚只是在监听差异毗连的数据传送事件上，好比有多个毗连已经成立，传统方法是当没有数据传输时，线程是阻塞的也就是一直在期待下一个数据的到来，软件开发，而 NIO 的处理惩罚方法是只有一个线程在期待所有毗连的数据的到来，而当某个毗连数据到来时 Jetty 会把它分派给这个毗连对应的处理惩罚线程去处理惩罚，所以差异毗连的处理惩罚线程仍然是独立的。