3 アプリケーションおよびモジュールのデプロイメント準備

次の項では、アプリケーションのデプロイメントを準備する上で必要となる重要なトピックについて説明します。

• デプロイするファイルのパッケージ化

• デフォルト・デプロイメント名について

• アプリケーションのネーミング要件について

• デプロイメント・バージョン文字列について

• アプリケーションのインストール・ディレクトリの作成

• FastSwapデプロイメントによる再デプロイメントの最小化

• デプロイメント・ファイルの準備のベスト・プラクティス

デプロイするファイルのパッケージ化

WebLogic Serverは、jarユーティリティまたはAntのjarツールを使用してアーカイブ・ファイルとしてパッケージ化されたデプロイメント、または展開されたアーカイブ・ディレクトリとしてパッケージ化されたデプロイメントをサポートしています。

注意: 一般に、アーカイブ・ファイルを使用して、より効率的に管理対象サーバー上にアプリケーションのデプロイができます。ただし、アプリケーションの再デプロイメントが必要とされるため、Webコンテンツの更新などのアプリケーションの更新がより難しくなります。

• アーカイブ・ファイルの使用

• 展開されたアーカイブ・ディレクトリの使用

• アーカイブ・ファイルからの展開されたアーカイブ・ディレクトリの作成

アーカイブ・ファイルの使用

アーカイブ・ファイルは、アプリケーションまたはモジュールのクラス、静的ファイル、ディレクトリ、およびデプロイメント記述子ファイルをすべて含む単一のファイルです。大半の本番環境において、管理者がデプロイメント用に受け取るアプリケーションは、アーカイブ・ファイルとして格納されます。

jarユーティリティを使用してパッケージ化されたデプロイメント・ユニットには、タイプ別に特定のファイル拡張子が付きます。

• EJBおよびクライアント・アーカイブは、.jarファイルとしてパッケージ化されます。

• Webアプリケーションは、.warファイルとしてパッケージ化されます。

• リソース・アダプタは、.rarファイルとしてパッケージ化されます。

• エンタープライズ・アプリケーションは.earファイルとしてパッケージ化し、EJB、JDBC、JMS、Webアプリケーション、リソース・アダプタなど他のJava EEモジュールを含めることができます。

• Webサービスは、Javaクラスを使用して実装したか、EJBを使用して実装したかに応じて、.warファイル、.jarファイルのいずれかとしてパッケージ化できます。通常、.warまたは.jarファイルは、さらにエンタープライズ・アプリケーション.earファイルにパッケージ化されます。

• Java EEライブラリは、エンタープライズ・アプリケーション(.earファイル)か、標準のJava EEモジュールとしてパッケージ化されます。

• クライアント・アプリケーションおよびオプション・パッケージは、.jarファイルとしてパッケージ化されます。

アーカイブ・ファイルに加えて、特定の環境についてアプリケーションを構成する別個のファイルである、デプロイメント・プランを受け取ることになる場合があります。デプロイメント・プランについての詳細は、「本番デプロイメントのためのアプリケーションの構成」で説明しています。

展開されたアーカイブ・ディレクトリの使用

展開されたアーカイブ・ディレクトリには、JARアーカイブと同じファイルおよびディレクトリが格納されています。展開されたアーカイブ・ディレクトリの使用を選択すると、それ以前にアーカイブされたデプロイメントを手動で復元することが必要になる場合があります。ただし、それらのファイルとディレクトリは、ファイル・システム上に直接存在し、jarユーティリティを使用して単一のアーカイブ・ファイルにパッケージ化されていません。

次のような状況下であれば、展開されたアーカイブ・ディレクトリからのデプロイを選択できます。

• デプロイメント後に、エンタープライズ・アプリケーションを部分的に更新する必要がある場合。エンタープライズ・アプリケーションを展開されたアーカイブ・ディレクトリとしてデプロイすると、アーカイブ・ファイルを再作成することなく、アプリケーションの個々のモジュールを更新しやすくなります。

• 定期的に更新される静的ファイルを含むWebアプリケーションまたはエンタープライズ・アプリケーションをデプロイする場合。この場合は、アプリケーションを展開されたディレクトリとしてデプロイする方が便利です。そうすればアーカイブを再作成せずに静的ファイルを更新とリフレッシュできるからです。

