| Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント 11g リリース 1 (10.3.1) B55511-01 |
|
 戻る |
 次へ |
| Oracle Fusion Middleware Oracle WebLogic Server アプリケーションのデプロイメント 11g リリース 1 (10.3.1) B55511-01 |
|
戻る |
次へ |
以下の節では、アプリケーションのデプロイメントを準備する上で必要となる重要なトピックについて説明します。
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 操作を実行するモジュールには、操作を実行するための物理ファイル システム ディレクトリが必要です。仕様により、アプリケーションをアーカイブとしてデプロイする時点でファイルを取得することはできません。
Java EE 仕様では、アーカイブされた EAR (エンタープライズ アプリケーション アーカイブ) をデプロイメント記述子を含まない状態で Java EE 準拠のサーバにデプロイすることが推奨されています。これを行うには、すべてのコンテナで、妥当なデフォルト値が設定されているか、またはアノテーション付きのクラスが使用されていることが前提となります。WebLogic Server では、この規定のサポートに加えて、展開された EAR ディレクトリをデプロイメント記述子を含まない状態でデプロイすることもできます。
こうしたデプロイメントがディレクトリに適用される場合、EAR とそのネストされたモジュールの特定には一定のルールが使用されます。ルールに従っていないディレクトリは、WebLogic Server Administration Console でもデプロイメント ツールでも、展開された有効な 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.Deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。
アプリケーションの WebLogic Server へのデプロイを正常に実行するには、アプリケーション名が有効であることが必要です。アプリケーションのネーミング要件は、次のとおりです。
アプリケーション名に含まれる文字は、以下のもののみでなければならない。
a-z
A-Z
0-9
_ (アンダースコア)
- (ハイフン)
. (ピリオド)
それ以外の文字をアプリケーション名に含めることはできません。
文字 . (ピリオド) を含むアプリケーション名には、少なくとも 1 つの別の文字が含まれている必要がある。「.」および「..」は、有効なアプリケーション名にはなりません。
アプリケーション名の長さは、215 文字未満とする必要がある。
デプロイメント名に加えて、アプリケーションまたはモジュールには、バージョン文字列を関連付けることもできます。バージョン文字列により、アプリケーションの初期デプロイメントと、後の再デプロイされたバージョンが区別されます。たとえば、問題点を修正したり、新しい機能を追加したりするために、アプリケーションを後から更新する場合があります。プロダクション システムでは、アプリケーションの初期デプロイメントと後続するデプロイメントの双方についてバージョン文字列を維持することが非常に重要です。そうすることで、既存のクライアントに対するサービスを中断させることなく、アプリケーションのバージョンを更新し、再デプロイを行えます。詳細については、「プロダクション環境でのアプリケーションの再デプロイメント」を参照してください。
バージョン文字列は、アプリケーションのマニフェスト ファイルで指定され、他のデプロイメント ファイルと一緒に、開発チームによって提供されます。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「アプリケーションのバージョンの割り当て」で、バージョン文字列を指定する際の規約について説明しています。
アプリケーションのインストール ディレクトリにより、生成されたコンフィグレーション ファイルはコア アプリケーション ファイルから分離されるため、コンフィグレーション ファイルはアプリケーション自体を乱すことなく、簡単に変更または置換できます。このディレクトリ構造はまた、同じアプリケーション デプロイメント ファイルの複数バージョンの整理と維持にも役立ちます。
次の図では、デプロイ可能なアプリケーションまたはモジュールの 1 つのバージョンを格納するアプリケーション インストール ディレクトリの階層を示します。
すべての新しいプロダクション デプロイメントを、WebLogic Server ドメインにデプロイする前に、アプリケーションのインストール ディレクトリにコピーしておくことをお勧めします。このディレクトリ構造からデプロイすることで、デプロイメント ユニットと関連付けられたファイルをすべて簡単に識別できるようになります。Administration Console を使用してインストール ルートをデプロイするだけで、Administration Console が自動的にデプロイメント プランや 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
|
注意 : 既存のデプロイメント プランがなければ、「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」で説明するように、Administration Console を使用して作成できます。Administration Console は、アプリケーションのインストール ディレクトリの\plan サブディレクトリに、新しく生成されたデプロイメント プランを自動的に格納します。 |
Administration Console を使用してアプリケーションをインストールするには、アプリケーションのインストール ディレクトリを選択します。デフォルトでは、plan.xml という名前のプランが \plan サブディレクトリ内にあれば、Administration Console はそれを使用します。Administration Console は、\plan サブディレクトリ以外のサブディレクトリ内にあるプランを識別しません。つまり、\plan1 または \plan2 サブディレクトリ内のプランは、Administration Console では識別されません。したがって、アプリケーションのプランが複数ある場合は、config.xml の中で、使用するプランを指定する必要があります。「プロダクション デプロイメントのためのアプリケーションのコンフィグレーション」を参照してください。config.xml の詳細については、『Oracle Fusion Middleware コンフィグレーション ウィザードを使用したドメインの作成』を参照してください。
アプリケーションをインストール後は、必要に応じてアプリケーションをコンフィグレーション、デプロイ、または分散できます。
|
注意 : weblogic.Deployer ツールを使用しているときは、アプリケーションのインストール ディレクトリを指定できず、利用可能な plan.xml ファイルがツールによってデフォルトで使用されることはありません。デプロイメントに使用する実際のデプロイメント ファイルおよびプランを指定する必要があります。「weblogic.Deployer によるアプリケーションおよびモジュールのデプロイ」を参照してください。 |
Web アプリケーション開発者は、デプロイされたアプリケーションに変更を加えたら、その変更をブラウザを更新してすぐに確認したいと考えています。Java EE サイドで作業中の変更を確認するには、開発者は通常、次のサイクルを行う必要があります。
編集 -> ビルド -> デプロイ -> テスト
これらのステップでは、多くの記述子要素が必要であり、Java EE を使用したアプリケーション開発が複雑で最初の工程に負担がかかるのはそのためです。これらのステップのビルド サイクルとデプロイ サイクルは、Java および使用するアプリケーション サーバで必要になります。IDE では、段階的なコンパイル サポートによって編集ステップとビルド ステップをシームレスに行うことができます。また、サーバ サイドでは、WLS FastSwap デプロイメント機能がデプロイ サイクルとテスト サイクルのシームレス化を実現しています。
Java EE 5 では、ClassLoader を削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。しかし、クラス (宣言されたフィールドとメソッド) の形式が変更できないという制限によって、Java EE 動的クラスの再定義は大幅に制限されます。FastSwap の目的は、WLS においてこの制限をなくし、新しい形式のクラスを動的に再定義できるようにして反復的な開発を容易にすることです。
FastSwap を使用すると、ClassLoader を再ロードせずにインプレースで Java クラスを再定義するため、所要時間を短縮できるという点で明らかに有利です。つまり、アプリケーションが再デプロイするまで待機した後に作業していた Web ページ フローに戻るということをしないで済みます。代わりに、変更を追加すると、自動でコンパイルされ、すぐに結果が確認できます。
FastSwap デプロイメントを使用する場合、次のアプリケーション コンフィグレーションがサポートされます。
FastSwap は、WLS が開発モードで実行している場合にのみサポートされる。プロダクション モードの場合は、自動的に無効になります。
展開されたディレクトリ内のクラス ファイルへの変更のみサポートされる。アーカイブされたアプリケーション内のクラス ファイルや、アプリケーションのクラスパスに含まれるアーカイブされた 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 Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
スタンドアロンの Web アプリケーションで FastSwap を有効にするには、weblogic.xml ファイルに <fast-swap> 要素を追加します。weblogic.xml 要素の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「weblogic.xml デプロイメント記述子の要素」を参照してください。
FastSwap デプロイメント プロセスの手順を以下に示します。
記述子レベルで FastSwap が有効になると、アプリケーションが WLS にデプロイされるときに、適切な ClassLoader がインスタンス化されます。
ブラウザを開いて動作中のアプリケーションを確認します。次に、メソッドまたはクラスを変更 (追加/編集/削除) し (「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'> <!-- 最後のロードから変更されたクラスを再定義する。 必須パラメータ : adminUrl: 接続 URL user: ユーザ名 password: ユーザ パスワード server: 管理対象サーバ名 application: デプロイ対象のアプリケーション名 省略可能なパラメータ : module: アプリケーション内のモジュールの名前 指定しない場合、アプリケーション内のすべてのモジュールが 処理される failonerror: デフォルトは true。true の場合、高速スワップに失敗するとタスクが失敗する。 true でない場合、メッセージが表示され、タスクが 成功を返す。 timeout: デフォルトは 300。タイムアウトは秒単位。 classnames: 処理対象のクラス名のリストはカンマで区切る。指定しない場合、 アプリケーションの指定されたモジュール (存在する場合) のすべてのクラスが対象になる。 --> <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 リフレクションの結果には、新しく追加されたフィールドとメソッドが含まれず、削除されたフィールドとメソッドが含まれる。その結果、Reflection API を使用すると、予期しない結果になる可能性があります。
既存のクラスの階層は、FastSwap では変更できない。たとえば、クラスの実装インタフェースのリストの変更や、クラスのスーパークラスの変更はサポートされません。
Java アノテーションの追加または削除は、FastSwap ではサポートされない (上述のリフレクション変更に関係するため)。
EJB インタフェースの追加または削除は、FastSwap ではサポートされない (EJB コンパイル ステップで実行時に変更を反映する必要があるため)。
Enum の定数の追加または削除はサポートされない。
finalize メソッドの追加または削除はサポートされない。
フィールド名を変更する場合、オブジェクトの状態は保持されない。これは、古い名前のフィールドを削除し、新しい名前のフィールドを追加する場合の変更です。この場合、古いフィールドの状態はすべて、名前変更後のフィールドに持ち越されません。インスタンスの値がリセットされることを踏まえた上でフィールド名を変更してください。
FastSwap が有効な場合、クラスを再コンパイルした後に FastSwap は既存のクラスローダにクラスを再定義しようとします。行った変更が FastSwap でサポートされる変更のスコープ外である場合、再定義は失敗し、JVM によって WLS ウィンドウとサーバ ログ ファイルに UnsupportedOperationException が送出されます。アプリケーションは変更を反映しませんが、実行は継続されます。
変更を反映するには、アプリケーション タイプと変更の範囲に応じて、アプリケーションまたは影響を受けるモジュール (部分的な再デプロイ) を再デプロイします。
アプリケーションおよびモジュールのデプロイメント準備を行う際には、次のベスト プラクティスをお勧めします。
デプロイするのがアーカイブ ファイルであっても展開されたアーカイブ ディレクトリであっても、「アプリケーションのインストール ディレクトリの作成」で説明したように、デプロイメント ファイルはアプリケーションのインストール ディレクトリに格納します。インストール ディレクトリを使用することで、Administration Console はデプロイメント ファイルおよびコンフィグレーション ファイルの場所を認識できるので、デプロイメント プロセスが簡素化されます。
必要に応じて、以前のバージョンのアプリケーションに簡単に戻れるよう、アプリケーションのインストール ディレクトリ全体を、ソース コントロール システムで管理します。
