The Jakarta Project

The mighty Tomcat - Meow!

Tomcat ユーザーズ・ガイド

このドキュメントは、Tomcat サーブレット・コンテナの紹介です。 だれでもTomcatをインストール、設定、配置するのに十分である必要があります。 また、新規ユーザに対する共通の多くの質問に答えます。また全てのユーザが Tomcat FAQ やこのドキュメントに存在しないような質問と答えを加える ことを薦めます。 もしこの文書についてコメントや提案があるならば、 mailing listsに 参加するのをためらわないで下さい。

この文書は Gal Shachoによって、Tomcat: A Minimalistic User's Guide として作成され、その他大勢の人によって修正さました。 これはまだ作業中と思ってください。Tomcatソースツリーが絶えず変わって いるので、ここでの情報は古いかもしれません。 唯一のもっとも信頼できる参照元は ソースコード です。

"???" の意味は、それが本当にふさわしければ、加筆しなければ ならないことか、あるいは、それがどこか別のところで言及しなければならない ことなのか私にはわからないことを意味します。 その他の編集コメントは、[ 正方形の括弧 ] で囲まれます。

その他の重要な文書:

目次

[ このセクションは、現在のアウトラインに合うように修正する必要がある。 XMLソースからXSLを使用してこのファイルを生成するのっていいと思わない? ]

Tomcat について

公式には、 Tomcat FAQを参照のこと。

    Tomcatとは?

Tomcat は、 Java Servlet 2.2 と JavaServer Pages 1.1 技術の公式リファレンスの実装です。 Apacheライセンスの下で開発され 開かれた、個人参加方式での環境で、世界中からの best-of-breed な開発者の協力により 開発されています。

    どこから Tomcatをダウロードできるの?

At the Jakarta download page!

    Tomcatは、JServではないの?

これは共通の誤解です。 JServ は、 Apacheと使われるために作成されたServlet API 2.0 に準拠したコンテナです。 Tomcat は、完全なリライトで、Servlet API 2.2 と JSP 1.1 に準拠したコンテナです。 Tomcatは、JServ(特にJServのApacheサーバー・アダプター)のために書かれる コードの一部を使用します、しかし、これは類似が終わるとこるです。

    サーブレットとは? What are JSPs?

ナッツシェルによれば、サーブレットは、メモリ常駐Javaプログラムで、 サーブレット・コンテナ(たとえばTomcat!)内部で実行されます。これらは CGIベースのスクリプト(たとえばperlとか)とは異なり、プロセス生成と 以後のクリーンアップのオーバーヘッドが必要ないので、より早く要求に 応答することができます。

Sun's servlet siteによれば:

"JavaTM Servlet API は、ウェブ開発者にウェブ・サーバーの、そして、既存のビジネス・システムに アクセスするための機能性を広げる単純な、一貫した仕組みを提供する。 サーブレットは、ほとんどサーバー上で動作し、faceは無い。"

...そしてJSP(JavaServer Pages)については, 再び Sun's servlet siteから:

"JSP 技術はHTMLとXMLページを書くことをサポートするために作成される サーブレット技術の拡張である。それは固定もしくは静的テンプレート・データを 動的な内容と組み合わせることをより簡単にする。"

JSP は、PHPとASPのような他の技術に相当します。そしてそれは、プログラミング/ スクリプティングをHTMLのようなマークアップ言語と組み合わせます。 プログラミング言語選択の重要な違い。 例えば、PHPは、C/C++/Javaハイブリッド、ASPは、VBScriptを使用します。 そしてJSPはJavaプログラミング言語の最大限のパワーを利用します。 これらの技術の多くの類似があり、これらは機敏な開発者の道具箱に 入っている。

これらの全ての情報は、 Sun's Java websiteにあり、ここからJSP, サーブレット、などをたどることが できる。 もし、徹底的に最初に JavaServer Pages と サーブレット 仕様書!を読み込めば、これらの技術で費やされる時間は有意義でしょう。

    どうやって貢献するの?

お願いです! Jakartaプロジェクトの貢献ページを見てください、それはここにあります。 tomcat-devメーリングリストに 参加。

    X, Y, Z が動かない。助けて!