• アプリケーション・コンテキストを通じてファイル・システムに直接I/Oを実行するWebアプリケーション(たとえば、自身の一部を動的に編集または更新しようとするWebアプリケーション)をデプロイする場合。この場合、I/O操作を実行するモジュールには、操作を実行するための物理ファイル・システム・ディレクトリが必要です。仕様により、アプリケーションをアーカイブとしてデプロイする時点でファイルを取得することはできません。

デプロイメント記述子を含まない展開されたEARディレクトリをデプロイする場合のJava EEルール

Java EE仕様では、アーカイブされたEAR(エンタープライズ・アプリケーション・アーカイブ)のJava EE準拠のサーバーへのデプロイはデプロイメント記述子を使用しないで実施することをお薦めします。正常のデプロイするには、すべてのコンテナで、妥当なデフォルト値の設定か、アノテーション付きのクラスの使用が必要になります。WebLogic Serverでは、この規定のサポートの他に、デプロイメント記述子のない展開されたEARディレクトリのデプロイも可能になります。

こうしたデプロイメントがディレクトリに適用される場合、EARとそのネストされたモジュールの特定には一定のルールが使用されます。ルールにしたがっていないディレクトリは、WebLogic Server管理コンソールでもデプロイメント・ツールでも、展開された有効なJava EEディレクトリとして処理されません。

• WEB-INF/web.xml記述子のない展開されたアーカイブWebアプリケーションについては、ディレクトリ名に.war接尾辞が付いている必要があります。

• META-INF/application.xml記述子のない展開されたアーカイブ・エンタープライズ・アプリケーションについては、ディレクトリ名に.ear接尾辞が必要です。アプリケーション内では、展開されたWebモジュールのディレクトリ名に.war接尾辞が必要です。同様に、展開されたEJBモジュールには.jar接尾辞と展開されたRARモジュールには.rar接尾辞を指定する必要があります。

• 展開されたエンタープライズ・アプリケーションにMETA-INF/application.xml記述子が含まれていない場合は、モジュールのデプロイ順が未定義になり、デプロイ順が基底のFile.listFiles()メソッド順序に依存します。モジュールを特定の順序でデプロイするには、application.xml記述子を追加し、その順序でモジュールをリストする必要があります。

アーカイブ・ファイルからの展開されたアーカイブ・ディレクトリの作成

展開されたアーカイブ・ディレクトリとしてデプロイするアーカイブ・ファイルがある場合は、jarユーティリティを使用してアーカイブ・ファイルを専用ディレクトリに復元します。例:

   mkdir /myapp
   cd /myapp
   jar xvf /dist/myapp.ear

復元するアーカイブ・ファイルに他のモジュール・アーカイブ・ファイル(たとえば、JARファイルやWARファイルを含むエンタープライズ・アプリケーションまたはWebサービス)が含まれており、それらモジュールの部分的な更新を行う場合には、組み込まれたアーカイブ・ファイルも展開する必要があります。各モジュールをアーカイブ・ファイルと同じ名前のサブディレクトリに解凍する必要があります。たとえば、myejb.jarという名前のモジュールの展開したエンタープライズ・アプリケーション・ディレクトリの/myejb.jarサブディレクトリへの解凍など。

注意: 展開した.EARファイルのアーカイブ・モジュールに異なるサブディレクトリ名を使用する場合は、アプリケーション自体の中で使用しているこれらのモジュールへの参照を修正する必要があります。たとえば、manifest.mfファイルのapplication.xmlおよびCLASSPATHのエントリに指定されているURI値を更新する必要があります。

デフォルト・デプロイメント名について

初めて、1つまたは複数のWebLogic Serverインスタンスにアプリケーションまたはスタンドアロン・モジュールをデプロイする場合、デプロイメント・ファイル、ターゲット・サーバー、および選択したその他の構成オプションを総体的に記述するためにデプロイメント名を指定します。次に、デプロイメント名を使用して、すべてのターゲット・サーバー上のデプロイメント・ユニットの再デプロイまたは停止を簡単に行えます。デプロイメント名を使用することによって、ドメイン内の複数サーバー間のデプロイメント・ユニットを操作する場合のデプロイメント・ファイルおよびターゲット・サーバーの再識別が簡単に行えます。

