WebLogic Server J2EE アプリケーションのパッケージ化



\| WebLogic Server ホーム \| アプリケーションの開発 \| 前へ \| 次へ \| 目次 \| 索引 \| PDF 版

以降の節では、WebLogic Server J2EE アプリケーションをパッケージ化およびデプロイする方法について説明します。

パッケージ化の概要

WebLogic Server J2EE アプリケーションは、J2EE 仕様で定義されている標準の方法でパッケージ化されます。J2EE では、コンポーネントの動作とパッケージ化が汎用的で移植性の高い方法で定義されています。このため、実行時コンフィグレーションはコンポーネントを実際にアプリケーションサーバにデプロイするときに行います。

J2EE には、Web アプリケーション、EJB モジュール、エンタープライズアプリケーション、クライアントアプリケーション、およびリソースアダプタ用のデプロイメント仕様が含まれています。J2EE では、どのようにアプリケーションをターゲットサーバにデプロイするかは指定されておらず、標準のコンポーネントまたはアプリケーションをパッケージ化する方法だけが指定されています。

コンポーネントのタイプごとに、J2EE には必要なファイルとそれらのディレクトリ構造上の格納場所が定義されています。コンポーネントとアプリケーションは、多くの場合、EJB とサーブレットの Java クラス、リソースアダプタ、Web ページとサポートファイル、XML 形式のデプロイメント記述子、およびその他のコンポーネントが格納された JAR ファイルで構成されています。

WebLogic Server にデプロイできる状態のアプリケーションには、WebLogic 固有のデプロイメント記述子が含まれています。また、WebLogic EJB、RMI、または JSP コンパイラで生成されたコンテナクラス（オプション）が含まれることもあります。

JAR ファイル

Java の jar ユーティリティで作成される Java ARchive （JAR）ファイルには、1 つのディレクトリ内のファイルが、ディレクトリ構造を維持したまま統合されます。Java クラスローダは、クラスパス内のディレクトリを検索するのと同じように、JAR ファイル内の Java クラスファイル（および他のファイルタイプ）を検索できます。クラスローダはディレクトリまたは JAR ファイルを検索できるので、「展開された」ディレクトリまたは JAR ファイルの形式で、J2EE コンポーネントを WebLogic Server にデプロイできます。

JAR ファイルは、コンポーネントとアプリケーションをパッケージ化して配布するのに役立ちます。簡単にコピーでき、展開されたディレクトリよりも処理するファイル数が少なく、ファイル圧縮によってディスクスペースも節約できます。管理サーバが複数の WebLogic Server を持つドメインを管理する場合、JAR ファイルしかデプロイできません。Administration Console は展開されたディレクトリを管理対象サーバにコピーしないからです。

jar ユーティリティは、Java Development Kit の bin ディレクトリに格納されています。パスに javac が指定されている場合、jar も指定されています。jar コマンドの構文と動作は、UNIX tar コマンドとほぼ同じです。

jar コマンドの最も一般的な使い方は次のとおりです。

jar cf jar-file files ...

jar-file という名前の JAR ファイルを作成し、指定したファイルを統合します。ファイルリストにディレクトリを入れた場合、そのディレクトリとサブディレクトリ内のすべてのファイルが JAR ファイルに追加されます。

jar xf jar-file

現在のディレクトリ内の JAR ファイルを展開（分解）します。

jar tf jar-file

JAR ファイルの内容を一覧表示します。

最初のフラグは、操作（create、extract、または一覧表示（tell））を指定します。f フラグの後には、JAR ファイル名を指定しなければなりません。f フラグを指定しないと、jar は JAR ファイルの内容を stdin から読み込むか、または stdout に書き出します。このような処理は一般的ではありません。jar コマンドオプションの詳細については、JDK ユーティリティのドキュメントを参照してください。

XML デプロイメント記述子

コンポーネントとアプリケーションには、ディレクトリまたは JAR ファイルの内容について説明したデプロイメント記述子という XML ドキュメントが組み込まれています。デプロイメント記述子は、XML タグでフォーマットされたテキストドキュメントです。J2EE 仕様では、J2EE コンポーネントおよびアプリケーション用の標準的で移植性の高いデプロイメント記述子が定義されています。BEA は、コンポーネントまたはアプリケーションを WebLogic Server 環境にデプロイするために必要な WebLogic 固有のデプロイメント記述子をさらに定義しています。

表 3-1 に、コンポーネントとアプリケーションのタイプと、それらの J2EE 標準および WebLogic 固有のデプロイメント記述子を示します。

表3-1 J2EE と WebLogic のデプロイメント記述子

コンポーネントまたはアプリケーション	スコープ	デプロイメント記述子
Web アプリケーション	J2EE	`WEB-INF`\`web.xml`
Web アプリケーション	WebLogic	`WEB-INF`\`weblogic.xml`
エンタープライズ Bean	J2EE	`META-INF`\`ejb-jar.xml`
エンタープライズ Bean	WebLogic	`META-INF`\`weblogic-ejb-jar.xml` `META-INF`\`weblogic-cmp-rdbms-jar.xml`
リソースアダプタ	J2EE	`META-INF`\`ra.xml`
リソースアダプタ	WebLogic	`META-INF`\`weblogic-ra.xml`
エンタープライズアプリケーション	J2EE	`META-INF`\`application.xml`
クライアントアプリケーション	J2EE	`application-client.xml`
クライアントアプリケーション	WebLogic	`client-application.runtime.xml`

コンポーネントまたはアプリケーションをパッケージ化する場合は、デプロイメント記述子を格納するディレクトリ（WEB-INF または META-INF）を作成し、次にそのディレクトリ内に必要な XML デプロイメント記述子を作成します。

