Tomcat breaks the parent delegation mechanism to achieve isolation of Web applications

Tomcat breaks parent delegation through the custom class loader WebAppClassLoader, that is, it rewrites the findClass method and loadClass method of the JVM class loader ClassLoader to give priority to loading classes in the Web application directory.

Tomcat is responsible for loading our Servlet class and the JAR package that the Servlet depends on. Tomcat itself is also a Java program, so it needs to load its own classes and dependent JAR packages.

If you run two web applications on Tomcat and they have Servlets with the same name but different functions, Tomcat needs to load and manage these two Servlet classes with the same name at the same time to ensure that they do not conflict. Therefore, classes between Web applications need to be isolated

If two web applications both depend on the same third-party jar, such as Spring, then after the Spring jar is loaded into memory, Tomcat must ensure that the two web applications can share it, that is, the Spring jar is only loaded once. Otherwise, as the number of third-party jars increases, the JVM's memory will be too large.
Therefore, like the JVM, it is necessary to isolate the classes of Tomcat itself and the classes of the Web application.

Tomcat class loader hierarchy

Tomcat's class loader hierarchy

The first three are loader instance names, not class names.

WebAppClassLoader

If you use the JVM's default AppClassLoader to load a Web application, AppClassLoader can only load one Servlet class. When loading a second Servlet class with the same name, AppClassLoader returns the Class instance of the first Servlet class.
Because in the eyes of AppClassLoader, a Servlet class with the same name can only be loaded once.

Therefore, Tomcat customizes a class loader WebAppClassLoader and creates a WebAppClassLoader instance for each web application.

Each Web application's own Java classes and dependent JAR packages are placed in WEB-INF/classes and WEB-INF/lib directories respectively, and are all loaded by WebAppClassLoader.

The Context container component corresponds to a Web application. Therefore, each Context container creates and maintains a WebAppClassLoader loader instance.
Classes loaded by different loader instances are considered different classes, even if they have the same class name. This is equivalent to creating mutually isolated Java class spaces inside the JVM. Each Web application has its own class space, and Web applications are isolated from each other through their own class loaders.

SharedClassLoader

How can two web applications share library classes and not load the same class repeatedly?

Each child loader of the parent delegation mechanism can load classes through the parent loader, so consider putting the classes to be shared in the loading path of the parent loader.

This is how applications share JRE core classes.
Tomcat has created a class loader SharedClassLoader as the parent loader of WebAppClassLoader to load classes shared between Web applications.

If WebAppClassLoader does not load a class, it entrusts the parent loader SharedClassLoader to load the class. SharedClassLoader will load the shared class in the specified directory and then return it to WebAppClassLoader to solve the sharing problem.

CatalinaClassLoader

How to isolate Tomcat's own classes from the web application's classes?

Sibling relationship: Two class loaders are parallel. They may have the same parent loader, but the classes loaded by the two sibling class loaders are isolated.

Therefore, Tomcat created CatalinaClassLoader to load Tomcat's own classes.

The question is, what should we do when some classes need to be shared between Tomcat and various web applications?

CommonClassLoader

Sharing still relies on the father-son relationship.
Add another CommonClassLoader as the parent loader of CatalinaClassLoader and SharedClassLoader.

The classes that CommonClassLoader can load can be used by CatalinaClassLoader and SharedClassLoader, while the classes that CatalinaClassLoader and SharedClassLoader can load are isolated from each other. WebAppClassLoader can use classes loaded by SharedClassLoader, but each WebAppClassLoader instance is isolated from each other.

Spring loading problem

By default, if a class is loaded by class loader A, the dependent classes of the class are also loaded by the same class loader.
For example, Spring, as a Bean factory, needs to create instances of business classes and load these classes before creating business class instances. Spring loads business classes by calling Class.forName. Let's take a look at the source code of forName:

public static Class<?> forName(String className) {
    Class<?> caller = Reflection.getCallerClass();
    return forName0(className, true, ClassLoader.getClassLoader(caller), caller);
}

The caller, Spring's loader, will be used to load the business class.

JAR files shared between web applications can be loaded by SharedClassLoader to avoid repeated loading. As a shared third-party jar, Spring is loaded by SharedClassLoader. Spring also needs to load business classes. According to the previous rule, the class loader that loads Spring will also be used to load business classes. However, the business classes are in the Web application directory, not in the loading path of SharedClassLoader. What should I do?

Thread context loader

So there is a thread context loader, a class loader transfer mechanism. Because the class loader is stored in the thread private data, as long as it is the same thread, once the thread context loader is set, the class loader can be taken out and used in the subsequent execution of the thread. Therefore, Tomcat creates a WebAppClassLoader class loader for each Web application and sets the thread context loader in the thread that starts the Web application. In this way, Spring takes out the thread context loader at startup to load the Bean. The code for Spring thread context loading is as follows:

cl = Thread.currentThread().getContextClassLoader();

In the startup method of StandardContext, the context loader of the current thread is set to WebAppClassLoader.

At the end of the start method, the thread's context loader is restored:

Thread.currentThread().setContextClassLoader(originalClassLoader);

Why is this?

The thread context loader is actually a private data of the thread, which is bound to the thread. After the thread completes starting the Context component, it will be recycled to the thread pool and then used to do other things. In order not to affect other things, the previous thread context loader needs to be restored.
Prioritize loading the web application class, and then change it back to the original one after loading is completed.

The thread context loader specifies the subclass loader to load a specific bridge class, such as the JDBC Driver.

Summarize

The Tomcat Context component creates a WebAppClassLoader class loader for each Web application. Since the classes loaded by different class loader instances are isolated from each other, the purpose of isolating Web applications is achieved. At the same time, third-party JAR packages are shared through parent loaders such as CommonClassLoader. How does a shared third-party JAR package load classes for a specific web application? This can be solved by setting the thread context loader.

Java class files and JAR packages shared by multiple applications are placed in the shared directories specified by the Web container:

CommonClassLoader
Corresponds to <Tomcat>/common/*

CatalinaClassLoader
Corresponds to <Tomcat >/server/*

SharedClassLoader
Corresponds to <Tomcat >/shared/*

WebAppClassloader
Corresponds to <Tomcat >/webapps/<app>/WEB-INF/*

You can configure the loading paths of various class loaders in the Catalina.properties file in the Tomcat conf directory.

When a ClassNotFound error occurs, you should check that your class loader is correct.
The thread context loader can not only be used in Tomcat and Spring class loading scenarios, but also can be used when the core framework class needs to load specific implementation classes. For example, the JDBC we are familiar with loads different database drivers through the context class loader.

This is the end of this article about how Tomcat breaks the parent delegation mechanism to achieve isolated Web applications. For more relevant content about Tomcat isolated Web applications, 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!