Weblogic启动时classloader加载顺序

Weblogic默认情况下采用的是parent first的方式。但这个parent first，是有“讲究”（tricky）的。  
       1. 父类加载器和子类加载器之间的关系类似于Java中，父类和子类之间的对象关系。  
      2. Weblogic会将所有load到的class缓存到cache中。（子类classloader能看到父类classloader加载到cache中的class）。 
 
      默认情况下，当我们的应用程序（ear，war）运行时，会先去cache中查找class，如果找不到。就去System Classpath loader 里去找class。如果System Classpath loader里能找到你需要的类，那么不好意思，你在ear和war包里包含的class就没用了。如果System ClassPath Loader找不到，接下来去ear的class path里找，接着去EJB class path里找，最后到war的class path里找。一旦找到了该类，就会load起这个类，并将该类放入cache中。 

 

总的来说，Weblogic的ClassLoader有如下几个层次，按照从高到低顺序排列： 
 1. JDK Classloader 
 2. JDK ext Class Loader 
 3. Weblogic System Class Loader 
 4. Domain Class Loader(Child of System Class Loader) 
 5. App Class Loader  (负责装载应用中的所有的EJB JAR文件)
 6. Web Class Loader  (负责装载所有的Web application 中的WAR文件（所有得jsp文件除外)
 7. JSP Class Loader  (负责装载Web application 中的所有的jsp文件)
 
可以从Weblogic官方文档获取更多的关于Weblogic ClassLoader的信息：http://docs.oracle.com/cd/E23943_01/web.1111/e13706/classloading.htm#autoId32
 
若要修改它的加载顺序，可以通过在Weblogic.xml（版本为8）中加入以下代码：
     
        true  
     

 

     最后，总结一下，在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的异常。

 

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