Tomcat deployment and context [reprinted]

First, let's talk about several Tomcat deployment methods:

1. Add the application folder or war file to the webapps subdirectory under the tomcat installation directory, so that Tomcat starts to deploy the folder or war content under the webapps directory as an application. This method is the easiest and requires no configuration files to be written.





2. server in the conf subdirectory of the tomcat installation directory. add the context byte under the host node in the XML configuration file: <context Path = "/Name" docbase = "... "/>, where the path attribute is the access directory name after the URL. In this example, the access URL of the project on the local machine is http: // localhost: 8080/Name, docbase is the application path, which can be any location of the system.
3. $ catalina_home/CONF/[enginename]/[hostname]/create an XML file in the directory. The root node of the file is the context node, and the attribute configuration is the same as that of the second method, you do not need to configure the path attribute. The path attribute is the name of the XML file.



4. log on to the http: // localhost: 8080/Manager page and use Tomcat's manager management function to manage and dynamically deploy applications.

The context node configuration of Tomcat is similar to that of Web. XML, but it is applied to two different aspects. The context element represents a web application and runs on a specific VM. Each web application is based on a web application archive (WAR) file, or a directory. The context that contains the extracted war file describes the deployment of an application from the Tomcat perspective, the context node describes a web application deployed in the container from the perspective of the Tomcat container. The Web. xml file describes the application content, which is for the application itself. By matching the longest possible prefix of the request URI with the context path of each context, Catalina (ENGINE) selects the corresponding web application to process HTTP requests. Once selected, according to the servlet ing defined in the Web application deployment descriptor file, context selects a correct servlet to process incoming requests. Servlet mappings must be defined in/WEB-INF/Web. XML in the Web application directory hierarchy.
You can nest any number of context elements in a host element. The path of each context must be unique and defined by the path attribute. In addition, you must define a context whose path length is 0. This context is called the default web application of the VM and is used to process requests that cannot match any context path.