デプロイメント時にデプロイメント名を指定しない場合、デプロイメント・ツールによってデプロイメント・ソース・ファイルに基づくデフォルトの名前が選択されます。アーカイブ・ファイルの場合、weblogic.Deployerはアーカイブ・ファイル名からファイル拡張子を抜いて使用します。たとえば、ファイルmyear.earのデフォルト・デプロイメント名は、myearとなります。展開されたアーカイブ・ディレクトリの場合、weblogic.Deployerはデプロイする最上位ディレクトリの名前を使用します。

Java EEライブラリおよびオプション・パッケージの場合、weblogic.Deployerはライブラリのマニフェスト・ファイルで指定されている名前を使用します。ライブラリのマニフェスト・ファイルで名前が指定されていなければ、-nameオプションで名前を指定できます。

アプリケーションのネーミング要件については次の「アプリケーションのネーミング要件について」を、デフォルト以外のデプロイメント名の指定については第6章「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。

アプリケーションのネーミング要件について

アプリケーションのWebLogic Serverへのデプロイを正常に実行するには、アプリケーション名が有効であることが必要です。アプリケーションのネーミング要件は、次のとおりです。

• アプリケーション名は、次の文字のみを含む必要があります。

  • a-z

  • A-Z

  • 0-9

  • _ (アンダースコア)

  • - (ハイフン)

  • . (ピリオド)

  それ以外の文字をアプリケーション名に含めることはできません。

• 文字. (ピリオド)を含むアプリケーション名には、少なくとも1つの別の文字が含まれている必要があります。「.」および「..」は、有効なアプリケーション名にはなりません。

• アプリケーション名の長さは、215文字未満とする必要があります。

デプロイメント・バージョン文字列について

デプロイメント名に加えて、アプリケーションまたはモジュールには、バージョン文字列を関連付けることもできます。バージョン文字列により、アプリケーションの初期デプロイメントと、後の再デプロイされたバージョンが区別されます。たとえば、問題点を修正したり、新しい機能を追加したりするために、アプリケーションを後から更新する場合があります。本番システムでは、アプリケーションの最初のデプロイメントと後続のデプロイメントの双方についてバージョン文字列を維持することが非常に重要です。そうすることで、既存のクライアントに対するサービスを中断させることなく、アプリケーションのバージョンを更新し、再デプロイを行えます。詳細については、「本番環境でのアプリケーションの再デプロイメント」を参照してください。

アプリケーションのマニフェスト・ファイルにバージョン文字列を指定します。開発チームは他のデプロイメント・ファイルと一緒にこのファイルを提供する必要があります。『Oracle WebLogic Serverアプリケーションの開発』のアプリケーションのバージョンの割当に関する項では、バージョン文字列を指定する際の規約について説明しています。

アプリケーションのインストール・ディレクトリの作成

アプリケーションのインストール・ディレクトリにより、生成された構成ファイルはコア・アプリケーション・ファイルから分離されるため、構成ファイルはアプリケーション自体を乱すことなく、簡単に変更または置換できます。このディレクトリ構造はまた、同じアプリケーション・デプロイメント・ファイルの複数バージョンの整理と維持にも役立ちます。

次の図では、デプロイ可能なアプリケーションまたはモジュールの1つのバージョンを格納するアプリケーション・インストール・ディレクトリの階層を示します。

図3-1 アプリケーションのインストール・ディレクトリ

すべての新しい本番デプロイメントを、WebLogic Serverドメインにデプロイする前に、アプリケーションのインストール・ディレクトリにコピーしておくことをお勧めします。このディレクトリ構造からデプロイすることで、デプロイメント・ユニットと関連付けられたファイルをすべて簡単に識別できるようになります。管理コンソールを使用してインストール・ルートをデプロイするだけで、管理コンソールが自動的にデプロイメント・プランやWebLogic Serverデプロイメント記述子など、構成中に生成された関連ファイルを見つけます。

アプリケーションのインストール・ディレクトリを作成する手順

アプリケーションのインストール・ディレクトリを作成するには:

1. システム上でアプリケーションおよびモジュールのデプロイメント・ファイルを格納する最上位ディレクトリを選択します。以下のベスト・プラクティスにしたがってください。

   • WebLogic Serverドメイン・ディレクトリ内にデプロイメント・ファイルを格納しません。

   • 可能であればソース・コントロールを使用して、デプロイメント・ソース・ファイルを維持します。

   • 可能であれば、ドメイン内の管理サーバーおよび管理対象サーバーからアクセスできるディレクトリにデプロイメント・ファイルを格納します。

   次の手順では、サンプル・デプロイメント・ディレクトリc:\deployments\productionを使用しています。

2. デプロイするアプリケーションまたはモジュール専用のサブディレクトリを作成します。

   mkdir c:\deployments\production\myApplication
   

3. デプロイしているアプリケーションのバージョンを指定するために、アプリケーション・ディレクトリの下にサブディレクトリを作成します。アプリケーションの正確なバージョン文字列を使用して、サブディレクトリに名前を付けます。例:

   mkdir c:\deployments\production\myApplication\91Beta
   

4. バージョン・サブディレクトリは、ディレクトリのデプロイ元であるインストール・ルート・ディレクトリとなります。バージョン・サブディレクトリの下に、appおよびplanという名前のサブディレクトリを作成します。

   mkdir c:\deployments\production\myApplication\91Beta\app
   mkdir c:\deployments\production\myApplication\91Beta\plan
   

   
   

   注意: アプリケーションに関連付けられたデプロイメント・プランが複数ある場合は、各プランにつき1つの\planサブディレクトリを作成します。たとえば、アプリケーションmyApplicationの91Betaバージョンに関連付けられたデプロイメント・プランが2つある場合は、\planサブディレクトリを2つ作成します。次に例を示します。 mkdir c:\deployments\production\myApplication\91Beta\plan1 mkdir c:\deployments\production\myApplication\91Beta\plan2

   
   

5. アプリケーション・ソース・デプロイメント・ファイルを\appサブディレクトリにコピーします。アーカイブ・ファイルからデプロイしている場合は、次のように、単にアーカイブ・ファイルをコピーします。

   cp c:\downloads\myApplication.ear c:\deployments\production\myApplication\91Beta\app
   

   展開されたアーカイブ・ディレクトリからデプロイしている場合は、展開されたアーカイブ・ディレクトリ全体を\appにコピーします。

   cp -r c:\downloads\myApplication c:\deployments\production\myApplication\91Beta\app
   

   その結果、新しいディレクトリc:\deployments\production\myApplication\91Beta\app\myApplicationが作成されます。

6. アプリケーションについて、1つまたは複数のデプロイメント・プランがある場合は、それらを\planサブディレクトリにコピーします。

   アプリケーションのデプロイメント・プランが1つの場合は、次のようになります。

   cp c:\downloads\myApplicationPlans\plan.xml c:\deployments\production\myApplication\91Beta\plan
   

   アプリケーションのデプロイメント・プランが2つの場合は、次のようになります。

   cp c:\downloads\myApplicationPlans\plan1.xml c:\deployments\production\myApplication\91Beta\plan1
   cp c:\downloads\myApplicationPlans\plan2.xml c:\deployments\production\myApplication\91Beta\plan2
   

   
   

   注意: 既存のデプロイメント・プランがなければ、「本番デプロイメントのためのアプリケーションの構成」で説明するように、管理コンソールを使用して作成できます。管理コンソールは、アプリケーションのインストール・ディレクトリの\planサブディレクトリに、新しく生成されたデプロイメント・プランを自動的に格納します。

   
   

7. 管理コンソールを使用してアプリケーションをインストールするには、アプリケーションのインストール・ディレクトリを選択します。デフォルトでは、plan.xmlという名前のプランが\planサブディレクトリ内にあれば、管理コンソールはそれを使用します。管理コンソールは、\planサブディレクトリ以外のサブディレクトリ内にあるプランを識別しません。つまり、\plan1または\plan2サブディレクトリ内のプランは、管理コンソールでは識別されません。したがって、アプリケーションのプランが複数ある場合は、config.xmlの中で、使用するプランを指定する必要があります。「本番デプロイメントのためのアプリケーションの構成」を参照してください。config.xmlの詳細は、『構成ウィザードによるドメインの作成』を参照してください。

   アプリケーションをインストール後は、必要に応じてアプリケーションを構成、デプロイ、または配布できます。

   
   

   注意: weblogic.Deployerツールを使用しているときは、アプリケーションのインストール・ディレクトリを指定できず、利用可能なplan.xmlファイルがツールによってデフォルトで使用されることはありません。デプロイメントに使用する実際のデプロイメント・ファイルおよびプランを指定する必要があります。「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。

   
   

