アプリケーション開発者ガイド

• 背景
• 標準ディレクトリレイアウト
• 共有ライブラリファイル
• Webアプリケーション配備記述子
• Tomcatコンテキスト記述子
• Tomcatを使用した配備

ソースコードディレクトリの構成方法を説明する前に、Webアプリケーションの実行時構成について検討することが役立ちます。Servlet API仕様バージョン2.2より前は、サーバープラットフォーム間で一貫性がほとんどありませんでした。しかし、2.2（またはそれ以降）の仕様に準拠するサーバーは、標準形式のWebアプリケーションアーカイブを受け入れる必要があります。これは後述します。

Webアプリケーションは、標準レイアウトのディレクトリとファイルの階層として定義されます。このような階層は、「展開済み」形式（各ディレクトリとファイルがファイルシステムに個別に存在する）または「圧縮済み」形式（Web ARchive、WARファイルとして知られる）でアクセスできます。前者の形式は開発中に、後者はアプリケーションを配布してインストールする場合に役立ちます。

Webアプリケーション階層の最上位ディレクトリは、アプリケーションのドキュメントルートでもあります。ここでは、アプリケーションのユーザーインターフェースを構成するHTMLファイルとJSPページを配置します。システム管理者がアプリケーションを特定のサーバーに配備する場合、アプリケーションにコンテキストパスを割り当てます（このマニュアルの後のセクションでは、Tomcatでの配備について説明します）。したがって、システム管理者がアプリケーションに/catalogというコンテキストパスを割り当てると、/catalog/index.htmlを参照するリクエストURIは、ドキュメントルートからindex.htmlファイルを検索します。

必要な形式でWebアプリケーションアーカイブファイルを作成しやすくするために、Webアプリケーションの「実行可能」ファイル（つまり、アプリの実行時にTomcatが実際に使用するファイル）を、WAR形式自体に必要なものと同じ構成に配置することが便利です。これを行うと、アプリケーションの「ドキュメントルート」ディレクトリに次の内容が含まれるようになります。

• *.html、*.jspなど - アプリケーションのユーザーブラウザに表示する必要があるHTMLおよびJSPページ、その他のファイル（JavaScript、スタイルシートファイル、画像など）。大規模なアプリケーションでは、これらのファイルをサブディレクトリ階層に分割することを選択できますが、小規模なアプリケーションでは、これらのファイルに対して単一のディレクトリのみを維持する方が一般的にはるかに簡単です。
  
  
• /WEB-INF/web.xml - アプリケーションのWebアプリケーション配備記述子。これは、アプリケーションを構成するサーブレットやその他のコンポーネント、初期化パラメータ、サーバーに強制させたいコンテナ管理セキュリティ制約などを記述したXMLファイルです。このファイルについては、次のサブセクションで詳しく説明します。
  
  
• /WEB-INF/classes/ - このディレクトリには、アプリケーションに必要なJavaクラスファイル（および関連リソース）が含まれています。サーブレットクラスとサーブレット以外のクラスの両方を含み、JARファイルに結合されていないクラスです。クラスがJavaパッケージに編成されている場合は、/WEB-INF/classes/の下のディレクトリ階層にそれを反映する必要があります。たとえば、com.mycompany.mypackage.MyServletという名前のJavaクラスは、/WEB-INF/classes/com/mycompany/mypackage/MyServlet.classという名前のファイルに格納する必要があります。
  
  
• /WEB-INF/lib/ - このディレクトリには、アプリケーションに必要なJavaクラスファイル（および関連リソース）を含むJARファイルが含まれています（サードパーティのクラスライブラリやJDBCドライバなど）。

アプリケーションをTomcat（またはその他の2.2以降のServletコンテナ）にインストールすると、WEB-INF/classes/ディレクトリ内のクラスと、WEB-INF/lib/ディレクトリにあるJARファイル内のすべてのクラスが、特定のWebアプリケーション内の他のクラスから見えるようになります。したがって、必要なライブラリクラスをこれらのいずれかの場所に含めれば（使用するサードパーティライブラリの再配布権に関するライセンスを確認してください）、Webアプリケーションのインストールが簡素化されます。システムクラスパスの調整（またはサーバーへのグローバルライブラリファイルのインストール）は不要になります。

この情報の多くは、Servlet API仕様バージョン2.3の第9章から抜粋したものであり、詳細についてはそちらを参照してください。

ほとんどのサーブレットコンテナと同様に、TomcatもライブラリJARファイル（または展開済みクラス）を一度インストールし、（Webアプリケーション自体に含める必要なく）インストールされているすべてのWebアプリケーションから見えるようにするメカニズムをサポートしています。Tomcatがそのようなクラスを見つけて共有する方法の詳細については、クラスローダーに関するハウツードキュメントを参照してください。Tomcatインストール内で共有コードに使用される一般的な場所は、$CATALINA_HOME/libです。ここに配置されたJARファイルは、Webアプリケーションと内部Tomcatコードの両方から見えます。これは、アプリケーションまたは内部Tomcatの使用（DataSourceRealmなど）に必要なJDBCドライバを配置するのに適した場所です。

