Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to configure the Server file of Tomcat. The editor thinks it is very practical, so I share it for you as a reference. I hope you can get something after reading this article.

1. A server.xml configuration instance

Server.xml is located in the $TOMCAT_HOME/conf directory; here is an instance of server.xml. Later, combined with this example, we will explain the meaning and function of each element in server.xml; in the process of reading the following chapters, you can compare with the xml document for easy understanding.

II. Element classification and overall structure of server.xml documents

1. Overall structure

The overall structure of server.xml is as follows:

In this structure, only the core components of Tomcat are given. In addition to the core components, Tomcat has some other components. Let's describe the classification of components.

2. Element classification

The elements in the server.xml file can be divided into the following four categories:

(1) Top-level elements: and

The element is the root element of the entire configuration file, and the element represents an Engine element and a set of Connector elements associated with it.

(2) Connector:

Represents the interface on which an external client sends requests to a specific Service; it is also the interface on which an external client receives a response from a particular Service.

(3) containers:

The function of the container is to process the incoming request received by the Connector and generate the corresponding response. Engine, Host, and Context are all containers, but they are not parallel relationships, but parent-child relationships: Engine contains Host,Host and Context. An Engine component can handle all requests in Service, a Host component can handle all requests sent to a specific virtual host, and a Context component can handle all requests from a particular Web application.

(4) embedded components: components that can be embedded in a container.

In fact, Server, Service, Connector, Engine, Host, and Context are the most important and core Tomcat components, and other components can be classified as embedded components.

The role of the core components in Tomcat and their relationship to each other are described in detail below.

III. Core components

This section will introduce the role, characteristics and configuration of each core component.

1 、 Server

The Server element is at the top level and represents the entire Tomcat container, so it must be the outermost element in the server.xml. There can be one or more Service elements in a Server element.

In the example in the * * section, there is an element in the outermost layer, and the shutdown attribute represents the instruction to turn off Server; the port attribute indicates the port number on which the Server receives the shutdown instruction, and the port can be disabled by setting it to-1.

The main task of Server is to provide an interface for the client to access the Service collection, while maintaining the declaration cycle of all the Service it contains, including how to initialize, how to end the service, and how to find the Service that the client wants to access.

2 、 Service

The function of Service is to wrap a layer around Connector and Engine, assemble them together and provide services. A Service can contain multiple Connector, but only one Engine;, where the role of Connector is to receive requests from the client, and the role of Engine is to process incoming requests.

In the example in the * * section, Server contains a Service named "Catalina". In fact, Tomcat can provide multiple Service, and different Service listens to different ports, as described later.

3 、 Connector

The main function of Connector is to receive connection requests, create Request and Response objects to exchange data with the requester, then assign threads to Engine to process the request, and pass the resulting Request and Response objects to Engine.

By configuring Connector, you can control the protocol and port number of the request Service. In the example in the * * section, Service contains two Connector:

(1) by configuring the first Connector, the client can access the Tomcat using the http protocol through the 8080 port number. Where the protocol attribute specifies the protocol of the request, port specifies the port number of the request, and redirectPort indicates that when https is required and the request is http, redirecting to Connector,connectionTimeout with port number 8443 indicates the connection timeout.

In this example, Tomcat listens for HTTP requests using port 8080 instead of the formal port 80; in fact, in a formal production environment, Tomcat often listens on port 8080 instead of port 80. This is because in a production environment, Tomcat is rarely opened to receive requests directly, but a proxy server (such as nginx) is added between the Tomcat and the client to forward requests, load balance, handle static files, and so on. When accessing Tomcat through a proxy server, it is in the LAN, so port 8080 is generally still used.

(2) by configuring the second Connector, the client can access the Tomcat using the AJP protocol through the 8009 port number. The AJP protocol is responsible for establishing connections with other HTTP servers, such as Apache; this connector is needed when integrating Tomcat with other HTTP servers. The reason for using Tomcat to integrate with other servers is that Tomcat can be used as an Servlet/JSP container, but it is slower to process static resources than HTTP servers such as Apache and IIS; therefore, Tomcat is often integrated with Apache, the former as a Servlet container, the latter handles static resources, and the AJP protocol is responsible for the connection between Tomcat and Apache. The principle of integration of Tomcat and Apache is shown in the following figure.