手動でデプロイメント記述子を作成することも、WebLogic 固有の Java ベースユーティリティを使用して自動的に生成することもできます。デプロイメント記述子の生成の詳細については、デプロイメント記述子の自動生成を参照してください。

開発者から J2EE 準拠の JAR ファイルを受け取った場合、そのファイルにはすでに J2EE 標準のデプロイメント記述子が組み込まれています。その JAR ファイルを WebLogic Server にデプロイするには、そのファイルの内容をディレクトリに展開し、必要な WebLogic 固有のデプロイメント記述子とその他の生成されたコンテナクラスを追加して、新旧のファイルが入った新しい JAR ファイルを作成します。

デプロイメント記述子の自動生成

WebLogic Server には、Web アプリケーション、エンタープライズ JavaBean（バージョン 1.1 および 2.0）、エンタープライズアプリケーションなどの J2EE コンポーネントまたはアプリケーションのデプロイメント記述子を自動的に生成する Java ベースのユーティリティがあります。

これらのユーティリティは、ステージングディレクトリにアセンブルしたオブジェクトを検証し、サーブレットクラス、EJB クラスなどを基に適切なデプロイメント記述子を構築します。ユーティリティは、コンポーネントごとに標準 J2EE デプロイメント記述子と WebLogic 固有のデプロイメント記述子の両方を生成します。

WebLogic Server には、以下のユーティリティがあります。

weblogic.ant.taskdefs.ejb.DDInit
エンタープライズ JavaBean 1.1 のデプロイメント記述子を作成します。
weblogic.ant.taskdefs.ejb20.DDInit
エンタープライズ JavaBean 2.0 のデプロイメント記述子を作成します。
weblogic.ant.taskdefs.war.DDInit
Web アプリケーションのデプロイメント記述子を作成します。
weblogic.ant.taskdefs.ear.DDInit
エンタープライズアプリケーションのデプロイメント記述子を作成します。

注意: これらのユーティリティは、ユーザのコンポーネントまたはアプリケーションに完全かつ厳密に従ったデプロイメント記述子ファイルを作成しようとしますが、必要な要素の多くに対して値を推測しなければなりません。この推測にはしばしば誤りがあり、コンポーネントまたはアプリケーションをデプロイするときに、WebLogic Server がエラーを返す原因になります。この場合、コンポーネントまたはアプリケーションをアンデプロイし、Administration Console のデプロイメント記述子エディタでデプロイメント記述子を編集してから、再デプロイする必要があります。デプロイメント記述子エディタの使用方法の詳細については、デプロイメント記述子の編集を参照してください。

各ユーティリティは、単一のパラメータをとります。デプロイメント記述子の生成対象となるコンポーネントまたはアプリケーションのオブジェクトを格納するルートディレクトリです。ルートディレクトリは、WEB-INF または META-INF サブディレクトリを含むディレクトリです。

たとえば、WEB-INF ディレクトリ、JSP ファイル、または Web アプリケーションを構成するその他のオブジェクトを含む c:\stage というディレクトリを作成したものの、web.xml および weblogic.xml デプロイメント記述子を作成していない場合があります。それらを自動的に生成するには、次のコマンドを実行します。

$ java weblogic.ant.taskdefs.war.DDInit c:\stage

ユーティリティは、WEB-INF ディレクトリに web.xml および weblogic.xml デプロイメント記述子を作成します。

開発モードとプロダクションモード

WebLogic Server は、開発モードとプロダクションモードの 2 つの異なるモードで実行できます。このモードは、STARTMODE スクリプト変数をコンフィグレーションして決定します。この変数は、domain_name\startWebLogic にあって、変更が可能です。この STARTMODE 変数で、起動時のモードをプロダクションモードから開発モードへと切り替えることができます。

開発モードを有効にするには、STARTMODE スクリプト変数を以下のようにコンフィグレーションします。

-Dweblogic.ProductionModeEnabled=false

プロダクションモードを有効にするには、この変数を以下のように設定します。

-Dweblogic.ProductionModeEnabled=true

注意: デフォルト設定は、false です。

WebLogic Server の開発モード、プロダクションモードでの起動についての詳細は、「WebLogic Server の起動と停止」を参照してください。

開発モードを指定すると、 applications ディレクトリの自動デプロイ機能を使用できます。これは、WebLogic Server がインストールされている config/domain_name （domain_name は WebLogic Server ドメインの名前）にある管理サーバの applications ディレクトリに新しいファイルをコピーするということです。アプリケーションは自動的にデプロイされ更新されます。

プロダクションモードでは、WebLogic Server の Administration Console または weblogic.Deploy ツールを使用して、アプリケーションをデプロイする必要があります。どちらのデプロイメント方式も、ユーザ名とパスワードが必要です。このようにして、ファイルシステムに対する書き込み権を持ち、サーバにアプリケーションをデプロイできる権限を持つユーザに関するセキュリティ上の懸念に対応します。

Web アプリケーションのパッケージ化

Web アプリケーションをパッケージ化する前に、クライアントアプリケーションのパッケージ化を読み、WebLogic Server がアプリケーションクラスをどのようにロードするかを理解してください。

Web アプリケーションをステージングおよびパッケージ化するには、次の手順に従います。