標準のTomcatインストールでは、次のようなさまざまな事前インストール済みの共有ライブラリファイルが含まれています。

• サーブレットとJSPの記述に不可欠なServlet 6.0およびJSP 3.1 API。
  
  

前述のように、/WEB-INF/web.xmlファイルには、アプリケーションのWebアプリケーション配備記述子が含まれています。ファイル名拡張子が示すように、このファイルはXMLドキュメントであり、サーバーが知る必要があるアプリケーションに関するすべてを定義します（システム管理者がアプリケーションを配備するときに割り当てられるコンテキストパスを除く）。

配備記述子の完全な構文とセマンティクスは、Servlet API仕様バージョン2.3の第13章で定義されています。時間とともに、配備記述子を自動的に作成および編集する開発ツールが提供されることが期待されます。とりあえず、出発点として、基本的なweb.xmlファイルが提供されています。このファイルには、各要素の目的を説明するコメントが含まれています。

注記 - Servlet仕様には、Webアプリケーション配備記述子のドキュメントタイプ記述子（DTD）が含まれており、Tomcatはアプリケーションの/WEB-INF/web.xmlファイルを処理する際にここで定義されたルールを適用します。特に、記述子要素（<filter>、<servlet>、<servlet-mapping>など）は、DTDで定義されている順序で入力する必要があります（13.3節を参照）。

/META-INF/context.xmlファイルを使用して、アクセスログ、データソース、セッションマネージャーの構成など、Tomcat固有の構成オプションを定義できます。このXMLファイルには、Context要素が1つ含まれている必要があります。これは、Webアプリケーションが配備されるHostに対応するHostの子要素として扱われます。Tomcat構成ドキュメントには、Context要素に関する情報が含まれています。

以下の説明では、変数名$CATALINA_BASEを使用して、ほとんどの相対パスが解決されるベースディレクトリを参照します。CATALINA_BASEディレクトリを設定して複数のインスタンス用にTomcatを構成していない場合は、$CATALINA_BASEは、Tomcatをインストールしたディレクトリである$CATALINA_HOMEの値に設定されます。

実行するには、Webアプリケーションをサーブレットコンテナに配備する必要があります。これは開発中にも当てはまります。Tomcatを使用して実行環境を提供する方法について説明します。Webアプリケーションは、次のいずれかの方法でTomcatに配備できます。

• 展開済みディレクトリ階層を$CATALINA_BASE/webapps/ディレクトリのサブディレクトリにコピーする。Tomcatは、選択したサブディレクトリ名に基づいてアプリケーションにコンテキストパスを割り当てます。これは開発中に最も迅速かつ簡単な方法であるため、構築するbuild.xmlファイルでこの手法を使用します。アプリケーションをインストールまたは更新した後は、Tomcatを必ず再起動してください。
  
  
• Webアプリケーションアーカイブファイルを$CATALINA_BASE/webapps/ディレクトリにコピーする。Tomcatが起動されると、Webアプリケーションアーカイブファイルが自動的に展開済み形式に展開され、そのようにしてアプリケーションが実行されます。このアプローチは、通常、サードパーティベンダーまたは内部開発スタッフが提供する追加のアプリケーションを既存のTomcatインストールにインストールするために使用されます。注記 - このアプローチを使用し、後でアプリケーションを更新する場合は、Webアプリケーションアーカイブファイルを置き換え、Tomcatが作成した展開済みディレクトリを削除し、Tomcatを再起動して変更を反映する必要があります。
  
  
• Tomcatの「Manager」Webアプリケーションを使用して、Webアプリケーションを配備およびアンデプロイする。Tomcatには、コンテキストパス/managerにデフォルトで配備されているWebアプリケーションが含まれており、これを使用して、実行中のTomcatサーバーでアプリケーションを再起動せずに配備およびアンデプロイできます。「Manager」Webアプリケーションの使用の詳細については、Managerアプリに関するハウツーを参照してください。
  
  
• ビルドスクリプトで「Manager」Antタスクを使用する。「Manager」Webアプリケーションへのコマンドの実行を自動化できる、Antビルドツール用のカスタムタスク定義のセットがTomcatに含まれています。これらのタスクはTomcatデプロイヤーで使用されます。
  
  
• Tomcatデプロイヤーを使用する。TomcatにはAntタスクをバンドルしたパッケージ化されたツールが含まれており、サーバーへの配備前にWebアプリケーションの一部であるJSPを自動的にプリコンパイルするために使用できます。
  
  

他のサーブレットコンテナへのアプリの配備は、コンテナごとに固有のものになりますが、Servlet API仕様（バージョン2.2以降）と互換性のあるすべてのコンテナは、Webアプリケーションアーカイブファイルを受け入れる必要があります。他のコンテナは、展開済みディレクトリ構造（Tomcatのように）を受け入れること、または共有ライブラリファイルのメカニズムを提供することを要求されていませんが、これらの機能は一般的に利用可能です。