この章には次の項が含まれます:
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デプロイメント記述子など、構成中に生成された関連ファイルを見つけます。
Webアプリケーション開発者は、デプロイされたアプリケーションに変更を加えたら、その変更をブラウザをリフレッシュしてすぐに確認したいと考えています。
Java EE側で、開発者は通常、 Edit -> Build -> Deploy -> Test
のサイクルを通して変更が実際に行われていることを確認する必要があります。これらのステップでは、多くの記述子要素が必要であり、Java EEを使用したアプリケーション開発が複雑で最初の工程に負担がかかるのはそのためです。
これらのステップのビルド・サイクルとデプロイ・サイクルは、Javaおよび使用するアプリケーション・サーバーで必要になります。IDEでは、段階的なコンパイル・サポートによって編集ステップとビルド・ステップをシームレスに行うことができます。また、サーバー側では、WebLogic Server FastSwapデプロイメント機能がデプロイ・サイクルとテスト・サイクルのシームレス化を実現しています。
Java EE では、クラスローダーを削除したり既存のインスタンスを破棄したりすることなく、実行時にクラスを再定義する機能が導入されています。これにより、コンテナは実行中のアプリケーションに影響を与えることなく、変更されたクラスを再ロードできるため、反復的な開発サイクル時間が大幅に短縮され、開発およびテスト全体が改善されています。しかし、クラス(宣言されたフィールドとメソッド)の形式が変更できないという制限によって、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)フィールドの追加 |
はい |
該当なし(N/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
がスローされます。アプリケーションは変更を反映しませんが、実行は継続されます。
変更を反映するには、アプリケーション・タイプと変更の範囲に応じて、アプリケーションまたは影響を受けるモジュール(部分的な再デプロイ)を再デプロイします。
アプリケーションおよびモジュールのデプロイメント準備を行う際には、Oracle推奨のベスト・プラクティスに従います。
デプロイするのがアーカイブ・ファイルであっても展開されたアーカイブ・ディレクトリであっても、「アプリケーションのインストール・ディレクトリの作成」で説明したように、デプロイメント・ファイルはアプリケーションのインストール・ディレクトリに格納します。インストール・ディレクトリを使用することで、WebLogic Server管理コンソールはデプロイメント・ファイルおよび構成ファイルの場所を認識できるので、デプロイメント・プロセスが簡素化されます。
必要に応じて、以前のバージョンのアプリケーションに簡単に戻れるよう、アプリケーションのインストール・ディレクトリ全体を、ソース・コントロール・システムで管理します。