The Jakarta Project The mighty Tomcat - Meow!

mod_jkの使用方法

Gal Shachor著 <shachor@il.ibm.com>

目次


mod_jkとは何か

mod_jkは、以前の mod_jserv を置き換えるものです。 これはTomcatとApache間の通信を処理する完全に新しい Tomcat-Apache プラグインです。


なぜ mod_jk なのか?

以下のような理由があります。


私にとってどのような意味があるか?

新しい簡単な設定メカニズムを知る必要がありますが、 このメカニズムを一度学べば、ApacheやマイクロソフトのInternet Information Server (IIS)やiPlanet Enterprise Web Serverのような他のWebサーバ上でもTomcatをすぐ配備できます。


定義と用語

このドキュメントの中で私が使用する用語を以下のように定義します。

用語

意味

ワーカプロセス (worker process)

ワーカは、Web サーバから来たservletのリクエストを処理するTomcatのインスタンスです。 多くの場合には、ワーカは一つ (一つのワーカと、一つのTomcatプロセスだけです) ですが、負荷分散やサイトの分割をおこなうために、複数のワーカを実行することもあります。 Webサーバは、各ワーカを、それが配置されたホストと、接続待ちしているポート番号、メッセージ交換に使用される通信プロトコルによって識別します。

プロセス内ワーカ (in-process worker)

これは特殊なワーカです。 別プロセスである Tomcat プロセスと一緒に動作するのではなく、 Web サーバが JVM をオープンし、Web サーバプロセスのアドレス空間の中で Tomcat を実行します。 この文書では、この特殊なワーカについては解説しません。

Web サーバプラグイン (Web server plug-in)/ tomcat リダイレクタ (tomcat redirector)

さまざまなWeb サーバと協調する Tomcat には、Web サーバ内に存在して、Servlet リクエストを送信してくれる"エージェント"が必要になります。 これがWebサーバプラグインですが、私たちの場合のWebサーバプラグインは mod_jk です。 このリダイレクタをWebサーバに組み込めるように、たいていはDLLまたは共有オブジェクトモジュールの形式で配布されます。

プラグイン設定 (plug-in configuration)

他の Tomcat ワーカにリクエストを転送するためには、Webサーバプラグインを設定する必要があります。 この情報には、プラグイン設定の一部であるログレベルのような内部パラメタも含まれます。

Web サーバ設定 (Web server configuration)

Webサーバは、その動作を定義する設定を持っています。 たとえばどのポート番号で接続待ちするのか、どのファイルを配信するのか、どの Web サーバプラグインをロードするかなどです。 そこで、Tomcat リダイレクタのmod_jkをロードするためには、それを指示するようにWebサーバの設定を変更する必要があります。


mod_jkの入手

mod_jkは、2種類のフォーマット - バイナリとソース - で入手することができます。 あなたがWebサーバを動作指せているプラットフォームによっては、mod_jkのバイナリ版が利用可能です。 それが利用可能な場合には、バイナリ版を使用することを勧めます。 バイナリが利用可能でない場合には、mod_jkをソースからビルドするために以下の指示に従ってください。 この節の最後に、特定のプラットフォームに対する推奨が記述されていることに注意してください。

mod_jkのバイナリ

mod_jkのバイナリは、Tomcatのバイナリリリースと同じ場所で、いくつかのプラットフォームに対して利用可能です。 このバイナリは、プラットフォームごとのサブディレクトリの中にあります。 Windowsのようないくつかのプラットフォームに対しては、大部分のWindowsシステムはCコンパイラを持たないことから、これがmod_jkを入手する代表的な方法です。 他のプラットフォームに対しても、mod_jkのバイナリ配布はインストールをより簡単にします。

たとえば、http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.3-m1/bin/のTomcat 3.3 M1リリースは、以下のようなバイナリを含んでいます。

