ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ
12c リリース1 (12.1.1)
B65920-02
  ドキュメント・ライブラリへ移動
ライブラリ
製品リストへ移動
製品
目次へ移動
目次

前
 
次
 

6 weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ

この章では、weblogic.Deployerユーティリティを使用して、コマンド・ライン・ベースの対話的なデプロイメント・タスクを実行する方法について説明します。

この章の内容は以下のとおりです。

一般的なデプロイメント・シナリオの概要

以下の節では、一般的なデプロイメント・タスクをいくつかの一般的なカテゴリにまとめています。最も基本的なタスクから始まり、より高度なタスクへと進みます。アプリケーションをデプロイする前に、「本番デプロイメントのためのアプリケーションの構成」で説明されている適切なタスクを実行します。

リモート・クライアントからのデプロイメント・ファイルのアップロード

ドメインにアプリケーションまたはモジュールをデプロイするには、デプロイメント・ファイルがドメインの管理サーバーからアクセス可能でなければなりません。デプロイメント・ファイルが管理サーバー・マシン上にない場合、またはネットワークにマウントされたディレクトリを通じて管理サーバー・マシンから使用できない場合は、-uploadオプションを使用して、デプロイする前にファイルをアップロードします。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -deploy -upload c:\localfiles\myapp.ear

展開されたアーカイブ・ディレクトリをアップロードするには、アーカイブ・ファイル名のかわりにディレクトリ名を指定します(たとえば、c:\localfiles\myappEar)。

管理サーバー・マシンにファイルをアップロードすると、アーカイブ・ファイルはサーバーのアップロード・ディレクトリに自動的に配置されます。このディレクトリのパスは、「サーバーのデフォルト・ステージング動作の変更」にある手順にしたがって構成できます。

アプリケーションまたはプランを更新する場合のアップロードの動作

ローカルとリモート(アップロード)のデプロイメント操作を混在させる場合は、アプリケーションのデプロイの過程を追跡するプロセスを用いることが重要です。以下のような一連のイベントを検討してください。

  1. 管理者または開発者は、次の情報を使用して、管理対象サーバーを持つ管理サーバーに、デプロイメント・プラン(productionEnvPlan.xml)を含めたアプリケーション(myapp.ear)をデプロイした場合。

       java weblogic.Deployer -adminurl http://test:7001 -username weblogic
          -password weblogic -deploy c:\localfiles\myapp.ear
          -plan c:\localfiles\productionEnvPlan.xml
    
  2. 管理者または開発者は管理対象サーバー上でWebLogic Portalを使用し、myapp.earアプリケーションに対していくつかの構成変更を保存した場合。アプリケーションを保存すると、WebLogic Portalは次の情報を使用してアプリケーションを更新します。

       java weblogic.Deployer -adminurl http://test:7001 -username weblogic
          -password weblogic -update -name myapp.ear -upload 
          -plan c:\localfiles\nuPlan.xml
    
  3. リモート・マシンにあるアプリケーションとデプロイメント・プラン・ファイルが、管理サーバーのアップロード・ディレクトリにアップロードされた場合。デプロイメントが更新され、構成ではc:\domain\servers\adminServerName\upload\plan\nuPlan.xmlのデプロイメント・プランが使用されます。

この時点で、アプリケーション(c:\localfiles\myapp.ear)とデプロイメント・プラン(c:\localfiles\productionEnvPlan.xml)から派生した動作を想定している管理者または開発者は、混乱してしまう可能性があります。管理者または開発者が、

  • アプリケーションとデプロイメント・プラン・ファイルを確認すると、ファイルは変更されていません。新しい動作の説明はつかないように見えます。

  • c:\localfiles\myapp.earアプリケーション・ファイルまたはc:\localfiles\productionEnvPlan.xmlデプロイメント・プランxmlファイルに変更を加えた場合、アップロード・ディレクトリ内のデプロイメント構成の変更は、失われるおそれがあります。

単一サーバー・ドメインへのデプロイ

1つの管理サーバーのみで構成される単一サーバーのWebLogic Serverドメインは、アプリケーションまたはモジュールをデプロイするシナリオとしては最も単純なものになります。ドメインと同じマシンにあるファイルをデプロイする場合は、管理サーバーの接続引数を指定して-deployコマンドを使用し、ファイルの場所を指定します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -deploy c:\localfiles\myapp.ear

「デフォルト・デプロイメント名について」で説明されているように、上記のコマンドでWebLogic Serverは、myappというデフォルト・デプロイメント名を作成します。myappはデプロイメント・ファイルの名前から拡張子を除いたものです。デフォルト以外のデプロイメント名を指定する場合は、次のように-nameオプションを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 
   -username weblogic -password weblogic -deploy 
   -name myTestApplication c:\localfiles\myapp.ear

アプリケーションまたはモジュールを複数のターゲットにデプロイする方法については、「サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定」を参照してください。

デプロイメント・プランによるアプリケーションのデプロイ

weblogic.Deployerを使用してアプリケーションをデプロイする場合、デプロイメント・プランとWebLogic Serverデプロイメント記述子では、ターゲットの環境の有効な構成を定義する必要があります。定義されていない場合、デプロイメントは失敗します。つまり、アプリケーションの必須のリソース・バインディングに対してnullの変数を定義したデプロイメント・プランを指定して、weblogic.Deployerを使用することはできません。

weblogic.Deployerを使用してアプリケーションとデプロイメント・プランをデプロイするには、-deployコマンドと一緒に-planオプションを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
     -password weblogic -deploy -name myTestDeployment 
     -source /myDeployments/myApplication.ear
     -targets myCluster -stage 
     -plan /myDeployments/myAppPlan.xml

アプリケーションのルート・ディレクトリからデプロイし、デプロイメント・プランが/planサブディレクトリにある場合でも、実際のデプロイメント・ソース・ファイルと、デプロイメントに使用するプランの両方を指定する必要があります。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
     -password weblogic -deploy -name myTestDeployment 
     -source /myDeployments/installedApps/myApplication/app/myApplication.ear
     -targets myCluster -stage
     -plan /myDeployments/installedApps/myApplication/plan/plan.xml

デプロイメント・プランを指定してアプリケーションをデプロイまたは配布する場合、アプリケーションのソース・ファイルと一緒に、デプロイメント・プランと生成済みデプロイメント記述子がターゲット・サーバーのステージング・ディレクトリにコピーされます。

