Oracle® Fusion Middleware Oracle WebLogic Serverデプロイメントのプログラミング 11g リリース1(10.3.5) B60989-03 |
|
前 |
アプリケーションのデプロイメントでは、サーバー側処理とアプリケーションの起動のために管理サーバーに第3章「デプロイメントのためのアプリケーションの構成」で作成した情報を配布します。デプロイメント・ツールを使用して、以下に示すデプロイメント操作を正常に完了する必要があります。
デプロイメント・ツールには、使用するDeploymentFactory
オブジェクトをインスタンス化して登録する役目があります。DeploymentFactory
オブジェクトを管理するメカニズムは独自に実装することができます。WebLogic Server DeploymentFactory
オブジェクトは、wldeploy.jar
ファイルに格納されているマニフェスト・ファイルによって公開されます。このマニフェストには、ファクトリの完全修飾クラス名をホワイトスペース区切りで定義するエントリが記述されています。たとえば、DeploymentFactory
オブジェクトが一定の場所にあり、デプロイメント・ツールのクラス・パスに指定されている場合、デプロイメント・ツールの起動時に認識されたDeploymentFactory
オブジェクトが登録されます。例 4-1を参照してください。
例 4-1 マニフェスト・ファイルに登録されたデプロイメント・ファクトリ
MANIFEST.MF: Manifest-version: 1.0 Implementation-Vendor: BEA Systems Implementation-Title: WebLogic Server 9.0 Mon May 29 08:16:47 PST 2006 221755 Implementation-Version: 9.0.0.0 J2EE-DeploymentFactory-Implementation-Class: weblogic.deploy.spi.factories.DeploymentFactoryImpl . . .
標準のDeploymentFactory
インタフェースが、weblogic.deploy.api.WebLogicDeploymentFactory
で拡張されています。この拡張には以下のような追加メソッドがあります。
String[] getUris()
: getDeploymentManager
で認識されるURIの配列を戻します。配列の最初のURIは、必ずデフォルトのDeploymentManager
のURI、deployer:WebLogic
です。公開されているURIのみがこの配列で返されます。
String createUri(String protocol, String host, String port)
:引数に基づいて使用に適したURIを戻します。
デプロイメント・ツールではデプロイメント操作を実行するために、DeploymentFactoryManager
クラスに登録されているDeploymentFactory
から取得したDeploymentManager
を割り当てる必要があります。DeploymentManager
には、デプロイメントのためのアプリケーションの構成に加えて、J2EEサーバーへの接続を確立する役割もあります。DeploymentManager
の実装には、DeploymentFactory
を介してアクセスします。
次の項では、DeploymentManager
がサーバー・インスタンスに接続する方法について説明します。
DeploymentManager
を取得するには、DeploymentFactory.getDeploymentManager
メソッドを使用します。このメソッドは、引数としてURI、ユーザーID、およびパスワードを取ります。URIのパターンを以下に示します。
deployer:WebLogic<:host:port>
deployer:WebLogic.remote<:host:port>
deployer:WebLogic.authenticated<:host:port>
管理サーバーに接続する際、URIにはホストとポートを含める必要があります。たとえば、deployer:WebLogic:localhost:7001
のようにします。詳細については、「DeploymentManager URI実装について」を参照してください。
DeploymentManager
の引数に関する情報を以下に示します。
DeploymentManager
オブジェクトは割当時に指定したURIによって以下のような特性を持ちます。
deployer:WebLogic
: DeploymentManager
は管理サーバーのローカルで動作します。そのため、デプロイメント・セッション中に参照されるファイルはすべて管理サーバーのローカルにあると想定されます。
deployer:WebLogic.remote
: DeploymentManager
は、WebLogic Server管理サーバーのリモートで動作しています。デプロイメント・セッション中に参照されるファイルはすべて管理サーバーのリモートにあると想定され、アップロードが必要になる場合があります。たとえば、配布操作ではアプリケーション・ファイルの管理サーバーへのアップロードが行われます。
deployer:WebLogic.authenticated
:これは内部の公開されていないURIで、すでに認証されていてドメインの管理情報にアクセスできるコンソール・サーブレットなどのアプリケーションで使用できます。DeploymentManager
はWebLogic管理サーバーのローカルで動作します。そのため、デプロイメント・セッション中に参照されるファイルはすべて管理サーバーのローカルにあると想定されます。
アプリケーション・ファイルのアップロードは、WebLogicDeploymentManager method enableFileUploads()
メソッドを使用することによって明示的に行うことができます。
DeploymentManager
は接続されているか、あるいは切断されています。接続されたDeploymentManager
とは、WebLogic Server管理サーバーに接続されていることを意味します。この接続は、接続が明示的に切断されるか失われるまで維持されます。接続が失われた場合、このDeploymentManager
は切断された状態になります。
DeploymentManager
の接続の明示的な切断は、DeploymentManager.release
メソッドを介して行います。DeploymentManager
を再接続するためのメソッドはありません。代わりにデプロイメント・ツールで新しいDeploymentManager
を割り当てる必要があります。
注意: 新しいDeploymentManager を割り当てても、ツール内でDeploymentConfiguration オブジェクトを通じて管理している構成情報には影響しません。 |
DeploymentManager
のほとんどの機能的なコンポーネントは、J2EEデプロイメントAPI仕様に定義されています。しかし、Oracleでは、DeploymentManager
インタフェースを拡張し、既存のWebLogic Serverベースのデプロイメント・ツールが必要とする機能を追加しています。OracleのWebLogic Serverデプロイメント拡張については、「weblogic.deploy.api.spi.WebLogicDeploymentManager」
を参照してください。
JSR-88のプログラミング・モデルは、TargetModuleID
のオブジェクト(TargetModuleID
)とProgressObject
のオブジェクトの使用を中心に展開されています。一般に、対象モジュールはTargetModuleID
のリストで定義されます。おおまかにいって、このリストはデプロイ可能なルート・モジュールおよび下位モジュール・レベルのMBeanに相当します。DeploymentManager
ではTargetModuleID
をそのデプロイメント・オペレーションや進捗状況の追跡に利用します。デプロイメント・ツールでは各オペレーションで返されるProgressObject
を介して進捗状況を問い合わせる必要があります。ProgressObject
でオペレーションの完了または失敗が示された場合、そのオペレーションが実行されたことになります。
次の項では、WebLogic DeploymentManager
機能の概要を説明します。
WebLogic ServerではDeploymentOptions
引数(weblogic.deploy.api.spi.DeploymentOptions
)を使用できます。この引数では、特定のデプロイメント動作のオーバーライドがサポートされています。この引数にはnull
も指定でき、その場合は標準的な動作になります。このリリースでサポートされているオプションの一部を以下に示します。
管理 (テスト)モード
廃止ポリシー
ステージング
詳細は、DeploymentOptionsのJavadocを参照してください。
新しいアプリケーションを配布すると、以下の処理が実行されます。
アプリケーションのアーカイブおよびプランがすべての対象にステージングされる
アプリケーションがドメインに構成される
注意: 再配布は、すでにアプリケーション用に構成されたステージング・モードで有効になります。 |
標準のdistribute操作ではバージョンに名前を付けることができません。WebLogicDeploymentManager
では標準が拡張され、アプリケーションに関連するバージョン名を指定できます。
distributeから返されるProgressObject
では、ターゲット・サーバーにアプリケーションが存在している状態を表すTargetModuleID
のリストが提供されます。distributeで使用されるTargetオブジェクトは、サポートされている任意の対象です。TargetModuleID
では、各対象でアプリケーションのモジュールを利用できるかどうかが表されます。
新しいアプリケーションについては、TargetModuleID
が最上位のAppDeploymentMBean
オブジェクトを表します。TargetModuleID
には、アプリケーション内のモジュールおよびサブモジュールに基づく子TargetModuleID
はありません。これは、基底のMBean
がルートのモジュールのみを表しているためです。既存のアプリケーションについては、TargetModuleID
はDeployableMBean
と、構成にあるすべてのAppDeploymentMBean
およびSubAppDeploymentMBean
に基づいています。
アプリケーションの配布にdistribute(Target[],InputStream,InputStream)
メソッドを使用する場合、パフォーマンスに影響を及ぼすデプロイメントの前に、入力ストリームで表されているアーカイブおよびプランがストリームから一時領域にコピーされます。
標準のstartオペレーションではルート・モジュールのみがサポートされています。つまり、アプリケーションの全体的な起動のみができます。以下の構成を検討します。
<AppDeployment Name="myapp"> <SubDeployment Name="webapp1", Targets="serverx"/> <SubDeployment Name="webapp2", Targets="serverx"/> </AppDeployment>
getAvailableModules(ModuleType.EAR)
から返されるTargetModuleID
は次のようになります。
myapp on serverx (implied) webapp1 on serverx webapp2 on serverx
したがって、start(tmid)
ではserverx
上のwebapp1
およびwebapp2
が起動されます。
webapp1
を起動するには、モジュール・レベルでの制御が必要です。モジュール・レベルでの制御を構成するには、TargetModuleID
の階層を次のように手動で作成します。
WebLogicTargetModuleID root = dm.createTargetModuleID("myapp",ModuleType.EAR
,getTarget(serverx));
WebLogicTargetModuleID web = dm.createTargetModuleID(root,"webapp1",ModuleType.WAR);
dm.start(new TargetModuleID[]{web});
この方法では、TargetModuleID
作成の拡張を使用して、手動で明示的にTargetModuleID
の階層を作成しています。この場合、作成されるTargetModuleID
は次のようになります。
myapp on serverx (implied) webapp1 on serverx
start
操作ではアプリケーションの構成は変更されません。バージョンのサポートがTargetModuleID
に組み込まれていて、それによって特定のバージョンのアプリケーションを起動できます。アプリケーションは通常モードまたは管理(テスト)モードで起動できます。
deploy
オペレーションは、distribute
オペレーションとstart
オペレーションの機能を合わせ持っています。Webアプリケーションは通常モードまたは管理(テスト)モードでデプロイできます。DeploymentOptions
引数を介してアプリケーションのステージングも設定できます。deploy
オペレーションではTargets
オブジェクトではなくTargetModuleIDs
を使用してターゲット指定するため、モジュール・レベルで構成できます。
deploy
操作では、提供されたTargetModuleID
に基づいてアプリケーションの構成を変更できます。
標準のstop
オペレーションではルート・モジュールのみがサポートされています。つまり、アプリケーションの全体的な停止のみができます。詳細については、「アプリケーションの起動」を参照してください。
Oracleではバージョンのサポートを提供しており、それによって特定のバージョンのアプリケーションを停止できます。stop
操作ではアプリケーションの構成は変更されません。詳細は、「バージョンのサポート」を参照してください。
標準のundeploy操作では、TargetModuleID
で指定してアプリケーションを構成から削除します。したがって、個々のモジュールをアンデプロイできます。結果としてアプリケーションは対象に残りますが、特定のモジュールが対象で実際に実行されないように構成されます。モジュール・レベルの制御の詳細は、「アプリケーションの起動」を参照してください。
WebLogicDeploymentManager
はundeployを拡張して、配布されたアプリケーションからファイルを削除できるようにしたものです。これはインプレース再デプロイメントの1つの形態で、Webアプリケーションでのみサポートされ、静的なページの削除を可能にすることを目的としています。詳細は、「バージョンのサポート」を参照してください。
標準の再デプロイメントのサポートはアプリケーション全体にのみ適用され、side-by-sideバージョニングを採用することで中断のないセッション管理を実現しています。WebLogicDeploymentManager
では、redeploy()
メソッドが拡張され、以下のようなサポートが新たに提供されています。
インプレース再デプロイメント方法では、実行中のアプリケーションのデプロイメント・ファイルを、更新されたデプロイメント・ファイルでただちに置き換えます。その方法は次のとおりです。
既存のデプロイメントに対する特定のファイルの追加や置換などの部分的な再デプロイメント
デプロイメント・プランの再デプロイメントによる構成の更新
DeploymentManager
では、JSR-88仕様に基づいてルート・モジュールへの操作が制限されます。モジュール・レベルで制御するには、WebLogicDeploymentManager.createTargetModuleID
を介してモジュール固有のTargetModuleID
階層を手動で構築します。
アプリケーションの新しいバージョンが再デプロイされる場合、古いバージョンは最終的には廃止されてアンデプロイされます。アプリケーションの古いバージョンの廃止には次の2つのポリシーがあります。
(デフォルト)新しいバージョンがアクティブな場合、古いバージョンは無効になり、古いバージョンで実行中の処理が完了されます。
新しいバージョンがアクティブになるまでの指定された時間制限の後で、新しいバージョンがアクティブなときに古いバージョンが廃止されます。
注意: 新しいバージョンが管理(テスト)モードの場合、古いバージョンは廃止されません。 |
サイドバイサイド・バージョニングは、JSR-88の再デプロイメント仕様に示されているように、廃止された拡張を提供するために使用されます。サイドバイサイド・バージョニングを使用すると、サービスを中断せずにアプリケーションを最新のクライアントに再デプロイできます。サイドバイサイド・バージョニングのデプロイの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』」の「本番環境上のアプリケーションの再デプロイ」を参照してください。
Webアプリケーションは通常モードまたは管理(テスト)モードで起動できます。通常モードは、そのWebアプリケーションがクライアントから完全にアクセス可能であることを示します。管理(テスト)モードは、そのアプリケーションがadmin
チャネルを通してのみリクエストをリスニングすることを示します。管理(テスト)モードはstart
、deploy
、およびredeploy
のWebLogic Server拡張のDeploymentOptions
引数によって指定されます。詳細は、DeploymentOptionsのJavadocを参照してください。
アプリケーションのデプロイメント状態を判断するには、ProgressObjects
を使用します。それらのオブジェクトは、DeploymentTaskRuntimeMBeans.ProgressObjects
に関連付けられており、cancel操作はサポートされますが、stop操作はサポートされません。
ProgessObject
の実装は1つまたは複数のTargetModuleID
に関連付けられます。各TargetModuleIDが、アプリケーションおよびそのアプリケーションと特定の対象との関連付けを表します。任意のProgressObject
の実装にとって、関連付けられたTargetModuleID
が、モニターの対象とするアプリケーションを表します。
ProgressObject
ではデプロイメント・フレームワークとの接続が維持されるため、デプロイメント・ツールに最新のデプロイメントのステータスを提供できます。デプロイメントの状態が実行中から完了または失敗に変化するのは、関係するすべてのTargetModuleID
で個々のデプロイメントが完了したすぐ後です。結果として状態がcompleted
になるのは、TargetModuleID
が正しくデプロイされた場合のみです。
released
の状態は、デプロイ中にDeploymentManager
の接続が切断されたことを意味します。この状態の原因には、手動による解放、ネットワークの停止、または類似する通信障害の場合があります。
サンプル4-2では、ProgressObject
を使用してデプロイメントの完了を待機する方法について示します。
例4-2 デプロイメントの完了を待機するサンプル・コード
package weblogic.deployer.tools; import javax.enterprise.deploy.shared.*; import javax.enterprise.deploy.spi.*; import javax.enterprise.deploy.spi.status.*; /** * Example of class that waits for the completion of a deployment * using ProgressEvent's. */ public class ProgressExample implements ProgressListener { private boolean failed = false; private DeploymentManager dm; private TargetModuleID[] tmids; public void main(String[] args) { // set up DeploymentManager, TargetModuleIDs, etc try { wait(dm.start(tmids
)); } catch (IllegalStateException ise) { //... dm not connected } if (failed) System.out.println("oh no!"); } void wait(ProgressObject po) { ProgressHandler ph = new ProgressHandler(); if (!po.getDeploymentStatus().isRunning()) { failed = po.getDeploymentStatus().isFailed(); return; } po.addProgressListener(ph); ph.start(); while (ph.getCompletionState() == null) { try { ph.join(); } catch (InterruptedException ie) { if (!ph.isAlive()) break; } } StateType s = ph.getCompletionState(); failed = (s == null ||s
.getValue() == StateType.FAILED.getValue()); po.removeProgressListener(ph); } class ProgressHandler extends Thread implements ProgressListener { boolean progressDone = false; StateType finalState = null; public void run(){ while(!progressDone){ Thread.currentThread().yield(); } } public void handleProgressEvent(ProgressEvent event){ DeploymentStatus ds = event.getDeploymentStatus(); if (ds.getState().getValue() != StateType.RUNNING.getValue()) { progressDone = true; finalState = ds.getState(); } } public StateType getCompletionState(){ return finalState; } } }
この項では、オブジェクトをターゲット指定する方法について説明します。
標準のモジュールのタイプはjavax.enterprise.deploy.shared.ModuleType
に定義されています。これが、WebLogic Server固有のモジュールのタイプJMS、JDBC、INTERCEPT、およびCONFIGをサポートするように拡張されています。
JSR-88では、モジュールで参照したり利用したりできる補足的な記述子として二次的な記述子が定義されています。このような記述子はモジュールのルートDConfigBean
と関連付けられることで、Java Beanベースのツールから参照できるようになっています。これらはDConfigBeanRoot
オブジェクトの子プロパティです。二次的記述子はモジュールの構成プロセスで自動的に含められます。
EJBまたはWebアプリケーションには、webservers.xml
記述子を含められます。これが存在する場合、モジュールはセカンダリ記述子としてWebLogic ServerのWebサービス構成用の相当する記述子に自動的に構成されます。デプロイメント・プランにはこのような記述子が、別のモジュールではなくモジュールの一部として含められます。
EJBでのCMPのサポートはRDBMS記述子によって構成されます。RDBMS記述子はweblogic-ejb-jar.xml
記述子内でCMP Bean用に定義されます。RDBMS記述子では、CMP11およびCMP20がサポートされています。RDBMS記述子はEJBモジュールにいくつでも含められます。この種の記述子は、アプリケーションのアーカイブまたは構成領域(approot/plan
)に配置します。この種の記述子は構成プロセスでは作成されませんが、別の記述子と同様、変更されることはあります。RDBMS記述子はデプロイメント・プランでは二次的記述子として扱われます。
JDBCモジュールはアーカイブなしの単一のデプロイメント記述子で記述されます。モジュールがEARの一部の場合、一連のJDBC記述子は構成可能なプロパティとしてweblogic-application.xml
に記述されます。JDBCモジュールはWebLogic Serverおよびクラスタにデプロイできます。JDBC記述子に対する構成の変更は、記述子のオーバーライドとして処理されます。
JDBCモジュールがEARの一部の場合、その構成のオーバーライドはEARの一部としてデプロイメント・プランに組み込まれ、別個のモジュールとしては組み込まれません。
JMSモジュールはアーカイブなしの単一のデプロイメント記述子で記述されます。モジュールがEARの一部の場合、一連のJMS記述子は構成可能なプロパティとしてweblogic-application.xml
に記述されます。JMSモジュールはJMSサーバーにデプロイされます。JMS記述子に対する構成の変更は、記述子のオーバーライドとして処理されます。JMS記述子では「ターゲット指定できるグループ」を識別できます。そうしたグループはデプロイメント処理中にはサブモジュールとして扱われます。
JMSモジュールがEARの一部の場合、その構成のオーバーライドはEARの一部としてデプロイメント・プランに組み込まれ、別個のモジュールとしては組み込まれません。
Interceptモジュールはアーカイブなしの単一のデプロイメント記述子で記述されます。モジュールがEARの一部の場合、一連のIntercept記述子は構成可能なプロパティとしてweblogic-application.xml
に記述されます。InterceptモジュールはWebLogic Serverおよびクラスタにデプロイされます。Intercept記述子に対する構成の変更は、記述子のオーバーライドとして処理されます。
InterceptモジュールがEARの一部の場合、その構成のオーバーライドはEARの一部としてデプロイメント・プランに組み込まれ、別個のモジュールとしては組み込まれません。
J2EEデプロイメントAPI仕様での対象の定義では、対象の種類について特に述べられていません。WebLogic Serverでは、標準モジュールとOracle固有のモジュールのタイプが有効なデプロイメント対象としてサポートされています。対象のサポートは、weblogic.deploy.api.spi.WebLogicTarget
クラスおよびweblogic.deploy.api.spi.WebLogicTargetType
クラスによって提供されます。詳細は、「モジュールのタイプ」を参照してください。
TargetModuleID
のオブジェクトではモジュールとそれに関連付けられた対象を一意的に識別します。TargetModuleID
は、起動および停止されるモジュールの場所を指定するオブジェクトです。TargetModuleID
を識別するために使用されるオブジェクト名は、次の形式で表されます。
Application=parent-name,Name=configured-name,Target=target-name,TWebLogicTargetType=target-type
説明:
parent-name
は、このモジュールが含まれるEARの名前。
configured-name
は、このアプリケーションまたはモジュールに対してWebLogic Server構成で使用される名前。
target-name
は、モジュールがターゲット指定されているサーバー、クラスタ、または仮想ホスト。
target-type
は、Target.getDescription
から得られた対象についての説明。
TargetModuleID.toString()
はこのオブジェクトの名前を返します。
TargetModuleID
がweblogic.deploy.api.spi.WebLogicTargetModuleID
によって拡張されています。このクラスでは以下の付加機能が提供されます。
getServers
: TargetModuleID
のターゲットに関連付けられたサーバー
isOnCluster
: ターゲットがクラスタであるか
isOnServer
: ターゲットがサーバーであるか
isOnHost
: ターゲットが仮想ホストであるか
isOnJMSServer
: ターゲットがJMSサーバーであるか
getVersion
: バージョン名
createTargetModuleID
: モジュール固有のターゲットを作成するためのファクトリ
WebLogicTargetModuleID
の定義の詳細は、Javadocsを参照してください。
また、WebLogicDeploymentManager
も便利なメソッド群で拡張されています。それらのメソッド群を使用するとTargetModuleID
との連携が容易になります。このようなユーティリティには以下の2つがあります。
filter
: アプリケーション、モジュールおよびバージョンに一致するTargetModuleIDs
のリストを返します
getModules
: AppDeploymentMBean
に基づいて、TargetModuleIDs
を作成します
TargetModuleID
群にはベースとするアプリケーションに基づく階層関係があります。アプリケーションのルートTargetModuleID
は、EARモジュールまたはスタンドアロン・モジュールを表します。子TargetModuleID
群は、ルート・モジュールの記述子で定義されているモジュール群です。EARの場合、そのEARのapplication.xml
記述子で定義されているモジュールになります。JMSモジュールには、JMSデプロイメント記述子に定義されている子TargetModuleID
(サブモジュール)が存在することもあります。それらは組込みモジュールの子またはルート・モジュールの子の場合があります。したがって、JMSモジュールではアプリケーションのTargetModuleID
には3つのレベルが存在する場合があります。
TargetModuleID
は一般的にはデプロイメント関連の操作、またはDeploymentManager.get*Modules()
メソッド群のうちの1つを介して取得されます。これらの操作では、既存の構成に基づくTargetModuleID
群が提供されます。現在、構成に定義されているよりも限定された対象を指定する必要がある場合のために、createTargetModuleID
メソッドが用意されています。このメソッドでは、アプリケーション内のモジュールまたはサブモジュールに相当するルートTargetModuleID
が作成されます。作成されたTargetModuleID
は、任意のデプロイメント関連の操作で使用できます。アプリケーションのアーカイブ処理が含まれる操作(deploy()
など)で、こうしたTargetModuleID
の1つを使用すると、アプリケーションが再構成されることがあります。例:
<AppDeployment Name="myapp", Targets="s1,s2"/>
このアプリケーションでは、現在すべてのモジュールがs1
およびs2
で動作するように構成されています。さらに限定されたターゲットを指定するには、デプロイメント・ツールで次のようにします。
Target s1 = find("s1",dm.getTargets()); // find() is not part of this api WebLogicTargetModuleID root = dm.createTargetModuleID("myapp",ModuleType.EAR,s1); WebLogicTargetModuleID web = dm.createTargetModuleID(root,"webapp1",ModuleType.WAR); dm.deploy(new TargetModuleID[]{web},myapp,myplan,null);
myapp
が再構成され、webapp
がs1
でのみ動作するように限定的にターゲット指定されます。新しい構成は次のようになります。
<AppDeployment Name="myapp", Targets="s1,s2"> <SubDeployment Name="webapp", Targets="s1"/> </AppDeployment>
サブモジュールを持つスタンドアロンJMSモジュールのデプロイメントを検討します。このモジュールはsimple-jms.xml
ファイルで定義され、このファイルにサブモジュールsub1
とsub2
が定義されています。この記述子は特定の環境向けに完全に構成されているのでデプロイメント・プランは必要ありませんが、ここで紹介するシナリオはデプロイメント・プランがある場合も同じです。
このモジュールをデプロイするツールでは次の手順が実行されます。
// init the jsr88 session. This uses a WLS specific helper class, // which does not employ any WLS extensions DeploymentManager dm = SessionHelper.getDeploymentManager(host,port,user,pword); // get list of all configured targets // The filter method is a location where you could ask the user // to select from the list of all configured targets Target[] targets = filter(dm.getTargets()); // the module is distributed to the selected targets ProgressObject po = dm.distribute(targets,new File("jms.xml"),plan); // when the wait comes back the task is done waitForCompletion(po); // It is assumed here that it worked (there is no exception handling) // the TargetModuleIDs (tmids) returned from the PO correspond to all the // configured app/module mbeans for each target the app was distributed to. // This should include 3 tmids per target: the root module tmid and the // submodules' tmids. TargetModuleID[] tmids = po.getResultTargetModuleIDs(); // then to deploy the whole thing everywhere you would do this po = dm.start(tmids); // the result is that all sub-modules would be deployed on all the selected // targets, since they are implicitly targeted wherever the their parent is // targeted // To get sub-module level deployment you need to use WebLogic Server // extensions to create TargetModuleIDs that support module level targeting. // The following deploys the topic "xyz" on a JMS server WebLogicTargetModuleID root = dm.createTargetModuleID(tmids[i].getModuleID(),tmids[i],jmsServer); WebLogicTargetModuleID topic = dm.createTargetModuleID(root,"xyz",WebLogicModuleType.JMS); // now we can take the original list of tmids and let the user select // specific tmids to deploy po = dm.start(topic);