原文はこちら| 原文はこちら |
このドキュメントは若干の Tomcat についての基本的なインフォメーションを供給します。 ここで覆われた見出しの若干がそうです：
希望を抱いて Tomcat を始めるどんな新参入ユーザにでも十分でしょう。
もし何かが欠けているなら、次のオーダーで試してください。
我々はすべてのユーザーに、もし（彼・それ）らがすでに存在しないなら、 Tomcat faq そして／あるいはこのドキュメントの中に質問への答えを加えるよう奨励します。 もしあなたがこのドキュメントについてコメントあるいは示唆を持っているなら、（彼・それ）らを Tomcat メーリングリストに行かせるのをためらわないでください。
Tomcat はＪＳＰ環境を持っている servlet コンテナです。
servlet コンテナは、ユーザーのために servlets
を管理・呼び出すためのランタイムシェルです。。
およそ、次のように servlet コンテナを分割することができます。
Tomcat はスタンドアローン・コンテナ（主に開発とデバッグのために）か、既存の web サーバー・アドオンとして（現在アパッチ、 IIS と Netscape サーバーがサポートされる）使用することができる。 これは、Tomcat を構成している時はいつでもそれを使う方法を決断しなければならない。そして、もし２か３のオプションを選ぶなら、同じく web サーバーアダプターをインストールする必要があることを意味します。
これは普通の誤解です。 Jserv はアパッチで使われるために作られた Servlet API 2.0-compliant コンテナです。 Tomcatは完全な書き直しであって、そして Servlet API ２.２とＪＳＰ 1.1-compliant コンテナです。
Tomcatが Jserv 、特に Jserv のアパッチサーバーアダプターのために書かれたコードのいくつかを使用します、しかしこれは類似性が終わる所です。
とても簡単です。次のようにしてください。
それだけです！ あなたは、すぐに Tomcat を実行することができます、そしてそれはスタンドアローンの（タイプ１） servlet コンテナとして動作するでしょう。
あなたは始めて、そして Tomcat がbin ディレクトリでスクリプトを使うのを止めます。
Tomcat を始めるために、実行してください：
ＵＮＩＸ ： bin/startup.sh
Win32 ： bin\startup
Tomcat を止めるために、実行してください：
ＵＮＩＸ ： bin/shutdown.sh
Win32 ： bin\shutdown
あなたが解凍した Tomcat バイナリの分配は次のディレクトリ構造となります。
| ディレクトリ名 | 記述 |
|---|---|
| bin | 始動／シャットダウン... スクリプトを含んでいます |
| conf | server.xml （Tomcatのメインコンフィギュレーション・ファイル）と Tomcat で構成された種々の web アプリケーションのためにデフォルト値をつける web.xml を含めて種々のコンフィギュレーション・ファイルを含んでいます。 |
| doc | Tomcat に関して雑多なドキュメントを含んでいます。 |
| lib | Tomcat によって使われる種々の jar ファイルを含んでいます。 ＵＮＩＸの上にどんなこのディレクトリの中のファイルでも Tomcat の classpath に添えられます。 |
| logs | これは Tomcat がそれを置く所がログファイルであるということです。 |
| src | servlet API はファイルを入手します。 けれども、興奮しないでください；これらはどんな servlet コンテナによってでも実行されるべきであるただからのインタフェースと抽象的なクラスに過ぎません。 |
| webapps | サンプル web アプリケーションを含んでいます。 |
さらにあなたはそうすることができます、あるいは Tomcat はそうするでしょう、次のディレクトリを作ってください：
| work | 自動的に Tomcat によって生み出されて、これは Tomcat がそれの間の（コンパイルされたＪＳＰファイルのような）媒介ファイルの仕事を寄せる所です。 もしあなたが、 Tomcat が走っている間に、このディレクトリをデリートするなら、あなたはＪＳＰページを実行することが可能ではないでしょう。 |
| classes | あなたは classpath に追加のクラスを加えるためにこのディレクトリを作ることができます。 あなたがこのディレクトリに加えるどんなクラスでも Tomcat の classpath でそれが位置であることに気付くでしょう。 |
Tomcat は Java プログラムです、そしてそれ故にコマンドラインから、いくつかの環境変数をつけた後でそれを実行することは可能です。 しかしながら、それぞれの環境変数をつけることと、 Tomcat によって使われたコマンドラインパラメータの後に続くことはうつ伏せで、そして退屈でエラーです。 その代わりに、 Tomcat 開発チームは始めて、そして Tomcat を止めて和らぐために少数のスクリプトを供給します。
ノート： スクリプトはただ起動／停止の都合が良い方法に過ぎません。 あなたは、正しいコマンドラインが Tomcat のために生み出される限り、 CLASSPATH 、 PATH のような環境変数と LD_LIBRARY_PATH などをカスタマイズするために（彼・それ）らを修正することができます。
これらのスクリプトは何か？ 次のテーブルは普通のユーザーのために最も重要なスクリプトを提出します：
| スクリプト名 | 記述 |
|---|---|
| Tomcat | メインスクリプト。 、 CLASSPATH 、 TOMCAT_HOME と JAVA_HOME を含めての、適切な環境をセットして、そして適切なコマンドラインパラメータで Tomcat を始めます。 |
| startup | バックグラウンドでTomcatを始めます。 「Tomcatスタート」のための近道 |
| shutdown | （それをダウンしているように閉じている）Tomcatを止めます。 「Tomcat停止」のための近道 |
ユーザーのために最も多くの重要性を持っているスクリプトはTomcat（ tomcat.sh ／ tomcat.bat ）です。 ‖他のTomcat関連のスクリプトは Tomcat スクリプトに単純化されたシングル仕事指向の入り口ポイントの役をする‖（異なったコマンドラインパラメータをセットしてください、など。）。
それが行う tomcat.sh ／ tomcat.bat 産出、次の行動、へのより近い一見：
| OS | 行動 |
|---|---|
| ＵＮＩＸ |
|
| Win32 |
|
あなたが会うことができるように、 tomcat.bat の Win32 バージョンはＵＮＩＸ１と比較して青ざめます。 特にそれは TOMCAT_HOME と JAVA_HOME の値を推測しません、そしてそれは同じくすべての jar ファイルを classpath に運びません。
Tomcatのコンフィギュレーションは２枚のファイルに基づいています：
このセクションはどのようにこれらのファイルを使うべきかを扱うでしょう。 我々は web.xml の internals をカバーしようとしていません、これらの internals は Servlet API 仕様で深く覆われています。 その代わりに我々は server.xml の内容をカバーして、そして Tomcat という環境で web.xml の使用法を論じるでしょう。
server.xml は Tomcat のメインコンフィギュレーション・ファイルです。 それは２つのゴールを果たします：
server.xml での重要な要素は次のテーブルで記述されます：
| 要素 | 記述 |
|---|---|
| Server | ファイル server.xml での最高の素子。 サーバーがひとつの Tomcat サーバーを明記します。 一般にあなたはあまりに多くそれを気にするべきではありません。 サーバー素子がタイプ木こりと ContextManager の要素を含んでいることができます。 |
| Logger | この要素は木こりオブジェクトを明記します。 それぞれの木こりが木こりアウトプットと（ログレベルを指定する） verbosityLevel を含んでいるためにログファイルに、パスと同様、それを識別するために名前を持っています。 ‖現在 servlets のために木こりがいる‖（‖ ServletContext.log である場合は‖（‖）‖行く‖）‖、‖ＪＳＰファイルとTomcatランタイム‖。 |
| ContextManager | ContextManager が ContextInterceptors のセット、 RequestInterceptors
、文脈と（彼・それ）らのコネクターのためにコンフィギュレーションと構造を指定します。
ContextManager はそれがそれに提供する少数の特質を持っています：
|
| ContextInterceptor ＆ RequestInterceptor | これらの迎撃機は ContextManager で起きるある特定のイベントのために聞きます。 例えば、 ContextInterceptor は始動のために聞きます、そして Tomcat のシャットダウンイベントとユーザーのリクエストがそれの間に通り越す必要がある RequestInterceptor 腕時計、種々の位相、はサービスです。 Tomcatのアドミニストレーターは迎撃機について多くを知る必要がありません；他方のデベロッパーがこれがオペレーションの「グローバルな」タイプが Tomcat （例えば、セキュリティそしてリクエスト毎に木材を伐採すること）に実装されることができる方法であることを知るべきです。 |
| Connector | コネクターは（スタンドアローンのコンフィギュレーションで）ユーザーに、
web
サーバーを通してあるいは直接ユーザーのブラウザに接続を表します。
コネクターオブジェクトは種々のクライアントに接続しているソケットからの
Tomcat
作業者スレッドのマネージメントのためにそして読み取り／書き込みのリクエスト／回答に関して責任がある（の・もの・人）です。
‖コネクターのコンフィギュレーションはインフォメーションを含む‖よう‖：‖
我々はこのドキュメントで後でのコネクターコンフィギュレーションを使う方法を記述するでしょう。 |
| Context | それぞれの文脈があなたが web アプリケーションを置く Tomcat
階層でパスを表します。 Tomcat Context
という人が次のコンフィギュレーションを持っています：
|
棄権によってTomcat がコンフィギュレーションのために TOMCAT_HOME ／ conf ／ server.xml を使うでしょう。 デフォルトコンフィギュレーションは、それが文脈のために卑しい（時・から・につれて・ように）、 TOMCAT_HOME を使うでしょう。
あなたは異なったサーバーコンフィギュレーション・ファイルを持っているそして文脈まぐさおけのホーム不動産をセットする「ｆ／パス ／ が ／ に server.xml する − 」オプションを使うことによってこれを変えることができます。 あなたはホームの中に必要とされるファイルを設立する必要があります：
もし server.xml での ContextManager.home 特性が相対的であるなら、それは現在の作業ディレクトリと比較してであるでしょう。
web.xml の詳細な記述と（ディレクトリ構造を含めての、そしてコンフィギュレーションの） web アプリケーション構造は Servlet API 仕様 の、１０チャプター９と１４で利用可能です、そして我々はそれについて書こうとしていません。
しかしながら web.xml と関係がある小さいTomcat関連の「特性」があります。 Tomcatがユーザーに conf ディレクトリにデフォルト web.xml ファイルを入れることによってすべての文脈のためにデフォルト web.xml 値を明記させます。 新しい文脈を建設する時、 Tomcat は、基盤コンフィギュレーションと特定のアプリケーションが（アプリケーションの Web - INF ／ web.xml に位置している（の・もの・人））を web.xml して、ただこれらのデフォルトに上書きするだけである（時・から・につれて・ように）、デフォルト web.xml ファイルを使います。
上へ今まで我々は、サーバーが付加する（時・から・につれて・ように）、 Tomcat を論じませんでした、その代わりに我々はそれをスタンドアローンのコンテナであると考えて、そしてどのようにそれが使われることができるか論じました。 しかしながら少数のこの写真における問題があります：
これらすべての理由のために本当の世界サイトが Servlet ／ＪＳＰアドオンとしてサイトと使用 Tomcat のスタティックな内容を果たすことに対して、アパッチのような、 web サーバーを使うことは勧められます。
我々は深く異なったコンフィギュレーションをカバーしようとしていません、その代わりに我々はそうするでしょう：
nutshell で web サーバーがクライアント HTTP のリクエストを待っています。 これらのリクエストが到着する時、サーバーは必要な内容を供給することによってリクエストを果たすために必要とされるものは何でもします。 servlet コンテナを加えることは幾分この行動を変えるかも知れません。 今 web サーバーは同じく次のことを行う必要があります：
他方のアダプターはそれが、通常リクエスト URL でいずれかのパターンに基づいていて何のリクエストに仕えようとしているか、そしてどこまでこれらのリクエストを指揮するべきか知る必要があります。
ものが、ユーザーが仮想のホストを使うコンフィギュレーションをセットすることか、あるいは（彼・それ）らが多数のデベロッパーを欲する時同じ web サーバーの上にしかし異なった servlet コンテナ JVMs の上に働くことを望む時、さらにいっそう複雑です。 我々は進歩したセクションでこれらの２ケースをカバーするでしょう。
１（人・つ）が考えることができる最も明白なコンフィギュレーションは servlet コンテナの責任の下である servlet URL のアイデンティティーです。 これは明確です；誰かが servlet コンテナに何のリクエストを伝達するべきか知っていなくてはなりません・・・。 それでもなおかつ我々が web サーバー／ servlet - コンテナ組合わせに供給するべきである追加のコンフィギュレーション項目があります：
このすべてのインフォメーションは web サーバーコンフィギュレーションで、あるいはファイルがアダプターによって使った私的なコンフィギュレーションに現われなくてはなりません。 次のセクションはどのようにコンフィギュレーションがアパッチの上に実行されることができるか明示するでしょう。
このセクションはあなたにどのように Tomcat と共に働くためにアパッチを構成するべきか示します；それはあなたが使うべきであるコンフィギュレーション指令に、洞察と同様、説明を提供しようとします。 あなたは jserv インストールページ で追加のインフォメーションを発見することができます。
Tomcat がそれを始める時は TOMCAT_HOME/conf/tomcat-apache.conf でアパッチのために自動的にコンフィギュレーション・ファイルを生み出すでしょう。 ほとんどいつもあなたはあなたの httpd.conf にこの ( appending "Include TOMCAT_HOME/conf/tomcat-apache.conf" ) ファイルを含めること以外何もする必要がありません。 もしあなたがスペシャルニーズ、例えば AJP ポート他、８００７、持つなら、あなたはあなたのカスタマイズされたコンフィギュレーションのためにこのファイルを基盤として用いて、そしてもう１枚のファイルで結果を救うことができます。 もしあなたがあなた自身アパッチコンフィギュレーションを首尾よく処理するなら、あなたは、あなたが新しい文脈を加える時はいつでも、それを更新する必要があるでしょう。
‖Tomcat３.１：‖あなたは新しい文脈を加えた後で、アパッチがコンフィギュレーション変更を支援しないTomcatと apache を再開しなくてはならない‖再起動する‖。 同じくファイル TOMCAT_HOME/conf/tomcat-apache.conf は、Tomcatが始める時、発生させられます、それであなたはアパッチの前に Tomcat を始める必要があるでしょう。 Tomcatがそれぞれの始動で TOMCAT_HOME/conf/tomcat-apache.conf に上書きするでしょう、それでカスタマイズされたコンフィギュレーションが他のところに保持されるでしょう。
アパッチ - Tomcat コンフィギュレーションは、それが最初あなたを混乱させるかも知れない、それを単純化してしかしながら２つのものがあるように、 Jserv ユニークな指令と同様、アパッチ核心コンフィギュレーション指令を使います：
tomcat.conf のサンプル ファイル
########################################################### # 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> |
|
A Minimalistic Apache-Tomcat Configuration |
構築手順は４つの階段に分けられます。
ApJServMount /examples ajpv12://hostname:port/root
ホスト「ホスト名」上で実行されている Tomcat プロセスに context /examples をマウントし、ポート番号「ポート」を聞く。
あなたがサンプルファイルで異なったコンフィギュレーションインストラクションを理解する今、どのようにあなたはアパッチコンフィギュレーションにそれを加えることができますか？ １つの「単純な」方法が httpd.conf （アパッチコンフィギュレーション・ファイル）でそれが内容であると手紙を書くことです、これはしかしながら非常に取り散らかし得ます。 ‖その代わりにあなたはそうするべきである‖使用、アパッチ、が指令を含む‖。 ‖アパッチの終わりにおいてコンフィギュレーションファイル（ httpd.conf ）が次の指令を加えます。
include <full path to the Tomcat configuration file>
例えば
include /tome/tomcat/conf/tomcat.conf
‖アパッチに、それの後にあなたがそうするべきであるあなたの Tomcat コンフィギュレーションはアパッチ libexec への jserv モジュール（あるいは Win32 ケースでのモジュール）のためにディレクトリをコピーして、そして再起動します（ ＋ スタートを止めます）‖アパッチ‖。 それは今 Tomcat に接続することが可能でしょう。
前に述べられるように、我々はアパッチで座って、そして Tomcat にリクエストをリダイレクトするために web サーバーアダプターを必要とします。 アパッチのために、このアダプターは mod_jserv のわずかに修正されたバージョンです。
‖あなたは ここで 見て、そして mod_jserv のすでに前もって構築されたバージョンがあるかどうか見ようとしてもよい‖それ‖スイート‖、しかしながら、あなたがそれほどまだ期待するべきでないネイティブのライブラリである、あなたの OS （通常 NT のための（の・もの・人）がある）‖（十分なデベロッパー、あまりにも短い人生ではなく、あまりに多くの OS ・・・）‖。 さらに、あなたがアパッチを建てた方法／あなたの特定のＵＮＩＸ変形での小さい相違がダイナミックなリンクしているエラーをもたらすかも知れません。 ‖あなたは本当にあなたのシステムのために mod_jserv を建てようとするべきである‖（パニックにならないでください、それは激しくそれではありません！）‖。
ＵＮＩＸの上に mod_jserv を組み込むには次のことを巻き込みます：
Win32 のために mod_jserv を組み込むことはより低度に有望です（あなたは Win32 のためにすでに downloadable dll を持っています）。 もうもしあなたがそれを構築することを望むなら、あなたはビジュアル C++ をインストールして、そして次のことを行うべきです：
それだけです； mod_jserv が組み込まれました。
前のアパッチ - Tomcat コンフィギュレーション・ファイルは幾分非能率的でした、それはアパッチに ／ 例 接頭辞から始める供給源が Tomcat によって果たされるどんなリクエストでも送るよう指示しました。 我々は本当にそれを欲しますか？ 我々の servlet 文脈の一部であるかも知れない多くのスタティックなファイルがあります（例えばイメージと批判 HTML ）、なぜ Tomcat はこれらのファイルを果たすべきですか？
あなたはそれをすることに対して、例えば実際に理由を持っているかも知れません：
一般にしかしながら、これはそのケースではありません、そして Tomcat にスタティックなファイルをセーブさせることはちょうどＣＰＵ浪費です。 我々はその代わりにアパッチが Tomcat ではなく、これらのスタティックなファイルを果たすようにするべきです。 レットが今正確にそれをするサンプル tomcat.conf ファイルを見ます：
アパッチがスタティックなファイルを果たすようにすることは次のことを必要とします：
そして残りを処理するためにアパッチを辞めます。 レットが今正確にそれをするサンプル tomcat.conf ファイルを見ます：
######################################################################
# 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-Tomcat Configuration where Apache Serves the Static Content |
あなたが会うことができるように、このコンフィギュレーション・ファイルの初めは前の例で見られると比べて同じです。 （文脈をマウントしている）最後のステップは、しかしながら、アパッチと今説明されるであろう Ajp コンフィギュレーション指令の長いシリーズで取って代わられました：
このコンフィギュレーションがもっとずっと多くの複合センターとその時うつ伏せのエラー、最初の例、であるのを見ることは易しいです、これはしかしながらあなたが（しばらくは）改善された遂行能力に対して支払うべきである価格です。
時々例えば異なった JVMs によって処理された、異なった文脈を持つことは有用です：
異なった文脈が異なった JVMs によって果たされるこのような組織を実行することは非常に易しいです、そして次のコンフィギュレーション・ファイルはこれを証明します：
###################################################################### # 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> |
|
Apache-Tomcat Configuration with per Context JVM |
あなたがいくつかの JVMs を使っている前の事例を中に案内します（異なった機械上で走るそれらさえ対等にします）ことができる（時・から・につれて・ように）フルの Ajp URL 基礎を使うことによって容易に熟達し得ます。 このフルの URL で我々は実際に Tomcat プロセスが位置しているホストを指定します、そしてそれはポートです。
もし２つの Tomcat プロセスが機械を同じ上で走らせていたなら、我々は異なったコネクターポートで（彼・それ）らのそれぞれを構成しなければならないでしょう。 ‖例えば、２つの JVMs ホームイン localhost の上に、アパッチ - 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> |
|
Same Machine Multiple JVM Apache-Tomcat Configuration |
上記のファイルを見て、あなたは我々が同じ機械の上に異なったポートを示してそれぞれ２つの明白な Ajp 基礎要点を持っているのを見ることができます。 このコンフィギュレーションが server.xml ファイルで発見されたコンフィギュレーションからサポートを必要とすることは明確です。 我々は、異なった Tomcat プロセスのために、これらのファイルで異なった <コネクター> コンフィギュレーションを必要とするでしょう。 我々は、次の２つのサンプルに示されるように、異なった <コネクター> 項目で実際に２枚の異なった server.xml ファイル（レットが（彼・それ）らを server_joe.xml と server_bill.xml と呼ぶ）を必要とするでしょう：
<?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>
|
|
Joe's server.xml file |
server_joe.xml を見る時、あなたは < Connector > がポート８００７のために構成を設定されるのを見ることができます。 ‖中にいる‖ server_bill.xml します（次に見ます）‖他方 < Connector > はポート８００９のために構成を設定される‖。
|
|
|
Bill's server.xml file |
ポートコンフィギュレーションは唯一の joe と請求書コンフィギュレーションが異なる所ではありません。 我々は変更がされなければならなかった４つの位置を特徴づけている xml ファイルでマルク @@@ を持っています。 あなたが会うことができるように、この相違はお互いの丸太と workspace に上書きすることから２つの Tomcat プロセスを避けるために必然的です。
その時我々は the -f コマンドラインオプションを使っている２つのTomcatプロセスを始めるべきです：
bin \が conf \ server_joe.xml
bin \ starup - ｆ conf \ server_bill.xml
を starup -f して
、そして次に異なった URL パス接頭辞に基づいてアパッチから（彼・それ）らにアクセスします。
Tomcat Ver3.1 の下で、実際仮想のホストコンフィギュレーションが（前のセクションで説明されるように）多数の JVM のために構成を設定することに非常に類似している仮想のホストをサポートすることは可能です、そして理由は単純です、Tomcat３.１でそれぞれの仮想のホストが異なった Tomcat プロセスによって実行されます。
‖現在の（ Ver3.1 ）Tomcatと一緒に、仮想のホストとして機能すること自覚が web サーバーによって供給される‖（‖アパッチ／ Netscape ■‖。 向け直すべき Tomcat アダプターがこの仮想のホストの文脈を含んでいて JVM （ｓ）にある仮想のホストに属することを求める仮想のホストとして機能することサポートが使われる web サーバー。 これはもし（例えば）我々が（ vhost1 の、そして vhost2 の）２つの仮想のホストを持っているなら、我々が２つの JVMs を持つであろうことを意味します： vhost2 の文脈を運営して vhost1 と他の文脈を走らせている１。 これらの JVMs はそれぞれの他のもの存在に気付いていません、実際、（彼・それ）らは仮想のホストとして機能することのコンセプトに気付いていません。 すべての仮想のホストとして機能することロジックが web サーバーアダプターの中にあります。 ものをいっそう明らかにするために、レットが次のサンプルアパッチ - Tomcat コンフィギュレーション・ファイルを見ます：
###################################################################### # 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> |
|
Apache-Tomcat Configuration with Virtual Hosts Support |
見られることができるように、仮想の２人のアパッチが主人役を務める１,２と３が明記する階段、そして（彼・それ）らのそれぞれのために、ある ajpv12 URL に ／ 例文脈をマウントしてください。 それぞれこのような ajpv12 URL 小数点仮想のホストを含んでいる JVM に。 ２つの JVMs のコンフィギュレーションは前のセクションで証明される（の・もの・人）に非常に類似しています、我々は再び２枚の異なった server.xml ファイル（それぞれの仮想のホストプロセスのための（の・もの・人））を使う必要があるでしょう、そして我々は the -f コマンドラインオプションで Tomcat プロセスを始める必要があるでしょう。 それをした後で我々はアパッチ、それぞれの異なったホスト名を持っている時に接近することが可能であるでしょう、そしてアダプターは適切な JVM に我々をリダイレクトするでしょう。
改善された仮想のホストサポートの必要
それぞれの仮想のホストが異なった JVM
によって実行されるようにすることは莫大な scalability 問題です。
Tomcat の次のバージョンは同じ Tomcat JVM
の中でいくつかの仮想のホストをサポートすることを可能にするでしょう。
‖棄権によって Tomcat 分配はその主なゴールが初回のユーザー経験を促進するはずである世間知らずのコンフィギュレーションで来る‖そして‖「ボックスから」オペレーションが・・・‖。 このコンフィギュレーションはしかしながら本当のサイトの上に Tomcat を構成する最も良い方法ではありません。 例えば、本当のサイトが若干の遂行能力調律とサイト特定の設定（例のための追加のパス要素）を必要とするかも知れません。 このセクションはあなたを、Tomcatを発表することはサイトの基礎を置く前に、とられるべきである第一歩に向けることによってあなたが始められるようにしようとするでしょう。
‖前のセクションで、スクリプトが（そのために）ここにである始動を述べたように‖あなた‖都合が良い‖。 それでもなおかつ、時々派遣のために必要とされるスクリプトは修正されるべきです：
‖基本的な（人たち・もの）が書く変更がへ明白な変更無しでされることができるこれらの若干；‖例えば、Tomcatスクリプトは余分のコマンドラインパラメータを JVM にセットするために TOMCAT_OPTS と命名された環境変数を使うことができる‖（メモリ環境などとしてそんなもの。）‖。 ＵＮＩＸの上にあなたは同じくあなたのホームディレクトリで 「 .tomcatrc 」 と命名されたファイルを作ることができます、そして Tomcat はこのファイルから PATH 、 JAVA_HOME 、 TOMCAT_HOME と CLASSPATH のような環境インフォメーションを取り出すでしょう。 NT の上にしかしながら（そして同じくＵＮＩＸの上に修正が JVM コマンドラインのような何かのためである時）、あなたは始動スクリプトのいくらかを書き直すことを強いられます・・・。
ためらって、ちょうどそれをしないでください。
Tomcatスクリプトでのデフォルト JVM 設定は非常に na の・ｅです；すべてがデフォルトのために残っています。 あなたがあなたの Tomcat 遂行能力を改善するために考慮するべきである少数のものがあります：
同じぐらい２つのコネクターが次の server.xml 破片のように構成した server.xml が含んでいる Tomcat のデフォルトで構成を設定されたコネクター：
<!-- (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>
|
|
The two default Connectors in server.xml |
良識がある Tomcat 派遣が out-of-process servlet インテグレーションあるいは独立型のオペレーションを使うであろうことは明確です、不必要なコネクターを取り去ることは重要です。
Tomcatはこれがそれぞれのリクエストがいずれかのスレッドによって実行されるために必要とすることを意味する multi-threaded servlet コンテナです。 棄権によってリクエストが到着する時、 Tomcat が新しいスレッドを作って、それを始めて、そしてそれがリクエストを果たすようにします。 ‖この行動は積み込まれたサイトのために問題が多い‖なぜなら‖：‖
これらの問題のための解決はスレッドプールを使うことです。 スレッドプールを使っている Servlet コンテナが直接（彼・それ）らのスレッドを管理することから（彼・それ）ら自身を和らげます。 新しいスレッドを割り当てる代わりに、（彼・それ）らがスレッドを必要とする時はいつでも、（彼・それ）らはプールからそれを求めます、そして（彼・それ）らがされる時、スレッドはプールに返されます。 道具がスレッドマネージメントテクニック、そんなものを洗練した玉突きが今使われることができるスレッド：
あなたは種々の方法で上に記述されたテクニックを洗練することができます、しかしこれらはただ改善に過ぎません。 ‖スレッドプールの主な貢献はスレッド再利用と同時発生を持つことである‖リソース使用法を制限する上の跳躍‖。
Tomcat でスレッドプールを使うことは単純な作動です；あなたがする必要があるすべてはあなたの <コネクター> コンフィギュレーションで PoolTcpConnector を使うことです。 例えば次の server.xml 破片は 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>
|
|
Pooled ajpv12 Connector |
この破片は非常に単純です、そして行動がそれによって教えた（デフォルト）プールはそうです：
デフォルトコンフィギュレーションは平均１０-４０の同時のリクエストで中間のロードサイトに適しています。 もしあなたのサイトが異なるなら、あなたはこのコンフィギュレーションを修正します（例えば上限を減らします）べきです。 プールを構成することは、次の破片で証明されるように、 server.xml で <コネクター> 素子を通してされることができます：
<!-- 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>
|
|
Configuring the Thread Pool |
見られることができるように、プールは３つのコンフィギュレーション parametes を持っています：
あなたはあなたの必要にプール行動を適応させるために上記のパラメータを使うべきです。
Servlet 自動車を再ロードすることは本当に開発時間に役立ちます。 しかしながら、それは（遂行能力退廃用語で）非常に高価であって、そして、ある classloader によってロードされたクラスが現在の classloader によって積み込まれたクラスと一緒に協同することができない時、妙な対立にあなたのアプリケーションを入れてもよいです。
それで、あなたがあなたの派遣の間に再装てんしてクラスの真の必要を持たないなら、あなたはあなたの文脈で reloadable 旗からそれるべきです。
不幸にもアパッチのために（あるいは他のサーバーの（どれ・何・誰）のためにも）開発されたアダプターはまだ Tomcat を始めることができません。 ＵＮＩＸの上にしかしながら、あなたは機械の始動の上に自動的に Tomcat を始めるために init テーブルを使うことができます。 FIXME ：
このドキュメントは通り過ぎて作られました：
ギャル Shachor
‖手助け‖から‖（‖アルファベット順‖注文する‖）‖：‖
ジョナサン Bnayahu
フィオナ Czuczman
Costin Manolache
コピーライト ©１９９９、アパッチソフトウェア基礎 |