[jbossweb-commits] JBossWeb SVN: r263 - trunk/webapps/docs.

Author: remy.maucherat(a)jboss.com Date: 2007-09-04 19:06:49 -0400 (Tue, 04 Sep 2007) New Revision: 263 Removed: trunk/webapps/docs/balancer-howto.xml trunk/webapps/docs/cluster-howto.xml trunk/webapps/docs/developers.xml trunk/webapps/docs/extras.xml trunk/webapps/docs/status.xml Modified: trunk/webapps/docs/aio.xml trunk/webapps/docs/apr.xml trunk/webapps/docs/building.xml trunk/webapps/docs/cgi-howto.xml trunk/webapps/docs/changelog.xml trunk/webapps/docs/class-loader-howto.xml trunk/webapps/docs/connectors.xml trunk/webapps/docs/default-servlet.xml trunk/webapps/docs/deployer-howto.xml trunk/webapps/docs/html-manager-howto.xml trunk/webapps/docs/index.xml trunk/webapps/docs/introduction.xml trunk/webapps/docs/jasper-howto.xml trunk/webapps/docs/legal.xml trunk/webapps/docs/project.xml Log: - Branding of docs (part 1/3). Modified: trunk/webapps/docs/aio.xml =================================================================== --- trunk/webapps/docs/aio.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/aio.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -7,7 +7,7 @@ &project; <properties> - <title>Advanced IO and Tomcat</title> + <title>Advanced IO and JBoss Web</title> <author>Remy Maucherat</author> </properties> @@ -16,7 +16,7 @@ <section name="Introduction"> <p> - With usage of the APR API as the basis of its connectors, Tomcat is + With usage of the APR API as the basis of its connectors, JBoss Web is able to provide a number of extensions over the regular blocking IO as provided with support for the Servlet API. </p> @@ -126,7 +126,7 @@ <p> The close() method ends the request, which marks the end of the comet session. This will send back to the client a notice that the server has no more data to send - as part of this request. If this method is called from a Tomcat provided thread + as part of this request. If this method is called from a conatiner provided thread (during the processing of an event), the container will not call an END event. If this method is called asynchronously, an END event will be sent to the servlet (note that this event will be sent whenever another event would have @@ -157,7 +157,7 @@ The suspend() method suspends processing of the connection until the configured timeout occurs, or resume() is called. In practice, this means the servlet will no longer receive read events. Reading should always be performed synchronously in - the Tomcat threads unless the connection has been suspended. + the contaner threads unless the connection has been suspended. </p> <p> @@ -335,7 +335,7 @@ <section name="Asynchronous writes"> <p> - When APR is enabled, Tomcat supports using sendfile to send large static files. + When APR is enabled, JBoss Web supports using sendfile to send large static files. These writes, as soon as the system load increases, will be performed asynchronously in the most efficient way. Instead of sending a large response using blocking writes, it is possible to write content to a static file, and write it @@ -346,7 +346,7 @@ </p> <p> - Any servlet can instruct Tomcat to perform a sendfile call by setting the appropriate + Any servlet can instruct JBoss Web to perform a sendfile call by setting the appropriate response attributes. When using sendfile, it is best to ensure that neither the request or response have been wrapped, since as the response body will be sent later by the connector itself, it cannot be filtered. Other than setting the 3 needed Modified: trunk/webapps/docs/apr.xml =================================================================== --- trunk/webapps/docs/apr.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/apr.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -7,7 +7,7 @@ &project; <properties> - <title>Apache Portable Runtime and Tomcat</title> + <title>Apache Portable Runtime and JBoss Web</title> <author>Remy Maucherat</author> </properties> @@ -26,7 +26,7 @@ </p> <p> - These features allows making Tomcat a general purpose webserver, will enable much better + These features allows making JBoss Web a general purpose webserver, will enable much better integration with other native web technologies, and overall make Java much more viable as a full fledged webserver platform rather than simply a backend focused technology. </p> @@ -39,7 +39,7 @@ APR support requires three main native components to be installed: <ul> <li>APR library</li> - <li>JNI wrappers for APR used by Tomcat (libtcnative)</li> + <li>JNI wrappers for APR used by JBoss Web (libtcnative)</li> <li>OpenSSL libraries</li> </ul> </p> @@ -76,7 +76,7 @@ </p> <p> - The wrapper library sources are located in the Tomcat binary bundle, in the + The wrapper library sources are located in the JBoss Web binary bundle, in the <code>bin/tomcat-native.tar.gz</code> archive. Once the build environment is installed and the source archive is extracted, the wrapper library can be compiled using (from the folder containing the configure script): @@ -91,18 +91,18 @@ <p> Once the libraries are properly installed and available to Java (if loading fails, the library path - will be displayed), the Tomcat connectors will automatically use APR. Configuration of the connectors + will be displayed), the JBoss Web connectors will automatically use APR. Configuration of the connectors is similar to the regular connectors, but have a few extra attributes which are used to configure APR components. Note that the defaults should be well tuned for most use cases, and additional tweaking shouldn't be required. </p> <p> - When APR is enabled, the following features are also enabled in Tomcat: + When APR is enabled, the following features are also enabled in JBoss Web: <ul> <li>Secure session ID generation by default on all platforms (platforms other than Linux required random number generation using a configured entropy)</li> - <li>OS level statistics on memory usage and CPU usage by the Tomcat process are displayed by + <li>OS level statistics on memory usage and CPU usage by the JBoss Web process are displayed by the status servlet</li> </ul> </p> @@ -297,7 +297,7 @@ When APR is enabled, the AJP connector will use a socket poller for keepalive, increasing scalability of the server. As AJP is designed around a pool of persistent (or almost persistent) connections, this will reduce significantly the amount of processing threads - needed by Tomcat. Unlike the HTTP connector, the AJP connector cannot use sendfile to optimize + needed by JBoss Web. Unlike the HTTP connector, the AJP connector cannot use sendfile to optimize static file processing. </p> Deleted: trunk/webapps/docs/balancer-howto.xml =================================================================== --- trunk/webapps/docs/balancer-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/balancer-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -1,152 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE document [ - <!ENTITY project SYSTEM "project.xml"> -]> -<document url="balancer-howto.html"> - - &project; - - <properties> - <author email=&quot;yoavs(a)apache.org&quot;&gt;Yoav Shapira</author> - <author>Remy Maucherat</author> - <author>Andy Oliver</author> - <title>Load Balancer HOW-TO</title> - </properties> - -<body> - -<section name="Table of Contents"> -<p> -<a href="#Using the JK 1.2.x native connector"> -Using the JK native connector</a><br /> -<a href="#Using Apache HTTP Server 2.x with mod_proxy"> -Using Apache HTTP Server 2.x and mod_proxy</a><br /> -<!-- -<a href="#Using the balancer webapp">Using the balancer webapp</a><br /> ---> -</p> -</section> - -<section name="Using the JK 1.2.x native connector"> - -Please refer to the JK 1.2.x documentation. - -</section> - -<section name="Using Apache HTTP Server 2.x with mod_proxy"> - -Please refer to the mod_proxy documentation for Apache HTTP Server 2.2. This supports either -HTTP or AJP load balancing. This new version of mod_proxy is also useable with -Apache HTTP Server 2.0, but mod_proxy will have to be compiled separately using the code -from Apache HTTP Server 2.2. - -</section> - -<!-- -<section name="Using the balancer webapp"> - -<subsection name="Overview"> - -<p> -Tomcat 5.0.15 and later ships with a webapp named balancer. This is -a simple implemention of a rules-based load balancer. It was not designed -as a replacement for other load-balancing mechanisms used for high traffic -environments. Rather, it is a simple, pure Java, easily extensible, and fast -way to direct traffic among multiple servers. -</p> -<p> -Although balancer ships with Tomcat, it is not Tomcat-specific and runs -on other containers without any modification. The balancer webapp -requires a Servlet Specification 2.3 or later container if you wish -to use a filter to redirect traffic. If you wish to redirect traffic -using a servlet, you may use any servlet container. -</p> -</subsection> - -<subsection name="Sample Configuration"> -<p> -The default balancer installation uses a single filter, BalancerFilter, -mapped to all requests (url-pattern /*). The filter reads its rules -from the location specified in the balancer deployment descriptor -(web.xml file). The default rules are: -<ul> - <li>Redirect requests with News in the URL to www.cnn.com</li> - <li>Redirect requests with a parameter named paramName whose -value is paramValue to www.yahoo.com.</li> - <li>Redirect all other requests to jakarta.apache.org.</li> -</ul> - -Therefore, when you install tomcat, start it, and point your -browser to http://localhost:8080/balancer, you will be redirected -to http://jakarta.apache.org. If you point your browser to -http://localhost:8080/balancer/News you will be redirected to -http://www.cnn.com. The request for -http://localhost:8080/balancer/BlahBlah?paramName=paramValue will -be redirected to http://www.yahoo.com. -</p> -</subsection> - -<subsection name="Balancer Rules"> -<p> -A <i>Rule</i> in the balancer system is a combination of -a request matching criterion and a redirection URL for -matching requests. Rules implement the -org.apache.webapp.balancer.Rule interface. -</p> - -<p> -The balancer distribution contains a number of useful -rules. The framework is also designed for easy extensibility -so that you can write your own rules quickly. Rules -should be JavaBeans (public no-args constructor, public -setter method setXXX for property xxx), as they are -instantiated by Jakarta Commons Digester. Feel free -to inquire on the tomcat-user mailing list regarding -the availability of rules or the inclusion of your rules -in the distribution. -</p> - -<p> -Rules are assembled into RuleChains. Each BalancerFilter -(or Servlet/JSP) refers to one RuleChain when making its -redirection decisions. Note that you are not restricted -to having one filter mapped to /* as done in the sample -configuration. You can configure as many filters as -desired, using the full filter mapping possibilities defined -in the Servlet Specification. Each filter will have -its own RuleChain. -</p> -</subsection> - -<subsection name="How it Works"> -<p> -<ol> - <li>You write a rules configuration file containing various -rules and redirection locations.</li> - <li>You define the balancer filter in your web.xml, mapping -it as desired (/* is a common use-case) and configuring it -with your rules configuration file.</li> - <li>The server is started, initializing the filter.</li> - <li>A request comes into the server. The filter consults -its rule chain to determine where to redirect the request. Rules -are consulted in the order in which they are defined in the rules -configuration file. The first matching rule will stop the -evaluation and cause the request to be redirected.</li> -</ol> -</p> - -</subsection> - -<subsection name="Comments"> -<p> -Please direct questions, comments, suggestions, etc. to the -tomcat-user mailing list. Thank you. -</p> -</subsection> - -</section> ---> - -</body> - -</document> Modified: trunk/webapps/docs/building.xml =================================================================== --- trunk/webapps/docs/building.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/building.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -16,7 +16,7 @@ <section name="Introduction"> <p> -Building Apache Tomcat from SVN is very easy, and is the first step to contributing to +Building JBoss Web from SVN is very easy, and is the first step to contributing to Tomcat. The following is a step by step TODO list. </p> @@ -59,34 +59,34 @@ </section> -<section name="Checkout or obtain the source code for Tomcat 6.0"> +<section name="Checkout or obtain the source code for JBoss Web"> <p> - Tomcat SVN repository URL: - <code>http://svn.apache.org/repos/asf/tomcat/tc6.0.x/</code> + JBoss Web SVN repository URL: + <code>http://svn.jboss.org/repos/jbossweb/trunk</code> </p> <p> Download a source package from: - <code>http://tomcat.apache.org/download-60.cgi</code> + <code>http://labs.jboss.com/jbossweb/</code> </p> <p> Checkout the source using SVN, selecting the desired version or branch (current development source is at - <code>http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/</code>), or + <code>http://svn.jboss.org/repos/jbossweb/trunk</code>), or unpack the source package. The location where the source has been - placed will be referred as ${tomcat.source}. + placed will be referred as ${jbossweb.source}. </p> </section> -<section name="Building Tomcat"> +<section name="Building JBoss Web"> <p> Use the following commands: <code><br/> - cd ${tomcat.source}<br/> + cd ${jbossweb.source}<br/> ant download<br/> ant<br/> </code> @@ -107,7 +107,7 @@ </p> <p> -The build can be controlled by creating a ${tomcat.source}/build.properties +The build can be controlled by creating a ${jbossweb.source}/build.properties file, and adding the following content to it: <code><br/> # ----- Proxy setup -----<br/> @@ -129,9 +129,9 @@ <p> <b>Important:</b> -This is not a supported means of building Tomcat; this information is +This is not a supported means of building JBoss Web; this information is provided without warranty :-). -The only supported means of building Tomcat is with the "ant build" +The only supported means of building JBoss Web is with the "ant build" described above. However, some developers like to work on Java code with a Java IDE, and the following steps have been used by some developers. @@ -166,7 +166,7 @@ Use File-&gt;New Project to create a new Java project for each of the binaries repository (e.g., /usr/share/java), container, connectors, jasper, servletapi. -Unless you thought ahead to make the ${tomcat.source} directory be under +Unless you thought ahead to make the ${jbossweb.source} directory be under your Workspace folder, tell Eclipse the external location using &quot;Import/Export...&quot;, General-&gt;Existing Project into Workspace. </p> @@ -180,22 +180,13 @@ </p> <p> -To run Tomcat without a special IDE plug-in, you can simply use Run-&gt;Run... +To run JBoss Web without a special IDE plug-in, you can simply use Run-&gt;Run... enter "org.apache.catalina.startup.Catalina" as the main class, "start" as program arguments, and "-Dcatalina.home=..." (with the name of your build directory) as VM arguments. </p> -<p> -Note also that due to the way the Tomcat source is assembled -from several SVN projects, you may not be able to use the Eclipse -SVN client to update (nor to commit, if you are a committer). -Use the external SVN client of your choice, then use the -Eclipse PackageExplorer or Navigator "Refresh" context menu item -to tell Eclipse that you've updated the files. -</p> - </section> <section name="Building with other IDEs"> Modified: trunk/webapps/docs/cgi-howto.xml =================================================================== --- trunk/webapps/docs/cgi-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/cgi-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -20,11 +20,11 @@ referred to as CGI programs or CGI scripts. </p> -<p>Within Tomcat, CGI support can be added when you are using Tomcat as your +<p>Within JBoss Web, CGI support can be added when you are using JBoss Web as your HTTP server and require CGI support. Typically this is done during development when you don't want to run a web server like Apache httpd. -Tomcat's CGI support is largely compatible with Apache httpd's, +JBoss Web's CGI support is largely compatible with Apache httpd's, but there are some limitations (e.g., only one cgi-bin directory). </p> @@ -32,13 +32,13 @@ <code>org.apache.catalina.servlets.CGIServlet</code>. Traditionally, this servlet is mapped to the URL pattern "/cgi-bin/*".</p> -<p>By default CGI support is disabled in Tomcat.</p> +<p>By default CGI support is disabled in JBoss Web.</p> </section> <section name="Installation"> <p><strong>CAUTION</strong> - CGI scripts are used to execute programs -external to the Tomcat JVM. If you are using the Java SecurityManager this +external to the JBoss Web JVM. If you are using the Java SecurityManager this will bypass your security policy configuration in <code>catalina.policy.</code></p> <p>Remove the XML comments from around the CGI servlet and servlet-mapping Modified: trunk/webapps/docs/changelog.xml =================================================================== --- trunk/webapps/docs/changelog.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/changelog.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -19,7 +19,8 @@ <subsection name="General"> <changelog> <update> - Swicth to JBoss logging. (remm) + Swicth to JBoss logging from Apache Commons Logging. Standalone JBoss Web uses + a special purpose version defaulting to use java.util.logging. (remm) </update> </changelog> </subsection> @@ -49,9 +50,6 @@ <fix> Use the system property for the session cookie name. (jfclere) </fix> - <update> - Validation for elements and attributes of server.xml. (remm) - </update> </changelog> </subsection> <subsection name="Coyote"> @@ -100,6 +98,9 @@ In the APR connector, start accepting connections after fully starting the connector, to prevent possible exceptions due to non initialized fields. (remm) </fix> + <fix> + Fixes to B2C conversion. (billbarker) + </fix> </changelog> </subsection> <subsection name="Jasper"> Modified: trunk/webapps/docs/class-loader-howto.xml =================================================================== --- trunk/webapps/docs/class-loader-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/class-loader-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -17,7 +17,7 @@ <section name="Overview"> -<p>Like many server applications, Tomcat 6 installs a variety of class loaders +<p>Like many server applications, JBoss Web installs a variety of class loaders (that is, classes that implement <code>java.lang.ClassLoader</code>) to allow different portions of the container, and the web applications running on the container, to have access to different repositories of available classes and @@ -32,7 +32,7 @@ web application class loaders differs slightly from this, as discussed below, but the main principles are the same.</p> -<p>When Tomcat 6 is started, it creates a set of class loaders that are +<p>When JBoss Web is started, it creates a set of class loaders that are organized into the following parent-child relationships, where the parent class loader is above the child class loader:</p> @@ -54,7 +54,7 @@ <section name="Class Loader Definitions"> -<p>As indicated in the diagram above, Tomcat 6 creates the following class +<p>As indicated in the diagram above, JBoss Web creates the following class loaders as it is initialized:</p> <ul> <li><strong>Bootstrap</strong> - This class loader contains the basic runtime @@ -66,20 +66,20 @@ <li><strong>System</strong> - This class loader is normally initialized from the contents of the <code>CLASSPATH</code> environment variable. All such classes are visible to both Tomcat internal classes, and to web - applications. However, the standard Tomcat 5 startup scripts + applications. However, the standard JBoss Web startup scripts (<code>$CATALINA_HOME/bin/catalina.sh</code> or <code>%CATALINA_HOME%\bin\catalina.bat</code>) totally ignore the contents of the <code>CLASSPATH</code> environment variable itself, and instead build the System class loader from the following repositories: <ul> <li><em>$CATALINA_HOME/bin/bootstrap.jar</em> - Contains the main() method - that is used to initialize the Tomcat 6 server, and the class loader + that is used to initialize the JBoss Web server, and the class loader implementation classes it depends on.</li> - <li><em>$CATALINA_HOME/bin/tomcat-juli.jar</em> - Package renamed Jakarta commons - logging API, and java.util.logging LogManager.</li> + <li><em>$CATALINA_HOME/bin/tomcat-juli.jar</em> - JBoss Logging API, + and java.util.logging LogManager.</li> </ul></li> <li><strong>Common</strong> - This class loader contains additional classes - that are made visible to both Tomcat internal classes and to all web + that are made visible to both JBoss Web internal classes and to all web applications. Normally, application classes should <strong>NOT</strong> be placed here. All unpacked classes and resources in <code>$CATALINA_HOME/lib</code>, as well as classes and @@ -88,17 +88,15 @@ <ul> <li><em>annotations-api.jar</em> - JEE annotations classes.</li> <li><em>catalina.jar</em> - Implementation of the Catalina servlet - container portion of Tomcat 6.</li> - <li><em>catalina-ant.jar</em> - Tomcat Catalina Ant tasks.</li> - <li><em>catalina-ha.jar</em> - High availability package.</li> - <li><em>catalina-tribes.jar</em> - Group communication package.</li> + container portion of JBoss Web.</li> + <li><em>catalina-ant.jar</em> - JBoss Web Catalina Ant tasks.</li> <li><em>el-api.jar</em> - EL 2.1 API.</li> <li><em>jasper.jar</em> - Jasper 2 Compiler and Runtime.</li> <li><em>jasper-el.jar</em> - Jasper 2 EL implementation.</li> <li><em>jasper-jdt.jar</em> - Eclipse JDT 3.2 Java compiler.</li> <li><em>jsp-api.jar</em> - JSP 2.1 API.</li> <li><em>servlet-api.jar</em> - Servlet 2.5 API.</li> - <li><em>tomcat-coyote.jar</em> - Tomcat connectors and utility classes.</li> + <li><em>tomcat-coyote.jar</em> - JBoss Web connectors and utility classes.</li> <li><em>tomcat-dbcp.jar</em> - package renamed database connection pool based on Commons DBCP.</li> <li><em>tomcat-i18n-**.jar</em> - Optional JARs containing resource bundles @@ -107,7 +105,7 @@ of messages is needed.</li> </ul></li> <li><strong>WebappX</strong> - A class loader is created for each web - application that is deployed in a single Tomcat 6 instance. All unpacked + application that is deployed in a single JBoss Web instance. All unpacked classes and resources in the <code>/WEB-INF/classes</code> directory of your web application archive, plus classes and resources in JAR files under the <code>/WEB-INF/lib</code> directory of your web application @@ -127,7 +125,7 @@ used. Last, any JAR containing servlet API classes will be ignored by the classloader. -All other class loaders in Tomcat 6 follow the usual delegation pattern.</p> +All other class loaders in JBoss Web follow the usual delegation pattern.</p> <p>Therefore, from the perspective of a web application, class or resource loading looks in the following repositories, in this order:</p> @@ -163,7 +161,7 @@ <a href="http://java.sun.com/j2se/1.5/docs/guide/standards/index.html&q... http://java.sun.com/j2se/1.5/docs/guide/standards/index.html</a>.&l... -<p>Tomcat utilizes this mechanism by including the system property setting +<p>JBoss Web utilizes this mechanism by including the system property setting <code>-Djava.endorsed.dirs=$CATALINA_HOME/endorsed</code> in the command line that starts the container.</p> Deleted: trunk/webapps/docs/cluster-howto.xml =================================================================== --- trunk/webapps/docs/cluster-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/cluster-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -1,685 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE document [ - <!ENTITY project SYSTEM "project.xml"> -]> -<document url="cluster-howto.html"> - - &project; - - <properties> - <author email=&quot;fhanik(a)apache.org&quot;&gt;Filip Hanik</author> - <author email=&quot;pero(a)apache.org&quot;&gt;Peter Rossbach</author> - <title>Clustering/Session Replication HOW-TO</title> - </properties> - -<body> - - -<section name="Important Note"> -<p><b>You can also check the <a href="config/cluster.html">configuration reference documentation.</a></b> -</p> -</section> - -<section name="For the impatient"> - <p> - Simply add <source>&lt;Cluster className=&quot;org.apache.catalina.ha.tcp.SimpleTcpCluster&quot;/&gt;</source> - to your <code>&lt;Engine&gt;</code> or your <code>&lt;Host&gt;</code> element to enable clustering. - </p> - <p> - Using the above configuration will enable all-to-all session replication - using the <code>DeltaManager</code> to replicate session deltas. By all-to-all we mean that the session gets replicated to all the other - nodes in the cluster. This works great for smaller cluster but we don't recommend it for larger clusters(a lot of tomcat nodes). - Also when using the delta manager it will replicate to all nodes, even nodes that don't have the application deployed.<br/> - To get around this problem, you'll want to use the BackupManager. This manager only replicates the session data to one backup - node, and only to nodes that have the application deployed. Downside of the BackupManager: not quite as battle tested as the delta manager. - <br/> - Here are some of the important default values:<br/> - 1. Multicast address is 228.0.0.4<br/> - 2. Multicast port is 45564 (the port and the address together determine cluster membership.<br/> - 3. The IP broadcasted is <code>java.net.InetAddress.getLocalHost().getHostAddress()</code> (make sure you don't broadcast 127.0.0.1, this is a common error)<br/> - 4. The TCP port listening for replication messages is the first available server socket in range <code>4000-4100</code><br/> - 5. Two listeners are configured <code>ClusterSessionListener</code> and <code>JvmRouteSessionIDBinderListener</code><br/> - 6. Two interceptors are configured <code>TcpFailureDetector</code> and <code>MessageDispatch15Interceptor</code><br/> - The following is the default cluster configuration:<br/> - <source> - &lt;Cluster className=&quot;org.apache.catalina.ha.tcp.SimpleTcpCluster&quot; - channelSendOptions=&quot;8&quot;&gt; - - &lt;Manager className=&quot;org.apache.catalina.ha.session.DeltaManager&quot; - expireSessionsOnShutdown=&quot;false&quot; - notifyListenersOnReplication=&quot;true&quot;/&gt; - - &lt;Channel className=&quot;org.apache.catalina.tribes.group.GroupChannel&quot;&gt; - &lt;Membership className=&quot;org.apache.catalina.tribes.membership.McastService&quot; - address=&quot;228.0.0.4&quot; - port=&quot;45564&quot; - frequency=&quot;500&quot; - dropTime=&quot;3000&quot;/&gt; - &lt;Receiver className=&quot;org.apache.catalina.tribes.transport.nio.NioReceiver&quot; - address=&quot;auto&quot; - port=&quot;4000&quot; - autoBind=&quot;100&quot; - selectorTimeout=&quot;5000&quot; - maxThreads=&quot;6&quot;/&gt; - - &lt;Sender className=&quot;org.apache.catalina.tribes.transport.ReplicationTransmitter&quot;&gt; - &lt;Transport className=&quot;org.apache.catalina.tribes.transport.nio.PooledParallelSender&quot;/&gt; - &lt;/Sender&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.TcpFailureDetector&quot;/&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor&quot;/&gt; - &lt;/Channel&gt; - - &lt;Valve className=&quot;org.apache.catalina.ha.tcp.ReplicationValve&quot; - filter=&quot;&quot;/&gt; - &lt;Valve className=&quot;org.apache.catalina.ha.session.JvmRouteBinderValve&quot;/&gt; - - &lt;Deployer className=&quot;org.apache.catalina.ha.deploy.FarmWarDeployer&quot; - tempDir=&quot;/tmp/war-temp/&quot; - deployDir=&quot;/tmp/war-deploy/&quot; - watchDir=&quot;/tmp/war-listen/&quot; - watchEnabled=&quot;false&quot;/&gt; - - &lt;ClusterListener className=&quot;org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener&quot;/&gt; - &lt;ClusterListener className=&quot;org.apache.catalina.ha.session.ClusterSessionListener&quot;/&gt; - &lt;/Cluster&gt; - </source> - </p> - <p>Will cover this section in more detail later in this document.</p> -</section> - -<section name="Cluster Basics"> - -<p>To run session replication in your Tomcat 6.0 container, the following steps -should be completed:</p> -<ul> - <li>All your session attributes must implement <code>java.io.Serializable</code></li> - <li>Uncomment the <code>Cluster</code> element in server.xml</li> - <li>If you have defined custom cluster valves, make sure you have the <code>ReplicationValve</code> defined as well under the Cluster element in server.xml</li> - <li>If your Tomcat instances are running on the same machine, make sure the <code>tcpListenPort</code> - attribute is unique for each instance, in most cases Tomcat is smart enough to resolve this on it's own by autodetecting available ports in the range 4000-4100</li> - <li>Make sure your <code>web.xml</code> has the <code>&lt;distributable/&gt;</code> element - or set at your <code>&lt;Context distributable="true" /&gt;</code></li> - <li>If you are using mod_jk, make sure that jvmRoute attribute is set at your Engine <code>&lt;Engine name="Catalina" jvmRoute="node01" &gt;</code> - and that the jvmRoute attribute value matches your worker name in workers.properties</li> - <li>Make sure that all nodes have the same time and sync with NTP service!</li> - <li>Make sure that your loadbalancer is configured for sticky session mode.</li> -</ul> -<p>Load balancing can be achieved through many techniques, as seen in the -<a href="balancer-howto.html">Load Balancing</a> chapter.</p> -<p>Note: Remember that your session state is tracked by a cookie, so your URL must look the same from the out - side otherwise, a new session will be created.</p> -<p>Note: Clustering support currently requires the JDK version 1.5 or later.</p> -<p>The Cluster module uses the Tomcat JULI logging framework, so you can configure logging - through the regular logging.properties file. To track messages, you can enable logging on the key:<code>org.apache.catalina.tribes.MESSAGES</code></p> -</section> - - -<section name="Overview"> - -<p>To enable session replication in Tomcat, three different paths can be followed to achieve the exact same thing:</p> -<ol> - <li>Using session persistence, and saving the session to a shared file system (PersistenceManager + FileStore)</li> - <li>Using session persistence, and saving the session to a shared database (PersistenceManager + JDBCStore)</li> - <li>Using in-memory-replication, using the SimpleTcpCluster that ships with Tomcat 6 (lib/catalina-tribes.jar + lib/catalina-ha.jar)</li> -</ol> - -<p>In this release of session replication, Tomcat can perform an all-to-all replication of session state using the <code>DeltaManager</code> or - perform backup replication to only one node using the <code>BackupManager</code>. - The all-to-all replication is an algorithm that is only efficient when the clusters are small. For larger clusters, to use - a primary-secondary session replication where the session will only be stored at one backup server simply setup the BackupManager. <br/> - Currently you can use the domain worker attribute (mod_jk &gt; 1.2.8) to build cluster partitions - with the potential of having a more scaleable cluster solution with the DeltaManager(you'll need to configure the domain interceptor for this). - In order to keep the network traffic down in an all-to-all environment, you can split your cluster - into smaller groups. This can be easily achieved by using different multicast addresses for the different groups. - A very simple setup would look like this: - </p> - -<source> - DNS Round Robin - | - Load Balancer - / \ - Cluster1 Cluster2 - / \ / \ - Tomcat1 Tomcat2 Tomcat3 Tomcat4 -</source> - -<p>What is important to mention here, is that session replication is only the beginning of clustering. - Another popular concept used to implement clusters is farming, ie, you deploy your apps only to one - server, and the cluster will distribute the deployments across the entire cluster. - This is all capabilities that can go into with the FarmWarDeployer (s. cluster example at <code>server.xml</code>)</p> -<p>In the next section will go deeper into how session replication works and how to configure it.</p> - -</section> - -<section name="Cluster Information"> -<p>Membership is established using multicast heartbeats. - Hence, if you wish to subdivide your clusters, you can do this by - changing the multicast IP address or port in the <code>&lt;Membership&gt;</code> element. -</p> -<p> - The heartbeat contains the IP address of the Tomcat node and the TCP port that - Tomcat listens to for replication traffic. All data communication happens over TCP. -</p> -<p> - The <code>ReplicationValve</code> is used to find out when the request has been completed and initiate the - replication, if any. Data is only replicated if the session has changed (by calling setAttribute or removeAttribute - on the session). -</p> -<p> - One of the most important performance considerations is the synchronous versus asynchronous replication. - In a synchronous replication mode the request doesn't return until the replicated session has been - sent over the wire and reinstantiated on all the other cluster nodes. - Synchronous vs asynchronous is configured using the <code>channelSendOptions</code> - flag and is an integer value. The default value for the <code>SimpleTcpCluster/DeltaManager</code> combo is - 8, which is asynchronous. You can read more on the <a href="tribes/introduction.html">send flag(overview)</a> or the - <a href="http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalin... flag(javadoc)</a>. - During async replication, the request is returned before the data has been replicated. async replication yields shorter - request times, and synchronous replication guarantees the session to be replicated before the request returns. -</p> -</section> - -<section name="Bind session after crash to failover node"> -<p> - If you are using mod_jk and not using sticky sessions or for some reasons sticky session don't - work, or you are simply failing over, the session id will need to be modified as it previously contained - the worker id of the previous tomcat (as defined by jvmRoute in the Engine element). - To solve this, we will use the JvmRouteBinderValve. -</p> -<p> - The JvmRouteBinderValve rewrites the session id to ensure that the next request will remain sticky - (and not fall back to go to random nodes since the worker is no longer available) after a fail over. - The valve rewrites the JSESSIONID value in the cookie with the same name. - Not having this valve in place, will make it harder to ensure stickyness in case of a failure for the mod_jk module. -</p> -<p> - By default, if no valves are configured, the JvmRouteBinderValve is added on. - The cluster message listener called JvmRouteSessionIDBinderListener is also defined by default and is used to actually rewrite the - session id on the other nodes in the cluster once a fail over has occurred. - Remember, if you are adding your own valves or cluster listeners in server.xml then the defaults are no longer valid, - make sure that you add in all the appropriate valves and listeners as defined by the default. -</p> -<p> - <b>Hint:</b><br/> - With attribute <i>sessionIdAttribute</i> you can change the request attribute name that included the old session id. - Default attribuite name is <i>org.apache.catalina.cluster.session.JvmRouteOrignalSessionID</i>. -</p> -<p> - <b>Trick:</b><br/> - You can enable this mod_jk turnover mode via JMX before you drop a node to all backup nodes! - Set enable true on all JvmRouteBinderValve backups, disable worker at mod_jk - and then drop node and restart it! Then enable mod_jk Worker and disable JvmRouteBinderValves again. - This use case means that only requested session are migrated. -</p> - - - -</section> - -<section name="Configuration Example"> - <source> - &lt;Cluster className=&quot;org.apache.catalina.ha.tcp.SimpleTcpCluster&quot; - channelSendOptions=&quot;6&quot;&gt; - - &lt;Manager className=&quot;org.apache.catalina.ha.session.BackupManager&quot; - expireSessionsOnShutdown=&quot;false&quot; - notifyListenersOnReplication=&quot;true&quot; - mapSendOptions=&quot;6&quot;/&gt; - &lt;!-- - &lt;Manager className=&quot;org.apache.catalina.ha.session.DeltaManager&quot; - expireSessionsOnShutdown=&quot;false&quot; - notifyListenersOnReplication=&quot;true&quot;/&gt; - --&gt; - &lt;Channel className=&quot;org.apache.catalina.tribes.group.GroupChannel&quot;&gt; - &lt;Membership className=&quot;org.apache.catalina.tribes.membership.McastService&quot; - address=&quot;228.0.0.4&quot; - port=&quot;45564&quot; - frequency=&quot;500&quot; - dropTime=&quot;3000&quot;/&gt; - &lt;Receiver className=&quot;org.apache.catalina.tribes.transport.nio.NioReceiver&quot; - address=&quot;auto&quot; - port=&quot;5000&quot; - selectorTimeout=&quot;100&quot; - maxThreads=&quot;6&quot;/&gt; - - &lt;Sender className=&quot;org.apache.catalina.tribes.transport.ReplicationTransmitter&quot;&gt; - &lt;Transport className=&quot;org.apache.catalina.tribes.transport.nio.PooledParallelSender&quot;/&gt; - &lt;/Sender&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.TcpFailureDetector&quot;/&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor&quot;/&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor&quot;/&gt; - &lt;/Channel&gt; - - &lt;Valve className=&quot;org.apache.catalina.ha.tcp.ReplicationValve&quot; - filter=&quot;.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;&quot;/&gt; - - &lt;Deployer className=&quot;org.apache.catalina.ha.deploy.FarmWarDeployer&quot; - tempDir=&quot;/tmp/war-temp/&quot; - deployDir=&quot;/tmp/war-deploy/&quot; - watchDir=&quot;/tmp/war-listen/&quot; - watchEnabled=&quot;false&quot;/&gt; - - &lt;ClusterListener className=&quot;org.apache.catalina.ha.session.ClusterSessionListener&quot;/&gt; - &lt;/Cluster&gt; - </source> - <p> - Break it down!! - </p> - <source> - &lt;Cluster className=&quot;org.apache.catalina.ha.tcp.SimpleTcpCluster&quot; - channelSendOptions=&quot;6&quot;&gt; - </source> - <p> - The main element, inside this element all cluster details can be configured. - The <code>channelSendOptions</code> is the flag that is attached to each message sent by the - SimpleTcpCluster class or any objects that are invoking the SimpleTcpCluster.send method. - The description of the send flags is available at <a href="http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/catalin... - our javadoc site</a> - The <code>DeltaManager</code> sends information using the SimpleTcpCluster.send method, while the backup manager - sends it itself directly through the channel. - <br/>For more info, Please visit the <a href="config/cluster.html">reference documentation</a> - </p> - <source> - &lt;Manager className=&quot;org.apache.catalina.ha.session.BackupManager&quot; - expireSessionsOnShutdown=&quot;false&quot; - notifyListenersOnReplication=&quot;true&quot; - mapSendOptions=&quot;6&quot;/&gt; - &lt;!-- - &lt;Manager className=&quot;org.apache.catalina.ha.session.DeltaManager&quot; - expireSessionsOnShutdown=&quot;false&quot; - notifyListenersOnReplication=&quot;true&quot;/&gt; - --&gt; - </source> - <p> - This is a template for the manager configuration that will be used if no manager is defined in the &lt;Context&gt; - element. In Tomcat 5.x each webapp marked distributable had to use the same manager, this is no longer the case - since Tomcat 6 you can define a manager class for each webapp, so that you can mix managers in your cluster. - Obviously the managers on one node's application has to correspond with the same manager on the same application on the other node. - If no manager has been specified for the webapp, and the webapp is marked &lt;distributable/&gt; Tomcat will take this manager configuration - and create a manager instance cloning this configuration. - <br/>For more info, Please visit the <a href="config/cluster-manager.html">reference documentation</a> - </p> - <source> - &lt;Channel className=&quot;org.apache.catalina.tribes.group.GroupChannel&quot;&gt; - </source> - <p> - The channel element is <a href="tribes/introduction.html">Tribes</a>, the group communication framework - used inside Tomcat. This element encapsulates everything that has to do with communication and membership logic. - <br/>For more info, Please visit the <a href="config/cluster-channel.html">reference documentation</a> - </p> - <source> - &lt;Membership className=&quot;org.apache.catalina.tribes.membership.McastService&quot; - address=&quot;228.0.0.4&quot; - port=&quot;45564&quot; - frequency=&quot;500&quot; - dropTime=&quot;3000&quot;/&gt; - </source> - <p> - Membership is done using multicasting. Please note that Tribes also supports static memberships using the - <code>StaticMembershipInterceptor</code> if you want to extend your membership to points beyond multicasting. - The address attribute is the multicast address used and the port is the multicast port. These two together - create the cluster separation. If you want a QA cluster and a production cluster, the easiest config is to - have the QA cluster be on a separate multicast address/port combination the the production cluster.<br/> - The membership component broadcasts TCP adress/port of itselt to the other nodes so that communication between - nodes can be done over TCP. Please note that the address being broadcasted is the one of the - <code>Receiver.address</code> attribute. - <br/>For more info, Please visit the <a href="config/cluster-membership.html">reference documentation</a> - </p> - <source> - &lt;Receiver className=&quot;org.apache.catalina.tribes.transport.nio.NioReceiver&quot; - address=&quot;auto&quot; - port=&quot;5000&quot; - selectorTimeout=&quot;100&quot; - maxThreads=&quot;6&quot;/&gt; - </source> - <p> - In tribes the logic of sending and receiving data has been broken into two functional components. The Receiver, as the name suggests - is responsible for receiving messages. Since the Tribes stack is thread less, (a popular improvement now adopted by other frameworks as well), - there is a thread pool in this component that has a maxThreads and minThreads setting.<br/> - The address attribute is the host address that will be broadcasted by the membership component to the other nodes. - <br/>For more info, Please visit the <a href="config/cluster-receiver.html">reference documentation</a> - </p> - <source> - - &lt;Sender className=&quot;org.apache.catalina.tribes.transport.ReplicationTransmitter&quot;&gt; - &lt;Transport className=&quot;org.apache.catalina.tribes.transport.nio.PooledParallelSender&quot;/&gt; - &lt;/Sender&gt; - </source> - <p> - The sender component, as the name indicates is responsible for sending messages to other nodes. - The sender has a shell component, the <code>ReplicationTransmitter</code> but the real stuff done is done in the - sub component, <code>Transport</code>. - Tribes support having a pool of senders, so that messages can be sent in parallel and if using the NIO sender, - you can send messages concurrently as well.<br/> - Concurrently means one message to multiple senders at the same time and Parallel means multiple messages to multiple senders - at the same time. - <br/>For more info, Please visit the <a href="config/cluster-sender.html">reference documentation</a> - </p> - <source> - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.TcpFailureDetector&quot;/&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.MessageDispatch15Interceptor&quot;/&gt; - &lt;Interceptor className=&quot;org.apache.catalina.tribes.group.interceptors.ThroughputInterceptor&quot;/&gt; - &lt;/Channel&gt; - </source> - <p> - Tribes uses a stack to send messages through. Each element in the stack is called an interceptor, and works much like the valves do - in the Tomcat servlet container. - Using interceptors, logic can be broken into more managable pieces of code. The interceptors configured above are:<br/> - TcpFailureDetector - verifies crashed members through TCP, if multicast packets get dropped, this interceptor protects against false positives, - ie the node marked as crashed even though it still is alive and running.<br/> - MessageDispatch15Interceptor - dispatches messages to a thread (thread pool) to send message asynchrously.<br/> - ThroughputInterceptor - prints out simple stats on message traffic.<br/> - Please note that the order of interceptors is important. the way they are defined in server.xml is the way they are represented in the - channel stack. Think of it as a linked list, with the head being the first most interceptor and the tail the last. - <br/>For more info, Please visit the <a href="config/cluster-interceptor.html">reference documentation</a> - </p> - <source> - &lt;Valve className=&quot;org.apache.catalina.ha.tcp.ReplicationValve&quot; - filter=&quot;.*\.gif;.*\.js;.*\.jpg;.*\.png;.*\.htm;.*\.html;.*\.css;.*\.txt;&quot;/&gt; - </source> - <p> - The cluster uses valves to track requests to web applications, we've mentioned the ReplicationValve and the JvmRouteBinderValve above. - The &lt;Cluster&gt; element itself is not part of the pipeline in Tomcat, instead the cluster adds the valve to its parent container. - If the &lt;Cluster&gt; elements is configured in the &lt;Engine&gt; element, the valves get added to the engine and so on. - <br/>For more info, Please visit the <a href="config/cluster-valve.html">reference documentation</a> - </p> - <source> - &lt;Deployer className=&quot;org.apache.catalina.ha.deploy.FarmWarDeployer&quot; - tempDir=&quot;/tmp/war-temp/&quot; - deployDir=&quot;/tmp/war-deploy/&quot; - watchDir=&quot;/tmp/war-listen/&quot; - watchEnabled=&quot;false&quot;/&gt; - </source> - <p> - The default tomcat cluster supports farmed deployment, ie, the cluster can deploy and undeploy applications on the other nodes. - The state of this component is currently in flux but will be addressed soon. There was a change in the deployment algorithm - between Tomcat 5.0 and 5.5 and at that point, the logic of this component changed to where the deploy dir has to match the - webapps directory. - <br/>For more info, Please visit the <a href="config/cluster-deployer.html">reference documentation</a> - </p> - <source> - &lt;ClusterListener className=&quot;org.apache.catalina.ha.session.ClusterSessionListener&quot;/&gt; - &lt;/Cluster&gt; - </source> - <p> - Since the SimpleTcpCluster itself is a sender and receiver of the Channel object, components can register themselves as listeners to - the SimpleTcpCluster. The listener above <code>ClusterSessionListener</code> listens for DeltaManager replication messages - and applies the deltas to the manager that in turn applies it to the session. - <br/>For more info, Please visit the <a href="config/cluster-listener.html">reference documentation</a> - </p> - -</section> - -<section name="Cluster Architecture"> - -<p><b>Component Levels:</b> -<source> - Server - | - Service - | - Engine - | \ - | --- Cluster --* - | - Host - | - ------ - / \ - Cluster Context(1-N) - | \ - | -- Manager - | \ - | -- DeltaManager - | -- BackupManager - | - --------------------------- - | \ - Channel \ - ----------------------------- \ - | \ - Interceptor_1 .. \ - | \ - Interceptor_N \ - ----------------------------- \ - | | | \ - Receiver Sender Membership \ - -- Valve - | \ - | -- ReplicationValve - | -- JvmRouteBinderValve - | - -- LifecycleListener - | - -- ClusterListener - | \ - | -- ClusterSessionListener - | -- JvmRouteSessionIDBinderListener - | - -- Deployer - \ - -- FarmWarDeployer - - -</source> -</p> - -</section> -<section name="How it Works"> -<p>To make it easy to understand how clustering works, We are gonna take you through a series of scenarios. - In the scenario we only plan to use two tomcat instances <code>TomcatA</code> and <code>TomcatB</code>. - We will cover the following sequence of events:</p> - -<ol> -<li><code>TomcatA</code> starts up</li> -<li><code>TomcatB</code> starts up (Wait that TomcatA start is complete)</li> -<li><code>TomcatA</code> receives a request, a session <code>S1</code> is created.</li> -<li><code>TomcatA</code> crashes</li> -<li><code>TomcatB</code> receives a request for session <code>S1</code></li> -<li><code>TomcatA</code> starts up</li> -<li><code>TomcatA</code> receives a request, invalidate is called on the session (<code>S1</code>)</li> -<li><code>TomcatB</code> receives a request, for a new session (<code>S2</code>)</li> -<li><code>TomcatA</code> The session <code>S2</code> expires due to inactivity.</li> -</ol> - -<p>Ok, now that we have a good sequence, we will take you through exactly what happens in the session repliction code</p> - -<ol> -<li><b><code>TomcatA</code> starts up</b> - <p> - Tomcat starts up using the standard start up sequence. When the Host object is created, a cluster object is associated with it. - When the contexts are parsed, if the distributable element is in place in web.xml - Tomcat asks the Cluster class (in this case <code>SimpleTcpCluster</code>) to create a manager - for the replicated context. So with clustering enabled, distributable set in web.xml - Tomcat will create a <code>DeltaManager</code> for that context instead of a <code>StandardManager</code>. - The cluster class will start up a membership service (multicast) and a replication service (tcp unicast). - More on the architecture further down in this document. - </p><p></p> -</li> -<li><b><code>TomcatB</code> starts up</b> - <p> - When TomcatB starts up, it follows the same sequence as TomcatA did with one exception. - The cluster is started and will establish a membership (TomcatA,TomcatB). - TomcatB will now request the session state from a server that already exists in the cluster, - in this case TomcatA. TomcatA responds to the request, and before TomcatB starts listening - for HTTP requests, the state has been transferred from TomcatA to TomcatB. - In case TomcatA doesn't respond, TomcatB will time out after 60 seconds, and issue a log - entry. The session state gets transferred for each web application that has distributable in - its web.xml. Note: To use session replication efficiently, all your tomcat instances should be - configured the same. - </p><p></p> -</li> -<li><B><code>TomcatA</code> receives a request, a session <code>S1</code> is created.</B> - <p> - The request coming in to TomcatA is treated exactly the same way as without session replication. - The action happens when the request is completed, the <code>ReplicationValve</code> will intercept - the request before the response is returned to the user. - At this point it finds that the session has been modified, and it uses TCP to replicata the - session to TomcatB. Once the serialized data has been handed off to the operating systems TCP logic, - the request returns to the user, back through the valve pipeline. - For each request the entire session is replicated, this allows code that modifies attributes - in the session without calling setAttribute or removeAttribute to be replicated. - a useDirtyFlag configuration parameter can be used to optimize the number of times - a session is replicated. - </p><p></p> - -</li> -<li><b><code>TomcatA</code> crashes</b> - <p> - When TomcatA crashes, TomcatB receives a notification that TomcatA has dropped out - of the cluster. TomcatB removes TomcatA from its membership list, and TomcatA will no longer - be notified of any changes that occurs in TomcatB. - The load balancer will redirect the requests from TomcatA to TomcatB and all the sessions - are current. - </p><p></p> -</li> -<li><b><code>TomcatB</code> receives a request for session <code>S1</code></b> - <p>Nothing exciting, TomcatB will process the request as any other request. - </p><p></p> -</li> -<li><b><code>TomcatA</code> starts up</b> - <p>Upon start up, before TomcatA starts taking new request and making itself - available to it will follow the start up sequence described above 1) 2). - It will join the cluster, contact TomcatB for the current state of all the sessions. - And once it receives the session state, it finishes loading and opens its HTTP/mod_jk ports. - So no requests will make it to TomcatA until it has received the session state from TomcatB. - </p><p></p> -</li> -<li><b><code>TomcatA</code> receives a request, invalidate is called on the session (<code>S1</code>)</b> - <p>The invalidate is call is intercepted, and the session is queued with invalidated sessions. - When the request is complete, instead of sending out the session that has changed, it sends out - an "expire" message to TomcatB and TomcatB will invalidate the session as well. - </p><p></p> - -</li> -<li><b><code>TomcatB</code> receives a request, for a new session (<code>S2</code>)</b> - <p>Same scenario as in step 3) - </p><p></p> - - -</li> -<li><code>TomcatA</code> The session <code>S2</code> expires due to inactivity. - <p>The invalidate is call is intercepted the same was as when a session is invalidated by the user, - and the session is queued with invalidated sessions. - At this point, the invalidet session will not be replicated across until - another request comes through the system and checks the invalid queue. - </p><p></p> -</li> -</ol> - -<p>Phuuuhh! :)</p> - -<p><b>Membership</b> - Clustering membership is established using very simple multicast pings. - Each Tomcat instance will periodically send out a multicast ping, - in the ping message the instance will broad cast its IP and TCP listen port - for replication. - If an instance has not received such a ping within a given timeframe, the - member is considered dead. Very simple, and very effective! - Of course, you need to enable multicasting on your system. -</p> - -<p><b>TCP Replication</b> - Once a multicast ping has been received, the member is added to the cluster - Upon the next replication request, the sending instance will use the host and - port info and establish a TCP socket. Using this socket it sends over the serialized data. - The reason I choose TCP sockets is because it has built in flow control and guaranteed delivery. - So I know, when I send some data, it will make it there :) -</p> - -<p><b>Distributed locking and pages using frames</b> - Tomcat does not keep session instances in sync across the cluster. - The implementation of such logic would be to much overhead and cause all - kinds of problems. If your client accesses the same session - simultanously using multiple requests, then the last request - will override the other sessions in the cluster. -</p> - -</section> - - - - - - -<section name="Monitoring your Cluster with JMX"> -<p>Monitoring is a very important question when you use a cluster. Some of the cluster objects are JMX MBeans </p> -<p>Add the following parameter to your startup script with Java 5: -<source> -set CATALINA_OPTS=\ --Dcom.sun.management.jmxremote \ --Dcom.sun.management.jmxremote.port=%my.jmx.port% \ --Dcom.sun.management.jmxremote.ssl=false \ --Dcom.sun.management.jmxremote.authenticate=false -</source> -</p> -<p>Activate JMX with JDK 1.4: -<ol> -<li>Install the compat package</li> -<li>Install the mx4j-tools.jar at common/lib (use the same mx4j version as your tomcat release)</li> -<li>Configure a MX4J JMX HTTP Adaptor at your AJP Connector<p></p> -<source> -&lt;Connector port="${AJP.PORT}" - handler.list="mx" - mx.enabled="true" - mx.httpHost="${JMX.HOST}" - mx.httpPort="${JMX.PORT}" - protocol="AJP/1.3" /&gt; -</source> -</li> -<li>Start your tomcat and look with your browser to http://${JMX.HOST}:${JMX.PORT}</li> -<li>With the connector parameter <code>mx.authMode="basic" mx.authUser="tomcat" mx.authPassword="strange"</code> you can control the access!</li> -</ol> -</p> -<p> -List of Cluster Mbeans<br/> -<table border="1" cellpadding="5"> - - <tr> - <th align="center" bgcolor="aqua">Name</th> - <th align="center" bgcolor="aqua">Description</th> - <th align="center" bgcolor="aqua">MBean ObjectName - Engine</th> - <th align="center" bgcolor="aqua">MBean ObjectName - Host</th> - </tr> - - <tr> - <td>Cluster</td> - <td>The complete cluster element</td> - <td><code>type=Cluster</code></td> - <td><code>type=Cluster,host=${HOST}</code></td> - </tr> - - <tr> - <td>DeltaManager</td> - <td>This manager control the sessions and handle session replication </td> - <td><code>type=Manager,path=${APP.CONTEXT.PATH}, host=${HOST}</code></td> - <td><code>type=Manager,path=${APP.CONTEXT.PATH}, host=${HOST}</code></td> - </tr> - - <tr> - <td>ReplicationValve</td> - <td>This valve control the replication to the backup nodes</td> - <td><code>type=Valve,name=ReplicationValve</code></td> - <td><code>type=Valve,name=ReplicationValve,host=${HOST}</code></td> - </tr> - - <tr> - <td>JvmRouteBinderValve</td> - <td>This is a cluster fallback valve to change the Session ID to the current tomcat jvmroute.</td> - <td><code>type=Valve,name=JvmRouteBinderValve, - path=${APP.CONTEXT.PATH}</code></td> - <td><code>type=Valve,name=JvmRouteBinderValve,host=${HOST}, - path=${APP.CONTEXT.PATH}</code></td> - </tr> - -</table> -</p> -</section> - -<section name="FAQ"> -<p>Please see <a href="http://tomcat.apache.org/faq/cluster.html">the clustering section of the FAQ</a>.</p> -</section> - -</body> - -</document> Modified: trunk/webapps/docs/connectors.xml =================================================================== --- trunk/webapps/docs/connectors.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/connectors.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -15,19 +15,19 @@ <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 +<p>Choosing a connector to use with JBoss Web can be difficult. This page will +list the connectors which are supported with this JBoss Web 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 +<p>The HTTP connector is setup by default with JBoss Web, 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 +must be installed to direct the traffic to the JBoss Web servers. JBoss Web 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> @@ -37,14 +37,14 @@ <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 +front of the JBoss Web instance is most of the time significantly worse than a +standalone JBoss Web 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. +proxied HTTP. AJP clustering is the most efficient from the JBoss Web perspective. It is otherwise functionally equivalent to HTTP clustering.</p> -<p>The native connectors supported with this Tomcat release are: +<p>The native connectors supported with this JBoss Web 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), Modified: trunk/webapps/docs/default-servlet.xml =================================================================== --- trunk/webapps/docs/default-servlet.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/default-servlet.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -76,7 +76,7 @@ <tr> <th valign='top'>debug</th> <td valign='top'> - Debugging level. It is not very useful unless you are a tomcat + Debugging level. It is not very useful unless you are a JBoss Web developer. As of this writing, useful values are 0, 1, 11, 1000. </td> @@ -206,7 +206,7 @@ <li>Readme is a CDATA entry</li> </ul> </p> -The following is a sample xsl file which mimics the default tomcat behavior: +The following is a sample xsl file which mimics the default JBoss Web behavior: <source> &lt;?xml version="1.0"?&gt; @@ -249,7 +249,7 @@ &lt;/table&gt; &lt;xsl:apply-templates select="readme"/&gt; &lt;hr size="1" /&gt; - &lt;h3&gt;Apache Tomcat/6.0&lt;/h3&gt; + &lt;h3&gt;JBoss Web/2.1&lt;/h3&gt; &lt;/body&gt; &lt;/html&gt; &lt;/xsl:template&gt; Modified: trunk/webapps/docs/deployer-howto.xml =================================================================== --- trunk/webapps/docs/deployer-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/deployer-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -8,7 +8,7 @@ <properties> <author>Allistair Crossley</author> - <title>Tomcat Web Application Deployment</title> + <title>JBoss Web Web Application Deployment</title> </properties> <body> @@ -18,11 +18,11 @@ <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="#Deployment on JBoss Web startup">Deployment on JBoss Web startup</a></li> + <li><a href="#Deploying on a running JBoss Web server">Deploying on a running JBoss Web server</a></li> + <li><a href="#Deploying using the JBoss Web Manager">Deploying using the JBoss Web Manager</a></li> <li><a href="#Deploying using the Client Deployer Package">Deploying using - the Tomcat Client Deployer</a></li> + the JBoss Web Client Deployer</a></li> </ul> </section> @@ -31,23 +31,23 @@ <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. + into the JBoss Web server. </p> <p> Web application deployment may be accomplished in a number of ways - within the Tomcat server. + within the JBoss Web server. <ul> - <li>Statically; the web application is setup before Tomcat is started</li> + <li>Statically; the web application is setup before JBoss Web is started</li> <li> - Dynamically; in conjunction with the Tomcat Manager web application or + Dynamically; in conjunction with the JBoss Web 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 + The JBoss Web 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 + which is a command shell based script that interacts with the JBoss Web Manager but provides additional functionality such as compiling and validating web applications as well as packaging web application into web application resource (WAR) files. @@ -57,17 +57,17 @@ <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, + applications as this is provided out of the box by JBoss Web. Nor is any + installation required for deployment functions with the JBoss Web 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). + JBoss Web Manager manual. An installation is however required if you wish + to use the JBoss Web Client Deployer (TCD). </p> <p> - The TCD is not packaged with the Tomcat core + The TCD is not packaged with the JBoss Web core distribution, and must therefore be downloaded separately from the Downloads area. The download is usually labelled - <i>apache-tomcat-6.0.x-deployer</i>. + <i>jbossweb-2.1.x-deployer</i>. </p> <p> TCD has prerequisites of Apache Ant 1.6.2+ and a Java installation. @@ -80,32 +80,32 @@ <ol> <li>Download the TCD distribution</li> <li> - The TCD package need not be extracted into any existing Tomcat + The TCD package need not be extracted into any existing JBoss Web 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> + JBoss Web 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 + <i>Context</i> is required to be understood. A Context is what JBoss Web calls a web application. </p> <p> - In order to configure a Context within Tomcat a <i>Context Descriptor</i> + In order to configure a Context within JBoss Web 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 + JBoss Web 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 + JBoss Web the content of a Context Descriptor configuration was often stored within + JBoss Web'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 + Context Descriptors not only help JBoss Web to know how to configure + Contexts but other tools such as the JBoss Web Manager and TDC often use these Context Descriptors to perform their roles properly. </p> <p> @@ -116,15 +116,15 @@ </ol> Files in (1) are named [webappname].xml but files in (2) are named context.xml. If a Context Descriptor is not provided for a Context, - Tomcat configures the Context using default values. + JBoss Web configures the Context using default values. </p> </section> - <section name="Deployment on Tomcat startup"> + <section name="Deployment on JBoss Web startup"> <p> - If you are not interested in using the Tomcat Manager, or TCD, + If you are not interested in using the JBoss Web Manager, or TCD, then you'll need to deploy your web applications - statically to Tomcat, followed by a Tomcat startup. The location you + statically to JBoss Web, followed by a JBoss Web 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 @@ -133,11 +133,11 @@ <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 + appBase is "$CATALINA_HOME/webapps") will be deployed on JBoss Web 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 + The following deployment sequence will occur on JBoss Web startup in that case: </p> <ol> @@ -157,9 +157,9 @@ </p> </section> - <section name="Deploying on a running Tomcat server"> + <section name="Deploying on a running JBoss Web server"> <p> - It is possible to deploy web applications to a running Tomcat server. + It is possible to deploy web applications to a running JBoss Web server. </p> <p> If the Host <code>autoDeploy</code> attribute is "true", the Host will @@ -170,7 +170,7 @@ </p> <p> - <code>autoDeploy</code> set to "true" and a running Tomcat allows for: + <code>autoDeploy</code> set to "true" and a running JBoss Web allows for: </p> <ul> <li>Deployment of .WAR files copied into the Host <code>appBase</code>.</li> @@ -215,19 +215,19 @@ </p> </section> - <section name="Deploying using the Tomcat Manager"> + <section name="Deploying using the JBoss Web Manager"> <p> - The Tomcat Manager is covered in its <a href="manager-howto.html">own manual page</a>. + The JBoss Web 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 + JBoss Web 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 + production or development JBoss Web servers. It should be noted that this feature + uses the JBoss Web Manager and as such the target JBoss Web server should be running. </p> @@ -262,15 +262,15 @@ <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 + JBoss Web server. The compiled application will only run on the associated + JBoss Web server release, and is not guaranteed to work on another + JBoss Web 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. + a JBoss Web server. </li> <li><code>undeploy</code>: Undeploy a web application</li> <li><code>start</code>: Start web application</li> @@ -287,9 +287,9 @@ <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. + setup for the target JBoss Web Manager (which TCD uses) otherwise the TCD + will not authenticate with the JBoss Web Manager and the deployment will + fail. To do this, see the JBoss Web Manager page. </p> <ul> @@ -309,17 +309,17 @@ 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 + <code>url</code>: Absolute URL to the JBoss Web Manager web application of a + running JBoss Web 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 + a JBoss Web 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 + <code>username</code>: JBoss Web Manager username (user should have a role of manager) </li> - <li><code>password</code>: Tomcat Manager password.</li> + <li><code>password</code>: JBoss Web Manager password.</li> </ul> </section> Deleted: trunk/webapps/docs/developers.xml =================================================================== --- trunk/webapps/docs/developers.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/developers.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -1,59 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE document [ - <!ENTITY project SYSTEM "project.xml"> -]> -<document url="developers.html"> - - &project; - - <properties> - <author email=&quot;remm(a)apache.org&quot;&gt;Remy Maucherat</author> - <author email=&quot;yoavs(a)apache.org&quot;&gt;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&gt;[login](a)apache.org&lt;/code&gt;. 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>Jim Jagielski (jim): 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> Deleted: trunk/webapps/docs/extras.xml =================================================================== --- trunk/webapps/docs/extras.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/extras.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -1,71 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE document [ - <!ENTITY project SYSTEM "project.xml"> -]> -<document url="extras.html"> - - &project; - - <properties> - <title>Additional Components</title> - <author>Remy Maucherat</author> - </properties> - -<body> - - <section name="Introduction"> - <p> - A number of additional third party components may be used with Apache Tomcat, but are not - provided directly in the downlad bundle for a variety of reasons. These may be built by - users should they need it. - </p> - - </section> - - <section name="Building"> - - <p> - The additional components are built using the <code>extras.xml</code> Ant script which is - present in the source bundle of Tomcat. - </p> - - <p>The build process is the following:</p> - - <ul> - <li>Follow the <a href="building.html">build instructions</a> to build a Tomcat binary from - the source bundle (note: it will be used by the build process of the additional components, but - does not need to be actually used later on)</li> - <li>Execute the command <code>ant -f extras.xml</code> to run the build script</li> - <li>The additional components JARs will be placed in the <code>output/extras</code> folder</li> - <li>Refer to the documentation below about the usage of these JARs</li> - </ul> - - </section> - - <section name="Components list"> - - <subsection name="Full commons-logging implementation"> - - <p> - Tomcat uses a package renamed commons-logging API implementation which is hardcoded to use - the java.util.logging API. The commons-logging additional component builds a full fledged - package renames commons-logging implementation which can be used to replace the implementation - provided with Tomcat. See the <a href="logging.html">logging</a> page for usage instructions. - </p> - - </subsection> - - <subsection name="Web Services support (JSR 109)"> - - <p> - Tomcat provides factories for JSR 109 which may be used to resolve web services references. - Place the generated catalina-ws.jar as well as jaxrpc.jar and wsdl4j.jar (or another implementation - of JSR 109) in the Tomcat lib folder. - </p> - - </subsection> - - </section> - -</body> -</document> Modified: trunk/webapps/docs/html-manager-howto.xml =================================================================== --- trunk/webapps/docs/html-manager-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/html-manager-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -8,7 +8,7 @@ <properties> <author email=&quot;glenn(a)apache.org&quot;&gt;Glenn L. Nielsen</author> - <title>Tomcat Web Application Manager How To</title> + <title>JBoss Web Application Manager How To</title> </properties> <body> @@ -17,7 +17,7 @@ <p>In many production environments it is very useful to have the capability to manage your web applications without having to shut down and restart -Tomcat. This document is for the HTML web interface to the web application +JBoss Web. This document is for the HTML web interface to the web application <a href="manager-howto.html">manager</a>.</p> <p>The interface is divided into five sections: @@ -28,7 +28,7 @@ <li><strong>Applications</strong> - List of web applications and commands.</li> <li><strong>Deploy</strong> - Deploying web applications.</li> - <li><strong>Server Information</strong> - Information about the Tomcat + <li><strong>Server Information</strong> - Information about the JBoss Web server.</li> </ul> </p> @@ -117,7 +117,7 @@ <li><em>Encountered exception</em> <blockquote> <p>An exception was encountered trying to start the web application. - Check the Tomcat 5 logs for the details.</p> + Check the JBoss Web logs for the details.</p> </blockquote></li> <li><em>Invalid context path was specified</em> <blockquote> @@ -157,7 +157,7 @@ <li><em>Encountered exception</em> <blockquote> <p>An exception was encountered trying to stop the web application. - Check the Tomcat 5 logs for the details.</p> + Check the JBoss Web logs for the details.</p> </blockquote></li> <li><em>Invalid context path was specified</em> <blockquote> @@ -205,7 +205,7 @@ <li><em>Encountered exception</em> <blockquote> <p>An exception was encountered trying to restart the web application. - Check the Tomcat 5 logs for the details.</p> + Check the JBoss Web logs for the details.</p> </blockquote></li> <li><em>Invalid context path was specified</em> <blockquote> @@ -247,7 +247,7 @@ <code>/stop</code> command instead.</p> <p>Signal an existing application to gracefully shut itself down, and then -remove it from Tomcat (which also makes this context path available for +remove it from JBoss Web (which also makes this context path available for reuse later). This command is the logical opposite of the <code>/deploy</code> Ant command, and the related deploy features available in the HTML manager.</p> @@ -263,7 +263,7 @@ <li><em>Encountered exception</em> <blockquote> <p>An exception was encountered trying to undeploy the web application. - Check the Tomcat logs for the details.</p> + Check the JBoss Web logs for the details.</p> </blockquote></li> <li><em>Invalid context path was specified</em> <blockquote> @@ -290,7 +290,7 @@ <section name="Deploy"> <p>Web applications can be deployed using files or directories located -on the Tomcat server or you can upload a web application archive (WAR) +on the JBoss Web server or you can upload a web application archive (WAR) file to the server.</p> <p>To install an application, fill in the appropriate fields for the type @@ -307,7 +307,7 @@ <h3>Deploy a Directory or WAR by URL</h3> -<p>Install a web application directory or ".war" file located on the Tomcat +<p>Install a web application directory or ".war" file located on the JBoss Web server. If no <i>Context Path</i> is specified, the directory name or the war file name without the ".war" extension is used as the path. The <i>WAR or Directory URL</i> specifies a URL (including the <code>file:</code> @@ -317,7 +317,7 @@ refer to the entire WAR file.</p> <p>In this example the web application located in the directory -<code>C:\path\to\foo</code> on the Tomcat server (running on Windows) +<code>C:\path\to\foo</code> on the JBoss Web server (running on Windows) is deployed as the web application context named <code>/footoo</code>. <source> Context Path: /footoo @@ -326,7 +326,7 @@ </p> <p>In this example the ".war" file <code>/path/to/bar.war</code> on the -Tomcat server (running on Unix) is deployed as the web application +JBoss Web server (running on Unix) is deployed as the web application context named <code>/bar</code>. Notice that there is no <code>path</code> parameter so the context path defaults to the name of the web application archive file without the ".war" extension. @@ -342,7 +342,7 @@ or the war file name without the ".war" extension is used as the path.</p> <p>In this example the web application located in a subdirectory named -<code>foo</code> in the Host appBase directory of the Tomcat server is +<code>foo</code> in the Host appBase directory of the JBoss Web server is deployed as the web application context named <code>/foo</code>. Notice that there is no <code>path</code> parameter so the context path defaults to the name of the web application directory. @@ -352,7 +352,7 @@ </p> <p>In this example the ".war" file <code>bar.war</code> located in your -Host appBase directory on the Tomcat server is deployed as the web +Host appBase directory on the JBoss Web server is deployed as the web application context named <code>/bartoo</code>. <source> Context Path: /bartoo @@ -370,8 +370,8 @@ <p>A Context configuration ".xml" file can contain valid XML for a web application Context just as if it were configured in your -Tomcat <code>server.xml</code> configuration file. Here is an -example for Tomcat running on Windows: +JBoss Web <code>server.xml</code> configuration file. Here is an +example for JBoss Web running on Windows: <source> &lt;Context path="/foobar" docBase="C:\path\to\application\foobar" debug="0"&gt; @@ -389,7 +389,7 @@ docBase configured in the context configuration ".xml" file.</p> <p>Here is an example of installing an application using a Context -configuration ".xml" file for Tomcat running on Windows. +configuration ".xml" file for JBoss Web running on Windows. <source> XML Configuration file URL: file:C:/path/to/context.xml </source> @@ -397,7 +397,7 @@ <p>Here is an example of installing an application using a Context configuration ".xml" file and a web application ".war" file located -on the server (Tomcat running on Unix). +on the server (JBoss Web running on Unix). <source> XML Configuration file URL: file:/path/to/context.xml WAR or Directory URL: jar:file:/path/to/bar.war!/ @@ -415,7 +415,7 @@ <p>Use the <i>Browse</i> button to select a WAR file to upload to the server from your local desktop system.</p> -<p>The .WAR file may include Tomcat specific deployment configuration, by +<p>The .WAR file may include JBoss Web specific deployment configuration, by including a Context configuration XML file in <code>/META-INF/context.xml</code>.</p> @@ -494,7 +494,7 @@ <li><em>Encountered exception</em> <blockquote> <p>An exception was encountered trying to start the new web application. - Check the Tomcat 5 logs for the details, but likely explanations include + Check the JBoss Web logs for the details, but likely explanations include problems parsing your <code>/WEB-INF/web.xml</code> file, or missing classes encountered when initializing application event listeners and filters.</p> @@ -532,8 +532,8 @@ <section name="Server Information"> -<p>This section displays information about Tomcat, the operating system of -the server Tomcat is hosted on, and the Java Virtual Machine Tomcat is +<p>This section displays information about JBoss Web, the operating system of +the server JBoss Web is hosted on, and the Java Virtual Machine JBoss Web is running in.</p> </section> Modified: trunk/webapps/docs/index.xml =================================================================== --- trunk/webapps/docs/index.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/index.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -18,9 +18,9 @@ <section name="Introduction"> <p>This is the top-level entry point of the documentation bundle for the -<strong>Apache Tomcat</strong> Servlet/JSP container. Apache Tomcat version 6.0 -implements the -Servlet 2.5 and JavaServer Pages 2.1 specifications from the +<strong>JBoss Web</strong> Servlet/JSP container, which is based on the +Apache Tomcat 6.0 project developed by the Apache Software Foundation. +JBoss Web implements the Servlet 2.5 and JavaServer Pages 2.1 specifications from the <a href="http://www.jcp.org">Java Community Process</a>, and includes many additional features that make it a useful platform for developing and deploying web applications and web services.</p> @@ -32,16 +32,16 @@ </section> -<section name="Apache Tomcat User Guide"> +<section name="JBoss Web User Guide"> <p>The following documents will assist you in downloading, installing -Apache Tomcat 6, and using many of the Apache Tomcat features.</p> +JBoss Web, and using many of its features.</p> <ol> <li><a href="introduction.html"><strong>Introduction</strong></a> - A - brief, high level, overview of Apache Tomcat.</li> + brief, high level, overview of JBoss Web.</li> <li><a href="setup.html"><strong>Setup</strong></a> - How to install and run - Apache Tomcat on a variety of platforms.</li> + JBoss Web on a variety of platforms.</li> <li><a href="appdev/index.html"><strong>First web application</strong></a> - An introduction to the concepts of a <em>web application</em> as defined in the <a href="http://java.sun.com/products/servlet/download.html">Se... @@ -50,11 +50,11 @@ introduction to the web application deployment descriptor (<code>/WEB-INF/web.xml</code>).</li> <li><a href="deployer-howto.html"><strong>Deployer</strong></a> - - Operating the Apache Tomcat Deployer to deploy, precompile, and validate web + Operating the JBoss Web Deployer to deploy, precompile, and validate web applications.</li> <li><a href="manager-howto.html"><strong>Manager</strong></a> - Operating the <code>Manager</code> web app to deploy, undeploy, and - redeploy applications while Apache Tomcat is running.</li> + redeploy applications while JBoss Web is running.</li> <li><a href="realm-howto.html"><strong>Realms and Access Control</strong></a> - Description of how to configure <em>Realms</em> (databases of users, passwords, and their associated roles) for use in web applications that @@ -71,45 +71,39 @@ - Configuring a JNDI DataSoure with a DB connection pool. Examples for many popular databases.</li> <li><a href="class-loader-howto.html"><strong>Classloading</strong></a> - - Information about class loading in Apache Tomcat 5, including where to place + - Information about class loading in JBoss Web, including where to place your application classes so that they are visible.</li> <li><a href="jasper-howto.html"><strong>JSPs</strong></a> - Information about Jasper configuration, as well as the JSP compiler usage.</li> <li><a href="ssl-howto.html"><strong>SSL</strong></a> - Installing and - configuring SSL support so that your Apache Tomcat will serve requests using + configuring SSL support so that your JBoss Web will serve requests using the <code>https</code> protocol.</li> <li><a href="ssi-howto.html"><strong>SSI</strong></a> - - Using Server Side Includes in Apache Tomcat.</li> + Using Server Side Includes in JBoss Web.</li> <li><a href="cgi-howto.html"><strong>CGI</strong></a> - - Using CGIs with Apache Tomcat.</li> + Using CGIs with JBoss Web.</li> <li><a href="proxy-howto.html"><strong>Proxy Support</strong></a> - - Configuring Apache Tomcat 5 to run behind a proxy server (or a web server + Configuring JBoss Web to run behind a proxy server (or a web server functioning as a proxy server).</li> <li><a href="mbeans-descriptor-howto.html"><strong>MBean Descriptor</strong></a> - Configuring MBean descriptors files for custom components.</li> <li><a href="default-servlet.html"><strong>Default Servlet</strong></a> - Configuring the default servlet and customizing directory listings.</li> -<li><a href="cluster-howto.html"><strong>Apache Tomcat Clustering</strong></a> - - Enable session replication in a Apache Tomcat environment.</li> -<li><a href="balancer-howto.html"><strong>Balancer</strong></a> - - Configuring, using, and extending the load balancer application.</li> <li><a href="connectors.html"><strong>Connectors</strong></a> - - Connectors available in Apache Tomcat, and native web server integration.</li> + Connectors available in JBoss Web, and native web server integration.</li> <li><a href="monitoring.html"><strong>Monitoring and Management</strong></a> - - Enabling JMX Remote support, and using tools to monitor and manage Apache Tomcat.</li> + Enabling JMX Remote support, and using tools to monitor and manage JBoss Web.</li> <li><a href="logging.html"><strong>Logging</strong></a> - - Configuring logging in Apache Tomcat.</li> + Configuring logging in JBoss Web.</li> <li><a href="apr.html"><strong>Apache Portable Runtime</strong></a> - Using APR to provide superior performance, scalability and better integration with native server technologies.</li> <li><a href="virtual-hosting-howto.html"><strong>Virtual Hosting</strong></a> - - Configuring vitual hosting in Apache Tomcat.</li> + Configuring vitual hosting in JBoss Web.</li> <li><a href="aio.html"><strong>Advanced IO</strong></a> - Extensions available over regular, blocking IO.</li> -<li><a href="extras.html"><strong>Additional Components</strong></a> - - Obtaining additional, optional components.</li> </ol> @@ -119,19 +113,19 @@ <section name="Reference"> <p>The following documents are aimed at <em>System Administrators</em> who -are responsible for installing, configuring, and operating a Apache Tomcat 6 server. +are responsible for installing, configuring, and operating a JBoss Web server. </p> <ul> <li><a href="RELEASE-NOTES.txt"><strong>Release notes</strong></a> - - Known issues in this Apache Tomcat release. + - Known issues in this JBoss Web release. </li> -<li><a href="config/index.html"><strong>Apache Tomcat Server Configuration Reference</strong></a> +<li><a href="config/index.html"><strong>JBoss Web Server Configuration Reference</strong></a> - Reference manual that documents all available elements and attributes - that may be placed into a Apache Tomcat 6 <code>conf/server.xml</code> file. + that may be placed into a JBoss Web <code>conf/server.xml</code> file. </li> <li><a href="http://tomcat.apache.org/connectors-doc/index.html">&l... Documentation</strong></a> - Complete documentation and HOWTOs on the JK native webserver connector, - used to interface Apache Tomcat with servers like Apache HTTPd, IIS + used to interface JBoss Web with servers like Apache HTTPd, IIS and others.</li> <li><a href="servletapi/index.html"><strong>Servlet API Javadocs</strong></a> - The Servlet 2.4 API Javadocs.</li> @@ -142,36 +136,30 @@ </section> -<section name="Apache Tomcat Developers"> +<section name="JBoss Web Developers"> <p>The following documents are for Java developers who wish to contribute to -the development of the <em>Apache Tomcat</em> project.</p> +the development of the <em>JBoss Web</em> project.</p> <ul> <li><a href="building.html"><strong>Building from Source</strong></a> - - Details the steps necessary to download Apache Tomcat 6 source code (and the + Details the steps necessary to download JBoss Web source code (and the other packages that it depends on), and build a binary distribution from those sources. </li> <li><a href="changelog.html"><strong>Changelog</strong></a> - Details the - changes made to Apache Tomcat. + changes made to JBoss Web. </li> -<li><a href="status.html"><strong>Status</strong></a> - Apache Tomcat development - status. - </li> -<li><a href="developers.html"><strong>Developers</strong></a> - List of active - Apache Tomcat contributors. - </li> <li><a href="catalina/funcspecs/index.html"><strong>Functional Specifications</strong></a> - Requirements specifications for features of the <em>Catalina</em> servlet - container portion of Apache Tomcat 6.</li> + container portion of JBoss Web.</li> <li><a href="catalina/docs/api/index.html"><strong>Catalina Javadocs</strong></a> - Javadoc API documentation for the <em>Catalina</em> servlet container and its dependencies.</li> <li><a href="jasper/docs/api/index.html"><strong>Jasper Javadocs</strong></a> - Javadoc API documentation for the <em>Jasper</em> JSP container - portion of Apache Tomcat 6.</li> -<li><a href="architecture/index.html"><strong>Apache Tomcat Architecture</strong></a> - - Documentation of the Apache Tomcat Server Architecture.</li> + portion of JBoss Web.</li> +<li><a href="architecture/index.html"><strong>JBoss Web Architecture</strong></a> + - Documentation of the JBoss Web Server Architecture.</li> </ul> Modified: trunk/webapps/docs/introduction.xml =================================================================== --- trunk/webapps/docs/introduction.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/introduction.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -19,7 +19,7 @@ <p>For administrators and web developers alike, there are some important bits of information you should familiarize yourself with before starting out. This document serves as a brief introduction to some of the concepts and -terminology behind the Tomcat container. As well, where to go when you need +terminology behind the JBoss Web container. As well, where to go when you need help.</p> </section> @@ -28,7 +28,7 @@ <section name="Terminology"> <p>In the course of reading these documents, you'll run across a number of -terms; some specific to Tomcat, and others defined by the +terms; some specific to JBoss Web, and others defined by the <a href="http://java.sun.com/products/servlet/">Servlet</a> or <a href="http://java.sun.com/products/jsp/">JSP</a> specifications.</p> @@ -45,12 +45,12 @@ <section name="Directories and Files"> <p>Throughout the docs, you'll notice there are numerous references to -<strong>$CATALINA_HOME</strong>. This represents the root of your Tomcat +<strong>$CATALINA_HOME</strong>. This represents the root of your JBoss Web installation. When we say, "This information can be found in your $CATALINA_HOME/README.txt file" we mean to look at the README.txt file at the -root of your Tomcat install.</p> +root of your JBoss Web install.</p> -<p>These are some of the key tomcat directories, all relative +<p>These are some of the key JBoss Web directories, all relative to <strong>$CATALINA_HOME</strong>:</p> <ul> @@ -69,7 +69,7 @@ </section> -<section name="Configuring Tomcat"> +<section name="Configuring JBoss Web"> <p>This section will acquaint you with the basic information used during the configuration of the container.</p> @@ -87,12 +87,8 @@ written and easy to understand, we may have missed something. Provided below are various web sites and mailing lists in case you get stuck.</p> -<p>As Tomcat 6 is a new release of Tomcat, keep in mind that some of the -issues and solutions vary between the major versions of Tomcat (4.x versus -5). As you search around the web, there will be some documentation that -is not relevant to Tomcat 6, but 3.x, 4.x and 5.x. Doing 3.x or 4.x things to 6 -will probably not work in most cases as the server.xml files are very -different.</p> +<p>As JBoss Web 2.1 changes things over past Tomcat releases, keep in mind that some of the +issues and solutions vary between the major versions of Tomcat (4.x, 5.x and 6.x).</p> <ul> <li>Current document - most documents will list potential hangups. Be sure Modified: trunk/webapps/docs/jasper-howto.xml =================================================================== --- trunk/webapps/docs/jasper-howto.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/jasper-howto.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -26,7 +26,7 @@ <section name="Introduction"> -<p>Tomcat 6.0 uses the Jasper 2 JSP Engine to implement +<p>JBoss Web uses the Jasper 2 JSP Engine to implement the <a href="http://java.sun.com/products/jsp/">JavaServer Pages 2.0</a> specification.</p> @@ -63,7 +63,7 @@ <p>By default Jasper is configured for use when doing web application development. See the section <a href="#Production Configuration"> Production Configuration</a> for information on configuring Jasper -for use on a production Tomcat server.</p> +for use on a production JBoss Web server.</p> <p>The servlet which implements Jasper is configured using init parameters in your global <code>$CATALINA_BASE/conf/web.xml</code>. @@ -87,7 +87,7 @@ <li><strong>classpath</strong> - Defines the class path to be used to compile the generated servlets. This parameter only has an effect if the ServletContext attribute org.apache.jasper.Constants.SERVLET_CLASSPATH is not set. This -attribute is always set when Jasper is used within Tomcat. By default the +attribute is always set when Jasper is used within JBoss Web. By default the classpath is created dynamically based on the current web application.</li> <li><strong>compilerSourceVM</strong> - What JDK version are the source files compatible with? (Default JDK 1.4)</li> @@ -112,7 +112,7 @@ <code>clsid:8AD9C840-044E-11D1-B3E9-00805F499D93</code>.</li> <li><strong>fork</strong> - Have Ant fork JSP page compiles so they are -performed in a seperate JVM from Tomcat? <code>true</code> or +performed in a seperate JVM from JBoss Web ? <code>true</code> or <code>false</code>, default <code>true</code>.</li> <li><strong>javaEncoding</strong> - Java file encoding to use for generating @@ -147,12 +147,12 @@ </p> <p>The Java compiler from Eclipse JDT in included as the default compiler. It is an -advanced Java compiler which will load all dependencies from the Tomcat class loader, +advanced Java compiler which will load all dependencies from the Jboss Web class loader, which will help tremendously when compiling on large installations with tens of JARs. On fast servers, this will allow sub-second recompilation cycles for even large JSP pages.</p> -<p>Apache Ant, which was used in previous Tomcat releases, can be used instead instead of +<p>Apache Ant can be used instead instead of the new compiler by simply removing the <code>lib/jasper-jdt.jar</code> file, and placing the <code>ant.jar</code> file from the latest Ant distribution in the <code>lib</code> folder. If you do this, you also need to use the "javac" @@ -166,7 +166,7 @@ this might not be possible (for example, when using the jsp-property-group feature) or practical, in which case the configuration of the Jasper servlet becomes critical.</p> -<p>When using Jasper 2 in a production Tomcat server you should consider +<p>When using Jasper 2 in a production JBoss Web server you should consider making the following changes from the default configuration. <ul> <li><strong>development</strong> - To disable on access checks for JSP @@ -251,7 +251,7 @@ <p> The following command line can be used to run the script -(replacing the tokens with the Tomcat base path and the path to the webapp +(replacing the tokens with the JBoss Web base path and the path to the webapp which should be precompiled):<br/> <source> $ANT_HOME/bin/ant -Dtomcat.home=&lt;$TOMCAT_HOME&gt; -Dwebapp.path=&lt;$WEBAPP_PATH&gt; @@ -267,8 +267,7 @@ running fine with precompiled servlets. An appropriate token placed in the web application deployment descriptor may also be used to automatically insert the generated servlet declarations and mappings using Ant filtering -capabilities. This is actually how all the webapps distributed with Tomcat -are automatically compiled as part of the build process. +capabilities. </p> <p> @@ -291,7 +290,7 @@ <p><strong>Hints:</strong> <ul> -<li> When you switch to another tomcat release, then regenerate and recompile +<li> When you switch to another JBoss Web or Tomcat release, then regenerate and recompile your jsp's with this version again!</li> <li>Use java system property at server runtime to disable tag pooling <code>org.apache.jasper.runtime.JspFactoryImpl.USE_POOL=false</code>. and limit the buffering with <code>org.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true</code>. Note that changing @@ -314,7 +313,7 @@ for <code>-encoding</code>.</li> <li>Set the init parameter <code>compiler</code> to <code>jikes</code>.</li> <li>Define the property <code>-Dbuild.compiler.emacs=true</code> when starting -Tomcat by adding it to your <code>CATALINA_OPTS</code> environment variable. +JBoss Web by adding it to your <code>CATALINA_OPTS</code> environment variable. This changes how jikes outputs error messages so that it is compatible with Jasper.</li> <li>If you get an error reporting that jikes can't use UTF8 encoding, try Modified: trunk/webapps/docs/legal.xml =================================================================== --- trunk/webapps/docs/legal.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/legal.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -12,8 +12,6 @@ <p>JBossWeb is released under the LGPL License.</p> <br/> - - <subsection name="GNU Lesser General Public License"> <p class="releaseinfo">This is the first released version of the Lesser GPL. It also counts as the successor of Modified: trunk/webapps/docs/project.xml =================================================================== --- trunk/webapps/docs/project.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/project.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -39,7 +39,6 @@ <item name="MBean Descriptor" href="mbeans-descriptor-howto.html"/> <item name="Default Servlet" href="default-servlet.html"/> - <item name="Load Balancer" href="balancer-howto.html"/> <item name="Connectors" href="connectors.html"/> <item name="Monitoring and Management" href="monitoring.html"/> @@ -47,7 +46,6 @@ <item name="APR" href="apr.html"/> <item name="Virtual Hosting" href="virtual-hosting-howto.html"/> <item name="Advanced IO" href="aio.html"/> - <item name="Additional Components" href="extras.html"/> </menu> <menu name="Reference"> Deleted: trunk/webapps/docs/status.xml =================================================================== --- trunk/webapps/docs/status.xml 2007-09-04 17:46:10 UTC (rev 262) +++ trunk/webapps/docs/status.xml 2007-09-04 23:06:49 UTC (rev 263) @@ -1,123 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE document [ - <!ENTITY project SYSTEM "project.xml"> -]> -<document url="status.html"> - - &project; - - <properties> - <author email=&quot;remm(a)apache.org&quot;&gt;Remy Maucherat</author> - <author email=&quot;yoavs(a)apache.org&quot;&gt;Yoav Shapira</author> - <title>Project Status</title> - </properties> - -<body> - <section name="Preface"> - <p> - This document attempts to convey the current status of Tomcat development - in "big picture" terms. This is not the place to check if an individual - bug report has been addressed or when an individual feature will be available. - </p> - <p> - This page is updated roughly once per every couple of Tomcat minor releases, - so for day-to-day status you should check the tomcat-user and tomcat-dev mailing - lists. You can always inquire there as to the availability or status of a - specific feature or component. - </p> - </section> - - <section name="Current Status Summary"> - <p> - <b>Tomcat 5.0.27</b> was released on June 17th, 2004. At that time, the TOMCAT_5_0 - branch was tagged in CVS, and work on Tomcat 5.5 began. We have now had several - Tomcat 5.5 releases, including a couple of stable ones. Accordingly, Tomcat 5.5 - is now the focus on work. Tomcat 5.0 is in maintenance mode and its releases - will become less and less frequent. - </p> - <p> - <b>Tomcat 5.5</b> has several major goals. They are discussed in the tomcat-dev - mailing list's "5.next" thread: - <a href="http://marc.theaimsgroup.com/?l=tomcat-dev&amp;w=2&amp...;. - The status of some of these items is detailed below. Once 5.5 releases are - available, please refer to the Changelog accompanying each release for detailed - changes, enhancements, and fixes. - </p> - <p> - <b>Tomcat 4.1.x</b> is no longer actively developed. It is maintained to address - only showstopper, security, and Servlet Specification compliance issues. Maintenance - for Tomcat 4.1.x will likely cease once a stable release or two of Tomcat 5.5 are out. - Users of Tomcat 4.1.x are strongly encouraged to upgrade to the latest stable Tomcat - 5.0 release. - </p> - <p> - <b>Tomcat 4.0.x</b> is relatively old, and not actively maintained or supported. - It is strongly recommended that users of these releases upgrade to the latest - stable Tomcat 5.0 release or at least the latest stable Tomcat 4.1 release. - </p> - <p> - <b>Tomcat 3.3.x</b> is in roughly the same maintenance mode as Tomcat 4.1.x. - </p> - <p> - <b>Tomcat 3.2</b> and earlier are in roughly the same support state as Tomcat 4.0.x. - Users should upgrade to Tomcat 3.3.x or the latest stable Tomcat 5.0.x. - </p> - </section> - - <section name="How to read the report"> - - <p> - The columns in this report contain the following information: - <ul> - <li><b>Priority</b> - A sense of how important it is to address this - issue in the short term.</li> - <li><b>Action Item</b> - Concise description of the action item - to be completed. Where relevant, Java package names of the - primary classes involved are listed in [square brackets]</li> - <li><b>Volunteers</b> - Login of those developers who - have volunteered to assist in the design, implementation, testing, and - documentation of this action item's changes to Tomcat.</li> - </ul> - Developers can nominate - themselves to work on particular action items by asking a Committer to - add their name address to those items. The developers - working on each item should discuss and agree upon the approach to be - used for implementing the item's changes to the project source code - and documentation, prior to completing those changes. Such discussions - should take place on the tomcat-dev mailing list so that everyone can - stay apprised of what is going on, or chime in if they want to - contribute ideas and suggestions. - </p> - - </section> - - <section name="TODO List"> - - <status> - <item priority="High" owner="costin"> - Refactor ClassLoaders for Tomcat 5.5 to allow container plugins. - </item> - <item priority="Medium" owner="fhanik"> - Enhance Cluster functionality for Tomcat 5.5. - </item> - <item priority="Medium" owner="everyone"> - Continue fixing bugs and updating docs. - </item> - </status> - - </section> - - <section name="Open bugs"> - - <p> - The list of the bugs which are in an unresolved state for Tomcat 5 can be - seen - <a href="http://issues.apache.org/bugzilla/buglist.cgi?bug_status=UNCON...;. - Aspiring volunteers and others are strongly encouraged to attempt - to comment and help resolve these issues. - </p> - - </section> - -</body> -</document>