4 JSPの作成と構成
この章の内容は以下のとおりです。
WebLogic JSPとJava EE
Java EEの主要なテーマは、開発の容易さです。プラットフォームのWeb層では、以下の2つの点で開発の容易さが大幅に向上しています。1つめは、プラットフォームにJavaServer Pages Standard Tag Library (JSTL)およびJavaServer Facesのテクノロジが組み込まれていることです。2つめは、Java EEでのWebアプリケーション開発を非常に容易にする一連の機能(JavaServer Faces技術タグとJavaServer Pages (JSP)ソフトウェア・コードとの緊密な連携など)がすべてのWeb層技術で提供されることです。
Java EE Webアプリケーション・テクノロジの詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.html
を参照してください。
WebLogic Serverでは、JSP 2.3仕様(https://jcp.org/aboutJava/communityprocess/mrel/jsr245/index2.html
)をサポートしています。Java EE 8プラットフォームでは、以前のリリースとの互換性を保つためにJavaServer Pages 2.3が必要ですが、新しいアプリケーションでは表示テクノロジとしてFaceletを使用することをお薦めします。
Java Server Pages (JSP)の構成
JavaServer Pages (JSP)ファイルをデプロイするには、これらのファイルをWebアプリケーションのルート(またはルートの下のサブディレクトリ)に格納する必要があります。JSP構成パラメータは、WebLogic固有のデプロイメント記述子であるweblogic.xml
のjsp-descriptor
要素の下位要素に定義します。
これらのパラメータは次の機能を定義します。
-
JSPコンパイラのオプション
-
デバッグ
-
再コンパイルが必要になる更新したJSPをWebLogic Serverがチェックする頻度
-
文字エンコーディング
これらの下位要素の詳細は、「jsp-descriptor」を参照してください。
JSPのサーブレットとしての登録
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に指定できます。
JSPタグ・ライブラリの構成
WebLogic Serverでは、カスタムJSPタグを作成および使用できます。カスタムJSPタグは、JSPページ内から呼び出すことができるJavaクラスです。カスタムJSPタグを作成するには、それらをタグ・ライブラリに登録して、それらの動作をタグ・ライブラリ記述子(TLD)ファイルに定義します。Webアプリケーション・デプロイメント記述子でこのTLDを定義して、JSPが組み込まれている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
ディレクトリにあります。)ウェルカム・ファイルの構成例を次に示します。
例4-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>
ウェルカム・ファイルの詳細は、https://download.oracle.com/otndocs/jcp/servlet-4-final-eval-spec/index.html
の10.10項にあるservlet 4.0の仕様を参照してください。
HTTPエラー・レスポンスのカスタマイズ
WebLogic Serverを構成すると、特定のHTTPエラーまたはJava例外が発生したときに、標準のWebLogic Serverエラー・レスポンス・ページを使用するかわりに、カスタムWebページなどのHTTPリソースを使って応答させることができます。
カスタム・エラー・ページは、Java EE標準のWebアプリケーション・デプロイメント記述子(web.xml
)のerror-page
要素で定義します(web.xml
ファイルは、WebアプリケーションのWEB-INF
ディレクトリにあります。)
HTTPリクエストのエンコーディングの識別
WebLogic Serverは、HTTPリクエストに含まれるバイナリ(バイト)データを、サーブレットで予期される正しいエンコーディングに変換します。着信するPOSTデータは、request.getParameter(..)
などのメソッドで使用するためにサーバー側で正しいエンコーディングに変換される必要のある、特定のエンコーディングでコード化されている場合があります。
コード・セットを定義する方法は2種類あります。
-
POST処理では、HTML
<form>
タグでエンコーディングを設定できます。たとえば、次のformタグはコンテンツの文字セットにSJIS
を設定しています。<form action="http://some.example.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
処理の両方で使用できます。
IANA文字セットのJava文字セットへのマッピング
文字セットを記述するために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>
JSPの最初と最後での暗黙的インクルードの構成
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
について考えてみます。次の例において、これらのファイルは各ファイルの最初と最後にコードを挿入するために使用されています。
例4-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プロパティ・グループとは、JSPページを表す一連のファイルに適用される、プロパティの集合です。これらのプロパティは、web.xml
デプロイメント記述子のjsp-property-group
要素における1つまたは複数の下位要素で定義します。
JSPプロパティ・グループで定義されるほとんどのプロパティは、変換単位全体、つまりURLパターンによって照合されるリクエストされたJSPファイルと、includeディレクティブを使用してそこにインクルードされるすべてのファイルに対して、適用されます。例外は、page-encoding
プロパティです。このプロパティは、URLパターンによって照合される各JSPファイルに個別に適用されます。JSPプロパティ・グループにおける適用可能性は、1つまたは複数のURLパターンによって定義されます。URLパターンには、Servlet 4.0仕様の第12章「Mapping Requests to Servlets」で定義されているものと同じ構文が使用されますが、これらのURLパターンがバインドされるのは変換時です。プロパティ・グループ内のすべてのプロパティは、URLパターンのいずれかに一致するWebアプリケーション内のリソースに適用されます。また、(JSPファイルのものであるという)暗黙的なプロパティが存在します。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プロパティ・グループの特長
次の目的のために、jsp-property-group
を構成できます。
-
リソースがJSPファイルであることを示します(暗黙的)。
-
JSP式言語(JSP EL)評価の無効化を制御します。
-
スクリプト記述要素の無効化を制御します。
-
ページのエンコーディング情報を示します。
-
PreludeおよびCodaを自動的にインクルードします。
-
リソースがJSPドキュメントであることを示します。
JSPプロパティ・グループの詳細は、https://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/
にあるJSP 2.3仕様の第3章「JSP Configuration」を参照してください。
XML構文を使用したJSPドキュメントの記述
JSP 2.3仕様では、XML構文を活用できるようにすることで、JSPドキュメントのコンセプトの面で改良がなされています。また、JSPドキュメントは、プロパティ・グループを使用するように拡張されています。JSPドキュメントとは、XML構文を用いて記述されたJSPページです。JSPドキュメントは、暗黙的または明示的に、SPコンテナに対してそのようにJ記述される必要があり、その後JSPコンテナはそれらをXMLドキュメントとして処理し、整形式であるかどうかをチェックして、エンティティ宣言のようなリクエストがあればそれを適用します。JSPドキュメントは、標準的なJSPセマンティクスで動的コンテンツを生成するのに使用されます。
以下は、JSP標準タグ・ライブラリを使用して、ルート要素として表
を有するXMLドキュメントを生成する、単純なJSPドキュメントの一例です。table要素には、値1
、2
、および3
を格納する3つのrow
下位要素があります。詳細および他の例は、https://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/
にあるJSP 2.3仕様の6.4項「Examples of JSP Documents」を参照してください。
例4-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ドキュメントは、JSPコンテナに直接渡すことができます。これは、ますます多くのコンテンツがXMLで作成されるようになってきているため、いっそう重要になってきています。生成されたコンテンツは、クライアントに直接送信することも、なんらかのXML処理パイプラインの一部とすることもできます。
-
JSPドキュメントは、XML対応ツールで操作できます。
-
JSPドキュメントは、XSLTなどXMLトランスフォーメーションを適用することによって、テキスト表現から生成できます。
-
JSPドキュメントは、たとえばなんらかのオブジェクトをシリアライズすることで、自動的に生成できます。
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ドキュメントの詳細は、https://download.oracle.com/otndocs/jcp/jsp-2_3-mrel2-eval-spec/
にあるJSP 2.3仕様の第6章「JSP Documents」を参照してください。