WebLogic Server 8.1 へのアップグレード
|
 |
 |
|
WebLogic Server 6.x からバージョン 8.1 へのアップグレードは、最も簡単な状況では、WebLogic Server 起動コマンド スクリプトと環境設定を変更するだけで完了します。
WebLogic Server 6.x ドメイン ディレクトリを、新しいディレクトリにコピーすることをお勧めします。その場合、外部ファイルへの相対パスが、コピー前同様に正しいことを確認してください。
アップグレード対象のサブシステムに固有の変更が必要になることもあります。
以下の節では、システムを WebLogic Server 6.x から WebLogic Server 8.1 にアップグレードするために必要な情報を示します。
WebLogic Server 6.1 の Pet Store アプリケーションを WebLogic Server 8.1 にアップグレードする手順については、「Pet Store アプリケーションの WebLogic Server 6.1 (サービス パック 4) から WebLogic Server 8.1 へのアップグレード」を参照してください。
WebLogic Platform 8.1 へアップグレードする方法については、『WebLogic Server FAQ 集』の「FAQ : アップグレード」を参照してください。
ドメイン ディレクトリの配置場所を、WebLogic Server インストール ディレクトリの外に指定することをお勧めします。
WebLogic Server 6.x では、WebLogic Server のディレクトリ構造内にドメイン ディレクトリが作成されていました。その後のバージョンでは、WebLogic Server インストールと JDK にアクセスできる任意の場所にドメイン ディレクトリを配置できるようになりました。
ドメイン ディレクトリの場所を変更する場合は、新しいディレクトリ構造に関係するカスタム ツールやスクリプトも忘れずに更新してください。また同様に、スクリプトによってドメインを作成するツールを使用している場合は、そのスクリプトも変更してください。ドメインの作成には、スクリプト化が可能なコンフィグレーション ウィザードを使用することをお勧めします。
WebLogic Server 6 から 8.1 にアップグレードすると、WebLogic Server ドメインがアップグレードされます。WebLogic Server ドメインについては、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメインの概要」を参照してください。
ドメインのコンフィグレーションは、管理サーバのドメイン ディレクトリの config.xml ファイルに格納されます。config.xml では、ドメインの名前と、ドメイン内の各サーバ インスタンス、クラスタ、リソース、およびサービスのコンフィグレーション パラメータ設定が格納されます。
ドメイン ディレクトリには、ドメイン内の管理サーバと管理対象サーバを起動するためのサーバ起動スクリプト ファイルも格納されます。
ドメイン ディレクトリ構造には、mydomain や petstore など、ドメインと同じ名前を持つルート ディレクトリを作成する必要があります。ルート ディレクトリには以下を格納します。
config.xml) WebLogic Server ドメインの詳細については、『WebLogic Server のコンフィグレーションと管理』の「WebLogic Server ドメイン」を参照してください。
複数のサーバ インスタンスを含むドメインも、単一サーバ ドメインと同じ方法でアップグレードします。nutshell を使用してアップグレードする場合は、WebLogic Server 6.x がインストールされているマシンに 8.1 をインストールし、6.x ドメインの内容を 8.1 ドメイン ディレクトリにコピーしてから、スクリプトや環境設定が新しい 8.1 のドメインおよびサーバ インスタンスを指すように変更します。
ドメインにクラスタが含まれており、WebLogic Server 8.1 の新しいクラスタ化機能を使用する場合は、『WebLogic Server クラスタ ユーザーズ ガイド』の「WebLogic クラスタの設定」に示した WebLogic Server 8.1 クラスタ コンフィグレーションのガイドラインを参照してください。
この節のアップグレード手順を実行する前に、アップグレードの対象となるドメインに 6.x サーバ インスタンスが含まれているすべてのマシンに WebLogic Server 8.1 をインストールする必要があります。WebLogic Server 8.1 のインストール手順については、『WebLogic Platform のインストール』を参照してください。
アップグレードする WebLogic Server 6.x のドメインで、サーバ インスタンスをすべて停止します。
サーバを停止することで、ドメインまたはそのアプリケーションへの最新の内容が確実に保持されます。「サーバの起動と停止 : クイック リファレンス」を参照してください。
8.1 ドメインを配置するための新しいディレクトリを作成します。
この新しい 8.1 ドメイン ディレクトリからみた外部リソースの相対的な位置が、6.x ドメイン ディレクトリのときと異なる場合は、6.x ドメイン ディレクトリの内容を 8.1 ドメイン ディレクトリに移動した後で、ドメイン内から外部リソースへの参照を変更する必要がありますので注意してください。
WebLogic Server 6.x ドメイン ディレクトリの内容を新しい 8.1 ドメイン ディレクトリにコピーします。コピーする内容としては、サーバ起動スクリプト、コンフィグレーション設定などがあります。詳細については、「ドメイン ディレクトリの内容」を参照してください。
ドメインを WebLogic Server 8.1 にアップグレードした後は、WebLogic Server 6.x に戻せないことがありますので注意してください。
注意 :まだこの時点では、8.1 のドメインとなるこの新しいドメインに入っているアプリケーション パスは、6.x ドメインにデプロイされていたアプリケーションを指しています。ドメイン変換が完了するまでは、どちらのドメインのサーバ インスタンスも起動しないようにしてください。複数バージョンの WebLogic Server の下で、同じアプリケーションをデプロイするサーバ インスタンスを同時に実行すると、問題の発生する危険性が高まります。
新しい 8.1 ドメイン ディレクトリ内で、拡張子が .log のファイルと、\.wlnotdelete フォルダを削除します。これらのアーティファクトには 6.x 固有の設定が含まれることがあるため、8.1 ドメインで問題が発生する原因になります。
WebLogic Server 6.x サーバ インスタンスではなく 8.1 サーバ インスタンスを指すように、新しい 8.1 ドメイン ディレクトリのサーバ起動スクリプトを変更します。この変更は、アップグレードしたドメイン内のすべての管理サーバおよび管理対象サーバに対して実施します。新しい WebLogic Server ドメインに作成されるデフォルトの起動スクリプトの名前は、管理サーバの場合は startWebLogic.cmd (または .sh)、管理対象サーバの場合は startManagedWebLogic.cmd (または .sh) になります。
6.x および 8.1 ドメインのサーバ起動スクリプトは、WL_HOME\server\bin ディレクトリにあるサーバ起動スクリプトを参照します (WL_HOME は WebLogic Server のインストール ディレクトリ)。
サーバ起動スクリプトで WebLogic Server 6.x の WL_HOME\server\bin ディレクトリ内の startWLS.cmd スクリプトを呼び出している場合は、WebLogic Server 8.1 の WL_HOME\server\bin ディレクトリ内の startWLS.cmd スクリプトが呼び出されるように変更します。
サーバ起動スクリプトによっては、そのプロパティのいくつかについて設定内容を変更する必要があります。「起動スクリプトの修正」を参照してください。
アプリケーションを WebLogic Server 8.1 にアップグレードするには、外部リソースの参照を確認し、ユーティリティを (必要に応じて JVM も) 更新してから、EJB やセキュリティなどの要素をアップグレードします。
これにより、アプリケーションから外部ファイルを参照している場合に、外部ファイルの正しいアドレスを参照していることを確認できます。 この作業では、アプリケーションのデプロイメント記述子ファイルとドメイン コンフィグレーション ファイル config.xml の編集が必要になる場合もあります。
WebLogic Server のコンフィグレーションは、ファイル システム (ログ ファイル、ファイルベースのリポジトリ、Java コンパイラなど) の上に格納できる多数のファイルを使用して行われます。これらすべての外部ファイルが相対パスでは参照されておらず、ドメイン ディレクトリまたはそのサブディレクトリ以外に格納されている場合は、次のいずれかを行ってください。
WebLogic Server 8.1 の管理サーバと管理対象サーバを起動して、アプリケーションのコンフィグレーションとデプロイを行います。
注意 :WebLogic Server 8.1 では、バージョン 6.x の config.xml ファイルのコンフィグレーション情報が、WebLogic Server 8.1 の情報を取り込んで自動的に更新されます。サーバを複数回、起動する間にもこうした変更を保持するためには、config.xml ファイルを書き込み可能に設定する必要があります。config.xml を読み込み専用にした場合は、書き込みを可能にするため、そのファイル プロパティにアクセスして属性を変更します。たとえば Windows の場合は、Windows エクスプローラでファイルを右クリックして [プロパティ] を選択し、[読み取り専用] 属性のチェックをはずします。
WebLogic Server 8.1 を起動する方法の詳細については、「サーバの起動と停止 : クイック リファレンス」を参照してください。
アプリケーションのコンフィグレーションとデプロイについては、『デプロイメント』を参照してください。
以前のバージョンで WebLogic Server 起動スクリプトを使用していた場合は、WebLogic Server 8.1 で利用できるようにスクリプトを変更する必要があります。
6.1 起動スクリプトを 8.1 に修正する具体例については、「Pet Store アプリケーションの WebLogic Server 6.1 (サービス パック 4) から WebLogic Server 8.1 へのアップグレード」を参照してください。
一般に、ここでの説明に従って、起動スクリプトを修正します。次の手順の基礎となる startWebLogic.cmd (または .sh) スクリプトと、ご使用のドメインの起動スクリプトが、大幅に異なる場合もあります。これらの手順は、管理サーバ起動スクリプトと管理対象サーバ起動スクリプトの両方に適用できます。7.0 サーバを参照するすべてのサーバ起動スクリプトを、8.1 サーバを参照するように変更する必要があります。
ここでは、前節の「WebLogic Server 6.x ドメインのバージョン 8.1 へのアップグレード 」で説明した手順のうち最初の 2 つが実行済みであることを前提にしています。すなわち、次の手順を実行する前に以下の作業を完了してください。
@rem Check that script is being run from the appropriate directory
if not exist lib\weblogic.jar goto wrongplace
echo startWebLogic.cmd must be run from the config\mydomain directory. 1>&2
if exist "%JAVA_HOME%/bin/javac.exe" goto runWebLogic
echo Javac wasn't found in directory %JAVA_HOME%/bin.
echo Please edit the startWebLogic.cmd script so that the JAVA_HOME
echo variable points to the root directory of your JDK installation.
WebLogic Server 8.1 は、サーバのインストール時に JDK 1.4.1 の JVM をインストールします。サーバに付属する setenv.cmd および .sh スクリプトはすべてこの JVM を指しています。動作確認された JVM についての最新情報は、『証明書ページ』で公開されています。
この節では、Sun の Pet Store アプリケーションを WebLogic Server 6.1 から 8.1 にアップグレードする手順を、順を追って説明します。ここで使用するバージョンの Pet Store は、WebLogic Server 6.x (サービス パック 4) に含まれています。
以下の手順では、WebLogic Server 6.1 と WebLogic Server 8.1 の両方がインストールされていることを前提にしています。
実際のアップグレード手順を開始する前に、Pet Store アプリケーションの一部の問題点を修正する必要があります。WebLogic Server 8.1 では JSP と XML の解析がこれまでよりも厳密になっているため、WebLogic Server 6.x では受け入れられた JSP と XML のマイナーなエラーの修正が必要になります。
この節では、Pet Store を WebLogic Server 8.1 にデプロイするために必要な修正項目について説明します。
WebLogic Server 6.1SP6 以降のバージョンの Pet Store では、これらの修正は必要ありません。
アップグレードに備えて Pet Store を修正する手順を説明した後で、「Pet Store ドメインのアップグレード 」で Pet Store ドメインをアップグレードする手順について説明します。
この作業は、WebLogic Server 6.1 サービス パック 4 以降のサービス パックからアップグレードする場合は必要ありません。
6.0 以降のバージョンの WebLogic Server では、WebLogic 固有のデプロイメント記述子で定義されたリソース参照と Sun のデプロイメント記述子のリソース参照が一致する必要があります。
次の手順に従い、Pet Store のデプロイメント記述子ファイル customer_weblogic_ejb.xml と customer_ejb.xml の不一致を修正します。
<ejb-name>TheCustomer</ejb-name>
<ejb-ref-name>ejb/account/Account</ejb-ref-name>
<jndi-name>estore/account</jndi-name>
<ejb-ref-name>ejb/order/Order</ejb-ref-name>
<jndi-name>estore/order</jndi-name>
WL_HOME\samples\petStore\src\petstore\src\docroot\WEB-INF に移動します。ここで、WL_HOME は WebLogic Server 6.1 のインストール ディレクトリです。次に例を示します。weblogic.xml には、Web アプリケーションで使用する resource-description 要素と ejb-reference-description 要素が複数定義されています。次の ejb-reference-description をファイルに追加します。 <ejb-reference-description>
<ejb-ref-name>ejb/profilemgr/ProfileMgr</ejb-ref-name>
<jndi-name>estore/profilemgr</jndi-name>
</ejb-reference-description>
WebLogic Server 8.1 では XML の解析がより厳密なため、以前のバージョンの WebLogic Server では受け入れられた以下のエンコーディング エラーが許可されなくなります。
セキュリティ エラーの原因となるおそれがあるため、ワイルドカード設定を Pet Store のプロパティ ファイルから削除します。
以前のバージョンの WebLogic Server では解析されたマイナーなエラーが JDK 1.4 では受け入れられないため、WebLogic Server 8.1 ではエラーになります。この節では、メソッドとセッターでのプロパティ設定の不一致が原因となるエラーを修正します。
このエラーを修正するには、次のソース ファイルの変更が必要になります。
ListTag.java
CartListTag.java
MyListTag.java
ProductItemListTag.java
ProductListTag.java
SearchListTag.java
これらのファイルはすべて、WL_HOME\samples\petStore\src\petstore\src\com\sun\j2ee\blueprints\petstore\taglib\list ディレクトリにあります。ここで、WL_HOME は WebLogic Server のインストール ディレクトリです。
WL_HOME\samples\petStore\src\petstore\src\com\sun\j2ee\blueprints\petstore\taglib\list に移動します。次に例を示します。 WL_HOME\samples\petStore\src\petstore\src\com\sun\j2ee\blueprints\petstore\taglib\list>notepad ListTag.java.
public void setNumItems(String numItemsStr) {
public void setStartIndex(String startIndexStr) {
startIndex = Integer.parseInt(startIndexStr);
}
WL_HOME\samples\petStore\src\petstore\src\com\sun\j2ee\blueprints\petstore\taglib\list に移動します。次に例を示します。 WL_HOME\samples\petStore\src\petstore\src\com\sun\j2ee\blueprints\petstore\taglib\list>notepad CartListTag.java.
public void setNumItems(String numItemsStr) {
super.setNumItems(numItemsStr);
}
public void setStartIndex(String startIndexStr) {
super.setNumItems(startIndexStr);
}
public void setNumItems(int numItems) {
super.setNumItems(numItems);
}
public void setStartIndex(int startIndex) {
super.setNumItems(startIndex);
}
MyListTag.java
ProductItemListTag.java
ProductListTag.java
SearchListTag.java
Pet Store の修正が完了したら、アプリケーションを再ビルドします。
このアップグレード手順では、WebLogic Server 6.1 で使用していた Cloudscape データベースを、引き続き WebLogic Server 8.1 コンフィグレーションでも指し示すようにします。
C:\petstorefrom61to81 を作成します。 RootDirectory 設定についても、WebLogic Server 6.x の WL_HOME パスを c:\petstorefrom61to81 パスで置き換えます。つまり、次の行を置き換えます。 if not exist lib\weblogic.jar goto wrongplace
if not exist WL_HOME\server\lib\weblogic.jar goto wrongplace
set CLASSPATH=.;C:\bea\81feb26\weblogic81\server\lib\weblogic.jar;.WL_HOME61\samples\eval\cloudscape\lib\cloudscape.jar;.\config\petStore\serverclasses
set CLASSPATH=.;WL_HOME81\server\lib\weblogic.jar;.C:\petstorefrom61to81\samples\eval\cloudscape\lib\cloudscape.jar;C:\petstorefrom61to81\config\petstore\serverclasses
-Dbea.home 設定を、6.x の BEA_HOME から 8.1 の BEA_HOME に変更します。BEA_HOME は、WebLogic Server のインストール ディレクトリを含むディレクトリです。次に例を示します。
WebLogic Server 8.1 では、新しいセキュリティ アーキテクチャが採用されています。変更点の詳細については、『WebLogic Security の紹介』の「WebLogic Security の変更点」を参照してください。
WebLogic Server 8.1 では、6.x など以前のバージョンの WebLogic Server からアップグレードしたのか、バージョン 8.1 が初めて使用する WebLogic Server なのかが自動的に検知されます。WebLogic Server 6.x からアップグレードする場合は、WebLogic Server 8.1 を互換性セキュリティで実行することで、ユーザおよびグループの 6.x コンフィグレーションをそのまま使用できます。
ただし、6.x の主要なセキュリティ機能の一部が非推奨になり、WebLogic Server 8.1 では改善および拡張されたセキュリティ機能が提供されているため、ユーザやグループのセキュリティ コンフィグレーションをアップグレードすることをお勧めします。この節では、以下のアップグレードとその手順について説明します。
WebLogic Server 8.1 では、セキュリティ レルムのスコープが変更されています。WebLogic Server 6.x では、セキュリティ レルムで認証および認可サービスを提供していました。6.x では、ファイル レルムか、または Lightweight Data Access Protocol (LDAP)、Windows NT、UNIX、RDBMS レルムなどの代替レルムを選択していました。また、カスタム セキュリティ レルムを記述することもできました。WebLogic Server 6.x のセキュリティ レルムの詳細については、『WebLogic Security プログラマーズ ガイド』の「セキュリティ レルム」を参照してください。
WebLogic Server 8.1 では、各セキュリティ レルムはコンフィグレーション済みのセキュリティ プロバイダ、ユーザ、グループ、セキュリティ ロール、およびセキュリティ ポリシーで構成されます。認証および認可サービスは、セキュリティ レルム内の認証プロバイダおよび認可プロバイダによって提供されます。WebLogic Server 8.1 のセキュリティ レルムの詳細については、『WebLogic Security の紹介』の「セキュリティ レルム」を参照してください。
WebLogic Server 6.x のセキュリティ レルムを WebLogic Server 8.1 にアップグレードする場合、次の 2 つの選択肢があります。
CompatibilityRealm に限定されます。WebLogic Server 8.1 の互換性セキュリティでの起動については、『WebLogic Security の管理』の「互換性セキュリティの使い方」を参照してください。 互換性セキュリティを使用するもう 1 つの利点は、セキュリティ ロール、セキュリティ ポリシーといった WebLogic Server 8.1 のセキュリティ機能を試すことができる点です。6.x セキュリティ コンフィグレーションは、後からでも WebLogic Server 8.1 の新しいセキュリティ機能に変換できます。互換性セキュリティを完全に削除する場合は、「互換性セキュリティから WebLogic Server 8.1 セキュリティへのアップグレード」を参照してください。
CompatibilityRealm 以外のセキュリティ レルム) でコンフィグレーションすると、WebLogic Server 6.x LDAP、Windows NT、UNIX、または RDBMS のセキュリティ レルムに格納されているユーザやグループへのアクセスを確保しつつ、WebLogic Server 8.1 の新しいセキュリティ メカニズムを使用できます。注意 :WebLogic Server 8.1 セキュリティ レルムでレルム アダプタ認証プロバイダを認証プロバイダとしてコンフィグレーションすると、WebLogic Server 6.x セキュリティ レルムの ACL にはアクセスできません。この場合、アプリケーション リソースは、セキュリティ ロールおよびセキュリティ ポリシーで保護する必要があります。
以下の節では、WebLogic Server 6.x のセキュリティ レルムをバージョン 8.1 にアップグレードする手順を説明します。
注意 :この節の手順を実行する前に、必ず WebLogic Server 6.x ドメインをバージョン 8.1 にアップグレードしてください。手順については、「WebLogic Server 6.x ドメインのバージョン 8.1 へのアップグレード」を参照してください。
この節では、WebLogic Server 6.x LDAP V2 セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順を説明します。このアップグレードにより、LDAP サーバに定義されているユーザおよびグループは、myrealm セキュリティ レルムから参照されるようになります。このレルムは、WebLogic Server 8.1 のデフォルト (アクティブ) セキュリティ レルムです。
注意 :セキュリティ ポリシーは、WebLogic Server 6.x で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) およびパーミッションに代わるものです。したがって、このアップグレードを行うと、ACL は 8.1 セキュリティ レルムからは参照されなくなります。WebLogic Server 8.1 におけるリソースのセキュリティの再設定については、「次の手順に従って、ACL のアップグレードを検証します。」の節および『WebLogic リソースのセキュリティ』を参照してください。
WebLogic Server 6.x LDAP V2 セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順は次のとおりです。
右ペインの最下部に、WebLogic Server 6.x LDAP V2 セキュリティ レルム用に定義されているユーザのリストが表示されます。以下では、これらのユーザを WebLogic Server 8.1 セキュリティ レルムから参照するように変更します。
右ペインに、WebLogic Server 6.x LDAP V2 セキュリティ レルム用に定義されているグループのテーブルが表示されます。以下では、これらのグループを WebLogic Server 8.1 セキュリティ レルムから参照するように変更します。
user.filter=(&(uid=%u)(objectclass=person))
user.dn=ou=people, ou=Test,dc=companysys,dc=com
server.port=1155
membership.filter=(&(uniquemember=%M)(objectclass=groupofuniquenames))
server.principal=uid=tadmin, ou=People,dc=companysys,dc=com
group.filter=(&(cn=%g)(objectclass=groupofuniquenames))
group.dn=ou=Groups,ou=Test,dc=companysys,dc=com
server.host=testmachine
注意 :同じマシン上で WebLogic Server 6.x と 8.1 を実行する場合、これらの手順を実行する前に、必ず WebLogic Server 6.x インスタンスを停止してください。
mydomain という名前の WebLogic Server 8.1 ドメインを作成します。注意 : WebLogic Server 8.1 ドメインを作成するには、コンフィグレーション ウィザードで、サーバの起動に使用するユーザ名とパスワードの組み合わせ以外のすべてのデフォルトを受け入れます。このユーザ名とパスワードの組み合わせは LDAP サーバ内に存在している必要があり、ユーザは Administrators グループののメンバーである必要があります。
コンフィグレーション ウィザードの使用の手順については、『WebLogic Server のコンフィグレーションと管理』の「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
[認証] ノードを展開すると、myrealm セキュリティ レルムにコンフィグレーション済みの認証プロバイダが表示されます。デフォルトでは、DefaultAuthenticator および DefaultIdentityAsserter という WebLogic セキュリティ プロバイダが含まれています。
たとえば、iPlanet (Netscape) LDAP サーバを使用している場合は、[新しい iPlantAuthenticator のコンフィグレーション] リンクをクリックします。
注意 :使用している LDAP サーバに対応する [新しい...のコンフィグレーション] リンクがない場合は、『WebLogic Security の管理』の「他の LDAP サーバへのアクセス」を参照してください。
[制御フラグ] では、LDAP 認証プロバイダを他の認証プロバイダと一緒に使用する方法を指定します。最初は、[OPTIONAL] のままにしておくことをお勧めします。詳細については、『WebLogic Security の管理』の「JAAS 制御フラグ属性の設定」を参照してください。
注意 :必要に応じて、これらの値を WebLogic Server 6.x LDAP V2 セキュリティ レルムで使用していた 6.x キャッシング レルムの値に変更しても構いません。
警告 :再起動アイコンが点滅しても、WebLogic Server 8.1 インスタンス myserver はまだ再起動しないでください。
[名前フィルタからのユーザ] - user.filter の値 (WebLogic Server 8.1 Administration Console のデフォルト値をそのまま使用できる場合もあります)
注意 :[メンバシップ] タブと [詳細] タブのフィールドに値を設定する必要はありません。ただし、WebLogic Server 8.1 の WebLogic LDAP 認証プロバイダでこれらのタブの機能 (動的グループなど) を使用しており、今後もそれらの機能を使用したい場合もあります。これらの機能の詳細については、『WebLogic Security の管理』の「LDAP 認証プロバイダのコンフィグレーション」を参照してください。
注意 :config.xml.booted ファイルは、変更を加える前の config.xml のコピーです。これを保存しておくことで、問題が発生した場合に元のコンフィグレーションに戻すことができます。
myserver を再起動します。この節では、WebLogic Server 6.x Windows NT セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順を説明します。このアップグレードにより、Windows NT サーバに定義されているユーザおよびグループは、myrealm セキュリティ レルムから参照されるようになります。このレルムは、WebLogic Server 8.1 のデフォルト (アクティブ) セキュリティ レルムです。
注意 :セキュリティ ポリシーは、WebLogic Server 6.x で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) およびパーミッションに代わるものです。したがって、このアップグレードを行うと、ACL は 8.1 セキュリティ レルムからは参照されなくなります。WebLogic Server 8.1 におけるリソースのセキュリティの再設定については、「次の手順に従って、ACL のアップグレードを検証します。」の節および『WebLogic リソースのセキュリティ』を参照してください。
WebLogic Server 6.x Windows NT セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順は次のとおりです。
右ペインの最下部に、WebLogic Server 6.x Windows NT セキュリティ レルム用に定義されているユーザのリストが表示されます。以下では、これらのユーザを WebLogic Server 8.1 セキュリティ レルムから参照するように変更します。
注意 :同じマシン上で WebLogic Server 6.x と 8.1 を実行する場合、これらの手順を実行する前に、必ず WebLogic Server 6.x インスタンスを停止してください。
mydomain という名前の WebLogic Server 8.1 ドメインを作成します。注意 : WebLogic Server 8.1 ドメインを作成するには、コンフィグレーション ウィザードで、サーバの起動に使用するユーザ名とパスワードの組み合わせ以外のすべてのデフォルトを受け入れます。このユーザ名とパスワードの組み合わせは、WebLogic Server 8.1 インスタンスを再起動できる適切な権限が付与されている必要があります(管理者アカウントである必要はありません)。
コンフィグレーション ウィザードの使用の手順については、『WebLogic Server のコンフィグレーションと管理』の「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
警告 : コンフィグレーション ウィザードを使用せずに WebLogic Server 8.1 ドメインを作成する場合は、まず 6.x filerealm.properties ファイルをコピーしないと、レルム アダプタ認証プロバイダを作成 (「手順 2: レルム アダプタ認証プロバイダをコンフィグレーションする」) できません。
注意 :レルム アダプタ認証プロバイダの詳細については、『WebLogic Security の管理』の「レルム アダプタ認証プロバイダのコンフィグレーション」を参照してください。
[認証] ノードを展開すると、myrealm セキュリティ レルムにコンフィグレーション済みの認証プロバイダが表示されます。デフォルトでは、DefaultAuthenticator および DefaultIdentityAsserter という WebLogic セキュリティ プロバイダが含まれています。
[制御フラグ] では、レルム アダプタ認証プロバイダを他の認証プロバイダと一緒に使用する方法を指定します。最初は、[OPTIONAL] のままにしておくことをお勧めします。詳細については、『WebLogic Security の管理』の「JAAS 制御フラグ属性の設定」を参照してください。
注意 :config.xml.booted ファイルは、変更を加える前の config.xml のコピーです。これを保存しておくことで、問題が発生した場合に元のコンフィグレーションに戻すことができます。
myserver を再起動します。互換性セキュリティで WebLogic Server 6.x Windows NT レルムをコンフィグレーションし直すと、レルム アダプタ認証プロバイダへの接続が提供され、6.x のユーザとグループを WebLogic Server 8.1 Administration Console に表示することが可能になります。
注意 :config.xml.booted ファイルは、変更を加える前の config.xml のコピーです。これを保存しておくことで、問題が発生した場合に元のコンフィグレーションに戻すことができます。
この節では、WebLogic Server 6.x Unix セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順を説明します。このアップグレードにより、Unix サーバに定義されているユーザおよびグループは、myrealm セキュリティ レルムから参照されるようになります。このレルムは、WebLogic Server 8.1 のデフォルト (アクティブ) セキュリティ レルムです。
注意 :セキュリティ ポリシーは、WebLogic Server 6.x で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) およびパーミッションに代わるものです。したがって、このアップグレードを行うと、ACL は WebLogic Server 8.1 セキュリティ レルムからは参照されなくなります。WebLogic Server 8.1 におけるリソースのセキュリティの再設定については、「次の手順に従って、ACL のアップグレードを検証します。」の節および『WebLogic リソースのセキュリティ』を参照してください。
WebLogic Server 6.x Unix セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順は次のとおりです。
右ペインの最下部に、WebLogic Server 6.x Unix セキュリティ レルム用に定義されているユーザのリストが表示されます。以下では、これらのユーザを WebLogic Server 8.1 セキュリティ レルムから参照するように変更します。
注意 :同じマシン上で WebLogic Server 6.x と 8.1 を実行する場合、これらの手順を実行する前に、必ず WebLogic Server 6.x インスタンスを停止してください。
mydomain という名前の WebLogic Server 8.1 ドメインを作成します。注意 :WebLogic Server 8.1 ドメインを作成する際、コンフィグレーション ウィザードですべてのデフォルトを受け入れます。ただし、Unix マシンにログインしている必要があります。
コンフィグレーション ウィザードの使用の手順については、『WebLogic Server のコンフィグレーションと管理』の「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
警告 : コンフィグレーション ウィザードを使用せずに WebLogic Server 8.1 ドメインを作成する場合は、まず 6.x filerealm.properties ファイルをコピーしないと、レルム アダプタ認証プロバイダを作成 (「手順 2: レルム アダプタ認証プロバイダをコンフィグレーションする」) できません。
注意 :レルム アダプタ認証プロバイダの詳細については、『WebLogic Security の管理』の「レルム アダプタ認証プロバイダのコンフィグレーション」を参照してください。
[認証] ノードを展開すると、myrealm セキュリティ レルムにコンフィグレーション済みの認証プロバイダが表示されます。デフォルトでは、DefaultAuthenticator および DefaultIdentityAsserter という WebLogic セキュリティ プロバイダが含まれています。
[制御フラグ] では、レルム アダプタ認証プロバイダを他の認証プロバイダと一緒に使用する方法を指定します。最初は、[OPTIONAL] のままにしておくことをお勧めします。詳細については、『WebLogic Security の管理』の「JAAS 制御フラグ属性の設定」を参照してください。
注意 :config.xml.booted ファイルは、変更を加える前の config.xml のコピーです。これを保存しておくことで、問題が発生した場合に元のコンフィグレーションに戻すことができます。
myserver を再起動します。互換性セキュリティで Unix レルムをコンフィグレーションし直すと、レルム アダプタ認証プロバイダへの接続が提供され、6.x のユーザとグループを WebLogic Server 8.1 Administration Console に表示することが可能になります。
注意 :config.xml.booted ファイルは、変更を加える前の config.xml のコピーです。これを保存しておくことで、問題が発生した場合に元のコンフィグレーションに戻すことができます。
注意 :この節では、WebLogic Server 6.x の RDBMS サンプルをアップグレードする方法について説明します。RDBMS サンプルでは、Cloudscape データベースを使用していました。このサンプルに変更を加えた場合や、他のデータベースを使用する場合は、その環境に合わせて以下の手順を変更してください。
この節では、WebLogic Server 6.x RDBMS セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順を説明します。このアップグレードにより、Cloudscape データベースに定義されているユーザおよびグループは、myrealm セキュリティ レルムから参照されるようになります。このレルムは、WebLogic Server 8.1 のデフォルト (アクティブ) セキュリティ レルムです。
注意 :セキュリティ ポリシーは、WebLogic Server 6.x で WebLogic リソースを保護するために使用していたアクセス制御リスト (ACL) およびパーミッションに代わるものです。したがって、このアップグレードを行うと、ACL は 8.1 セキュリティ レルムからは参照されなくなります。WebLogic Server 8.1 におけるリソースのセキュリティの再設定については、『WebLogic リソースのセキュリティ』を参照してください。
WebLogic Server 6.x RDBMS セキュリティ レルムを WebLogic Server 8.1 セキュリティ レルムにアップグレードする手順は次のとおりです。
右ペインの最下部に、WebLogic Server 6.x RDBMS セキュリティ レルム用に定義されているユーザのリストが表示されます。以下では、これらのユーザを WebLogic Server 8.1 セキュリティ レルムから参照するように変更します。
右ペインに、WebLogic Server 6.x RDBMS セキュリティ レルム用に定義されているグループのテーブルが表示されます。以下では、これらのユーザを WebLogic Server 8.1 セキュリティ レルムから参照するように変更します。
注意 :出荷時の RDBMS サンプルでは、[ドライバ] の値として COM.cloudscape.core.JDBCDriver が、[URL] の値として jdbc:cloudscape:demo;create=true;autocommit=false が使用されています。
getGroupMembers=SELECT GM_GROUP, GM_MEMBER from groupmembers WHERE GM_GROUP = ? deleteGroup2=DELETE FROM aclentries WHERE A_PRINCIPAL = ? deleteGroup1=DELETE FROM groupmembers WHERE GM_GROUP = ? addGroupMember=INSERT INTO groupmembers VALUES ( ? , ? ) getUser=SELECT U_NAME, U_PASSWORD FROM users WHERE U_NAME = ? getPermission=SELECT DISTINCT A_PERMISSION FROM aclentries WHERE A_PERMISSION = ? deleteUser3=DELETE FROM aclentries WHERE A_PRINCIPAL = ? getGroupNewStatement=true deleteUser2=DELETE FROM groupmembers WHERE GM_MEMBER = ? deleteUser1=DELETE FROM users WHERE U_NAME = ? getAcls=SELECT A_NAME, A_PRINCIPAL, A_PERMISSION FROM aclentries ORDER BY A_NAME, A_PRINCIPAL getUsers=SELECT U_NAME, U_PASSWORD FROM users getGroups=SELECT GM_GROUP, GM_MEMBER FROM groupmembers getPermissions=SELECT DISTINCT A_PERMISSION FROM aclentries getAclEntries=SELECT A_NAME, A_PRINCIPAL, A_PERMISSION FROM aclentries WHERE A_NAME = ? ORDER BY A_PRINCIPAL newUser=INSERT INTO users VALUES ( ? , ? ) removeGroupMember=DELETE FROM groupmembers WHERE GM_GROUP = ? AND GM_MEMBER = ?
WebLogic Server 6.x の WL_HOME\samples\examples\security\rdbmsrealm に格納されている RDBMS レルムのサンプルでは、RDBMSDelegate.java ファイルの RDBMSDelegate(RDBMSRealm realm) メソッド内のプライベートな Admin API (weblogic.management.Admin.getActiveDomain()) を使用していました。WebLogic Server 8.1 では、このプライベートな Admin API がパブリックな Admin API に変更されました。したがって、以下の作業を行う必要があります。
RDBMSDelegate.java ファイルを変更して、RDBMS レルム サンプル コードでプライベートな Admin API の代わりにパブリックな Admin API が使用されるようにします。 詳細については、「MBean API の変更」を参照してください。 注意 :同じマシン上で WebLogic Server 6.x と 8.1 を実行する場合、これらの手順を実行する前に、必ず WebLogic Server 6.x インスタンスを停止してください。
mydomain という名前の WebLogic Server 8.1 ドメインを作成します。コンフィグレーション ウィザードの使用の手順については、『WebLogic Server のコンフィグレーションと管理』の「コンフィグレーション ウィザードを使用したドメインの作成とコンフィグレーション」を参照してください。
注意 : レルム アダプタ認証プロバイダの詳細については、『WebLogic Security の管理』の「レルム アダプタ認証プロバイダのコンフィグレーション」を参照してください。
[認証] ノードを展開すると、myrealm セキュリティ レルムにコンフィグレーション済みの認証プロバイダが表示されます。 デフォルトでは、DefaultAuthenticator および DefaultIdentityAsserter という WebLogic セキュリティ プロバイダが含まれています。
[制御フラグ] では、レルム アダプタ認証プロバイダを他の認証プロバイダと一緒に使用する方法を指定します。最初は、[OPTIONAL] のままにしておくことをお勧めします。詳細については、『WebLogic Security の管理』の「JAAS 制御フラグ属性の設定」を参照してください。
\samples\eval\cloudscape\lib にインストールされている WebLogic Server 6.x cloudscape.jar ファイル注意 :config.xml.booted ファイルは、変更を加える前の config.xml のコピーです。これを保存しておくことで、問題が発生した場合に元のコンフィグレーションに戻すことができます。
myserver を再起動します。WebLogic Server 6.x カスタム セキュリティ レルムは、互換性セキュリティでのみ使用できます。以下では、カスタム セキュリティ レルムのアップグレードの一般的な状況とその留意点について説明します。
カスタム セキュリティ レルムで config.xml ファイルではなく weblogic.properties ファイルを使用している場合は、このファイルを変換しないと WebLogic Server 8.1 インスタンスを互換性セキュリティで起動できません。この変換の手順および詳細については、『WebLogic Server 4.5 および 5.1 アプリケーションのバージョン 6.x への移行』の「weblogic.properties ファイルの .xml ファイルへの変換」および「weblogic.properties のマッピング表」を参照してください。
WebLogic Server 8.1 では、WebLogic Server 5.x カスタム レルム コードと WebLogic Server 6.x との互換性を確保するため、以下のようにコードを変更する必要があります。
BasicRealm.getUser(String) メソッドまたは BasicRealm.getUser(UserInfo) メソッドを CustomRealm クラスに実装する。このメソッドは、system、everyone、および Administrators に対して null を返します。 weblogic.server で始まる ACL 名について、リクエストを無視する (null を戻す) ための BasicRealm.getAcl() メソッドを実装します(たとえば、weblogic.server.myserver で始まる ACL 名など)。戻り値 null は、WebLogic Server 6.x インスタンスがこのプレフィックスで始まる ACL を無視して起動する必要があることを示します。警告 :上記の変更を実施しないと、サーバが起動しないことがあります。
WebLogic Server 6.x ドメインが「適切に」アップグレードされている場合は、WebLogic Server 8.1 が互換性セキュリティ用に自動的にコンフィグレーションされます。「適切に」とは、6.x と同じドメイン ディレクトリを使用し、起動スクリプト、クラスパスなどを「WebLogic Server 6.x ドメインのバージョン 8.1 へのアップグレード」の説明どおりに変更して、6.x ドメインが 8.1 で実行できるようにアップグレードされていることを意味します。この場合は、以下の作業を行うだけでセキュリティのアップグレードを完了できます。
これらの手順の具体例 (RDBMS レルムを使用した例) については、「手順 2: WebLogic Server 6.x RDBMS レルム コードを WebLogic Server 8.1 用に再コンパイルする」を参照してください。
WebLogic Server 6.x では、WebLogic リソースと対話できるユーザのパーミッションを ACL で定義していました。ACL は、MBean と他のタイプの WebLogic リソースの両方を保護するために使用していました。この節では、ACL の状態に関する以下の情報について説明します。
MBean の ACL は、WebLogic Server 8.1 ではサポートされていません。したがって、これを WebLogic Server 8.1 にアップグレードすることはできません。MBean の ACL の機能は、セキュリティ ロールによる保護に引き継がれています。セキュリティ ロールによる MBean の保護については、『WebLogic リソースのセキュリティ』の「保護された MBean の属性と操作」を参照してください。
WebLogic Server 8.x を互換性セキュリティで実行している場合、WebLogic Server 6.x のリソースを保護していた出荷時の ACL は、デフォルトのセキュリティ ポリシーで表現されています。追加で作成した ACL (MBean の ACL を除く) は、これまでどおり ACL として WebLogic リソースの保護に使用されます。つまり、WebLogic Server 8.x を互換性セキュリティで実行すると、6.x ACL と 8.1 のセキュリティ ロールやセキュリティ ポリシーが混在した環境になります。詳細については、『WebLogic リソースのセキュリティ』の「デフォルト セキュリティ ポリシー」を参照してください。
注意 :以下の手順を実行する前に、WebLogic Server 6.x ドメインが WebLogic Server 8.1 ドメインにアップグレードされており、WebLogic Server 6.x セキュリティ レルムが WebLogic Server 8.1 セキュリティ レルムにアップグレードされていることを確認してください。これらの手順については、「WebLogic Server 6.x ドメインのバージョン 8.1 へのアップグレード」および「セキュリティ レルムの WebLogic Server 6.x から 8.1 へのアップグレード」を参照してください。
myserver が実行されていない場合は、[プログラム｜BEA WebLogic Platform 8.1｜User Projects｜domains｜mydomain｜Start Server] を選択して起動します。[以前のセキュリティ] 内のレルム アダプタ認証プロバイダを使用すると、WebLogic Server 6.x セキュリティ コンフィグレーションで定義した ACL を表示できます。ただし、WebLogic リソースを保護する出荷時の ACL は、WebLogic Server 8.1 では使用されないため表示されない点に注意してください。
WebLogic リソースの詳細については、『WebLogic リソースのセキュリティ』の「WebLogic リソースのタイプ」を参照してください。
たとえば、グループ Administrators にはサーバのロックを解除するパーミッションがあると ACL に記述されていた場合は、[サーバ] リソースの [ALL] のポリシー エディタ ページに [呼び出し側に許可するロールは Admin] と表示されます。これは、WebLogic Server 8.1 では Administrators グループに Admin セキュリティ ロールが許可されているためです。
注意 :WebLogic リソースを保護するすべての出荷時の ACL は、グローバル ロールを使用するセキュリティ ポリシーにアップグレードされます。ただし、WebLogic Server 8.1 には WebLogic リソースを保護する場合に便利なスコープ ロールもあります。詳細については、『WebLogic リソースのセキュリティ』の「セキュリティ ロールのタイプ : グローバル ロールとスコープ ロール」を参照してください。
注意 :WebLogic Server 6.x から Weblogic Server 8.x にアップグレードされた ACL およびパーミッションは、examples ドメインおよび petstore ドメインの filerealm.properties ファイルにリストされています。これらの一覧は、コードリスト 3-1 および コードリスト 3-2 に示されています。
コード リスト 3-1 6.x examples ドメインからの fileRealm.properties
acl.modify.weblogic.jndi.weblogic.fileSystem=everyone
user.j2ee=0xe22513c99d9279bdf9318894033ef310b9aa830f
acl.lookup.weblogic.jndi.weblogic.fileSystem=everyone
acl.lookup.weblogic.jndi.weblogic.ejb=system,everyone
acl.lookup.weblogic.jndi=system,everyone
acl.list.weblogic.jndi.weblogic.rmi=system,everyone
acl.lockServer.weblogic.admin=system,guest
acl.shutdown.weblogic.admin=system,guest
group.gold=
acl.boot.weblogic.server=system,everyone
user.jps_admin=0xcc0b7594b451623dd59a3db8148de6984c60ac74
acl.list.weblogic.jndi.weblogic.fileSystem=everyone
acl.lookup.weblogic.jndi.weblogic=system,everyone
acl.modify.weblogic.jndi.weblogic.rmi=system,everyone
acl.modify.weblogic.jndi.weblogic=system,everyone
acl.list.weblogic.jndi.weblogic=system,everyone
acl.lookup.weblogic.management=system,everyone
group.cust=j2ee
acl.modify.weblogic.management=system,everyone
acl.findMBeans.weblogic.admin=Administrators
group.Administrators=system
group.admin=jps_admin
acl.lookup.weblogic.jndi.weblogic.rmi=system,everyone
acl.list.weblogic.jndi=system,everyone
acl.modify.weblogic.admin.acl=system,guest
acl.list.weblogic.jndi.weblogic.ejb=system,everyone
acl.modify.weblogic.jndi=system,everyone
acl.write.managedObject=system,guest
acl.reserve.weblogic.jdbc.connectionPool.demopool=system,everyone
acl.read.managedObject=system,guest
acl.admin.weblogic.jdbc.connectionPoolcreate=system,guest
user.system=0xc4d441a2bdd9c4bba6029d63066781512326d355
acl.unlockServer.weblogic.admin=system,guest
acl.reset.weblogic.jdbc.connectionPool=system
acl.execute.weblogic.servlet=everyone
acl.modify.weblogic.jndi.weblogic.ejb=system,everyone
コード リスト 3-2 6.x petstore ドメインからの fileRealm.properties
acl.modify.weblogic.jndi.weblogic.fileSystem=everyone
acl.lookup.weblogic.jndi.weblogic.fileSystem=everyone
user.support=0xa227185fac962e564de4796154a80757860e32d4
acl.lookup.weblogic.jndi.weblogic.ejb=system,newdbuSer,NEWDBUSER,everyone
acl.lookup.weblogic.jndi=system,newdbuSer,NEWDBUSER,everyone
acl.list.weblogic.jndi.weblogic.rmi=system,newdbuSer,NEWDBUSER,everyone
acl.create.weblogic.jms.ConnectionConsumer=guest
acl.lockServer.weblogic.admin=system,newdbuSer,NEWDBUSER,guest
acl.reserve.weblogic.jdbc.connectionPool.oraclepool=system,newdbuSer,NEWDBUSER,everyone
acl.shutdown.weblogic.admin=system,newdbuSer,NEWDBUSER,guest
acl.boot.weblogic.server=vlatas,system,newdbuSer,NEWDBUSER,everyone
acl.list.weblogic.jndi.weblogic.fileSystem=everyone
acl.lookup.weblogic.jndi.weblogic=system,newdbuSer,NEWDBUSER,everyone
acl.modify.weblogic.jndi.weblogic.rmi=system,newdbuSer,NEWDBUSER,everyone
acl.modify.weblogic.jndi.weblogic=system,newdbuSer,NEWDBUSER,everyone
acl.list.weblogic.jndi.weblogic=system,newdbuSer,NEWDBUSER,everyone
acl.lookup.weblogic.management=system,newdbuSer,NEWDBUSER,everyone
acl.modify.weblogic.management=system,newdbuSer,NEWDBUSER,everyone
acl.findMBeans.weblogic.admin=Administrators
group.Administrators=system
acl.lookup.weblogic.jndi.weblogic.rmi=system,newdbuSer,NEWDBUSER,everyone
acl.list.weblogic.jndi=system,newdbuSer,NEWDBUSER,everyone
acl.modify.weblogic.admin.acl=vlatas,system,newdbuSer,NEWDBUSER,guest
acl.list.weblogic.jndi.weblogic.ejb=system,newdbuSer,NEWDBUSER,everyone
acl.modify.weblogic.jndi=system,newdbuSer,NEWDBUSER,everyone
acl.frob.aclexample=joeuser
acl.write.managedObject=system,newdbuSer,NEWDBUSER,guest
acl.reserve.weblogic.jdbc.connectionPool.demopool=system,newdbuSer,NEWDBUSER,everyone
user.joeuser=0x5923f72dc88665f59c119a2a965897fc28a2feaa
acl.read.managedObject=system,newdbuSer,NEWDBUSER,guest
acl.admin.weblogic.jdbc.connectionPoolcreate=system,newdbuSer,NEWDBUSER,guest
user.system=0xfafe4ee933bf59e193de3a8a506a57ddd2364943
acl.unlockServer.weblogic.admin=system,newdbuSer,NEWDBUSER,guest
acl.reset.weblogic.jdbc.connectionPool=system
acl.execute.weblogic.servlet=everyone
acl.modify.weblogic.jndi.weblogic.ejb=system,newdbuSer,NEWDBUSER,everyone
WebLogic Server 8.1 の新しいセキュリティ機能を十分に活用するには、既存のセキュリティ コンフィグレーションを WebLogic Server 8.1 セキュリティ コンフィグレーションにアップグレードする必要があります。
WebLogic Server 8.1 で WebLogic Server 6.x コンフィグレーションを起動すると、CompatibilityRealm というセキュリティ レルムが作成され、デフォルト (アクティブ) セキュリティ レルムとして設定されます。この互換性レルムには、使用している 6.x のすべてのセキュリティ データが含まれています。これに加え、WebLogic Server 8.1 を起動すると myrealm というセキュリティ レルムが作成されます。
互換性セキュリティをアップグレードするには、myrealm セキュリティ レルムをデフォルト セキュリティ レルムにする必要があります。
レルムのテーブルに、コンフィグレーション済みの 2 つのセキュリティ レルム (CompatibilityRealm および myrealm) が表示されます。CompatibilityRealm のデフォルト属性は true に設定されています。
myrealm 用にコンフィグレーションされているセキュリティ プロバイダを表示します。デフォルトでは、myrealm には WebLogic セキュリティ プロバイダがコンフィグレーションされています。 Administrators グループに追加します。このユーザは system に代わるユーザです。ユーザを Administrators グループに追加するには、次の手順に従います。 myrealm をデフォルト (アクティブ) セキュリティ レルムとして設定します。詳細については、『WebLogic Security の管理』の「新しいセキュリティ レルムのデフォルト (アクティブ) セキュリティ レルムとしての設定」を参照してください。 WebLogic Server 6.x では、認証されないユーザ (匿名ユーザ) はすべて guest ユーザとして識別されました。また、guest ユーザは WebLogic リソースにアクセスできました。セキュリティ リスクを招くおそれがあったので、この機能は修正されました。
新しいバージョンの WebLogic Server では、guest ユーザはデフォルトではなくなりました。匿名ユーザに <Anonymous> という名前を割り当てることで、guest ユーザと匿名ユーザを区別するようになりました。
WebLogic Server 6.x と同じように guest ユーザを使用するには、以下のいずれかの方法で行います。
guest ユーザを定義する (WebLogic 認証プロバイダは、デフォルト セキュリティ レルムですでにコンフィグレーションされています)。WebLogic Server のインスタンスを起動するときに、以下の引数を設定して定義します。 警告 :この引数は、既存の WebLogic Server ユーザが効率的にセキュリティ機能をアップグレードできるように追加されたものです。guest ユーザをプロダクション環境で使用する場合には十分な注意が必要です。
WebLogic Server の以前のリリースでは、password.ini ファイルを使用して WebLogic Server デプロイメントの管理 ID を特定することができました。この password.ini ファイルは、WebLogic Server 8.1 ではサポートされなくなりました。代わりに、ユーザ名とパスワードを暗号化された形式で格納する boot.properties ファイルを使用します。boot.properties ファイルの使い方の詳細については、『Administration Console オンライン ヘルプ』の「起動 ID ファイル」を参照してください。古い password.ini を直接アップグレードすることはありません。
この節では、SSL のアップグレードに関する以下の内容について説明します。
ファイルまたは WebLogic キーストア プロバイダを ID や信頼の格納に使用することは、WebLogic Server 8.1 では非推奨になりました。また、ファイルに格納されたプライベート キーはパスワードで保護される場合とされない場合があります。パスワードで保護されていないプライベート キーは、セキュリティ攻撃に対して脆弱になります。ID および信頼の格納方法の 1 つとして、キーストアをアップグレードすることをお勧めします。キーストアを使用しない場合、このリリースの WebLogic Server では、プライベート キーおよび関連付けられたデジタル証明書の使用にパスワードが必要になります。詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
WebLogic Server 8.1 Administration Console は、下位互換性を確保するため、ファイル ベースの ID と信頼を使用して SSL をコンフィグレーションするメカニズムを備えています。ただし、キーストアはできるだけ早くアップグレードする必要があります。
WebLogic Server 8.1 のデフォルトでは、SSL クライアントがサーバの信頼性のある認証局をチェックします。このチェックは、WebLogic Server がクライアントとして動作しているときも含め、クライアントとサーバが SSL で接続されると必ず行われます。クライアントは、サーバの信頼性のある認証局が信頼できないとこれを拒否します。WebLogic Server の以前のリリースでは、SSL クライアントの信頼をファイルに格納することができていました。WebLogic Server 8.1 では、クライアントの信頼性のある CA 証明書はキーストアに格納しなければなりません。WebLogic Server 8.1 では、クライアントの信頼をキーストアに格納するための別の方法が用意されています。
デフォルトでは、JDK (...\jre\lib\security\cacerts) から利用できるすべての信頼性のある認証局が SSL クライアントから信頼されます。 次のコマンドライン引数を必要に応じて使用すると、JDK cacerts 信頼キーストアのパスワードを指定できます。
-Dweblogic.security.JavaStandardTrustKeystorePassPhrase=password
password は、Java 標準信頼キーストアのパスワードです。このパスワードは、キーストアを作成するときに定義します。
\server\lib ディレクトリに配置されたデモ用信頼キーストア (DemoTrust.jks) の信頼性のある CA 証明書。JDK cacerts キーストアの CA も信頼されます。デモ信頼を使用するには、次のコマンドライン引数を指定します。-Dweblogic.security.TrustKeyStore=DemoTrust
次のコマンドライン引数を必要に応じて使用すると、JDK cacerts 信頼キーストアのパスワードを指定できます。
-Dweblogic.security.JavaStandardTrustKeystorePassPhrase=password
password は、Java 標準信頼キーストアのパスワードです。このパスワードは、キーストアを作成するときに定義します。
キーストアの使い方の詳細については、『WebLogic Security の管理』の「SSL のコンフィグレーション」を参照してください。
このリリースの WebLogic Server のデフォルトでは、SSL クライアントがホスト名検証を実行します。SSL クライアントは、サーバから受信したデジタル証明書の一般名 (CN) フィールドと、サーバに接続するためにクライアントが使用した URL のサーバ名を比較します。CN フィールドとサーバ名が一致しないと、ホスト名の検証チェックはパスできません。WebLogic Server の以前のリリースでは、このチェックを有効にする必要がありました。
SSL クライアントが正常に機能するためには、このホスト名検証を無効にしなければならない場合があります。ホスト名検証を無効にすると、使用している環境が介在者の攻撃に対して無防備な状態になります。チェックを無効するには、次のコマンドライン引数を指定します。
-Dweblogic.security.SSL.ignoreHostnameVerification=true
注意 :SSL サーバがその URL で IP アドレスを指定した場合は、ホスト名の検証チェックを無効にしてください。
SSL クライアントは、WebLogic Server が提供するホスト名検証の代わりに、カスタム ホスト名検証を使用することもできます。カスタム ホスト名検証は、weblogic.security.SSL.HostnameVerifier インタフェースの実装です。次のコマンドライン引数を使用すると、カスタム ホスト名検証を指定できます。
-Dweblogic.security.SSL.hostnameVerifier=classname
classname は weblogic.security.SSL.HostnameVerifier インタフェースの実装を指定します。
WebLogic Server 6.x のセキュリティ コンフィグレーションを weblogic.security.acl.CertAuthenticator クラスの実装で使用していた場合は、レルム アダプタ認証プロバイダに含まれる ID アサーション プロバイダをコンフィグレーションする必要があります。
レルム アダプタ認証プロバイダで ID アサーション プロバイダを有効にするには、次の手順に従います。
ID アサーション プロバイダをコンフィグレーションすると、ユーザ名/パスワード認証の前に必ず証明書認証プロバイダが呼び出されます。クライアントが認証に双方向 SSL とユーザ名/パスワードの両方を使用していると、この動作変更が原因で WebLogic Server 6.x で記述した証明書認証プロバイダが失敗する場合があります。この問題を修正するには、レルム アダプタ認証プロバイダ内の証明書認証プロバイダをコンフィグレーションし、認識できない証明書に対して、または証明書を使用して SSL 接続を確立する場合にはすべての証明書に対して NULL を返すようにします。
WebLogic Server 6.1 で使用していたプライベート キーおよびデジタル証明書は、WebLogic Server 8.1 でも使用できます。プライベート キーおよびデジタル証明書を DER (distinguished encoding rules) 形式および PEM (privacy-enhanced mail) 形式の間で変換します。詳細については、『WebLogic Server Java ユーティリティの使い方』の「der2pem」の説明を参照してください。
ファイルの変換後、デジタル証明書ファイルに -----BEGIN CERTIFICATE---- ヘッダと -----END CERTIFICATE----- フッタがあることを確認してください。これらがない場合は、デジタル証明書は WebLogic Server 8.1 で機能しません。
以下の節では、非推奨となった機能、アップグレード、および WebLogic Server 8.1 での重要な変更点についての有益な補足情報を示します。
注意 :WebLogic Server 8.1 ではサンプル データベースとして PointBase 4.2 を使用しており、Cloudscape データベースは同梱されていません。
WebLogic Server 8.1 の組み込みトランスフォーマは、Apache Xalan 2.2 トランスフォーマをベースとしています。
Xalan API を直接使用することは非推奨になりました。それらの API を引き続き使用していて問題が発生する場合は、Java API for XML Processing (JAXP) を使用して XSLT を使用することをお勧めします。
Apache の Xalan コードは、Xerces と Xalan が連携できるように変更が行われています。その変更が含まれていないので、Apache から Xalan を使用すると問題が発生する場合があります。
一般には、JAXP を使用し、ベンダ固有のコードを SAX、DOM、および XSL 処理用に JAXP などの中立な API に移行するのが最適です。
以前のバージョンの WebLogic Server では、www.apache.org から入手できる Xerces パーサと Xalan トランスフォーマの未修正版が WL_HOME\server\ext\xmlx.zip ファイルに収められていました。現在では、ZIP ファイルにこれらのクラスおよびインタフェースは含まれていません。未修正版の Xerces パーサおよび Xalan トランスフォーマは、Apache Web サイトから直接ダウンロードしてください。
WebLogic Server 8.1 の組み込み XML パーサは、Apache Xerces 1.4.4 パーサをベースとしています。このパーサは SAX および DOM インタフェースのバージョン 2 を実装しています。以前のバージョンに付属していた古いパーサを使用すると、旧式であることを示すメッセージが表示される場合があります。
WebLogic Server 8.1 には、WebLogic FastParser も付属します。これは、WebLogic Web サービスに関連付けられた SOAP および WSDL ファイルなど、中小規模のドキュメントを処理するために特別に設計された高性能の XML パーサです。アプリケーションで中小規模 (要素数が 10,000 個程度まで) の XML ドキュメントを処理することがほとんどの場合、FastParser を使用するように WebLogic Server をコンフィグレーションします。詳細については、『WebLogic XML プログラマーズ ガイド』の「WebLogic Server XML の管理」を参照してください。
以前のバージョンの WebLogic Server では、www.apache.org から入手できる Xerces パーサと Xalan トランスフォーマの未修正版が WL_HOME\server\ext\xmlx.zip ファイルに収められていました。現在では、ZIP ファイルにこれらのクラスおよびインタフェースは含まれていません。
WebLogic Server 6.1、7.0 および 8.1 では、実行時モードが「開発」と「プロダクション」の 2 つに区別されています。実行時モードは、WebLogic Server の起動時にコマンドライン パラメータで指定します (-Dweblogic.ProductionModeEnabled=true | false)。このパラメータを true に設定していると、サーバは開発モードで動作します。開発モードでは、サーバの動作は WebLogic Server 6.0 の場合と同じです。ただし、バージョン 6.1 以降のプロダクション モードでは、自動デプロイメント機能が使用できないため、applications ディレクトリ内のデプロイメント ユニットのうち、コンフィグレーション リポジトリ (config.xml) で明示的にデプロイ対象として設定されていないものは自動的にはデプロイされません。
WebLogic Server 8.1 は 2 フェーズ デプロイメント モデルを使用しますが、このモデルによるデプロイメントのクラスタ化は、一部のサーバで失敗した場合、すべてのサーバで失敗します。このデプロイメント モデルと、バージョン 8.1 のその他のデプロイメント機能の詳細については、『デプロイメント』を参照してください。デフォルトでは、静的にコンフィグレーションされるアプリケーションは 6.x デプロイメント モデルを使用します。コンソールまたは新しいコマンドライン ユーティリティの weblogic.Deployer を使用して開始されるデプロイメントでは、新しい 2 フェーズ デプロイメント モデルが使用されます。
以前のバージョンとは違い、WebLogic Server 8.1 では、デプロイメント記述子にエラーのあるアプリケーションはデプロイされません。たとえば、WebLogic Server 6.x アプリケーションのデプロイメント記述子で参照記述スタンザが欠落していた場合、そのスタンザを追加するまでは WebLogic Server 8.1 にアプリケーションがデプロイされません。一般的なスタンザは次のようになります。
<ejb-reference-description>
<ejb-ref-name>ejb/acc/Acc</ejb-ref-name>
<jndi-name>estore/account</jndi-name>
</ejb-reference-description>
WebLogic Server 8.1 を使用する場合、6.x プロトコルを使用してコンソールからデプロイメントを行うことはできなくなりました。その結果、新しいデプロイメント API を使用しなければなりません。アプリケーションが以前に 6.x でデプロイされており、サーバを起動している場合、アプリケーションは 1 フェーズのデプロイメントによってデプロイされています。コマンドライン ユーティリティの weblogic.deploy および weblogic.refresh と、weblogic.management.tools.WebAppComponentRefreshTool はバージョン 8.1 では非推奨になっています。
非推奨になった MBean の属性および操作については、「非推奨になった API と機能」を参照してください。
EJB 2.0 仕様は、WebLogic Server 6.0 から WebLogic Server 8.1 までの間に大幅に、また WebLogic Server 6.1 から WebLogic Server 8.1 までの間にも若干変更されています。
ここでは重要な変更点をいくつか示します。WebLogic Server 6.0 から WebLogic Server 8.1 までの間に行われたすべての仕様変更を確認するには、http://java.sun.com/products/ejb/2.0.html から EJB 2.0 最終仕様を参照またはダウンロードしてください。
WebLogic Server 6.0 から WebLogic Server 6.1 までの間に行われた変更については、WebLogic Server バージョン 6.1 マニュアルの『WebLogic Server エンタープライズ JavaBean の概要』の「WebLogic Server の EJB 機能の強化」を参照してください。WebLogic Server 6.x で動作した EJB 1.1 Bean は、通常はそのまま WebLogic Server 8.1 でも動作します。
EJB 2.0 Bean については、以下の変更が必要になる場合があります。
relationship-role-source。6.0 では、role-source という名前でした。destination-type。6.0 では、jms-destination-type という名前でした。run-as。 6.0 では、run-as-specified-identity という名前でした。EJB-QL クエリに SELECT 句が必要になる。ejb-jar.xml ファイルで abstract-schema-name 要素を指定する必要がある。EJB 2.0 仕様の変更に由来する、その他の主な変更点は以下のとおりです。
NOT_SUPPORTED に限定されない。この実装では排他的ロックも行われず、各トランザクションが使用できる、読み込み専用 Bean の個別のインスタンスが提供されます。EJB QL クエリで、修飾形式のパスを使用せずに CMP または CMR フィールドを参照できた。ただし、最終仕様では、すべての EJB QL クエリで修飾形式パスの使用が必須となっています。NOT_SUPPORTED に限定されない。新しい実装では排他的ロックも行われず、各トランザクションが使用できる、読み込み専用 Bean の個別のインスタンスが提供されます。アプリケーション デプロイメントのスコープ内でサーブレットを使用した際の問題への対処については、『デプロイメント』を参照してください。
WebLogic Server 6.1 から WebLogic Server 8.1 にかけて、インタフェース weblogic.management.configuration.EJBComponentMBean が変更され、ComponentMBean および EJBContainerMBean の両方を拡張するようになりました。EJBComponentMBean を実装するすべてのメソッド (getVerboseEJBDeploymentEnabled など) は、WebLogic Server 6.0 から 8.1 にアップグレードする際に、EJBContainerMBean をサポートするように変更しなければなりません。
WebLogic Server 8.1 の max-beans-in-cache パラメータは、データベースの同時実行性を高めるためにキャッシュに格納される Bean の最大数を制御します。以前のバージョンの WebLogic Server では、max-beans-in-cache は無視され、キャッシュのサイズは無制限でした。このパラメータの値をより大きく調整しなければならない場合があります。
注意 :使用可能なメモリ量と必要なメモリ量を正しく評価してください。極端に大きい値を max-beans-in-cache パラメータに割り当てると、OutOfMemoryError が発生する可能性があります。必要なメモリ キャッシュ量は、キャッシュに格納される Bean の数と EJB のサイズを掛けることで算出できます。
WebLogic Server 8.1 で実行される EJB QL クエリでは、すべてのパス式は完全修飾形式でなければなりません。これは WebLogic Server 6.x からの変更点です。WebLogic Server 8.1 上で 6.x EJB を使用していて、ejbc の実行時に ejbc エラーが発生する場合、ejb-jar.xml ファイル内の ejb-ql 要素、または weblogic-cmp-jar.xml ファイル内の weblogic-ql 要素のどちらかを修正する必要があります。次に例を示します。
SELECT address FROM CustomerBean AS c WHERE zip = ?1
SELECT c.address FROM CustomerBean AS c WHERE c.zip = ?1
WebLogic jCOM 6.1 から WebLogic jCOM 8.1 へのアップグレードについては、『WebLogic jCOM プログラマーズ ガイド』の「アップグレードに関する考慮事項」を参照してください。
JDBC 接続プールの最小増加容量は、WebLogic Server 6.1 では 0 でしたが、バージョン 8.1 では 1 に変更されました。『コンフィグレーション リファレンス』の「JDBCConnectionPool」を参照してください。
WebLogic Server 8.1 のアプリケーションをコンパイルする場合は、以前の JDK ではなく JDK 1.4 を参照して、以降のビルドを実行することをお勧めします。
JDK 1.4 では、それ以前の JDK 以上に、JavaSoft JMS 仕様への準拠を厳密にする必要があります。たとえば、Blueprint サンプルのアプリケーション Pet Store には、セッターで String を指定する一方で int を宣言するメソッドが含まれています。このメソッドは、以前のバージョンの WebLogic Server では使用できましたが、JDK 1.4 では使用できないため、WebLogic Server 8.1 で実行するには修正する必要があります。「JSP の解析エラーを修正する」を参照してください。
1.3.1_09 より前の JDK で許容されていた不正なコードが、JDK 1.3.1_09 以降ではエラーになるようになりました。このエラーは、Introspector API に関係する JSP およびすべての Bean で発生します。特に、プロパティのセッターとゲッターの型が異なると、JDK 1.3.1_09 以降への移行後に次のような起動エラーが発生します。
Error in using tag library uri='/WEB-INF/tlds/taglib.tld' prefix='j2ee': There is no setter method for property 'numItems', for Tag class 'com.sun.j2ee.blueprints.petstore.taglib.list.SearchListTag' probably occurred due to an error in /template.jsp line 8: <%@ taglib uri="/WEB-INF/tlds/taglib.tld" prefix="j2ee" %>
型の一致に関する Java Bean 仕様にクラスが準拠していないと、違反しているプロパティを読み書きするためのメソッドが java.beans.Introspector API から返されなくなります。こうしたエラーが発生しないようにするには、クラス内のセッターとゲッターの型を一致させます。セッターが整数であれば、ゲッターも整数にする必要があります。文字列にすることはできません。
たとえば、次の例のように有効なセッターとゲッターを指定すると、Introspection API から有効な read および write メソッドが返されます。
private String foo;
public void setFoo(String f) {
foo = f;
}
public String getFoo() {
return foo;
}
次に、Java Bean 仕様に準拠していないコード例を示します。
private int foo; // foo が int であることに注意
public void setFoo(String f) {
foo = Integer.parseInt(f);
}
public int getFoo() {
return foo;
}
2 つめの例では、セッターとゲッターの型が一致しておらず、JDK 1.3.1_09 以降では Java Bean 仕様に厳密に準拠しているためにエラーが発生します。 */
API など、JDK 1.4 に追加されたものの中には、WebLogic Server 8.1 バージョンの weblogic.jar で削除されたものもあります。こうした API などは、クラスパスに以前のバージョンの weblogic.jar ではなく 8.1 の weblogic.jar を使用してアプリケーションをコンパイルした後は、WebLogic Server 8.1 のアプリケーションでは使用できなくなります。
たとえば JAXP は、以前のバージョンの weblogic.jar には入っていましたが、WebLogic Server 8.1 の weblogic.jar には入っていません。JAXP は JDK 1.3 に入っていないので、WebLogic Server 6.x アプリケーションで JAXP を使用していて、6.x の weblogic.jar を 8.1 の weblogic.jar に置き換えた後にそのアプリケーションをコンパイルする場合には、JDK 1.4 を使用してクラスをビルドしてください。
JDK 1.4 に対する他の WebLogic Server 8.1 の依存関係には、JAAS パッケージと Principal Authenticator オブジェクトが入っています。
WebLogic Server 8.1 は、JavaSoft の JMS 仕様バージョン 1.0.2 をサポートしています。
すべての WebLogic JMS 6.x アプリケーションは WebLogic JMS 8.1 でサポートされています。ただし、新しい高可用性 JMS の機能をアプリケーションで使用するには、既存の物理的な送り先 (キューおよびトピック) を、単一の分散送り先セットの一部としてコンフィグレーションする必要があります。JMS の分散送り先の使用方法については、『WebLogic JMS プログラマーズ ガイド』の「分散送り先の使用」を参照してください。
WebLogic JMS アプリケーションの移植の詳細については、『WebLogic JMS プログラマーズ ガイド』の「WebLogic JMS アプリケーションの移植」を参照してください。
WebLogic Server 6.x のすべてのパブリックな MBean および属性は、WebLogic Server 8.1 でサポートされています。ただし、内部的な MBean または属性を使用している場合には、移植時に問題が発生することがあります。
非推奨になった MBean の属性および操作については、「非推奨になった API と機能」を参照してください。
Jolt ユーザは、BEA WebLogic Server 8.1 を使用する Web に BEA Tuxedo サービスを対応させるために、Jolt Java Client 8.1.0 にアップグレードすることが必要になる場合もあります。詳細については、『サポート対象のコンフィグレーション』を参照してください。Jolt Java Client は、『ダウンロード』で入手できます。
ドメインを WebLogic Server 8.1 にアップグレードする際には、JVM を JRockit にアップグレードすることを検討してください。WebLogic JRockit は、Intel アーキテクチャ上で動作する Windows および Linux で実行されるサーバサイド アプリケーション用に設計された JVM です。サーバサイド アプリケーションでは、他の仮想ホストに比べて、JRockit には次のようなメリットがあります。
WebLogic Server ドメインは、次のように JRockit JVM に切り替えます。
@rem Set user-defined variables.
set JAVA_HOME=WL_HOME\jdk131
WL_HOME は、WebLogic Server 6.x のインストール ディレクトリです。これを次のように変更します。
@rem Set user-defined variables.
set JAVA_HOME=WL_HOME\jrockit81_141_02
JavaCompiler="WL_HOME\jdk131\bin\javac"
WL_HOME は、WebLogic Server 6.x のインストール ディレクトリです。これを次のように変更します。
JavaCompiler=WL_HOME\jrockit81_141_02\bin\javac"
echo on "%JAVA_HOME%\bin\java" -hotspot .... weblogic.Server
JRockit プラットフォームとユーザ情報については、適切なバージョンの WebLogic JRockit ドキュメントの『ユーザーズ ガイド』を参照してください。
JSP 仕様の変更により、null のリクエスト属性は空の文字列の代わりに文字列「null」を返すようになりました。バージョン 6.1 以降の WebLogic Server では、weblogic.xml に printNulls と呼ばれる新しいフラグがあります。デフォルトではこのフラグは true、すなわち「null」を返す設定になっています。printNulls を false に設定すると、式の結果が「null」になる場合に文字列「null」ではなく空の文字列が出力されます。
weblogic.xml における printNulls 要素のコンフィグレーションの例を次に示します。
<param-name>printNulls</param-name>
<param-value>false</param-value>
バージョン 6.x と 8.1 では、StartupClassMbean におけるロード順メソッドの動作が変更されました。
LoadBeforeAppDeployment を true または false に設定して、バージョン 6.x のロード順を設定すると、LoadBeforeAppActivation を使用するようになります。
6.x で LoadBeforeAppDeployments を true に設定したため、起動クラスが呼び出されるのは、データソースが作成されてからアプリケーションがアクティブになる間となりました。8.1 で同じロード順を実現するには、LoadBeforeAppActivation を true に設定します。
LoadBeforeAppDeployments はバージョン 8.1 にも残っていますが、動作が変更されました。現在は、起動クラスのロードおよび実行を、JMS サービスおよび JDBC サービスがサーバによってアクティブにされる前に行うか、アプリケーションと EJB がサーバによってデプロイされる前に行うかを決定するという動作を行います。
WebLogic Server 8.1 におけるこうしたメソッドの詳細については、../javadocs/weblogic/management/configuration/StartupClassMBean.html を参照してください。
WebLogic Server 6.x を実行している管理対象サーバは、WebLogic Server 8.1 を実行している管理サーバを使用してそのコンフィグレーションおよび起動情報を取得できません。WebLogic Server 6.x のインストール ディレクトリにある running-managed-servers.xml ファイルを、WebLogic Server 8.1 のインストール ディレクトリにはコピーしないでください。
WebLogic Server 8.1 では、実行キューのデフォルト名が変更されました。実行キューを指定するコンフィグレーションをアップグレードする場合、新しい実行キューの名前として、デフォルトのキュー名が自動的に付けられます。
このドキュメントの以前のバージョンおよび他のサンプルのドキュメントに、Administration Server で MBeanHome インタフェースをルックアップする方法として weblogic.management.Admin.getInstance().getAdminMBeanHome() を使用するという誤った説明がありました。
しかし、weblogic.management.Admin クラスはパブリックではありません。非パブリックなこのクラスを使用する代わりに、JNDI を使用して MBeanHome を取得します。『WebLogic JMX Service プログラマーズ ガイド』の「例 : アクティブなドメインとサーバの判別」を参照してください。
サーブレットの場合は、次に示す新しいクラスを使用するように web.xml ファイルを更新してください。
weblogic.servlet.proxy.HttpClusterServlet
weblogic.servlet.internal.HttpClusterServlet
weblogic.servlet.proxy.HttpProxyServlet
weblogic.t3.srvr.HttpProxyServlet
アプリケーション デプロイメントのスコープ内でサーブレットを使用した際の問題への対処については、「デプロイメント」を参照してください。
WebLogic Server 6.0 では、ワーカ スレッドの数はサーバ MBean の ThreadPoolSize パラメータで指定しました。WebLogic Server 6.1 からは、ワーカ スレッドの数はサーバ MBean の ExecuteQueue で定義します。
WebLogic Server 8.1 ではこのパラメータの移植パスが提供されるので、パラメータが config.xml ファイルで指定される、もしくはコマンドラインでクライアントまたはサーバに渡される (-Dweblogic.ThreadPoolSize=<xx>) 場合には、ThreadPoolSize が自動的に ThreadCount 設定に移行されます。
WebLogic Server 6.x では、スレッド数をコマンドラインで次のように設定します。
<Server
Name="myserver"
ThreadPoolSize="23"
...
/Server>
WebLogic Server 7.0 が初めて使用するバージョンの場合は、スレッド数をコマンドラインで次のように設定します。
<Server
Name="myserver"
... >
<ExecuteQueue
Name="default"
ThreadCount="23" />
/Server>
WebLogic Server 8.1 の Administration Console でスレッド数の値を変更するには、次の手順に従います。
WebLogic Server の以前のバージョンでは、余分なスペースを含んでいる URI が解決されました。WebLogic Server 8.1 では余分なスペースは解決されなくなり、URI リクエストに余分なスペースが含まれている場合は 404 エラーになります。
たとえば、http://server:port/mywebapp/foo%20%20 は以前は Web アプリケーション「mywebapp」のリソース foo として解決されましたが、8.1 ではこれは行われません。
weblogic.management.runtime.ServletRuntimeMBean.getName() API (WebLogic Server 6.0) は、WebLogic Server 6.1、7.0、および 8.1 で weblogic.management.runtime.ServletRuntimeMBean.getServletName() に変更されています。weblogic.management.runtime.ServletRuntimeMBean.getName() を使用する場合は、ソース コードを更新して再コンパイルする必要があります。 application.xml ファイルの context-root 要素を「/」に、スタンドアロンの Web アプリケーションである場合は weblogic.xml ファイルの同要素を「/」に設定します。 <check-auth-on-forward> を weblogic.xml ファイルに追加します。 Solaris 上の WebLogic Server クラスタにデプロイされた一部のアプリケーション (大きな EJB アプリケーション) は、サーバ JVM ではなくクライアント JVM を使用することでパフォーマンスが向上します。このことは、負荷の大きな状況で特に顕著になります。
WebLogic Server 8.1 で WebLogic Tuxedo Connector を使用するためには、アプリケーションおよびコンフィグレーションに以下の変更を行う必要があります。
注意 :WebLogic Tuxedo Connector のコンフィグレーション方法の詳細については、「Administration Console を使用した WebLogic Tuxedo Connector のコンフィグレーション」を参照してください。
WebLogic Server 7.0 より前のリリースでは、WebLogic Tuxedo Connector のセッションの開始に WebLogic Server の起動クラスを、またセッションの終了に WebLogic Server の停止クラスを使用しています。WebLogic Server 8.1 では、WebLogic Server のサービスとして WebLogic Tuxedo Connector を管理しています。
WebLogic Server Tuxedo Connector のセッションの開始と終了については、「サーバへの WTC サービスの割り当て」を参照してください。
8.1 では、WebLogic Tuxedo Connector はサービスとして実装され、独立した XML コンフィグレーション ファイルを使用しなくなりました。WTCMigrateCF ツールにより、XML コンフィグレーション ファイルの情報をアクティブな管理サーバの config.xml ファイルに移行します。8.1 以前の WebLogic Tuxedo Connector の XML コンフィグレーション ファイルを変換するには、次の手順に従います。
java-Dweblogic.wtc.migrateDebugweblogic.wtc.gwt.WTCMigrateCF-urlURL-usernameUSERNAME-passwordPASSWORD-infileCONFIGWTC
[-server SERVERNAME] [-domain DOMAIN] [-protocol PROTOCOL]
[-deploy]
このコマンドの引数の定義は次のとおりです。
移行が完了すると、移行ユーティリティは次のメッセージを表示します。
指定された XML コンフィグレーション ファイル内の情報が移行され、手順 2 で指定したサーバの config.xml ファイルに取り込まれます。移行ユーティリティによって、AppKey Generator 属性が TpUsrFile に、デフォルト AppKey 属性が -1 に設定されます。
WebLogic Tuxedo Connector でインバウンド RMI-IIOP を使用する方法の詳細については、「Using WebLogic Tuxedo Connector for RMI-IIORP」を参照してください。
8.1 でインバウンド RMI-IIOP を使用するには、WebLogic Tuxedo Connector のインスタンスを Tuxedo の CORBA アプリケーションに接続する参照オブジェクトを修正しなければなりません。Tuxedo の CORBA オブジェクトでは現在、サーバ名を使用してリモートの WebLogic Tuxedo Connector のオブジェクトを参照しています。以前のリリースでは DOMAINID を使用していました。
コード リスト 3-3ドメイン コンフィグレーション ファイル
*DM_RESOURCES
VERSION=U22*DM_LOCAL_DOMAINS
TDOM1 GWGRP=SYS_GRP
TYPE=TDOMAIN
DOMAINID="TDOM1"
BLOCKTIME=20
MAXDATALEN=56
MAXRDOM=89*DM_REMOTE_DOMAINS
TDOM2 TYPE=TDOMAIN
DOMAINID="TDOM2"*DM_TDOMAIN
TDOM1 NWADDR="<network address of Tuxedo domain:port>"
TDOM2 NWADDR="<network address of WTC domain:port>"*DM_REMOTE_SERVICES//
"servername"
詳細については、「ユーザ認証」を参照してください。
WebLogic Tuxedo Connector はアクセス制御リスト (Access Control Lists: ACL) を使用します。ACL は、サービスを実行できるリモート ドメインを制限することによって、ローカル ドメインの内部にあるローカル サービスへのアクセスを制限します。このパラメータの有効な値は次のとおりです。
WebLogic Tuxedo Connector の ACL ポリシーが LOCAL に設定されている場合、Tuxedo リモート ドメインの DOMAINID がローカル ユーザとして認証される必要があります。WebLogic Tuxedo Connector で DOMAINID がローカル ユーザとして認証されるようにするには、WebLogic Server 8.1 Administration Console を使用して、以下の手順を実行します。
WebLogic Tuxedo Connector の ACL ポリシーが GLOBAL の場合、ユーザのセキュリティ トークンが渡されます。管理上の変更は必要ありません。
注意 :WebLogic Tuxedo Connector のプロパティの設定方法については、「WebLogic Tuxedo Connector プロパティの設定方法」を参照してください。
TraceLevel および PasswordKey は、現在では WebLogic Server のプロパティとなっています。
WebLogic Server ログ ファイルを使用して WebLogic Tuxedo Connector をモニタするには、WebLogic Server の TraceLevel プロパティを使用してトレース レベルを設定する必要があります。詳細については、「WebLogic Tuxedo Connector のモニタ」を参照してください。
weblogic.wtc.gwt.genpasswd ユーティリティを使用してパスワードを生成するには、WebLogic Server の PasswordKey プロパティを使用してパスワード キーを設定する必要があります。パスワードの生成方法については、「パスワード コンフィグレーションのコンフィグレーション」を参照してください。
このリリースの WebLogic Tuxedo Connector は、WebLogic Server RMI-IIOP 実行時と CORBA サポートを使用する新しい WTC ORB を実装します。以前のリリースでは JDK ベースの WTC ORB を使用していました。ラッパーが用意されているので、従来のアプリケーションのユーザは、既存のアプリケーションを修正せずに新しい WTC ORB を使用できます。BEA では、ユーザが新しい WTC ORB に移行することをお勧めします。詳細については、「CORBA Java API を用いて WebLogic Tuxedo Connector クライアント Bean を開発する方法」を参照してください。
WebLogic Server のバージョン 6.1 から 8.1 の間に、Web サービスの実行時システムとアーキテクチャが変化したことにより、バージョン 6.1 で作成した Web サービスをバージョン 8.1 上で実行するにはアップグレードが必要です。
WebLogic Server 6.1 に組み込まれていた WebLogic Web サービス クライアント API は非推奨になり、この API を使用して 8.1 の Web サービスを起動することはできません。WebLogic Server 8.1 には、Java API for XML-based RPC (JAX-RPC) をベースとした新しいクライアント API が組み込まれています。
バージョン 6.1 の WebLogic Web サービスから 8.1 へのアップグレードについては、「6.1 WebLogic Web サービスから 8.1 へのアップグレード」を参照してください。
JAX-RPC を使用して WebLogic Web サービスを起動する例については、「クライアント アプリケーションおよび WebLogic Server からの Web サービスの呼び出し」を参照してください。
バージョン 6.1 と 8.1 の Web サービスの違いについては、「WebLogic Web サービスの紹介」を参照してください。
weblogic.deploy は WebLogic Server 8.1 のこのリリースでは非推奨であり、weblogic.Deployer に置き換えられています。詳細については、『WebLogic Server アプリケーションのデプロイメント』を参照してください。weblogic.management.tools.WebAppComponentRefreshTool および weblogic.refresh はともに、WebLogic Server 8.1 のこのリリースでは非推奨となっています。これらは weblogic.Deployer に置き換えられています。weblogic.Admin コマンドによってアプリケーションおよびコンポーネント MBean を作成し、MBean の属性を設定し、それらの MBean の操作を呼び出して MBean をシステムにデプロイしていた場合、MBean の次の属性および操作が非推奨となっている点に注意してください。deploy
load
undeploy
LastModified
LoadError
isDeployed
これらの属性および操作に代わる要素については、WebLogic Server 8.1 javadoc の、ApplicationMBean インタフェースに関する説明箇所を参照してください。
|
|
|