Oracle® Fusion Middleware Oracle WebLogic Serverへのアプリケーションのデプロイ 11g リリース1(10.3.5) B60988-03 |
|
前 |
次 |
次の項では、アプリケーションのデプロイメントを準備する上で必要となる重要なトピックについて説明します。
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
ファイルとしてパッケージ化されます。
アーカイブ・ファイルに加えて、特定の環境についてアプリケーションを構成する別個のファイルである、デプロイメント・プランを受け取ることになる場合があります。デプロイメント・プランについての詳細は、第4章「本番デプロイメントのためのアプリケーションの構成」で説明しています。
展開されたアーカイブ・ディレクトリには、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
オプションで名前を指定できます。
アプリケーションのネーミング要件については次の「アプリケーションのネーミング要件について」を、デフォルト以外のデプロイメント名の指定については第6章「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」を参照してください。
アプリケーションのWebLogic Serverへのデプロイを正常に実行するには、アプリケーション名が有効であることが必要です。アプリケーションのネーミング要件は、次のとおりです。
アプリケーション名は、次の文字のみを含む必要があります。
a-z
A-Z
0-9
_
(アンダースコア)
-
(ハイフン)
.
(ピリオド)
それ以外の文字をアプリケーション名に含めることはできません。
文字.
(ピリオド)を含むアプリケーション名には、少なくとも1つの別の文字が含まれている必要があります。「.」
および「..」
は、有効なアプリケーション名にはなりません。
アプリケーション名の長さは、215文字未満とする必要があります。
デプロイメント名に加えて、アプリケーションまたはモジュールには、バージョン文字列を関連付けることもできます。バージョン文字列により、アプリケーションの初期デプロイメントと、後の再デプロイされたバージョンが区別されます。たとえば、問題点を修正したり、新しい機能を追加したりするために、アプリケーションを後から更新する場合があります。本番システムでは、アプリケーションの最初のデプロイメントと後続のデプロイメントの双方についてバージョン文字列を維持することが非常に重要です。そうすることで、既存のクライアントに対するサービスを中断させることなく、アプリケーションのバージョンを更新し、再デプロイを行えます。詳細は、第8章「本番環境でのアプリケーションの再デプロイメント」を参照してください。
アプリケーションのマニフェスト・ファイルにバージョン文字列を指定します。開発チームは他のデプロイメント・ファイルと一緒にこのファイルを提供する必要があります。『Oracle WebLogic Serverアプリケーションの開発』のアプリケーションのバージョンの割当に関する項では、バージョン文字列を指定する際の規約について説明しています。
アプリケーションのインストール・ディレクトリにより、生成された構成ファイルはコア・アプリケーション・ファイルから分離されるため、構成ファイルはアプリケーション自体を乱すことなく、簡単に変更または置換できます。このディレクトリ構造はまた、同じアプリケーション・デプロイメント・ファイルの複数バージョンの整理と維持にも役立ちます。
次の図では、デプロイ可能なアプリケーションまたはモジュールの1つのバージョンを格納するアプリケーション・インストール・ディレクトリの階層を示します。
すべての新しい本番デプロイメントを、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
注意: 既存のデプロイメント・プランがなければ、第4章「本番デプロイメントのためのアプリケーションの構成」で説明するように、管理コンソールを使用して作成できます。管理コンソールは、アプリケーションのインストール・ディレクトリの\plan サブディレクトリに、新しく生成されたデプロイメント・プランを自動的に格納します。 |
管理コンソールを使用してアプリケーションをインストールするには、アプリケーションのインストール・ディレクトリを選択します。デフォルトでは、plan.xml
という名前のプランが\plan
サブディレクトリ内にあれば、管理コンソールはそれを使用します。管理コンソールは、\plan
サブディレクトリ以外のサブディレクトリ内にあるプランを識別しません。つまり、\plan1
または\plan2
サブディレクトリ内のプランは、管理コンソールでは識別されません。したがって、アプリケーションのプランが複数ある場合は、config.xml
の中で、使用するプランを指定する必要があります。第4章「本番デプロイメントのためのアプリケーションの構成」を参照してください。config.xmlの詳細は、「構成ウィザードを使用したドメインの作成」を参照してください。
アプリケーションをインストール後は、必要に応じてアプリケーションを構成、デプロイ、または配布できます。
注意: weblogic.Deployerツールを使用しているときは、アプリケーションのインストール・ディレクトリを指定できず、利用可能なplan.xmlファイルがツールによってデフォルトで使用されることはありません。デプロイメントに使用する実際のデプロイメント・ファイルおよびプランを指定する必要があります。第6章「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
がスローされます。アプリケーションは変更を反映しませんが、実行は継続されます。
変更を反映するには、アプリケーション・タイプと変更の範囲に応じて、アプリケーションまたは影響を受けるモジュール(部分的な再デプロイ)を再デプロイします。
アプリケーションおよびモジュールのデプロイメント準備を行う際には、次のベスト・プラクティスをお薦めします。
デプロイするのがアーカイブ・ファイルであっても展開されたアーカイブ・ディレクトリであっても、「アプリケーションのインストール・ディレクトリの作成」で説明したように、デプロイメント・ファイルはアプリケーションのインストール・ディレクトリに格納します。インストール・ディレクトリを使用することで、管理コンソールはデプロイメント・ファイルおよび構成ファイルの場所を認識できるので、デプロイメント・プロセスが簡素化されます。
必要に応じて、以前のバージョンのアプリケーションに簡単に戻れるよう、アプリケーションのインストール・ディレクトリ全体を、ソース・コントロール・システムで管理します。