一時的なステージングディレクトリを作成します。このディレクトリの名前は自由に付けることができます。
HTML ファイル、JSP ファイル、およびこれらの Web ページが参照する画像などのすべてのファイルを、ステージングディレクトリにコピーします。その際、参照されるファイルのディレクトリ構造はそのまま維持します。たとえば、HTML ファイルに <img src="images/pic.gif"> というタグが定義されている場合、pic.gif ファイルはその HTML ファイルの images サブディレクトリに配置されなければなりません。
ステージングディレクトリに WEB-INF および WEB-INF\classes サブディレクトリを作成して、デプロイメント記述子とコンパイル済みの Java クラスを格納します。
サーブレットクラスとヘルパークラスを WEB-INF\classes サブディレクトリにコピーまたはコンパイルします。
サーブレットが使用するエンタープライズ Bean のホームおよびリモートインタフェースクラスを WEB-INF\classes サブディレクトリにコピーします。
注意: クラスローダの概要を参照して、同じアプリケーションにあるサーブレットからの EJB 参照に影響する WebLogic Server のクラスロードメカニズムについて理解しておきます。
JSP タグライブラリを WEB-INF サブディレクトリにコピーします（タグライブラリは WEB-INF のサブディレクトリにインストールされます。.tld へのパスは .jsp ファイルにコーディングされています）。
シェル環境を設定します。
Windows NT の場合は、setEnv.cmd コマンドを実行します。このコマンドは BEA_HOME\config\domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。

UNIX の場合は、setEnv.sh コマンドを実行します。このコマンドは BEA_HOME/config/domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
WEB-INF サブディレクトリに web.xml および weblogic.xml デプロイメント記述子を自動的に生成する次のコマンドを実行します。
```
java weblogic.ant.taskdefs.war.DDInit staging-dir
```
staging-dir は、ステージングディレクトリです。

デプロイメント記述子を生成する Java ベースユーティリティ DDInit の詳細については、デプロイメント記述子の自動生成を参照してください。

または、WEB-INF サブディレクトリに web.xml および weblogic.xml ファイルを手動で作成することもできます。

注意: web.xml および weblogic.xml ファイルの要素の詳細については、『Web アプリケーションのアセンブルとコンフィグレーション』を参照してください。
次のような jar コマンドを実行して、ステージングディレクトリを .war ファイルにパッケージ化します。
```
jar cvf myapp.war -C staging-dir .
```
作成された .war ファイルは、エンタープライズアプリケーション（.ear ファイル）に追加するか、Administration Console または weblogic.deploy コマンドラインユーティリティを使用して単独でデプロイすることができます。

エンタープライズ JavaBeans のパッケージ化

1 つまたは複数のエンタープライズ Bean を 1 つのディレクトリにステージングして、それらを EJB JAR ファイルにパッケージ化できます。

EJB をパッケージ化する前に、クライアントアプリケーションのパッケージ化を読み、WebLogic Server が EJB クラスをどのようにロードするかを理解してください。

エンタープライズ Bean をステージングおよびパッケージ化するには、次の手順が必要です。

一時的なステージングディレクトリを作成します。
対象となる Bean の Java クラスをステージングディレクトリにコンパイルまたはコピーします。
ステージングディレクトリに META-INF サブディレクトリを作成します。
シェル環境を設定します。
Windows NT の場合は、setEnv.cmd コマンドを実行します。このコマンドは BEA_HOME\config\domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。

UNIX の場合は、setEnv.sh コマンドを実行します。このコマンドは BEA_HOME/config/domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
META-INF サブディレクトリに ejb-jar.xml、weblogic-ejb-jar.xml、および（必要に応じて） weblogic-rdbms-cmp-jar-bean_name.xml デプロイメント記述子を自動的に生成する次のコマンドを実行します。
```
java weblogic.ant.taskdefs.ejb.DDInit staging-dir
```
staging-dir は、ステージングディレクトリです。このユーティリティは EJB 1.1 用です。EJB 2.0 を作成する場合は、次のユーティリティを使用します。
```
java weblogic.ant.taskdefs.ejb20.DDInit staging-dir
```
デプロイメント記述子を生成する Java ベースユーティリティ DDInit の詳細については、デプロイメント記述子の自動生成を参照してください。

または、EJB デプロイメント記述子ファイルを手動で作成することもできます。META-INF サブディレクトリに ejb-jar.xml および weblogic-ejb-jar.xml ファイルを作成します。この Bean がコンテナ管理される永続的なエンティティ Bean である場合、META-INF ディレクトリに、weblogic-rdbms-cmp-jar-bean_name.xml デプロイメント記述子を作成し、その Bean のエントリを追加します。weblogic-ejb-jar.xml ファイルの <type-storage> 属性を使用して、Bean をこの CMP デプロイメント記述子にマッピングします。

注意: エンタープライズ Bean のコンパイルと EJP デプロイメント記述子の作成については、『WebLogic エンタープライズ JavaBeans プログラマーズガイド』を参照してください。
すべてのエンタープライズ Bean クラスとデプロイメント記述子をステージングディレクトリに配置すると、次のような jar コマンドを使用して EJB JAR ファイルを作成できます。
```
jar cvf jar-file.jar -C staging-dir .
```
このコマンドによって作成された jar ファイルは、WebLogic Server にデプロイすることも、またはアプリケーション JAR ファイルにパッケージ化することもできます。

-C staging-dir オプションを指定すると、jar コマンドはディレクトリを staging-dir に変更します。これにより、JAR ファイルに記録されるディレクトリパスがエンタープライズ Bean のステージングディレクトリを基準にした相対パスとなります。

エンタープライズ Bean には、コンテナクラスが必要となります。コンテナクラスとは、WebLogic EJB コンパイラによって生成され、エンタープライズ Bean を WebLogic Server にデプロイできるようにするためのクラスです。WebLogic EJB コンパイラは、EJB JAR ファイル内のデプロイメント記述子を読み取って、コンテナクラスの生成方法を決定します。WebLogic EJB コンパイラは、エンタープライズ Bean をデプロイする前に JAR ファイル上で実行できます。また、デプロイメント時に WebLogic Server にコンパイラを実行させることもできます。WebLogic EJB コンパイラの詳細については、『WebLogic エンタープライズ JavaBeans プログラマーズガイド』を参照してください。