FastSwapデプロイメントによる再デプロイメントの最小化

Webアプリケーション開発者は、デプロイされたアプリケーションに変更を加えたら、その変更をブラウザをリフレッシュしてすぐに確認したいと考えています。Java EEサイドで作業中の変更を確認するには、開発者は通常、次のサイクルを行う必要があります。

編集 ->ビルド ->デプロイ ->テスト

これらのステップでは、多くの記述子要素が必要であり、Java EEを使用したアプリケーション開発が複雑で最初の工程に負担がかかるのはそのためです。これらのステップのビルド・サイクルとデプロイ・サイクルは、Javaおよび使用するアプリケーション・サーバーで必要になります。IDEでは、段階的なコンパイル・サポートによって編集ステップとビルド・ステップをシームレスに行うことができます。また、サーバー側では、WebLogic Server FastSwapデプロイメント機能がデプロイ・サイクルとテスト・サイクルのシームレス化を実現しています。

FastSwapデプロイメントの仕組み

Java EE 5では、クラスローダーを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。しかし、クラス(宣言されたフィールドとメソッド)の形式が変更できないという制限によって、Java EE動的クラスの再定義は大幅に制限されます。FastSwapの目的は、WebLogic Serverにおいてこの制限をなくし、新しい形式のクラスを動的に再定義できるようにして反復的な開発を容易にすることです。

FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。かわりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。

FastSwapでサポートされるアプリケーション構成

FastSwapデプロイメントを使用する場合、次のアプリケーション構成がサポートされます。

• FastSwapは、WebLogic Serverが開発モードで実行している場合にのみサポートされます。本番モードの場合は、自動的に無効になります。

• 展開されたディレクトリ内のクラス・ファイルへの変更のみサポートされます。アーカイブされたアプリケーション内のクラス・ファイルや、アプリケーションのクラスパスに含まれるアーカイブされたJARファイルへの変更はサポートされません。以下に例を示します。

  • EARに含まれるアーカイブされたWARとしてWebアプリケーションがデプロイされる場合、クラスへの変更はFastSwapエージェントによって認識されません。

  • 展開されたWebアプリケーション内のJavaクラスへの変更は、WEB-INF/classesディレクトリ内でのみサポートされ、FastSwapエージェントはWEB-INF/libに含まれるアーカイブされたjarへの変更は認識しません。

アプリケーションにおけるFastSwapの有効化

アプリケーションでFastSwapを有効にするには、weblogic-application.xmlファイルに次の要素を追加します。

 <fast-swap>
    <enabled>true</enabled>
 </fast-swap>

weblogic-application.xml要素の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

スタンドアロンのWebアプリケーションでFastSwapを有効にするには、weblogic.xmlファイルに<fast-swap要素を追加します。weblogic.xml要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のweblogic.xmlデプロイメント記述子の要素に関する項を参照してください。

FastSwapプロセスの概要

FastSwapデプロイメント・プロセスの手順を以下に示します。

1. 記述子レベルでFastSwapが有効になると、アプリケーションがWebLogic Serverにデプロイされ、適切なクラスローダーがインスタンス化されます。

2. ブラウザをオープンして動作中のアプリケーションを確認します。次に、メソッドまたはクラス(あるいはその両方)を変更(追加/編集/削除)し(「FastSwap使用時の制限」を参照)、コンパイルします。

   EclipseやIntelliJなどのIDEを使用して、Javaファイルが保存時にコンパイルされるように保存時にコンパイルするオプションを設定することをお薦めします。FastSwapエージェントはJavaファイルをコンパイルしません。

3. ブラウザをリフレッシュするか、アプリケーションに新しいリクエストを送信します。

   FastSwapエージェントは、クラスパスに含まれるすべてのディレクトリを検索することによって、最後の反復処理から変更されたすべてのクラスを検索しようとします。展開されたアプリケーションが単一のWebアプリケーションである場合、次のディレクトリに対してタイムスタンプに基づいてクラス・ファイルの変更の有無が調査されます。

   ExampleApp/APP-INF/classes
   ExampleApp/webapp/WEB-INF/classes
   

   FastSwapエージェントは、アプリケーションの変更されたクラスを再定義し、リクエストを処理します。

