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

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

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

この情報の多くは、Servlet API仕様のバージョン2.3の第9章から抽出されたものであり、詳細については参照する必要があります。

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

すぐに使える標準のTomcatインストールには、次のようなさまざまな事前インストールされた共有ライブラリファイルが含まれています。

• サーブレットおよびJSPの記述に不可欠なServlet 6.0およびJSP 4.0 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ファイルには、1つのContext要素を含める必要があり、これは、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サーバーを再起動せずに実行中のTomcatサーバーでアプリケーションをデプロイおよびアンデプロイできます。Manager Webアプリケーションの使用方法の詳細については、Manager App How-Toを参照してください。
  
  
• ビルドスクリプトで「Manager」Antタスクを使用します。Tomcatには、Antビルドツール用のカスタムタスク定義のセットが含まれており、「Manager」Webアプリケーションへのコマンドの実行を自動化できます。これらのタスクは、Tomcatデプロイヤで使用されます。
  
  
• Tomcatデプロイヤを使用します。Tomcatには、Antタスクをバンドルしたパッケージ化されたツールが含まれており、サーバーへのデプロイ前にWebアプリケーションの一部であるJSPを自動的にプリコンパイルするために使用できます。
  
  

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