BEA ホーム | 製品 | dev2dev | support | askBEA |
![]() |
![]() |
|
![]() |
e-docs > WebLogic Server > Web アプリケーションのアセンブルとコンフィグレーション > Web アプリケーション コンポーネントのコンフィグレーション |
Web アプリケーションのアセンブルとコンフィグレーション
|
Web アプリケーション コンポーネントのコンフィグレーション
次の節では、Web アプリケーションをコンフィグレーションする方法について説明します。
サーブレットは、Web アプリケーション デプロイメント記述子の複数のエントリで Web アプリケーションの一部として定義されます。<servlet> 要素の下の最初のエントリには、サーブレットの名前が定義され、そのサーブレットを実行するコンパイル済みクラスが指定されます。あるいは、サーブレット クラスを指定する代わりに、JSP ページを指定することもできます。この要素には、サーブレットの初期化パラメータとセキュリティ ロール用の定義も含まれています。<servlet-mapping> 要素の下の 2 番目のエントリには、このサーブレットを呼び出す URL パターンが定義されています。
Web アプリケーション デプロイメント記述子の詳しい編集手順については、以下のトピックを参照してください。
サーブレット マッピングとは、サーブレットへのアクセス方法を制御することです。次の例は、Web アプリケーションでサーブレット マッピングを使用する方法を示しています。この例には、(web.xml デプロイメント記述子の) サーブレット コンフィグレーションとマッピングがあり、その後にこれらのサーブレットの起動に使う URL を示す表 (url-pattern と呼び出されるサーブレットを参照) があります。
<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>
デフォルト サーバ (コンフィグレーションされている場合)、または HTTP 404 エラー メッセージ (「File not found」)。 |
|
サーブレットの初期化パラメータは、Web アプリケーション デプロイメント記述子、web.xml の中の <servlet> 要素の <init-param> 要素に、<param-name> タグと <param-value> タグを使って定義します。次に例を示します。
コード リスト 3-2 web.xml 内のサーブレット初期化パラメータのコンフィグレーション例
<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 タグ ライブラリの作成の詳細については、『WebLogic 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 ファイル、画像ファイルといったほとんどのファイルを提供するために使用されるので、デフォルト サーブレットは慎重に設定する必要があります。デフォルト サーブレットでこれらのファイルを提供するには、その機能をデフォルト サーブレットに記述する必要があります。
ユーザ定義のデフォルト サーブレットを設定するには、次の手順を実行します。
デフォルト サーブレットが *.htm または *.html で終わる名前のファイルにも応答するようにするには、「/」のマッピングに加えて、それらの拡張子をデフォルト サーブレットにマップする必要があります。サーブレットのマップの手順については、サーブレットのコンフィグレーションを参照してください。
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 をコンフィグレーションするには、次の手順に従います。
コード リスト 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
ClasspathServlet による CLASSPATH からのリソースの提供
システム CLASSPATH から、または Web アプリケーションの WEB-INF/classes ディレクトリからクラスまたは他のリソースを提供する必要がある場合、ClasspathServlet と呼ばれる特殊なサーブレットを使用できます。ClasspathServlet はアプレットまたは RMI クライアントを使用し、サーバサイド クラスへのアクセスを必要とするアプリケーションで役に立ちます。ClasspathServlet は暗黙的に登録され、任意のアプリケーションから利用できます。
ClasspathServlet を使用するには次の 2 つの方法があります。
http://server:port/classes/my/resource/myClass.class
http://server:port/myWebApp/classes/my/resource/myClass.class
警告: ClasspathServlet はシステム CLASSPATH にあるすべてのリソースを提供するので、システム CLASSPATH には公開できないリソースは置かないでください。
Web アプリケーションで使用するリソースは、通常アプリケーションの外部にデプロイされます。オプションとして、JDBC データソースを EAR ファイルの一部として Web アプリケーションのスコープの中でデプロイできます。
WebLogic Server 7.0 より前のバージョンでは、JDBC データソースは常に Web アプリケーションの外部にデプロイされました。Web アプリケーションで外部リソースを使用するには、web.xml および weblogic.xml デプロイメント記述子を使用して、アプリケーションが使用する JNDI リソース名をグローバル JNDI リソース名で解決する必要があります。詳細については、外部リソースのコンフィグレーションを参照してください。
WebLogic Server 7.0 では、weblogic-application.xml デプロイメント記述子で JDBC データソースをコンフィグレーションすることによって、それらを Web アプリケーション EAR ファイルの一部としてデプロイできます。EAR ファイルの一部としてデプロイされるリソースを、アプリケーション スコープ リソースと呼びます。これらのリソースは Web アプリケーションのプライベートなリソースであり、アプリケーション コンポーネントは java:comp/env でローカル JNDI ツリーから直接これらのリソース名にアクセスできます。詳細については、アプリケーション スコープのリソースのコンフィグレーションを参照してください。
Web アプリケーションから JNDI (Java Naming and Directory Interface) を介してデータソースなどの外部リソース (アプリケーション EAR ファイルでデプロイされないリソース) にアクセスする場合、コード内でルックアップする JNDI 名を、グローバル JNDI ツリーにバインドされている実際の JNDI 名にマップできます。このマッピングは、web.xml および weblogic.xml の両方のデプロイメント記述子を使用して行われ、アプリケーション コードを変更しないリソースの変更を可能にします。デプロイメント記述子には、Java コードで使用される名前、JNDI ツリーにバインドされているとおりのリソースの名前、リソースの Java タイプを指定します。また、リソースのセキュリティをサーブレットによってプログラム的に処理するか、または HTTP リクエストに関連付けられる資格に基づいて処理するかを指定します。
外部リソースをコンフィグレーションするには、次の手順を行います。
この例は、accountDataSource というデータソースが定義されていることを前提としています。詳細については、「JDBC データ ソース」を参照してください。
サーブレットのコード :
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 Server は、アプリケーション スコープ リソース名をアプリケーションのローカル JNDI ツリーにバインドします。Web アプリケーション コードは、java:comp/env に基づいて実際の JNDI リソース名をルックアップすることによって、これらのリソースにアクセスします。
Web アプリケーションがアプリケーション スコープ リソースだけを使用する場合、weblogic.xml デプロイメント記述子にグローバル JNDI リソース名を入力する必要はありません (外部リソースのコンフィグレーションを参照)。実際のところ、このデプロイメント記述子の他の機能が不要な場合、weblogic.xml を完全に省略できます。
アプリケーション スコープ リソースをコンフィグレーションするには、次の手順に従います。
サーブレットのコード :
javax.sql.DataSource ds = (javax.sql.DataSource) ctx.lookup
("java:comp/env/myDataSource");
weblogic-application.xml のエントリ :
<weblogic-application>
<data-source-name>myDataSource</data-source-name>
</weblogic-application>
Web アプリケーションで使用する EJB は、アプリケーションの外部にデプロイするか、EAR ファイルの一部として Web アプリケーションのスコープの中でデプロイします。EJB の参照手順は、その EJB が外部かアプリケーション スコープかによって異なります。
Web アプリケーションは、外部参照を使用することによって、異なるアプリケーション (異なる EAR ファイル) の一部としてデプロイされた EJB にアクセスできます。参照される EJB は、その weblogic-ejb-jar.xml デプロイメント記述子のグローバル JNDI ツリーに名前をエクスポートします。Web アプリケーション モジュールでの EJB 参照は、<ejb-reference-description> 要素をその weblogic.xml デプロイメント記述子に追加することによって、このグローバル JNDI 名にリンクできます。
この手順は、Web アプリケーションと EJB との間接レベルを提供しており、サード パーティの EJB や Web アプリケーションを使用していて、EJB を直接呼び出すコードを変更できない場合に便利です。ほとんどの場合、この間接機能を使用しなくても EJB は直接呼び出すことができます。詳細については、../ejb/EJB_design.html#design_invoking の「デプロイされた EJB へのアクセス」を参照してください。
Web アプリケーションで使用するために外部 EJB を参照するには、次の手順に従います。
Web アプリケーションがエンタープライズ アプリケーション アーカイブ (.ear ファイル) の一部である場合は、<ejb-link> 要素のある .ear で使用される名前で EJB を参照できます。
アプリケーションの内部で、WebLogic Server は、他のアプリケーション コンポーネントによって参照される EJB を、参照するコンポーネントに関連付けられた環境にバインドします。これらのリソースは、java:comp/env を基準とした相対的な JNDI 名のルックアップを通じて、実行時にアクセスされます。
EJB と Web アプリケーションを含むアプリケーションのアプリケーション デプロイメント記述子 (application.xml) の例を以下に示します (XML ヘッダは省略しています)。
<application>
<display-name>MyApp</display-name>
<module>
<web>
<web-uri>myapp.war</web-uri>
<context-root>myapp</context-root>
</web>
</module>
<module>
<ejb>ejb1.jar</ejb>
</module>
</application>
Web アプリケーション のコードで ejb1.jar 内の EJB を使用できるようにするには、Web アプリケーション デプロイメント記述子 (web.xml) に、JAR ファイルを参照する <ejb-link> と、呼び出される EJB の名前を含む <ejb-ref> スタンザが含まれている必要があります。
<ejb-link> エントリのフォーマットは以下のようにする必要があります。
filename#ejbname
filename は Web アプリケーションに対する相対的な JAR ファイル名、ejbname はその JAR ファイル内の EJB です。<ejb-link> 要素は以下のようになります。
<ejb-link>../ejb1.jar#myejb</ejb-link>
JAR のパスは WAR ファイルに対して相対的なので、「../」で始まります。また、ejbname がそのアプリケーション全体でユニークな場合、JAR のパスは省略してもかまいません。その結果、エントリは以下のようになります。
<ejb-link>myejb</ejb-link>
<ejb-link> 要素は、Web アプリケーションの web.xml 記述子に含まれる <ejb-ref> 要素の下位要素です。<ejb-ref> 要素は以下のようになります。
<web-app>
...
<ejb-ref>
<ejb-ref-name>ejb1</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<home>mypackage.ejb1.MyHome</home>
<remote>mypackage.ejb1.MyRemote</remote>
<ejb-link>../ejb1.jar#myejb</ejb-link>
</ejb-ref>
...
</web-app>
<ejb-link> で参照される名前 (この例では myejb) は、参照される EJB の記述子の <ejb-name> 要素に対応しています。その結果、この <ejb-ref> が参照している EJB モジュールのデプロイメント記述子 (ejb-jar.xml) には、以下のようなエントリが必要です。
<ejb-jar>
...
<enterprise-beans>
<session>
<ejb-name>myejb</ejb-name>
<home>mypackage.ejb1.MyHome</home>
<remote>mypackage.ejb1.MyRemote</remote>
<ejb-class>mypackage.ejb1.MyBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
</session>
</enterprise-beans>
...
</ejb-jar>
<ejb-name> 要素は myejb に設定されています。
注意: デプロイメント記述子エントリの作成手順については、手順 21: エンタープライズ JavaBean (EJB) リソースの参照を参照してください。
実行時に、Web アプリケーション コードが java:/comp/env に基づいて EJB の JNDI 名をルックアップすることを確認します。サーブレット コードの例は以下のとおりです。
MyHome home = (MyHome)ctx.lookup("java:/comp/env/ejb1");
この例で使用される名前 (ejb1) は、上記の web.xml の抜粋の <ejb-ref> 要素で定義される <ejb-ref-name> です。
WebLogic Server は、HTTP リクエストに含まれている文字データを、そのネイティブのエンコーディングから Java サーブレット API が使用する Unicode エンコーディングに変換する必要があります。この変換を実行するために、WebLogic Server は、リクエストのエンコーディングでどのコードセットが使われたのかを知る必要があります。
<form action="http://some.host.com/myWebApp/foo/index.html">
<input type="application/x-www-form-urlencoded; charset=SJIS">
</form>
<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>
![]() |
![]() |
![]() |
![]() |
||
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |