| Oracle Smart Update Oracle WebLogic Serverへのパッチの適用 リリース3.3.0 B61614-03 |
|
 前 |
 次 |
この項には次のトピックが含まれます:
WebLogicシステム・クラスパスや、WebLogic Server上にデプロイされたアプリケーションのクラスパスなどのようなクラスパス内にロードされるクラスを含んだパッチを適用した後は、それらのクラスが適切なクラスパスに正しく挿入されたことを必ず確認してください。そうでない場合、それらは有効になりません。同様に、ライブラリ・パス内に挿入されるライブラリ・ファイルを含んだパッチについては、それらを使用するサーバー・インスタンスやアプリケーションが起動したときに、ライブラリ・ファイルを示すパスが正しく処理されることを必ず確認してください。
製品インストールに対するパッチ適用の際にSmart Updateで使用される方法は一律ではなく、パッチの種類および内容に応じて異なります。パッチには、次のいずれかが収められています:
製品インストール内のリソースに対する置換え
クラスローディング・メカニズムで使用されるクラス・ファイル(クラスパスや拡張ディレクトリのファイルなど)
ライブラリ・パスに含められるライブラリ・ファイル
ライブラリ・ファイルを含んだパッチは、ターゲット・インストール内にすでに存在するファイルを置き換えるものとは限りません。そのため、起動スクリプトによって明示的にロードする必要があります。
デプロイしてアプリケーションで参照する必要がある共有アーカイブ
モジュールと呼ばれるエンティティを更新するパッチJARファイル
パッチが適用される方法と、システム上でパッチがSmart Updateにより管理される方法については、次の項を参照してください。起動スクリプトを変更するかどうかおよび変更方法を判断するためには、これらを理解しておく必要があります。
この項では、WebLogicドメインに適用するパッチが有効になることを確認する場合に実行する必要のある基本的な作業についても説明します。
起動スクリプトによってロードされるクラスまたはライブラリ・ファイルを含んだパッチの場合、それらのクラスやファイルはSmart Updateによって、システム上にあるインストール・レベルのパッチ・ディレクトリに一元的に格納されます。これにより、クラスやライブラリ・ファイルは、それらを使用するWebLogic Serverインスタンスの起動時にロードできる状態になります。
このカテゴリに属するパッチの例として、次のようなものがあります
WebLogic Serverシステム・クラスパスにロードされるクラス・ファイル
WebLogic Server上にデプロイされたアプリケーションのクラスパスにロードされるクラス・ファイル
WebLogic Serverライブラリ・パスにロードされるライブラリ・ファイル
|
注意: パッチの検証およびターゲット・インストールへの適用はいつでも実行できますが、ただちに有効にならないパッチもあります。(a)クラスパスにロードされるクラスおよび(b)ライブラリ・パスにロードされるネイティブ・ライブラリ・ファイルのいずれかが含まれるパッチは、(a)必要に応じて、適切なWebLogicドメインまたはサーバーの起動スクリプトに変更を加えてパッチを参照するようにしたうえで、(b)対応するドメインまたはサーバーを再起動するまで、有効になりません。 |
製品インストールに含まれる既存のリソースを置き換えるパッチは、適用と同時に、そのインストール全体に対して自動的に有効になります。起動スクリプトによって有効化されるのではありません。したがって、システム・リソースの置換えを含んだパッチの場合、起動スクリプトに変更を加える必要はありません。
置換えアーティファクトを含んだパッチの一般的な内容の例を次に示します。
Webサーバー・プラグインのリソース
ソケット・マルチプレクサ
ダイナミック・リンク・ライブラリ
|
注意: Smart Updateでは、置き換えられたファイルがインストール・レベルのパッチ・ディレクトリのbackupサブディレクトリに格納されます。その後、置換えが含まれるパッチを削除すると、元のリソースがバックアップから復元されます。(バックアップの詳細は、表5-1を参照してください。)ただし、最大限の安全性を確保するために、システム・リソースを置き換えるパッチを適用する前には、置換え予定のシステム・リソースすべてについて別途バックアップを作成することをお薦めします。 |
共有アーカイブのパッチは、これを必要とするアプリケーションにより明示的にデプロイし、参照する必要があります。共有アーカイブのパッチをすべてのアプリケーションではなく、選択されたアプリケーションに適用する場合は、固有のパッチ・レベルごとにカスタム・パッチ・プロファイルを作成する必要があります。
My Oracle Supportからパッチをダウンロードすると、パッチ・ダウンロード・ディレクトリにパッチ・コンテナが配置されます。パッチ・コンテナには次の内容が収められています。
パッチ
1つのパッチには複数のファイルが含まれている場合があります。次のようなファイルが含まれます
クラスの置換え用として提供される同名のクラス(サーバー起動時にWebLogicシステム・クラスパスに挿入される)
ネイティブ・ライブラリ・ファイル(システム・パスに挿入される)
構成ファイル
そのパッチ・コンテナに含まれる各パッチに関するメタデータ
メタデータは、各パッチを、同じ製品インストールに適用されている他のすべてのパッチに対して検証するためにSmart Updateで使用される情報です。(パッチを適用すると、メタデータは、システム上のSmart Updateによって管理されるディレクトリにあるパッチ・レジストリに置かれます。詳細は、「インストール・レベルのパッチ・ディレクトリの構造」を参照してください。)
パッチ・プロファイルに対してパッチが適用されると、そのパッチに含まれる個々のファイルは次のように処理されます。
システム・リソース(WebLogic Serverプラグイン・モジュールなど)に対する置換えを含んだパッチの場合、該当する既存のリソースが、その置換えによって自動的に更新されます。
パッチJARファイル(ターゲット・インストール内にある同名のクラスに対する更新としてクラスパスにロードされるクラスのセット)がパッチに含まれている場合、次のイベントがj発生します:
パッチJARファイルがインストール・レベルのパッチ・ディレクトリに配置されます。このディレクトリについては、「インストール・レベルのパッチ・ディレクトリの構造」を参照してください。
パッチ・マニフェストJAR(パッチJARファイル内にあるクラスへのポインタを含んだファイル)がSmart Updateにより作成されます。現在のプロファイルに対するパッチ・マニフェストJARが存在する場合は、既存のパッチ・マニフェストJARが更新され、新しいパッチJARファイル内にあるクラスへのポインタが追加されます。パッチ・マニフェストJARファイルについては、「パッチ・マニフェストJARファイル」の説明を参照してください。
パッチが環境変数PATHまたはLIBPATHを介してシステム・ライブラリ・パスにロードされるネイティブ・ライブラリ・ファイルを含む場合、Smart Updateでは、現在選択されているパッチ・プロファイル専用のnativeというサブディレクトリの有無の確認が行われます。このサブディレクトリが見つからない場合は、作成されます。nativeサブディレクトリについては、「「起動スクリプトを開く」ダイアログ・ボックスのアイコン」を参照してください。
製品をインストールし、Smart Updateを実行すると、パッチ・ディレクトリが作成されます。各製品(WebLogic Server、Workshop for WebLogic、WebLogic Integration、WebLogic Portalなど)には、ミドルウェア・ホーム・ディレクトリの下に独自のパッチ・ディレクトリ構造(patch_wls1001、patch_wlw1020、patch_wli1020、patch_wlp1020など)があります。
|
注意: カスタム・プロファイルは、Smart Update 3.3.0以降、非推奨になっています。これ以降、カスタム・プロファイルを使用しないようにお薦めします。カスタム・プロファイルでは、インストール全体で使用されるWebLogic Serverパッチのインストールがより複雑になっています。 |
製品固有パッチ・ディレクトリ構造は、製品のパッチ・メンテナンスの新しい区分を提供します。またそれによって、今後の製品が、WebLogic Serverの異なる、または共通のバージョン間で相互運用する際の柔軟性も向上します。
図5-1は、MW_HOME\patch_productディレクトリの構造を示しています。
表5-1では、各パッチ・ディレクトリの内容について説明します。
表5-1 インストール・レベルのパッチ・ディレクトリ内のディレクトリとファイル
| このディレクトリは | 次を含みます |
|---|---|
|
patch_product\backup |
システムを以前のパッチ・レベルに復元するために必要なファイルおよび情報が格納されているパッチ・バックアップ・マニフェストを含みます。 このディレクトリは、製品インストール・ディレクトリ内に配置されるファイルを含んだ、インストール全体を対象とするパッチを適用すると、作成されます。 |
|
patch_product\patch_jars |
各製品のパッチ・ディレクトリ(図5-1に示す 各製品のパッチ・ディレクトリの下の1つのパッチJARファイルには、次のうち1つまたは複数のものが含まれます。
注意: システム・リソースに対する置換えを含むパッチJARファイルは、このディレクトリ( 注意: 追加されるパッチJARファイルの格納に十分なディスク領域があるか確認しておくことをお薦めします。JARファイルを含んだパッチのサイズについては、「パッチ情報の表示」を参照してください。 |
|
patch_product\profiles\default |
デフォルトのパッチ・プロファイルのディレクトリ。パッチを適用すると、次のうち1つまたは複数のサブディレクトリが作成される場合があります。
|
|
patch_product\profiles\custom-profile-name |
カスタム・パッチ・プロファイル用のディレクトリ。カスタム・パッチ・プロファイルの名前がディレクトリ名となります。カスタム・パッチ・プロファイルが1つ作成されるたびに、そのプロファイルの名前を持つディレクトリが自動的に作成されます。カスタム・パッチ・プロファイルの各ディレクトリには、次のうち1つまたは複数のサブディレクトリが含まれます。
|
|
patch_product\registry |
次に関する情報が含まれます
この情報は、パッチ検証などの処理を実行するためにSmart Update内部で使用されます。 |
同名の既存クラスに取ってかわるためにクラスパスに挿入されるクラスを含んだパッチは、パッチ・マニフェストJARによって参照されます。そのようなクラスを含んだパッチをパッチ・プロファイルに適用すると、対象プロファイルのパッチ・マニフェストJARファイルがSmart Updateによって自動的に更新され、新しいパッチ内にあるクラスを参照するようになります。
たとえば、パッチにBug10131320_1032.jarという名前のJARファイルが含まれ、このファイルにWebLogicシステム・レベル・クラスがある場合、そのパッチをデフォルト・パッチ・プロファイルに適用すると、Smart Updateにより次の処理が実行されます。
Bug10131320_1032.jarがMW_HOME\patch_wls1032\patch_jarsディレクトリに追加されます。
次のファイルが存在しない場合、作成されます。
MW_HOME\patch_wls1032\profiles\default\sys_manifest_classpath\weblogic_patch.jar
weblogic_patch.jar内に、Bug10131320_1032.jar内のWebLogicシステム・クラスを指す次の参照が追加されます。
Class-Path: C:\Oracle\Middleware\patch_wls1032\patch_jars\Bug10131320_1032.jar
MW_HOME\patch_wls1032\registryディレクトリ内のパッチ・レジストリ情報が更新されます。
対応するWebLogic Serverインスタンスの起動時にシステム・ライブラリ・パスにロードされるネイティブ・ライブラリ・ファイルを含んだパッチの場合は、適用先パッチ・プロファイルのnativeサブディレクトリにそれらのライブラリ・ファイルが格納されます。
たとえば、サーバー起動時にシステム・ライブラリ・パスにロードされるlibmuxer.soというファイルがパッチに含まれているとします。このパッチをデフォルト・パッチ・プロファイルに適用すると、Smart Updateにより次の処理が実行されます。
次のディレクトリが存在しない場合、作成されます。
MW_HOME\patch_wls1032\profiles\default\native
次のディレクトリにlibmuxer.soが配置されます。
MW_HOME\patch_wls1032\profiles\default\native
次のディレクトリ内で管理されているパッチ・レジストリ情報が更新されます。
MW_HOME\patch_wls1032\registry
共通のモジュール・パッチか製品固有のモジュール・パッチかにかかわらず、モジュール・パッチが適用された場合、Smart Updateによって、MW_HOME\patch_product\profiles\profileName\modulesディレクトリにパッチが追加されます。元のモジュールJARファイルは修正されません。この方法が取られているのは、適用したパッチの有効範囲を限定するためです。
たとえば、WebLogic Event Server用モジュール・パッチがMW_HOME\wlevs20\modules\com.bea.wlevs.processor.monitor_2.0.0.0.jarに更新したクラスを含み、そのパッチがデフォルト・パッチ・プロファイルに適用された場合、Smart Updateでは次のタスクが実行されます。
次のディレクトリが存在しない場合、作成されます。
MW_HOME\patch_wlevs20200\profiles\default\modules
更新されたcom.bea.wlevs.processor.monitor_2.0.0.0.jarを、MW_HOME\patch_wlevs20200\profiles\default\modulesディレクトリに追加します
MW_HOME\patch_wlevs20200\registryディレクトリ内のパッチ・レジストリ情報が更新されます。
WebLogic Event Serverが起動すると、MW_HOME\wlevs20200\modulesディレクトリにまだある元のモジュールではなく、MW_HOME\patch_wlevs20200\profiles\default\modulesにあるパッチ適用済のモジュールが使用されます。
次の場合は、起動スクリプトに変更を加えなくても、クラスパスおよびライブラリ・パスに対するパッチがWebLogicドメイン・サーバーの起動時に正しく取り込まれると考えられます。
WebLogicドメイン用に構成したOracle製品サーバー・インスタンスを起動するためのデフォルト・スクリプトを構成ウィザードで生成し、実際のWebLogicドメインでそのスクリプトを使用している場合。
パッチの適用範囲を特定のWebLogicドメインやサーバー・インスタンスに限定する必要がない場合。
それ以外の場合は、追加の作業手順を実行して、製品サーバーの起動時にパッチが適切なクラスパスやライブラリ・パスに挿入されるようにする必要があります。追加の作業手順が必要となるのは、パッチを適用した製品の使用環境に次のいずれかが該当する場合です。
WebLogicドメイン内のサーバーを起動するときに、デフォルトのcommEnvスクリプトを呼び出さない、カスタム・スクリプトを使用します。
Windows:
WL_HOME\common\bin\commEnv.cmd
UNIX:
WL_HOME/common/bin/commEnv.sh
特定の製品インストール上で動作するすべてのドメインおよびサーバーにパッチを広く適用するのではなく、特定のWebLogicドメインまたはサーバーのみに適用範囲を限定する必要があります。
ここでは、スクリプトの使用方法およびSmart Update Start Script Editorを使用しての起動スクリプトの変更方法について説明します。なお、すべてのWebLogicドメインおよびサーバーにクラスパス、拡張クラスパスおよびネイティブ・ライブラリ・ファイルのパッチを参照させるために使用できるカスタム・スクリプトについても説明します。
|
注意: Workshop for WebLogic (10.1以降のリリース)では、ランタイムWebLogic Serverパッチは自動的に有効化されません。Smart updateを使用してパッチを適用したら、Workshop IDEでランタイムWebLogic Serverのパッチ・プロファイルも指定する必要があります。詳細は、Workshop for WebLogicのドキュメントを参照してください。 |
WebLogic Serverインスタンスの起動時、パッチが確実にクラスパスまたはシステム・ライブラリ・パスにロードされるようにするために、該当するサーバーの起動スクリプトにパッチへのポインタを追加することが必要な場合があります。次の項では、Smart Updateの動作と、起動スクリプトに加える必要がある変更の内容について説明します。
WebLogic Serverインスタンスが起動する際には、いくつかの起動スクリプトが実行されます。そうしたスクリプトで実行される処理の1つに、システムで使用されるクラスパスとライブラリ・パス(WebLogicシステム・クラスパスなど)の定義があります。デフォルトでは、すべてのWebLogic Serverインスタンスで、次のいずれかのスクリプト内で設定されるクラスパスおよびライブラリ・パス定義が使用されます。
Windows:
WL_HOME\common\bin\commEnv.cmd
UNIX:
WL_HOME/common/bin/commEnv.sh
|
注意: UNIX環境でcommEnv.shをコマンド・ラインから手動で実行するか、カスタム・サーバー起動スクリプトから呼び出す場合は、次の構文を使用する必要があります。
または
|
commEnvスクリプトには、表5-2で説明する環境変数のデフォルトの定義が含まれています。デフォルトでは、それらのパッチ・パス変数はすべてのWebLogic Serverインスタンスが起動する際に使用されます。また、クラス・パスとライブラリ・パスに挿入されるパッチをポイントしています。
表5-2 commEnvスクリプト内で定義されるパッチ・パス変数
| この変数は | 次のロケーションに設定されています |
|---|---|
|
PATCH_CLASSPATH |
デフォールトのパッチ・プロファイル用のパッチ・マニフェストJARファイル( このJARファイルには、WebLogicのシステム・クラスパスにロードされるパッチJARファイル内にあるクラスへの参照が含まれています。たとえば、Windowsの場合、 if "%PATCH_CLASSPATH%" == "" set PATCH_CLASSPATH= %WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH% 注意: My Oracle Supportから提供されるパッチの多くは、 |
|
WEBLOGIC_EXTENSION_DIRS |
デフォールトのパッチ・プロファイル用のWebLogic拡張ディレクトリ・パッチ・マニフェストJARファイル( このJARファイルには、WebLogicサーバーにデプロイされているアプリケーションのクラスパスにロードされたパッチJARファイル内にあるクラスへの参照が含まれています。たとえば、Windowsの場合、 if "%WEBLOGIC_EXTENSION_DIRS%" == "" set WEBLOGIC_EXTENSION_DIRS= %BEA_HOME%\ patch_wls1030\profiles\default\sysext_manifest_classpath 注意: この変数は、WebLogic Server上にデプロイされたアプリケーションのクラスパスにロードされる、パッチJARファイル内のクラスを必要とする製品で使用するため、予約されています。デプロイされたアプリケーションにパッチを適用するためのこのメカニズムは、現在WebLogic Server 9.1では使用されていません。 |
|
PATCH_LIBPATH (UNIXのみ) |
デフォルトのパッチ・プロファイル用のインストール・レベルのディレクトリ内の このフォルダには、
if [ "${PATCH_LIBPATH}" = "" ];
then PATCH_LIBPATH=${BEA_HOME}
/patch_wls1030/profiles/default/native
|
|
PATCH_PATH (Windowsのみ) |
デフォルトのパッチ・プロファイル用のインストール・レベルのパッチ・ディレクトリ内のnativeフォルダ このフォルダには、 if "%PATCH_PATH%" == "" set PATCH_PATH= %BEA_HOME%\patch_wls1030\profiles\default\native |
commEnvスクリプト内では、表5-2で説明するパッチ・パス変数が、システム・クラスパス、ライブラリ・パスなどを設定する文に必要に応じて挿入されます。たとえば、commEnvスクリプト内にある次のデフォルト文では、WebLogicシステム・クラスパスを設定しています。クラスパス定義の冒頭で変数PATCH_CLASSPATHが使用されている箇所を太字で示します。
set WEBLOGIC_CLASSPATH=%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar;
%WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar;
%WL_HOME%\server\lib\webservices.jar
サーバーの起動時にcommEnvスクリプトが実行されると、これらのパッチ・パス変数で参照されているクラスおよびライブラリ・ファイルがロードされ、classpath文またはpath文でそれ以降に参照されている同名のクラスまたはライブラリ・ファイルをオーバーライドします。
図5-2は、PATCH_CLASSPATH環境変数を介して参照され、commEnvスクリプトによってWebLogicシステム・クラスパスにロードされるクラスを含んだパッチJARファイルを示しています。
「すべてのドメインおよびサーバーで使用されるクラス・パスとライブラリ・パスを定義したデフォルト・スクリプト」で説明するパッチ・パス変数が、WebLogic Serverインスタンスの起動に先立って実行されるスクリプト(startWebLogic、setDomainEnvなど)の中で定義されている場合、該当するサーバー・インスタンスに対してはそうした既存の定義内容が使用されます。commEnv内の変数定義によってオーバーライドされることはありません。
たとえば、MyTestDomainドメインのsetDomainEnvスクリプトに、MyTestDomain内のすべてのWebLogic Serverインスタンスで使用するPATCH_CLASSPATH変数の定義が含まれている場合、該当するサーバー・インスタンスに対してはその定義内容が使用され、commEnvスクリプト内のPATCH_CLASSPATHはオーバーライドされます。したがって、起動スクリプト内にパッチ・パス変数の定義を追加する際は、別の起動スクリプトを呼び出す文よりも前に定義を記述する必要があります。
個々のWebLogic Serverインスタンスそれぞれについて、必要なすべてのパッチを使用して起動が正しく行われるようにしてください。使用環境において、いずれかのパッチ・パス変数を定義してWebLogic Serverインスタンスを起動することが求められる場合は、次の事項を理解しておく必要があります。
製品インストール環境において各種スクリプトが実行されるデフォルトの順序。「起動スクリプトの実行順序」を参照してください。
構成ウィザードで作成されるデフォルト起動スクリプトに含まれている、パッチ・パス変数定義用の各種プレースホルダー。「デフォルト・スクリプト内のパッチ・パス変数定義用プレースホルダー」を参照してください。
使用環境内にある各種の起動スクリプトが実行される順序と、起動スクリプトが呼び出される場所について理解していれば、変更を加える必要のあるスクリプトを判断し、すべてのターゲット・サーバー・インスタンスに必要なすべてのパッチ・パス変数について、確実に正しい値が代入されるようにすることができます。
WebLogic Serverインスタンスを起動し、各WebLogicドメインおよびOracle製品インストールに対して変数を設定するデフォルト・スクリプトが用意されています。
それらのスクリプトは、各スクリプトの内容に応じて決まる特定の順序に従って実行されます。
次の点について、表5-3で説明します。
サーバー、WebLogicドメイン、および製品インストールに対して作成される各種のデフォルト・スクリプト
各スクリプトの機能
スクリプトが実行される順序
表5-3 製品インストールに含まれるスクリプトのデフォルト・セット
| このスクリプトは | この機能を実行します | 実行されるとき |
|---|---|---|
|
WebLogicドメインの Windows: startManagedWebLogic.cmd UNIX: startManagedWebLogic.sh |
ドメイン内の管理対象サーバーを起動します。スクリプト内で定義されるパッチ・パス変数は、当該スクリプトから起動されるすべての管理対象サーバーで使用されます。 |
構成に管理対象サーバーが含まれるドメイン(クラスタなど)では、このスクリプトはデフォルトで最初に実行されます。 このスクリプトからは、 |
|
WebLogicドメインの Windows: startWebLogic.cmd UNIX: startWebLogic.sh |
ドメイン内のWebLogic Serverインスタンスを起動します。スクリプト内で定義されるパッチ・パス変数は、ドメイン・サーバーすべて(すでに起動しているものを除く)に対して有効になります。 たとえば、前もって実行された |
構成に管理対象サーバーが含まれるドメインでは、このスクリプトはデフォルトで
|
|
WebLogicドメインの Windows: setDomainEnv.cmd UNIX: setDomainEnv.sh |
WebLogic Serverインスタンスを起動および実行するためのドメイン全体の環境を設定します。スクリプト内で定義されるパッチ・パス変数は、ドメイン・サーバーすべて( |
このスクリプトは、デフォルトで
|
|
インストールの Windows: commEnv.cmd UNIX: commEnv.sh |
WebLogic Serverインスタンスを起動および実行するための、ドメイン全体の環境を設定します。スクリプト内で定義されるパッチ・パス変数は、ドメイン・サーバーすべて( |
デフォルトでは、当該インストール上で起動および実行されるサーバー用に設定を定義するために呼び出されるスクリプトとしてはこれが最後です。 注意: UNIX環境で
. WL_HOME/common/bin/commEnv.sh
すでにbinディレクトリに移動している場合は、次の構文を使用します。 . ./commEnv.sh |
構成ウィザードを使用してWebLogicドメインを作成すると、次に説明するとおり、パッチ・パス変数定義用のプレースホルダーを含んだスクリプトがそのドメイン用に作成されます。
setDomainEnvスクリプトには、次に示すコード行が含まれています(デフォルトではコメント・アウトされています)。
@REM If you want to override the default Patch Classpath, Library Path and Path for this domain, @REM Uncomment the following lines and add a valid value for the environment variables @REM set PATCH_CLASSPATH=[myPatchClasspath] (windows) @REM set PATCH_LIBPATH=[myPatchLibpath] (windows) @REM set PATCH_PATH=[myPatchPath] (windows) @REM PATCH_CLASSPATH=[myPatchClasspath] (unix) @REM PATCH_LIBPATH=[myPatchLibpath] (unix) @REM PATCH_PATH=[myPatchPath] (unix)
これらのコメント行は、パッチ・パス変数の定義内容を記述する場所がわかりやすいように、構成ウィザードによって用意されるものです。たとえば、MyProfileというカスタム・プロファイル内のパッチJARファイルをドメインから参照する場合は、次のようにPATCH_CLASSPATH変数のプレースホルダーのコメントを解除し、値を定義します。
PATCH_CLASSPATH=%BEA_HOME%\patch_wls1001\profiles\MyProfile\sys_manifest_classpath\weblogic_patch.jar
|
注意: カスタム・プロファイルは、Smart Update 3.3.0以降、非推奨になっています。これ以降、カスタム・プロファイルを使用しないようにお薦めします。カスタム・プロファイルでは、インストール全体で使用されるWebLogic Serverパッチのインストールがより複雑になっています。 |
commEnvスクリプトにデフォルトで含まれているこれらの変数の定義については、表5-2を参照してください。
パッチ・パス変数定義の追加作業を支援するために、Smart Updateには起動スクリプト・エディタが用意されています(「起動スクリプト・エディタの使用」の説明を参照)。
|
注意: 1つの起動スクリプト内で参照するWebLogicシステム・レベル・クラスのパッチ・マニフェストJARファイルは1つだけにしてください。複数のファイルを参照すると、実行時に予期できない動作が生じることがあります。 |
構成ウィザードで作成されるstartWebLogicおよびstartManagedWebLogic起動スクリプトには、パッチ・パス変数定義用のプレースホルダーはありません。これらのスクリプトのいずれかに1つ以上の変数定義を追加する場合は、どのWebLogic Serverインスタンスに影響が及ぶかについて十分に注意してください。
パッチ・パス変数定義を追加する起動スクリプトの数を最小限にとどめることにより、インストール済の製品のメンテナンス・レベルやバージョンを変更またはアップグレードした場合、起動スクリプト関連で必要となるメンテナンス作業の量が軽減されます。
起動スクリプトでプロファイル内のクラスのパッチまたはライブラリ・ファイルのパッチを参照する場合に実行が必要な固有の作業は、これらのパッチの適用範囲が、製品インストール上で実行されているすべてのWebLogicドメインおよびサーバーを対象としているのか、そのインストールの特定のドメインまたはサーバーのみを対象としているのかに応じて異なります。
カスタム起動スクリプトを使用する場合、またはパッチの適用範囲を特定のWebLogicドメインまたはサーバーに限定する必要がある場合、起動スクリプトを次のように変更する必要があります。
特定の製品インストール上で動作するすべてのサーバー・インスタンスのシステム・クラスパスまたはライブラリ・パスにパッチを挿入する場合であっても、カスタム起動スクリプトを使用していれば、デフォルト・パッチ・プロファイルへの参照をそのスクリプトに追加する必要があります。
パッチの適用範囲を特定のWebLogicドメインまたはサーバーに限定する場合、次の2つの作業を行う必要があります。
製品インストール上で実行しているドメインまたはサーバーにパッチを適用するためのカスタム・パッチ・プロファイルを作成します。
|
注意: カスタム・プロファイルは、Smart Update 3.3.0以降、非推奨になっています。これ以降、カスタム・プロファイルを使用しないようにお薦めします。カスタム・プロファイルでは、インストール全体で使用されるWebLogic Serverパッチのインストールがより複雑になっています。 |
該当するWebLogicドメインまたはサーバーの起動スクリプト内に、カスタム・パッチ・プロファイルへの参照を追加します。
適用したクラス・パス・パッチおよびライブラリ・パス・パッチが正しく使用されるように起動スクリプトを変更する方法については、「概要」を参照してください。次の項目についての説明があります。
システム・クラスパスまたはライブラリ・パスに動的にロードされることが必要なパッチ・ファイルと、インストール全体に対して自動的に有効になるパッチとの区別
パッチ適用時にSmart Updateによってパッチ・ファイルの内容が配置されるシステム上の場所
「起動スクリプトに対するパッチの場所の指定について」も参照し、構成ウィザードで作成されるデフォルト・スクリプトによってクラスやライブラリのパッチがシステム・クラスパスやライブラリ・パスに自動的に挿入される仕組みについて理解してください。クラスやライブラリのパッチを正しく参照するようスクリプトに変更を加える必要がある場合は、このプロセスを理解しておくことが重要です。
スクリプトの変更が必要になるのは、次のような場合です:
使用している環境内でデフォルト・スクリプトを使用していない。
パッチの適用範囲を特定のWebLogicドメインやサーバーの起動スクリプトに限定する必要がない。
表5-4は、起動スクリプトの変更に関する情報をまとめたものです。
表5-4 起動スクリプトの変更
| 次に関する情報は | 次のトピックを参照してください |
|---|---|
|
起動スクリプト・エディタの使用 |
|
|
起動スクリプトを開く方法 |
|
|
すべてのWebLogicドメインおよびサーバーで使用するクラスおよびライブラリ・パスのパッチを参照するために起動スクリプトに加える変更の内容 |
カスタム・スクリプト経由のパッチですべてのドメインとサーバーをポイントする方法 |
|
特定のWebLogicドメインまたはサーバーで使用するクラスおよびライブラリ・パスのパッチを参照するために起動スクリプトに加える変更の内容 |
第6章「個々のアプリケーション、ドメイン、またはサーバーへのパッチの適用」 |
|
カスタム・パッチ・プロファイルの作成(WebLogicドメインまたはサーバーからパッチを参照するようスクリプトを変更する前に必要) |
|
起動スクリプト・エディタはSmart Updateに用意されているツールです。使用環境内で目的の起動スクリプトを見つけ、スクリプト内にパッチ・パス変数の定義を作成する作業を簡単に実行できます。Smart Updateは、デフォルト・パッチ・プロファイルとカスタム・パッチ・プロファイルの組合せで表される、パッチ・レベルの異なる複数の製品を使用する環境におけるスクリプトを維持されます。
|
注意: カスタム・プロファイルは、Smart Update 3.3.0以降、非推奨になっています。これ以降、カスタム・プロファイルを使用しないようにお薦めします。カスタム・プロファイルでは、インストール全体で使用されるWebLogic Serverパッチのインストールがより複雑になっています。 |
この変更により、下部のペインに表示されるスクリプト・スニペットも製品固有のものになり、myCustomProfileがターゲットに設定されます。各種のパスそれぞれに対して異なるスニペットが提供されています。これらのパスには、クラスパス、WebLogic拡張クラスパスおよびネイティブが含まれます。
SET PATCH_CLASSPATH=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\sys_manifest_classpath\weblogic_patch.jar SET WEBLOGIC_EXTENSION_DIRS=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\sysext_manifest_classpath SET PATCH_LIBPATH=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\native SET PATCH_PATH=%BEA_HOME%\patch_wls1001\profiles\myCustomProfile\native
export PATCH_CLASSPATH=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/sys_manifest_classpath/weblogic_patch.jar
export WEBLOGIC_EXTENSION_DIRS=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/sysext_manifest_classpath
export PATCH_LIBPATH=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/native
export PATCH_PATH=${BEA_HOME}/patch_wls1001/profiles/myCustomProfile/native
この手順は、WebLogic Platform 9.x、ALSB 2.5、およびALSB 2.6用に起動スクリプト・エディタを使用する方法を順を追って説明します。起動スクリプト・エディタを使用するには、次の手順を実行します:
Smart Updateの「ターゲット・インストール」パネルで、ターゲット・インストールを選択します。
「パッチ」→「スクリプト・エディタの起動」を選択します。
「スクリプト・エディタの起動」ダイアログ・ボックスで次の操作を実行します。
WebLogicドメインまたはサーバーから参照するパッチ・プロファイルを選択します。カスタム・パッチ・プロファイルを使用してパッチを特定のWebLogicドメインまたはサーバーに適用する方法の詳細は、第9章「パッチの配布に関するベスト・プラクティス」を参照してください。
起動スクリプトを編集する製品を選択します。図5-3を参照してください。
|
注意: Workshop for WebLogicを選択した場合、そのカスタム・プロファイルに存在するWebLogic ServerパッチはWebLogicドメインに自動的にダウンロードされません。 |
変更を加える起動スクリプトを開きます。
詳しい手順は、「起動スクリプトを開く方法」を参照してください。
パッチ・プロファイルに、適切なパッチ・パス変数定義を追加します。
起動スクリプト・エディタには、PATCH_CLASSPATH、WEBLOGIC_EXTENSION_DIRS、PATCH_LIBPATH、PATCH_PATHの各変数に対して推奨される定義付きのコード・スニペットが用意されています。これらの定義はすべて、前に選択したパッチ・プロファイル用にカスタマイズされています。ただし、定義内容は必要に応じて変更することもできます。
デフォルト・パッチ・プロファイル内のパッチを参照するようにスクリプトを修正する場合は、「カスタム・スクリプト経由のパッチですべてのドメインとサーバーをポイントする方法」の手順を参照してください。
カスタム・パッチ・プロファイル内のパッチを参照するようにスクリプトを修正する場合は、第6章「個々のアプリケーション、ドメイン、またはサーバーへのパッチの適用」を参照してください。カスタム・パッチ・プロファイルを作成して、そのプロファイルへのポインタをWebLogicドメインまたはサーバーの起動スクリプトに追加する方法についての説明があります。
カスタム・パッチ・プロファイルmyCustomProfileにWebLogic ServerとWorkshop for WebLogicの両方のパッチが含まれており、そのすべてを特定のドメインでアクティブにする場合は、スニペットのようではあるがsetPatchEnv.cmd内の宣言でモデル化されている、製品固有のトークン化されたパス宣言を含めるようにドメインの起動スクリプトを最初に編集します。
例:
WLS_PATCH_CLASSPATH= and WLW_PATCH_CLASSPATH=
変更前の内容は次のとおりです。
PATCH_CLASSPATH=
また、setPatchEnv.cmdに含まれているような連結文を追加する必要もあります。
set PATCH_CLASSPATH=%WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH%
この処理をパスのタイプごとに繰り返します。
起動スクリプトを保存します。
|
注意: パッチ・パス変数の定義を起動スクリプトに追加する際、別の起動スクリプトを呼び出す文より前にその定義を配置するようにしてください。たとえば、setDomainEnvスクリプトにパッチ・パス変数の定義を追加する場合は、commEnvスクリプトを呼び出す文の前に追加します。この位置関係を守れば、追加した定義がその後呼び出される別の起動スクリプト内の定義によってオーバーライドされることはありません。 |
起動スクリプトの変更方法は、Smart Updateによって強制または制限されることはありません。ただし、構成ウィザードなどの標準ツールによってデフォルトで作成される起動スクリプトの内容と、ツールによって決定されるデフォルトの格納場所にはそのまま従うことをお薦めします。そうすることで、パッチ・プロファイル内のパッチを参照するよう修正が必要な適切な起動スクリプトを見つけるための機能が期待どおりに動作し、Smart Updateをより便利に利用できます。
「スクリプト・エディタの起動」ダイアログ・ボックスはウィザードではないため、次のような処理はできません。
修正が必要とされるすべての適切なスクリプトの特定。構成ウィザードによってデフォルトで作成される起動スクリプトを使用していれば、起動スクリプト・エディタを使用して目的のスクリプトをすばやく見つけることができます。
サーバーおよびドメインの起動メカニズムがカスタマイズされている場合、起動スクリプト・エディタ内のみではすべての変更作業を完結できないことがあり、追加の作業手順が必要となる可能性があります。
起動スクリプトの修正。起動スクリプト・エディタでは、スクリプトを表示し、スクリプトに対して推奨される追加コードも提示しますが、変更内容と保存場所の最終決定はユーザーが行います。
起動スクリプトのバックアップ・コピーを作成します。
「スクリプト・エディタの起動」ダイアログ・ボックスで「開く」をクリックして起動スクリプトを開くと、Smart Updateの「起動スクリプトを開く」ダイアログ・ボックスが表示されます。このダイアログ・ボックスは、WebLogicドメイン、管理対象サーバー、クラスタ、または個別のサーバーについて、パッチ・プロファイル内のパッチへのポインタを追加する対象の起動スクリプトを見つけるために使用します。
「スクリプト・エディタの起動」ダイアログ・ボックスでは、表5-5に示すアイコンを使用すると、変更対象の起動スクリプトを含むディレクトリに移動できます。
表5-5 「起動スクリプトを開く」ダイアログ・ボックスのアイコン
| このアイコンは | 次を表します |
|---|---|
 |
WebLogicドメイン内のbinサブディレクトリ(変更する必要があるスクリプトがデフォルトで格納されている)の親ディレクトリ。 |
 |
スクリプト・ファイルが格納されているドメイン・サブディレクトリ(binなど)。サブディレクトリを開いて中のスクリプトを表示するには、このアイコンをクリックします。 |
構成ウィザードによってドメイン用に作成されたディレクトリ構造を使用している場合は、Smart Updateにより、変更が必要な起動スクリプトのあるディレクトリへと誘導されます。
修正対象となる特定の起動スクリプトを見つける場合の詳細は、以下のトピックを参照してください。
ドメインの起動スクリプトに変更を加えるには、対象となるドメインのbinサブディレクトリにあるsetDomainEnvまたはstartWebLogicスクリプトを選択します。図5-3は、WindowsシステムでsetDomainEnvスクリプトを選択する方法を示しています。
図5-3 起動スクリプトの選択ダイアログ・ボックスでのsetDomainEnvスクリプトの選択
setDomainEnvスクリプトには、PATCH_CLASSPATH、PATCH_LIBPATH、PATCH_PATHの各変数定義のプレースホルダーが含まれています。このスクリプトの変更の詳細は、表5-6を参照してください。
表5-6 スクリプトの変更
| 次の変更に関する情報は | 次の項を参照してください |
|---|---|
|
|
デフォルト・スクリプト内のパッチ・パス変数定義用プレースホルダー |
|
このスクリプトをデフォルト・パッチ・プロファイル内のパッチをポイントするように変更する方法 |
カスタム・スクリプト経由のパッチですべてのドメインとサーバーをポイントする方法 |
|
このスクリプトをカスタム・パッチ・プロファイル内のパッチをポイントするように変更する方法 |
ドメインおよびサーバーからカスタム・パッチ・プロファイルへの参照 |
ドメイン内にある管理対象サーバーすべて(デフォルトではクラスタ内のサーバーすべてを含む)の起動スクリプトに変更を加えるには、対象となるドメインのbinサブディレクトリにあるstartManagedWebLogicスクリプトを選択します。図5-4は、Windowsシステムの場合についてその方法を示しています。
図5-4 起動スクリプトの選択ダイアログ・ボックスでのstartManagedWebLogicスクリプトの選択
このスクリプトの変更の詳細は、表5-7を参照してください。
表5-7 スクリプトの変更
| このスクリプトに対する変更に関する情報は | 次の項を参照してください |
|---|---|
|
このスクリプトをデフォルト・パッチ・プロファイル内のパッチをポイントするように変更する方法 |
カスタム・スクリプト経由のパッチですべてのドメインとサーバーをポイントする方法 |
|
このスクリプトをカスタム・パッチ・プロファイル内のパッチをポイントするように変更する方法 |
ドメインおよびサーバーからカスタム・パッチ・プロファイルへの参照 |
ドメイン内の特定のサーバーに対する起動スクリプトに変更を加えるには、対象となるドメインのbinサブディレクトリにある、特定のサーバー用に固有の名前を付けた起動スクリプトを選択します。図5-5は、Windowsシステムで起動スクリプトstartWebLogicServer1を選択する方法を示しています。
このスクリプトの変更の詳細は、表5-8を参照してください。
表5-8 起動スクリプトの変更
| このスクリプトに対する変更に関する情報は | 次の項を参照してください |
|---|---|
|
このスクリプトをデフォルト・パッチ・プロファイル内のパッチをポイントするように変更する方法 |
カスタム・スクリプト経由のパッチですべてのドメインとサーバーをポイントする方法 |
|
このスクリプトをカスタム・パッチ・プロファイル内のパッチをポイントするように変更する方法 |
ドメインおよびサーバーからカスタム・パッチ・プロファイルへの参照 |
クラスおよびライブラリのパッチは、実際のドメインで使用されるクラス・パスおよびライブラリ・パスに確実に正しくロードされるようにすることが重要です。WebLogicドメイン内でサーバー起動や環境設定に使用している起動スクリプトから、「すべてのWebLogicドメインおよびサーバーで使用されるクラス・パスとライブラリ・パスを定義したデフォルト・スクリプト」に示すとおりデフォルトのcommEnvスクリプトの呼出しが行われない場合は、次のようにスクリプトを修正する必要があります。
デフォルト・パッチ・プロファイルに適用されているクラスおよびライブラリのパッチを指し示す環境変数を定義する
それらの環境変数を次のパスに追加する
WebLogicシステム・クラスパス
WebLogic Server上にデプロイされたアプリケーションで使用されるクラスパス(製品の要件に応じて追加)
ライブラリ・パス
デフォルトのcommEnvスクリプトのこの機能は、次のいずれかの方法で必ず自身のスクリプトに追加してください。
デフォルト・パッチ・プロファイル内のパッチを参照するコードを単一のスクリプトにまとめ、一元管理する方法。その一元化したスクリプトを、すべての起動スクリプトから呼び出すようにします。パッチを参照するコードのメンテナンス作業が簡略化され、環境変化に伴って発生するスクリプト変更作業の量が最小限になるため、この方法を採用することをお薦めします。
デフォルト・パッチ・プロファイルに適用されているパッチを参照するコードを、個々の起動スクリプト内にコピーする方法。当該コードを個々の起動スクリプト内に確実にコピーすれば、適用済みのパッチがドメイン内のすべてのサーバーから参照されることを保証できます。ただし、サーバーの追加や構成の変化が使用環境内に生じると、起動スクリプトを正しくメンテナンスする作業の内容は複雑になっていきます。
使用環境内にあるドメインおよびサーバーが起動する際には、デフォルト・パッチ・プロファイルに適用されているパッチJARがWebLogicシステム・クラスパスに挿入される必要があります。パッチJARがクラスパスに確実に挿入されるようにするため、使用する起動スクリプトに、この項で説明するコードを必ず追加してください。
PATCH_CLASSPATH環境変数のデフォルトの定義を追加します。例:
if "%PATCH_CLASSPATH%" == "" set PATCH_CLASSPATH=BEA_HOME\patch_wls1001\profiles\default\sys_manifest_classpath\weblogic_patch.jar
この定義を使用すると、個々のサーバーまたはドメインからカスタム・パッチ・プロファイル内のパッチを参照する必要がある場合に、そのサーバーまたはドメインでこの定義をオーバーライドできます。この定義におけるBEA_HOMEは、ミドルウェア・ホーム・ディレクトリ・パスを表します。絶対パスを指定する方法と、前に定義した環境変数を使用する方法(推奨)があります。
PATCH_CLASSPATHを、WebLogicシステム・クラスパスを設定する文の先頭に追加します。例:
set WEBLOGIC_CLASSPATH=%PATCH_CLASSPATH%;%JAVA_HOME%\lib\tools.jar; %WL_HOME%\server\lib\weblogic_sp.jar;%WL_HOME%\server\lib\weblogic.jar; %WL_HOME%\server\lib\webservices.jar
このように定義すれば、パッチJARに収められたクラスが、クラスパス内でそれより後に参照されている同名の既存クラスをオーバーライドします。
デフォルト・パッチ・プロファイルに、製品対応のWebLogic Serverにデプロイされているアプリケーション用のパッチJARが含まれている場合、次のように、WEBLOGIC_EXTENSION_DIRS環境変数を該当するアプリケーションのパッチJARをポイントするように定義できます。
if "%WEBLOGIC_EXTENSION_DIRS%" == "" set WEBLOGIC_EXTENSION_DIRS= %BEA_HOME%\patch_wls1001\profiles\default\sysext_manifest_classpath
|
注意: WEBLOGIC_EXTENSION_DIRS変数は、WebLogic Server上にデプロイされたアプリケーションのクラスパスにロードされる、パッチJARファイル内のクラスを必要とする製品で使用するため、予約されています。デプロイされたアプリケーションに対するパッチ用のこのメカニズムは、現在、WebLogic Server 9.1では使用されていません。 |
デフォルト・パッチ・プロファイルに適用されたネイティブ・ファイルは、使用環境内にあるどのドメインまたはサーバーが起動する際にも、システム・ライブラリ・パスに確実に挿入される必要があります。それらのファイルが正しく挿入されるようにするには、デフォルト・パッチ・プロファイルに適用されたパッチを参照するスクリプトに、この項で説明するコードを追加してください。
このコードをスクリプトに追加するには、次に示す適切な手順説明に従ってください。
PATCH_LIBPATH環境変数のデフォルトの定義を追加します。例:
if [ "${PATCH_LIBPATH}" = "" ]; then PATCH_LIBPATH=${BEA_HOME}/patch_wls1001/profiles/default/native
この定義を使用すると、個々のサーバーまたはドメインからカスタム・パッチ・プロファイル内のパッチを参照する必要がある場合に、そのサーバーまたはドメインでこの定義をオーバーライドできます。
PATCH_LIBPATHを、システムのシステム・ライブラリ・パスを設定する文の先頭に追加します。このスクリプトを製品でサポートされているすべてのオペレーティング・システムとハードウェア・アーキテクチャで使用可能にするために、これらの各システムのパスを設定する個々の文を指定できます。例:
if [ -n "${LIBPATH}" ]; then
LIBPATH=${LIBPATH}:${WL_HOME}/server/native/aix/ppc
else
LIBPATH=${WL_HOME}/server/native/aix/ppc
fi
LIBPATH=${PATCH_LIBPATH}:${LIBPATH}
export LIBPATH
これで、デフォルト・パッチ・プロファイル内のライブラリ・ファイル・パッチが、パスに後で出現する既存の同名のファイルを確実にオーバーライドするようになります。
PATCH_PATH環境変数のデフォルトの定義を追加します。例:
if "%PATCH_PATH%" == "" set PATCH_PATH=%BEA_HOME%\patch_wls1001\profiles\default\native
この定義を使用すると、個々のサーバーまたはドメインからカスタム・パッチ・プロファイル内のパッチを参照する必要がある場合に、そのサーバーまたはドメインでこの定義をオーバーライドできます。この定義におけるBEA_HOMEは、ミドルウェア・ホーム・ディレクトリ・パスを表します。絶対パスを指定する方法と、前に定義した環境変数を使用する方法(推奨)があります。
変数PATCH_PATHを、システム・ライブラリ・パスを設定する文の先頭に追加します。このスクリプトを製品でサポートされているすべてのオペレーティング・システムとハードウェア・アーキテクチャで使用可能にするために、これらの各システムのパスを設定する個々の文を指定できます。例:
if "%WL_USE_X86DLL%" == "true" set PATH=%PATCH_PATH%;%WL_HOME%\server\native\win\32; %WL_HOME%\server\bin;%JAVA_HOME%\jre\bin;%JAVA_HOME%\bin;%PATH%;%WL_HOME%\server\native\win\32\oci920_8
これで、デフォルト・パッチ・プロファイル内のライブラリ・ファイル・パッチが、パスに後で出現する既存の同名のファイルを確実にオーバーライドするようになります。
WebLogic Server (10.0以降のリリース)およびOSGiベースの製品(Oracle Enterprise Repositoryなど)は、ソフトウェアの開発と配布にモジュール化アプローチを採用しています。このようなモジュールを更新するパッチが提供されています。
|
注意: OSGiベースの製品は、microServices Architecture (mSA)上に構築され、Open Services Gateway initiative (OSGi)ベースのフレームワークを使用して、モジュールまたは機能セットで提供されるサービスを管理します。 |
モジュールには、共通モジュールと製品固有モジュールの2種類があります。共通モジュールは複数の製品で共有し、製品固有モジュールは1つの製品のみで使用します。共通モジュール用のパッチを適用しようとすると、Smart Updateから警告メッセージが表示されます。すべての製品にパッチを適用する場合は、「はい」をクリックできます。それ以外の場合は、「いいえ」をクリックします。ダイアログ・ボックスに表示される指示に従ってください。
WebLogic Platformの実行時インスタンスには、1つのバージョンのモジュールだけを含めることができます。そのため、特定のモジュール・バージョンが正しくパッチを適用されるようにするには、複数の製品に関連付けられているモジュールに関して、連携するすべての製品にパッチを適用する必要があります。
WebLogic Serverではモジュール・パッチはクラスパスに従って追加しますが、OSGiベースの製品ではパッチはベースのランチャを使用してロードします。
WebLogic Serverなどの製品は、クラスパスに従ってモジュールをランタイム・コンテナにロードします。クラスパスへのパッチのロードの詳細は、「クラスパス、拡張クラスパス、およびネイティブ・ライブラリ・パッチ」を参照してください。
OSGiベースの製品は、OSGiベースのランチャを通じてモジュールをランタイム・コンテナにロードします。ランチャは、必要なモジュールと実行時にモジュールがロードされる順序を決定します。また、特定の製品のモジュールにパッチが適用されているかどうかを判別します。モジュールにパッチが適用されていると、更新されたバージョンがロードされ、使用されます。モジュール・パッチの適用範囲は、製品およびパッチ・プロファイルに固有です。これにより、同じミドルウェア・ホーム・ディレクトリのすべての製品ではなく、1つの製品のみにパッチを限定するために必要とされるきめ細かな管理が可能になります。
OSGiベースの製品インストールの場合、共通モジュール用(MW_HOME\modules)および製品固有モジュール用(MW_HOME\wlevs20\modulesなど)の2つのディレクトリがあります。図5-6にこれらのディレクトリの構造を示します。
|
注意: Oracle Fusion Middleware 11gR1リリースから、BEA_HOMEにかわってMW_HOMEが新たに使用されています。 |
図5-6 WebLogic Event Serverに対するインストール・レベルのディレクトリ構造
ネイティブ・バイナリとその他のアーティファクトは、「すべてのアプリケーション、ドメインおよびサーバーに対してリソースを置き換えるパッチ」で説明しているように、すべてのアプリケーション、ドメインおよびサーバーで有効になります。
ここでは、アプリケーションで共有アーカイブ・パッチをデプロイおよび参照する方法について説明します。
共有アーカイブ・パッチは、共有ライブラリ、特にWebLogicライブラリ・モジュールをサポートするために導入されました。製品ディレクトリにインストールされる他のアーティファクトと異なり、アプリケーションは既知の場所に依存しなくても、ディレクトリ名とバージョン参照によって共有アーカイブを使用できます。これは、共有アーカイブのデフォルト・インストールが、同じ共有アーカイブのカスタム・インストールによって指定されたプロファイルに置き換えられるまで、インストール全体(またはドメイン全体)に適用されることを示しています。
Smart Updateで、デフォルト・プロファイルまたはカスタム・プロファイルへの適用後、共有アーカイブ・パッチをアクティブ化するには、パッチを適用したアーカイブを対象のドメインにデプロイしてから、必要があれば、そのアーカイブを参照するようにアプリケーションの記述を変更します。
|
注意: カスタム・プロファイルは、Smart Update 3.3.0以降、非推奨になっています。これ以降、カスタム・プロファイルを使用しないようにお薦めします。カスタム・プロファイルでは、インストール全体で使用されるWebLogic Serverパッチのインストールがより複雑になっています。 |
共有アーカイブ・パッチは、ドメイン全体(または特定のインストールで動作中のすべてのドメイン)またはドメイン内の選択したアプリケーションに適用できます。インストール内のすべてのドメインに影響を与えるには、Smart Update内のデフォルト・プロファイルに共有アーカイブ・パッチを適用します。
このトピックの詳細は、「共有アーカイブ・パッチのデフォルト・アプリケーション」を参照してください。
特定のアプリケーションにのみ影響を与えるには、カスタム・プロファイルにパッチを適用し、アプリケーション記述子のアーカイブ参照を更新する必要があります。この方法により、必要に応じて、共有ライブラリを利用するアプリケーションごとに独自のパッチ・プロファイルを維持できます。
このトピックの詳細は、「アプリケーション・スコープによるカスタム・プロファイルでの共有アーカイブ・パッチのアクティブ化」を参照してください。
共有アーカイブ・パッチを適用すると、アーカイブ全体が置き換えられる(まったく新しいアーカイブがインストールされる)か、(挿入によって)アーカイブの一部が更新されます。
どちらの操作が行われるかは、パッチの作成者が決定します。不明な場合は、My Oracle Supportにお問合せください。
Smart Updateで共有アーカイブ・パッチをデフォルト・プロファイルに適用する場合、パッチ管理システムでは、インストール全体に適用可能なパッチとして扱われます。したがって、共有アーカイブ・パッチをデフォルト・プロファイルに適用すると、そのパッチはすべてのカスタム・プロファイル(ある場合)にも適用されます。Smart Updateでは、パッチが製品インストール全体に適用されるという警告が表示されます。「続行」をクリックすると、パッチがすべてのプロファイルに適用されます。
パッチを適用した共有アーカイブが実際に書き込まれる場所は、通常は製品の共有ライブラリ・ディレクトリを基準とします。アーカイブのデプロイ方法によって、この情報が必要になる場合もあります。
共有ライブラリは、次の場所にあります。
WL_HOME/common/deployable-libraries
WL_HOME/portal/lib/modules
WL_HOME/servicebus/lib
WL_HOME/integration/common/lib/installation
通常、ポータル共有アーカイブ・パッチは、前述の共通ディレクトリおよびポータル共有ライブラリ・ディレクトリのmaintenance/defaultにインストールされます。他の製品では、別のデフォルト・パッチ・ディレクトリ構造が作成される場合もあります。特定のパッチに関する詳細なガイダンスが必要な場合は、My Oracle Supportにお問合せください。
パッチが既存のアーカイブを置き換えるタイプのもので、すでにデプロイされている場合、サーバーを再起動する必要があります。パッチに新しいバージョンがある場合、または別のディレクトリにインストールされる場合、パッチを適用したアーカイブをデプロイする必要があります。デプロイメントを実行するには、WebLogic ServerコンソールまたはカスタムWLSTスクリプトを使用するか、ターゲット・ドメインのconfig.xmlを直接更新します。
パッチを適用したアーカイブのデプロイメントが正常に完了すると、アーカイブの名前、仕様、バージョン番号などがWebLogic Server管理コンソールに表示されます。
ライブラリ・モジュール・マニフェストを変更しない場合、ライブラリ・モジュールへの参照もすべて変更されず、ドメイン内のすべてのアプリケーションは、アプリケーション記述子を手動でさらに構成しなくても、新しい機能をただちに利用できるようになります。
パッチを一定のレベルで管理して、選択したアプリケーションに適用することがあります。このような場合に共有アーカイブ・パッチを適用するには、カスタム・プロファイルを作成し、そのカスタム・プロファイルにのみ共有アーカイブ・パッチを適用します。
共有ライブラリ・パッチのバージョンを区別し、1つのドメイン内で複数のバージョンの共有ライブラリが共存できるようにするには、固有の名前または固有の実装バージョン(あるいはその両方)でバージョンを区別します。
Smart Updateのカスタム・プロファイルに共有アーカイブ・パッチを適用したあと、2つの手順を実行して、パッチを適用するアプリケーションに対してパッチをアクティブ化する必要があります。
カスタム・プロファイルでパッチをデプロイします。
パッチを適用したアーカイブの特定のバージョンを参照するように、アプリケーション記述子を更新します。
カスタム・プロファイルの共有アーカイブ・パッチをデプロイする手順は、パッチが次のディレクトリにあるという点を除いて、デフォルト・プロファイルの共有アーカイブ・パッチをデプロイする手順と同じです。
MW_HOME/patch_weblogicversion/profile/custom-profile-name/archives
例: MW_HOME/patch_wls1001/profile/customProfile
アプリケーション適用範囲のパッチの様々な例をサポートするために、パッチのインストール時に固有の名前またはバージョン(あるいはその両方)を強制するように作成されている場合、共有アーカイブ・パッチを構成できます。Smart Updateでは、パッチがカスタム・プロファイルに適用された場合にこれを検出し、そのときにアーカイブ・マニフェストでアーカイブの拡張子名または実装バージョン(あるいはその両方)を変更します。
一意の名前を強制するようにパッチが作成されている場合、パッチ・インストール・プロセスにより、マニフェスト拡張子名に文字列-patch_custom-profile-nameが追加されます。
一意の実装バージョンを強制するようにパッチが作成されている場合、パッチ・インストール・プロセスにより、バージョンの末尾の数字がデクリメントされ、数字Nが追加されます。Nは、patch-registry.xmlで定義されているパッチ・プロファイルIDです。たとえば、9.2.0.1の実装バージョンは9.2.0.0.1になります。
通常、アプリケーション記述子(WARの場合はweblogic.xml、EARの場合はweblogic-application.xml)には特定のバージョンは不要です。かわりに、最新(最大値)バージョンが検索されます。特定のバージョンの共有ライブラリを参照するためには、ブールの<exact-match>をtrueに設定する必要があります。
たとえば、9.2.0.0.1共有アーカイブ・パッチに対するweblogic-application.xmlの次に示すセクションでは、<exact-match>がtrueに設定されています。
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <library-ref> <library-name>wlp-tools-admin-app-lib</library-name> <specification-version> 9.2.0 </specification-version> implementation-version> 9.2.0.0.1 </implementation-version> <exact-match> true </exact-match> </library-ref> </weblogic-application>
