Tomcat Architecture (IV)

8. Standard coverage mechanism

J2SE 1.4 and 1.5contains a Java API for XML processing parsers . the Bootstrap class Loader Loads this parser's class file, so this parser takes precedence over any one installed in CLASSPATHthe parser is loaded, even if you have installed a new version of the parser. The standard override mechanism allows you to overridejava_home/lib/endorsedsome specific classes in the folder ( For example ,CORBAand theJAXPclass ) . the Bootstrap class loader will load these classes first. To learn more about this mechanism, please visit http://java.sun.com/j2se/1.5.0/docs/guide/standards/.

Some interesting considerations for class loading are as follows:

JVM

A classloader can only see the directories of classes located above it's hierarchy. For example, a extension jar You cannot use class files in the application classpath. This is because extension The classes in the folder can only see extension class loader and bootstrap class loader can load classes.

class.getclassloader () to get.

? each thread has a context class loader that uses the Thread.CurrentThread (). Getcontextclassloader () you can view the. Each time a new thread is created, the context class loader for this new thread is set to its creation thread. Main () A thread's ClassLoader is an application class loader that automatically propagates down to each worker thread, unless you call Thread.CurrentThread (). Setcontextclassloader () to intervene.

9. Java EE class loading

This pattern seems awkward in the context of Java EE.

First, the servlet container needs to provide a restrictive environment for Web applications.

If a servlet uses the System class loader directly, the servlet will see all the classes under the path used in the JVM command used to start Tocmat. Calss. This is a potential security risk because a malicious application (an app deployed on the same host's host) may be allowed to load a class of web apps onto its sibling node. Because of this, each Web application must have its own ClassLoader, which is located in the root node of the ClassLoader tree and has the ability to load the classes found in the directory web-inf/classes and Web-inf/lib of the Web App.

When the requested class is a Java standard, the custom ClassLoader will only delegate its parent ClassLoader to load, and if a Web application needs other classes, the custom ClassLoader is not going to delegate its parent class to load, but first check web-inf/classes and web-inf/ Whether the class is included in Lib. The ClassLoader is delegated to its parent ClassLoader to load only if both directories are not found, and the load of the parent ClassLoader follows the standard delegate mode. (for class loading, see the end of the article).

Additional class loader for Tomcat

During the boot process, tomcat first clears the classpath and points it back to Catalina_home/bin/bootstrap.jar (the class that Tomcat starts), Tomcat-juli (log function), Tools.jar (JSP compilation feature) to mask the System class loader (systems ClassLoader). This allows the system ClassLoader to function only when a small number of Tomcat special classes are loaded.

At the same time, Tomcat changed the support directory and pointed it back to the catalina_home/endorsed directory.

Under its custom ClassLoader, Tomcat adds its own classloader, including the server ClassLoader (server class loader), the shared class loader (sharer class loader), and the generic ClassLoader (Common class Loader) and a Web application class loader for each deployed application.

When a Web application needs to load a class, a request is sent first to the Web app's ClassLoader, which is responsible for loading the classes in the Web App Web-inf/classes and web-inf/lib two directories.

The Web application ClassLoader first requests the system ClassLoader to allow each layer of ClassLoader to find all Java core classes. When the requested class is not found, the Web App ClassLoader attempts to locate the requested class from its own class library, or if it is still not found, it delegates the generic classloader or, if there is a shared ClassLoader, the shared class loader to load.

The shared class loader and server ClassLoader are not installed by default, but we can edit the catalina_home/conf/ The Catalina.properties file opens the shared class loader and the server class loader by adding Shared.loader and Server.loader, while the common ClassLoader monitors the contents of the Catalina_home/lib directory , this is the jar package for some cicada pupa, such as Servlet-api.jar, Jasper.jar, Coyote.jar, and Jsp-api.jar. In addition, classes located in shared directories will be visible to all web apps, but not Tomcat's inner classes, and classes placed in the server's loader directory will only be visible to the tomcat inner class.

10. Class overloading in Web applications

A Web application-specific ClassLoader that enables Tomcat to support class overloading.

When the context needs to be newly deployed or when a class needs to be overloaded (for example, when a recompiled class file is added to the web-inf/classes directory), the entire Web application's ClassLoader is discarded and a new instance branch is created to load all classes of the Web App. The new class load is used to service the subsequent request.

11, Logger

The logger element in Server.xml has been deprecated in Tomcat5.5, so the log is generated in TOMCAT6 based on the log API introduced in Java1.4.

However, the Java log can only be configured at the entire JVM level, but not individually for each classloader. In order for each Web application to allow different configuration files, Tomcat implements a custom Java log, which is known as Juli, which is located in Catalina_home/bin/tomcat-juli.jar.

The global configuration file Catalina_home/conf/logging.properties controls the log settings. In addition, each Web app can have its own log profile, Web-inf/classes/logging.properties.

As shown, the logs are made up of components:

● Logger : All log requests are entered into the Logger object. These objects are arranged hierarchically, their roots are at the root logger, and this hierarchy reflects the package structure as well. In this hierarchy, the properties can be bound to any level, and the logger subclass inherits the parent class property.

● Handler : Specifies where the log messages should be sent. Optional Consolehandler (writes the log to the console), Filehandler (writes the log to the file), Sockethandler (writes the log to the TCP socket).

● Level (log level): The log level includes: SEVERE, WARNING, INFO, CONFIG, FINE, Finer, FINEST, off (disabled), all (records all information), each level determines what type of message needs to be logged.

● Formatter (log formatting): This element determines what format the information is displayed in. Tomcat provides two formatting tools for Simpleformatter and Xmlformatter.

12. Resources (Resource)

Resources related to Web application contexts include static resources such as class files, HTML, JSPs, and CSS files. These resources may exist in a different format. By default, Tomcat supports locating resource files from a compressed file in the war format (the war package) or from an extracted war.

It is conceivable that a resource in a context can also be accessed from an alternative storage mechanism, such as a JDBC database. and resource components make it possible.

Tomcat also provides a directory service-based Jndi API that can support reading resources from unknown storage methods.

Summarize

There's a lot to be said here, and what we need to do now is to make ourselves understood in the Tomcat architecture Overview. In this article, we discuss some of the core components of Tomcat and see how a running Tomcat instance is built from a variety of top-level components, connectors (Connector), and nested components.

1. This article is translated by the programmer architecture

2. This article is translated from

Https://www.packtpub.com/books/content/overview-tomcat-6-servlet-container-part-2

3. Reprint Please be sure to indicate this article from: Programmer Architecture (No.:archleaner)

4. More articles please scan the code:

Tomcat Architecture (IV)