For more information about Connector, you can refer to my other article: explain the number of connections and thread pool of tomcat in detail.

4 、 Engine

There is one and only one Engine component in the Service component; Engine is the request processing component in the Service component. The Engine component receives the request from one or more Connector and processes it, and returns the completed response to the Connector, which is finally delivered to the client.

As mentioned earlier, Engine, Host, and Context are all containers, but they are not parallel relationships, but parent-child relationships: Engine contains Host,Host and Context.

In the example in the * * section, the configuration statement for Engine is as follows:

Where the name attribute is used for logging and error messages, which should be * * throughout the Server. The defaultHost attribute specifies the default host name, and when the host name specified by the local request does not exist, the host specified by defaultHost is used for processing; therefore, the value of defaultHost must match the value of the name property of a Host component in Engine.

5 、 Host

(1) Engine and Host

Host is a child container of Engine. One or more Host components can be embedded in Engine components, and each Host component represents a virtual host in the Engine. There is at least one Host component, and the name of one of them must match the defaultHost property of the Engine component.

(2) the function of Host

The role of the Host virtual host is to run multiple Web applications (one Context represents a Web application) and is responsible for installing, deploying, starting and ending each Web application.

The virtual host represented by the Host component corresponds to a network name entity in the server (such as "www.javastack.cn", or the IP address "116.25.25.25"); in order for users to connect to the Tomcat server through the network name, this name should be registered on the DNS server.

Clients usually use a hostname to identify the server they want to connect to; that hostname is also included in the HTTP request header. Tomcat extracts the hostname from the HTTP header and looks for a host whose name matches. If there is no match, the request is sent to the default host. Therefore, the default host does not need to be a network name registered in the DNS server, because any request that does not match all Host names is routed to the default host.

(3) configuration of Host

In the example in the * * section, the configuration of Host is as follows:

The properties configured in it are described below:

The name attribute specifies the hostname of the virtual host, and the name property of one and only one Host component in an Engine matches the defaultHost property of the Engine component; in general, the hostname needs to be a network name registered with the DNS server, but the defaultHost specified by Engine is not required, for reasons explained earlier.

UnpackWARs specifies whether to extract the WAR file representing the Web application; if it is true, run the Web application through the decompressed file structure; if it is false, run the Web application directly using the WAR file.

The autoDeploy and appBase attributes of Host are related to the automatic deployment of Web applications in Host. In addition, the xmlBase and deployOnStartup attributes that do not appear in this example are also related to the automatic deployment of Web applications, which will be described in the next section (Context).

6 、 Context

(1) the function of Context

The Context element represents a Web application running on a specific virtual host. In a later article, Context, applications, or Web applications are mentioned, which all refer to Web applications. Each Web application is based on the WAR file, or the directory corresponding to the extracted WAR file (here called the application directory).

Context is a child container of Host, and any number of Context elements can be defined in each Host.

In the example in the * * section, you can see that the configuration of the Context element does not appear in the server.xml configuration file. This is because Tomcat enables automatic deployment, and Web applications are not configured for static deployment in server.xml, but are automatically deployed by Tomcat through specific rules. Here is a look at the mechanism for Tomcat to automatically deploy Web applications.

(2) automatic deployment of Web applications

Configuration of Host

To enable automatic deployment of Web applications, you need to configure the virtual host in which the host resides; it is configured by the deployOnStartup and autoDeploy attributes of the Host element mentioned earlier. If deployOnStartup and autoDeploy are set to true, tomcat initiates automatic deployment: when an update of a new Web application or Web application is detected, the deployment (or redeployment) of the application is triggered. The main difference between the two is that when deployOnStartup is true, Tomcat checks Web applications at startup, and all Web applications detected are regarded as new applications; when autoDeploy is true, Tomcat periodically checks for updates of new Web applications or Web applications at run time. In addition, the two treatments are similar.

By configuring deployOnStartup and autoDeploy, you can turn on the virtual host to automatically deploy Web applications; in fact, automatic deployment depends on checking for new or changed Web applications, while the appBase and xmlBase of the Host element set directories to check for Web application updates.

