Skip navigation.

eDocs ホーム > BEA WebLogic Platform 8.1 ドキュメント > WebLogic Platform アプリケーションのデプロイメント > アプリケーションのデプロイメントの準備

WebLogic Platform アプリケーションのデプロイメント

  前 次 前と次、目次/インデックス/pdf を分けるコロン 目次  

アプリケーションのデプロイメントの準備

アプリケーションがプロモーション段階で処理されるにつれて、アプリケーション ソース ファイルおよびコンフィグレーション ファイルを、アプリケーションのデプロイメント前に変更する必要があります。新しい対象環境が、以下のように前の環境と異なる場合、ファイルの変更が必要です。

この章では、必要な特定の変更、それらの変更が必要な状況、およびその変更方法について説明します。この章の内容は以下のとおりです。

 

アプリケーションの準備タスクの概要

表 7-1 に、アプリケーションの特性や対象環境に応じて、アプリケーション ファイルで実行が必要なタスクを示します。また、タスクの実行方法を説明するトピックへのリンクも示します。

表 7-1 実行が必要なアプリケーションの準備タスク リスト 

アプリケーションまたは対象環境の特性

実行が必要なタスク

詳細情報の参照先

開発後の環境

アプリケーション ファイルを取得する。

「アプリケーション ファイルへのアクセス」

アプリケーション プロジェクト ファイルを更新して、アプリケーションを実行する対象環境のドメインを指すようにする。

「サーバ パス属性の更新」

WebLogic Portal キャッシュ コンフィグレーション、行動追跡、キャンペーン、コマースの税金などの設定を更新する。

「デプロイメント記述子およびコンフィグレーション ファイルの変更の概要」の application-config.xml ファイルの更新に関する指示

アプリケーションをプロダクション環境にチューニングする。

「デプロイメント記述子およびコンフィグレーション ファイルの変更の概要」にある weblogic.xml デプロイメント記述子ファイルの <jsp-descriptor> 要素の変更に関する指示

WebLogic Workshop ディスパッチャおよびコンテナ EJB をプロダクション環境にチューニングする。

「デプロイメント記述子およびコンフィグレーション ファイルの変更の概要」にある EJB の変更に関する指示

アプリケーションはクラスタを対象とする。

サーバに障害が発生したとき、セッション レプリケーションを有効にして、オブジェクト ステートについての情報を維持する。

「セッション レプリケーションの有効化」

Web サービス コントロールを使用して、ほかのアプリケーションにアクセスする。

Web サービス コントロールで指定された対象サービスのホスト、ポート、必要に応じて、セキュリティ プロトコルを更新する。

「アプリケーション間の通信の有効化」

WebLogic Integration のビジネス プロセス モニタ機能を使用する。

ステートフル ビジネス プロセス エンティティ Bean に同時方式を設定する。

「ステートフル ビジネス プロセス エンティティ Bean の同時方式の指定」

WebLogic Integration の Application Integration 機能を使用する。

WebLogic Integration アプリケーション ビューを更新する。

「アプリケーション ビューの再コンフィグレーション」

Application Integration アダプタの対象イベント ジェネレータを指定する。

「イベント ジェネレータの対象指定」

アプリケーションへの安全なアクセスが必要である。

アプリケーションのアクセスを認証されたユーザのみに制限する。

「認証されたユーザへのアクセスの制限」

アプリケーションのアクセスを SSL リクエストのみに制限する。

「アプリケーションのアクセスを SSL トラフィックのみに制限する」


 

 

デプロイメント記述子およびコンフィグレーション ファイルの変更の概要

J2EE アプリケーションと同様に、WebLogic Platform アプリケーションにも、プロダクション環境に合わせて調整できるデプロイメント記述子があります。また、プロダクション環境には、変更できるプロパティ ファイルもあります。次の表に、関連ファイル、必要な変更の概要、その変更方法、および変更が有効になる時期を示します。また、関連する詳細について説明しているトピックへのリンクも示します。次の表で説明される各ファイル名とファイルが配置されるディレクトリは、最初のカラムに太字で示されます。この表では、

 

プロダクション環境へのプロモーションに関するアプリケーション ファイルの管理

この節は、プロダクション環境へプロモートするアプリケーション ファイルの管理についての推奨事項を示す、以下のトピックで構成されています。

