《How Tomcat Works》翻译(7) 之 Tomcat类加载器续集

一、The Loader接口

 

在web应用程序中加载servlet和其他类时有一些规则。比如：在应用程序中加载一个servlet，被限制在the WEB-INF/classes目录以及子目录下。然而，servlet不会访问其他类，即使这些类包含运行在Tomcat中的JVM的CLASSPATH下。同时一个servlet限制了访问类库的目录(WEB-INF/lib目录)。

 

一个Tomcat Loader代表了一个web应用的loader而不是一个class loader. 一个loader一定要实现the org.apache.catalina.Loader接口。一个Loader实现一个自己定制的类加载器是由org.apache.catalina.loader.WebappClassLoader类代表的。只要你使用Loader接口中的getClassLoader方法你就能获得一个web Loader里面的类加载器。

 

 该接口还有其他方法就是定义了repositories集合。一个web应用中的WEB-INF/classes和WEB-INF/lib目录将会被添加到respositories。The Loader接口中的addRepository方法是添加一个repository, 而findRepositories方法将会返回所有的repositories（以数组形式返回）。

 

 一个Tomcat loader实现通常与一个context相关联，the Loader接口中的getContainer和setContainer方法就是为了与context 相关联。一个loader也支持重新部署（当一个或者多个类在context容器里修改了）。这种方式，一个servlet程序设计者重新编译了servlet类或者说一个受支持的类和新的类将会被重新加载(这种环境是不需要Tomcat重新启动的)。为了达到重新加载的目的，The Loader接口也有一个modified方法。实现一个loader里面，the modified方法一定要返回true因为一个或者多个类在制定的目录下已经发生修改了，这样重新加载时必须的。然而一个实现Loader本身不会加载,相反它会调用Context接口的reloade方法。Loader接口还有两个方法：setReloadable, getReloaderable，目的是决定Loader是否支持自动加载（热部署）。Context的一个标准的实现(the org.apache.catalina.core.StandardContext类将会在第十二章讨论)，默认情况下，重新加载时不允许的。因此为了使一个context容器支持重新加载，你需要在Tomcat目录下的server.xml文件中添加一个Context元素，例如下面：

 

        <Context path="/myApp" docBase="myApp" debug="0" reloadable="true"/>

 

同时，一个Loader实现需要告知是否需要委派给父亲类加载器。对于这样的目的，The Loader接口有提供了两个方法：getDelegate和setDelegate。

 

下面是Loader接口的代码：

package org.apache.catalina;


import java.beans.PropertyChangeListener;
public interface Loader {
    public ClassLoader getClassLoader();
    public Container getContainer();
    public void setContainer(Container container);
    public DefaultContext getDefaultContext();
    public void setDefaultContext(DefaultContext defaultContext);
    public boolean getDelegate();
    public void setDelegate(boolean delegate);
    public String getInfo();
    public boolean getReloadable();
    public void setReloadable(boolean reloadable);

    public void addPropertyChangeListener(PropertyChangeListener listener);
    public void addRepository(String repository);   
    public String[] findRepositories();
    public boolean modified();
    public void removePropertyChangeListener(PropertyChangeListener listener);


}

 Catalina提供了the org.apache.catalina.loader.WebappLoader作为实现the Loader接口。对于这个类加载器，The WebappLoader对象包含了org.apache.catalina.loader.WebappClassLoader实例(该类继承了java.net.URLClassLoader类)。

 

  注意：当容器invoke方法被调用，无论什么时候与loader相关联的容器都需要一个servlet类。容器首先会调用the Loader接口中的getClasssLoader方法老获得类加载器。容器然后就会调用类加载器中的loadClass方法目的是加载the servlet类。更加详细的讨论请大家快看第十一章“StandardWrapper”.

 

下面是关于Loader接口和实现的类图：

   

二、The Reloader接口

 

 为了支持自动部署，一个类加载器的实现一定要实现org.apache.catalina.Reloader接口。

 

package org.apache.catalina.loader;

public interface Reloader {
    public void addRepository(String repository);
    public String[] findRepositories();

    public boolean modified();

}

 

