WebLogic class loading mechanism

The JVM will generate three classloader at runtime, bootstrap classloader, extension classloader, and appclassloader. Among them, bootstrap is written in C ++ and we cannot see it in Java. It is null. It is used to load the core class library and writes in the JVM Source Code as follows:

Static const
Char classpathformat []
=
"%/Lib/RT. jar :"
"%/Lib/i18n. jar :"
"%/Lib/sunrsasign. jar :"
"%/Lib/JSSE. jar :"
"%/Lib/JCE. jar :"
"%/Lib/charsets. jar :"
"%/Classes ";

Do you know why you don't need to load these classes in classpath? When the JVM is started, the bootstrap loading path cannot be modified at all.
Extension classloader is used to load extension classes, that is, classes in/lib/Ext.

Finally, the appclassloader loads the classpath.
Classloader loads classes using a delegated model. That is, the parent class (instead of super, not the inheritance relationship) is searched first, and the parent can only be searched by itself if it cannot be found. It seems that classloader is quite filial. The relationship between the three is as follows: appclassloader's parent is extclassloader, while extclassloader's parent is Bootstrap
Classloader. When loading a class, bootstrap first searches for the class, then extclassloader finds the class, and finally appclassloader.
Why is the design so complicated? One important reason is security. For example, in an applet, if a java. Lang. string class is written and destructive. If this delegation mechanism is not used, the destructive string will be loaded to the user's machine, resulting in damage to user security. However, this kind of delegation mechanism is not used. Because the system will eventually load the java. Lang. string class by bootstrap, and this destructive string will never be loaded.

Let's look at this Code:
// A. Java

Public Class {

Public static
Void main (string [] ARGs ){

A A = new ();

System. Out. println (system. getproperty (
"Java. Ext. dirs "));

System. Out. println (A. getclass (). getclassloader ());

B = new B ();

B. Print ();

}
}
// B. Java

Public Class B {

Public void
Print (){

System. Out. println (this. getclass (). getclassloader ());

}
}
1. If we put it in classpath, print it out.
Sun. Misc. launcher $ appclassloader @ 92e78c

Sun. Misc. launcher $ appclassloader @ 92e78c

It can be seen that all are loaded by appclassloader.
2. Place it in the directory where extclassloader loads % JRE %/lib/EXT/classes. It loads the JAR file in/lib/EXT or the class file in the subdirectory classes. The output is as follows:

Sun. Misc. launcher $ extclassloader

Sun. Misc. launcher $ extclassloader

3. What if we put a. Class in % JRE %/lib/EXT/classes and B. Class in classpaht? The result is:

Sun. Misc. launcher $ extclassloader

Exception in
Thread "Main"
Java. Lang. noclassdeffounderror: B

At a. Main (A. Java: 6)

How can this happen? One of the important problems is that Class A is loaded by extclassloader, and which class B is loaded? Class B is the class loader that calls its own class (real interface ). That is to say, a calls B, so B is loaded by extclassloader of Class. According to the delegate mechanism, extclassloader loads data by using Bootstrap, which is not found by bootstrap. Then it finds Class B by itself, but it still does not find it, so an exception is thrown. Extclassloader does not request appclassloader to load! You may think: What's the problem? Can I just put the two classes together?

It's not that easy. For example, JDBC is the core class library, and the JDBC driver of each database is defined in the extended class library or classpath. Therefore, JDBC is loaded by bootstrap classloader, while driver is loaded by appclassloader. Wait, the problem is that Bootstrap will not request the appclassloader to load the class. So how do they implement it? I am involved in a context classloader problem. I call thread. getcontextclassloader. I am not very clear about the details. Please let me know what will happen later! (Ah! Don't take bricks

Article Reference 2:
The classloader loading policy of Weblogic and the directory structure for deploying applications

The classloader loading policy of Weblogic and the directory structure of deploying the application 1 directory structure
To publish a web Applicate on WebLogic, you must have the following directory structure:
Mywebapp
|____ WEB-INF
| ___ Lib
// Put the jar package required by the web application

| ___ Classes
// Put the class

| ___ Web. xml
// Description of this Web Application


To publish an application, you must have the following directory structure:
Myapplication
| ___ APP-INF
// The Lib and classes in this directory cannot instantiate the class in webapp.

| ___ Lib
// Put the jar packages shared by EJB and webapp

| ___ Classes
// Put the class shared by EJB and webapp

| ___ META-INF
| |__ Application. xml
| ___ Mywebapp
| |____ WEB-INF
| ___ Lib

| ___ Classes
// Put the class

| ___ Web. xml
| ___ EJB. Jar
// EJB jar package

========================================================== ========================================================== =

2 classloader
Classloader is hierarchical. It can only load classes with higher levels and its own classes. classes of the same level and classes with lower levels cannot be loaded. The classloader in WebLogic has five layers, from high to low:
A. JDK
B. JDK ext
C. System classpath
D. (APP-INF/lib
And APP-INF/classes)
E. (WEB-INF/lib
And WEB-INF/classes)

F. EJB. Jar
Note: The classloader of E and F is of the same level.
So APP-INF/lib and APP-INF/classes under the class can not instantiate the webapp under the class, this especially pay attention to, otherwise it will report the class can not find the error.