サーブレットの動作の変更

Servlet 3.1 実装には、Servlet 3.1 フィーチャーを使用した場合に、Servlet 3.0 用に作成されたアプリケーションが異なる動作をしたり、失敗したりする原因となる可能性がある動作の変更が含まれています。

Servlet 3.0 のフィーチャーと Servlet 3.1 のフィーチャーのいずれを実装するかを、動作の変更を考慮してサーバー・インスタンスごとに選択できます。必要な動作が Servlet 3.1 のフィーチャーにのみ含まれている場合は、Servlet 3.1 のフィーチャーを使用する必要があります。既存のアプリケーションが Servlet 3.1 のフィーチャーの動作変更で悪影響を受ける場合は、Servlet 3.0 のフィーチャーを使用すれば、そのアプリケーションの既存の動作が保持されます。同じサーバーで Servlet 3.0 と Servlet 3.1 の両方のフィーチャーを使用することはできません。両方のフィーチャーを構成すると、エラーになります。両方のフィーチャーを構成した場合は、いずれのサーブレット・フィーチャーもロードされません。

動作の変更は、以下の理由で導入されています。
  • Servlet 3.1 仕様で明確化された事柄により必要となった変更。
  • 実装が Servlet 3.1 Technology Compatibility Kit (TCK) に合格するために必要な変更。
  • サーブレット実装を改善するための変更。

プログラムで追加されるサーブレット、フィルター、およびリスナー

Servlet 3.1 仕様での明確化により、ServletContextListener が web.xml ファイルまたは web-fragment.xml ファイルで宣言されていないか、@WebListener のアノテーションが付けられていない場合、ServletContextListener がプログラムでサーブレット、フィルター、またはリスナーを構成することはできなくなりました。したがって、ServletContext を呼び出してプログラムによるそのような構成を行うと、UnsupportedOperationException が発生します。

非同期処理開始後の forward

Servlet 3.0 実装では、応答は必ず RequestDispatcher インターフェースの forward メソッドが戻る前に閉じられます。しかし、Servlet 3.1 仕様での明確化により、Servlet 3.1 実装では、要求が非同期モードになった場合、RequestDispatcher インターフェースの forward メソッドが戻る前に応答が閉じられることも、フラッシュされることもありません。この変更は、forward からの戻り時に応答出力を追加する既存の 3.0 アプリケーションに影響する可能性があります。Servlet 3.0 では そのような応答データが送信されることはありませんでしたが、Servlet 3.1 では送信されるようになったためです。

URL パターンの競合

Servlet 3.0 では、URL パターンが複数のサーブレットにマップされている場合でも、アプリケーションは正常に開始していました。しかし、Servlet 3.1 仕様での明確化によれば、この場合アプリケーションは開始に失敗するべきです。Liberty Servlet 3.1 3.1 実装では、次のメッセージが出力され、アプリケーションは開始に失敗します。
SRVE9016E: Unable to insert mapping [{0}] for servlet named [{1}]. The URL pattern is already defined for servlet named [{2}].

Explanation: There is an application error. A servlet mapping URL pattern should not map to multiple servlets.

User action: Change the URL pattern for the servlet mapping.

ServletContext.getMinorVersion()

Servlet 3.0 フィーチャー実装では、この API は、0 を返します。

Servlet 3.1 フィーチャーでは、この API は 1 を返すようになりました。

ServletContext.getServerInfo()

Servlet 3.0 フィーチャー実装では、この API は、SMF WebContainer を返します。

Servlet 3.1 フィーチャーでは、この API は IBM WebSphere Liberty/8.5.5.<x> を返すようになりました。<x> は、WebSphere® Application Server フィックスパック番号です。

ServletResponse.reset()

応答がまだコミットされていないときに、ServletResponse.reset() を使用して、バッファーに入れられている応答データ、状況コード、および応答ヘッダーをクリアできます。Servlet 3.1 フィーチャーを使用している場合、このメソッドは、前に呼び出された ServletResonse.getWriter() や ServletResponse.getOutputStream() のレコードもクリアします。

X-Powered-By ヘッダー

Servlet 3.0 フィーチャー実装では、X-Powered-By ヘッダーは Servlet/3.0 に設定されます。 Servlet 3.1 フィーチャー実装では、X-Powered-By ヘッダーは Servlet/3.1 に設定されます。

リソース参照注入ターゲットのマージ