The Reloader接口十分重要的方法就是modified方法，因为假设在web应用程序中一个servlet或者受支持的类已经修改，那么就要返回true. 在实现Reloader接口中的类加载器类中，The addRepository方法是用来添加一个repository（相当一添加一个规则），the findRepositories方法就是返回全部repositories的字符串数组。

 

二、The WebappLoader 类

 

The org.apache.catalina.loader.WebappLoader类实现了Loader接口并且代表了一个web应用的loader（主要负责加载web应用程序所需要的类）。WebappLoader类定义了一个成员变量( the org.apache.catalina.loader.WebappClassLoader类实例 )作为它的类加载器。像Catalina其他组件那样，WebappLoader类实现了 org.apache.catalina.Lifecycle，通过与之关联的容器来启动/关闭该组件。The WebappLoader类也实现了 java.lang.Runnable接口，它的目的就是创建一个独立的线程反复的调用class Loader中的modified方法。如果the modified方法返回了true,那么the WebappLoader实例通知与之关联的容器(在本应用程序是一个context)。类的重新加载是由the Context来实现的不是通过WebappLoader类实现。The Context组件到底做了什么请看第十二章的讨论，(StandardContext)。

 

 当The WebappLoader类中的开始方法就会有许多任务要执行如：

 

            1、创建一个class loader

            2、设置规则(repositories)

            3、设置类路径

            4、设置权限

            5、开启一个自动部署的线程

 

 

 每个任务都会在下面的子部分详细讨论。

 

三、创建一个Class Loader

 

 为了加载一个类，a WebappLoader实例绑定了一个内部的class loader. 你可能会想起前面讨论的Loader接口(仅仅提供了getClassLoader方法，确没有提供setClassLoader)。因此，你无法实例化一个 class loader传给The WebappLoader.The WebappLoader，它并没有和一个默认的class Loader绑定，那么就意味着它就无法绑定class loader了吗？

 

   答案肯定说不，The WebappLoader提供了the getLoaderClasss和setLoaderClass方法目的就是获得和改变私有变量字符串loaderClass。这个变量是一个字符串(代表了the class loader的类名字)。默认情况下，the loaderclass值是org.apache.catalina.loader.WebappClassLoader. 如果你能够创建你自己的class Loader（扩展了WebappClassLoader）,就调用setLoaderClass方法迫使你的WebappLoader使用你自己定制的类加载器。否则，当WebappLoader开始启动时，他就会调用自己的私有方法createClassLoader（目的是创建一个WebappClassLoader实例）。下面的方法如下：

 

 

 private WebappClassLoader createClassLoader()
        throws Exception {

        Class clazz = Class.forName(loaderClass);
        WebappClassLoader classLoader = null;

        if (parentClassLoader == null) {
            // Will cause a ClassCast is the class does not extend WCL, but
            // this is on purpose (the exception will be caught and rethrown)
            classLoader = (WebappClassLoader) clazz.newInstance();
        } else {
            Class[] argTypes = { ClassLoader.class };
            Object[] args = { parentClassLoader };
            Constructor constr = clazz.getConstructor(argTypes);
            classLoader = (WebappClassLoader) constr.newInstance(args);
        }

        return classLoader;

    }

 可能使用了不同的class loader,除了使用了WebappClassLoader实例。然而，注意的是createClassLoader方法返回一个WebappClassLoader实例。因此，如果你想定制你自己的class loader且没有继承WebappClassLoader,这个方法会抛出一个异常。

 classLoader = (WebappClassLoader) clazz.newInstance();

 

四、设置Repositories

 

 The WebappLoader类中的start方法调用了setRepositories方法(目的的想添加repositories到class loader)。 The WEB-INF/classs 目录当做参数传给了class loader类中的addRepository方法，the WEB-INF/lib目录当做参数传给了class loader类中的setJarPath方法。这种方式，the class loader将能够在WEB-INF/classes目录和一个部署在WEB-INF/lib目录下的任何类库加载classes.

 

 

五、 设置类路径

 

 这个任务执行是由the start方法调用了setClassPath方法在servlet context下赋值给了一个属性(该属性字符串包含了Jasper JSP compiler的类路径信息)，这里就不在讨论。

 