リソースアダプタのパッケージ化

1 つまたは複数のリソースアダプタを 1 つのディレクトリにステージングして、それらを JAR ファイルにパッケージ化できます。

リソースアダプタをパッケージ化する前に、クライアントアプリケーションのパッケージ化を読み、WebLogic Server がクラスをどのようにロードするかを理解してください。

リソースアダプタをステージングおよびパッケージ化するには、次の手順に従います。

一時的なステージングディレクトリを作成します。
対象となるリソースアダプタの Java クラスをステージングディレクトリにコンパイルまたはコピーします。
ステージングディレクトリに META-INF サブディレクトリを作成します。
META-INF サブディレクトリに ra.xml デプロイメント記述子を作成して、そのリソースアダプタのエントリを追加します。
注意: ra.xml の文書型定義の詳細については、以下の Sun Microsystems のドキュメントを参照してください。

http://java.sun.com/dtd/connector_1_0.dtd
META-INF サブディレクトリに weblogic-ra.xml デプロイメント記述子を作成して、そのリソースアダプタのエントリを追加します。
注意: weblogic-ra.xml 文書型定義の詳細については、『WebLogic J2EE コネクタアーキテクチャ』を参照してください。
すべてのリソースアダプタクラスとデプロイメント記述子をステージングディレクトリに配置すると、次のような jar コマンドを使用してリソースアダプタ JAR ファイルを作成できます。
```
jar cvf jar-file.jar -C staging-dir .
```
このコマンドによって作成された jar ファイルは、WebLogic Server にデプロイすることも、またはアプリケーション JAR ファイルにパッケージ化することもできます。

-C staging-dir オプションを指定すると、jar コマンドはディレクトリを staging-dir に変更します。これにより、JAR ファイルに記録されるディレクトリパスがリソースアダプタのステージングディレクトリを基準にした相対パスとなります。

注意: WebLogic Server へのデプロイメントに対するリソースアダプタの作成および既存のリソースアダプタの変更については、 WebLogic Server J2EE アプリケーションの開発のリソースアダプタの作成 : 主な手順を参照してください。

エンタープライズアプリケーションのパッケージ化

エンタープライズアーカイブには、関連するアプリケーションの一部である EJB および Web モジュールが格納されます。EJB および Web モジュールは .ear 拡張子を持つ別の JAR ファイルに一緒にまとめられます。

.ear ファイルの META-INF サブディレクトリには、.ear ファイルにパッケージ化さたモジュールを識別する application.xml デプロイメント記述子が含まれています。application.xml ファイルの DTD は、http://java.sun.com/j2ee/dtds/application_1_2.dtd で提供されています。エンタープライズアーカイブには WebLogic 固有のデプロイメント記述子は必要ありません。

次に、Pet Sotre サンプルの application.xml ファイルを示します。

<?xml version="1.0"  encoding="UTF-8"?>

<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD 
J2EE Application 1.2//EN'
'http://java.sun.com/j2ee/dtds/application_1_2.dtd'>

<application>
  <display-name>estore</display-name>
  <description>Application description</description>
  <module>
    <web>
      <web-uri>petStore.war</web-uri>
      <context-root>estore</context-root>
    </web>
  </module>
  <module>
    <ejb>petStore_EJB.jar</ejb>
  </module>
  <security-role>
    <description>the gold customer role</description>
    <role-name>gold_customer</role-name>
  </security-role>
  <security-role>
    <description>the customer role</description>
    <role-name>customer</role-name>
  </security-role>
</application>

エンタープライズアプリケーションをパッケージ化する前に、クライアントアプリケーションのパッケージ化を読み、WebLogic Server がエンタープライズアプリケーションクラスをどのようにロードするかを理解してください。

エンタープライズアプリケーションをステージングおよびパッケージ化するには、次の手順に従います。

一時的なステージングディレクトリを作成します。
Web アーカイブ（.war ファイル）と EJB アーカイブ（.jar ファイル）をステージングディレクトリにコピーします。
ステージングディレクトリに META-INF サブディレクトリを作成します。
シェル環境を設定します。
Windows NT の場合は、setEnv.cmd コマンドを実行します。このコマンドは BEA_HOME\config\domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。

UNIX の場合は、setEnv.sh コマンドを実行します。このコマンドは BEA_HOME/config/domain ディレクトリにあります。BEA_HOME は WebLogic Server がインストールされているディレクトリで、domain はドメインの名前です。
META-INF サブディレクトリに application.xml デプロイメント記述子を自動的に生成する次のコマンドを実行します。
```
java weblogic.ant.taskdefs.ear.DDInit staging-dir
```
staging-dir は、ステージングディレクトリです。

デプロイメント記述子を生成する Java ベースユーティリティ DDInit の詳細については、デプロイメント記述子の自動生成を参照してください。

または、META-INF ディレクトリに application.xml ファイルを手動で作成することもできます。このファイルの要素の詳細については、 application.xml デプロイメント記述子の要素を参照してください。
次のような jar コマンドを使用して、アプリケーションのエンタープライズアーカイブ（.ear ファイル）を作成します。
```
jar cvf application.ear -C staging-dir .
```

作成された .ear ファイルは、Administration Console または weblogic.deploy コマンドラインユーティリティを使用してデプロイできます。

クライアントアプリケーションのパッケージ化