Where the appBase attribute specifies the directory where the Web application is located, and the default value is webapps, which is a relative path that represents the webapps folder under the Tomcat root directory.

The xmlBase attribute specifies the directory where the XML configuration file of the Web application is located, and the default value is conf//,. In the example in the * section, the default value for the xmlBase of the host localhost is $TOMCAT_HOME/conf/Catalina/localhost.

Check for Web application updates

A Web application may include the following files: the XML configuration file, the WAR package, and an application directory (which contains the file structure of the Web application); where the XML configuration file is located in the directory specified by xmlBase, and the WAR package and application directory are located in the directory specified by appBase.

Tomcat scans in the following order to check for application updates:

A. scan the XML configuration file under the xmlBase specified by the virtual host

B. Scan the WAR file under the appBase specified by the virtual host

C. Scan the application directory under appBase specified by the virtual host

Configuration of elements

The most important attributes of the Context element are docBase and path, and the reloadable attribute is also more common.

DocBase specifies the WAR package path, or application directory, used by the Web application. It should be noted that in the automatic deployment scenario (the configuration file is located in xmlBase), docBase is not in the appBase directory, so you need to specify it. If the WAR package or application directory specified by docBase is in docBase, you do not need to specify it, because Tomcat will automatically scan the WAR package and application directory in appBase, and specifying it will cause problems.

Path specifies the context path to access the Web application. When the request arrives, Tomcat selects the Web application to process the corresponding request according to the matching degree between the path attribute of the Web application and the URI. For example, if the path attribute of the Web application app1 is "/ app1" and the path attribute of the Web application app2 is "/ app2", the request / app1/index.html will be processed by app1, while the request / app2/index.html will be processed by app2. If the path attribute of a Context element is "", then the Context is the default Web application for the virtual host; when the requested uri does not match all path, the default Web application is used to process it.

However, it should be noted that in an automatic deployment scenario (the configuration file is located in xmlBase), the path attribute cannot be specified, and the path attribute is automatically derived from the file name of the configuration file, the file name of the WAR file, or the name of the application directory. If a Web application is scanned and the app1.xml under the xmlBase directory or the app1.WAR or app1 application directory under the appBase directory is found, the path attribute of the Web application is "app1". If the name is not app1 but ROOT, then the Web application is the default Web application for the virtual host, and the path attribute is deduced as "".

The reloadable attribute indicates whether tomcat monitors changes to class files in the WEB-INF/classes and WEB-INF/lib directories at run time. If the value is true, then the reload of the Web application will be triggered when the class file changes. In a development environment, reloadable is set to true for debugging; however, setting it to true in a production environment puts performance pressure on the server, so the default value of the reloadable parameter is false.

Here's an example of the XML configuration file app1.xml under xmlBase for automatic deployment:

In this example, docBase is located outside the appBase directory of Host; the path property is not specified, but is automatically deduced to "app1" according to app1.xml; and because it is in the development environment, reloadable is set to true, which is convenient for development and debugging.

Example of automatic deployment

The most typical automatic deployment is that after we install Tomcat, there are the following folders in the $TOMCAT_HOME/webapps directory:

When we start Tomcat, we can use http://localhost:8080/ to access Tomcat. In fact, we can access Web applications corresponding to ROOT. We can also access docs applications through http://localhost:8080/docs. In the same way, we can access examples/host-manager/manager Web applications.

(3) static deployment of Web applications in server.xml

In addition to automatic deployment, we can also statically deploy Web applications through elements in server.xml. Static deployment and automatic deployment can coexist. In practical applications, static deployment is not recommended because server.xml is a resource that cannot be dynamically reloaded. Once the server is started, to modify this file, you have to restart the server to reload. Automatic deployment can be achieved through periodic scans while Tomcat is running, without the need to restart the server.

The Context element is used in server.xml to configure the Web application, and the Context element should be in the Host element. Examples are as follows

DocBase: when statically deployed, docBase can be in the appBase directory or not; in this case, docBase is not in the appBase directory.

