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目录是必须的。
2、通过命令行激活模块
激活Jetty的模块有两种办法。第一种办法是通过命令行激活：
上面的命令会在Jetty目录下创建logging.ini文件，干系的配置可以在此文件中查到。配置日志后，可以再次启动Jetty，并可以查看到日志模块是激活了的。
3、通过配置文件start.ini激活模块
第二种办法是通过配置文件start.ini激活模块
这种办法和前一种相似，且更常用。
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 相称于一个不雅观察者，打开一个 Server 端通道，把这个 server 通道注册到不雅观察者上并且指定监听的事宜。然后遍历这个不雅观察者不雅观察到事宜，取出感兴趣的事宜再处理。这里有个最核心的地方便是，我们不须要为每个被不雅观察者创建一个线程来监控它随时发生的事宜。而是把这些被不雅观察者都注册一个地方统一管理，然后由它把触发的事宜统一发送给感兴趣的程序模块。这里的核心是能够统一的管理每个被不雅观察者的事宜，以是我们就可以把做事端上每个建立的连接传送和接管数据作为一个事宜统一管理，这样就不必要每个连接须要一个线程来掩护了。
这里须要把稳的地方时，很多人认为监听 SelectionKey.OP_ACCEPT 事宜就已经是非壅塞办法了，实在 Jetty 仍旧是用一个线程来监听客户真个连接要求，当接管到要求后，把这个要求再注册到 Selector 上，然后才是非壅塞办法实行。这个地方还有一个随意马虎引起误解的地方是：认为 Jetty 以 NIO 办法事情只会有一个线程来处理所有的要求，乃至会认为不同用户会在做事端共享一个线程从而会导致基于 ThreadLocal 的程序会涌现问题，实在从 Jetty 的源码中能够创造，真正共享一个线程的处理只是在监听不同连接的数据传送事宜上，比如有多个连接已经建立，传统办法是当没有数据传输时，线程是壅塞的也便是一贯在等待下一个数据的到来，而 NIO 的处理办法是只有一个线程在等待所有连接的数据的到来，而当某个连接数据到来时 Jetty 会把它分配给这个连接对应的处理线程去处理，以是不同连接的处理线程仍旧是独立的。
Jetty 的 NIO 处理办法和 Tomcat 的险些一样，唯一不同的地方是在如何把监听到事宜分配给对应的连接的处理办法。从测试效果来看 Jetty 的 NIO 处理办法更加高效。下面是 Jetty 的 NIO 处理时序图：
五、与 Tomcat 的比较
Tomcat 和 Jetty 都是作为一个 Servlet 引擎运用的比较广泛，可以将它们比作为中国与美国的关系，虽然 Jetty 正常发展为一个精良的 Servlet 引擎，但是目前的 Tomcat 的地位仍旧难以撼动。比较较来看，它们都有各自的优点与缺陷。
Tomcat 经由永劫光的发展，它已经广泛的被市场接管和认可，相对 Jetty 来说 Tomcat 还是比较稳定和成熟，尤其在企业级运用方面，Tomcat 仍旧是第一选择。但是随着 Jetty 的发展，Jetty 的市场份额也在不断提高，至于缘故原由就要归功与 Jetty 的很多优点了，而这些优点也是由于 Jetty 在技能上的上风表示出来的。
架构比较
从架构上来说，显然 Jetty 比 Tomcat 更加大略，如果你对 Tomcat 的架构还不是很理解的话，建议你先看一下 《Tomcat系统架构与设计模式》这篇文章。
Jetty 的架构从前面的剖析可知，它的所有组件都是基于 Handler 来实现，当然它也支持 JMX。但是紧张的功能扩展都可以用 Handler 来实现。可以说 Jetty 是面向 Handler 的架构，就像 Spring 是面向 Bean 的架构，iBATIS 是面向 statement 一样，而 Tomcat 因此多级容器构建起来的，它们的架构设计一定都有一个“元神”，所有以这个“元神“构建的其它组件都是肉身。
从设计模板角度来看 Handler 的设计实际上便是一个任务链模式，接口类 HandlerCollection 可以帮助开拓者构建一个链，而另一个接口类 ScopeHandler 可以帮助你掌握这个链的访问顺序。其余一个用到的设计模板便是不雅观察者模式，用这个设计模式掌握了全体 Jetty 的生命周期，只要继续了 LifeCycle 接口，你的工具就可以交给 Jetty 来统一管理了。以是扩展 Jetty 非常大略，也很随意马虎让人理解，整体架构上的大略也带来了无比的好处，Jetty 可以很随意马虎被扩展和裁剪。
比较之下，Tomcat 要臃肿很多，Tomcat 的整体设计上很繁芜，前面说了 Tomcat 的核心是它的容器的设计，从 Server 到 Service 再到 engine 等 container 容器。作为一个运用做事器这样设计无口厚非，容器的分层设计也是为了更好的扩展，这是这种扩展的办法是将运用做事器的内部构造暴露给外部利用者，使得如果想扩展 Tomcat，开拓职员必须要首先理解 Tomcat 的整体设计构造，然后才能知道如何按照它的规范来做扩展。这样无形就增加了对 Tomcat 的学习本钱。不仅仅是容器，实际上 Tomcat 也有基于任务链的设计办法，像串联 Pipeline 的 Vavle 设计也是与 Jetty 的 Handler 类似的办法。要自己实现一个 Vavle 与写一个 Handler 的难度不相上下。表面上看，Tomcat 的功能要比 Jetty 强大，由于 Tomcat 已经帮你做了很多事情了，而 Jetty 只见告，你能怎么做，如何做，有你去实现。
打个比方，就像小孩子学数学，Tomcat 见告你 1+1=2，1+2=3，2+2=4 这个结果，然后你可以根据这个办法得出 1+1+2=4，你要打算其它数必须根据它给你的公式才能打算，而 Jetty 是见告你加减乘除的算法规则，然后你就可以根据这个规则自己做运算了。以是你一旦节制了 Jetty，Jetty 将变得非常强大。
性能比较
纯挚比较 Tomcat 与 Jetty 的性能意义不是很大，只能说在某种利用场景下，它表现的各有差异。由于它们面向的利用场景不尽相同。从架构上来看 Tomcat 在处理少数非常繁忙的连接上更有上风，也便是说连接的生命周期如果短的话，Tomcat 的总体性能更高。
而 Jetty 刚好相反，Jetty 可以同时处理大量连接而且可以永劫光保持这些连接。例如像一些 web 谈天运用非常适宜用 Jetty 做做事器，像淘宝的 web 旺旺便是用 Jetty 作为 Servlet 引擎。
其余由于 Jetty 的架构非常大略，作为做事器它可以按需加载组件，这样不须要的组件可以去掉，这样无形可以减少做事器本身的内存开销，处理一次要求也是可以减少产生的临时工具，这样性能也会提高。其余 Jetty 默认利用的是 NIO 技能在处理 I/O 要求上更占上风，Tomcat 默认利用的是 BIO，在处理静态资源时，Tomcat 的性能不如 Jetty。
特性比较
作为一个标准的 Servlet 引擎，它们都支持标准的 Servlet 规范，还有 Java EE 的规范也都支持，由于 Tomcat 的利用的更加广泛，它对这些支持的更加全面一些，有很多特性 Tomcat 都直接集成进来了。但是 Jetty 的应变更加快速，这一方面是由于 Jetty 的开拓社区更加生动，另一方面也是由于 Jetty 的修正更加大略，它只要把相应的组件更换就好了，而 Tomcat 的整体构造上要繁芜很多，修正功能比较缓慢。以是 Tomcat 对最新的 Servlet 规范的支持总是要比人们预期的要晚。