preStart期間中にJNDIからシステム・リソースをルックアップするアプリケーションのデプロイ

preStartアプリケーション・ライフサイクル・リスナーはアプリケーションの準備フェーズ中(編集セッションがアクティブ化のときに発生)に呼び出されるため、同じ編集セッション中に新しいシステム・リソースを作成し、そのシステム・リソースを使用するアプリケーションをデプロイすると、システム・リソースのJNDIルックアップは失敗します。たとえば、管理コンソールで編集ロックを取得し、新しいJDBCシステム・リソースを作成して、同じ編集セッション中に(つまり、管理コンソールで変更をアクティブ化する前に)、そのJDBCシステム・リソースを使用するアプリケーションをデプロイする場合、システム・リソースがアクティブになる前にpreStartアプリケーション・ライフサイクル・リスナーが呼び出されるため、JDBCシステム・リソースのJNDIルックアップは失敗します。preStartライフサイクル・リスナーでJNDIからシステム・リソースをルックアップするには、起動時または別の編集セッションでシステム・リソースを作成してから、システム・リソースを使用するアプリケーションをデプロイすることをお薦めします。例:

  1. 管理コンソールで「ロックして編集」をクリックして、編集ロックを取得します。

  2. 必要なシステム・リソースを作成します。詳細は、Oracle WebLogic Server管理コンソール・ヘルプJMSシステム・モジュールの作成に関する項を参照してください。

  3. 管理コンソールで「変更のアクティブ化」をクリックして、編集セッションを完了します。

  4. 管理コンソールで「ロックして編集」をクリックして、別の編集ロックを取得します。

  5. ステップ2で作成したシステム・リソースを使用するアプリケーションをデプロイします。管理コンソールからアプリケーションをデプロイする方法については、Oracle WebLogic Server管理コンソール・ヘルプアプリケーションおよびモジュールのデプロイに関する項を参照してください。

詳細は、『Oracle WebLogic Serverアプリケーションの開発』のJava EEライブラリおよびオプション・パッケージの概要に関する項を参照してください。

サーバー、クラスタ、および仮想ホストへのデプロイメントのターゲット指定

ほとんどの本番環境では、通常、WebLogic Serverドメインに構成されている1つまたは複数の管理対象サーバーにアプリケーションをデプロイします。場合によっては、サーバーがWebLogic Serverクラスタに含まれていたり、仮想ホストがWebアプリケーションのリクエストの転送に使用されていることがあります。デプロイメント・ターゲットとは、アプリケーションまたはモジュールをデプロイできるサーバーまたはサーバーの集合のことです。

デプロイメント・ターゲットについて

デプロイメント・ターゲットとは、アプリケーションまたはスタンドアロン・モジュールをデプロイするサーバーまたはサーバーのグループです。デプロイメント・プロセス中に、ドメインで構成されている使用可能なターゲットからターゲットのリストを選択します。モジュールをデプロイした後でターゲットのリストを変更できます。

次の表では、WebLogic Serverのすべての有効なデプロイメント・ターゲットについて説明し、各ターゲットにデプロイできるモジュールの種類を示します。

表6-1 WebLogic Serverのデプロイメント・ターゲット

ターゲット・タイプ 説明 有効なデプロイメント

WebLogic Serverインスタンス

単一サーバー・ドメインの管理サーバー、管理対象サーバーなどのWebLogic Serverインスタンス。

Java EEアプリケーション

Java EEモジュール

JMS、JDBC、またはWLDFモジュール

Java EEライブラリ

クラスタ

複数のWebLogic Serverインスタンスの構成済みクラスタ。

Java EEアプリケーション

Java EEモジュール

JMS、JDBC、またはWLDFモジュール

Java EEライブラリ

仮想ホスト

特定のDNS名に対するリクエストをWebLogic Serverインスタンスまたはクラスタにルーティングする、構成済のホスト名。詳細は、『Oracle WebLogic Serverサーバー環境の構成』の仮想ホスティングの構成に関する項を参照してください。

Webアプリケーション

JMSサーバー

WebLogic Serverドメインで構成されているJMSサーバー。

JMSモジュール内に定義されているJMSキューまたはトピック*

*スタンドアロン・アプリケーション・モジュールとしてデプロイされた場合、JMS、JDBC、またはWLDFリソースは、管理コンソールではJava EEデプロイメントとして表示されます。

スタンドアロンのJMSアプリケーション・モジュールは、サーバー、クラスタ、または仮想ホストのターゲットに割り当てることができます。JMSモジュール内で定義されているキューおよびトピックは、さらに、構成済JMSサーバーに割り当てることができます。サブモジュールのターゲット指定の詳細については、「JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用」を参照。


1つまたは複数のターゲットへのデプロイ

1つのWebLogic Serverターゲットにデプロイするには、weblogic.Deployer-targetsオプションの後に、構成済みのターゲット名を指定します。たとえば、companyHostという名前の構成済み仮想ホストにWebアプリケーションをデプロイするには、次のコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -deploy -targets companyHost c:\localfiles\myWebApp.ear

複数のターゲットは、カンマ区切りのリストを使用して指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -deploy -targets ManagedServer-1,ManagedServer-2 
   c:\localfiles\myapp.ear

クラスタ・ターゲットへのデプロイ

(-targets myclusterを使用して)クラスタ・ターゲットを指定すると、WebLogic Serverはデフォルトでクラスタ内のすべてのサーバー・インスタンスをターゲットに指定します。これは、ほとんどのクラスタにおいて薦められる均質なモジュール・デプロイメントに対応しています。クラスタ内の1つのサーバーのみにモジュールをデプロイする(モジュールをサーバーに「固定」する)場合は、ターゲットとして、クラスタではなく個別のサーバー・インスタンス名を指定します。このタイプのデプロイメントは一般的ではなく、固定されたサービスが必須とされる特別な状況においてのみ行うようにする必要があります。詳細は、『Oracle WebLogic Serverクラスタの使用』のクラスタの構成およびアプリケーション・デプロイメントに関する項を参照してください。


注意:

クラスタ内の(1つのサーバーではなく)複数のサーバー・インスタンスのサブセットにデプロイメントを固定することはお薦めできません。その場合は警告メッセージが生成されます。


