Shulou(Shulou.com)06/01 Report--

This article mainly introduces the example analysis based on the tomcat configuration file server.xml, which has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor take you to understand it.

1. Getting started example: virtual host provides web service

This example provides web services by setting up a virtual host, which is extremely simple because it is a starter example, as long as you change the $CATALINA_HOME/conf/server.xml file to the following. Most of these are set by default, except that two Host containers are added to the engine container.

In addition to the default localhost virtual host defined in engine, there are two other virtual hosts, www.longshuai.com and www.xiaofang.com, whose program directories are / www/longshuai and / www/xiaofang, respectively, so these two directories need to be established in advance. In addition, docBase is defined in context, and for the uri path / xuexi, its file system path is / www/ {longshuai,xiaofang} / xuexi directory, so you should also define the xuexi directory in the above two program root directories. In addition, logs are defined for each of the three virtual hosts, and their path is the relative path logs, relative to $CATALINA_HOME.

Then provide appBase directory and docBase directory.

Mkdir-p / www/ {longshuai,xiaofang} / xuexi

Then provide the index.jsp file for testing. The content is roughly as follows, copied to / www/ {longshuai,xiaofang} / and / www/ {longshuai,xiaofang} / xuexi/, respectively, and the output of the out.println is slightly modified to distinguish which index.jsp is being read.

Finally restart catalina.

Catalina.sh stopcatalina.sh start

Then add the host record of www. {longshuai,xiaofang} .com on the test host. For example, on windows, add the following record in C:\ Windows\ System32\ drivers\ etc\ hosts:

192.168.100.22 www.longshuai.com www.xiaofang.com

Tested in the browser, the results are as follows:

2. Basic description of tomcat architecture

As shown below:

Tomcat is highly modular, and there is a nested parent-child relationship between each module. If you use a configuration file to describe it, it can be roughly simplified as follows:

The server component is a component that works in the background to manage the tomcat instance. It can listen on a port from which the shutdown shutdown command can be remotely sent to the instance.

The service component is a logical component that binds connector and containor. With service, it means that services can be provided to the outside world, just like the service of a general daemon class service.

The connector component is a service listening component, which is used to listen for external requests and establish a TCP connection, then give the connection to the containor, and then transmit data from this connection, such as receiving http requests, sending http responses, and so on.

Containor is a container, which is not reflected in the configuration file. It contains four container class components: engine container, host container, context container, and wrapper container.

The engine container is used to receive the established TCP connection from the connector component, and also to receive the http request sent by the client and analyze the request, and then pass the relevant parameters to the matching virtual host according to the result of the analysis. Engine is also used to specify the default virtual host.

The host container defines a virtual host, and since tomcat is primarily a servlet container, each web application is specified with its root directory, appBase.

The context container corresponds to the processing of the servlet container. You can also specify the relevant wrapper container class, although the default standard wrapper class is generally used.

Finally, when the request is processed, context returns the response data to host, then to engine, then to connector, and finally to the client.

Put aside the behavior of tomcat as a servlet container. It roughly corresponds to the functions of apache and nginx. For example, take nginx as an example, the following is the configuration structure when nginx provides web services:

Server {listen PORT; server_name www.a.com; # corresponds to location / {# corresponds to context path= "" root html; # corresponds to docBase} location / xuexi {# corresponds to context path= "/ xuexi" root html/xuexi;}}

The connetcor component is similar to the listen instruction of nginx. The host container is similar to the server directive of nginx, and the name attribute in the host container is equivalent to the server_name directive of nginx. The engine component has no corresponding configuration item, but it also has the function of engine in nginx, such as the default virtual host, analyzing the URL to determine which virtual host to process the request. The context container is equivalent to the location instruction, the path attribute of the context container is equivalent to the uri matching path of location, and docBase is equivalent to the root instruction in location, that is, DocumentRoot.

Tomcat is roughly like this as a simple web service program, but its core is to deal with servlet and jsp, and it must manage each webapp well. Therefore, for tomcat, it is necessary to master how to deploy webapp. When deploying webapp on tomcat, you must understand the concept of context. For tomcat, each context should be regarded as a webapp, and its path is determined by docBase. The directory stores archived war files or unarchived webapp-related files, while appBase in host container is the place where virtual hosts organize webapp. There can be multiple webapp under one appBase, that is, multiple context.

3. Detailed description of appBase and docBase of tomcat

Although the meaning of these two goods is very clear, the "hidden rules" are very serious. Take the following configuration as an example.

AppBase is the directory where the virtual host stores the webapp. It can be a relative path or an absolute path. If it is a relative path, it is strictly $CATALINA_BASE relative to $CATALINA_HOME.

Path is the matching path of URI, which is equivalent to the path after location of nginx. Tomcat requires that each virtual host must be configured with an empty string of path, which acts as the default context when the URI cannot be explicitly matched, which is equivalent to the role of location / {} in nginx.

DocBase is the directory where each webapp is stored (or archived war files). It can be a relative path or an absolute path, relative to the appBase when a relative path is provided. This directory is generally under the appBase directory, but it is not required to be placed under appBase. For web services, it is equivalent to the root instruction of nginx, but for webapp, a context is equivalent to a webapp, and docBase is the path of webapp.

The "hidden rule" lies in how the default context is provided. There are the following situations:

1. It is clearly defined that the default processing path for context is webappPATH.

two。 Clearly defined, but no docBase attribute is given, so the default context processing path is the appBase/ROOT directory, and note that ROOT is uppercase.

3. When the context for path= "" is not defined at all, that is, there is no explicit path= "" in the host container, a default context is implicitly defined and the processing path is the appBase/ROOT directory.

4. When the path is defined but the docBase attribute is not defined, docBase infers its path from the path. The rules of inference are as follows:

DocBase path inferred by context path context name-/ foo/ foo foo/ foo/bar / foo/bar foo/barEmpty String Empty String ROOT

Here are a few examples of definitions:

# there is no context defined in the virtual host, and the ROOT under appBase will be used as the default processing path # the context of path= "" is not defined, but the context of path is not empty, and ROOT will also be used as the default processing path # if the docBase attribute is omitted in the Context container below, it is inferred that its docBase path is appBase/xuexi # a context defines path= "", the context will be the default context#, but the default context does not define docBase. It will be inferred that its docBase path defines a path= "" for appBase/ROOT # a context, and that context will clearly define docBase as the default context under the default context#.

4. Detailed explanation of tomcat profile server.xml

The properties of each component are configured in the tomcat configuration file, and the global configuration file is $CATALINA_HOME/conf/server.xml. The main components are as follows: Server,Service,Connector,Engine,Host,Alias,Context,Valve and so on. You need to restart tomcat after configuring the configuration file, but be sure to check whether tomcat starts successfully after startup, because even if something goes wrong, it will not report an error in many cases, which can be judged from the listening port.

For configuration methods, see the official manual, where there are links to each component on the left side of the page.

The configuration files for tomcat are all xml files, and the following are common rules for xml files:

1. The first line of the file sets the xml identity, indicating that the file is in xml format. For example.

The comment method of the 2.xml file is that this can be a single-line comment or a multi-line comment, as long as the comment symbol before and after the comment symbol corresponds to the comment, the middle content is the comment.

3. There are two ways to define attributes: single-line definition and multi-line definition. For example:

The configuration of the following components uses a relative path relative to $CATALINA_BASE, which is slightly different from $CATALINA_HOME. If there is only one instance of tomcat, they are equivalent, both of which are the installation path of tomcat. If you have multiple tomcat instances, $CATALINA_HOME represents the installation path, and $CATALINA_BASE represents the root directory where each instance is located. For more than one instance of tomcat, see the corresponding description in running.txt.

4.1 Top level element server

The server component defines an instance of tomcat. The default definition is as follows:

By default, it listens on port 8005 to receive shutdown commands. To enable multiple tomcat instances, simply listen on different ports. The definition of this port provides a convenient way for the administrator to shut down the instance. You can telnet directly to this port and use the SHUTDOWN command to shut down the instance. However, for security reasons, it is usually not allowed to proceed remotely.

Related properties of Server:

ClassName: the name of the java class that implements this component, which must implement the interface org.apache.catalina.Server. The default standard class org.apache.catalina.core.StandardServer will be used when the attribute is not given

Address: the address that listens to the port binding. If not specified, the default is Localhost, that is, only SHUTDOWN commands can be sent on localhost

Port: the port that receives shutdown instructions. By default, only local access is allowed. Default is 8005.

Shutdown: the command string sent to this Server over a TCP/IP connection to close the tomcat instance.

One or more service components can be nested within a server component.

4.2 Top level element service

If you define service, you can provide services. Connector and containor are encapsulated in the service component, which also means that the connector and containor in this service are bound together, that is, they form a service to provide services. The default definition is as follows:

Service-related attributes:

ClassName: the name of the class used to implement service, which must implement the org.apache.catalina.Service interface. The default standard class org.apache.catalina.core.StandardService is used when this attribute is not given.

Name: the display name of this service, which is mainly used to identify the service in the log. Generally speaking, it doesn't matter, and the default is Catalina.

4.3 Actuator executor

The actuator defines a pool of threads that are shared among the components of the tomcat. In the past, each connector created its own thread pool, but now you can define a thread pool that components can share, but mainly between connector. Note that executor creates a shared thread pool, and if a connector does not reference a thread pool created by executor, the connector will still create its own thread pool based on its own specified properties.

The connector must implement the org.apache.catalina.Executor interface. It is an element nested in the service component, which must also be defined before the connector element in order to pick the connector used.

The default definition is as follows:

The properties of this component are:

ClassName: the name of the java class that implements this component, which must implement the interface org.apache.catalina.Executor. The default standard class org.apache.catalina.core.StandardThreadExecutor will be used when the attribute is not given

Name: the name of the thread pool that other components need to use to refer to it.

The properties of a standard class include:

ThreadPriority: thread priority, default value is 5.

Daemon: whether the thread runs as daemon. The default value is true.

NamePrefix: the name prefix when the executor creates each thread, and the final thread's name is: namePrefix+threadNumber.

MaxThreads: the maximum number of threads activated by the thread pool. The default value is 200.

MinSpareThreads: the minimum number of idle threads in the thread pool. The default value is 25.

MaxIdleTime: the number of milliseconds before the idle thread shuts down. Unless the number of active threads is less than or equal to the value of minSpareThreads, there will be idle threads. The default value is 60000, which means that the idle thread needs to remain idle for 1 minute before it is killed.

MaxQueueSize: the maximum number of queues in which tasks can be executed. Connection requests will be rejected when the queue limit is reached.

PrestartminSpareThreads: whether to create the number of minSpareThreads threads immediately when starting executor. The default is false, that is, threads are created only when needed.

For example, specify the thread pool to be used in connector as follows:

4.4 Connector connector

The connector is used to receive the request sent by the client and return the response to the client. There can be more than one connector in a service. There are a variety of connector, the common of which are http/1.1,http/2 and ajp (apache jserv protocol). In tomcat, the ajp connection protocol type is dedicated to situations where the tomcat front end is an apache reverse proxy.

So tomcat can play two roles:

1.Tomcat acts only as an application server: the request comes from the front-end web server, which may be Apache, IIS, Nginx, etc.

2.Tomcat acts as both a web server and an application server: the request comes from the browser.

Tomcat should consider the working situation and define the required connectors for the requests in the corresponding situation in order to receive the requests from the client correctly.

The property settings of the HTTP/1.1 connector are introduced here. I will introduce you later on ajp.

HTTP connectors represent components that support the HTTP/1.1 protocol. Setting this connector means that catalina enables its independent web service functionality, and of course, it certainly provides the necessary servlets and jsp execution functions. One or more connectors can be configured in a service, and each connector can forward requests to their associated engine to process requests and create responses.

If you want to configure a connector for a web server, use the AJP protocol.

Each incoming request needs to be received by a separate thread. When the number of concurrent requests exceeds the value specified by maxThreads, the extra requests are stacked in the socket until the value specified by acceptCount is exceeded. Requests that exceed the accpetCount will be rejected with a "connection refused" error.

The default definition is as follows:

There are too many properties for HTTP connectors. See the official manual for detailed configuration. Usually the only property that must be defined when defining a HTTP connector is "port".

Address: specifies the address that the connector listens to, which defaults to all addresses, namely 0.0.0.0.

MaxThreads: the maximum number of concurrent connections supported, which defaults to 200; this attribute is ignored if the shared thread pool created by executor is referenced.

AcceptCount: sets the maximum length of the waiting queue; usually when all tomcat processing threads are busy, new requests will be placed in the waiting queue

MaxConnections: the maximum number of connections allowed. AcceptCount and maxThreads are the maximum number of threads that accept connections. There is a situation where when maxConnections is less than acceptCount, connection requests beyond maxConnections will be received, but no connection will be established with it.

Port: listening port. Default is 0, which means that a port is randomly selected. Usually, the listening port should be explicitly specified.

Protocol: the protocol used by the connector to process the corresponding request. The default is HTTP/1.1, which automatically switches between Java NIO-based or APR/native-based connectors. The AJP protocol is usually defined as AJP/1.3.

RedirectPort: if the protocol supported by a connector is HTTP, when receiving a HTTPS request from the client, it is forwarded to the port defined by this attribute.

ConnectionTimeout: the timeout for waiting for the client to send a request (in milliseconds). The default is 60000, that is, 1 minute. Note that the connection has been established.

KeepAliveTimeout: the timeout for the persistent connection status. When this value is exceeded, the persistent connection is closed.

EnableLookups: whether to query DNS through request.getRemoteHost () to obtain the hostname of the client. Default is true, which should be set to false to prevent client hosts from being decrypted.

Compression: whether to compress the data. The default is off. Set to on to compress only text text, and set to force to compress all content. There should be a tradeoff between compression and sendfile.

UseSendfile: this attribute is a property of NIO, indicating whether the feature of sendfile is enabled. The default is true, and enabling this property disables the compression property.

When the protocol is specified as HTTP/1.1, the NIO/APR protocol processing method is automatically switched on demand by default. To explicitly specify the protocol, the method is as follows:

Where NIO is the IO implementation of the non-blocking IO reuse model in JAVA, and NIO2 is asynchronous NIO, that is, asynchronous non-blocking IO:

NioProtocol: non blocking Java NIO connectorNio2Protocol:non blocking Java NIO2 connectorAprProtocol: the APR/native connector

The similarities and differences between them are shown below:

Java Nio ConnectorJava Nio2 ConnectorAPR/native ConnectorClassnameHttp11NioProtocolHttp11Nio2ProtocolHttp11AprProtocolTomcat Version6.x onwards8.x onwards5.5.x onwardsSupport PollingYESYESYESPolling SizemaxConnectionsmaxConnectionsmaxConnectionsRead Request HeadersNon BlockingNon BlockingNon BlockingRead Request BodyBlockingBlockingBlockingWrite Response Headers and BodyBlockingBlockingBlockingWait for next RequestNon BlockingNon BlockingNon BlockingSSL SupportJava SSL or OpenSSLJava SSL or OpenSSLOpenSSLSSL HandshakeNon blockingNon blockingBlockingMax ConnectionsmaxConnectionsmaxConnectionsmaxConnections

Here is an SSL connector with multiple properties defined:

4.5 Container Class engine

Engine is the engine machine used to analyze the protocol in the service component. It receives the request from one or more connector and sends the request to the corresponding virtual host for processing. Finally, the complete response data is returned to connector, and the response data is returned to the client through connector.

Only one engine element must be nested within each service, and the engine must follow the connector it needs to associate, so that the connector before the engine can be associated with this engine, while the connector after the engine is ignored because only one engine is allowed in a service.

The definition is roughly as follows:

Common engine properties are:

ClassName: a class that implements engine, which must implement the org.apache.catalina.Engine interface. The default standard class org.apache.catalina.core.StandardEngine is used when this attribute is not given.

DefaultHost: specifies the default virtual host for processing requests. At least one of the host names of multiple virtual hosts defined in Engine has the same name as the host name defined by defaultHost.

The name of the name:Engine component, which is used to log and error messages, and properties that are insignificant can be given at will.

JvmRoute: an identifier that specifies which load balancer to use when session stickiness is enabled. This identifier must be unique in all tomcat server instances, and it is appended to the end of the session identifier, so that the front-end agent can always forward a specific session to the same tomcat instance.

Note that jvmRoute can also be set using the system properties of jvmRoute. If jvmRoute is set here, the jvmRoute system property is overridden. The use of jvmRoute is described in a later article on tomcat ajp load balancing.

Engine is the top-level sub-container in a container, in which one or more Host can be nested as virtual hosts, and at least one host corresponds to the default virtual host name in engine. In addition to host, you can also nest releam and valve components.

4.6 Container class host

The host container is used to define virtual hosts. After receiving the request from the connector for analysis, engine passes the relevant attribute parameters to the corresponding virtual host (the filtering method is to match the host field and the virtual host name in the header of the request) for processing. If there is no suitable virtual host, it is passed to the default virtual host. Therefore, at least one virtual host must be defined in each container, and one virtual host must have the same name as the default virtual host defined in the engine container.

It is roughly defined as follows:

Common attribute description:

ClassName: a class that implements the host container, which must implement the org.apache.catalina.Host interface. The default standard class org.apache.catalina.core.StandardHost is used when this attribute is not given.

Name: the hostname of the virtual host, ignoring case (automatically converted to lowercase when initialized). You can use a prefix asterisk wildcard, such as "* .a.com". Virtual hosts that use the asterisk prefix match the virtual host with a lower priority than the exact name.

AppBase: the webapps directory of this Host, which is the directory where webapp is deployed on this virtual host. Includes directories for non-archived web applications and archived WAR files. The relative path is based on $CATALINA_BASE.

XmlBase: the context xml directory deployed on this virtual host.

StartStopThreads: the number of parallel threads when the context container is started. If the automatic deployment feature is used, the same thread pool is used when deploying or updating again.

AutoDeploy: whether the application files placed in the appBase directory while Tomcat is running automatically deploy or update the deployment status. This is equivalent to turning on both the deployOnStartup property and the reload/redeploy webapp function. The webapp is overloaded by default when automatic updates are triggered. The default is true.

UnpackWars: whether to extract the WAR file in the archive format and then run it when executing this webapps. If it is set to false, the WAR file will be executed directly. Default is true. Performance is compromised when set to false.

WorkDir: the working directory of the virtual host. Each webapp has its own temporary IO directory, which defaults to $CATALINA_BASE/work.

Most of the time, you only need to set the virtual host name name and webBase properties, and the rest will be deployed by default, and webapp will be automatically deployed by default. Sometimes you also need to manage multiple site names, that is, host aliases. You can use Alias to define a host alias for the hostname specified by Host. Such as:

Www.a.com

Automatic deployment refers to the service of automatically loading webapp to provide related webapp.

4.7 Container context

Connector and containor are the heart of the whole tomcat, while context is the heart of containor and the heart of tomcat. It is the place where servlet is really managed, and its configuration affects how servlet works.

A context represents a webapp. Servlet states that each webapp must be based on archived WAR (WEB application archive) files or on the directory where the non-archived related content resides.

Catalina selects based on the rule that the request URI is prefixed with the path defined in the context, and which context is used to process the HTTP request. This is equivalent to nginx's location container, and catalina's path is equivalent to location's path, and they serve the same purpose.

Each context must have a unique context name in the virtual host container host. The path of context does not need to be unique because it allows co-existing deployments of different versions of the same webapp. In addition, there must be a string (that is) with a path of 0 for the context, which is the default webapp for the virtual host and is used to handle all requests that cannot be matched by all context path in the virtual host.

With regard to context name, it is inferred from context path, not only that, but also from other attributes such as context basefile name. The rules are as follows:

If path is not empty, context name equals context path,basefile name takes the path after the prefix "/" is removed from path, and all "/" is replaced with "#".

If path is empty, context name is also empty and basefile is ROOT (note that it is uppercase).

For example:

Context path context name basefile name deploy examples-/foo / foo foo foo.xml,foo.war,foo/foo/bar / foo/bar foo#bar foo#bar.xml,foo#bar.war Foo#barEmpty String Empty String ROOT ROOT.xml,ROOT.war,ROOT

When configuring context, it is strongly recommended that it not be defined in server.xml, because when defining conf/server.xml, reloading can only take effect by restarting tomcat, that is, the application cannot be deployed automatically. Although officially recommended, most people will write directly in server.xml out of habit and convenience, which is no problem, it's just a reboot.

Consider defining it in / META-INF/context.xml, and if the copyXML property is set at this time, the context.xml will be copied to $CATALINA_BASE/conf/enginename/hostname/ at deployment time and renamed to "basefile name.xml". It can also be defined directly in the .xml file under $CATALINA_BASE/conf/enginename/hostname/, where the path has xml priority over / META-INF/context.xml.

You can also define a default context.xml file, including two types: (1) it is defined in $CATALINA_BASE/conf/context.xml, and the default context is valid for all webapp; (2) it is defined in $CATALINA_BASE/conf/ [enginename] / [hostname] / context.xml.default, and the default context only works for all webapp in the virtual host.

The definition is roughly as follows:

The path of the first context is an empty string, indicating that it is the default context. When entering www.a.com in the browser, it is defaulted to the first context processing because it cannot match the second context. When entering www.a.com/bbs in the browser, it will be processed by the second context, which will execute the webapp corresponding to web/bbs and return the relevant content.

There are many attributes that can be defined in the context container. See the official manual for details. Here are a few common attributes:

ClassName: a class that implements the host container, which must implement the org.apache.catalina.Context interface. The default standard class org.apache.catalina.core.StandardContext is used when this attribute is not given.

Cookies: the default is true, which means that cookie is enabled to identify session.

DocBase: DocumentRoot, which is the context root of the webapp, that is, the directory where the archived WAR file is located or the directory where the non-archived content is located. It can be an absolute path or a relative path relative to the webapp appBase.

Path: define webapp path. Note that when path= "" indicates the default context;, this attribute needs to be defined only in server.xml, and cannot be defined in all other cases, because path is inferred from the xml file names of docBase and context.

Reloadable: whether to monitor changes in files in the / WEB-INF/class and / WEB-INF/lib directories, which will be reloaded automatically when they change. This property is fine in a test environment, but it should not be set when deploying an application in a real production environment, because monitoring significantly increases the load, so the default value for this property is false.

WrapperClass: the class that implements the wrapper container. Wrapper is used to manage the servlet in the context. This class must implement the org.apache.catalina.Wrapper interface. If you do not specify this property, the default standard class is used.

XmlNamespaceAware: it has something to do with how web.xml is parsed. The default is true, and setting it to false can improve performance.

XmlValidation: it has something to do with how web.xml is parsed. The default is true, and setting it to false can improve performance.

4.8 nested class realm

Realm defines a security context, such as how to store the database related to users and groups at the time of authentication. There are several ways to store data:

JAASRealm: user authentication based on Java Authintication and Authorization Service

JDBCRealm: access to a relational database table through JDBC to achieve user authentication

JNDIRealm: using directory service to obtain authentication information based on JNDI

MemoryRealm: search for tomcat-user.xml files to obtain user information

UserDatabaseRealm: implements user authentication based on UserDatabase files (usually tomcat-user.xml). It implements a fully updatable and persistent MemoryRealm, so it is compatible with standard MemoryRealm; it is implemented through JNDI

Here is a common configuration that uses UserDatabase:

The following is a configuration that uses JDBC to obtain user authentication information:

4.9The nested class valve

Valve means valve in Chinese and is similar to a filter. It can work between Engine and Host/Context, between Host and Context, and between resources in Context and Web applications. Multiple Valve can be created in a container, and the order defined by Valve determines the order in which they take effect.

There are many different Valve:

AccessLogValve: access log Valve

ExtendedAccessValve: access log Valve for extended functionality

JDBCAccessLogValve: sends access log information to the database through JDBC

RequestDumperValve: request to dump Valve

RemoteAddrValve: access control based on remote address

RemoteHostValve: access control based on remote host name

SemaphoreValve: used to control the number of concurrent accesses on any container on the Tomcat host

JvmRouteBinderValve: in a cluster architecture with multiple Tomcat configured to use Apache through mod_proxy or mod_jk as the front end, when you expect to stop a node, you can use this Valve to direct the usage request to the standby node; with this Valve, you must use JvmRouteSessionIDBinderListener

ReplicationValve: designed for Tomcat cluster architecture, session data can be triggered to replicate between nodes when a requested session information changes

SingleSignOn: connect two or more webapp that need to authenticate users together when authenticating users, that is, all connected webapp can be accessed in a single authentication

ClusterSingleSingOn: an extension to SingleSignOn that is dedicated to Tomcat clusters and needs to work in conjunction with ClusterSingleSignOnListener

RemoteHostValve and RemoteAddrValve can be used to implement access control based on host name and IP address respectively, and the control itself can be defined by allow or deny, which is similar to the access control function of Apache. As shown in the following Valve, only native access to / probe is allowed:

The relevant attribute definitions are:

ClassName: add ".valves.RemoteHostValve" or ".valves.RemoteAddrValve" to the suffix of the corresponding location

Allow: a comma-separated list of allowed IP addresses that support regular, dot "." Escape is required when used for IP addresses; when only allow entries are defined, addresses of ambiguous allow are all deny

Deny: a comma-separated list of forbidden IP addresses, which supports regularity; when using the same way as allow; to define only deny entries, the addresses of ambiguous deny are all allow

Another commonly used Valve is AccessLogValve, which is roughly defined as follows:

Where prefix and suffix represent the prefix name and suffix name of the log file. Pattern indicates the information and format in which the log is recorded.

Thank you for reading this article carefully. I hope the article "sample Analysis based on tomcat profile server.xml" shared by the editor will be helpful to you. At the same time, I also hope you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

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.