Servlet 3.0 仕様では、web-fragment.xml ファイルで定義されたリソース参照の <injection-target> エレメントは、同じ名前の web.xml リソース参照定義に <injection-target> エレメントがない場合、親 web.xml ファイルにのみ追加されます。 Servlet 3.1 仕様では、web-fragment.xml 記述子に含まれるすべての <injection-target> エレメントが、同じ名前のリソース参照の <injection-target> エレメントの親 web.xml 記述子リストに追加されることが明確化されました。 Servlet 3.1 フィーチャーを使用している場合、このフィーチャーは、以前は web.xml ファイルから除外されていた注入ターゲットをアクティブ化して、既存のアプリケーションの機能を変更する可能性があります。

Web 記述子内の重複エレメントの許容

Servlet 3.1 仕様では、web.xml ファイルに 2 つの <absolute-ordering> エレメントを含められないということが明確化されました。複数の <absolute-ordering> エレメントを使用したアプリケーションのデプロイメントは、失敗します。また、web-fragment.xml 記述子に 2 つの <ordering> エレメントを含めることはできません。 複数の <ordering> エレメントを使用したアプリケーションのデプロイメントは、失敗します。以前のバージョンでは、デプロイメントは失敗しません。ただし、エレメントの機能が不確定になる可能性があります。

metadata-complete の場合の Web フラグメント順序の変更

web.xml 記述子が metadata-complete="true" とマークされた場合の <absolute-ordering> エレメントの処理が変更されました。 以前のバージョンでは、metadata-complete="true" の場合、すべての Web フラグメント・アーカイブが使用されます。Servlet-3.1 フィーチャーを使用しているとき、metadata-complete の場合の <absolute-ordering> エレメントは完全であると見なされます。 この変更により、<absolute-ordering> エレメントにリストされないフラグメントが処理から除外されることになります。

AsyncContext.dispatch()

AsyncContext.dispatch() を (例えば、パラメーターを指定せずに) 使用している場合、要求は元の URL にディスパッチされます。Servlet-3.0 フィーチャーを使用している場合、照会ストリングが元の要求に含まれていれば、ディスパッチされたリソースでそれを使用できます。しかし、Servlet 3.1 フィーチャーを使用している場合、照会ストリングがディスパッチング・リソースに提供された場合、ディスパッチされたリソースで使用できるのは、その照会ストリングになります。 以下に例を示します。
Request for /FirstResource?param=One
First Resource:
    getParameter("param") returns "One"
           forward request to /SecondResource?param=Two
SecondResource
           getParameter(param) returns "Two"
           ac.start()
           ac.dispacth() dispatches to /FirstResource
First Resource
           Servlet-3.0 feature : getParamter("param") returns "One"
           Servlet-3.1 feature : getParameter("param") returns "Two"

This change was required by the Servlet 3.1 TCK.
AsyncContext.dispatch() または AsyncContext.complete() の後に要求オブジェクトまたは応答オブジェクトを取得することは許可されず、以下の例外がスローされます。
java.lang.IllegalStateException: SRVE9015E: Cannot obtain the request or response object after an AsyncContext.dispatch() or AsyncContext.complete().
    at com.ibm.ws.webcontainer31.async.AsyncContext31Impl.getRequest(AsyncContext31Impl.java:72)
    [...]

SessionCookieConfig.setComment()

Java™ Servlet 3.1 仕様によれば、この API は、ServletContext で初期化が完了した後に呼び出された場合、illegalStateException を返します。Servlet 3.1 フィーチャーは、要求されているこの動作に従います。しかし、Servlet 3.0 フィーチャーでは、コンテキストの初期化後のこの API の使用が妨げられないため、Servlet 3.0 フィーチャーの動作に依存しているアプリケーションは、Servlet 3.1 フィーチャーでは機能しません。

sendRedirect(java.lang.String location) API

sendRedirect(java.lang.String location) API は相対 URL を受け入れます。ただし、サーブレット・コンテナーは、応答をクライアントに送信する前に相対 URL を絶対 URL に変換する必要があります。先頭に '/' がない相対ロケーション (folder/default.jsp) の場合、コンテナーは現行要求 URI を基準とした相対ロケーションとして解釈します。先頭に '/' がある相対ロケーションの場合、コンテナーはサーブレット・コンテナー・ルートを基準とした相対ロケーションとして解釈します。

