How tomcat works 读书笔记十二 StandardContext 下

对重载的支持

tomcat里容器对重载功能的支持是依靠Load的(在目前就是WebLoader)。当在绑定载入器的容器时

    public void setContainer(Container container) {
              ...
        // Register with the new Container (if any)
        if ((this.container != null) && (this.container instanceof Context)) {
            setReloadable( ((Context) this.container).getReloadable() );
            ((Context) this.container).addPropertyChangeListener(this);
        }
    }

可见载入器的reloadable与它所绑定的容器的reloadable是一致的。

我们再看看载入器的setReloadable

 public void setReloadable(boolean reloadable) {

        // Process this property change
        boolean oldReloadable = this.reloadable;
        this.reloadable = reloadable;
      ....
        if (!started)
            return;
        if (!oldReloadable && this.reloadable)  //
            threadStart();
        else if (oldReloadable && !this.reloadable)
            threadStop();
    }

之前在第八章的时候,我们就知道congext容器reloadable的默认值是false,而且载入器的reloadable也是false。

因而默认情况下,载入器的run方法不会运作。那载入器的start没有启动run方法么?

public void start() throws LifecycleException {
               .....
        // Start our background thread if we are reloadable
        if (reloadable) {
            log(sm.getString("webappLoader.reloading"));
            try {
                threadStart();
            } catch (IllegalStateException e) {
                throw new LifecycleException(e);
            }
        }
    }

