Jetty 类加载器体系结构
转载请注明出处 http://blog.csdn.net/lovingprince
-------------------------------------------------------------------------------------------------------------------------------
一般类加载器分三类：引导类加载器、扩展类加载器、系统类加载器
请见这里的分析 http://blog.csdn.net/lovingprince/archive/2009/07/02/4317069.aspx
请记住类加载器的几个特点：
1、 双亲委托
2、 全局负责
Jetty 的 jetty_home/lib 下包含了 jetty 服务器运行所需要的 jar 包 , 而 jetty_home/lib/ext 下包含的服务器使用的一些扩展包，运行在 webapps 下特定应用的 WEB-INF/lib 和 WEB-INF/classess 是各个应用自己的使用的类，特定应用自己的类当然不能与其他应用分享。
-
系统类加载器
Jetty 启动方式 java -jar start.jar （内部实际执行 org.eclipse.jetty.start.Main 类）
那么这个 org.eclipse.jetty.start.M ain 是由哪个加载器加载的呢？很明显，这里没有其他的自定义类加载器，只有系统类加载器能够做这个工作。
-
系统自定义加载器
Jetty 自定义了一个的 Loader 类加载器，以系统类加载器做为父加载器，完成对 start.config 配置文件的读取 ( 注意，这里只是读取，并没有实例化里面的类，只是使用类加载器来确定里面的 class 是否可用 ) 。
接下来， Jetty 有两种运行方式，一种进程内运行 ( 通过反射执行 MainClass), 一种是进程外执行 ( 通过 Runtime.getRuntime().exec()), 进程外执行时由于线程上下文不能进程之间传递，因此相当于我们直接使用如下方式直接执行：
-cp 后是 classpath ， org.eclipse.jetty.xml.XmlConfiguration 是 MainClass, 大家可以猜猜 org.eclipse.jetty.xml.XmlConfiguration 是哪个 ClassLoader 加载的？同样加载他的只能依靠系统加载器来完成。同时 classpath 中的 lib/ 中的类都由系统类加载器完成。
而进程内启动则不同，通过自定义的 Loader 加载器完成对 MainClass 的加载，通过反射方式运行 MainClass 的 main() 方法，后续所有的 lib/ 中的类都以该自定义 Loader 做为加载器。
-
WebApp 自定义类加载器
上面我们说了 jetty 服务器 lib/ 中的 jar 都是系统自定义加载器加载的，如果让这个系统自定义加载器来加载 WEB-INF/lib 、 WEB-INF/classes 下的类，那么在这个服务器下 WEB 应用之间可能就会相互影响了，并且服务器绝大多数时候并不需要应用 /WEB-INF/lib 下的类，于是 WebApp 自定义类加载器应运而生， Jetty 中默认叫 WebAppClassLoader 。
他是以当前线程上下文的 ClassLoader 为父 classloader, 如果上下文没有设定 classLoader ，俺么就使用加载 WebAppClassLoader 的加载器，如果还是没有，则采用系统类加载器。很明显，默认情况下，如果采用进程内运行，那么这个 parent 就是 Loader( 系统自定义类加载器 ) ，如果是进程外， parent 就是系统类加载器。
WebAppClassLoader 可以设定是否由 parent 优先加载 lib/ 、 classes 下的类。
Jetty 的 ClassLoader 体系结构可以使用下图来简单表示：