アプリケーション ファイルへのアクセス

アプリケーション管理者がアプリケーション ファイルへアクセスするための 2 種類の主なメカニズムは、次のとおりです。

メカニズムの選択に関して、次の 2 つの考慮事項があります。

バージョン コントロール システムを使用する主な利点は、アプリケーション ファイルへの変更を追跡できることであり、そのようなシステムは、一般に、WebLogic Workshop IDE と統合されることです。この統合により、アプリケーション ファイルを再構築するために便利な方法が得られます。ただし、対象環境にデプロイする目的でこれらのファイルに変更を行う場合、追跡が必要です。大規模なチーム環境では、複数のチーム メンバーにより同時に変更を行う場合、混乱が生じる可能性があります。

また、アプリケーション管理者がアプリケーション EAR ファイルを指定する場合、ビルド環境へアクセスできないこともあります。変更によりアプリケーション ファイルの再構築が必要な場合、アプリケーション管理者はその変更を行えず、制限が生じる可能性もあります。ただし、デプロイメント記述子を直接編集する方法を選択してファイルを変更する場合、必要なのは EAR ファイルへのアクセスのみです。デプロイメント記述子は簡単に抽出、変更、およびステージングできます。また、EAR ファイルをアプリケーション管理者に渡すことにより、アプリケーション ソース ファイルへの変更を効率的に制御できます。さらに、EAR ファイルで直接的に扱われるスクリプトを作成するほうが簡単です。IT チームが使用するポリシー、アプリケーション管理者の役割、プロモーション プロセス、アプリケーションなどに応じて、1 つのメカニズムが他のメカニズムよりも適切な場合もあります。

この章で説明するほとんどの変更は、アプリケーション ソース ファイルではなく、EAR ファイルで自動的に使用できるデプロイメント記述子に行われます。そのため、特に明記しない限り、ソース ファイル コントロールの問題については、この章では考慮していません。

バージョン コントロール システムの使用

アプリケーション ファイルのバージョン コントロールとアーカイブの保持には、ソース コントロール ツールを使用することをお勧めします。WebLogic Workshop は、CVS、Perforce、IBM Rational ClearCase などと直接統合できます。WebLogic Workshop アプリケーション内のファイルを、このいずれかのソース コントロール製品で管理されているリポジトリに追加すると、WebLogic Workshop のコマンドを使用して、ファイルをチェック インおよびチェック アウトできます。

WebLogic Workshop でアプリケーションを開発する場合、ソース コントロールに追加するファイルは次のとおりです。

WebLogic Workshop プロジェクトとバージョン コントロール システムの統合についての詳細は、以下の URL にある WebLogic Workshop ヘルプの「ソース コントロール システムと統合する」を参照してください。

http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/workshop/guide/devenv/conIntegratingWithSourceControlSystems.html

バージョン コントロールされないファイル

Perforce、CVS などのソース コントロール ツールを使用することが重要ですが、そのようなツールで管理されるソース ツリーにチェックしてはいけないファイルがあります。そのようなファイルには、プロダクション デプロイメントでアプリケーションを構築する前にインストールする必要のあるファイルが含まれます。それは、WebLogic Portal と WebLogic Integration 用に WebLogic Workshop で使用する JAR ファイルおよびライブラリ ファイルや、NetUI タグ ライブラリ ファイル、Liquid Data コントロール ファイルなどです。これらのファイルは、製品で作成するアプリケーションのテンプレートを有効にすると、WebLogic Workshop により自動的にステージングされます。

また、開発中に WebLogic Workshop により自動的に生成される以下のファイルをチェック インしないよう注意してください。