六、设置权限

 

 当运行的Tomcat运用了安全管理，那么setPermission方法给class loader添加权限(限制访问目录比如：WEB-INF/classes和WEB-INF/lib). 如果没有安全管理在使用，那么该方法就会立马返回。

 

七、开始一个自动部署的线程

 

WebLoader支持自动部署。如果一个类在web-inf.classes或者WEB-INF/lib目录下重新编译了，那么这个类就会在Tomcat不重新启动的前提下，自动的加载这个类。要达到这样的目的，WebappLoader要有一个线程(对每个资源，每个x秒钟)核实时间标记。x 在这儿是被定义的变量checkInterval的值，默认值是15，也就是意味着每个15秒就核实一下。The getCheckInterval和setCheckInterval方法被用来访问这个成员变量。

 

 

在Tomcat 4 中WebappLoader实现了java.lang.Runnable接口，目的是支持自动部署。下面是实现Runnable接口的方法：

 public void run() {

        if (debug >= 1)
            log("BACKGROUND THREAD Starting");

        // Loop until the termination semaphore is set
        while (!threadDone) {

            // Wait for our check interval
            threadSleep();

            if (!started)
                break;

            try {
                // Perform our modification check
                if (!classLoader.modified())
                    continue;
            } catch (Exception e) {
                log(sm.getString("webappLoader.failModifiedCheck"), e);
                continue;
            }

            // Handle a need for reloading
            notifyContext();
            break;

        }

        if (debug >= 1)
            log("BACKGROUND THREAD Stopping");

    }

 

注意：在Tomcat 5中核实被修改的类任务是由org.apache.catalina.core.StandardContext类中的backgroundProcess方法执行。这个方法通过一个专门的线程(在 org.apache.catalina.core.ContainerBase类中)周期的调用，ContainerBase的子类是StanardContext. 在开启的专门线程，由内部类ContainerBackgroundProcessor实现了Runnable接口.

 

到了一个十分重要的部分，下面的run方法包含了一个while循环,跳出循环的条件就是布尔值started(WebappLoader已经启动了)变成false。The while循环做了下面几件事：

 

        1、通过checkInternal变量控制休眠的周期

        2、通过调用The WebappLoader实例变量class loader中的modified方法，来核实是否已经加载的类被修改了。如 果没有就继续。

         3、如果一个类已经修改了，就会调用the notifyContext私有方法，请求the context(与The WebappLoader相关联)重新加载。

 

 The notifyContext方法代码如下面所示：

 

    private void notifyContext() {

        WebappContextNotifier notifier = new WebappContextNotifier();
        (new Thread(notifier)).start();

    }

 The notifyContext方法没有直接调用The Context接口的reload方法。相反，它是实例化了一个内部类WebappContextNotifier并传递给线程对象然后再调用启动线程的start方法。这种方式，重新加载的功能将会以不同的线程来实现。下面是WebappContextNotifier类代码：

 

    protected class WebappContextNotifier implements Runnable {


        /**
         * Perform the requested notification.
         */
        public void run() {

            ((Context) container).reload();

        }


    }

 

当WebappContextNotifer实例传给了一个线程，那么线程对象中的start方法将会被调用，The WebappContextNotifier实例中的run方法就会被执行。接着，the run方法就会调用Context接口的reload方法。你将会在第十二章看到org.apache.catalina.core.StandardContext类是如何实现the reload方法的。

 

 

八、The WebappClassLoader类

 

The org.apache.catalina.loader.WebappClassLoader类代表了the class loader,负责处理在web应用中的类的加载。WebappClassLoader继承了java.net.URLClassLoader类，这个类我们用来加载java Classes（在前面章节的应用程序中）。

 

 WebappClassLoader优化设计以及进行安全的考虑。比如，它就会缓存前面已经加载好的类，来提高系统性能，它也缓存没有找到的类，如此这样下一次在加载同样的类时，the class loader就会抛出ClassNotFounException异常. WebappClassLoader会搜索存放在repositories下面的类以及具体的JAR文件。关于安全的考虑，WebappClassLoader类就不允许某些类被加载。这些类被存放在一个字符串数组triggers,数组里面有一个值：

           private static final String[] triggers={

               "javax.servlet.Servlet"

             };

 

