Jetty8.0.4的ClassLoader的体系结构

Bootstrap ClassLoader/启动类加载器 

主要负责jdk_home/lib目录下的核心 api 或 -Xbootclasspath 选项指定的jar包装入工作。

Extension ClassLoader/扩展类加载器 

主要负责jdk_home/lib/ext目录下的jar包或 -Djava.ext.dirs 指定目录下的jar包装入工作。

System ClassLoader/系统类加载器 

主要负责java -classpath/-Djava.class.path所指的目录下的类与jar包装入工作。

User Custom ClassLoader/用户自定义类加载器(java.lang.ClassLoader的子类) 

在程序运行期间, 通过java.lang.ClassLoader的子类动态加载class文件, 体现java动态实时类装入特性。

自User Custom向Bootstrap的检查类是否已经加载；自Bootstrap向User Custom的尝试加载类

     JVM在加载类时默认采用的是双亲委派机制。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父类加载器，依次递归，如果父类加载器可以完成类加载任务，就成功返回；只有父类加载器无法完成此加载任务时，才自己去加载。关于虚拟机默认的双亲委派机制，我们可以从系统类加载器和标准扩展类加载器为例作简单分析。

2.1：Jetty的classloader架构

    web容器的classloader比普通java应用略为复杂。

    每个web上下文（web应用和war文件）的普通配置是有自身的classloader，系统的classloader是它的父类。这是普通的java classloader的层次，但是servlet规范提出了负责的层次要求：

1. 在WEB-INF/lib和WEB-INF/classes中包含的类的加载优先级高于父classloader中的类。这和普通的java2的classloader加载动作相反。

2. 像java.lang.String这样的系统类不会被WEB-INF/lib或者WEB-INF/classes中的类替代。不幸的是，servlet规范并没有清楚的规定哪些类是系统类，也没有清楚的指出javax类应该作为系统类

3. Server实现类应该对web应用和其他classloader不可见。不幸的是，servelt规范并没有规定什么是server class ，也没有清楚的指出像xerces parser 这样的common libraries应该作为实现类。

2.2：如何配置classloading

    jetty提供配置来控制以上三个选项。org.mortbay.jetty.webapp.WebAppContext.setParentLoaderPriority(boolean) 来控制所有类是否双亲委派的方式加载，这个配置解决了web应用加载的类在web应用和系统classpath同时存在的情况。

    org.mortbay.jetty.webapp.WebAppContext.setSystemClasses(String[])和org.mortbay.jetty.webapp.WebAppContext.setServerClasses(String[])用来控制那些能够被web应用看到或者覆写的类。

* SystemClasses 不能被webapp 上下文 classloaders覆写. 默认的是： 

* ServerClasses (on the container classpath) 不能被webapp 上下文 classloaders看到但是可以被webapp覆写. 默认配置是: 

    [ 这段不知道如何翻译]Absolute classname can be passed, names ending with . are treated as packages names and names starting with – are treated as negative matches and must be listed before any enclosing packages.

      具体的类名可以不写，名称以.结尾代表是package名称，名称以"-"开头被认为是负面符号， and must be listed before any enclosing packages.

2.3：给jetty添加额外的classpaths

    在启动时，jetty会自动加载$jetty.home/lib下所有的jars，随之加载在start.jar中的文件start.config中明确配置的子目录（例如：$jetty.home/lib/management，$jetty.home/lib/naming/ 等）中的jars。所以，给jetty添加拓展的jars，需要在$jetty.home/lib/ext中创建一个任何你想的深度的文件层次。当然，你可以在自己创建start.config来定义默认加载动作来代替系统动作，否则，你需要使用以下方法：  

2.4：使用 jetty.class.path 系统属性

    如果你想添加一个类目录或者jar到jetty，但是你不想把东西放到$jetty.home/lib/ext/中，或者你不想自己创建start.config文件，你可以简单的使用系统属性-Djetty.class.path，示例：

    java -Djetty.class.path="../my/classes:../my/jars/special.jar:../my/jars/other.jar" -jar start.jar

2.5：在WebAppContext中使用extraClasspath()方法

    如果你因为某种原因不想把jars或者classes放到 $jetty.home/lib ,同事也不想放到WEB-INF/lib 或者 WEB-INF/classes中，你可以把它添加到 $JETTY_HOME/contexts/mycontext.xml 文件中

    <Configure class="org.mortbay.jetty.webapp.WebAppContext">

      …

      <Set name="extraClasspath">../my/classes:../my/jars/special.jar:../my/jars/other.jar</Set>

      …

2.6：使用惯用的WebAppClassLoader

   最后，没有其他替代方案满足你的需求，你可以在自己的webapp中定制classloader，建议你的classloader是    org.mortbay.jetty.webapp.WebAppClassLoader的子类，但这不是必须的。你可以像如下的方式配置自己的webapp的classloader：

     MyCleverClassLoader myCleverClassLoader = new MyCleverClassLoader();

     …

     WebAppContext webapp = new WebAppContext();

     …

     webapp.setClassLoader(myCleverClassLoader);

• What is Jetty's classloading architecture?
• 如何设置children/parent frist
• Web Application Deployer
• Inside Class Loaders