|
|
|
|
|
|
| | | |
Web アプリケーション コンポーネントのコンフィグレーション
次の節では、Web アプリケーションをコンフィグレーションする方法について説明します。
サーブレットは、Web アプリケーションの一部として登録およびコンフィグレーションされます。サーブレットを登録するには、Web アプリケーション デプロイメント記述子にいくつかのエントリを追加します。<servlet> 要素の下の最初のエントリには、サーブレットの名前が定義され、そのサーブレットを実行するコンパイル済みクラスが指定されます（あるいは、サーブレット クラスを指定する代わりに、JSP ページを指定することもできます）。この要素には、サーブレットの初期化パラメータとセキュリティ ロール用の定義も含まれています。<servlet-mapping> 要素の下の 2 番目のエントリには、このサーブレットを呼び出す URL パターンが定義されています。
Web アプリケーション デプロイメント記述子 の詳しい編集手順については、以下のトピックを参照してください。
サーブレット マッピングとは、サーブレットへのアクセス方法を制御することです。次の例は、Web アプリケーションでサーブレット マッピングを使用する方法を示しています。この例には、（web.xml デプロイメント記述子の）サーブレット コンフィグレーションとマッピングがあり、その後にこれらのサーブレットの起動に使う URL を示す表（
url-pattern と呼び出されるサーブレットを参照）があります。
コード リスト 3-1 サーブレット マッピングの例
<servlet>
<servlet-name>watermelon</servlet-name>
<servlet-class>myservlets.watermelon</servlet-class>
</servlet>
<servlet>
<servlet-name>garden</servlet-name>
<servlet-class>myservlets.garden</servlet-class>
</servlet>
<servlet>
<servlet-name>list</servlet-name>
<servlet-class>myservlets.list</servlet-class>
</servlet>
<servlet>
<servlet-name>kiwi</servlet-name>
<servlet-class>myservlets.kiwi</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>watermelon</servlet-name>
<url-pattern>/fruit/summer/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>garden</servlet-name>
<url-pattern>/seeds/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>list</servlet-name>
<url-pattern>/seedlist</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>kiwi</servlet-name>
<url-pattern>*.abc</url-pattern>
</servlet-mapping>
サーブレットの初期化パラメータは、Web アプリケーション デプロイメント記述子の中の <servlet> 要素の <init-param> 要素に、<param-name> タグと <param-value> タグを使って定義します。次に例を示します。
コード リスト 3-2 サーブレット初期化パラメータのコンフィグレーション例
<servlet>
<servlet-name>HelloWorld2</servlet-name>
<servlet-class>examples.servlets.HelloWorld2</servlet-class>
<init-param>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
</init-param>
<init-param>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
</init-param>
</servlet>
Web アプリケーション デプロイメント記述子の編集の詳細については、 Web アプリケーションのデプロイメント記述子の記述を参照してください。
JavaServer Pages（JSP）ファイルは、Web アプリケーションのルート（またはルートの下のサブディレクトリ）に格納することでデプロイされます。追加の JSP コンフィグレーション パラメータは WebLogic 固有のデプロイメント記述子である weblogic.xml の <jsp-descriptor> 要素に定義されます。これらのパラメータは次の機能を定義します。
これらのパラメータの詳細については、 JSP パラメータの名前と値を参照してください。
weblogic.xml ファイルの編集手順については、
weblogic.xml ファイル作成の主な手順を参照してください。
<servlet> タグを使うと 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 アプリケーション デプロイメント記述子に次のエントリを作成します。
<taglib>
<taglib-uri>myTaglib</taglib-uri>
<tablig-location>WEB-INF/myTLD.tld</taglib-location>
</taglib>
タグ ライブラリは、.jar ファイルとしてデプロイできます。詳細については、「JSP タグ ライブラリを JAR ファイルとしてデプロイする」を参照してください。
カスタム JSP タグ ライブラリの作成の詳細については、『JSP Tag Extensions プログラマーズ ガイド』を参照してください。
WebLogic Server には、アプリケーションで使用できるカスタム JSP タグがいくつか付属しています。これらのタグを使用すると、キャッシング、クエリ パラメータベースのフロー制御の効率化、およびオブジェクト セットに対する反復処理の効率化を行うことができます。詳細については、以下を参照してください。
WebLogic Server では、要求された URL がディレクトリである場合にデフォルトによって提供されるページを設定できます。ユーザが特定のファイル名を指定せずに URL を入力できるので、このウェルカム ページの機能でサイトが使いやすくなります。
ウェルカム ページは、Web アプリケーション レベルで定義します。サーバが複数の Web アプリケーションのホストになっている場合は、Web アプリケーションごとに別個のウェルカム ページを定義する必要があります。
ウェルカム ページを定義するには、Web アプリケーション デプロイメント記述子の web.xml を編集します。詳細については、
手順 13 : ウェルカム ページの定義を参照してください。
ウェルカム ページを定義していない場合、WebLogic Server は以下のファイルを次の順序で検索し、最初に見つけたものにサービスを提供します。
詳細については、「WebLogic Server による HTTP リクエストの解決方法」を参照してください。
各 Web アプリケーションには、デフォルト サーブレットがあります。このデフォルト サーブレットは管理者が指定できますが、指定しない場合、WebLogic Server では FileServlet という内部サーブレットがデフォルト サーブレットとして使用されます。FileServlet の詳細については、「WebLogic Server による HTTP リクエストの解決方法」を参照してください。
どのサーブレットでも、デフォルト サーブレットとして登録できます。独自のデフォルト サーブレットを作成すれば、独自のロジックを使用して、デフォルト サーブレットに送られるリクエストの処理方法を定義できます。
設定したデフォルト サーブレットは、FileServlet に取って代わります。FileServlet はほとんどのファイル（テキスト ファイル、HTML ファイル、イメージ ファイルなど）を提供するために使用されるので、デフォルト サーブレットの設定は注意深く行う必要があります。デフォルト サーブレットでこれらのファイルを提供するには、その機能をデフォルト サーブレットに記述する必要があります。
ユーザ定義のデフォルト サーブレットを設定するには、次の手順を実行します。
/」という url パターンを使ってマップします。これにより、デフォルト サーブレットは、拡張子が *.htm または *.html のファイルを除くすべてのファイルに応答します。
デフォルト サーバが *.htm または *.html ファイルに応答するようにするには、これらの拡張子をデフォルト サーブレットにマップし、さらに「/」をマップします。サーブレットのマップの手順については、
3-1 ページの「サーブレットのコンフィグレーション」を参照してください。
FileServlet を他の拡張子付きのファイルに提供する場合は、次の手順に従います。
WebLogic Server をコンフィグレーションすると、特定の HTTP エラーまたは Java 例外が発生したときに、標準の WebLogic Server エラー応答ページを使う代わりに、カスタム Web ページなどの HTTP リソースを使って応答させることができます。
カスタム エラー ページは、Web アプリケーション デプロイメント記述子（web.xml）の <error-page> 要素に定義します。詳細については、
error-page 要素を参照してください。
WebLogic Server には、レガシー CGI（Common Gateway Interface）スクリプトのサポート機能が用意されています。しかし、新しいプロジェクトでは、HTTP サーブレットまたは JavaServer Pages を使用することをお勧めします。
WebLogic Server は、CGIServlet という内部 WebLogic サーブレットを介してすべての CGI スクリプトをサポートします。CGI を使用するには、この CGIServlet を Web アプリケーション デプロイメント記述子に登録します（
CGIServlet の登録に使用する Web アプリケーション デプロイメント記述子エントリのサンプルを参照）。詳細については、
サーブレットのコンフィグレーションを参照してください。
CGI を使用するための WebLogic Server のコンフィグレーション
WebLogic Server で CGI をコンフィグレーションするには、次の手順に従います。
<servlet> 要素および <servlet-mapping> 要素を使用して、Web アプリケーションで CGIServlet を宣言します。CGIServlet のクラス名は、weblogic.servlet.CGIServlet です。このクラスを Web アプリケーションにパッケージ化する必要はありません。
<init-param> 要素を定義して、CGIServlet の初期化パラメータを登録します。
;」 (Windows) またはコロン「:」 (UNIX) で区切ります。CGI ディレクトリをアプリケーション ルートを基準にして指定する場合、または CGI ディレクトリが WAR ファイルの内部に存在する場合は、cgiDir を指定します。cgiDir については、以下の点に注意してください。
cgiDir で指定されているパスのサブディレクトリからは、CGI を取り出しません。
<param-name> は、*.pl のように、アスタリスク、ドット、ファイル拡張子の順で指定する必要があります。
<param-value> には、スクリプトを実行するインタープリタまたは実行可能ファイルへのパスが含まれます。マッピングごとに個別の <init-param> 要素を作成すると、複数のマッピングを作成できます。
コード リスト 3-3 CGIServlet の登録に使用する Web アプリケーション デプロイメント記述子エントリのサンプル
<servlet>
<servlet-name>CGIServlet</servlet-name>
<servlet-class>weblogic.servlet.CGIServlet</servlet-class>
<init-param>
<param-name>cgiDir</param-name>
<param-value>
/bea/wlserver6.0/config/mydomain/applications/myWebApp/cgi-bin
</param-value>
</init-param>
<init-param>
<param-name>*.pl</param-name>
<param-value>/bin/perl.exe</param-value>
</init-param>
</servlet>
...
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>
perl スクリプトを要求するために使用する URL は、次のパターンに従う必要があります。
http://
host:port/myWebApp/cgi-bin/myscript.pl
各要素の説明は次のとおりです。
host:port
myWebApp
cgi-bin
CGIServlet にマップされる url-pattern 名
myscript.pl
cgiDir 初期化パラメータで指定したディレクトリに存在する Perl スクリプトの名前
ClasspathServlet による CLASSPATH からのリソースの提供
システム CLASSPATH から、または Web アプリケーションの WEB-INF/classes ディレクトリからクラスまたは他のリソースを提供する必要がある場合、ClasspathServlet と呼ばれる特殊なサーブレットを使用できます。ClasspathServlet はアプレットまたは RMI クライアントを使用し、サーバサイド クラスへのアクセスを必要とするアプリケーションで役に立ちます。ClasspathServlet は暗黙的に登録され、任意のアプリケーションから利用できます。
ClasspathServlet を呼び出す一般的な形式は、次のとおりです。
http://server:port[/<context-path>]/classes[/<app>@[<webapp.]]/<package>.<classname>>.class
各要素の内容は以下のとおりです。
ClasspathServlet を呼び出す対象のアプリケーションを指定します。
ClasspathServlet を使用するには次の 2 つの方法があります。
CLASSPATH からリソースを提供する場合、次のような URL でリソースを呼び出す。
http://server:port/classes/weblogic/myClass.class
WEB-INF/classes ディレクトリからリソースを提供する場合、次のような URL でリソースを呼び出す。
http://server:port/classes/myApp@myWebApp/examples/servlets/myClass.class
この場合、リソースは Web アプリケーションのルートに相対した次のディレクトリにあります。
WEB-INF/classes/my/resource/myClass.class
警告: ClasspathServlet はシステム CLASSPATH にあるすべてのリソースを提供するので、システム CLASSPATH には公開できないリソースは置かないでください。
Web アプリケーションでの外部リソースのコンフィグレーション
Web アプリケーションから JNDI を介して DataSource などの外部リソースにアクセスする場合、コード内でルックアップする JNDI 名を、JNDI ツリーにバインドされているとおりの実際の JNDI 名にマップできます。このマッピングを行うには、web.xml と weblogic.xml の両方のデプロイメント記述子を使用します。このマッピングにより、アプリケーション コードを変更せずにこれらのリソースを変更できるようになります。デプロイメント記述子には、Java コードで使用される名前、JNDI ツリーにバインドされているとおりのリソースの名前、リソースの Java タイプを指定します。また、リソースのセキュリティをサーブレットによってプログラマティックに処理するか、または HTTP リクエストに関連付けられる資格に基づいて処理するかを指定します。
外部リソースをコンフィグレーションするには、次の手順に従います。
この例は、accountDataSource というデータ ソースが定義されていることを前提としています。詳細については、「JDBC データ ソース」を参照してください。
コード リスト 3-4 DataSource の使用例
Servlet code:javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup
("myDataSource");
web.xmlのエントリ :
<resource-ref>
. . .
<res-ref-name>myDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>CONTAINER</res-auth>
. . .
</resource-ref>
weblogic.xmlエントリ
<resource-description>
<res-ref-name>myDataSource</res-ref-name>
<jndi-name>accountDataSource</jndi-name>
</resource-description>
weblogic-ejb-jar.xml ファイル デプロイメント記述子に定義される EJB の JNDI 名にマップされる名前を Web アプリケーション デプロイメント記述子に指定すると、Web アプリケーションで EJB を参照できます。この手順は、Web アプリケーションと EJB との間接レベルを提供しており、サード パーティの EJB や Web アプリケーションを使用していて、EJB を直接呼び出すコードを変更できない場合に便利です。ほとんどの場合、この間接機能を使用しなくても EJB は直接呼び出すことができます。詳細については、「デプロイされた EJB の呼び出し」を参照してください。
Web アプリケーションで使用するために EJB を参照するには、次の手順に従います。
<ejb-ref> 要素に入力します。デプロイメント記述子エントリの作成手順については、
手順 21 : エンタープライズ JavaBean（EJB）リソースの参照を参照してください。
weblogic.xml の <ejb-reference-description> 要素にある参照名を weblogic-ejb-jar.xml ファイルに定義された JNDI 名にマップします。デプロイメント記述子エントリの作成手順については、
手順 3 : リソースの JNDI へのマッピングを参照してください。
Web アプリケーションがエンタープライズ アプリケーション アーカイブ（.ear ファイル）の一部である場合、.ear の <ejb-link> 要素で使用されている名前によって EJB を参照できます。
WebLogic Server は、HTTP リクエストに含まれている文字データを、そのネイティブのエンコーディングから Java サーブレット API が使用する Unicode エンコーディングに変換する必要があります。この変換を実行するために、WebLogic Server は、リクエストのエンコーディングでどのコードセットが使われたのかを知る必要があります。
コードセットを定義する方法は 2 種類あります。
<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 文字セットを使ってデータを処理します。
weblogic.xml にある <input-charset> 要素を使って、リクエストに使用するコードセットを設定できます。<java-charset-name> 要素は、リクエストの URL が <resource-path> 要素で指定したパスを含んでいるときにデータを変換するエンコーディングを定義します。
次に例を示します。
<input-charset>
<resource-path>/foo/*</resource-path>
<java-charset-name>SJIS</java-charset-name>
</input-charset>
この方法は GET 処理と POST 処理の両方で使用できます。
Web アプリケーション デプロイメント記述子の詳細については、 WebLogic 固有のデプロイメント記述子（weblogic.xml）の記述を参照してください。
文字セットを記述するために 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>
<iana-charset-name>Shift-JIS</iana-charset-name>
<java-charset-name>SJIS</java-charset-name>
</charset-mapping>
|
|
|