A brief discussion on how Tomcat breaks the parent delegation mechanism

We often encounter ClassNotFound exceptions, indicating that the JVM failed when trying to load a class.

To solve this exception, you need to know

• What is class loading?
• How JVM loads classes
• Why does ClassNotFound occur?

Think about how Tomcat loads and manages Servlets under Web applications?
Tomcat loads and manages Web applications through the Context component, so today I will analyze Tomcat's class loading mechanism in detail. But before that, we need to preview the JVM class loading mechanism. I will first answer the question raised at the beginning, and then talk about how Tomcat's class loader breaks Java's parent delegation mechanism.

JVM Class Loader

Java class loading is to load the bytecode format .class file into the method area of ​​JVM, and create a java.lang.Class object instance in the JVM heap to encapsulate the data and methods related to the Java class.

What is a Class object?
It can be understood as a template of the business class, and the JVM creates a specific business class object instance based on the template.

The JVM does not load all .class files at startup, but only loads the class when the program is used during operation.
JVM class loading is done by the class loader. JDK provides an abstract class ClassLoader:

public abstract class ClassLoader {

    //Each class loader has a parent loader private final ClassLoader parent;
    
    public Class<?> loadClass(String name) {
  
        // Find out if the class has been loaded Class<?> c = findLoadedClass(name);
        
        // If it has not been loaded if( c == null ){
          // [Recursion] Delegate to the parent loader to load if (parent != null) {
              c = parent.loadClass(name);
          } else {
              // If the parent loader is empty, find out whether the Bootstrap loader has been loaded c = findBootstrapClassOrNull(name);
          }
        }
        // If the parent loader fails to load, call its own findClass to load if (c == null) {
            c = findClass(name);
        }
        
        return c;
    }
    
    protected Class<?> findClass(String name){
       // 1. According to the passed class name, search for the class file in a specific directory and read the .class file into memory...
          
       // 2. Call defineClass to convert the byte array into a Class object return defineClass(buf, off, len);
    }
    
    // Parse the bytecode array into a Class object and implement it with native methods protected final Class<?> defineClass(byte[] b, int off, int len){
       ...
    }
}

The JVM's class loaders are hierarchical parent-child relationships, and each class loader holds a parent field pointing to the parent loader.

• defineClass tool method: calls the native method to parse the bytecode of the Java class into a Class object
• findClass is to find the .class file, which may come from the file system or the network. After finding it, read the .class file into the memory to get the bytecode array, and then call the defineClass method to get the Class object

loadClass first checks whether the class has been loaded. If so, it returns directly, otherwise it passes it to the parent loader to load.
This is a recursive call, that is, the child loader holds a reference to the parent loader. When a class loader needs to load a Java class, it will first delegate the loading to the parent loader, and then the parent loader will search for the Java class in its own loading path. When the parent loader cannot find it in its own loading range, it will return it to the child loader for loading. This is the parent delegation mechanism.

The working principle of JDK class loader is the same, the only difference is the loading path, that is, the path searched by findClass is different.
The parent delegation mechanism is to ensure the uniqueness of a Java class in the JVM. If you accidentally write a class with the same name as a JRE core class, such as Object, the parent delegation mechanism can ensure that the Object class in the JRE is loaded instead of the Object you wrote.
Because when AppClassLoader loads your Object class, it will delegate to ExtClassLoader to load, and ExtClassLoader will delegate to BootstrapClassLoader. BootstrapClassLoader finds that it has already loaded the Object class and will return directly without loading your Object class.

The parent-child relationship of class loaders is not implemented through inheritance. For example, AppClassLoader is not a subclass of ExtClassLoader, but the parent of AppClassLoader points to the ExtClassLoader object.
Therefore, if you customize the class loader, instead of inheriting AppClassLoader, you can inherit the ClassLoader abstract class and then rewrite findClass and loadClass.
Tomcat implements its own class loading through a custom class loader.
If you want to break the parent delegation, you only need to rewrite loadClass, because the default implementation of loadClass is the parent delegation mechanism.

Tomcat class loader

