Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
![]() 戻る |
![]() 次へ |
以下の節では、JavaServer Pages (JSP) の作成に関するリファレンス情報を提供します。
以下の表では、JSP ページで使用できる基本的なタグについて説明します。短縮形のタグには、それぞれ対応する XML タグがあります。
表 13-1 JSP ページの基本タグ
JSP タグ | 構文 | 説明 |
---|---|---|
スクリプレット |
<% java_code %> または対応する以下の XML タグを使用する
|
Java ソース コード スクリプトレットを、HTML ページ内に埋め込む。Java コードが実行され、その出力が順に残りの HTML と共にページへ挿入される。詳細については、「スクリプトレット」を参照。 |
ディレクティブ |
または対応する以下の XML タグを使用する
|
ディレクティブには、アプリケーション サーバへのメッセージが含まれる。 また、 |
宣言 |
<%! declaration %> または対応する以下の XML タグを使用する <jsp:declaration> declaration; </jsp:declaration> |
ページ内の他の宣言、スクリプトレット、または式から参照できる変数またはメソッドを宣言する。「宣言」を参照。 |
式 |
<%= expression %> または対応する以下の XML タグを使用する
|
ページを要求するときに評価され、 |
アクション |
<jsp:useBean ... > Bean をここでインスタンス化する場合は、ここに JSP 本文を入れる
|
JSP の高度な機能へのアクセスを提供し、XML 構文のみを使用する。これらのアクションは、JSP 2.1 仕様の定義のとおりにサポートされている。「アクション」を参照。 |
コメント |
<%/* comment */%> |
HTML ファイルの表示可能なソースからコメントを削除する場合は、JSP コメント タグのみを使用すること。ブラウザでソースの表示を選択した場合、HTML のコメントは表示されたままになる。 |
JSP 2.1 ではいくつかの新機能が導入され、同じ構文が JSP 2.1 と JSP 2.0 間で異なる意味を持つ場合があるため、想定する動作を実現するには JSP バージョンを定義する必要があります。次に例を示します。
<%@ page deferredSyntaxAllowedAsLiteral="true" %>
は JSP 2.0 では使用できない。
# {expr}
は JSP 2.0 のテンプレート テキストでは有効だが、JSP 2.1 ではデフォルトで無効になっている。
JSP ページのバージョンは、明示的な指定方法がないため、次のように Web アプリケーションのバージョンによって決まります。
JSP ドキュメントのバージョンは、ドキュメント内に <jsp:root>
がある場合はその属性のバージョン値によって決まり、ない場合は Web アプリケーションのバージョンによって決まる。
Web アプリケーションのバージョンによって JSP バージョンが決まる場合、2.5 はそのバージョンが JSP 2.1 であることを、2.4 はそのバージョンが JSP 2.0 であることを示す。
JSP ドキュメントに <jsp:root>
があり、Web アプリケーションのバージョンが 2.4 である場合、<jsp:root>
のバージョンは 2.0 を超えてはならないが、Web アプリケーションのバージョンが 2.5 の場合は、<jsp:root>
のバージョンは 2.1 未満でもよい。
参照されるすべての JSP タグ バージョンは、現在の JSP ファイルのバージョンを超えてはならない。
すべての JSP タグ ファイルのバージョンは、そのタグ ファイルが属するタグ ライブラリのバージョンによって決まります。
暗黙的なタグ ライブラリはディレクトリごとに作成されるため (タグ ファイルを含む)、暗黙的なタグ ライブラリのバージョンはデフォルトで 2.0 となる。ただし、このバージョンは、JSP 2.1 の同じディレクトリにある implicit.tld
ファイルによってコンフィグレーションすることができます。
.tagx
ファイルの <jsp:root>
属性のバージョン値は、タグ ファイルのバージョンと同じでなければならない。
参照されるすべての JSP タグ バージョンは、現在のタグ ファイルのバージョンを超えてはならない。
JSP では、スクリプトレットや式に含まれる暗黙的オブジェクト用に予約語が用意されています。この暗黙的オブジェクトとは、JSP ページに有用なメソッドや情報を提供する Java オブジェクトです。WebLogic JSP は、JSP 2.1 仕様に定義されている暗黙的オブジェクトをすべて実装しています。JSP API については、Sun Microsystems の JSP ホームページ (http://www.java.sun.com/products/jsp/download/index.html
) にある Javadoc で説明されています。
注意 : この暗黙的オブジェクトはスクリプトレットや式の中でのみ使用するようにします。宣言で定義されるメソッドからこれらのキーワードを使用すると、未定義の変数を参照することになるため、変換時にコンパイル エラーが発生します。 |
表 13-2 暗黙的オブジェクト用の予約語
予約語 | 説明 |
---|---|
request |
|
response |
注意 : JSP ページ内から |
out |
出力ストリームを必要とするメソッドを使用している場合、 ByteArrayOutputStream ostr = new ByteArrayOutputStream(); exception.printStackTrace(new PrintWriter(ostr)); out.print(ostr); |
pageContext |
|
session |
|
application |
要求を転送または取り込む場合は、 |
config |
|
page |
|
関数を実行したり、JSP ページを特定の方法で解釈したりするよう WebLogic JSP に指示するには、ディレクティブを使用します。ディレクティブは、JSP ページのどこに挿入してもかまいません。通常、ディレクティブの位置は無関係で (include ディレクティブを除く)、複数のディレクティブ タグを使用できます。ディレクティブは、ディレクティブ タイプとその 1 つまたは複数の属性で構成されます。
構文は、次に示すように短縮形と XML の 2 種類を使用できます。
短縮形 :<%@ dir_type dir_attr %>
XML :<jsp:directive.dir_type dir_attr />
dir_type はディレクティブのタイプ、dir_attr はそのディレクティブ タイプの 1 つまたは複数のディレクティブ属性のリストで置き換えます。
ディレクティブには、page、taglib、include の 3 種類があります。
文字エンコーディング セットを指定するには、そのページの先頭で次のディレクティブを使用します。
<%@ page contentType="text/html; charset=custom-encoding" %>
contentType
ディレクティブで指定した文字セットは、JSP およびその JSP に含まれるすべての JSP で使用される文字セットを指定します。
Web アプリケーションの WebLogic 固有のデプロイメント記述子で、デフォルトの文字エンコーディングを指定できます。
taglib
ディレクティブを使用して、JSP ページが、タグ ライブラリに定義されているカスタム JSP タグ拡張を使用することを宣言します。カスタム JSP タグの記述方法と使い方の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JSP Tag Extensions プログラマーズ ガイド』を参照してください。
宣言を使用して、生成された JSP サーブレット内のクラス スコープ レベルの変数とメソッドを定義します。JSP タグの間に記述された宣言は、JSP ページの他の宣言やスクリプトレットからアクセスできます。次に例を示します。
<%! int i=0; String foo= "Hello"; private void bar() { // ここに Java コードを記述 } %>
クラス スコープのオブジェクトは、サーブレットの同一のインスタンス内で実行中の複数のスレッド間で共有されます。共有違反を防ぐには、クラス スコープのオブジェクトを同期させます。スレッドセーフなコードの記述に自信がない場合は、次のディレクティブを使用して、サーブレットを非スレッドセーフとして宣言できます。
<%@ page isThreadSafe="false" %>
デフォルトでは、この属性は true に設定されています。isThreadSafe を false
に設定すると、メモリ消費量が増えるのでパフォーマンスが低下することがあります。
JSP スクリプトレットは、JSP サーブレットの HTTP 応答の Java 本文を構成します。次に示すように短縮形または XML の scriptlet タグを使用して、JSP ページ内にスクリプトレットを含めます。
短縮形 :
<% // ここに Java コードを記述 %>
XML :
<jsp:scriptlet> // ここに Java コードを記述 </jsp:scriptlet>
スクリプトレットの特長は次のとおりです。
Java コードとプレーンな HTML が混在する複数ブロックのスクリプトレットを作成できる。
Java コンストラクトやブロックの内部であっても、任意の場所で HTML と Java コードを切り替えられる。「HTML と埋め込み Java を使用した JSP の例」では、Java ループを宣言し、HTML に切り替えてから、再び Java コードに戻ってループを閉じています。ループ内部の HTML は、ループが反復する回数分出力として生成されます。
あらかじめ定義されている変数 out
を使用して、Java コードからサーブレット出力ストリームに、HTML テキストを直接出力できる。print()
メソッドを呼び出して、HTTP ページ応答に文字列を追加します。
ユーザが以前に入力したデータを出力する場合、HTML 特殊文字が入力されていればすべて削除することが推奨される。これらの文字を削除しない場合、クロスサイト スクリプティングによって Web サイトが損なわれるおそれがあります。詳細については、「JSP 式言語」を参照してください。
この Java タグはインライン タグであり、パラグラフが分けられることはない。
JSP ファイルの中に式を含めるには、次のタグを使用します。
<%= expr %>
expr を Java 式で置き換えます。式が評価されるときに、その string
表現が HTML 応答ページ内にインラインで配置されます。このタグは次のタグの短縮形です。
<% out.print( expr ); %>
このテクニックを使用すると、JSP ページ内の HTML を読みやすくできます。次の節のサンプルでは expression タグの使い方を示します。
式は、ユーザが以前に入力したデータを返すためによく使われます。ユーザが入力したデータを出力する場合、HTML 特殊文字が入力されていればすべて削除することをお勧めします。これらの文字を削除しない場合、クロスサイト スクリプティングによって Web サイトが損なわれるおそれがあります。詳細については、「JSP 式言語」を参照してください。
次に、HTML と埋め込み Java を使用した JSP の例を示します。
<html> <head><title>Hello World Test</title></head> <body bgcolor=#ffffff> <center> <h1> <font color=#DB1260> Hello World Test </font></h1> <font color=navy> <% out.print("Java-generated Hello World"); %> </font> <p> This is not Java! <p><i>Middle stuff on page</i> <p> <font color=navy> <% for (int i = 1; i<=3; i++) { %> <h2>This is HTML in a Java loop! <%= i %> </h2> <% } %> </font> </center> </body> </html>
上記のコードがコンパイルされると、ブラウザには次のようなページが表示されます。
JSP アクションを使用して、JavaBean で表されるオブジェクトの変更、使用、または作成を行います。アクションでは、XML 構文のみが使用されます。
<jsp:useBean>
アクション タグを使用すると、JavaBean 仕様に準拠した Java オブジェクトをインスタンス化し、それを JSP ページから参照できます。
JavaBean 仕様に準拠するには、オブジェクトに次のものが必要です。
引数をとらないパブリック コンストラクタ
各 variable
フィールドに対する setVariable()
メソッド
各 variable
フィールドに対する getVariable()
メソッド
<jsp:useBean>
タグは、既存の名前付き Java オブジェクトを特定のスコープから検索しようと試みます。既存のオブジェクトが見つからなければ、新しいオブジェクトをインスタンス化し、id
属性で指定された名前にそのオブジェクトを関連付けようとします。オブジェクトは、オブジェクトの可用性を決定する scope
属性で指定された位置に格納されます。たとえば、次のタグでは、examples.jsp.ShoppingCart
というタイプの Java オブジェクトを、cart
という名前の HTTP セッションから検索しようとします。
<jsp:useBean id="cart" class="examples.jsp.ShoppingCart" scope="session"/>
そのようなオブジェクトがその時点で存在しなければ、JSP では新しいオブジェクトを作成し、cart
という名前の HTTP セッション内に格納しようとします。クラスは、WebLogic Server の起動に使用する CLASSPATH
内、または JSP を含む Web アプリケーションの WEB-INF/classes
ディレクトリに入っている必要があります。
捕捉が必要な実行時例外があるので、<jsp:useBean>
タグと共に errorPage
ディレクティブを使用することをお勧めします。errorPage
ディレクティブを使用しない場合、JavaBean で参照されるクラスを作成できず、InstantiationException
が送出され、ブラウザにエラー メッセージが返されます。
Java 内で有効な型キャスト操作であれば、type
属性を使用して、その JavaBean タイプを別のオブジェクトやインタフェースにキャストできます。class
属性なしで type 属性を使用する場合、JavaBean オブジェクトは、指定したスコープ内にすでに存在している必要があります。有効でない場合は、InstantiationException
が送出されます。
<jsp:useBean>
タグ構文には、別の形式もあります。これを使用すると、オブジェクトがインスタンス化されるときに実行する JSP コードの本文を定義できます。名前付き JavaBean が指定したスコープ内にすでにある場合、本文は実行されません。この形式を使用すると、オブジェクトが最初に作成されるときのプロパティを設定できます。次に例を示します。
<jsp:useBean id="cart" class="examples.jsp.ShoppingCart" scope=session> Creating the shopping cart now... <jsp:setProperty name="cart" property="cartName" value="music"> </jsp:useBean>
注意 : class 属性なしで type 属性を使用すると、JavaBean オブジェクトはインスタンス化されません。したがって、本文を含めるようなタグ形式は使用しないでください。代わりに、単一のタグ形式を使用します。この場合、JavaBean が指定したスコープ内に存在している必要があります。存在していないと InstantiationException が送出されます。errorPage ディレクティブを使用して、潜在的な例外を捕捉します。 |
JavaBean オブジェクトをインスタンス化したら、Java オブジェクトのように、JSP ファイルでその id
名により参照できます。この JavaBean オブジェクトは、スクリプトレット タグや式評価タグ内で使えます。<jsp:setProperty>
タグを用いてその setXxx()
メソッドを呼び出すこともでき、また <jsp:getProperty>
タグを用いて getXxx()
メソッドを呼び出すこともできます。
scope
属性を使用して、JavaBean オブジェクトの可用性とライフスパンを指定します。スコープは以下のいずれかです。
表 13-3 JavaBean オブジェクトの scope 属性の定義
スコープ | 説明 |
---|---|
page |
JavaBean に対するデフォルトのスコープです。オブジェクトは現在のページの |
request |
|
session |
複数の HTTP ページにわたって JavaBean オブジェクトを追跡できるよう、 |
application |
|
JavaBean の使用方法の詳細については、JSP 2.1 仕様 (http://www.java.sun.com/products/jsp/index.html
) を参照してください。
どのような種類の認証を使用している場合でも、<jsp:forward> タグで要求が転送されるときには、ユーザを再認証する必要はありません (デフォルト設定)。この動作を変更して、転送された要求の認証を実行するには、<check-auth-on-forward/> 要素を WebLogic 固有のデプロイメント記述子 (weblogic.xml) の <container-descriptor> 要素に追加します。次に例を示します。
<container-descriptor> <check-auth-on-forward/> </container-descriptor>
<jsp:include> タグを使用すると、JSP に別のリソースを含めることができます。このタグは、次の 2 種類の属性を取ります。
page
- 含めるリソースを指定するために使用します。次に例を示します。
<jsp:include page="somePage.jsp"/>
flush
- この boolean 型属性を true
に設定すると、ページ出力がバッファに格納され、リソースが含まれる前にそのバッファがフラッシュされます。<jsp:include>
タグが JSP ページの別のタグ内にあり、含めるリソースをそのタグで処理する場合は、flush="false"
に設定すると便利です。
新しい JSP 式言語 (JSP EL 2.1) は、ECMAScript 式言語と XPath 式言語の両方の影響を受けています。JSP EL は、標準アクションおよびカスタム アクションの属性値と、テンプレート テキスト内で使用可能です。どちらの場合も、JSP EL は一貫して構文 #{expr}
または ${expr}
で呼び出されます。
#{expr}
構文は、JSP EL 2.1 で導入された遅延式を示します。「#{}
」で区切られた式は、その値がシステムで必要とされるまで評価されないため、「遅延評価」を使用します。これにより、式はライフサイクル内の適切な時点で基底のメカニズムによって処理されるようになります。一方、「${}
」で区切られた式は、JSP ページのコンパイル時にコンパイルされ、JSP ページの実行時に実行されるため、「即時評価」を使用します。遅延式には、遅延 ValueExpression
および遅延 MethodExpression
が含まれます。${expr}
構文は、JSP EL 2.1 でサポートされています。
この JSP EL が JSP 技術に追加されたことで、スクリプトレット JSP ページをより簡単に記述できるようになりました。スクリプトレット JSP ページでは JSP EL 式を使用できますが、Java スクリプトレット、Java 式、そして Java 宣言要素は使用できません。この使用パターンは、web.xml
デプロイメント記述子の scripting-invalid
JSP コンフィグレーション要素を介して使用することができます。
JSP 式言語の詳細については、http://java.sun.com/products/jsp/download/index.html
を参照してください。
JSP EL 式は、実行時の式を受け入れられる任意の属性で、標準アクションとカスタム アクションのどちらの場合にも使用できます。以下に、属性値での式の使用方法として例を示します。
属性値に式の構文 <some:tag value="${expr}"/>
または <some:tag value="#{expr}"/>
を 1 つ含める。この場合、式が評価され、結果がその属性の想定される型に変換されます。この変換は、http://java.sun.com/products/jsp/download/index.html
のセクション 1.18 「Type Conversion」で説明されている型変換のルールに従います。
属性値に 1 つまたは複数の式をテキストを挟むかテキストで囲む形で含める。たとえば <some:tag value="some${expr}${expr}text${expr}"/>
または <some:tag value="some#{expr}#{expr}text#{expr}"/>
のようにします。この場合、式が左から右へ評価され、(後述の型変換ルールに従って) String 型に変換されてから、間に挟まれたテキストと連結されます。結果である String 型は http://java.sun.com/products/jsp/download/index.html
のセクション 1.18 「Type Conversion」で説明されている型変換のルールに従って、その属性の想定される型に変換されます。
属性値にテキストのみを含める。たとえば <some:tag value="sometext"/>
のようにします。この場合、属性の String 値がその属性の想定される型に変換されます。この変換は、http://java.sun.com/products/jsp/download/index.html
のセクション 1.18 「Type Conversion」で説明されている型変換のルールに従います。
注意 : このルールは JSP 2.1 の変換と同様ですが、空の文字列の扱いが異なります。 |
JSPX を使用する際は、以下の 2 つの条件を満たす必要があります。
web.xml
- web-app
で、サーブレットのバージョンが 2.4
以上に定義されている必要があります。この条件が満たされない場合は、すべての EL 機能が無視されます。
TLD ファイル – jsp
プレフィックスに、次のようなネームスペース宣言が必要です。
<html xmlns:jsp="http://java.sun.com/JSP/Page";
以下に、JSP EL を使用して Bean のプロパティが 3 個未満かどうかを調べる条件付きのアクションを示します。
<c:if test="${bean1.a < 3}"> ... </c:if>
通常の JSP の制御メカニズムでも <mytags:if test="true" /> を使用することは可能です。リテラル値に文字列 ${ を含める場合、この値を含むリテラルの使用方法は次のようになります。
<mytags:example code="an expression is ${'${'}expr}" />
結果として生じる属性値は、「an expression is ${expr}
」という文字列になります。
テンプレート テキスト内には JSP EL を直接使用できます。カスタムまたは標準のアクションの本文内でもアクション外部のテンプレート テキスト内でも構いません。ただし、タグの本体がタグ依存の場合や、(通常、互換性の問題から) ディレクティブによって明示的に、または暗黙的に JSP EL が無効化されている場合は除きます。
JSP EL 式のセマンティクスは Java 式と同じで、値が計算されて現在の出力に挿入されます。エスケープ処理が必要な場合 (クロスサイト スクリプティング攻撃を予防するために行う場合など) は、JSTL のコア タグ <c:out>
を使用できます。次に例を示します。
<c:out value="${anELexpression}" />
以下に示すカスタム アクションでは、2 つの JSP EL 式を使用して Bean のプロパティにアクセスしています。
<c:wombat> 1 つめの値は ${bean1.a}、2 つめの値は ${bean2.a.c} です。 </c:wombat>
JSP ページ内で使用する JSP EL 式で利用可能な暗黙的オブジェクトが、複数用意されています。これらのオブジェクトは以下の名前を使用して常に利用可能です。
pageContext
- pageContext
オブジェクトを表します。
pageScope
- ページ スコープの属性名とその値のマップを表します。
requestScope
- 要求スコープの属性名とその値のマップを表します。
sessionScope
- セッション スコープの属性名とその値のマップを表します。
applicationScope
- アプリケーション スコープの属性名とその値のマップを表します。
param
- パラメータ名と単一の String 型パラメータ値 (ServletRequest.getParameter(String name)
の呼び出しで取得される) のマップを表します。
paramValues
- パラメータ名とそのパラメータのすべての値を含む単一の String[]
(ServletRequest.getParameterValues(String name)
の呼び出しで取得される) のマップを表します。
header
- ヘッダ名と単一の String 型ヘッダ値 (ServletRequest.getHeader(string name)
の呼び出しで取得される) のマップを表します。
headerValues
- ヘッダ名とそのヘッダのすべての値を含む String[]
(ServletRequest.getHeaders(String name)
の呼び出しで取得される) のマップを表します。
cookie
- クッキー名と単一の Cookie オブジェクトのマップを表します。クッキーは、HttpServletRequest.getCookies()
のセマンティクスに従って取得されます。複数のクッキーで同じ名前が共有されている場合、実装では必ず getCookies()
メソッドから返された Cookie オブジェクトの配列のうち最初のものが使用されます。ただし、暗黙的オブジェクト cookie を使用するユーザは、クッキーの順序が現在の Servlet 仕様では指定されていないことを認識しておく必要があります。
initParam
- コンテキストの初期化パラメータ名とその String 型のパラメータ値 (ServletRequest.getInitParameter(String name)
の呼び出しで取得される) のマップを表します。
表 13-4 に、上記の暗黙的オブジェクトの使用例をいくつか示します。
表 13-4 暗黙的オブジェクトの使用例
式 | 説明 |
---|---|
${pageContext.request.requestURI} |
要求の URI ( |
${sessionScope.profile} |
セッション スコープの属性の名前付きプロファイル (見つからなかった場合 |
${param.productId} |
|
${paramValues.productId} |
|
以降の節では、JSP EL 式のリテラルと演算子について説明します。JSP EL の構文はとても簡単です。変数には名前でアクセスできます。汎用の演算子 [] を使用すると、マップ、リスト、オブジェクトの配列、および JavaBean オブジェクトのプロパティにアクセスできます。この演算子は自由にネスト可能です。. 演算子は、Java の ID 規約に従った名前を持つプロパティに対し、簡単にアクセスする手段として使用できます。一方、[] 演算子では、より汎用的なアクセスが可能です。
標準の Java 比較演算子を使用して、関係比較を行えます。他の値、ブール値 (等価比較のみ)、String 型、整数、または浮動小数点リテラルに対して比較を実行できます。算術演算子を使用すると、整数および浮動小数点の値を計算できます。論理演算子も利用可能です。
ブール値、整数、浮動小数点、文字列、null 用のリテラルが用意されています。
ブール値 - true および false。
整数 - JSP 2.1 EL 仕様のセクション 1.19 「Collected Syntax」の IntegerLiteral
コンストラクトで定義されています。
浮動小数点 - JSP 2.1 EL 仕様のセクション 1.19 「Collected Syntax」の FloatingPointLiteral
コンストラクトで定義されています。
文字列 - 単一引用符および二重引用符。" は \"、' は \' 、\ は \\ のようにするとエスケープされます。引用符は、同じ種類の引用符で囲まれた文字列値でのみエスケープする必要があります。
null 値 - null。
ほとんどの場合、JSP ページは表示用に使われます。表示に使用する場合は一般的に、ページに単純なエラーがあっても可能な限り良い状態で表示できるようにすることが、もっとも重要なポイントになります。JSP EL では、この要件のための警告は用意されていませんが、デフォルト値とエラーを利用できます。デフォルト値は入力を修正する値で、問題がある場合に代わりに表示するものとして割り当てられます。エラーは例外であり、送出された後には標準の JSP 機構で処理されます。
JSP 式言語 (JSP EL) で提供される演算子の一覧を以下に示します。
. および []
算術演算子 : +、- (二項演算子)、*、/ および div、% および mod、- (単項演算子)
論理演算子 : and、&&、or、||、not、!
比較演算子 : ==、eq、!=、ne、<、lt、>、gt、<=、ge、>=、le 他の値、ブール値、文字列、整数、または浮動小数点リテラルに対して比較を実行できます。
空演算子 : empty 演算子はプレフィックス操作で、値が null または空のどちらなのかを判断するために使用できます。
条件演算子 : A ? B : C。A を評価した結果に応じて B または C の評価が実施されます。
演算子とその機能の詳細については、JSP 2.1 仕様を参照してください。
以下の単語は予約語であり、識別子として使用することはできません。
and
eq
gt
true
instanceof
or
ne
le
false
empty
not
lt
ge
null
div
mod
注意 : 現時点では、これらの単語の多くがこの言語に含まれていません。ただし、将来的に組み入れられる可能性があるので、使用は避けるようにしてください。 |
JSP EL の基本的な構想に、変数名を評価してオブジェクトに解決することがあります。JSP EL API では、名前をオブジェクトに解決する汎用メカニズムとして VariableResolver が提供されています。このデフォルトの解決メカニズムが、テンプレートや属性内にある JSP EL 式の評価に使用されます。このデフォルト解決メカニズムでは、「JSP 式言語の暗黙的オブジェクト」で説明した暗黙的オブジェクトが提供されています。
デフォルトの解決メカニズムでは、他の識別子をマップすることも可能です。これには、pageContext
オブジェクトの PageContext.findAttribute(String)
の動作により、識別子の値を属性としてルックアップします。たとえば ${product}
のようにします。
この式では product という名前の属性を検索し、ページ、要求、セッション、およびアプリケーション スコープを検索して、属性の値を返します。属性が見つからない場合、null が返されます。JSP 2.1 仕様の第 14 章「Expression Language API」を参照してください。VariableResolver の詳細と、評価 API との対応関係について参照してください。
式やスクリプトレットを使うと、JSP でユーザからデータを受け取ったり、ユーザが入力したデータを返したりできます。たとえば、コード リスト 13-1 のサンプル JSP では、ユーザに文字列の入力を求め、その文字列を userInput
という名前のパラメータに代入してから、<%= javax.servlet.ServletRequest.getParameter("userInput")%>
という式を使ってそのデータをブラウザに返しています。
コード リスト 13-1 ユーザが入力した内容を返すための式の使用
<html> <body> <h1>My Sample JSP</h1> <form method="GET" action="mysample.jsp"> Enter string here: <input type="text" name="userInput" size=50> <input type=submit value="Submit"> </form> <br> <hr> <br> Output from last command: <%= javax.servlet.ServletRequest .getParameter("userInput")%> </body> </html>
このようにユーザが入力したデータを返す機能があると、クロスサイト スクリプティングと呼ばれるセキュリティの脆弱性がもたらされます。これは、ユーザのセキュリティ認可を盗用するために利用されるおそれがあります。クロスサイト スクリプティングの詳細については、http://www.cert.org/tech_tips/malicious_code_mitigation.html
の「Understanding Malicious Content Mitigation for Web Developers」(CERT のセキュリティ勧告) を参照してください。
セキュリティの脆弱性をなくすには、ユーザが入力したデータを返す前に、そのデータをスキャンして、表 13-5 に示す HTML 特殊文字があるかどうかを調べます。特殊文字が見つかった場合、HTML のエンティティ参照または文字参照と置き換えます。文字を置換することで、ブラウザでユーザ入力によるデータが HTML として実行されることを回避します。
表 13-5 置き換えの必要がある HTML の特殊文字
置き換える必要のある特殊文字 | 置き換え後のエンティティ/文字参照 |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
WebLogic Server には、ユーザが入力したデータ内の特殊文字を置き換える weblogic.servlet.security.Utils.encodeXSS()
メソッドが用意されています。このメソッドを使用するには、ユーザ入力データを入力として提供します。次に例を示します。
<%= weblogic.servlet.security.Utils.encodeXSS(
javax.servlet.ServletRequest.getParameter("userInput"))%>
アプリケーション全体を保護するため、ユーザが入力したデータは、返す際に毎回 encodeXSS()
メソッドを使用する必要があります。上記の例は encodeXSS()
メソッドを明らかに使用すべき場所ですが、表 13-5 には、他に encodeXSS()
メソッドの使用を検討すべき場所を示します。
WebLogic JSP 内のセッションは、JSP 2.1 仕様に従って動作します。次に、セッションの使い方に関連した留意事項を示します。
セッションには小さなオブジェクトを格納する。たとえば、セッションは EJB の格納ではなく、EJB プライマリ キーの格納に使用する方がよいでしょう。大量のデータは、データベースに格納します。セッションには、データの単純な文字列参照のみを保持するようにします。
サーブレットまたは JSP の動的な再ロードとともにセッションを使用する場合、サーブレット セッションに格納されるオブジェクトは、シリアライズ可能でなければならない。シリアライゼーションが必要なのは、サーブレットが新しいクラス ローダで再ロードされるためです。再ロードにより、先に (サーブレットの古いバージョンから) ロードされたクラスと、新しいクラス ローダにロードされる (サーブレット クラスの新しいバージョンに対応した) クラスとの間で互換性がなくなります。この互換性の欠如によって、サーブレットから ClassCastException
エラーが返されます。
セッション データがユーザ定義型でなければならない場合、データ クラスはシリアライズできるようにする必要がある。さらに、セッションはシリアライズされた形のデータ オブジェクトを格納しなければなりません。このとき、シリアライゼーションはデータ クラスのバージョン間で互換性を保つ必要があります。
JSP を使用すると、適切なクライアント ブラウザ タグを含む HTML を生成することによって、Web ページに Java Plug-in を簡単に組み込むことができます。Java Plug-in では、クライアントの Web ブラウザにより実装された JVM の代わりに、Sun Microsystems から提供されている Java Runtime Environment (JRE) を使用することができます。この機能により、アプレットと特定の種類の Web ブラウザ間の非互換性による問題が回避できます。Java Plug-in は、Sun の Web サイト (http://java.sun.com/products/plugin/
) から入手できます。
Internet Explorer と Netscape では使用している構文が違うため、<jsp:plugin>
アクションから生成されたサーブレット コードでは、動的にブラウザ クライアントの種類が調べられ、適切な <OBJECT>
タグか、<EMBED>
タグがその HTML ページに送信されます。
<jsp:plugin>
タグでは、<APPLET>
タグの属性に似た多くの属性、および使用する Java Plug-in のバージョンをコンフィグレーションできる他の属性群が使用されます。アプレットがサーバと通信する場合、アプレット コードを実行する JVM は WebLogic Server を実行する JVM と互換性がある必要があります。
次のサンプルでは、plugin アクションを使用してアプレットをデプロイします。
<jsp:plugin type="applet" code="examples.applets.PhoneBook1" codebase="/classes/" height="800" width="500" jreversion="2.0" nspluginurl= "http://java.sun.com/products/plugin/1.1.3/plugin-install.html" iepluginurl= "http://java.sun.com/products/plugin/1.1.3/ jinstall-113-win32.cab#Version=1,1,3,0" > <jsp:params> <param name="weblogic_url" value="t3://localhost:7001"> <param name="poolname" value="demoPool"> </jsp:params> <jsp:fallback> <font color=#FF0000>Sorry, cannot run java applet!!</font> </jsp:fallback> </jsp:plugin>
上のサンプルの JSP 構文は、ブラウザに対して、(まだダウンロードされていなければ) Java Plug-in バージョン 1.3.1 をダウンロードし、code
属性で指定したアプレットを、codebase
で指定された位置から実行するように指示しています。
jreversion
属性は、アプレットが要求している Java Plug-in のバージョンを識別します。Web ブラウザでは、このバージョンの Java Plug-in を使おうとします。プラグインがまだブラウザにインストールされていない場合、nspluginurl
属性および iepluginurl
属性で URL が指定され、そこで、Sun の Web サイトからその Java Pug-in をダウンロードできます。一度プラグインが Web ブラウザにインストールされれば、再度そのプラグインをダウンロードする必要はありません。
WebLogic Server では Java 1.3.x VM を使用するため、<jsp:plugin>
タグ内に、Java Plug-in バージョン 1.3.x を指定する必要があります。上のサンプル コードで 1.3 JVM を指定するには、対応する属性値を次のように置き換えます。
jreversion="1.3" nspluginurl= "http://java.sun.com/products/plugin/1.3/plugin-install.html" iepluginurl= "http://java.sun.com/products/plugin/1.3/jinstall-131-win32.cab"
プラグイン アクションのほかの属性は、<APPLET>
タグの属性に相当します。アプレット パラメータは、<params>
タグのペアで指定し、<jsp:plugin>
タグと </jsp:plugin>
タグでネストします。
<jsp:fallback>
タグでは、<jsp:plugin>
アクションでサポートされていないブラウザ用に HTML を置換できます。<fallback>
タグと </jsp:fallback>
タグでネストされた HTML が、プラグイン構文の代わりに送られます。
注意 : WebLogic JSP コンパイラは非推奨になっています。EAR ファイル、WAR ファイル、および EJB のコンパイルには、WebLogic の appc コンパイラであるweblogic.appc の使用をお勧めします。『Oracle Fusion Middleware Oracle WebLogic Server エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「appc リファレンス」を参照してください。 |
WebLogic JSP コンパイラではコンパイルのパフォーマンスを向上させるため、ディスク上にまず java ファイルを作成してからクラス ファイルにコンパイルするのではなく、直接 JSP をディスク上のクラス ファイルに変換します。java ファイルはメモリ上にのみ置かれます。
生成された java ファイルを参照するには、メモリ内の java ファイルをディスクにダンプする -keepgenerated フラグをオンにします。
注意 : JSP のコンパイル中には、コマンドライン フラグ (compilerclass) も記述子要素も呼び出されません。 |
JSP コンパイラは、他の WebLogic コンパイラ (RMI コンパイラや EJB コンパイラなど) とほとんど同じ方法で動作します。JSP コンパイラを起動するには、次のコマンドを入力します。
$ java weblogic.jspc -options fileName
fileName
を、コンパイルする JSP ファイルの名前で置き換えます。対象の fileName
の前か後に options
を指定することもできます。次の例では、-d
オプションを使用して myFile.jsp
をコンパイルし、出力先ディレクトリ weblogic/classes
に出力します。
$ java weblogic.jspc -d /weblogic/classes myFile.jsp
注意 : Web アプリケーションの一部で、Web アプリケーションのリソース (JSP タグ ライブラリなど) を参照している JSP をプリコンパイルする場合は、-webapp フラグを使用して Web アプリケーションの場所を指定する必要があります。-webapp フラグは JSP コンパイラ オプションの次のリストで説明します。 |
次のオプションを任意で組み合わせて使用します。
表 13-7 JSP コンパイラ オプション
オプション | 説明 |
---|---|
-classpath |
希望する $ java weblogic.jspc -classpath java/classes.zip;/weblogic/classes.zip myFile.JSP |
-charsetMap |
JSP -charsetMap x-sjis=Shift_JIS,x-big5=Big5 最も一般的なマッピングは、JSP コンパイラに組み込まれています。このオプションは、希望の文字セット マッピングが認識されない場合にのみ使用します。 |
-commentary |
JSP コンパイラにより、生成された HTML ページに JSP からのコメントが含められます。このオプションを省略すると、コメントは生成された HTML ページに表示されません。 |
-compileAll |
カレント ディレクトリ、または |
-compileFlags |
1 つまたは複数のコマンドライン フラグをコンパイラに渡します。複数のフラグはスペースで区切り、引用符で囲みます。次に例を示します。 java weblogic.jspc -compileFlags "-g -v" myFile.jsp |
-compiler |
生成された Java ソース コードからクラス ファイルをコンパイルする際に使用する Java コンパイラを指定します。デフォルトでは、コンパイラとして |
-compilerclass |
Java コンパイラを、ネイティブ実行ファイルとしてではなく、Java クラスとして実行します。 |
-compressHtmlTemplate |
JSP テンプレート ブロック内の HTML を圧縮し、実行時のパフォーマンスを改善します。 JSP の HTML テンプレート ブロックに |
-d <dir> |
コンパイルされた出力 (クラス ファイル) の出力先ディレクトリを指定します。このオプションは、コンパイルされたクラスを、すでに |
-depend |
JSP の以前に生成されたクラス ファイルのタイム スタンプが、JSP ソース ファイルよりも新しい場合、JSP は再コンパイルされません。 |
-debug |
デバッグ モードでコンパイルします。 |
-deprecation |
生成された Java ソース ファイルをクラス ファイルにコンパイルしているときに、ソース ファイル中に非推奨のメソッドが使用されていると警告します。 |
-docroot ディレクトリ |
|
-encoding デフォルトまたは名前付き文字エンコーディング |
有効な引数は、(a) JDK のデフォルト文字エンコーディングの使用を指定する |
-g |
クラス ファイルにデバッグ情報も入れるよう、Java コンパイラに指示します。 |
-help |
JSP コンパイラで使用可能なオプションをすべて表示します。 |
-J |
コンパイラに渡されるオプションのリストを取得します。 |
-k |
1 つのコマンドで複数の JSP をコンパイルする場合、1 つまたは複数の JSP がコンパイルに失敗しても、コンパイルを続行します。 |
-keepgenerated |
コンパイル処理の途中で作成された Java ソース コード ファイルを削除せずに残します。通常、こうしたファイルはコンパイル後に削除されます。 |
-noTryBlocks |
JSP ファイルに、多数のまたは深くネストしたカスタム JSP タグが含まれていて、コンパイル時に |
-nowarn |
Java コンパイラからの警告メッセージが出力されないようにします。 |
-noPrintNulls |
JSP の式の "null" が "" (空の文字列) として示されます。 |
-O |
最適化を有効にして、生成された Java ソース ファイルをコンパイルします。このオプションは、 |
-optimizeJavaExpression |
Java 式を最適化し、実行時のパフォーマンスを改善します。 |
-package packageName |
生成された Java HTTP サーブレットのパッケージ名の前に追加するパッケージ名を設定します。デフォルトは |
-superclass クラス名 |
生成されたサーブレットによって拡張されたスーパークラスのクラス名を設定します。スーパークラスの名前は、 |
-verbose |
|
-verboseJavac |
指定した JSP コンパイラによって生成されたメッセージを出力します。 |
-version |
JSP コンパイラのバージョンを出力します。 |
-webapp ディレクトリ |
展開ディレクトリ形式で Web アプリケーションが含まれるディレクトリの名前。JSP タグ ライブラリやその他の Java クラスなど、Web アプリケーション内のリソースへの参照が JSP に含まれる場合、JSP コンパイラはそのリソースをこのディレクトリで探します。Web アプリケーションのリソースを要求する JSP をコンパイルする場合、このフラグを省略するとコンパイルに失敗します。 |
weblogic.xml
デプロイメント記述子の <jsp-descriptor>
要素の precompile
パラメータを true に設定すると、Web アプリケーションをデプロイまたは再デプロイしたとき、あるいは WebLogic Server を起動したときに JSP をプリコンパイルするようにコンフィグレーションできます。サーバを再起動するたびに、また追加でサーバを対象指定したときに、JSP を再コンパイルしないようにするには、weblogic.jspc を使用して JSP をプリコンパイルし、プリコンパイルした JSP を WEB-INF/classes
フォルダにコピーして、.war
ファイルにアーカイブします。ソース ファイルをアーカイブ .war
ファイルとは別のディレクトリに格納すると、クラス ファイルのいずれかと JSP との依存関係によってエラーが発生するおそれがなくなります。
JSP の再コンパイルを回避する別の方法は、JSPServlet の代わりに JSPClassServlet を使用し、コンパイル済みの JSP を WEB-INF/classes
ディレクトリ内に格納することです。これによって、ソース コードがサーバから検出されなくなるため、JSP が再コンパイルされる可能性がなくなります。この方法を使用すると、JSP に対するいかなる変更も記録されず、JSP は再コンパイルされません。この方法により、プリコンパイル後にアプリケーションから JSP ソース コードを完全に削除することができます。
次に、JSPClassServlet を Web アプリケーションの web.xml
ファイルに追加する方法の例を示します。
<servlet> <servlet-name>JSPClassServlet</servlet-name> <servlet-class>weblogic.servlet.JSPClassServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>JSPClassServlet</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping>
仮想ホスティングを使用する場合は、作成するマッピングに対応する物理的なディレクトリを用意し、サーバがファイルを検出できるようにする必要があります。