而载入器的run方法干什么?就是用

        while (!threadDone) {
            // Wait for our check interval
            threadSleep();

            if (!started)
                break;

            try {
                // Perform our modification check
                if (!classLoader.modified())     //WebappClassLoader的modified是根据时间判定所监
                    continue;                    //控的class是否改变
            } catch (Exception e) {              //一旦改变了 返回true 就 notifyContext
                log(sm.getString("webappLoader.failModifiedCheck"), e);
                continue;
            }

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

notifyContext()会启用WebappContextNotifier,后者调用容器的reload方法。

不过上面说了这么多,前提条件是载入器的reloadable得是true....

backgroundProcess 方法

在tomcat5中(上面说的那些是基于tomcat4的),关于时间戳的检查交给了backgroundProcess。

现在有个问题,4里好好的,为什么到5里就改了呢?

改是有原因的嘛。

想想之前,session因为要检查过期时间得启用一个线程,关于重载得检查时间戳,还得启用一个线程...

因而,在tomcat5中,所以的后台处理程序共用一个线程。具体怎么办呢?听老夫给你细细道来。

后面的所有代码来自tomcat7.0.55

在tomcat中,ContainerBase里面有

    protected void threadStart() {

        if (thread != null)
            return;
        if (backgroundProcessorDelay <= 0)
            return;
        threadDone = false;
        String threadName = "ContainerBackgroundProcessor[" + toString() + "]";
        thread = new Thread(new ContainerBackgroundProcessor(), threadName);
        thread.setDaemon(true);
        thread.start();
    }

重启了一个线程,不用说关键问题就是ContainerBackgroundProcessor。而它是ContainerBase的一个内部类。

ContainerBackgroundProcessor在run方法里会周期性的调用processChildren方法。
 protected void processChildren(Container container, ClassLoader cl) {
       ...
                container.backgroundProcess();
           ...
            Container[] children = container.findChildren();
            for (int i = 0; i < children.length; i++) {
                if (children[i].getBackgroundProcessorDelay() <= 0) {
                    processChildren(children[i], cl);
                }
            }
}

processChildren会先调用自己的backgroundProcess,然后让自己的子孙们也走一遍自己的流程。

   public void backgroundProcess() {

        if (!getState().isAvailable())
            return;

        if (loader != null) {
            try {
                loader.backgroundProcess();     //载入器的后台程序
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.loader", loader), e);
            }
        }
        if (manager != null) {
            try {
                manager.backgroundProcess();    //session的后台程序
            } catch (Exception e) {
                log.warn(sm.getString("containerBase.backgroundProcess.manager", manager), e);
            }
        }
}

那具体的载入器的backgroundProcess怎么写呢?如下

WebappLoader.java
 public void backgroundProcess() {
        if (reloadable && modified()) {
            try {
                Thread.currentThread().setContextClassLoader
                    (WebappLoader.class.getClassLoader());
                if (container instanceof StandardContext) {
                    ((StandardContext) container).reload();
                }
            } finally {
                if (container.getLoader() != null) {
                    Thread.currentThread().setContextClassLoader
                        (container.getLoader().getClassLoader());
                }
            }
        } else {
            closeJARs(false);
        }
    }

时间: 2024-10-12 21:57:18

How tomcat works 读书笔记十二 StandardContext 下的相关文章

How tomcat works 读书笔记十二 StandardContext 上

在tomcat4中,StandardContext.java是最大的一个类,有117k.废话不说,开始分析吧. 其实要分析StandardContext,也就主要分析两个方法,一个start,一个invoke. 两个变量 这里首先咱们得说两个boolean型的变量available,configured. 先说available,它表示了StandardContext是否可用,初始值为false.若StandardContext启动成功,其值就变为true;另外各种原因都会导致StandardC

How tomcat works 读书笔记十五 Digester库

Digester库 在前面的几个章节里,我们对tomcat里各个组件的配置完全是使用写硬编码的形式完成的. 如 Context context = new StandardContext(); Loader loader = new WebappLoader(); context.setLoader(loader); 就完成了向context容器里添加WepappLoader的功能. 这么做的问题就在于,一旦我想更改配置就必须得重新加载Bootstrap类. 幸运的是tomcat的设计者使用了一

How tomcat works 读书笔记十五 Digester库 下

在这一节里我们说说ContextConfig这个类. 这个类在很早的时候我们就已经使用了(之前那个叫SimpleContextConfig),但是在之前它干的事情都很简单,就是吧context里的configured变量置为true.在这里我们看看完整版的ContextConfig都干了什么. 在tomcat的实际部署中,StandContext类的实际监听器是org.apache.catalina.startup.ContextConfig的实例. ContextConfig完成加载验证器阀,

How tomcat works 读书笔记十四 服务器组件和服务组件

之前的项目还是有些问题的,例如 1 只能有一个连接器,只能处理http请求,无法添加另外一个连接器用来处理https. 2 对容器的关闭只能是粗暴的关闭Bootstrap. 服务器组件 org.apache.catalina.Server接口的实例用来表示Catalina的整个servlet引擎. 我们使用Server就是因为,它用一种优雅的方式来启动/关闭整个系统. 下面是启动和停止机制是如何工作的.当服务器启动的时候,它启动它内部的所有组件.然后无限期的等待关闭命令,如果你想要关闭系统,发送

how tomcat works 读书笔记 八 载入器下

载入类 我们看看之前的文章,这一节就从SimpleWrapper的loadServlet讲起. SimpleWrapper.java如下(省略了try catch及其他部分代码) public Servlet loadServlet() throws ServletException { ... String actualClass = servletClass; Loader loader = getLoader(); // Acquire an instance of the class l

how tomcat works 读书笔记(二)----------一个简单的servlet容器

app1 (建议读者在看本章之前,先看how tomcat works 读书笔记(一)----------一个简单的web服务器 http://blog.csdn.net/dlf123321/article/details/39378157) 回顾我们上一章,我们开发了一个最最简单的web服务器,它可以使用户访问服务器内的静态资源.当然这是远远不够的,在这一节里,我们就试着让服务器在能相应静态资源的基础上继续支持servlet. servlet接口 javax.servlet.Servlet接口

how tomcat works 读书笔记四 tomcat的默认连接器

其实在第三章,就已经有了连接器的样子了,不过那只是一个学习工具,在这一章我们会开始分析tomcat4里面的默认连接器. 连接器 Tomcat连接器必须满足以下几个要求 1 实现org.apache.cataline.Connector接口 2 负责创建实现了org.apache.cataline.Request接口的request对象 3 负责创建实现了org.apache.cataline.Response接口的response对象 这里默认的连接器的原理很简单,就是等待http请求,创建re

how tomcat works 读书笔记 十一 StandWrapper 上

方法调用序列 下图展示了方法调用的协作图: 这个是前面第五章里,我画的图: 我们再回顾一下自从连接器里 connector.getContainer().invoke(request, response); 这句代码运行之后发生的事情; 这是第五章的时序图,放在这一章同样适用... 我们仔细分析一下: 1首先连接器创建请求与响应对象; 2调用这行代码 connector.getContainer().invoke(request, response) (我们一StandContext为顶层容器)

How tomcat works 读书笔记十三 Host和Engine

Host Host是Context的父容器.如果想在一个tomcat上部署多个context就需要使用Host了.上下文容器的父容器是主机,但是可能有一些其它实现,没有必要的时候也可以忽略.不过在实践中,即使是一个Context,我们也使用了Host,为什么?后面我们再说. Host是个接口,里面有个map方法比较重要 /** * Return the Context that would be used to process the specified * host-relative requ