TM| ドキュメントのダウンロード | サイト マップ | Glossary | TM|
|
|||
| BEA ホーム | 製品 | dev2dev | support | askBEA |
|
TM |
|
|||||||
 |
| e-docs > WebLogic ServerTM > WebLogic エンタープライズ JavaBeans プログラマーズ ガイド > WebLogic Server への EJB のデプロイ |
|
WebLogic エンタープライズ JavaBeans プログラマーズ ガイド
|
以下の各節では、WebLogic Server の起動時、または 動作中の WebLogic Server に EJB をデプロイする手順について説明します。
WebLogic Server の 1 つまたは複数のインスタンスに EJB を作成、変更、およびデプロイできます。EJB デプロイメントを設定し、EJB 参照を実際のリソース ファクトリ、ロール、およびサーバ上で使用可能な他の EJB に割り当てるには、XML デプロイメント記述子ファイルを編集します。
WebLogic Server 起動時の EJB のデプロイメント
WebLogic Server の起動時に EJB を自動的にデプロイするには、次の手順に従います。
リモート呼び出しによって複数の異なったアプリケーションに EJB をデプロイするとき、EJB を呼び出すために call-by-reference は使用できません。代わりに、pass-by-value を使用します。一般に、相互に対話するコンポーネントは call-by-reference を使用できるように同じアプリケーション内に配置する必要があります。デフォルトでは、同じサーバから呼び出された EJB メソッドは引数を参照で渡します。パラメータはコピーされないので、これによってメソッド呼び出しのパフォーマンスが向上します。EJB がリモートで (同じサーバ以外から) 呼び出される場合は、pass-by-value にする必要があります。
動作中の WebLogic Server への EJB のデプロイ
EJB JAR ファイルまたはデプロイメント ディレクトリを wlserver/config/mydomain/applications ディレクトリに配置すると EJB を直ちにデプロイできますが、デプロイ済みの EJB を変更した場合は、その変更を有効にするために EJB を再デプロイする必要があります。
WebLogic Server を再起動できない場合に備えて、自動デプロイメントという方法が用意されています。自動デプロイメントでは、更新された EJB のみを管理サーバにデプロイし、ドメインの管理対象サーバには EJB をデプロイしません。自動デプロイメント機能を使用すると、次の作業を行うことができます。
コマンド ラインまたは Administration Console から EJB をデプロイする場合でも、更新する場合でも、自動デプロイメント機能を利用することになります。以降の節では、自動デプロイメントの概念と手順について説明します。
EJB JAR ファイルまたはデプロイメント ディレクトリをデプロイする場合は、デプロイメント ユニットの名前を指定します。この名前を使用すると、後で EJB をアンデプロイしたり更新したりする場合に、EJB デプロイメントを簡単に参照できます。
EJB をデプロイする場合は、WebLogic Server が、JAR ファイルまたはデプロイメント ディレクトリのパスおよびファイル名と一致するデプロイメント名を明示的に割り当てます。この名前を使用すると、サーバが起動した後に Bean をアンデプロイまたは更新できます。
注意: EJB デプロイメント名は、サーバが再起動されるまで、WebLogic Server 内でアクティブなままです。EJB をアンデプロイしても、関連付けられたデプロイメント名は削除されません。Bean をデプロイするために後でその名前を使う場合があるからです。
デプロイされていない EJB JAR ファイルまたはデプロイメント ディレクトリを WebLogic Server をデプロイするには、次の手順に従います。
.jar ファイルに未コンパイルのクラスおよびインタフェースが含まれる場合に、クラスタ内の 1 つのサーバ インスタンスに EJB をデプロイまたは再デプロイする (固定デプロイメントと呼ばれる) と、問題が生じることが知られています。
未コンパイルの EJB は、デプロイ中にクラスタ内の各サーバ インスタンスにコピーされますが、この EJB はデプロイ先のサーバ インスタンス上でしかコンパイルされません。その結果、EJB の対象とされなかったクラスタのサーバ インスタンスには、コンパイルの過程で生成される、EJB の呼び出しに必要なクラスが存在しません。別のサーバ インスタンスのクライアントが固定 EJB を呼び出そうとしても失敗し、RMI レイヤでアサーション エラーが送出されます。
クラスタ内の 1 つのサーバ インスタンスに EJB をデプロイまたは再デプロイする場合は、生成されたクラスが、クラスタ内のすべてのノードに利用可能なすべてのサーバ インスタンスに必ずコピーされるように、デプロイ前にその EJB を ejbc でコンパイルしてください。
固定デプロイメントの詳細については、「WebLogic クラスタの設定」を参照してください。
EJB のアンデプロイメントは、すべてのクライアントにその EJB を使用できなくする効果的な方法です。EJB をアンデプロイすると、直ちに、指定した EJB の実装クラスがサーバ内で使用不可になったことが示されます。WebLogic Server は実装クラスを自動的に削除して、その Bean を使用していたすべてのクライアントに UndeploymentException を伝播します。
アンデプロイメントによって、指定した EJB のパブリック インタフェース クラスがすべて自動的に削除されるわけではありません。これらのクラスへの参照がすべて解放されるまで、パブリック インタフェースで参照されるホーム インタフェース、リモート インタフェース、およびすべてのサポート クラスの実装は、サーバ内に残ります。パブリック クラスは、参照が解放された時点で、通常の Java ガベージ コレクション ルーチンによって削除できます。
同様に、EJB をアンデプロイしても、ejb.jar ファイルまたはデプロイメント ディレクトリに関連付けられたデプロイメント名は削除されません。デプロイメント名は、後で EJB を更新することができるようにサーバ内に残ります。
デプロイ済み EJB をアンデプロイするには次の手順に従います。
WebLogic Server Administration Console を使用する場合
EJB をアンデプロイしても、WebLogic Server から EJB デプロイメント名は削除されません。EJB は、アンデプロイされた後に変更された場合を除いて、サーバ セッションが持続している間、アンデプロイされたままです。サーバを再起動するまで、deploy 引数でデプロイメント名を再利用することはできません。次の項で説明するように、デプロイメントの更新にそのデプロイメント名を再使用できます。
デプロイ済みの EJB のクラスを変更した場合、以下のいずれかを行うまで、変更は WebLogic Server で反映されません。
EJB デプロイメントを再デプロイすると、EJB プロバイダがデプロイ済みの EJB のクラスを変更し、再コンパイルしてから、動作中のサーバのクラスを「更新」できるようになります。
EJB デプロイメントを再デプロイすると、直ちに、ロード済みの EJB のクラスがサーバ内で使用不可になったことが示され、EJB のクラスローダと関連クラスが削除されます。 同時に、改版された EJB クラスをロードして維持する新規の EJB クラスローダが作成されます。
クライアントが次に EJB への参照を必要とする場合、クライアントの EJB メソッドの呼び出しでは、変更済みの EJB クラスが使用されます。
スタンドアロンまたはアプリケーションの一部を構成する EJB を再デプロイするには、weblogic.Deployer ツールまたは Administration Console を使用します。
weblogic.Deployer を使用して再デプロイするには、次の手順に従います。
WebLogic Server Administration Console を使用して再デプロイするには、次の手順に従います。
コンパイル済みの EJB 2.0 JAR または EAR ファイルを作成するには、次の手順に従います。
以前のバージョンの WebLogic Server からコンパイル済みの EJB を作成するには、次の手順に従います。
mydomain¥applications¥DefaultWebApp ディレクトリ
注意: 以前のバージョンの EJB は、EJB コンテナにデプロイする前に、すべて手動で再コンパイルする必要があります。これをしない場合、WebLogic Server が自動的にそれらの EJB を再コンパイルし、エラーがあればコンパイラから出力が別のログ ファイルに送られます。
(再パッケージ化、再コンパイル、または既存の ejb.jar ファイルにコピーして) applications 内のコンパイル済み ejb.jar ファイルの内容を変更した場合、WebLogic Server は、自動デプロイメント機能を利用して、ejb.jar を自動的に再デプロイしようとします。
WebLogic Server コンテナを使用すると、未コンパイルの EJB クラスおよびインタフェースが入った JAR ファイルも自動的にデプロイすることができます。未コンパイル EJB ファイルはコンパイル済みファイルと同じ構造を持っていますが、次の点で異なります。
JAR ファイル内の .java または .class ファイルは、Java パッケージ階層と同じサブディレクトリにパッケージ化する必要があります。また、すべての ejb.jar ファイルと同じように、適切な XML デプロイメント ファイルを META-INF ディレクトリの最上位に置く必要があります。
未コンパイルのクラスをパッケージ化したら、JAR を wlserver¥config¥mydomain¥applications ディレクトリにコピーするだけです。WebLogic Server は、必要に応じて、javac を自動的に実行して (またはユーザがコンパイラを指定して)、.java ファイルをコンパイルし、weblogic.ejbc を実行してコンテナ クラスを生成します。コンパイルされたクラスは、mydomain¥applications¥DefaultWebApp の新しい JAR ファイルにコピーされ、EJB コンテナにデプロイされます。
(再パッケージ化するか、JAR ファイルにコピーするかして) applications ディレクトリ内の未コンパイル ejb.jar を変更した場合、WebLogic Server は、変更された JAR を同じ手順で自動的に再コンパイルして再デプロイします。
コンテナ管理による関係を持つ EJB は、同じ JAR ファイルでデプロイする必要があります。 コンテナ管理による関係の詳細については、コンテナ管理による関係を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
