The Jakarta Project

Tomcat - A Minimalistic User's Guide

This document provides some basic information about Tomcat. Some of the topics covered here are:
  1. Tomcatバイナリー・バージョンのインストール
  2. Tomcatを用いるscriptに関する主な問題点
  3. sever.xml、Tomcatの主な構成ファイルに関する主な問題点
  4. 本来のWeb Serverを対象とするTomcatのセットアップの仕方の説明
  5. 現実のWeb SiteでTomcatを配置につかせる方法の説明
希望に満ちて，これは，Tomcatを始めるどんな新しいユーザーにも十分で・るべきだ。もし何かがミスしていればその時、以下のことを試みよ。:
  1. Tomcat faq を検索すること.
  2. Tomcat のリストアーカイブを検索すること
  3. Tomcatユーザー・メーリング・リストに質問を郵送すること
もしそれらがまだ存在しなければ、すべてのユーザーがTomcatのよく・る質問およびこのドキュメント、またはその一方の質問に答えることを、私達は奨励する。　もし・なたがこのドキュメントについて、何かコメントや案が・ればTomcatメーリング・リストにそれらを送るのをためらわないでほしい。

入門

TomcatはJSP環境をもつservlet containerで・る。servlet containerは、ユーザーに代わってservletを処理したり起動したりする、runtime shellで・る。

・なたはservlet containerを、以下のように分割する事ができる。:

  1. Stand-alone servlet containers

    2. これらは，欠くことができないWebServerの一部分で・る。例えばJava WebServerの一部分で・るservlet containerをJavaを使うWebServerの基本とするケースで・る。スタンドアローンは、Tomcatによって使われたデフォルト・モードで・る。
    しかしながら、ほとんどのWebServerはjavaを基本としない。そしてそれは、私達を次の2つのタイプのcontainerに導く。
  2. In-process servlet containers

    3. servlet containerは、WebServerプラグインとJava容器実装の組み合わせで・る。WebServerプラグインは、WebServerのアドレス空間の中にJVMをオープンして、Java containeに走らせる。 もし・るリクエストがServletを実行すべきなら、プラグインは，管理にリクエストを案内して、( JNIを使って)Java containerにそれをパスする。 インプロセスcontainerの中は、マルチスレッドの単一のプロセスサーバーにとって適当で・って、良いパフォーマンスだが、拡張性に制限している。
  3. Out-of-process servlet containers

    4. servlet containerは、ウェブ・サーバーの外でJVMで走るウェブ・サーバー・プラグインとジャバ容器実装の組み合わせで・る。ウェブ・サーバー・プラグイン、およびJAVA container JVMは、使用している、・るIPC機構(通常TCP/IPソケット)を伝える。 もし・るリクエストがServletを実行すべきなら、プラグインは、管理にリクエストを案内して、それ( 使用しているIPC)をJava containerに渡す。プロセスからのエンジンで・るレスポンスタイムは一つのプロセスの中では良くないが、そのプロセスからのエンジンは、多くの適度な方法(拡張性、安定、etc)でよりよく実行する。
Tomcatは、スタンドアローンcontainer(主として開発、およびデバッギングのためで・る)または、生存するウェブ・サーバー(現在アパッチ、IIS、およびネットスケープ、サーバーがサポートされる)への付属装置として、どちらか一方を使うことができる。 ということは、Tomcatを配置につかせているときにはいつもそれを使う方法を決める必要が・るだろう、そして、もし・なたがオプション２・るいは３を選べばまた、ウェブ・サーバー・アダプターをインストールする必要が・るだろう。

TomcatとJservとの違いは何か?　TomcatはJservではないか?

これは一般的な誤解で・る。Jservは、アパッチで使われるために作り出されたServlet API２.０準拠のcontainerで・る。Tomcatは完成した書き換えで・り、Servlet API２.２、およびJSP１.１準拠のcontainerで・る。

Tomcatは、Jservに書かれているいくつかのコードを使う。特に、 JservのApache server アダプターで・る。しかし、これは類似の最後のときで・る。

どのようにして、Tomcatのバイナリーバージョンをインストールするのか？

とてもシンプルで・る。以下のことをすべきだ: それですべてだ。・なたは今、Tomcatを実行することができ、それは、スタンドアローン(型１)として servlet containerを実行するだろう。

Tomcatの開始と中止

binディレクトリの中のスクリプトを利用したTomcatを開始して中止する。

Tomcatを開始するために実行すること:

UNIXでは: bin/startup.sh

Win32では: bin\startup

Tomcatを中止するために実行すること:
UNIXでは: bin/shutdown.sh

Win32では: bin\shutdown

The Tomcat directory structure

Tomcatバイナリー・ディストリビューションをunzipped/untaredすることを仮定して・なたは、以下のディレクトリー・ストラクチャーを知っているべきで・る:
 
ディレクトリー名 記述
bin  startup/shutdown... などのスクリプトを含む
conf  server.xml (Tomcatの主な構成ファイル)を含むいろいろな構成ファイル、 および、Tomcatで配置につかされたいろいろなウェブ・アプリケーションのためにデフォルト値をセットするweb.xmlを含む
doc  Tomcatに関連して種々のドキュメントを含む。
lib  Tomcatによって使われるいろいろなjarファイルを含む。UNIXで、このディレクトリーのいくつかのファイルは、Tomcatのclasspathにアペンドされる。
logs  これは、Tomcatを置く場所がログ・ファイルだということだ。
src  servlet APIsのソースファイルで・る。たとえ感情を刺激されなくても、これらが唯一どんなservlet containerによっても実行される、空のインターフェース、および抽象的なクラスで・る。
webapps  ウェブ・アプリケーションのサンプルを含む。

