ナビゲーションをスキップ

WebLogic Server Web アプリケーションの開発

  前 次 前/次ボタンと目次ボタンとの区切り線 目次  

Web アプリケーション コンポーネントのコンフィグレーション

以下の節では、Web アプリケーション コンポーネントをコンフィグレーションする方法について説明します。

 


サーブレットのコンフィグレーション

サーブレットは、Web アプリケーション デプロイメント記述子の複数のエントリで Web アプリケーションの一部として定義します。<servlet> 要素の下の最初のエントリには、サーブレットの名前が定義され、そのサーブレットを実行するコンパイル済みクラスが指定されます。あるいは、サーブレット クラスを指定する代わりに、JSP を指定することもできます。この要素には、サーブレットの初期化属性とセキュリティ ロール用の定義も含まれています。<servlet-mapping> 要素の下の 2 番目のエントリには、このサーブレットを呼び出す URL パターンが定義されています。

サーブレット マッピング

サーブレット マッピングとは、サーブレットへのアクセス方法を制御することです。次の例は、Web アプリケーションでサーブレット マッピングを使用する方法を示しています。この例には、(web.xml デプロイメント記述子の) サーブレット コンフィグレーションとマッピングがあり、その後にこれらのサーブレットの起動に使う URL を示す表 (「url-pattern と呼び出されるサーブレット」を参照) があります。