アプリケーションをクラスタ・ターゲットにデプロイする場合、WebLogic Serverは必ず、クラスタのすべての使用可能なメンバーにデプロイメントを正常にデプロイします。クラスタ内の使用可能なWebLogic Serverインスタンスのうち、アプリケーションをデプロイできないインスタンスが1つでもあると、デプロイメント全体が失敗して、クラスタ内のどのサーバーもそのアプリケーションを起動しません。つまり、デプロイメント処理は1つの論理単位として成功または失敗するので、クラスタにおける均一なデプロイメントが維持されます。

クラスタリングされたサーバーが、(管理サーバーと管理対象サーバーの間にネットワーク障害がある、クラスタ・メンバーが停止しているなどの理由で)デプロイメントの時点でアクセス不能である場合、そのサーバーは、ネットワーク接続が回復するまでデプロイメント・リクエストを受信しません。このデフォルトの動作によって、サーバーがオフラインに置かれている場合でも、ほとんどのデプロイメント処理が成功します。

すべての構成済みクラスタ・メンバーへの一貫性のあるデプロイメントの強制

デフォルトのクラスタ・デプロイメントの動作では、デプロイメントの時点でアクセス可能なすべてのクラスタリング・サーバー・インスタンスに対する、均一なデプロイメントが保証されます。ただし、ネットワークの停止が原因で、管理サーバーが1つまたは複数のクラスタリング・サーバーにアクセスできない場合、それらのサーバーは、ネットワーク接続が回復するまで、デプロイメント・リクエストを受信しません。再デプロイメント処理の場合、この動作は、アクセス不能なサーバーがデプロイ済みアプリケーションの古いバージョンを使用する一方で、アクセス可能なサーバーは新しいバージョンを使用するという状況につながる可能性があります。ネットワーク接続が回復した場合、以前に接続できなかったサーバーは、遅延した再デプロイメント・リクエストを受信して、突然アプリケーションを更新することになります。

WebLogic Serverドメインの起動時にClusterConstraintsEnabledオプションを設定すると、クラスタに対するWebLogic Serverのデフォルトのデプロイメント動作を変更することができます。ClusterConstraintsEnabledオプションは、クラスタ内に構成されているすべてのサーバーに対する、厳密なデプロイメントを強制します。クラスタ内のすべてのメンバーがアクセス可能で、指定したファイルをデプロイできる場合にのみ、クラスタへのデプロイメントが成功します。


警告:

非常に信頼性の高いネットワーク構成を備えていて、すべてのクラスタ・メンバーが常にデプロイメントおよび再デプロイメント・リクエストを受信できる場合以外は、ClusterConstraintsEnabledオプションを使用しないでください。ClusterConstraintsEnabledを使用する場合、使用不能なクラスタリング・サーバーがあると、たとえば、保守のために1つでもサーバーが停止していると、WebLogic Serverではクラスタへのすべてのデプロイメント処理が失敗します。


管理サーバーの起動時にドメインにClusterConstraintsEnabledを設定するには、適切な起動引数を指定します。

  • -DClusterConstraintsEnabled=true - ドメイン内のサーバーに対する厳密なクラスタ・デプロイメントを強制します。

  • -DClusterConstraintsEnabled=false - すべての使用可能なクラスタ・メンバーがアプリケーションまたはモジュールをデプロイするようにします。使用不能サーバーが、使用可能なクラスタリング・インスタンスへの正常なデプロイメントを妨げることはありません。これは、WebLogic Serverのデフォルトのデプロイメント動作に相当します。

モジュール・レベルのターゲット指定を使用したエンタープライズ・アプリケーションのデプロイ

エンタープライズ・アプリケーション(EARファイル)は、他のモジュール・タイプ(WARおよびJARアーカイブ)を含むことができるため、他のデプロイメント・ユニットとは異なります。管理コンソールを使用してエンタープライズ・アプリケーションをデプロイする場合は、アーカイブのすべてのモジュールを1つのデプロイメント・ユニットとして一緒に割り当てることも、個々のモジュールを別々のサーバー、クラスタ、または仮想ホストに割り当てるもできます。

モジュール・レベルのターゲット指定を使用して、EAR内にあるモジュールのサブセットのみをデプロイすることもできます。複数のモジュールを1つの配布可能なEARにパッケージ化し、各ドメインに必要なモジュールのみを割り当てることによって、アプリケーションのパッケージ化と配布を簡素化することができます。

モジュールターゲット指定の構文

エンタープライズ・アプリケーション内の個々のモジュールを割り当てるには、module_name@target_name構文を使用します。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name myEnterpriseApp
   -targets module1@myserver1,module2@myserver2,module3@myserver3 
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

Webアプリケーション・モジュールのターゲット指定

.earファイルの一部であるWebアプリケーション・モジュールを割り当てるには、Webアプリケーションのcontext-root名をモジュール名として使用するか、web-uriを指定します。

たとえば、myEnterpriseApp.earファイルのapplication.xmlファイルで次のように定義されている場合は、

<module>
  <web>
    <web-uri>myweb.war</web-uri>
    <context-root>/welcome</context-root>
  </web>
</module>

context-root名を使用してWebアプリケーション・モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name mywebapplication -targets /welcome@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

web-uriを使用して、Webアプリケーション・モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name mywebapplication -targets myweb.war@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

WebアプリケーションをデフォルトWebアプリケーションとしてデプロイするには、context-root要素の値を「/」に設定します。たとえば、myEnterpriseApp.earファイルのapplication.xmlファイルで次のように定義されている場合は、

<module>
  <web>
    <web-uri>myweb.war</web-uri>
    <context-root>/</context-root>
  </web>
</module>

context-root名を使用してWebアプリケーション・モジュールのみをデプロイできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name mywebapplication -targets /@myserver1
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

モジュールの起動と停止

各子モジュールは、次の手順を実行すると起動または停止できます。

java weblogic.Deployer -username weblogic -password weblogic -adminurl 
t3://localhost:7001 -name appName -start -targets moduls1@myserver1

java weblogic.Deployer -username weblogic -password weblogic -adminurl 
t3://localhost:7001 -name appName -stop -targets moduls1@myserver1

注意:

モジュールに依存関係がある場合、本番環境でのモジュールの起動および停止に関する注意を参照してください。


JDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイ

スタンドアロンのJDBC、JMS、およびWLDFアプリケーション・モジュールは、スタンドアロンのJava EEモジュールと同様にデプロイできます。スタンドアロンのJDBC、JMS、またはWLDFアプリケーション・モジュールの場合、ターゲットのリストによって、モジュールを利用できるWebLogic Serverドメインが決定されます。アプリケーション・モジュール内で指定したJNDI名はグローバル名としてバインドされ、クライアントから使用可能になります。たとえば、スタンドアロンのJDBCアプリケーション・モジュールを1つのサーバー・ターゲットにデプロイした場合、そのJDBCモジュールで定義されているリソースを必要とするアプリケーションは、同じサーバー・インスタンスにのみデプロイできます。アプリケーション・モジュールを複数のサーバーに割り当てることも、WebLogic Serverクラスタに割り当てて他のサーバーでリソースを使用できるようにすることもできます。

JDBC、JMS、またはWLDFリソースをドメイン内のすべてのサーバーで使用できるようにする必要がある場合は、デプロイ可能なアプリケーション・モジュールではなく、システム・モジュールを作成します。『Oracle WebLogic Server JMSの構成と管理』のJMSシステム・リソースの構成に関する項、『Oracle WebLogic Server JDBCの構成と管理』のWebLogic JDBCリソースの構成に関する項および『Oracle WebLogic Server診断フレームワークの構成と使用』の診断システム・モジュールの構成に関する項を参照してください。


注意:

JMSモジュールをデプロイしても、必ずしもそのモジュールが適切に割り当てられてアクティブになり、JNDI名が使用可能になっているとは限りません。JMSモジュールが適切に割り当てられるまで、JNDI名は使用可能になりません。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMSリソースの構成に関する項を参照してください。


アプリケーション・スコープのJMS、JDBC、およびWLDFモジュールのターゲット指定

JMS、JDBC、およびWLDFアプリケーション・モジュールは、アプリケーション・スコープのリソース・モジュールとして、エンタープライズ・アプリケーションに含まれる場合もあります。必要に応じて、デプロイメント時にモジュール・レベルのターゲット指定構文を使用して、アプリケーション・スコープのリソース・モジュールを、他のEARモジュールとは別に割り当てることができます。例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name myEnterpriseApp
   -targets myWebApp@myCluster,myJDBCModule@myserver1,myEJBModule@myserver1 
   -stage -deploy c:\localfiles\myEnterpriseApp.ear

JMSアプリケーション・モジュールにおけるサブモジュールのターゲット指定の使用

JMSアプリケーション・モジュールの内部で定義されている特定のJMSリソースを、そのモジュールのターゲットで使用可能になっているJMSサーバーに、デプロイメント時にさらに割り当てることができます。このようなリソースをサブモジュールといいます。次のタイプのサブモジュールはJMSサーバーにデプロイする必要があります。

  • キュー

  • トピック

他のサブモジュールは、JMSサーバーに加えて、WebLogic Serverインスタンスやクラスタに割り当てることができます。

  • 接続ファクトリ

  • 外部サーバー

  • SAFインポート済み宛先

  • 共通分散トピック

  • 共通分散キュー

デプロイメント時またはアンデプロイメント時にサブモジュールのターゲットを指定するには、モジュールターゲット指定の構文を拡張して、weblogic.Deployer-submoduletargetsオプションを指定する必要があります。

デフォルトのサブモジュールのターゲット指定

『Oracle WebLogic Server JMSの構成と管理』のJMSモジュールとリソースのサブデプロイメントのターゲット指定に関する項で説明されているように、管理コンソールからデプロイするときに、WebLogic Serverは、JMSアプリケーション・モジュール内のサブモジュール用に、デフォルトのJMSサーバー・ターゲットを選択します。

WLSTを使用してサブモジュールをデプロイするときには、以下のすべての条件が満たされる場合に、親モジュールのターゲットをJMSリソースのデフォルトのターゲットとして使用できます。

  • アプリケーションに1つまたは複数のJMSモジュールが含まれています。

  • モジュール・ターゲットに関連付けられたJMSサーバー・インスタンスが1つのみ存在します。

  • -submoduletargetsオプションが指定されていません。

  • defaultSubmoduleTargetsオプションがtrueです。

『WebLogic Scripting Tool』のデプロイメント・コマンドに関する項を参照してください。

スタンドアロンのJMSモジュールにおけるサブモジュールのターゲット指定

スタンドアロンのJMSモジュールの場合、サブモジュールのターゲット指定の構文は-submoduletargets submodule_name@target_nameになります。たとえば、1つのサーバー・インスタンスにスタンドアロンのJMSモジュールをデプロイする場合、JMSServer1というJMSサーバーにサブモジュールmyQueueを割り当てるには、次のコマンドを入力します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name myJMSModule
   -targets ManagedServer1 -submoduletargets myQueue@JMSServer1
   -deploy c:\localfiles\myJMSModule.xml

同じJMSモジュールをアンデプロイするには、次のコマンドを入力します。このコマンドでは、myJMSModuleの中に複数のサブモジュールがあると想定し、myQueueサブモジュールのみをアンデプロイします。他のサブモジュールは影響を受けません。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name myJMSModule
   -undeploy -submoduletargets myQueue@JMSServer1

アプリケーション・スコープのJMSモジュールにおけるサブモジュールのターゲット指定

EAR内のアプリケーション・スコープのJMSモジュールの場合は、submodule_name@module_name@target_nameという構文を使用して、サブモジュールを割り当てます。たとえば、上記の例のキューがエンタープライズ・アプリケーションの一部としてパッケージ化されている場合は、次のコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name myEnterpriseApp
   -targets ManagedServer1 -submoduletargets myQueue@myJMSModule@JMSServer1
   -deploy c:\localfiles\myEnterpriseApp.ear

同じJMSモジュールをアンデプロイするには、次のコマンドを入力します。このコマンドでは、myEnterpriseAppの中に複数のサブモジュールがあると想定し、myQueueサブモジュールのみをアンデプロイします。他のサブモジュールは影響を受けません。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name myEnterpriseApp
   -undeploy -submoduletargets myQueue@myJMSModule@JMSServer1

警告:

アプリケーション・スコープのリソースを含むアプリケーションをアンデプロイすると、そのリソースはアプリケーションと一緒に削除されます。そのため、JMS宛先の削除が原因で、トランザクションが破棄されたり、メッセージが失われたりする可能性があります。詳細は、『Oracle WebLogic Server JTAのプログラミング』のリソース登録解除の猶予期間に関する項を参照してください。

完全に削除するアプリケーションのみをアンデプロイするようにしてください。アプリケーションへのクライアント・アクセスを一時的に停止するには、「weblogic.Deployerコマンド・ライン・リファレンス」で説明するように、-stopコマンドを使用します。