.workshop ディレクトリ
META-INF (application-config.xml ファイルは除く)
<web-project>/WEB-INF/*.tld
<web-project>/WEB-INF/*.tldx
<web-project>/WEB-INF/jpf-struts-config*.xml
<web-project>/WEB-INF/classes
<web-project>/WEB-INF/lib
<schema-project>/system/*.*
*.jar
*.war

上記のリストの説明は以下のとおりです。

注意 : 異なるアプリケーションで生成された JAR ファイルを、ライブラリまたはモジュールとして現在のアプリケーションに追加する場合、ソースの管理下に置きます。ただし、アプリケーション内でライブラリをビルドする場合は、そのライブラリをソースの管理下に置かないでください。また、プロダクション ドメイン内にはコピーしないでください。WebLogic Workshop の [アプリケーション] ペインの [モジュール] フォルダにモジュールとして追加する JAR ファイルは、アプリケーションのルート フォルダに WebLogic Workshop により配置され、WebLogic Workshop の [ライブラリ] フォルダにライブラリとして追加する JAR は物理的に APP-INF/lib ディレクトリに配置されます。

 

高可用性の有効化

WebLogic Workshop でアプリケーションを開発する場合、一般に、以下のようなプロダクション環境の特徴を扱う必要はありません。

WebLogic Workshop の長所は、一般にプロダクション環境でのエンタープライズ レベルのアプリケーションに必要な移植性、信頼性、可用性およびスケーラビリティの各機能を有効にするコードを記述しないで、アプリケーションのビジネス ロジックに専念できることです。WebLogic Workshop では、多くのリソースや機能をある程度自動的に使用可能にすることによって、または、開発環境において、データベース アクセス、クライアント アクセス、他のアプリケーションとの通信などの非常に簡単な方法で、これを実現しています。

ただし、アプリケーションを開発環境からプロダクション環境へ移動する場合、クラスタ化された環境でリソースにアクセスしたり、クライアントがアクセスできるよう、アプリケーション ファイルに少数の変更を加える必要があります。これらの簡単な変更を行うことにより、アプリケーションで、クラスタ化された WebLogic ドメイン環境で提供される高可用性およびロード バランシング機能を十分に利用できます。

クラスタ化されたプロダクション ドメインでアプリケーションが機能するよう変更しなければならない主な領域は、以下の 3 つです。

アプリケーション間の通信の有効化

ネットワークを介した分散システムとの相互運用が必要なアプリケーションを構築する場合、Web サービス コントロールの使用により、多彩で便利な方法で、バックエンド リソースやほかのアプリケーションと通信できます。開発環境では、アプリケーションは、「直接アクセス」を使用して、Web サービスや、Web アプリケーションを呼び出すことができます。たとえば、サービスのホストとポートに localhost:7001 を指定します。ただし、プロダクション環境では、これらの Web サービスは、通常、ローカルに使用できないか、ロケーションが変更されていることがあります。または、Web プロキシ サーバやロード バランサのみを介して、対象環境のサーバへアクセスできます。

したがって、アプリケーションを WebLogic Workshop の開発環境からプロダクション環境へ移動するには、アプリケーションに使用する Web サービス コントロールに、正しく更新された URL が確実に含まれている必要があります。この節で提供される情報は、アプリケーション デプロイメントの手順だけではなく、適切にアプリケーションを設計するための重要な考慮事項についても説明しています。

Web サービス コントロールで URL の更新が必要になるのは、以下の状況です。

どちらの状況でも、Web サービス コントロールで設定されたホストおよびポートは、アプリケーションがプロダクション環境でデプロイされるまで、変更される可能性があります。この節では、Web サービス コントロールの URL 例を示し、URL の更新に使用できる 4 つの方法を説明します。

Web サービス コントロールの URL 例

Web サービス コントロールをアプリケーションに組み込み、Web サービスを呼び出す場合、WebLogic Workshop は、呼び出した Web サービスのホストとポートを JCX ファイルに生成し、@jc:location アノテーションの一部として、そのホストとポートを含みます。以下に、開発中に生成された Web サービス コントロールの @jc:location アノテーションの例を示します。ホストとポートは太字で示されています。

/**
 * @jc:location http?url="http://localhost:7001/processes/CSR.jpd"
 * @jc:wsdl file="#CSR_ProcessWsdl"
 */

Web サービス コントロールの URL 更新方法

アプリケーション EAR ファイルをプロダクション デプロイメントにビルドする前に、次の例で示すように、必ず @jc:location アノテーションのホストとポートを更新して、対象 Web サービスがデプロイされるプロダクション ドメインの Web プロキシ サーバまたはロード バランサを指定します。 

/**
  * @jc:location http?url="http://proxysvr2:9201/processes/CSR.jpd"
  * @jc:wsdl file="#CSR_ProcessWsdl"
  */

アプリケーションの Web サービス コントロールに指定したホストとポートを更新するには、次の方法を使用します。

方法 1 と方法 2 は、アプリケーションにソース レベルの変更を行うため、ビルド環境へアクセスして変更する必要があり、変更を有効にするために必ずアプリケーションを再構築します。方法 3 と方法 4 は、上記の 2 つの方法に要求される、デプロイメント時のアプリケーションへのソース レベルの変更は必要ありませんが、開発中にアプリケーションに設計されるべき機能が反映されます。

どの方法を使用するかに関係なく、開発チームは、最終プロダクション環境を構築およびデプロイする前に、プロダクション環境のシステム管理者が対応するサービス コントロール ファイルを適宜更新できるように、アプリケーションに使用するリモート サービスのリストを用意します。

方法 1: 対象の Web サービスの WSDL ファイルをプロジェクトに再インポートする

アプリケーションをプロダクション ドメインに移動する場合、対象の Web サービスの WSDL ファイルをプロジェクトに再インポートできます。この WSDL ファイルは、プロダクション環境でデプロイされた後、対象の Web サービスから生成される必要があります。この方法を使用すると、アプリケーションの Web サービス コントロールを正しく更新できます。

方法 2: アプリケーションの @jc:location アノテーションを手動で更新する

WebLogic Workshop では、対象の Web サービスごとに正しいホストとポートを指定して、各 @jc:location を手動で更新できます。この方法が最も迅速で簡単ですが、IDE のアプリケーションを再コンパイルする必要があります。また、手動で更新するため、エラーが生じるおそれがあります。

方法 3: サービス コントロールの setEndPoint() メソッドへの呼び出しを実装する

各サービス コントロールには、実行時にコントロールを強制し、作成するプロパティ ファイルに含まれる URL のエンドポイント情報を使用できるようにする setEndPoint() メソッドがあります。この方法を使用するための考慮事項は次のとおりです。

方法 4: サービス ブローカ コントロールを実装する

サービス ブローカ コントロールを使用すると、ビジネス プロセスでは、別のビジネス プロセス、Web サービス、またはリモートの Web サービスやビジネス プロセスとの間で、要求を送信したりコールバックを受信したりできます。サービス ブローカ コントロールは Web サービス コントロールの拡張であり、エンドポイント情報をアプリケーションに動的に受け渡しできます。たとえば、WebLogic Integration Administration Console にプロパティを指定できます。この方法を実装することにより、アプリケーションの再構築が不要です。

セッション レプリケーションの有効化

WebLogic Server では、標準に基づいた通信技術および通信機能を利用して、クラスタ内のオブジェクトの可用性に関する情報を共有および維持します。WebLogic Server ではこれらの技術によって、(アプリケーションが実行されているマシンにエラーが生じたため) ジョブを完了する前にオブジェクトを停止したかを判断したり、中断されたジョブを完了するためのオブジェクトのコピーが存在する場所を特定します。

あるジョブに関してどのような処理が完了しているかについての情報をステートと呼びます。ステートについての情報を維持するために、WebLogic Server で使用される方法は、セッション レプリケーションです。セッション レプリケーションにより、特定のオブジェクトが不意にそのジョブの実行を停止したとき、障害を起こしたオブジェクトがどこで停止したかをオブジェクトの別のコピーが認識し、代わりにそのジョブを完了することが可能になります。

WebLogic Platform ドメインでデプロイされるアプリケーションでは、セッション レプリケーションを有効にする必要があります。この設定を行わないと、クラスタ内のサーバが停止したときに、ユーザの状態に関する情報がフェイルオーバされません。クラスタ内でセッション レプリケーションを有効にするには、次の例に示すように、アプリケーションの weblogic.xml デプロイメント記述子ファイルの <session-param> 記述子の要素をコンフィグレーションします。

<session-descriptor>
        <session-param>
                <param-name>PersistentStoreType</param-name>
                <param-value>replicated_if_clustered</param-value>
        </session-param>
</session-descriptor>

ステートフル ビジネス プロセス エンティティ Bean の同時方式の指定

Oracle など、ほとんどのデータベース システムは、insert 操作の後にロックを保持しません。ビジネス プロセスの最初のトランザクションには、常に insert 操作が含まれます。ビジネス プロセスで、最初のトランザクションが完了する前にメッセージまたはコールバックを受信するよう想定されている場合、Database 同時方式が不十分な可能性があります。このような場合は、Exclusive 同時方式を使用します。この機能を実現するために、以後のメッセージまたはコールバックは必ずローカル サーバから送信される必要があります。

Exclusive 同時方式を有効にするには、wlw-config.xml ファイルの <ejb-concurrency-strategy> 要素が、ステートフル ビジネス プロセス エンティティ Bean で exclusive に設定されているか確認します。特定のデータベースに関する問題については、次の URL にある『BEA WebLogic Integration リリース ノート』を参照してください。

http://edocs.beasys.co.jp/e-docs/wli/docs81/relnotes/index.html

wlw-config.xml ファイルの変更の詳細については、次の URL にある WebLogic Workshop ヘルプの「wlw-config.xml コンフィグレーション ファイル」を参照してください。

http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/workshop/reference/configfiles/con_wlw-config_xml_ConfigurationFile.html

 

アプリケーション ビューとアダプタの再コンフィグレーション

aiConfigurator ユーティリティにより、管理者は、WebLogic Integration で使用されるアプリケーション ビュー、アダプタ、接続ファクトリ記述子の環境固有の情報を変更できます。これにより、管理者は、Application Integration リソースを事前にコンフィグレーションし、プロダクション システム環境に適切にデプロイすることができます。WebLogic Integration Administration Console を使用すると、これらのリソースをさらに調整できます。

次の節では、アプリケーション ビューおよび対象のイベント ジェネレータを再コンフィグレーションするための aiConfigurator ユーティリティの使用方法を説明し、その例を示します。

アプリケーション ビューの再コンフィグレーション

アプリケーションで、1 つまたは複数のアダプタにより有効になるアプリケーションのサービスおよびイベントへのインタフェースとして、WebLogic Integration からアプリケーション ビューを使用する場合、それらのアプリケーション ビューをプロダクション環境でのコンフィグレーションに応じて更新する必要があります。たとえば、アプリケーションでアプリケーション ビューを DBMS アダプタとともに使用する場合、プロダクション ドメインで使用される DBMS の設定は、開発ドメインでの設定とは異なります。

BEA では、アプリケーション ビューの再コンフィグレーションを自動化するための aiConfigurator ユーティリティが使用できます。aiConfigurator ユーティリティの使用方法の詳細については、次の URL にある『WebLogic Integration ソリューションのデプロイメント』の「環境固有の Application Integration 情報の管理」を参照してください。

http://edocs.beasys.co.jp/e-docs/wli/docs81/deploy/config_appx.html

イベント ジェネレータの対象指定

DBMS サンプル アダプタなどの、複数のジェネレータ インスタンスをサポートする Application Integration アダプタを使用する場合は、イベント ジェネレータをクラスタ内の各ノードに分散できます。このような分散を行うには、-inboundMessagingTargets オプションを使用して、aiConfigurator ユーティリティにイベント生成対象を指定します。

対象の指定は、アダプタがイベント ジェネレータのインスタンス サポートを実装しているかどうかにより異なります。イベント ジェネレータのインスタンス サポートの実装に関する考慮事項は、次の URL にある『アダプタの開発』の「イベント アダプタの開発」で説明しています。

http://edocs.beasys.co.jp/e-docs/wli/docs81/devadapt/7devea.html

 

アプリケーション セキュリティの準備

次の節では、対象環境のセキュリティ要件に応じてアプリケーション ファイルに必要とされる変更について説明します。

認証されたユーザへのアクセスの制限

対象環境のアプリケーションへのアクセスが認証されたユーザのみに制限される場合、web.xml デプロイメント記述子の <login-config> 要素にある、FORM または CLIENT-CERT のいずれかを必要に応じて指定します。

以下に <login-config> 要素の <auth-method> 下位要素を CLIENT-CERT に設定する例を示します。

<login-config>
  <auth-method>CLIENT-CERT</auth-method>
</login-config>

アプリケーションのアクセスを SSL トラフィックのみに制限する