AntでのJMXインタフェースの使用

「ヘッドレス」アプリケーション(Webアプリケーションを経由しないアプリケーション)の場合、クラスの再定義はJMXインタフェースを使用して明示的に初期化できます。JMXインタフェースを使用するAntタスクは、クラスの再定義の初期化に使用できます。Ant FastSwapタスクの例を次に示します。

例3-1 AntでのJMXインタフェースの使用

<project name='MyProject' default='all' >
  <taskdef name='fast-swap'  classname='com.bea.wls.redef.ant.FastSwapTask'/>
  <target name='all'>
    <!--
      Redefine classes which have changed since they were last loaded.
      Required parameters:
       adminUrl: Connection url
           user: User name
       password: User password
         server: Managed server name
      application: Deployed application name
      Optional parameters:
          module: Name of the module within the application.
                  If not specified, all modules within the application
                  will be processed.
       failonerror: Default=true. If true, task will fail if fast-swap failed.
                  Otherwise, a message will be displayed and the task will
                    return success.
         timeout: Default=300. Timeout in seconds.
      classnames: Comma separated list of classnames to process. If not
                  specified, all classes within specified modules (if any)
                    in the application will be considered.
    -->
    <fast-swap
      adminUrl='t3://localhost:7001'
      user='weblogic'
      password='weblogic'
      server='myserver'
       application='SimpleApp'
      module='SimpleAppCookie'
      failonerror='false'
      timeout='30'
      classnames='examples.servlets.CookieCounter1,
                  examples.servlets.CookieCounter2,
                    examples.servlets.CookieCounter'
    />
  </target>
</project>

FastSwapでサポートされるアプリケーション・タイプと変更

FastSwapは、展開形式でデプロイされたPOJO(JAR)、Webアプリケーション(WAR)、およびエンタープライズ・アプリケーション(EAR)でサポートされます。FastSwapは、リソース・アダプタ(RAR)ではサポートされません。

FastSwapでサポートされる変更のタイプを以下に示します。

• 静的メソッドの追加

• 静的メソッドの削除

• インスタンス・メソッドの追加

• インスタンス・メソッドの削除

• 静的メソッド本体の変更

• インスタンス・メソッド本体の変更

• 静的フィールドの追加

• 静的フィールドの削除

• インスタンス・フィールドの追加

• インスタンス・フィールドの削除

次の表に、FastSwapでサポートされる変更タイプの詳細を示します。

表3-1 サポートされるアプリケーション・タイプおよび変更

スコープ	Javaの変更タイプ	サポート	ノート
Javaクラス	メソッドの追加	はい	finalizeメソッドの追加はサポートされません。
インスタンス(非抽象)	メソッドの削除	はい	finalizeメソッドの追加はサポートされません。
	a)フィールドの追加	はい
	b)フィールドの削除	はい
	c)メソッド本体の変更	はい
	d)コンストラクタの追加	はい
	e)コンストラクタの削除	はい
	f)フィールド修飾子の変更	はい
	g)メソッド修飾子の変更	はい
クラス・レベル(静的)	メソッドの追加	はい
	メソッドの削除	はい
	メソッド本体の変更	はい
クラス階層の変更	実装インタフェースのリストの変更	いいえ
	「SuperClass」拡張の変更	いいえ
抽象Javaクラス	抽象メソッドの追加	はい
	抽象メソッドの削除	はい
	インスタンスでサポートされるその他のすべての変更(a – g)	はい
「final」 Javaクラス	インスタンスでサポートされる変更(a – g)	はい
「final」 Javaメソッド	インスタンスでサポートされる変更(a – g)	はい
「final」 Javaフィールド	インスタンスでサポートされる変更(a – g)	はい
Enum	定数の追加	いいえ
	定数の削除	いいえ
	メソッドの追加/削除	いいえ
無名内部クラス	フィールドの追加/削除	NA	Java言語でサポートされない
	メソッドの追加/削除	いいえ
