Through the experiment, we draw a conclusion that there is a class under the server/lib of WebLogic, and the application webapp/web-inf/classes
Under the same class name, the method name is the same, there is only a slight difference in the characters printed in the background, after the WebLogic is started, regardless of the text
The class in the folder who is newly compiled (version new or old), the application system is using the class under Server/lib by default,
Instead of referencing a class under Webapp/web-inf/classes.
First, through a large number of data learned that the Java class loading principle is as follows the JVM at runtime will produce three classloader:
Bootstrap ClassLoader, Extension ClassLoader and Appclassloader. Where Bootstrap is written in C + +, which we do not see in Java, is null, which is used to load the core class library.
About Bootstrap ClassLoader, in the JVM source code, write this:
static const char classpathformat[] =
"%/lib/rt.jar:"
"%/lib/i18n.jar:"
"%/lib/sunrsasign.jar:"
"%/lib/jsse.jar:"
"%/lib/jce.jar:"
"%/lib/charsets.jar:"
"%/classes";
You know why you don't need to load these classes in Classpath? They are automatically loaded when the JVM is started and cannot be modified at all during the bootstrap load path.
Extension ClassLoader is used to load extension classes, which are classes in/lib/ext.
The last Appclassloader is to load classpath.
The ClassLoader load class uses a delegate model. That is, the parent class (not super, not the inheritance relationship) is searched for, and the parent cannot find it. It seems that ClassLoader is quite filial.
The relationship between the three is:
The parent of Appclassloader is Extclassloader, and Extclassloader's parent is bootstrap ClassLoader. Add
Load a class, first Bootstrap first to find, can not find again by Extclassloader search, the last is Appclassloader.
Why is it so complicated to design? One of the important reasons is security.
For example, in an applet, if you write a java.lang.String class and it is destructive. If this mechanism is not adopted, it will be
This destructive string is loaded onto the user's machine, causing user security to be compromised. However, the use of such a delegation mechanism will not present this
Case Because the Java.lang.String class is loaded, the system will eventually be loaded by bootstrap, a destructive string that is permanently
Far no chance of loading.
One article explains the principles of Java class loading in its entirety, as follows:
--------------------------------------------Reference begins--------------------------------------
My understanding of class loading in Java
1. All classes in Java must be loaded into the JVM to run, which is done by the class loader in the JVM, and what the class loader does is essentially to read the class file from the hard disk into memory.
2. The classes in Java are broadly divided into three types:
A. System class
B. Extension classes
C. A class that is customized by the programmer
3. Class loading method, there are two kinds:
A. Implicit loading, when the program is running, the class loader implicitly loads the corresponding class into the JVM when it encounters the generation of objects by means of new.
B. Explicit loading, explicitly loading the required classes by means of Class.forName ().
The difference between implicit loading and explicit loading: is the two essentially the same? ？
4. Dynamic representation of class loading
An application is always composed of n multiple classes, when the Java program starts, not once all the classes are loaded and then run, it is always
The advantage of first loading the underlying class of the guaranteed program into the JVM and other classes waiting for the JVM to load again is to save
Memory overhead, because Java was originally designed for embedded systems, memory is valuable, this is an understandable mechanism, and when used
Reload this is also a manifestation of Java dynamics.
5. Java class Loader
The class loader in Java is essentially a class, the function is to load the class into the JVM, it is worth noting that the JVM class loader is not one, but three, the hierarchy is as follows:
Bootstrap Loader-Responsible for loading system classes
|
--Extclassloader-Responsible for loading extension classes
|
--Appclassloader-Responsible for loading the application class
Why should have three class loaders, on the one hand is the division of labor, each responsible for the respective block, on the other hand in order to implement the delegation model, the following will talk about the model
6. How the class loader coordinates the work
As I said earlier, there are three ClassLoader in Java, and the question is, how do they work when a class needs to be loaded?
That is how Java distinguishes a class from which classloader to complete it.
Here Java uses the commission model mechanism, this mechanism simply, is "class loader has loaded class requirements, will first ask its parent to use its search path to help load, if the parent can not find, then by their own search path search class", note oh, this sentence has recursion.
Here's an example of how a few lines of code should be understood in order to get a better understanding:
public class test{public static void Main (string[] arg) { ClassLoader c = Test.class.getClassLoader (); Gets the class loader for the test class System.out.println (c); ClassLoader C1 = C.getparent (); Gets the C class Loader's parent ClassLoader System.out.println (C1); ClassLoader C2 = c1.getparent ();//Get C1 the class loader's parent ClassLoader System.out.println (C2); }
Save the above code to the D:\My folder, compile directly, and then run in DOS mode
D:\my\java Test
。。。 Appclassloader ...
。。。 Extclassloader ...
Null
D:\my
Note:... Indicates that the content is omitted
You can see that test was loaded by the Appclassloader loader, and the Appclassloader parent loader is extclassloader, but
Is the extclassloader of the parent null is what's going on uh, friends note that the previous mentioned bootstrap loader is in C + +
Language written, according to the Java point of view, there is no logical existence of bootstrap loader class entities, so in the Java program code to try to play
When you print out its contents, we see that the output is null.
Note: Most of the following refer to Java Deep Adventures.
To figure out the above example, go directly to the class-loaded delegate model instance and write two files, as follows:
Files: Test1.java
public class test1{public static void Main (string[] arg) { System.out.println (Test1.class.getClassLoader ()); Test2 t2 = new Test2 (); T2.print (); }
Files: Test2.java
public class test2{public void Prin () { System.out.println (This.getclass (). getClassLoader ()); }
The purpose of these two classes is to print out who is loading their class loader, save these two files to the D:\My directory, compile, we
In the copy two copies, placed under jdk1.4\jre\classes (note that we do not have this directory at the beginning of our system, we need to establish their own) and
Jdk1.4\jre\lib\ext\classes (also note that the start of our system does not have this directory, manually established), and then switch to D:\My
Directory to start the test,
Test One:
<jre directory under >\classes
Test1.class
Test2.class
<jre directory under >\lib\ext\classes
Test1.class
Test2.class
D:\my under
Test1.class
Test2.class
DOS input Run command, the result is as follows:
D:\my>java Test1
Null
Null
D:\my>
From the output we can see:
When the Appclassloader to load the Test1.class, first please its parent, that is, extclassloader to load,
Extclassloader also requested its parent, bootstrap loader, to load Test1.class.
Because <jre is located in the directory >\classes directory is bootstrap loader one of the search paths, so bootstrap loader found
Test1.class, so it is loaded, then there is a need to load test2.class within the Test1.class, since Test1.class is
Bootstrap loader is loaded, so test2.class is determined by Bootstrap loader according to its search path to find,
Because Test2.class is also located in bootstrap loader can be found under the path, so also was loaded, and finally we see Test1.class
Both with Test2.class are loaded by bootstrap Loader (null).
Test Two:
<jre directory under >\classes
Test1.class
<jre directory under >\lib\ext\classes
Test1.class
Test2.class
D:\my under
Test1.class
Test2.class
DOS input Run command, the result is as follows:
D:\my>java Test1
Null
Exception in thread "main" java.lang.NoClassdefFoundError:Test2 at Test1.main ...
D:\my>
From the output we can see:
When the Appclassloader to load the Test1.class, first please its parent, that is, extclassloader to load,
Extclassloader also requested its parent, bootstrap loader, to load Test1.class.
Because <jre is located in the directory >\classes directory is bootstrap loader one of the search paths, so bootstrap loader found
Test1.class, so it is loaded, then there is a need to load test2.class within the Test1.class, since Test1.class is
Bootstrap loader is loaded, so test2.class is determined by Bootstrap loader according to its search path to find,
But because bootstrap loader couldn't find Test2.class (removed by us), and bootstrap loader did not have the parent,
It is not possible to load test2.class. Finally we see that Test1.class is loaded by bootstrap Loader (null) and Test2.class cannot be loaded
Test Three
<jre directory under >\classes
Test2.class
<jre directory under >\lib\ext\classes
Test1.class
Test2.class
D:\my under
Test1.class
Test2.class
DOS input Run command, the result is as follows:
D:\my>java Test1
。。。 Extclassloader ...
Null
D:\my>
From the output we can see:
When the Appclassloader to load the Test1.class, first please its parent, that is, extclassloader to load,
Extclassloader also requested its parent, bootstrap loader, to load Test1.class.
But bootstrap loader couldn't find Test1.class under its search path (we deleted it), so Extclassloader had to
Search, so extclassloader found Test1.class in the directory where the search path <jre is located >\lib\ext\classes
This loads it, and then there is a need to load the Test2.class within the Test1.class, since Test1.class is Extclassloader
is loaded, so test2.class is determined by Extclassloader according to its search path, but because Extclassloader has
Parent, so first by bootstrap loader help to find, test2.class located in bootstrap loader can find the path, the
was loaded with the bootstrap loader. Finally we see that Test1.class is loaded by Extclassloader, and Test2.class is
Bootstrap Loader (NULL) loading
Understanding the above rules, ask friends to analyze the results of the following scenarios on their own
Test four:
<jre directory under >\classes
<jre directory under >\lib\ext\classes
Test1.class
Test2.class
D:\my under
Test1.class
Test2.class
Test Five:
<jre directory under >\classes
<jre directory under >\lib\ext\classes
Test1.class
D:\my under
Test1.class
Test2.class
Test Six:
<jre directory under >\classes
<jre directory under >\lib\ext\classes
Test2.class
D:\my under
Test1.class
Test2.class
Test Seven:
<jre directory under >\classes
<jre directory under >\lib\ext\classes
D:\my under
Test1.class
Test2.class
-----------------------------------end of the quote, thanks to the author ha! ----------------------------------
The above through their own speculation, and conduct field testing, found that there is a certain truth.
WebLogic the principle container for class loading also encapsulates class loading, although different containers differ for class loading. In WebLogic, this is the principle.
ClassLoader in WebLogic is hierarchical, it can only load classes higher than its hierarchy and its own classes, the same level of classes and classes lower than its level can not be loaded.
The ClassLoader in WebLogic has 5 levels, from high to low rows:
A.jdk
B.JDK ext
C.system Classpath
D. (App-inf/classes and App-inf/lib)
E. (Web-inf/classes and Web-inf/lib)
Attention:
Here is the class in classes loaded first, then the class in Lib, to modify its loading order, you can add the following code in Weblogic.xml (version 8):
<container-descriptor> <prefer-web-inf-classes>true</prefer-web-inf-classes> </ Container-descriptor>
F.ejb.jar
Note: The ClassLoader of E and F are siblings.
So the App-inf/lib and App-inf/classes classes cannot instantiate classes under WebApp, which is especially important to note that the class cannot find errors.
There is also a Web text, "Weblogic10 classloading problem", the principle of WebLogic loading class is introduced in detail.
From the WebLogic official documentation, a clearer and simpler description of the class loading order for WebLogic is given:
When an application is deployed, WebLogic server automatically creates a class loader with a hierarchy.
A.application ClassLoader is responsible for loading all the EJB jar files in the application;
B.web Application ClassLoader is responsible for loading all the war files in the Web application (except for all JSP files);
C.jsp Classloader is responsible for loading all the JSP files in the Web application;
Tomcat is the opposite of WebLogic:
For Web applications running in a Java EE container, the ClassLoader is implemented differently than a typical Java application. A different web
The way containers are implemented can also vary. As with Apache Tomcat, each WEB application has a corresponding ClassLoader instance.
The ClassLoader also uses the proxy mode, and the difference is that it is the first attempt to load a class if it cannot find a proxy to the parent class loader.
This is contrary to the order of the generic ClassLoader. This is the recommended practice in the Java Servlet specification, which is designed to make Web applications self-
Class is higher than the class provided by the Web container. One exception to this proxy pattern is that the class of the Java core Library is not in the lookup scope
Within the. This is also to ensure the type safety of the Java Core library.
Finally, to summarize, in the process of starting the WebLogic service, a class loader with hierarchy structure is automatically formed:
First load the JDK and Java extension jar packages or classes;
Then load each jar package or class used by WebLogic itself;
Then load the classes class under the Web App folder,
Then load the jar package or class under Lib in the Web App folder.
That is, each level of the class loader corresponds to a different class path, which corresponds to one by one.
For example, the system loader corresponds to the JDK and extension path;
The application loader corresponds to the related class of WebLogic;
and the Web application loader corresponds to the path of classes and Lib under WebApp application;
The JSP loader corresponds to the JSP file.
Of course, during the loading process, if a class has already been loaded in a high-level loader, then the class will not be encountered again later in the load.
will be loaded, but will be ignored. After the load is complete, put the class into the cache for system application calls.
In the course of running the system, if you encounter the use of this class, you will follow the principle of first loading through its parent ClassLoader, for example,
I want to load a Wswordmanager class, the system will first look in the cache, if not found, then call the parent loader to the corresponding
The path inside to look for, has been upward, looked for the load, if cannot find to report the ClassNotFound exception.
----------------------------------------a gorgeous delimiter----------------------------------------
Haha, a day-long trial can prove this.
When resolving the System project "native class repeated load, exception is Jacob.dll already loaded in another ClassLoader" issue,
Forced to study the above principles. Now the problem is a more perfect solution, but also the key is to learn a lot of relevant knowledge of the underlying, for
The improvement of your own technology is very beneficial.
WebLogic and Java class loader principle test analysis
