web容器类加载顺序

最新推荐文章于 2024-06-29 02:13:01 发布

一起玩编程

最新推荐文章于 2024-06-29 02:13:01 发布

阅读量7.4k

点赞数

分类专栏： java-server 文章标签： web classloader weblogic java application null

java-server 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

Weblogic中classloader是分层次的，它只能加载比它层次高的类及它自身的类，同层次的类及比它层次低的类都不能加载。

在weblogic中的classloader有5个层次，从高到低排：
a. jdk
b. jdk ext
c. system classpath
d. ( APP-INF/classes and APP-INF/lib )
e. ( WEB-INF/classes and WEB-INF/lib )
    注意：这里是先加载classes中的类，再加载lib中的类，若要修改它的加载顺序，可以通过在Weblogic.xml（版本为8）中加入以下代码：
    <container-descriptor>
       <prefer-web-inf-classes> true </prefer-web-inf-classes>
    </container-descriptor>

f. ejb.jar

注意：e 和 f 的classloader是同级的。
所以APP-INF/lib和APP-INF/classes下类不能实例化webapp下的类，这点尤其要注意，否则会报类找不到的错误。

来自Weblogic官方的说明文件中，对于Weblogic的类加载顺序给出了一个比较清晰和简单的描述：

　当部署一个应用的时候，weblogic server会自动创建一个具有层次结构的类装载器。
1、a.Application Classloader负责装载应用中的所有的EJB JAR文件；
2、b.Web Application Classloader负责装载所有的Web application 中的WAR 文件（所有得jsp文件除外）；
3、c.Jsp Classloader 负责装载Web application 中的所有的jsp 文件。

Tomcat与Weblogic是相反的：对于运行在 Java EE 容器中的 Web 应用来说，类加载器的实现方式与一般的 Java 应用有所不同。不同的 Web 容器的实现方式也会有所不同。以 Apache Tomcat 来说，每个 Web 应用都有一个对应的类加载器实例。该类加载器也使用代理模式，所不同的是它是首先尝试去加载某个类，如果找不到再代理给父类加载器。这与一般类加载器的顺序是相反的。这是 Java Servlet 规范中的推荐做法，其目的是使得 Web 应用自己的类的优先级高于 Web 容器提供的类。这种代理模式的一个例外是：Java 核心库的类是不在查找范围之内的。这也是为了保证 Java 核心库的类型安全。

附：java类加载顺序

java类装载器
Java中的类装载器实质上也是类，功能是把类载入jvm中，值得注意的是jvm的类装载器并不是一个，而是三个，层次结构如下：
Bootstrap Loader - 负责加载系统类
|
- - ExtClassLoader - 负责加载扩展类
|
- - AppClassLoader - 负责加载应用类
为什么要有三个类加载器，一方面是分工，各自负责各自的区块，另一方面为了实现委托模型，下面会谈到该模型

类加载器之间是如何协调工作的
前面说了，java中有三个类加载器，问题就来了，碰到一个类需要加载时，它们之间是如何协调工作的，即java是如何区分一个类该由哪个类加载器来完成呢。
在这里java采用了委托模型机制，这个机制简单来讲，就是“类装载器有载入类的需求时，会先请示其Parent使用其搜索路径帮忙载入，如果Parent 找不到,那么才由自己依照自己的搜索路径搜索类”，注意喔，这句话具有递归性。
下面举一个例子来说明，为了更好的理解，先弄清楚几行代码：
Public class Test{
Public static void main(String[] arg){
ClassLoader c = Test.class.getClassLoader(); //获取Test类的类加载器
System.out.println(c);
ClassLoader c1 = c.getParent(); //获取c这个类加载器的父类加载器
System.out.println(c1);
ClassLoader c2 = c1.getParent();//获取c1这个类加载器的父类加载器
System.out.println(c2);
}
}
把以上代码存到d:\my 文件夹下，直接编译，然后在dos模式下运行
D:\my\java Test
。。。AppClassLoader。。。
。。。ExtClassLoader。。。
Null

D:\my

注：。。。表示省略了内容
可以看出Test是由AppClassLoader加载器加载的
AppClassLoader的Parent 加载器是 ExtClassLoader

但是ExtClassLoader的Parent为 null 是怎么回事呵，朋友们留意的话，前面有提到Bootstrap Loader是用C++语言写的,依java的观点来看，逻辑上并不存在Bootstrap Loader的类实体，所以在java程序代码里试图打印出其内容时，我们就会看到输出为null。

弄明白了上面的示例，接下来直接进入类装载的委托模型实例，写两个文件，如下：
文件：Test1.java
Public class Test1{
Public static void main(String[] arg){
System.out.println(Test1.class.getClassLoader());
Test2 t2 = new Test2();
T2.print();
}
}

文件： Test2.java
Public class Test2{
Public void prin(){
System.out.println(this.getClass().getClassLoader());
}
}

这两个类的作用就是打印出载入它们的类装载器是谁，将这两个文件保存到d:\my目录下，编译后，我们在复制两份，分别置于jdk1.4\jre\classes下（注意，刚开始我们的系统下没有此目录，需自己建立）与 jdk1.4\jre\lib\ext\classes下（同样注意，开始我们的系统下也没此目录，手工建立）, 然后切换到d:\my目录下开始测试，