JMSサブデプロイメントの詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMSモジュールとリソースのサブデプロイメントのターゲット指定に関する項を参照してください。

ステージング・モードによるデプロイメント・ファイルのコピーの制御

デプロイメントのステージング・モードにより、デプロイメント・ファイルを、アプリケーションまたはスタンドアロン・モジュールをデプロイする必要があるターゲット・サーバーから使用できるようにする方法が決まります。WebLogic Serverのステージング・モードには、stageモード、nostageモード、external_stageモードの3種類があります。

ステージング・モードとベスト・プラクティス

次の表では、デプロイメント・ステージング・モード別にそのモードを使用する場合の動作とベスト・プラクティスについて説明します。

表6-2 アプリケーション・デプロイメントのステージング・モード

デプロイメントのステージング・モード 動作 使用するタイミング

stage

管理サーバーは最初にデプロイメント・ユニットのソース・ファイルをターゲット・サーバーのステージング・ディレクトリにコピーします。(ステージング・ディレクトリはデフォルトでstageという名前であり、ターゲット・サーバーのルート・ディレクトリにあります。)

ターゲット・サーバーは次にデプロイメント・ファイルのローカル・コピーを使用してデプロイします。

  • 小さいサイズまたは中程度のサイズのアプリケーションを複数のWebLogic Serverインスタンスにデプロイする場合。

  • 小さいサイズまたは中程度のサイズのアプリケーションをクラスタにデプロイする場合。

nostage

管理サーバーはデプロイメント・ユニット・ファイルをコピーしません。代わりに、すべてのサーバーで同じデプロイメント・ファイルの物理コピーを使用してデプロイします。それらのファイルは、管理サーバーとターゲット・サーバーから直接アクセス可能でなければなりません。

展開されたアーカイブ・ディレクトリのnostageモード・デプロイメントでは、WebLogic ServerはデプロイメントのJSPまたはサーブレットに対する変更を自動的に検出し、デプロイメントをリフレッシュします。(この動作は必要に応じて無効にできます。)

  • 単一サーバー・ドメインにデプロイする場合。

  • 複数のホームがあるマシン上のクラスタにデプロイする場合。

  • 使用可能なデプロイメント・ファイルが共有ディレクトリにある複数のターゲットまたはクラスタに、非常に大きいアプリケーションをデプロイする場合。

  • 内容変更後、定期的に再デプロイする展開されたアーカイブ・ディレクトリをデプロイする場合。

  • 管理コンソールを通じて選択されたデプロイメント記述子の動的更新を必要とするデプロイメント。

external_stage

管理サーバーはデプロイメント・ファイルをコピーしません。そのかわりに、デプロイメントの前に、(たとえば、デプロイメントの前に手動でファイルをコピーするなどして)デプロイメント・ファイルが正しいステージング・ディレクトリの位置にコピーされていることを管理者が確認する必要があります。

external_stageデプロイメントでは、管理サーバーは検証用にデプロイメント・ファイルのコピーを必要とします。ターゲット・サーバーのステージング・ディレクトリ内に存在するデプロイメント・ファイルのコピーは、デプロイメントの前には検証されません。

-noversionオプションを使用すると、デプロイメント・ファイルが管理サーバー上にあるという要件を無効にできます。ただし、-noversionオプションを使用するとバージョン情報は無視されるので、バージョン管理されているアプリケーションでは-noversionオプションを使用できません。詳細については、「共通の引数」を参照。

  • デプロイメント・ファイルのターゲット・サーバーへの配布を手動で制御するデプロイメント。

  • デプロイメント・ファイルを正しいステージング・ディレクトリにコピーするようにサード・パーティのアプリケーションまたはスクリプトで管理しているドメインにデプロイする場合。

  • 管理コンソールを通じて選択されたデプロイメント記述子の動的更新(external_stageモードではサポートされない)を必要としないデプロイメント。

  • アプリケーション・コンポーネントの部分的な再デプロイを必要としないデプロイメント。


サーバーのステージング・ディレクトリは、管理サーバーがstageモード・デプロイメント用のデプロイメント・ファイルをコピーするディレクトリです。また、external_stageモードを使用してアプリケーションをデプロイする前には、このディレクトリにデプロイメント・ファイルが配置されている必要があります。

ほとんどのデプロイメントでは、stageモードまたはnostageモードを使用します。アプリケーションまたはモジュールをデプロイするときに、WebLogic Serverのデプロイメント・ツールは適切なモードを使用します。たとえば、weblogic.DeployerまたはWLSTを使用してWebLogic Serverでアプリケーションをデプロイするとき、stageモードを指定しない場合、デフォルトのstageモードが使用されます。管理サーバーでは、デフォルトのstageモードはnostageで、管理対象サーバーではstageです。

以下の節では、アプリケーションまたはモジュールをデプロイするときに、デプロイメントのステージング・モードを明示的に設定する方法について説明します。

nostageモードのデプロイメントの使用

nostageモードでは、管理サーバーはアーカイブ・ファイルをソース位置からコピーしません。かわりに、各ターゲット・サーバーは、デプロイメント用の単一のソース・ディレクトリにあるアーカイブ・ファイルにアクセスする必要があります。nostageデプロイメントでは、ターゲット・サーバーのステージング・ディレクトリは無視されます。

たとえば、Java EEアプリケーションをクラスタ内の3つのサーバーにデプロイする場合、アプリケーションをデプロイするには各サーバーが(共有またはネットワーク・マウント・ディレクトリの)同じアプリケーション・アーカイブ・ファイルにアクセスできる必要があります。


注意:

nostageモードでは、デプロイメント・ファイルのソースは、デプロイ時にユーザーが指定するパスです(これに対し、stageモードでは各サーバーのステージング・ディレクトリのパスがソースになります)。ただし、WebLogic Serverは、nostageモードの場合でもデプロイメント・ファイルの一部を一時ディレクトリにコピーします。このため、ユーザーがアーカイブ形式デプロイメントの全体または一部を更新することが可能です。


nostageモードでは、Webアプリケーション・コンテナがJSPおよびサーブレットに対する変更を自動的に検出します。また、アプリケーションの一部のみを後から更新することもできます。そのためには、該当する部分をファイル・システムの1つの位置で更新し、再デプロイします。

