![]() ![]() ![]() ![]() |
クラスパス (WebLogic システム クラスパスや、WebLogic Server 上にデプロイされたアプリケーションのクラスパスなど) 内にロードされるクラスを含んだパッチをダウンロードして適用した後は、それらのクラスを適切なクラスパスに対して正しく挿入したことを必ず確認してください。挿入方法が不適切な場合はパッチが有効になりません。同様に、ライブラリ パス内に挿入されるライブラリ ファイルを含んだパッチについては、それらを使用するサーバ インスタンスやアプリケーションにおいて、ライブラリ ファイルを示すパスが正しく処理されることを必ず確認してください。
製品インストールに対するパッチ適用の際に Smart Update で使用される方法は一律ではなく、パッチの種類および内容に応じて異なります。パッチには、場合によって次の内容が収められています。
パッチが BEA ホーム ディレクトリに対して適用される方法と、マシン上でパッチが Smart Update により管理される方法については、以下の節を参照してください。起動スクリプトに変更を加えることが必要かどうかを判断し、必要な場合にその変更方法を認識するためには、これらを理解しておく必要があります。
この節では、ドメインに適用するパッチが有効になることを確認する場合に実行する必要のある、2 つの基本的な作業についても説明します。
起動スクリプトによってロードされるクラスまたはライブラリ ファイルを含んだパッチの場合、それらのクラスやファイルは Smart Update によって、マシン上にあるインストール レベルのパッチ ディレクトリに一元的に格納されます。これにより、クラスやライブラリ ファイルは、それらを使用する WebLogic Server インスタンスの起動時にロードできる状態になります。
このカテゴリに属するパッチに含まれる内容の例を次に示します。
注意 : |
製品インストールに含まれる既存のリソースを置き換えるパッチは、適用と同時に、そのインストール全体に対して自動的に有効になります。起動スクリプトによって有効化されるのではありません。したがって、システム リソースの置き換えを含んだパッチの場合、起動スクリプトに変更を加える必要はありません。
置き換えリソースを含んだパッチの一般的な内容の例を次に示します。
注意 : | Smart Update では、置き換えられたファイルが、インストール レベルのパッチ ディレクトリの backup サブディレクトリに格納されます。その後、置き換えが含まれるパッチを削除すると、元のリソースが backup から復元されます (backup の詳細については、表 5-1 を参照)。ただし、最大限の安全性を確保するために、置き換えを含んだパッチを適用する前には、置き換え予定のシステム リソースすべてについて別途バックアップを作成することをお勧めします。 |
共有アーカイブのパッチは、これを必要とするアプリケーションにより明示的にデプロイし、参照する必要があります。共有アーカイブのパッチをすべてのアプリケーションではなく、選択されたアプリケーションに適用する場合は、固有のパッチ レベルごとにカスタム パッチ プロファイルを作成する必要があります。
BEA カスタマ サポートからパッチまたはパッチ セットをダウンロードすると、パッチ ダウンロード ディレクトリにパッチ コンテナが置かれます。パッチ コンテナには次の内容が収められています。
1 つのパッチには複数のファイルが含まれている場合があります。含まれるファイルは次のようなものです。
メタデータは、対象の製品インストールに適用されているすべてのパッチに対して各パッチを検証するために Smart Update で使用される情報です (パッチを適用すると、メタデータは、Smart Update によって管理されるそのマシン上のディレクトリにあるパッチ レジストリに置かれます。詳細については、「インストール レベルのパッチ ディレクトリの構造」を参照してください)。
パッチ プロファイルに対してパッチが適用されると、そのパッチに含まれる個々のファイルは次のように処理されます。
PATH
または LIBPATH
を介してシステム ライブラリ パスにロードされるネイティブ ライブラリ ファイルを含んだパッチの場合、次の処理が実行される。native
というサブディレクトリの有無がチェックされる。見つからない場合は、このサブディレクトリが Smart Update によって作成される。native
サブディレクトリの詳細については、表 5-1 を参照。 native
サブディレクトリにコピーされる。
製品をインストールし、Smart Update を実行すると、パッチ ディレクトリが作成されます。各製品 (たとえば、WebLogic Server、Workshop for WebLogic、WebLogic Integration および WebLogic Portal) には、BEA_HOME ディレクトリ配下に独自のパッチ ディレクトリ構造があります (patch_wls1001
、patch_wlw1020
、patch_wli1020
、patch_wlp1020
など)。
製品固有パッチ ディレクトリ構造は、製品のパッチ メンテナンスの新しい区分を提供します。またそれによって、今後の製品が、WebLogic Server の異なる、または共通のバージョン間で相互運用する際の柔軟性も向上します。
図 5-1 に、BEA_HOME\patch_<product>
ディレクトリの構造が表示されます。
表 5-1 では、各パッチ ディレクトリの内容について説明します。
patch_wlp1020、patch_wls1001、 および patch_wlw1020 ) マシンへの製品インストールに対して適用された各種パッチからのクラス JAR ファイルが含まれる。
|
||||||
|
||||||
|
||||||
同名の既存クラスに取って代わるためにクラスパスに挿入されるクラスを含んだパッチは、パッチ マニフェスト JAR によって参照されます。そのようなクラスを含んだパッチをパッチ プロファイルに適用すると、対象プロファイルのパッチ マニフェスト JAR ファイルが Smart Update によって自動的に更新され、新しいパッチ内にあるクラスを参照するようになります。
たとえば、パッチに CR99004.jar
という名前の JAR ファイルが含まれ、このファイルに WebLogic システムレベル クラスがある場合、そのパッチをデフォルト パッチ プロファイルに適用すると、Smart Update により次の処理が実行されます。
CR99004.jar
が BEA_HOME
\patch_wls1001\patch_jars
ディレクトリに追加される。
BEA_HOME
\patch_wls1001\profiles\default\sys_manifest_classpath\weblogic_patch.jar
weblogic_patch.jar
内に、CR99004.jar
内の WebLogic システム クラスを指す次の参照が追加される。
Class-Path: C:\bea\patch_wls1001\patch_jars\CR99004.jar
BEA_HOME
\patch_wls1001\registry
ディレクトリ内のパッチ レジストリ情報が更新される。
対応する WebLogic Server インスタンスの起動時にシステム ライブラリ パスにロードされるネイティブ ライブラリ ファイルを含んだパッチの場合は、適用先パッチ プロファイルの native
サブディレクトリにそれらのライブラリ ファイルが格納されます。
たとえば、サーバ起動時にシステム ライブラリ パスにロードされる libmuxer.so
というファイルがパッチに含まれているとします。このパッチをデフォルト パッチ プロファイルに適用すると、Smart Update により次の処理が実行されます。
共通のモジュール パッチか製品固有のモジュール パッチかにかかわらず、モジュール パッチが適用された場合、Smart Update によって、BEA_HOME
\patch_<product>\profiles\
profileName\modules
ディレクトリにパッチが追加されます。元のモジュール JAR ファイルが修正されません。適用したパッチを限定するにはこのアプローチが実装されます。
たとえば、WebLogic Event Server 用モジュール パッチが BEA_HOME\wlevs20\modules\com.bea.wlevs.processor.monitor_2.0.0.0.jar
に更新したクラスを含み、そのパッチがデフォルト パッチ プロファイルに適用された場合、Smart Update では次のタスクが実行されます。
WebLogic Event Server を起動する場合、BEA_HOME\wlevs20200\modules
ディレクトリに存在している元のモジュールを使用する代わりに、BEA_HOME\patch_wlevs20200\profiles\default\modules
にあるパッチを適用したモジュールを使用します。
次の条件に該当する場合は、起動スクリプトに変更を加えなくても、クラスパスおよびライブラリ パスに対するパッチがドメイン サーバの起動時に正しく取り込まれると考えられます。
それ以外の場合は、製品サーバの起動時にパッチが適切なクラスパスやライブラリ パスに挿入されるようにするために必要な作業があります。追加の作業手順が必要となるのは、パッチを適用した対象製品の使用環境に次のいずれかが該当する場合です。
この節では、スクリプトの使用、および Smart Update の起動スクリプト エディタを使用した起動スクリプトの変更方法を示し、クラスパス、拡張クラスパス、およびネイティブ ライブラリ ファイルのパッチですべてのドメインとサーバをポイントするために使用できるカスタム スクリプトについて説明します。
注意 : | Workshop for WebLogic (10.1 および以降のリリース) は、自動的にランタイム WebLogic Server パッチを有効化しません。Smart update を使用してパッチを適用したら、Workshop IDE でのランタイム WebLogic Server に対するパッチ プロファイルも指定する必要があります。詳細については、「ランタイム (サーバ) パッチの有効化」を参照してください。 |
WebLogic Server インスタンスの起動時、パッチが確実にクラスパスまたはシステム ライブラリ パスにロードされるようにするために、該当するサーバの起動スクリプトにパッチへのポインタを追加することが必要な場合があります。以下の節では、Smart Update の動作と、場合によって起動スクリプトに加える必要がある変更内容について説明します。
WebLogic Server インスタンスが起動する際には、いくつかの起動スクリプトが実行されます。そうしたスクリプトで実行される処理の 1 つに、システムで使用されるクラスパスとライブラリ パス (WebLogic システム クラスパスなど) の定義があります。デフォルトでは、すべての WebLogic Server インスタンスで、次のいずれかのスクリプト内で設定されるクラスパスおよびライブラリ パス定義が使用されます。
WL_HOME
\common\bin\commEnv.cmd
commEnv
スクリプトには、表 5-2 で説明する環境変数のデフォルトの定義が含まれています。デフォルトでは、それらの「パッチ パス変数」はすべての WebLogic Server インスタンスが起動する際に使用され、また、クラスパスとライブラリ パスに挿入されるパッチをポイントしています。
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 インスタンスを起動することが要求される場合は、次の事項を理解しておく必要があります。
使用環境内にある各種の起動スクリプトが実行される順序と、起動スクリプトが呼び出される場所について理解していれば、どのスクリプトに変更を加える必要があるかを判断でき、対象サーバ インスタンスすべてに対する必要なパッチ パス変数すべてについて、確実に正しい値が代入されるようにすることができます。
提供されているデフォルト スクリプトで行われる処理は次のとおりです。
それらのスクリプトは、各スクリプトの内容に応じて決まる特定の順序に従って実行されます。
次の点について、表 5-3 で説明します。
コンフィグレーション ウィザードを使用してドメインを作成すると、次に説明するとおり、パッチ パス変数定義用のプレースホルダを含んだスクリプトがそのドメイン用に作成されます。
setDomainEnv
スクリプトには、次に示すコード行が含まれている (デフォルトではコメントアウト)。
@REM このドメインのデフォルトのパッチ クラスパス、ライブラリ パス
およびパスをオーバーライドするには、
@REM 次のコード行のコメントを解除し、環境変数に対して有効な値を
指定してください
@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
これらの変数について commEnv
スクリプトにデフォルトで含まれている定義については、表 5-2 を参照してください。
パッチ パス変数定義の追加作業を支援するために、Smart Update には起動スクリプト エディタが用意されています (「起動スクリプト エディタの使用」の説明を参照)。
注意 : | 1 つの起動スクリプト内で参照する WebLogic システムレベル クラスのパッチ マニフェスト JAR ファイルは 1 つだけにしてください。複数のファイルを参照すると、実行時に予期できない動作が生じることがあります。 |
startWebLogic
および startManagedWebLogic
起動スクリプトには、パッチ パス変数定義用のプレースホルダはない。これらのスクリプトに変数定義を追加する場合は、どの WebLogic Server インスタンスに影響が及ぶかについて十分に注意してください。
パッチ パス変数定義を追加する起動スクリプトの個数を最小限にとどめることにより、インストールされている製品のメンテナンス レベルやバージョンを変更またはアップグレードする際、起動スクリプト関連で必要となる作業量が軽減されます。
起動スクリプトでプロファイル内のクラスのパッチまたはライブラリ ファイルのパッチを参照する場合に実行が必要な固有の作業は、これらのパッチの適用範囲が、製品インストール上で実行されているすべてのドメインおよびサーバを対象としているのか、またはそのインストールの特定のドメインまたはサーバのみを対象としているのかに応じて異なります。
カスタムの起動スクリプトを使用する場合、またはパッチの範囲を特定のドメインまたはサーバに制限する必要がある場合、起動スクリプトを次のように変更する必要があります。
適用したクラスパス パッチおよびライブラリ パス パッチが正しく使用されるように起動スクリプトを変更する方法については、「概要」を参照してください。以下についての説明があります。
「起動スクリプトに対するパッチの場所の指定について」には、コンフィグレーション ウィザードで作成されるデフォルト スクリプトに組み込まれている、クラスやライブラリのパッチを自動的にシステム クラスパスやライブラリ パスに挿入する仕組みに関する説明があります。クラスやライブラリのパッチを正しく参照するようカスタム スクリプトに変更を加える必要がある場合は、この処理を理解しておくことが重要です。変更が必要になるのは、(a) 使用環境内でデフォルト スクリプトを使用していない場合、または (b) パッチの適用対象を特定のドメインまたはサーバ起動スクリプトに限定する必要がある場合です。
起動スクリプトに加える変更内容の詳細については、次の表で該当する手順説明を参照してください。
起動スクリプト エディタは Smart Update に用意されているツールです。使用環境内で目的の起動スクリプトを見つけ、スクリプト内にパッチ パス変数の定義を作成する作業を簡単に実行できます。Smart Update は、デフォルト パッチ プロファイルとカスタム パッチ プロファイルの組み合わせで表される、パッチ レベルの異なる複数の製品を使用する環境におけるスクリプトを維持されます。
注意 : | リリース 3.1 のインタフェースは、以前のリリースのインタフェースとは異なります。ツールは同じですが、更新を適用するバージョンに応じて、以前のリリースとリリース 3.1 ではタスクが異なります。主な違いである製品のドロップダウン リストは、次の図のようになります。 |
この変更により、下部のペインに表示されるスクリプトも製品固有のものになり、対象は 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 用に起動スクリプト エディタを使用する方法を順を追って説明します。起動スクリプト エディタを使用するには、以下の手順を実行します。
注意 : | Workshop for WebLogic を選択すると、使用しているドメインでは、カスタム プロファイル内に存在する可能性のある WebLogic Server パッチは自動的にダウンロードされません。 |
詳細については、「起動スクリプトを開く方法」を参照してください。
起動スクリプト エディタには、PATCH_CLASSPATH
、WEBLOGIC_EXTENSION_DIRS
、PATCH_LIBPATH
、および PATCH_PATH
の各変数に対して推奨される定義付きのコードが用意されています。これらの定義はすべて、前に選択したパッチ プロファイル用にカスタマイズされています。それらの定義内容は必要に応じて変更することもできます。
- デフォルト パッチ プロファイル内のパッチを参照するようにスクリプトを修正する場合は、「カスタム スクリプト経由のパッチですべてのドメインとサーバをポイントする方法」の手順説明を参照してください。
- カスタム パッチ プロファイル内のパッチをポイントするようにスクリプトを変更する場合、カスタム パッチ プロファイルを作成して、そのプロファイルへのポインタをドメインまたはサーバの起動スクリプトに追加する方法については、「個々のアプリケーション、ドメイン、またはサーバへのパッチの適用」を参照してください。
myCustomProfile
に WebLogic Server と Workshop for WebLogic の両方のパッチが含まれており、そのすべてを特定のドメインでアクティブにする場合は、スニペットのようではあるが setPatchEnv.cmd
内の宣言でモデル化されている、製品固有のトークン化されたパス宣言を含めるようにドメインの起動スクリプトを最初に編集します。
WLS_PATCH_CLASSPATH=
および WLW_PATCH_CLASSPATH=
また、setPatchEnv.cmd
に含まれているような連結文を追加する必要もあります。
set PATCH_CLASSPATH=%WLS_PATCH_CLASSPATH%;%WLW_PATCH_CLASSPATH%
注意 : | パッチ パス変数の定義を起動スクリプトに追加する際、別の起動スクリプトを呼び出すステートメントより前にその定義を配置するようにしてください。たとえば、setDomainEnv スクリプトにパッチ パス変数の定義を追加する場合は、commEnv スクリプトを呼び出すステートメントの前に追加します。この位置関係を守れば、追加した定義がその後呼び出される別の起動スクリプト内の定義によって上書きされることはありません。 |
起動スクリプトの変更方法は、Smart Update によって強制または制限されることはありません。ただし、コンフィグレーション ウィザードなどの標準ツールによってデフォルトで作成される起動スクリプトの内容と、ツールによって決定されるデフォルトの格納場所にはそのまま従うことをお勧めします。そうすることで、パッチ プロファイル内のパッチを参照するよう修正が必要な適切な起動スクリプトを見つけるための機能が期待どおりに動作し、Smart Update をより便利に利用できます。
[スクリプト エディタの起動] ダイアログ ボックスはウィザードではないため、次のような処理はできません。
サーバおよびドメインの起動メカニズムがカスタマイズされている場合、起動スクリプト エディタ内だけではすべての変更作業を完結できないことがあり、追加の作業手順が必要となる可能性があります。
[スクリプト エディタの起動] ダイアログ ボックスで [開く] をクリックして起動スクリプトを開くと、Smart Update の [起動スクリプトを開く] ダイアログ ボックスが表示されます。このダイアログ ボックスは、ドメイン、管理対象サーバ、クラスタ、または個別のサーバについて、パッチ プロファイル内のパッチへのポインタを追加する対象の起動スクリプトを見つけるために使用します。
[スクリプト エディタの起動] ダイアログ ボックスでは、表 5-5 に示すアイコンを使用すると、変更対象の起動スクリプトを含むディレクトリに移動できます。
コンフィグレーション ウィザードによってドメイン用に作成されたディレクトリ構造を使用している場合は、Smart Update により、修正が必要な起動スクリプトのあるディレクトリへと誘導されます。
修正対象となる特定の起動スクリプトを見つける場合の詳細については、以下のトピックを参照してください。
ドメインの起動スクリプトに変更を加えるには、対象ドメインの bin
サブディレクトリにある setDomainEnv
または startWebLogic
スクリプトを選択します。図 5-4 は、Windows システムで setDomainEnv
スクリプトを選択する方法を示しています。
setDomainEnv
スクリプトには、PATCH_CLASSPATH
、PATCH_LIBPATH
、および PATCH_PATH
の各変数定義のプレースホルダが含まれています。このスクリプトの変更については、「表 5-6」を参照してください。
ドメイン内にある管理対象サーバすべて (デフォルトではクラスタ内のサーバ全てを含む) に対する起動スクリプトに変更を加えるには、対象ドメインの bin
サブディレクトリにある startManagedWebLogic
スクリプトを選択します。図 5-5 は、Windows システムの場合についてその方法を示しています。
このスクリプトの変更方法については、以下の表を参照してください。
ドメイン内の特定のサーバに対する起動スクリプトに変更を加えるには、対象ドメインの bin
サブディレクトリにある、対象サーバ用に固有の名前を付けた起動スクリプトを選択します。図 5-6 は、Windows システムで startWebLogicServer1
スクリプトを選択する方法を示しています。
このスクリプトの変更方法については、以下の表を参照してください。
クラスおよびライブラリのパッチは、実際のドメインで使用されるクラスパスおよびライブラリ パスに確実に正しくロードされるようにすることが重要です。WebLogic ドメイン内でサーバ起動や環境設定に使用している起動スクリプトから、「すべてのドメインおよびサーバで使用されるクラスパスとライブラリ パスを定義したデフォルト スクリプト」に示すとおり commEnv
スクリプトの呼び出しが行われない場合は、次のようにスクリプトを修正する必要があります。
デフォルトの 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
は、BEA ホーム ディレクトリ パスを表します。絶対パスを指定するか、前に定義した 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 変数は、パッチ JAR ファイル内のクラスを WebLogic Server にデプロイされているアプリケーションのクラスパスにロードする必要がある製品で使用するために予約されています。デプロイされたアプリケーションに対するパッチ用のこのメカニズムは、現在、WebLogic Server 9.1 では使用されていません。 |
デフォルト パッチ プロファイルに適用されたネイティブ ファイルは、使用環境内にあるどのドメインまたはサーバが起動する際にも、システム ライブラリ パスに確実に挿入される必要があります。それらのファイルが正しく挿入されるようにするには、デフォルト パッチ プロファイルに適用されたパッチを参照するスクリプトに、この節で説明するコードを追加してください。
このコードをスクリプトに追加するには、次に示す適切な手順説明に従ってください。
PATCH_LIBPATH
環境変数のデフォルトの定義を追加します。以下に例を示します。
if [ "${PATCH_LIBPATH}" = "" ]; then
PATCH_LIBPATH=${BEA_HOME}/patch_wls1001/profiles/default/native
fi
この定義では、個々のサーバまたはドメインがカスタム パッチ プロファイル内のパッチをポイントする必要がある場合に、そのサーバまたはドメインでこの定義をオーバーライドできます。この定義で BEA_HOME
は、BEA ホーム ディレクトリ パスを表します。絶対パスを指定するか、前に定義した $BEA_HOME
などの環境変数を使用 (推奨) することもできます。
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
は、BEA ホーム ディレクトリ パスを表します。絶対パスを指定するか、前に定義した %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 および以降のリリース) および BEA の OSGi ベースの製品 (WebLogic Event Server 2.0 および AquaLogic Enterprise Repository 3.0 など) は、ソフトウェアの開発と配布にモジュール化アプローチを採用しています。このようなモジュールを更新するパッチが提供されています。
注意 : | BEA の OSGi ベースの製品は、BEA microServices Architecture (mSA) 上に構築され、Open Services Gateway initiative (OSGi) ベースのフレームワークを使用して、モジュールまたは機能セットで提供されたサービスを管理します。 |
共通と製品固有の 2 つのモジュール タイプがあります。共通モジュールは複数の製品で共有し、製品固有モジュールは製品のみで使用します。共通モジュール用にパッチを適用しようとすると、Smart Update から警告メッセージが表示されます。すべての製品にパッチを適用する場合は、[はい] をクリックできます。それ以外の場合は、[いいえ] をクリックします。ダイアログ ボックスに表示される指示に従ってください。
WebLogic Platform の実行時インスタンスには、1 つのバージョンのモジュールだけを含めることができます。そのため、特定のモジュール バージョンが正しくパッチを適用されるようにするには、複数の製品に関連付けられているモジュールに関して、連携するすべての製品にパッチを適用する必要があります。
WebLogic Server ではモジュール パッチはクラスパスに従って追加しますが、OSGi ベースの製品ではパッチはベースのランチャーを使用してロードします。
クラスパスに従ってランタイム コンテナへ WebLogic Server ロード モジュールなどの製品クラスパスへパッチのロードの詳細については、「クラスパス、拡張クラスパス、およびネイティブ ライブラリ パッチ」を参照してください。
BEA の OSGi ベースの製品は、OSGi ベースのランチャーを通じてモジュールをランタイム コンテナにロードします。ランチャーは、必要なモジュールと実行時にロードされるモジュールの順序を決定します。また、特定の製品に対してモジュールにパッチが適用されているかどうかを決定します。モジュールにパッチが適用されていると、更新されたバージョンがロードされ、使用されます。モジュール パッチのスコープは、製品およびパッチ プロファイルに固有です。これにより、同じ BEA_HOME
ディレクトリのすべての製品に対してではなく 1 つの製品だけに固有なパッチであることが確実になります。
OSGi ベースの製品インストールでは、共通のモジュール (BEA_HOME\
modules
) および製品固有モジュール (たとえば、BEA_HOME\wlevs20\
modules
) の 2 つのディレクトリが表示されます。図 5-7 にこれらのディレクトリの構造を示します。
ネイティブ バイナリとその他のアーティファクトは、「すべてのアプリケーション、ドメインおよびサーバに対してリソースを置き換えるパッチ」で説明しているように、すべてのアプリケーション、ドメイン、およびサーバで有効になります。
この節では、アプリケーションで共有アーカイブ パッチをデプロイおよび参照する方法について説明します。
共有アーカイブ パッチは、共有ライブラリ、特に WebLogic ライブラリ モジュールをサポートするために導入されました。製品ディレクトリにインストールされる他のアーティファクトと異なり、アプリケーションは既知の場所に依存しなくても、ディレクトリ名とバージョン参照によって共有アーカイブを使用できます。これは、共有アーカイブのデフォルト インストールが、同じ共有アーカイブのカスタム インストールによって指定されたプロファイルに置き換えられるまで、インストール全体 (またはドメイン全体) に適用されることを示しています。
Smart Update でデフォルト プロファイルまたはカスタム プロファイルに適用された後、共有アーカイブ パッチをアクティブ化するには、ユーザは影響を受けるドメインでパッチを適用するアーカイブをデプロイしてから、アーカイブを特定して参照するようにアプリケーションの記述を変更します。
共有アーカイブ パッチは、ドメイン全体 (または特定のインストールで動作中のすべてのドメイン) またはドメイン内の選択したアプリケーションに適用できます。インストール内のすべてのドメインに影響を与えるには、Smart Update 内のデフォルト プロファイルに共有アーカイブ パッチを適用します。
このトピックの詳細については、「共有アーカイブ パッチのデフォルト アプリケーション」を参照してください。
特定のアプリケーションにのみ影響を与えるには、カスタム プロファイルにパッチを適用し、アプリケーション記述子のアーカイブ参照を更新する必要があります。この方法により、必要に応じて、共有ライブラリを利用するアプリケーションごとに独自のパッチ プロファイルを維持できます。
このトピックの詳細については、「アプリケーション スコープによるカスタム プロファイルでの共有アーカイブ パッチのアクティブ化」を参照してください。
共有アーカイブ パッチを適用する場合、アーカイブ全体を置き換える (まったく新しいアーカイブをインストールする) か、(挿入によって) アーカイブの一部を更新します。
使用される操作は、パッチの作成者によって決まります。不明な場合は、BEA サポートにお問い合わせください。
パッチを削除する場合、ツールを使用してパッチを削除するだけでなく、パッチを明示的にアンデプロイする必要があります。
共有ライブラリのデプロイとアンデプロイの詳細については、『Oracle WebLogic Server アプリケーションのデプロイメント』を参照してください。共有ライブラリの詳細については、『WebLogic Server アプリケーションの開発』を参照してください。
Smart Update で共有アーカイブ パッチをデフォルト プロファイルに適用する場合、パッチ管理システムでは、インストール全体に適用可能なパッチとして扱われます。したがって、共有アーカイブ パッチをデフォルト プロファイルに適用すると、そのパッチはすべてのカスタム プロファイル (ある場合) にも適用されます。Smart Update では、パッチが製品インストール全体に適用されるという警告が表示されます。[続行] をクリックすると、パッチがすべてのプロファイルに適用されます。
パッチを適用した共有アーカイブが実際に書き込まれる場所は、通常は製品の共有ライブラリ ディレクトリを基準とします。アーカイブのデプロイ方法によって、この情報が必要になる場合もあります。
通常、ポータル共有アーカイブ パッチは、上記の共通ディレクトリおよびポータル共有ライブラリ ディレクトリの maintenance/default にインストールされます。他の WebLogic および AquaLogic 製品では、別のデフォルト パッチ ディレクトリ構造が作成される場合もあります。特定のパッチに関する詳細なガイダンスが必要な場合は、BEA サポートにお問い合わせください。
パッチが既存のアーカイブを置き換えて、すでにデプロイされている場合、サーバを再起動する必要があります。パッチに新しいバージョンがある場合、または別のディレクトリにインストールされる場合、パッチを適用したアーカイブをデプロイする必要があります。デプロイメントを実行するには、WebLogic Server コンソールまたはカスタム WLST スクリプトを使用するか、対象ドメインの config.xml を直接更新します。
パッチを適用したアーカイブのデプロイメントが正常に完了すると、アーカイブの名前、仕様、バージョン番号などが WebLogic Server Administration Console に表示されます。
ライブラリ モジュール マニフェストを変更しない場合、ライブラリ モジュールへの参照もすべて変更されず、ドメイン内のすべてのアプリケーションは、アプリケーション記述子を手動でさらにコンフィグレーションしなくても、新しい機能をただちに利用できるようになります。
パッチを一定のレベルで管理して、選択したアプリケーションに適用することがあります。このような場合に共有アーカイブ パッチを適用するには、カスタム プロファイルを作成し、そのカスタム プロファイルにのみ共有アーカイブ パッチを適用します。
共有ライブラリ パッチのバージョンを区別し、1 つのドメイン内で複数のバージョンの共有ライブラリが共存できるようにするには、固有の名前または固有の実装バージョン (あるいはその両方) でバージョンを区別します。
Smart Update のカスタム プロファイルに共有アーカイブ パッチを適用したあと、2 つの手順を実行して、パッチを適用するアプリケーションに対してパッチをアクティブ化する必要があります。
カスタム プロファイルで共有アーカイブ パッチをデプロイする手順は、パッチが次の場所にあるという点を除いて、デフォルト プロファイルで共有アーカイブ パッチをデプロイする手順と同じです。
BEA_HOME/patch_weblogic[version]/profile/custom-profile-name/archives
BEA_HOME/patch_wls1001/profile/customProfile1
アプリケーション適用範囲のパッチのさまざまな例をサポートするために、パッチのインストール時に固有の名前またはバージョン (あるいはその両方) を強制するように作成されている場合、共有アーカイブ パッチをコンフィグレーションできます。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-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>
![]() ![]() ![]() |