You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by re...@apache.org on 2006/07/08 00:40:09 UTC

svn commit: r420006 [9/17] - in /tomcat/tc6.0.x/trunk: res/ res/deployer/ webapps/docs/ webapps/docs/META-INF/ webapps/docs/WEB-INF/ webapps/docs/api/ webapps/docs/appdev/ webapps/docs/appdev/sample/ webapps/docs/appdev/sample/docs/ webapps/docs/appdev...

Added: tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,434 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="valve.html">
+
+  &project;
+
+  <properties>
+    <author email="craigmcc@apache.org">Craig R. McClanahan</author>
+    <title>The Valve Component</title>
+  </properties>
+
+<body>
+
+
+<section name="Introduction">
+
+  <p>A <strong>Valve</strong> element represents a component that will be
+  inserted into the request processing pipeline for the associated
+  Catalina container (<a href="engine.html">Engine</a>,
+  <a href="host.html">Host</a>, or <a href="context.html">Context</a>).
+  Individual Valves have distinct processing capabilities, and are
+  described individually below.</p>
+
+    <blockquote><em>
+    <p>The description below uses the variable name $CATALINA_HOME
+    to refer to the directory into which you have installed Tomcat 5,
+    and is the base directory against which most relative paths are
+    resolved.  However, if you have configured Tomcat 5 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></blockquote>
+
+</section>
+
+
+<section name="Access Log Valve">
+
+  <subsection name="Introduction">
+
+    <p>The <strong>Access Log Valve</strong> creates log files in the same
+    format as those created by standard web servers.  These logs can later
+    be analyzed by standard log analysis tools to track page hit counts,
+    user session activity, and so on.  The files produces by this <code>Valve</code>
+    are rolled over nightly at midnight.  This <code>Valve</code>
+    may be associated with any Catalina container (<code>Context</code>,
+    <code>Host</code>, or <code>Engine</code>), and
+    will record ALL requests processed by that container.</p>
+
+  </subsection>
+
+  <subsection name="Attributes">
+
+    <p>The <strong>Access Log Valve</strong> supports the following
+    configuration attributes:</p>
+
+    <attributes>
+
+      <attribute name="className" required="true">
+        <p>Java class name of the implementation to use.  This MUST be set to
+        <strong>org.apache.catalina.valves.AccessLogValve</strong> to use the
+        default access log valve. To use a more optimized access log valve
+        designed for production use, you MUST set this attribute to 
+        <strong>org.apache.catalina.valves.FastCommonAccessLogValve</strong>.
+        In this case, only the <code>common</code> and <code>combined</code>
+        patterns are supported.</p>
+      </attribute>
+
+      <attribute name="directory" required="false">
+        <p>Absolute or relative pathname of a directory in which log files
+        created by this valve will be placed.  If a relative path is
+        specified, it is interpreted as relative to $CATALINA_HOME.  If
+        no directory attribute is specified, the default value is "logs"
+        (relative to $CATALINA_HOME).</p>
+      </attribute>
+
+      <attribute name="pattern" required="false">
+        <p>A formatting layout identifying the various information fields
+        from the request and response to be logged, or the word
+        <code>common</code> or <code>combined</code> to select a
+        standard format.  See below for more information on configuring
+        this attribute. Note that the optimized access does only support
+        <code>common</code> and <code>combined</code> as the value for this
+        attribute.</p>
+      </attribute>
+
+      <attribute name="prefix" required="false">
+        <p>The prefix added to the start of each log file's name.  If not
+        specified, the default value is "access_log.".  To specify no prefix,
+        use a zero-length string.</p>
+      </attribute>
+
+      <attribute name="resolveHosts" required="false">
+        <p>Set to <code>true</code> to convert the IP address of the remote
+        host into the corresponding host name via a DNS lookup.  Set to
+        <code>false</code> to skip this lookup, and report the remote IP
+        address instead.</p>
+      </attribute>
+
+      <attribute name="suffix" required="false">
+        <p>The suffix added to the end of each log file's name.  If not
+        specified, the default value is "".  To specify no suffix,
+        use a zero-length string.</p>
+      </attribute>
+
+      <attribute name="rotatable" required="false">
+        <p>Deafult true. Flag to determine if log rotation should occur.
+           If set to false, then this file is never rotated and
+           <tt>fileDateFormat</tt> is ignored. Use with caution!
+        </p>
+      </attribute>
+
+      <attribute name="condition" required="false">
+        <p>Turns on conditional logging. If set, requests will be
+           logged only if <tt>ServletRequest.getAttribute()</tt> is
+           null. For example, if this value is set to
+           <tt>junk</tt>, then a particular request will only be logged
+           if <tt>ServletRequest.getAttribute("junk") == null</tt>.
+           The use of Filters is an easy way to set/unset the attribute
+           in the ServletRequest on many different requests.
+        </p>
+      </attribute>
+
+      <attribute name="fileDateFormat" required="false">
+        <p>Allows a customized date format in the access log file name.
+           The date format also decides how often the file is rotated.
+           If you wish to rotate every hour, then set this value
+           to: <tt>yyyy-MM-dd.HH</tt>
+        </p>
+      </attribute>
+
+    </attributes>
+
+    <p>Values for the <code>pattern</code> attribute are made up of literal
+    text strings, combined with pattern identifiers prefixed by the "%"
+    character to cause replacement by the corresponding variable value from
+    the current request and response.  The following pattern codes are
+    supported:</p>
+    <ul>
+    <li><b>%a</b> - Remote IP address</li>
+    <li><b>%A</b> - Local IP address</li>
+    <li><b>%b</b> - Bytes sent, excluding HTTP headers, or '-' if zero</li>
+    <li><b>%B</b> - Bytes sent, excluding HTTP headers</li>
+    <li><b>%h</b> - Remote host name (or IP address if
+        <code>resolveHosts</code> is false)</li>
+    <li><b>%H</b> - Request protocol</li>
+    <li><b>%l</b> - Remote logical username from identd (always returns
+        '-')</li>
+    <li><b>%m</b> - Request method (GET, POST, etc.)</li>
+    <li><b>%p</b> - Local port on which this request was received</li>
+    <li><b>%q</b> - Query string (prepended with a '?' if it exists)</li>
+    <li><b>%r</b> - First line of the request (method and request URI)</li>
+    <li><b>%s</b> - HTTP status code of the response</li>
+    <li><b>%S</b> - User session ID</li>
+    <li><b>%t</b> - Date and time, in Common Log Format</li>
+    <li><b>%u</b> - Remote user that was authenticated (if any), else '-'</li>
+    <li><b>%U</b> - Requested URL path</li>
+    <li><b>%v</b> - Local server name</li>
+    <li><b>%D</b> - Time taken to process the request, in millis</li>
+    <li><b>%T</b> - Time taken to process the request, in seconds</li>
+    </ul>
+
+    <p>
+    There is also support to write information from the cookie, incoming
+    header, the Session or something else in the ServletRequest.
+    It is modeled after the apache syntax:
+    <ul>
+    <li><b><code>%{xxx}i</code></b> for incoming headers</li>
+    <li><b><code>%{xxx}c</code></b> for a specific cookie</li>
+    <li><b><code>%{xxx}r</code></b> xxx is an attribute in the ServletRequest</li>
+    <li><b><code>%{xxx}s</code></b> xxx is an attribute in the HttpSession</li>
+    </ul>
+    </p>
+
+
+    <p>The shorthand pattern name <code>common</code> (which is also the
+    default) corresponds to <strong>%h %l %u %t "%r" %s %b"</strong>.</p>
+
+    <p>The shorthand pattern name <code>combined</code> appends the
+    values of the <code>Referer</code> and <code>User-Agent</code> headers,
+    each in double quotes, to the <code>common</code> pattern
+    described in the previous paragraph.</p>
+
+  </subsection>
+
+</section>
+
+
+<section name="Remote Address Filter">
+
+  <subsection name="Introduction">
+
+    <p>The <strong>Remote Address Filter</strong> allows you to compare the
+    IP address of the client that submitted this request against one or more
+    <em>regular expressions</em>, and either allow the request to continue
+    or refuse to process the request from this client.  A Remote Address
+    Filter can be associated with any Catalina container
+    (<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
+    <a href="context.html">Context</a>), and must accept any request
+    presented to this container for processing before it will be passed on.</p>
+
+    <p>The syntax for <em>regular expressions</em> is different than that for
+    'standard' wildcard matching. Tomcat uses the
+    <a href="http://jakarta.apache.org/regexp/">Jakarta Regexp</a> library.
+    Please consult the Regexp documentation for details of the expressions
+    supported.</p>
+
+  </subsection>
+
+  <subsection name="Attributes">
+
+    <p>The <strong>Remote Address Filter</strong> supports the following
+    configuration attributes:</p>
+
+    <attributes>
+
+      <attribute name="className" required="true">
+        <p>Java class name of the implementation to use.  This MUST be set to
+        <strong>org.apache.catalina.valves.RemoteAddrValve</strong>.</p>
+      </attribute>
+
+      <attribute name="allow" required="false">
+        <p>A comma-separated list of <em>regular expression</em> patterns
+        that the remote client's IP address is compared to.  If this attribute
+        is specified, the remote address MUST match for this request to be
+        accepted.  If this attribute is not specified, all requests will be
+        accepted UNLESS the remote address matches a <code>deny</code>
+        pattern.</p>
+      </attribute>
+
+      <attribute name="deny" required="false">
+        <p>A comma-separated list of <em>regular expression</em> patterns
+        that the remote client's IP address is compared to.  If this attribute
+        is specified, the remote address MUST NOT match for this request to be
+        accepted.  If this attribute is not specified, request acceptance is
+        governed solely by the <code>accept</code> attribute.</p>
+      </attribute>
+
+    </attributes>
+
+  </subsection>
+
+</section>
+
+
+<section name="Remote Host Filter">
+
+  <subsection name="Introduction">
+
+    <p>The <strong>Remote Host Filter</strong> allows you to compare the
+    hostname of the client that submitted this request against one or more
+    <em>regular expressions</em>, and either allow the request to continue
+    or refuse to process the request from this client.  A Remote Host
+    Filter can be associated with any Catalina container
+    (<a href="engine.html">Engine</a>, <a href="host.html">Host</a>, or
+    <a href="context.html">Context</a>), and must accept any request
+    presented to this container for processing before it will be passed on.</p>
+
+    <p>The syntax for <em>regular expressions</em> is different than that for
+    'standard' wildcard matching. Tomcat uses the
+    <a href="http://jakarta.apache.org/regexp/">Jakarta Regexp</a> library.
+    Please consult the Regexp documentation for details of the expressions
+    supported.</p>
+
+  </subsection>
+
+  <subsection name="Attributes">
+
+    <p>The <strong>Remote Host Filter</strong> supports the following
+    configuration attributes:</p>
+
+    <attributes>
+
+      <attribute name="className" required="true">
+        <p>Java class name of the implementation to use.  This MUST be set to
+        <strong>org.apache.catalina.valves.RemoteHostValve</strong>.</p>
+      </attribute>
+
+      <attribute name="allow" required="false">
+        <p>A comma-separated list of <em>regular expression</em> patterns
+        that the remote client's hostname is compared to.  If this attribute
+        is specified, the remote hostname MUST match for this request to be
+        accepted.  If this attribute is not specified, all requests will be
+        accepted UNLESS the remote hostname matches a <code>deny</code>
+        pattern.</p>
+      </attribute>
+
+      <attribute name="deny" required="false">
+        <p>A comma-separated list of <em>regular expression</em> patterns
+        that the remote client's hostname is compared to.  If this attribute
+        is specified, the remote hostname MUST NOT match for this request to be
+        accepted.  If this attribute is not specified, request acceptance is
+        governed solely by the <code>accept</code> attribute.</p>
+      </attribute>
+
+    </attributes>
+
+  </subsection>
+
+</section>
+
+
+<section name="Request Dumper Valve">
+
+
+  <subsection name="Introduction">
+
+    <p>The <em>Request Dumper Valve</em> is a useful tool in debugging
+    interactions with a client application (or browser) that is sending
+    HTTP requests to your Tomcat-based server.  When configured, it causes
+    details about each request processed by its associated <code>Engine</code>, 
+    <code>Host</code>, or <code>Context</code> to be logged according to 
+    the logging configuration for that container.</p>
+
+    <p><strong>WARNING: Using this valve has side-effects.</strong>  The
+    output from this valve includes any parameters included with the request.
+    The parameters will be decoded using the default platform encoding. Any
+    subsequent calls to <code>request.setCharacterEncoding()</code> within
+    the web application will have no effect.</p>
+
+  </subsection>
+
+
+  <subsection name="Attributes">
+
+    <p>The <strong>Request Dumper Valve</strong> supports the following
+    configuration attributes:</p>
+
+    <attributes>
+
+      <attribute name="className" required="true">
+        <p>Java class name of the implementation to use.  This MUST be set to
+        <strong>org.apache.catalina.valves.RequestDumperValve</strong>.</p>
+      </attribute>
+
+    </attributes>
+
+  </subsection>
+
+
+</section>
+
+
+<section name="Single Sign On Valve">
+
+  <subsection name="Introduction">
+
+    <p>The <em>Single Sign On Vale</em> is utilized when you wish to give users
+    the ability to sign on to any one of the web applications associated with
+    your virtual host, and then have their identity recognized by all other
+    web applications on the same virtual host.</p>
+
+    <p>See the <a href="host.html#Single Sign On">Single Sign On</a> special
+    feature on the <strong>Host</strong> element for more information.</p>
+
+  </subsection>
+
+
+  <subsection name="Attributes">
+
+    <p>The <strong>Single Sign On</strong> Valve supports the following
+    configuration attributes:</p>
+
+    <attributes>
+
+      <attribute name="className" required="true">
+        <p>Java class name of the implementation to use.  This MUST be set to
+        <strong>org.apache.catalina.authenticator.SingleSignOn</strong>.</p>
+      </attribute>
+
+      <attribute name="requireReauthentication" required="false">
+        <p>Default false. Flag to determine whether each request needs to be 
+        reauthenticated to the security <strong>Realm</strong>. If "true", this
+        Valve uses cached security credentials (username and password) to
+        reauthenticate to the <strong>Realm</strong> each request associated 
+        with an SSO session.  If "false", the Valve can itself authenticate 
+        requests based on the presence of a valid SSO cookie, without 
+        rechecking with the <strong>Realm</strong>.</p>
+      </attribute>
+ 
+
+    </attributes>
+
+  </subsection>
+
+
+</section>
+
+
+<section name="Form Authenticator Valve">
+
+  <subsection name="Introduction">
+
+    <p>The <strong>Form Authenticator Valve</strong> is automatically added to
+    any <a href="context.html">Context</a> that is configured to use FORM
+    authentication.</p>
+
+    <p>If any non-default settings are required, the valve may be configured
+    within <a href="context.html">Context</a> element with the required
+    values.</p>
+
+  </subsection>
+
+  <subsection name="Attributes">
+
+    <p>The <strong>Form Authenticator Valve</strong> supports the following
+    configuration attributes:</p>
+
+    <attributes>
+
+      <attribute name="className" required="true">
+        <p>Java class name of the implementation to use.  This MUST be set to
+        <strong>org.apache.catalina.authenticator.FormAuthenticator</strong>.</p>
+      </attribute>
+
+      <attribute name="characterEncoding" required="false">
+        <p>Character encoding to use to read the username and password parameters
+        from the request. If not set, the encoding of the request body will be
+        used.</p>
+      </attribute>
+
+    </attributes>
+
+  </subsection>
+
+</section>
+
+
+</body>
+
+
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/config/valve.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/docs/connectors.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/connectors.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/connectors.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/connectors.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,61 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="connectors.html">
+
+    &project;
+
+    <properties>
+        <author email="remm@apache.org">Remy Maucherat</author>
+        <title>Connectors How To</title>
+    </properties>
+
+<body>
+
+<section name="Introduction">
+
+<p>Choosing a connector to use with Tomcat can be difficult. This page will
+list the connectors which are supported with this Tomcat release, and will
+hopefully help you make the right choice according to your needs.</p>
+
+</section>
+
+<section name="HTTP">
+
+<p>The HTTP connector is setup by default with Tomcat, and is ready to use. This
+connector features the lowest latency and best overall performance.</p>
+
+<p>For clustering, a HTTP load balancer <b>with support for web sessions stickiness</b>
+must be installed to direct the traffic to the Tomcat servers. Tomcat supports mod_proxy
+(on Apache HTTP Server 2.x, and included by default in Apache HTTP Server 2.2) as the load balancer. 
+It should be noted that the performance of HTTP proxying is usually lower than the 
+performance of AJP, so AJP clustering is often preferable.</p>
+
+</section>
+
+<section name="AJP">
+
+<p>When using a single server, the performance when using a native webserver in 
+front of the Tomcat instance is most of the time significantly worse than a
+standalone Tomcat with its default HTTP connector, even if a large part of the web
+application is made of static files. If integration with the native webserver is 
+needed for any reason, an AJP connector will provide faster performance than 
+proxied HTTP. AJP clustering is the most efficient from the Tomcat perspective. 
+It is otherwise functionally equivalent to HTTP clustering.</p>
+
+<p>The native connectors supported with this Tomcat release are:
+<ul>
+<li>JK 1.2.x with any of the supported servers</li>
+<li>mod_proxy on Apache HTTP Server 2.x (included by default in Apache HTTP Server 2.2), 
+with AJP enabled</li>
+</ul>
+</p>
+
+<p><b>Other native connectors supporting AJP may work, but are no longer supported.</b></p>
+
+</section>
+
+</body>
+
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/connectors.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/docs/default-servlet.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/default-servlet.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/default-servlet.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/default-servlet.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,298 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="default-servlet.html">
+
+    &project;
+
+    <properties>
+        <author email="funkman@apache.org">Tim Funk</author>
+        <title>Default Servlet Reference</title>
+    </properties>
+
+<body>
+
+<section name="Introduction">
+
+This discusses different ways to manipulate the default servlet. Topics are
+<ul>
+  <li><a href="#what">What is the DefaultServlet?</a></li>
+  <li><a href="#where">Where is it declared?</a></li>
+  <li><a href="#change">What can I change?</a></li>
+  <li><a href="#dir">How do I customize directory listings?</a></li>
+  <li><a href="#secure">How do I secure directory listings?</a></li>
+
+</ul>
+
+</section>
+
+<section name="What is the DefaultServlet">
+<a name="what"></a>
+The default servlet is the servlet which serves static resources as well
+as serves the directory listings (if directory listings are enabled).
+
+</section>
+
+<section name="Where is it declared?">
+<a name="where"></a>
+It is declared globally in <i>$CATALINA_HOME/conf/web.xml</i>.
+By default here is it's declaration:
+<source>
+    &lt;servlet&gt;
+        &lt;servlet-name&gt;default&lt;/servlet-name&gt;
+        &lt;servlet-class&gt;
+          org.apache.catalina.servlets.DefaultServlet
+        &lt;/servlet-class&gt;
+        &lt;init-param&gt;
+            &lt;param-name&gt;debug&lt;/param-name&gt;
+            &lt;param-value&gt;0&lt;/param-value&gt;
+        &lt;/init-param&gt;
+        &lt;init-param&gt;
+            &lt;param-name&gt;listings&lt;/param-name&gt;
+            &lt;param-value&gt;true&lt;/param-value&gt;
+        &lt;/init-param&gt;
+        &lt;load-on-startup&gt;1&lt;/load-on-startup&gt;
+    &lt;/servlet&gt;
+
+...
+
+    &lt;servlet-mapping&gt;
+        &lt;servlet-name&gt;default&lt;/servlet-name&gt;
+        &lt;url-pattern&gt;/&lt;/url-pattern&gt;
+    &lt;/servlet-mapping&gt;
+
+</source>
+
+So by default, the default servlet is loaded at webapp startup and
+directory listings are enabled and debugging is turned off.
+</section>
+
+<section name="What can I change?">
+<a name="change"></a>
+The DefaultServlet allows the following initParamters:
+
+<table border="1">
+  <tr>
+    <th valign='top'>debug</th>
+    <td valign='top'>
+        Debugging level. It is not very useful unless you are a tomcat
+        developer. As
+        of this writing, useful values are 0, 1, 11, 1000.
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>listings</th>
+    <td valign='top'>
+        If no welcome file is present, can a directory listing be
+        shown?
+        value may be <b>true</b> or <b>false</b>
+        <br />
+        Welcome files are part of the servlet api.
+        <br />
+        <b>WARNING:</b> Listings of directories containing many entries are
+        expensive. Multiple requests for large directory listings can consume
+        significant proportions of server resources.
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>readmeFile</th>
+    <td valign='top'>
+        If a directory listing is presented, a readme file may also
+        be presented with the listing. This file is inserted as is
+        so it may contain HTML. default value is null
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>globalXsltFile</th>
+    <td valign='top'>
+        If you wish to customize your directory listing, you
+        can use an XSL transformation. This value is an absolute
+        file name which be used for all direcotory listings.
+        This can be disabled by per webapp by also declaring the
+        default servlet in your local webapp's web.xml. The format
+        of the xml is shown below.
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>localXsltFile</th>
+    <td valign='top'>
+        You may also customize your directory listing by directory by
+        configuring <code>localXsltFile</code>. This should be a relative
+        file name in the directory where the listing will take place.
+        This overrides <code>globalXsltFile</code>. If this value
+        is present but a file does not exist, then
+        <code>globalXsltFile</code> will be used. If
+        <code>globalXsltFile</code> does not exist, then the default
+        directory listing will be shown.
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>input</th>
+    <td valign='top'>
+        Input buffer size (in bytes) when reading
+        resources to be served.  [2048]
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>output</th>
+    <td valign='top'>
+        Output buffer size (in bytes) when writing
+        resources to be served.  [2048]
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>readonly</th>
+    <td valign='top'>
+        Is this context "read only", so HTTP commands like PUT and
+        DELETE are rejected?  [true]
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>fileEncoding</th>
+    <td valign='top'>
+        File encoding to be used when reading static resources.
+        [platform default]
+    </td>
+  </tr>
+  <tr>
+    <th valign='top'>sendfileSize</th>
+    <td valign='top'>
+        If the connector used supports sendfile, this represents the minimal 
+        file size in KB for which sendfile will be used. Use a negative value 
+        to always disable sendfile. [48]
+    </td>
+  </tr>
+
+</table>
+</section>
+
+<section name="How do I customize directory listings?">
+<a name="dir"></a>
+<p>You can override DefaultServlet with you own implementation and use that
+in your web.xml declaration. If you
+can undertand what was just said, we will assume yo can read the code
+to DefaultServlet servlet and make the appropriate adjustments. (If not,
+then that method isn't for you)
+</p>
+<p>
+You can use either  <code>localXsltFile</code> or
+<code>globalXsltFile</code> and DefaultServlet will create
+an xml document and run it through an xsl transformation based
+on the values provided in <code>localXsltFile</code> and
+<code>globalXsltFile</code>. <code>localXsltFile</code> is first
+checked, followed by <code>globalXsltFile</code>, then default
+behaviors takes place.
+</p>
+
+<p>
+Format:
+<source>
+    &lt;listing&gt;
+     &lt;entries&gt;
+      &lt;entry type='file|dir' urlPath='aPath' size='###' date='gmt date'&gt;
+        fileName1
+      &lt;/entry&gt;
+      &lt;entry type='file|dir' urlPath='aPath' size='###' date='gmt date'&gt;
+        fileName2
+      &lt;/entry&gt;
+      ...
+     &lt;/entries&gt;
+     &lt;readme&gt;&lt;/readme&gt;
+    &lt;/listing&gt;
+</source>
+<ul>
+  <li>size will be missing if <code>type='dir'</code></li>
+  <li>Readme is a CDATA entry</li>
+</ul>
+</p>
+The following is a sample xsl file which mimics the default tomcat behavior:
+<source>
+&lt;?xml version="1.0"?&gt;
+
+&lt;xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
+  version="1.0"&gt;
+
+  &lt;xsl:output method="xhtml" encoding="iso-8859-1" indent="no"/&gt;
+
+  &lt;xsl:template match="listing"&gt;
+   &lt;html&gt;
+    &lt;head&gt;
+      &lt;title&gt;
+        Sample Directory Listing For
+        &lt;xsl:value-of select="@directory"/&gt;
+      &lt;/title&gt;
+      &lt;style&gt;
+        h1{color : white;background-color : #0086b2;}
+        h3{color : white;background-color : #0086b2;}
+        body{font-family : sans-serif,Arial,Tahoma;
+             color : black;background-color : white;}
+        b{color : white;background-color : #0086b2;}
+        a{color : black;} HR{color : #0086b2;}
+      &lt;/style&gt;
+    &lt;/head&gt;
+    &lt;body&gt;
+      &lt;h1&gt;Sample Directory Listing For
+            &lt;xsl:value-of select="@directory"/&gt;
+      &lt;/h1&gt;
+      &lt;hr size="1" /&gt;
+      &lt;table cellspacing="0"
+                  width="100%"
+            cellpadding="5"
+                  align="center"&gt;
+        &lt;tr&gt;
+          &lt;th align="left"&gt;Filename&lt;/th&gt;
+          &lt;th align="center"&gt;Size&lt;/th&gt;
+          &lt;th align="right"&gt;Last Modified&lt;/th&gt;
+        &lt;/tr&gt;
+        &lt;xsl:apply-templates select="entries"/&gt;
+        &lt;/table&gt;
+      &lt;xsl:apply-templates select="readme"/&gt;
+      &lt;hr size="1" /&gt;
+      &lt;h3&gt;Apache Tomcat/5.0&lt;/h3&gt;
+    &lt;/body&gt;
+   &lt;/html&gt;
+  &lt;/xsl:template&gt;
+
+
+  &lt;xsl:template match="entries"&gt;
+    &lt;xsl:apply-templates select="entry"/&gt;
+  &lt;/xsl:template&gt;
+
+  &lt;xsl:template match="readme"&gt;
+    &lt;hr size="1" /&gt;
+    &lt;pre&gt;&lt;xsl:apply-templates/&gt;&lt;/pre&gt;
+  &lt;/xsl:template&gt;
+
+  &lt;xsl:template match="entry"&gt;
+    &lt;tr&gt;
+      &lt;td align="left"&gt;
+        &lt;xsl:variable name="urlPath" select="@urlPath"/&gt;
+        &lt;a href="{$urlPath}"&gt;
+          &lt;tt&gt;&lt;xsl:apply-templates/&gt;&lt;/tt&gt;
+        &lt;/a&gt;
+      &lt;/td&gt;
+      &lt;td align="right"&gt;
+        &lt;tt&gt;&lt;xsl:value-of select="@size"/&gt;&lt;/tt&gt;
+      &lt;/td&gt;
+      &lt;td align="right"&gt;
+        &lt;tt&gt;&lt;xsl:value-of select="@date"/&gt;&lt;/tt&gt;
+      &lt;/td&gt;
+    &lt;/tr&gt;
+  &lt;/xsl:template&gt;
+
+&lt;/xsl:stylesheet&gt;
+</source>
+
+</section>
+
+<section name="How do I secure directory listings?">
+<a name="secure"></a>
+Use web.xml in each individual webapp. See the security section of the
+Servlet specification.
+
+</section>
+
+</body>
+
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/default-servlet.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/docs/deployer-howto.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/deployer-howto.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/deployer-howto.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/deployer-howto.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,330 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="deployer-howto.html">
+
+    &project;
+
+    <properties>
+        <author>Allistair Crossley</author>
+        <title>Tomcat Web Application Deployment</title>
+    </properties>
+
+<body>
+
+    <section name="Table of Contents">
+    <ul>
+        <li><a href="#Introduction">Introduction</a></li>
+        <li><a href="#Installation">Installation</a></li>
+        <li><a href="#A word on Contexts">A word on Contexts</a></li>
+        <li><a href="#Deployment on Tomcat startup">Deployment on Tomcat startup</a></li>
+        <li><a href="#Deploying on a running Tomcat server">Deploying on a running Tomcat server</a></li>
+        <li><a href="#Deploying using the Tomcat Manager">Deploying using the Tomcat Manager</a></li>
+        <li><a href="#Deploying using the Client Deployer Package">Deploying using
+            the Tomcat Client Deployer</a></li>
+    </ul>
+    
+    </section>
+    
+    <section name="Introduction">
+        <p>
+            Deployment is the term used for the process of installing a web
+            application (either a 3rd party WAR or your own custom web application) 
+            into the Tomcat server. 
+        </p>
+        <p>
+            Web application deployment may be accomplished in a number of ways
+            within the Tomcat server.
+            <ul>
+                <li>Statically; the web application is setup before Tomcat is started</li>
+                <li>
+                    Dynamically; in conjunction with the Tomcat Manager web application or 
+                    manipulating already deployed web applications
+                </li>
+            </ul>
+        </p>
+        <p>
+            The Tomcat Manager is a tool that allows URL-based web application
+            deployment features. There is also a tool called the Client Deployer,
+            which is a command shell based script that interacts with the Tomcat
+            Manager but provides additional functionality such as compiling and
+            validating web applications as well as packaging web application into
+            web application resource (WAR) files.
+        </p>
+    </section>
+    
+    <section name="Installation">
+        <p>
+            There is no installation required for static deployment of web
+            applications as this is provided out of the box by Tomcat. Nor is any
+            installation required for deployment functions with the Tomcat Manager, 
+            although some configuration is required as detailed in the 
+            Tomcat Manager manual. An installation is however required if you wish
+            to use the Tomcat Client Deployer (TCD). 
+        </p>   
+        <p>
+            The TCD is not packaged with the Tomcat core 
+            distribution, and must therefore be downloaded separately from 
+            the Downloads area. The download is usually labelled 
+            <i>jakarta-tomcat-5.5.x-deployer</i>.
+        </p>
+        <p>
+            TCD has prerequisites of Apache Ant 1.6.2+ and a Java installation.
+            Your environment should define an ANT_HOME environment value pointing to
+            the root of your Ant installation, and a JAVA_HOME value pointing to
+            your Java installation. Additionally, you should ensure Ant's ant
+            command, and the Java javac compiler command run from the command shell
+            that your operating system provides.
+        </p>
+        <ol>
+            <li>Download the TCD distribution</li>
+            <li>
+                The TCD package need not be extracted into any existing Tomcat
+                installation, it can be extracted to any location.
+            </li>
+            <li>Read Using the <a href="#Deploying using the Client Deployer Package">
+            Tomcat Client Deployer</a></li>
+        </ol>
+    </section>
+        
+    <section name="A word on Contexts">
+        <p>
+            In talking about deployment of web applications, the concept of a
+            <i>Context</i> is required to be understood. A Context is what Tomcat 
+            calls a web application.
+        </p>
+        <p>
+            In order to configure a Context within Tomcat a <i>Context Descriptor</i>
+            is required. A Context Descriptor is simply an XML file that contains
+            Tomcat related configuration for a Context, e.g naming resources or 
+            session manager configuration. In earlier versions of
+            Tomcat the content of a Context Descriptor configuration was often stored within
+            Tomcat's primary configuration file <i>server.xml</i> but this is now
+            discouraged (although it currently still works).
+        </p>
+        <p>        
+            Context Descriptors not only help Tomcat to know how to configure 
+            Contexts but other tools such as the Tomcat Manager and TDC often use 
+            these Context Descriptors to perform their roles properly.
+        </p>
+        <p>
+            The locations for Context Descriptors are;
+            <ol>
+                <li>$CATALINA_HOME/conf/[enginename]/[hostname]/context.xml</li>
+                <li>$CATALINA_HOME/webapps/[webappname]/META-INF/context.xml</li>
+            </ol>
+            If a Context Descriptor is not provided for a Context, Tomcat
+            automatically creates one and places it in (1) with a filename of
+            [webappname].xml although if manually created, the filename need not
+            match the web application name as Tomcat is concerned only with the
+            Context configuration contained within the Context Descriptor file(s).
+        </p>
+    </section>
+    
+    <section name="Deployment on Tomcat startup">
+        <p>
+            If you are not interested in using the Tomcat Manager, or TCD, 
+            then you'll need to deploy your web applications 
+            statically to Tomcat, followed by a Tomcat startup. The location you
+            deploy web applications to for this type of deployment is called the 
+            <code>appBase</code> which is specified per Host. You either copy a
+            so-called <i>exploded web application</i>, i.e non-compressed, to this
+            location, or a compressed web application resource .WAR file.
+        </p>
+        <p>
+            The web applications present in the location specified by the Host's
+            (default Host is "localhost") <code>appBase</code> attribute (default
+            appBase is "$CATALINA_HOME/webapps") will be deployed on Tomcat startup 
+            only if the Host's <code>deployOnStartup</code> attribute is "true".
+        </p>
+        <p>
+            The following deployment sequence will occur on Tomcat startup in that
+            case:
+        </p>
+        <ol>
+            <li>Any Context Descriptors will be deployed first.</li>
+            <li>
+                Exploded web applications not referenced by any Context
+                Descriptor will then be deployed. If they have an associated 
+                .WAR file in the appBase and it is newer than the exploded web application, 
+                the exploded directory will be removed and the webapp will be 
+                redeployed from the .WAR
+            </li>
+            <li>.WAR files will be deployed</li>
+        </ol>
+        <p>
+            Note again that for each deployed web application, a 
+            Context Descriptor will be created <i>unless one exists already</i>.
+        </p>
+    </section>
+    
+    <section name="Deploying on a running Tomcat server">
+        <p>
+            It is possible to deploy web applications to a running Tomcat server.
+        </p>
+        <p>
+            If the Host <code>autoDeploy</code> attribute is "true", the Host will 
+            attempt to deploy and update web applications dynamically, as needed,
+            for example if a new .WAR is dropped into the <code>appBase</code>. 
+            For this to work, the Host needs to have background processing 
+            enabled which is the default configuration.
+        </p>
+        
+        <p>
+            <code>autoDeploy</code> set to "true" and a running Tomcat allows for:
+        </p>
+        <ul>
+            <li>Deployment of .WAR files copied into the Host <code>appBase</code>.</li>
+            <li>
+                Deployment of exploded web applications which are
+                copied into the Host <code>appBase</code>.
+            </li>
+            <li>
+                Re-deployment of a web application which has already been deployed from
+                a .WAR when the new .WAR is provided. In this case the exploded 
+                web application is removed, and the .WAR is expanded again. 
+                Note that the explosion will not occur if the Host is configured 
+                so that .WARs are not exploded with a <code>unpackWARs</code>
+                attribute set to "false", in which case the web application 
+                will be simply redeployed as a compressed archive.
+            </li>
+            <li>
+                Re-deployment of a web application if the /WEB-INF/web.xml file (or any
+                other resource defined as a WatchedResource) is updated.
+            </li>
+            <li>
+                Re-deployment of a web application if the Context Descriptor file from which
+                the web application has been deployed is updated.
+            </li>
+            <li>
+                Re-deployment of a web application if a Context Descriptor file (with a
+                filename corresponding to the Context path of the previously deployed
+                web application) is added to the 
+                <code>$CATALINA_HOME/conf/[enginename]/[hostname]/</code>
+                directory.
+            </li>
+            <li>
+                Undeployment of a web application if its document base (docBase)
+                is deleted. Note that on Windows, this assumes that anti-locking 
+                features (see Context configuration) are enabled, otherwise it is not 
+                possible to delete the resources of a running web application.
+            </li>
+        </ul>
+        <p>
+            Note that web application reloading can also be configured in the loader, in which
+            case loaded classes will be tracked for changes.
+        </p>
+    </section>
+    
+    <section name="Deploying using the Tomcat Manager">
+        <p>
+            The Tomcat Manager is covered in its <a href="manager-howto.html">own manual page</a>. 
+        </p>
+    </section>
+        
+    <section name="Deploying using the Client Deployer Package">
+        <p>
+            Finally, deployment of web application may be achieved using the 
+            Tomcat Client Deployer. This is a package which can be used to 
+            validate, compile, compress to .WAR, and deploy web applications to 
+            production or development Tomcat servers. It should be noted that this feature 
+            uses the Tomcat Manager and as such the target Tomcat server should be
+            running.
+        </p>
+    
+        <p>
+            It is assumed the user will be familar with Apache Ant for using the TCD.
+            Apache Ant is a scripted build tool. The TCD comes pre-packaged with a
+            build script to use. Only a modest understanding of Apache Ant is
+            required (installation as listed earlier in this page, and familiarity
+            with using the operating system command shell and configuring
+            environment variables).
+        </p>
+        
+        <p>
+            The TCD includes Ant tasks, the Jasper page compiler for JSP compilation 
+            before deployment, as well as a task which
+            validates the web application Context Descriptor. The validator task (class
+            <code>org.apache.catalina.ant.ValidatorTask</code>) allows only one parameter:
+            the base path of an exploded web application.
+        </p>
+    
+        <p>
+            The TCD uses an exploded web application as input (see the list of the
+            properties used below). A web application that is programatically 
+            deployed with the deployer may include a Context Desciptor in 
+            <code>/META-INF/context.xml</code>.
+        </p>
+    
+        <p>
+            The TCD includes a ready-to-use Ant script, with the following targets:
+        </p>
+        <ul>
+            <li>
+                <code>compile</code> (default): Compile and validate the web 
+                application. This can be used standalone, and does not need a running
+                Tomcat server. The compiled application will only run on the associated
+                Tomcat 5.5.x server release, and is not guaranteed to work on another
+                Tomcat release, as the code generated by Jasper depends on its runtime
+                component. It should also be noted that this target will also compile
+                automatically any Java source file located in the 
+                <code>/WEB-INF/classes</code> folder of the web application.</li>
+            <li>
+                <code>deploy</code>: Deploy a web application (compiled or not) to 
+                a Tomcat server.
+            </li>
+            <li><code>undeploy</code>: Undeploy a web application</li>
+            <li><code>start</code>: Start web application</li>
+            <li><code>reload</code>: Reload web application</li>
+            <li><code>stop</code>: Stop web application</li>
+        </ul>
+        
+        <p>
+            In order for the deployment to be configured, create a file
+            called <code>deployer.properties</code> in the TCD installation
+            directory root. In this file, add the following name=value pairs per
+            line:
+        </p>
+        
+        <p>
+            Additionally, you will need to ensure that a user has been 
+            setup for the target Tomcat Manager (which TCD uses) otherwise the TCD
+            will not authenticate with the Tomcat Manager and the deployment will
+            fail. To do this, see the Tomcat Manager page.        
+        </p>
+        
+        <ul>
+            <li>
+                <code>build</code>: The build folder used will be, by default, 
+                <code>${build}/webapp/${path}</code>. After the end of the execution
+                of the <code>compile</code> target, the web application .WAR will be
+                located at <code>${build}/webapp/${path}.war</code>.
+            </li>
+            <li>
+                <code>webapp</code>: The directory containing the exploded web application 
+                which will be compiled and validated. By default, the folder is
+                <code>myapp</code>.
+            </li>
+            <li>
+                <code>path</code>: Deployed context path of the web application, 
+                by default <code>/myapp</code>.
+            </li>
+            <li>
+                <code>url</code>: Absolute URL to the Tomcat Manager web application of a 
+                running Tomcat server, which will be used to deploy and undeploy the
+                web application. By default, the deployer will attempt to access 
+                a Tomcat instance running on localhost, at 
+                <code>http://localhost:8080/manager</code>.
+            </li>
+            <li>
+                <code>username</code>: Tomcat Manager username (user should have a role of
+                manager)
+            </li>
+            <li><code>password</code>: Tomcat Manager password.</li>
+        </ul>
+    </section>
+
+</body>
+
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/deployer-howto.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/docs/developers.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/developers.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/developers.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/developers.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,58 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="developers.html">
+
+  &project;
+
+  <properties>
+    <author email="remm@apache.org">Remy Maucherat</author>
+    <author email="yoavs@apache.org">Yoav Shapira</author>
+    <title>Tomcat Developers</title>
+  </properties>
+
+<body>
+
+  <section name="Active Developers">
+
+    <p>
+      The list indicates the developers' main areas of interest. Feel free to
+      add to the list :) The developers email addresses are 
+      <code>[login]@apache.org</code>. Please <strong>do not</strong> contact 
+      developers directly for any support issues (please post to the 
+      tomcat-users mailing list instead, or one of the other support 
+      resources; some organizations and individual consultants also offer 
+      for pay Tomcat support, as listed on the 
+      <a href="http://jakarta.apache.org/site/vendors.html">vendors page</a>
+      on the Jakarta website).
+    </p>
+
+    <ul>
+      <li>Amy Roh (amyroh): Catalina, Admin webapp</li>
+      <li>Bill Barker (billbarker): Connectors</li>
+      <li>Costin Manolache (costin): Catalina, Connectors</li>
+      <li>Filip Hanik (fhanik): Clustering</li>
+      <li>Glenn Nielsen (glenn): Catalina, Connectors</li>
+      <li>Henri Gomez (hgomez): Connectors</li>
+      <li>Jan Luehe (luehe): Jasper</li>
+      <li>Jean-Francois Arcand (jfarcand): Catalina</li>
+      <li>Jean-Frederic Clere (jfclere): Connectors</li>
+      <li>Kin-Man Chung (kinman): Jasper</li>
+      <li>Mladen Turk (mturk): Connectors</li>
+      <li>Peter Rossbach (pero): Catalina, Clustering, JMX</li>
+      <li>Remy Maucherat (remm): Catalina, Connectors, Docs</li>
+      <li>Tim Funk (funkman): Catalina, Docs</li>
+      <li>Yoav Shapira (yoavs): Docs, JMX, Catalina, balancer, Release Manager</li>
+    </ul>
+
+  </section>
+
+  <section name="Retired Developers">
+
+
+
+  </section>
+
+</body>
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/developers.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-apps.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-apps.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-apps.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-apps.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,278 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="fs-admin-apps.html">
+
+  &project;
+
+  <properties>
+    <author email="craigmcc@apache.org">Craig McClanahan</author>
+    <title>Administrative Apps - Overall Requirements</title>
+    <revision>$Id: fs-admin-apps.xml 301989 2003-06-25 01:38:16Z yoavs $</revision>
+  </properties>
+
+<body>
+
+
+<section name="Overview">
+
+
+  <subsection name="Introduction">
+
+    <p>The purpose of this specification is to define high level requirements
+    for administrative applications that can be used to manage the operation
+    of a running Tomcat 5 container.  A variety of <em>Access Methods</em>
+    to the supported administrative functionality shall be supported, to
+    meet varying requirements:</p>
+    <ul>
+    <li><em>As A Scriptable Web Application</em> - The existing
+        <code>Manager</code> web application provides a simple HTTP-based
+        interface for managing Tomcat through commands that are expressed
+        entirely through a request URI.  This is useful in environments
+        where you wish to script administrative commands with tools that
+        can generate HTTP transactions.</li>
+    <li><em>As An HTML-Based Web Application</em> - Use an HTML presentation
+        to provide a GUI-like user interface for humans to interact with the
+        administrative capabilities.</li>
+    <li><em>As SOAP-Based Web Services</em> - The operational commands to
+        administer Tomcat are made available as web services that utilize
+        SOAP message formats.</li>
+    <li><em>As Java Management Extensions (JMX) Commands</em> - The operational
+        commands to administer Tomcat are made available through JMX APIs,
+        for integration into management consoles that utilize them.</li>
+    <li><em>Other Remote Access APIs</em> - Other remote access APIs, such
+        as JINI, RMI, and CORBA can also be utilized to access administrative
+        capabilities.</li>
+    </ul>
+
+    <p>Underlying all of the access methods described above, it is assumed
+    that the actual operations are performed either directly on the
+    corresponding Catalina components (such as calling the
+    <code>Deployer.deploy()</code> method to deploy a new web application),
+    or through a "business logic" layer that can be shared across all of the
+    access methods.  This approach minimizes the cost of adding new
+    administrative capabilities later -- it is only necessary to add the
+    corresponding business logic function, and then write adapters to it for
+    all desired access methods.</p>
+
+    <p>The current status of this functional specification is
+    <strong>PROPOSED</strong>.  It has not yet been discussed and
+    agreed to on the TOMCAT-DEV mailing list.</p>
+
+  </subsection>
+
+
+  <subsection name="External Specifications">
+
+    <p>The implementation of this functionality depends on the following
+    external specifications:</p>
+    <ul>
+    <li><a href="http://java.sun.com/products/jdk/idl/index.html">Java
+        IDL</a> (for CORBA, included in the JDK)</li>
+    <li><a href="http://java.sun.com/products/JavaManagement/index.html">
+        Java Management Extensions</a></li>
+    <li><a href="http://java.sun.com/products/rmi/index.html">Remote
+        Method Invocation</a> (Included in the JDK)</li>
+    </ul>
+
+  </subsection>
+
+
+  <subsection name="Implementation Requirements">
+
+    <p>The implementation of this functionality shall conform to the
+    following requirements:</p>
+    <ul>
+    <li>To the maximum extent feasible, all administrative functions,
+        and the access methods that support them, shall run portably
+        on all platforms where Tomcat 5 itself runs.</li>
+    <li>In a default Tomcat distribution, all administrative capabilities
+        shall be disabled.  It shall be necessary for a system
+        administrator to specifically enable the desired access methods
+        (such as by adding a username/password with a specific role to
+        the Tomcat user's database.</li>
+    <li>Administrative functions shall be realized as direct calls to
+        corresponding Catalina APIs, or through a business logic layer
+        that is independent of the access method used to initiate it.</li>
+    <li>The common business logic components shall be implemented in
+        package <code>org.apache.catalina.admin</code>.</li>
+    <li>The common business logic components shall be built as part of the
+        standard Catalina build process, and made visible in the
+        Catalina class loader.</li>
+    <li>The Java components required for each access method shall be
+        implemented in subpackages of <code>org.apache.catalina.admin</code>.
+        </li>
+    <li>The build scripts should treat each access method as optional,
+        so that it will be built only if the corresponding required
+        APIs are present at build time.</li>
+    <li>It shall be possible to save the configured state of the running
+        Tomcat container such that this state can be reproduced when the
+        container is shut down and restarted.</li>
+    <li>Adminstrative commands to start up and shut down the overall
+        Tomcat container are <strong>out of scope</strong> for the
+        purposes of these applications.  It is assumed that other
+        (usually platform-specific) mechanisms will be used for container
+        startup and shutdown.</li>
+    </ul>
+
+  </subsection>
+
+
+</section>
+
+
+<section name="Dependencies">
+
+
+  <subsection name="Environmental Dependencies">
+
+    <p>The following environmental dependencies must be met in order for
+    administrative applications to operate correctly:</p>
+    <ul>
+    <li>For access methods that require creation of server sockets, the
+        appropriate ports must be configured and available.</li>
+    </ul>
+
+  </subsection>
+
+
+  <subsection name="Container Dependencies">
+
+    <p>Correct operation of administrative applications depends on the
+       following specific features of the surrounding container:</p>
+    <ul>
+    <li>To the maximum extent feasible, Catalina components that offer
+        direct administrative APIs and property setters shall support
+        "live" changes to their operation, without requiring a container
+        restart.</li>
+    </ul>
+
+  </subsection>
+
+
+  <subsection name="External Technologies">
+
+    <p>The availability of the following technologies can be assumed
+    for the implementation and operation of the various access methods
+    and the corresponding administrative business logic:</p>
+    <ul>
+    <li><a href="http://java.sun.com/j2se/">Java 2 Standard Edition</a>
+        (Version 1.2 or later)</li>
+    <li><a href="http://www.jcp.org/jsr/detail/154.jsp">Servlet 2.4</a>
+        (supported natively by Tomcat 5)</li>
+    <li><a href="http://www.jcp.org/jsr/detail/152.jsp">JavaServer Pages 2.0</a>
+        (supported natively by Tomcat 5)</li>
+    <li><a href="http://jakarta.apache.org/taglibs/doc/standard-doc/intro.html">JavaServer Pages Standard Tag Library 1.0 (Jakarta Taglibs-Standard 1.0.3)</a></li>
+    <li><a href="http://jakarta.apache.org/struts/">Struts Framework</a>
+        (Version 1.0) - MVC Framework for Web Applications</li>
+    <li><strong>TO BE DETERMINED</strong> - Application for hosting SOAP
+        based web services</li>
+    </ul>
+
+  </subsection>
+
+
+</section>
+
+
+<section name="Functionality">
+
+
+  <subsection name="Properties of Administered Objects">
+
+  <p>Functional requirements for administrative applications are specified
+  in terms of <em>Administered Objects</em>, whose definitions and detailed
+  properties are listed <a href="fs-admin-objects.html">here</a>.  In general,
+  Administered Objects correspond to components in the Catalina architecture,
+  but these objects are defined separately here for the following reasons:</p>
+  <ul>
+  <li>It is possible that the administrative applications do not expose
+      every possible configurable facet of the underlying components.</li>
+  <li>In some cases, an Administered Object (from the perspective of an
+      administrative operation) is realized by more than one Catalina
+      component, at a finer-grained level of detail.</li>
+  <li>It is necessary to represent the configuration information for a
+      component separately from the component itself (for instance, in
+      order to store that configuration information for later use).</li>
+  <li>It is necessary to represent configuration information (such as
+      a Default Context) when there is no corresponding component instance.
+      </li>
+  <li>Administered Objects, when realized as Java classes, will include
+      methods for administrative operations that have no correspondence
+      to operations performed by the corresponding actual components.</li>
+  </ul>
+
+  <p>It is assumed that the reader is familiar with the overall component
+  architecture of Catalina.  For further information, see the corresponding
+  Developer Documentation.  To distinguish names that are used as both
+  <em>Administered Objects</em> and <code>Components</code>, different
+  font presentations are utilized.  Default values for many properties
+  are listed in [square brackets].</p>
+
+  </subsection>
+
+
+  <subsection name="Supported Administrative Operations">
+
+  <p>The administrative operations that are available are described in terms
+  of the corresponding Administered Objects (as defined above), in a manner
+  that is independent of the access method by which these operations are
+  requested.  In general, such operations are relevant only in the context
+  of a particular Administered Object (and will most likely be realized as
+  method calls on the corresponding Administered Object classes), so they
+  are organized based on the currently "focused" administered object.
+  The available Supported Operations are documented
+  <a href="fs-admin-opers.html">here</a>.</p>
+
+  </subsection>
+
+
+  <subsection name="Access Method Specific Requirements">
+
+  <h5>Scriptable Web Application</h5>
+
+  <p>An appropriate subset of the administrative operations described above
+  shall be implemented as commands that can be performed by the "Manager"
+  web application.  <strong>FIXME</strong> - Enumerate them.</p>
+
+  <p>In addition, this web application shall conform to the following
+  requirements:</p>
+  <ul>
+  <li>All request URIs shall be protected by a security constraint that
+      requires security role <code>manager</code> for processing.</li>
+  <li>The default user database shall <strong>not</strong> contain any
+      user that has been assigned the role <code>manager</code>.</li>
+  </ul>
+
+  <h5>HTML-Based Web Application</h5>
+
+  <p>The entire suite of administrative operations described above shall be
+  made available through a web application designed for human interaction.
+  In addition, this web application shall conform to the following
+  requirements:</p>
+  <ul>
+  <li>Must be implemented using servlet, JSP, and MVC framework technologies
+      described under "External Technologies", above.</li>
+  <li>Prompts and error messages must be internationalizable to multiple
+      languages.</li>
+  <li>Rendered HTML must be compatible with Netscape Navigator (verson 4.7
+      or later) and Internet Explorer (version 5.0 or later).</li>
+  </ul>
+
+  </subsection>
+
+
+</section>
+
+
+<section name="Testable Assertions">
+
+  <p><strong>FIXME</strong> - Complete this section.</p>
+
+</section>
+
+
+</body>
+
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-apps.xml
------------------------------------------------------------------------------
    svn:eol-style = native

Added: tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-objects.xml
URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-objects.xml?rev=420006&view=auto
==============================================================================
--- tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-objects.xml (added)
+++ tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-objects.xml Fri Jul  7 15:40:04 2006
@@ -0,0 +1,481 @@
+<?xml version="1.0"?>
+<!DOCTYPE document [
+  <!ENTITY project SYSTEM "project.xml">
+]>
+<document url="fs-admin-objects.html">
+
+  &project;
+
+  <properties>
+    <author email="craigmcc@apache.org">Craig McClanahan</author>
+    <title>Administrative Apps - Administered Objects</title>
+    <revision>$Id: fs-admin-objects.xml 303281 2004-09-27 16:00:31Z yoavs $</revision>
+  </properties>
+
+<body>
+
+
+<section name="Administered Objects Overview">
+
+<p>This document defines the <em>Administered Objects</em> that represent
+the internal architectural components of the Catalina servlet container.
+Associated with each is a set of <a href="fs-admin-opers.html">Supported
+Operations</a> that can be performed when the administrative application is
+"focused" on a particular configurable object.</p>
+
+<p>The following Administered Objects are defined:</p>
+<ul>
+<li><a href="#Access Logger">Access Logger</a></li>
+<li><a href="#Connector">Connector</a></li>
+<li><a href="#Context">Context</a></li>
+<li><a href="#Default Context">Default Context</a></li>
+<li><a href="#Default Deployment Descriptor">Default Deployment Descriptor</a></li>
+<li><a href="#Engine">Engine</a></li>
+<li><a href="#Environment Entry">Environment Entry</a></li>
+<li><a href="#Host">Host</a></li>
+<li><a href="#JDBC Resource">JDBC Resource</a></li>
+<li><a href="#Loader">Loader</a></li>
+<li><a href="#Manager">Manager</a></li>
+<li><a href="#Realm">Realm</a></li>
+<li><a href="#Request Filter">Request Filter</a></li>
+<li><a href="#Server">Server</a></li>
+<li><a href="#Service">Service</a></li>
+</ul>
+
+</section>
+
+
+<section name="Access Logger">
+
+  <p>An <em>Access Logger</em> is an optional <code>Valve</code> that can
+  create request access logs in the same formats as those provided by
+  web servers.  Such access logs are useful input to hit count and user
+  access tracking analysis programs.  An Access Logger can be attached to
+  an <em>Engine</em>, a <em>Host</em>, a <em>Context</em>, or a <em>Default
+  Context</em>.</p>
+
+  <p>The standard component implementing an <em>Access Logger</em> is
+  <code>org.apache.catalina.valves.AccessLogValve</code>.  It supports the
+  following configurable properties:</p>
+  <ul>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>directory</code> - Absolute or relative (to $CATALINA_HOME) path
+      of the directory into which access log files are created.
+      [logs].</li>
+  <li><code>pattern</code> - Pattern string defining the fields to be
+      included in the access log output, or "common" for the standard
+      access log pattern.  See
+      <code>org.apache.catalina.valves.AccessLogValve</code> for more
+      information.  [common]</li>
+  <li><code>prefix</code> - Prefix added to the beginning of each log file
+      name created by this access logger.</li>
+  <li><code>resolveHosts</code> - Should IP addresses be resolved to host
+      names in the log?  [false]</li>
+  <li><code>suffix</code> - Suffix added to the end of each log file name
+      created by this access logger.</li>
+  </ul>
+
+</section>
+
+
+<section name="Connector">
+
+  <p>A <em>Connector</em> is the representation of a communications endpoint
+  by which requests are received from (and responses returned to) a Tomcat
+  client.  The administrative applications shall support those connectors
+  that are commonly utilized in Tomcat installations, as described in detail
+  below.</p>
+
+  <p>For standalone use, the standard connector supporting the HTTP/1.1
+  protocol is <code>org.apache.catalina.connectors.http.HttpConnector</code>.
+  It supports the following configurable properties:</p>
+  <ul>
+  <li><code>acceptCount</code> - The maximum queue length of incoming
+      connections that have not yet been accepted.  [10]</li>
+  <li><code>address</code> - For servers with more than one IP address, the
+      address upon which this connector should listen.  [All Addresses]</li>
+  <li><code>bufferSize</code> - Default input buffer size (in bytes) for
+      requests created by this Connector.  [2048]</li>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>enableLookups</code> - Should we perform DNS lookups on remote
+      IP addresses when <code>request.getRemoteHost()</code> is called?
+      [true]</li>
+  <li><code>maxProcessors</code> - The maximum number of processor threads
+      supported by this connector.  [20]</li>
+  <li><code>minProcessors</code> - The minimum number of processor threads
+      to be created at container startup.  [5]</li>
+  <li><code>port</code> - TCP/IP port number on which this Connector should
+      listen for incoming requests. [8080]</li>
+  <li><code>proxyName</code> - Host name to be returned when an application
+      calls <code>request.getServerName()</code>.  [Value of Host: header]</li>
+  <li><code>proxyPort</code> - Port number to be returned when an application
+      calls <code>request.getServerPort()</code>.  [Same as <code>port</code>]
+      </li>
+  </ul>
+
+</section>
+
+
+<section name="Context">
+
+  <p>A <em>Context</em> is the representation of an individual web application,
+  which is associated with a corresponding <em>Host</em>.  Note that the
+  administrable properties of a <em>Context</em> do <strong>not</strong>
+  include any settings from inside the web application deployment descriptor
+  for that application.</p>
+
+  <p>The standard component implementing a <em>Context</em> is
+  <code>org.apache.catalina.core.StandardContext</code>.  It supports the
+  following configurable properties:</p>
+  <ul>
+  <li><code>cookies</code> - Should be use cookies for session identifier
+      communication?  [true]</li>
+  <li><code>crossContext</code> - Should calls to
+      <code>ServletContext.getServletContext()</code> return the actual
+      context responsible for the specified path?  [false]</li>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>docBase</code> - The absolute or relative (to the
+      <code>appBase</code> of our owning <em>Host</em>) pathname of a
+      directory containing an unpacked web application, or of a web
+      application archive (WAR) file.</li>
+  <li><code>override</code> - Should settings in this <em>Context</em>
+      override corresponding settings in the <em>Default Context</em>?
+      [false]</li>
+  <li><code>path</code> - Context path for this web application, or an empty
+      string for the root application of a <em>Host</em>.  [Inferred from
+      directory or WAR file name]</li>
+  <li><code>reloadable</code> - Should Tomcat monitor classes in the
+      <code>/WEB-INF/classes</code> directory for changes, and reload the
+      application if they occur?  [false]</li>
+  <li><code>useNaming</code> - Should Tomcat provide a JNDI naming context,
+      containing preconfigured entries and resources, corresponding to the
+      requirements of the Java2 Enterprise Edition specification?  [true]</li>
+  <li><code>workDir</code> - Absolute pathname of a scratch directory that is
+      provided to this web application.  [Automatically assigned relative to
+      $CATALINA_HOME/work]</li>
+  </ul>
+
+  <p>Each <em>Context</em> is owned by a parent <em>Host</em>, and is
+  associated with:</p>
+  <ul>
+  <li>An optional <em>Access Logger</em> that logs all requests processed
+      by this web application.</li>
+  <li>Zero or more <em>Environment Entries</em> representing environment
+      entries for the JNDI naming context associated with a web
+      application.</li>
+  <li>Zero or more <em>JDBC Resources</em> representing database connection
+      pools associated with a web application.</li>
+  <li>A <em>Loader</em> representing the web application class loader used
+      by this web application.</li>
+  <li>A <em>Manager</em> representing the session manager used by this
+      web application.</li>
+  <li>An optional <em>Realm</em> used to provide authentication and access
+      control information for this web application.</li>
+  <li>Zero or more <em>Request Filters</em> used to limit access to this
+      web application based on remote host name or IP address.</li>
+  </ul>
+
+</section>
+
+
+<section name="Default Context">
+
+  <p>A <em>Default Context</em> represents a subset of the configurable
+  properties of a <em>Context</em>, and is used to set defaults for those
+  properties when web applications are automatically deployed.  A <em>Default
+  Context</em> object can be associated with an <em>Engine</em> or a
+  <em>Host</em>.  The following configurable properties are supported:</p>
+  <ul>
+  <li><code>cookies</code> - Should be use cookies for session identifier
+      communication?  [true]</li>
+  <li><code>crossContext</code> - Should calls to
+      <code>ServletContext.getServletContext()</code> return the actual
+      context responsible for the specified path?  [false]</li>
+  <li><code>reloadable</code> - Should Tomcat monitor classes in the
+      <code>/WEB-INF/classes</code> directory for changes, and reload the
+      application if they occur?  [false]</li>
+  <li><code>useNaming</code> - Should Tomcat provide a JNDI naming context,
+      containing preconfigured entries and resources, corresponding to the
+      requirements of the Java2 Enterprise Edition specification?  [true]</li>
+  </ul>
+
+  <p>Each <em>Default Context</em> is owned by a parent <em>Engine</em> or
+  <em>Host</em>, and is associated with:</p>
+  <ul>
+  <li>Zero or more <em>Environment Entries</em> representing environment
+      entries for the JNDI naming context associated with a web
+      application.</li>
+  <li>Zero or more <em>JDBC Resources</em> representing database connection
+      pools associated with a web application.</li>
+  <li>An optional <em>Loader</em> representing default configuration
+      properties for the Loader component of deployed web applications.</li>
+  <li>An optional <em>Manager</em> representing default configuration
+      properties for the Manager component fo deployed web applications.</li>
+  </ul>
+
+</section>
+
+
+<section name="Default Deployment Descriptor">
+
+  <p>Default web application characteristics are configured in a special
+  deployment descriptor named <code>$CATALINA_HOME/conf/web.xml</code>.  This
+  section describes the configurable components that may be stored there.</p>
+
+  <p><strong>FIXME</strong> - Complete the description of default servlets,
+  default mappings, default MIME types, and so on.</p>
+
+</section>
+
+
+<section name="Engine">
+
+  <p>An <em>Engine</em> is the representation of the entire Catalina
+  servlet container, and processes all requests for all of the associated
+  virtual hosts and web applications.</p>
+
+  <p>The standard component implementing an <em>Engine</em> is
+  <code>org.apache.catalina.core.StandardEngine</code>.  It supports the
+  following configurable properties:</p>
+  <ul>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>defaultHost</code> - Name of the <em>Host</em> to which requests
+      will be directed if the requested host is unknown.  [localhost]</li>
+  <li><code>name</code> - Logical name of this engine. [Tomcat Stand-Alone]
+      </li>
+  </ul>
+
+  <p>Each <em>Engine</em> is owned by a parent <em>Service</em>, and is
+  associated with:</p>
+  <ul>
+  <li>An optional <em>Access Logger</em> that logs all requests processed
+      by the entire container.</li>
+  <li>A <em>Default Context</em>, representing default properties of a
+      <em>Context</em> for automatically deployed applications for all
+      associated <em>Hosts</em> (unless overridden by a subordinate
+      component).</li>
+  <li>One or more <em>Hosts</em> representing individual virtual hosts
+      supported by this container.</li>
+  <li>A <em>Realm</em> used to provide authentication and access control
+      information for all virtual hosts and web applications (unless
+      overridden by a subordinate component).</li>
+  <li>Zero or more <em>Request Filters</em> used to limit access to the
+      entire container based on remote host name or IP address.</li>
+  </ul>
+
+</section>
+
+
+<section name="Environment Entry">
+
+  <p>An <em>Environment Entry</em> is the representation of a
+  <code>&lt;env-entry&gt;</code> element from a web application deployment
+  descriptor.  It will cause the creation of a corresponding entry in the
+  JNDI naming context provided to the corresponding <em>Context</em>.  The
+  following configurable properties are supported:</p>
+  <ul>
+  <li><code>description</code> - Description of this environment entry.</li>
+  <li><code>name</code> - Environment entry name (relative to the
+      <code>java:comp/env</code> context)</li>
+  <li><code>type</code> - Environment entry type (must be one of the fully
+      qualified Java classes listed in the servlet spec).</li>
+  <li><code>value</code> - Environment entry value (must be convertible from
+      String to the specified <code>type</code>.</li>
+  </ul>
+
+</section>
+
+
+<section name="Host">
+
+  <p>A <em>Host</em> is the representation of an individual virtual host,
+  which has a unique set of associated web applications.</p>
+
+  <p>The standard component implementing a <em>Host</em> is
+  <code>org.apache.catalina.core.StandardHost</code>.  It supports the
+  following configurable properties:</p>
+  <ul>
+  <li><code>aliases</code> - Zero or more DNS names that are also associated
+      with this host (for example, a particular host might be named
+      <code>www.mycompany.com</code> with an alias <code>company.com</code>).
+      </li>
+  <li><code>appBase</code> - Absolute or relative (to $CATALINA_HOME) path
+      to a directory from which web applications will be automatically
+      deployed.</li>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>name</code> - DNS Name of the virtual host represented by this
+      object.</li>
+  <li><code>unpackWARs</code> - Should web application archive files
+      deployed by this virtual host be unpacked first?  [true]</li>
+  </ul>
+
+  <p>Each <em>Host</em> is owned by a parent <em>Engine</em>, and is
+  associated with:</p>
+  <ul>
+  <li>An optional <em>Access Logger</em> that logs all requests processed
+      by this virtual host.</li>
+  <li>One or more <em>Contexts</em> representing the web applications
+      operating on this <em>Host</em>.</li>
+  <li>A <em>Default Context</em> representing default <em>Context</em>
+      properties for web applications that are automatically deployed
+      by this <em>Host</em>.</li>
+  <li>A optional <em>Realm</em> used to provide authentication and access
+      control information for all web applications associated with this
+      virtual host (unless overridden by a subordinate component).</li>
+  </ul>
+
+  <p><strong>FIXME</strong> - Should we support configuration of the
+  User Web Applications functionality?</p>
+
+</section>
+
+
+<section name="JDBC Resource">
+
+  <p>A <em>JDBC Resources</em> represents a database connection pool (i.e.
+  an implementation of <code>javax.sql.DataSource</code> that will be
+  configured and made available in the JNDI naming context associated with
+  a web application.</p>
+
+  <p><strong>FIXME</strong> - properties of this administered object</p>
+
+</section>
+
+
+<section name="Loader">
+
+  <p>A <em>Loader</em> represents a web application class loader that will
+  be utilized to provide class loading services for a particular
+  <em>Context</em>.</p>
+
+  <p>The standard component implementing a <em>Loader</em> is
+  <code>org.apache.catalina.loader.StandardLoader</code>.  It supports
+  the following configurable properties:</p>
+  <ul>
+  <li><code>checkInterval</code> - Number of seconds between checks for
+      modified classes, if automatic reloading is enabled.  [15]</li>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>reloadable</code> - Should this class loader check for modified
+      classes and initiate automatic reloads?  [Set automatically from the
+      <code>reloadable</code> property of the corresponding <em>Context</em>]
+      </li>
+  </ul>
+
+  <p>Each <em>Loader</em> is owned by a parent <em>Context</em>.</p>
+
+</section>
+
+
+<section name="Manager">
+
+  <p>A <em>Manager</em> represents a session manager that will be associated
+  with a particular web application.  <strong>FIXME</strong> - Add support
+  for advanced session managers and their associated Stores.</p>
+
+  <p>The standard component implementing a <em>Manager</em> is
+  <code>org.apache.catalina.session.StandardManager</code>.  It supports
+  the following configurable properties:</p>
+  <ul>
+  <li><code>checkInterval</code> - Number of seconds between checks for
+      expired sessions.  [60]</li>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>entropy</code> - String initialization parameter used to increase
+      the entropy (initial randomness) of the random number generator used to
+      create session identifiers.  [Inferred from engine, host, and context]
+      </li>
+  <li><code>maxActiveSessions</code> - The maximum number of active sessions
+      that are allowed, or -1 for no limit.  [-1]</li>
+  </ul>
+
+  <p>Each <em>Manager</em> is owned by a parent <em>Context</em>.</p>
+
+</section>
+
+
+<section name="Realm">
+
+  <p>A <em>Realm</em> represents a "database" of information about authorized
+  users, their passwords, and the security roles assigned to them.  This will
+  be used by the container in the implementation of container-managed security
+  in accordance with the Servlet Specification.  Several alternative
+  implementations are supported.</p>
+
+  <p><code>org.apache.catalina.realm.MemoryRealm</code> initializes its user
+  information from a simple XML file at startup time.  If changes are made
+  to the information in this file, the corresponding web applications using
+  it must be restarted for the changes to take effect.  It supports the
+  following configurable properties:</p>
+  <ul>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>pathname</code> - Absolute or relative (to $CATALINA_HOME) path to
+      the XML file containing our user information.  [conf/tomcat-users.xml]
+      </li>
+  </ul>
+
+  <p><code>org.apache.catalina.realm.JDBCRealm</code> uses a relational
+  database (accessed via JDBC APIs) to contain the user information.  Changes
+  in the contents of this database take effect immediately; however, the roles
+  assigned to a particular user are calculated only when the user initially
+  logs on (and not per request).  The following configurable properties
+  are supported:</p>
+  <ul>
+  <li><code>connectionName</code> - Database username to use when establishing
+      a JDBC connection.</li>
+  <li><code>connectionPassword</code> - Database password to use when
+      establishing a JDBC connection.</li>
+  <li><code>connectionURL</code> - Connection URL to use when establishing
+      a JDBC connection.</li>
+  <li><code>debug</code> - Debugging detail level.  [0]</li>
+  <li><code>digest</code> - Name of the <code>MessageDigest</code> algorithm
+      used to encode passwords in the database, or a zero-length string for
+      no encoding.  [Zero-length String]</li>
+  <li><code>driverName</code> - Fully qualified Java class name of the JDBC
+      driver to be utilized.</li>
+  <li><code>roleNameCol</code> - Name of the column, in the User Roles table,
+      which contains the role name.</li>
+  <li><code>userCredCol</code> - Name of the column, in the Users table,
+      which contains the password (encrypted or unencrypted).</li>
+  <li><code>userNameCol</code> - Name of the column, in both the Users and
+      User Roles tables, that contains the username.</li>
+  <li><code>userRoleTable</code> - Name of the User Roles table, which contains
+      one row per security role assigned to a particular user.  This table must
+      contain the columns specified by the <code>userNameCol</code> and
+      <code>roleNameCol</code> properties.</li>
+  <li><code>userTable</code> - Name of the Users table, which contains one row
+      per authorized user.  This table must contain the columns specified by
+      the <code>userNameCol</code> and <code>userCredCol</code> properties.
+      </li>
+  </ul>
+
+  <p><strong>FIXME</strong> - Should we provide mechanisms to edit the contents
+  of a "tomcat-users.xml" file through the admin applications?</p>
+
+  <p>Each <em>Realm</em> is owned by a parent <em>Engine</em>, <em>Host</em>,
+  or <em>Context</em>.</p>
+
+</section>
+
+
+<section name="Request Filter">
+
+  <p><strong>FIXME</strong> - complete this entry</p>
+
+</section>
+
+
+<section name="Server">
+
+  <p><strong>FIXME</strong> - complete this entry</p>
+
+</section>
+
+
+<section name="Service">
+
+  <p><strong>FIXME</strong> - complete this entry</p>
+
+</section>
+
+</body>
+
+</document>

Propchange: tomcat/tc6.0.x/trunk/webapps/docs/funcspecs/fs-admin-objects.xml
------------------------------------------------------------------------------
    svn:eol-style = native



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org