対象環境のセキュリティにより、アプリケーションが SSL リクエストのみを受け取るよう制限される場合、ホスト サーバが SSL リスン ポートのみでリクエストを受け取るようコンフィグレーションされているかどうかに関係なく、次の手順を実行します。

  1. アプリケーションを呼び出すための Web サービス コントロールを更新します。

    2. 「アプリケーション間の通信の有効化」では、アプリケーションにより呼び出される対象 Web サービスへのアクセスを処理する Web プロキシやロード バランサのホストおよびポートを指定する、Web サービス コントロールの更新方法を説明します。アプリケーションのアクセスを SSL リクエストのみに制限する場合、同じ Web サービス コントロールを更新して、Web サービスの URL にセキュアな転送を指定する必要があります。

    次のコードの断片は、サービス コントロールの対象 Web サービスの URL に指定する必要のあるセキュアな転送を示します。

    /**
    * @jc:location http-url="https://proxysvr1:7002/webservice/Report.jws"
    * @jc:wsdl file="#ReportWsdl"
    */
    public interface ReportControl extends com.bea.control.ControlExtension, com.bea.control.ServiceControl

    この更新は、「Web サービス コントロールの URL 更新方法」の説明のように、対象 Web サービスの URL のホストおよびポートの変更と同時に行われます。

    注意 : アプリケーションは、一方向または双方向の SSL を使用するために、追加的なメカニズムをコードに実装する必要があります。ただし、この処理はデプロイメントではなく、開発タスクです。詳細については、次の URL にある WebLogic Workshop ヘルプの「WebLogic Workshop のセキュリティの概要」を参照してください。

    http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/workshop/guide/security/navSecurity.html

  2. アプリケーションが SSL を介して送信されるリクエストのみを受信するには、WEB-INF ディレクトリに配置された、アプリケーションの web.xml デプロイメント記述子の <user-data-constraint> 要素の <transport-guarantee> セクションに CONFIDENTIAL を指定します。以下に例を示します。

    3. <security-constraint>
    <!-some other configs -->
    <user-data-constraint>
    <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
    </security-constraint>

警告 : ドメイン レベルのセキュリティは、SSL リスン ポートをコンフィグレーションドして、正しく設定する必要があります。アプリケーションによる呼び出しに対応する変更では、SSL の使用を有効にする必要があります。クライアント証明書の送信例については、次の URL にある WebLogic Workshop ヘルプの「WebServiceA.jws サンプル」を参照してください。

警告 : http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/samplesrc/SamplesApp/WebServices/security/transport/clientCert/WebServiceA-jws.html

 

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

WebLogic Workshop により、J2EE エンタープライズ アプリケーションが作成され、プロダクション ドメインでデプロイされます。アーカイブ形式では、一般に EAR ファイルがこれにあたります。Web アプリケーションは、単体でデプロイすることはできません。アプリケーション全体の一部としてしかデプロイできないので注意が必要です。

ここでは以下のトピックについて説明します。

サーバ パス属性の更新

アプリケーションを、プロモーションの各段階で、ある環境からほかの環境へ移動する場合、アプリケーション EAR ファイルは wlwBuild コマンドを使用して再構築されます。アプリケーションのプロジェクトを別の環境へ移動する場合、必ずアプリケーションの .work ファイルの server.path 属性をリセットして、対象環境のルート ドメイン ディレクトリを指すようにします。

このアプリケーションの .work ファイルは、アプリケーション ディレクトリのルートに置かれます。

次の例では、server.path 属性はドメインの platDomain に設定されます。

<option name="server.path" value="../../../domains/platDomain"/>

wlwBuild コマンドの詳細については、次の URL にある WebLogic Workshop ヘルプの「wlwBuild コマンド」を参照してください。

http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/workshop/reference/commands/cmdWlwBuild.html

EAR ファイルの生成

次のいずれかの方法を使用して、WebLogic Workshop アプリケーションの EAR ファイルを生成できます。

wlwBuild ツールの方が多少柔軟で、アプリケーション全体に EAR ファイルをビルドする代わりに、特定のプロジェクトに JAR ファイルをビルドするようにフラグを設定できます。また、wlwBuild ツールは、自動生成または手動での作成が可能な Ant タスクから簡単に呼び出すことができます。詳細については、次の URL にある WebLogic Workshop ヘルプの「ANT build.xml ファイルから wlwBuild.cmd を呼び出すには」を参照してください。

http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/workshop/guide/deployment/howCallWLWBuildFromAnt.html

アプリケーションを構築する際には、以下の点に注意してください。

アプリケーション デプロイメントのパッケージ化については、以下のトピックを参照してください。

 

ナビゲーション バーをスキップ  ページの先頭 前 次