HTTPレスポンスに設定するヘッダ数の制限
J2EEではHTTPレスポンスに設定するヘッダ数に制限がありませんが、Java EE 7では100個までに制限されるようになりました。なお、上限値はネットワーク設定の定義項目の「レスポンスヘッダ数の上限値」で変更可能です。
HTTPリクエストパラメータ数/ヘッダ数の制限
J2EEではHTTPリクエストパラメータ数は特に制限されませんでしたが、Java EE 7では10000個に制限されるようになりました。なお、上限値はネットワーク設定の定義項目の「HTTPリクエストパラメータ数の最大値」で変更可能です。
また、J2EEではHTTPリクエストヘッダ数は特に制限されませんでしたが、Java EE 7では100個に制限されるようになりました。なお、上限値はネットワーク設定の定義項目の「リクエストヘッダ数の上限値」で変更可能です。
キープアライブのタイムアウト値
Java EE 7のキープアライブのタイムアウトを設定する以下の定義項目は、キープアライブ以外のタイムアウト値としても使用されます。詳細は「HTTP接続のタイムアウト」を参照してください。
${clusterName_instanceName_configName}.network-config.protocols.protocol.${protocol-name}.http.timeout-seconds |
本定義項目は以下の3つのタイムアウトとして設定されます。
キープアライブ:Webコンテナがレスポンスを返却後、次のリクエストが来るまでの間キープアライブ接続を維持する時間
HTTPの接続：WebコンテナでHTTP接続後、リクエストがスレッドプールのキューに格納されるまで接続を維持する時間
HTTP接続キュー：Webコンテナでスレッドプールのキューに格納後、リクエストがスレッドで処理を開始されるまで接続を維持する時間
キープアライブを無効にするときは、キープアライブのタイムアウト値を変更する必要はなく、初期値のままで問題ありません。
JSPファイルを読み込むエンコーディング
J2EEではJSP1.2に従い、JSPファイルを読み込むエンコーディングは、コンパイル単位でした。include先のJSPファイルも、include元とおなじエンコーディングで読み込まれます。
Java EE 7ではJSP2.3に従い、JSPファイルを読み込むエンコーディングは、ファイル単位となります。include先のJSPファイルを読み込むエンコーディングは、include元のJSPファイルを読み込むエンコーディングの影響を受けません。(デフォルトISO-8859-1)
初回リクエスト時のJSPコンパイル
J2EE機能の場合は、Webアプリケーション配備後の初回リクエスト時にJSPのコンパイルが行われるだけで、JSPファイルの更新およびコンパイル結果の更新、削除を行わない限りは再度JSPのコンパイルが行われることはありませんでした。
Java EE 7機能の場合は、IJServerクラスタを起動した後の初回リクエスト時に毎回JSPのコンパイルを実施します。
JSPのコンパイルが行われることによる運用環境での一時的な負荷を減らす場合には、JSP事前コンパイル機能を利用して、事前にコンパイル結果を生成した状態で運用を行ってください。詳細は、「2.6.8 JSP事前コンパイル」を参照してください。
JSP事前コンパイル
J2EE機能では、配備後にJSP事前コンパイルを行うことができました。
Java EE 7機能では、配備前、または配備時にのみJSP事前コンパイルを行うことができます。
配備後にJSPの入替えを行う場合には、以下のいずれかの運用を行ってください。
JSPのオートリロード機能を使用してください。
リクエストごと、および一定間隔ごとにJSPの更新チェックを行います。JSPの更新が行われた場合、一時的にJSPコンパイルによる負荷がかかります。詳細は、「2.6.7 JSPのオートリロード」を参照してください。
Webアプリケーションを新たに配備し直してください。
JSP事前コンパイル済みのWebアプリケーションに関しては配備解除を行い、更新したJSPを含めたWebアプリケーションを再度、JSP事前コンパイルを有効にして配備します。
開発環境でコンパイルした結果を本番環境へコピーしてください。
運用環境とは別の環境で配備とJSP事前コンパイルを行い、出力結果を運用環境へコピーします。
詳細は、「2.6.8 JSP事前コンパイル」を参照してください。
JREによるJSPの運用
J2EE機能の場合は、Java Runtime Environment(以降、JREとする)でJSPを含むWebアプリケーションを実行できました。
Java EE 7機能の場合は、JREを使用できません。
要求を受け付けるWebサーバのIPアドレス
Java EE 7機能の環境設定画面は、システムの環境設定「Webサーバとワークユニットを同一のマシンで運用する」の設定の影響を受けません。
Webコンテナが要求を受け付けるWebサーバを制限する必要がある場合には、運用環境に合わせて要求を受け付けるWebサーバのIPアドレスを設定する必要があります。なお、デフォルトの動作は要求を受け付けるサーバのIPアドレスが指定されていない状態となります。この場合、WebコンテナはすべてのWebサーバからのリクエストを受け付けます。
例
以下に、運用環境に合わせた要求を受け付けるWebサーバのIPアドレスを指定する方法を説明します。
Webサーバを同一マシンで運用している場合(ループバックアドレスを指定)
127\.0\.0\.0\.1 |
Webサーバを同一マシンで運用していない場合
192\.168\.10\.5 |
Webブラウザでセションを保存する
J2EE機能で「Webブラウザでセションを保存する」を有効にする場合、サーバ上にあるセッションのセッションタイムアウト時間と、Webブラウザ上で保持するセッションの追跡に使用するcookieの有効時間は連動していました。そのため、サーバ上のセッションがセッションタイムアウトした時点で、Webブラウザが保持するセッションの追跡に使用するcookieは無効となり、Webブラウザからの次のリクエストは最も負荷の少ないWebコンテナ(IJServerプロセス)で処理されました。
Java EE 7機能では、Webブラウザでセッションを保存する場合、セッションの追跡に使用するcookieの有効時間を以下のいずれかで設定します。詳細は「cookie-properties (親タグ:session-config)」を参照してください。
web.xmlの<session-config>-<cookie-config>
Servlet APIのjavax.servlet.SessionCookieConfig
Interstage Web application deployment descriptor (glassfish-web.xml)のcookieプロパティ「cookieMaxAgeSeconds」
そのため、サーバ上にあるセッションのセッションタイムアウト時間と、Webブラウザ上で保持するセッションの追跡に使用するcookieの有効時間は連動しません。セッションタイムアウトとは異なる値を設定すると、サーバ上のセッションがセッションタイムアウトしていても、Webブラウザはセッションを継続するようリクエストし、常に同じWebコンテナ(IJServerプロセス)で処理されます。
本機能を使用する場合には、以下の点に注意してください。
セッションの追跡に使用するcookieの有効時間について
セッションタイムアウト時間よりセッションの追跡に使用するcookieの有効時間が短い場合、サーバ上にあるセッションのセッションタイムアウトよりも先に、Webブラウザが保存するセッションの追跡に使用するcookieが無効となってしまうため、サーバ上に不要なセッションが残存してしまう可能性があります。
以下の何れかで設定しているセッションタイムアウト時間の最大値をセッションの追跡に使用するcookieの有効時間に設定してください。
デフォルト値(30分)
Deployment Descriptor(web.xml)の<session-timeout>タグで指定した値
アプリケーション内でjavax.servlet.http.HttpSession#setMaxInactiveInterval(…)の引数で指定した値
セキュリティについて
Webブラウザを再起動してもセッションを継続できるため、共通端末にあるWebブラウザからリクエストする運用環境では、セッションの情報をユーザ間で共有してしまう恐れがあります。十分に注意してください。
セションの追跡に使用するcookieの破棄
J2EE機能では、以下の場合にWebブラウザにセションの追跡に使用するcookieの破棄を促すヘッダをレスポンスに付加していました。
IJServerでセションの追跡にcookieを使用しない設定(Interstage管理コンソールの[Webアプリケーションの環境設定] > [コンテキスト設定] > [セション]が[クッキーに設定しない])の場合、かつ、Webブラウザからのリクエストにセションの追跡に使用するcookieが付加されている場合(セションを使用するアプリケーションを運用中に該当の設定を切り替えた場合に発生)
Webブラウザからのリクエストにセションの追跡に使用するcookieが付加されてきたが、レスポンス時にサーバ上でセションが無効な場合(セションのタイムアウト後またはセション破棄済みである場合)
これにより、セションを破棄(ログアウトなど)またはセションタイムアウトした後のリクエストは以前と同じWebコンテナ(IJServerプロセス)ではなく、リクエスト時点で負荷(リクエスト処理多重度)のもっとも小さいWebコンテナで処理されました。
Java EE 7機能では、セションの破棄cookieはレスポンスに付加されません。
そのため、セションを破棄した後に同じWebブラウザから(Webブラウザの再起動なしに)リクエストした場合、以前と同じWebコンテナでリクエストが処理されます。
Webブラウザで保持しているセッションの追跡に使用するcookieを削除するためには、Webブラウザを再起動してください。
ただし、「Webブラウザでセションを保存する」を有効にしている場合、Webブラウザの再起動では削除されません。Webブラウザの設定に従って、手動でセッションの追跡に使用するcookieを削除してください。
マッピングがなくてもサーブレットが動作する
Java EE 7機能では、本機能は使用できません。
J2EE機能で本機能を使用していた場合、deployment descriptor(web.xml)にマッピングを記述してください。
「/servlet/サーブレットクラス名」または「/servlet/サーブレット名」にマッピングすることによって、Webアプリケーションのプログラム修正を行わずに移行することが可能です。以下に、修正方法を説明します。
例
サーブレットクラス名で運用していた場合のdeployment descriptor(web.xml)
<servlet>
<servlet-name>TestServlet</servlet-name>
<servlet-class>com.fujitsu.interstage.NonMappingServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>TestServlet</servlet-name>
<url-pattern>/servlet/com.fujitsu.interstage.NonMappingServlet</url-pattern>
</servlet-mapping> |
サーブレット名で運用していた場合のdeployment descriptor(web.xml)
<servlet>
<servlet-name>TestServlet</servlet-name>
<servlet-class>com.fujitsu.interstage.NonMappingServlet</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>TestServlet</servlet-name>
<url-pattern>/servlet/TestServlet</url-pattern>
</servlet-mapping> |
注意
以下の理由によりセキュリティ上の問題があるため、本製品では「マッピングがなくてもサーブレットが動作する」の使用を推奨していません。
deployment descriptor(web.xml)の定義がなくてもすべてのサーブレットが呼出し可能となってしまう。
Webアプリケーション内で使用しているクラスなど、内部構造が外部に漏れてしまう。
サーブレットはdeployment descriptor(web.xml)にマッピングを記述して呼び出してください。
Interstage HTTP ServerがBASIC認証した情報の取得について
J2EE機能では、デフォルトではInterstage HTTP ServerがBASIC認証した情報を使用できません。
Interstage管理コンソールの[システム] > [ワークユニット] > [IJServer] > [配備] > [詳細設定]画面で、設定できます。
Java EE 7機能では、デフォルトでInterstage HTTP Server 2.2がBASIC認証した情報を使用できます。ただし、上記のような設定項目はなく、使用不可にはできません。そのため、Interstage HTTP Server 2.2がBASIC認証した情報を取得できないようにしたい場合はInterstage HTTP Server 2.2を使用するのをやめて、Java EE 7側でBASIC認証してください。
レスポンスヘッダに指定する文字コード
Java EE 7では、印字可能なASCIIコード範囲外の文字をHTTPレスポンスヘッダに設定すると、半角空白に置き換えられてクライアントに返却されるようになりました。
そのため、HTTPレスポンスヘッダにContent-Dispositionヘッダを設定することによりファイルのダウンロードが行われる場合は、レスポンスヘッダのURLエンコードが必要です。詳細は、「レスポンスヘッダに指定する文字コード」「日本語などのASCIIではないファイル名のファイルをダウンロードする場合」を参照してください。
ネットワークの共有資源へアクセスする場合 
ネットワークの共有資源へアクセスする場合、再度設定が必要になります。詳細は「3.1.12 ネットワークの共有資源へアクセスする場合の環境設定」を参照してください。
J2EE機能のTomcat4.1ベースのServletサービス、Tomcat5.5ベースのServletサービスと、Java EE 7機能のWebコンテナのアプリケーション動作の非互換項目を以下に示します。該当する機能をWebアプリケーションで使用している場合には、Webアプリケーションを修正してください。
Servlet/JSP仕様の差分については、Java(TM) Servlet SpecificationおよびJavaServer Pages(TM) Specificationをあわせて参照してください。
またシステム移行の際には、運用前に業務の観点で十分な動作検証を実施してください。
Tomcat 3.1ベースのServletサービスとの動作については、「J2EE ユーザーズガイド(旧版互換)」の「旧機能から新機能への移行方法」-「Servletサービス(Tomcat5.5ベースのサーブレット実行環境)への移行」-「アプリケーションの非互換一覧」を参照してください。
No. | 機能 | J2EE機能 | Java EE 7機能のWebコンテナ | |
|---|---|---|---|---|
Tomcat4.1ベースのServletサービス | Tomcat5.5ベースのServletサービス | |||
| カスタムタグのTag#release()メソッド | カスタムタグの開発で実装するjavax.servlet.jsp.tagext.Tagインタフェースのpublic void release()メソッドは、Webアプリケーション終了時に呼び出されます。 public void doCatch(Throwable t) | ||
| Webブラウザに返却されるステータスコード | Webアプリケーション環境定義ファイルに<error-page>タグが設定されている場合にも、発生した現象のステータスコードがそのまま返却されます。 | Webアプリケーション環境定義ファイルに<error-page>タグが設定されている場合にも、発生した現象のステータスコードがそのまま返却されます。 | |
| JSPの呼出し(更新の反映契機) | JSPまたはJSPから静的includeしているファイルを更新した場合、前回コンパイルされた日時よりも新しい日付のJSPファイルの場合に反映されます。 | JSPまたはJSPから静的includeしているファイルを更新した場合、前回コンパイルされた日時よりも新しい日付のJSPファイルの場合に反映されます。「JSPの入れ替えについて」も参照してください。 | |
| Webアプリケーション環境定義ファイルの<servlet>タグ内の<load-on-startup>タグ | 0を指定した場合は最後にロードされます。 | 0を指定した場合は最初にロードされます。 | |
-2147483648～2147483647以外の値を指定した場合もWebアプリケーションの起動は成功します。 | -2147483648～2147483647以外の値を指定した場合は配備エラーになります。 | |||
| Webブラウザにスタックトレースを表示 | 内部の情報が漏洩する可能性があるため、リクエストの処理でErrorやExceptionが発生した場合、Webブラウザにスタックトレースを表示しません。 Tomcat 3.1ベースのServletサービスでの動作については、「J2EE ユーザーズガイド(旧版互換)」の「旧機能から新機能への移行方法」-「Servletサービス(Tomcat5.5ベースのサーブレット実行環境)への移行」-「アプリケーションの非互換一覧」を参照してください。 | ||
| Webアプリケーション環境定義ファイルの<servlet-mapping>タグ内の<servlet-name>タグ | 指定していない名前を記述した場合は、Webアプリケーションの起動に失敗します。 | 指定していない名前を記述した場合は、Webアプリケーションの配備に失敗します。 | |
| Webアプリケーション環境定義ファイルの<welcome-file-list>タグ内の<welcome-file>タグ | welcome fileを省略した場合、デフォルト設定が使用されます。デフォルト設定のファイルは以下の順番で有効になります。 | welcome fileを省略した場合、デフォルト設定が使用されます。デフォルト設定のファイルは以下の順番で有効になります。 | |
| Webアプリケーション環境定義ファイルの<env-entry>タグ内の<env-entry-value>タグ | <env-entry-value>タグを省略した場合には、デフォルト値が設定されます。 (注1) Tomcat 3.1ベースのServletサービスでの動作については、「J2EE ユーザーズガイド(旧版互換)」の「旧機能から新機能への移行方法」-「Servletサービス(Tomcat5.5ベースのサーブレット実行環境)への移行」-「アプリケーションの非互換一覧」を参照してください。 | <env-entry-value>タグを省略して環境エントリをlookupした場合にはjavax.naming.NamingExceptionまたはそのサブクラスが投げられます。 | |
| Webアプリケーション環境定義ファイルの<taglib-location>タグで存在しないパスを指定した場合 | Webアプリケーションの起動に失敗します。 | 無効となります。 | |
| WEB-INF配下にXMLの文法に誤りのあるTagLibraryDescriptorファイルが存在した場合 | メッセージ「IJServer15111」がコンテナログに出力され、Webアプリケーションの起動に失敗します。 | メッセージは出力されますが、Webアプリケーションの起動は成功します。 | Webアプリケーションの配備に失敗、またはWebアプリケーションの起動に失敗します。 |
| Webアプリケーション環境定義ファイルの<servlet-mapping>タグ内の<url-pattern>タグ | 特定の拡張子をもつURLを指定した場合(例:*.jsp)は、URL内の「/」と「/」で囲まれた箇所もマッピング対象とならず、最後の「/」以降がマッピング対象となります。 Tomcat 3.1ベースのServletサービスでの動作については、「J2EE ユーザーズガイド(旧版互換)」の「旧機能から新機能への移行方法」-「Servletサービス(Tomcat5.5ベースのサーブレット実行環境)への移行」-「アプリケーションの非互換一覧」を参照してください。 | ||
| Webアプリケーション環境定義ファイルの<welcome-file-list>タグ内の<welcome-file>タグに指定されたファイルを表示する場合の動作 |
| URLが「/」で終わっていない場合、URLの最後に「/」を追加した値をLocationヘッダに指定し、ステータスコード:301を返します。 | |
URLが「/」で終わっている場合、<welcome-file>タグに指定されたファイル名を追加したURLをLocationヘッダに指定し、ステータスコード:302を返します。そのため、指定したコンテンツ先で取得できるリクエストのURLなどのパス情報は、ブラウザが再度リクエストを発行(リダイレクト)した時の情報となります。 | URLが「/」で終わっている場合、<welcome-file>タグに指定されたコンテンツを直接処理して返します。そのため、指定したコンテンツ先で取得できるリクエストのURLなどのパス情報は、ブラウザからリクエストされてきたパスのままとなり、<welcome-file>タグで指定したコンテンツを含むパスとはなりません。 | URLが「/」で終わっている場合、<welcome-file>タグに指定されたコンテンツを直接処理して返します。そのため、指定したコンテンツ先で取得できるリクエストのURLなどのパス情報は、ブラウザからリクエストされてきたパスのままとなり、<welcome-file>タグで指定したコンテンツを含むパスとはなりません。 | ||
| 複数のAccept-Languageヘッダを持つリクエストを受け付けた場合のHttpServletRequest#getHeaders()メソッドの動作 (注2) | 「,」で区切られた値を1つの要素としてEnumerationが返されます。 Tomcat 3.1ベースのServletサービスでの動作については、「J2EE ユーザーズガイド(旧版互換)」の「旧機能から新機能への移行方法」-「Servletサービス(Tomcat5.5ベースのサーブレット実行環境)への移行」-「アプリケーションの非互換一覧」を参照してください。 | ||
| レスポンスのデフォルトLocale | "en_US"です。 | デフォルトではサーバのLocaleとなります。 | |
| レスポンスのコミット後またはgetWriterメソッド呼出し後の、setLocaleメソッドまたはsetContentTypeメソッド呼出しのレスポンスのエンコーディングへの反映 (注4) | 「setLocaleメソッドまたはsetContentTypeメソッド呼出しのレスポンスのエンコーディングへの反映」を参照してください。 | ||
| レスポンスのsetLocaleメソッドまたはsetContentTypeメソッド(引数のmimeタイプ文字列にcharset属性を含む) (注5)によりレスポンスのエンコーディングを設定済みで、setContentTypeメソッドをcharset属性を含まないmimeタイプ文字列を指定して呼び出した場合の動作 (注6) | レスポンスのWriterによるデータの書き出しには反映されますが、レスポンスのContent-Typeヘッダにはcharset属性は付加されません。 | Servletの仕様に従い、レスポンスのWriterによるデータの書き出し、Content-Typeヘッダのcharset属性ともに、先に設定済みのエンコーディングが反映されます。 | |
| レスポンスのsetContentTypeメソッドをcharset属性ありのmimeタイプ文字列を指定して呼び出した (注5)後の、setLocaleメソッドのレスポンスのエンコーディングへの反映 (注6) | 反映されます。 | Servletの仕様に従い、反映されません。 | |
| setLocaleメソッドまたはsetContentTypeメソッドでエンコーディングを指定しない場合のレスポンスのエンコーディング | レスポンスのWriterによるデータの書き出しはISO-8859-1となりますが、レスポンスのContent-Typeヘッダに、charset属性は付加されません。 | レスポンスのWriterによるデータの書き出し、およびContent-Typeヘッダのcharset属性はISO-8859-1となります。 | |
| getWriterでcharsetを指定する場合のエラーページ処理のエンコーディングへの反映 | getWriterで指定したcharsetの内容が、エラーページ処理に引き継がれません。 | getWriterで指定したcharsetの内容が、エラーページ処理に引き継がれます。 | getWriterで指定したcharsetの内容が、エラーページ処理に引き継がれません。 |
| JSPのpageディレクティブで明示的にpageEncodingまたはcontentType属性を指定しない場合のデフォルトエンコーディング | レスポンスのデータの書き出しはISO-8859-1、Content-Typeヘッダは"text/html;charset=ISO-8859-1"となります。 Tomcat 3.1ベースのServletサービスでの動作については、「J2EE ユーザーズガイド(旧版互換)」の「旧機能から新機能への移行方法」-「Servletサービス(Tomcat5.5ベースのサーブレット実行環境)への移行」-「アプリケーションの非互換一覧」を参照してください。 | ||
| サーブレットのserviceが、永久的に使用不能な状態であること示すUnavailableExceptionをthrowした時の動作 | Servlet2.3では規定されていませんが、基本的にステータスコード503を返却。 | ステータスコード404を返却。 | |
| deployment descriptor(web.xml)のtaglibタグ | <taglib>タグは、<web-app>タグの直下に記載します。 | web.xmlのバージョンがServlet 2.4以上の場合、<taglib>タグは、<jsp-config>タグ配下に記載します。 | |
| server.xml定義ファイルへのrealmの設定 | Tomcat4.1と同様のrealmタグを設定することができます。 | できません。ディレクトリサービスを使用してください。 | server.xml定義ファイルはありませんが、fileレルムなどを使用できます。レルムの設定については、「5.4 セキュリティ機能を利用した運用方法」を参照してください。 |
| 「コンテキストの共有」有効時のセション | Webアプリケーション環境設定の「コンテキストの共有」を「する」に設定し、Webアプリケーションから別のWebアプリケーションに、RequestDispatcherを使用してディスパッチした場合、ディスパッチ前と後で使用するセションは同じとなります。 | Webアプリケーション環境設定の「コンテキストの共有」を「する」に設定し、Webアプリケーションから別のWebアプリケーションに、RequestDispatcherを使用してディスパッチした場合、Servletの仕様に厳密に従い、セションは別のものとなります。セションの属性は共有されません。ディスパッチ前のセションの情報(属性)をディスパッチ後に使用したい場合は、リクエストの属性として(ServletRequest#setAttributeメソッド等を使用して)受渡を行う等、アプリケーションで対応してください。 | Interstage Web application deployment descriptor(glassfish-web.xml)の<property>タグで「crossContextAllowed」プロパティを「true」に設定し、Webアプリケーションから別のWebアプリケーションに、RequestDispatcherを使用してディスパッチした場合、Servletの仕様に厳密に従い、セションは別のものとなります。セションの属性は共有されません。ディスパッチ前のセションの情報(属性)をディスパッチ後に使用したい場合は、リクエストの属性として(ServletRequest#setAttributeメソッド等を使用して)受渡を行う等、アプリケーションで対応してください。 |
| HttpSessionのgetAttribute(null)呼出し時 | nullが返却されます。 | NullPointerExceptionとなります。 | nullが返却されます。 |
| JSPのコンパイル | JSPの仕様に沿っていなくてもコンパイル/実行できる場合がありました。 | JSPの仕様に沿っていない場合は動作しない可能性があります。
修正しない場合は、事前に充分な動作検証を行ってください。 | |
| HttpSessionListenerのsessionDestroyed | セションが破棄された後に呼び出されます。 | セションが破棄される前に呼び出されます。 | |
| HttpSessionBindingListenerのvalueBound | オブジェクトがHttpSessionのgetAttributeで取得できる状態になってから呼び出されます。 | オブジェクトがHttpSessionのgetAttributeで取得できる状態になる前に呼び出されます。 | |
| Webアプリケーション環境定義ファイルのタグの順番 | <env-entry>タグ配下は以下の順で記載します。 | <env-entry>タグ配下は以下の順で記載します。 | |
| JSPのタグの書式 | 以下の例のように、タグ～閉じタグ(ETag)間に子タグやBODYがなく、改行などがあっても動作する場合がありました。 | JSP2.0では許可される書式が明示され、左記のような記述はコンパイル時にエラーとなります。JSPの仕様に従い、以下のようにしてください。 | |
| JSPのBeanのプロパティ値がnullの場合の動作 | JSPのBeanのプロパティ値がnullの場合、<jsp:getProperty>アクションの出力は""(空文字列)となります。 | JSPの仕様に従い、出力は"null"となります。
Interstage管理コンソールの[ワークユニット] > 「ワークユニット名」 > [環境設定]タブ > [詳細設定] > [ワークユニット設定] > [JavaVMオプション]に「-Dcom.fujitsu.interstage.jservlet.jsp.bean. | JSPの仕様に従い、出力は"null"となります。 |
| Webアプリケーション環境定義ファイルの<security-constraint>タグ内の<auth-constraint>タグ内の<role-name>タグ | "*"を指定する場合、<security-role>タグを定義しなくてもリソースにアクセスできます。 | "*"を指定する場合、<security-role>タグに有効な<role-name>タグが定義されていなければリソースにアクセスできません。 | "*"を指定する場合、<security-role>タグに有効な<role-name>タグが定義されていなければ認証が行われません。そのため、web.xmlの<security-role>タグには有効な<role-name>タグを指定してください。 |
| JSPのファイルエンコーディング | JSP1.2に従い、JSPファイルを読み込むエンコーディングは、コンパイル単位でした。include先のJSPファイルも、include元とおなじエンコーディングで読み込まれます。 | JSP2.0に従い、JSPファイルを読み込むエンコーディングは、ファイル単位となります。include先のJSPファイルを読み込むエンコーディングは、include元のJSPファイルを読み込むエンコーディングの影響を受けません。(デフォルトISO-8859-1) Tomcat4.1ベース以前のServletサービスと同様の動作をするには、include先のJSPファイルにエンコーディングを明に設定します。 | |
| JSPでカスタムタグライブラリ使用時の動作 | TLD(Tag Library Description file)にて、対象のタグのbody-contentに「TAGDEPENDENT」(大文字)指定でも動作可能です。 | TLD(Tag Library Description file)にて、対象のタグのbody-contentに「TAGDEPENDENT」(大文字)は指定できません。仕様に従い、「tagdependent」(小文字)を指定してください。 | |
XML構文のJSP(JSP Documents)の場合、TLD(Tag Library Description file)にて、対象のタグのbody-contentに「tagdependent」(「TAGDEPENDENT」)を指定し、タグのボディで<jsp:text>などを使用した場合、ボディは処理された後にタグライブラリに渡されます。 | XML構文のJSP(JSP Documents)の場合、TLD(Tag Library Description file)にて、対象のタグのbody-contentに「tagdependent」を指定し、タグのボディで<jsp:text>などを使用した場合、ボディは処理されずにそのままタグライブラリに渡されます。仕様通りの正しい動作です。 Tomcat4.1ベース以前のServletサービスと同じ動作をさせたい場合は、TLD(Tag Library Description file)にて、body-contentに「JSP」を指定してください。 なおServletの仕様に従い、参照するTLDファイルは必ずWebアプリケーション内に存在している必要があります。 | |||
| サーブレットコンテキストの初期化パラメタ | サーブレットコンテキストの初期化パラメタ(<context-param>タグ)の複数指定時、重複したパラメタ名(<param-name>タグ)がある場合、最後に指定したものが有効となります。 | 重複したパラメタ名は指定できません。定義エラーとなります。 | サーブレットコンテキストの初期化パラメタ(<context-param>タグ)の複数指定時、重複したパラメタ名(<param-name>タグ)がある場合、最初に指定したものが有効となります。 |
| 無効なセションのgetLastAccessedTimeメソッド呼出し | 無効なセション(破棄やタイムアウトしたセション)のgetLastAccessedTimeメソッドを呼出し可能です。 | 無効なセション(破棄やタイムアウトしたセション)のgetLastAccessedTimeメソッドを呼び出した場合、IllegalStateExceptionとなります。 | |
| Webアプリケーション環境定義ファイルの<display-name>タグを省略した場合のServletContext#getServletContextName()の値 | <display-name>タグを省略した場合はnullが返却されます。 | <display-name>タグを省略した場合は空文字が返却されます。 | |
| サーブレットの初期化パラメタ | サーブレットの初期化パラメタ(<init-param>タグ)の複数指定時、重複したパラメタ名(<param-name>タグ)がある場合、最後に指定したものが有効となります。 | サーブレットの初期化パラメタ(<init-param>タグ)の複数指定時、重複したパラメタ名(<param-name>タグ)がある場合、最初に指定したものが有効となります。 | |
| Webアプリケーション環境定義ファイルの<listener-class>タグ | <listener-class>タグに存在しないクラスを指定した場合は、IJServer起動時にコンテナログにエラーが出力され、アプリケーションの状態は"非活性"になります。また、そのアプリケーションにアクセスした場合にはステータスコード404(ファイルが存在しない)が表示されます。 | <listener-class>タグに存在しないクラスを指定した場合は、Webアプリケーションの配備に失敗、またはWebアプリケーションの起動に失敗します。 | |
| JSFの実装クラス | JSFの実装クラスを用意してアプリケーションに含めるか、またはクラスパスに設定する必要があります。 | JSFがJava EE に含まれるようになり、Java EEコンテナで実装クラスをロードするため、アプリケーション側でJSFの実装を保持する必要がありません。 また、JSFの実装クラスをアプリケーションやクラスパスに含めた場合は、動作保障ができないため、Java EEで保持しているJSFの実装クラスを利用するようにしてください。 | |
| ServletRequestのgetServerName | リクエストを受信したサーバのホスト名。 CGI変数のSERVER_NAMEと同じ値が返ります。 | リクエストを受信したサーバのホスト名。 リクエストヘッダのHostヘッダの値が返ります。Hostヘッダがない場合は、CGI変数のSERVER_NAMEと同じ値が返ります。 | リクエストを受信したサーバのホスト名。 リクエストヘッダのHostヘッダの値が返ります。Hostヘッダがない場合は、以下の通りです。
|
| ServletRequestのgetServerPort | リクエストを受信したサーバのポート番号。 CGI変数のSERVER_PORTと同じ値が返ります。 | リクエストを受信したサーバのポート番号。 リクエストヘッダのHostヘッダの値が返ります。Hostヘッダがない場合は、CGI変数のSERVER_PORTと同じ値が返ります。 | リクエストを受信したサーバのポート番号。 リクエストヘッダのHostヘッダの値が返ります。Hostヘッダがない場合は、以下の通りです。
|
| HttpServletResponseのsendRedirect | 指定された相対URLを用いて、クライアントに一時的なリダイレクトレスポンスを送信します。 Servletコンテナによる絶対URLへの変換は、CGI変数のSERVER_NAMEおよびSERVER_PORTと同じ値が使用されます。 | 指定された相対URLを用いて、クライアントに一時的なリダイレクトレスポンスを送信します。 Servletコンテナによる絶対URLへの変換は、リクエストヘッダのHostヘッダの値が使用されます。Hostヘッダがない場合は、CGI変数のSERVER_NAMEおよびSERVER_PORTと同じ値が使用されます。 | 指定された相対URLを用いて、クライアントに一時的なリダイレクトレスポンスを送信します。 Webコンテナによる絶対URLへの変換は、リクエストヘッダのHostヘッダの値が使用されます。Hostヘッダがない場合は、以下の通りです。
|
| HTTPレスポンスのヘッダ数 | 「HTTPレスポンスに設定するヘッダ数の制限」を参照してください。 | ||
| HTTPリクエストパラメータ数 | 「HTTPリクエストパラメータ数/ヘッダ数の制限」を参照してください。 | ||
| HTTPリクエストのヘッダ数 | 「HTTPリクエストパラメータ数/ヘッダ数の制限」を参照してください。 | ||
| HTTPレスポンスヘッダに指定する文字コード | 「レスポンスヘッダに指定する文字コード」を参照してください。 | ||
以下のデフォルト値が設定されます。
env-entry-type | エントリ値 |
|---|---|
java.lang.Boolean | Boolean.FALSE |
java.lang.Byte | 値0のByteオブジェクト |
java.lang.Character | 値0のCharacterオブジェクト |
java.lang.String | なし |
java.lang.Short | 値0のShortオブジェクト |
java.lang.Integer | 値0のIntegerオブジェクト |
java.lang.Long | 値0のLongオブジェクト |
java.lang.Float | 値0のFloatオブジェクト |
java.lang.Double | 値0のDoubleオブジェクト |
例
Accept-Language: ja
Accept-Language: es
Tomcat4.1ベースのServletサービスからの移行の場合、<welcome-file>でディレクトリ階層の異なるパス(途中に'/'を含むパス)を指定し、そのパスで示されるコンテンツから相対パスのリンクがあると、リンク先が意図したURIとならず、コンテンツが参照できない場合があります。以下のどちらかの対応を行ってください。
<welcome-file>でディレクトリ階層の異なるコンテンツを指定しない。
<welcome-file>で指定したページ中のリンクについて、コンテキストパスを含むパスとする。
例
<welcome-file>が「/jsp/welcome.jsp」、Webアプリケーション名が「sample」、JSPからのリンクが「../next.jsp」の場合、リンク先を、「/sample/next.jsp」とする。
動的コンテンツ(JSPやServlet)の場合は、以下のようにコンテキストパスを動的に取得することも可能です。(推奨)
リンク先を、request.getContextPath()+"/next.jsp" とする。
※実際には、必要に応じてHttpServletResponseのencodeURLメソッド等をあわせて使用してください。
仕様に従っていないアプリケーションの場合であり、記載のTomcat4.1ベースのServletサービスの動作が保障されるものではありません。
JSPのpageディレクティブでpageEncoding属性を指定している場合、または、contentType属性にcharsetを指定している場合も含まれます。
No.15が前提です。
setLocaleメソッドまたはsetContentTypeメソッド呼出しのレスポンスのエンコーディングへの反映
Tomcat4.1ベースのServletサービス | Tomcat5.5ベースのServletサービス | Java EE 7機能のWebコンテナ | |||||
|---|---|---|---|---|---|---|---|
getWriterメソッド | レスポンスのコミット | Content-Typeヘッダのcharset属性 | データの書き出し | Content-Typeヘッダのcharset属性 | データの書き出し | Content-Typeヘッダのcharset属性 | データの書き出し |
呼出し前 | コミット前 | 反映される | 反映される | 反映される | 反映される | 反映される | 反映される |
コミット後 | 反映されない | 反映されない | 反映されない | 反映されない | 反映されない | 反映されない | |
呼出し後 | コミット前 | 反映される | 反映される | 反映されない | 反映されない | 反映されない | 反映されない |
コミット後 | 反映されない | 反映されない | 反映されない | 反映されない | 反映されない | 反映されない | |
