第4章 サーブレットコンテキスト (Servlet
Context)
ServletContextインターフェイスは、このサーブレットが走っているWebアプリケーション環境へのサーブレット側からの観点を定義する。ServletContextインターフェイスはまたサーブレットが、それが使えるリソースへのアクセスを可能ならしめる。かかるオブジェクトを使って、サーブレットはイベントのログをとったり、リソースへのURLの参照を取得したり、またこのコンテキストの他のサーブレットが使えるよう属性の読み書きをしたりすることができる。サーブレット コンテナにServletContextインターフェイスを実装するのはコンテナのプロバイダである。
ServletContextはWebサーバの特定のパスのルートに置かれる。例えば、コンテキストはhttp://www.mycorp.com/catalogに置かれる。/catalog要求パス(コンテキスト パス:context pathとして知られる)で始まるすべての要求はこのサーブレット コンテキストに回される。
ServletContextの唯一つのインスタンスがwebアプリケーション内のサーブレット(複数)に参照可能である。Webアプリケーションが分散可能としている場合は、Java仮想マシンあたり、アプリケーションあたりのServletContextオブジェクトの唯一つのインスタンスが使用中でなければならない。
4.1 ServletContextのスコープ (Scope of a ServletContext)
ひとつのコンテナにコンテナに導入(デプロイ)された各ウェブ アプリケーションに関連づけられたServletContextインターフェイスのインスタンスはひとつである。コンテナが複数の仮想マシンにわたって分散しているときは、VMあたりのウェブ アプリケーションあたりのインスタンスはひとつである。
ウェブ アプリケーションの一部として導入されていないサーブレットがコンテナに存在するときは、これは暗示的にデフォルトのウェブ アプリケーションの一部であるとし、デフォルトのServletContextに含まれているものとする。分散コンテナの場合は、デフォルトのServletContextは分散不可であり、ひとつの仮想マシン上にのみ存在しなければならない。
4.2 初期化パラメタ (Initialization Parameters)
コンテキスト初期化パラメタのセットはウェブ アプリケーションと結び付けられ、ServletContextインターフェイスの以下のメソッドにより取得可能である。
- getInitParameter
- getInitParamterNames
初期化パラメタはアプリケーション開発者がセットアップのための情報、例えばwebmasterのE-mailアドレスまたはクリチカルなデータを管理するシステムの名前などを伝達するのに使用される。
4.3 Contextの属性 (Context Attributes)
サーブレットはオブジェクトの属性を名前でコンテキストにバインドすることができる。コンテキストにバインドされたいかなるオブジェクトも同じウェブ アプリケーションに属する他の総てのサーブレットからアクセスできる。ServletContextインターフェイスの以下のメソッドによりこの機能にアクセスすることができる。
- setAttribute
- getAttribute
- getAttributeNames
- removeAttribute
4.3.1 分散コンテナでのコンテキスト属性 (Context Attributes in a Distributed Container)
Context属性はそれが作成され配置された仮想マシンにローカルに存在する。これによりServletContextが分散共用メモリとして使用されるのを防止する。分散環境で走っているサーブレット間で共用する情報が必要になったときは、その情報はセッション(第7章参照)、データ ベース、あるいはエンタープライズJavaBeanの形で蓄積されねばならない。
4.4 資源 (Resources)
ServletContextインターフェイスにより、次のメソッドを使ってたとえばHTML、GIF、JPEGファイルといったウェブ アプリケーションの一部であるコンテンツのドキュメントの静的なドキュメント階層を直接アクセスすることが出来るようになる:
- GetResource
- getResourceAsStream
GetResourceとgetResourceAsStreamの双方のメソッドともに、変数としてこのコンテキストのルートに相対的な資源のパスを与えるString変数を持つ。
これらのメソッドによりサーバが使用しているリポジトリに関わらず、静的なリソースのアクセスが可能となることに注意することが重要である。このドキュメントの階層は、ファイルシステム、Webアプリケーションのアーカイブファイル、リモートサーバ、あるいは他の場所に存在し得る。上記のメソッドはダイナミックなコンテンツの取得には使用されない。例えば、JavaServer Pages仕様1をサポートするコンテナにおいては、getResource(“/index.jsp”)の形式のメソッド呼び出しはJSPソースコードを返し、処理した出力を返さない。詳細は第8章の「要求のディスパッチ」を参照のこと。
注1: JavaServerぺージの仕様はhttp://java.sun.com/products/jspにある。
4.5 複数のホストとサーブレット コンテキスト (Multiple Hosts and Servlet Context)
多くのWebサーバは、複数の論理ホストがサーバ上でひとつのIPアドレスを共有する機能を有している。この機能は「バーチャル ホスティング」として呼ばれるものである。サーブレット コンテナのホストがこの機能をサポートする場合は、各論理ホストはそれ自身のサーブレット コンテキストを保有するか,サーブレット コンテキスト(複数)のセットを保有しなければならない。サーブレット コンテキストはバーチャル ホスト間で共用できない。
4.6 再ロードする場合の考察点 (Reloading Considerations)
開発が容易であるように多くのサーブレット コンテナがサーブレットの再ロード(リロード)をサポートしている。サーブレット クラス再ロードはすでに前のサーブレット コンテナの作成時にこのサーブレットをロードするために新しいクラスのローダを作成することで達成されてしまっている。このクラスローダは、他のサーブレット コンテキストで使われる他のサーブレットあるいはクラスをロードするときにつかわれるローダとは区別される。このことは好ましくない副作用として、あるサーブレット コンテキスト内のオブジェクトの参照を期待したものと異なるクラスあるいはオブジェクトにしてしまい、予期せぬ結果をもたらす可能性がある。
従って,コンテナのプロバイダはクラス再ロードの機能を実装するときは、使用されるであろう総てのサーブレット及びクラスが単一のクラスローダのスコープ内にロードされ、アプリケーションが所定のとおり振舞うことを保証しなければならない。
4.7 一時的な作業用ディレクトリ (Temporary Working Directories)
アプリケーション開発者にとっては、ローカルなファイル システムに一時的な作業領域を持つことがしばしば有用となる。すべてのサーブレット コンテナはサーブレット コンテキスト毎にプライベートな一次ディレクトリを用意して、javax.servlet.context.tempdirなるコンテキスト属性でアクセス可能としなければならない。この属性で関連付けされたオブジェクトはjava.io.file型でなければならない。