WebLogic Server アプリケーションには必要ありませんが、J2EE にはクライアントアプリケーションをデプロイするための仕様が定義されています。 J2EE クライアントアプリケーションモジュールは、JAR ファイルにパッケージ化されます。この JAR ファイルには、クライアント JVM (Java Virtual Machine) で実行される Java クラスと、EJB (Enterprise JavaBeans) およびクライアントによって使用されるその他の WebLogic Server リソースを記述するデプロイメント記述子が収められています。

Sun が提供する事実上の標準デプロイメント記述子である application-client.xml が J2EE クライアントに対しても使用され、補足デプロイメント記述子には、その他のWebLogic 固有のデプロイメント情報が収められます。

注意: これらのデプロイメント記述子については、 application.xml デプロイメント記述子の要素の application.xml デプロイメント記述子の要素を参照してください。

EAR ファイルのクライアントアプリケーションの実行

アプリケーションの配布を簡略化するため、J2EE では、 WebLogic Server が使用するサーバサイドモジュールに合わせて、EAR ファイルにクライアントサイドコンポーネントを入れる方式を定義しています。こうすることにより、サーバサイド、クライアントサイド両方のコンポーネントを1 つにまとめて配布できます。

クライアント JVM は、アプリケーション用に作成した Java クラスと、WebLogic Server クラスなどアプリケーションが依存する Java クラスのすべての位置を把握できなければなりません。クライアントアプリケーションをステージングするには、クライアントで必要なすべてのファイルを 1 つのディレクトリにコピーし、そのディレクトリを 1 つの JAR ファイルにまとめます。クライアントアプリケーションディレクトリの最上位には、アプリケーションを起動するバッチファイルまたはスクリプトを置くことができます。 classes サブディレクトリを作成して、Java クラスと JAR ファイルを格納し、起動スクリプト内のクライアントの Class-Path にそれらを追加します。 Java Runtime Environment (JRE) と Java クライアントアプリケーションのパッケージ化もできます。

注意: クライアントコンポーネント JAR 内で Class-Path manifest エントリを使用すると、J2EE 標準ではこれにまだ対応していないため、移植できません。

JAR ファイル manifest の Main-Class 属性は、クライアントアプリケーションのメインクラスを定義します。クライアントでは、通常、java:/comp/env JNDI ルックアップを使用して、Main-Class 属性を実行します。デプロイする側として、JNDI ルックアップエントリの実行時の値を与え、クライアントの Main-Class 属性を呼び出す前にコンポーネントローカルな JNDI ツリーを設定する必要があります。クライアントのデプロイメント記述子に JNDI ルックアップツリーを定義します（クライアントアプリケーションのデプロイメント記述子の要素を参照してください）。

weblogic.ClientDeployer を使用して、J2EE EAR ファイルからクライアントサイド JAR ファイルを展開し、デプロイ可能な JAR ファイルを作成します。weblogic.ClientDeployer クラスは、以下の構文を使って Java コマンドラインで実行します。

java weblogic.ClientDeployer ear-file client

ear-file 引数は、展開ディレクトリ（すなわち、拡張子が .ear となっている Java アーカイブファイル）で、その中に 1 つ以上のクライアントアプリケーション JAR ファイルが入っています。

例:

java weblogic.ClientDeployer app.ear myclient

app.ear は、myclient.jar にパッケージ化された J2EE クライアントを含む EAR ファイル。

EAR ファイルからクライアントサイド JAR ファイルを展開したら、その weblogic.j2eeclient.Main ユーティリティを使って、クライアントサイドアプリケーションをブートストラップし、以下のように WebLogic Server を指すようにします。

java weblogic.j2eeclient.Main クライアントのjar URL [アプリケーション変数]

例:

java weblogic.j2eeclient.Main helloWorld.jar t3://localhost:7001 Greetings

J2EE クライアントアプリケーションのデプロイメントに関する考慮事項

以下に、J2EE クライアントアプリケーションのデプロイメントに関する考慮事項を挙げます。

WebLogic Server クライアントデプロイメントファイルは、.runtime.xml というサフィックスを使って命名すること。
weblogic.ClientDeployer クラスは、client.properties ファイルを生成し、それをクライアント JAR ファイルへ追加する処理を担当します。別プログラムの weblogic.j2eeclient.Main がローカルクライアント JNDI コンテキストを作成し、クライアント manifest ファイルで指定されているエントリポイントからクライアントを実行します。
注意: weblogic.ClientDeployer を使って J2EE クライアントアプリケーションを実行するには、（weblogic.jar ファイル内にある）weblogic.j2eeclient.Main クラスが必要です。
application-client.xml ファイルに記述のあるリソースが、以下に示したタイプの 1 つである場合、weblogic.j2eeclient.Main クラスは、サーバ上のグローバルな JNDI ツリーからそれを取り出して、java:comp/env/ にバインドしようとします。
```
ejb-ref
```
```
javax.jms.QueueConnectionFactory
```
```
javax.jms.TopicConnectionFactory
```
```
javax.mail.Session
```
```
javax.sql.DataSource
```
weblogic.j2eeclient.Main クラスは、UserTransaction を java:comp/UserTransaction にバインドします。
その他のクライアント環境は、 weblogic.ClientDeployer クラスが作成した client.properties ファイルから java:comp/env/ にバインドされます。weblogic.j2eeclient.Main クラスは、バインドするものがなかったり、バインド処理が完了しない場合にエラーメッセージを出します。
アプリケーションデプロイメントファイル内の <res-auth> タグは、現在は無視され、Application として入力する必要があります。フォームベースの認証は、現在サポートしていません。

Apache ant を使った J2EE アプリケーションのパッケージ化

この節では、Apache の ant という拡張可能な Java ベースのツールを使った J2EE アプリケーションのビルドとパッケージ化について説明します。 ant は、make コマンドに似ていますが、Java アプリケーションのビルド用に設計されたものです。 ant ライブラリは WebLogic Server に同梱されており、カスタマがそのまま簡単に Java アプリケーションをビルドできるようになっています。

