| Oracle® Fusion Middleware Oracle WebLogic Serverデプロイメントのプログラミング 11g リリース1 (10.3.6) B60989-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Serverデプロイメントのプログラミング 11g リリース1 (10.3.6) B60989-04 |
|
前 |
次 |
このドキュメントでは、構成という用語はWebLogic Serverインスタンスへのデプロイメントのためにアプリケーションまたはデプロイ可能なリソースを準備するプロセスのことを指します。アプリケーションのほとんどの構成情報は、アプリケーションのデプロイメント記述子に指定されます。これらの記述子の一部の要素は外部オブジェクトを参照し、サーバー・ベンダーに応じて特別な処理が必要なものもあります。WebLogic Serverでは、記述子を拡張したWebLogic Server固有のデプロイメント記述子を使用します。標準の記述子とWebLogic Server記述子とのマッピングはDDBeansおよびDConfigBeansを介して管理されます。
次の項では、デプロイメントのためにWebLogicデプロイメントAPIを使用してアプリケーションを構成する方法について説明します。
この項では、デプロイするアプリケーションの構成を行うために、デプロイメント・ツールで行う必要がある基本的な手順について説明します。
アプリケーション評価: アプリケーション・ファイルを検査および評価して、アプリケーションの構造および組み込まれている標準の記述子の内容を判断します。
WebLogicDeploymentManagerを取得することでデプロイメント・セッションを初期化します。「アプリケーション評価」を参照してください。
WebLogicJ2eeApplicationObjectまたはWebLogicDeployableObjectを作成して、エンタープライズ・アプリケーション(Enterprise Application: EAR)またはスタンドアロン・モジュール(WAR、EAR、RARまたはCAR)のJava EE構成を表します。オブジェクトはEARの場合、子オブジェクトが生成されます。http://java.sun.com/j2ee/tools/deployment/index.jspのJava EEデプロイメントAPI標準(JSR-88)およびデプロイ可能なオブジェクトの作成を参照してください。
フロントエンド構成: アプリケーションに組み込まれている情報に基づいて構成情報を作成します。この情報には、WebLogic Server記述子、デフォルト、ユーザー定義によるデプロイメント・プランなどがあります。
WebLogicDeploymentConfigurationオブジェクトを作成して、アプリケーションのWebLogic Server構成を表現します。これは、このオブジェクトのデプロイメント・プランを作成するための最初のステップです。「デプロイメント構成」を参照してください。
既存のデプロイメント・プランを利用できる場合は、そのデプロイメント・プランから既存のWebLogic Server構成の値を復元します。「フロントエンド構成の実行」を参照してください。
デプロイメント構成: ユーザー入力および選択したWebLogic Serverターゲットに基づいて、個別のWebLogic Server構成の値を変更します。
デプロイメント・ツールには、ユーザー入力および選択するWebLogic Serverターゲットに基づいて、個々のWebLogic Server構成の値を変更する機能が必要です。「デプロイメント構成のカスタマイズ」を参照してください。
デプロイメントの準備: 最終的なデプロイメント・プランを生成し、クライアント側でアプリケーションを事前に検証します。
デプロイメント・ツールには、変更したWebLogic Server構成情報を、新しいデプロイメント・プランまたは既存のデプロイメント・プランの変数定義に保存する機能が必要です。
次の項では、構成情報の種類、表現方法、およびJava EE記述子とWebLogic Server記述子の関係に関する基本情報について説明します。
アプリケーションのJava EE構成では、アプリケーションの基本的なセマンティクスと実行時の動作、またアプリケーションの機能に必要な外部リソースを定義します。この構成情報は、アプリケーションに関連付けられた標準Java EEデプロイメント記述子ファイルに格納されます。表3-1は、この記述子ファイルの一覧です。
表3-1 標準Java EEデプロイメント記述子
| アプリケーションまたはスタンドアロン・モジュール | Java EE記述子 |
|---|---|
|
エンタープライズ・アプリケーション |
|
|
Webアプリケーション |
|
|
Enterprise JavaBeans |
|
|
リソース・アダプタ |
|
|
クライアント・アプリケーション・アーカイブ |
|
あらゆるアプリケーション構成セッションには、完全で有効なJava EEデプロイメント記述子の入力が必須です。
Java EE構成でアプリケーションの基本的な動作が判断するため、Java EE記述子は通常アプリケーションのデプロイメント・フェーズ中にのみ定義され、アプリケーションが後に別の環境にデプロイされる際にも変更されません。たとえば、テスト用ドメインまたは本番用ドメインにアプリケーションをデプロイする場合、アプリケーションの動作は(したがってそのJava EE構成も)そのアプリケーションをデプロイメント・ドメインにデプロイしたときと同じ状態のままです。詳細は、「フロントエンド構成の実行」を参照してください。
WebLogic Server記述子では、拡張機能、外部リソースの解決、およびアプリケーション・セマンティクスに関連するチューニングが規定されます。この記述子はアプリケーションに組み込まれていても、組み込まれていなくても構いません。アプリケーションのWebLogic Server構成では、以下のことができます。
外部リソース名をJava EEデプロイメント記述子のリソースの定義にバインドして、特定のWebLogic Serverドメインでアプリケーションが機能できるようにする
アプリケーション・コンテナのチューニング・パラメータを定義する
Java EEアプリケーションおよびスタンドアロン・モジュールに拡張機能を提供する
WebLogic Server構成の属性および値は、WebLogic Serverデプロイメント記述子ファイルに格納されます。これについて、表3-2に示します。
表3-2 WebLogic Serverデプロイメント記述子
| アプリケーションまたはスタンドアロン・モジュール | WebLogic Server記述子 |
|---|---|
|
エンタープライズ・アプリケーション |
|
|
Webアプリケーション |
|
|
Enterprise JavaBeans |
|
|
リソース・アダプタ |
|
|
クライアントのアーカイブ |
|
様々なWebLogic Serverドメインでアプリケーションに対して色々な種類の外部リソースや多様なレベルのサービスが提供されるため、アプリケーションのWebLogic Server構成は、通常そのアプリケーションが新しい環境にデプロイされる際に変更されます。たとえば、本番ステージング・ドメインにはデプロイメント・ドメインとは異なるデータベース・ベンダーが採用されていたり、より使用に適したメモリーが用意されていたりする場合があります。そのため、アプリケーションをデプロイメントからステージング・ドメインに移動する際には、新しいデータベース接続や利用可能なメモリーを使用できるようにするために、アプリケーションのWebLogic Server記述子の値を更新する必要があります。
デプロイメント構成ツールの主な仕事は、アプリケーションのWebLogic Server構成を、選択したWebLogicターゲットに対して確実に有効なものにすることです。
Java EEデプロイメント記述子と利用可能なすべてのWebLogic Server記述子の両方が、アプリケーションの構成プロセスへの入力として使用されます。デプロイメントAPIを使用して、Java EE構成およびWebLogic Server構成の両方をJavaオブジェクトとして表現します。
アプリケーションのJava EE構成は、EARの場合WebLogicJ2eeApplicationObjectを、スタンドアロン・モジュールの場合WeblogicDeployableObjectを作成することにより取得されます。(WebLogicJ2eeApplicationObjectには、EARにある個々のモジュールを表現する複数のDeployableObjectインスタンスが含まれています)。
各WebLogicJ2eeApplicationObjectまたはWeblogicDeployableObjectにはDDBeanRootがあり、これが対応するJava EEデプロイメント記述子ファイルを表しています。EARおよびモジュールのJava EE記述子のプロパティは、DDBeanRootの下にある1つ以上のDDBeanオブジェクトで表されます。DDBeanコンポーネントには、デプロイメント記述子の個々のプロパティ、値、およびネストされた記述子要素のそれぞれにアクセスする標準のゲッター・メソッドが備わっています。
DDBeansはjavax.enterprise.deploy.modelパッケージに記述されています。このオブジェクトでは標準デプロイメント記述子の要素に対する一般的なインタフェースが提供されますが、標準記述子の基本的な形式に従う任意のXMLファイルへのアクセス用にXPathベースのメカニズムとしても使用できます。そのようなファイルの例には、WebLogic Server記述子やWebサービス記述子があります。
記述子のDDBean表現はDDBeansのツリー構造で、専用のDDBeanが使用され、ツリーのルートには、DDBeanRootがあります。DDBeansには、それらが表現する記述子要素の要素名、ID属性、ルートおよびテキストに対するアクセサが用意されています。
アプリケーションのDDBeanはモデル・プラグインによって導入されます。モデル・プラグインはjavax.enterprise.deploy.modelのツール・プロバイダ実装です。アプリケーションは、DeployableObjectインタフェースで表現されます。このインタフェースのWebLogic Server実装はpublicクラスweblogic.deploy.api.model.WebLogicDeployableObjectです。WebLogic Serverベースのデプロイメント・ツールで、アプリケーションのWebLogicDeployableObjectオブジェクトのインスタンスをcreateDeployableObjectファクトリ・メソッドを介して取得します。その結果、アプリケーションのDDBeanツリーが作成されて、アプリケーションに組み込まれたJava EE記述子の要素により内容が設定されます。アプリケーションがEARの場合、複数のWebLogicDeployableObjectオブジェクトが作成されます。ルートのWebLogicDeployableObjectはWebLogicJ2eeApplicationObjectとして拡張され、これがEARモジュールを表します。その子WebLogicDeployableObjectインスタンス群がアプリケーションに含まれるモジュール群(WAR、EJB、RAR、CARなど)を表します。
Java EE記述子とWebLogic Server記述子は外部リソースの構成において直接的に関連しています。Java EE記述子にはアプリケーションが機能するために必要なリソースの種類を定義しますが、実際に使用するリソース名は特定しません。WebLogic Server記述子の方で、そのJava EE記述子内のリソース定義名をターゲット・ドメインの実際のリソース名にバインドします。
外部リソースのバインドは、構成プロセスに必須のプロセスです。リソースをターゲット・ドメインにバインドすることで、確実にアプリケーションでリソースを見つけ、正しくデプロイできるようになります。
Java EE記述子とWebLogic Server記述子は、WebLogic Serverのチューニング・パラメータの構成においても間接的に関連しています。標準Java EE記述子の要素に対してWebLogic Serverでチューニング・パラメータを設定する必要はありませんが、個々の記述子ファイルの存在によって、どのチューニング・パラメータがアプリケーションの構成時に重要なのかが分かります。たとえば、ejb.xml記述子にWebLogic Server EJBコンテナのチューニングに関連する要素が含まれていなくても、ejb.xmlがJava EE構成にあることで、デプロイメントの前にチューニング・プロパティを構成できることが分かります。
DConfigBean (構成Bean)は、サーバーの構成要件をデプロイメント・ツールに伝達するために使われるオブジェクトです。また、デプロイメント・プランの作成には主にここからの情報が使用されます。構成BeanはJava Beanであり、このBeanのプロパティは参照できます。また、それらには基本的なプロパティ編集機能もあります。
DConfigBeanは、組み込まれたWebLogic Server記述子とデプロイメント・プランの情報、およびIDEデプロイメント・ツールからの入力によって作成されます。
DConfigBeanは、アプリケーションの依存関係に関連付けられるすべてのWebLogic記述子要素に対して作成できます。記述子はアプリケーションで利用可能なリソースが記述されるエンティティで、サーバーで指定されるJNDI名で表されます。
記述子は、構成セッションの設定時に型付きのBeanツリーとしてメモリーに解析されます。DConfigBean実装クラスはWebLogic Server記述子Beanに委任します。依存関係にあるプロパティ(リソース参照など)を持つBeanのみがDConfigBeanを持ちます。記述子のルートには常にDConfigBeanRootがあります。
Beanのプロパティへのアクセサでは、構成が必要な要素については子DConfigBeanが、構成不要の要素については記述子Beanが返されます。プロパティへのアクセサでは記述子Beanからのデータが返されます。
Beanのプロパティを変更すると、プランがオーバーライドされます。既存の記述子に対するプランのオーバーライドは、変数の割当によって処理されます。関連するWebLogic Server記述子がアプリケーションにない場合、記述子が自動的に作成されて外部プラン・ディレクトリに配置されます。外部デプロイメント記述子の場合、記述子が直接変更されます。組み込まれた記述子はディスク上では変更されません。
アプリケーション評価では、アプリケーション用のデプロイメント・マネージャおよびデプロイ可能なオブジェクト・コンテナを取得します。次の手順に従います。
デプロイメント・ファクトリ・クラスを名前にweblogic.deployer.spi.factories.internal.DeploymentFactoryImplを指定して取得します。
ファクトリ・クラスをjavax.enterprise.deploy.spi.DeploymentFactoryManagerインスタンスに登録します。
次に例を示します。
Class WlsFactoryClass = Class.forname("weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl");
DeploymentFactory myDeploymentFactory =
(DeploymentFactory) WlsFactoryClass.newInstance();
DeploymentFactoryManager.getInstance().registerDeploymentFactory(myDeploymentFactory);
次の項では、デプロイメント・マネージャを取得する方法について説明します。
WebLogic Serverにはjavax.enterprise.deploy.spi.DeploymentManagerの実装が1つ用意されていますが、この実装はファクトリから取得したクラスの初期化時に指定するURIによって動作が異なります。そのためWebLogic Serverには、基本的なデプロイメント・マネージャが2種類あります。
切断されたデプロイメント・マネージャには、WebLogic Serverインスタンスへの接続がありません。リモート・クライアント・マシン上のアプリケーションを構成するために、切断されたデプロイメント・マネージャを使用します。それをデプロイメント操作を実行するために使用することはできません。(たとえば、デプロイメント・ツールは切断されたデプロイメント・マネージャを使用してアプリケーションを配布することはできません。)
接続されたデプロイメント・マネージャには、WebLogic Serverドメイン用の管理サーバーへの接続があり、デプロイメント・ツールにより、アプリケーションの構成およびデプロイの両方に使用できます。
接続されたデプロイメント・マネージャは、管理サーバーのローカルに存在するか、あるいは管理サーバーに接続されたリモート・マシンで動作しているかによってさらに分類されます。ローカルまたはリモートの分類によって、ファイル参照が管理サーバーに対してローカルとして扱われるかリモートとして扱われるかが決まります。
表3-3に、デプロイメント・マネージャのタイプをまとめます。
WebLogicDeploymentFactoryから取得した各DeploymentManagerでは、WebLogic Server拡張がサポートされます。デプロイメント・ツールを作成する場合、デプロイメント・ファクトリのインスタンスにある適切なメソッドを呼び出し、必要な種類のデプロイメント・マネージャについて記述されているweblogic.deployer.spi.factories.WebLogicDeploymentFactoryに定義された文字列定数を指定して、特定の種類のデプロイメント・マネージャを取得します。接続されたデプロイメント・マネージャで管理サーバーへの接続を取得するためには、有効なサーバーのURIと資格証明をメソッドに渡す必要があります。
表3-4に、各種のデプロイメント・マネージャを取得する際に使用するメソッド・シグネチャと定数についてまとめます。
表3-4 WebLogic Serverデプロイメント・マネージャを取得するためのURI
| デプロイメント・マネージャの種類 | メソッド | 引数 |
|---|---|---|
|
切断された |
|
|
|
接続された、ローカル |
|
以下の要素からなる
|
|
接続された、リモート |
|
以下の要素からなる
|
例 3-1のサンプル・コードに、切断されたデプロイメント・マネージャを取得する方法について示します。
例 3-1 切断されたデプロイメント・マネージャの取得
Class WlsFactoryClass = Class.forname("weblogic.deployer.spi.factories.internal.DeploymentFactoryImpl");
DeploymentFactory myDeploymentFactory = (DeploymentFactory) WlsFactoryClass.newInstance();
DeploymentFactoryManager.getInstance().registerDeploymentFactory(myDeploymentFactory);
WebLogicDeploymentManager myDisconnectedManager =
(WebLogicDeploymentManager)myDeploymentFactory.getDisconnectedDeploymentManager(WebLogicDeploymentFactory.LOCAL_DM_URI);
デプロイメント・ファクトリには、接続されたデプロイメント・マネージャ作成のためのURI引数の形成に役立つcreateUri()というヘルパー・メソッドがあります。たとえば、切断されたリモート・デプロイメント・マネージャを作成するには、コードの最終行を次のように置き換えます。
(WebLogicDeploymentManager)myDeploymentFactory.getDeploymentManager(myDeploymentFactory.createUri(WebLogicDeploymentFactory.REMOTE_DM_URI, "localhost", "7001", "weblogic", "weblogic"));
SessionHelperヘルパー・クラスでは、例 3-1にあるように手動でデプロイメント・ファクトリを作成および登録せずに、簡単にデプロイメント・マネージャを取得できるようにするための便利なメソッドが複数提供されています。切断されたデプロイメント・マネージャを取得するために必要なSessionHelperのコードは以下の1行のみです。
DeploymentManager myDisconnectedManager = SessionHelper.getDisconnectedDeploymentManager();
SessionHelperを使用して接続されたデプロイメント・マネージャを取得することもできます。以下に例を示します。
DeploymentManager myConnectedManager = SessionHelper.getDeploymentManager("adminhost", "7001", "weblogic", "weblogic"));
このメソッドでは、管理サーバー(adminhost)へのリモート接続を前提にしています。SessionHelpeの詳細は、「Javadocs」を参照してください。
以下の節では、デプロイ可能なオブジェクトを作成する方法について説明します。このオブジェクトは、デプロイメント・ツールでアプリケーションをデプロイするのに使用されるコンテナになります。デプロイメント・マネージャの取得によって構成セッションを初期化したら、デプロイメント・ツールで使用するデプロイ可能なオブジェクトを次のいずれかの方法で作成します。
直接的なアプローチでは、modelパッケージのWebLogicDeployableObjectクラスを次のように使用します。
WebLogicDeployableObject myDeployableObject = WebLogicDeployableObject.createWebLogicDeployableObject("myAppFileName");
デプロイ可能なオブジェクトが作成されたら、アプリケーションのデプロイメント構成を作成できます。
SessionHelperヘルパー・クラスには、デプロイ可能なオブジェクトを取得するための便利なメソッドが用意されています。デプロイ可能なオブジェクトの取得に必要なSessionHelperコードを以下に示します。
SessionHelper.setApplicationRoot(root); WebLogicDeployableObject myDeployableObject = SessionHelper.getDeployableObject();
getDeployableObject()呼出しには何もアプリケーションが指定されていません。SessionHelperでは、setApplicationRoot()で指定されたルート・ディレクトリのアプリケーションが使用されます。アプリケーションのルート・ディレクトリを指定すれば、SessionHelperで他の処理(明示的なディスパッチ・ファイルの場所やデプロイメント・プランの場所の指定など)を実行できます。
また、以下のようにsetApplicationメソッドを使用してアプリケーションのファイル名を指定することもできます。
SessionHelper.setApplication(AppFileName);
このメソッドを使用すると、ディレクトリ構造に関係なく引続きSessionHelperを使用できます。getDeployableObjectメソッドは、指定されたアプリケーションを返します。
フロントエンド構成では、WebLogicDeploymentPlanの作成と、WebLogicDeploymentPlanおよび関連するBeanツリーへの構成情報の指定を行います。
フロントエンド構成フェーズは、次の2つの論理的処理から構成されます。
デプロイメント・プランからデプロイメント構成に情報をロードします。デプロイメント構成がまだ存在しない場合は、WebLogicDeploymentConfigurationオブジェクトを作成して、アプリケーションのWebLogic Server構成を表現します。これは、このオブジェクトのデプロイメント・プランを作成するプロセスの最初のステップです。
既存のデプロイメント・プランから既存のWebLogic Server構成の値を復元します。
デプロイメント・ツールには、以下の機能が必要です。
デプロイメント構成からの情報の展開。デプロイメント構成はデプロイメント・マネージャで構成情報を取得するために使用されるアクティブなJavaオブジェクトです。デプロイメント・プランは、アプリケーションを操作せずに変更できるように、アプリケーションの外部に置かれています。
デプロイメント・プランはアプリケーション環境の構成が格納されるXMLドキュメントで、アプリケーションのフロントエンド構成と呼ばれることもあります。デプロイメント・プランには、以下のような目的があります。
アプリケーションのロジックからアプリケーションの環境固有の詳細情報を分離します。
すべてのアプリケーションに必須なわけではありませんただし、デプロイメント・プランは一般的にアプリケーションのデプロイ先とする各環境に存在します。
アプリケーションにどのようなモジュールがあるかなど、アプリケーションの構造を記述します。
開発者や管理者がアプリケーションのアーカイブを変更せずにアプリケーションの構成を更新できるようにします。
環境固有の記述子オーバーライド情報(チューニング可能)を格納します。デプロイメント・プランを変更して、アプリケーションのチューニング可能な変数に環境固有の値を指定できます。
アプリケーション用のサーバー構成はjavax.enterprise.deploy.spi.DeploymentConfigurationインタフェースにカプセル化されます。DeploymentConfigurationはデプロイメント・プランのオブジェクト表現を提供します。DeploymentConfigurationはDeploymentManager.createConfigurationメソッドを介してDeployableObjectに関連付けられます。DeploymentConfigurationオブジェクトを作成すると、すべてのWebLogic Server記述子に記述された、構成可能な要素とチューニング可能な要素を表すDConfigBeanのツリーが利用できるようになります。アプリケーションにWebLogic Server記述子がない場合、DConfigBeanツリーは利用可能なデフォルト値を使用して作成されます。デフォルト値のないバインドのプロパティは指定されないままになります。
デプロイメント・ツールを作成する場合、アプリケーションが配布される前にDConfigBeanツリーを完全に設定する必要があります。
次のコードは、DConfigBeanの設定方法の例です。
例 3-2 DConfigBeanを設定するためのサンプル・コード
public class DeploymentSession {
DeploymentManager dm;
DeployableObject dObject = null;
DeploymentConfiguration dConfig = null;
Map beanMap = new HashMap();
.
.
.
// Assumes app is a Web app.
public void initializeConfig(File app) throws Throwable {
/**
* Init the wrapper for the DDBeans for this module. This example assumes
* it is using the WLS implementation of the model api.
*/
dObject= WebLogicDeployableObject.createDeployableObject(app);
//Get basic configuration for the module
dConfig = dm.createConfiguration(dObject);
/**
* At this point the DeployableObject is populated. Populate the
* DeploymentConfigurationbased on its content.
* We first ask the DeployableObject for its root.
*/
DDBeanRoot root = dObject.getDDBeanRoot();
/**
* The root DDBean is used to start the process of identifying the
* necessary DConfigBeans for configuring this module.
*/
System.out.println("Looking up DCB for "+root.getXpath());
DConfigBeanRoot rootConfig = dConfig.getDConfigBeanRoot(root);
collectConfigBeans(root, rootConfig);
/**
* The DeploymentConfiguration is now initialized, although not necessarily
* completely setup.
*/
FileOutputStream fos = new FileOutputStream("test.xml");
dConfig.save(fos);
}
// bean and dcb are a related DDBean and DConfigBean.
private void collectConfigBeans(DDBean bean, DConfigBean dcb) throws Throwable{
DConfigBean configBean;
DDBean[] beans;
if (dcb == null) return;
/**
* Maintain some sort of mapping between DDBeans and DConfigBeans
* for later processing.
*/
beanMap.put(bean,dcb);
/**
* The config bean advertises xpaths into the web.xml descriptor it
* needs to know about.
*/
String[] xpaths = dcb.getXpaths();
if (xpaths == null) return;
/**
* For each xpath get the associated DDBean and collect its associated
* DConfigBeans. Continue this recursively until we have all DDBeans and
* DConfigBeans collected.
*/
for (int i=0; i<xpaths.length; i++) {
beans = bean.getChildBean(xpaths[i]);
for (int j=0; j<beans.length; j++) {
/**
* Init the DConfigBean associated with each DDBean
*/
System.out.println("Looking up DCB for "+beans[j].getXpath());
configBean = dcb.getDConfigBean(beans[j]);
collectConfigBeans(beans[j], configBean);
}
}
このサンプルでは単にDDBeanツリーを反復処理して、インスタンス化される各DDBeanのDConfigBeanをリクエストしています。
DeploymentConfigurationオブジェクトはDeploymentConfiguration.save()を使用するとデプロイメント・プランとして永続化できます。デプロイメント・ツールを使用すると、デプロイメント・プランをゼロから作成する代わりに、保存されているデプロイメント・プランをDeploymentConfigurationオブジェクトにインポートすることもできます。DeploymentConfiguration.restore()を使用するとこの機能を実現できます。これにより、アプリケーションのデプロイメント・プランのリポジトリを保持して、そこに様々な環境に適用できる様々なデプロイメント・プランを格納するという手法がサポートされます。
同様に、以前の構成セッションからリポジトリに保存された部分的なプランをつなぎ合わせてDeploymentConfigurationを構成することもできます。部分的なプランは、DConfigBeanツリーのmodule-rootにマップされます。DeploymentConfiguration.saveDConfigBean()およびDeploymentConfiguration.restoreDConfigBean()を使用すると、この機能を実現できます。
アプリケーションのWebLogic Server記述子の解析は、DeploymentConfigurationが作成されるときに自動的に行われます。記述子は最新のスキーマに準拠しているのが理想的です。WebLogic Server 8.1以前のDTDに基づく記述子が含まれる古いアプリケーションの場合、変換が実行されます。古い記述子はサポートされてはいますが、デプロイメント・プランを使用して変更することはできません。そのため、あらゆるDOCTYPE宣言をネーム・スペースの参照に変換する必要があります。また、要素に固有の変換も必ず実施します。
SessionHelper.initializeConfigurationでは、アプリケーション内のすべての標準記述子およびWebLogic Server記述子が処理されます。
initializeConfigurationを呼び出す前に、SessionHelper.setPlan()メソッドを使用して既存のデプロイメント・プランをアプリケーションに関連付けるように指定できます。プランが設定されている場合、DeploymentConfiguration.restore()メソッドでデプロイメント・プランを読み取ることもできます。さらに、プランを設定するとDeploymentConfiguration.initializeConfiguration()メソッドで自動的に構成情報を復元することも可能です。
SessionHelperクラスで構成セッションを開始する場合、以下に例示するようにデプロイメント・プランの情報をdeploymentConfigurationに入力して簡単に開始できます。
DeploymentManager dm = SessionHelper.getDisconnectedDeploymentManager();
SessionHelper helper = SessionHelper.getInstance(dm);
// specify location of archive
helper.setApplication(app);
// specify location of existing deployment plan
helper.setPlan(plan);
// initialize the configuration session
helper.initializeConfiguration();
DeploymentConfiguration dc = helper.getConfiguration();
上記のコードでは、デプロイメント構成およびそれに関連付けられるWebLogicDDBeanTreeが生成されます。
構成の検証は、ほとんどの場合、アプリケーションの記述子が処理される際に行われる記述子の解析中に発生します。検証では、記述子が有効なXMLドキュメントかどうか、また記述子が各自のスキーマに準拠しているかどうかが確認されます。
デプロイメント構成のカスタマイズ・フェーズでは、ユーザー入力と選択したWebLogic Serverターゲットに基づいて、個々のWebLogic Server構成の値を変更します。
この段階の構成は、記述子またはアプリケーションに関連付けられた既存のプランとほとんど同様です。DConfigBeanはJava Beanとして設計されていて内部を参照できるため、ツールでその内容を意味のある形式で提示できます。DConfigBeanのプロパティは、そのほとんどが構成可能です。また、主要なプロパティ(一意なもの)も公開されます。セッターについては、安全に変更できるプロパティに関するもののみが公開されます。一般的に、アプリケーションの動作が記述されるプロパティは変更できません。すべてのプロパティには記述子スキーマで定義されている型が指定されています。
プロパティのゲッターからは下位要素のDConfigBean、DConfigBeanの配列、記述子Bean、記述子Beanの配列、単純な値(プリミティブおよびjava.langオブジェクト)、または単純な値の配列が返されます。記述子Beanでは、変更可能だがDConfigBeanの機能を必要としない記述子要素が表現されます。たとえば、記述子Beanに直接関連している標準記述子要素はありません。構成の編集は、プロパティのセッターを呼び出すことにより行われます。
Java JSR-88のDConfigBeanクラスを使用すると、ツールからgetDConfigBean(DDBean)メソッドまたは内部参照を利用してBeanにアクセスできます。アプリケーションのDeployableObject内のDDBeanに基づいて標準記述子を提示し、各DDBeanの構成(そのDConfigBean)に直接アクセスするツールでは、前者のアプローチが便利です。このアプローチでは、アプリケーションに指定されている可能性のある必須リソース要件の構成が提供されます。内部参照でのアプローチでは、ツールでアプリケーション全体の構成を提示できますが、必須のリソース要件が強調されるとは限りません。
内部参照は両方のアプローチにおいて記述子のプロパティを提示または変更するために必要になります。異なるのはツールでの情報の提示方法です。
標準記述子の内容
WebLogic Server記述子の内容
構成情報を変更するシステムには、変更を要求するためのユーザー・インタフェースを含める必要があります。例 3-3を参照してください。
例 3-3 構成情報を変更するためのサンプル・コード
.
.
.
// Introspect the DConfigBean tree and ask for input on properties with setters
private void processBean(DConfigBean dcb) throws Exception {
if (dcb instanceof DConfigBeanRoot) {
System.out.println("Processing configuration for descriptor: "+dcb.getDDBean().getRoot().getFilename());
}
// get property descriptor for the bean
BeanInfo info =
Introspector.getBeanInfo(dcb.getClass(),Introspector.USE_ALL_BEANINFO);
PropertyDescriptor[] props = info.getPropertyDescriptors();
String bean = info.getBeanDescriptor().getDisplayName();
PropertyDescriptor prop;
for (int i=0;i<props.length;i++) {
prop = props[i];
// only allow primitives to be updated
Method getter = prop.getReadMethod();
if (isPrimitive(getter.getReturnType())) // see isPrimitive method below
{
writeProperty(dcb,prop,bean); //see writeProperty method below
}
// recurse on child properties
Object child = getter.invoke(dcb,new Object[]{});
if (child == null) continue;
// traversable if child is a DConfigBean.
Class cc = child.getClass();
if (!isPrimitive(cc)) {
if (cc.isArray()) {
Object[] cl = (Object[])child;
for (int j=0;j<cl.length;j++) {
if (cl[j] instanceof DConfigBean) processBean((DConfigBean) cl[j]);
}
} else {
if (child instanceof DConfigBean) processBean((DConfigBean) child);
}
}
}
}
// if the property has a setter then invoke it with user input
private void writeProperty(DConfigBean dcb, PropertyDescriptor prop, String bean)
throws Exception {
Method getter = prop.getReadMethod();
Method setter = prop.getWriteMethod();
if (setter != null) {
PropertyEditor pe =
PropertyEditorManager.findEditor(prop.getPropertyType());
if (pe == null &&
String[].class.isAssignableFrom(getter.getReturnType())) pe =
new StringArrayEditor(); // see StringArrayEditor class below
if (pe != null) {
Object oldValue = getter.invoke(dcb,new Object[0]);
pe.setValue(oldValue);
String val =
getUserInput(bean,prop.getDisplayName(),pe.getAsText());
// see getUserInput method below
if (val == null || val.length() == 0) return;
pe.setAsText(val);
Object newValue = pe.getValue();
prop.getWriteMethod().invoke(dcb,new Object[]{newValue});
}
}
}
private String getUserInput(String element, String property, String curr) {
try {
System.out.println("Enter value for "+element+"."+property+". Current value is: "+curr);
return br.readLine();
} catch (IOException ioe) {
return null;
}
}
// Primitive means a java primitive or String object here
private boolean isPrimitive(Class cc) {
boolean prim = false;
if (cc.isPrimitive() || String.class.isAssignableFrom(cc)) prim = true;
if (!prim) {
// array of primitives?
if (cc.isArray()) {
Class ccc = cc.getComponentType();
if (ccc.isPrimitive() || String.class.isAssignableFrom(ccc)) prim = true;
}
}
return prim;
}
/**
* Custom editor for string arrays. Input text is converted into tokens using
* commas as delimiters
*/
private class StringArrayEditor extends PropertyEditorSupport {
String[] curr = null;
public StringArrayEditor() {super();}
// comma separated string
public String getAsText() {
if (curr == null) return null;
StringBuffer sb = new StringBuffer();
for (int i=0;i<curr.length;i++) {
sb.append(curr[i]);
sb.append(',');
}
if (curr.length > 0) sb.deleteCharAt(sb.length()-1);
return sb.toString();
}
public Object getValue() { return curr; }
public boolean isPaintable() { return false; }
public void setAsText(String text) {
if (text == null) curr = null;
StringTokenizer st = new StringTokenizer(text,",");
curr = new String[st.countTokens()];
for (int i=0;i<curr.length;i++) curr[i] = new String(st.nextToken());
}
public void setValue(Object value) {
if (value == null) {
curr = null;
} else {
String[] v = (String[])value; // let caller handle class cast issues
curr = new String[v.length];
for (int i=0;i<v.length;i++) curr[i] = new String(v[i]);
}
}
}
.
.
.
管理者またはユーザーが構成を変更できるあらゆるインタフェースでは、基礎的なユーザー・インタフェースの仕組みを超えてプロパティのセッターが使用されます。例 3-3を参照してください。
TargetはWebLogic Server、クラスタ、Webサーバー、仮想ホスト、およびJMSサーバーに関連付けられています。詳細は、「weblogic.deploy.api.spi.WebLogicTarget」および「WebLogicターゲット・タイプの問合せサポート」を参照してください。
WebLogic Serverでは、アプリケーションの名前をデプロイメント・ツールで指定します。アプリケーションに格納されているモジュールの名前は、関連付けられているアーカイブ名またはモジュールのルート・ディレクトリ名に基づきます。これらの名前は、アプリケーション用に構築された構成MBeansに保持されます。
Java EEデプロイメントでは、アプリケーションやその構成要素のモジュールに構成される名前について、TargetModuleIDオブジェクト以外には特に規定されていません。しかし、TargetModuleIDは、WebLogic Serverドメインに配布済みのアプリケーションにのみ存在するものです。そのため、配布する前にデプロイメント・ツールでアプリケーションおよびモジュールの名前を表現する必要があります。この表現は、最終的にアプリケーションが配布されるときにサーバーによって割り当てられる名前と一致している必要があります。
デプロイメント・ツール・プラグインでは、DeployableObjectクラスおよびJ2eeApplicationObjectクラスを通じて、アプリケーションの一覧を構築する必要があります。これらのクラスはそれぞれスタンドアロン・モジュールとEARを表します。各々のクラスがDDBeanRootオブジェクトと直接関係しています。名前が構成されていない配布を提示する場合、デプロイメント・ツールで配布の名前を作成する必要があります。配布されるのがFileオブジェクトである場合、その配布のファイル名を使用します。アーカイブが入力ストリームとして提供された場合、ルート・モジュールにはランダムな名前が使用されます。
デプロイメント準備フェーズでは、構成セッションから生成されたプランを保存します。これは、DeploymentConfiguration.save()メソッド(標準Java EEデプロイメントAPIのメソッド)によって行われます。この作業にSessionHelper.savePlan()メソッドを使用できます。この場合デプロイメント・プランの新しいコピーが、プラン・ディレクトリにあるすべての外部ドキュメントと共に保存されます。
DeploymentConfiguration.saveメソッドでは、デプロイメント・プランのスキーマに基づいてXMLファイルが作成されます。このファイルは、現在のDConfigBeanの集合のシリアライゼーション、およびすべての変数割当てと定義で構成されます。DConfigBeanツリーは常に外部の記述子として保存されます。この記述子は、アプリケーションのアーカイブまたは外部構成領域にまだ存在していない場合にのみ保存されます。すなわち、保存操作では既存の記述子は上書きされません。一方、DeploymentConfiguration.saveDConfigBeanメソッドではファイルが上書きされます。これは、構成に行ったすべての変更が失われるということではありません。変更は変数割当てを使用して処理されます。
前述したように、DeploymentConfiguration.restoreメソッドは前もって保存されたデプロイメント・プランに基づく構成Beanを作成するために使用されます(「フロントエンド構成の実行」を参照)。構成Beanはその全集合を復元することも、一部のみを復元することもできます。また、アプリケーション内の特定モジュールの構成Beanを保存したり復元したりすることも可能です。
構成セッション中には一時ファイルが作成されます。アーカイブは一時領域に展開され、セッション構成の完了後にのみ削除できます。セッションをクローズするために定義された標準のAPIはありません。WebLogicDeployableObjectとWebLogicDeploymentConfigurationに対してはclose()を使用します。SessionHelper.close()を使用するとセッションの完了後にクリーン・アップできます。セッションのクローズ後にクリーン・アップしないと、時間が経過すると一時ディレクトリのディスクがいっぱいになる可能性があります。
