前面的文章基本上对整个jetty的设计实现有了大概的分析, 这篇文章从源码的角度上来分析一下jetty的配置文件,因为以前在读nginx的时候,比较遗憾读完源码就完事了,没有在那基础上好好的分析掌握一下nginx的配置和使用...所以现在争取每一次源码读的差不多的时候都好好的来看看使用,争取在了解一个东西的实现的基础上也掌握它的用法...
jetty的启动方式后很多中，可以采用嵌入式的方法，也就是在自己的代码中创建jetty的组件对象，然后启动，还有一种启动方法就是服务器启动了，也就是我们常用的方法：在jetty的根目录中敲命令行：java -jar start.jar ，当然这也是用的最多的启动方法了。。。。
这种启动方法真正会调用org.mortbay.xml.XmlConfiguration来作为启动类，而这个它默认又会读取/etc/jetty.xml文件，这也是我们比较熟悉的jetty的配置文件。。。那么接下来就来看看这个文件中定义的主要内容（jetty的配置文件感觉很像是用xml定义了一种命令脚本，在载入的时候就自动根据它的说明来创建相应的对象）：
<Configure id="Server" class="org.mortbay.jetty.Server">
上述是整个配置文件的root元素，读到它的时候会创建一个server对象，当然这个server对象的创建采用的是默认构造函数，因而可以理解为它是一个空的server。。。那么接下来就是为其填充各种各样的对象了。。。
接下来继续看配置：
<Set name="ThreadPool">
<New class="org.mortbay.thread.QueuedThreadPool">
<Set name="minThreads">10</Set>
<Set name="maxThreads">200</Set>
<Set name="lowThreads">20</Set>
<Set name="SpawnOrShrinkAt">2</Set>
</New>
<!-- Optional Java 5 bounded threadpool with job queue
<New class="org.mortbay.thread.concurrent.ThreadPool">
<Set name="corePoolSize">50</Set>
<Set name="maximumPoolSize">50</Set>
</New>
-->
</Set>
这段配置是用于为当前的server设置线程池，可以看看这个xml元素的名字叫Set，其实也就是调用server的set方法，后面有一个name属性的值为ThreadPool，那么这里就可以知道这个元素其实是要调用server对象的setThreadPool方法，也就是如下方法：
//为当前的server设置运行时候的线程池
public void setThreadPool(ThreadPool threadPool) {
_container.update(this,_threadPool,threadPool, "threadpool",true);
_threadPool = threadPool;
}
接着在这个set命令后看到了一个New元素，应该猜也能猜出来这里是创建一个对象了吧，它用于创建一个org.mortbay.thread.QueuedThreadPool的对象，然后下面又接着调用了set方法，为这个threadPool对象设置了许多参数，例如最小线程数量，最大线程数量，SpawnOrShrinkAt参数表示最多有多少task可以暂时放到队列里待会执行。。。
那么上面的一段配置代码要干的事情就已经很清楚了吧，创建线程池对象，然后设置它的一些基本属性，然后调用server的setThreadPool方法将其设置为当前server的线程池。。。
配置文件看到这里，就已经清楚了整个jetty的配置文件的脉络了，用一用类似脚本命令的xml配置来完成了整个server对象的创建。。
那么接下来来看配置文件：
<Call name="addConnector">
<Arg>
<New class="org.mortbay.jetty.nio.SelectChannelConnector">
<Set name="host"><SystemProperty name="jetty.host" /></Set>
<Set name="port"><SystemProperty name="jetty.port" default="8080"/></Set>
<Set name="maxIdleTime">30000</Set>
<Set name="Acceptors">2</Set>
<Set name="statsOn">false</Set>
<Set name="confidentialPort">8443</Set>
<Set name="lowResourcesConnections">5000</Set>
<Set name="lowResourcesMaxIdleTime">5000</Set>
</New>
</Arg>
</Call>
<!-- Use this connector if NIO is not available.
<Call name="addConnector">
<Arg>
<New class="org.mortbay.jetty.bio.SocketConnector">
<Set name="port">8081</Set>
<Set name="maxIdleTime">50000</Set>
<Set name="lowResourceMaxIdleTime">1500</Set>
</New>
</Arg>
</Call>
-->
上述配置文件跟上面的Set不太一样，而是采用的call，不过说白了就是调用addConnector方法，为当前的server对象添加一个connector，从上面也可以看到默认情况下创建的还是SelectChannelConnector，也就是所谓的nioConnector，毕竟它的性能相对于bio的SocketConnector要更好。。。
这里我们来解析一下下面为connector设置的参数吧：
host和port参数就不用说了吧，maxIdleTime是一个连接对大的空闲时间，jetty将会为连接设置超时，如果空闲时间超过了这么多，那么会将这个连接关闭。。。。
Acceptors这个参数可能会比较误导人，比如上面设置为2，看起来像是要创建两个ServerSocketChannel，其实不然，这里其实创建了两个SelectSet，而每一个SelectSet都有一个selector，也就是这里创建了两个selector，并且会在线程池中独占两个线程来专门执行select操作。。。。但是一个connector本身只有一个ServerSocketConnector。。。这里只不过是多建立了selector，毕竟多建立selector可以多维护一些连接嘛。。在连接数量比较多的时候，特别是大量短连接的时候，可以适当的创建多一些selector。。。。避免同一个selector会维护太多连接，会对性能造成影响。。。。
好了，接下来继续来读配置文件。。。
<Set name="handler">
<New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection">
<Set name="handlers">
<Array type="org.mortbay.jetty.Handler">
<Item>
<New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/>
</Item>
<Item>
<New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/>
</Item>
<Item>
<New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/>
</Item>
</Array>
</Set>
</New>
</Set>
这段配置应该也还算是比较容易理解吧，调用了server的setHandler方法为当前的server设置handler属性，折后这里的创建了的handler其实是org.mortbay.jetty.handler.HandlerCollection，接着在创建了3个handler，将其保存在这个handlerCollection当中，分别是
（1）我们最熟悉的ContextHandlerCollection
（2）DefaultHandler，用于处理一些前面没有处理的http请求，多半都是一些错误
（3）log的handler。。。
我们知道当一个http请求收到之后，会调用server来处理这个请求，但其实server对象也是调用内部的handler来处理这个http请求，那么这里来看看HandlerCollection是怎么处理的吧，也就是它的handle方法：
//处理http请求，这个方法会被覆盖的
//这里的处理是比较的简单的，说白了就是遍历所有的handler，依次调用他们的handle方法来处理http请求。。每一个handler都要处理
public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch)
throws IOException, ServletException {
if (_handlers!=null && isStarted())
{
MultiException mex=null;
//遍历当前的所有handler，用他们都来处理一下这个请求
for (int i=0;i<_handlers.length;i++) {
try{
_handlers[i].handle(target,request, response, dispatch);
}
catch(IOException e)
{
throw e;
}
catch(RuntimeException e)
{
throw e;
}
catch(Exception e)
{
if (mex==null)
mex=new MultiException();
mex.add(e);
}
}
if (mex!=null)
{
if (mex.size()==1)
throw new ServletException(mex.getThrowable(0));
else
throw new ServletException(mex);
}
}
}
代码很简单吧，就是遍历当前保存的所有的handle，一次调用他们的handle方法。。。也就是说每一次http请求接收到以后，都会调用上面3个handler的handle方法来依次处理。。。
其实这里的handler配置会对整个jetty服务器的性能产生比较大的影响。。。
如果我们只是部署一个应用在jetty的话，那么我们可以将WebAppContext前面的ContextHandlerCollection去掉，这样就可以少了一层path的匹配。。。
最精简的情况下我们可以这么高配置：
<Set name="handler">
<New id="Handlers" class="org.mortbay.jetty.webapp.WebAppContext">
<Set name="extractWAR">true</Set>
<Set name="contextPath">/</Set>
<Set name="war">file:/F:/360云盘/jettywork/jetty/webapps/manager.war</Set>
<Set name="parentLoaderPriority">true</Set>
</New>
</Set>
将server的handler属性直接设置为一个WebAppContext对象，同时设置这context的path，以及app的路径什么的。。。这样子性能应该是最好的了。。毕竟省去了很多其余的处理过程。。
好了，到这里整个jetty的配置文件最重要的一些内容就算是差不多了。。。接下来还有一些其他的配置，不过基本上都能够很容易搞懂的。。。
总的来说整个jetty的配置还算是比较简单的，现在感觉到如果真的要用好一个东西，对其的实现由一定的了解是很有帮助的。。。