開発者は、eXtensible Markup Language (XML) を使って Ant ビルドスクリプトを作成します。XML タグで、ビルド対象、対象の依存関係、対象をビルドするために実行する処理を定義します。

ant で可能なことについての詳しい説明は、以下を参照してください。 http://jakarta.apache.org/ant/manual/index.html

Java ソースファイルのコンパイル

ant では、Java ソースファイルのコンパイルのため、javac タスクを用意しています。以下の例では、カレントディレクトリにあるすべての Java ファイルをコンパイルして classes ディレクトリに入れます。

<target name=”compile”>

  <javac srcdir=”.” destdir=”classes”/>

</target>

javac タスクに関連する全オプションについては、Apache ant のオンラインドキュメントを参照してください。

WebLogic Server コンパイラの実行

ant からの任意の Java プログラムの実行は、カスタマイズした ant タスクを作成するか、そのまま java タスクを使ってプログラムを実行することにより可能です。ejbc または rmic などのタスクは、以下に示すように java タスクを使って実行できます。

コードリスト 3-1 WebLogic Server コンパイラの実行

<java classname="weblogic.ejbc" fork="yes" failonerror="yes">

  <sysproperty key="weblogic.home" value="${WL_HOME}"/>

     <arg line="-compiler java ${dist}/std_ejb_basic_containerManaged.jar

     ${APPLICATIONS}/ejb_basic_containerManaged.jar"/>

  <classpath>

     <pathelement path="${CLASSPATH}"/>

  </classpath>

</java>

上記のサンプルでは、fork システムコールを使って ejbc を実行するための Java プロセスを作成します。サンプルでは、system プロパティを提供して weblogic.home を定義し、arg タグを使ってコマンドライン変数を用意します。呼び出される Java プロセスのためのクラスパスは、classpath タグを使って指定します。

J2EE デプロイメントユニットのパッケージ化

すでに説明したように、 J2EE アプリケーションはコンポーネントのタイプによってそれぞれのファイル拡張子をを持った JAR ファイルとしてパッケージ化されます。

EJB は、JAR ファイルとしてパッケージ化される。
Web アプリケーションは、WAR ファイルとしてパッケージ化される。
リソースアダプタは、RARファイルとしてパッケージ化される。
エンタープライズアプリケーションは、EAR ファイルとしてパッケージ化される。

これらのコンポーネントは、J2EE 仕様に従って構成されます。標準の XML デプロイメント記述子に加えて、コンポーネントは WebLogic Server 固有の XML デプロイメント記述子を使用してパッケージ化することもできます。

ant は、こうした JAR ファイルの構築をより簡単に行えるタスクを提供します。JAR コマンドの機能の他に、ant はEAR ファイルおよび WAR ファイルをビルドするための特別なタスクを提供します。ant を使用して、JAR アーカイブ内に示されるパス名を指定できます。このパス名は、ファイルシステム内の元のパスとは異なってもかまいません。この機能は、（J2EE がアーカイブ内の実際の位置を指定している）デプロイメント記述子のパッケージ化に便利です。この場合、ソースツリー内の位置と対応しない場合もあります。 ZipFileSet コマンドと関連情報については、Apache ant のオンラインドキュメントを参照してください。

以下のリストを参照してください。

コードリスト 3-2 WAR タスクのサンプル

<war warfile="cookie.war" webxml="web.xml" manifest="manifest.txt">

   <zipfileset dir="." prefix="WEB-INF" includes="weblogic.xml"/>

   <zipfileset dir="." prefix="images" includes="*.gif,*.jpg"/>

   <classes dir="classes" includes="**/CookieCounter.class"/>

   <fileset dir="." includes="*.jsp,*.html">

   </fileset>

</war>

J2EE デプロイメントユニットをパッケージ化するには、以下のステップに従う必要があります。

webxml パラメータを使って、標準 XML デプロイメント記述子を指定します。
war タスクは、 XML デプロイメント記述子をWAR アーカイブ WEB-INF/web.xml 内の標準名に自動的にマップします。
Apache ant は manifest パラメータを使って指定したmanifest ファイルを標準名 META-INF/MANIFEST.MF で格納します。
Apache ant の ZipFileSet コマンドを使って、 WEB-INF ディレクトリに格納すべきファイルのセットを定義します（この場合は、WebLogic Server 固有のデプロイメント記述子 weblogic.xml のみ)。
2 つめの ZipFileSet コマンドでは、 images ディレクトリにあるすべてのイメージをパッケージ化します。
classes タグは、WEB-INF/classes ディレクトリにあるサーブレットクラスをパッケージ化します。
最後に、カレントディレクトリにあるすべての .jsp ファイルおよび .html ファイルをアーカイブに追加します。

WAR ファイルの構造にそのまま対応するディレクトリ内のファイルをステージングし、JAR ファイルをそのディレクトリから作成することにより、同じ結果が得られます。ant の JAR タスクの特別な機能を使用して、特定のディレクトリ構造にファイルをコピーしなくても済みます。

以下のサンプルでは、 Web アプリケーションと EJB を 1 つずつビルドし、それらを 1 つの EAR ファイルにまとめてパッケージ化します。

コードリスト 3-3 パッケージ化のサンプル