管理コンソールでは、管理サーバーのみにデプロイする場合(単一サーバー・ドメインの場合など)のデフォルト・モードとしてnostageモードが使用されます。weblogic.Deployerではターゲット・サーバーのステージング・モードを使用し、管理サーバーではnostageモードをデフォルトで使用します。同じマシンでサーバー・インスタンスのクラスタを実行する場合、または共有ディレクトリにアクセスできる複数のマシンに非常に大きいアプリケーションをデプロイする場合も、nostageモードを選択できます。非常に大きいアプリケーションをnostageモードでデプロイすると、ファイルがコピーされないため、デプロイ時間を短縮できます。

nostageモードの構文

nostageモードを使用するには、weblogic.Deployerのオプションとして-nostageを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name mydeploymentname 
   -targets myserver1,myserver2,myserver3 -nostage 
   -deploy c:\localfiles\myapp.ear

stageモードのデプロイメントの使用

stageモードでは、管理サーバーはマシンの元の位置から各ターゲット・サーバーのステージング・ディレクトリにデプロイメント・ファイルをコピーします。たとえば、stageモードを使用してクラスタ内の3つのサーバーにJava EEアプリケーションをデプロイする場合、管理サーバーは3つのサーバー・マシンのそれぞれのディレクトリにデプロイメント・ファイルをコピーします。各サーバーは、アーカイブ・ファイルのローカル・コピーを使用してJava EEアプリケーションをデプロイします。

ステージング・ディレクトリにファイルをコピーするときに、管理サーバーはデプロイメント名と同名のサブディレクトリを作成します。そのため、次のコマンドを使用してデプロイした場合、

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name mytestear -stage -targets mycluster 
   -deploy c:\Oracle\Middleware\wlserver_12.1\samples\server\medrecd\dist\physicianEar

myclusterの各サーバーのステージング・ディレクトリに新しいディレクトリmytestearが作成されます。デプロイメント名を指定しないと、次のようにデフォルトのデプロイメント名(およびステージング・サブディレクトリ)が使用されます。

  • 展開されたアーカイブ・デプロイメントの場合、デプロイメント名およびステージング・サブディレクトリはデプロイするディレクトリの名前になります(上の例ではphysicianEar)。

  • アーカイブされたデプロイメントの場合、デフォルトのデプロイメント名はアーカイブ・ファイルの名前から拡張子を除いた名前になります(たとえば、physicianEar.earをデプロイする場合のデプロイメント名とステージング・サブディレクトリはphysicianEar)。

管理コンソールでは、複数のWebLogic Serverインスタンスにデプロイする場合のデフォルト・モードとして、stageモードを使用します。weblogic.Deployerではデフォルトとしてターゲット・サーバーのステージング・モードを使用し、管理対象サーバーではデフォルトでstageモードを使用します。

stageモードでは、ネットワーク停止により管理サーバーがアクセス不能になった場合でも、各サーバーがデプロイメント・ファイルのローカル・コピーを持つことが保証されます。ただし、非常に大きいアプリケーションを複数のサーバー、またはクラスタにデプロイする場合は、ターゲット・サーバーへのファイルのコピーに要する時間がかなり長くなることがあります。大きいファイルを複数のサーバーにコピーすることによるオーバーヘッドを防ぐには、nostageモードを検討してください。

stageモードの構文

stageモードを使用するには、weblogic.Deployerのオプションとして-stageを指定します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
   -password weblogic -name mydeploymentname 
   -targets myserver1,myserver2,myserver3 -stage 
   -deploy c:\localfiles\myapp.ear

external_stageモードのデプロイメントの使用

external_stageモードではstageモードと同様に、ターゲット・サーバーはデプロイメント・ファイルのローカル・コピーを使用してデプロイします。ただし、external_stageモードでは、管理サーバーはターゲット・サーバーにデプロイメント・ファイルを自動的にコピーしません。そのため、デプロイメントの前に、各ターゲット・サーバーのステージング・ディレクトリにファイルをコピーする必要があります。手動でコピーすることも、自動化スクリプトを使用することもできます。

デプロイメント・ファイルは、各ターゲット・サーバーのステージング・ディレクトリ内で、デプロイメント名を反映した名前を持つサブディレクトリに格納されている必要があります。この名前は、デプロイメントに対してユーザーが入力する名前、またはデフォルトのデプロイメント名(展開されたアーカイブ・ディレクトリの名前、またはアーカイブ・ファイル名からファイル拡張子を除いた名前)のどちらでもかまいません。

external_stageモードは、使用することが少ないデプロイメント・ステージング・モードです。このモードは、通常、必要なファイルの自動コピーをサード・パーティのツールによって管理している環境でのみ使用します。非常に大きいアプリケーションを複数のマシンにデプロイする場合で共有ファイル・システムがない(nostageモードを使用できない)場合も、external_stageモードを使用できます。このような場合にexternal_stageモードを使用すると、デプロイメント時にファイルがコピーされないため、デプロイメントにかかる時間を短縮できます。

-noversionオプションを使用すると、デプロイメント・ファイルが管理サーバー上にあるという要件を無効にすることができます。ただし、-noversionオプションを使用するとバージョン情報は無視されるので、バージョン管理されているアプリケーションでは -noversionオプションを使用できません。詳細については、「共通の引数」を参照。

external_stageモードの構文

external_stageモードでアプリケーションをデプロイするには:

  1. デプロイメント・ファイルが管理サーバーからアクセス可能であることを確認します。「リモート・クライアントからのデプロイメント・ファイルのアップロード」を参照してください。

  2. デプロイメントのターゲット・サーバーごとに、デプロイメント名と同じ名前のサブディレクトリをステージング・ディレクトリに作成します。たとえば、デプロイメント名としてmyEARExternalを指定する場合は、各ターゲット・サーバーのステージング・ディレクトリにmyEARExternalというサブディレクトリを作成します。


    注意:

    デプロイメント時にデプロイメント名を指定しない場合、WebLogic Serverによってデフォルトの名前が選択されます。詳細は、「デフォルト・デプロイメント名について」を参照してください。


  3. 本番再デプロイメントで使用するためにバージョン管理されたアプリケーションをデプロイする場合は、デプロイするアプリケーションのバージョンに対応するサブディレクトリを、アプリケーション・ディレクトリの下に作成します。たとえば、myEARExternalをバージョン・レベル2.0Betaでデプロイする場合、各ターゲット・サーバーのmyEARExternal\2.0Betaというステージング・ディレクトリに、デプロイメント・ファイルを置く必要があります。

  4. 上記のステップ2または3で作成したステージング・サブディレクトリにデプロイメント・ファイルをコピーします。

  5. weblogic.Deployerユーティリティを使用してアプリケーションまたはモジュールをデプロイします。例:

java weblogic.Deployer -adminurl http://localhost:7001 -name weblogic
   -password weblogic -external_stage -name myEARExternal 
   -deploy c:\myapps\myear

サーバーのデフォルト・ステージング動作の変更

サーバーのステージング・モードは、デプロイ時に指定されたモードがない場合のデフォルトのデプロイメント・モードになります。たとえば、weblogic.Deployerを使用してアプリケーションまたはスタンドアロン・モジュールをデプロイするときにステージング・モードを指定しなかった場合、サーバーのステージング・モードが使用されます。デフォルトのステージング・モードは、管理サーバーではnostageで、管理対象サーバーではstageです。


注意:

サーバーのステージング・モードは、管理コンソールを使用するか、JMXを通じてServerMBeanを直接変更することによってのみ、変更できます。

サーバーのステージング・モードを変更しても、既存のアプリケーションには影響しません。既存のアプリケーションのステージング・モードを変更するには、アプリケーション・デプロイメントをアンデプロイしてから、新しいステージング・モードで再デプロイする必要があります。


管理コンソールを使用してサーバーのステージング・モードを設定するには、Oracle WebLogic Server管理コンソール・ヘルプサーバーのステージング・モードの設定に関する項の手順に従ってください。ステージング・モードの詳細は、表6-2を参照してください。

本番環境へのアプリケーションの配布

アプリケーションの分散とは、デプロイメント・ファイルをすべてのターゲット・サーバーにコピーして検証し、アプリケーションをデプロイメントの準備が整った状態にすることです。アプリケーションを分散したら、そのアプリケーションを管理モードで起動できます。管理モードでは、アプリケーションに対するアクセスが構成済の管理チャネルに制限されるので、外部のクライアント接続にアプリケーションを公開せずに、アプリケーションを本番環境に分散(またはアプリケーションの新しいバージョンを分散)できます。

管理モードの間は、構成済の管理チャネル経由でのみアプリケーションに接続できます。したがって、アプリケーションの最終(状態)チェックを、クライアントを中断させることなく本番環境で直接実行できます。最終テストを行ったら、アプリケーションをアンデプロイしてさらに変更を加えることも、アプリケーションを起動して一般のクライアントから利用できるようにすることもできます。

-adminmodeオプションを使用すると、アプリケーションを管理モードで起動できます。詳細は、「配布されたアプリケーションの管理モードでの起動」を参照してください。

WebLogicドメインを超えてデポロイする場合、CrossDomainConnectorロールにより、外部のドメインからドメイン間の呼び出しを実行することができます。すべてのセキュリティ・ロールの完全なリストは、『Oracle WebLogic Serverロールおよびポリシーによるリソースの保護』のデフォルトのグローバル・ロールに関する項を参照してください。

アプリケーションの配布

アプリケーションを配布するには、次の示すようにweblogic.Deployer -distributeコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
     -password weblogic -distribute -name myTestDeployment
     /myDeployments/myApplication/

配布されたアプリケーションの管理モードでの起動

WebLogic Serverがデプロイメント・ファイルを配布したら、アプリケーションを管理モードで起動して、構成済の管理チャネル経由でアプリケーションへのアクセスやテストを行えるようにします。管理チャネルを構成する方法は、『Oracle WebLogic Serverサーバー環境の構成』のネットワーク・リソースの構成に関する項を参照してください。

配布されたアプリケーションを管理モードで起動するには、-adminmodeオプションを指定して-startコマンドを使用します。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
     -password weblogic -start -adminmode -name myTestDeployment
     /myDeployments/myApplication/

配布されたアプリケーションの起動

構成済の管理チャネルを使用して配布されたアプリケーションの最終テストを行ったら、-adminmodeオプションを指定せずにweblogic.Deployer -startコマンドを使用して、アプリケーションを新しいクライアント接続にオープンできます。

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
     -password weblogic -start -name myTestDeployment

共有Java EEライブラリおよびそれに依存するアプリケーションのデプロイ

WebLogic ServerのJava EEライブラリのサポートにより、複数のエンタープライズ・アプリケーション間で、1つまたは複数のJava EEモジュールまたはJARファイルを簡単に共有できます。Java EEライブラリは、スタンドアロンのJava EEモジュール、エンタープライズ・アプリケーション(EAR)内にパッケージ化された複数のJava EEモジュール、またはデプロイメント時にJava EEアプリケーション・コンテナに登録されるプレーンなJARファイルです。Java EEライブラリが登録されると、そのライブラリを参照するエンタープライズ・アプリケーションをデプロイできます。参照側の各アプリケーションは、デプロイメントの際に共有Java EEライブラリ・モジュールのコピーを受け取り、アプリケーション自体の一部としてパッケージ化されているかのように、これらのモジュールを使用できます。


注意:

OracleのドキュメントとWebLogic Serverユーティリティでは、ライブラリという語をJava EEライブラリとオプション・パッケージの両方の意味で使用します。必要な場合にのみオプション・パッケージと呼びます。


共有ライブラリに対するデプロイメント動作について

WebLogic Serverでは、参照側アプリケーションがデプロイされるときに共有ファイルと参照側アプリケーションをマージすることによって、共有Java EEライブラリをサポートしています。

まず、Java EEライブラリをデプロイして、そのデプロイメントがライブラリであることを示すことによって、1つまたは複数のWebLogic ServerインスタンスまたはクラスタにJava EEライブラリまたはオプション・パッケージを登録します(「WebLogic Serverでのライブラリの登録」を参照)。ライブラリまたはパッケージをデプロイしても、そのデプロイメントは必ずしもターゲット・サーバー上でアクティブになりません。かわりに、WebLogic Serverがデプロイメント・ファイルをターゲット・サーバーに配布し(nostageデプロイメント・モードが使用されている場合)、デプロイメント・ファイルの場所、デプロイメント名、ライブラリまたはパッケージのバージョン文字列情報などを記録します。

共有ライブラリまたはパッケージを参照するアプリケーションがデプロイされると、WebLogic Serverは名前とバージョン文字列の要件を、サーバーに登録済みのライブラリに照らしてチェックします。ライブラリまたはパッケージ名に完全に一致するものが見つからない場合、またはバージョン要件が満たされない場合、そのアプリケーションのデプロイメントは失敗します。

