Tomcat, WebSphere, and JBoss class loading mechanisms

http://blog.csdn.net/lshxy320/article/details/6448972 2 Tomcat class loading mechanism

Tomcat Server Constructs a ClassLoader tree at startup to ensure that the module's class library is private
the ClassLoader structure diagram for Tomcat Server is as follows:

-Bootstrap-  load  jvm  comes with classes and  /jre/ Lib/ext/*.jar
-System-  loading  /*.class
-Common-  loading   /common/...   tomcat  and all  web app  are visible  
-Catalina-  load  /server/...   tomcat  visible, for all  web app  are not visible  
-Shared-  loads  /shared/... , which are visible only to all  web app , to  tomcat  not visible (and do not see)  
-WebApp-  load   contextbase?/web-inf/... , which are only visible to the  web app 

Each running thread has a memberContextclassloader, which is used to dynamically load other classes at run time, the system defaultcontextclassloader  is systemclassloader , so generally java  program can be executed using jvm  from   band class,  $ Java_ Classes in home/jre/lib/ext/  and  / , you can use   Thread.CurrentThread (). Setcontextclassloader (...);   Change the current thread's  contextclassloader , to change the behavior of its load class  classloader   is organized into a tree, the general working principle is:  
1)   thread needs to use a class, so   contextclassloader  is requested to load the class  
2) contextclassloader  request its parent   classloader  to complete the load request  
3)   If parent   classloader  cannot load class,  contextclassloader  tries to load

3 Websphere class loading mechanism

When a Java application runs, it must be loaded through the ClassLoader to make it valid before class is executed and accessed, and the ClassLoader is part of the JVM code that is responsible for locating and loading all Java classes and local Lib libraries in the JVM virtual machine . The different configurations of the ClassLoader affect the behavior of the application when it is deployed to the runtime on the application server. The JVM and WebSphere application servers provide a number of different classloader configurations that form a hierarchical structure with parent-child relationships.

The class loader hierarchy in WebSphere is shown in Figure 1:

As shown, theclass loader in WebSphere is organized into a top-down hierarchy, the topmost of which is the system's running environment JVM, the bottom level is the specific application, and the parent-child relationship is formed between the upper and lower layers.

• JVM class loader: At the top of the entire hierarchy, it is the root of the entire ClassLoader hierarchy, so it does not have a parent classloader. This classloader is responsible for loading the JVM class, the JVM extension class, and all Java classes defined on the CLASSPATH environment variable .
• WebSphere Extensions class Loader: The WebSphere Extension class loader , which loads WebSphere runtime classes, resource adapter classes, and so on.
• WebSphere Lib/app class Loader: The WebSphere server classloader that loads classes on the path of $ (was_home)/lib/app in the WebSphere installation directory. In the was V4 version, was uses this path to share jar packages across all applications . starting with was V5, the shared library feature provides a better way, so the ClassLoader is primarily used for compatibility with some legacy systems.
• WebSphere "Server" class Loader: WebSphere Application Server ClassLoader. It defines the classes that are shared among all the applications on this server. with the concept of shared libraries in was V5, you can define multiple ClassLoader associated with the shared library for the application server, which form a parent-child relationship in the order in which they are defined.
• Application Module class Loader: The Application class loader, located at the last level of the hierarchy, for loading the Java EE application. Depending on the application's class loading strategy, you can also define your own class loader for the Web module.

With regard to the hierarchy of the WebSphere ClassLoader, the following notes may be more helpful in understanding the lookup and loading process of a class:

• Each class loader is responsible for finding and loading classes on its own defined classpath.
• A subclass loader can delegate its parent ClassLoader to find and load classes, and a request to load a class is sent from the subclass loader to the parent ClassLoader, but never from the parent class loader to the child ClassLoader.
• Once a class is loaded successfully, the JVM caches the class until its lifecycle ends and associates it with the appropriate classloader, which means that different classloader can load classes of the same name.
• If a loaded class relies on another or some class, then these dependent classes must exist on the class loader lookup path for the class, or the parent ClassLoader looks for the path.

If a class loader and all of its parent ClassLoader cannot find the desired class, the system throws an Classnotfoundexecption exception or noclassdeffounderror error.

Delegate mode for Class loader

The ClassLoader has an important property: the delegate pattern (delegation mode, sometimes called load mode: Classloader mode). The delegate mode determines whether the ClassLoader finds a class by looking for the classpath specified by the ClassLoader itself or the classpath on the parent class loader first.

The class loader's delegate mode has two values:

• Parent_first: When loading a class, first try to find and load the class on the classpath of the parent class loader before looking for the load class from the class loader's own classpath.
• Parent_last: When loading a class, first try to find the load class from its own classpath, and then try the parent ClassLoader classpath if it is not found.

With the concept of a delegate pattern, we can more flexibly configure how classes are loaded and looked up in the class loader hierarchy. Table 1 shows the definition of the delegate pattern for each class loader in the WebSphere ClassLoader hierarchy, and gives the life cycle of classes within different classloader.

Note: In the table above,"JVM class loader" because at the top of the ClassLoader, it has no parent classloader, so its delegate mode is N/A,"WebSphere Extensions Class loader" and " The delegate mode of the WebSphere Lib/app class loader is fixed to the value in the table, not configurable, and the delegate mode of the other classloader can be configured.

WebSphere the class loader policy in

There are some related configurations for the ClassLoader in WebSphere, called ClassLoader policies (classloader policy). The ClassLoader policy refers to the class loader's stand-alone policy (classloader isolation policy), and we can define the class loader for was and the application independently, through the ClassLoader policies setting.

Each of the was can configure its own application class loader policy, andeach application in was can also configure its own Web module ClassLoader policy, as described in the following two strategies.

1 . Application Server (was) configuration: Application class loader policy

The application server has two configurations for the application ClassLoader policy:

• Single: All applications on the entire application server use the same classloader. In this configuration, each application no longer has its own classloader.
• Multiple: Each application on the application server uses its own classloader.

2 . Application configuration:Web module class loader policy

There are two configurations for the Web Module class loader in your application:

• Application: All utility jar packages and Web modules within the entire application use the same classloader.
• Module: Each WEB module within the application uses its own classloader. The class loader for the application still exists and is responsible for loading classes other than the Web module in the application, including all utility jar packages.

As can be seen from the above definition, some class loaders on the class loader hierarchy may not exist under the configuration of the different ClassLoader policies. For example, in the case where the application ClassLoader policy of the application server is defined as single, the class loader for the application will not exist, and all applications on the same application server will share the same classloader, which means that the classes between the different applications are shared, A class with the same name cannot exist between applications.

4 Jboss boot and load process

Detailed reference: http://tech.it168.com/j/2007-06-27/200706271521984.shtml

1) Org.jboss.Main.main (string[]) for the entrance .

2) The main function creates a thread group called "JBoss" , and then creates a thread that belongs to the group and executes the boot method in the threads.

3) The boot method first deals with the parameters in the main function (and some other system environment settings ) and then creates the Org.jboss.system.server.ServerLoader with the properties of the system. Example [New ServerLoader (props)].

4) ServerLoader registers Jboss related classpath , including XML parser , Jboss-jmx.jar, Concurrent.jar and some additional classpath .

5)         serverloader  Create  jboss server  instance  load (ClassLoader)   method Lang= "en-us" >.  parameter  classloader  is  classloader ParentCL = Thread.CurrentThread (). Getcontextclassloader ()   Gets the current thread of the class loader  .  created server  instance is  org.jboss.system.server.server  Interface implementation   load (ClassLoader)   Details of the method:

Ø Create an instance of URLClassLoader with the jar package and the classpath registered in ServerLoader , and use the incoming ClassLoader as the urlclassloader parent.

the implementation class of the Server interface is determined by the system attribute Jboss.server.type , which is org.jboss.system.server.ServerImpl by default .

Ø URLClassLoader An instance of the Server interface implementation through the parameterless constructor . Set the class loader of the current thread to the URLClassLoader before loading , and then reset the previous incoming ClassLoader.

6) The Server instance is initialized with System Properties [Server.init (props)].

7) service Start [Server.start ()]. The default implementation of the START process is as follows :

Ø the current thread type loader is placed to load the ClassLoader of the Server interface implementation instance .

Ø in the jboss domain , the mbeanserver instance is created through the mbeanserverfactory creatembeanserver (String) method .

Ø Registration of Serverimpl and serverconfigimpl two mbean on the Mbean Server.

Ø Initializes a unified class loading Repository (Unified class loader repository), which is used to load the server configuration directory and its jar files under other optional directories . For each jar file and class directory, create a corresponding C10>org.jboss.jmx.loading.unifiedclassloader instances , and register them in a unified warehouse. One of the Unifiedclassloader The instance is set to the ClassLoader of the current thread context . [?: This effectively makes allunifiedclassloaders available through the thread context class loader.]

Ø Next Create an MBean instance of Org.jboss.system.ServiceController . ServiceController manages the life cycle of the JBoss Mbean service .

Tomcat, WebSphere, and JBoss class loading mechanisms