Path: when you deploy statically, you can explicitly specify the path property, but it is still subject to strict restrictions: you can set the path property only when automatic deployment is completely turned off (deployOnStartup and autoDeploy are both false) or when docBase is not in appBase. In this case, docBase is not in appBase, so the path property can be set.

The use of the reloadable property is the same as in automatic deployment.

IV. The association of core components

1. Overall relationship

The overall relationship between the core components is described in the previous section, which is summarized here:

The Server element is at the top level and represents the entire Tomcat container; there can be one or more Service elements in a Server element.

Service wraps Connector and Engine with a layer and assembles them to provide services. A Service can contain multiple Connector, but only one Engine;Connector receives the request, and the Engine processes the request.

Engine, Host, and Context are all containers, and Engine contains Host,Host and contains Context. Each Host component represents a virtual host in the Engine; each Context component represents a Web application running on a particular Host.

2. How to determine who handles the request?

When a request is sent to the host where the Tomcat is located, how do you determine which Web application will eventually process the request?

(1) Select Service and Engine based on protocol and port number

The Connector component in Service can receive requests from a specific port, so when Tomcat starts, the Service component listens on the specific port. In the example in the * * section, the Service Catalina listens on port 8080 (based on HTTP protocol) and port 8009 (based on AJP protocol). When the request comes in, the Tomcat can select the Service;Service to process the request based on the protocol and port number. Once selected, the Engine is determined.

By configuring multiple Service in Server, you can access different applications deployed on the same machine through different port numbers.

(2) Select Host based on domain name or IP address

After the Service is determined, Tomcat looks in the Service for a Host whose name matches the domain name / IP address to process the request. If it is not found, the request is processed using the defaultHost specified in the Engine. In the example in the * * section, since there is only one Host (the name attribute is localhost), all requests for that Service/Engine are handed over to that Host for processing.

(3) Context/Web application is selected according to URI

This is explained in detail in the Context section: Tomcat selects the Web application to process the request according to the matching degree between the path attribute of the application and the URI, which will not be discussed here.

(4) examples

Take the request http://localhost:8080/app1/index.html as an example, first select Service; by protocol and port number (http and 8080), then select Host; by hostname (localhost), and then select Web application by uri (/ app1/index.html).

3. How to configure multiple services

By configuring multiple Service services in Server, you can access different Web applications deployed on the same machine through different port numbers.

The method of configuring multiple services in server.xml is very simple, which is divided into the following steps:

(1) copy the element and put it after the current.

(2) modify the port number: modify the port attribute of the element according to the port number you need to listen to. You must make sure that the port is not occupied by other processes, otherwise Tomcat will report an error when it starts and cannot access the Web application through this port.

Take Win7 as an example, you can use the following methods to find out whether a port is occupied by another process: netstat-aon | findstr "8081" finds that port 8081 is occupied by a process with a PID of 2064, and tasklist | findstr "2064" finds that the process is FrameworkService.exe (this is the process of McAfee antivirus software).

(3) modify the name attribute of Service and Engine

(4) modify the appBase attribute of Host (such as webapps2)

(5) Web applications still use automatic deployment

(6) copy the Web application (WAR package or application directory) to be deployed to the new appBase.

Take the server.xml in * as an example. Multiple Service configurations are as follows:

Then copy the docs directory under the original webapps to webapps2, and you can access the docs application through the following two APIs:

Http://localhost:8080/docs/

Http://localhost:8084/docs/

5. Other components

In addition to the core components, many other components can be configured in server.xml. The following only describes the components that appear in some of the examples. If you want to learn more, you can check the Tomcat official documentation.

1 、 Listener

A component defined by a Listener (that is, a listener) that can perform specific actions when a particular event occurs; the listening event is usually the start and stop of the Tomcat.

Listeners can be in Server, Engine, Host, or Context, and in this case listeners are all in Server. In fact, all six listeners defined in this example can only exist in the Server component. Listeners do not allow other components to be embedded.

The most important property that the listener needs to configure is className, which specifies the listener's specific implementation class, which must implement the org.apache.catalina.LifecycleListener interface.

The listeners configured in the example are described below in turn:

VersionLoggerListener: when Tomcat starts, this listener records information about Tomcat, Java, and the operating system. The listener must be configured with * * listeners.

