サーブレット API の 2.1 から 2.2 への変更点

サーブレット API バージョン 2.2 には、API のいくつかの改良 (その主な機能拡張の 1 つは Web アプリケーション) およびその他の機能拡張が含まれています。

API の改良

サーブレット API バージョン 2.2 は、前のバージョンに次の改良を加えています。

要求の送信の機能拡張

サーブレット API 2.2 には ServletContext.getNamedDispatcher(String path) メソッドが含まれています。これを使用して、コンポーネントをその登録されている名前に基づいて送信できます。

また、ServletRequest.getRequestDispatcher(String path) メソッドを使用することもできます。これは、ターゲットとして相対 URL を使用します
(ServletContext.getRequestDispatcher(String path) は完全修飾 URL を使用します)。

転送機能の拡張

HttpServletResponse.sendRedirect(String url) は相対 URL をサポートします。

Web アプリケーション

Web アプリケーションは、サーブレット、JSP ドキュメント、HTML ドキュメント、イメージ、およびその他のリソースから構成されています。これらのリソースをあらかじめ定義されているディレクトリ構造に従って公開し、サーブレットをサポートするどの Web サーバーにもそれを公開できるようにします。

2 つのアプリケーションがデータ レポジトリとして共通のデータベースを使用してデータを共有できます。これによって 2 つのアプリケーションが同じ情報にアクセスできます。たとえば、電子商取引 Web サイトが、共通のデータベースを使用する複数のアプリケーションから構成されているとします。顧客はログイン名、パスワード、またはその他の形式の識別子によって識別され、それによって各アプリケーションは、ショッピング カート、支払い情報、住所など、すべてのアプリケーションに共通するユーザ情報にアクセスできます。

アプリケーション間でデータを共有するもう 1 つの手段は、JRun による EJB のサポートです。EJB の使用の詳細については、第 31 章 を参照してください。

1 つの JRun JVM で複数の Web アプリケーションをサポートできます。Web アプリケーションを開発するときに検討しなければならない問題の 1 つは、アプリケーションの間の境界をどこに設定するかです。言い換えれば、アプリケーションをほかのアプリケーションと同じ JRun JVM 内に置くことができるか、別の JVM 内に置く必要があるかという問題です。

それを決定する 1 つの要因はエラー処理です。同じ JRun JVM 内のすべての Web アプリケーションは同じプロセス内で実行するため、1 つのアプリケーションのエラーによって JVM 全体が停止します。このエラー処理結果が容認できない場合は、アプリケーションを別の JRun JVM に配置する必要があります。

また、それぞれの JRun JVM に、特定のアプリケーションによって要求される JVM 固有の属性を割り当てることができます。たとえば、JRun JVM ごとに異なる Java JVM を使用できるため、JVM のタイプを使用してアプリケーションを区別できます。

最後に、アプリケーションのセキュリティは JRun JVM レベルで決定されます。2 つのアプリケーションに別々のセキュリティ管理システムが必要な場合は、それらのアプリケーションを別の JRun JVM に配置する必要があります。

Web アプリケーションの詳細については、Java サーブレット API バージョン 2.2 の仕様書を参照してください。

WAR ファイル

WAR (Web application archive) について説明します。

WEB-INF ディレクトリ

WEB-INF ディレクトリには web.xml ファイル、lib ディレクトリ、および classes ディレクトリが含まれています。

アプリケーションあたり 1 つの ServletContext

Web アプリケーション内のすべてのサーブレットは、1 つの ServletContext を共有します。Web アプリケーションの初期パラメータにアクセスするには、
ServletContext.getInitParameter(String name) および
ServletContext.getInitParameterNames() メソッドを使用します。

ほかの拡張機能

サーブレット API のバージョン 2.2 には、上記のほかに次の拡張機能が含まれています。

このセクションで、これらの拡張機能について説明します。

応答バッファ

応答バッファによって、サーブレットがその応答をバッファに入れるかどうかを制御できます。また、バッファのサイズを制御することもできます。ServletResponse オブジェクトには応答バッファをサポートするために次のメソッドが含まれています。

複数のヘッダ値のサポート

HttpServletRequest オブジェクトには、複数の値を持つヘッダを取得するために getHeaders(String name) メソッドが含まれています。これは Accept-Language ヘッダによって複数言語のサポートを実装するときに特に便利です。このヘッダは複数のヘッダ値を処理できます。

また、HttpServletRequest.addHeader(String name, String value)
HttpServletRequest.addIntHeader(String name, int value)、および
HttpServletRequest.addDateHeader(String name, long date) を使用して複数の値を設定することもできます。

一時ディレクトリのサポート

サーブレット API 2.2 では、それぞれのサーブレット コンテキストが専用の一時作業ディレクトリを提供する必要があります。サーブレット コンテキストの一時ディレクトリの位置を決めるときは、ServletContext 属性 javax.servlet.context.tempdir にアクセスします。この属性を持つオブジェクトのタイプは java.io.File です。
次のコードと同様のコードを使用します。

...
ServletContext sc = this.getServletContext();
File tempDir = (File) sc.getAttribute("javax.servlet.context.tempdir");
...

サーブレット名へのアクセス

GenericServlet.getServletName() メソッドを使用してサーブレット登録名にアクセスできます。サーブレットが登録されていない場合、このメソッドはサーブレットのクラス名を返します。

国際化

ServletRequest.getLocale() メソッドを使用してクライアントの Locale オブジェクトにアクセスできます。返されるロケールは、Accept-Language ヘッダに基づきます。このヘッダがない場合、このメソッドはサーバーの既定のロケールを返します。また、ServletRequest.getLocales() メソッドを使用して、許容可能なロケールを指定している Locale オブジェクトの Enumeration にアクセスすることもできます。

HttpServletResponse.setLocale(Locale loc) メソッドを使用してロケールを指定することもできます。

セキュリティ

Web アプリケーションにロールベースのセキュリティ情報を含めることができます。これは、指定したページへのアクセスが特定のロールのユーザにのみ許可されるようにします。

サーブレット API 2.2 には HttpServletRequest.getUserPrincipal() および HttpServletRequest.isUserInRole(String role) メソッドが含まれています。また、HttpServletRequest.isSecure() メソッドも含まれています。このメソッドは、要求が HTTPS を使用している場合に true を返します。

Web アプリケーションでのロールおよびセキュリティの詳細については、Java サーブレット API バージョン 2.2 の仕様書を参照してください。