例えば、アプリケーションによって提供されたリダイレクト・ロケーションが先頭に '/' がない folder/default.jsp であり、インバウンド要求 URL が http://host:port/context_root/folder または http://host:port/context_root/folder/ の場合、要求は、現行要求 URI を基準とした相対ロケーションである http://host:port/context_root/folder/folder/default.jsp にリダイレクトされます。

この動作が見られるのは、Servlet 3.0 フィーチャーで com.ibm.ws.webcontainer.redirectwithpathinfo プロパティーが true に設定されている場合です。このプロパティーは Servlet 3.1 フィーチャーでは無視され、説明のとおりのデフォルト動作になります。

デフォルト・エラー・ページ

IBM® 拡張機能は、ibm-web-ext.xml など、Web 拡張機能を使用してデフォルト・エラー・ページを指定する機能です。

Servlet 3.0 以上の機能である、デフォルト・エラー・ページは、エラー・ページを指定する機能を変更したものです。通常の (非デフォルト) エラー・ページと同様に、デフォルト・エラー・ページは、Web モジュール記述子 (web.xml) および Web フラグメント記述子 (web-fragment.xml) で指定します。

通常の (非デフォルト) エラー・ページでは、例外タイプまたはエラー・コードのいずれかを指定します。デフォルト・エラー・ページでは、例外タイプとエラー・コードの両方を省略します。デフォルト・エラー・ページは、サーブレットで例外がスローされるか、エラー・コード結果が設定されたが、例外タイプまたは設定されたエラー・コードに一致するエラー・ページが構成されていない場合に使用されます。

デフォルト・エラー・ページを定義する機能は Servlet 3.0 仕様で提供され、Servlet 3.0 スキーマによってサポートされています。デフォルト・エラー・ページは、Servlet 3.1 仕様によれば、exception-type エレメントまたは error-code エレメントが含まれていないエラー・ページです。

以下に、エラー・ページおよびデフォルト・エラー・ページの例を示します。

デフォルト・エラー・ページの優先順位ルール
web.xmlweb-fragment.xml、および ibm-web-ext.xml の各ファイルでのデフォルト・エラー・ページの優先順位の決定には、以下の 3 つのルールが適用されます。
  • ルール 1: web.xml ファイルおよび web-fragment.xml ファイル。

    デフォルト・エラー・ページが web.xml ファイルで指定されている場合、そのページは、web-fragment.xml ファイルで指定されているすべてのデフォルト・エラー・ページをオーバーライド (マスク) します。 また、複数の web-fragment.xml ファイルでさらにデフォルト・エラー・ページが指定されていても、エラーは発生しません。

  • ルール 2: web-fragment.xml および web-fragment.xml

    デフォルト・エラー・ページが web.xml ファイルで指定されていない場合、異なる複数のデフォルト・エラー・ページが 2 つ以上の web-fragment.xml ファイルで指定されていれば、エラー状態が存在することになります。

  • ルール 3: ibm-web-ext.xml ファイルおよび web.xml ファイルまたは web-fragment.xml ファイル。

    ibm-web-ext.xml ファイルと、web.xml ファイルまたは web-fragment.xml ファイルとの間の優先順位のルールは、Web コンテナー・フィーチャー・レベルによって異なります。

Web コンテナー・フィーチャー・レベルが 3.0 の場合は、ibm-web-ext.xml ファイルで定義されているデフォルト・エラー・ページが、web.xml または web-fragment.xml ファイルで定義されているデフォルト・エラー・ページよりも優先されます。
注: Web コンテナーがフィーチャー・レベル 3.0 を使用している場合、Servlet 3.1 スキーマは使用できません。サーブレット 3.0 スキーマのデフォルト・エラー・ページの使用に関するルールを参照してください。

Web コンテナー・フィーチャー・レベルが 3.1 以上の場合は、web.xml または web-fragment.xml ファイルで指定されているデフォルト・エラー・ページが、ibm-web-ext.xml ファイルで指定されているデフォルト・エラー・ページよりも優先されます。

スキーマ・ルール

web.xml ファイルまたは web-fragment.xml ファイル内のいずれのデフォルト・エラー・ページが処理されるのかに関しては、2 つのルールが適用されます。 ルールは、Web コンテナー・フィーチャーのバージョン、使用されているサーブレット・スキーマ、および Java カスタム・プロパティーの設定によって異なります。

