WebLogic デプロイメント プログラマーズ ガイド
|
 |
 |
|
コンフィグレーションという用語は、WebLogic Server へのデプロイメントのためにアプリケーションまたはデプロイ可能なリソースを準備するプロセスのことをいいます。J2EE Deployment API 標準 (JSR-88) では、コンフィグレーション セッションとデプロイメントは違うものとされています。この 2 つは次のように区別されています。
次の節では、デプロイメントのために WebLogic デプロイメント API を使用してアプリケーションをコンフィグレーションする方法について説明します。
デプロイメントの各フェーズをもう一度確認します。コンフィグレーションと関係があるのは初めの 4 フェーズです。
1) アプリケーション評価 - このフェーズではアプリケーション ファイルを検査および評価して、アプリケーションの構造と組み込まれている標準の記述子の内容を判断します。
WebLogicDeploymentManager を取得することによりデプロイメント セッションを初期化する。「アプリケーション評価」を参照してください。WebLogicJ2eeApplicationObject または WebLogicDeployableObject を作成して、エンタープライズ アプリケーション (Enterprise Application : EAR) またはスタンドアロン モジュール (WAR、EAR、RAR、または CAR) の J2EE コンフィグレーションを表現する。EAR の場合、子オブジェクトが生成されます。J2EE Deployment API 標準 (JSR-88) に記述されているとおり、これはデプロイ可能なオブジェクトです。「デプロイ可能なオブジェクトを作成する」を参照してください。2) フロントエンド コンフィグレーション - このフェーズでは、アプリケーションに組み込まれている情報に基づいてコンフィグレーション情報を確立します。この情報には、WebLogic Server 記述子、デフォルト、ユーザ定義によるデプロイメント プランの形式があります。
WebLogicDeploymentConfiguration オブジェクトを作成して、アプリケーションの WebLogic Server コンフィグレーションを表現する。これにより開始されるプロセスで、このオブジェクトのこのデプロイメント用のデプロイメント プランが作成されます。「デプロイメント コンフィグレーション」を参照してください。3) デプロイメント コンフィグレーションのカスタマイズ - このフェーズでは、特定のデプロイメントについてユーザと会話して目的のコンフィグレーションを確立しチューニングします。これまでに解決されていなかった要素はこのフェーズで解決され、既存のコンフィグレーションや確立された環境固有の情報をオーバーライドすることもできます。
4) デプロイメント準備 - このフェーズでは、最終的なデプロイメント プランを生成し、クライアントサイドでアプリケーションをある程度検証します。
5) アプリケーションのデプロイメント - このフェーズでは、サーバサイド処理とアプリケーションの起動のために管理サーバにアプリケーションとプランを配布します (このフェーズはコンフィグレーションの一部ではありません。次章「デプロイメント工程の実行」を参照してください)。
初めの 4 フェーズでは、複数の手順をデプロイメント コンフィグレーション ツールで実行します。各フェーズのそれぞれの手順については下記に詳しく説明しますが、それらのタスクをコーディングし始める前に、コンフィグレーション情報の処理用に WebLogic で用意されているツールについて知っておく必要があります。
SessionHelper を使用すると、DeploymentManager へのアクセス、コンフィグレーション セッションの初期化、デプロイメント プランの保存、JMS サブモジュールの対象指定、アプリケーションの検査、といったもっとも一般的な操作パターンを簡単に実行できます。
WebLogic の J2EE Deployment API 実装に直接コーティングするツールでは SessionHelper を使用することをお勧めします。以下の各章とそれに属するトピックに SessionHelper に関する記述があります。それを参考に SessionHelper を実装で使用できます。SessionHelper の詳細については、「Javadocs」も参照してください。
コンフィグレーション セッション中には一時的なファイルが作成され、一時エリアにはアーカイブが展開されます。そうしたファイルはセッションの完了後にのみ削除できます。セッションをクローズするために定義された標準の API はありません。WebLogicDeployableObject と WebLogicDeploymentConfiguration に対しては close() メソッドが用意されています。SessionHelper.close() を使用するとセッションの完了後にすべてをクリーンアップできます。これらのメソッドの使用はツールのプログラマに任されています。使用しない場合、時間が経過すると一時ディレクトリがいっぱいになることがあります。
Deployer ツールで処理するタスクの 1 つに、正しくデプロイするためのアプリケーションのコンフィグレーションがあります。アプリケーションのほとんどのコンフィグレーション情報は、アプリケーションのデプロイメント記述子に指定されます。サポートされている記述子は下記にリストされています。これらの記述子の一部の要素では外部オブジェクトが参照され、サーバ固有の方法による処理が必要なものもあります。このような要素については、各種サーバ ベンダでさまざまな方法で管理することになります。WebLogic Server ではこれを管理するために記述子拡張を使用します。すなわち、WebLogic Server 固有のデプロイメント記述子が用意されています。一般にデプロイメント記述子の詳細については、「Overview of Deployment Configuration」で参照できます。標準の記述子と WebLogic Server 記述子とのマッピングは DDBean と DConfigBean を介して管理されます。これらについてはこのマニュアルで説明します。
アプリケーションの主要なコンフィグレーション情報は、以下のような異なる (ただし関連する) 2 つのカテゴリに分類されます。
アプリケーションの J2EE コンフィグレーションでは、アプリケーションの基本的なセマンティクスと実行時の動作、またアプリケーションの機能に必要な外部リソースを定義します。このコンフィグレーション情報は、アプリケーションに関連付けられた複数の標準 J2EE デプロイメント記述子ファイルに格納されます。表 3-1 に、この記述子ファイル群の一覧を示します。
あらゆるアプリケーション コンフィグレーション セッションには、完全で有効な J2EE デプロイメント記述子の入力が必須です。
J2EE コンフィグレーションでアプリケーションの基本的な動作が決まるため、J2EE 記述子は通常アプリケーションのデプロイメント フェーズ中にのみ定義され、アプリケーションが後に別の環境にデプロイされる際にも変更されません。たとえば、テスト用ドメインまたはプロダクション用ドメインにアプリケーションをデプロイする場合、アプリケーションの動作は (したがってその J2EE コンフィグレーションも) そのアプリケーションをデプロイメント ドメインにデプロイしたときと同じ状態のままです。詳細については、「フロントエンド コンフィグレーションの実行」を参照してください。
DDBean は javax.enterprise.deploy.model パッケージに記述されています。このオブジェクトでは標準デプロイメント記述子の要素に対する一般的なインタフェースが提供されますが、標準記述子の基本的な形式に従う任意の XML ファイルへのアクセス用に XPath ベースのメカニズムとしても使用できます。そのような XML ファイルの例には、WebLogic Server 記述子や Web サービス記述子があります。
記述子の DDBean 表現は DDBean のツリー構造で、専用の DDBean が使用され、ツリーのルートには DDBeanRoot があります。DDBean には、それが表現する記述子要素の要素名、ID 属性、ルート、およびテキストに対する、アクセサが用意されています。
アプリケーションの DDBean はモデル プラグインによって導入されます。モデル プラグインは javax.enterprise.deploy.model のツール プロバイダ実装です。アプリケーションは、DeployableObject インタフェースで表現されます。このインタフェースの WebLogic Server 実装は public クラス weblogic.deploy.api.model.WebLogicDeployableObject です。WebLogic Server ベースの Deployer ツールで、アプリケーションの WebLogicDeployableObject オブジェクトのインスタンスを createDeployableObject ファクトリ メソッドを介して取得します。その結果、アプリケーションの DDBean ツリーが作成されて、アプリケーションに組み込まれた J2EE 記述子の要素により内容が設定されます。アプリケーションが EAR の場合、複数の WebLogicDeployableObject オブジェクトが作成されます。ルートの WebLogicDeployableObject は WebLogicJ2eeApplicationObject として拡張され、これが EAR モジュールを表します。その子 WebLogicDeployableObject インスタンス群がアプリケーションに含まれるモジュール群を表します。それらが WAR、EJB、 RAR、および CAR に相当します。
J2EE デプロイメント記述子と利用可能なすべての WebLogic Server 記述子の両方が、アプリケーションのコンフィグレーション プロセスへの入力として使用されます。デプロイメント API を使用して、J2EE コンフィグレーションおよび WebLogic Server コンフィグレーションの両方を Java オブジェクトとして表現します。
アプリケーションの J2EE コンフィグレーションは、EAR の場合 WebLogicJ2eeApplicationObject を、スタンドアロン モジュールの場合 WeblogicDeployableObject を作成することにより取得されます (WebLogicJ2eeApplicationObject には、EAR にある個々のモジュールを表現する複数の DeployableObject インスタンスが含まれています)。
各 WebLogicJ2eeApplicationObject または WeblogicDeployableObject には DDBeanRoot があり、これが対応する J2EE デプロイメント記述子ファイルを表しています。EAR およびモジュールの J2EE 記述子のプロパティは、DDBeanRoot の下にある 1 つまたは複数の DDBean オブジェクトで表されます。DDBean コンポーネントには、デプロイメント記述子の個々のプロパティ、値、およびネストされた記述子要素のそれぞれにアクセスする標準のゲッター メソッドが備わっています。
J2EE 記述子と WebLogic Server 記述子は外部リソースのコンフィグレーションにおいて直接的に関連しています。J2EE 記述子にはアプリケーションが機能するために必要なリソースの種類を定義しますが、実際に使用するリソース名は特定しません。WebLogic Server 記述子の方で、その J2EE 記述子内のリソース定義名を対象ドメインの実際のリソース名にバインドします。
外部リソースのバインドは、コンフィグレーション プロセスに必須のプロセスです。リソースを対象ドメインにバインドすることで、確実にアプリケーションでリソースを見つけ、正しくデプロイできるようになります。
J2EE 記述子と WebLogic Server 記述子は、WebLogic Server のチューニング パラメータのコンフィグレーションにおいても間接的に関連しています。標準 J2EE 記述子の要素に対して WebLogic Server でチューニング パラメータを設定する必要はありませんが、個々の記述子ファイルの存在によって、どのチューニング パラメータがアプリケーションのコンフィグレーション時に重要なのかが分かります。たとえば、ejb.xml 記述子に WebLogic Server EJB コンテナのチューニングに関連する要素が含まれていなくても、ejb.xml が J2EE コンフィグレーションにあることで、デプロイメントの前にチューニング プロパティをコンフィグレーションできることが分かります。
WebLogic Server 記述子では、拡張機能、外部リソースの解決、およびアプリケーション セマンティクスに関連するチューニングが規定されます。この記述子はアプリケーションに組み込まれていても、組み込まれていなくても構いません。アプリケーションの WebLogic Server コンフィグレーションでは、以下のことができます。
WebLogic Server コンフィグレーションの属性および値は、WebLogic Server デプロイメント記述子ファイルに格納されます。これについて 表 3-2 に示します。
表 3-2 WebLogic Server デプロイメント記述子
さまざまな WebLogic Server ドメインでアプリケーションに対して色々な種類の外部リソースや多様なレベルのサービスが提供されるため、アプリケーションの WebLogic Server コンフィグレーションは、通常そのアプリケーションが新しい環境にデプロイされる際に変更されます。たとえば、プロダクション ステージング ドメインにはデプロイメント ドメインとは異なるデータベース ベンダが採用されていたり、より使用に適したメモリが用意されていたりする場合があります。そのため、アプリケーションをデプロイメントからステージング ドメインに移動する際には、新しいデータベース接続や利用可能なメモリを使用できるようにするために、アプリケーションの WebLogic Server 記述子の値を更新する必要があります。
デプロイメント コンフィグレーション ツールの主要な役割は、アプリケーションの WebLogic Server コンフィグレーションを、選択した WebLogic 対象に対して確実に有効なものにすることです。
DConfigBean (コンフィグレーション Bean) は、サーバのコンフィグレーション要件を Deployer ツールに伝達するために使われるオブジェクトです。また、デプロイメント プランの作成には主にここからの情報が使用されます。コンフィグレーション Bean は Java Bean であり、この Bean のプロパティは参照できます。また、この Bean には基本的なプロパティ編集機能もあります。
DConfigBean は、組み込まれた WebLogic Server 記述子とデプロイメント プランの情報、および IDE スタイルの Deployer ツールからの入力によって作成されます。
DConfigBean は、アプリケーションの依存関係に関連付けられるすべての WebLogic 記述子要素に対して作成できます。記述子はアプリケーションで利用可能なリソースが記述されるエンティティで、サーバで指定される JNDI 名で表されます。
記述子は、コンフィグレーション セッションの設定時に型付きの Bean ツリーとしてメモリに解析されます。DConfigBean 実装クラスは WebLogic Server 記述子 Bean に委託します。依存関係にあるプロパティ (たとえば、リソース参照) を持つ Bean のみが DConfigBean を持ちます。記述子のルートには常に DConfigBeanRoot があります。
Bean のプロパティへのアクセサでは、コンフィグレーションが必要な要素については子 DConfigBean が、コンフィグレーション不要の要素については記述子 Bean が返されます。プロパティへのアクセサでは記述子 Bean からのデータが返されます。
Bean のプロパティを変更すると、プランがオーバーライドされます。既存の記述子に対するプランのオーバーライドは、変数の割り当てによって処理されます。関連する WebLogic Server 記述子がアプリケーションにない場合、記述子が自動的に作成されて外部プラン ディレクトリに配置されます。外部デプロイメント記述子の場合、記述子が直接変更されます。組み込まれた記述子はディスク上では変更されません。
アプリケーション評価フェーズは、必要に応じて以下のようなデプロイメント処理から構成されます。
WebLogicDeploymentManager を取得することでデプロイメント セッションを初期化する。WebLogicJ2eeApplicationObject または WebLogicDeployableObject を作成して、エンタープライズ アプリケーション (Enterprise Application : EAR) またはスタンドアロン モジュール (WAR、EAR、RAR、CAR) の J2EE コンフィグレーションを表現する。EAR の場合、子オブジェクトが生成されます。これは、J2EE Deployment API 標準 (JSR-88) の記述にあるように、デプロイ可能なオブジェクトです。デプロイメント マネージャでは、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);
デプロイメント ファクトリを登録したら、そのファクトリと特定の URI を使用して、必要な機能を持つデプロイメント マネージャを取得します。この際、デプロイメント マネージャの種類を選択する必要があります。
WebLogic Server には javax.enterprise.deploy.spi.DeploymentManager の実装が 1 つ用意されていますが、この実装はファクトリから取得したクラスの初期化時に指定する URI によって動作が異なります。そのため WebLogic Server には、基本的なデプロイメント マネージャが 2 種類あります。
接続デプロイメント マネージャは、管理サーバのローカルに存在するか、あるいは管理サーバに接続されたリモート マシンで動作しているかによってさらに分類されます。ローカルまたはリモートの分類によって、ファイル参照が管理サーバに対してローカルとして扱われるかリモートとして扱われるかが決まります。
表 3-3 に、基本的なデプロイメント マネージャの種類のそれぞれについてまとめます。
表 3-3 WebLogic Server デプロイメント マネージャの使い方
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) へのリモート接続を前提にしています。SessionHelper の詳細については、「Javadocs」を参照してください。
アプリケーション評価における 2 番目の作業は、デプロイ可能なオブジェクトの作成です。デプロイ可能なオブジェクトとは、デプロイするアプリケーションのコンテナです。WebLogicDeploymentManager の取得によってコンフィグレーション セッションを初期化したら、デプロイ可能なオブジェクトを 2 つのうち 1 つの方法で作成できます。直接的なアプローチでは、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 メソッドでは、指定したアプリケーションがデプロイされると見なされます。
アプリケーション評価では、アプリケーション用のデプロイメント マネージャおよびデプロイ可能なオブジェクトを取得します。この作業により、以降のデプロイメント工程を行う準備が整います。
フロントエンド コンフィグレーション フェーズは、必要に応じて以下の 2 つの論理的処理から構成されます。
WebLogicDeploymentConfiguration オブジェクトを作成して、アプリケーションの WebLogic Server コンフィグレーションを表現する。これにより開始されるプロセスで、このオブジェクトのこのデプロイメント用にデプロイメント プランが作成されます。デプロイメント プランは XML ドキュメントで、アプリケーションのフロントエンド コンフィグレーションと呼ばれるアプリケーション環境のコンフィグレーションが格納されています。これによって、アプリケーションのロジックからアプリケーションの環境固有の詳細情報が分離されます。デプロイメント プランはすべてのアプリケーションに必須なわけではありません。デプロイメント プランが必要なのは、自動的に生成される一般的な値でない、記述子から提供される特定の属性がアプリケーションに必要な場合です。アプリケーションのデプロイ先とする各環境にデプロイメント プランを保持できます。
デプロイメント プランには以下のような複数の目的があります。
デプロイメント プランの情報はデプロイメント コンフィグレーションにロードしたり、そこから抽出したりできます。デプロイメント コンフィグレーションはアクティブな Java オブジェクトで、デプロイメント マネージャでコンフィグレーション情報を取得するために使用されます。デプロイメント プランは、アプリケーションを操作せずに変更できるように、アプリケーションの外部に置かれています。
アプリケーション用のサーバ コンフィグレーションは javax.enterprise.deploy.spi.DeploymentConfiguration インタフェースにカプセル化されます。DeploymentConfiguration はデプロイメント プランのオブジェクト表現と見なすこともできます。DeploymentConfiguration は DeploymentManager.createConfiguration メソッドを介して DeployableObject に関連付けられます。DeploymentConfiguration を作成すると、続いてすべての WebLogic Server 記述子に記述された、コンフィグレーション可能な要素とチューニング可能な要素を表す DConfigBean のツリーが利用できるようになります。アプリケーションに WebLogic Server 記述子がない場合、DConfigBean ツリーは利用可能なデフォルト値を使用して作成されます。デフォルト値のないバインディングのプロパティは指定されないままになります。
DConfigBean ツリーをアプリケーションの配布に使用する前に必ず完全に設定するのは、Deployer ツールの役割です。DConfigBean は以下のコンフィグレーション コードに示すようにゼロから設定できます。
public class DeploymentSession {
DeploymentManager dm;
DeployableObject dObject = null;
DeploymentConfiguration dConfig = null;
Map beanMap = new HashMap();
...
// app を web アプリケーションとする
public void initializeConfig(File app) throws Throwable {
/**
* このモジュールの DDBean のラッパーを初期化する。このサンプルでは
* model API の WLS 実装を使用する
*/
dObject= WebLogicDeployableObject.createDeployableObject(app);
//モジュールの基本的なコンフィグレーションを取得
dConfig = dm.createConfiguration(dObject);
/**
* この時点では DeployableObject が指定されている。
* DeploymentConfiguration をその内容に基づいて指定する。
* はじめに DeployableObject にそのルートを要求する
*/
DDBeanRoot root = dObject.getDDBeanRoot();
/**
* ルート DDBean を使用して、このモジュールのコンフィグレーションに
* 必要な DConfigBean 群を識別するプロセスを開始する
*/
System.out.println("Looking up DCB for "+root.getXpath());
DConfigBeanRoot rootConfig = dConfig.getDConfigBeanRoot(root);
collectConfigBeans(root, rootConfig);
/**
* これで DeploymentConfiguration が初期化されたが、
* 必ずしも完全に設定する必要はない
*/
FileOutputStream fos = new FileOutputStream("test.xml");
dConfig.save(fos);
}
// bean は DDBean、dcb は DConfigBean を表す
private void collectConfigBeans(DDBean bean, DConfigBean dcb) throws Throwable{
DConfigBean configBean;
DDBean[] beans;
if (dcb == null) return;
/**
* 以降のプロセスのために、DDBean と DConfigBean 間に
* 一種のマッピングを維持する
*/
beanMap.put(bean,dcb);
/**
* コンフィグレーション Bean から web.xml 記述子に
* 記述子で必要とする xpath を公開する
*/
String[] xpaths = dcb.getXpaths();
if (xpaths == null) return;
/**
* 各 xpath について関連する DDBean を取得し、
* それに関連する DConfigBean を収集する。すべての DDBean および
* 収集された DConfigBean が得られるまで、これを再帰的に繰り返す
*/
for (int i=0; i<xpaths.length; i++) {
beans = bean.getChildBean(xpaths[i]);
for (int j=0; j<beans.length; j++) {
/**
* 各 DDBean に関連付けられている DConfigBean を初期化する
*/
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() を使用するとデプロイメント プランとして永続化できます。Deployer ツールを使用すると、デプロイメント プランをゼロから作成する代わりに、保存されているデプロイメント プランを 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() メソッドで J2EE Deployment API 標準 (JSR-88) に基づいてデプロイメント プランを読み取ることもできます。 さらに、プランを設定すると DeploymentConfiguration.initializeConfiguration() メソッドで自動的にコンフィグレーション情報を復元することも可能です。
SessionHelper クラスでコンフィグレーション セッションを開始する場合、以下に例示するようにデプロイメント プランの情報を deploymentConfiguration に入力して簡単に開始できます。
DeploymentManager dm = SessionHelper.getDisconnectedDeploymentManager();
SessionHelper helper = SessionHelper.getInstance(dm);
// アーカイブの場所を指定する
helper.setApplication(app);
// 既存のデプロイメント プランの場所を指定する
helper.setPlan(plan);
// コンフィグレーション セッションを初期化する
helper.initializeConfiguration();
DeploymentConfiguration dc = helper.getConfiguration();
上記のコードでは、デプロイメント コンフィグレーションおよびそれに関連付けられる WebLogicDDBeanTree が生成されます。この段階で、通常どおり WebLogicDConfigBean ツリーの構築を開始します。
コンフィグレーションの検証は、ほとんどの場合、アプリケーションの記述子が処理される際に行われる記述子の解析中に発生します。検証では、記述子が有効な xml ドキュメントかどうか、また記述子が各自のスキーマに従っているかどうかが確認されます。
フロントエンド コンフィグレーションの実行では、WebLogicDeploymentPlan の作成と、WebLogicDeploymentPlan および関連する Bean ツリーへのデプロイメント プランのコンフィグレーション情報の指定を行います。デプロイメント プランの指定は任意ですが、デプロイメント コンフィグレーション (以下を参照) のコンフィグレーション値を変更するためには、有効な WebLogicDeploymentConfiguration が必要です。
デプロイメント コンフィグレーションのカスタマイズ フェーズでは、ユーザ入力と選択した WebLogic Server 対象に基づいて、個々の WebLogic Server コンフィグレーションの値を変更します。この段階のコンフィグレーションは、記述子またはアプリケーションに関連付けられた既存のプランとほとんど同様です。DConfigBean は Java Bean として設計されていて内部を参照できるため、ツールでその内容を意味のある形式で提示できます。DConfigBean のプロパティは、そのほとんどがコンフィグレーション可能です。また、主要なプロパティ (ユニークなもの) も公開されます。セッターについては、安全に変更できるプロパティに関するもののみが公開されます。一般的に、アプリケーションの動作が記述されるプロパティは変更できません。すべてのプロパティには記述子スキーマで定義されている型が指定されています。
プロパティのゲッターからは下位要素の DConfigBean、DConfigBean の配列、記述子 Bean、記述子 Bean の配列、単純な値 (プリミティブおよび java.lang オブジェクト)、または単純な値の配列が返されます。記述子 Bean では、変更可能だが DConfigBean の機能を必要としない記述子要素が表現されます。たとえば、記述子 Bean に直接関連している標準記述子要素はありません。
コンフィグレーションの編集は、プロパティのセッターを呼び出すことにより行われます。
純粋な JSR88 の DConfigBean クラスを使用すると、ツールで getDConfigBean(DDBean) メソッドまたは内部参照を利用して Bean にアクセスできます。アプリケーションの DeployableObject 内の DDBean 実装に基づいて標準記述子を提示した後に、各 DDBean のコンフィグレーション (その DConfigBean) に直接アクセスするツールでは、getDConfigBean(DDBean) によるアプローチが便利です。このアプローチでは、アプリケーションに指定されている可能性のある必須リソース要件のコンフィグレーションが提供されます。内部参照でのアプローチでは、ツールでアプリケーション全体のコンフィグレーションを提示できますが、必須のリソース要件が強調されるとは限りません。
もちろん、内部参照は両方のアプローチにおいて記述子のプロパティを提示または変更するために必要になります。異なるのはツールでの情報の提示方法です。標準記述子の内容で決まるか WebLogic Server 記述子の内容で決まるかが異なります。
コンフィグレーション情報を変更するシステムには、変更を要求するためのユーザ インタフェースを含めます。そのような変更を取得して設定するシステムを以下のコード サンプルに例示します。
// DConfigBean ツリーの内部を参照し、セッターでプロパティの入力を要求する
private void processBean(DConfigBean dcb) throws Exception {
if (dcb instanceof DConfigBeanRoot) {
System.out.println("Processing configuration for descriptor: "+dcb.getDDBean().getRoot().getFilename());
}
// 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];
// プリミティブのみを更新できるようにする
Method getter = prop.getReadMethod();
if (isPrimitive(getter.getReturnType())) // 下記の isPrimitive メソッドを参照
{
writeProperty(dcb,prop,bean); // 下記の writeProperty メソッドを参照
}
// 子プロパティについて再帰する
Object child = getter.invoke(dcb,new Object[]{});
if (child == null) continue;
// 子が 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);
}
}
}
}
// プロパティにセッターがある場合はユーザ入力で呼び出す
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(); // 下記の StringArrayEditor クラスを参照
if (pe != null) {
Object oldValue = getter.invoke(dcb,new Object[0]);
pe.setValue(oldValue);
String val = getUserInput(bean,prop.getDisplayName(),pe.getAsText());
// 下記の getUserInput メソッドを参照
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 とは、ここでは Java プリミティブまたは String 型のオブジェクトを意味する
private boolean isPrimitive(Class cc) {
boolean prim = false;
if (cc.isPrimitive() || String.class.isAssignableFrom(cc)) prim = true;
if (!prim) {
// プリミティブの配列 ?
if (cc.isArray()) {
Class ccc = cc.getComponentType();
if (ccc.isPrimitive() || String.class.isAssignableFrom(ccc)) prim = true;
}
}
return prim;
}
/**
* String 配列用のカスタム エディタ。入力テキストは
* カンマ区切りを使用してトークンに変換される
*/
private class StringArrayEditor extends PropertyEditorSupport {
String[] curr = null;
public StringArrayEditor() {super();}
// カンマ区切りの文字列
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; // 呼び出し側にクラス キャストの問題を処理させる
curr = new String[v.length];
for (int i=0;i<v.length;i++) curr[i] = new String(v[i]);
}
}
}
管理者またはユーザがコンフィグレーションを変更できるあらゆるインタフェースでは、基礎的なユーザ インタフェースの仕組みを超えてプロパティのセッターが上記のように使用されます。
Target は WebLogic Server、クラスタ、Web サーバ、仮想ホスト、および JMS サーバに関連付けられます。これについては、weblogic.deploy.api.spi.WebLogicTarget の Javadoc で説明されています。
WebLogic Server では、アプリケーションの名前をデプロイメント ツールで指定します。アプリケーションに格納されているモジュールの名前は、関連付けられているアーカイブ名またはモジュールのルート ディレクトリ名に基づきます。これらの名前は、アプリケーション用に構築されたコンフィグレーション MBeans に保持されます。
J2EE デプロイメントでは、アプリケーションやその構成要素のモジュールにコンフィグレーションされる名前について、TargetModuleID オブジェクト以外には特に規定されていません。しかし、TargetModuleID は、WebLogic Server ドメインに配布済みのアプリケーションにのみ存在するものです。そのため、配布する前に Deployer ツールでアプリケーションおよびモジュールの名前を表現する必要があります。この表現は、最終的にアプリケーションが配布されるときにサーバによって割り当てられる名前と一致している必要があります。
ツール プラグインでは、DeployableObject および J2eeApplicationObject クラスを通じて、アプリケーションの一覧を構築します。これらのクラスはそれぞれスタンドアロン モジュールと EAR を表します。各々のクラスが DDBeanRoot オブジェクトと直接関係しています。名前がコンフィグレーションされていない配布位置を提示する場合、その位置の名前が生成されます。その位置に配布されているのが File オブジェクトの場合、そのファイルの名前が使用されます。アーカイブが入力ストリームとして提供された場合、ルート モジュールにはランダムな名前が使用されます。
デプロイメント準備フェーズでは、コンフィグレーション セッションから生成されたプランを保存します。これは、DeploymentConfiguration.save() メソッド (別の標準 J2EE Deployment API のメソッド) によって行われます。この作業に SessionHelper.savePlan() メソッドを使用できます。この場合デプロイメント プランの新しいコピーが、プラン ディレクトリにあるすべての外部ドキュメントと共に保存されます。
DeploymentConfiguration.save メソッドでは、デプロイメント プランのスキーマに基づいて XML ファイルが作成されます。このファイルは、現在の DConfigBean の集合のシリアライゼーション、およびすべての変数割り当てと定義で構成されます。DConfigBean ツリーは常に外部の記述子として保存されます。この記述子は、アプリケーションのアーカイブまたは外部コンフィグレーション領域にまだ存在していない場合にのみ保存されます。すなわち、保存操作では既存の記述子は上書きされません。一方、DeploymentConfiguration.saveDConfigBean メソッドではファイルが上書きされます。これは、コンフィグレーションに行ったすべての変更が失われるということではありません。そうではなく、変更は変数割り当てを使用して処理されます。
前述したように、DeploymentConfiguration.restore メソッドは前もって保存されたデプロイメント プランに基づくコンフィグレーション Bean を作成するために使用されます (「フロントエンド コンフィグレーションの実行」を参照)。コンフィグレーション Bean はその全集合を復元することも、ツールで一部のみを復元することもできます。たとえば、アプリケーション内の特定モジュールのコンフィグレーション Bean のみを保存したり復元したりすることが可能です。このように処理できることで、アプリケーションのコンフィグレーションがある程度の柔軟性のあるものになっています。
|
|
|