同时也不允许加载属于下面的这些包名和子包下，无法一开始就委派到the system class loader中去：

 

 

    private static final String[] packageTriggers = {
        "javax",                                     // Java extensions
        "org.xml.sax",                               // SAX 1 & 2
        "org.w3c.dom",                               // DOM 1 & 2
        "org.apache.xerces",                         // Xerces 1 & 2
        "org.apache.xalan"                           // Xalan
    };

 现在让我们看看这个类是怎样实现缓存功能和类的加载。

 

九、Caching

 

Tomcat为了到达更好的性能，已经加载的类存储到cache中，目的是为了下次请求时相同的类不再需要加载，直接从缓存中取。Caching是在本地上做的，也就是缓存是有WebappClassLoader实例进行管理。除此之外，the java.lang.ClassLoader维护了一个Vector (把已经加载的类存放在这里)，目的是防止这些类被垃圾回收站销毁。在本应用程序中，caching是有父类管理。

 

 可能被WebappClassLoader加载的每个类(不管类文件部署在WEB-INF/classes目录，还是该类来自一个JAR文件)要指向一个资源(resource).一个resource有org.apache.catalina.ResourceEntry类代表。一个ResourceEntry实例拥有许多内容如：类的字节数组，最后的修改时间，The Manifest(当资源是来自一个JAR文件)。

 

 下面是ResourceEntry类的代码：

package org.apache.catalina.loader;

import java.net.URL;
import java.security.cert.Certificate;
import java.util.jar.Manifest;
public class ResourceEntry {
    public long lastModified = -1;
    public byte[] binaryContent = null;
    public Class loadedClass = null;
    public URL source = null;
    public URL codeBase = null;
    public Manifest manifest = null;
    public Certificate[] certificates = null;


}

 

全部的cached资源存储在一个HashMap中名字叫做resourceEntries.The key是资源的名字。无法找到的资源就会存储到另外一个HashMap（叫做noyFoundResources）.

 

十、加载Classes

 

但要加载一个类时，The WebappClassLoader类要运用以下规则：

 

  1、首先要和售本地的cache,整个已经加载的classes一定要存放在cached中。

  2、如果在本地cache中没有找到此类，那么就需要调用java.lang.ClassLoader类中的findLoadedClass方法，目的是核实cache。

  3、如果在两个cache中都没有找到，那么就用system 类加载器目的是阻止web应用中的类覆盖J2EE中的类。

  4、如果安全管理被使用，就要核实the class是否允许加载。如果不允许那么就会抛出一个异常ClassNotFoundException.

 

  5、如果布尔值(委派标记)为true或者被加载的the class属于trigger包中的名字，那么就使用父类加载器加载the calss.如果父类加载器为null, 那么就是用system 类加载器。

 

  6、加载来自当前的repositories中的类。

  7、如果类在当前的repositories没有找到以及布尔值(委派标记)为false时，就是用父类加载器。如果父类加载器也为null,那么就只能使用system加载。

  8、如果类仍然还是没有找到，那么就会抛出一个异常ClassNotFoundException.

 

十一、应用程序

 

本章的应用程序目的是想说明与Context相关的WebappLoader实例。the org.apche.catalina.core.StandardContext类是Context的一个标准的实现，因此在本应用程序就实例化了StandardContext类。然而，StandardContext会推迟到第十二章进行讨论。在这个阶段你不需要理解这个类的详细细节，而需要你理解仅仅是关于协调工作的触发事件，如：The START_EVENT、STOP_EVENT.  The Listener一定要实现org.apache.catalina.lifecycle.LifecycleListener接口，然后调用The StandardContext类中的setConfigured方法。对于本应用程序，The listener是有SimpleContextConfig类代表的，下面显示详细的代码：

 

package ex08.pyrmont.core;

import org.apache.catalina.Context;
import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;

public class SimpleContextConfig implements LifecycleListener {

  public void lifecycleEvent(LifecycleEvent event) {
    if (Lifecycle.START_EVENT.equals(event.getType())) {
      Context context = (Context) event.getLifecycle();
      context.setConfigured(true);
    }
  }
}

 呵呵。。这样就只需要你实例化StandardContext和SimpleContextConfig这两个类，然后就调用org,apache.catalina.Lifecycle接口中的addLifecycleListener方法目的是把后面的实例注册给StandardContext.Lifecycle接口我们在第六章是详细的讨论了。

 