一般的なサーブレット マッピングのルールや規約など、サーブレット マッピングの詳細については、サーブレット 2.3 仕様のセクション 11 (http://www.jcp.org/aboutJava/communityprocess/final/jsr053/) を参照してください。

コード リスト 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>

表 3-1 url-pattern と呼び出されるサーブレット

URL

呼び出される
サーブレット

http://host:port/mywebapp/fruit/summer/index.html

watermelon

http://host:port/mywebapp/fruit/summer/index.abc

watermelon

http://host:port/mywebapp/seedlist

list

http://host:port/mywebapp/seedlist/index.html

デフォルト サーバ (コンフィグレーションされている場合)、または HTTP 404 エラー メッセージ (「File not found」)。

list サーブレットが /seedlist* にマップされていた場合、list サーブレットが呼び出される。

http://host:port/mywebapp/seedlist/pear.abc

kiwi

list サーブレットが /seedlist* にマップされていた場合、list サーブレットが呼び出される。

http://host:port/mywebapp/seeds

garden

http://host:port/mywebapp/seeds/index.html

garden

http://host:port/mywebapp/index.abc

kiwi

ServletServlet は、サーブレットのデフォルト マッピングの作成に使用できます。たとえば、/myservlet/* に対するすべてのサーブレットにマップするデフォルト マッピングを作成すると、http://host:port/web-app-name/myservlet/com/foo/FooServlet を使用してサーブレットを呼び出せます。このデフォルト マッピングを作成するには、web.xml ファイルに次のコードを追加します。

<servlet>
  <servlet-name>ServletServlet</servlet-name>
  <servlet-class>weblogic.servlet.ServletServlet</servlet-class>
</servlet>

<servlet-mapping>

<servlet-name>ServletServlet</servlet-name>
  <url-pattern>myservlet/*</url-pattern>
</servlet-mapping>

サーブレット初期化属性

サーブレットの初期化属性は、Web アプリケーションのデプロイメント記述子、web.xml の中の <servlet> 要素の <init-param> 要素に、<param-name> タグと <param-value> タグを使って定義します。次に例を示します。

コード リスト 3-2web.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 アプリケーションのデプロイメント」を参照してください。

 


Java Server Pages (JSP) のコンフィグレーション

Java Server Pages (JSP) ファイルをデプロイするには、Web アプリケーションのルート (またはルートの下のサブディレクトリ) に格納する必要があります。JSP コンフィグレーション属性は、WebLogic 固有のデプロイメント記述子である weblogic.xml<jsp-descriptor> 要素に定義します。これらの属性は次の機能を定義します。

これらの属性の詳細については、「JSP 属性の名前と値」を参照してください。

 


JSP のサーブレットとしての登録

<servlet> 要素を使うと JSP をサーブレットとして登録できます。サーブレット コンテナは、既知のサーブレットのマップを保持します。このマップは、コンテナに対するリクエストを解決するために使われます。このマップにエントリを追加することを、サーブレットを「登録する」と言います。このマップへのエントリの追加は、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) ファイルに定義します。 この 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 タグ ライブラリの作成の詳細については、『WebLogic JSP Tag Extensions プログラマーズ ガイド』を参照してください。

WebLogic Server には、アプリケーションで使用できるカスタム JSP タグがいくつか付属しています。これらのタグを使用すると、キャッシング、クエリ属性ベースのフロー制御の効率化、およびオブジェクト セットに対する反復処理の効率化を行うことができます。詳細については、次を参照してください。

 


ウェルカム ページのコンフィグレーション

WebLogic Server では、要求された URL がディレクトリである場合にデフォルトによって提供されるページを設定できます。ユーザが特定のファイル名を指定せずに URL を入力できるので、このウェルカム ページの機能でサイトが使いやすくなります。

ウェルカム ページは、Web アプリケーション レベルで定義します。サーバが複数の Web アプリケーションのホストになっている場合は、Web アプリケーションごとに別個のウェルカム ページを定義する必要があります。

ウェルカム ページを定義するには、Web アプリケーション デプロイメント記述子 web.xml を編集します。ウェルカム ページを定義していない場合、WebLogic Server は以下に示すファイルをここに書かれた順序で検索し、最初に見つけたファイルを提供します。

  1. index.html
  2. index.htm
  3. index.jsp

ウェルカム ページのコンフィグレーション例を次に示します。

コード リスト 3-3ウェルカム ページの例

<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>

 


デフォルト サーブレットの設定

各 Web アプリケーションには、デフォルト サーブレットがあります。このデフォルト サーブレットは管理者が指定できますが、指定しない場合、WebLogic Server では FileServlet という内部サーブレットがデフォルト サーブレットとして使用されます。

どのサーブレットでも、デフォルト サーブレットとして登録できます。独自のデフォルト サーブレットを作成すれば、独自のロジックを使用して、デフォルト サーブレットに送られるリクエストの処理方法を定義できます。

設定したデフォルト サーブレットは、FileServlet に取って代わります。FileServlet はほとんどのファイル (テキスト ファイル、HTML ファイル、イメージ ファイルなど) を提供するために使用されるので、デフォルト サーブレットの設定は注意深く行う必要があります。デフォルト サーブレットでこれらのファイルを提供するには、その機能をデフォルト サーブレットに記述する必要があります。

ユーザ定義のデフォルト サーブレットを設定するには、次の手順に従います。

  1. サーブレットのコンフィグレーション」の説明に従って、サーブレットを定義します。
  2. FileServlet で他の拡張子付きのファイルを提供する場合は、次の手順に従います。
    1. サーブレットを定義し、myFileServlet などの <servlet-name> を指定します。
    2. <servlet-class>weblogic.servlet.FileServlet と定義します。
    3. <servlet-mapping> 要素を使ってファイル拡張子を myFileServlet にマップします (デフォルト サーブレット用のマッピングに追加して)。 たとえば、myFileServlet.gif ファイルを提供するには、*.gifmyFileServlet にマップします。

注意 : FileServlet には、docHome が指定されていない場合にソース ファイル名を特定するための SERVLET_PATH が含まれています。 その結果、FileServlet/dir/* などにマップすることで、特定のディレクトリからのファイルのみを明示的に提供できるようになりました。

 


HTTP エラー応答のカスタマイズ

WebLogic Server をコンフィグレーションすると、特定の HTTP エラーまたは Java 例外が発生したときに、標準の WebLogic Server エラー応答ページを使う代わりに、カスタム Web ページなどの HTTP リソースを使って応答させることができます。

カスタム エラー ページは、Web アプリケーションのデプロイメント記述子 (web.xml) の <error-page> 要素で定義します。エラー ページの詳細については、「error-page」を参照してください。

 


WebLogic Server での CGI の使用

注意 : WebLogic Server には、レガシー CGI (Common Gateway Interface) スクリプトのサポート機能が用意されています。しかし、新しいプロジェクトでは、HTTP サーブレットまたは JavaServer Pages を使用することをお勧めします。

WebLogic Server は、CGIServlet という内部 WebLogic サーブレットを介してすべての CGI スクリプトをサポートします。CGI を使用するには、この CGIServlet を Web アプリケーション デプロイメント記述子に登録します。詳細については、「サーブレットのコンフィグレーション」を参照してください。

CGI を使用するための WebLogic Server のコンフィグレーション

WebLogic Server で CGI をコンフィグレーションするには、次の手順に従います。

  1. <servlet> 要素および <servlet-mapping> 要素を使って、Web アプリケーションで CGIServlet を宣言します。CGIServlet のクラス名は、weblogic.servlet.CGIServlet です。このクラスを Web アプリケーションにパッケージ化する必要はありません。
  2. 次の <init-param> 要素を定義して、CGIServlet 用の次の初期化属性を登録します。

cgiDir

CGI スクリプトが存在するディレクトリのパス。複数のディレクトリを指定するには、Windows でも UNIX でもセミコロン (;) で区切ります。cgiDir を指定しない場合、Web アプリケーション ルートの下の cgi-bin がデフォルトのディレクトリとなります。

useByteStream

このパラメータ (大文字小文字が区別される) は、デフォルトの文字ストリームの代わりとしてデータ転送に使用できます。このパラメータを使用すると、CGI サーブレット内の画像をゆがみなく転送できます。

extension mapping

ファイル拡張子をスクリプトを実行するインタープリタまたは実行可能ファイルにマップします。スクリプトが実行可能ファイルを必要としない場合、この初期化属性は省略可能です。

拡張子マッピング用の <param-name> は、*.pl のように、アスタリスク、ドット、ファイル拡張子の順で指定する必要があります。

<param-value> は、スクリプトを実行するインタープリタまたは実行可能ファイルへのパスを含んでいます。個別のマッピングに独立した <init-param> 要素を作成すると、複数のマッピングを作成できます。

コード リスト 3-4CGIServlet の登録に使用する 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>

CGI スクリプトの要求

Perl スクリプトを要求するために使用する URL は、次のパターンに従う必要があります。

http://host:port/myWebApp/cgi-bin/myscript.pl

各値の説明は次のとおりです。

host:port

WebLogic Server のホスト名とポート番号

myWebApp

Web アプリケーションの名前

cgi-bin

CGIServlet にマップされる url-pattern

myscript.pl

cgiDir 初期化属性で指定したディレクトリに存在する Perl スクリプトの名前

CGI のベスト プラクティス

サブスクリプトの呼び出しに関する CGI のベスト プラクティスを次に示します。

 


ClasspathServlet による CLASSPATH からのリソースの提供

システム CLASSPATH から、または Web アプリケーションの WEB-INF/classes ディレクトリからクラスまたは他のリソースを提供する必要がある場合、ClasspathServlet と呼ばれる特殊なサーブレットを使用できます。ClasspathServlet はアプレットまたは RMI クライアントを使用し、サーバサイド クラスへのアクセスを必要とするアプリケーションで役に立ちます。 ClasspathServlet は暗黙的に登録され、任意のアプリケーションから利用できます。

ClasspathServlet は、デフォルトでは常に有効です。無効にするには、ServerMBean のパラメータ ClassPathServletDisabled を true に設定します (デフォルトは false)。

ClasspathServlet はシステム CLASSPATH から次の順序でクラスまたはリソースを返します。

  1. WEB-INF/classes
  2. WEB-INF/lib/* の下の jar ファイル
  3. システム CLASSPATH

Web アプリケーションの WEB-INF/classes ディレクトリからリソースを提供する場合、次のような URL でリソースを呼び出します。

http://server:port/myWebApp/classes/my/resource/myClass.class

この場合、リソースは Web アプリケーションのルートを基準にした次のディレクトリにあります。

WEB-INF/classes/my/resource/myClass.class

警告 : ClasspathServlet はシステム CLASSPATH にあるすべてのリソースを提供するので、システム CLASSPATH には公開できないリソースは置かないでください。

 


Web アプリケーションのリソースのコンフィグレーション

Web アプリケーションで使用するリソースは、通常アプリケーションの外部にデプロイされます。オプションとして、JDBC データソースを EAR ファイルの一部として Web アプリケーションのスコープの中でデプロイできます。

WebLogic Server 7.0 より前のバージョンでは、JDBC データソースは常に Web アプリケーションの外部にデプロイされました。Web アプリケーションで外部リソースを使用するには、web.xml および weblogic.xml デプロイメント記述子を使用して、アプリケーションが使用する JNDI リソース名をグローバル JNDI リソース名で解決する必要があります。詳細については、「外部リソースのコンフィグレーション」を参照してください。

WebLogic Server 7.x 以降では、weblogic-application.xml デプロイメント記述子で JDBC データソースをコンフィグレーションすることによって、それらを Web アプリケーション EAR ファイルの一部としてデプロイできます。EAR ファイルの一部としてデプロイされるリソースを、アプリケーション スコープ リソースと呼びます。これらのリソースは Web アプリケーションのプライベートなリソースであり、アプリケーション コンポーネントは java:app/env でローカル JNDI ツリーから直接これらのリソース名にアクセスできます。

外部リソースのコンフィグレーション

Web アプリケーションから JNDI (Java Naming and Directory Interface) を介してデータソースなどの外部リソース (アプリケーション EAR ファイルでデプロイされないリソース) にアクセスする場合、コード内でルックアップする JNDI 名を、グローバル JNDI ツリーにバインドされている実際の JNDI 名にマップできます。このマッピングを行うには、web.xmlweblogic.xml の両方のデプロイメント記述子を使用します。このマッピングにより、アプリケーション コードを変更せずにこれらのリソースを変更できるようになります。デプロイメント記述子には、Java コードで使用される名前、JNDI ツリーにバインドされているとおりのリソースの名前、リソースの Java タイプを指定します。また、リソースのセキュリティをサーブレットによってプログラム的に処理するか、または HTTP リクエストに関連付けられる資格に基づいて処理するかを指定します。

外部リソースをコンフィグレーションするには、次の手順に従います。

  1. コードで使用するリソース名、Java タイプ、およびセキュリティ認証タイプをデプロイメント記述子に入力します。
  2. リソース名を JNDI 名にマップします。

次の例に、外部データソースの使用方法を示します。この例は、accountDataSource というデータ ソースが定義されていることを前提としています。詳細については、Administration Console オンライン ヘルプの「[JDBC データ ソース] --> [コンフィグレーション]」を参照してください。

コード リスト 3-5外部データソースの使用例

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>

外部 EJB の参照

Web アプリケーションは、外部参照を使用することによって、異なるアプリケーション (異なる EAR ファイル) の一部としてデプロイされた EJB にアクセスできます。参照される EJB は、その weblogic-ejb-jar.xml デプロイメント記述子のグローバル JNDI ツリーに名前をエクスポートします。Web アプリケーション モジュールでの EJB 参照は、<ejb-reference-description> 要素をその weblogic.xml デプロイメント記述子に追加することによって、このグローバル JNDI 名にリンクできます。

この手順は、Web アプリケーションと EJB との間接レベルを提供しており、サード パーティの EJB や Web アプリケーションを使用していて、EJB を直接呼び出すコードを変更できない場合に便利です。ほとんどの場合、この間接機能を使用しなくても EJB は直接呼び出すことができます。詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』を参照してください。

Web アプリケーションで使用するために外部 EJB を参照するには、次の手順に従います。

  1. コード内で EJB をルックアップするために使用する EJB 参照名、Java クラス名、EJB のホームおよびリモート インタフェース名を、Web アプリケーション デプロイメント記述子の <ejb-ref> 要素に入力します。
  2. WebLogic 固有のデプロイメント記述子である weblogic.xml<ejb-reference-description> 要素にある参照名を、weblogic-ejb-jar.xml ファイルに定義された JNDI 名にマップします。
  3. Web アプリケーションがエンタープライズ アプリケーション アーカイブ (EAR ファイル) の一部である場合は、<ejb-link> 要素のある EAR で使用される名前で EJB を参照できます。

ejb-ref* 要素についての詳細

web.xml デプロイメント記述子の ejb-ref 要素では、サーブレットまたは JSP のいずれかが特定の EJB を使用することを宣言します。weblogic.xml デプロイメント記述子の ejb-reference-description 要素で、その参照を EJB にバインドします。バインドされた EJB はグローバル JNDI ツリーに通知されます。

ejb-reference-descriptor 要素は、ejb-ref-name 要素を使って解決する ejb-ref 要素を示します。つまり、同じ ejb-ref-name 要素を持つ ejb-reference-descriptor 要素と ejb-ref 要素を同時に使用できます。

ejb-link の構文が追加されたことによって、EJB を使用するサーブレットまたは JSP と使用される EJB が同じアプリケーション内にある場合には、ejb-reference-descriptor 要素は不要になりました。

ejb-ref-name 要素は、web.xml デプロイメント記述子内で次の 2 つの役割を果たします。

アプリケーション スコープの EJB の参照

アプリケーションの内部で、WebLogic Server は、他のアプリケーション コンポーネントによって参照される EJB を、参照するコンポーネントに関連付けられた環境にバインドします。 これらのリソースは、java:comp/env を基準とした相対的な JNDI 名のルックアップを通じて、実行時にアクセスされます。

EJB と Web アプリケーションを含むアプリケーション (エンタープライズ アプリケーションとも呼ばれる) のアプリケーション デプロイメント記述子 (application.xml) の例を以下に示します (簡潔に示すために、この例では XML ヘッダは省略しています)。

コード リスト 3-6デプロイメント記述子の例

<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> 要素は以下のようになります。

コード リスト 3-7<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> 要素の構文は次のとおりです。

<ejb-link>../ejb1.jar#ejb1</ejb-link>,

この構文で # の左側の部分は、参照される EJB モジュールの相対パスです。# の右側の構文は、そのモジュールで参照される特定の EJB です。上記の例では、EJB の JAR ファイルと WAR ファイルが同じレベルにあります。

<ejb-link> で参照される名前 (この例では myejb) は、参照される EJB の記述子の <ejb-name> 要素に対応しています。その結果、この <ejb-ref> が参照している EJB モジュールのデプロイメント記述子 (ejb-jar.xml) には、以下のようなエントリが必要です。

コード リスト 3-8<ejb-jar> 要素

 <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 に設定されています。

実行時に、Web アプリケーション コードが java:/comp/env に基づいて EJB の JNDI 名をルックアップすることを確認します。サーブレット コードの例は以下のとおりです。

MyHome home = (MyHome)ctx.lookup("java:/comp/env/ejb1");

この例で使用される名前 (ejb1) は、上記の web.xml の抜粋の <ejb-ref> 要素で定義される <ejb-ref-name> です。

 


サーブレット、コンテキスト リスナ、フィルタのロード

サーブレット、コンテキスト リスナ、およびフィルタは、以下の順序でロードされ、破棄されます。

ロードの順序 :

  1. コンテキスト リスナ
  2. フィルタ
  3. サーブレット

破棄の順序 :

  1. サーブレット
  2. フィルタ
  3. コンテキスト リスナ

サーブレットとフィルタは、web.xml ファイルで定義されている順序でロードされ、その逆の順序でアンロードされます。コンテキスト リスナは次の順序でロードされます。

  1. web.xml ファイル内のすべてのコンテキスト リスナ (そのファイルで指定されている順序でロードされる)
  2. タグ ライブラリ記述子を含む、パッケージ化された JAR ファイル
  3. WEB-INF ディレクトリ内のタグ ライブラリ記述子

 


HTTP リクエストのエンコーディングの識別

WebLogic Server は、HTTP リクエストに含まれている文字データを、そのネイティブのエンコーディングから Java サーブレット API が使用する Unicode エンコーディングに変換する必要があります。この変換を実行するために、WebLogic Server は、リクエストのエンコーディングでどのコード セットが使われたのかを知る必要があります。

コード セットを定義する方法は 2 種類あります。

 


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>
    <iana-charset-name>Shift-JIS</iana-charset-name>
    <java-charset-name>SJIS</java-charset-name>
</charset-mapping>

 

フッタのナビゲーションのスキップ  ページの先頭 前 次