Oracle® Fusion Middleware

Oracle WebLogic Serverのアップグレード

12c (12.2.1.2.0)

E82833-02(原本部品番号:E78030-03)

2017年1月

このドキュメントでは、アプリケーション環境をOracle WebLogic Server 12c (12.2.1.2.0)にアップグレードする手順について説明します。

Oracle Fusion Middleware Oracle WebLogic Serverのアップグレード, 12c (12.2.1.2.0)

E82833-02

Copyright © 2007, 2017, Oracle and/or its affiliates. All rights reserved.

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

タイトルおよび著作権情報

はじめに

- ドキュメントのアクセシビリティについて

- 表記規則

1 はじめに

- バージョンの互換性

- 重要な用語

- WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード

- アップグレード・プロセスの概要

- 始める前に

- 旧リリースとの相互運用性および互換性

- 既存のWebLogic Serverインストールへのパッチ適用

- ダウンタイムなしのパッチ適用について

- ローリング更新について

- ローリング更新の実行

- パッチ、バンドル・パッチまたはパッチ・セット更新のロールバック

2 アプリケーション環境のアップグレードのロードマップ

- アップグレードの計画

- ステップ1: アプリケーション環境のインベントリの実施

- ステップ2: サポート対象構成情報の確認

- ステップ3: 互換性情報の確認

- ステップ4: アップグレード計画の作成

- アップグレードの準備

- ステップ1: アプリケーションの確認(必要に応じてアンデプロイ)

- ステップ2: アプリケーション環境内のサーバーの停止

- ステップ3: アプリケーション環境のバックアップの作成

- ステップ4: 必要なOracle製品のインストール

- ステップ5: 環境の設定

- アプリケーション環境のアップグレード

- アプリケーション環境をアップグレードする手順

- アップグレード・プロセスで問題が発生した場合のトラブルシューティング

3 WebLogicドメインの再構成

- 始める前に

- WebLogic Server 10.3.0より前に作成されたドメインのアップグレード

- UNIXおよびLinuxシステムでのCONFIG_JVM_ARGSの設定

- ドメインのバックアップ

- ノード・マネージャのアップグレード手順の決定

- 同じマシンでの複数のドメインごとのノード・マネージャの構成

- 同じマシンでの2つのホストごとのノード・マネージャの実行

- WebLogicドメインの再構成

- グラフィカル・モードでのWebLogicドメインの再構成

- WebLogic Scripting Toolを使用したWebLogicドメインの再構成

- ノード・マネージャ構成の完了

- ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)

- リモート・マシンの管理対象サーバー・ドメインの更新

- ドメインのアップグレードに関する重要な注意事項

- アップグレード後のタスクの実行

- 起動スクリプトへのカスタマイズの再適用

- デフォルト起動スクリプト

- カスタム起動スクリプト

- ファイル権限の確認

- リモート・サーバー起動オプションの確認

- Windowsノード・マネージャ・サービスの再作成

- アプリケーション環境の本番環境へのプロモート

- 評価版データベースを使用するドメインのアップグレード

4 WebLogic Webサービスのアップグレード

- 10.3.xのRESTful Webサービス(JAX-RS)の12.2.xへのアップグレード

- 10.xのWebLogic Webサービス(JAX-WS)の12.2.xへのアップグレード

- 8.1のWebLogic WebサービスのWebLogic JAX-WSスタックへのアップグレード

- WebLogic JAX-RPC WebサービスのWebLogic JAX-WSスタックへのアップグレード

5 再構成ウィザードの画面

- ドメインの選択

- 再構成セットアップの進行状況

- ドメイン・モードおよびJDK

- データベース構成タイプ

- JDBCコンポーネント・スキーマ

- GridLink Oracle RACコンポーネント・スキーマ

- Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ

- JDBCコンポーネント・スキーマ・テスト

- JDBCデータ・ソース

- GridLink Oracle RACデータ・ソース

- Oracle RACマルチ・データ・ソース

- JDBCデータ・ソース・テスト

- データベース・スクリプト

- ノード・マネージャ

- 拡張構成

- 資格証明

- キーストア

- 管理対象サーバー

- クラスタ

- サーバーのクラスタへの割当て

- HTTPプロキシ・アプリケーション

- Coherenceクラスタ

- マシン

- ドメイン・フロントエンド・ホスト

- サーバーのマシンへの割当て

- システム・コンポーネント

- OHSサーバー

- ODIサーバー構成

- システム・コンポーネントのマシンへの割当

- デプロイメント・ターゲット指定

- サービス・ターゲット指定

- JMSファイル・ストア

- 構成のサマリー

- 再構成の進行状況

- 再構成に成功しました

A WebLogic Server 12.2.1.2.0の旧リリースとの互換性

- WebLogic Server起動時のランタイム使用量の制限のオプションは削除されました

- 乱数ジェネレータ

- パーティション、アプリケーションおよびコンテナのコンテキスト・ルーツの想定

- デフォルトのCommonJ Work Managerの自動バインディングが削除されました

- パラレル・デプロイメント

- サーバー・ロギング・ブリッジ

- Oracleデータベース・ドライバ

- OracleでJavaNet FastPathの有効化

- 最大POSTサイズ

- WLDFスキーマのアップグレード

- jdbc-connection-timeout-secs要素

- ローカル・トランザクションのコミット

- JVMの設定

- Java承認ディレクトリの場所の設定

- permgen領域の設定

- ノード・マネージャのstartScriptEnabledのデフォルト

- Enterprise Java Beans (EJB)

- WebLogic Server 8.1 Webサービス・スタックの削除

- Universal Description and Discover (UDDI)レジストリの削除

- Certicom SSLの実装

- Coherenceのバージョン

- 非推奨および廃止済Webアプリケーションの機能

- PointBaseからDerbyに変更された評価版データベース

- データ・ソース・プロファイル・ロギング

- ONSのデバッグ

- DataDirectのOracleタイプ4 JDBCドライバの使用

- デフォルトのメッセージング・モードの変更

- SSLMBeanへの変更

- 新しいWebサービス機能

- JSSEの導入

- セキュリティ・ポリシー・デプロイメントのパフォーマンス向上

- ActiveCache

- クラス・キャッシュ

- 非推奨となったJDBCドライバ

- weblogic.jms.extension APIの変更

- 永続ストアの更新

- Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダ

- capacityIncrement属性

- Middlewareホーム・ディレクトリ

- リソース登録名

- サーブレット・パス・マッピング

はじめに

ここでは、このガイドOracle WebLogic Serverのアップグレードで使用されるドキュメントのアクセシビリティ機能および表記規則について説明します。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイトhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=docaccを参照してください。

Oracleサポートへのアクセス

サポートをご購入のOracleのお客様は、My Oracle Supportにアクセスして電子サポートを受けることができます。詳細情報はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=infoか、聴覚に障害のあるお客様はhttp://www.oracle.com/pls/topic/lookup?ctx=acc&id=trsを参照してください。

表記規則

このドキュメントでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

斜体

イタリックは、ユーザーが特定の値を指定するプレースホルダー変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 はじめに

このドキュメントでは、以前のリリースのWebLogic ServerからWebLogic Server 12cリリース1 (12.2.1.2.0)にサーバーおよびドメインをアップグレードする方法、および必要に応じてWebLogic Server 12.2.1.2.0で実行する既存のアプリケーションを更新する方法について説明します。WebLogic Server 12.2.1.2.0へのアップグレード時にアプリケーションを変更すると判断する場合や、アプリケーションの変更が必須となる場合もありますが、このドキュメントでは、アプリケーションの変更を行わずにWebLogic Server 12.2.1.2.0へアプリケーションを移動する際に考慮が必要な問題について説明します。

このドキュメントの手順は、次のアップグレード・シナリオに対応します。

- WebLogic Server 10.3.xの任意のリリースからWebLogic Server 12.2.1.2.0へのアップグレード

- WebLogic Server 12.1.xからWebLogic Server 12.2.1.2.0へのアップグレード

注意:

WebLogic Server 10.3.1より前のリリースからアップグレードする場合は、「WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード」を参照してください

12.2.1.1.0から12.2.1.2.0にアップグレードしている場合、スキーマまたは構成のアップグレードのためにアップグレード・アシスタント(UA)を実行する必要はありません。「再構成」ウィザードのみを実行する必要があります。ただし、新しいOracleホームにバイナリをインストールして、オフラインで再構成を実行する必要があります。

また、このドキュメントでは、既存のWebLogic Server 10.3.xまたは12.1.xドメインをWebLogic Server 12.2.1.2.0と互換性を持つように更新(再構成)する方法およびWebサービスをアップグレードする方法についても説明します。

WebLogic Serverは一般的に、WebLogic Serverのバージョン全体でハイレベルのアップグレード機能をサポートします。このドキュメントの目的は、WebLogic Serverアップグレード・サポートの提供と、アップグレード中に直面する可能性のある問題の特定によって迅速な解決を促すことです。

注意:

現在のJava EE環境およびデプロイされているアプリケーションを、Oracle Application Server 10gおよびOracle Containers for Java EE (OC4J)からWebLogic Server 12cリリース1 (12.2.1.2.0)にアップグレードする場合は、『Fusion Middleware Java EEアップグレード・ガイド』を参照してください。

このドキュメントでは、WebLogic Serverのみを含むOracle製品のインストールのアップグレード・プロセスについて説明します。インストールが他のOracle Fusion Middleware製品に含まれる場合は、アップグレードを開始する前に、『Oracle Fusion Middlewareのアップグレードのプランニング』およびインストールにおける各Fusion Middleware製品のアップグレード・ガイドを参照してください。

WebLogic Server12.2.1.2.0には、Fusion Middleware再構成ウィザードが含まれていて、WebLogic Serverおよびご使用のアプリケーション環境のアップグレードを支援します。

ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1.2.0の新たなアプリケーション環境で動作します。

この章の内容は次のとおりです。

- バージョンの互換性

- 重要な用語

- WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード

- アップグレード・プロセスの概要

- 始める前に

- 旧リリースとの相互運用性および互換性

- 既存のWebLogic Serverインストールへのパッチ適用

バージョンの互換性

アップグレード前に、WebLogic ServerとWebLogic Server 12.2.1.2.0のドメイン互換性要件を確認する必要があります。詳細は、『Oracle WebLogic Serverの理解』のドメイン内の互換性に関する項を参照してください。

重要な用語

次のトピックに進む前に、次の用語の説明をお読みください。

- アップグレード - このドキュメントでは、アップグレードという用語は、WebLogic Serverをアップグレードし、既存のアプリケーションを未変更のまま、新規の(アップグレードされた)WebLogic Serverバージョンに移動するプロセスのことを指します。

- 再構成 - アップグレードしたWebLogic Serverのバージョンと互換性を持つように、以前のWebLogic Serverのバージョンで作成されたドメインをアップグレードするプロセスです。これは、再構成ウィザードまたはWLSTのいずれかを使用して実行できます。

- アプリケーション環境 - アプリケーション環境には、アプリケーションとそのデプロイ先のWebLogicドメインが含まれます。また、そのドメインに関連するすべてのアプリケーション・データも含まれます。データベース・サーバー、ファイアウォール、ロード・バランサおよびLDAPサーバーなどのリソースが含まれる場合もあります。

- 移行 - アプリケーションやドメイン構成を、サード・パーティ製品からOracle製品に移動すること。

- 相互運用性 - (1)あるWebLogic Serverバージョンでデプロイされたアプリケーションが、別のWebLogic Serverバージョンでデプロイされた別のアプリケーションと通信する機能。(2) Oracle製品のコンポーネントが、標準のプロトコルを使用してサード・パーティ製のソフトウェアと通信する機能。

- 互換性 - あるWebLogic Serverリリースで構築されたアプリケーションを、アプリケーションが再構築されたかどうかに関係なく、別のWebLogic Serverリリースで実行できること。

WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード

WebLogic Server 10.3.1より前のWebLogicバージョンを現在使用している場合、バージョン12.2.1.2.0へのアップグレードには2段階のプロセスがあります。

- 最初に現在のインストール内容をWebLogic Server 10.3.6にアップグレードする必要があります。これを実行するには、WebLogic Serverアップグレード・ガイド(10.3.6)の説明に従ってください。http://docs.oracle.com/cd/E23943_01/web.1111/e13754/toc.htmを参照してください。ドメインをアップグレードするには、WebLogic Server 10.3.6ドメイン・アップグレード・ウィザードを使用してください。

注意:

WebLogic Server 10.3.6アップグレード・インストーラをダウンロードするには、「My Oracle Support」に適切なパッチ番号を入力します。

- パッチ13529623—10.3.6汎用アップグレード・インストーラ(JDKバンドルは含まれていません)

- パッチ13529653—10.3.6 Linux 32ビット・アップグレード・インストーラ

- パッチ13529639—10.3.6 Windows 32ビット・アップグレード・インストーラ

- パッチ13529649—10.3.6 Solaris 32ビット・アップグレード・インストーラ

- このガイドの説明に従って、WebLogic Server 10.3.6をWebLogic Server 12.2.1.2.0にアップグレードします。

注意:

WebLogic Server 12.1.2から、アップグレード・インストーラは提供されなくなりました。WebLogic Server 12.2.1.2.0を新しいディレクトリの場所にインストールする必要があります。既存のインストール上にインストールすることはできません。

アップグレード・プロセスの概要

アプリケーション環境のアップグレードに必要なプロセスは、アプリケーション・スコープにより異なります。アプリケーション環境は、WebLogicドメインとそれに関連付けられているアプリケーションおよびアプリケーション・データで構成されます。また、アプリケーション環境には、ファイアウォール、ロード・バランサ、LDAPサーバーなどの外部リソースも含まれます。図1-1に、WebLogicのアプリケーション環境の例を示します。

図1-1 WebLogicのアプリケーション環境の例

表1-1に、図1-1に示されているWebLogicアプリケーション環境のコンポーネントとそのアップグレード要件を示します。

表1-1 WebLogicのアプリケーション環境例のコンポーネントのアップグレード要件

コンポーネント

説明

アップグレード要件

WebLogicドメイン

管理サーバー(AS)と必要に応じて1台または複数の管理対象サーバー(MS1、MS2、MS3、MS4など)で構成されます。ドメイン内のサーバーは、複数のマシンにまがたる場合があります。さらに、重要なアプリケーションにロード・バランシングとフェイルオーバー保護を適用できるよう管理対象サーバーをクラスタとしてグループ化することができます。WebLogicドメインの詳細は、Oracle WebLogic Serverドメイン構成の理解のOracle WebLogicドメインの理解に関する項を参照してください。

ドメイン内のすべてのコンピュータのドメイン・ディレクトリをアップグレードします。

アプリケーション

WebアプリケーションやEJBなどを含むすべてのJava EEアプリケーション。一般的に、アプリケーションはドメイン内の1つまたは複数の管理対象サーバーにデプロイされます。デプロイメント戦略に応じて、アプリケーションはコンピュータ上のローカルに配置したり、共有ディレクトリを使用してアクセスできます。さらに、外部クライアント・アプリケーションがファイアウォールの外側からアプリケーション環境にアクセスすることも可能です。

ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1.2.0の新たなアプリケーション環境で動作します。詳細については、「旧リリースとの相互運用性および互換性」を参照してください。

外部リソース

ドメインとアプリケーション・データを格納するためのデータベース、ロード・バランサ、ファイアウォールなどのソフトウェア・コンポーネント。

すべての外部リソースがWebLogic Server 12.2.1.2.0と互換性があることを確認します。詳細は、Oracle Technology NetworkにあるOracle Fusion Middlewareのサポートされるシステム構成のページを参照してください。

WebLogic Serverにデプロイされているビジネス・アプリケーションのアップグレードには、複数のWebLogic Serverアプリケーションのアップグレードが必要な場合があり、一部のケースでは次の目的のためにドメインも連動してアップグレードする場合があります。

- 使用対象のWebLogic Serverバージョンの整合性の維持

- インストール全体における同一のサポートされた構成環境の使用

- 特定の相互運用性の要件への対応

たとえば、すべてのアプリケーションおよびドメインを同時にアップグレードする場合や、アップグレードを正確に定義された順序で行う場合、あるいは一部のアプリケーションおよびドメインをアップグレードする一方、その他のアプリケーションおよびドメインは旧バージョンのWebLogic Serverにそのまま残すような場合があります。

始める前に

アップグレード・プロセスを開始する前に、アップグレードする環境の範囲と、どのアプリケーションをどの順序でアップグレードするかについて検討してください。このドキュメントの範囲では、アップグレードのすべての組合せを網羅することはできません。したがって、アップグレードを計画する前に、次の内容を考慮する必要があります。この内容は、単一ドメインで実行中の単一アプリケーションが関連するアップグレードを対象にしています。

- 一般的に推奨される手順は、開発環境でアプリケーションをアップグレードし、標準のQA、テストおよびステージング・プロセスを使用して、アップグレードされたアプリケーションを本番環境に移動することです。

- アプリケーションのアップグレードでは通常、既存ドメインのアップグレードまたは新規ドメインの作成のどちらかを行います。このドメインから新バージョンのWebLogic Serverでアプリケーションを実行できます。アップグレードするアプリケーションをテストする目的のため、Fusion Middleware構成ウィザードまたは他の構成ツール(WLSTなど)を使用して、新規ドメインを作成する場合もあります。

注意:

ドメインがWebLogic Serverバージョン10.3.1より前のバージョンを使用して作成された場合は、最初にWebLogic Server 10.3.6にアップグレードする必要があります。「WebLogic Server 10.3.1より前のWebLogicバージョンからのアップグレード」を参照してください。WebLogic Server 10.3.6にアップグレードした後で、WebLogic Server 10.3.6ドメイン・アップグレード・ウィザードを実行して、ドメインをアップグレードします。その後、再構成ウィザードを使用して、ドメインをWebLogic Server 12.2.1.2.0にアップグレードできます。

- WebLogic Serverのバージョン・アップグレードを計画する際は、Oracle Technology Network (OTN)のFusion Middlewareのサポート対象システム構成ページを参照して、アップグレードされた環境がOracleでサポートされていることを、特に次の点について確認します。

- 現行および計画中のJVMおよびJDKのバージョン

- オペレーティング・システムのバージョン

- データベースのバージョン

- Webサービスのバージョン

- WebLogic Serverで同時使用または実行されるその他の製品のバージョン。これは、アップグレードされた環境が、WebLogic Serverで使用しているOracleまたは他のベンダーの製品によってサポートされているかを確認するためです。

- オラクル社は非推奨(つまり今後のリリースでは廃止予定)となったAPIおよび機能について文書化しており、現在も進行中です。この目的は、アップグレード性を維持するために使用を避けた方がいいAPIおよび機能について通知することです。現行のリリースで実際に廃止されているAPIおよび機能についても文書化されているため、以前のバージョンからアップグレードする場合は、対象のアプリケーションがアップグレードによる影響を受けるかどうかを判断できます。
APIおよび機能の廃止は累積方式です。たとえば、WebLogic Server 10.0からWebLogic Server 12.2.1.2.0にアップグレードする場合、アプリケーションはWebLogic Server 12.2.1.2.0で廃止されたAPIまたは機能に加えて、WebLogic Server 10.3で廃止されたAPIまたは機能による影響を受ける可能性があります。アップグレードの際は、WebLogic Serverのすべての対象バージョンに対する、非推奨および廃止となった機能に関するドキュメントをすべて確認してください。

- WebLogic Serverアプリケーションの構成、デプロイ、起動/停止または監視に使用する、あらゆるオートメーション(WLSTスクリプトなど)にアップグレード・プロセスが与えうる影響を(ある場合は)考慮する必要があります。アップグレード対象のアプリケーションおよびドメインとともに、オートメーションのアップグレードも必要になる場合があります。

- アプリケーションでのサードパーティ・ライブラリの使用によって発生しうる潜在的影響を考慮する必要があります。WebLogic Serverに埋め込まれている別バージョンの同一ライブラリと競合する可能性があるためです。特に、新バージョンのWebLogic Serverでは、WebLogic Serverに埋め込まれているオープン・ソース・ライブラリのバージョンが変更されている場合があります。旧バージョンのWebLogic Serverでは正常に動作するアプリケーションで、アップグレード後に新規クラス競合が発生することがあります。
サードパーティ・ライブラリが埋め込まれているアプリケーションをアップグレードする場合、Classloader Analysis Toolの使用と、WebLogic ServerアプリケーションのWebLogic Server 12.2.1.2.0へのアップグレード時にフィルタ・クラスローダーの使用を考慮する必要があります。このツールでは競合の特定、診断および解決が可能になり、アップグレード・プロセスも短縮される場合があります。

- 旧バージョンのWebLogic Serverでアプリケーションを実行中で、WebLogic Serverパッチまたはバグ修正を使用中の場合、アップグレード先のWebLogic Serverのバージョンにそのパッチまたはバグ修正が組み込まれているかどうかを調べる必要があります。

旧リリースとの相互運用性および互換性

ほとんどの既存のWebLogic Server 10.3.1以降のアプリケーションは、修正を加えることなくWebLogic Server 12.2.1.2.0の新たなアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、WebLogic Server 12.2.1.2.0の旧リリースとの互換性で互換性情報を確認してください。アプリケーションで非推奨になったAPIまたは削除されたAPIが使用されている場合は、実行時に警告または例外が発生するおそれがあります。

既存のWebLogic Serverインストールへのパッチ適用

この項では、既存のWebLogic Serverインストールにパッチを適用するために使用できる2つの方法について説明します。

- 顧客に対するサービスを中断せずにドメイン内のサーバーに更新をロールアウトする、高度に自動化された方法である「ダウンタイムなしのパッチ適用」を使用。この方法は、ドメインに3つ以上のノードが含まれ、パッチを適用するすべてのサーバーがクラスタに割り当てられている場合のみ使用できます。「ダウンタイムなしのパッチ適用について」を参照してください

- サーバーのローリング更新の手動実行。この処理も顧客に対するサービスを中断しませんが、手動の処理です。クラスタの一部でない個別のサーバーにパッチを適用する場合と、ドメインに含まれるノードが3つ未満の場合は、この方法を使用する必要があります。「ダウンタイムなしのパッチ適用について」を参照してください

ダウンタイムなしのパッチ適用について

WebLogic Server 12.2.1現在、ダウンタイムなしのパッチ適用(ZDTパッチ適用)を使用して、WebLogic Serverインストールに対するパッチ、バンドル・パッチまたはパッチ・セット更新を適用する処理を自動化できます。ZDTパッチ適用を使用すると、OPatchAutoツール、WLSTまたはWebLogic Server管理コンソールを使用して、ドメイン内のサーバーの一部またはすべてにわたり、更新のロールアウトを編成できます。簡略化すると、内容は次のとおりです。

- 2番目のOracleホームの作成とパッチ適用。これは、手動で行うことも、OPatchAutoを使用して処理を自動化することもできます。

- パッチが適用されたOracleホームをノードのすべてに配布。これも、手動で行うことも、OPatchAutoにさせることもできます。

- OPatchAuto、WLSTまたはWebLogic Server管理コンソールを使用してパッチ適用ワークフローを構成し、ドメイン内の目的のサーバーを更新。

ZDTパッチ適用では、以前にZDTパッチ適用を使用してWebLogic Serverインストールに適用したパッチを、パッチ適用ワークフローを使用して元に戻すこともできます。

ZDTパッチ適用の詳細は、『ゼロ・ダウンタイム・パッチ適用ワークフローの管理』を参照してください。

ローリング更新について

WebLogic Serverのローリング更新とは、クラスタまたはドメイン全体を停止せずに、既存のWebLogic Serverインストールに、パッチ、バンドル・パッチまたはパッチ・セット更新をインストールするプロセスのことを指します。ローリング更新は、アクティブなクライアント・セッションの状態を保持します。ローリング更新プロセス中に、クライアント・セッションは、非アクティブ・サーバーからアクティブ・サーバーにフェイルオーバーされ、アプリケーション・ユーザーにシームレスな経験を提供します。

クラスタのローリング更新時に、クラスタ内の他のサーバーが操作を続行する間、クラスタ内の各サーバーは個別にパッチ適用および再起動されます。クラスタの一部ではない管理対象サーバー上でもローリング更新を実行できます。

注意:

インストールにOracle Enterprise Manager (EM)が含まれる場合、『Oracle Enterprise Managerライフサイクル・マネージメント管理者ガイド』のソフトウェア・デプロイメントのパッチ適用に関する項を参照してください。

ローリング更新については、次の制限事項に留意してください。

- ローリング更新を使用してWebLogic Serverの新しいマイナー・バージョンにアップグレードすることはできません(たとえばバージョン12.1.2から12.1.3へ)。個々のパッチ、パッチ・バンドルまたはパッチ・セット更新のみをインストールできます(たとえば12.1.2.0.0から12.1.2.0.1へ、12.1.2.0.1から12.1.2.0.2へ、12.1.2.0.0から12.1.2.0.5へ)。新しいマイナー・バージョンにアップグレードするには、新しいOracleホーム・ディレクトリで新しいバージョンをインストールする必要があります。詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

- 管理サーバーが実行中のマシンは、管理対象サーバーのみを実行しているドメイン内のマシンと同じまたはそれ以降のバージョンのソフトウェアを実行している必要があるため、そのマシンを最初に更新する必要があります。

- WebLogic Serverがインストールされているマシンの場合、そのマシンで複数のサーバーが実行中の場合は、ローリング更新を実行する前に、そのマシン上で管理サーバーが実行中の場合はそれを含め、マシン上のすべてのサーバーを停止する必要があります。

- ドメイン内のすべてのサーバーが更新されるまで、ローリング更新プロセス中に構成変更を行わないでください。新しい構成オプションについては、特に注意が必要です。サーバーは処理できない設定を無視して、反応しないため、ローカル構成ファイルが適切に更新されません。また、新しい構成オプションを使用すると、ローリングの方法でのパッチ、パッチ・セットまたはパッチ・セット更新の削除を妨げる可能性があります。

ローリング更新の実行

Oracle WebLogic Serverのパッチ、バンドル・パッチまたはパッチ・セット更新を使用してローリング更新を実行するには、Oracle OPatchツールを使用します。一般的なプロセスは次のとおりで、管理サーバーで開始します。詳細は、OPatchを使用したパッチ適用を参照してください

1. アプリケーション、データベース・スキーマ、その他のアプリケーション・データ、およびドメインをバックアップしています。

2. WebLogic Serverのパッチ、バンドル・パッチまたはパッチ・セット更新をクラスタ内のサーバーにダウンロードします。

3. アップグレードするマシン上のサーバーを停止します。

a. 任意の保留中のプロセスを完了します。

b. サーバーを正常に停止します。

4. パッチまたはパッチ・セット更新を適用します。

5. サーバーを再起動します。

6. パッチを適用する必要がある各サーバー・マシンに対して、前述の手順を繰り返します。

注意:

ベスト・プラクティスとして、アクティブなクライアント・セッションの状態を保持するには、アップグレード順序で次のマシン上のサーバーが停止するまで、適切な時間、待機する必要があります。待機する時間は、アプリケーションがアイドル・クライアント・セッションを無効化するのにかかる時間に応じて、5分から10分ほどになることがあります。

パッチ、バンドル・パッチまたはパッチ・セット更新のロールバック

Oracle OPatchツールを使用して、適用されたパッチ、バンドル・パッチまたはパッチ・セット更新をロールバックします。詳細は、OPatchを使用したパッチ適用の次のトピックを参照してください。

- 単一のパッチをロールバックする場合は、適用した1つのパッチのロールバックに関する項を参照してください。

- 複数のパッチをロールバックする場合は、適用した複数のパッチのロールバックに関する項を参照してください。

2 アプリケーション環境のアップグレードのロードマップ

この章では、WebLogicのアプリケーション環境のアップグレードを準備し、実行する方法について説明します。

この章の内容は次のとおりです。

- アップグレードの計画

- アップグレードの準備

- アプリケーション環境のアップグレード

- アップグレード・プロセスで問題が発生した場合のトラブルシューティング

注意:

このドキュメントでは、WebLogic Serverのみを含むOracle製品のインストールのアップグレード・プロセスについて説明します。インストールが他のOracle Fusion Middleware製品に含まれる場合は、アップグレードを開始する前に、『Oracle Fusion Middlewareのアップグレードのプランニング』およびインストールにおける各Fusion Middleware製品のアップグレード・ガイドを参照してください。

アップグレードの計画

アプリケーション環境のアップグレードを計画することは、アップグレード・プロセスの重要な手順の1つです。使用している環境のすべてのアップグレード要件に対応する計画を策定するには、次のステップを実行します:

- ステップ1: アプリケーション環境のインベントリの実施

- ステップ2: サポート対象構成情報の確認

- ステップ3: 互換性情報の確認

- ステップ4: アップグレード計画の作成

ステップ1: アプリケーション環境のインベントリの実施

次のコンポーネントを指定することで、アプリケーション環境のインベントリを生成します。

- 管理サーバーとそれが存在するコンピュータ

- 管理対象サーバーとそれが動作しているコンピュータ

- アプリケーションの場所(すべての外部クライアント・アプリケーションも含む)

- 次のような外部リソース:

- 永続データとアプリケーション・データの保存に使用されているデータベース

- ファイアウォール

- ロード・バランサ

- アプリケーション環境を構築するのに必要なタスクの自動化に使用されているツール、スクリプト、テンプレート、およびソース・コード

「アップグレード・プロセスの概要」にアプリケーション環境の例がありますので(図1-1)、参考にしてください。

ステップ2: サポート対象構成情報の確認

WebLogic Server 12.2.1.2.0でサポートされる構成(たとえば、JDKバージョン、オペレーティング・システム・バージョン、Webサーバー・バージョン、データベース・バージョン)は変更されました。ご使用の環境を、これらの製品および他の製品のサポートされるバージョンにアップグレードする必要がある場合があります。

サポートされる構成の詳細は、Oracle Technology Network (OTN)上のOracle Fusion Middlewareのサポートされるシステム構成を参照してください。

データベースについては、次の点に注意してください。

- WebLogic Server 12.2.1.2.0ではPointBase 5.7がサポートされますが、PointBaseは現在WebLogic Serverインストール・プログラムに含まれません。WebLogic Serverサンプルを実行するためDerbyがPointBaseを置換します。
WebLogic Server 12.2.1.2.0にアップグレードするには、新規のWebLogic Serverインストールを作成する必要があります。したがって、PointBaseインストール・ディレクトリは含まれません。引き続きPointBaseを使用するには、「評価版データベースを使用するドメインのアップグレード」を参照してください

注意: WebLogic Serverの古いバージョンを使用して配信された5.7以前のバージョンのPointBaseは、WebLogicドメインに対してのみ使用できます。

- WebLogic Server 10.3.3以降、インストール・プログラムに含まれる評価版データベース(サンプル・アプリケーションやコード例用またはデモンストレーション・データベースとして提供されます)が、PointBaseからDerbyに変更されます。Derbyは、Java、JDBCおよびSQL標準に基づくオープン・ソースのリレーショナル・データベース管理システムです。Derbyの詳細は、http://db.apache.org/derby/を参照してください。
以前のバージョンのWebLogic ServerにPointBaseに基づくドメインがあり、このドメインをWebLogic Server 12.2.1.2.0にアップグレードする場合は、引き続きPointBaseを使用できます。ただし、これを使用するにはライセンスをhttp://www.pointbase.comで取得する必要があります。詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください

- WebLogic Server 10.3から、Oracle Thin DriverはWebLogic Serverのインストールに含まれています。

- Oracle OCIデータベース・ドライバからThinデータベース・ドライバに移行する場合は、生成されたJDBCモジュールからserverプロパティを削除する必要があります。例:

<property>
<name>server</name>
<value>servername</value>
</property>

- Oracle Thin DriverはWebLogic Serverでインストールされ、使用できる準備が整います。これらのドライバの使用の詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のWebLogic ServerでインストールされるJDBCドライバに関する項を参照してください。

ステップ3: 互換性情報の確認

ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1.2.0のアプリケーション環境で動作します。ただし、実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、WebLogic Server 12.2.1.2.0の旧リリースとの互換性で確認してください。

ステップ4: アップグレード計画の作成

以上の手順で収集した情報を使用して、アプリケーション環境のアップグレード計画を作成します。アップグレード・プロセスのスコープとタイミングは、ビジネス・ニーズに応じて特定します。次の点に注意してください。

- 現在本番環境にデプロイされているアプリケーション環境をアップグレードすることはお薦めしません。開発中またはテスト中のアプリケーション環境をアップグレードし、アップグレードした環境を本番環境にプロモートする前に、標準的な品質保証およびパフォーマンス・チューニングを行うことをお薦めします。

- たとえば、アプリケーション環境に多数のクラスタリングされたドメインがあり、多数のアプリケーションがデプロイされているなど、アプリケーション環境が複雑な場合は、アプリケーション環境のコンポーネントを段階的にアップグレードすることを推奨します。

- 管理するシステムの多様性とコストを最小限に抑えるため、単一のアプリケーション環境で使用されるWebLogic Serverのバージョン数を制限することを推奨します。

- WebLogicドメインでRDBMSセキュリティ・ストアを使用する場合は、RDBMSセキュリティ・ストアが構成された新しいドメインを作成すること推奨します。RDBMSセキュリティ・ストアを使用するドメインが作成済であっても、新しいドメインを作成し、そのドメインに既存のセキュリティ・レルムを移行してください。既存のドメインにはRDBMSセキュリティ・ストアを組み込まないでください。詳細は、『Oracle WebLogic Serverのセキュリティの管理』のRDBMSセキュリティ・ストアの管理に関する項を参照してください。

アップグレードの準備

アプリケーション環境をアップグレードする前に、次の手順を実行する必要があります。

- ステップ1: アプリケーションの確認(必要に応じてアンデプロイ)

- ステップ2: アプリケーション環境内のサーバーの停止

- ステップ3: アプリケーション環境のバックアップの作成

- ステップ4: 必要なOracle製品のインストール

- ステップ5: 環境の設定

ステップ1: アプリケーションの確認(必要に応じてアンデプロイ)

ドメインをアップグレードする前に、WebLogic Serverアプリケーションをアンデプロイする必要はありません。ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1.2.0のアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、WebLogic Server 12.2.1.2.0の旧リリースとの互換性で互換性情報を確認してください。アプリケーションで非推奨になったAPIまたは削除されたAPIが使用されている場合は、実行時に警告または例外が発生するおそれがあります。

ステップ2: アプリケーション環境内のサーバーの停止

アプリケーション環境をアップグレードする前に、アプリケーション環境内のすべてのサーバーを停止する必要があります。

ステップ3: アプリケーション環境のバックアップの作成

アプリケーション環境をアップグレードする前に、表2-1に示されているコンポーネントを手動でバックアップすることをお薦めします。ドメイン内のすべてのマシンに関連する情報をバックアップする必要があります。

表2-1 アプリケーション環境のバックアップに関する推奨事項

コンポーネント

推奨事項

ドメイン・ディレクトリ

管理サーバーとアプリケーション環境で定義されているリモートの管理対象サーバーのドメイン・ディレクトリをすべてバックアップします。

注意: アップグレードするドメインの自動バックアップを行っていた、ドメイン・アップグレード・ウィザードは、WebLogic Serverで提供されなくなりました。ドメインをアップグレードする前に、ドメイン・ディレクトリを手動でバックアップする必要があります。

アプリケーション、アプリケーション・データ、および永続データ

ドメイン・ディレクトリの外にあるアプリケーションとデータをすべてバックアップします。

ログ・ファイル

ログに記録されたすべてのメッセージの記録を維持する必要がある場合は、ログ・ファイルをバックアップします。ログ・ファイルにより大量のディスク容量が消費されることがあるので、ログ・ファイルを保持する必要がない場合は、ディスク容量を節約するため削除することもできます。

ステップ4: 必要なOracle製品のインストール

アプリケーション環境をアップグレードする前に、ドメイン内のすべてのコンピュータに必要なOracle WebLogic Server 12.2.1.2.0製品をインストールする必要があります。Oracle WebLogic製品のインストールの詳細は、『Oracle WebLogic ServerおよびCoherenceのインストールと構成』を参照してください。

ステップ5: 環境の設定

アップグレードする環境を設定するには:

1. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開きます。

2. WebLogic ServerクラスをCLASSPATH環境変数に、WL_HOME\server\binをPATH環境変数に追加します。WL_HOMEはWebLogic Serverのインストール先の最上位ディレクトリです。

WL_HOME\server\bin\setWLSEnvスクリプトを実行すると、これらの変数を設定できます。

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

アプリケーション環境のアップグレード

図2-1に、アプリケーション環境をアップグレードするのに必要な手順を示します。詳細は、アプリケーション環境をアップグレードする手順を参照してください。

図2-1 アプリケーション環境のアップグレードのロードマップ

アプリケーション環境をアップグレードする手順

表2-2に、アプリケーション環境のアップグレード手順の概要を示します。手順には、必須のものと省略可能なものがあります。各手順は、ドメイン内のすべてのコンピュータに対して、この表に示されている順序で実行する必要があります。

表2-2 アプリケーション環境のアップグレード手順

タスク

説明

WebLogic Server 10.3.6へのアップグレード

ドメインがWebLogic Server 10.3.0より前に作成された場合は、最初にWebLogic Server 10.3.6にアップグレードする必要があります。これは、WebLogic Server 10.3.6アップグレード・インストーラを使用して実行できます。詳細は、http://docs.oracle.com/cd/E23943_01/doc.1111/e14142/toc.htmにある『Oracle WebLogic Serverインストレーション・ガイド(10.3.6)』を参照してください。

ドメイン・アップグレード・ウィザードの実行

ドメインがWebLogic Server 10.3.0より前に作成された場合は、WebLogic Server 10.3.6ドメイン・アップグレード・ウィザードを実行して、ドメインをアップグレードします。「WebLogic Server 10.3.0より前に作成されたドメインのアップグレード」を参照してください

ドメインのバックアップ

管理サーバーのドメインをアップグレードする前に、ドメインのバックアップ・コピーを作成します。「ドメインのバックアップ」を参照してください

WebLogicドメインのアップグレード(管理サーバー)

再構成ウィザードを実行して、管理サーバーをホストするコンピュータ上のWebLogicドメインをアップグレードします。「WebLogicドメインの再構成」を参照してください

注意: 管理対象サーバーのドメインをアップグレードする前に管理サーバーのドメインを完全にアップグレードすることをお薦めします。

元のドメインのノード・マネージャ構成、およびアップグレードされたドメインの目的のノード・マネージャ構成に応じて、再構成ウィザードを介してノード・マネージャをアップグレードできることがあります。「ノード・マネージャのアップグレード手順の決定」を参照してください

ノード・マネージャ構成の完了

必要に応じて、ホストごとのノード・マネージャとしてノード・マネージャを構成します。これが必要となるのは、既存のドメインがホストごとのノード・マネージャ構成を使用していて、アップグレードされたドメインでホストごとのノード・マネージャの使用を続行する場合のみです。「ノード・マネージャ構成の完了」を参照してください

各管理対象サーバーのドメインをバックアップします。

管理対象サーバーのドメインをアップグレードする前に、ドメインのバックアップ・コピーを作成します。「ドメインのバックアップ」を参照してください

WebLogicドメインのアップグレード(リモートの管理対象サーバー)

packおよびunpackコマンドまたはWLST writeTemplate()コマンドをオンライン・モードで使用して、管理対象サーバーをホストするすべてのコンピュータ上のWebLogicドメインをアップグレードします。リモート・マシンの管理対象サーバー・ドメインの更新を参照してください。packおよびunpackの詳細は、PackおよびUnpackコマンドによるテンプレートとドメインの作成を参照してください。

注意: 管理サーバーと同じコンピュータにある管理対象サーバーについては、これ以上アップグレードの手順を実行する必要はありません。

アップグレード・プロセスで問題が発生した場合のトラブルシューティング

アップグレード・プロセスの手順が失敗すると、再構成ウィザードは失敗の理由を示すメッセージを表示してから終了します。続行するには、次のステップを実行します:

1. 「ステップ3: アプリケーション環境のバックアップの作成」で作成したバックアップ・ファイルを使用してアプリケーション環境を元の状態にリストアします

2. 再構成ウィザードにより報告された障害を修正します。

3. ドメインをアップグレードするために再構成ウィザードをもう一度実行します。

3 WebLogicドメインの再構成

この章では、再構成ウィザードを使用して、WebLogic Server 10.3.1以降のリリースまたはWebLogic Server 12.1.1以降のリリースを使用して作成されたWebLogic Serverドメインを再構成する方法について説明します。

再構成ウィザードを実行して、WebLogic Serverドメインを再構成する場合は、ドメインのアプリケーションによって、次の項目が自動的に更新されます。

- WLSコア・インフラストラクチャ

- ドメイン・バージョン

注意:

再構成ウィザードでは、ドメインに含まれる独自のアプリケーションは更新されません。独自のアプリケーションのアップグレード方法の詳細は、WebLogic Server 12.2.1.2.0の旧リリースとの互換性を参照してください。

この章の内容は次のとおりです。

- 始める前に

- WebLogicドメインの再構成

- リモート・マシンの管理対象サーバー・ドメインの更新

- ドメインのアップグレードに関する重要な注意事項

- 評価版データベースを使用するドメインのアップグレード

始める前に

アップグレード・プロセスを開始する前に、次の2つのセクションを参照してください。

WebLogic Server 10.3.0より前に作成されたドメインのアップグレード

ドメインがWebLogic Server 10.3.0より前に作成された場合は、最初にWebLogic Server 10.3.6にアップグレードする必要があります。WebLogic Server 10.3.6にアップグレードした後で、ドメイン・アップグレード・ウィザードを実行して、ドメインをアップグレードします。

WebLogic Server 10.3.6へのアップグレードおよびドメイン・アップグレード・ウィザードの実行の詳細は、次のURLにある『Oracle WebLogic Serverアップグレード・ガイド(10.3.6)』を参照してください。

http://docs.oracle.com/cd/E23943_01/web.1111/e13754/toc.htm

UNIXおよびLinuxシステムでのCONFIG_JVM_ARGSの設定

再構成ウィザードを実行してUNIXまたはLinuxオペレーティング・システムのドメインを再構成する前に、オペレーティング・システムの乱数ジェネレータを使用するためにCONFIG_JVM_ARGS環境変数を次の値に設定します(まだ設定していない場合)。

-Djava.security.egd=file:/dev/./urandom

これにより、再構成ウィザードでドメインを再構成するのにかかる時間が短縮されます。

ドメインのバックアップ

再構成ウィザードを実行する前に、ドメイン・ディレクトリのバックアップ・コピーを作成します。たとえば、C:\domains\mydomainをC:\domains\mydomain_backupにコピーします。

各リモート管理対象サーバーのドメインを更新する前に、各リモート・マシンのドメイン・ディレクトリのバックアップ・コピーを作成します。

ドメインの再構成がなんらかの理由で失敗した場合は、再構成を実行する前に、すべてのファイルおよびディレクトリをバックアップ・ディレクトリから元のドメイン・ディレクトリにコピーしてドメインを完全に元の状態に戻す必要があります。

ノード・マネージャのアップグレード手順の決定

WebLogic Server 12.1.2より前では、デフォルト起動スクリプトおよびデフォルトのノード・マネージャ・ホームの場所を介して、WebLogic Serverによってデフォルトのノード・マネージャ構成が指定されていました。デフォルトでは、そのマシン上で作成された新規ドメインは、デフォルトのノード・マネージャの場所でノード・マネージャに関連付けられていました。一般に、これはホストごとのノード・マネージャと呼ばれます。

WebLogic Server 12.1.2以降、ノード・マネージャのデフォルトの構成は、ドメインごとのノード・マネージャ構成です。つまり、ノード・マネージャ構成は指定されたドメインに固有です。これにより、指定されたマシン上の複数のドメインが、異なるノード・マネージャ構成を持つことができます。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

表3-1に、WebLogic Serverを12.1.1以前のバージョンから現行バージョンにアップグレードする場合、または12.1.2以降のバージョンから現行バージョンにアップグレードする場合の、サポートされているノード・マネージャのアップグレード・パスを示します。このコンテキストでホストごととは、ドメインごとのノード・マネージャ構成以外のノード・マネージャ構成を意味します。

表3-1 サポートされているノード・マネージャのアップグレード・パス

ノード・マネージャのアップグレード・パス

WebLogic Server 12.1.1以前から

WebLogic Server 12.1.2以降から

ドメインごとからドメインごとへ

使用不可

サポート対象

ドメインごとからホストごとへ

使用不可

サポート対象外

ホストごとからドメインごとへ

サポート対象

サポート対象

ホストごとからホストごとへ

手動構成

手動構成

表3-2に、サポートされている各アップグレード・パスのノード・マネージャのアップグレード詳細を示します。

表3-2 ノード・マネージャのアップグレード詳細

ドメインごとからドメインごとへ

ホストごとからドメインごとへ

ホストごとからホストごとへ

これは、ドメインごとのノード・マネージャにすでに構成されているWebLogic Server 12.1.2以降のすべてのリリースでは、自動アップグレードです。環境は標準設定に更新され、後でカスタマイズできます。

ドメインをアップグレードするために再構成ウィザードまたはWLSTを使用しているかどうかに関係なく、アップグレードは自動で行われます。

この場合、再構成ウィザードでは、ドメインの再構成中に「ノード・マネージャ」画面が表示されます。

WLSTを使用して、ドメインおよび必要なノード・マネージャ構成をアップグレードすることもできます。詳細および例は、「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください

複数のドメインごとのノード・マネージャが同じマシン上で実行される場合、「同じマシンでの複数のドメインごとのノード・マネージャの構成」を参照してください

「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャ構成を手動で完了する必要があります

一部の11gドメインが12cにアップグレードされる場合のみ、12cドメインに2つ目のノード・マネージャの構成が必要になることがあります。再構成プロセスを開始する前に、同じマシンでの2つのホストごとのノード・マネージャの実行を参照してください。ドメインの再構成の後で、ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)の説明に従って、ノード・マネージャ構成を完了します。

同じマシンでの複数のドメインごとのノード・マネージャの構成

ドメインごとのノード・マネージャ構成を使用して同じマシン上に複数のドメインがある場合、再構成ウィザードを実行する際、次のようになります。

- 11gドメインからアップグレードしている場合、「ノード・マネージャ」画面が表示されます。ドメインごとのデフォルトの場所またはドメインごとのカスタムの場所のいずれかを選択します。

- 12cノード・マネージャの既存のマシンを再構成する必要があるため、「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択します。

- 「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各ドメインに一意のノード・マネージャ・ポートを使用していることを確認してください。たとえば、マシン上で実行中の3つのドメインごとのノード・マネージャがある場合、ドメイン1にはポート5556、ドメイン2にはポート5557、ドメイン3にはポート5558を使用します。

同じマシンでの2つのホストごとのノード・マネージャの実行

次のすべての項目がアップグレード・シナリオに適用する場合、12cドメインに2つ目のノード・マネージャを作成するには、再構成プロセス中に追加の手順が必要です。

- 11gドメインの一部のみを12cにアップグレードします。

- 12cドメインのホストごとのノード・マネージャの使用を続行します。

- 11gと12cの両方のホストごとのノード・マネージャが同じマシンで実行されます。

再構成ウィザードの実行時には、次のようになります。

- 「ノード・マネージャ」画面で、「手動ノード・マネージャ・セットアップ」を選択します。これにより、12cドメインのホストごとのノード・マネージャとしてのノード・マネージャ構成がアップグレードされている状態を維持します。

- 12cノード・マネージャの既存のマシンを再構成する必要があるため、「拡張構成」画面で、管理対象サーバー、クラスタおよびCoherenceを選択します。また、「デプロイメントとサービス」を選択して、デプロイメントおよびサービスのマシンの割当てを確認します。

- 「管理対象サーバー」および「クラスタ」画面では、変更する必要はありません。「マシン」画面が表示されたときは、各マシンの名前を、11gドメインで使用されている名前以外に変更します。また、11gノード・マネージャで使用されているノード・マネージャのポート番号とは異なるノード・マネージャのポート番号を入力します。このドメインの各12cマシンには同じポート番号を使用します。

- デプロイメントおよびサービスが新しいマシン名に割り当てられていることを確認します。

WebLogicドメインの再構成

WebLogicドメインは次のように再構成できます。

- グラフィック・モードで、Fusion Middleware再構成ウィザードを実行します。

- コマンド・ラインから、WebLogic Scripting Toolを使用します。

注意:

ドメインの再構成プロセスを開始すると、元に戻すことはできません。再構成ウィザードまたはWLSTを使用してドメインをアップグレードする前に、ドメインのバックアップの説明に従ってドメインをバックアップしていることを確認してください。再構成プロセス中にエラーその他の中断が発生した場合は、バックアップの場所から元のドメイン・ディレクトリにファイルとディレクトリをコピーして、ドメインをリストアする必要があります。これは、再構成前にドメインを確実に元の状態に戻す唯一の方法です。

ドメインを再構成する場合:

- ドメインのconfig.xmlファイルのドメイン・バージョン番号は、管理サーバーのインストール済WebLogic Serverバージョンのメジャーおよびマイナー・バージョン番号(たとえば、12.2.1.0)に更新されます。

- すべてのインストール済Oracle製品の再構成テンプレートは、自動的に選択されてドメインに適用されます。これらのテンプレートは、WebLogicドメインが現在のWebLogic Serverバージョンと互換性を持つために必要な再構成タスクを定義します。

- 起動スクリプトが更新されます。

ドメインを再構成する場合は次の項目に注意してください。

- 管理サーバーのドメインを再構成した後で、再構成されたドメインをドメイン内のすべてのリモート管理対象サーバーにポートする必要があります。詳細は、「リモート・マシンの管理対象サーバー・ドメインの更新」を参照してください

- WLSTまたは再構成ウィザードのいずれかを使用してホストごとのノード・マネージャにドメインを再構成した後で、ノード・マネージャ構成を完了するための追加の手順を実行する必要があります。ノード・マネージャ構成の完了およびノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)を参照してください。

グラフィカル・モードでのWebLogicドメインの再構成

グラフィカル・モードで再構成ウィザードを使用してWebLogicドメインを再構成するには、次のようにウィザードを起動します。DOSコマンド・プロンプト・ウィンドウまたはUNIXシェルからのみ再構成ウィザードを起動できます。

注意:

GUIモードで再構成ウィザードを実行できない状況では、WLSTスクリプトを使用してドメインを再構成することをお薦めします。詳細は、「WebLogic Scripting Toolを使用したWebLogicドメインの再構成」を参照してください

Windowsコマンド・プロンプトまたはUNIXシステムから、再構成ウィザードをグラフィカル・モードで起動する手順は次のとおりです。

1. ドメインが存在するシステムにログインします。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開きます。

3. 次のディレクトリに移動します。ここでORACLE_HOMEは、Oracleホーム・ディレクトリです。

Windowsの場合: ORACLE_HOME\oracle_common\common\bin

UNIX:の場合: ORACLE_HOME/oracle_common/common/bin

4. 次のコマンドを実行します。

Windowsの場合: reconfig.cmd

UNIXの場合: sh reconfig.sh

注意:

reconfig.cmdまたはreconfig.shコマンドを実行すると、デフォルトのキャッシュ・ディレクトリが無効であることを示す次のエラー・メッセージが表示される場合があります。

*sys-package-mgr*: パッケージ・キャッシュ・ディレクトリを作成できません。

コマンドに-Dpython.cachedir=valid_directoryオプションを含めることで、キャッシュ・ディレクトリを変更できます。

再構成ウィザード・セッションのログ・ファイルを作成するには、コマンドに-log=reconfig.log -log_priority=debugパラメータを含めます。ログ・ファイルのファイル名(config_today.logなど)を指定できます。ログ・ファイルは、Oracleホーム・ディレクトリのlogsディレクトリに格納されます。log_priorityに有効な他の値は、OFF、SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINESTおよびALLです。

「ドメインの選択」画面が表示されます。

再構成ウィザードでは、表3-3にリストされる順序で一連の画面が表示されます。各画面の詳細は、再構成ウィザードの画面の関連項目を参照するか、または「画面」列のリンクをクリックします。

注意:

ドメインおよび他の要因により、アプリケーションによって、次の表に表示される画面のほかに、追加の構成画面が表示される場合もあります。これらの画面の詳細は、画面上の「ヘルプ」ボタンをクリックするか、再構成ウィザードの画面を参照してください。

再構成中に「拡張構成」画面が表示される場合は、オプションを選択しないで、すべての拡張構成をスキップしてくだい。必要に応じて、後でWLST、構成ウィザードまたはWebLogic Server管理コンソールを使用して、サーバーおよびクラスタの追加やデプロイメント・ターゲット指定の変更などの拡張構成を実行できます。

表3-3 既存のWebLogicドメインの再構成

画面

画面がいつ表示されるか

次のアクションを実行

ドメインの選択

常時

ドメイン・ディレクトリへのフルパスを入力するか、「参照」をクリックして、ドメイン・ディレクトリに移動して選択します。

「次へ」をクリックして、続行します。

再構成セットアップの進行状況

常時

再構成テンプレートのアプリケーションの進行状況を表示します。

処理が終了したら、「次へ」をクリックして、続行します。

ドメイン・モードおよびJDK

常時

ドメイン・モードは変更できません。

ドメインで使用するJDKを選択するか、「参照」をクリックして使用するJDKに移動します。

「次へ」をクリックして、続行します。

この時点で追加のドメイン構成画面が表示される場合があります。

追加の画面はドメイン構成によって異なります。

画面の「ヘルプ」ボタンをクリックするか、または表示順に画面のすべてが説明されている再構成ウィザードの画面を参照してください。

拡張構成

常時

詳細構成タスクを実行する各カテゴリ(存在する場合)のチェック・ボックスを選択します。

使用可能なチェック・ボックスは、ドメイン構成によって異なります。

「次へ」をクリックして、続行します。

この時点で追加のドメイン構成画面が表示される場合があります。

追加の画面は、選択した「拡張構成」オプションによって異なります。

画面の「ヘルプ」ボタンをクリックするか、または表示順に画面のすべてが説明されている再構成ウィザードの画面を参照してください。

構成のサマリー

常時

構成を確認します。

構成を変更するには「戻る」ボタンをクリックし、ドメイン再構成プロセスを完了するには「再構成」ボタンをクリックします。

再構成に成功しました

常時

再構成プロセスの最終ステータスを表示します。

構成ウィザードを終了するには、「終了」をクリックします。

WebLogic Scripting Toolを使用したWebLogicドメインの再構成

この項では、readDomainForUpgradeコマンドを使用し、オフライン・モードでWebLogic Scripting Tool (WLST)を使用してドメインを再構成する方法について説明します。

注意:

元のドメインがドメインごとのノード・マネージャ構成を使用している場合、ノード・マネージャは自動的にアップグレードされ、追加の手順は必要ありません。

元のドメインがホストごとのノード・マネージャを使用していて、その構成の使用を続行する場合、「ノード・マネージャ構成の完了」の説明に従って、ノード・マネージャを手動で再構成する必要があります

例3-1は、オフラインでWLSTを使用してmy_domainというドメインを再構成する方法を示しています。

例3-2は、DOMAIN_HOME/nodemanagerにあるドメインごとの構成に、既存のホストごとのノード・マネージャ構成を移行する方法を示しています。

例3-3は、/Oracle/Middleware/custom/nodemanagerにあるドメインごとの構成に、/Oracle/Middleware/oracle_common/common/nodemanagerにある既存のホストごとの構成を移行する方法を示しています。

setOptionコマンドで使用可能なノード・マネージャ・オプションの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のsetOptionに関する項を参照してください。使用可能なノード・マネージャのWLSTコマンドの詳細は、『WebLogic Server WLSTコマンド・リファレンス』のノード・マネージャ・コマンドに関する項を参照してください。

例3-1 WebLogicドメインの再構成

# Open the domain for upgrade.
wls:/offline> readDomainForUpgrade('c:/domains/my_domain')

# Save the updated domain.
wls:/offline/my_domain> updateDomain()

# Close the domain.
wls:/offline/my_domain> closeDomain()

既存のドメインがホストごとのノード・マネージャを使用していて、ドメインごとのノード・マネージャ構成に移動する場合、いくつかのオプションがあります。

- 既存のホストごとの構成を移行して、デフォルトの場所(DOMAIN_HOME/nodemanager)でドメインごとの構成を作成します。

- Oracle推奨のデフォルトに基づいた新しい構成を使用して、デフォルトの場所(DOMAIN_HOME/nodemanager)でドメインごとの構成を作成します。

- 既存のホストごとの構成を移行して、カスタムの場所でドメインごとの構成を作成します。

- Oracle推奨のデフォルトに基づいた新しい構成を使用して、カスタムの場所でドメインごとの構成を作成します。

例3-2 デフォルトの場所での新規ノード・マネージャ構成の作成

#Read domain for reconfiguration
readDomainForUpgrade('domains/mydomain')

#Set Node Manager username and password.
cd('/')
cd('SecurityConfiguration/mydomain')
cmo.setNodeManagerUsername('username')
cmo.setNodeManagerPasswordEncrypted('password')

#Browse Node Manager properties
cd('/')
cd('NMProperties')

# Create per domain Node Manager with new default configuration. Existing
# Node Manager properties will not be migrated in this case.
setOption('NodeManagerType','PerDomainNodeManager')
setOption('NodeManagerUpgradeType','New')

# Update the domain to commit the changes.
updateDomain()

例3-3 カスタムの場所への既存の構成の移行

#Read domain for reconfiguration
readDomainForUpgrade('/domains/mydomain')

#Set Node Manager username and password.
cd('/')
cd('SecurityConfiguration/mydomain')
cmo.setNodeManagerUsername('username')
cmo.setNodeManagerPasswordEncrypted('password')

#Browse node manager properties
cd('/')
cd('NMProperties')

# Create custom location Node Manager, migrating an existing Node Manager
# configuration with default values for Oracle-recommended default properties.
setOption('NodeManagerType','CustomLocationNodeManager')
setOption('NodeManagerHome','/Oracle/Middleware/custom/nodemanager/')
setOption('NodeManagerUpgradeType','Migrate')
setOption('OldNodeManagerHome','/Oracle/Middleware/Oracle_Home/oracle_common/
common/nodemanager')
setOption('NodeManagerUpgradeOverwriteDefault','true')

# Update the domain to commit the changes.
updateDomain()

ノード・マネージャ構成の完了

再構成したドメインがホストごとのノード・マネージャ構成を使用していて、そのドメインのホストごとのノード・マネージャの使用を続行する場合、再構成の後で、次の手順を実行します。

1. 新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanagerディレクトリを作成します。

2. nodemanager.propertiesおよびnodemanager.domainsファイルを以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、手順1で作成したディレクトリにコピーします。

3. 以前のインストールにnm_data.properties、SerializedSystemIni.dataまたはsecurity/SerializedSystemIni.datファイルが含まれている場合は、それを手順1で作成したディレクトリにコピーします。SerializedSystemIni.datをコピーする場合は、nodemanagerディレクトリの下にsecurityディレクトリを作成して、そこにファイルを格納します。

4. nodemanager.propertiesファイルに次の編集を行います。ORACLE_HOMEは、WebLogic Server 12.2.1.2.0インストールのOracleホーム・ディレクトリです。

- DomainsFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsファイルを指すように更新します。

- JavaHomeをWebLogic Server 12.2.1.2.0に対して使用しているJDKのjreディレクトリを指すように更新します。ファイルにjavaHomeプロパティ設定(小文字のj)も含まれる場合、必要ではないため削除します。

- NodeManagerHomeをORACLE_HOME/oracle_common/common/nodemanagerを指すように更新します。

- LogFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logを指すように更新します。

5. 独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。
以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGenを実行してこのインストールのデモ・キーストアを作成する必要があります。

a. setWLSEnvを実行します。
cd WL_HOME/server/bin

. ./setWLSEnv.sh (UNIX)

setWLSEnv.cmd (Windows)

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

b. ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。

c. セキュリティ・ディレクトリに変更し、次のコマンドを入力します。
java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase

d. 次のコマンドを入力して、DemoIdentity.jksファイルを生成します。
java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity

6. ORACLE_HOME/wlserver/server/bin directoryから、startNodeManager.cmd (Windows)またはstartNodeManager.sh (UNIX)を実行します。

7. ノード・マネージャを使用してサーバーを起動できることを確認します。詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。

- startManagedWebLogicスクリプトを使用して管理対象サーバーを起動します。

- nodemanager.propertiesのStartScriptEnabled値をtrueに設定します。これにより、管理対象サーバーの起動時にStartManagedWebLogicスクリプトを起動できます。

- permgen領域の設定の説明に従って、permgen領域を設定します。

- サーバーを起動するためにsetUserOverridesスクリプトを使用してpermgen設定を指定します。詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

ノード・マネージャ構成の完了(2つのホストごとのノード・マネージャ)

再構成したドメインがホストごとのノード・マネージャ構成を使用していて、11gドメインのホストごとのノード・マネージャがすでにあるマシンで12cドメインのホストごとのノード・マネージャの使用を続行する場合、再構成の後で、ドメイン内の各マシンで次の手順を実行します。

注意:

この項の手順を実行する前に、ドメイン内の各リモート・マシンにドメインを解凍したことを確認してください。コマンドに-nodemanager_type=ManualNodeManagerSetupパラメータおよび-overwrite_domain=trueパラメータを含めます。例:

./unpack.sh -domain=domain_home -template=template_jar -nodemanager_type=ManualNodeManagerSetup -overwrite_domain=true

1. 新しいWebLogic Serverのインストールでは、ORACLE_HOME/oracle_common/commonにnodemanagerディレクトリを作成します。

2. nodemanager.domainsおよびnodemanager.propertiesファイルを、以前のWebLogic ServerインストールのWL_HOME/common/nodemanagerディレクトリから、手順1で作成したディレクトリにコピーします。11gドメインがnodemanager.domainsにリストされている場合、その行を削除またはコメント・アウトします。

3. 各マシンでnodemanager.propertiesファイルを適切に編集します。具体的には、次のとおりです。

- SecureListenerが、SSLノード・マネージャを使用している場合はtrueに設定され、プレーン・ノード・マネージャを使用している場合はfalseに設定されていることを確認してください。

- DomainsFileをORACLE_HOME/oracle_common/common/nodemanager/nodemanager.domainsを指すように変更します。

- PropertiesVersionを12.1に変更します。

- NodeManagerHomeをORACLE_HOME/oracle_common/common/nodemanagerに変更します。

- JavaHomeを、WebLogic Server 12.2.1.2.0で使用しているJavaインストールのjreディレクトリを指すように変更します。

- javaHome行は、12cで必要ではないため削除します。

- ListenPortを、構成ウィザードの「マシン」画面で指定した値に変更します。

- LogFileを目的の場所およびファイル名に変更します。推奨値はORACLE_HOME/oracle_common/common/nodemanager/nodemanager.logです。

4. 独自のセキュリティ証明書を使用している場合は、これらの証明書の場所がnodemanager.propertiesで正しいことを確認します。証明書を別の場所に移動した場合はパスを更新する必要がある場合があります。
以前のインストールでWebLogic Serverデモ証明書を使用していた場合は、CertGenを実行してこのインストールのデモ・キーストアを作成する必要があります。

a. setWLSEnvを実行します。
cd WL_HOME/server/bin

. ./setWLSEnv.sh (UNIX)

setWLSEnv.cmd (Windows)

注意:

UNIXオペレーティング・システムでは、setWLSEnv.shコマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。

b. ORACLE_HOME/oracle_common/common/nodemanager/ディレクトリに変更し、存在しない場合はセキュリティ・ディレクトリを作成します。

c. セキュリティ・ディレクトリに変更し、次のコマンドを入力します。
java utils.CertGen -certfile democert -keyfile demokey -keyfilepass DemoIdentityPassPhrase

d. 次のコマンドを入力して、DemoIdentity.jksファイルを生成します。
java utils.ImportPrivateKey -certfile democert.pem -keyfile demokey.pem -keyfilepass DemoIdentityPassPhrase -keystore DemoIdentity.jks -storepass DemoIdentityKeyStorePassPhrase -alias demoidentity

5. ORACLE_HOME/wlserver/server/binディレクトリから、ノード・マネージャを起動します。

6. 管理サーバーが実行中の場合、管理サーバーを再起動します。

7. ノード・マネージャを使用してサーバーを起動できることを確認します。詳細は、Oracle WebLogic Serverノード・マネージャの管理のノード・マネージャを使用したサーバーの制御に関する項を参照してください。permgen設定がサーバーの起動に十分であることを確認するには、次の方法のいずれかを使用できます。

- startManagedWebLogicスクリプトを使用して管理対象サーバーを起動します。

- nodemanager.propertiesのStartScriptEnabled値をtrueに設定します。これにより、管理対象サーバーの起動時にStartManagedWebLogicスクリプトを起動できます。

- permgen領域の設定の説明に従って、permgen領域を設定します。

- サーバーを起動するためにsetUserOverridesスクリプトを使用してpermgen設定を指定します。詳細は、Oracle WebLogic Serverサーバーの起動と停止の管理のドメイン全体のサーバー・パラメータのカスタマイズに関する項を参照してください。

リモート・マシンの管理対象サーバー・ドメインの更新

WebLogicドメインに複数の管理対象サーバーが含まれ、各管理対象サーバー・ドメイン・ディレクトリが管理サーバーが存在しないリモート・マシン上にある場合、そのリモート・マシン上のドメインを更新するには次の方法のいずれかを使用できます。

- packコマンドに-managed=true引数が含まれていることを確認し、packを使用してドメイン・テンプレートJARを生成します。JARをリモート・マシンに移動してから、リモート・マシンでunpackを使用して管理対象サーバー・ドメインを作成します。詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』を参照してください。

- オンライン・モードでWLST writeTemplateコマンドを使用します。リモート・マシンから管理サーバーへの接続時にwriteTemplateコマンドを実行する場合は、管理サーバー上のドメインをテンプレートJARファイルを動的にパックして、そのテンプレートJARを指定されたディレクトリに転送します。
次のサンプルのWLSTスクリプトは、writeTemplateを使用してリモート・マシン上で管理対象サーバー・ドメインを作成または更新する方法を示しています。ドメインの各リモート・マシン上でスクリプトを実行します。このスクリプトでは次の操作を実行します。

- 管理サーバーへのログイン

- 管理サーバー・ドメインをJARファイルにパックして、それをリモート・マシン上の指定されたテンプレート・ディレクトリに書き込む

- 管理サーバーからの切断

- テンプレートJARの読取り

- リモート・マシン上でのドメインの作成

import os

wlsHome = os.getenv('WL_HOME')
mwHome = os.path.join(wlsHome, '..')

#Substitute the administrator user name and password values below as needed
connect('adminuser','adminpassword','admin_server_url')

#Create the path on the local machine where the template will be stored,
#The specified template JAR should not already exist. The timeout value
#specifies the number of milliseconds to elapse before the connection between
#the Administration Server and remote machine times out (default is 120000).
templatePath = '/user_templates/myTemplate.jar'
timeout = '180000'

#get the packed template from the Administration Server
writeTemplate(templatePath, timeout)

#disconnect from online WLST connection to the Administration Server
disconnect()

#read the template that was downloaded from the Administration Server
readTemplate(templatePath)

#specify the domain directory where the domain needs to be created
domainPath = 'domains/myDomain')

#create the domain
writeDomain(domainPath)

ドメインのアップグレード・プロセスに関する重要な注意事項

アップグレード・プロセスには次の重要な情報があります。

- WebLogic Serverアプリケーションをアンデプロイする必要はありません。ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.2.1.2.0のアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、WebLogic Server 12.2.1.2.0の旧リリースとの互換性で互換性情報を確認してください。アプリケーションで非推奨になったAPIまたは削除されたAPIが使用されている場合は、実行時に警告または例外が発生するおそれがあります。

- 少なくとも、ドメイン・ディレクトリに次のファイルが含まれている必要があります:

- config.xml

- セキュリティ関連のファイル(SerializedSystemIni.dat、DefaultAuthenticatorInit.ldift、DefaultAuthorizerInit.ldift、DefaultRoleMapperInit.ldift)
セキュリティ関連のファイルがないと、サーバーは起動されず、認証エラー・メッセージがログに記録されます。

- ドメイン内にあるトランザクション・ログ・ファイル(..tlog)。詳細は、Oracle WebLogic Server JTAアプリケーションの開発のトランザクション・ログ・ファイルに関する項を参照してください。

- ターゲットのコンピュータ上のドメイン・ディレクトリに含まれるすべての内容がこのプロセスにおいて更新されます。

- アプリケーション環境内のすべてのコンピュータのドメインをアップグレードする必要があります。

- 再構成ウィザードでは、WebLogicドメインのアップグレード時に、ドメインに存在する可能性のある独自のアプリケーションはアップグレードされません。

- WebLogic Liquid Data、またはAquaLogic Data Services Platformのリソースを含むドメインは、WebLogic Server 12.2.1.2.0にアップグレードできません。

- リモートの管理対象サーバーのドメインをアップグレードするとき、参照されているアプリケーション・パスがシステムにないことを通知する次のようなメッセージが表示される場合があります。

<Apr 12, 2009 6:42:06 PM EDT> <INFO> <Upgrade> <BEA-800000> <An invalid
path, 'C:\bea\wlserver_10.3\user_projects\mydomain\medrecEar.ear', was
specified for application, 'medrecEar'.>

このメッセージは無視できます。

- Solarisコンピュータ上(のみ)でAvitek Medical Recordアプリケーションを8.1から12.1.3にアップグレードした場合は、サーバーを起動する前に、setDomainEnv.shファイルの起動コマンドから-Xverify:noneを削除します。これを行うには、次の行の後でJAVA_OPTIONS=""を設定します。

. ${WL_HOME}/common/bin/commEnv.sh

そうでない場合、JVMエラーのためサーバーの起動に失敗します。

アップグレード後のタスクの実行

アプリケーション環境をアップグレードした後で、次のタスクを実行する必要がある場合があります。

- 起動スクリプトへのカスタマイズの再適用

- ファイル権限の確認

- リモート・サーバー起動オプションの確認

- Windowsノード・マネージャ・サービスの再作成

- アプリケーション環境の本番環境へのプロモート

必ずしもすべての手順を実行する必要があるわけではありません。以下の説明に基づいて、アプリケーション環境に必要な手順を決定してください。互換性の問題が環境に適用されるかどうかについては、WebLogic Server 12.2.1.2.0の旧リリースとの互換性で互換性問題を確認してください。

起動スクリプトへのカスタマイズの再適用

アプリケーション環境の12.2.1.2.0へのアップグレードを完了するには、起動スクリプトへのカスタマイズの再適用が必要になる場合があります。次の節では、デフォルト起動スクリプトおよびカスタム起動スクリプトをカスタマイズする方法について説明します。

デフォルト起動スクリプト

再構成ウィザードによるアップグレード・プロセスでは、デフォルト起動スクリプトに対して行われたカスタマイズの内容(JAVA_OPTIONS環境変数の設定など)は保持されません。アップグレード・プロセスが完了した後に、デフォルト起動スクリプトを再びカスタマイズする必要があります。

ドメインを12.2.1.2.0にアップグレードすると同時にPointBaseを継続して使用する場合は、PointBaseのJARファイルをCLASSPATH環境変数定義の先頭に追加する必要があります。これを行うには、setDomainEnvファイル内のset CLASSPATH文を変更します。

注意:

WebLogic Server 12.2.1.2.0ではPointBase 5.7がサポートされますが、PointBaseの任意のバージョンをWebLogic Server 10.3.3以上で使用するには、http://www.pointbase.comで入手できるPointBaseのライセンスが必要です。

カスタム起動スクリプト

カスタム起動スクリプトを作成した場合は、次の手順に従って手動で更新する必要があります。

- JDKバージョンをWebLogic Serverで使用しているJDKに設定します。

- 次のようにCLASSPATH変数を更新します。

- WebLogic Server 12.2.1.2.0のクラスを変数の先頭に追加します。

- 使用されていない10.3より前のバージョンのWebLogicのクラスをすべて削除します。

- PointBaseを継続して使用するには、PointBaseデータベースのJARをCLASSPATH環境変数定義の最初に追加します。
評価版データベースを使用するドメインのアップグレードの詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください

ファイル権限の確認

次のようにファイル権限を確認します。

- アップグレード・プロセスにおいてドメイン・ディレクトリのバックアップを行った場合、バックアップ・ファイルには機密情報が含まれている可能性があるため、バックアップ・ファイルを保護する必要があります。

- アップグレード・プロセスでは、ファイル権限は保持されません。デフォルト以外のファイル権限がファイルに設定されている場合は、これらを確認し、リセットする必要があります。

- UNIXシステムでは、アップグレード・プロセス中に作成される新しいファイルの所有権と権限は、アップグレードを実行するユーザーに割り当てられます。たとえば、アップグレードがrootにより実行される場合、新しいファイルの所有権はrootに割り当てられます。このため、後でドメイン内のこれらのファイルを更新するユーザーにはroot権限が必要となります。したがって、アップグレード・プロセス中に作成されたファイルに設定されている権限を確認または修正することをお薦めします。

リモート・サーバー起動オプションの確認

管理サーバーを起動したら、JAVA_HOME、BEA_HOME、CLASSPATHなどのリモート・サーバー起動オプションが、対象の管理対象サーバーにインストールされているWebLogic Server を参照していることを確認します。これはWebLogic Server管理コンソールを使用して行います。詳細は、Oracle WebLogic Server管理コンソール・オンライン・ヘルプの管理対象サーバーの起動引数の構成に関する項を参照してください。

注意:

リモート・サーバー起動オプションが正しく設定されていないと、ノード・マネージャを使用して管理対象サーバーを起動するときに、次のようなメッセージがログ・ファイルに書き込まれることがあります。このメッセージは再帰的に送信されるため、最終的に使用可能なディスク容量がすべて消費されるおそれがあります。

No config.xml was found.

Would you like the server to create a default configuration and boot? (y/n):
java.io.IOException: The handle is invalid

Windowsノード・マネージャ・サービスの再作成

Windowsシステムで、ノード・マネージャをドメインのWindowsサービスとして実行していて、引き続きこれを使用する場合、再構成する必要があります。

Windows用のノード・マネージャ・サービスの構成方法の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

オプションで、uninstallNodeMgrSrv.cmdを実行して、インストールからノード・マネージャ・サービスを削除できます。『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

アプリケーション環境の本番環境へのプロモート

アプリケーション環境を本番環境にプロモートする前に、標準的な品質保証およびパフォーマンス・チューニングを行います。テスト・アプリケーション環境でアプリケーション(外部クライアント・アプリケーションを含む)の動作をテストすることをお薦めします。非推奨となったAPIまたは削除されたAPIがアプリケーションで使用されている場合は、実行時に警告または例外が発生するおそれがあります。発生した場合は、アプリケーション環境を本番環境にプロモートする前に、必要な修正を行う必要があります。

すべてのテスト基準をクリアしていれば、「ステップ4: アップグレード計画の作成」で定義したアップグレード計画に従って、アプリケーション環境を本番環境にプロモートできます。

新しい12.2.1.2.0のアプリケーション環境が本番環境にデプロイされたら、既存の環境から新しい環境にリクエストをリダイレクトできるようになります。このようにして、最終的には、既存の環境を安全な停止状態にすることができます。これは、ロード・バランサなどを使用して行います。

評価版データベースを使用するドメインのアップグレード

WebLogic 10.3.3以降、インストール・プログラムに含まれる評価版データベースが、PointBaseからDerbyに変更されています。評価版データベースは、サンプル・アプリケーションやコード例で使用されるため、またデモンストレーション・データベースとして使用するために提供されます。PointBaseを使用していたサンプルやデモのドメインをアップグレードする場合は、ドメインのPointBaseを引き続き使用するオプションがあります。

WebLogic 12.2.1.2.0にアップグレードするドメインでデータベースとして引き続きPointBaseを使用するには、次の手順を実行します。

1. アップグレードの準備の説明に従ってWebLogic Server 12.2.1.2.0をインストールするとき、フル・インストーラを使用する必要があります。フル・インストーラを使用すると、前のWebLogic ServerインストールのPointBaseインストールが保存されません。

2. アプリケーション環境のアップグレードおよびアップグレード後のタスクの実行で説明されている手順を実行します。

PointBaseに関するドメインの構成設定が保存されます。

3. http://www.pointbase.comでPointBaseのライセンスを取得します。

4. PointBaseインストールをリストアします。PointBaseは、WL_HOME/common/eval/pointbaseディレクトリにインストールされます。

5. PointBaseデータベースのJARをCLASSPATH環境変数定義の最初に追加します。

4 WebLogic Webサービスのアップグレード

次の項では、WebLogic Server 10.xからWebLogic Server 12.2.x リリースへのWebLogicおよびRESTful Webサービスのアップグレード手順について説明します。また、8.1のWebLogic Webサービスを12.2.x WebLogic JAX-WS Webサービスにアップグレードする方法も説明します。

この章の内容は次のとおりです。

- 10.3.xのRESTful Webサービス(JAX-RS)の12.2.xへのアップグレード

- 10.xのWebLogic Webサービス(JAX-WS)の12.2.xへのアップグレード

- 8.1のWebLogic WebサービスのWebLogic JAX-WSスタックへのアップグレード

- WebLogic JAX-RPC WebサービスのWebLogic JAX-WSスタックへのアップグレード

注意:

関連するWebサービス・ランタイムはこのリリースでもサポートされるため、10.3.xのWebLogic Webサービス(JAX-WSまたはJAX-RPC)は変更しなくてもバージョン12.2.xのWebLogic Serverで引き続き実行できますが、対象のWebサービス・ランタイムは非推奨になっており、今後のリリースの製品からは削除される予定です。このため、この章の説明に従って、10.3.xのWebサービスを12.2.xにアップグレードすることをお薦めします。

JAX-RPC APIは、12.2.xから非推奨となり、今後のリリースで削除される予定です。JAX-RPCスタックへのアップグレードはお薦めしません。

10.3.xのRESTful Webサービス(JAX-RS)の12.2.xへのアップグレード

10.3.xでは、RESTful Webサービス(JAX-RS)参照実装(RI)のJersey 1.9および1.1.5.1 Java APIをサポートするために、一連の事前構築済共有ライブラリがWebLogic Serverに付属しています。共有ライブラリを使用するためには、WebLogic Serverインスタンスにそのライブラリを登録し、Jerseyサーブレットを使用して共有ライブラリを参照するためにweb.xmlおよびweblogic.xmlのデプロイメント記述子をそれぞれ変更する必要があります。

WebLogic Serverの12.2.xリリースでは、デフォルトでJersey 2.21.x (JAX-RS 2.0 RI)がサポートされています。共有ライブラリとしてのWebLogic Serverへの登録は不要になりました。

Jersey 2.21.x (JAX-RS 2.0 RI)を使用するには、次のように、10.3.x RESTful Webサービス・アプリケーションを変更する必要があります。

1. Jersey 2.xコンテナを参照するように、アプリケーションのデプロイメント・ディスクリプタを更新します。詳細は、Jersey 2.21 User GuideのServlet-based Deploymentを参照してください。

注意:

下位互換性のため、次の例に示すようにcom.sun.jersey.spi.container.servlet.ServletContainerへの参照を引き続き指定できます。ただし、推奨されるのは、かわりにJersey 2.xコンテナを参照するように、アプリケーションのデプロイメント・ディスクリプタを更新することです。

たとえば、次の<web-app>コンテンツで、com.sun.jersey.spi.container.servlet.ServletContainerをorg.glassfish.jersey.servlet.ServletContainerに置き換えます。

<web-app>
<servlet>
<display-name>My Jersey Application</display-name>
<servlet-name>MyJerseyApp</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>myPackage.myJerseyApplication</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>MyJerseyApp</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>

追加の詳細な構成オプションについては、『Jersey 2.21.1 User Guide』を参照してください。

2. 該当する場合、Jersey 1.xサーバーAPIを使用するすべてのアプリケーションを更新して、対応する標準JAX-RS 2.0またはJersey 2.x APIをかわりに使用します。Jersey 1.x (JAX-RS 1.1 RI) サーバー APIのサポートはこのリリースで削除されたため、それらを参照するアプリケーションは機能しなくなります。

3. 『Oracle WebLogic Server RESTful Webサービスの開発と保護』の「RESTful Webサービス・クライアントの開発」の説明に従って、javax.ws.rs.client APIを使用するようにクライアントを更新します。

注意:

Jersey 1.18クライアント・パッケージ(com.sun.jerseyパッケージとそのネスト・パッケージ、およびweblogic.jaxrs.api.clientパッケージなど)のサポートは、WebLogic Serverのこのリリースで非推奨になりましたが、後方互換性のために維持されています。ただし、多くのFusion Middlewareコンポーネント(Oracle Web Services Managerなど)は標準JAX-RS 2.0クライアントAPIに移行したため、Jersey 1.x JAX-RSクライアントAPIと互換性がありません。したがって、できるだけ早く、標準JAX-RS 2.0 APIを使用するようにRESTfulクライアント・アプリケーションを更新することをお薦めします。

Jersey 1.x JAX-RS RIクライアントAPIは、Jersey 2.x (JAX-RS 2.0 RI)と互換性がありません。

10.xのWebLogic Webサービス(JAX-WS)の12.2.xへのアップグレード

10.x WebLogic Webサービスを12.2.xへアップグレードするために必要な手順はありません。JAX-WSのWebサービスは、変更や再コンパイルを行わずにWebLogic Server 12.2.xへ再デプロイすることができます。

8.1のWebLogic WebサービスのWebLogic JAX-WSスタックへのアップグレード

8.1 WebLogic Webサービス・ランタイムは12.1.2リリースで削除されました。8.1 WebLogic Webサービスを使用している場合、8.1 WebLogic Webサービス・アプリケーションをJAX-WS (Java API for XML-Based Web Services)スタックにアップグレードする必要があります。8.1 WebLogic Webサービスは、SOAPペイロード内のXML要素をJavaオブジェクト内にマッピングする(その逆もまた同様)ため、Apache XMLBeansに依存します。XMLBeansは12.1.2以降ではサポートされていません。

注意:

12.2.1.2.0にアップグレードする前に、現在のWebLogic Serverリリースで8.1 WebサービスからJAX-WSへアップグレードします。12.2.1.2.0にアップグレードすると、8.1 Webサービスは機能しなくなります。

JAX-WSスタックにアップグレードすると、WebLogic Serverの最新のテクノロジと標準のサポートを利用できます。このパスには手作業によるアップグレード・プロセスが必要であり、作業レベルは既存の8.1 Webサービス・アプリケーションの性質によります。たとえば、アプリケーションでXMLBeansをほとんど使用しない場合、アップグレード・プロセスは比較的容易なものになります。XMLBeansの依存性が高い8.1 Webサービス・アプリケーションの場合、XMLBeansクラスのかわりにJAXBクラスを使用するにはサービス実装のビジネス・ロジックを変更する必要があります。JAX-WSは、RPCエンコード・スタイルをサポートしていません。RPCエンコード・スタイルの8.1 Web Serviceアプリケーションは、より相互運用性の高いリテラル・スタイルのサービス規定に対応することが必要になります。

WebLogic JAX-WSのランタイムは、JAX-WS 2.2仕様とWeb Services for Java EE v1.3 (JSR 109)仕様に基づいています。これらはWebサービスの定義にJava Web Service (JWS)ソース・ファイルで使用されるアノテーションを定義します。Antタスクが次に使用されてJWSがJavaクラスにコンパイルされ、すべての関連するアーティファクトが生成されます。Java Webサービス(JWS)は、JAX-WS Webサービスの中核部分です。

8.1 Webサービスのアップグレードには次の高レベル・タスクが含まれます。

- WebサービスEJBの2.xから3.xへのアップグレード。
JAX-WSはEJB 3.0および3.xをサポートします。EJB 2.xはサポートしません。

- 8.1 Webサービス・クラスをJAX-WS JWSファイルとして書き換えて、8.x固有の機能を類似したJAX-WS機能にマッピングします。
8.1 Webサービス機能とJAX-WS 12.1.x機能の間に1対1で対応するものはありません。

- WebサービスをビルドするAntビルド・スクリプトを、8.1のservicegenタスクではなく12.1.xのWebLogic WebサービスAntタスクjwscを呼び出すように更新します。

- JAX-WS clientgen Antタスクを使用して新規のJAX-WSクライアントを生成します。

JAX-WSのアップグレードに関する考慮事項

JAX-WSにアップグレードする前に、次の点を考慮してください。

- JAX-WS仕様はdocument-literalおよびrpc-literal形式をサポートしていますが、rpc-encodedはサポートしていません。

- JAX-WS仕様は、SOAP配列をサポートしていません。

JAX-WSの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』を参照してください。

WebLogic JAX-RPC WebサービスのWebLogic JAX-WSスタックへのアップグレード

WebLogic JAX-WSのランタイムは、JAX-WS (The Java API for XML-Based Web Services) 2.2仕様とWeb Services for Java EE v1.3 (JSR 109)仕様に基づいています。JAX-WS 2.0から、JavaプラットフォームおよびWebLogic ServerにおいてJAX-WSテクノロジがJAX-RPCに取って替わりました。WebLogicアプリケーションのJAX-RPC Webサービスは、JAX-WSにアップグレードする必要があります。

この項では、WebLogic JAX-WSスタックを使用するようにWebLogic JAX-RPC Webサービスをアップグレードする方法を説明します。

WebLogic Server JAX-RPC Webサービスのアップグレードには主に次のタスクが含まれます。

- WebサービスEJBの2.xから3.xへのアップグレード。
JAX-WSはEJB 3.0および3.xをサポートします。EJB 2.xはサポートしません。

- JWSをアップグレードし、JAX-RPC固有の機能を類似のJAX-WS機能にマップします。
WebLogic JAX-RPC Webサービス機能とJAX-WS 12.x機能の間に1対1で対応するものはありません。

- WebサービスをビルドするAntビルド・スクリプトを更新して、jws、wsdlcおよびclientgenタスクのtype属性の値を"JAXWS" (たとえば、type="JAXWS")に変更します。

- JAX-WS clientgen Antタスクを使用して新規のJAX-WSクライアントを生成します。

JAX-WSのアップグレードに関する考慮事項

JAX-WSにアップグレードする際、次の点を考慮してください。

- JAX-WS仕様はdocument-literalおよびrpc-literal形式をサポートしていますが、rpc-encodedはサポートしていません。

- SOAP配列はJAX-WSではサポートされません。

JAX-WSの詳細は、『Oracle WebLogic Server JAX-WS Webサービスの開発』を参照してください

5 再構成ウィザードの画面

この章では、アップグレード中にドメインを再構成する場合に、再構成ウィザードに表示される画面について説明します。

このファイルでは、Fusion Middleware再構成ウィザードのすべての画面について説明します。

この章には次の項が含まれます:

- ドメインの選択

- 再構成セットアップの進行状況

- ドメイン・モードおよびJDK

- データベース構成タイプ

- JDBCコンポーネント・スキーマ

- GridLink Oracle RACコンポーネント・スキーマ

- Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ

- JDBCコンポーネント・スキーマ・テスト

- JDBCデータ・ソース

- GridLink Oracle RACデータ・ソース

- Oracle RACマルチ・データ・ソース

- JDBCデータ・ソース・テスト

- データベース・スクリプト

- ノード・マネージャ

- 拡張構成

- 資格証明

- キーストア

- 管理対象サーバー

- クラスタ

- サーバーのクラスタへの割当て

- HTTPプロキシ・アプリケーション

- Coherenceクラスタ

- マシン

- ドメイン・フロントエンド・ホスト

- サーバーのマシンへの割当て

- システム・コンポーネント

- OHSサーバー

- ODIサーバー構成

- システム・コンポーネントのマシンへの割当

- デプロイメント・ターゲット指定

- サービス・ターゲット指定

- JMSファイル・ストア

- 構成のサマリー

- 再構成の進行状況

- 再構成に成功しました

ドメインの選択

アップグレードするドメインの場所を指定します。

この画面から、アップグレードするドメインの場所を指定します。

オプション

説明

ドメインの場所を入力してください

再構成するドメインへのフルパスを入力します(たとえば、C:\domains\mydomain)。「参照」ボタンを使用して、ドメイン・ディレクトリに移動することもできます。

関連トピック

再構成セットアップの進行状況

構成のサマリー

再構成の進行状況

再構成に成功しました

再構成セットアップの進行状況

この画面には、セットアップ・プロセスの進行状況が表示されます。プロセス中に、次の操作が行われます。

- WLSコア・インフラストラクチャ・ファイルが更新されます。

- WebLogicドメイン構成が読み取られます。

- Fusion Middleware製品を含む、インストール済製品の再構成テンプレートが自動的に適用されます。これにより、config.xml、config-groups.xml、security.xmlなどの様々なドメイン構成ファイルが更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

- ドメイン・アップグレードが検証されます。

「次へ」をクリックして、続行します。「ドメイン・モードおよびJDK」画面が表示されます。

ドメイン・モードを構成して、JDKを選択したら、その後の画面は、ドメインのコンテンツによって異なり、ドメインごとに異なります。

関連トピック

ドメインの選択

構成のサマリー

再構成の進行状況

再構成に成功しました

ドメイン・モードおよびJDK

ドメイン・モード

ドメイン・モードは再構成時に変更できません。元のドメインから継承されます。

JDK

「JDK」セクションを使用してドメインのJDKを選択します。ご使用のプラットフォームでサポートされるJDKのみを選択します。特定のプラットフォームでサポートされているJDKのリストは、Oracle Technology NetworkのOracle Fusion Middlewareでサポートされているシステム構成を参照してください。

オプション

説明

JDK

WebLogic Serverをインストールした際に使用されたJDKをリストします。デフォルトJDKは、Oracle HotSpot SDK versionですが、インストール時に別のJDKをインストールして使用した可能性があります。

その他のJDK

WebLogic Serverをインストールした際に使用したJDK以外のJDKを使用する場合にこのオプションを選択します。「参照」ボタンを使用して、JDKを格納しているディレクトリに移動します。

WebLogic Serverをインストールした際に使用したJDKを選択する場合は、再構成ウィザードによりそのJDKを起動するサーバー起動スクリプトが作成されます。WebLogic Serverをインストールした際に使用しなかったJDKを選択すると、再構成ウィザードで起動スクリプトが構成されません。起動スクリプトを手動で変更する必要があります。

起動スクリプトの詳細は、『Oracle WebLogic Serverのパフォーマンスのチューニング』を参照してください。

関連トピック

『Oracle WebLogic Server本番環境の保護』の「本番環境のセキュリティの確保」

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「本番モードへの変更」

『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「weblogic.Deployerによるアプリケーションおよびモジュールのデプロイ」

『Oracle WebLogic Serverセキュリティの管理』の「SSLの構成」

Oracle WebLogic Server管理コンソール・オンライン・ヘルプの「ログ・ファイルのローテーション」

Oracle WebLogic Serverのパフォーマンスのチューニング

データベース構成タイプ

この画面を使用して、後続のコンポーネント・スキーマ画面(「JDBCコンポーネント・スキーマ」、「GridLink Oracle RACコンポーネント・スキーマ」または「Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ」)のスキーマ・フィールドに移入するために使用するスキーマ情報を取得するためにデータベースに接続する情報を指定できます。この手順をスキップして、コンポーネント・スキーマ画面で各コンポーネント・スキーマを手動で構成するオプションもあります。

次のいずれかのオプションを選択します。

フィールド

説明

RCUデータ

データベースに接続して、ドメインに含まれるすべてのスキーマのスキーマ情報を取得する場合は、このオプションを選択します。このオプションを選択すると、この画面のフィールドがアクティブになります。Repository Creation Utility (RCU)のSTBコンポーネントに指定した接続情報を使用して、各フィールドに入力します。実行したら、「RCU構成の取得」をクリックして、スキーマ情報を取得します。

サービス表の詳細は、『Oracle Fusion Middlewareの管理』のサービス表の理解に関する項を参照してください。

スキーマ情報を正常に取得したら、「次へ」をクリックして、続行します。

注意: サポートされるJDBC接続は、RCUによってサポートされるOracleサービス・タイプのJDBC接続だけです。

手動で構成

このオプションを選択すると、各スキーマの設定を手動で構成する必要があります。コンポーネント・スキーマ画面のスキーマ表の一部のフィールドは、デフォルトのJava DB値で移入されることに注意してください。たとえば、すべてのスキーマに対してホスト名はdbhost.exampleに設定されます。

このオプションを選択したら、「次へ」をクリックして続行します。

RCUデータ・オプションの次のフィールドに情報を入力して、「RCU構成の取得」をクリックします。

詳細は、『Repository Creation Utilityによるスキーマの作成』のデータベース接続の詳細に関する項を参照してください。

フィールド

説明

ベンダー

データベースのベンダーを選択します。

ドライバ

データベースに構成されるJDBCドライバを選択します。リストには、選択したデータベースのベンダーの共通JDBCドライバが含まれます。

DBMS/サービス

データベースDBMS名を入力します。サービス・タイプ・ドライバを選択した場合はサービス名を入力します。

ホスト名

データベースをホストするサーバーの名前を入力します。

ポート

データベースのホストになるサーバーへの接続に使用するポート番号を入力します。

スキーマ所有者

スキーマ・パスワード

データベースのサービス表スキーマに接続するためのユーザー名とパスワードを入力します。これは、Repository Creation Utility (RCU)の「スキーマ・パスワード」画面でSTBコンポーネントに指定されたスキーマのユーザー名およびパスワードです。デフォルトのユーザー名はprefix_STBです(接頭辞がRCUで定義した接頭辞である場合)。指定するスキーマはドメインに対して一意である(他のドメインによって使用されていない)必要があります。

詳細は、『Repository Creation Utilityによるスキーマの作成』のスキーマ・パスワードに関する項を参照してください。

注意: 「RCU構成の取得」をクリックすると、RCUを使用して、スキーマの作成時に指定されたスキーマ・パスワードが取得されます。スキーマ・パスワードがRCUで設定されていた元のパスワードから変更された場合、「JDBCコンポーネント・スキーマ」、「GridLink Oracle RACコンポーネント・スキーマ」、または「Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ」画面で、新しいパスワードを「スキーマ・パスワード」フィールドまたは列に入力する必要があります。

関連トピック

JDBCコンポーネント・スキーマ

GridLink Oracle RACコンポーネント・スキーマ

Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ

『リポジトリ作成ユーティリティによるスキーマの作成』のデータベース接続の詳細に関する項

『リポジトリ作成ユーティリティによるスキーマの作成』のスキーマ・パスワードに関する項

『Oracle Fusion Middlewareの管理』のサービス表の理解に関する項

JDBCコンポーネント・スキーマ

Fusion Middlewareのいくつかのコンポーネントの場合、JDBCデータ・ソースは、コンポーネントのデータベース・スキーマの一部として定義される場合があります。これらのスキーマは、インストール時にリポジトリ作成ユーティリティ(RCU)によりロードされます。

再構成ウィザードを使用してコンポーネントのWebLogicドメインを再構成する場合は、データベース・ドライバ、スキーマ所有者、パスワードなど、JDBCコンポーネント・スキーマ設定を構成できます。

- 「データベース構成タイプ」画面で「RCU構成の取得」オプションを選択した場合は、スキーマ表がすでに適切に移入されており、「次」をクリックして続行できます。
ただし、スキーマ・パスワードがRCUで設定されていた元のパスワードから変更された場合は、手動で「スキーマ・パスワード」フィールドまたは列に新規パスワードを入力する必要があります。

注意:

11gリリースからのアップグレード時に、OPSSスキーマ・アップグレードに関する重要な情報について、『Oracle Platform Security Servicesによるアプリケーションの保護』の12.2.1.xへのセキュリティのアップグレードに関する項を参照してください。

- 「データベース構成タイプ」画面で「手動で構成」オプションを選択した場合は、この表にリストされているスキーマを手動で構成してから続行する必要があります。

ドメインを作成する製品に関連付けられるJDBCコンポーネント・スキーマは、画面の下半分にリスト表示されます。

スキーマの名前の横のチェック・ボックスを選択して、データ・ソース設定を指定するスキーマを選択します。

注意:

複数のコンポーネント・スキーマを選択する場合、一部のフィールドに、フィールドの現在の値が選択したコンポーネント・スキーマ間で異なることを示す「コンポーネント・スキーマ間で異なります」というテキストが表示される場合があります。それらのフィールドの値を変更すると、新しい値が選択した各コンポーネント・スキーマに一様に適用されます。

ベンダー、ドライバ、ホスト名、ポート番号など、コンポーネント・スキーマのパラメータのデフォルト値は、アプリケーションのテンプレートに指定した値によって異なります。

フィールド

説明

ベンダー

データベースのベンダーを選択します。

ドライバ

データベースへの接続に使用するJDBCドライバを選択します。リストには、選択したデータベースのベンダーの共通JDBCドライバが含まれます。

DBMS/サービス

データベースのDBMS名(サービス・タイプ・ドライバを選択している場合はサービス名)を入力します。

ホスト名

データベースをホストするサーバーの名前を入力します。

ポート

データベースのホストになるサーバーへの接続に使用するポート番号を入力します。

スキーマ所有者

データベースへの接続に使用するユーザー名を入力します。

スキーマ・パスワード

このユーザー名のパスワードを入力します。

指定した値は、選択したスキーマのスキーマ・リストの適切な列に表示されます。

1つ以上のスキーマをGridLink RACスキーマに変換するには、それらのスキーマのチェック・ボックスを選択し、「GridLinkへ変換」オプションを選択します。構成が終わったら、「次へ」をクリックします。「次へ」をクリックすると、「GridLink Oracle RACコンポーネント・スキーマ」画面が表示されます。

詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項を参照してください。

1つ以上のスキーマをOracle RACマルチ・データ・ソース・スキーマに変換するには、そのスキーマの名前の横のチェック・ボックスを選択し、RACマルチ・データ・ソースに変換オプションを選択します。構成が終わったら、「次へ」をクリックします。「次へ」をクリックすると、「Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ」画面が表示されます。

詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracle RACとWebLogic Serverの併用に関する項を参照してください。

関連トピック

データベース構成タイプ

JDBCコンポーネント・スキーマ

GridLink Oracle RACコンポーネント・スキーマ

Oracle WebLogic Server JDBCデータ・ソースの管理のJDBCスキーマに関する項

Oracle WebLogic Server JDBCデータ・ソースの管理のWebLogic ServerでのOracle RACの使用に関する項

Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項

『Oracle Platform Security Servicesによるアプリケーションの保護』の12.2.1.xへのセキュリティのアップグレードに関する項

GridLink Oracle RACコンポーネント・スキーマ

この画面は、WebLogicドメインに含まれるコンポーネント・スキーマをGridLink RACデータ・ソースとして構成するために使用します。GridLinkデータ・ソース は、Fast Application Notification (FAN)イベントにレスポンスするサービスを表す単一のデータ・ソースです。

GridLink RACデータ・ソースの詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項を参照してください。

ウィザードの「JDBCコンポーネント・スキーマ」画面でGridLink RACデータ・ソースとして構成するために選択したコンポーネント・スキーマが、画面の下半分にリストされます。

- 「データベース構成タイプ」画面でRCUデータ・オプションを選択した場合は、スキーマ表は適切に移入されており、「次へ」をクリックして続行できます。
ただし、スキーマ・パスワードがRCUで設定されていた元のパスワードから変更された場合は、手動で「スキーマ・パスワード」フィールドまたは列に新規パスワードを入力する必要があります。

注意:

11gリリースからのアップグレード時に、OPSSスキーマ・アップグレードに関する重要な情報について、『Oracle Platform Security Servicesによるアプリケーションの保護』の12.2.1.xへのセキュリティのアップグレードに関する項を参照してください。

- 「データベース構成タイプ」画面で「手動で構成」オプションを選択した場合は、この表にリストされているスキーマを手動で構成してから続行する必要があります。

画面の下半分に表示されるスキーマのリストでは、スキーマの名前の横にあるチェック・ボックスを選択して、GridLink RACデータ・ソースとして構成するスキーマを選択します。

注意:

複数のデータ・ソース・スキーマを選択した場合、一部のフィールドに、フィールドの現在の値が選択したスキーマ間で異なることを示す「コンポーネント・スキーマ間で異なります」というテキストが表示される場合があります。それらのフィールドの値を変更すると、新しい値が選択した各スキーマに一様に適用されます。

フィールド

説明

ドライバ

適切なドライバを選択します。次のドライバの一部または全部がリストで表示されます。

このリストに新しいエントリがないかアプリケーションで定期的に確認してください

- GridLink接続用Oracleドライバ(Thin)
GridLink Type 4非XAドライバです。

- GridLink接続用Oracleドライバ(Thin XA)
GridLink Type 4 XAドライバです。

サービス名

データベースのOracle RACサービス名を入力します。

スキーマ所有者

データベースへの接続に使用するユーザー名を入力します。

スキーマ・パスワード

このユーザー名のパスワードを入力します。

FANの有効化

選択すると、データ・ソースはFAN通知を登録して処理します。

SSLの有効化

選択すると、SSLが有効になるため、ウォレット・ファイル、ウォレット・パスワード、および1つ以上のOracle Notification Service (ONS)ホスト/ポートを指定する必要があります。

ウォレット・ファイル

SSLが有効の場合、ONS/SSLの資格証明を含むウォレット・ファイルへのフルパスを指定します。ウォレット・ファイルは、キーと証明書を保存するOracle資格証明ファイルです。

ウォレット・パスワード

ウォレット・ファイルのパスワードを指定します。このパスワードは、モジュール構成ファイルで暗号化されます。

サービス・リスナー

GridLinkデータベース・サービス・リスナーの名前を入力します。1つ以上のデータベース・インスタンスのサービス・リスナーを構成する必要があります。

ポート

データベース・サービス・リスナーのリスニング・ポートです。デフォルトでは1521に設定され、通常は変更する必要がありません。

プロトコル

このフィールドをクリックし、WebLogic Serverとデータベース・サービス・リスナーの間の通信に使用するプロトコルを選択します。

ONSホスト

Oracle Notification Service (ONS)ホスト名を指定します。SSLが有効の場合、1つ以上のONSホストとポートを指定する必要があります。

ポート

ONSホストで使用するリスニング・ポートを指定します。

指定した値は、選択したスキーマのスキーマ・リストの適切な列に表示されます。

追加行をサービス・リスナー表に追加するには、表内の任意の場所をクリックし、「追加」をクリックします。

追加行をONSホスト表に追加するには、表内の任意の場所をクリックし、「追加」をクリックします。

サービス・リスナー表から行を削除するには、表内の任意の場所をクリックし、「削除」をクリックします。

ONSホスト表から行を削除するには、表内の任意の場所をクリックし、「削除」をクリックします。

関連トピック

JDBCコンポーネント・スキーマ

Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ

Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項

『Oracle Platform Security Servicesによるアプリケーションの保護』の12.2.1.xへのセキュリティのアップグレードに関する項

Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ

この画面は、WebLogicドメインに含まれるコンポーネント・スキーマをOracle RACマルチ・データ・ソースとして構成するために使用します。

詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracle RACとWebLogic Serverの併用に関する項を参照してください。

ウィザードの「JDBCコンポーネント・スキーマ」画面でOracle RACマルチ・データ・ソースとして構成するために選択したコンポーネント・スキーマが、画面の下半分にリストされます。

- 「データベース構成タイプ」画面でRCUデータ・オプションを選択した場合は、スキーマ表は適切に移入されており、「次へ」をクリックして続行できます。
ただし、スキーマ・パスワードがRCUで設定されていた元のパスワードから変更された場合は、手動で「スキーマ・パスワード」フィールドまたは列に新規パスワードを入力する必要があります。

注意:

11gリリースからのアップグレード時に、OPSSスキーマ・アップグレードに関する重要な情報について、『Oracle Platform Security Servicesによるアプリケーションの保護』の12.2.1.xへのセキュリティのアップグレードに関する項を参照してください。

- 「データベース構成タイプ」画面で「手動で構成」オプションを選択した場合は、この表にリストされているスキーマを手動で構成してから続行する必要があります。

画面の下半分に表示されるスキーマのリストでは、スキーマの名前の横にあるチェック・ボックスを選択して、Oracle RACマルチ・データ・ソースとして構成するスキーマを選択します。

注意:

複数のデータ・ソース・スキーマを選択した場合、一部のフィールドに、フィールドの現在の値が選択したスキーマ間で異なることを示す「コンポーネント・スキーマ間で異なります」というテキストが表示される場合があります。それらのフィールドの値を変更すると、新しい値が選択した各スキーマに一様に適用されます。

フィールド

説明

ドライバ

データベースへの接続に使用するJDBCドライバを選択します。

サービス名

データベースのOracle RACサービス名を入力します。

ユーザー名

データベースへの接続に使用するユーザー名を入力します。

パスワード

指定したユーザー名のパスワードを入力します。

ホスト名

Oracle RACデータベース・インスタンスをホストしているサーバーの名前を入力します。

インスタンス名

各Oracleデータベース・インスタンスの名前を入力します。

ポート

データベースのホストになるサーバーへの接続に使用するポート番号を入力します。

注意:

少なくとも1つのデータベース・インスタンスのホスト名、インスタンス名およびポート番号を指定する必要があります。

現在選択しているスキーマの別データベース・インスタンスを追加するには、「ホストの追加」をクリックします。

データベース・インスタンスを削除するには、「ホスト名」表のその行の任意の場所をクリックして、「削除」をクリックします。

スキーマに指定した値は、選択したスキーマのスキーマ・リストの適切な列に表示されます。

関連トピック

JDBCコンポーネント・スキーマ

GridLink Oracle RACコンポーネント・スキーマ

Oracle WebLogic Server JDBCデータ・ソースの管理のWebLogic ServerでのOracle RACの使用に関する項

『Oracle Platform Security Servicesによるアプリケーションの保護』の12.2.1.xへのセキュリティのアップグレードに関する項

JDBCコンポーネント・スキーマ・テスト

前の画面で指定したデータ・ソースの構成をテストするためにこの画面を使用します。

テストするスキーマの名前の横のチェック・ボックスを選択して、「選択された接続のテスト」をクリックします。

ウィザードでは、スキーマを構成するとき指定したドライバ、ホスト、ポートや他の情報から構成されるURLへの接続を試行して、各スキーマの構成をテストします。

テストの結果は、「ステータス」列に表示されます。詳細は、「接続結果ログ」の項に表示されます。

関連トピック

JDBCコンポーネント・スキーマ

GridLink Oracle RACコンポーネント・スキーマ

Oracle RACマルチ・データ・ソース・コンポーネント・スキーマ

JDBCデータ・ソース

JDBCデータ・ソースにはデータベース接続のプールが含まれます。データベース接続は、データ・ソース・インスタンスの作成時(デプロイ時またはターゲット指定時)に作成されるか、サーバー起動時に作成されます。アプリケーションはJNDIツリーでデータ・ソースをルックアップしてから、接続をリクエストします。アプリケーションに接続する必要がなくなった場合は、接続がデータ・ソースの接続プールに戻されます。

この画面では、ドメイン・ソースで定義したJDBCデータ・ソースを構成します。

ドメインを作成する製品に関連付けられるJDBCデータ・ソースは、画面の下半分にリスト表示されます。

各データ・ソース名の横のチェック・ボックスを選択して、設定を指定するデータ・ソースを選択します。指定した値は、選択したデータ・ソースのデータ・ソース・リストの適切な列に表示されます。

注意:

複数のデータ・ソースを選択した場合、一部のフィールドに、フィールドの現在の値が選択したデータ・ソース間で異なることを示す「コンポーネント・スキーマ間で異なります」というテキストが表示される場合があります。それらのフィールドの値を変更すると、新しい値が選択した各データ・ソースに一様に適用されます。

ベンダー、ドライバ、ホスト名、およびポート番号などのデータ・ソース・パラメータのデフォルト値は、アプリケーション・テンプレートで指定した値によって異なります。

フィールド

説明

ベンダー

データベースのベンダーを選択します。

ドライバ

データベースへの接続に使用するJDBCドライバを選択します。リストには、選択したデータベースのベンダーの共通JDBCドライバが含まれます。

DBMS/サービス

DBMS SIDまたはサービス名を入力します。入力する値は、選択したドライバによって異なります。

Oracleドライバ名に、「インスタンス接続用」という言葉が含まれている場合、SIDを入力します。

Oracleドライバ名に、「サービス接続用」という言葉が含まれている場合、サービス名を入力します。

DataDirectドライバの構成の詳細は、DataDirectのドキュメントを参照してください。

ホスト名

データベースをホストするサーバーの名前を入力します。

ポート名

サーバーへの接続に使用するポート番号を入力します。

ユーザー名

データベースへの接続に使用するユーザー名を入力します。

パスワード

指定したユーザー名のパスワードを入力します。

1つ以上のデータ・ソースをGridLink Oracle RACデータ・ソースに変換するには、それらのスキーマのチェック・ボックスを選択し、「GridLinkへ変換」オプションを選択します。構成が終わったら、「次へ」をクリックします。「次へ」をクリックすると、「GridLink Oracle RACデータ・ソース」画面が表示されます。

詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項を参照してください。

1つ以上のデータ・ソースをOracle RACマルチ・データ・ソースに変換するには、必要なデータ・ソースの名前の横のチェック・ボックスを選択し、「RACマルチ・データ・ソースへ変換」オプションを選択します。「次へ」をクリックすると、「Oracle RACマルチ・データ・ソース」画面が表示されます。

詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracle RACとWebLogic Serverの併用に関する項を参照してください。

関連トピック

GridLink Oracle RACデータ・ソース

Oracle RACマルチ・データ・ソース

『Oracle WebLogic Server JDBCデータ・ソースの管理』の「JDBCデータ・ソースの構成」

Oracle WebLogic Server JDBCデータ・ソースの管理のWebLogic ServerでのOracle RACの使用に関する項

Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項

GridLink Oracle RACデータ・ソース

この画面は、WebLogicドメインに含まれるデータ・ソースをGridLink Oracle RACデータ・ソースとして構成するために使用します。GridLinkデータ・ソース は、Fast Application Notification (FAN)イベントにレスポンスするサービスを表す単一のデータ・ソースです。

詳細は、Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項を参照してください。

ウィザードの「JDBCデータ・ソース」画面でGridLink RACデータ・ソースとして構成するために選択したデータ・ソースが、画面の下半分にリストされます。

画面の下半分に表示されるデータ・ソースのリストでは、各データ・ソースの名前の横にあるチェック・ボックスを選択して、GridLink RACデータ・ソースとして構成するデータ・ソースを選択します。

注意:

複数のデータ・ソースを選択した場合、一部のフィールドに、フィールドの現在の値が選択したデータ・ソース間で異なることを示す「データ・ソース間で異なります」というテキストが表示される場合があります。それらのフィールドの値を変更すると、新しい値が選択した各データ・ソースに一様に適用されます。

フィールド

説明

ドライバ

次のドライバの一部または全部がリストで表示されます。

このリストに新しいエントリがないか定期的に確認してください

- GridLink接続用Oracleドライバ(Thin)
GridLink Type 4非XAドライバです。

- GridLink接続用Oracleドライバ(Thin XA)
GridLink Type 4 XAドライバです。

サービス名

データベースのOracle RACサービス名を入力します。

ユーザー名

データベースへの接続に使用するユーザー名を入力します。

パスワード

指定したユーザー名のパスワードを入力します。

FANの有効化

選択すると、データ・ソースはFAN通知を登録して処理します。

SSLの有効化

選択すると、SSLが有効になるため、ウォレット・ファイル、ウォレット・パスワード、および1つ以上のOracle Notification Service (ONS)ホスト/ポートを指定する必要があります。

ウォレット・ファイル

SSLが有効の場合、ONS/SSLの資格証明を含むウォレット・ファイルへのフルパスを指定します。ウォレット・ファイルは、キーと証明書を保存するOracle資格証明ファイルです。

ウォレット・パスワード

ウォレット・ファイルのパスワードを指定します。このパスワードは、モジュール構成ファイルで暗号化されます。

サービス・リスナー

GridLinkデータベース・サービス・リスナーの名前を入力します。1つ以上のデータベース・インスタンスのサービス・リスナーを構成する必要があります。

ポート

データベース・サービス・リスナーのリスニング・ポートです。デフォルトでは1521に設定され、通常は変更する必要がありません。

プロトコル

このフィールドをクリックし、WebLogic Serverとデータベース・サービス・リスナーの間の通信に使用するプロトコルを選択します。

ONSホスト

Oracle Notification Service (ONS)ホスト名を指定します。SSLが有効の場合、1つ以上のONSホストとポートを指定する必要があります。

ポート

ONSホストで使用するリスニング・ポートを指定します。

指定した値は、選択したスキーマのデータ・ソース・リストの適切な列に表示されます。

追加行をサービス・リスナー表に追加するには、表内の任意の場所をクリックし、「追加」をクリックします。

追加行をONSホスト表に追加するには、表内の任意の場所をクリックし、「追加」をクリックします。

サービス・リスナー表から行を削除するには、表内の任意の場所をクリックし、「削除」をクリックします。

ONSホスト表から行を削除するには、表内の任意の場所をクリックし、「削除」をクリックします。

関連トピック

JDBCデータ・ソース

Oracle RACマルチ・データ・ソース

Oracle WebLogic Server JDBCデータ・ソースの管理のActiveLink GridLinkデータ・ソースの使用に関する項

Oracle RACマルチ・データ・ソース

ドメインに含まれるデータ・ソースをOracle RACデータ・ソースとして構成するためにこの画面を使用します。

「JDBCデータ・ソース」画面でOracle RACデータ・ソースとして構成するために選択したデータ・ソースのリストが画面の下半分に表示されます。

各データ・ソース名の横のチェック・ボックスを選択して、設定を指定するデータ・ソースを選択します。

Oracle RACデータ・ソースの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のOracle RACとWebLogic Serverの併用に関する項を参照してください。

注意:

複数のデータ・ソースを選択した場合、一部のフィールドに、フィールドの現在の値が選択したデータ・ソース間で異なることを示す「データ・ソース間で異なります」というテキストが表示される場合があります。それらのフィールドの値を変更すると、新しい値が選択した各データ・ソースに一様に適用されます。

フィールド/列

説明

ドライバ

データベースへの接続に使用するJDBCドライバを選択します。

サービス名

Oracle RACデータベースのサービス名を入力します。

ユーザー名

データベースへの接続に使用するユーザー名を入力します。

パスワード

指定したユーザー・アカウントのパスワードを入力します。

ホスト名

Oracle RACデータベース・インスタンスをホストしているサーバーの名前を入力します。

インスタンス名

各Oracleデータベース・インスタンスの名前を入力します。

ポート

データベースのホストになるサーバーへの接続に使用するポート番号を入力します。

新規データベース・インスタンスを追加するには、「追加」をクリックして、ホスト名、インスタンス名、およびポート番号を指定します。

関連トピック

JDBCデータ・ソース

GridLink Oracle RACデータ・ソース

Oracle WebLogic Server JDBCデータ・ソースの管理のWebLogic ServerでのOracle RACの使用に関する項

JDBCデータ・ソース・テスト

この画面を使用して、「JDBCデータ・ソース」画面および「Oracle RACマルチ・データ・ソース」画面で構成したデータ・ソース接続をテストします。

注意:

データベース接続をテストするには、接続するデータベースが起動している必要があります。

接続をテストしない場合は、データ・ソースを選択しません。「次へ」をクリックして、続行します。

テストする各データ・ソースのチェック・ボックスを選択して、「接続のテスト」をクリックします。

ウィザードでは、各データ・ソースを構成するとき指定したドライバ、ホスト、ポート、および他の情報から構成されるURLへの接続を試行して、選択した各データ・ソースの構成をテストします。

テストの結果は、「ステータス」列に表示されます。詳細は、「接続結果ログ」の項に表示されます。

関連トピック

JDBCデータ・ソース

GridLink Oracle RACデータ・ソース

Oracle RACマルチ・データ・ソース

データベース・スクリプト

ドメイン・テンプレートには、データベース・タイプ別に分類されたSQLファイルのセットが含まれている場合があります。ドメイン・テンプレートにSQLファイルが存在する場合、WebLogicドメインを作成するときに、「データベース・スクリプト」画面でそれらを実行できます。既存のSQLまたはデータベース・ロード・ファイルを使用して、WebLogicドメインに定義されたすべてのデータ・ソースのデータベースのコンテンツが設定されます。

1. 「JDBCデータ・ソース」項で、スクリプトを実行するデータ・ソースを選択します。実行できるスクリプトが「SQLファイル」項に表示されます。

2. 「DBバージョン」ドロップダウン・リストからデータベースのバージョンを選択します。

3. 「スクリプトの実行」をクリックします。
選択したデータ・ソースの「SQLファイル」項に表示されたすべてのスクリプトが実行され、結果は「結果」項に表示されます。テスト出力をログ・ファイルにキャプチャするには、「ロギングの有効化」チェック・ボックスを選択して、「ログ・ファイル」フィールドにログ・ファイルのフルパスを指定します。

4. SQLスクリプトを実行する各データ・ソースに対して、ステップ1から3を繰り返します。

5. すべてのスクリプトを実行したら、「次へ」をクリックします。

関連トピック

『ドメイン・テンプレート・リファレンス』のテンプレートに含まれるファイルに関する項。

ノード・マネージャ

この画面は、再構成するドメインで、ホストごとのノード・マネージャが使用されている場合にのみ表示されます。この画面を使用して、再構成するドメインに使用するノード・マネージャ構成を選択します。。結果として生成される構成は、「ノード・マネージャ・タイプ」および「ノード・マネージャ構成」で選択したオプションの組合せに応じて異なります。

ドメインごとおよびホストごとのノード・マネージャ構成の詳細は、『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項を参照してください。

注意:

ドメインをアップグレードしてホストごとのノード・マネージャ構成からドメインごとのノード・マネージャ構成に変更する際に、カスタム・スクリプトを使用してWebLogic Server環境を起動および停止する場合、手動でスクリプトを更新してノード・マネージャ・ホームの場所を新しいドメインベースの場所に変更する必要があります。

オプション/フィールド

説明

ノード・マネージャ・タイプ

次のいずれかのノード・マネージャ・タイプを選択します。

ドメインごとのデフォルトの場所

このオプションを選択すると、ノード・マネージャ・ホームが<domain_name>/nodemanagerに再定義され、ノード・マネージャ・ホームを編集できなくなります。

ドメインごとのカスタムの場所

このオプションは、このドメインの特定の場所に、ドメインごとのノード・マネージャ構成ファイルを作成する場合に選択します。「ノード・マネージャ・ホーム」フィールドでディレクトリを指定するか、「参照」をクリックしてその場所に移動します。指定するディレクトリは空である必要があります。このディレクトリに、nodemanager.propertiesおよびnodemanager.domainsファイルが作成されます。

ノード・マネージャ・ホーム

ドメインごとのカスタムの場所オプションを選択した場合は、「参照」をクリックして、ドメインごとのノード・マネージャ構成の格納に使用するディレクトリの場所に移動します。

手動ノード・マネージャ・セットアップ

このオプションを選択した場合は、ドメインのノード・マネージャ構成の作成がスキップされ、残りのフィールドはすべて変更できなくなるため、ドメインでノード・マネージャを使用する場合はノード・マネージャ構成の実行の説明に従って、ノード・マネージャを手動で構成する必要があります。再構成されたドメインでは、ホストごとのノード・マネージャ構成が引き続き使用されます。

既存のドメインがノード・マネージャを使用するように構成されておらず、再構成されたドメインでノード・マネージャを使用しない場合も、このオプションを選択する必要があります。

ノード・マネージャの構成の詳細は、Oracle WebLogic Serverノード・マネージャの管理を参照してください。

ノード・マネージャ構成

次の2つのオプションから1つを選択します。「手動ノード・マネージャ・セットアップ」を選択した場合は、次のフィールドを使用できません。

新規構成の作成

nodemanager.propertiesのデフォルトの設定を使用して、再構成されたドメインに、ドメインごとのノード・マネージャ構成が自動的に作成されます。ドメインが正常に再構成された後に、必要に応じて、nodemanager.propertiesを変更できます。

既存の構成を移行

すでに存在するホストごとのノード・マネージャ構成が、再構成されたドメインのドメインごとの構成に移行されます。これには、ListenAddress、ListenPort、StartScriptName、JavaHomeおよびLogFileの環境固有の設定は含まれません。

ノード・マネージャ・ホーム

「既存の構成を移行」オプションを選択した場合は、再構成したドメインの移行先にするノード・マネージャのホーム・ディレクトリを入力するか、参照してください。

Oracle推奨デフォルトの適用

このチェック・ボックスは、「既存の構成を移行」オプションを選択した場合に、nodemanager.propertiesファイルに指定されているOracle推奨のデフォルトを使用するときに選択します。移行されるnodemanager.propertiesファイルの設定を引き続き使用する場合は、このチェック・ボックスの選択を解除してください。

Oracleが推奨するデフォルト状態のプロパティは次のとおりです。

LogLimit=0
AuthenticationEnabled=true
LogLevel=INFO
DomainsFileEnabled=true
NativeVersionEnabled=true
LogToStderr=true
SecureListener=true
LogCount=1
StopScriptEnabled=false
QuitEnabled=false
LogAppend=true
StateCheckInterval=500
CrashRecoveryEnabled=false
StartScriptEnabled=true
LogFormatter=weblogic.nodemanager.server.LogFormatter
ListenBacklog=50

ノード・マネージャ資格証明

次のフィールドに適切なノード・マネージャ資格証明を指定します。

ユーザー名

パスワード

パスワードの確認

再構成されたドメインで、ノード・マネージャの起動に使用するユーザー名とパスワード。

関連トピック

『Oracle WebLogic Serverノード・マネージャの管理』のノード・マネージャのデフォルト構成に関する項

『Oracle WebLogic Serverノード・マネージャの管理』の「ノード・マネージャの概要」

拡張構成

詳細構成を行うすべてのカテゴリ(存在する場合)を選択します。選択したカテゴリごとに、詳細構成を行うことができる適切な構成画面が表示されます。この画面で項目も選択しない場合、次に「構成のサマリー」画面が表示されます。

注意:

この画面にリストされたカテゴリは、ドメインのために選択したテンプレートで定義されたリソースによって異なります。

オプション

説明

ノード・マネージャ

このオプションは、ホストごとのノード・マネージャ構成を使用中のドメインを再構成する場合にのみ使用できます。ドメインごとのノード・マネージャに切り替えることも、既存のホストごとのノード・マネージャの使用を続行することも可能です。

注意: このオプションが使用可能な場合に選択しないときは、「ノード・マネージャ構成の実行」の説明に従って、ノード・マネージャを手動で構成する必要があります。

ノード・マネージャを参照してください。

管理対象サーバー、クラスタおよびCoherence

次のタスクを実行するには、このオプションを選択します:

- ドメインに管理対象サーバー、クラスタ、またはマシンを追加

- 既存の管理対象サーバー、クラスタまたはマシンを削除

- 既存のクラスタに管理対象サーバーを追加

- 既存の管理対象サーバー、クラスタまたはマシンの設定を変更

- デフォルトCoherenceクラスタの構成

管理対象サーバーからサーバーのマシンへの割当までを参照してください。

ドメイン・フロントエンド・ホストのキャプチャ

ドメイン全体のフロントエンド・ホストのHTTP URLおよびHTTPS URLと、HTTPまたはHTTPSのどちらがデフォルトかを構成します。このオプションは、選択したテンプレートの少なくとも1つにConfigMappingが定義されている場合にのみ使用できます。

「ドメイン・フロントエンド・ホスト」を参照してください

デプロイメントとサービス

アプリケーション・デプロイメントおよびサービスのサーバーとクラスタへのターゲット指定方法をカスタマイズするために、このオプションを選択します。

デプロイメント・ターゲット指定およびサービス・ターゲット指定を参照してください。

JMSファイル・ストア

このオプションを選択して、JMSファイル・ストアの設定を変更します。各ファイル・ストアの名前、ディレクトリおよび同期書込みポリシーを変更できます。

「JMSファイル・ストア」を参照してください

関連トピック

管理対象サーバー

クラスタ

サーバーのクラスタへの割当て

HTTPプロキシ・アプリケーション

マシン

サーバーのマシンへの割当て

デプロイメント・ターゲット指定

サービス・ターゲット指定

JMSファイル・ストア

資格証明

この画面を使用して、ドメイン内の各キーの資格証明を提供します。ドメインで以前に定義された「その他」資格証明は表にすでに含まれています。

資格証明の詳細は、『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ、ポリシー、資格証明、キー、証明書および監査の理解に関する項を参照してください。

列

説明

キー名

この列には、ドメイン内の各キーの名前が表示されます。

ユーザー名

各行に、各キーに使用するユーザー名を入力します。

パスワード

各行に、各キーに使用するパスワードを入力します。

ストア名

この列には、各キーに関連付けられている資格証明ストアが表示されます。

関連トピック

キーストア

『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ、ポリシー、資格証明、キー、証明書および監査の理解に関する項

キーストア

この画面では、次のものを指定します。

- 各キーストアに対して信頼できる証明書へのパス

- 各キーストアの秘密鍵へのパス、秘密鍵のパスワード、および秘密鍵のアイデンティティ証明書へのパス。

「信頼できる証明書」、「秘密鍵」または「アイデンティティ証明書」フィールドをクリックすると、フィールドの右側に参照アイコンが表示されます。このアイコンをクリックして、適切なファイルを参照します。

オプション/フィールド

説明

ストア・キー名

ドロップダウン・リストから、構成するストア/キーを選択します。

「信頼できる証明書」表

「信頼できる証明書」表には、次の2つの列が含まれます。

別名

製品テンプレートで定義される信頼できる証明書の別名を表示する読取り専用フィールド。

信頼できる証明書

選択したストア/キーに使用する信頼できる証明書のフルパスおよびファイル名を入力するか、行の右側にあるアイコンをクリックして、信頼できる証明書ファイルに移動して選択します。

「秘密鍵」表

「秘密鍵」表には、次の4つの列が含まれます。

別名

製品テンプレートで定義される秘密鍵の別名を表示する読取り専用フィールド。

秘密鍵

選択したストア/キーに使用する秘密鍵ファイルのフルパスおよびファイル名を入力するか、フィールドの右側にあるアイコンをクリックして、秘密鍵ファイルに移動して選択します。

パスワード

秘密鍵に使用するパスワードを入力します。

アイデンティティ証明書

秘密鍵に関連付けるアイデンティティ証明書のフルパスおよびファイル名を入力するか、フィールドの右側にあるアイコンをクリックして、アイデンティティ証明書ファイルに移動して選択します。

関連トピック

資格証明

『Oracle Platform Security Servicesによるアプリケーションの保護』のアイデンティティ、ポリシー、資格証明、キー、証明書および監査の理解に関する項

Oracle WebLogic Serverのセキュリティの管理のアイデンティティおよび信頼の構成

管理対象サーバー

この画面では、管理対象サーバーを追加、削除またはクローンの作成ができます。また、既存の管理対象サーバーの設定も変更できます。

注意:

packおよびunpackコマンドを使用してリモート・マシン上に管理対象サーバーを作成できます。

詳細は、『PackおよびUnpackコマンドによるテンプレートとドメインの作成』のリモート・マシンにおける管理対象サーバーの作成と起動に関する項を参照してください。

列

説明

サーバー名

有効なサーバー名は、文字列(文字および数字)です。名前は、ドメイン内で一意である必要があります。

リスニング・アドレス

ドロップ・ダウン・リストから、リスン・アドレスの値を選択する。

リスニング・ポート

通常の非セキュア・リクエスト(HTTPやT3などのプロトコル経由)で使用するリスン・ポートの有効な値を入力します。リスニング・ポートの有効な範囲は、1から65535までです。

SSLの有効化

SSLリスン・ポートを有効にする場合は、このチェック・ボックスをチェックする。デフォルトで、すべての新しいサーバーではSSLは無効になっています。

SSLリスニング・ポート

サーバーに「SSL有効」チェック・ボックスを選択した場合のみこのフィールドが有効になります。

(HTTPSおよびT3Sのようなプロトコル経由の)セキュア・リクエストのために使用する有効な値を入力します。リスニング・ポートの有効な範囲は、1から65535までです。

サーバー・グループ

ドメインを作成または更新するために選択したテンプレートにユーザー拡張可能なサーバー・グループ定義が含まれている場合は、「サーバー・グループ」列が表示されます。各管理対象サーバーに対して、サーバーに割り当てる各サーバー・グループのチェック・ボックスを選択します。ユーザー選択可能と定義されるサーバー・グループのみがリストに表示されます。通常、Fusion Middleware製品サーバーのデフォルトを受け入れる必要があります。

注意: 管理対象サーバーのクローンを作成する場合、サーバー・グループの割当ては元のサーバーと同じものになります。追加のFusion Middleware製品サーバーを作成するには、クローンの作成をお薦めします。

選択したサーバー・グループにより、指定された管理対象サーバーにマップされるアプリケーションとサービスが決まります。たとえば、サーバーにOVAB_MAN_SVRグループを選択する場合、ドメインのconfig-groups.xmlファイルのそのサーバー・グループにマップされるすべてのアプリケーションとサービスがサーバーに自動的にサーバーにターゲット指定されます。

サーバー・グループの詳細は、『ドメイン・テンプレート・リファレンス』のconfig-groups.xmlおよびstartup-plan.xmlに関する項を参照してください。

サーバーを追加するには、「追加」をクリックして、新しいサーバーの設定を構成します。新しいサーバーのデフォルト名は、new_ManagedServer_nです。nの初期値は1であり、追加する新しいサーバーごとに増分します。

サーバーのクローンを作成するには、クローンを作成するサーバーの行をクリックして、「クローン」をクリックします。新しいクローンのデフォルト名は、original_server_name_clonenです。nの初期値は1であり、そのサーバーからクローンを作成する新しいサーバーごとに増分します。既存の管理対象サーバーのクローンである管理対象サーバーを作成する場合、ソース・サーバーにターゲット指定されるすべてのアプリケーションとライブラリもクローンにデプロイされます。また、クローン・サーバーはソース・サーバーが割り当てられている(存在する場合)すべてのサーバー・グループにも割り当てられます。また、ソース・サーバーにターゲット指定される次のサービスがクローンに自動的にターゲット指定されます。

- connectionFactory

- queueConnectionFactory

- topicConnection

- Queue

- Topic

- activationSpec

- Data source

- URLProvider

- workManager

- busMember

- customService

- resourceAdapter

サーバーを削除するには、サーバーを選択して、「削除」をクリックします。一度に1つのサーバーのみ削除できます。

関連トピック

『PackおよびUnpackコマンドによるテンプレートとドメインの作成』の「リモート・マシンでの管理対象サーバーの作成および起動」

『Oracle WebLogic Serverの理解』の管理対象サーバーと管理対象クラスタに関する項

クラスタ

クラスタはWebLogic Serverインスタンスのグループであり、それらが連携して動作することにより、アプリケーションに拡張性と高可用性を提供します。クラスタを作成すると、管理対象サーバーをグループ化し、アプリケーションおよびリソースをホストするシングル・ホストとして動作するようにできます。

この画面を使用して、クラスタを追加または削除します。また、既存のクラスタの設定も変更できます。

列

説明

クラスタ名

有効な名前を入力します。クラスタの名前は、WebLogicドメイン内のすべてのコンポーネント名の間で一意である必要があります。

クラスタ・アドレス

クラスタ内の管理対象サーバーを識別するためのアドレスを入力します。クラスタ・アドレスには、次のいずれかを指定できます。

- IPアドレスまたはDNS名とポートのカンマ区切りリスト(例: dns_name:port、dns_name:port)

- 複数のIPアドレスにマップされるDNS名

- すべての管理対象サーバーのリスニング・アドレスが、一意のポート番号を持つ同一アドレスをリスニングしている場合は、localhost、DNS名、またはIPアドレス

フロントエンド・ホスト

フロントエンドHTTPポート

フロントエンドHTTPSポート

クラスタのフロントエンド・ホストのIPアドレス、プレーン・ポート(HTTP)およびセキュア・ポート(HTTPS)を入力します。これはハードウェア・ロード・バランサ、Oracle HTTP Server (OHS)インスタンス、またはWebLogic Server構成ですでに定義済のフロントエンド・ホストである可能性があります。

「ドメイン・フロントエンド・ホスト」画面で指定されたドメイン全体のフロントエンド・ホスト値がクラスタに対して使用される場合は、これらのフィールドを空のままにできます。クラスタに対してこれらの値を入力する場合、「ドメイン・フロントエンド・ホスト」画面で指定された値(ある場合)はオーバーライドされます。

クラスタを削除するには、サーバーを選択して「削除」をクリックします。クラスタを削除すると、そのクラスタに割り当てられたサーバーは削除されません。サーバーは、そのクラスタから削除されるのみで、他のクラスタに追加できます。一度に1つのクラスタのみを削除できます。

クラスタを追加するには、「追加」をクリックして、新しいサーバーの設定を構成します。新しいクラスタのデフォルト名は、new_Cluster_nです。nの初期値は1であり、追加する新しいクラスタごとに増分します。デフォルト名を変更するには、「名前」列に適切な名前を入力します。

クラスタの詳細は、『Oracle WebLogic Serverクラスタの管理』のWebLogicクラスタの設定に関する項を参照してください。

関連トピック

サーバーのクラスタへの割当て

HTTPプロキシ・アプリケーション

『Oracle WebLogic Serverクラスタの管理』の「WebLogicクラスタの設定」

『Oracle WebLogic Serverの理解』の管理対象サーバーと管理対象クラスタに関する項

サーバーのクラスタへの割当て

この画面を使用して、クラスタに管理対象サーバーを割り当てます。

注意:

「サーバー」リスト・ボックスには管理対象サーバーのみが表示されます。管理サーバーは、クラスタに割り当てることができないので、リストに表示されません。

クラスタに1つ以上のサーバーを割り当てるには:

1. 「クラスタ」リスト・ボックスで、管理対象サーバーを割り当てるクラスタを選択します。

2. 次のいずれかの方法で、選択したクラスタに管理対象サーバーを割り当てます。

- 「サーバー」リスト・ボックスで、管理対象サーバーの名前をダブルクリックします。

- 管理対象サーバーを選択し、右矢印をクリックします。

- 「Shift」を押しながらクリックして複数の管理対象サーバーを選択し、右矢印をクリックします。

管理対象サーバーの名前が「サーバー」リスト・ボックスから削除され、「クラスタ」リスト・ボックスのターゲット・クラスタ名の下に追加されます。

3. クラスタに割り当てる管理対象サーバーごとにステップ1と2を繰り返します。

4. クラスタの割当てを確認します。
必要に応じて、次のいずれかの方法でクラスタから管理対象サーバーを削除できます。

- 「クラスタ」リスト・ボックスで管理対象サーバーの名前をダブルクリックします。

- 管理対象サーバーを選択し、左矢印をクリックします。

管理対象サーバーの名前が「クラスタ」リスト・ボックスから削除され、「サーバー」リスト・ボックスにリストアされます。

関連トピック

管理対象サーバー

クラスタ

HTTPプロキシ・アプリケーション

HTTPプロキシ・アプリケーションは、HTTPリクエストの中継システムとして機能します。

この画面を使用して、各クラスタのHTTPプロキシ・アプリケーションを作成し、プロキシ・アプリケーションをデプロイする必要がある管理対象サーバーを指定します。

次の両方の文がtrueの場合のみ、この画面が表示されます。

- 少なくとも1つの管理対象サーバーがクラスタに割り当てられています。

- 少なくとも1つの管理対象サーバーがどのクラスタにも割り当てられていません。

列

説明

クラスタ名

この列には、ドメイン内の各クラスタがリストされます。

HTTPプロキシの作成

HTTPプロキシ・アプリケーションをデプロイするクラスタごとにこのチェック・ボックスを選択します。

プロキシ・サーバー

このドロップダウン・リストには、クラスタに割り当てられていないすべての管理対象サーバーが含まれます。プロキシ・アプリケーションをデプロイする管理対象サーバーを選択します。

OracleProxy4_clustername_servernameという名前のプロキシ・アプリケーションが作成され、管理対象サーバーにデプロイされます。

関連トピック

管理対象サーバー

サーバーのクラスタへの割当て

Coherenceクラスタ

この画面は、WebLogic ServerインストールにCoherenceが含まれた場合にのみ表示されます。自動的にドメインに追加されるCoherenceクラスタがリストされます。

列

説明

名前

デフォルトのクラスタ名を受け入れるか、またはCoherenceクラスタの新しい名前を入力します。

ドメインの更新時には、WLSTまたはWebLogic Server管理コンソールを介してCoherenceクラスタをドメインに追加した場合、これらのクラスタもここにリストされます。

Coherenceリスニング・ポート

Coherenceクラスタ・リスニング・ポートとして使用するポート番号を入力します。詳細

Coherenceクラスタ・リスニング・ポートの詳細は、『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタ・メンバーのユニキャスト設定の構成に関する項を参照してください。

ドメインにCoherenceクラスタを含む場合:

- 現在の再構成ウィザード・セッションまたは今後の構成ウィザード・セッション時にドメインで構成するすべての管理対象サーバーおよびクラスタは、自動的にCoherenceクラスタに追加されます。

- 再構成ウィザードを実行する前にドメインに存在しているサーバーおよびクラスタは、Coherenceクラスタに自動的に割り当てられます。

- ドメインを再構成する際に、ドメインに管理サーバーのみが含まれていて、管理対象サーバーが含まれていない場合、管理サーバーはCoherenceクラスタに自動的に割り当てられます。ただし、少なくとも1つの管理対象サーバーがドメインに存在する場合、管理サーバーはCoherenceクラスタに割り当てられません。

- ドメインに複数のCoherenceクラスタが存在する場合(WLSTまたはWebLogic Server管理コンソールを介して2つ目のCoherenceクラスタを追加した場合など)、後で再構成ウィザードによりドメインに追加するサーバーまたはクラスタは、「Coherenceクラスタ」画面にリストされている1つ目のCoherenceクラスタに自動的に割り当てられます。

関連トピック

管理対象サーバー

クラスタ

サーバーのクラスタへの割当て

『Oracle WebLogic Serverクラスタの管理』のCoherenceクラスタ・メンバーのユニキャスト設定の構成に関する項

マシン

WebLogicドメインでは、マシン定義がハードウェアの物理単位を識別し、ホストするWebLogic Serverのインスタンスまたはシステム・コンポーネント(OHSサーバーなど)に関連付けられています。

この画面を使用して、マシンを追加または削除します。また、既存のマシンの設定を変更することもできます。各マシンには、次の構成設定があります。

Windowsの場合「マシン」タブ、またはUNIXの場合、「Unixマシン」タブを選択します。

列

説明

名前

有効なマシン名を入力します。マシンの名前は、WebLogicドメイン内にマシンを識別するために使用されます。マシンのネットワーク名と一致している必要はありません。名前は、ドメイン内のすべてのコンポーネント名の間で一意である必要があります。

ノード・マネージャのリスニング・アドレス

ドロップ・ダウン・リストから、Node Managerで接続要求のリスンに使用するリスン・アドレスの値を選択する。デフォルトでは、ドロップダウン・リストにローカル・システムに定義済のIPアドレスおよびlocalhostが表示されます。デフォルト値は、localhostです。

管理サーバーをホストするマシンのIPアドレスを指定し、WebLogic Serverノード・マネージャにアクセスする必要がある場合は、ホスト名の検証を無効にする必要があります。

詳細は、『Oracle WebLogic Serverのセキュリティの管理』のホスト名検証の使用に関する項を参照してください。

ノード・マネージャのリスニング・ポート

Node Managerで接続要求のリスンに使用するリスン・ポートの有効な値を入力する。

ノード・マネージャのリスニング・ポートの有効な範囲は1から65535です。デフォルト値は、5556です。

[Post bind GID enabled]

(UNIXマシンの場合のみ)このマシンで稼働するサーバーが、すべての権限のある起動アクションの実行後に、UNIXグループID (GID)にバインドできるようにするには、このチェック・ボックスを選択します。デフォルトでは、このチェック・ボックスは選択されていません。

バインド後のGID

(UNIXマシンの場合のみ)このマシンで稼働するサーバーが、すべての権限起動アクションの実行後に動作する際のUNIXグループID (GID)を入力します。そうしない場合、サーバーは引き続き起動時のグループで動作します。この設定を有効にするには、「バインド後のGIDの有効化」チェック・ボックスを選択する必要があります。

[Post bind UID enabled]

(UNIXマシンの場合のみ)このマシンで稼働するサーバーが、すべての権限のある起動アクションの実行後に、UNIXユーザーID (UID)にバインドできるようにするには、このチェック・ボックスを選択します。デフォルトでは、このチェック・ボックスは選択されていません。

バインド後のUID

(UNIXマシンの場合のみ)このマシンで稼働するサーバーが、すべての権限起動アクションの実行後に動作する際のUNIXユーザーID (UID)を入力します。そうしない場合、サーバーは引き続き起動時のアカウントで動作します。この設定を有効にするには、「バインド後のUIDの有効化」チェック・ボックスを選択する必要があります。

次の場合には、マシン定義を作成する必要があります。

- リモート・サーバーを起動するために管理サーバーがノード・マネージャ・アプリケーションと連携してマシン定義を使用する場合。

- WebLogic ServerまたはOHSなどの他のシステム・コンポーネントが、クラスタ内で特定のタスク(HTTPセッション・レプリケーションなど)の処理に最も適したサーバーを特定する際に、構成したマシン名を使用します。これらのタスクは特定されたサーバーに委任されます。

注意:

ノード・マネージャ・プロセスを実行する製品インストールごとにマシンを構成する必要があります。マシン構成には、リスニング・アドレスおよびポート番号パラメータの値などが定義されている必要があります。

「追加」をクリックして、新しいマシンを追加します。新しいマシンのデフォルト名は、new_[Unix]Machine_nです。nの初期値は1であり、追加する新しいマシンごとに増分します。

既存のマシンを削除するには、「削除」をクリックします。

関連トピック

サーバーのマシンへの割当て

Oracle WebLogic Serverのセキュリティの管理のホスト名の検証の使用

ドメイン・フロントエンド・ホスト

この画面は、「拡張構成」画面で「ドメイン・フロントエンド・ホストのキャプチャ」オプションを選択した場合にのみ表示されます。

新規ドメインの作成時は、この画面を使用してフロントエンド・ホストを有効化し、フロントエンド・ホストのプレーンおよびセキュアの両方のURLを指定して、デフォルトのフロントエンド・ホストURLを選択します。ドメインで構成されたOHSインスタンスが1つ以上ある場合、「プレーン」および「SSL」フィールドは、ドメイン内の最初のOHSインスタンスから適切な値が自動的に移入されます。それ以外の場合は、値を構成する必要があります。その設定は、サービス表に保存されます。

ドメインを更新する際、値は、サービス表の値(ある場合)に基づいて移入されます。サービス表の値がnullで構成されたOHSインスタンスが存在しない場合、「ドメイン・フロントエンド・ホストの構成」チェック・ボックスはデフォルトで選択されていません(チェックされていません)。この場合は、チェックボックスを選択し、ホストを構成してドメイン・フロントエンド・ホストを有効にする必要があります。

フィールドまたはオプション

説明

ドメイン・フロントエンド・ホストの構成

選択した場合、ドメイン全体のフロントエンド・ホストが有効化されます。

フロントエンド・ホストの構成を無効化および削除するには、このチェックボックスの選択を解除します。構成がサービス表から削除されることを示す通知が表示されます。

プレーン

自動的に移入されていない場合は、フロントエンド・ホストのプレーンURL(例: http://www.myhost.com:8180)を入力します。必要に応じて、既存の値を更新することもできます。

SSL

自動的に移入されていない場合は、フロントエンド・ホストのSSL URLを入力します。必要に応じて、既存の値を更新することもできます。

注意: フロントエンド・ホストのプレーンURLを使用している場合は引き続きデフォルトのSSL URLを指定する必要があります。フロントエンド・ホストにプレーン接続のみを設定している場合、プレーンとSSLに同じURLを使用できます。それ以外の場合は、異なる必要があります。

デフォルト

該当するラジオ・ボタンを選択して、プレーンURLまたはSSL URLをフロントエンド・ホストのデフォルトURLに設定します。

関連トピック

クラスタ

サーバーのマシンへの割当て

定義した各マシンにWebLogic Serverインスタンスを割り当てるためにこの画面を使用します。

1. 「マシン」リスト・ボックスで、WebLogic Serverインスタンスを割り当てるWindowsマシンまたはUNIXマシンを選択します。

2. 次のいずれかの方法で、選択したマシンにWebLogic Serverインスタンスを割り当てます。

- 「サーバー」リスト・ボックスでWebLogic Serverインスタンスをダブルクリックします。

- 「サーバー」リスト・ボックスで適切なWebLogic Serverインスタンスを選択して、右矢印をクリックします。

- 「サーバー」リスト・ボックスで「Shift」を押しながらクリックして複数のサーバーを選択して、右矢印をクリックします。

WebLogic Serverインスタンスの名前が、「サーバー」リスト・ボックスから削除され、「マシン」リスト・ボックスのターゲット・マシンの名前の下に追加されます。

3. マシンに割り当てるWebLogic Serverインスタンスごとに、ステップ1と2を繰り返します。

4. マシンの割当てを確認します。
必要に応じて、次のいずれかの方法でマシンからWebLogic Serverインスタンスを削除できます。

- 「マシン」リスト・ボックスの適切なWebLogic Serverインスタンスの名前をダブルクリックします。

- 「マシン」リスト・ボックスで適切なWebLogic Serverインスタンスを選択して、左矢印をクリックします。

WebLogic Serverインスタンスの名前が、「マシン」リスト・ボックスから削除され、「サーバー」リスト・ボックスにリストアされます。

関連トピック

マシン

システム・コンポーネント

この画面では、OHSやODIなどのシステム・コンポーネントを追加または削除します。

フィールド

説明

システム・コンポーネント

システム・コンポーネントを識別するための一意の名前を入力します。

コンポーネント・タイプ

OHSやODIなどの適切なコンポーネント・タイプを入力します。

再起動間隔秒数

アプリケーションが応答しない場合に、再起動を試行する前に待機する秒数を指定します。

再起動間隔遅延

再起動を再度試行する前に待機する秒数を指定します。

新規システム・コンポーネントを追加するには、「追加」をクリックします。新しいコンポーネントのデフォルト名はnew_SystemComponentnで、nは1から始まり、OHSまたはODIインスタンスを追加するたびに1ずつ増分されます。

既存のシステム・コンポーネントを削除するには、表内でコンポーネントの行をクリックして「削除」をクリックします。

関連トピック

OHSサーバー

ODIサーバー構成

システム・コンポーネントのマシンへの割当

OHSサーバー

この画面を使用して、ドメイン内のOHSサーバーを構成します。

フィールド

説明

システム・コンポーネント

このドロップダウン・リストから、構成するシステム・コンポーネントを選択します。

管理ホスト

ノード・マネージャと通信するために、選択したOHSサーバーで使用するリスニング・アドレス。このアドレスでは、ホスト内のループバック通信のみを許可する必要があります(例: 127.0.0.1)。

管理ポート

このシステム上でノード・マネージャと通信するために、選択したOHSサーバーで使用するリスニング・ポート。ポートは一意である必要があります。

リスニング・アドレス

このシステム・コンポーネントで使用するリスニング・アドレス。

リスニング・ポート

このシステム・コンポーネントで使用するリスニング・ポート。

SSLリスニング・ポート

このフィールドは、指定したWebLogic Server管理サーバー上でSSLが有効である場合にのみ使用できます。

このサーバー・インスタンス上でセキュアなリクエストに使用する、有効な値を入力します。リスニング・ポートの有効な範囲は、1から65535までです。

デフォルトで、サーバー・インスタンスではデモ証明書を使用してセキュア・ポートからのリクエストを認証します。本番環境では、認証局が発行した証明書を使用できるようにSSLを構成する必要があります。

詳細は、『Oracle WebLogic Serverセキュリティの管理』のSSL: 概要に関する項を参照してください。

サーバー名

現在選択されているOHSサーバーのURLおよびリスニング・ポート。新しいサーバーを追加する場合、このフィールドは、再構成ウィザードを実行しているサーバーと、「リスニング・ポート」フィールドのポート値にデフォルトで設定されます。

関連トピック

システム・コンポーネント

システム・コンポーネントのマシンへの割当

ODIサーバー構成

この画面を使用して、同じ場所に配置されたODIエージェントをドメインに構成します。

スタンドアロンODIエージェントおよび同じ場所に配置されたODIエージェントの詳細は、Oracle Data Integratorのインストールおよび構成のOracle Data Integratorエージェントの理解に関する項を参照してください。

フィールド

説明

システム・コンポーネント

このドロップダウン・リストから、構成するODIエージェントを選択します。

サーバー・リスニング・アドレス

このエージェントが存在するホスト・システムのホスト名またはIPアドレスを入力します。localhostを使用しないでください。

サーバー・リスニング・ポート

ODIエージェントに使用するリスニング・ポートを入力します。

スーパーバイザ・ユーザー名

スーパーバイザ権限を持つODIユーザー名を入力します。

スーパーバイザ・パスワード

スーパーバイザ・ユーザーのパスワードを入力します。

優先データソース

このドロップダウンリストから、選択されたODIエージェントに使用するデータ・ソースを選択します。

関連トピック

システム・コンポーネント

システム・コンポーネントのマシンへの割当

『Oracle Data Integratorのインストールと構成』のOracle Data Integratorエージェントの理解に関する項

システム・コンポーネントのマシンへの割当

この画面では、定義したマシンにシステム・コンポーネントを割り当てます。

1. 「マシン」リスト・ボックスで、システム・コンポーネントを割り当てるWindowsマシンまたはUNIXマシンを選択します。

2. 次のいずれかの方法で、選択したマシンにシステム・コンポーネントを割り当てます。

- 「システム・コンポーネント」リスト・ボックスのインスタンスをダブルクリックします。

- 「システム・コンポーネント」リスト・ボックスで適切なインスタンスを選択し、右矢印をクリックします。

- 「システム・コンポーネント」リスト・ボックスで[Shift]キーを押しながら複数のインスタンスをクリックして選択し、右矢印をクリックします。

システム・コンポーネントの名前が「システム・コンポーネント」リスト・ボックスから削除され、「マシン」リスト・ボックス内にあるターゲット・マシンの名前の下に追加されます。

3. マシンに割り当てる各インスタンスに対して、手順1と2を繰り返します。

4. マシンの割当てを確認します。
必要な場合は、次のいずれかの方法でマシンからインスタンスを削除できます。

- 「マシン」リスト・ボックスの適切なインスタンスの名前をダブルクリックします。

- 「マシン」リスト・ボックスで適切なインスタンスを選択し、左矢印をクリックします。

インスタンスの名前が「マシン」リスト・ボックスから削除され、「システム・コンポーネント」リスト・ボックスに復元されます。

関連トピック

システム・コンポーネント

OHSサーバー

ODIサーバー構成

デプロイメント・ターゲット指定

この画面で、サーバーまたはクラスタ上のデプロイメントのためにアプリケーションをターゲット設定できます。

ドメインを構成する製品に関連付けられるアプリケーションが、その製品のために作成した管理対象サーバーまたはその管理対象サーバーが割り当てられているクラスタに自動的にターゲット指定されます。この画面で、アプリケーションを追加のサーバーおよびクラスタにターゲット指定できます。

アプリケーション・デプロイメントをクラスタまたはサーバーにターゲット指定するには:

1. 「ターゲット」リスト・ボックスで、アプリケーションをデプロイするクラスタまたはサーバーを選択します。
選択したターゲットの名前が、右側のリスト・ボックスのタイトルとして表示されます。

2. target_nameリスト・ボックスで、選択したターゲットにデプロイするアプリケーションに対応するチェック・ボックスを選択します。
このリストに表示されるアプリケーションは、このウィザードの前の「ドメイン・ソースの選択」画面で選択した製品によって異なります。

注意:

「ターゲット」リスト・ボックスで管理対象サーバーを選択すると、target_nameリスト・ボックスの一部のチェック・ボックスが無効になります。無効になったチェック・ボックスは、選択した管理対象サーバーを含むクラスタにすでにターゲット指定されているアプリケーションであることを示しています。

アプリケーションを選択すると、ターゲット指定されたクラスタおよびサーバーの名前がtarget_nameリスト・ボックスの「ターゲット」列に表示されます。

3. 必要に応じて、他のクラスタおよびサーバーに対してステップ1と2を繰り返します。

4. 必要なフィールドを選択した後、「次へ」をクリックします。

ドメインを再構成する際に、アプリケーションが現在ターゲット指定される管理対象サーバーまたはクラスタを削除する場合、再構成ウィザードによりこれらのアプリケーションが次のように自動的にターゲットに再指定されます。

- 最初に、アプリケーションが、削除する管理対象サーバーまたはクラスタのみにターゲット指定されている(つまり、管理対象サーバーまたはクラスタを削除したら、変更したドメインでアプリケーションがターゲット指定解除される)場合、再構成ウィザードにより、アプリケーションが自動的にすべての適切なターゲットに再指定されます。
適切なターゲットとは、テンプレートの構成グループ指定(config-groups.xmlファイル)に定義されていない任意のクラスタまたは管理対象サーバーです。config-groups.xmlに指定されているサーバーまたはクラスタは、基本的にテンプレートが所有するので、自動ターゲット指定に不適格です。

- 元々、アプリケーションが複数のターゲット(管理対象サーバー、クラスタおよび管理サーバーを含む)にターゲット指定されている場合、ターゲット指定される管理対象サーバーまたはクラスタの1つを削除すると、拡張ドメインで再構成ウィザードによって、残りのターゲット関連付けがそのまま残され、アプリケーションの新しいターゲットへの再ターゲット指定が試行されません。

関連トピック

『Oracle WebLogic Serverへのアプリケーションのデプロイ』の「WebLogic Serverデプロイメントについて」

サービス・ターゲット指定

この画面を使用して、サービスの適切な管理対象サーバーまたはクラスタへのターゲット指定をします。

ドメインを構成する製品に関連付けられるサービスが、その製品のために作成した管理対象サーバーまたはその管理対象サーバーが割り当てられているクラスタに自動的にターゲット指定されます。この画面で、サービスを追加のサーバーおよびクラスタにターゲット指定できます。

サービスを管理対象サーバーまたはクラスタにターゲット指定するには、

1. 「ターゲット」リスト・ボックスで、サービスをデプロイするクラスタまたはサーバーを選択します。
選択したターゲットの名前が、右側のリスト・ボックスのタイトルとして表示されます。

2. 「target_name」リスト・ボックスで、選択したターゲットにデプロイするサービスに対応するチェック・ボックスを選択します。
このリストに表示されるサービスは、このウィザードの前の「ドメイン・ソースの選択」画面で選択した製品によって異なります。

注意:

「ターゲット」リスト・ボックスで管理対象サーバーを選択すると、target_nameリスト・ボックスの一部のチェック・ボックスが無効になります。無効になったチェック・ボックスは、選択した管理対象サーバーを含むクラスタにすでにターゲット指定されているサービスであることを示しています。

サービスを選択すると、ターゲット指定されたクラスタおよびサーバーの名前がtarget_nameリスト・ボックスの「ターゲット」列に表示されます。

3. 必要に応じて、他のクラスタおよびサーバーに対してステップ1と2を繰り返します。

4. 必要なフィールドを選択した後、「次へ」をクリックします。

ドメインを再構成する際に、サービスが現在ターゲット指定される管理対象サーバーまたはクラスタを削除する場合、再構成ウィザードにより、これらのサービスが次のように自動的に再度ターゲット指定されます。

- 元々、サービスが削除する管理対象サーバーまたはクラスタのみにターゲット指定されている(つまり、管理対象サーバーまたはクラスタを削除したら、変更したドメインではサービスのターゲット指定が解除される)場合、再構成ウィザードにより、サービスが自動的にすべての適切なターゲットに再指定されます。
適切なターゲットとは、テンプレートの構成グループ指定(config-groups.xmlファイル)に定義されていない任意のクラスタまたは管理対象サーバーです。config-groups.xmlに指定されているサーバーまたはクラスタは、基本的にテンプレートが所有するので、自動ターゲット指定には不適切です。

- 元々、サービスが複数のターゲット(管理対象サーバー、クラスタおよび管理サーバーを含む)にターゲット指定されている場合、ターゲット指定される管理対象サーバーまたはクラスタの1つを削除すると、拡張ドメインでは再構成ウィザードによって、残りのターゲット関連付けがそのまま残され、サービスの新しいターゲットへの再指定が試行されません。

関連トピック

『Oracle WebLogic Serverの理解』のリソースとサービスに関する項。

JMSファイル・ストア

JMSファイル・ストアは、永続メッセージを格納するためのディスク・ベースのファイルです。

「JMSファイル・ストア」画面では、ドメイン内に構成されているJMSファイル・ストアを変更します。この画面には、次のフィールドがあります。

列

説明

名前

JMSファイル・ストアの有効な名前を入力します。名前は、文字列である必要があります。JMSファイル・ストアの名前は、ドメイン内のすべてのコンポーネント名の間で一意であることが必要です。

ディレクトリ

JMSファイル・ストアが存在するシステム内のディレクトリ・パスを入力する。

同期書込みポリシー

ドロップダウン・リストから次のいずれかの同期書込みポリシーを選択して、ファイル・ストアのデータをディスクに書き込む方法を指定します。

ディスクへの非永続メッセージのページングにJMSファイル・ストアを排他的に使用すると、同期書込みポリシーは無視されます。

キャッシュ・フラッシュ

WebLogic Serverでは、オペレーティング・システムとストレージ・デバイスのデフォルトのファイル書込み動作が有効になります。デフォルトのファイル書込み動作では、基本的にキャッシングとファイルの書込みのスケジューリングを行いますが、トランザクションが完了する前にキャッシュのディスクへのフラッシュを強制します。

詳細は、『WebLogic永続ストアの管理』のキャッシュ・フラッシュ・ポリシーに関する項を参照してください。

直接書込み

WebLogic Serverは、ネイティブなI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期的に書き込みます。

詳細は、『WebLogic永続ストアの管理』の直接書込みポリシーに関する項を参照してください。

直接書込み - キャッシュあり

ほとんどのシナリオでは、直接書込み - キャッシュありポリシーを使用することをお薦めします。このポリシーを選択すると、WebLogic Serverは、ネイティブなI/O wlfileioドライバを使用して、ファイル・ストアの構成のDirectory属性で定義された場所に格納される一連のプライマリ・ファイルに同期的に書き込みます。

詳細は、『WebLogic永続ストアの管理』の直接書込み - キャッシュありポリシーに関する項を参照してください。

無効

WebLogic Serverはオペレーティング・システムおよびストレージ・デバイスのデフォルトのファイル書込み動作に依存しています。

詳細は、『WebLogic永続ストアの管理』の無効ポリシーに関する項を参照してください。

直接書込み

書込み操作はディスクに直接実行されます。このポリシーは、SolarisおよびWindowsでサポートされています。このポリシーはサポートしていないプラットフォームでアクティブになっている場合、ファイル・ストアは自動的に「キャッシュ・フラッシュ」ポリシーに切り替わります。

詳細は、『WebLogic永続ストアの管理』の直接書込みポリシーに関する項を参照してください。

無効

トランザクションは書込みがメモリーにキャッシュされるとすぐに完了します。このポリシーがアクティブになっている場合、トランザクションは書込みがディスクに格納されるのを待たずに完了します。

この設定は、パフォーマンス、スケーラビリティ、および信頼性に影響します。

関連トピック

『Oracle WebLogic Serverサーバー環境の管理』の同期書込みポリシーの構成のガイドラインに関する項。

構成のサマリー

続行する前にドメインの詳細な構成設定を確認します。

「表示」ドロップダウン・リストからフィルタ・オプションを選択すると、右側のパネルに表示される項目を制限できます。

構成を変更する必要がある場合は、「戻る」をクリックして該当する画面に戻ります。

実行したら、「再構成」をクリックして、ドメインを再構成します。ドメインの場所は変更されません。

関連トピック

ドメインの選択

再構成セットアップの進行状況

再構成の進行状況

再構成に成功しました

再構成の進行状況

この画面には、再構成プロセスの進行状況が表示されます。プロセス中に、次の操作が行われます。

- ドメイン情報が抽出、保存および更新されます。

- Fusion Middleware製品をサポートするスキーマ、スクリプトおよび他のファイルが更新されます。

処理が終了したら、「終了」をクリックします。

関連トピック

ドメインの選択

再構成セットアップの進行状況

構成のサマリー

再構成の進行状況

再構成に成功しました

この画面は、再構成プロセスが成功して完了したか、または失敗したかどうかを示します。管理サーバーURL(リスニング・ポートを含む)とともに再構成されたドメインの場所も表示します。

再構成プロセスが成功して完了しなかった場合は、その理由を示すエラー・メッセージが表示されます。問題を解決するための適切な措置を講じます。問題を解決できない場合は、My Oracle Supportに連絡してください。

関連トピック

ドメインの選択

再構成セットアップの進行状況

A WebLogic Server 12.2.1.2.0の旧リリースとの互換性

この付録では、WebLogic Server 10.3.xまたは12.1.xリリースからWebLogic Server 12.2.1.2.0にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。特に、この付録には、アップグレードされた環境で実行するアプリケーションに影響を及ぼす可能性がある様々なWebLogic Serverバージョンにおける機能の変更について記載されています。

関連項目:

- Oracle WebLogic Serverの理解のWebLogic Serverの互換性に関する項。この項では、WebLogic Serverの互換性の目標に関する一般情報、およびこのリリースのWebLogic Serverへの適用方法について説明します。

- このリリースおよび以前のリリースの『Oracle WebLogic Serverの新機能』 12.2.1.2.0。これらのドキュメントでは、使用可能な新機能に関する情報、およびアプリケーションに影響を及ぼす可能性がある動作の変更について説明します。

互換性に関する検討事項は、次のように分類されます。ユーザーの状況に該当する項は、WebLogic Server 12.2.1.2.0にアップグレードする前のWebLogic Serverのバージョンによって異なります。WebLogic Serverの現在のバージョンに基づいて参照する各項の一覧については、表A-1を参照してください。

表A-1 各バージョンのWebLogic Serverからのアップグレードに適用される項

このバージョンのWebLogic Serverからアップグレードする場合

これらの項を参照

12.2.1.0.0

WebLogic Server起動時のランタイム使用量の制限のオプションは削除されました

12.1.3

乱数ジェネレータ

パーティション、アプリケーションおよびコンテナのコンテキスト・ルーツの想定

デフォルトのCommonJ Work Managerの自動バインディングが削除されました

パラレル・デプロイメント

12.1.2

上記のすべての項、および次の項:

サーバー・ロギング・ブリッジ

Oracleデータベース・ドライバ

OracleでJavaNet FastPathの有効化

12.1.1

上記のすべての項、および次の項:

最大POSTサイズ

WLDFスキーマのアップグレード

jdbc-connection-timeout-secs要素

ローカル・トランザクションのコミット

10.3.5および10.3.6

上記のすべての項、および次の項:

JVMの設定

ノード・マネージャのstartScriptEnabledのデフォルト

Enterprise Java Beans (EJB)

WebLogic Server 8.1 Webサービス・スタックの削除

Universal Description and Discover (UDDI)レジストリの削除

Certicom SSLの実装

Coherenceのバージョン

非推奨および廃止済Webアプリケーションの機能

PointBaseからDerbyに変更された評価版データベース

データ・ソース・プロファイル・ロギング

ONSのデバッグ

DataDirectのOracleタイプ4 JDBCドライバの使用

デフォルトのメッセージング・モードの変更

10.3.3および10.3.4

上記のすべての項、および次の項:

SSLMBeanへの変更

10.3.2

上記のすべての項、および次の項:

新しいWebサービス機能

JSSEの導入

セキュリティ・ポリシー・デプロイメントのパフォーマンス向上

ActiveCache

クラス・キャッシュ

非推奨となったJDBCドライバ

weblogic.jms.extension APIの変更

永続ストアの更新

10.3.1

上記のすべての項、および次の項:

Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダ

10.3.0

上記のすべての項、および次の項:

capacityIncrement属性

Middlewareホーム・ディレクトリ

リソース登録名

サーブレット・パス・マッピング

WebLogic Server起動時のランタイム使用量の制限のオプションは削除されました

通常、WebLogic Serverインスタンスの起動時には、EJB、JMS、コネクタ、クラスタリング、デプロイメント、管理などすべてのサービスが起動します。ただし、WebLogic Serverには、次のサービスのサブセットを起動の対象から除外することでランタイム使用量を軽量化する起動オプションが用意されています。

java weblogic.Server -DserverType= {"wlx" | "wls"}

Oracle WebLogic Serverバージョン12.2.1.0.0で、この起動オプションは削除されました。

乱数ジェネレータ

WebLogic 12.2.1.2.0では、以前のリリースにおいて使用されたものよりセキュアな乱数ジェネレータ・アルゴリズムを使用しています。この結果、低エントロピ・システム上で管理対象サーバー、構成ウィザード、ノード・マネージャおよびWebLogic Javaユーティリティ(utils.ImportPrivateKeyなど)の起動が遅くなることがあるため、システム・エントロピを増加する手段を講じてください。

Linuxシステムでは、rng-toolsを使用して、システム・エントロピを置換します。構成するには、/etc/sysconfig/rngdを編集して、次の行を追加します。

EXTRAOPTIONS="-i -r /dev/urandom -o /dev/random -b"

また、-t 60および-W 2048パラメータを使用することもでき、その場合、エントロピ・プールのサイズが2048に達するまで、60秒ごとにプールにビットが追加されます。

次のコマンドを使用して、手動でエントロピを生成します。

rngd -r /dev/urandom -o /dev/random -b

次のコマンドを使用して、現在のエントロピを確認します。

cat /proc/sys/kernel/random/entropy_avail

パーティション、アプリケーションおよびコンテナのコンテキスト・ルーツの想定

Webコンテナのコンテキスト・ルートに関連した想定をするJava EEアプリケーションが、uriPrefixセットがある仮想ターゲットにデプロイされている場合、これを変更する必要があります。このような場合、アプリケーションのコンテキスト・パスには、仮想ターゲットのuriPrefixが含まれます。

その例は、次のとおりです。

- アプリケーションは、受信URLを解析して別のURLを作成ます。この解析でURLルートがhost:portで終了すると想定される場合、アプリケーションを更新して、URLルートをURIベースのルーティングを使用したhost:port/prefixにする必要があります。
MedRecサンプル・アプリケーションが、その例の1つです。MedRecは、受信URLを解析して別のURLを作成し、ルートURLがhost:portだけから構成されていると想定していました。これに対処するために、次の変更が、MedRecアプリケーションに加えられました。

- この内科医用アプリケーション用のJaxWsProperties.javaファイルの元のコードは、次のとおりです。

public final static String WSURL = "http://"
+ ServerPropertiesUtils.getServerAddress("physician", "localhost")
+ ":"
+ ServerPropertiesUtils.getServerPort("7001")
+ "/medrec-jaxws-services/";

これは次のコードに変更されました。ServerPropertiesUtils.getRegion()は、URLにパーティションURI接頭辞が含まれる可能性を示しています。

public final static String WSURL = "http://"
+ ServerPropertiesUtils.getRegion() + "medrec-jaxws-services/";

- この内科医用Webアプリケーション用のGettingHostFilter.javaファイルの元のコードは、次のとおりです。

ServerPropertiesUtils.setAddress(request.getServerName());
ServerPropertiesUtils.setPort(String.valueOf(request.getServerPort()));
chain.doFilter(request, response);

host:port(または、MT URIベースのルーティングを使用する場合、Webサービス・クライアントでhost:port/partition)を維持するために、これは次のコードに変更されました。

if (ServerPropertiesUtils.getRegion() == null ||
ServerPropertiesUtils.getRegion().equals("")) {
StringBuilder builder = new StringBuilder();
builder.append(request.getServerName());
builder.append(":");
builder.append(String.valueOf(request.getServerPort()));
builder.append(partition);
ServerPropertiesUtils.setRegion(builder.toString());

- アプリケーションは、HTML/JSPコード内で「/」にリンクしています。非MT環境では、アプリケーションに、デプロイされるコンテキスト・ルートに関する想定がある場合があります。たとえば、アプリケーションが、コンテキスト・ルート/fruitsでデプロイされ、次を参照するページを含むとします。

<a href="/fruits/index.html">Back to Fruits List</a>

URI接頭辞を使用する仮想ターゲットを持つパーティションにアプリケーションがデプロイされる場合、このタイプの絶対参照は機能しません。前述のリンクは、host:port/partition1/fruits/index.htmlではなく、host:port/fruits/index.htmlに移動しようとします。最も安全な手法は、次のように、リンクで相対URLを使用することです。

<a href="index.html">Back to Fruits List</a>

デフォルトのCommonJ Work Managerの自動バインディングが削除されました

デフォルトCommonJ Work Managerのjava:comp/env/wm/defaultへの自動バインディングは、Java EE 7プラットフォーム仕様に準拠しないためWebLogic Server 12.2.1で削除されました。

デフォルトCommonJ Work Managerを使用するアプリケーションがある場合、次のいずれかのようにします。

- デプロイメント記述子で、wm/defaultのためのresource-refエントリを追加します。例:

<resource-ref>
<res-ref-name>wm/default</res-ref-name>
<res-type>commonj.work.WorkManager</res-type>
<res-auth>Container</res-auth>
</resource-ref>

- CommonJワーク・マネージャを、アプリケーション・コンポーネントにインジェクトします。例:

@Resource commonj.work.WorkManager myWorkManager;

パラレル・デプロイメント

WebLogic Server 12.2.1では、アプリケーションおよびモジュールのパラレル・デプロイメントに対するサポートが追加されて、起動および実行後デプロイメント時間が改善されました。アプリケーションのパラレル・デプロイメントでは、同一のデプロイメント順序でアプリケーションが互いにパラレルにデプロイされます。一方、モジュールのパラレル・デプロイメントでは、単一アプリケーション・アーカイブ内のモジュールが、互いにパラレルにデプロイされます。

WebLogic Server 12.2.1 (または以降)で作成されたまたはアップグレードされたWebLogicドメインのデフォルトは、次のとおりです。

- アプリケーションのパラレル・デプロイメントが有効です。

- ドメイン内のすべてのアプリケーション用モジュールのパラレル・デプロイメントは、無効です。

WebLogic Server 12.1.3以前では、アプリケーションは常にシリアルでデプロイされました。デフォルトのデプロイメント順序は、ドメイン構成で定義される自然順序です(つまり、config.xmlファイルで確立されます)。ただし、以前のWebLogic Serverリリースで、デプロイメント順序を明示的に制御するには、WebLogic Server管理コンソールを使用してAppDeploymentMBeanのDeploymentOrder属性を設定するか、Oracle WebLogic Serverへのアプリケーションのデプロイのアプリケーションおよびスタンドアロン・モジュールのデプロイメント順序の変更に関する項で説明するようにプログラム的に制御します。アプリケーション間に固有の依存性がある場合、この機能を旧リリースで使用することが重要です。

WebLogic Server 12.2.1.2.0で新しいドメインを作成する、または既存のドメインを12.2.1.2.0にアップグレードする場合、WebLogic Server 12.1.3デプロイメント順序動作をリストアするには、DomainMBeanの次の属性を無効にします。

- ParallelDeployApplications — アプリケーションをパラレルにデプロイするかどうか決定します。(この属性はデフォルトで有効になっています。)

- ParallelDeployApplicationModules — アプリケーションのモジュールをパラレルにデプロイするかどうか決定します。(この属性は、デフォルトでは無効になっています。)

ただし、前述の属性を無効化すると、パラレル・デプロイメントによるパフォーマンス向上の利点を効果的に使用できない可能性があります。WebLogic Server 12.2.1.2.0にアップグレードするドメイン内のパラレル・デプロイメントをすべて無効化するのではなく、アプリケーションまたはモジュールのデプロイメント順序付けがカスタム化されているかどうか、その場合、それが必要かどうかを確認することをお薦めします。詳細については、次を参照してください:

- Oracle WebLogic Serverへのアプリケーションのデプロイのアプリケーションおよびモジュールのパラレル・デプロイメントの有効化に関する項には、パラレル・デプロイメントの使用におけるアプリケーションおよびモジュールの依存性に関する重要な考慮事項が記載されています。

- Oracle WebLogic Server管理コンソール・オンライン・ヘルプのサーバー・デプロイメント順序の変更に関する項には、WebLogic Server管理コンソールを使用したデプロイメントのデプロイメント順序を表示するまたは変更する方法が説明されています。

サーバー・ロギング・ブリッジ

WebLogic Server 12.1.3では、サーバー・ロギング・ブリッジがjava.util.loggingロガー・ツリーのルート・ロガーに追加されました。従って、サーバー・ロギング・ブリッジを明示的に構成する必要がありません。

『Oracle WebLogic Serverログ・ファイルの構成とログ・メッセージのフィルタ処理』のサーバー・ロギング・ブリッジに関する項の説明に従ってweblogic.logging.ServerLoggingHandlerを構成した場合:

- weblogic.logging.ServerLoggingHandlerがルート・ロガーにアタッチされている場合、logging.propertiesファイルから削除することを強くお薦めします。

- weblogic.logging.ServerLoggingHandlerがルート以外のロガーにアタッチされている場合、logging.properties構成から削除するか、useParentHandlers属性をfalse(たとえばcom.foo.barUseParentHandlers=falseなど)に設定することを強くお薦めします。

前述の状況はLog4Jにも適用されますが、用語は異なります。

- weblogic.logging.log4j.ServerLoggingAppenderは、Log4J用のブリッジです。

- useParentHandlersは、Log4JではAdditivityと呼ばれます。これは、log4j.propertiesファイルではlog4j.additivity.com.foo.bar=falseとして構成されます。

Oracleデータベース・ドライバ

WLSインストールには、Oracle Database 12cドライバが含まれるようになりました。これは、アプリケーションに次の変更が必要です:

- wlserver/server/lib/ojdbc6.jarへの参照を${MW_HOME}/oracle_common/modules/features/com.oracle.db.dbc7-no-dms.jarに置き換えます。これは、weblogic.jarの使用時に自動的にクラス・パスに含まれます。

- wlserver/server/lib/aqapi.jarへの参照を${MW_HOME}/oracle_common/modules/oracle.jdbc_12.1.0/aqapi.jarに置き換えます。これはcom.oracle.db.jdbc7-no-dms.jarも使用する必要があります。

Oracle Database 11gドライバJARを使用して実行を続行する場合、次の操作が必要です。

- クラスパスの最前部へのドライバJARの追加

- MW_HOME/oracle_common/modules/oracle.jdbc_12.1.0ディレクトリの外部へのOracle Database 12cドライバJARの移動

OracleでJavaNet FastPathの有効化

WebLogic Server管理コンソールの「ドメイン構造」→「サービス」→「データ・ソース」→「構成: Oracle」タブにある「OracleでJavaNet Fastpathの有効化」属性は、現在サポートされていません。

最大POSTサイズ

新しいセッション記述子max-save-post-sizeがWebLogic Server 12.1.2に追加されました。これは既存のアプリケーションに影響を及ぼす可能性があります。この記述子は、FORM認証中にアプリケーション・コンテナによって保存またはバッファリングされるPOSTの最大サイズ(バイト単位)を設定します。デフォルト値は4096バイトです。

FORM認証中に、アプリケーションでサイズが4096バイトを超えるフォームをポストする場合は、max-save-post-sizeを適切な値に増やす必要があります。そうしない場合、ブラウザでMaxPostSizeExceededExceptionが発生します。

WLDFスキーマのアップグレード

WLDFイベントおよびハーベスタ・データにJDBCベースのストアを使用している場合は、データベースのWLDF表を更新または再作成する必要があります。wls_events表で、THREADNAME列をvarchar(128)からvarchar(250)に変更します。wls_hvst表で、WLDFMODULE varchar(250) default NULL列を追加します。詳細は、『Oracle WebLogic Server診断フレームワークの構成と使用』のJDBCベースのストアの構成に関する項を参照してください。

これはWLSスタンドアロン・インストールにのみ適用されます。Fusion Middleware製品を含むインストールの場合、スキーマ・アップグレード・プロセスはOracle Upgrade Assistantを介して行います。

jdbc-connection-timeout-secs Element

WebLogic Server 12.1.2以降、weblogic.xmlデプロイメント記述子のjdbc-connection-timeout-secs要素はWebLogic Server 12.1.2で削除されました。アプリケーションでjdbc-connection-timeout-secs要素を構成する場合は、アプリケーションのデプロイメントが失敗しないように、weblogic.xmlデプロイメント記述子からそれを削除する必要があります。

ローカル・トランザクションのコミット

WebLogic Server 12.1.2以降、アプリーションによってコミットまたはロールバックされなかった非XA接続のローカル・トランザクションは、その接続がプールに戻されるときにデフォルトで明示的にコミットされるようになりました。また、接続プールを閉じるときに非XA接続とXA接続のローカル・トランザクションをコミットするかどうかを設定するために、次の2つのパラメータが追加されました。

- -Dweblogic.datasource.endLocalTxOnNonXAConWithCommit=falseを使用すると、アプリケーションでトランザクションの明示的な完了を保証できる際に、非XA接続でこれ以上のDBMSアクセスが不要になります。このパラメータをfalseに設定すると、setAutoCommit(true)の呼出し時に使用する特定のJDBCドライバの動作に応じて、接続プールを閉じるときに非XA接続のローカル・トランザクションが暗黙的にコミットまたはロールバックされます。JDBC仕様に準拠する場合、そのアクションはトランザクションをコミットしますが、ドライバごとに準拠の度合いは異なります。デフォルトでは、このプロパティをtrueに設定すると、これらのトランザクションはコミットされます。

- -Dweblogic.datasource.endLocalTXOnXAConWithCommit=trueを使用すると、接続プールを閉じるときにXA接続のローカル・トランザクションをコミットできます。デフォルトでは、これらのトランザクションはロールバックされます。

JVMの設定

WebLogic Server 10.3.xドメインをWebLogic Server 12.1.2以上のドメインにアップグレードする際は、次の操作が必要な場合があります。

- Java承認ディレクトリ(JRE_HOME/lib/endorsed)の場所の手動設定

- Oracle HotSpot JDKのpermgen領域および最大permgen領域の手動拡張

Java承認ディレクトリの場所の設定

次の状況では、Java承認ディレクトリの場所の手動設定は必要ありません。

- JDK7を使用中の場合。

- WebLogic Server 12.1.1でインストールされたJDKの1つを使用中の場合。

- WebLogic Server 12c構成ウィザードによるドメイン作成で生成されたWLS 12cドメインおよび起動スクリプトを使用中の場合、またはWebLogic Serverインストーラでインストールされたように起動スクリプトがcommEnv.cmd/shを参照する場合、あるいはその両方の場合。

この状況がいずれも当てはまらないとき、次のいずれかの状況が当てはまる場合は、管理対象サーバーの起動に使用するコマンドでJava承認ディレクトリの場所を手動設定する必要があります。

- 管理対象サーバーの起動にノード・マネージャを使用しているが、起動スクリプト(startScriptEnabled=false)を使用していない場合。WebLogic Server 12.1.1以降、startScriptEnabledのデフォルト値はtrueになりました。

- カスタム起動スクリプト、つまりOracleで提供されていない起動スクリプトを使用中の場合。

- java.weblogic.Serverを使用して空のドメインを作成しようとしている場合。

このいずれのケースでも、管理対象サーバーの起動コマンドにjava.endorsed.dirsパラメータを含めてください。

startWeblogic.sh -Djava.endorsed.dirs=WL_HOME/endorsed

複数のJava承認ディレクトリを指定する場合は、各ディレクトリ・パスをコロン(:)で区切ります。

注意:

この項に記述されているオプションではすべて、WL_HOMEを自分のWebLogic Serverインストールのフル・パスに置き換える必要があります。

次のように、startServerを呼び出すときに値をjvmArgsとして渡すか、nmstartを呼び出すときに値をプロパティとして渡すことで、この値を指定することもできます。

wls:/nm/mydomain> prps = makePropertiesObject("Arguments=-Djava.endorsed.dirs=/WL_HOME/endorsed")

wls:/nm/mydomain> nmStart("AdminServer",props=prps)

管理対象サーバーの起動にノード・マネージャを使用している場合は、WLSTまたはWebLogic Server管理コンソールを使用して、-Djava.endorsed.dirs=/WL_HOME/endorsed")パラメータをServerStartMBeanのarguments属性に含めることができます。WebLogic Server管理コンソールを使用中の場合、サーバーの「構成」→「サーバーの起動」タブでこのパラメータを「引数」フィールドに入力します。管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、またはWebLogic Server管理コンソールでサーバーの「起動」ボタンをクリックした際にこの属性は適用されます。

permgen領域の設定

管理対象サーバーの起動時にOutOfMemory: PermGen Spaceエラーが発生した場合は、permgen領域を128MB以上に手動設定し、最大permgen領域を256MB以上に拡張する必要があります。

注意:

ここで記述されているオプションではすべて、WL_HOMEを自分のWebLogic Serverインストールのフル・パスに置き換える必要があります。

これを実行するには、WLSTまたはWebLogic Server管理コンソールを使用して、ServerStartMBeanのarguments属性に次のように指定します。WebLogic Server管理コンソールを使用中の場合、サーバーの「構成」→「サーバーの起動」タブで「引数」フィールドに-XX:PermSize=128m -XX:MaxPermSize=256mを入力します。

注意:

WebLogic Server管理コンソールを介してサーバーを起動することを計画している場合は、WebLogic Server管理コンソールからサーバーを起動する前にpermgen設定を適用する必要があります。そうしないと、サーバーがリカバリ不能な状態になる可能性があります。

管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、またはWebLogic Server管理コンソールでサーバーの「起動」ボタンをクリックした際にこの属性は適用されます。

使用可能な別の方法は、コマンド・ラインを介して管理対象サーバーを起動し、ここに示すように、正しい設定を指定する方法です。

(UNIX) startManagedWebLogic.sh server_name -XX:PermSize=128m -XX:MaxPermSize=256m

(Windows) startManagedWebLogic.cmd server_name -XX:PermSize=128m -XX:MaxPermSize=256m

次のように、startServerを呼び出すときに値をjvmArgsとして渡すか、nmstartを呼び出すときに値をプロパティとして渡すことで、この値を指定することもできます。

wls:/nm/mydomain> prps = makePropertiesObject("Arguments= -XX:PermSize=128m -XX:MaxPermSize=256m")

wls:/nm/mydomain> nmStart("AdminServer",props=prps)

ノード・マネージャのstartScriptEnabledのデフォルト

WebLogic Server 12.1.1以降、startScriptEnabledのデフォルト値はtrueに変更されました。これまでの旧リリースでは、デフォルトはfalseでした。ノード・マネージャで起動スクリプトを使用しない場合は、アップグレード後にこの値をfalseに変更します。

Enterprise Java Beans (EJB)

Oracle Kodoは、WebLogic Server 10.3.1から非推奨とされています。WebLogic Server 12.1.1から、Kodoにかわって、EclipseLinkがデフォルトのJPAプロバイダとなっています。WebLogic Server 12.1.2でKodoを永続プロバイダとして使用するアプリケーションは、更新する必要があります。詳細は、『Oracle WebLogic Server Enterprise JavaBeansの開発』の競合を解決するためのアプリケーションの更新に関する項を参照してください。

WebLogic Server 12.1.1から、JPA 2.0のサポートが組み込まれています。JPA 2.0では、ドメイン・モデリング、オブジェクト/リレーショナル・マッピング、EntityManagerインタフェース、問合せインタフェースおよびJava Persistence Query Language (JPQL)などの各機能が向上し、強化されています。詳細は、『Oracle WebLogic Server Enterprise JavaBeansの開発』のWebLogic ServerでのTopLinkとJPA 2.0の併用に関する項を参照してください。

WebLogic Server 8.1 Webサービス・スタックの削除

WebLogic Server 8.1 Webサービス・スタックはWebLogic Server 12.1.1リリースで削除されています。したがって、WebLogic Server 8.1 Webサービス・アプリケーションは今後機能しません。これらのアプリケーションは、8.1のWebLogic Webサービスの12.1.xへのアップグレードの指示に従って、WebLogic JAX-RPCまたはJAX-WSスタックにアップグレードすることをお薦めします。

Universal Description and Discover (UDDI)レジストリの削除

Universal Description and Discovery (UDDI)レジストリはWebLogic Server 12.1.1から削除されています。UDDIを引き続き使用中の場合にWebLogic Server 12.1.1にアップグレードする際は、UDDI 3.0に準拠したOracle Service Registry (OSR)に移行することをお薦めします。

Certicom SSLの実装

WebLogic Server 12.1.1から、Certicom SSLの実装は削除されています。この変更によって、『Oracle WebLogic Serverセキュリティの管理』のSSLデバッグの有効化のためのコマンド・ライン・プロパティに関する項およびJSSE SSL実装とCerticom SSL実装のシステム・プロパティの相違に関する項の説明に従って、システム・プロパティの更新およびスイッチのデバッグが必要な場合があります。

Coherenceのバージョン

WebLogic Server 12.1.1インストーラにはCoherence 3.7.1が含まれています。クラスタ内のサーバーはすべて同じバージョンのCoherenceを使用する必要があります。したがって、クラスタ内のすべてのキャッシュ・サーバーをCoherence 3.7.1にアップグレードします。

非推奨および廃止済Webアプリケーションの機能

WebLogic Server 12.1.1から非推奨またはサポート対象外となったWebアプリケーション機能については、次を参照してください。

- WebLogic Server 11g リリース1で非推奨になった機能に関する情報は、My Oracle Support (https://support.oracle.com/)で入手できます。
「ナレッジ・ベースの検索」フィールドに、ドキュメントID888028.1を入力してください。

- WebLogic Server 12.1.1で非推奨になった機能に関する情報は、My Oracle Support(https://support.oracle.com/)で入手できます。「Deprecated Features」で検索してください。

PointBaseからDerbyに変更された評価版データベース

WebLogic Server 10.3.3以降では、WebLogic Serverインストール・プログラムの評価版データベースがPointBaseからApache Derbyに変更されています。「製品とコンポーネントの選択」画面の評価版データベース・オプションを選択すると、DerbyデータベースがWL_HOME\common\derbyディレクトリにインストールされます。「標準」インストールを選択すると、Derbyがデフォルトでインストールされます。

PointBaseに基づくドメインがあり、ドメインをWebLogic Server 10.3.3以降にアップグレードした後も引き続きPointBaseを使用する場合は、PointBaseのライセンスをhttp://www.pointbase.comで入手する必要があります。フルWLSインストーラではPointBaseインストール・ディレクトリが保存されません。PointBaseを使用するかわりに、ドメイン・データベースをDerbyに移行できます。

詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください

データ・ソース・プロファイル・ロギング

操作性とパフォーマンスを向上させるため、WebLogic Server 10.3.6以上ではデータ・ソース・プロファイル・ログを使用してイベントが格納されます。『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic JDBCリソースの監視に関する項を参照してください。

ONSのデバッグ

WebLogic Serverリリース10.3.6以上では、UCPおよびONSのパッケージ名が再パッケージされなくなりました。UPCとONSのデバッグの設定方法の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のUCP/ONSのデバッグの設定に関する項を参照してください。

DataDirectのOracleタイプ4 JDBCドライバの使用

WebLogic Server 10.3.6から、DataDirectのOracleタイプ4 JDBCドライバは、WebLogicブランドのDataDirectドライバと呼ばれるようになりました。オラクル社では『Oracle® Fusion Middleware Oracle WebLogic Serverタイプ4 JDBCドライバ』のドキュメントの提供を停止するため、DataDirectドライバの詳細情報は今後提供されなくなります。WebLogic Server環境でWebLogicブランドのドライバを構成および使用する方法の詳細は、Oracle WebLogic Server JDBCアプリケーションの開発のWebLogicブランドのDataDirectドライバの使用に関する項で引き続き提供します。ドライバの動作の詳細は、DataDirectドキュメントを確認することをお薦めします。http://www.datadirect.com/index.htmlの『Progress DataDirect for JDBC User's Guide Release 5.1』および『Progress DataDirect for JDBC Reference Release 5.1』を参照してください。

デフォルトのメッセージング・モードの変更

WebLogic Server 12.1.1から、デフォルトのメッセージング・モードがマルチキャストからユニキャストに変更されました。

SSLMBeanへの変更

SSLMBeanはWebLogic Server 10.3.5から、JSSEアダプタを有効化または無効化する機能など追加のSSL構成機能をサポートするように変更されています。

詳細については、以下のマニュアルを参照してください。

- JSSE SSL実装がWebLogicシステム・プロパティを扱う方法の相違点の一覧は、『Oracle WebLogic Serverのセキュリティの管理』のJSSE SSL実装とCerticom SSL実装のシステム・プロパティの相違に関する項を参照してください。

- WebLogic ServerでのSSLサポートの詳細は、Oracle WebLogic Serverセキュリティの理解のSSL: 概要に関する項を参照してください。

- JSSEの詳細は、『Java Secure Socket Extension (JSEE) Reference Guide』( http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。

新しいWebサービス機能

リリース10.3.3で、WebLogic Serverには次の機能が追加されました。

- Webサービスの原子性トランザクションのサポート。WebLogic Webサービスは、WebSphere、JBoss、Microsoft .NETなどの外部トランザクション処理システムとの相互運用性を実現します。

- クラスタ環境でのWebサービスの拡張サポート

- Webサービスおよびクライアントの監視の拡張

- Fusion Middleware Controlを使用するWebLogic WebサービスへのOracle WSMポリシーの添付

- リレーショナル・データベースにアクセスするための宣言Webサービス・ソリューションのEclipseLink DBWSサポート

- メソッドレベルのポリシー添付動作の変更: WebLogic Server 10.3.3より前のリリースでは、WebLogic Server管理コンソールを使用してWebサービスのメソッドにポリシーを添付すると、そのポリシーはモジュール内のすべてのWebサービスで同じ名前を持つすべてのメソッドにも添付されていました。WebLogic Server 10.3.3では、ポリシーは適切なWebサービスのメソッドのみに添付されます。

- OWSMポリシー名からのpolicy:接頭辞の削除

- Webサービスの「WSDL」タブの削除: WebLogic Server 10.3.3より前のリリースでは、「構成」→「WSDL」タブを選択すると、現在のWebサービスのWSDLを表示できました。「WSDL」タブはWebLogic Server 10.3.3以降では削除されています。

- 新しい開発ツール: Oracle JDeveloperおよびOracle Enterprise Pack for Eclipse (OEPE)。

- Oracle Enterprise Manager Fusion Middleware Controlとの統合

- Oracle WebLogic Services Manager (WSM)セキュリティ・ポリシーのサポート

- JAX-WSでのWS-SecureConversation 1.3、およびJAX-WSでのWS-SecurityによるMTOMのサポート

詳細は、『Oracle WebLogic Serverの新機能』のWebサービスに関する項を参照してください。

JSSEの導入

WebLogic Server 10.3.3から、Java Secure Socket Extension (JSSE)がSSL実装として導入されています。JSSEは、SSLおよびTLS用のJava標準フレームワークで、ブロッキングI/O API、ノンブロッキングI/O API、および複数の信頼性のあるCAを含む参照実装が含まれています。

セキュリティ・ポリシー・デプロイメントのパフォーマンス向上

リリース10.3.3では、WebLogic Serverにスレッド・セーフなデプロイ可能認可プロバイダおよびロール・マッピング・プロバイダのデプロイメント・パフォーマンス拡張が含まれます。WebLogic Serverはデフォルトで、アプリケーションおよびモジュールのデプロイメント中にセキュリティ・ポリシーおよびロールに対してスレッド・セーフな並列変更を実行できます。このため、セキュリティ・レルムに構成されているデプロイ可能な認可プロバイダおよびロール・マッピング・プロバイダでは、並列呼出しがサポートされている必要があります。WebLogicのデプロイ可能なXACML認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。

ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされていない場合は、セキュリティ・ポリシーとロールの並列変更を無効にし、かわりに同期メカニズムを強制的に使用する必要があります。この場合、各アプリケーションとモジュールはキューに入り、順番にデプロイされます。この同期強制メカニズムは、WebLogic Server管理コンソールまたはRealmMBeanのDeployableProviderSynchronizationEnabled属性とDeployableProviderSynchronizationTimeout属性を使用することで有効にできます。

詳細は、『Oracle WebLogic Serverのセキュリティの管理』のデプロイメント時のセキュリティ・ポリシーとロール変更での同期の有効化に関する項を参照してください。

ActiveCache

WebLogic Server 10.3.3以降では、WebLogic ServerにデプロイされているアプリケーションでのCoherenceデータ・キャッシュの使用が容易になり、セッション管理用のCoherence*WebとTopLink Gridをobject-to-relational永続フレームワークとしてシームレスに取り込めるようになりました。これらの機能の総称がActiveCacheです。

ActiveCacheでは、レプリケートおよび分散されたデータ管理とキャッシングのサービスが提供されており、このサービスを使用することで、アプリケーションのオブジェクトとデータをCoherenceクラスタ内のすべてのサーバーに対して利用可能にすることができます。

詳細は、次を参照してください。

クラス・キャッシュ

リリース10.3.3で、WebLogic Serverでクラス・キャッシュを有効にできるようになりました。クラス・キャッシュを使用する利点を次に示します。

- サーバーの起動時間が短縮されます。

- パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。

クラス・キャッシュが開発モードでサポートされるのは、startWebLogicスクリプトを使用してサーバーを起動したときです。クラス・キャッシュはデフォルトでは無効になっており、本番モードではサポートされません。起動時間の短縮の程度は様々なJREベンダーによって異なります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシュの構成に関する項を参照してください。

非推奨となったJDBCドライバ

次のJDBCドライバは非推奨となりました。

- Oracle用のWebLogicタイプ4 JDBCドライバ
このドライバは、WebLogic Server 10.3で非推奨になり、削除されています。この非推奨のドライバのかわりに、WebLogic Serverにも付属しているOracle Thin Driverを使用してください。Oracle Thin Driverの詳細は、『Oracle WebLogic Server JDBCデータ・ソースの管理』のWebLogic ServerでインストールされるJDBCドライバに関する項を参照してください。

- Sybase Jconnect 5.5および6.0ドライバ。これらのドライバは、サンプル・コードのデフォルト・インストールに関するOracleセキュリティ・ポリシーに従ってリリース10.3.3の時点でWebLogic Serverから削除されました。これらのドライバはSybaseからダウンロードできます。また、WebLogic Serverに付属しているOracleブランドのSybase用JDBCドライバを使用することもできます。

weblogic.jms.extension APIの変更

WebLogic Server 10.3.3から、weblogic.jms.extensions.WLMessageインタフェースの次の内部メソッドが、Oracle WebLogic Server Java APIリファレンスから削除されました。

public void setSAFSequenceName(String safSequenceName);
public String getSAFSequenceName();
public void setSAFSeqNumber(long seqNumber);
public long getSAFSeqNumber();

アプリケーションでこれらの内部メソッドを使用しないでください。内部メソッドは、将来のリリースで予告なしに変更または削除される場合があります。

永続ストアの更新

WebLogic Server 10.3.3から、WebLogicファイル・ストアの動作とチューニング方法は、デフォルト・ファイル・ストアとカスタム・ファイル・ストアについて変更されています。

Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダ

Oracle Internet Directory認証プロバイダとOracle Virtual Directory認証プロバイダという2つの新しいLDAP認証プロバイダがWebLogic Server 10.3.2に追加されました。これらの認証プロバイダを使用すると、Oracle Internet Directory LDAPサーバーとOracle Virtual Directory LDAPサーバーにユーザーとグループを格納したり、両サーバーからユーザーとグループを読み取ったりできます。

これらの新しいセキュリティ・プロバイダの構成と使用の詳細は、『Oracle WebLogic Serverのセキュリティの管理』のLDAP認証プロバイダの構成に関する項を参照してください。

capacityIncrement属性

WebLogic Server 10.3.1以上のリリースでは、capacityIncrement属性は構成可能ではなく、1という値に設定されます。

Middlewareホーム・ディレクトリ

WebLogic Server 10.3.1では、BEAホーム・ディレクトリがMiddlewareホームに変更されました。このディレクトリのデフォルト・パスは<drive:>Oracle/Middlewareです。この変更がWebLogic Serverに及ぼす影響は次のとおりです。

- 10.3.1の複数のWebLogicスクリプトに、Middlewareホームを表すための新しい環境変数MW_HOMEが導入されています。この変数が設定されているディレクトリは通常はBEA_HOMEと同じで、これまでどおりWebLogic Serverスクリプトで使用できます。

- インストール時のデフォルトでは、WebLogic Serverのインストール・ディレクトリのルート製品として<drive:>Oracle/Middlewareが選択されます。ただし、既存のWebLogic Serverが検出された場合は、デフォルトでそのインストール・ディレクトリが選択されます。

- 現在、WebLogic Server 10.3.1のドキュメントでは、BEAホームではなくMiddlewareホームという用語を使用します。ただし、この変更は用語のみに適用されます。WebLogicソフトウェア、カスタム・ドメインまたはアプリケーションの移動や、それらの場所を表す既存の環境変数の変更は必要ありません。

この変更によって、コンピュータ上の既存のWebLogic Serverインストール、カスタム・ドメイン、アプリケーションまたはスクリプトが影響を受けることはありません。従来どおりBEA_HOME環境変数を使用し続けることができます。

リソース登録名

WebLogic Server 10.3.1以降では、XAデータ・ソース構成のリソース登録名の動作が変更されました。以前のリリースでは、JTAの登録名はデータ・ソースの名前のみでした。今後は、データ・ソース名とドメインの組合せになります。

詳細は、Oracle WebLogic Server JTAアプリケーションの開発のXAResourceのトランザクションへの参加の登録に関する項を参照してください。

サーブレット・パス・マッピング

Javaサーブレットの仕様バージョン2.3の時点で、次の構文がマッピングの定義に使用されています。

- /(スラッシュ)文字だけが含まれるサーブレット・パス文字列は、アプリケーションのデフォルト・サーブレットを表します。サーブレット・パスは、リクエストURIからコンテキスト・パスを削除したパス(この場合はnull)に解決されます。

- 1個の*(アスタリスク)で始まる文字列は、拡張子マッピングを指定します。

これらの変更により、次のHttpServletRequestメソッドの動作に変化が生じます。

- getPathInfo

- getServletPath

動作の変更を説明するために、例として/abc/def.htmlというリクエストがServletAに解決される場合を考えます。

- /がServletAにマップされると、servletPath="abc/def.html"およびpathInfo=nullになります。

- /*がServletAにマップされると、servletPath=""およびpathInfo="abc/def.html"になります。

確実にnullでないパス情報が返されるようにするには、/(スラッシュ)のサーブレット・マッピング文字列が出現するすべての箇所を/*に置換します。

Javaサーブレット仕様は、次の場所からダウンロードできます。

http://www.oracle.com/technetwork/java/javaee/servlet/index.html

Oracleの法律上の注意点

コピーライト

Copyright © 1994-2017, Oracle and/or its affiliates. All rights reserved.

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクルまでご連絡ください。

制限付権利について

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアまたはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアまたはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアまたはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle Corporationおよびその関連会社は一切の責任を負いかねます。

商標と登録商標について

OracleおよびJavaはオラクルおよびその関連会社の登録商標です。その他の社名、商品名等は各社の商標または登録商標である場合があります。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。適用されるお客様とOracle Corporationとの間の契約に別段の定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。適用されるお客様とOracle Corporationとの間の契約に定めがある場合を除いて、Oracle Corporationおよびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

Pre-General Availability (一般提供前)版のドキュメントについて

このドキュメントがPre-General Availability (一般提供前)版の場合:

このドキュメントはPre-General Availability (一般提供前)版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。Oracle Corporationおよびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。

非公開のPre-General Availability (一般提供前)版のドキュメントについて

このドキュメントが非公開のPre-General Availability (一般提供前)版の場合:

このドキュメントに含まれる情報は、情報の共有のみを目的としたものであって、顧客諮問委員会(Customer Advisory Board)のメンバーとしてのお客様の立場でのみ、またはお客様のPre-General Availability Trial Agreement (Pre-GAトライアル契約)のみに従って検討されるべきものとします。マテリアル、コード、または機能の提供をお約束するものではなく、購入決定を行う際の判断材料とすべきではありません。このドキュメントに記載されている特徴または機能の開発、リリースおよび時期については、オラクルの裁量により決定されます。

このドキュメントには、ソフトウェアまたは印刷物などの形式を問わず、オラクルが独占的な権利を有する財産的情報が含まれています。この機密資料へのアクセスと使用は、お客様とオラクルとの間で締結され、お客様が遵守に同意した、Oracle Master Agreement、Oracle License and Oracle Services Agreement (オラクル・ライセンスおよびサービスに関する契約書)、Oracle Partner Network Agreement、Oracle Distribution Agreementまたはその他のライセンス契約の条件に従うものとします。このドキュメントとその内容の開示、コピー、複製および配布には、オラクルによる事前の承諾を必要とします。このドキュメントはライセンス契約の一部となるものではなく、オラクルおよびその子会社や関連会社との契約を構成するものではありません。

ドキュメントのアクセシビリティ

オラクルのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

サポートをご契約のお客様には、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info)か、聴覚に障害のあるお客様は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。