除此之外，本应用程序也保留了前面章节的以下几个类：SimplePipeline,SimplWrapper , SimpleWrapperValve.

 

同时本应用程序使用了PrimitiveServlet和ModernServlet来进行测试，但是这次StandardContext强制这些servltes存放在WEB-INF/classes应用程序目录下。该应用目录的名称是myApp，当你第一次部署可下载的ZIP文件时该目录就应该被创建。为了告知StandardContext实例在哪个应用目录下查找，那么你必须把use.dir 属性值设置到叫做catalina.base的一个系统属性中，下面是其代码：

 

     System.setProperty("catalina.base",System.getProperty("use.dir"));

 

事实上，在Bootstrap类中的main方法代码第一行实例化的是一个默认连接器：

 

        Connector connector=new HttpConnector();

然后创建了两个wrapper(负责处理servlet)，接着初始化他们，正如前面的章节的应用程序那样：

 

 

    Wrapper wrapper1 = new SimpleWrapper();
    wrapper1.setName("Primitive");
    wrapper1.setServletClass("PrimitiveServlet");
    Wrapper wrapper2 = new SimpleWrapper();
    wrapper2.setName("Modern");
    wrapper2.setServletClass("ModernServlet");

 接着，有创建了StandardContext实例，在设置路径以及基于context的文档。

 

 

    Context context = new StandardContext();
    // StandardContext's start method adds a default mapper
    context.setPath("/myApp");
    context.setDocBase("myApp");

 上面的代码就如同Tomcat配置文件server.xml.

 

         <Context path="/myApp" docBase="myApp"/>

 然后，两个wrappers别添加到context,然后又给他们添加mapping，目的是为了Context查找the wrapper.

 

    context.addChild(wrapper1);
    context.addChild(wrapper2);

    // context.addServletMapping(pattern, name);
    context.addServletMapping("/Primitive", "Primitive");
    context.addServletMapping("/Modern", "Modern");

 

下一步，实例化一个listener,在把它注册到the Context中。

 

             LifecycleListener listener=new SimpleContextConfig();

             ((Lifecycle)context).addLifecycleListener(listener);

 

在下一步，实例化一个WebappLoader,并与the Context相关联。

 

               Loader loader=new WebappLoader();

               context.setLoader(loader);

  connector.setContainer(context);

    try {
       connector.initialize();
      ((Lifecycle) connector).start();
      ((Lifecycle) context).start();

 

下面的几行代码仅仅就是显示了资源 docBase的值以及在类加载器中的repositories.

 

之后，the context有与默认连接器相关联，连接器初始化，start方法被调用，接下来就是启动context容器。这就是把servlet容器放到一个service中。。。

 

 

 //  now we want to know some details about WebappLoader
      WebappClassLoader classLoader = (WebappClassLoader) loader.getClassLoader();
      System.out.println("Resources' docBase: " + ((ProxyDirContext)classLoader.getResources()).getDocBase());
      String[] repositories = classLoader.findRepositories();
      for (int i=0; i<repositories.length; i++) {
        System.out.println("  repository: " + repositories[i]);
      }

 

当你运行该应用程序时，上面几行代码就是显示了docBase和repositories列表。

 

   Resources's docBase:    C:/HowTomcatWorks/myApp

      repository:  /WEB-INF/classes/

 

docBase的值会根据你的电脑显示的不一样，这是取决 于你的应用程序是放在哪里.

 

   最后，应用程序一直等待，知道在控制台上按了Enter键，才会终止应用程序。

  // make the application wait until we press a key.
      System.in.read();
      ((Lifecycle) context).stop();

 

十二、运行应用程序

 

   这里就不必多说

 

十三、 总结

 

  The Web 应用的Loader或者一个简单的loader在catalina中的组件式尤为重要。一个Loader负责加载类因此要拥有一个内在的class loader.这个内在的class loader是自己定制的类(Tomcat通常在context应用中使用了某些规则)，同时定制的class loader支持缓存以及热部署。。。

 

 

 

精彩！  很深入的文章