わたしたちは、多くの共通の問題を満足させることを希望するが、疑う余地無くいくつか みのがした。より多くのヘルプを得るために、試してください(この順番で):
  1. Tomcatをインストールした場所の logs サブディレクトリ にログが記録されています。これらは未開発のリソースです。
  2. このドキュメントの共通の問題
  3. Tomcat FAQを通して読む。ほとんどのインストールと設定の質問はここでみつかります。
  4. Tomcat user と developer のメーリングリスト アーカイブを検索する。
  5. 質問を tomcat-user メーリングリストに投げる、返事をもらうには最初に 参加 しなければならない。

Tomcatのインストール

    ファイル配置と環境設定

これだけ! Tomcat の実行 とそれは スタンドアロン サーブレット・コンテナとしての実行が可能です。

いったん、正しく動作するとわかったら、これらの環境変数は設定ファイルで セットしておいたほうがよい。 設定ファイルは: Windowsでは、C:/AUTOEXEC.BAT, ~/bash_profile または ~/[ tcshの場合には何? ]

    Tomcatの開始と停止

Tomcatの開始と停止ではTOMCAT_HOME以下の binディレクトリにあるスクリプトを使用します。

Tomcastの実行を開始するためには:

UNIX: bin/startup.sh

Win32: bin\startup

Tomcastの実行を停止するには:

UNIX: bin/shutdown.sh

Win32: bin\shutdown

    個々のserver.xmlファイル を使用して複数インスタンスを開始するには

次のセクションで説明している、Tomcat の ディレクトリ構成, と Tomcatの設定 を読むまでこの章は たくさんの意味をなさないかもしれない。それらの後でここに戻ってくるのが 良いかもしれない。

デフォルトでは、Tomcatは、設定として TOMCAT_HOME/conf/server.xml を使用する> デフォルトとしてTOMCAT_HOMEは、そのベースとして使用される。 "-f /path/to/server.xml" オプションを使用することで変更することが可能で、 異なるサーバー設定ファイルで ContextManager 要素を 指定できる。homeの中で必要とされる設定ファイルは:

server.xmlでのContextManager要素のホームでの属性が関連しているならば、 それは現在のワークディレクトリと関連している。

    Tomcat ディレクトリ構成

Tomcatバイナリ配布を展開したとすると、以下のディレクトリ構成が TOMCAT_HOME以下にある:

ディレトクリ 内容
bin Startup/shutdown スクリプトとその他の便利ファイル
conf 設定ファイルで server.xml を含む。(Tomcatの メイン設定ファイル) と web.xml (Tomcatに配置される様様なウェブ・アプリケーションのためのデフォルト値。
doc Tomcatに関する様様な文書
lib Tomcastによって使用される様様な jar ファイル。 このディレクトリのどんなファイルでもTomcatのクラスパスに追加される。
logs これはデフォルトのTomcatのログファイルが置かれる場所
src サーブレット API ソースファイル。しかし、喜んではいけない、 これらは、空のインタフェースでabstractクラスなので、サーブレットコンテナで 実装しなけれはならならい。
webapps ウェブ・アプリケーションのサンプル。 ここに置かれる どんな .war ファイルでも自動的に広げられる。 WAR ファイルの配置を参照。

これに加えて、、Tomcaltまたはあなたよって以下のディレクトリが作成される。

work Tomcatが中間ファイル(JSPファイルのコンパイルされたものなど)を 動作中に置く場所です。もしこのディレクリをTomcatの動作中に削除すると JSPページの実行ができなくなります。
classes Tomcatのクラスパスの場所で見つけたいクラスを何でも追加することができる。

    Tomcat スクリプト

前記のスタートアップとシャットダウン・スクリプトによって提供されるデフォルト の機能が大部分のTomcatを開始するためのユーザーに十分であるので、このセクションは 読む必要はない。すべてがこれまでに動作しているならば、 Tomcatの設定 にスキップしてください。あなたが、疑う余地無くスクリプトに関するより多くの 情報が必要ならば、このセクションに戻ってきてください。

Tomcat はJavaプログラムです。したがって、いくつかの環境変数をセットした後に、 コマンドラインからそれを実行することが可能です。しかしそれぞれ環境変数を コマンドラインパラメータで指定して設定することは、エラーを起こしやすく 退屈なことです。その代わりに Tomcat開発チームは、Tomcatの開始、停止を簡単に するために、いくつかのスクリプトを提供しています。

注: スクリプトは、開始/停止への便利な方法だけです。 Tomcatのために正しいコマンドラインを生成するためにするかぎり 環境変数の CLASSPATH, PATH, LD_LIBRARY_PAHTなどを修正することができます。

以下の表は、普通のユーザにとって最も重要なスクリプトを提示しています。

スクリプト名 説明
tomcat メイン・スクリプト。CLASSPATH, TOMCAT_HOME, JAVA_HOMEを含んだ適当な環境をセットして、適当なコマンドラインパラメータ でTomcatを開始します。
startup tomcatをバックグラウンドで開始します。"tomcat start"のショートカット
shutdown tomcatを停止(シャットダウン)します。"tomcat stop"のショートカット

ユーザのために最も重要性を持つスクリプトは tomcat(tomcat.sh/tomcat.bat)です。 その他のTomcat関連のスクリプトは、単純化されたひとつの作業を行うためのエントリを tomcatスクリプトに対して行うために用意されています(異なるパラメータをセットして)

    Tomcat スクリプト: 厳密な実装

tomcat.sh/tomcat.batの動作の詳細は以下のとおり:

これらの振る舞いは、(特にCLASSPATH設定)は、Tomcat 3.2で変更された。 一番よいのは、直接スクリプトを見て変数設定と何のクラスのが読み込まれるか確かめることです。 [??? -再テストが終わるまでに全セクション削除? ]

OS 動作
Unix
  • TOMCAT_HOMEが指定されてなければ、推測する
  • JAVA_HOMEが指定されていなければ、推測する
  • それらを含むCLASSPATHを設定する -
    1. ${TOMCAT_HOME}/classes ディレクトリ (もしあれば).
    2. ${TOMCAT_HOME}/lib の全ての内容.
    3. ${JAVA_HOME}/lib/tools.jar (この jar ファイルは、 toolの javac を含んでおり、jsp ファイルのために javacが必要).
  • java をコマンドライン引数を指定して実行し、javaシステム環境を tomcat.homeを呼び出し、org.apache.tomcat.startup.Tomcat を スタートアップクラスとして呼び出す。また、コマンドライン引数を org.apache.tomcat.startup.Tomcatに渡す:
    1. 実施する操作 start/stop/run/etc.
    2. このTomcatプロセスよって使用される server.xml へのパス

    例えば、server.xmlが、/etc/server_1.xmlに存在して、 ユーザーが、apacheをバックグラウンドで開始したい場合には 以下のコマンドラインを提供する:

    bin/tomcat.sh start -f /etc/server_1.xml
Win32
  • 以下を含んだCLASSPATHを設定する -
    1. %TOMCAT_HOME%\lib ディレクトリの servlet.jar, webserver.jar, jasper.jar, xml.jar
    2. %TOMCAT_HOME%\classes (存在しなくても),
    3. %JAVA_HOME%\lib\tools.jar (この jar ファイルにはjavacツールが含まれており jspファイルのために javacが必要).
  • コマンドライン引数を伴って、PATHの中にあるはずの javaを実行し、 tomcat.homeを呼び出し、org.apache.tomcat.startup.Tomcatを呼び出し、 ます。またコマンドライン引数をorg.apache.tomcat.startup.Tomcatに 渡します。
    1. 動作させる操作 start/stop/run/etc.
    2. このTomcatプロセスで使用するserver.xmlへのパス

    例えば、server.xmlがconf\server_1.xmlに有るとして、apacheを バックグラウンドで動作させたい場合には、次のようなコマンドに なります。

    bin\tomcat.bat start -f conf\server_1.xml

Win32版のtomcat.batは、Unixのそれと比較することができるので見たい場合には見れる。 特にも、TOMCAT_HOMEとJAVA_HOMEの値を推測しないこと全ての .jarファイルをclasspathに 持っていくわけではない。

Servlet Container Types

Tomcat(にかぎらずどんなサーブレット・コンテナ)は、ウェブ・サーバの後ろ で実行されます。ウェブ・サーバーはクライアント・ブラウザからの HTTP要求を受信することを担当します。サーブレット・コンテナは、 それらのURLのためにサーブレットとJSPにその要求の処理をします。

Tomcatの場合、3つ異なるの実行モードをサポートします。

  1. スタンドアロン・サーブレット・コンテナ
    これらは、ウェブ・サーバーの必要不可欠な部分である。 これは、Javaベースのウェブサーバー(例えば JavaWebServer の部分である サーブレット・コンテナ)を使用するときの場合である。 スタンドアロン型は、Tomcatのデフォルトモードである。大部分のウェブ・サーバは しかし、 Javaベースではないので、次の2つのコンテナ・タイプを率いる。
  2. 内部プロセス・サーブレット・コンテナ
    サーブレット・コンテナは、ウェブ・サーバーのプラグインと、Javaコンテナ実装 の組み合わせとなる。ウェブ・サーバー・プラグインは、JVMをウェブサーバー のアドレス空間の内側で開き、そこでサーブレット・コンテナを実行させる。 特定の要求がサーブレットを実行するならば、プラグインは、要求に 対する管理をして、サーブレットコンテナに JNI を使うことを渡す。 内部プロセス・コンテナは、マルチスレッド化されたひとつのプロセス・サーバ に最適な、良いパフォーマンスを提供するがスケーラビリティで制限される。
  3. 外部プロセス・サーブレット・コンテナ
    サーブレット・コンテナは、ウェブ・サーバ・プラグインと、ウェブ・サーバー の外側で走るJVMのJavaコンテナ実装の組み合わせとなる。 ウェブ・サーバー・プラグインは、JavaコンテナJVMは、若干のIPC機構( 通常TCP/IPソケット)を使うことを伝える。特定の要求がサーブレットを 実行するならば、プラグインは要求に対する管理をして、サーブレット・コンテナ に(IPCを使用して)パスする。外部プロセス・エンジンの応答時間は、 内部プロセスのそれよりも良くは無いが、外部プロセス・エンジンは、 多くの重要な点(スケーラビリティ、安定性、その他)においてよりよく 動作する。

Tomcatは、(主として開発とデバッグ用に)スタンドアロン・コンテナとしても 既存のウェブ・サーバ(現在は、Apache, IIS, Netscape サーバー)のアドオン としても使用できます。この意味は、Tomcatを配置するときには、それを使う 方法を決定しなければならないことであり、またオプション2,3を選択する 場合には、ウェブ・サーバー・アダプターを設置する必要があります。

もし Tomcatを最初に設定して、そのうちウェブ・サーバーに統合する 場合にはスタントアロン型で分離して実行したほうが良いでしょう。将来的に 統合したときに、エラーの切り分けができます - " エラーが Tomcatのせいなのかウェブ・サーバーのせいなのか ? "

Tomcatの設定

Tomcatは、2つのファイルから設定されます。:

  1. server.xml - Tomcatの全体設定ファイル
  2. web.xml - デフォルト配置記述

    server.xml - Tomcatのメイン設定ファイル

server.xml (TOMCAT_HOME の下の conf サブディレクトリにある) の要素は、 以下に説明されています。もうひとつのウインドウでデフォルトのserver.xml とともにつづくことは役に立つ。デフォルト server.xmlファイルは、下のコメント に取って代わるかもしれない多くのコメントがあります。 これは、how-toより多くのリファレンス・セクションです。

<Server> The topmost element. <Server> ひとつの Tomcat サーバーを定義する。 通常そのことを気にしてはならない
<xmlmapper:debug> server.xmlファイルの内容をどのように Tomcatが登録するかを心配しない限り、たぶんこれに決して触る必要がない。 たとえ心配するとしても、Tomcatのメイン・ログ・ファイルにおいて見つけられる 最初の出力が通常この目的には十分である。

属性:

  • level. "0" の意味は "何も出力しない". "9" の意味は "ほとんど何でも".
<Logger> この要素は、Loggerオブジェクト(ログ・ファイルに等しい)を定義します。現在、 loggersがサーブレット(ServletContext.log()が行くところ)とtomcat実行時の ためにあります。

属性:

  • name. loggerの識別子。 "tc_log", "servlet_log", or "JASPER_LOG"のうちのひとつ.
  • path. TOMCAT_HOMEと関連した出力ファイル "path"の値を省略すると標準エラー出力と標準出力が使用される。
  • verbosityLevel. 冗長出力の順番; "FATAL", "ERROR", "WARNING", "INFORMATION", or "DEBUG"のうちのひとつ.
<ContextManager> ContextManagerは、ContextInterceptors、RequestInterceptors、Contextと 彼らのコネクタの集合のために、設定と構造を指定する

属性:

  • debug. "0" 意味は "何も出力しない". "9" の意味は "何でも出力する".
  • home. すべてコンテキストで定義されたすべての webapps, conf, logs ディレクトリのベース位置。 TOMCAT_HOME以外のディレクトリからTomcatを開始するときに使用される。 この属性のデフォルト値は、TOMCAT_HOME
  • workDir. working directoryの名前、上記のhome属性に関連
<ContextInterceptor>
<RequestInterceptor>		 これらのインターセプターは、 ContextManagerで発生する特定のイベントに聞き耳を立てる。例えば、 ContextInterceptorは、Tomcatの開始とシャットダウン・イベントに聞き耳を立てる、 そして、RequestInterceptorはユーザ要求がそのサービスの間、通過する必要がある いろいろなフェーズを見る。Tomcatの管理者は、インターセプターについて多くを 知る必要はない。一方、開発者は、これがどのように操作の「グローパル」なタイプ (例えば、リクエスト記録やセキュリティ)で実装 される方法であることをしっていなければならならい。
<Connector> Connector は、ユーザー(ウェブ・サーバーまたは ユーザーのブラウザへの直接接続( スタンドアロン型 設定の場合)とのつながりを表します。 Connector オブジェクトは、ワーカー・スレッド管理のために、そして様様な クライアントからのソケット接続によるread/write 要求/応答 のために責任 があります。

属性:

  • className. どのコネクタを使用するか
このConnectorの設定についてはこのドキュメントのあとで説明します。
<Parameter> Connector 初期化パラメータ。 各Connectorの下で、必要に応じてこれらの要素をさらに同じだけ持つかもしれない。

属性:

  • name. "handler", "port", "socketFactory"のどれか.
  • value. 適切な値.
<Context> ぞれぞれの Context は、ウェブ・アプリケーションを置くTomcat階層を代表します。

属性:

  • path. どのContextがこの要求を処理するために使われなければ ならないのかについて、Tomcatに要求を伝えるためのURIのプレフィックスで ある特定のウェブアプリケーションのための context path 。 この属性は、必須で、スラッシュからはじめなければならない ('/') 文字
  • docBase. ウェブ・アプリケーションのroot。 関連する ContextManager のホームまたはフルパスが指定できる。 これは Apacheの "DocumentRoot" 指示の Tomcat版です。
  • reloadable. servletを開発するとき、自動的にTomcatにそれを再ロードさせることは非常に便利である。 そして、バグを修正して、Tomcatにコンテナを再開する必要なしで、新しいコードをテストすることが できるようになります。サーブレット再読み込みをONにするには、reloadableフラグをtureにします。 しかしながら、変更を見つけることは、時間がかかります。 さらに、新しいサーブレットが新しいclass-loaderオブジェクトでロードされるときに、この クラスを再ロードしているのをトリガーとしてエラーを投げる場合があります。 これらの問題を避けるために、reloadableフラグをfalseにセットすることができます。
  • trusted. FacadeManagerと内部オブジェクトにTomcatがアクセスすることを全て信頼する
  • debug. "0" は "出力しない". "9" は "なんでも出力する".
<Host> <Context> 要素に含まれる. <Host> 要素は、pre-virtual ホスト Contextsの設定のために使用される

属性:

  • name: 仮想ホストの完全修飾ホスト名または、IPアドレス
</ContextManager>
</Server>

    web.xml - デフォルト配置記述

web.xmlとウェブ・アプリケーション構造(ディレクトリ構造と設定を含む)の 詳細な記述は Servlet API Spec の9,10,13章において確認できます。これについては記述するつもりはない。 Tomcatでのアプリケーション開発 では、Tomcatでのウェブ・アプリケーションと配置をカバーしている。 時間を取って通しでServlet API Spec! を読んでいないならば、それは必要なことです。

web.xmlに関連した小さな「機能」がTomcatにある。 Tomcatは、ユーザーにデフォルトのweb.xmlファイルをTOMCAT_HOMEの confサブディレクトリに置くことによって全てのコンテキストのため にデフォルトのweb.xml値を定義させる。 新規にConextを作成するときに、Tomcatは、ベース設定としての デフォルトのweb.xmlファイルを使用して、それからアプリケーション特性 web.xml(アプリケーションの WEB-INF/web.xmlファイル)設定を適用する。 これはTomcatで、あなたが空のweb.xmlファイルを持っていけることを 意味すま。そして、要素 <web-app/>, や (もっと現実的に)必要とする要素だけ(例えば、マッピングとmime-type) だけ含める。 しかし、これはあなたのwebappのポータビリティを制限するので 、それは完全なweb.xmlファイルを使用すると勧められる。 あなたは、その代わりにTOMCAT_HOME/conf/web.xmlをコピー したいかもしれなくて、それを修正するかもしれない。

我々は以降のセクションにおいてweb.xmlの特定の面をカバーする、 そこで、それはTomcatでアプリケーション配置と相互作用に付随する。

ウェブ・アプリケーションの配置

ウェブ・アプリケーションとは?

[??? - このセクションを Tomcat設定セクションの上に移動したほうが良いか? server.xml他を紹介する前に、またその後に webappsについて教えなければ なないどうか明らかではない ]

ウェブ・アプリケーション (または "webapp") は、 Servlet Specification version 2.2. [2.1?] で紹介された概念です。 あなたは、明確に仕様を読まなければならない。 仕様(9章)から:

ウェブ・アプリケーションは、servlets、htmlページ、クラスと 束になることができて、複数のベンダーから複数のコンテナで 動くことができる他のリソースのコレクションである。 ウェブ・アプリケーションは、ウェブ・サーバーの範囲内で特定 のパスで根づく。 例えば、カタログ・アプリケーションは、http://www.mycorp.com/ カタログに位置することができた。 カタログ・アプリケーションを表すServletContextに、この接頭辞 から始める全ての要求は、経由する。

servletコンテナは、また、ウェブ・アプリケーションの自動生成に対する 規則を確立することができる。 例えば、 ~user/ マッピングをウェブ・アプリケーションの /home/user/public_html/ へとマップできる。

[...]

ウェブ・アプリケーションは、ディレクトリの階層構造として存在する。 この階層のルートは、このコンテキストの一部であるファイルを 対応するためのドキュメントルートとして役に立つ。 例えば、ウェブ・アプリケーションでウェブサーバー上で /catalog としていつづけられるときに、index.htmlファイルは、ウェブ・アプリケーション 階層のベースの位置は、/catalog/index.htmlへの要求を満たすために 提供される。

「WEB-INF」と名前の付けられた特別なディレクトリがアプリケーション階層内に存在する。 このディレクトリは、アプリケーションのドキュメントルートに存在しない アプリケーションに関連するすべてのものが含まれる。 WEB-INFノードがアプリケーションの publicドキュメントツリーの一部でない点に注意する ことは重要である。 WEB-INFディレクトリ内に含まれるファイルは、直接クライアントに提供されないかもしれない。

WEB-INFディレクトリの内容は:

サンプル・ウェブ・アプリケーション・ディレクトリ構造

サンプル・ウェブ・アプリケーションの全てのファイルのリストの図示: 

/index.html
/howto.jsp
/feedback.jsp
/images/banner.gif
/images/jumping.gif
/WEB-INF/web.xml
/WEB-INF/lib/jspbean.jar
/WEB-INF/classes/com/mycorp/servlets/MyServlet.class
/WEB-INF/classes/com/mycorp/util/MyUtils.class

TOMCAT_HOME/conf/server.xmlに <Context> タグを追加することによって ローカルファイルシステム上にあるWARファイルを配置することができます。 例えば、 

<Context path="/mywebapp" 
  docBase="/home/alex/webapps/mywebapp" 
  reloadable="true" >
</Context>

WAR ファイルとは?

"WAR. へぇ! それは何にいいんだい?" - Edwin Starr

WAR (または "web archive") ファイルは、単純にパッケージ化された webappディレクトリです。それは標準 Java jarツール によって作成されます。 例えば: 

cd /home/alex/webapps/mywebapp 
jar cf mywebapp.war *

Tomcatでの WARファイルの配置

現在 (バージョン3.2)では、新しいWARファイルを配置するための手順は:

  1. Tomcatを停止する.
  2. 存在する配置を削除する 以前に TOMCAT_HOME/webappsに "foo.war" を配置していた場合には、 webapps/foo/.... に展開されています。このディレクトリと中身を全て削除 しなければなりません。Unixでは、 
    rm -r $TOMCAT_HOME/webapps/foo
    とします。
  3. WARファイルを TOMCAT_HOME/webapps/ にコピーする.
  4. Tomcat を開始する.

この手順は、将来的にもっと簡単になる予定です。 "deploy tool" は、Tomcatの "to-do" リストにあります。

注意: あなたがこのようにWARファイルを展開するならば、 あなたがserver.xmlにいかなる変更も する必要がない−サーバーが動き出すとき、それは自動的に 認識されて、活性化される。 しかし、あなたがこのwebappのために非デフォルト・オプションを 指定したいならば、あなたは<Context docBase="webapps/foo&quo ...

How do I deploy a WAR file in Tomcat? jGuru FAQ参照のこと.

Tomcatチュートリアル

これらのチュートリアルは、Tomcatが独立型コンテナとして働 いているという仮定で動く。我々が前に言ったように、あなたが 使っている特定のウェブ・サーバーにかかわりなく、Tomcatの 機能性がわかることは役に立つことがありえる。二と追うものは 一兎も得ずだ。統合は、以降のセクションの後でカバーされる。

[注: なにかのチュートリアルをここに追加しとく :-) ]

現実世界での設定 Tips

デフォルトでTomcatの配布では、ネイティブ設定でやってくるため 本当の目的は、最初の時間でユーザ経験を促進することにある。 そして「out of the box」操作.... この構成は、しかし本当のサイトでTomcatを展開する最高の方法ではない。 例えば、本当のサイトは、いくらかのパフォーマンス・チューニングと サイトに特有の設定（例えば、追加のパス要素）を必要とするかもしれない。 このセクションでは、Tomcatベースのサイトで発表する前に行わなければ ならない最初のステップについて方向づけようとしている。

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

前のセクションで、起動スクリプトは便利なものであると述べました。しかし、 しかし、時によって配置のために必要とされるスクリプトは修正されなければ ならなものです。

これらの変更の一部は、基本スクリプトに対する変更無しで可能です。 例えば、tomcatスクリプトは、環境変数 TOMCAT_OPTS を使用して 　　　　JVMにメモリ設定などの特別なコマンド行引数を設定することができます。 UNIX では、あなたのホームディレクトリに ".tomcatrc" という名前のファイルを作成して、Tomcat がこのファイルから PATH, JAVA_HOME, TOMCAT_HOME, CLASSPATHといった環境情報を取ることができます。 しかしNTでは、(そしてまたUNIX上でも、JVMコマンドラインに対して何か 修正をしたい場合には)、起動スクリプトの一部を書き直すことを強制されます...
躊躇せず、ちょっとやてみてください。

デフォルトJVM設定の修正

tomcatスクリプトのデフォルトJVM設定は、とてもna・eです。 なにもかもがデフォルトの残されます。 Tomcatのパフォーマンスを向上させるために考慮しなければならないものが 2,3あります。

  1. JVMメモリ設定を修正しなさい。 通常、JVMは、 初期サイズをJavaヒープのために割り当て、あなたがこのメモリ量より 多く必要になったら、得られません。
    それにもかかわらず、ロードした サイトでは、JVMにより多くの記憶を与えることは、Tomcatのパフォー マンスを向上させます。コマンド行パラメータとして -Xms/-Xmx/-ms/-mx を 使用してJavaヒープの最小/最大のサイズを指定します。(そしてパフォーマンス が向上したか確認します)。
  2. JVMスレッド設定を修正しなさい。SUN JDK1.2.2 for Linux は、グリーンスレッドとネイティブスレッドの両方をサポート しています。一般に、ネイティブスレッドは、I/Oに縛られたアプリケーション のパフォーマンス向上させることを提供することが知られています。 一方、グリーンスレッドは他方より少ないマシン負荷となります。 これらの2つのスレッドモデルで実験して、どのモデルがあたなのサイト のためにより良いか確認すべきです。(一般にネイティブスレッドの方が 良いです。)
  3. タスクに最適なJVMを選択しなさい。いくつかのJVMベンダーがあります。 例えば、今日(2000年3月21日)現在で、Linux用には、2つの製品レベルの JVMがあります。SUN JDK1.2.2 と IBM JDK1.1.8 です。あなたのアプリケーション が特定のJDK機能を必要としないならば、2つのJVMをベンチマークで テストして、良いものを選択してください。 私の(Gal Shachor) の内部テストでは、Sunによって作られたものよりも IBMのJVMの方がかなり早いことがわかりました。あなたは、自分自身のために それをチェックして、計画して、決定してください。

Connectors の修正

Tomcatのデフォルトで構成される server.xml には、次のserver.xml断片 の場合のように構成される2つのConnectorを含みます。

server.xmlでの2つのデフォルトConnector 
        <!-- (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-process 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要求のためにポート8080で監視するコネクタです。 この connector　はスタンドアロンで使用する場合必要です。
  2. 入ってくるAJPV12要求のためにポート8007で監視するコネクタです。 このコネクタはウェブ・サーバーと統合するために必要です。 (外部プロセスサーブレット統合)
分別のあるTomcat配置では、外部プロセスサーブレット統合かまたは スタンドアロン運用のどちらかをしようすることが明白なので、 不要なコネクタを削除することは重要です。

コネクタでスレッドブールを使う

Tomcatは、マルチスレッド・サーブレット・コンテナです。これは、各 要求がいくつかのスレッドによって実行される必要があることを意味しています。 デフォルトでは、要求が到着するとTomcatは新しいスレッドを作成して 開始して、要求を処理します。この振る舞いはロードしたサイトでは 問題を含みます。

この問題のための解決策は、thread poolを使用することです。 スレッド・プールは使用しているサーブレット・コンテナは、 彼ら自身を彼らのスレッドを直接管理することから解放します。 新しいスレッドを割り当てる代わりに; スレッドを必要とするときはいつでも、 プールからそれを求め、終了したらスレッドはブールに返されます。 スレッド・プールが、現在、洗練されたスレッド管理技術を実装するために 使用することができます、例えば:
  1. スレッドを「開い」ておいて、何度も再利用する。 これはスレッドを絶え間なく作成と破棄することで発生する 問題を省きます。
    • 通常、管理者はプールにあまり多くの動いていないスレッドを 保持しないように指示でき、必要ならば解放できる。
  2. 同時使用するスレッド数の上限を設定する。 これは、無制限にスレッド割り当てと結び付けられるリソース 割り当て問題を防ぎます。
    • コンテナの最大がスレッド上限を超えた場合、新しい要求は、他のどれかの(前の) 要求がサービスに使われるスレッドが終了して、解放されるのを待たなくてはならない。
あなたは、上記のさまざまな方法のテクニックを洗練することができますが、それは 改良だけです。スレッド・プールの主な貢献は、スレッド再利用と、同時実行の上限を 設定することによるリソースの使用制限です。

Tomcatでのスレッド・プールの使用は簡単な変更で済みます。<Connector> 設定で、PoolTcpConnectorを使用するだけです。例えば、以下のserver.xml の断片では、ajpv12でプールされたコネクタを定義しています。

Pooled ajpv12 Connector 
        <!-- A pooled AJPV12 Connector for out-of-process operation -->
        <Connector className="org.apache.tomcat.service.PoolTcpConnector">
            <Parameter
                name="handler"
                value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
            <Parameter
                name="port"
                value="8007"/>
        </Connector>
この断片は非常に単純で、そして、それによって指示される(デフォルト)のプールの振る舞いは

デフォルトの設定では、平均して10〜40の同時要求の中程度の負荷のサイトに適しています。 あなたのサイトがことれは異なるのであれば、この構成(例えば、上限を減らす)など修正しなければなりません。 poolの設定は、次の server.xmlの断片で <Connecor>を通じてデモしています。

スレッド・プールの設定 
        <!-- A pooled AJPV12 Connector for out-of-process 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>
poolに3つの設定パラメータがあることがわかります。

ブール挙動をニーズに合わせるためには、上記のパラメータを使用 しなければならない。

サーブレット自動再読み込みを禁止する

サーブレットの自動再読み込みは、開発時には本当に便利です。 しかし、特定のクラスローダーによってロードされたクラスが現在の クラスローダーによってロードされるクラスと協力することができない とき、それは非常に高価(パフォーマンス低下用語)で、アプリケーション を奇妙な対立にしてしまうかもしれない。

それで、クラスの本当の必要がない限り、展開の間、再ロードすることは コンテキストにおいてreloadableフラグをオフにしなければならない。

Tomcatを /etc/initab から開始する

残念なことに、Apache(または他のサーバーでも)のために開発される アダプターは、まだTomcatの開始ができない。しかし、UNIX上では マシンスタートアップ時に自動的にTomcatを開始させるためにinitテーブルを 使用することができます。 FIXME:

Credits

Tomcat は、オリジナルは、サン・マイクロシステムズによって書かれ、cast of thousands によって改善されている(希望).

本ドキュメントの作成は:

協力(アルファベット順):

Copyright ©1999 The Apache Software Foundation
Legal Stuff They Make Us Say
連絡先