3. WEBアプリケーションのインストールと構成
日本語訳というか意訳:ひろも
オリジナル : {TOMCAT_HOME}\doc\appdev\deployment.html(in
Tomcat3.1)
3.1 バックグラウンド
自作ソースコードディレクトリのインストールについて説明する前に、WEBアプリケーションの実行環境について振り返ってみましょう。
Servlet API version 2.2 の仕様が制定される前は、異なるサーバープラットフォーム間での一貫性はほとんどありませんでした。
しかし、Servlet API 2.2の仕様が制定された今、それに適合したサーバーは、以下で説明する標準フォーマット「WEBアプリケーションアーカイブ(Web Application
Archive)」に対応していなければいけません。
WEBアプリケーションは、標準的な階層ディレクトリ、ファイルの形で定義されます。
この階層構造は、以下の2つの形になります。
- それぞれのディレクトリやファイルがディスク上にバラバラに入っている「unpacked」型
- 「Web ARchive」又は、「WAR」形式ファイルとして知られている「packed」型
「packed」型は、特に開発後期に、WEBアプリケーションの配布・インストールに使います。
WEBアプリケーションの階層構造のトップもまた、WEBアプリケーションの「ドキュメントルート」です。
例えば、WEBアプリケーションのユーザーインターフェースになるHTMLファイルとJSPページを設置するとします。
システム管理者は、「コンテキストパス(context path)」と呼ばれるものを、そのWEBアプリケーション用に割り当てます。
例えば、あるWEBアプリケーションのコンテキストパスとして「/catalog」を割り当てた場合、「/catalog/index.html」へのURI参照により、ドキュメントルートにある
index.html が返されるわけです。
3.2 基本的なディレクトリレイアウト
規定にしたがったWEBアプリケーションアーカイブファイルを簡単に作成するには、WAR フォーマットで決められてるのと同じ構成で、WEBアプリケーションを「実行可能な」形(Tomcatが実行時、実際に使うファイル)に整えてやるのが近道です。
具体的には、WEBアプリケーションのドキュメントルート以下が、以下のようになっていなければいけません。
- *.html, *.jsp, etc. - WEBアプリケーションで使う HTML や JSP
ページ、また、クライアント側のブラウザで表示するその他のファイル(例えばJavaScriptやスタイルシートなど)。大規模なWEBアプリケーションでは、サブディレクトリにファイルを分散して保存するかもしれませんが、小規模なWEBアプリケーションなら、一般的にひとつのディレクトリにまとめておいたほうがメンテナンスしやすいでしょう。
- WEB-INF/web.xml - WEBアプリケーション設置の記述。WEBアプリケーションを構成するサーブレットや、その他のコンポーネントについて書いたXMLファイルです。また、パラメーターの初期化や、その他、サーバーのセキュリティ強化をしたい時に、サーブレットコンテナ側のセキュリティ設定をこのファイルで行います。このファイルの詳細については、後で解説します。
- WEB-INF/classes/ - このディレクトリには、あなたのWEBアプリケーションに必要な、すべてのJavaクラスファイル(と関連するリソース)
、サーブレット、非サーブレットクラスをJARファイルにまとめずに入れてください。
もし、クラスファイルがJavaパッケージになっている場合は、WEB-INF/classes/ディレクトリ下に、パッケージの階層構造と同じディレクトリ構造を反映させなければいけません。例えば、「
com.mycompany.mypackage.MyServlet
」という名前のJavaクラスは、「WEB-INF/classes/com/mycompany/mypackage/MyServlet.class
」というディレクトリ・ファイル名で保存しなければいけません。
- WEB-INF/lib/ - このディレクトリには、WEBアプリケーションが必要とする、Java
クラスファイルを含んだJARファイルを入れます。例えば、サードパーティー製クラスライブラリや、JDBCドライバなどです。
Tomcat(または、Servlet API 2.2 互換サーバー)にWEBアプリケーションをインストールする場合、WEB-INF/classes/
ディレクトリ、WEB-INF/lib/ ディレクトリ内のJARファイルがあなたのWEBアプリケーション固有のクラスパスとして追加されます。このように、必要なすべてのクラスライブラリをこれらのうちのひとつの場所に取り込んだとすると(サードパーティー製ライブラリは再配布のライセンスの確認が必要ですが)WEBアプリケーションのインストールを簡略化できます。---つまり、システムのクラスパスの設定は必要なくなるわけです。
ここの情報の多くががサーブレットAPI仕様書
version2.2の第9章からの抜粋ですので、さらなる詳細についてはそちらを読むべきです。
3.3 WEBアプリケーション設置の記述(Web Application Deployment Descriptor)
先にも書いたように、WEB-INF/web.xml ファイルはWEBアプリケーション設置の記述を含んでいます。拡張子からも分かるように、このファイルはXML文書で、WEBアプリケーションについてサーバーが知らなければいけない内容を定義します。(ただし、WEBアプリケーションの設置のためにシステム管理者が割り当てる「コンテキストパス(context
path)」は除く)
WEBアプリケーションの設置の記述についての完全な文法と意味については、サーブレットAPI仕様書
version2.2の第13章で定義されています。将来的には、WEBアプリケーション設置の記述(Web
Application Deployment Descriptor)を作成・編集するツールが提供される可能性がありますが、それまでの間は、スタートポイントとして、基本の
web.xml ファイルが提供しています。このファイルでは、各XML要素の使用目的について説明しています。
3.4 Tomcatへの統合
WEBアプリケーションを実行するには、サーブレットコンテナに統合、またはインストールしなければいけません。これは、たとえ開発中であってもそうです。ここでは、WEBアプリケーションの実行環境を実現するのにTomcatを使用する方法を説明します。Tomcatでは、以下の異なる3つのアプローチで、WEBアプリケーションを設置できます。
- 「unpacked」なディレクトリ構造をそのまま $TOMCAT_HOME/webapps/
内のサブディレクトリにコピーする方法。TomcatはWEBアプリケーションに、あなたが付けたサブディレクトリ名のコンテキストパスを割り当てます。私たちは、build.xmlを書き、このテクニックを使うようにしています。なぜなら、開発中は、これがもっとも速くて簡単なアプローチだからです。
- 「packed」なWEBアプリケーションアーカイブファイル(WAR形式ファイル)を $TOMCAT_HOME/webapps/ にコピーする方法。Tomcatが起動すると、自動的にWEBアプリケーションアーカイブファイルを「unpacked」な形式に展開し、これを実行できるようにします。このアプローチは、すでにあるTomcat環境に、サードパーティーやあなたの会社のスタッフが開発した追加のWEBアプリケーションのインストールで主に使われます。
- Tomcat の server.xml 設定ファイルに<Context>の項目を追加する方法。次に説明するこのアプローチなら、
$TOMCAT_HOME/webapps/ ディレクトリ以外をWEBアプリケーションのドキュメントルートに設定することができます。これを実現するには、次の手順が必要です。(Tomcat3.1の場合)
<Context>エントリーを Tomcat の server.xml
には、次の手順が必要です。(Tomcat3.1の場合)
- $TOMCAT/conf/server.xml をエディタで開きます。
- ファイルの下の方を見てください。(最後の
<Context> 要素の次)
- 既にあるサンプルを参考に、WEBアプリケーション用に新しい <Context>
要素を追加します。このとき、次の属性がサポートされています。
- path. WEBアプリケーション用の「コンテキストパス」。どのWEBアプリケーションでURI要求を処理すればいいかをTomcatに伝える、そのURI要求の頭に付ける文字です。例えば、パスを「/catalog」に設定した場合、「/catalog」で始まるURI要求のすべてが、このWEBアプリケーションで処理されます。この属性は必ず必要で、かつ、「/」(スラッシュ)から始まる必要があります。
- docBase.このWEBアプリケーションのドキュメントルート。WEBアプリケーションが入っているディレクトリを、相対パス(Tomcatがインストールされているフォルダからの)、または、絶対パスで指定できます。Windows環境で、絶対パス指定する場合は、ドライブ名とコロン(C:
や D:)を頭に付けるのを忘れないでください。この属性は必ず必要です。
- debug. WEBアプリケーションの、初期化、開始、終了時に、Tomcat
がどのくらい詳しくにデバッグ情報を記録するかを
"0" から "9"までの間で指定します。特に何も指定しない場合は0(最小の記録)になります。
- reloadable. WEB-INF/classes ディレクトリにあるJavaクラスファイル、または、WEB-INF/lib内のJARファイルが変更されたどうかをTomcatに検出させたい場合、"true"にしてください。変更されたことが分かると、Tomcatは変更点をピックアップし、WEBアプリケーションの終了と再読み込みを自動的に行います。初期値は「false」で、変更は検出は無効になっています。メモ:この機能は、開発中に大変便利ですが、変更の検出によるオーバーヘッドが発生します。WEBアプリケーションを製品としてインストールするのであれば、一般的にこの機能は使われるべきではありません。
WEBアプリケーションを、Tomcat以外のサーブレットコンテナに統合、インストールする場合は、それぞれのコンテナの指示に従ってください。ただし、サーブレットAPI仕様書(version2.2)と互換のあるコンテナであれば、上記で説明したWEBアプリケーションアーカイブファイルは使えるようになっていなければいけないはずです。