静的内部クラス	インスタンスでサポートされる変更(a – g)	はい
メンバー内部クラス(非静的内部クラス)	インスタンスでサポートされる変更(a – g)	はい
ローカル内部クラス	インスタンスでサポートされる変更(a – g)	はい
Javaインタフェース	メソッドの追加	はい
Javaリフレクション	既存のフィールド/メソッドへのアクセス	はい
	新しいメソッドへのアクセス	いいえ	リフレクションでは新しいメソッドは公開されません。一部の合成メソッドは公開されます。
	新しいフィールドへのアクセス	いいえ	リフレクションでは新しいフィールドは公開されません。
クラスのアノテーション	メソッド/フィールド・アノテーションの追加または削除	いいえ
アノテーション・タイプ	メソッド/属性の追加または削除	いいえ
例外クラス	インスタンスでサポートされる変更(a – g)	はい
EJBインタフェース	メソッドの追加/削除	いいえ	EJBインタフェースの変更には、フル・サポートではないリフレクションを使用。
EJB 3.0セッション/MDB EJB実装クラス	メソッドの追加/削除	いいえ	EJBクラスによって参照されるサポート・クラスは変更可能です。
	フィールドの追加/削除	いいえ
EJB 3.0エンティティBean	メソッドの追加/削除	いいえ	EJBクラスによって参照されるサポート・クラスは変更可能です。
	フィールドの追加/削除	いいえ
EJBインターセプタ	メソッドの追加/削除	いいえ	EJBクラスによって参照されるサポート・クラスは変更可能です。
	フィールドの追加/削除	いいえ

FastSwap使用時の制限

FastSwapデプロイメントを使用する場合、次のような制限が適用されます。

• Javaリフレクションの結果には、新しく追加されたフィールドとメソッドが含まれず、削除されたフィールドとメソッドが含まれます。その結果、リフレクションAPIを使用すると、予期しない結果になる可能性があります。

• 既存のクラスの階層は、FastSwapでは変更できません。たとえば、クラスの実装インタフェースのリストの変更や、クラスのスーパークラスの変更はサポートされません。

• Javaアノテーションの追加または削除は、FastSwapではサポートされません(上述のリフレクション変更に関係するため)。

• EJBインタフェースの追加または削除は、EJBコンパイル・ステップで実行時に変更を反映する必要があるため、FastSwapではサポートされません。

• Enumの定数の追加または削除はサポートされません。

• finalizeメソッドの追加または削除はサポートされません。

• フィールド名を変更する場合、オブジェクトの状態は保持されません。これは、古い名前のフィールドを削除し、新しい名前のフィールドを追加する場合の変更です。この場合、古いフィールドの状態はすべて、名前変更後のフィールドに持ち越されません。インスタンスの値がリセットされることを踏まえた上でフィールド名を変更してください。

FastSwapでサポートされない変更の処理

FastSwapが有効な場合、クラスを再コンパイルした後にFastSwapは既存のクラスローダーにクラスを再定義しようとします。行った変更がFastSwapでサポートされる変更のスコープ外である場合、再定義は失敗し、JVMによってWebLogic Serverウィンドウとサーバー・ログ・ファイルにUnsupportedOperationExceptionがスローされます。アプリケーションは変更を反映しませんが、実行は継続されます。

変更を反映するには、アプリケーション・タイプと変更の範囲に応じて、アプリケーションまたは影響を受けるモジュール(部分的な再デプロイ)を再デプロイします。

デプロイメント・ファイルの準備のベスト・プラクティス

アプリケーションおよびモジュールのデプロイメント準備を行う際には、次のベスト・プラクティスをお薦めします。

• デプロイするのがアーカイブ・ファイルであっても展開されたアーカイブ・ディレクトリであっても、「アプリケーションのインストール・ディレクトリの作成」で説明したように、デプロイメント・ファイルはアプリケーションのインストール・ディレクトリに格納します。インストール・ディレクトリを使用することで、管理コンソールはデプロイメント・ファイルおよび構成ファイルの場所を認識できるので、デプロイメント・プロセスが簡素化されます。

• 必要に応じて、以前のバージョンのアプリケーションに簡単に戻れるよう、アプリケーションのインストール・ディレクトリ全体を、ソース・コントロール・システムで管理します。