| Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発 11g リリース1 (10.3.6) B60993-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発 11g リリース1 (10.3.6) B60993-05 |
|
前 |
次 |
次の項では、JSPを作成および構成する方法について説明します。
WebLogic JSPでは、JSP 2.1仕様(http://www.oracle.com/technetwork/java/javaee/jsp/index.html)をサポートしています。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がチェックする頻度
文字エンコーディング
これらの下位要素の詳細は、付録B「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 WebLogic Server JSPタグ拡張のプログラミングを参照してください。
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://www.oracle.com/technetwork/java/javaee/servlet/index.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文字セット名を定義します。付録B「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://www.oracle.com/technetwork/java/javaee/jsp/index.htmlのJSP 2.1仕様の第3章「JSP Configuration」を参照してください。
JSP 2.1仕様では、XML構文を活用できるようにすることで、JSPドキュメントのコンセプトの面で改良がなされています。また、JSPドキュメントは、プロパティ・グループを使用するように拡張されています。JSPドキュメントとは、XML構文を用いて記述されたJSPページです。JSPドキュメントは、暗黙的または明示的に、SPコンテナに対してそのようにJ記述される必要があり、その後JSPコンテナはそれらをXMLドキュメントとして処理し、整形式であるかどうかをチェックして、エンティティ宣言のようなリクエストがあればそれを適用します。JSPドキュメントは、標準的なJSPセマンティクスで動的コンテンツを生成するのに使用されます。
以下は、JSP標準タグ・ライブラリを使用して、ルート要素として表を有するXMLドキュメントを生成する、単純なJSPドキュメントの一例です。table要素には、値1、2、および3を格納する3つのrow下位要素があります。詳細およびその他のサンプルについては、http://www.oracle.com/technetwork/java/javaee/jsp/index.htmlの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://www.oracle.com/technetwork/java/javaee/jsp/index.htmlのJSP 2.1仕様の第6章「JSP Documents」を参照してください。