アプリケーションで参照されているすべてのライブラリと名前およびバージョン文字列が一致するものが見つかったら、WebLogic Serverはそのライブラリのクラスを参照側アプリケーションのクラスパスに追加し、メモリー内でアプリケーションとライブラリの両方のデプロイメント記述子を結合します。結果としてデプロイされるアプリケーションは、参照されるライブラリがアプリケーションそのものにバンドルされているかのように見えます。

Java EEライブラリの内容は、エンタープライズ・アプリケーション内の他のJava EEモジュールと同様にクラスローダーにロードされます。たとえば、EJBモジュールは参照側アプリケーションのクラスローダーの一部としてロードされますが、Webアプリケーション・モジュールはアプリケーション・クラスローダーの下のクラスローダーにロードされます。共有Java EEライブラリがEARからなる場合は、そのEARのAPP-INF/libまたはAPP-INF/classesサブディレクトリに格納されているクラスも、参照側アプリケーションから使用できるようになります。

現在デプロイされているアプリケーションによって参照されているJava EEライブラリまたはオプション・パッケージをアンデプロイすることはできません。共有ライブラリまたはパッケージをアンデプロイする必要がある場合は、まず、共有ファイルを使用するすべてのアプリケーションをアンデプロイしてください。定期的なアプリケーションの保守作業では、共有ライブラリまたはパッケージの新しいバージョンをデプロイしてから、共有ファイルの新しいバージョンを使用するために参照側アプリケーションを再デプロイする必要があります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有ライブラリのマニフェスト属性の編集に関する項を参照してください。

WebLogic Serverでのライブラリの登録

共有Java EEライブラリは、WebLogic Serverコンテナにライブラリとして登録されている、標準のJava EEモジュールまたはエンタープライズ・アプリケーションです。Java EEライブラリをWebLogic Serverコンテナに登録するには、次の手順を実行します。

  1. 操作するデプロイメント・ファイルが有効なJava EEライブラリまたはオプション・パッケージであることを確認します。『Oracle WebLogic Serverアプリケーションの開発』の共有Java EEライブラリの作成に関する項を参照してください。

  2. ライブラリまたはパッケージを登録するWebLogic Serverターゲットを選択します。共有ライブラリは、参照側アプリケーションをデプロイするのと同じWebLogic Serverインスタンスに登録する必要があります(後で必要に応じて参照側アプリケーションをデプロイできるように、ドメイン内のすべてのサーバーにライブラリをデプロイしてもかまいません)。

  3. ライブラリまたはパッケージを登録します。それには、選択したターゲット・サーバーにファイルをデプロイし、-libraryオプションで、そのデプロイメントをライブラリまたはパッケージとして指定します。例:

    java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
         -password weblogic -deploy -targets myserver1,myserver2
         -library /deployments/myLibraryApplication/
    

デプロイメント時のライブラリのバージョン指定

ベスト・プラクティスとして、開発チームでは常に、ライブラリまたはオプション・パッケージのバージョン文字列情報を、デプロイメントのマニフェスト・ファイルに含めるようにしてください。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有ライブラリのマニフェスト属性の編集に関する項を参照してください。

バージョン文字列情報を含まないライブラリまたはパッケージをデプロイする場合は、以下のいずれかまたは両方のオプションを使用して、コマンド・ラインで指定することができます。

  • libspecver - ライブラリまたはパッケージの仕様のバージョンを定義します。

  • libimplver - ライブラリまたはパッケージの実装のバージョンを指定します。

例:

java weblogic.Deployer -adminurl http://localhost:7001 -username weblogic
     -password weblogic -deploy -targets myserver1,myserver2
     -library -libspecver 700 -libimplversion 7.0.0.1Beta 
     /deployments/myLibraryApplication/

注意:

マニフェスト・ファイルとweblogic.Deployerコマンド・ラインの両方でバージョン情報を指定して、両者の値が一致していない場合、デプロイメントは失敗します。

最初に仕様または実装のバージョンを指定しないでライブラリを登録した場合は、新しいバージョンを登録してバージョン文字列情報を指定する前に、ライブラリをアンデプロイする必要があります。

ライブラリまたはパッケージの複数のバージョンを登録できますが、各バージョンで同じバージョン文字列を使用する必要があります。たとえば、仕様のバージョンのみを持つライブラリを登録してから、仕様と実装の両方のバージョンを持つそのライブラリの新しいバージョンを登録することはできません。


ライブラリを参照するアプリケーションのデプロイ

必要なバージョンのライブラリおよびパッケージをデプロイしたら、そのライブラリを参照するエンタープライズ・アプリケーションやモジュールをデプロイできます。参照側アプリケーションを正常にデプロイするには、次の2つの条件を満たす必要があります。

  • 参照されるすべてのライブラリがアプリケーションのターゲット・サーバーに登録されています。

  • 登録されたライブラリは参照側アプリケーションのバージョン要件を満たしています。

参照側アプリケーションをデプロイする特別な構文はありません。標準のエンタープライズ・アプリケーションまたはJava EEモジュールの場合と同様にアプリケーションをデプロイします。


注意:

参照側アプリケーションは、共有ライブラリの様々なレベルのバージョン要件を指定して構成できます。


アプリケーションの構成では以下のいずれかが必要です。

  • 共有ライブラリまたはパッケージの最新バージョン(最新の登録済みバージョン)

  • ライブラリまたはパッケージの最小のバージョン(または最高のバージョン)

  • ライブラリまたはパッケージの厳密なバージョン

バージョン要件が原因で参照側アプリケーションをデプロイできない場合は、競合しているライブラリまたはパッケージの必要なバージョンを登録してみてください。または、開発チームに相談して、アプリケーションのバージョン要件を緩和できるかどうかを判断してください。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーション内のライブラリ参照に関する項を参照してください。


注意:

Webアプリケーション・コンポーネントを含むEARライブラリがある場合は、コンテキスト・パスの競合が起きるため、ライブラリを参照する複数のアプリケーションをデプロイすることはできません。これは、EARライブラリ内の個々のWebアプリケーションに対してcontext-rootを設定できないからです。context-rootはライブラリ全体に対してのみ設定できます。


詳細は、『Oracle WebLogic Serverアプリケーションの開発』のJava EEライブラリおよびオプション・パッケージの概要に関する項を参照してください。

アプリケーションのデプロイのベスト・プラクティス

アプリケーションをデプロイするときには、以下のベスト・プラクティスをお薦めします。