WebSphere Application Server, Version 6.1   
             オペレーティング・システム: AIX , HP-UX, Linux, Solaris, Windows, Windows Vista

             目次と検索結果のパーソナライズ化

JavaServer Pages マイグレーションのベスト・プラクティスと考慮事項

JSP 1.1 の標準的な JavaServer Pages (JSP) タグ (jsp:include、jsp:useBean、 <%@ page %> など) は、JSP 2.0 に正常にマイグレーションされます。 しかし、JavaServer Pages をマイグレーションする際に考慮しなければならない領域がいくつかあります。 このトピックでは、JavaServer Pages のマイグレーション時に考慮する必要のある領域について説明します。

名前のないパッケージまたはデフォルトのパッケージからのクラス

JSP 2.0 では、名前のないパッケージまたはデフォルトのパッケージからのクラスへの参照は許可されていません。 このため、一部のコンテナーで変換エラーが発生することがあります。 具体的には、JDK 1.4 以上の環境で実行されるコンテナーで、この環境は、一部の古い JSP アプリケーションとも互換性がありません。 ただし、JDK 1.4 では、名前のないパッケージからクラスをインポートすることはできません。 詳しくは、「Java 2 Platform, Standard Edition Version 1.4.2 Compatibility with Previous Releases」を参照してください。 したがって、前方互換性に関しては、 アプリケーションは名前のないパッケージに依存することはできません。 この制約事項は、 クラスを参照する他のすべての場合 (例えばタグ・ライブラリー記述子 (TLD) ファイルで タグのクラス名を指定する場合) にも適用されます。

JSP 文書のページ・エンコード

JSP 1.2 仕様にあいまいな点があったため、一部のコンテナーについて、その国際化対応の振る舞いにかなりの違いがありました。 しかし、 後方互換性に関する影響を最小限にとどめる手段が取られた結果、JSP ファイルの国際化対応機能は、全体として、大幅に改善されました。

JSP 仕様の JSP 2.0 より古いバージョンでは、XML 構文の JSP ページ、JSP 文書、および標準構文の JSP 文書の ページ・エンコードを同じ方法で決定していました。つまり、 ページ・ディレクティブの pageEncoding 属性または contentType 属性を調べるという方法で決定していました。 どちらの属性も存在しない場合は、デフォルトとして ISO-8859-1 が使用されていました。

JSP 2.0 では、JSP 文書のページ・エンコードは XML 仕様のセクション 4.3.3 および 付録 F.1 で説明されている方法で決定されます。これらのページの pageEncoding 属性は、 XML 仕様によって決まるページ・エンコードとの整合性を確認するためだけに検査されます。 この変更の結果、 pageEncoding 属性によって決定されるページ・エンコードに依存する JSP 文書は、正しくデコードされなくなりました。 このような JSP 文書は、適切な XML エンコード宣言を含むように変更する必要があります。

さらに、JSP 1.2 ではページ・エンコードが変換単位を基本に決定されるのに対し、 JSP 2.0 では個々のファイルを基本として決定されます。 したがって、 a.jsp ファイルに b.jsp ファイルが静的に組み込まれ、 a.jsp ファイルではページ・エンコードが指定されているが、 b.jsp ファイルでは指定されていないという場合、JSP 1.2 では b.jsp ファイルに対して a.jsp ファイルのエンコードが使用されますが、JSP 2.0 では、 b.jsp ファイルに対してデフォルト・エンコードが使用されます。

web.xml ファイルのバージョン

JSP コンテナーは、 web.xml ファイルのバージョンによって、実行中の アプリケーションが JSP 1.2 か JSP 2.0 かを判断します。 さまざまなフィーチャーが、web.xml ファイルのバージョンによって異なる振る舞いをします。 以下に、web.xml ファイルのバージョンをサーブレット 2.3 からサーブレット 2.4 に アップグレードする際に JSP 開発者が注意すべき事柄をリストします。
  1. JSP 1.2 アプリケーションでは、デフォルトで EL 式は無視されます。 Web アプリケーションを JSP 2.0 にアップグレードすると、デフォルトで EL 式が解釈されるようになります。 エスケープ・シーケンス ¥$ を使用することで、コンテナーに解釈させたくない EL 式をエスケープすることができます。 あるいは、isELIgnored ページ・ディレクティブ属性または <el-ignored> 構成要素を使用して、変換単位全体で EL を非アクティブにすることもできます。 JSTL 1.0 のユーザーは、 タグ・ライブラリーのインポートを JSTL 1.1 の URI にアップグレードするか、タグの _rt バージョンを 使用する (例えば c ではなく c_rt、fmt ではなく fmt_rt を使用) 必要があります。
  2. 拡張子が .jspx のファイルを含む Web アプリケーションは、 デフォルトでは、それらのファイルを JSP 文書と解釈します。 JSP 構成要素 <is-xml> を 使用すると、.jspx ファイルを正規の JSP ページとして処理できますが、 JSP コンテナーから .jspx を分離する方法はありません。
  3. エスケープ・シーケンス ¥$ は、JSP 1.2 では予約されていませんでした。 JSP 1.2 で ¥$ として表される任意のテンプレート・テキストまたは属性値の出力は ¥$ でしたが、今では $ だけになっています。

jsp:useBean タグ

WebSphere Application Server バージョン 5.1 以降では、タイプおよびクラス属性を伴う jsp:useBean タグの仕様に、より厳密に準拠しています。 具体的には、JavaBean としてインスタンス生成できない Java タイプを指定する際に型属性を使用するようにしてください。 例えば、抽象クラス、インターフェース、または 引数なしのパブリック・コンストラクターを持たないクラス、などの Java タイプです。 クラス属性が、JavaBean としてインスタンス生成できない Java タイプで使用される場合、 WebSphere Application Server の JSP コンテナーは、変換時に、リカバリー不能な変換エラーを出します。

JSP クラスの生成済みパッケージ

JSP クラスの生成済みパッケージに依存すると、移植不能な JSP ファイルが生成されます。 生成済みクラスのパッケージは実装固有のものであるため、これらのパッケージには依存しないようにしてください。

JspServlet クラス

JspServlet クラスの存在に依存すると、リカバリー不能エラーの問題が発生します。 WebSphere Application Server バージョン 6.0 以降では、JspServlet クラスは使用されなくなりました。




関連概念
JavaServer Pages
関連タスク
WebSphere Application Server バージョン 5.x からの Web アプリケーション・コンポーネントのマイグレーション
参照トピック    

ご利用条件 | フィードバック

最終更新: Jan 21, 2008 5:05:53 PM EST
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r1/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rweb_jsp_migration.html