[Notes]
1. The tomcat configuration file server. XML is case-sensitive. For example, docbase does not use the original docbase. If it is written incorrectly, the container will have the same docbase and path values by default, rather than the docbase values.
2. define the context node in server. XML to overwrite the same folder as path in webapps.
3. Trying to define the pathname of the same context will cause Tomcat to fail to start
4. Several contexts can point to the same docbase
[Context]
Function:
Webapplicationarchive Descriptor
Location:
$ Catalina_home/CONF/context. xml: this is a public configuration file for all application context nodes. It works for all applications.
$ Catalina_home/CONF/[enginename]/[hostname]/context. xml. Default
$ Catalina_home/CONF/[enginename]/[hostname]/*. xml: * indicates the application name.
$ Catalina_home/webbase/appdirname/META-INF/context. xml
Server. xml
Attribute:
Backgroundprocessordelay
Classname implements the org. Apache. Catalina. Context Interface
Whether cookies are allowed
Does crosscontext allow applications to call servletcontext. getcontext () interactively ()
Docbase context root directory.
Whether override overwrites the default context configuration of the host
Path: the URL path of the application. The path of all apps of each host must be different. Note: This is only used when context is defined in server. xml. Generally, it is automatically inferred by the file name or directory name.
Whether privileged allows container Servlets, just like the manager Servlet
Reloadable whether to monitor and load updates to class files in/WEB-INF/classes/AND/WEB-INF/lib.
Wrapperclass implements the org. Apache. Catalina. Wrapper interface class.
Allowlinking, antijarlocking, antiresourcelocking, cachemaxsize, cachettl, cachingallowed, casesensitive, processtlds, swallowoutput, validation, tldvalidation, unloaddelay, unpackwar
Subnode:
Loader class loader. You can configure at most one class loader for the Web application to load Servlet and JavaBean. Normally, it is enough to use the default class loader.
Logger-configure the logger used to receive and process all log messages, including all messages recorded by calling the servletcontext. Log () function.

Manager Management class for creating, destroying, and maintaining HTTP sessions. The maximum number is one. Normally, the default Session Manager configuration is enough.
Realm authorization management. At most one, configure realm. The user database of this realm and related roles are only used in this specific web application. If not specified, the Web application uses the host or engine realm
Resources resource management. Up to one configuration is used to access the static resources associated with the Web application. Under normal circumstances, it is enough to use the default Resource Manager.
Watchedresource is a string of monitored resources. The auto-loader updates the resource at any time.



[Loader]
Note:
Placed in the context node
Attribute:
Classname implements the class loader of org. Apache. Catalina. loader interface. The default is org. Apache. Catalina. loader. webappclassloader.
Delegate true indicates that the upper-level loader is asked before loading, which is in the same java mode. False indicates that the loader is started to load
Whether the reloadable monitors changes in class files and updates and loads in real time.

[Manager]
Note:
In the context to manage the creation and maintenance of HTTP sessions for each webapp.

Automatic Configuration of Context
If standard context is used, the following configuration steps will automatically take place when Catalina is started or when a web application is overloaded. Special configurations are not required to enable this feature.

If no loader element is defined, a standard web application class loader is configured;
If no manager element is defined, a standard Session Manager is configured;
If you do not define your own resources, use the standard resource manager.
The Web application attributes listed in CONF/Web. XML are considered as the default attributes of the Web application. This is used to create a default ing (for example, ing. jsp to the corresponding JSP servlet) and other standard attributes.
Properties listed in/WEB-INF/Web. xml resources are processed (if the resource exists );
If the web application specifies security restrictions and users may need to be authenticated, Catalina configures the selected authenticator, which implements the login method.


Context Parameter
You can nest the <parameter> element in the context and configure the value with a name as the initialization parameter of servletcontext, which is visible to the entire web application. For example, you can create initialization parameters like this:
<Context...>
...
<Parameter name = "companyName" value = "my company, inreceivated"
Override = "false"/>
...
</Context>
This is equivalent to containing the following elements in/WEB-INF/Web. xml:
<Context-param>
<Param-Name> companyName </param-Name>
<Param-value> my company, inmarshated </param-value>
</Context-param>

The difference is that the former does not need to modify the deployment descriptor to customize this value.
The valid attribute values of the <parameter> element are as follows:

Attribute description
Description (optional) description of the context initialization parameter)

Name
Name of the context initialization parameter to be created
Override if you do not want <context-param> with the same parameter name in/WEB-INF/Web. XML to overwrite the value specified here, set it to false. The default value is true.
Value indicates the parameter value that is returned to the application when servletcontext. getinitparameter () is called.
Environment entry
You can nest the <environment> element in the context and configure the named values as the Environment entry resource, which is visible to the entire web application. For example, you can create an environment entry as follows:
<Context...>
...
<Environment name = "maxexemptions" value = "10"
Type = "Java. Lang. Integer" override = "false"/>
...
</Context>
This is equivalent to containing the following elements in/WEB-INF/Web. xml:
<Env-entry>
<Env-entry-Name> maxexemptions </param-Name>
<Env-entry-value> 10 </env-entry-value>
<Env-entry-type> JAVA. Lang. Integer </env-entry-type>
</Env-entry>
The difference is that the former does not need to modify the deployment descriptor to customize this value.
The valid attributes of the <environment> element are as follows:
Attribute description
Description Description (optional)
Name indicates the name of the Environment entry, relative to Java: COMP/ENV context.
Override if you do not want <env-entry> with the same name in/WEB-INF/Web. XML to overwrite the value specified here, set it to false. The default value is true.
The full name of the Java class name of the type environment entry. in/WEB-INF/web. in XML, <env-entry-type> must be the following value: Java. lang. boolean, Java. lang. byte, Java. lang. character, Java. lang. double, Java. lang. float, Java. lang. integer, Java. lang. long, Java. lang. short, or Java. lang. string.
The parameter value returned to the application when the value is requested through the JNDI context. This value must be converted to the Java type defined by the Type attribute.
Life Cycle listeners
If a Java object needs to know when the context is started and when it is stopped, a listener element can be nested in the object. The listener element must implement the org. Apache. Catalina. lifecyclelistener interface to notify the listener when a corresponding Life Cycle event occurs. You can configure listener in the following format:
<Context Path = "/Examples"...>
...
<Listener classname = "com. mycompany. mypackage. mylistener"...>
...
</Context>
Note that a listener can have any number of additional attributes. The attribute name corresponds to the attribute name of JavaBean and uses the standard attribute naming method.
Request Filters)
For each request sent to the engine, host, or context, you can require Catalina to check the IP address or host name. Catalina checks the client address or host name using a series of configured "accept" or "deny" filters. The filters are defined according to the regular expression syntax and are supported by the Jakarta Regexp Regular Expression Library. If the request is not accepted, an HTTP "forbidden" error is returned. The following is the definition of the filter.
<Context Path = "/Examples"...>
...
<Valve classname = "org. Apache. Catalina. Valves. remotehostvalve"
Allow = "* .mycompany.com, www.yourcompany.com"/>
<Valve classname = "org. Apache. Catalina. Valves. remoteaddrvalve"
Deny = "192.168.1. *"/>
...
</Context>

Resource Definition)
You can define the properties of a resource in/WEB-INF/Web. xml. When you use JNDI to find the <resource-ref> and <resource-env-ref> elements, these features are returned. For the same resource name, you must also define the resource parameters (see the "resource parameters" section below). These parameters are used to configure the attributes of the object factory and the object factory.
For example, you can create a resource definition as follows:
<Context...>
...
<Resource Name = "JDBC/employeedb" auth = "Container"
Type = "javax. SQL. datasource"
Description = "employees database for HR applications"/>
...
</Context>

This is equivalent to containing the following elements in/WEB-INF/Web. xml:
<Resource-ref>
<Description> employees database for HR applications </description>
<Res-ref-Name> JDBC/employeedb </RES-ref-Name>
<Res-ref-type> javax. SQL. datasource </RES-ref-type>
<Res-auth> container </RES-auth>
</Resource-ref>

The difference is that the former does not need to modify the deployment descriptor to customize this value.

<Resource> the valid attributes of an element are as follows:
Attribute description
Auth indicates whether the web application code itself is signed on to the corresponding resource mananger, or whether the container represents the web application sign on to the resource manager. The value of this attribute must be application or container. If <resource-ref> is used in the Web application deployment descriptor, this attribute is required. If <resource-env-ref> is used, this attribute is optional.

Description Description (optional)

Name Resource Name, relative to Java: COMP/ENV Context

Scope specifies whether the connection obtained through the resource manager is shared. The value of this attribute must be retriable or unretriable. By default, connections are shared.
Type the full name of the returned Java class name when the web application looks for the resource.

Resource Parameters
Resource source parameters are used to configure Resource Manager (resource manager, or object factory ). When performing a JNDI search, the resource manager returns the searched object. Each <resource> element of the <context> or <defaultcontext> element, or/WEB-INF/web. each <resource-ref> or <resource-env-ref> element defined in XML must define resource parameters.

Resource parameters are defined by name. Different resource managers (or object factory) are used, and the set of parameter names are different. These parameter names correspond to the JavaBeans attributes of the factory class. The JNDI implementation configures a specific factory class by calling the corresponding JavaBeans attribute setting function, and then makes the instance visible through the Lookup () call.

The resource parameters of a JDBC data source can be defined as follows:
<Context...>
...
<Resourceparams name = "JDBC/employeedb">
<Parameter>
<Name> driverclassname </Name>
<Value> org. hsql. jdbcdriver </value>
</Parameter>
<Parameter>
<Name> URL </Name>
</Value> JDBC: hypersonicsql: database </value>
</Parameter>
<Parameter>
<Name> User </Name>
<Value> dbusername </value>
</Parameter>
<Parameter>
<Name> password </Name>
<Value> dbpassword </value>
</Parameter>
</Resourceparams>
...
</Context>

If you need to specify the Java class name in the factory for a specific resource type, a <parameter> entry named factory is nested in the <resourceparams> element.

The valid attributes of the <resourceparams> element are as follows:
Attribute description
Name indicates the Resource Name configured, relative to Java: COMP/ENV context. This name must be consistent with $ catalina_home/CONF/server. A Resource Name Defined by a <resource> element in XML matches, or in/WEB-INF/web. use the <resource-ref> or <resource-env-ref> element in XML.

Resource links)
A resource connection is used to create a connection to a global JNDI resource. After performing a JNDI query on the connection name, the connected global resource is returned.
For example, you can create a resource connection as follows:
<Context...>
...
<Resourcelink name = "linktoglobalresource"
Global = "simplevalue"
Type = "Java. Lang. Integer"
...
</Context>

The valid attributes of the <resourcelink> element are as follows:
Attribute description
Name of the global resource connected to global
The name of the resource connection created by name, relative to Java: COMP/ENV Context
Type the full name of the returned Java class name when the web application searches for the resource connection