When AprLifecycleListener:Tomcat starts, check the APR library and load it if it exists. APR, or Apache Portable Runtime, is the Apache portable runtime that enables high scalability, high performance, and better integration with local server technology.

JasperListener: initializing Jasper,Jasper before the Web application starts is a JSP engine, parsing JSP files that JVM doesn't know into java files, and then compiling them into class files for JVM to use.

JreMemoryLeakPreventionListener: related to memory leaks caused by classloaders.

GlobalResourcesLifecycleListener: through this listener, initialize

The global JNDI resource defined in the tag; without this listener, no global resource can be used.

It will be introduced later.

ThreadLocalLeakPreventionListener: when the Web application is stopped due to a memory leak caused by thread-local, the listener triggers updates to threads in the thread pool. When the thread completes the task and is withdrawn from the thread pool, the active thread will be updated one by one. This listener is valid only if the renewThreadsWhenStoppingContext attribute of the Web application (that is, the Context element) is set to true.

2. GlobalNamingResources and Realm

In the example of * part, the Realm component is defined under the Engine component:

Realm, which can be understood as a "domain"; Realm provides a mapping relationship between user passwords and web applications, thus achieving the role of role security management. In this example, the configuration of Realm is implemented using a resource with name as UserDatabase. The resource is configured with GlobalNamingResources in the Server element:

The GlobalNamingResources element defines the global resource, and as you can see from the configuration, this configuration is achieved by reading $TOMCAT_HOME/ conf/tomcat-users.xml.

For more information on Tomcat domain management, please refer to: realm Domain Management

3 、 Valve

In the example in the * * section, the Valve component is defined within the Host element:

The word Valve means "valve" and in Tomcat represents a component on the request processing pipeline; Valve can be associated with a Tomcat container (Engine, Host, or Context).

Different Valve have different features, so let's take a look at the AccessLogValve that appears in this example.

The role of AccessLogValve is to log all requests processed in its container. In this case, Valve is placed under Host and all requests processed by that Host can be recorded. The log recorded by AccessLogValve is the access log, and daily requests are written to a log file. AccessLogValve can be associated with Engine, Host, or Context; in this case, there is only one Engine,Engine, only one Host,Host and only one Context, so the effect of AccessLogValve under three containers is similar.

The AccessLogValve attribute in this example is configured using the default configuration. The role of each attribute in AccessLogValve is described below:

(1) className: specifies the type of Valve, which is the most important attribute; in this case, it is specified as an AccessLogValve through this attribute.

(2) directory: specify the location where the log is stored. In this case, the log is stored in the $TOMCAT_HOME/logs directory.

(3) prefix: specifies the prefix of the log file.

(4) suffix: the suffix of the log file is specified. With the configuration of directory, prefix, and suffix, you can see the log files shown below in the $TOMCAT_HOME/logs directory.

(5) pattern: specify the format of the log. In this example, the meaning of each item is as follows:

% h: remote hostname or IP address; if there is a reverse proxy server such as nginx for request distribution, the hostname / IP address represents nginx, otherwise it represents the client. The meaning of remote is similar later and will not be explained any more.

% l: remote logical user name, all "-", can be ignored.

% u: authorized remote user name, if not, "-".

% t: time of visit.

% r: the requested * * line, that is, the request method (get/post, etc.), uri, and protocol.

% s: response status, 200404, etc.

% b: the amount of data in the response, excluding the request header, or ""-if 0.

For example, here is a record in the access log:

In the configuration of pattern, in addition to the above, a very commonly used option is% D, which means the processing time of the request (in milliseconds), which is very helpful for statistical analysis of the processing speed of requests.

Developers can make full use of the access log to analyze problems and optimize applications. For example, analyzing the proportion of interfaces accessed in the access log can not only provide data support for requirements and operators, but also make their own optimization targeted; analyze the response status codes of each request in the access log. You can know the success rate of server requests and identify problematic requests. By analyzing the response time of each request in the access log, you can find out the slow request and optimize the response time as needed.

On "how to configure the Server file of Tomcat" this article is shared here, I hope the above content can be of some help to you, so that you can learn more knowledge, if you think the article is good, please share it out for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.