<project name="app" default="app.ear">

	   <property name="wlhome" value="/bea/wlserver6.1"/>

   <property name="srcdir" value="/bea/myproject/src"/>

   <property name="appdir" value="/bea/myproject/config/mydomain/applications"/>

   <target name="timer.war">

       <mkdir dir="classes"/>

       <javac srcdir="${srcdir}" destdir="classes" includes="myapp/j2ee/timer/*.java"/>

        <war warfile="timer.war" webxml="timer/web.xml" manifest="timer/manifest.txt">

          <classes dir="classes" includes="**/TimerServlet.class"/>

       </war>

   </target>

   <target name="trader.jar">

   <mkdir dir="classes"/>

   <javac srcdir="${srcdir}" destdir="classes" includes="myapp/j2ee/trader/*.java"/>

   <jar jarfile="trader0.jar" manifest="trader/manifest.txt">

      <zipfileset dir="trader" prefix="META-INF" includes="*ejb-jar.xml"/>

      <fileset dir="classes" includes="**/Trade*.class"/>

      </jar>

      <ejbc source="trader0.jar" target="trader.jar"/>

   </target>

   <target name="app.ear" depends="trader.jar, timer.war">

      <jar jarfile="app.ear">

         <zipfileset dir="." prefix="META-INF" includes="application.xml"/>

         <fileset dir="." includes="trader.jar, timer.war"/>

      </jar>

   </target>

   <target name="deploy" depends="app.ear">

      <copy file="app.ear" todir="${appdir}/>

   </target>

</project>

ant の実行

BEA は、server/bin ディレクトリに ant 実行の簡単なスクリプトを用意しています。デフォルトでは、ant は build.xml ビルドファイルをロードしますが、 -f フラグを使って、これを変更できます。以下のコマンドを使って、上記のビルドスクリプトを使用してアプリケーションのビルドとデプロイメンとを行います。

ant -f yourbuildscript.xml

コンポーネント間のクラス参照の解決

アプリケーションでは、エンタープライズ Bean、サーブレットと JavaServer Pages、スタートアップクラス、ユーティリティクラス、およびサードパーティ製パッケージなど、さまざまな Java クラスを使用します。WebLogic Server では、個別のクラスローダにアプリケーションをデプロイして、独立を維持し、動的な再デプロイメントとアンデプロイメントを容易にします。このため、各コンポーネントが各クラスに個別にアクセスできるようにアプリケーションのクラスをパッケージ化する必要があります。場合によっては、一連のクラスを複数のアプリケーションまたはコンポーネントに格納する必要があります。この節では、アプリケーションを正常にステージングするために、WebLogic Server で複数のクラスローダを使用する方法について説明します。

クラスローダの概要

クラスローダは、要求されたクラスを見つけて Java 仮想マシン（JVM）にロードする Java クラスです。クラスローダは、クラスパスに示されたディレクトリまたは JAR ファイル内のファイルを検索して、参照を解決します。ほとんどの Java プログラムには 1 つのクラスローダがあります。JVM の起動時に作成されるシステムクラスローダです。WebLogic Server は、アプリケーションをデプロイするときに追加のクラスローダを作成します。これらのクラスローダはアプリケーションをアンデプロイするために破棄することができます。これにより、WebLogic Server では、変更されたアプリケーションをサーバを再起動せずに再デプロイできます。

クラスローダは階層的です。WebLogic Server の起動時に、Java システムクラスローダはアクティブになり、その後に WebLogic Server が作成するすべてのクラスローダの親になります。クラスローダは自身のクラスパスを検索する前に、常に親クラスローダにクラスを要求しますが、親クラスローダは子のクラスローダにはアクセスしません。検索はクラスローダの階層で上方向にのみ行われるためです。従って、子のクラスローダは兄弟クラスローダのクラスパス上にあるクラスを見つけることもできません。

検索プロトコルでは、重複したクラスが Java で処理される方法についても決められています。Java システムクラスパスで見つかったクラスは、子のクラスローダのクラスパスにある同じ名前のクラスよりも常に優先されます。このため、WebLogic Server を起動する前に、Java システムクラスパスにアプリケーションのクラスを配置することは避けてください。起動時に作成されたクラスローダは破棄されないため、このクラスローダに含まれるクラスは WebLogic Server を再起動しないと再デプロイできません。

アプリケーションのクラスローダ

WebLogic Server では、アプリケーションをデプロイするときに、EJB 用と Web アプリケーション用の 2 つの新しいクラスローダを作成します。EJB クラスローダは Java システムクラスローダの子、Web アプリケーションクラスローダは EJB クラスローダの子です。このため、Web アプリケーションのクラスは EJB クラスを見つけられますが、EJB クラスは Web アプリケーションのクラスを見つけられません。このクラスローダの階層には、サーブレットと JSP が EJB の実装クラスに直接アクセスできるという効果的な作用もあります。EJB のクライアントと実装は同じ JVM にあるため、WebLogic Server は中間の RMI クラスを無視できます。

アプリケーションにエンタープライズ Bean を使用するサーブレットと JSP が含まれる場合は、次の手順に従います。

サーブレットと JSP を .war ファイルにパッケージ化します。
エンタープライズ Bean を EJB .jar ファイルにパッケージ化します。
.war ファイルと .jar ファイルを .ear ファイルにパッケージ化します。
.ear ファイルをデプロイします。

.war ファイルと .jar ファイルは別々にデプロイできますが、.ear ファイルに一緒にデプロイすると、サーブレットと JSP が EJB クラスを見つけられるようにクラスローダが配置されます。.war ファイルと .ejb ファイルを別々にデプロイすると、WebLogic Server はそれぞれのファイルごとに兄弟のクラスローダを作成します。つまり、.war ファイルには EJB ホームおよびリモートインタフェースを含める必要があります。EJB クライアントと実装クラスが異なる JVM にある場合と同じように、WebLogic Server は EJB 呼び出しで RMI のスタブクラスとスケルトンクラスを使用する必要があります。

リソースアダプタクラス

