| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3へのアプリケーションのデプロイ 12c (12.1.3) E56252-03 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle WebLogic Server 12.1.3へのアプリケーションのデプロイ 12c (12.1.3) E56252-03 |
|
前 |
次 |
この章では、WebLogic Server 12.1.3へのデプロイメントについて、アプリケーションとモジュールを準備する方法を説明します。
この章には次の項が含まれます:
WebLogic Serverは、jarユーティリティまたはAntのjarツールを使用してアーカイブ・ファイルとしてパッケージ化されたデプロイメント、または展開されたアーカイブ・ディレクトリとしてパッケージ化されたデプロイメントをサポートしています。
|
注意: 一般に、アーカイブ・ファイルを使用して、より効率的に管理対象サーバー上にアプリケーションのデプロイができます。ただし、アプリケーションの再デプロイメントが必要とされるため、Webコンテンツの更新などのアプリケーションの更新がより難しくなります。 |
アーカイブ・ファイルは、アプリケーションまたはモジュールのクラス、静的ファイル、ディレクトリ、およびデプロイメント記述子ファイルをすべて含む単一のファイルです。大半の本番環境において、管理者がデプロイメント用に受け取るアプリケーションは、アーカイブ・ファイルとして格納されます。
jarユーティリティを使用してパッケージ化されたデプロイメント・ユニットには、タイプ別に特定のファイル拡張子が付きます。
EJBおよびクライアント・アーカイブは、.jarファイルとしてパッケージ化されます。
Webアプリケーションは、.warファイルとしてパッケージ化されます。
リソース・アダプタは、.rarファイルとしてパッケージ化されます。
エンタープライズ・アプリケーションは、.earファイルとしてパッケージ化され、Webアーカイブ(.warファイル)、EJBアーカイブ(.jarファイル)、コネクタ・アーカイブ(.rarファイル)およびクライアント・アーカイブ(.jarファイル)などの他の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操作を実行するモジュールには、操作を実行するための物理ファイル・システム・ディレクトリが必要です。仕様により、アプリケーションをアーカイブとしてデプロイする時点でファイルを取得することはできません。
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オプションで名前を指定できます。
WebLogic Server 12.1.1の時点で、Java EE 6仕様に準拠し、アプリケーション名を指定する追加の方法(application.xml内の<application-name>要素)があります。スタンドアロン・モジュールの場合、それぞれのデプロイメント記述子に<module-name>要素を指定できます。デプロイメント記述子内で提供されるアプリケーション名(application.xml内のapplication-nameまたはweb.xml内のmodule-name)は、weblogic.Deployer -nameオプションまたはマニフェスト・アプリケーション名属性によってもオーバーライドされます。
ネーミングの優先順位は、高い順に次のとおりとなります。
-name weblogic.Deployerオプション。
マニフェスト・ファイルで指定される名前。
デプロイメント記述子で指定される名前。
デプロイメント・ソース・ファイルに基づいて計算された名前。
提供または計算されたアプリケーション/モジュール名がすでに使用されている場合、WebLogic Serverによって数字の接尾辞が追加され、その名前は一意の名前に変更されます。
アプリケーションのネーミング要件については次のアプリケーションのネーミング要件の理解に関する項を、デフォルト以外のデプロイメント名の指定についてはweblogic.Deployerによるアプリケーションおよびモジュールのデプロイに関する項を参照してください。
アプリケーションのWebLogic Serverへのデプロイを正常に実行するには、アプリケーション名が有効であることが必要です。アプリケーションのネーミング要件は、次のとおりです。
アプリケーション名は、次の文字のみを含む必要があります。
a-z
A-Z
0-9
_ (アンダースコア)
- (ハイフン)
. (ピリオド)
それ以外の文字をアプリケーション名に含めることはできません。
文字. (ピリオド)を含むアプリケーション名には、少なくとも1つの別の文字が含まれている必要があります。「.」および「..」は、有効なアプリケーション名にはなりません。
アプリケーション名の長さは、215文字未満とする必要があります。
デプロイメント名に加えて、アプリケーションまたはモジュールには、バージョン文字列を関連付けることもできます。バージョン文字列により、アプリケーションの初期デプロイメントと、後の再デプロイされたバージョンが区別されます。たとえば、問題点を修正したり、新しい機能を追加したりするために、アプリケーションを後から更新する場合があります。本番システムでは、アプリケーションの最初のデプロイメントと後続のデプロイメントの双方についてバージョン文字列を維持することが非常に重要です。そうすることで、既存のクライアントに対するサービスを中断させることなく、アプリケーションのバージョンを更新し、再デプロイを行えます。詳細については、「本番環境でのアプリケーションの再デプロイメント」を参照してください。
アプリケーションのマニフェスト・ファイルにバージョン文字列を指定します。開発チームは他のデプロイメント・ファイルと一緒にこのファイルを提供する必要があります。『Oracle WebLogic Serverアプリケーションの開発』のアプリケーションのバージョンの割当に関する項では、バージョン文字列を指定する際の規約について説明しています。
アプリケーションのインストール・ディレクトリにより、生成された構成ファイルはコア・アプリケーション・ファイルから分離されるため、構成ファイルはアプリケーション自体を乱すことなく、簡単に変更または置換できます。このディレクトリ構造はまた、同じアプリケーション・デプロイメント・ファイルの複数バージョンの整理と維持にも役立ちます。
次の図では、デプロイ可能なアプリケーションまたはモジュールの1つのバージョンを格納するアプリケーション・インストール・ディレクトリの階層を示します。
すべての新しい本番デプロイメントを、WebLogic Serverドメインにデプロイする前に、アプリケーションのインストール・ディレクトリにコピーしておくことをお薦めします。このディレクトリ構造からデプロイすることで、デプロイメント・ユニットと関連付けられたファイルをすべて簡単に識別できるようになります。WebLogic Server管理コンソールを使用してインストール・ルートをデプロイするだけで、WebLogic Server管理コンソールが自動的にデプロイメント・プランやWebLogic Serverデプロイメント記述子など、構成中に生成された関連ファイルを見つけます。
アプリケーションのインストール・ディレクトリを作成するには:
システム上でアプリケーションおよびモジュールのデプロイメント・ファイルを格納する最上位ディレクトリを選択します。以下のベスト・プラクティスにしたがってください。
WebLogic Serverドメイン・ディレクトリ内にデプロイメント・ファイルを格納しません。
可能であればソース・コントロールを使用して、デプロイメント・ソース・ファイルを維持します。
可能であれば、ドメイン内の管理サーバーおよび管理対象サーバーからアクセスできるディレクトリにデプロイメント・ファイルを格納します。
次の手順では、サンプル・デプロイメント・ディレクトリc:\deployments\productionを使用しています。
デプロイするアプリケーションまたはモジュール専用のサブディレクトリを作成します。
mkdir c:\deployments\production\myApplication
デプロイしているアプリケーションのバージョンを指定するために、アプリケーション・ディレクトリの下にサブディレクトリを作成します。アプリケーションの正確なバージョン文字列を使用して、サブディレクトリに名前を付けます。例:
mkdir c:\deployments\production\myApplication\91Beta
バージョン・サブディレクトリは、ディレクトリのデプロイ元であるインストール・ルート・ディレクトリとなります。バージョン・サブディレクトリの下に、appおよびplanという名前のサブディレクトリを作成します。
mkdir c:\deployments\production\myApplication\91Beta\app mkdir c:\deployments\production\myApplication\91Beta\plan
|
注意: アプリケーションに関連付けられたデプロイメント・プランが複数ある場合は、各プランにつき1つの\planサブディレクトリを作成します。たとえば、アプリケーションmyApplicationの91Betaバージョンに関連付けられたデプロイメント・プランが2つある場合は、\planサブディレクトリを2つ作成します。次に例を示します。
|
アプリケーション・ソース・デプロイメント・ファイルを\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が作成されます。
アプリケーションについて、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
|
注意: 既存のデプロイメント・プランがなければ、「本番デプロイメントのためのアプリケーションの構成」で説明するように、WebLogic Server管理コンソールを使用して作成できます。WebLogic Server管理コンソールは、アプリケーションのインストール・ディレクトリの\planサブディレクトリに、新しく生成されたデプロイメント・プランを自動的に格納します。 |
WebLogic Server管理コンソールを使用してアプリケーションをインストールするには、アプリケーションのインストール・ディレクトリを選択します。デフォルトでは、plan.xmlという名前のプランが\planサブディレクトリ内にあれば、WebLogic Server管理コンソールはそれを使用します。WebLogic Server管理コンソールは、\planサブディレクトリ以外のサブディレクトリ内にあるプランを識別しません。つまり、\plan1または\plan2サブディレクトリ内のプランは、WebLogic Server管理コンソールでは識別されません。したがって、アプリケーションのプランが複数ある場合は、config.xmlの中で、使用するプランを指定する必要があります。「本番デプロイメントのためのアプリケーションの構成」を参照してください。config.xmlについては、『構成ウィザードによるWebLogicドメインの作成』を参照してください。
アプリケーションをインストール後は、必要に応じてアプリケーションを構成、デプロイ、または配布できます。
|
注意: weblogic.Deployerツールを使用しているときは、アプリケーションのインストール・ディレクトリを指定できず、利用可能なplan.xmlファイルがツールによってデフォルトで使用されることはありません。デプロイメントに使用する実際のデプロイメント・ファイルおよびプランを指定する必要があります。「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。 |
Webアプリケーション開発者は、デプロイされたアプリケーションに変更を加えたら、その変更をブラウザをリフレッシュしてすぐに確認したいと考えています。Java EEサイドで作業中の変更を確認するには、開発者は通常、次のサイクルを行う必要があります。
編集 ->ビルド ->デプロイ ->テスト
これらのステップでは、多くの記述子要素が必要であり、Java EEを使用したアプリケーション開発が複雑で最初の工程に負担がかかるのはそのためです。これらのステップのビルド・サイクルとデプロイ・サイクルは、Javaおよび使用するアプリケーション・サーバーで必要になります。IDEでは、段階的なコンパイル・サポートによって編集ステップとビルド・ステップをシームレスに行うことができます。また、サーバー側では、WebLogic Server FastSwapデプロイメント機能がデプロイ・サイクルとテスト・サイクルのシームレス化を実現しています。
Java EE 5では、クラスローダーを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。しかし、クラス(宣言されたフィールドとメソッド)の形式が変更できないという制限によって、Java EE動的クラスの再定義は大幅に制限されます。FastSwapの目的は、WebLogic Serverにおいてこの制限をなくし、新しい形式のクラスを動的に再定義できるようにして反復的な開発を容易にすることです。
FastSwapを使用すると、ClassLoaderを再ロードせずにインプレースでJavaクラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、アプリケーションが再デプロイするまで待機した後に作業していたWebページ・フローに戻るということをしないで済みます。かわりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。
FastSwapデプロイメントを使用する場合、次のアプリケーション構成がサポートされます。
FastSwapは、WebLogic Serverが開発モードで実行している場合にのみサポートされます。本番モードの場合は、自動的に無効になります。
展開されたディレクトリ内のクラス・ファイルへの変更のみサポートされます。アーカイブされたアプリケーション内のクラス・ファイルや、アプリケーションのクラスパスに含まれるアーカイブされたJARファイルへの変更はサポートされません。以下に例を示します。
EARに含まれるアーカイブされたWARとしてWebアプリケーションがデプロイされる場合、クラスへの変更はFastSwapエージェントによって認識されません。
展開されたWebアプリケーション内のJavaクラスへの変更は、WEB-INF/classesディレクトリ内でのみサポートされ、FastSwapエージェントはWEB-INF/libに含まれるアーカイブされたJARへの変更は認識しません。
アプリケーションで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が有効になると、アプリケーションがWebLogic Serverにデプロイされ、適切なクラスローダーがインスタンス化されます。
ブラウザをオープンして動作中のアプリケーションを確認します。次に、メソッドまたはクラス(あるいはその両方)を変更(追加/編集/削除)し(「FastSwap使用時の制限」を参照)、コンパイルします。
EclipseやIntelliJなどのIDEを使用して、Javaファイルが保存時にコンパイルされるように保存時にコンパイルするオプションを設定することをお薦めします。FastSwapエージェントはJavaファイルをコンパイルしません。
ブラウザをリフレッシュするか、アプリケーションに新しいリクエストを送信します。
FastSwapエージェントは、クラスパスに含まれるすべてのディレクトリを検索することによって、最後の反復処理から変更されたすべてのクラスを検索しようとします。展開されたアプリケーションが単一のWebアプリケーションである場合、次のディレクトリに対してタイムスタンプに基づいてクラス・ファイルの変更の有無が調査されます。
ExampleApp/APP-INF/classes ExampleApp/webapp/WEB-INF/classes
FastSwapエージェントは、アプリケーションの変更されたクラスを再定義し、リクエストを処理します。
「ヘッドレス」アプリケーション(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は、展開形式でデプロイされたPOJO (JAR)、Webアプリケーション(WAR)、およびエンタープライズ・アプリケーション(EAR)でサポートされます。FastSwapは、リソース・アダプタ(RAR)ではサポートされません。
FastSwapでサポートされる変更のタイプを以下に示します。
静的メソッドの追加
静的メソッドの削除
インスタンス・メソッドの追加
インスタンス・メソッドの削除
静的メソッド本体の変更
インスタンス・メソッド本体の変更
静的フィールドの追加
静的フィールドの削除
インスタンス・フィールドの追加
インスタンス・フィールドの削除
次の表に、FastSwapでサポートされる変更タイプの詳細を示します。
表3-1 サポートされるアプリケーション・タイプおよび変更
| スコープ | Javaの変更タイプ | サポート | ノート |
|---|---|---|---|
|
Javaクラス |
メソッドの追加 |
はい |
|
|
インスタンス(非抽象) |
メソッドの削除 |
はい |
|
|
a)フィールドの追加 |
はい |
||
|
b)フィールドの削除 |
はい |
||
|
c)メソッド本体の変更 |
はい |
||
|
d)コンストラクタの追加 |
はい |
||
|
e)コンストラクタの削除 |
はい |
||
|
f)フィールド修飾子の変更 |
はい |
||
|
g)メソッド修飾子の変更 |
はい |
||
|
クラス・レベル(静的) |
メソッドの追加 |
はい |
|
|
メソッドの削除 |
はい |
||
|
メソッド本体の変更 |
はい |
||
|
クラス階層の変更 |
実装インタフェースのリストの変更 |
いいえ |
|
|
「SuperClass」拡張の変更 |
いいえ |
||
|
抽象Javaクラス |
抽象メソッドの追加 |
はい |
|
|
抽象メソッドの削除 |
はい |
||
|
インスタンス |
はい |
||
|
「final」 Javaクラス |
インスタンス |
はい |
|
|
「final」 Javaメソッド |
インスタンス |
はい |
|
|
「final」 Javaフィールド |
インスタンス |
はい |
|
|
Enum |
定数の追加 |
いいえ |
|
|
定数の削除 |
いいえ |
||
|
メソッドの追加/削除 |
いいえ |
||
|
無名内部クラス |
フィールドの追加/削除 |
NA |
Java言語でサポートされない |
|
メソッドの追加/削除 |
いいえ |
||
|
静的内部クラス |
インスタンス |
はい |
|
|
メンバー内部クラス(非静的内部クラス) |
インスタンス |
はい |
|
|
ローカル内部クラス |
インスタンス |
はい |
|
|
Javaインタフェース |
メソッドの追加 |
はい |
|
|
Javaリフレクション |
既存のフィールド/メソッドへのアクセス |
はい |
|
|
新しいメソッドへのアクセス |
いいえ |
リフレクションでは新しいメソッドは公開されません。一部の合成メソッドは公開されます。 |
|
|
新しいフィールドへのアクセス |
いいえ |
リフレクションでは新しいフィールドは公開されません。 |
|
|
クラスのアノテーション |
メソッド/フィールド・アノテーションの追加または削除 |
いいえ |
|
|
アノテーション・タイプ |
メソッド/属性の追加または削除 |
いいえ |
|
|
例外クラス |
インスタンス |
はい |
|
|
EJBインタフェース |
メソッドの追加/削除 |
いいえ |
EJBインタフェースの変更には、フル・サポートではないリフレクションを使用。 |
|
EJB 3.0セッション/MDB EJB実装クラス |
メソッドの追加/削除 |
いいえ |
EJBクラスによって参照されるサポート・クラスは変更可能です。 |
|
フィールドの追加/削除 |
いいえ |
||
|
EJB 3.0エンティティBean |
メソッドの追加/削除 |
いいえ |
EJBクラスによって参照されるサポート・クラスは変更可能です。 |
|
フィールドの追加/削除 |
いいえ |
||
|
EJBインターセプタ |
メソッドの追加/削除 |
いいえ |
EJBクラスによって参照されるサポート・クラスは変更可能です。 |
|
フィールドの追加/削除 |
いいえ |
FastSwapデプロイメントを使用する場合、次のような制限が適用されます。
Javaリフレクションの結果には、新しく追加されたフィールドとメソッドが含まれず、削除されたフィールドとメソッドが含まれます。その結果、リフレクションAPIを使用すると、予期しない結果になる可能性があります。
既存のクラスの階層は、FastSwapでは変更できません。たとえば、クラスの実装インタフェースのリストの変更や、クラスのスーパークラスの変更はサポートされません。
Javaアノテーションの追加または削除は、FastSwapではサポートされません(上述のリフレクション変更に関係するため)。
EJBインタフェースの追加または削除は、EJBコンパイル・ステップで実行時に変更を反映する必要があるため、FastSwapではサポートされません。
Enumの定数の追加または削除はサポートされません。
finalizeメソッドの追加または削除はサポートされません。
フィールド名を変更する場合、オブジェクトの状態は保持されません。これは、古い名前のフィールドを削除し、新しい名前のフィールドを追加する場合の変更です。この場合、古いフィールドの状態はすべて、名前変更後のフィールドに持ち越されません。インスタンスの値がリセットされることを踏まえた上でフィールド名を変更してください。
FastSwapが有効な場合、クラスを再コンパイルした後にFastSwapは既存のクラスローダーにクラスを再定義しようとします。行った変更がFastSwapでサポートされる変更のスコープ外である場合、再定義は失敗し、JVMによってWebLogic Serverウィンドウとサーバー・ログ・ファイルにUnsupportedOperationExceptionがスローされます。アプリケーションは変更を反映しませんが、実行は継続されます。
変更を反映するには、アプリケーション・タイプと変更の範囲に応じて、アプリケーションまたは影響を受けるモジュール(部分的な再デプロイ)を再デプロイします。
アプリケーションおよびモジュールのデプロイメント準備を行う際には、次のベスト・プラクティスをお薦めします。
デプロイするのがアーカイブ・ファイルであっても展開されたアーカイブ・ディレクトリであっても、「アプリケーションのインストール・ディレクトリの作成」で説明したように、デプロイメント・ファイルはアプリケーションのインストール・ディレクトリに格納します。インストール・ディレクトリを使用することで、WebLogic Server管理コンソールはデプロイメント・ファイルおよび構成ファイルの場所を認識できるので、デプロイメント・プロセスが簡素化されます。
必要に応じて、以前のバージョンのアプリケーションに簡単に戻れるよう、アプリケーションのインストール・ディレクトリ全体を、ソース・コントロール・システムで管理します。