さらに、・なたができる、またはTomcatがすることは、以下のディレクトリーを作り出すことで・る:
 
work  Tomcatによって自動的に生成させられる、これは、Tomcatがそれの間に中間ファイルを置く(例えばJSPファイルをコンパイルする)場所がworkだということで・る。もしTomcatが実行している間に、このディレクトリーを削除すれば、・なたは、JSPページを実行することができないだろう。
classes  classpathに追加のクラスを加えるために、このディレクトリーを作り出すことができる。このディレクトリーを付け加えるどんなクラスも、Tomcatのclasspathの場所を見つけるだろう。

Tomcatスクリプト

Tomcatはjavaプログラムです。そしていくつかの環境変数をセットした後でコマンドラインから実行することにより可能です。しかしそれぞれの環境変数をセットしてコマンドラインパラメータからTomcatをすることは誤りを生じやすい。かわりにTomcat開発チームはTomcatを始動・停止を容易にするために少しのスクリプトを与えます。

注：スクリプトは単に始動／停止の簡単な方法です。正しいコマンドラインが Tomcatのために発生される限り・なたは PATH と LD＿LIBRARY＿PATH，etc...といったCLASSPATH、環境変数をカストマイズするためにそれらを改変できます。

これらのスクリプトは何ですか？以下のテーブルは最も一般的なユーザーにとって重要なスクリプトを与えます。:
 
スクリプト名 記述
tomcat  主なスクリプト。適切なコマンドラインパラメータCLASSPATH、TOMCAT_HOME、JAVA_HOMEおよびTomcat始動を含んで適切な環境をセットします。
startup  背景のTomcat始動。”Tomcat始動”のためのショートカット
shutdown  Tomcat停止。”Tomcat停止”のためのショートカット

ユーザーのための最大の意義をもっているスクリプトはtomcat.sh/tomcat.batです。その他のTomcatに関するスクリプトはTomcatスクリプトへの簡単にされた一つのタスク指向の入口として供給します。（異なるコマンドラインパラメータにその他をセットします。）

tomcat.sh/tomcat.batによりそれが以下の活動をすることを生み出します:
 
