Tomcat server.xml Context Configuration __tomcat

The context element represents a Web application that runs on a specific virtual host. As described in servlet specification 2.2 or later, each Web application is based on a Web application Archive (War) file, or a directory containing the contents of the WAR file after it has been uncompressed. For more information about Web application archive, you can refer to the servlet specification and the Tomcat application Developer's Guide. By matching the longest possible prefix of the request URI with the context path of each context, Catalina selects the appropriate Web application to process the HTTP request. Once selected, the context selects a correct servlet to process incoming requests based on the servlet mappings defined in the Web application deployment descriptor file. Servlet mappings must be defined in the/web-inf/web.xml in the WEB application directory hierarchy. You can nest any number of context elements in a host element. The path for each context must be unique and defined by the path attribute. In addition, you must define a context with a context path length of 0, which is called the default Web application of the virtual host to handle requests that cannot match the context path of any context. In addition to nesting the context elements in the host element, you can store them in a single file (with the. xml suffix) and under the $catalina_home/conf/[enginename]/[hostname]/directory. For more information on this, refer to the automatic release of the application. This approach allows for dynamic reconfiguration of the Web application, because Tomcat must be restarted if Conf/server.xml is modified. In addition to explicitly specifying a context element, there are several other techniques that can automatically generate a context element. Reference automatic application deployment and the user Web applications The following description uses variable $catalina_home to refer to the directory where Tomcat 5 is installed. Most of the relative paths are based on the directory. However, by setting up the Catalina_base directory, you can run multiple instances of Tomcat 5, where you should use $catalina_base as a directory benchmark instead of using $catalina_home. Properties Common PropertiesAll context implementations support the following properties: Backgroundprocessordelay This value represents the delay, in seconds, of invoking the Backgroundprocess method on the context and its child containers (including all wrappers). If the delay value is non-negative, the child container is not invoked, which means that the child container uses its own processing thread. If the value is positive, a new thread is created. After waiting for the specified time, the thread invokes the Backgroundprocess method on the host and its child containers. The context uses a background processing session to expire, and monitoring class changes are used to reload. If not specified, the default value of this property is-1, which indicates that the context relies on the background processing of the host to which it belongs. The Java class name implemented by ClassName. The class must implement the Org.apache.catalina.Context interface. If not specified, use a standard implementation (defined below). Cookies are set to ture if they want to use cookies to pass the session identifier (requiring the client to support cookies). Otherwise, false, in which case the session identifier can only be passed by the URL rewriting. Crosscontext If you want to call Servletcontext.getcontext () within the application to return to the request dispatcher of another Web application running on that virtual host, set to True. In an environment where security is important, set to false so that getcontext () always returns NULL. The default value is False. DocBase the document base directory for the Web application (document base, also known as context Root), or the path to the war file. You can use an absolute path, or you can use a appbase path relative to the host to which the context belongs. Override set to True if you want to use the settings in this context element to overwrite the corresponding settings in Defaultcontext. By default, the settings in Defaultcontext are used. Privileged set to true to allow the context to use container servlets, such as the manager servlet. The context path for the path Web application. Catalina compares the start of each URL to the context path and selects the appropriate Web application to process the request. The context path under a specific host must be uniqueOf If the context path is an empty string (""), this context is the default Web application of the owning host to handle requests that cannot match any of the context path. reloadable If you want Catalina to monitor/web-inf/classes/and/web-inf/lib The following classes change, automatically overload the WEB application when a change occurs, set to true. This feature is useful in the development phase, but it also greatly increases the overhead of the server. Therefore, it is not recommended to use after release. However, you can use the manager to apply the overload that triggers the application when necessary. Wrapperclass Org.apache.catalina.Wrapper The name of the implementation class for the servlets of the context management. If not specified, the standard default value is used. The standard implementation of the context is org.apache.catalina.core.StandardContext. It also supports the following additional properties: property describes the level of detail for debug information for debug logger records associated with this engine. The larger the number, the more verbose the output. If not specified, the default is 0. Swallowoutput If this value is true,system.out and System.err output is redirected to the logger of the Web application. If not specified, the default value is False usenaming set to True if you want Catalina to enable a Jndi InitialContext object for the Web application. The initialialcontext conforms to the Java Platform's Convention, and the default value is true. The path to the temporary directory provided by the WORKDIR context for temporary read/write of the servlet. With the Javax.servlet.context.tempdir property, the servlet can access the directory. If not specified, use $catalina_home/work to the next appropriate directory. Nested components The following elements can be nested within a context element, but each element may be nested at most once. Loader-configures the class loader that the Web application uses to load servlet and JavaBean. Normally, using the default class loader is sufficient; Logger-configures the Logger for receiving and processing all log messages, including all messages that call the ServletContext.log () function record; Manager-configure for creating, destroying, maintaining HTTP The Sessi of the sessionOn Manager. Normally, using the default Session manager configuration is sufficient; Realm-Configure Realm, the Realm user database and related roles are used only in this particular Web application. If not specified, the Web application uses the realm of the host or engine to which it belongs. Resources-Configure to access the static resource associated with this Web application. Normally, using the default resource manager is sufficient. Proprietary feature access log normally, running a Web server generates an access log. The access log outputs one line of information for each request in a standard format. Catalina contains an optional valve implementation that generates logs in a standard format and can also use any custom format. By nesting a valve element in the Engine,host or context, Catalina creates access logs for all requests processed by the container, as follows: ... Refer to access Log Valve for more information on configuration properties; automatic configuration of the context if you use a standard implementation of the environment, when the Catalina is started, or if you overload the Web application, the following configuration steps occur automatically. No special configuration is required to enable this feature. If you do not define your own loader element, you will configure a standard Web application class loader, and if you do not define your own manager element, configure a standard Session manager, and if you do not define your own resources element, Use the standard resource manager. The properties of the Web application that are listed in Conf/web.xml are treated as the default properties for the Web application. This is used to establish the default mappings (such as mapping. JSP to the corresponding JSP servlet), and other standard properties. The attributes listed in the/web-inf/web.xml resource are processed (if the resource exists), and if the WEB application specifies security restrictions and may need to authenticate the user, Catalina configures the selected authenticator. The authenticator implements the login method. The context parameter can nest elements in elements in the context, and configure names with values that are used as ServletContext initialization parameters and are visible to the entire Web application. For example, you can create initialization parameters like this: ... This is equivalent to including the following elements in/web-inf/web.xml: CompanyName my company, IncoThe rporated difference is that the former does not need to modify deployment descriptor to customize this value. The valid property values for the element are as follows: The property Description Description The text description of the context initialization parameter (optional) name of the context initialization parameter you want to create override if you don't want/web-inf/ Web.xml the value specified here in the overlay with the same parameter name, set to False. The default value is true. Value is returned to the applied parameter value when Servletcontext.getinitparameter () is invoked. Environment entries can nest elements in the context, configuring named values that are visible to the entire Web application as an Environment entry resource (Environment Entry Resource). For example, you can create an environment entry by doing the following: ... This is equivalent to the inclusion of the following elements in/web-inf/web.xml: Maxexemptions java.lang.Integer The difference is that the former does not need to modify deployment descriptor to customize this value. The valid properties of the element are as follows: The attribute describes the text description of the description environment entry (optional) name environment entry, relative to the java:comp/env context. Override if you do not want the value specified here in the/web-inf/web.xml with the same name, set to False. The default value is true. The full name of the Java class name for the type environment entry. In/web-inf/web.xml, the value must be the following: 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. Value is returned to the applied parameter value through the JNDI context request. This value must be converted to the Java type Lifecycle defined by the type attribute listeners if a Java object needs to know when the context is to start and when to stop, you can nest a listener element in the object. The listener element must implement the Org.apache.catalina.LifecycleLiStener interface that notifies the listener when a corresponding life-cycle event occurs. You can configure such listener in the following format: ... Note that a listener can have any number of additional attributes. The property name corresponds to the property name of the JavaBean, using the Standard property naming method. Request Filters requests the Catalina to check the IP address or host name for each request sent to the Engine,host or context. Catalina uses a series of configured accept or deny filters to check the address or host name of the client, which is defined by the regular expression syntax and supported by Jakarta regexp regular expression libraries. Requests that are not accepted return an HTTP "forbidden" error. The following is the definition of the filter. ... ... Resource definitions (Resource definitions) can define the attributes of a resource in/web-inf/web.xml. When using Jndi lookups and elements, these attributes are returned. For the same resource name, you must also define the resource parameters (see the "Resource Parameters" section below), which are used to configure the object factory (objects factory) and the properties of the object factory. For example, you can create a resource definition as follows: ... This is equivalent to including the following elements in/web-inf/web.xml: Employees Database for HR applications Jdbc/employeedb Javax.sql.DataSource Container the difference is , the former does not need to modify deployment descriptor to customize this value. The valid properties of the element are as follows: Property Description Auth Specifies whether the Web application code itself sign on to the corresponding resource Mananger, or the container on behalf of the Web application sign on to Resource manager. The value of this property must be either application or container. This property is required if used in the Web application deployment descriptor, which is optional if used. The name of the description resource's text description (optional), relative to java:comp/env context scope, to specify whether the connection obtained through this resource manager is shared. The value of this property must be shareable or UnsharEable. By default, the connection is assumed to be shared. Type the full name of the Java class name that is returned when the Web application looks up the resource. Resource parameter resource parameters are used to configure the Resource Manager (Resource Manager, or object factory, objects factory). When you do a jndi lookup, the Resource manager returns the object you are looking for. Before a resource can be accessed, each element of a pair or element, or each or element defined in/web-inf/web.xml, must define a resource parameter. Resource parameters are defined by name, and the collection of parameter names differs from the Resource manager (or object factory) used. These parameter names correspond to the JavaBeans properties of the factory class. The JNDI implementation configures a specific factory class by calling the corresponding JavaBeans property-setting function, and then makes the instance visible through a lookup () call. Resource parameters for a JDBC data source can be defined as follows: ... driverclassname org.hsql.jdbcDriver url jdbc:HypersonicSQL:database user dbusername Password Dbpassword ... If you need to specify a Java class name within the factory for a particular resource type, nest an entry in the element called factory. The valid properties of the element are as follows: The attribute describes the resource name of the name configuration, relative to the java:comp/env context. This name must match the resource name defined by an element in the $catalina_home/conf/server.xml, or it may be used in/web-inf/web.xml or element. A resource connection (Resource Links) resource connection is used to create a connection to a global jndi resource. A jndi query on the connection name returns the connected global resource. For example, you can create a resource connection by using the following methods: ... The valid properties of the element are as follows: Property describes the name of a resource connection created by the name of the globally connected connection global resource, relative to the JAVA:COMP/ENV context type, the full name of the Java class name that is returned when the Web application looks up on the resource connection