| career | drupal | java | mac | mysql | perl | scala | uml | unix  

Tomcat example source code file (host.xml)

This example Tomcat source code file (host.xml) is included in the "Java Source Code Warehouse" project. The intent of this project is to help you "Learn Java by Example" TM.

Java - Tomcat tags/keywords

application, automatic, automatic, catalina, context, context, deployment, host, host, name, the, the, this, war

The Tomcat host.xml source code

<?xml version="1.0"?>
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  See the License for the specific language governing permissions and
  limitations under the License.
<!DOCTYPE document [
  <!ENTITY project SYSTEM "project.xml">
<document url="host.html">


    <author email="">Craig R. McClanahan
    <author email="">Remy Maucherat
    <author email="">Yoav Shapira
    <title>The Host Container


<section name="Introduction">

  <p>The Host element represents a virtual host,
  which is an association of a network name for a server (such as
  "" with the particular server on which Catalina is
  running.  In order to be effective, this name must be registered in the
  <em>Domain Name Service (DNS) server that manages the Internet
  domain you belong to - contact your Network Administrator for more

  <p>In many cases, System Administrators wish to associate more than
  one network name (such as <code> and
  <code> with the same virtual host and applications.
  This can be accomplished using the <a href="#Host Name Aliases">Host
  Name Aliases</a> feature discussed below.

<p>One or more Host elements are nested inside an <a href="engine.html">Engine element. Inside the Host element, you can nest <a href="context.html">Context elements for the web applications associated with this virtual host. Exactly one of the Hosts associated with each Engine MUST have a name matching the <code>defaultHost attribute of that Engine.

<blockquote> <p>The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 6, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 6 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references.</p> </em> </section> <section name="Attributes"> <subsection name="Common Attributes"> <p>All implementations of Host support the following attributes:</p> <attributes> <attribute name="appBase" required="true"> <p>The Application Base directory for this virtual host. This is the pathname of a directory that may contain web applications to be deployed on this virtual host. You may specify an absolute pathname for this directory, or a pathname that is relative to the <code>$CATALINA_BASE directory. See <a href="#Automatic Application Deployment">Automatic Application Deployment</a> for more information on automatic recognition and deployment of web applications to be deployed automatically.</p> </attribute> <attribute name="autoDeploy" required="false"> <p>This flag value indicates if new web applications, dropped in to the <code>appBase directory while Tomcat is running, should be automatically deployed. The flag's value defaults to true. See <a href="#Automatic Application Deployment">Automatic Application Deployment</a> for more information.

</attribute> <attribute name="backgroundProcessorDelay" required="false"> <p>This value represents the delay in seconds between the invocation of the backgroundProcess method on this host and its child containers, including all contexts. Child containers will not be invoked if their delay value is not negative (which would mean they are using their own processing thread). Setting this to a positive value will cause a thread to be spawn. After waiting the specified amount of time, the thread will invoke the backgroundProcess method on this host and all its child containers. A host will use background processing to perform live web application deployment related tasks. If not specified, the default value for this attribute is -1, which means the host will rely on the background processing thread of its parent engine.</p> </attribute> <attribute name="className" required="false"> <p>Java class name of the implementation to use. This class must implement the <code>org.apache.catalina.Host interface. If not specified, the standard value (defined below) will be used.</p> </attribute> <attribute name="deployOnStartup" required="false"> <p>This flag value indicates if web applications from this host should be automatically deployed by the host configurator. The flag's value defaults to true. See <a href="#Automatic Application Deployment">Automatic Application Deployment</a> for more information.

</attribute> <attribute name="name" required="true"> <p>Network name of this virtual host, as registered in your <em>Domain Name Service
server. One of the Hosts nested within an <a href="engine.html">Engine MUST have a name that matches the <code>defaultHost setting for that Engine. See <a href="#Host Name Aliases">Host Name Aliases for information on how to assign more than one network name to the same virtual host.</p> </attribute> </attributes> </subsection> <subsection name="Standard Implementation"> <p>The standard implementation of Host is <strong>org.apache.catalina.core.StandardHost. It supports the following additional attributes (in addition to the common attributes listed above):</p> <attributes> <attribute name="deployXML" required="false"> <p>Set to false if you want to disable parsing the context.xml file embedded inside the application (located at <code>/META-INF/context.xml). Security consious environments should set this to <code>false to prevent applications from interacting with the container's configuration. The administrator will then be responsible for providing an external context configuration file, and put it in <code>$CATALINA_HOME/conf/[enginename]/[hostname]/. The flag's value defaults to <code>true.

</attribute> <attribute name="errorReportValveClass" required="false"> <p>Java class name of the error reporting valve which will be used by this Host. The responsability of this valve is to output error reports. Setting this property allows to customize the look of the error pages which will be generated by Tomcat. This class must implement the <code>org.apache.catalina.Valve interface. If none is specified, the value <code>org.apache.catalina.valves.ErrorReportValve will be used by default.</p> </attribute> <attribute name="unpackWARs" required="false"> <p>Set to true if you want web applications that are placed in the <code>appBase directory as web application archive (WAR) files to be unpacked into a corresponding disk directory structure, <code>false to run such web applications directly from a WAR file. See <a href="#Automatic Application Deployment">Automatic Application Deployment</a> for more information.

</attribute> <attribute name="workDir" required="false"> <p>Pathname to a scratch directory to be used by applications for this Host. Each application will have its own sub directory with temporary read-write use. Configuring a Context workDir will override use of the Host workDir configuration. This directory will be made visible to servlets in the web application by a servlet context attribute (of type <code> named <code>javax.servlet.context.tempdir as described in the Servlet Specification. If not specified, a suitable directory underneath <code>$CATALINA_HOME/work will be provided.

</attribute> </attributes> </subsection> </section> <section name="Nested Components"> <p>You can nest one or more Context elements inside this <strong>Host element, each representing a different web application associated with this virtual host.</p> <p>You can nest at most one instance of the following utility components by nesting a corresponding element inside your <strong>Host element:</p> <ul> <li>Realm - Configure a realm that will allow its database of users, and their associated roles, to be shared across all <a href="context.html">Contexts nested inside this Host (unless overridden by a <a href="realm.html">Realm configuration at a lower level).</li> </ul> </section> <section name="Special Features"> <subsection name="Logging"> <p>A host is associated with the <code>org.apache.catalina.core.ContainerBase.[enginename].[hostname] log category. Note that the brackets are actuall part of the name, don't omit them.</p> </subsection> <subsection name="Access Logs"> <p>When you run a web server, one of the output files normally generated is an <em>access log, which generates one line of information for each request processed by the server, in a standard format. Catalina includes an optional <a href="valve.html">Valve implementation that can create access logs in the same standard format created by web servers, or in any number of custom formats.</p> <p>You can ask Catalina to create an access log for all requests processed by an <a href="engine.html">Engine, <a href="host.html">Host, or Context by nesting a <a href="valve.html">Valve element like this:

<source> <Host name="localhost" ...> ... <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".txt" pattern="common"/> ... </Host> </source> <p>See Access Log Valve for more information on the configuration attributes that are supported.</p> </subsection> <subsection name="Automatic Application Deployment"> <p>If you are using the standard Host implementation, the following actions take place automatically when Catalina is first started, if the <code>deployOnStartup property is set to <code>true (which is the default value):

<ul> <li>Any XML file in the <code>$CATALINA_HOME/conf/[engine_name]/[host_name] directory is assumed to contain a <a href="context.html">Context element (and its associated subelements) for a single web application. The <code>docBase attribute of this <code><Context> element will typically be the absolute pathname to a web application directory, or the absolute pathname of a web application archive (WAR) file (which will not be expanded). The path attribute will be automatically set as defined in the <a href="context.html">Context documentation. <li>Any web application archive file within the application base (appBase) directory that does not have a corresponding directory of the same name (without the ".war" extension) will be automatically expanded, unless the <code>unpackWARs property is set to <code>false. If you redeploy an updated WAR file, be sure to delete the expanded directory when restarting Tomcat, so that the updated WAR file will be re-expanded (note that the auto deployer, if enabled, will automatically expand the updated WAR file once the previously expanded directory is removed).</li> <li>Any subdirectory within the application base directory will receive an automatically generated <a href="context.html"> Context</a> element, even if this directory is not mentioned in the <code>conf/server.xml file. This generated Context entry will be configured according to the properties set in any <a href="defaultcontext.html">DefaultContext element nested in this Host element. The context path for this deployed Context will be a slash character ("/") followed by the directory name, unless the directory name is ROOT, in which case the context path will be an empty string ("").</li> </ul> <p>In addition to the automatic deployment that occurs at startup time, you can also request that new XML configuration files, WAR files, or subdirectories that are dropped in to the <code>appBase (or <code>$CATALINA_HOME/conf/[engine_name]/[host_name] in the case of an XML configuration file) directory while Tomcat is running will be automatically deployed, according to the rules described above. The auto deployer will also track web applications for the following changes: <ul> <li>An update to the WEB-INF/web.xml file will trigger a reload of the web application</li> <li>An update to a WAR which has been expanded will trigger an undeploy (<strong>with a removal of the expanded webapp), followed by a deployment</li> <li>An update to a XML configuration file will trigger an undeploy (without the removal of any expanded directory), followed by a deployment of the associated web application</li> </ul> </p> <p>When using automatic deployment, the docBase defined by an XML <a href="context.html">Context file should be outside of the <code>appBase directory. If this is not the case difficulties may be experienced deploying the web application or the application may be deployed twice.</p> <p>Finally, note that if you are defining contexts explicitly, you should probably turn off automatic application deployment. Otherwise, your context will be deployed twice each, and that may cause problems for your app. </p> </subsection> <subsection name="Host Name Aliases"> <p>In many server environments, Network Administrators have configured more than one network name (in the <em>Domain Name Service (DNS) server), that resolve to the IP address of the same server. Normally, each such network name would be configured as a separate <strong>Host element in conf/server.xml, each with its own set of web applications.</p> <p>However, in some circumstances, it is desireable that two or more network names should resolve to the <strong>same virtual host, running the same set of applications. A common use case for this scenario is a corporate web site, where it is desireable that users be able to utilize either <code> or <code> to access exactly the same content and applications.</p> <p>This is accomplished by utilizing one or more Alias elements nested inside your <strong>Host element. For example:</p> <source> <Host name="" ...> ... <Alias></Alias> ... </Host> </source> <p>In order for this strategy to be effective, all of the network names involved must be registered in your DNS server to resolve to the same computer that is running this instance of Catalina.</p> </subsection> <subsection name="Lifecycle Listeners"> <p>If you have implemented a Java object that needs to know when this <strong>Host is started or stopped, you can declare it by nesting a <strong>Listener element inside this element. The class name you specify must implement the <code>org.apache.catalina.LifecycleListener interface, and it will be notified about the occurrence of the coresponding lifecycle events. Configuration of such a listener looks like this:</p> <source> <Host name="localhost" ...> ... <Listener className="com.mycompany.mypackage.MyListener" ... > ... </Host> </source> <p>Note that a Listener can have any number of additional properties that may be configured from this element. Attribute names are matched to corresponding JavaBean property names using the standard property method naming patterns.</p> </subsection> <subsection name="Request Filters"> <p>You can ask Catalina to check the IP address, or host name, on every incoming request directed to the surrounding <a href="engine.html">Engine, Host, or <a href="context.html">Context element. The remote address or name will be checked against a configured list of "accept" and/or "deny" filters, which are defined using the Regular Expression syntax supported by the <a href="">Jakarta Regexp regular expression library. Requests that come from locations that are not accepted will be rejected with an HTTP "Forbidden" error. Example filter declarations:</p> <source> <Host name="localhost" ...> ... <Valve className="org.apache.catalina.valves.RemoteHostValve" allow="*,"/> <Valve className="org.apache.catalina.valves.RemoteAddrValve" deny="192.168.1.*"/> ... </Host> </source> <p>See Remote Address Filter and <a href="valve.html#Remote Host Filter">Remote Host Filter for more information about the configuration options that are supported.</p> </subsection> <subsection name="Single Sign On"> <p>In many environments, but particularly in portal environments, it is desireable to have a user challenged to authenticate themselves only once over a set of web applications deployed on a particular virtual host. This can be accomplished by nesting an element like this inside the Host element for this virtual host:</p> <source> <Host name="localhost" ...> ... <Valve className="org.apache.catalina.authenticator.SingleSignOn" debug="0"/> ... </Host> </source> <p>The Single Sign On facility operates according to the following rules: </p> <ul> <li>All web applications configured for this virtual host must share the same <a href="realm.html">Realm. In practice, that means you can nest the Realm element inside this Host element (or the surrounding <a href="engine.html">Engine element), but not inside a <a href="context.html">Context element for one of the involved web applications.</li> <li>As long as the user accesses only unprotected resources in any of the web applications on this virtual host, they will not be challenged to authenticate themselves.</li> <li>As soon as the user accesses a protected resource in <strong>any web application associated with this virtual host, the user will be challenged to authenticate himself or herself, using the login method defined for the web application currently being accessed.</li> <li>Once authenticated, the roles associated with this user will be utilized for access control decisions across <strong>all of the associated web applications, without challenging the user to authenticate themselves to each application individually.</li> <li>As soon as the user logs out of one web application (for example, by invalidating the corresponding session if form based login is used), the user's sessions in <strong>all web applications will be invalidated. Any subsequent attempt to access a protected resource in any application will require the user to authenticate himself or herself again.</li> <li>The Single Sign On feature utilizes HTTP cookies to transmit a token that associates each request with the saved user identity, so it can only be utilized in client environments that support cookies.</li> </ul> </subsection> <subsection name="User Web Applications"> <p>Many web servers can automatically map a request URI starting with a tilde character ("~") and a username to a directory (commonly named <code>public_html) in that user's home directory on the server. You can accomplish the same thing in Catalina by using a special <strong>Listener element like this (on a Unix system that uses the <code>/etc/passwd file to identify valid users):

<source> <Host name="localhost" ...> ... <Listener className="org.apache.catalina.startup.UserConfig" directoryName="public_html" userClass="org.apache.catalina.startup.PasswdUserDatabase"/> ... </Host> </source> <p>On a server where /etc/passwd is not in use, you can request Catalina to consider all directories found in a specified base directory (such as <code>c:\Homes in this example) to be considered "user home" directories for the purposes of this directive:</p> <source> <Host name="localhost" ...> ... <Listener className="org.apache.catalina.startup.UserConfig" directoryName="public_html" homeBase=c:\Homes" userClass="org.apache.catalina.startup.HomesUserDatabase"/> ... </Host> </source> <p>If a user home directory has been set up for a user named <code>craigmcc, then its contents will be visible from a client browser by making a request to a URL like:</p> <source> </source> <p>Successful use of this feature requires recognition of the following considerations:</p> <ul> <li>Each user web application will be deployed with characteristics established by any <a href="defaultcontext.html">DefaultContext element you have configured for this Host.</li> <li>It is legal to include more than one instance of this Listener element. This would only be useful, however, in circumstances where you wanted to configure more than one "homeBase" directory.</li> <li>The operating system username under which Catalina is executed MUST have read access to each user's web application directory, and all of its contents.</li> </ul> </subsection> </section> </body> </document>

Other Tomcat examples (source code examples)

Here is a short list of links related to this Tomcat host.xml source code file:

... this post is sponsored by my books ...

#1 New Release!

FP Best Seller


new blog posts


Copyright 1998-2021 Alvin Alexander,
All Rights Reserved.

A percentage of advertising revenue from
pages under the /java/jwarehouse URI on this website is
paid back to open source projects.