| Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
 戻る |
 次へ |
| Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
戻る |
次へ |
以下の節では、JSP を作成およびコンフィグレーションする方法について説明します。
WebLogic JSP では、Sun Microsystems の JSP 2.1 仕様 (http://java.sun.com/products/jsp/) をサポートしています。Java EE の主要なテーマは、開発の容易さです。プラットフォームの Web 層では、以下の 2 つの点で開発の容易さが大幅に向上しています。1 つめは、プラットフォームに JavaServer Pages Standard Tag Library (JSTL) 技術と JavaServer Faces 技術が組み込まれていることです。2 つめは、Java EE での Web アプリケーション開発を非常に容易にする一連の機能 (JavaServer Faces 技術タグと JavaServer Pages (JSP) ソフトウェア コードとの緊密な連携など) がすべての Web 層技術で提供されることです。
Java Server Pages (JSP) ファイルをデプロイするには、Web アプリケーションのルート (またはルートの下のサブディレクトリ) に格納する必要があります。JSP コンフィグレーション パラメータは、WebLogic 固有のデプロイメント記述子である weblogic.xml の jsp-descriptor 要素の下位要素に定義します。これらのパラメータは次の機能を定義します。
JSP コンパイラのオプション
デバッグ
再コンパイルが必要になる更新した JSP を WebLogic Server がチェックする頻度
文字エンコーディング
これらの下位要素の詳細については、「jsp-descriptor」を参照してください。
JSP は、Java EE 標準のデプロイメント記述子 web.xml の servlet 要素を使用して、サーブレットとして登録できます。web.xml ファイルは、Web アプリケーションの WEB-INF ディレクトリにあります。サーブレット コンテナは、既知のサーブレットのマップを保持します。このマップは、コンテナに対する要求を解決するために使われます。このマップにエントリを追加することを、サーブレットを「登録する」と言います。このマップへのエントリの追加は、web.xml の servlet-mapping エントリで servlet 要素を参照することによって行います。
JSP はサーブレットの一種です。JSP の登録は、サーブレット登録の特別なケースです。通常、JSP は最初の呼び出し時に JSP ファイルの名前に基づいて暗黙的に登録されます。したがって、myJSPfile.jsp ファイルは myJSPfile.jsp としてマッピング テーブルに登録されます。次の例に示すように、JSP を暗黙的に登録することができます。次の例では、myJSPfile.jsp という暗黙的な名前ではなく、/main という名前を指定して JSP を要求しています。
次の例で、/main を含む URL は myJSPfile.jsp を起動します。
<servlet> <servlet-name>myFoo</servlet-name> <jsp-file>myJSPfile.jsp</jsp-file> </servlet> <servlet-mapping> <servlet-name>myFoo</servlet-name> <url-pattern>/main</url-pattern> </servlet-mapping>
JSP をサーブレットとして登録することによって、サーブレットに対して行うのと同様に、ロード順、初期化属性、およびセキュリティ ロールを JSP に指定できます。
WebLogic Server では、カスタム JSP タグを作成および使用できます。カスタム JSP タグは、JSP ページ内から呼び出すことができる Java クラスです。カスタム JSP タグを作成するには、それらをタグ ライブラリに登録して、それらの動作をタグ ライブラリ記述子 (TLD) ファイルに定義します。この TLD は、JSP が組み込まれている Web アプリケーションで使用できなければなりません。そのためには、Web アプリケーション デプロイメント記述子にその TLD を定義します。TLD ファイルは、Web アプリケーションの WEB-INF ディレクトリに格納してください。このディレクトリは、外部には公開されません。
Web アプリケーション デプロイメント記述子には、タグ ライブラリの URI パターンを定義します。この URI パターンは、JSP ページの taglib ディレクティブの値と一致する必要があります。また、TLD の格納場所も定義します。たとえば、JSP ページに次の taglib ディレクティブがあるとします。
<%@ taglib uri="myTaglib" prefix="taglib" %>
また、TLD が Web アプリケーションの WEB-INF ディレクトリに格納されているとします。この場合、Web アプリケーション デプロイメント記述子に次のエントリを作成します。
<jsp-config> <taglib> <taglib-uri>myTaglib</taglib-uri> <tablig-location>WEB-INF/myTLD.tld</taglib-location> </taglib> </jsp-config>
タグ ライブラリは、.jar ファイルとしてもデプロイできます。
カスタム JSP タグ ライブラリの作成の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JSP Tag Extensions プログラマーズ ガイド』を参照してください。
WebLogic Server には、アプリケーションで使用できるカスタム JSP タグがいくつか付属しています。これらのタグを使用すると、キャッシング、クエリ属性ベースのフロー制御の効率化、およびオブジェクト セットに対する反復処理の効率化を行うことができます。詳細については、以下を参照してください。
Web アプリケーション開発者は、Web アプリケーション デプロイメント記述子内で、ウェルカム ファイルと呼ばれる部分的な URI の順序付けされたリストを定義できます。このメカニズムの目的は、Web コンポーネントにマップされていない WAR 内のディレクトリ エントリに対応する URI に対する要求があった場合に、コンテナが URI に付加するために使用する部分的 URI の順序付けされたリストを、デプロイヤが指定できるようにすることです。ユーザが特定のファイル名を指定せずに URL を入力できるので、このウェルカム ページの機能でサイトが使いやすくなります。
|
注意 : ウェルカム ファイルは、JSP、静的ページ、またはサーブレットとすることができます。 |
ウェルカム ファイルは、Web アプリケーション レベルで定義します。サーバが複数の Web アプリケーションのホストになっている場合は、Web アプリケーションごとに別個のウェルカム ファイルを定義する必要があります。ウェルカム ファイルは、web.xml 内で welcome-file-list 要素を使用して定義します (web.xml ファイルは、Web アプリケーションの WEB-INF ディレクトリにあります)。ウェルカム ファイルのコンフィグレーション例を次に示します。
コード リスト 5-1 ウェルカム ファイル例
<servlet> <servlet-name>WelcomeServlet</servlet-name> <servlet-class>foo.bar.WelcomeServlet</servlet-class> </servlet> <servlet-mapping> <servlet-name>WelcomeServlet</servlet-name> <url-pattern>*.foo</url-pattern> </servlet-mapping> <welcome-file-list> <welcome-file>/welcome.foo</welcome-file> </welcome-file-list>
詳細については、http://java.sun.com/products/servlet/download.html#specs のセクション 9.10 を参照してください。
WebLogic Server をコンフィグレーションすると、特定の HTTP エラーまたは Java 例外が発生したときに、標準の WebLogic Server エラー応答ページを使う代わりに、カスタム Web ページなどの HTTP リソースを使って応答させることができます。
カスタム エラー ページは、Java EE 標準の Web アプリケーション デプロイメント記述子 (web.xml) の error-page 要素で定義します (web.xml ファイルは、Web アプリケーションの WEB-INF ディレクトリにあります)。
WebLogic Server は、HTTP リクエストに含まれるバイナリ (バイト) データを、サーブレットで予期される正しいエンコーディングに変換します。着信する POST データは、request.getParameter(..) などのメソッドで使用するためにサーバサイドで正しいエンコーディングに変換される必要のある、特定のエンコーディングでコード化されている場合があります。
コード セットを定義する方法は 2 種類あります。
POST 処理では、HTML <form> タグでエンコーディングを設定できる。たとえば、次の form タグはコンテンツの文字セットに SJIS を設定しています。
<form action="http://some.host.com/myWebApp/foo/index.html"> <input type="application/x-www-form-urlencoded; charset=SJIS"> </form>
フォームは、WebLogic Server に読み込まれると、SJIS 文字セットを使ってデータを処理します。
前述の例で、セミコロンの後ろにある情報はすべての Web クライアントが転送するわけではないので、WebLogic 固有のデプロイメント記述子である weblogic.xml にある input-charset 要素を使って、要求に使用するコード セットを設定できる。
java-charset-name 下位要素は、要求の URL が resource-path 下位要素で指定したパスを含んでいるときにデータを変換するエンコーディングを定義します。
以下の例では、パターン /foo/* にマップされるすべての要求パラメータが、Java 文字セット SJIS を使用して確実にコード化されるようになっています。
<input-charset> <resource-path>/foo/*</resource-path> <java-charset-name>SJIS</java-charset-name> </input-charset>
この方法は GET 処理と POST 処理の両方で使用できます。
文字セットを記述するために Internet Assigned Numbers Authority (IANA) によって割り当てられる名前は、Java で使用される名前とは異なることがあります。すべての HTTP 通信が IANA 文字セット名を使用し、これらの名前は常に同じとは限らないので、WebLogic Server は IANA 文字セット名を Java 文字セット名に内部でマップし、通常は正しいマッピングを判断できます。ただし、IANA 文字セットを Java 文字セットの名前に明示的にマッピングすると、あいまいさを解決することができます。
IANA 文字セットを Java 文字セットにマップするには、WebLogic 固有のデプロイメント記述子である weblogic.xml の charset-mapping 要素で文字セット名を設定します。iana-charset-name 要素に IANA 文字セット名を定義し、java-charset-name 要素に Java 文字セット名を定義します。「charset-mapping」を参照してください。
次に例を示します。
<charset-mapping> <iana-charset-name>Shift-JIS</iana-charset-name> <java-charset-name>SJIS</java-charset-name> </charset-mapping>
Web アプリケーションの web.xml デプロイメント記述子の <jsp-property-group> 要素内に、<include-prelude> 要素と <include-coda> 要素をそれぞれ追加することで、JSP ページのグループに対し prelude (ヘッダとも言います) および coda (フッタとも言います) を暗黙的にインクルードできます。それらの値は、コンテキストに相対的なパスであり、Web アプリケーション内の要素に対応している必要があります。それらの要素が存在する場合、指定されたパスが、プロパティ グループ内の各 JSP ページの最初と最後に、それぞれ自動的に (include ディレクティブの場合のように) インクルードされます。グループ内に複数の include または coda 要素がある場合、それらは登場順にインクルードされます。複数の JSP プロパティ グループが JSP ページに適用される場合、対応する要素は JSP コンフィグレーション セクションに登場するのと同じ順序で処理されます。
ファイル /template/prelude.jspf および /template/coda.jspf について考えてみます。次の例において、これらのファイルは各ファイルの最初と最後にコードを挿入するために使用されています。
コード リスト 5-2 暗黙的インクルード
<jsp-config> <jsp-property-group> <display-name>WebLogicServer</display-name> <url-pattern>*.jsp</url-pattern> <el-ignored>false</el-ignored> <scripting-invalid>false</scripting-invalid> <is-xml>false</is-xml> <include-prelude>/template/prelude.jspf</include-prelude> <include-coda>/template/coda.jspf</include-coda> </jsp-property-group> </jsp-config>
JSP プロパティ グループとは、JSP ページを表す一連のファイルに適用される、プロパティの集合です。これらのプロパティは、web.xml デプロイメント記述子の jsp-property-group 要素における 1 つまたは複数の下位要素で定義します。
JSP プロパティ グループで定義されるほとんどのプロパティは、変換単位全体、つまり URL パターンによって照合される要求された JSP ファイルと、include ディレクティブを使用してそこにインクルードされるすべてのファイルに対して、適用されます。例外は、page-encoding プロパティです。このプロパティは、URL パターンによって照合される各 JSP ファイルに個別に適用されます。JSP プロパティ グループにおける適用可能性は、1 つまたは複数の URL パターンによって定義されます。URL パターンには、Servlet 2.5 仕様の第 11 章「Mapping Requests to Servlets」で定義されているものと同じ構文が使用されますが、これらの URL パターンがバインドされるのは変換時です。プロパティ グループ内のすべてのプロパティは、URL パターンのいずれかに一致する Web アプリケーション内のリソースに適用されます。また、(JSP ファイルのものであるという) 暗黙的なプロパティが存在します。JSP プロパティ グループは、タグ ファイルには影響を与えません。
以下は、JSP プロパティ グループに適用されるルールの一部です。
リソースが、servlet-mapping と jsp-property-group の両方で URL パターンに一致している場合、最も特定的なパターンが適用される (Servlet 仕様と同じルールに準拠)。
URL パターンが同一の場合、servlet-mapping よりも jsp-property-group が優先される。
少なくとも 1 つの jsp-property-group に、最も特定的な一致する URL パターンが含まれている場合、そのリソースは JSP ファイルであると見なされ、その jsp-property-group のプロパティが適用される。
リソースが JSP ファイルと見なされている場合、すべての include-prelude および include-coda プロパティは、一致する URL パターンを備えた jsp-property-group 要素から適用される。「JSP の最初と最後での暗黙的インクルードのコンフィグレーション」を参照してください。
次の目的のために、jsp-property-group をコンフィグレーションできます。
リソースが JSP ファイルであることを示す (暗黙的)。
JSP 式言語 (JSP EL) 評価の無効化を制御する。
スクリプト記述要素の無効化を制御する。
ページのエンコーディング情報を示す。
Prelude および Coda を自動的にインクルードする。
リソースが JSP ドキュメントであることを示す。
JSP プロパティ グループの詳細については、http://java.sun.com/products/jsp/ の JSP 2.1 仕様の第 3 章「JSP Configuration」を参照してください。
JSP 2.1 仕様では、XML 構文を活用できるようにすることで、JSP ドキュメントの概念という面での改良がなされています。また、JSP ドキュメントは、プロパティ グループを使用するように拡張されています。JSP ドキュメントとは、XML 構文を用いて記述された JSP ページです。JSP ドキュメントは、そのようにして暗黙的または明示的に JSP コンテナに対して記述される必要があります。その後、JSP コンテナはそれを XML ドキュメントとして処理し、整形式であるかどうかをチェックして、要求があれば、それをエンティティ宣言のように適用します。JSP ドキュメントは、標準的な JSP セマンティクスで動的コンテンツを生成するのに使用されます。
以下は、JSP 標準タグ ライブラリを使用して、ルート要素としてテーブルを有する XML ドキュメントを生成する、単純な JSP ドキュメントの一例です。table 要素には、値 1、2、および 3 を格納する 3 つの row 下位要素があります。詳細およびその他のサンプルについては、http://java.sun.com/products/jsp/ のセクション 6.4「Examples of JSP Documents」を参照してください。
コード リスト 5-3 単純な JSP ドキュメント
<table>
<c:forEach
xmlns:c="http://java.sun.com/jsp/jstl/core"
var="counter" begin="1" end="3">
<row>${counter}</row>
</c:forEach>
</table>
JSP ドキュメントは、以下を含むいくつかの使い方ができます。
JSP ドキュメントは、JSP コンテナに直接渡すことができる。これは、ますます多くのコンテンツが XML で作成されるようになってきているため、いっそう重要になってきています。生成されたコンテンツは、クライアントに直接送信することも、何らかの XML 処理パイプラインの一部とすることもできます。
JSP ドキュメントは、XML 対応ツールで操作できる。
JSP ドキュメントは、XSLT など XML トランスフォーメーションを適用することによって、テキスト表現から生成できる。
JSP ドキュメントは、たとえば何らかのオブジェクトをシリアライズすることで、自動的に生成できる。
以下は、JSP ドキュメントに関連するいくつかの重要な情報です。
デフォルトでは、ファイル名に拡張 .jspx または .tagx の付いたファイルは、XML 構文の JSP ドキュメントとして扱われる。
web.xml デプロイメント記述子で定義される JSP プロパティ グループは、Web アプリケーション内のどのファイルを、XML 構文のものとして扱うことができるかを制御できる。「JSP プロパティ グループのコンフィグレーション」を参照してください。
JSP ファイルの最初が <jsp:root> である場合、これは XML 構文内で使用される。
<%@taglib%> taglib タグの代わりに、XML ネームスペースが使用される (xmlns:prefix="...")。
<%...%>、<%!...%>、および <%=...%> の代わりに、<jsp:scriptlet>、<jsp:declaration> および <jsp:expression> タグが使用される。
<%@page%> および <%@include%> の代わりに、<jsp:directive.page> および <jsp:directive.include> タグが使用される。
属性値内では、式を示すためには <%=...%> ではなく、%...% のみを使用する。
JSP ドキュメントの詳細については、http://java.sun.com/products/jsp/ の JSP 2.1 仕様の第 6 章「JSP Documents」を参照してください。