これらのルールが作成されたのは、IBM WebSphere Application Server traditional V8.0 では、V8.0 一般出荷版リリースでデフォルト・エラー・ページがサポートされなかったためです。 デフォルト・エラー・ページのサポートは、サービス・パックで APAR PM94199 によって WebSphere Application Server traditional に追加されました。 サービス・パックの APAR PI05845 によって、WebSphere Application Server Liberty にデフォルト・エラー・ページのサポートが追加されました。これらの更新は、外部に表示される機能の変更であるため、デフォルトでは新機能は無効になっており、Java システム・プロパティーによって有効にする必要があります。

  • ルール 1: Servlet 3.0 スキーマおよび Web コンテナー・フィーチャーのバージョン 3.0 を使用しているデフォルト・エラー・ページ。

    Web コンテナー・フィーチャーのバージョンが 3.0 であり、デフォルト・エラー・ページが Servlet 3.0 スキーマを使用している web.xml ファイルまたは web-fragment.xml ファイルで指定されている場合、デフォルト・エラー・ページが処理されるのは、com.ibm.ws.webcontainer.allowdefaulterrorpage Java システム・プロパティーが true に設定されている場合のみです。 この Java システム・プロパティーが設定されていないか、true に設定されていない場合、デフォルト・エラー・ページは無視されます。ibm-web-ext.xml ファイルで指定されているデフォルト・エラー・ページが使用されます。

  • ケース 2: Web コンテナー・フィーチャーのバージョン 3.1 を使用しているデフォルト・エラー・ページ。

    Web コンテナー・フィーチャーのバージョンが 3.1 以上の場合、使用されているサーブレット・スキーマ・バージョンに関係なく、また Java カスタム・プロパティーが設定されているかどうかに関係なく、web.xml ファイルまたは web-fragment.xml ファイルに指定されているデフォルト・エラー・ページが常に処理されます。

    Servlet 3.1 スキーマを使用している記述子の処理には Web コンテナー・フィーチャーのバージョン 3.1 が必要であるため、このケースは、記述子が Servlet 3.1 スキーマを使用している場合に発生します。

重要: Web フラグメントは、Servlet 3.0 まで追加されていませんでした。web-fragment.xml ファイルには、Servlet 2.5 からのスキーマはありません。
エラー・ページおよびデフォルト・エラー・ページの例
ibm-web-ext.xml ファイルに定義されているデフォルト・エラー・ページ:
<?xml version="1.0" encoding="UTF-8"?>
<web-ext xmlns="http://websphere.ibm.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://websphere.ibm.com/xml/ns/javaee http://websphere.ibm.com/xml/ns/javaee/ibm-web-ext_1_0.xsd"
    version="1.0">

	<default-error-page uri="/ExtErrorPage.html"/>
</web-ext>
web.xml ファイルまたは web-fragment.xml ファイルに定義されている error-code エラー・ページ・エレメント:
	<error-page>
			  <error-code>404</error-code>
<location>/ErrorCodeErrorPage.html</location>
	</error-page>
web.xml ファイルまたは web-fragment.xml ファイルに定義されている exception-type エラー・ページ・エレメント:
	<error-page>
		<exception-type>javax.servlet.ServletException</exception-type>
		<location>/ExceptionTypeErrorPage.html</location>
	</error-page>
web.xml ファイルまたは web-fragment.xml ファイルに定義されているデフォルト・エラー・ページ・エレメント:
	<error-page>
		<location>/DefaultErrorPage.html</location>
	</error-page>
スキーマの例
Servlet 2.5 スキーマを使用している web.xml ファイルのヘッダーの例:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" 
		 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      	xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
      version="2.5">
Servlet 3.0 スキーマを使用している web.xml ファイルのヘッダーの例:
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
      	version="3.0">
Servlet 3.1 スキーマを使用している web.xml ファイルのヘッダーの例:
<?xml version="1.0" encoding="UTF-8"?>
<web-app
    xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
    version="3.1">
Servlet 3.0 スキーマを使用している web-fragment.xml ファイルのヘッダーの例:
<?xml version="1.0" encoding="utf-8"?>
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-fragment_3_0.xsd"
      	version="3.0">
Servlet 3.1 スキーマを使用している web-fragment.xml ファイルのヘッダーの例:
<?xml version="1.0" encoding="utf-8"?>
<web-fragment xmlns="http://java.sun.com/xml/ns/javaee"
      xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
      xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-fragment_3_1.xsd"
      version="3.1">

トピックのタイプを示すアイコン 概念トピック



タイム・スタンプ・アイコン 最終更新: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cweb_servlet_behavior
ファイル名:cweb_servlet_behavior.html