オペレーティングシステム 活動
Unix 
  • もしそれが明示されなければ何がTOMCAT_HOMEかを見当をつけます。 
  • もしそれが明示されなければ何がJAVA_HOMEかを見当をつけます。 
  • それを含むCALSSPATHをセットアップすることで - 
    1. ＄{TOMCAT_HOME}/classにディレクトリを分類します。（利用できれば）
    2. すべてのコンテンツ＄{TOMCAT_HOME}/lib
    3. ＄{JAVA_HOME｝/lib/tools.jar（jarファイルはjavacツールを含みjspファイルのためのjavacを必要とします。）
  • スタートアップクラスとしてorg.apache.tomcat.startupが・りtomcat.homeと呼ばれるjavaシステム環境をセットアップしたコマンドラインパラメーラでjavaを実行します。 またコマンドラインパラメータをorg.apache.tomcat.startupに渡します。例えば: 
    1. start/stop/run/etcを実行するオペレーション 
    2. server.xmlはこのtomcatプロセスによって使いました
    例えばserver.xmlが/etc/server_1.xml及びユーザーに位置するかはそれらが以下のコマンドラインを提供すべきApacheの開始次第です。:bin/tomcat.sh start -f /etc/server_1.xml
Win32 
  • それを含むCLASSPATHをセットアップすることで - 
    1. %TOMCAT_HOME%/libディレクトリからserver.jar、webserver.jar、jasper.jarxml.jarservlet.jar, webserver.jar, jasper.jar, xml.jar from the %TOMCAT_HOME%\lib directory,
    2. %TOMCAT_HOME%\classes (存在しません),
    3. %JAVA_HOME%\lib\tools.jar (このjarファイルはツールjavacを含みjspファイルのためにjavacが必要です).
  • org.apache.tomcat.startupがスタートアップクラスとしての機能でそれがtomcat.homeと呼ばれる（javaシステム環境をセットアップしたコマンドラインパラメータをもつ）PATHに・ることを仮定してjavaを実行します。それはまたコマンドラインパラメータを org.apache.tomcat.startup に渡します。例えば: 
    1. start/stop/run/etcを実行するオペレーション。 
    2. server.xmlはこのtomcatプロセスによって使いました。
    例えばserver.xmlがconf/server_1.xmlおよびユーザーに位置するかはそれらが以下のコマンドラインを提供すべきApacheの開始次第です。:bin\tomcat.bar start -f conf\server_1.xml

見ることができますtomcat.barのWIN32バージョンがUNIXの一つとして比べられます。特にそれはTOMCAT_HOMEおよびJAVA_HOMEの価値またすべてのjarファイルをCLASSPATHに運ばないと見当がつかない。

Tomcat's Configuration Files

Tomcatの構成は以下の2点から成り立っている:
     
  1. server.xml - Tomcatの一般的なファイル
  2. web.xml - Tomcat内における様々な前後関係の構成
このセクションではこれらのファイルの使用法を扱う。 web.xmlに関してはServlet APIs specと関連が・るためここでは扱わないが、server.xmlの内容からTomcatの前後関係におけるweb.xmlの使用を説明していく。

server.xml

server.xmlはTomcatの中心となる構成ファイルで・り、以下の2点が挙げられる:
     
  1. Tomcatに対する初期構成要素を定義している。
  2. Tomcatの意義や起動方法等の構造を具体的に挙げ、特にserver.xmlの構成要素を例に挙げながら構築する。
server.xmlの重要な構成要素は次の表で述べられている:
 
Element  Description 
Server  server.xmlファイル内で最上の構成要素で・り、ServerはTomcatサーバー単体を定義する。注意する点はそれほどなく、Server構成要素はLoggerやContextManagerに含まれる。
Logger  loggerオブジェクトを定義し、各loggerはlogger outputやverbosityLevelを含むlogファイルパスのような識別名をもつ。一般にサーブレットやJSPファイル、Tomcatのランタイム用のlogger。
ContextManager  ContextManagerはその構成とContextInterceptors、RequestInterceptors、ContextやConnectorの組み合わせ構造を具体的に挙げている。ContextManagerはいくつかの属性をもつ。: 
  1. デバッグレベルはデバッグメッセージを得る用途に用いる。
  2. webapps/,conf/,logs/やその他の場所はcontextで定義される。TOMCAT_HOME以外のディレクトリからTomcatを起動するときに使用。
  3. ワークディレクトリ名を用いる。
ContextInterceptor & RequestInterceptor  これらのinterceptorはContextManager内で起きたイベントを調べる。例としてContextInterceptorはTomcatのstartupやshutdownイベントを聞き、RequestInterceptorはユーザーがどのサービスへの通過要求段階にいるかを見る。Tomcatの管理者はinterceptorについて深く知る必要はないが、開発者はセキュリティやログ要求指示面でいかに重要で・るかしっておく必要が・る。
Connector  Connectorはwebサーバー、またはディレクトリのどちらかからユーザーのwebへの接続を伝える。ConnectorオブジェクトはTomcatでよく使うスレッドの管理や様々なクライアントからの接続要求/応答の入出力に関して重要で・る。Connectorの構成要素には以下のものが・る。: 
  1. handlerクラス
  2. handlerの問合せ対象はTCP/IPポートで・る。 
  3. TCP/IPのバックログはhandler server socketのために・る。
Connectorの構成については後述する。
Context  ContextはwebアプリケーションがTomcatのどの階層に・るかを指示する。TomcatのContextは次のような構成が・る。: 
  1. Contextが・る場所がパスになり、フルパスかContextManager'homeと関係・るものになる。
  2. デバッグレベルはデバッグメッセージを得る用途に用いる。
  3. reloadable flagが・り、Tomcatが再実行に便利なservletを開発する際バグを修正し、再起動なしで新しいコードによるTomcatのテストを実行できる。reloadable flagをtrueにすると、エラー発生後新しいクラスで実行時の時間消費がどれくらいかがわかる。問題を避けるためreloadable flagをfalseにセットした場合、autoreloadが機能しなくなる。

Starting Tomcat From Another Directory

デフォルトでの構成はTOMCAT_HOME/conf/server.xmlを使い、デフォルト構成はcontextをベースにTOMCAT_HOMEを使う。

異なるservlet構成ファイルや ContextManagerの設定をセットする際、"-f/path/to/server.xml"オプションで変更できるが、home内に必要なファイルをセットアップしなければならない。:

もしserver.xml内のContextManager.homeの設定が関係していれば、カレントワークディレクトリと関係が・るだろう。

web.xml

web.xmlの詳細やwebアプリケーション構造はServlet API Spec内の9,10,14章で入手できるのでここでは述べない。

Tomcatの機能はweb.xmlと少なからずとも関係している。Tomcatはconfディレクトリ内にデフォルトweb.xmlファイルをおくことによってcontext用の値をデフォルトweb.xmlに定義させる。新しいcontextを構成した際、Tomcatは基本構成として、特にweb.xmlのアプリケーションとしてデフォルトの更新だけにデフォルトweb.xmlを使う。

Setting Tomcat to Cooperate with the Apache Web Server

Up until now we have not discussed Tomcat as a server add on, instead we have considered it as a stand-alone container and discussed how it can be used. There are however a few problems with this picture:
     
  1. Tomcat is not as fast as Apache when it comes to static pages.
  2. Tomcat is not as configurable as Apache.
  3. Tomcat is not as robust as Apache.
  4. There are many sites with long time investment in certain web servers, for example, sites that are using CGI scripts/Server API modules/perl/php... We cannot assume that all of them will want to ditch this legacy.
For all these reasons it is recommended that real world sites use a web server, such as Apache, for serving the static content of the site, and use Tomcat as a Servlet/JSP add-on.

We are not going to cover the different configuration in depth, instead we will:

  1. Cover the fundamental behavior of the web server.
  2. Explain what configuration is needed.
  3. Demonstrate this on Apache.

Web Server Operation

In a nutshell a web server is waiting for client HTTP requests. When these requests arrive the server does whatever is needed to serve the requests by providing the necessary content. Adding a servlet container may somewhat change this behavior. Now the web server needs also to perform the following: The adapter on the other hand needs to know what requests it is going to serve, usually based on some pattern in the request URL, and to where to direct these requests.

Things are even more complex when the user wants to set a configuration that uses virtual hosts, or when they want multiple developers to work on the same web server but on different servlet container JVMs. We will cover these two cases in the advanced sections.

What is the Needed Configuration

The most obvious configuration that one can think of is the identity of the servlet URLs that are under the responsibility of the servlet container. This is clear; someone must know what requests to transmit to the servlet container... Yet there are additional configuration items that we should provide to the web-server/servlet-container combination: All this information must appear either in the web server configuration, or in a private configuration files used by the adapter. The next section will demonstrate how configuration can be implemented on Apache.

Making it on Apache

This section shows you how to configure Apache to work with Tomcat; it tries to provide explanations as well as insight for the configuration directives that you should use. You can find additional information in the jserv install page .

When Tomcat starts up it will automatically generate a configuration file for Apache in TOMCAT_HOME/conf/tomcat-apache.conf. Most of the time you don't need to do anything but include this file (appending "Include TOMCAT_HOME/conf/tomcat-apache.conf") in your httpd.conf. If you have special needs, for example an AJP port other the 8007, you can use this file as a base for your customized configuration and save the results in another file. If you manage the Apache configuration yourself you'll need to update it whenever you add a new context.

Tomcat 3.1: you must restart tomcat and apache after adding a new context; Apache doesn't support configuration changes without a restart. Also the file TOMCAT_HOME/conf/tomcat-apache.conf is generated when tomcat starts, so you'll need to start Tomcat before Apache. Tomcat will overwrite TOMCAT_HOME/conf/tomcat-apache.conf each startup so customized configuration should be kept elsewhere.

The Apache-Tomcat configuration uses Apache core configuration directives as well as Jserv unique directives so it may confuse you at first, there are however two things simplifying it:

Lets look now at a sample tomcat.conf file.
A Minimalistic Apache-Tomcat Configuration  
    
###########################################################
#      A minimalistic Apache-Tomcat Configuration File    #
###########################################################

# Note: this file should be appended or included into your httpd.conf

# (1) Loading the jserv module that serves as Tomcat's apache adapter.
LoadModule jserv_module libexec/mod_jserv.so

# (1a) Module dependent configuration.
<IfModule mod_jserv.c>

# (2) Meaning, Apache will not try to start Tomcat.
ApJServManual on
# (2a) Meaning, secure communication is off
ApJServSecretKey DISABLED
# (2b) Meaning, when virtual hosts are used, copy the mount
# points from the base server
ApJServMountCopy on
# (2c) Log level for the jserv module.
ApJServLogLevel notice

# (3) Meaning, the default communication protocol is ajpv12
ApJServDefaultProtocol ajpv12
# (3a) Default location for the Tomcat connectors.
# Located on the same host and on port 8007
ApJServDefaultHost localhost
ApJServDefaultPort 8007

# (4)
ApJServMount /examples /root
# Full URL mount
# ApJServMount /examples ajpv12://hostname:port/root
</IfModule>
            

As you can see the configuration process was split into 4 steps that will now be explained:

  1. In this step we instruct Apache to load the jserv shared-object (or the NT world dll). This is a well known Apache directive. If the loading went well and the module came from a file named mod_jserv.c (1a) we can start with the rest of the Jserv-Tomcat configuration.
  2. This step sets various Jserv internal parameters, these parameters:
  3. This step sets the default communication parameters. Basically it says that the default protocol used for the communication is ajpv12 (do not mess with this one) and that the Tomcat process runs on the same machine and listens on port 8007. If you run Tomcat on a machine other than the one used for Apache you should either update your ApJServDefaultHost or use a full URL when mounting contexts (see next). Also, if you configured the Tomcat connectors to use a port other then 8007, you should update your ApJServDefaultPort or use a full URL when mounting contexts.
  4. This step mounts a context to Tomcat. Basically it says that all the web server paths that start with /examples go to Tomcat. This ApJServMount example is a rather simple one, in fact ApJServMount can also provide information regarding the communication protocol to be used and the location where the Tomcat process listens, for example:

    5. ApJServMount /examples ajpv12://hostname:port/rootmounts the context /examples to a Tomcat process that runs on host "hostname" and listens on port number "port".
Now that you understand the different configuration instructions in the sample file, how can you add it to the Apache configuration? One "simple" method is to write it's content in the httpd.conf (the Apache configuration file), this however can be very messy. Instead you should use the Apache include directive. At the end of the Apache configuration file (httpd.conf) add the following directive:include <full path to the Tomcat configuration file>for example:include /tome/tomcat/conf/tomcat.confThis will add your Tomcat configuration to Apache, after that you should copy the jserv module to the Apache libexec (or modules in the Win32 case) directory and restart (stop+start) Apache. It should now be able to connect to Tomcat.

Jserv Moduleの取得方法(mod_jserv)

以前述べているように、Apacheの代理をし、Tomcatにリクエストをリダイレクトするにはwebサーバーアダプターが必要です。Apacheでは、このアダプターはmod_jservのバージョンで少し変更されています。

・なたのOSに・ったmod_Jservの前バージョンをすでに持っている方は（NTだけでは・りません。）、この ＵＲＬを参照してください。, however, being a native library you should not expect that yet (開発が十分でない、、期間はとても短い　たくさんのOSが・る). おまけに、・なたが構築したApache / 特殊な別のUNIXでの　小さな違いは、動的リンクエラーを起こすかもしれません。・なたのシステムにmod_jservの構築をすべきです。（それはむつかしく・りませんので、パニックになる必要は・りません。）

UNIX上に mod_jservを構築するには以下のように行います。:

     
  1. ここから、Tomcatのソースをダウンロードする。
  2. 任意のディレクトリに解凍する。
  3. モジュールの構築方法:
Win32のmod_jservの構築は、（Win32用のdllをダウンロードしておいてください。）構築するためには、Visual C++をインストールし、次のことを実行する必要が・る。
  1. ここから、Tomcatのソースをダウンロードする。.
  2. 任意のディレクトリに解凍する。
  3. モジュールの構築方法:
これで、mod_jservを構築できました。

Making Apache Serve your Context's Static Files

前述したApache-Tomcatコンフィグレーションファイルは、リソースを開始するのに、Tomcatによって提供される URLに /examples をつけて Apacheにリクエスト送信をさせるには いくぶん非能率的だ。そんなことを本当にしたいですか？ servletコンテキストにたくさんの静的ファイルが・るかもれない。（たとえばイメージや静的HTMLファイル）TomcatはこれらのファイルをThere are many static files that may be a part of our servlet context (for example images and static HTML), why should Tomcat serve these files?

たとえば、以下のようなことをするのに理由が・る。:

     
  1. リソースをTomcatベースのセキュリティを構成したいかもしれない。
  2. 静的なリソースへのユーザー要求を追跡したいかもしれない。
一般的に、これはそのケースではないが、Tomcatに静的ファイルを保管することは、CPUの浪費です。かわりに、静的ファイルの提供をTomcatではなくApacheにさせます。 以下の　tomcat.conf　ファイルのサンプルを参照してください。

以下のような、静的ファイルの要求ををApacheが処理しています。:

     
  1. ApacheはすべてのサーブレットのリクエストをTomcatに送信するよう指示。
  2. ApacheはすべてのJSPのリクエストをTomcatに送信するよう指示
そのほかをApacheがハンドルします。以下の　tomcat.conf　ファイルのサンプルを参照してください。
Apache-Tomcat Configuration where Apache Serves the Static Content 
    
######################################################################
#              Apache-Tomcat Smart Context Redirection               #
######################################################################
LoadModule jserv_module modules/ApacheModuleJServ.dll
<IfModule mod_jserv.c>
ApJServManual on
ApJServDefaultProtocol ajpv12
ApJServSecretKey DISABLED
ApJServMountCopy on
ApJServLogLevel notice

ApJServDefaultHost localhost
ApJServDefaultPort 8007

#
# Mounting a single smart context:
#
# (1) Make Apache know about the context location.
Alias /examples D:\tomcat\webapps\examples
# (2) Optional, customize Apache context service.
<Directory "D:\tomcat\webapps\examples">
    Options Indexes FollowSymLinks
# (2a) No directory indexing for the context root.
#    Options -Indexes
# (2b) Set index.jsp to be the directory index file.
#    DirectoryIndex index.jsp
</Directory>
# (3) Protect the WEB-INF directory from tampering.
<Location /examples/WEB-INF/>
    AllowOverride None
    deny from all
</Location>
# (4) Instructing Apache to send all the .jsp files under the context to the 
# jserv servlet handler. 
<LocationMatch /examples/*.jsp>
    SetHandler jserv-servlet
</LocationMatch>
# (5) Direct known servlet URLs to Tomcat.
ApJServMount /examples/servlet /examples

# (6) Optional, direct servlet only contexts to Tomcat.
ApJServMount /servlet /ROOT
</IfModule>
      

わかるように、このコンフィギュレーションファイルの先頭は以前の例と同じです。しかし最後のステップ（コンテキストをマウントしている部分）は、ApacheとAjpのコンフィギュレーション指示の長いシリーズの中で置き換えられました。下記に説明します。:

     
  1. このステップは、Apacheにコンテキストロケーションと、Apacheの仮想ディレクトリのエイリアスを設定する。これで、Apacheはこのディレクトリからファイルを処理できる。
  2. このオプションのステップは、コンテキストを処理する別の方法をApacheに設定する。たとえば、ディレクトリインデックス(リスト)や、特別なインデックスファイルをセットすれば、Apacheはそこからコンテキストを処理するようにできる。
  3. このステップは、クライアントアクセスから　WEB-INFディレクトリを保護するよう設定する。セキュリティの理由として、WEB-INFのコンテンツを訪問者から見えないようにすることは重要だ。たとえば、web.xmlファイルは　侵入者に大切なインフォメーションを提供することができる。このステップは訪問者からWEB-INFのコンテンツを訪問者から防ぐことができる。
  4. このステップは、jservサーブレットハンドラーを使用したコンテンツを含むすべてのjspの場所をApacheに設定する。サーブレットハンドラーはそれらの要求をデフォルトホストとポートにリダイレクトする。
  5. このステップは、Tomcatに特定のサーブレットURLのマウントを設定する。特定のサーブレットURLの数と同じだけのマウント設定を記述すべきです。
  6. この最後のステップは、Tomcatに唯一のコンテキストを追加するために行う設定です。
このように　この構成は、最初の例より、より複雑でエラーが発生しやすいことがわかる。しかし、パフォーマンスを向上させたいのならば（さし・たり）しなくてはならないことだ。

複数のTomcat JVMの構成

時々、異なるJVMによって異なるコンテキストを扱いたいときが・る。たとえば: 異なるコンテキストを異なるJVM上で処理させることを計画し実行することは、とても簡単です。以下の構成ファイルはその例です。:
 
1つのコンテキストJVMのApache-Tomcat構成  
    
######################################################################
#             Apache-Tomcat with JVM per Context                     #
######################################################################
LoadModule jserv_module modules/ApacheModuleJServ.dll
<IfModule mod_jserv.c>
ApJServManual on
ApJServDefaultProtocol ajpv12
ApJServSecretKey DISABLED
ApJServMountCopy on
ApJServLogLevel notice

ApJServDefaultHost localhost
ApJServDefaultPort 8007

# Mounting the first context.
ApJServMount /joe ajpv12://joe.corp.com:8007/joe

# Mounting the second context.
ApJServMount /bill ajpv12://bill.corp.com:8007/bill
</IfModule>
            

前述の例からわかるように、異なったJVMを使用し、(異なるマシン上で実行するものでさえ）完全なAjp URLマウントを使うことによって簡単に実行することができる。この完全なURLは、Tomcatプロセスがロケートされているポートの本当の特定のホストです。

同じマシン上に２つのTomcatプロセスが稼動している場合は、異なった接続ポートを使用することでそれぞれの構成をすることができる。たとえば、ローカルホスト上で２つのJVMが稼動できるようなApache-Tomcatの構成は以下のようにします。:
 
同じマシン上に複数のJVMのApach-Tomcat構成 
    
######################################################################
#      Apache-Tomcat with Same Machine JVM per Context               #
######################################################################
LoadModule jserv_module modules/ApacheModuleJServ.dll
<IfModule mod_jserv.c>
ApJServManual on
ApJServDefaultProtocol ajpv12
ApJServSecretKey DISABLED
ApJServMountCopy on
ApJServLogLevel notice

ApJServDefaultHost localhost
ApJServDefaultPort 8007

# Mounting the first context.
ApJServMount /joe ajpv12://localhost:8007/joe

# Mounting the second context.
ApJServMount /bill ajpv12://localhost:8009/bill
</IfModule>
            

上記のファイルのように、同一マシン上の異なるポートをそれぞれ明確にAjpにマウントしている指示が・る。この構成は、server.xmlファイルの中の構成からサポートを要求する。異なるomcatプロセスのためには異なった<Conector>が構成されたファイルが必要だ。次の２つのサンプルのように、異なった<Connector>の設定値をもつ２つの異なったserver.xmlファイルが必要だ。(server_joe.xml と　server_bill.xmlのように） :
 
Joe's server.xml file  
    
<?xml version="1.0" encoding="ISO-8859-1"?>

<Server>
    <!-- Debug low-level events in XmlMapper startup -->
    <xmlmapper:debug level="0" />

    <!--  @@@
        Note, the log files are suffixed with _joe to distinguish
        them from the bill files. 
    -->

    <Logger name="tc_log" 
            path="logs/tomcat_joe.log"
            customOutput="yes" />

    <Logger name="servlet_log" 
            path="logs/servlet_joe.log"
            customOutput="yes" />

    <Logger name="JASPER_LOG" 
        path="logs/jasper_joe.log"
            verbosityLevel = "INFORMATION" />

    <!--  @@@
        Note, the work directory is suffixed with _joe to distinguish
        it from the bill work directory.
    -->
    <ContextManager debug="0" workDir="work_joe" >
        <!-- Context level Setup -->    
        <ContextInterceptor 
                    className="org.apache.tomcat.context.AutoSetup" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.DefaultCMSetter" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.WorkDirInterceptor" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.WebXmlReader" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.LoadOnStartupInterceptor" />
        <!-- Request processing -->
        <RequestInterceptor 
                    className="org.apache.tomcat.request.SimpleMapper" debug="0" />
        <RequestInterceptor 
                    className="org.apache.tomcat.request.SessionInterceptor" />
        <RequestInterceptor 
                    className="org.apache.tomcat.request.SecurityCheck" />
        <RequestInterceptor 
                    className="org.apache.tomcat.request.FixHeaders" />

        <!-- @@@ This connector uses port number 8007 for it's ajp communication -->
        <Connector 
                    className="org.apache.tomcat.service.SimpleTcpConnector">
            <Parameter 
                name="handler" 
                value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
            <Parameter name="port" value="8007"/>
        </Connector>

        <!-- @@@ the /jow context -->
        <Context path="/joe" docBase="webapps/joe" debug="0" reloadable="true" > 
        </Context>
    </ContextManager>
</Server>       
            

server_joe.xmlには<Connector>に、port8007が設定されており、server_bill.xml(次を参照)には<Connector>にport8009が構成されている。
 
Bill's server.xml file  
    
<?xml version="1.0" encoding="ISO-8859-1"?>

<Server>
    <!-- Debug low-level events in XmlMapper startup -->
    <xmlmapper:debug level="0" />

    <!--  @@@
        Note, the log files are suffixed with _bill to distinguish
        them from the joe files. 
    -->

    <Logger name="tc_log" 
            path="logs/tomcat_bill.log"
            customOutput="yes" />

    <Logger name="servlet_log" 
            path="logs/servlet_bill.log"
            customOutput="yes" />

    <Logger name="JASPER_LOG" 
        path="logs/jasper_bill.log"
            verbosityLevel = "INFORMATION" />

    <!--  @@@
        Note, the work directory is suffixed with _bill to distinguish
        it from the joe work directory.
    -->
    <ContextManager debug="0" workDir="work_bill" >
        <!-- Context level Setup -->
        <ContextInterceptor 
                    className="org.apache.tomcat.context.AutoSetup" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.DefaultCMSetter" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.WorkDirInterceptor" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.WebXmlReader" />
        <ContextInterceptor 
                    className="org.apache.tomcat.context.LoadOnStartupInterceptor" />
        <!-- Request processing -->
        <RequestInterceptor 
                    className="org.apache.tomcat.request.SimpleMapper" debug="0" />
        <RequestInterceptor 
                    className="org.apache.tomcat.request.SessionInterceptor" />
        <RequestInterceptor 
                    className="org.apache.tomcat.request.SecurityCheck" />
        <RequestInterceptor 
                    className="org.apache.tomcat.request.FixHeaders" />

        <!-- @@@ This connector uses port number 8009 for it's ajp communication -->
        <Connector className="org.apache.tomcat.service.SimpleTcpConnector">
            <Parameter 
                name="handler" 
                value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
            <Parameter name="port" value="8009"/>
        </Connector>

        <!-- @@@ the /bill context -->
        <Context path="/bill" docBase="webapps/bill" debug="0" reloadable="true" > 
        </Context>
    </ContextManager>
</Server>       
          

ポート構成は、joeとbillが異なった構成をする唯一の場所では・りません。xmlファイル内の@@@をマークしている４つの場所は変更する必要が・る。みてわかるように、この違いは２つのTomcatプロセスがお互いのログとワークスペースのオーバーライドを避けるために必要です。

２つのTomcatプロセスを開始するのに、-f　コマンド行のオプションを使用しなくてはならない。: bin\starup -f conf\server_joe.xmlbin\starup -f conf\server_bill.xmlそれから異なるURLパス接頭辞をベースにしたApacheからアクセスしてください。

バーチャルホスティングの構成

Tomcat Ver3.1はバーチャルホストをサポートしている。実際、バーチャルホストはマルチプレＪＶＭの構成に良く似ている。理由は単純で、Tomcat3.1は各々のバーチャルホストで、多くのTomcatプロセスを実行している。

Ver3.1のTomcatはwebサーバーにバーチャルホスティングを与えた。webサーバーのバーチャルホスティングはTomcatのアダプターを使ったときにサポートされる。JVMを含むバーチャルホストの情況下で転送は要求される。たとえば、私たちが二つのバーチャルホスト、ＪＶＭを持っていたとする。ｖｈｏｓｔ１の状況下で、一つの処理が動いて、vhost2の前後でほかの処理が動いている。それらのＪＶＭはお互いの存在を知らない。バーチャルホストの概念はそれらを気づかせないこと。すべてのバーチャルホストの構造はwebサーバーのアダプタの中に・る。問題をはっきりさせるにはApache-Tomcatに付いてくるサンプルファイルを調べること。:
 
Apache-Tomcat Configuration with Virtual Hosts Support  
    
######################################################################
#        Apache Tomcat Virtual Hosts Sample Configuration            #
######################################################################
LoadModule jserv_module modules/ApacheModuleJServ.dll
<IfModule mod_jserv.c>
ApJServManual on
ApJServDefaultProtocol ajpv12
ApJServSecretKey DISABLED
ApJServMountCopy on
ApJServLogLevel notice

ApJServDefaultHost localhost
ApJServDefaultPort 8007

# 1 Creating an Apache virtual host configuration
NameVirtualHost 9.148.16.139

# 2 Mounting the first virtual host
<VirtualHost 9.148.16.139>
ServerName www.vhost1.com
ApJServMount /examples ajpv12://localhost:8007/examples
</VirtualHost>

# 3 Mounting the second virtual host
<VirtualHost 9.148.16.139>
ServerName www.vhost2.com
ApJServMount /examples ajpv12://localhost:8009/examples
</VirtualHost>
</IfModule>
            

step１、２と３には２つのApacheバーチャルホストの定義がされており、それぞれの文脈にはajpv12URLが・る。それぞれ、ajpv12のポイントとJVMを含むバーチャルホストで・る。二つのJVMの形状はとてもよく似ていることを前の部分で説明している。私たちは二つの違ったserver.xmlファイルを再び使う必要が・る（ひとつはバーチャルホストのプロセスとして）そして、Tomcatプロセスをコマンドラインに-fオプションを指定して、実行させる必要が・る。その・と、Apacheに入るごとにいろいろなホストネームを使うことができる。そして、アダプターは我々に適切なJVMを転送する。

バーチャルホストの改良をサポートする必要が・る。
違ったJVMで、各々バーチャルホストを実行すると大きなスケーラビリティの問題が発生する。次のTomcatのバージョンではTomcat　JVMの中にいくつものバーチャルホストを作るのをサポートしている。

実世界のコンフィグレーションティプス

標準のTomcatは単純な構成で配布される。その主な目的は初めて使うユーザーの経験を促進させること。そして、開放的な作業をさせること。この構成では本当のサイトにTomcatを配置するよい方法はない。たとえばサイトのパフォーマンスを調整するそして明確なセッティングをする。（たとえばパスに要素を追加する。）このセクションは・なたが始めることを指示している。最初のステップはTomcatベースのサイトを見るべきで・る。

バッチファイルの修正とカスタマイズ

前の部分の状態はスタートアップスクリプトに都合がよい。時々スクリプトの配置を修正する必要が・る。: 基本のスクリプトを持っていないものは取り替える。例えば、Tomcatスクリプトは周囲にわかりやすい名前に替えられる。TOMCAT_OPTSはJVMのパラメータの特別なコマンドライン。（メモリセッティングなど。）UNIX上でもまたホームディレクトリに".tomcatrc"と名前を変えたファイルを作ることができる。そして、周囲の情報を得るようにPATH、JAVA_HOME,TOMCAT_HOME、CLASSPATHを通す。NT上では、スタートアップスクリプトの書き換えを強制する。（UNIXでは修正にJVMのコマンドラインのようなものを使う）Do not hesitate, just do it.

デフォルトJVM設定の修正

デフォルトJVMの設定はTomcatスクリプトの中でもとても、単純で・る。すべてのことはデフォルトに任せられている。それらのことはTomcatのパフォーマンスの改良を考えるべきで・る。:
     
  1. JVMには標準的にjavaヒープに始めのサイズは割り当てられている。もし、メモリを得られないときが多いときは、JVMのメモリ構成を修正する。それにもかかわらず、JVMはサイトをロードするメモリを多く与えるようにTomcatのパフォーマンスを改良する。Javaヒープの最大値、最小値をセットするコマンドラインのパラメータに-Xms/-Xmx/-ms/-mxなどを使わなければならない。
  2. JVMのスレッディングの形状を修正する。SUNのJDK1.2.2　for　Linuxはgreenスレッドや、特有のスレッドの両方をサポートしている。全体的に特有なスレッドはI/Oアプリケーションの境界にパフォーマンスを改良することを知らせる。greenスレッドは他方に圧迫をかけない。サイトで二つのスレッドモデルのうち、どちらのモデルがよいか実験しなければならない。（主に、特有のスレッドのほうがよい。）
  3. タスクでベストなJVMを選ぶ。いくつものJVMベンダーが・る。例えば、Linuxでは2000/03/21現在JVMレベルで二つの製品が・る。SUNのJDK1.2.2とIBMのJDK1.1.8で・る。もしアプリケーションで、明確なJDKの機能を必要としないなら、二つをベンチマークテストし、よいほうを選ぶ。私の内部テストではIBMのJDKのほうがSUNよりも早く立ち上がった。・なた自身が計算し決定するべきで・る。

Modify your Connectors

コネクターTomcatのデフォルトで形成される、server.xmlは、次のserver.xmlフラグメントように構成された２つのコネクターを含みます。
The two default Connectors in server.xml  
        <!-- (1) HTTP Connector for stand-alone operation -->
        <Connector className="org.apache.tomcat.service.SimpleTcpConnector">
            <Parameter
                name="handler"
                value="org.apache.tomcat.service.http.HttpConnectionHandler"/>
            <Parameter
                name="port"
                value="8080"/>
        </Connector>

        <!-- (2) AJPV12 Connector for out-of-processs operation -->
        <Connector className="org.apache.tomcat.service.SimpleTcpConnector">
            <Parameter
                name="handler"
                value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
            <Parameter
                name="port"
                value="8007"/>
        </Connector>
                
  1. HTTPリクエストのためのポート８０８０、このコネクターは、スタンドアローン・オペレーションのために必要とされます。
  2. AJPV１２リクエストのためのポート８００７。このコネクターがウェブ-サーバー統合のために必要とされます(プロセスからのservlet integration)。
Tomcat deployment が使う、どちらかaプロセスからのservlet integration、・るいはスタンドアローン・オペレーション、リムーブすること不必要なことが重要です。

Use a Thread Pool in your Connectors

Tomcatは、それぞれのリクエストを意味するマルチ・スレッドのservlet containerが・るスレッドによって実行される必要が・るということです。リクエストが着くデフォルトによって、Tomcatは、新しいスレッドを作り出して、それを開始して、それにリクエストを出させます。このリクエストがサイトにとロードされたとき問題が・ります。: これらの問題のための解決は、スレッド・プールを使うことです。スレッド・プールを使っているServlet containerは、直接にそれらのスレッドを管理することから用をたします。 新しいスレッドを割り当てるのではなく、スレッドを必要とするときにはいつも、それらは、プールから取り出されます。そして、終わったときに、スレッドは、プールに返されます。スレッド・プールは、洗練されているスレッド・マネージメント技術を実行するために、今使うことができます。:
  1. これらの問題のための解決は、スレッドが「オープンする」保管、およびそれらを再使用することを使うことです。これは、切れ目なくスレッドを作り出して意図的に破壊することに関係が・るトラブルを保存します
  2. 上位の境界をスレッドの数にけしかけて同時に使われました。これは、無制限のスレッド配分に関係が・る資源配分の問題を阻止します。
・なたは、技術がいろいろな道で上について述べたことをうまくすることができます、しかし、これらはひとつの技術です。スレッド・プールの主な機能は、スレッド-再使用、およびリソース使い方を制限する上位で・って縛られている合意を持っています。

Tomcatでスレッド・プールを使うことは、シンプルな動きです。・なたがする必要が・るすべては、・なたの<コネクター>構成でPoolTcpConnectorを使うことです。例えば、以下のserver.xml fragmentは、ajpv１２、共同計算にされたコネクターを定義します:
Pooled ajpv12 Connector  
        <!-- A pooled AJPV12 Connector for out-of-processs operation -->
        <Connector className="org.apache.tomcat.service.PoolTcpConnector">
            <Parameter
                name="handler"
                value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
            <Parameter
                name="port"
                value="8007"/>
        </Connector>
                
このfragmentは、シンプルで(デフォルト)プールに教えます。:

デフォルト構成は、１０-４０の同時に起こるリクエストの平均で中間のロード・サイトにとって適当です。もし・なたのサイトが違えば、・なたはこの構成を変更すべきです(例えば上限を縮小する)。プールを構成することは、次のfragmentでデモをされたとしてserver.xmlで<コネクター>要素を通して終わることができました:
Configuring the Thread Pool  
        <!-- A pooled AJPV12 Connector for out-of-processs operation -->
        <Connector className="org.apache.tomcat.service.PoolTcpConnector">
            <Parameter
                name="handler"
                value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
            <Parameter
                name="port"
                value="8007"/>
            <Parameter
                name="max_threads"
                value="30"/>
            <Parameter
                name="max_spare_threads"
                value="20"/>
            <Parameter
                name="min_spare_threads"
                value="5" />
        </Connector>
                
見ることができるものとして、プールには、３つの構成要素が・ります: ・なたは、プールの操作を・なたのニーズに合わせるために、上記のパラメーターを使うべきです。

Disable Servlet Auto-Reloading

Servlet auto-reloading is really useful for development time. However it is very expensive (in performance degradation terms) and may put your application in strange conflicts when classes that were loaded by a certain classloader cannot co-operate with classes loaded by the current classloader.

したがって、・なたの配布の間にリロードするクラスに対する現実の必要を持っていることがない限り、・なたは、・なたのコンテキストでリロード可能なフラグを止めるべきです。

Start Tomcat from /etc/inittab

運わるく、アパッチのために、(またはその他のサーバーのどれかのため)開発されたアダプターは、もうTomcatを開始することができません。UNIXでしかし、・なたは、マシン・スタートアップで自動的にTomcatを開始するために、initテーブルを使うことができます。 FIXME:

Authors

This document was created by: Gal Shachor
With help from (alphabetical ordered):Jonathan Bnayahu
Fiona Czuczman
Costin Manolache
Copyright ｩ1999 The Apache Software Foundation


Legal Stuff They Make Us Say
Contact Information