リソースアダプタ固有のクラスが WebLogic Server のシステムクラスパスにないことを確認してください。Web ドキュメントでリソースアダプタ固有のクラス（たとえば、EJB または Web アプリケーション）を使用する必要がある場合、これらのクラスを対応する各アーカイブファイル（たとえば、サーブレットの場合は .war の \classes ディレクトリ、EJB の場合は .jar の \classes ディレクトリ）にまとめる必要があります。

J2EE アプリケーションでの PreferWebInfClasses の使い方

デフォルトでは、Web アプリケーションのクラスローダは、Javasoft のドキュメントに記載されている標準の委託モデルに従います。サーブレット仕様では、 Web アプリケーションは WAR ファイルからそのクラス定義を取得する必要があります。

この要件をサポートするため、Web アプリケーションのクラスローダは、WAR ファイルを検索してからそのクラスの親クラスローダに問い合わせるよう、BEA はWeb アプリケーション用に委託モデルを変更するスイッチを組み込みました。このスイッチは PreferWebInfClasses といい、WebAppComponentMBean 上にあります。このスイッチの設定は、WebLogic Server コンソールで行えます。

PreferWebInfClassesを false （デフォルト）に設定すると、Web アプリケーションのクラスローダは標準の委託モデルに従います。true に設定すると、WAR ファイル内のクラス定義を検索してから、親にクラス定義を問い合わせます。

このスイッチは、仕様要件を満たします。しかし、親クラスローダ内にあるバージョンではなく、Web アプリケーションクラスローダ内にロードされている同じクラスの別のバージョンになる可能性があります。開発者がこの 2 つのインスタンスを切り分けるよう注意していないと、ClassCastExceptions を招きます。このため、標準の委託モデルを使用するよう、BEA はこの設定のデフォルトを false にしてあります。

共通ユーティリティクラスとサードパーティクラスのパッケージ化

複数のアプリケーションで使用するユーティリティクラスを作成または取得する場合、それらのクラスを各アプリケーションに一緒にパッケージ化する必要があります。代わりに、WebLogic Server を実行するスクリプト内の java コマンドを編集して、Java システムクラスパスにそれらのクラスを追加できます。ただし、ユーティリティクラスを変更し、そのクラスが Java システムクラスパスにある場合は、ユーティリティクラスを変更した後に WebLogic Server を再起動する必要があります。

起動時に WebLogic Server が使用するクラスは Java システムクラスパスに存在しなければなりません。たとえば、接続プールに使用する JDBC ドライバは WebLogic Server の起動時にクラスパス内になければなりません。また、Java システムクラスパス内のクラスを変更する必要がある場合、またはクラスパスを変更した場合は、クラスまたはクラスパスを変更した後に WebLogic Server を再起動する必要があります。

スタートアップクラスとアプリケーションの対話の処理

スタートアップクラスはユーザが作成するクラスで、WebLogic Server の起動時に実行されます。スタートアップクラスは Java システムクラスパスによって検索されるため、サーバを起動する前にシステムクラスパス内に配置しておく必要があります。また、スタートアップクラスで必要なクラスは、すべてシステムクラスパスに含まれていなければなりません。

スタートアップクラスがアプリケーションクラス（EJB インタフェースなど）を使用する場合、それらのクラスも WebLogic Server の起動クラスパスに追加しなければなりません。このため、それらのクラスは後でサーバを再起動しないと変更が反映されません。

アプリケーションオブジェクトを使用するスタートアップクラスは、WebLogic Server でそのアプリケーションのデプロイメントが完了するまで、アプリケーションオブジェクトへのアクセスの試行を待つ必要があります。たとえば、スタートアップクラスが EJB を使用する場合、ホームおよびリモートインタフェースをシステムクラスパス内に配置し、WebLogic Server が EJB アプリケーションのデプロイメントを完了するまで、スタートアップクラスで EJB インスタンスを作成しないようにしておく必要があります。

Pet Store アプリケーションにはスタートアップクラスがあります。その中で、スタートアップクラスがアプリケーションのデプロイメントの完了を待つために使用できるメソッドが示されています。com.bea.estore.startup.StartBrowser スタートアップクラスでは、Pet Store アプリケーションにアクセスする初期 URL が表示されます。また、Windows 上では、その URL と共にブラウザが起動します。StartBrowser は、アプリケーションがデプロイされてサーバが接続要求の受け入れを開始するまで、while ループを実行します。

このクラスから抜粋した次の部分は、この動作を示しています。

while (loop) {
　    try {
　      socket = new Socket(host, new Integer(port).intValue());
　      socket.close();
　
　      //ブラウザを起動
　      String[] cmdArray = new String[3];
　      cmdArray[0] = "beaexec.exe";
　      cmdArray[1] = "-target:browser";
　      cmdArray[2] = "-command:\"http://"+host+":"+port+"\"";
　      try {
　        Process p = Runtime.getRuntime().exec(cmdArray);
　        p.getInputStream().close();
　        p.getOutputStream().close();
　        p.getErrorStream().close();
　      }
　      catch (IOException ioe) {
　      }
　      loop = false;
　    } catch (Exception e) {
　      try {
　        Thread.sleep(SLEEPTIME); // 500 ミリ秒ごとに試行
　      } catch (InterruptedException ie) {}
　      finally {
　        try {
　          socket.close();
　        } catch (Exception se) {}
　      }
　    }
　  }

システムがソケットの作成に失敗した場合、または BEA で提供する beaexec.exe ユーティリティがエラーを返す場合は、500 ミリ秒間スリープしてからループが繰り返されます。スタートアップクラスで EJB インスタンスを作成する必要がある場合、EJB インスタンスを作成するメソッドが正常に実行されるまでループするという同様の手法を使用できます。