测试一：
<JRE所在目录>\classes下
Test1.class
Test2.class

<JRE所在目录>\lib\ext\classes下
Test1.class
Test2.class

D:\my下
Test1.class
Test2.class

dos下输入运行命令，结果如下：
D:\my>java Test1
Null
Null

D:\my>

从输出结果我们可以看出，当AppClassLoader要载入Test1.class时，先请其Parent，也就是ExtClassLoader来载入，而ExtclassLoader又请求其Parent,即Bootstrap Loader来载入Test1.class. 由于 <JRE所在目录>\Classes目录为Bootstrap Loader的搜索路径之一，所以Bootstrap Loader找到了Test1.class,因此将它载入，接着在Test1.class之内有载入Test2.class的需求，由于Test1.class是由Bootstrap Loader所载入，所以Test2.class内定是由Bootstrap Loader根据其搜索路径来找，因Test2.class也位于Bootstrap Loader可以找到的路径下，所以也被载入了，最后我们看到Test1.class与Test2.class都是由Bootstrap Loader（null）载入。

测试二：
<JRE所在目录>\classes下
Test1.class

<JRE所在目录>\lib\ext\classes下
Test1.class
Test2.class

D:\my下
Test1.class
Test2.class

dos下输入运行命令，结果如下：
D:\my>java Test1
Null
Exception in thread “main” java.lang.NoClassdefFoundError:Test2 at Test1.main。。。
D:\my>

从输出结果我们可以看出，当AppClassLoader要载入Test1.class时，先请其Parent，也就是ExtClassLoader来载入，而ExtclassLoader又请求其Parent,即Bootstrap Loader来载入Test1.class. 由于 <JRE所在目录>\Classes目录为Bootstrap Loader的搜索路径之一，所以Bootstrap Loader找到了Test1.class,因此将它载入，接着在Test1.class之内有载入Test2.class的需求，由于Test1.class是由Bootstrap Loader所载入，所以Test2.class内定是由Bootstrap Loader根据其搜索路径来找，但是因为Bootstrap Loader根本找不到Test2.class（被我们删除了），而Bootstrap Loader又没有Parent，所以无法载入Test2.class.最后我们看到Test1.class是由Bootstrap Loader（null）载入，而Test2.class则无法载入

测试三
<JRE所在目录>\classes下

Test2.class

<JRE所在目录>\lib\ext\classes下
Test1.class
Test2.class

D:\my下
Test1.class
Test2.class

dos下输入运行命令，结果如下：
D:\my>java Test1
。。。ExtClassLoader。。。
Null

D:\my>

从输出结果我们可以看出，当AppClassLoader要载入Test1.class时，先请其Parent，也就是ExtClassLoader来载入，而ExtclassLoader又请求其Parent,即Bootstrap Loader来载入Test1.class.但是Bootstrap Loader无法在其搜索路径下找到Test1.class(被我们删掉了)，所以ExtClassLoader只得自己搜索，因此ExtClassLoader在其搜索路径 <JRE所在目录>\lib\ext\classes下找到了Test1.class,因此将它载入，接着在Test1.class之内有载入Test2.class的需求，由于Test1.class是由ExtClassLoader所载入，所以Test2.class内定是由ExtClassLoader根据其搜索路径来找，但是因为ExtClassLoader有Parent,所以先由Bootstrap Loader帮忙寻找，Test2.class位于Bootstrap Loader可以找到的路径下，所以被Bootstrap Loader载入了.最后我们看到Test1.class是由ExtClassLoader载入，而Test2.class则是由Bootstrap Loader（null）载入

最后，总结一下，在Weblogic服务启动的过程中，自动形成一个具有层次结构的类装载器，首先装载jdk及java扩展jar包或类；然后再加载Weblogic本身使用的各个jar包或类；然后再加载Web应用文件夹里面的classes下的类，然后再加载Web应用文件夹里面lib下的jar包或类。也就是说，每个层次的类装载器均对应不同的类路径，它们是一一对应的。比如System装载器对应着jdk及扩展路径；Application装载器对应着Weblogic的相关类；而web 应用装载器对应着webapp应用下的classes和lib下的路径；而jsp装载器则对应着jsp文件。

当然，在加载过程中，若在高层次的加载器中已经加载了某类，那么再以后的加载中，再次遇到该类也不会加载，只是会忽略。加载完成之后，将类放入Cache中供系统应用调用。

在系统的运行过程中，若遇到使用该类的情况，则会遵循先通过其父类加载器进行加载的原则，比方说，我要加载一个WSWordManager类，
则系统会首先在Cache中寻找，若找不到，则调用父装载器到与之对应的路径里面去寻找，一直向上，找着了则进行加载，若找不着则报出ClassNotFound的异常。

理解为：

1. weblogic会一次性装载所有类，从上层到下层依次装载所以上层不能实例化下层的类。

2. java会请示其Parent使用其搜索路径帮忙载入，如果Parent 找不到,那么才由自己依照自己的搜索路径搜索类

3.tomcat会从自己的搜索路径中搜索类，找不到再请示器parent