Tomcat's custom class loader WebAppClassLoader breaks the parent delegation mechanism:
First, try to load a class yourself. If it cannot find it, delegate it to the parent class loader. The purpose is to prioritize loading classes defined by the Web application itself.
Just rewrite two methods of ClassLoader:

findClass

public Class<?> findClass(String name) throws ClassNotFoundException {
    ...
    
    Class<?> clazz = null;
    try {
            //1. First search for the class in the Web application directory clazz = findClassInternal(name);
    } catch (RuntimeException e) {
           throw e;
       }
    
    if (clazz == null) {
    try {
            //2. If not found in the local directory, let the parent loader search clazz = super.findClass(name);
    } catch (RuntimeException e) {
           throw e;
       }
    
    //3. If the parent class is not found, throw ClassNotFoundException
    if (clazz == null) {
        throw new ClassNotFoundException(name);
     }

    return clazz;
}

Workflow

• First search for the class to be loaded in the local directory of the Web application
• If not found, it is handed over to the parent loader, that is, AppClassLoader
• If the parent loader also does not find the class, throw ClassNotFound

loadClass

public Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {

    synchronized (getClassLoadingLock(name)) {
 
        Class<?> clazz = null;

        //1. First check in the local cache whether the class has been loaded clazz = findLoadedClass0(name);
        if (clazz != null) {
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }

        //2. Check whether the system class loader has loaded clazz = findLoadedClass(name);
        if (clazz != null) {
            if (resolve)
                resolveClass(clazz);
            return clazz;
        }

        // 3. Try to load the class using ExtClassLoader class loader, why?
        ClassLoader javaseLoader = getJavaseClassLoader();
        try {
            clazz = javaseLoader.loadClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

        // 4. Try to search for the class in the local directory and load it try {
            clazz = findClass(name);
            if (clazz != null) {
                if (resolve)
                    resolveClass(clazz);
                return clazz;
            }
        } catch (ClassNotFoundException e) {
            // Ignore
        }

        // 5. Try to use the system class loader (that is, AppClassLoader) to load try {
                clazz = Class.forName(name, false, parent);
                if (clazz != null) {
                    if (resolve)
                        resolveClass(clazz);
                    return clazz;
                }
            } catch (ClassNotFoundException e) {
                // Ignore
            }
       }
    
    //6. The above processes all fail to load and throw an exception throw new ClassNotFoundException(name);
}

Workflow

• First check the local Cache to see if the class has been loaded
• That is, whether Tomcat's class loader has already loaded this class.
• If the Tomcat class loader has not loaded the class, check whether the system class loader has loaded it.
• If none of them exists, let ExtClassLoader load it to prevent the Web application's own classes from overwriting the JRE core classes.
• Because Tomcat needs to break the parent delegation, if a class called Object is customized in the Web application, if the Object class is loaded first, the JRE Object class will be overwritten. Therefore, the Tomcat class loader will try to load it with ExtClassLoader first, because ExtClassLoader will delegate to BootstrapClassLoader to load. BootstrapClassLoader finds that it has already loaded the Object class and directly returns it to the Tomcat class loader. In this way, the Tomcat class loader will not load the Object class under the Web application, avoiding overwriting the JRE core class.
• If ExtClassLoader fails to load, that is, JRE does not have this class, then search and load it in the local Web application directory.
• If there is no such class in the local directory, it means that it is not a class defined by the Web application itself, and it will be loaded by the system class loader. Please note here that the Web application is handed over to the system class loader through the Class.forName call, because the default loader of Class.forName is the system class loader.
• If the above loading process fails, throw ClassNotFound

It can be seen that the Tomcat class loader breaks the parent delegation and does not directly delegate to the parent loader at the beginning, but loads it in the local directory first.
However, to prevent local directory classes from overwriting JRE core classes, ExtClassLoader will be used to load them first.
So why not load it with AppClassLoader first?
If this is the case, it becomes parent delegation again, which is the mystery of the Tomcat class loader.

This is the end of this article about how Tomcat breaks the parent delegation mechanism. For more information about Tomcat’s parent delegation mechanism, please search for previous articles on 123WORDPRESS.COM or continue to browse the following related articles. I hope you will support 123WORDPRESS.COM in the future!