linux/i386/ 標準APIだけでなくEAPIのApache 1.3のmod_jk.soと、Apache 2.0のmod_jk.soを含んでいます。
netware/ mod_jk.nlmとnsapi.nlmを含んでいます。
win32/ Windows用のmod_jk.dllだけでなく、他の便利なバイナリを含んでいます。

最新のバイナリについては、このサイトをチェックしてください。

注意: mod_jkのバージョンは、Tomcatのバージョンに依存しません。 mod_jkのTomcat 3.3の配布は、Tomcat 3.2.1のような他のTomcatの3.xバージョンでも正しく機能します。

mod_jkのビルド

すべてのWindowsと大部分のUnixプラットフォーム用のソース配布で、mod_jkは利用可能です。 mod_jkのソースは、Tomcatのバイナリ配布のTOMCAT_HOME/native/mod_jk/ディレクトリの中に含まれています。 このディレクトリは、Webサーバ名とバージョンに基づいて構成されています。 各ディレクトリは、ソースだけでなく適切なビルドスクリプト、makeファイルまたはプロジェクトファイルも含んでいます。

NT用のmod_jkのビルド

リダイレクタは、Visual C++バージョン6.0を用いて開発されたので、あなたがカスタムビルドを実行したい場合には、この環境が不可欠です。

以下の手順を実行する必要があります。

  1. あなたのApacheのバージョンに応じて、apache1.3またはapache2.0 のソースディレクトリにディレクトリを移動します。
  2. APACHE1_HOME環境変数がApacheがインストールされている場所を指すように設定します。
  3. 次のコマンドを実行します。
    MSDEV mod_jk.dsp /MAKE ALL

    msdevがあなたのパスに存在しない場合には、msdev.exeのフルパスを入力してください。 また、ApacheCore.libがAPACHE1_HOME\src\CoreDの中に存在して、APACHE1_HOME\src\CoreRディレクトリの前にリンクされる必要があります。 さらに、これらのライブラリを作成するためには、Apacheのソースをビルドする必要があります。
  4. mod_jk.dllをApacheのmodulesディレクトリにコピーします。

この方法で、リダイレクタプラグイン (mod_jk) のリリース版とデバッグ版の両方を作成できます.

他にmsdevのmod_jk.dspをオープンして、ビルドメニューを使って作成する方法があります。

Unix用のmod_jkのビルド

