ClassLoader structure of Apusic Application Server

The ClassLoader structure of the Apusic Application Server-Linux general technology-Linux programming and kernel information. The following is a detailed description. The J2EE1.3 Specification defines a packaging framework to organize all parts of J2EE applications. Different Application server vendors can freely design their own class loading layers to obtain classes and resources in the application. Therefore, developers must be very clear about where classes and resources should be stored and available for J2EE applications. Understanding the class loading architecture of Apusic application server can help J2EE application developers design efficient and portable application packaging structures. This article first introduces the basic concepts of class loading, and then discusses how to design the class loading hierarchy of Apusic application server. Through this article, J2EE application developers can better understand how the class loading architecture of Apusic Application Server obtains classes and resources from J2EE applications, it is helpful to exclude general ClassNotFoundException exceptions.
Basic concepts of class loading

Classloader is generally organized into parent/child hierarchies. When a class loading request is submitted to the classloader, it first requests the parent classloader to complete the request, and the parent classloader will pass the request step by step until the top of the class loading hierarchy. If the top classloader cannot complete the class loading request, its sub-classloader will be called to complete class loading. If the sub-classloader cannot load classes, the request will continue to be passed down until a classloader completes the request. Otherwise, if the classloader at the bottom of the class loading Hierarchy cannot complete the request, a ClassNotFoundException exception will be thrown.
Classloader
\
/| \
|
Classloader B
\\
/| \
|
Classloader c classloader D

Classloader hierarchy

Shows the hierarchy of a basic ClassLoader. ClassLoader at a given level cannot reference ClassLoader whose level is lower than its ClassLoader. In addition, classes loaded by its Sub-ClassLoader are invisible. In, if the class Foo is loaded by ClassLoader B and Foo depends on the class Bar, the class Bar must have ClassLoader A or B. If the class Bar is only visible to ClassLoader C and D, a ClassNotFoundException exception will occur.
?? If the class Bar is visible to two levels of ClassLoader (such as C and D), but not to their parent ClassLoader, when the class loading request is sent to these two ClassLoader, each ClassLoader will load its own version of the class. The instance of the class Bar loaded by ClassLoader C is not compatible with the instance of the class Bar loaded by D. If you do not know the hierarchical structure of ClassLoader, the above description may cause type incompatibility confusion.
?? It is very simple to show the hierarchical structure of ClassLoader through programming, but the results can effectively help us identify how the class is loaded. For example, the following program will display the ClassLoader hierarchy of the loaded class Foo.
Public class Foo
{
Public void showCLHierarchy (){
ClassLoader classLoader = getClass (). getClassLoader ();
System. out. println ("the classloader is:" + classLoader + "\ r ");

ClassLoader = classLoader. getParent ();
System. out. println ("the parent classloader is:" + classLoader );
}
Public static void main (String [] args ){
Foo foo = new Foo ();
Foo. showCLHierarchy ();
}
}
?? Make sure that the current path is in classpath, compile and run the above program. For example, on windows:
E: \ classloader \ test> javac Foo. java
E: \ classloader \ test> java Foo
?? If the compiling and running environment is SUN's JDK1.3 +, the following running result is displayed:
The classloader is: sun. misc. Launcher $ AppClassLoader @ e39a3e
The parent classloader is: sun. misc. Launcher $ ExtClassLoader @ a39.pdf
Apusic Application Server ClassLoader Architecture
?? The Apusic application server adopts a two-layer ClassLoader hierarchy. After the Apusic server is started, it creates a series of parent-child relationship ClassLoader, as shown in. The following describes the features of each ClassLoader, including their visible classes and resources.
Bootstrap
/| \
|
System
/| \
|
Ear classloader
/| \
|
War classloader

Apusic classloader Architecture

Bootstrap
This ClassLoader loads the basic runtime class provided by the Java Virtual Machine, and also includes classes placed in the JAR file in the System Extension directory ($ JAVA_HOME/jre/lib/ext.
System
?? The system ClassLoader is generally responsible for loading the classes set in the system environment variable CLASSPATH. The classes loaded by the system ClassLoader are visible to the classes in the Apusic server and the J2EE applications deployed on the Apusic server (usually packaged as ears. The jar file in the % APUSIC_HOME %/lib directory is the core class of the Apusic Application Server. These jar files are generally added to the system CLASSPATH.
?? In addition, some public classes can also be added to the system CLASSPATH, such as the JDBC driver.
Ear ClassLoader
?? Each EAR has a ClassLoader for loading the EJB module and public classes. Because the ClassLoader of each EAR is in a hierarchical relationship, classes in different applications are invisible to each other. Assume that the directory structure of an application is as follows:
MyApp
|
| _ MyEJB
| _ Com
| _ Apusic
| _ App
| _ HelloBean. class
|
| _ MyWEB
| _ WEB-INF
| _ Classes
| _ Lib
| _ Index. jsp
| _...
|
|-META-INF


The class paths of the EAR ClassLoader are MyApp/and MyApp/MyEJB/. That is to say, the classes in these two directories will be loaded by the EAR ClassLoader, which is generally EJB moudle and public class.
War ClassLoader
Each WAR has a ClassLoader, a sub-ClassLoader of the EAR ClassLoader, used to load Servlet and JSP. The WAR ClassLoader is responsible for the following class paths:
· MyApp/MyWeb/WEB-INF/classes/class under the Directory
· MyApp/MyWeb/WEB-INF/jar file under the Directory
· % APUSIC_HOME %/scratch/hostname_port_MyApp/jsp/Directory class, which is the Servlet corresponding to the JSP page
?? Because the WAR ClassLoader is the sub-ClassLoader of the EAR ClassLoader, The EJB module and public class loaded by the EAR ClassLoader are visible to JSP and Servlet in Web applications.
?? After understanding the ClassLoader principle and the architecture of the Apusic Application Server ClassLoader, it is of great help to solve ClassNotFoundException exceptions and class incompatibility issues encountered during the development of J2EE applications. For example, for the above application MyApp, assume that the public class com. apusic. app. util. log is used to record logs. You can store this class in the MyApp/MyEJB/com/apusic/app/util directory. In this way, this class will be loaded by the EAR ClassLoader, both EJB and Web applications are visible. If developers place a copy of this class under the MyApp/MyWeb/WEB-INF/classes directory, according to The ClassLoader proxy mode, when using this class in Web applications, the Log class is still loaded by the EAR ClassLoader. Because the class loading request sent to the WAR ClassLoader is first passed to the parent ClassLoader for execution, and the EAR ClassLoader can process this request, it will load the Log class. If developers do not have a good understanding of this behavior on the server, there may be an inexplicable error: clearly changed the Log class under the MyApp/MyWeb/WEB-INF/classes directory, but why do we still execute old behaviors in Web applications, even if we restart the Apusic server. The reason is simple: the Log class is always loaded by the EAR ClassLoader. It is useless to store the Log class in the MyApp/MyWeb/WEB-INF/classes directory!
?? The Apusic application server uses this convenient and flexible ClassLoader policy to support the deployment and operation of J2EE applications. I believe that as developers become familiar with Apusic application servers, they will become more and more fond of developing J2EE applications on Apusic!