Apache

  1. あなたのApacheがDSOサポートを持っているかどうかを調べてください。 これは、$APACHE_HOME/bin/httpd -lによってチェックできます。 この出力の中に"mod_so.c"が見つかれば、DSOサポートが利用できます。 ない場合には、Apacheを再コンパイルするか、再インストールしなければならないでしょう。
  2. あなたのApacheがEAPIサポートを持っているかどうかを調べてください。 ソースからコンパイルしたならば、(たぶんmod_sslと一緒に)自分自身で追加しない限り、EAPIはたぶんコンパイルされていません。 あなたのApacheの設定に合わせて、EAPIを持っている、またはEAPI持っていないmod_jk.soをビルドする必要があります。 適合しないmod_jk.soをインストールした場合は、$APACHE_HOME/bin/apachectl configtestがあなたに警告してくれるでしょう。
  3. Perl 5がインストールされているかを確認します。 モジュールをビルドに使用されるapxsスクリプトは、Perlで書かれています。
  4. TOMCAT_HOME/native/mod_jk/apache1.3 (またはapache2.0)に、ディレクトリを移動します。
  5. mod_jk.soをビルドします。 以下が、あなたが試すことができる3つの手順であり、簡単な方から順番に実行してください。

    1. あなたのプラットフォーム用のビルドスクリプトを実行します。 あなたのプラットフォーム用のビルドスクリプトが利用できなければ、./build-unix.shを使用してmod_jkをビルドすることができるかもしれません。 このスクリプトは、いくつかの変数を設定して、以下のようにapxsを呼び出し、mod_jk.soを$APACHE_HOME/libexecにコピーしようとします。 失敗した場合は、以下のように手でおこなう必要があります。
      • あなたのシェルのJAVA_HOMEを設定します。 例、"set JAVA_HOME=/usr/local/jdk1.2.2; export JAVA_HOME"
      • あなたのシェルのAPACHE_HOMEを設定します。 例、"set APACHE_HOME=/usr/local/apache; export APACHE_HOME"
      • build-unix.shファイルの中のコメントアウトされている次の行を元に戻して、"linux"をあなたのインストールのためのJavaのincludeディレクトリで指定されている名前に置換します。
        # JAVA_INCLUDE="-I ${JAVA_HOME}/include -I ${JAVA_HOME}/include/linux"
    2. build-unix.shが失敗した場合は、同じディレクトリの中のMakefileを使用すればうまくいくかもしれません。 例、"make -f Makefile.linux mod_jk.so"
    3. 最後に、それを手でビルドしようとすることもできます。 あなたのApacheの配布に付属してきたapxsコマンドを実行します (ヒント: /usr/local/apache/bin、/usr/sbin、またはApacheをインストールした場所を調べてみてください)。 そのコマンドのすべてを、一行で入力してください。


      Linuxの場合:

      apxs -o mod_jk.so -I../jk -I/usr/local/jdk/include -I/usr/local/jdk/include/linux -c *.c ../jk/*.c

      ソースディレクトリではなくカレントディレクトリに対して、../jkディレクトリからオブジェクトファイルがコンパイルされると、あなたのビルドは失敗するかもしれません。 その場合には、gcc -shared -o mod_jk.so *.oを実行すれば、そのビルドを終了できます。


      Solarisの場合:

      build-solaris.shスクリプトを以下のように使用します。

      # sh build-solaris.sh

      これは、mod_jk.soをビルドして、apache/libexecディレクトリの中にインストールします。 このスクリプトは、あなたのJavaとApacheのホームの位置についての設定も含んでいます。 これらが、あなたのインストールに従っているかを確認してください。 このデフォルトの設定は、 JAVA_HOME=/usr/javaAPACHE_HOME=/usr/local/apacheです。 あなたのインストールが異なる場合には、 build-solaris.shスクリプトを編集して、これらの値を適切に変更する必要があるでしょう。

      より詳しくは、TOMCAT_HOME/native/mod_jk/apache1.3の中にあるREADME.solarisを参照してください。

      ビルドスクリプトが動作しない場合には、以下のようにmod_jkをビルドすることもできます。

      $APACHE_HOME/bin/apxs -o mod_jk.so -DSOLARIS -I../jk -I/usr/java/include -I/usr/java/include/solaris -c *.c ../jk/*.c

      あるシステムでは、これはモジュールを正しくビルドしますが、実行時に"symbol "fdatasync" not found"というエラーで失敗することがあります。 これを修正するためには、上記のコマンドの-cの直前に、-lposix4を追加してください。


      HP-UX 11.00の場合:

      build-hpux.shスクリプトを以下のように使用します。

      # sh build-hpux.sh

      これは、mod_jk.soをビルドして、apache/libexecディレクトリの中にインストールします。 このスクリプトは、あなたのJavaとApacheのホームの位置についての設定も含んでいます。 これらが、あなたのインストールに従っているかを確認してください。 このデフォルトの設定は、 JAVA_HOME=/opt/java1.3APACHE_HOME=/usr/local/apacheです。 あなたのインストールが異なる場合には、 build-hpux.shスクリプトを編集して、これらの値を適切に変更する必要があるでしょう。

      さらに、2つのHP-UXビルドスクリプトがあることに注意してください。 一つのスクリプトは、mod_jkをGNU GCCを使用してJNIサポートなしでビルドするように書かれています。 もう一つのスクリプトは、mod_jkをJNIサポートつきでビルドします。 ただし、このスクリプトにはHP ANSI Cコンパイラ(カーネルを再ビルドするためにHP-UXに含まれている機能が削減されたCコンパイラではありません)が必要です。 HPコンパイラが必要なのは、64ビットアプリケーション用のdlopen()と関連した共有ライブラリがこれでのみ利用できるからで、GCCの現在のバージョンでは信頼できる64ビットアプリケーションは作成できません。

      build-hpux.shは、HP-UX 10.00でも動作します。

      より詳しくは、TOMCAT_HOME/native/mod_jk/apache1.3の中にあるREADME.hpuxを参照してください。


      他のUnixの場合(FreeBSDも含む):

      jk_util.cの中のfsync()をfdatasync()に置換する必要があるかもしれません。

      IRIXとAIXでは、build-hpux-cc.shスクリプトを変更しなければいけません。 スクリプトを編集して、APACHE_HOMEとJAVA_HOMEを必要に応じて変更してください。


      あなたがEAPIを使用している場合には、 apxsコマンドのmod_jk.soの後に-DEAPIを追加してみてください。

      apxsが、 apxs:Break: Command failed with rc=255というエラーで失敗する場合には、mod_sslによって損なわれているかもしれません。 以下の部分を探して、

      my $CFG_LD_SHLIB      = q();          # substituted via Makefile.tmpl
      my $CFG_LDFLAGS_SHLIB = q(); # substituted via Makefile.tmpl
      

      次のように変更してください。

      my $CFG_LD_SHLIB      = q(ld);          # substituted via Makefile.tmpl
      my $CFG_LDFLAGS_SHLIB = q(-G); # substituted via Makefile.tmpl
      

      あなたがJavaを別のディレクトリにインストールした場合には、それに従って変更してください。

      他のUnixの場合には、うまくビルドできなければいけませんが、apxsの引数の順番が重要である!ということを覚えておいてください。

  6. さあ、mod_jkライブラリをコピーしましょう。 # cp mod_jk.so $APACHE_HOME/libexec (ビルドスクリプトがこれをしようとするので、まずsuを実行しなければならないかもしれないことに注意してください。)

他のWebサーバ

TOMCAT_HOME/native/mod_jk/ディレクトリの下の他のディレクトリの中にいくつかのMakefileが含まれています。 あなたは他のWebサーバに関する特有の情報をTomcatのドキュメントで確認しておく必要があります。


Apacheの設定

この節は、Apache Webサーバがmod_jkをサポートするために必要な設定について詳しく説明します。

mod_jserv指示子の削除

すでにmod_jservを使用するようにApacheを設定している場合には、httpd.confからすべてのApJServMount宣言子を削除してください。 tomcat-apache.conftomcat.confをインクルードしている場合には、それらのファイルはmod_jserv固有なので、同様に削除します。 mod_jserv設定指示子は、mod_jkとは互換ではありません!

mod_jkを使用するApacheの設定

mod_jkを使用するようにApacheを設定する最も簡単な方法は、TomcatのApacheの自動設定設定を有効にして、次のinclude指示子をApacheのhttpd.confファイルの最後に記入することです(以下のTOMCAT_HOMEをあなたがTomcatをインストールした正しい場所に置換したことを確かめてください)。

Include TOMCAT_HOME/conf/jk/mod_jk.conf-auto

例:

Include /usr/local/jakarta-tomcat/conf/jk/mod_jk.conf-auto

これは、Apacheの設定の中のApacheにmod_jk.conf-autoファイル中の指示子を使用することを命じます。 このファイルは、以下のTomcatの設定の節[Tomcatの設定]で述べられているように、Apacheの自動設定を有効にすることによって作成されます。

注意:  あなたがTomcat-Apacheの自動設定を使用するつもりならば、この節の残りを飛ばして、Tomcatの設定から読んでください。

カスタマイズされた設定は、自動設定を有効にして、そのTOMCAT_HOME/conf/jk/mod_jk.conf-autoファイルを、TOMCAT_HOME/conf/jk/mod_jk.conf-localのような自分自身の設定ファイルとしてコピーすることで作成できます。

基本的な設定を、次に示します。

  • 指示子JkLogStampFormatは、mod_jkのログファイルに記録される日付/時刻フォーマットを設定します。 デフォルトは、strftime()フォーマット文字列を使用して、"[%a %b %d %H:%M:%S %Y] "に設定されます。
  • 簡単な例として、あなたのhttpd.confファイルに以下のコードを取り込んでください。
    LoadModule    jk_module  libexec/mod_jk.so
    AddModule     mod_jk.c
    JkWorkersFile /usr/local/jakarta-tomcat/conf/workers.properties
    JkLogFile     /usr/local/apache/logs/mod_jk.log
    JkLogLevel    info
    JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
    

    TomcatへのURLの割り当て

    もしあなたが上記のようにmod_jk.conf-localのカスタマイズしたまたはローカルのバージョンを作成するならば、あなたはそのワーカまたはURLのプリフィックスのように設定を変更することができます。

    mod_jkのJkMount指示子を用いて、TomcatにURLを割り当てます。 一般的な、JkMount指示子の構成を、以下に示します。

    JkMount <URL prefix> <Worker name>
    

    たとえば、以下のように指示子を用いた場合には、 すべての.jspで終了するリクエストや、/servlet/で始まるすべてのリクエストは、"ajp13"ワーカに送信しますが、 /otherworker内に配置されているファイルに対するJSPリクエストは "remoteworker"に送信します。

    JkMount /*.jsp ajp13
    JkMount /servlet/* ajp13
    JkMount /otherworker/*.jsp remoteworker
    
    トップレベルか、あなたのhttpd.confファイルの<VirtualHost>セクションの中で、JkMount指示子を使用することができます。
    これだけで、設定は終了です。 Tomcatとapacheを起動すれば、 tomcatとapacheが協調してservletとJSPファイルを処理できます。

    Tomcatの設定

    TomcatのApacheの自動設定機能の有効化

    たいていの簡単な場合では、Tomcatが必要なApacheの設定を生成できます。 Tomcatが起動した時にmod_jkを使用するApache用の設定ファイルを自動的に生成するようにTomcatを設定することができます。 前の節(Apacheの設定)に示されたように、このファイルをhttpd.confに取り込めば("Include TOMCAT_HOME/conf/jk/mod_jk.conf-auto"を追加します)、あなたはほとんど何もする必要はありません。

    TomcatをApacheの自動設定を生成するように設定するために、<AutoWebApp ... />の後のTOMCAT_HOME/conf/server.xmlファイルの次のブロックを追加します。

    <ApacheConfig />
    

    これで、TomcatとApacheを起動して、ApacheサーバからTomcatにアクセスできるようになります。

    注意: mod_jkの自動設定の設定は、Tomcat 3.3の新しい機能です。 Tomcatの古いバージョンでは、server.xmlの中の指示子がなくても、自動設定ファイルを作成します。 Tomcat 3.3の新しい指示子には、この節の後で詳しく述べるように追加の設定オプションを指定できます。 Tomcatの古いバージョンでは、そのバージョンに添付されているドキュメントを参照してください。

    たとえば、デフォルト以外のURL プレフィックスをマウントするなどの、 何か特別な要求がある場合には、 このファイルをカスタマイズされる設定のベースとして使用して、 別のファイルにその結果を保存することができます。 自分自身でApacheの設定を管理する場合には、新しいコンテキストを追加する時には常にこのファイルを更新する必要があります。

    新しいコンテキストを追加した後には、TomcatとApacheを再起動する必要があります。 これは、Apacheが再起動せずに設定を変更する機能をサポートしていないからです。 さらに、 Tomcatを起動した時にファイルTOMCAT_HOME/conf/jk/mod_jk.conf-autoを生成するので、Apacheを起動する前にTomcatを起動しておく必要があります。 Tomcatは、 起動する度にTOMCAT_HOME/conf/jk/mod_jk.conf-autoを上書きするので、カスタマイズした設定をどこかに保存しておく必要があります。

    たとえば、変更する前に TOMCAT_HOME/conf/jk/mod_jk.conf-auto to TOMCAT_HOME/conf/jk/mod_jk.conf-local をコピーします。 最初にあなたの設定のこのファイルを生成するためには、Tomcatを一度起動する必要があるでしょう。

    <ApacheConfig />ブロックの中の設定オプションによって自動的に生成されるファイルの位置を指定することもできます。 次に詳しい文法を示します。

    < ContextManager ... >
      ...
      <ApacheConfig options />
      ...
    < /ContextManager >
    

    このoptionsは、次の属性を含むことができます。

     例:

    ...
    
    <AutoWebApp dir="webapps" host="DEFAULT" />
    
    <ApacheConfig confighome="/home/mydir" />
    
    ...

    (オプション) AJPv13プロトコルを使用するTomcatの設定

    mod_jkは、オリジナルのAjpv12プロトコルと新しいAjpv13プロトコルのどちらか一方を使用することができます。 デフォルトでは、両方のプロトコルが有効になっています。 Tomcatの"Ajp13"コネクションハンドラは、より高速なプロトコルであるという恩恵と、HTTPS経由でおこなわれたリクエストを判定できる能力を提供します。

    次のブロックでは、TOMCAT_HOME/conf/server.xmlファイルの中のAjpv13を有効にします。
    <RequestInterceptor
      className="org.apache.tomcat.modules.server.Ajp13Interceptor"
      port="8009"/>
    

    server.xmlファイルは、ポート8007のAjp12接続(mod_jservによって処理されます)のためにすでにこれとよく似たブロックも持っています。 Ajp13しか使用しないと思った場合でさえも、このコネクタを削除したいとは思わないでしょう。 というのは、これはTomcatを停止するために必要だからです。

    (オプション) "workers"の定義

    ワーカのマニュアル設定

    ワーカは、ファイル TOMCAT_HOME/conf/jk/workers.propertiesを使用して設定されます。 より多くの情報がドキュメントworkers.propertiesの手引きに書かれているので、まずこれを最初に読んでください。 しかし、急いでいる場合には、ファイルworkers.propertiesを編集して、workers.tomcat_homeworkers.java_homeps変数を、あなたのシステムにとって正しい値に設定すれば、たぶん使用できるでしょう。


    設定例

    これは、実際のさまざまな設定を反映していると思われる設定の例です。 このサイトは、TomcatとApacheを2つのバーチャルホストで使用しています(そのうちひとつはHTTPSを使用していて、mod_sslで処理していると仮定します)。

    .jspで終わるURLと、/servletで始まるURLは、Tomcatが処理しますが、残りはApacheが処理します。 それぞれのホストのファイルは、それぞれ/web/host1と/web/host2のサーバに存在します。

    この例は、非常に簡略化しすぎたので不完全かもしれませんが、あなたの役に立つでしょう。 また、バーチャルホストの設定は、Tomcat 3.2で新しくなったことに注意してください - つまり、この例はTomcat 3.1では動作しません。

    .
    .
    <Connector className="org.apache.tomcat.service.PoolTcpConnector">
      <Parameter name="handler" value="org.apache.tomcat.service.connector.Ajp12ConnectionHandler"/>
      <Parameter name="port" value="8007"/>
    </Connector>
    
    <Connector className="org.apache.tomcat.service.PoolTcpConnector">
      <Parameter name="handler"  value="org.apache.tomcat.service.connector.Ajp13ConnectionHandler"/>
      <Parameter name="port" value="8009"/>
    </Connector>
    
    <Host name="host1.apache.org">
      <Context path="" docBase="/web/host1" debug="0"/>
    </Host>
    <Host name="host2.apache.org">
      <Context path="" docBase="/web/host2" debug="0"/>
    </Host>
    .
    .
    
    表 1 - Ajp13コネクタと2つのバーチャルホストを示すserver.xmlの抜粋

    # Setup for Solaris system
    #
    workers.tomcat_home=/usr/local/jakarta-tomcat
    workers.java_home=/usr/java
    ps=/
    worker.list=ajp12, ajp13
    
    # Definition for Ajp13 worker (Ajp12 left to readers imagination)
    #
    worker.ajp13.port=8009
    worker.ajp13.host=localhost
    worker.ajp13.type=ajp13
    
    表 2 - Ajp13ワーカを示すworkers.propertiesの抜粋

    # Load mod_jk
    #
    LoadModule    jk_module  libexec/mod_jk.so
    AddModule     mod_jk.c
    
    # Configure mod_jk
    #
    JkWorkersFile /usr/local/jakarta-tomcat/conf/jk/workers.properties
    JkLogFile     /usr/local/apache/logs/mod_jk.log
    JkLogLevel    info
    
    # First Virtual Host.
    #
    <VirtualHost 10.0.0.1:80>
      DocumentRoot /web/host1
      ServerName host1.apache.org
      JkMount /*.jsp ajp13
      JkMount /servlet/* ajp13
    </VirtualHost>
    
    # Second Virtual Host. Also accessible via HTTPS
    #
    <VirtualHost 10.0.0.2:80>
      DocumentRoot /web/host2
      ServerName host2.apache.org
      JkMount /*.jsp ajp13
      JkMount /servlet/* ajp13
    </VirtualHost>
    
    <VirtualHost 10.0.0.2:443>
      DocumentRoot /web/host2
      ServerName host2.apache.org
      SSLEngine On
      JkMount /*.jsp ajp13
      JkMount /servlet/* ajp13
    </VirtualHost>
    
    
    表 3 - のJK宣言子を示すApacheのhttpd.confの抜粋

    トラブルシューティングとFAQ

    Q. どこでmod_jkの助力/サポートを得ることができますか?

    A. サポートの主な仕組みは、TOMCAT_HOME/docディレクトリの中のTomcatのドキュメントを通しておこなわれます。 このドキュメントは、Tomcat http://localhost:8080/doc/index.html からブラウザを経由して見ることができます。 ドキュメントは、TomcatのためのApache Jakarta Webサイト上のhttp://jakarta.apache.org/tomcat/jakarta-tomcat/src/doc/index.htmlからも利用することができます。

    さらなる助力のための最適なリソースは、Tomcatユーザ討論リストです。 質問をメーリングリストに投稿する前に、 http://mikal.org/interests/java/tomcat/index.htmlでメーリングリストのアーカイブを検索することから始めなければいけません。 あなたがそのアーカイブの中であなたの質問に対する回答を見つけられなかった場合に、助力のためにTomcatまたはmod_jkについての質問をそのユーザリストに投稿することができます。 あなたが実行しているプラットフォームだけでなく、あなたの使用しているApacheとTomcatのバージョンが含まれているかを確かめてください。http://jakarta.apache.org/site/mail.html

    Q. mod_jkが見つかりません。どこにありますか?

    A. Tomcat 3.3の場合には、mod_jkのソースがnative/mod_jkディレクトリの中に含まれています。 Tomcat 3.3以前のバージョンでは、mod_jkのソースを得るために、Tomcatのソース配布をダウンロードすることができます。 mod_jkのバイナリ配布は、Tomcatのバイナリ配布と同じ場所で利用可能です。 mod_jkのバイナリは、プラットフォームに応じたサブディレクトリの中にあります。 しかし、2001年の5月からjakarta-tomcat-connectorsが開始され、mod_jkの最新の機能はここで見つけることができます (例、AJP14/WARPなどの新しいプロトコル)。

    Q. Ajp12とAjp13の、どちらのプロトコルを使用するべきですか?

    A. Ajp13は、新しいプロトコルで、より高速で、SSLともよりうまく動作します。 だから、あなたは、きっとこちらを使いたいと思うことでしょう。 より詳しい情報は、workers.propertiesの手引きのドキュメントに書かれています。

    Q. Tomcatを再起動すると、Apacheがデッドロックします!

    A. Ajp13プロトコルは、TomcatとApacheの間でソケットをオープンしたままにします。 mod_jkの最新のリリース (Tomcat 3.3-m3とJ-T-C) は、このネットワーク障害を処理することができます。 しかし、mod_jkの以前のリリースでは、Apacheも同様にリスタートする必要があるかもしれません。

    Q. Linuxのダウンロードディレクトリの中に2つのmod_jk.soファイル (-eapiと-noeapi)が存在するのはなぜですか?

    A.Apacheの多くのバージョンは、拡張APIとして知られている変更されたAPIを使用しています。 たとえば、mod_sslを使用したApache、またはある最近のLinux配布の中に含まれるApacheです。 このように、あなたがそのような'拡張されたApache'を入手した場合に、あなたはmod_jk.so-eapiを使用する必要があります。 また、標準のApacheに対してはmod_jk.so-noeapiを使用します。 これは、標準APIのApacheでEAPIモジュールを使用したり、EAPIのApacheで標準APIモジュールを使用することを避ける賢明な方法です。 常にあなたのApacheのバージョンに合ったmod_jk.soを使用しているかを確かめてください。

    Q. 'garbled DSO'のメッセージは何でしょうか?

    A. ApacheのEAPIに関連して、'mod_jk.so is garbled - perhaps this is not an Apache module DSO ?'というメッセージは、あなたがapache-mod_sslやApacheでRedhatの6.2/7.0のApacheのようにEAPIを用いたApacheでコンパイルされたmod_jk.so DSOモジュールをインストールしようとしているが、あなたのシステムは標準APIを用いている普通のApacheであることを示しています。

    Q. さらに'module might crash under EAPI! 'というメッセージは何でしょうか?

    A. 同様にEAPIに関連して、'[warn] Loaded DSO /usr/lib/apache/mod_jk.so uses plain Apache 1.3 API, this module might crash under EAPI! (please recompile it with -DEAPI)'というメッセージは、mod_jk.soが標準APIを用いている普通のApacheでコンパイルされているが、あなたがEAPIを用いたAPIにそのモジュールをインストールしようとしていることを示しています。

    Q. どこから詳しい情報を入手できますか?

    A. workers.propertiesの手引きのドキュメントは、これよりもはるかに詳しい情報が書かれていますので、一見の価値があります。 また、"mod_jk"のメーリングリストのアーカイブを検索したり、ソースコードを見ることもできるでしょう。

    Q.mod_jkのビルドの最中に、APXSはrc=0またはrc=255のようなエラーを受け取ります。 ビルドの節の中のステップのすべてを試したのですが、私は何をすればよいでしょうか?

    A. APXSは、あなたがApacheをソースからビルドした時に作成されるPerlスクリプトです。 あなたがこのエラーを受け取り、かつバイナリ配布としてApacheを入手している場合には、APXSはあなたのシステムに正しく設定されていません。 最適な方法は、http://httpd.apache.orgからApacheのソースを入手して、それを自分でビルドすることです。 基本的なビルド(他のオプションについてはApacheのドキュメントを読んでください)は、以下のように実行します。
    # cd /usr/local/src
    # gzip -dc apache_1.3.19.tar.gz|tar xvf -
    # cd apache_1.3.19
    # ./configure --prefix=/usr/local/apache \
                  --enable-module=most \
                  --enable-shared=max
    # make
    # make install

    注意: 上記のステップは、あなたがApacheのソースをダウンロードして、それをあなたの/usr/local/src中に配置したと仮定しています。


    クレジット

    このドキュメントは、最初はGal Shachorが作成しました。

    さらに以下の人たちによって改訂されました(アルファベット順)。

    Mike Braden <mikeb@mwbinc.com>
    Mike Bremford
    Chris Pepper

    そして、tomcat-devとtomcat-userリストにおける数えきれないほど多くの人の助力を得ました。

    [訳注: これは風間一洋が翻訳しました。 日本語訳に対するコメントは、jajakarta-report@nekoyanagi.com宛に送って下さい。]

    Copyright ©1999-2001 The Apache Software Foundation
    法律上の情報
    コンタクト情報