Oracle WebLogic Serverアップグレード・ガイド

12c リリース1 (12.1.1)

B65938-02(原本部品番号:E24497-02)

目次

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

はじめに

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

- 表記規則

1 はじめに

- 重要な用語

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

- 始める前に

- アップグレード・ウィザードによる容易なアップグレード・プロセス

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

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

- アップグレードの計画

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

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

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

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

- アップグレードの準備

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

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

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

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

- ステップ5: リモートの管理対象サーバーのドメイン・ディレクトリの準備

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

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

- アップグレード後の手順の完了

- ステップ1: アプリケーション・インフラストラクチャのアップグレード

- 非推奨のweblogic.Adminユーティリティ

- WebLogic Scripting Toolの使用

- カスタム・ドメイン構成テンプレートのアップグレード

- SNMPを使用したWebLogic Serverのモニター

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

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

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

- ステップ3: ファイル権限の確認

- ステップ4: ノード・マネージャへのコンピュータの登録

- ステップ5: リモート・サーバー起動オプションの確認

- ステップ6: アプリケーション環境の本番環境へのプロモート

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

3 セキュリティ・プロバイダのアップグレード

- セキュリティ・プロバイダのアップグレードの仕組み

- セキュリティ・プロバイダのアップグレード

- セキュリティ・プロバイダのグラフィカル・モードでのアップグレード

- セキュリティ・プロバイダをアップグレードするため
グラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

- セキュリティ・プロバイダをアップグレードする手順

- セキュリティ・プロバイダのサイレント・モードでのアップグレード

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

- ノード・マネージャのアップグレードの仕組み

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

- ノード・マネージャのグラフィカル・モードでのアップグレード

- ノード・マネージャをアップグレードするため
グラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

- ノード・マネージャをアップグレードする手順

- ノード・マネージャのサイレント・モードでのアップグレード

5 WebLogicドメインのアップグレード

- WebLogicドメインのアップグレードの仕組み

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

- ドメインのアップグレード

- ドメインのグラフィカル・モードでのアップグレード

- ドメインをアップグレードするため
グラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

- WebLogicドメインをアップグレードする手順

- ドメインのサイレント・モードでのアップグレード

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

- アップグレードしたドメインでのPointBaseの使用

- アップグレードしたドメイン・データベースのDerbyへの移行

6 WebLogic Server 9.xまたは10.xアプリケーション環境から12.1.1へのアップグレード

- 新しいドメインの作成

- 既存のドメインの更新

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

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

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

- Jersey 1.9共有ライブラリを使用する
10.3.x RESTful Webサービスのアップグレード

- Jersey 1.1.5.1共有ライブラリを使用する
10.3.x RESTful Webサービスのアップグレード

- 9.2または10.xのWebLogic Webサービス(JAX-WSまたはJAX-RPC)の12.1.xへのアップグレード

- 9.0または9.1のWebLogic Webサービス(JAX-WSまたはJAX-RPC)の12.1.xへのアップグレード

- 8.1のWebLogic Webサービスの12.1.xへのアップグレード

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

- Javaクラス実装の8.1のWebLogic Webサービスの
12.1.xへのアップグレード: 主な手順

- EJB実装の8.1のWebLogic Webサービスの
12.1.xへのアップグレード: 主な手順

- servicegen属性とJWSアノテーションまたはjwsc属性のマッピング

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

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

- 非推奨になった機能

- 下位互換性フラグ

- JVMの設定

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

- permgen領域の設定

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

- Enterprise Java Beans (EJB)

- Webサービス

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

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

- 新しいWebサービス機能

- セキュリティ

- SSLサポートの変更

- Certicom SSLの実装

- SSLMBeanへの変更

- JSSEの導入

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

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

- SAML 2.0プロバイダ

- RDBMSセキュリティ・ストア

- 非推奨となったWindows NT認証プロバイダ

- SAML V2プロバイダ

- XACMLセキュリティ・プロバイダ

- セキュリティMBean

- パスワードの暗号化

- HTTPリクエストのセキュリティ

- MBeanHomeへのセキュア・アクセス

- Webサービスにおけるメッセージ・レベルのセキュリティ

- Webアプリケーション、JSP、およびサーブレット

- Coherenceのバージョン

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

- ActiveCache

- クラス・キャッシュ

- 下位互換性フラグ

- JSP 2.1のサポートとJSP 2.0 Webアプリケーションとの互換性

- JSP 2.0のサポート

- 保護されていないリソースを使用するBASIC認証

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

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

- JDBC機能の変更点

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

- セッション・アフィニティ・ポリシー

- 接続ラベリング

- ONSのデバッグ

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

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

- capacityIncrement属性

- JDBC 4.0サポート

- 更新されたWebLogicブランドのDataDirectドライバ

- JMS

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

- JMSリソースのモジュール式構成およびデプロイメント

- JMSメッセージID形式

- メッセージ・ページングの改善

- メッセージング

- weblogic.jms.extension APIの変更

- 永続ストアの更新

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

- JTA

- リソース登録名

- JTAトランザクション・ログの移行

- 管理コンソール

- コンソール構成機能

- 管理コンソールの拡張アーキテクチャ

- バージョン9.2のコンソール拡張に関する重要な情報

- 完全修飾する必要のあるWebLogic PortalスケルトンURI参照

- 使用されなくなったSNMP MIBリフレッシュ間隔とサーバー・ステータス・チェック間隔

- JMX 1.2実装

- JMXの非推奨になった機能

- WebLogicの管理および構成スクリプト

- 動的構成管理

- JDBCリソースのモジュール式構成およびデプロイメント

- JDBCデータ・ソースとJDBC接続プール

- マルチプール

- データ・ソース・ファクトリ

- スレッド管理

- XML実装

- XMLBeans実装とXQuery実装

- デプロイメント記述子の検証および変換

- 非推奨となった起動クラスと停止クラス

- リソース・アダプタ

- WLEC

B WebLogicドメイン・ディレクトリ構造の強化

- WebLogic Server 8.1のドメイン・ディレクトリ構造

C アップグレード・ウィザード・コマンド・ライン・リファレンス

- 例

D サイレント・アップグレード用XMLスクリプト・リファレンス

- サンプルXMLスクリプトの変更について

- セキュリティ・プロバイダのアップグレード・スクリプト

- ノード・マネージャのアップグレード・スクリプト

- ドメインのアップグレード・スクリプト

E 管理サーバー起動時におけるドメインのアップグレード(暗黙モード)

Oracle® Fusion Middleware

Oracle WebLogic Serverアップグレード・ガイド

12c リリース1 (12.1.1)

B65938-02(原本部品番号:E24497-02)

2012年1月

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

Oracle Fusion Middleware Oracle WebLogic Serverアップグレード・ガイド, 12cリリース1 (12.1.1)

B65938-02

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

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

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

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

U.S. GOVERNMENT RIGHTS Programs, software, databases, and related documentation and technical data delivered to U.S. Government customers are "commercial computer software" or "commercial technical data" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, the use, duplication, disclosure, modification, and adaptation shall be subject to the restrictions and license terms set forth in the applicable Government contract, and, to the extent applicable by the terms of the Government contract, the additional rights set forth in FAR 52.227-19, Commercial Computer Software License (December 2007).Oracle America, Inc., 500 Oracle Parkway, Redwood City, CA 94065.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(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 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 12cリリース1 (12.1.1)に移動するプロセスについて説明します。WebLogic Server 12.1.1へのアップグレード時にアプリケーションを変更すると判断する場合や、アプリケーションの変更が必須となる場合もありますが、このドキュメントでは、アプリケーションの変更を行わずにWebLogic Server 12.1.1へアプリケーションを移動する際に考慮が必要な問題について説明します。

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

注意:

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

WebLogicドメインは、必ずしもWebLogic Server 10.3から12.1.1にアップグレードする必要はありません。WebLogic Server 10.3をベースとするWebLogicドメインは、WebLogic Server 12.1.1でも修正なしで動作します。

WebLogic Server 12.1.1には、ドメイン、カスタム・セキュリティ・プロバイダ、およびカスタム・ノード・マネージャをアップグレードするWebLogicアップグレード・ウィザードなど、アプリケーション環境のアップグレードに役立つ強力なツールがあります。

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

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

- 重要な用語

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

- 始める前に

- アップグレード・ウィザードによる容易なアップグレード・プロセス

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

重要な用語

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

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

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

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

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

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

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

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

図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ドメインに関する項を参照してください。

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

カスタム・セキュリティ・プロバイダ

カスタム・セキュリティ要件をサポートします。カスタム・セキュリティ・プロバイダの開発については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

ドメイン内のすべてのコンピュータのカスタム・セキュリティ・プロバイダをアップグレードします。

ノード・マネージャ

管理対象サーバーで高可用性を実現します。ノード・マネージャの詳細は、Oracle WebLogic Serverのノード・マネージャ管理者ガイドのノード・マネージャの概要に関する項を参照してください。

ドメイン内のすべてのコンピュータのカスタム・ノード・マネージャをアップグレードします。

アプリケーション

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

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

外部リソース

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

すべての外部リソースがWebLogic Server 12.1.1と互換性があることを確認します。詳細については、『Oracle Fusion Middleware Supported System Configurations』(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)を参照してください。

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

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

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

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

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

始める前に

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

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

- アプリケーションのアップグレードでは通常、既存ドメインのアップグレードまたは新規ドメインの作成のどちらかを行います。このドメインから新バージョンのWebLogic Serverでアプリケーションを実行できます。ドメイン・アップグレード・ウィザードは、旧バージョンのWebLogic Serverから新バージョンのWebLogic Serverへのドメインのアップグレードをサポートしています。
ドメイン・アップグレード・ウィザードは、旧バージョンのWebLogic Serverから新バージョンのWebLogic Serverへドメインをアップグレードします。ドメインをアップグレードした場合、ドメイン構成を再作成する必要はなく、既存アプリケーションをサポートするために既知の既存ドメイン構成を利用できます。

ただし、アップグレードするアプリケーションをテストする目的のため、Fusion Middleware構成ウィザードまたは他の構成ツール(WLSTなど)を使用して、新規ドメインを作成する場合もあります。

- WebLogic Serverのバージョン・アップグレードを計画する際は、Fusion Middlewareのサポート対象システム構成ページ(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)を参照して、アップグレードされた環境がOracleでサポートされていることを、特に次の点について確認します。

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

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

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

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

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

- オラクル社は非推奨(つまり今後のリリースでは廃止予定)となったAPIおよび機能について文書化しており、現在も進行中です。この目的は、アップグレード性を維持するために使用を避けた方がいいAPIおよび機能について通知することです。現行のリリースで実際に廃止されているAPIおよび機能についても文書化されているため、以前のバージョンからアップグレードする場合は、対象のアプリケーションがアップグレードによる影響を受けるかどうかを判断できます。
APIおよび機能の廃止は累積方式です。たとえば、WebLogic Server 10.0からWebLogic Server 12.1.1にアップグレードする場合、アプリケーションはWebLogic Server 12.1.1で廃止された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.1.1へのアップグレード時にフィルタ・クラスローダーの使用を考慮する必要があります。このツールでは競合の特定、診断および解決が可能になり、アップグレード・プロセスも短縮される場合があります。

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

アップグレード・ウィザードによる容易なアップグレード・プロセス

WebLogicアップグレード・ウィザードは、WebLogic Server 8.1のドメインを、WebLogic Server 12.1.1アプリケーション環境で実行できるようアップグレードするために必要な手順を、ウィザードに従って進めることができます。アップグレード・プロセスの一部として、ドメインで使用されているカスタム・セキュリティ・プロバイダおよびノード・マネージャもアップグレードする必要があります。

また、WebLogicアップグレード・ウィザードを使用して、WebLogic Server 9.xまたは10.xと互換性のあるWebLogic Server 12.1.1ドメインにアップグレードすることもできますが、これは任意です。この種類のドメインは、変更せずにWebLogic Server 12.1.1で実行できます。

アップグレード・プロセスは、グラフィカル・ユーザー・インタフェース(GUI)を使用して対話形式で実行、またはスクリプトを作成してメッセージを通知しない形式で実行することができます。サイレント・モードは、WebLogicドメイン、セキュリティ・プロバイダ、およびノード・マネージャのアップグレードでサポートされています。

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

WebLogic Server 12.1.1で動作するアプリケーション環境は、WebLogic Server 8.1、9.x、10.0、または10.3で構築されたアプリケーション環境と相互運用できます。

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

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

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

ここで説明するトピックは以下のとおりです。

- アップグレードの計画

- アップグレードの準備

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

- アップグレード後の手順の完了

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

WebLogic 9.xまたは10.xからアップグレードする場合は、第6章「WebLogic Server 9.xまたは10.xアプリケーション環境から12.1.1へのアップグレード」を参照してください。

注意:

WebLogicドメインは、必ずしもWebLogic Server 10.3から12.1.1にアップグレードする必要はありません。WebLogic Server 10.3をベースとするWebLogicドメインは、WebLogic Server 12.1.1でも修正なしで動作します。

アップグレードの計画

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

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

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

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

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

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

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

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

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

- ドメインで使用されているカスタム・セキュリティ・プロバイダ

- ドメインで使用されているカスタム・ノード・マネージャ

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

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

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

- ファイアウォール

- ロード・バランサ

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

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

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

アプリケーション環境に含まれるすべてのハードウェアおよびソフトウェア・コンポーネントのサポート状況を確認します。表2-1に、サポート状況を確認する必要のある重要なコンポーネントを示します。

表2-1 サポート対象構成情報の確認

次を確認するには...

次を参照してください...

オペレーティング・システムとハードウェアのサポート

『Oracle Fusion Middleware Supported System Configurations』の、サポートされるオペレーティング・システム構成の一覧(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)

データベース・サポート

『Oracle Fusion Middleware Supported System Configurations』の、サポートされるデータベース構成

次の点に注意してください。

- WebLogic Server 12.1.1ではPointBase 5.7がサポートされますが、PointBaseは現在WebLogic Serverインストール・プログラムに含まれません。(WebLogic Serverサンプルを実行するためApache DerbyがPointBaseを置換。)
WebLogic Server 12.1.1へのアップグレードにはフル・インストーラを使用する必要があります。したがって、PointBaseインストール・ディレクトリは保存されません。PointBaseを継続して使用するには、a) ドメインをアップグレードした後で、「ステップ2: カスタマイゼーションを起動スクリプトに再適用する」に記載された手順を完了し、b) PointBaseライセンスをhttp://www.pointbase.comから取得します。「アップグレードしたドメインでのPointBaseの使用」も参照してください。

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

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

ドメイン・データベースをPointBaseからDerbyに移行する方法の詳細は、「アップグレードしたドメイン・データベースのDerbyへの移行」を参照してください。

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

- WebLogic jDriver for Oracleは、9.0で削除されています。ドメイン内のJDBC接続プールでデータベース接続を作成するのにWebLogic jDriverが使用されている場合、別のJDBCドライバを使用するには、アップグレードしたデータ・ソースを再構成する必要があります。たとえば、ドライバ・クラス名、データベースURLのフォーマット、データベース接続を作成するときにドライバに送信されるプロパティなどを変更する必要があります。代替ドライバとして、インストールに含まれているOracle Thin Driverを使用することや、仕様を実装しているスレッド・セーフなJDBCドライバを使用することができます。選択したドライバは、データ・ソースがデプロイされているすべてのサーバーで(CLASSPATH内に)インストールする必要があります。サポートされるJDBCドライバの詳細については、『Oracle Fusion Middleware Supported System Configurations』の「サポート対象のデータベース構成」(http://www.oracle.com/technology/software/products/ias/files/fusion_certification.html)を参照。

- Oracle 8.1.7 Oracle Thin Driver(oracle.jdbc.driver.OracleDriver)はWebLogic Server 10.xではサポートされていません。このドライバを使用するよう構成されたJDBCConnectionPoolsがドメインに含まれている場合、別のドライバを使用するように接続プールを再構成することをお薦めします。データベースのアップグレード中にこのドライバを使用すると、ドメインのアップグレードに失敗します。

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

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

- Oracle用のWebLogicタイプ4 JDBCドライバ(非推奨)とOracle Thin DriverはWebLogic Serverと共にインストールされており、すぐに使用することができます。これらのドライバの使用方法については、『Oracle WebLogic Serverタイプ4 JDBCドライバ』のWebLogicタイプ4 JDBCドライバの使い方に関する項と、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のWebLogic Serverでインストールされるサード・パーティJDBCドライバに関する項を参照してください。

Webサーバー、ブラウザ、およびファイアウォール

『Oracle Fusion Middleware Supported System Configurations』のサポートされるWebサーバー、ブラウザ、およびファイアウォール

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

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

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

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

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

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

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

- WebLogic以外のXA対応JMSプロバイダによって駆動されるトランザクション対応のメッセージドリブンBean (MDB)を使用している場合は、サーバーを停止およびアップグレードする前に、仕掛かり中のすべてのトランザクションを安全に休止させる必要があります。仕掛かり中のトランザクションをアップグレード後に回復することはできません。メッセージドリブンBeanの詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のメッセージドリブンEJBに関する項を参照してください。

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

アップグレードの準備

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

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

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

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

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

- ステップ5: リモートの管理対象サーバーのドメイン・ディレクトリの準備

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

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

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

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

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

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

アップグレード・プロセスの途中で、ドメインをバックアップするかどうかを選択できます(「WebLogicドメインをアップグレードする手順」の「ドメインのバックアップ」を参照)。ただし、ウィザードはドメイン・ディレクトリのみをアーカイブするため、ファイル権限は維持されません。

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

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

コンポーネント

推奨事項

ドメイン・ディレクトリ

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

デフォルトでは、ドメイン・ディレクトリは構成ウィザードにより{MW_HOME\user_projectsディレクトリ(MW_HOMEはWebLogic ServerがインストールされているMiddlewareホーム・ディレクトリ)に作成されます。

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

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

デフォルトでは、アプリケーションはMW_HOME\user_projects\applicationsディレクトリ(MW_HOMEはWebLogic ServerがインストールされているMiddlewareホーム・ディレクトリ)に作成されます。この場所は、10.3.1より前のリリースではBEAホーム・ディレクトリと呼ばれていました。

カスタム・セキュリティ・プロバイダ

アプリケーション環境で使用しているカスタム・セキュリティ・プロバイダをすべてバックアップします。

デフォルトでは、セキュリティ・プロバイダはWL_HOME\server\bin\mbeantypes(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)に格納されています。

ノード・マネージャのディレクトリおよびスクリプト

クラスタリング環境内のサーバーを管理するのに使用しているノード・マネージャのディレクトリおよびスクリプトをすべてバックアップします。

ディレクトリ名とスクリプト名は、ご使用のオペレーティング・システムによって異なります。

- Windows:

WL_HOME\common\nodemanager
WL_HOME\server\bin\startNodeManager.cmd

- UNIX:

WL_HOME/common/nodemanager
WL_HOME/server/bin/startNodeManager.sh

上記パス名において、WL_HOMEは、WebLogic Serverのインストール先のルート・ディレクトリ(例: c:\Oracle\Middleware\wlserver_12.1)を表します。

ログ・ファイル

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

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

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

注意:

インストールを進める前に次の項目に注意してください。

- 10.0より前のバージョンでノード・マネージャを使用している場合は、12.1.1製品をインストールするときに、ノード・マネージャのリスン・ポートを、10.0より前のバージョンで使用されているポートと同じ番号に設定するようにしてください。ノード・マネージャのリスニング・ポートのデフォルト値は5556です。

- PointBaseを使用している既存のドメインがあり、WebLogic Server 12.1.1へのアップグレード後もそのドメインでPointBaseを引き続き使用する予定の場合、PointBaseインストールは保存されません。詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください。

ステップ5: リモートの管理対象サーバーのドメイン・ディレクトリの準備

構成によっては、ドメイン内で管理サーバーからリモートの管理対象サーバーが1つまたは複数のマシンで実行されていることがあります。このタイプの構成の場合、リモートの管理対象サーバーをホストするすべてのマシンのドメイン・ディレクトリをアップグレードする必要があります。

リモートのドメイン・ディレクトリを準備するには、管理サーバーのホスト・コンピュータ上にあるアップグレード前のドメイン・ディレクトリのルート・ディレクトリから次のファイルをリモートの管理対象サーバーのホスト・ドメインのルート・ディレクトリにコピーする必要があります。

- config.xml(構成ファイル)

- SerializedSystemIni.dat

注意:

構成内のデータベースがWebLogic Server 12.1.1と互換性がない場合、サポートされているデータベースにデータをアップグレードしなければ、新しいアプリケーション環境でデータを使用できません。詳細については、「ステップ4: アップグレード計画の作成」を参照してください。

ステップ6: 環境の設定

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

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

2. WebLogic ServerクラスをCLASSPATH環境変数に、WL_HOME\server\binをPATH環境変数に追加します。WL_HOMEはWebLogic Server 12.1.1のインストール先の最上位ディレクトリです。
WL_HOME\server\bin\setWLSEnvスクリプトを実行すると、これらの変数を設定できます。

3. JMS JDBCストアを使用する場合は、次の手順に従います。

1. JDBCドライバ・クラスがCLASSPATH環境変数に追加されていることを確認します。

2. 対応するデータベースを起動します。

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

図2-1に、アプリケーション環境をアップグレードするのに必要な手順を示します。

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

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

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

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

ステップ

タスク

説明

1

カスタム・セキュリティ・プロバイダのアップグレード

WebLogic Server 8.1からのアップグレードで、現在のアプリケーション環境でカスタム・セキュリティ・プロバイダを使用しており、新しいアプリケーション環境でもそれを継続して使用する場合は、次の要件に従ってカスタム・セキュリティ・プロバイダをアップグレードします。

- アプリケーション環境内のすべてのマシンでアップグレードする

- WebLogicドメインをアップグレードする前にアップグレードする

注意: 9.0より前のバージョンのWebLogic ServerがインストールされているディレクトリにWebLogic Server 12.1.1をインストールすると、デフォルトの場所(WL_HOME\server\lib\mbeantypes)にあるすべてのカスタム・セキュリティ・プロバイダは自動的にアップグレードされます。すべてのカスタム・セキュリティ・プロバイダがデフォルトの場所に格納されている場合は、セキュリティ・プロバイダのアップグレードが完了していることを意味するため、ここで説明するセキュリティ・プロバイダのアップグレード手順を実行する必要はありません。

2

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

現在、管理対象サーバーで高可用性を実現するため、カスタマイズ・バージョンのノード・マネージャを使用しており、新しいアプリケーション環境でもそれを継続して使用する場合は、次の要件に従ってノード・マネージャをアップグレードします。

- アプリケーション環境内のすべてのマシンでアップグレードする

- アップグレードしたWebLogicドメインでサーバーを起動する前にアップグレードする

3

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

管理サーバーをホストするコンピュータ上のWebLogicドメインをアップグレードします。

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

4

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

管理対象サーバーをホストするすべてのコンピュータ上のWebLogicドメインをアップグレードします。「ステップ5: リモートの管理対象サーバーのドメイン・ディレクトリの準備」で説明されているように、アップグレードを実行する前に、必要なファイルが管理対象サーバーにコピーされていることを確認してください。

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

アップグレード後の手順の完了

WebLogicアップグレード・ウィザードを使用してアプリケーション環境のアップグレードが完了したら、必要に応じて次の手順を実行する必要があります。

- ステップ1: アプリケーション・インフラストラクチャのアップグレード (WebLogic Server 9.1以下のリリースからのアップグレードや、weblogic.Adminユーティリティを現在も使用中の場合のみ)

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

- ステップ3: ファイル権限の確認

- ステップ4: ノード・マネージャへのコンピュータの登録

- ステップ5: リモート・サーバー起動オプションの確認

- ステップ6: アプリケーション環境の本番環境へのプロモート

必ずしもすべての手順を実行する必要があるわけではありません。以下の説明に基づいて、アプリケーション環境に必要な手順を決定してください。

ステップ1: アプリケーション・インフラストラクチャのアップグレード

この項は、WebLogic Server 9.1以下のリリースからアップグレードする場合や、weblogic.Adminユーティリティを現在も使用中の場合のみ、該当します。それ以降のリリースからアップグレードする場合や、すでにWebLogic Scripting Toolに移行済みの場合は、このステップをスキップできます。

MBeanの階層構造に最近加えられた変更により、既存の構成および管理スクリプト(WLST、wlconfig、weblogic.Admin、Antなど)は9.2より前の環境で必ずしも動作しない可能性があります。WebLogic Server 9.2、10.0、10.3、および12.1.1の新しい機能を利用するようにスクリプトを更新することをお薦めします。リリース9.2以降の各リリースで導入されたMBeanにおける新しいWebLogic Server機能と変更の詳細は、「WebLogic管理と構成スクリプト」を参照してください。

次の項では、スクリプト・ツール、カスタム・ドメイン・テンプレート、およびSNMPについて詳しく説明します。

- 非推奨のweblogic.Adminユーティリティ

- WebLogic Scripting Toolの使用

- カスタム・ドメイン構成テンプレートのアップグレード

- SNMPを使用したWebLogic Serverのモニター

非推奨のweblogic.Adminユーティリティ

weblogic.AdminユーティリティはWebLogic Server 9.0以降で非推奨となりました。詳細は、Oracle WebLogic Serverのコマンド・リファレンスのweblogic.Serverコマンドライン・リファレンスに関する項を参照してください。weblogic.Adminユーティリティを現在使用中の場合は、次の項で説明するように、Oracle WebLogic Scripting Toolを使用することをお薦めします。

WebLogic Scripting Toolの使用

WebLogic Scripting Tool (WLST)は、コマンド・ライン形式のスクリプト・インタフェースで(Jythonで構築)、WebLogicドメインの構成に使用することができます。WLSTを使用することで、WebLogic Server管理者は、対話形式で、または実行可能なスクリプトにより、管理タスクを実行し、WebLogic Server構成の変更を開始することができます。

WLST OnlineとWLST Offlineは1つのツールとして提供されます。WLSTでは、12.1.1が提供する管理機能と構成機能が完全にサポートされています。WLSTの詳細は、『Oracle WebLogic Scripting Tool』を参照してください。

MBeanの階層構造に最近加えられた変更により、既存の9.2より前のWLSTスクリプトは、9.2より前の他のツールと同様に、9.2または10.xで動作しない可能性があります。これらのスクリプトは、WebLogic Server 9.2、10.0、10.3、および12.1.1の新しい機能を利用するように更新することをお薦めします。

リリース9.2以降の各リリースで導入されたMBeanにおける新しいWebLogic Server機能と変更の詳細は、「WebLogic管理と構成スクリプト」を参照してください。

カスタム・ドメイン構成テンプレートのアップグレード

表2-4は、Template Builderで作成されたカスタム・ドメイン・テンプレートまたは拡張テンプレートをアップグレードするのに必要な手順の概要を示しています。

表2-4 カスタム・ドメイン・テンプレートのアップグレード手順

ステップ

タスク

詳細情報

1

アップグレード・ウィザードを使用して、カスタム・ドメイン・テンプレートまたは拡張テンプレートで作成されたドメインをアップグレードします。

「アプリケーション環境のアップグレード」の手順に従います。

2

必要に応じて新機能を活用できるようドメインを修正します。

『Oracle WebLogic Serverの新機能』を参照してください。リリース9.2以降のWebLogic Server各リリースで導入された機能については、表A-4を参照してください。

3

Template Builderまたはpackコマンドを使用して、12.1.1のドメインまたは拡張テンプレートを作成します。

参照:

- 『ドメイン・テンプレート・ビルダーによるドメイン・テンプレートの作成』

- 『PackおよびUnpackコマンドによるテンプレートとドメインの作成』

SNMPを使用したWebLogic Serverのモニター

SNMPマネージャを使用してWebLogic Serverをモニターする場合は、次の手順に従います。

1. WebLogic Server 12.1.1 MIBをSNMPマネージャにロードします。
MIBは、WL_HOME/server/lib/BEA-WEBLOGIC-MIB.asn1にあります。WebLogic Serverは、既存の管理対象オブジェクトのオブジェクト識別子(OID)を変更するのではなく、新しい管理対象オブジェクトの新しいOIDを追加します。

2. 非推奨の管理対象オブジェクトのトラップを生成する場合は、置換オブジェクトのトラップを新規作成します。
非推奨の管理対象オブジェクトの一覧については、Oracle WebLogic Server MBeanリファレンスの非推奨のMBeanに関する項を参照してください。非推奨のMBeanの説明には、置換MBeanへのポインタも含まれています。SNMPの管理対象オブジェクトはそれぞれMBean属性に対応します。

注意:

WebLogic Server 9.0から、多数のOracle専用の実行時MBeanがMIBから削除されています。これらのMBeanは、非推奨のMBeanの一覧に含まれていません。詳細は、WebLogic Server 9.0確認済みおよび解決済みの問題のJMXの問題に関する項を参照してください。

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

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

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

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

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

注意:

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

カスタム起動スクリプト

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

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

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

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

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

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

ステップ3: ファイル権限の確認

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

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

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

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

ステップ4: ノード・マネージャへのコンピュータの登録

アップグレード・プロセス中にノード・マネージャをアップグレードする場合は、WebLogicドメインをホストしているコンピュータをノード・マネージャに登録する必要があります。これを実行するには、nmEnrollコマンドを使用します。

注意:

管理サーバーと管理対象サーバーが実行されるよう構成されているコンピュータにnodemanager.domainsファイルがあり、管理サーバーと管理対象サーバーが同じドメイン・ディレクトリを共有している場合は、手動でそのドメインのエントリを<domain-name>=<domain-directory>という形式でファイルに含めることができます。

デフォルトでは、このファイルはWL_HOME/common/nodemanager(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)にあります。

ノード・マネージャの詳細は、『Oracle WebLogic Serverノード・マネージャ管理者ガイド』の「ノード・マネージャの一般的な構成」にある、nodemanager.domainsファイルの構成に関する項を参照してください。

nmEnrollコマンドを実行すると、WL_HOME/common/nodemanagerディレクトリ(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)にあるnodemanager.domainsファイルのドメインに関する情報が更新されます。nodemanager.domainsファイルには、ノード・マネージャ・インスタンスが制御するドメインを指定します。このファイルを使用することにより、スタンドアロン・クライアントでドメイン・ディレクトリを明示的に指定する必要がなくなります。

また、このコマンドを実行すると、管理サーバーから次のファイルがダウンロードされます。

- nm_password.properties(サーバー認証に使用される暗号化されたユーザー名とパスワードが含まれるノード・マネージャ秘密ファイル)

- SerializedSystemIni.datファイル

nmEnrollコマンドを使用してコンピュータをノード・マネージャに登録するには:

1. 『Oracle WebLogic Scripting Tool』の環境の設定に関する項の説明に従って、環境を設定します。

2. 『Oracle WebLogic Scripting Tool』のWLSTの呼出しに関する項の説明に従って、WLSTを呼び出します。
ステップ2の説明に従って、WebLogic Serverインスタンスを起動し、connectコマンドを使用してWLSTをサーバーに接続します。

3. WLSTが管理サーバーに接続されると、nmEnrollコマンドを入力して、WLSTを実行するコンピュータをノード・マネージャに登録します。
以下の情報を指定できます。

- ノード・マネージャ秘密ファイル(nm_password.properties)とSerializedSystemIni.datファイルの保存先のドメイン・ディレクトリのパス。デフォルトでは、この2つのファイルは、起動したWLSTが格納されているディレクトリに保存されます。

- ノード・マネージャのホーム・ディレクトリのパス。ドメインに関する情報を含むnodemanager.domainsファイルは、このディレクトリに保存されます。デフォルトでは、WL_HOME/common/nodemanager(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)です。
たとえば、ドメイン・ディレクトリがc:/bea/mydomain/common/nodemanagerに指定されており、ノード・マネージャのデフォルトのホーム・ディレクトリ(WL_HOME/common/nodemanager)が使用されている場合、WLSTが実行されているコンピュータをノード・マネージャに登録するには、次のコマンド(太字部分)を使用します。

wls:/mydomain/serverConfig> nmEnroll('c:/bea/mydomain/common/nodemanager')
Enrolling this machine with the domain directory at c:\bea\mydomain\common\nodemanager....
Successfully enrolled this machine with the domain directory at C:\bea\mydomain\common\nodemanager
wls:/mydomain/serverConfig>

詳細は、WebLogic Scripting Toolのコマンド・リファレンスのnmEnrollに関する項を参照してください。

ステップ5: リモート・サーバー起動オプションの確認

管理サーバーを起動したら、JAVA_HOME、MW_HOME、BEA_HOME、CLASSPATHなどのリモート・サーバー起動オプションが、ターゲットの管理対象サーバーにインストールされているWebLogic Server 12.1.1を参照していることを確認します。これは管理コンソールを使用して行います。詳細は、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
at COM.jrockit.io.FileNativeIO.read(III)I(Native Method)
at COM.jrockit.io.NativeIO.read(Ljava.io.FileDescriptor;II)I(Unknown Source)
at COM.jrockit.io.NativeIOInputStream.read(II)I(Unknown Source)
at COM.jrockit.io.NativeIOInputStream.read(I[BI)I(Unknown Source)
at COM.jrockit.io.NativeIOInputStream.read([BII)I(Unknown Source)
at java.io.FileInputStream.read([BII)I(Unknown Source)

ステップ6: アプリケーション環境の本番環境へのプロモート

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

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

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

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

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

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

2. WebLogicアップグレード・ウィザードにより報告された障害を修正します。

3. 「アプリケーション環境のアップグレード」の説明に従って、障害が発生した手順からアップグレード・プロセスを続行します。

このページのスクリプトは、ナビゲーション目的のみのもので、内容を変更しません。

3 セキュリティ・プロバイダのアップグレード

WebLogic Server 8.1環境でカスタム・セキュリティ・プロバイダを使用している場合、WebLogicアップグレード・ウィザードを使用して、セキュリティ・プロバイダをWebLogic Server 12.1.1のアプリケーション環境で使用できるようアップグレードすることができます。

注意:

WebLogic Server 9.1には、XACML認可プロバイダおよびXACMLロール・マッピング・プロバイダという2つの新しいセキュリティ・プロバイダが含まれています。既存のWebLogicドメインを12.1.1にアップグレードして、現在指定されている認可プロバイダおよびロール・マッピング・プロバイダ(サード・パーティ・パートナのプロバイダ、オリジナルのWebLogic認可プロバイダおよびロール・マッピング・プロバイダなど)を引き続き使用できます。WebLogic Server独自のプロバイダを使用している既存ドメインを、必要に応じてXACMLプロバイダに移行することもできます(既存ポリシーのバルク・インポートも含む)。詳細は、『Oracle WebLogic Serverの理解』のWebLogic Serverのセキュリティの理解に関する項を参照してください。

次の項では、WebLogicアップグレード・ウィザードを使用してセキュリティ・プロバイダをアップグレードする方法について説明します。

- セキュリティ・プロバイダのアップグレードの仕組み

- セキュリティ・プロバイダのアップグレード

カスタム・セキュリティ・プロバイダの開発については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。

セキュリティ・プロバイダのアップグレードの仕組み

セキュリティ・プロバイダをアップグレードする場合、アップグレード元のディレクトリとアップグレード先のディレクトリを指定すると、WebLogicアップグレード・ウィザードが既存のJARをアップグレードします。これにより、セキュリティ・プロバイダはWebLogic Server 12.1.1のアプリケーション環境で実行可能となります。

注意:

セキュリティ・プロバイダJARには、MBeanを定義するMBean定義ファイル(MDF)が含まれていなければなりません。MDFは、特定のMBeanタイプの.javaファイルを生成するために使用されます。MDFの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。MDFがJARファイルに含まれていない場合、当該セキュリティ・プロバイダのアップグレード・プロセスは正常に実行されません。

MDFに未登録のタグがある場合は、アップグレード・プロセス中に警告が表示されます。これらの警告はアップグレードに影響しないので無視してかまいません。ただし、MDFから未登録のタグを削除して、この警告が表示されないようにすることをお薦めします。

9.2より前の構成で定義されているセキュリティ・レルムでは、ロックアウト・マネージャ(UserLockoutManagerMBean)が定義されていなければなりません。また、これらのセキュリティ・レルムは、JMXオブジェクトのネーミング・ルール(Security:Name=name)に準拠していなければなりません。これらの条件が満たされていない場合、当該セキュリティ・プロバイダのアップグレード・プロセスは正常に実行されません。

アップグレード中、アップグレード・ウィザードは次のタスクを実行します。

- セキュリティ・プロバイダJARに必要なクラスを追加する(MBeanImpl要素やスキーマ・ファイルなど)

- MDFを読み込み、必要なスキーマ、MBean実装、およびBinderクラスを作成します。

- 当該セキュリティ・プロバイダのアップグレードされたJARを指定した場所に格納します。

- アップグレードされたJARが既存のセキュリティ・プロバイダJARと区別されるようセキュリティ・プロバイダ名に_Upgradedを付加します。

- Oracle製品に付属のセキュリティ・プロバイダJARまたは名前に_Upgradedが付加されているアップグレード済みのJARを無視します。

セキュリティ・プロバイダのアップグレード

WebLogic Server 12.1.1環境で実行する各カスタム・セキュリティ・プロバイダをアップグレードする必要があります。

注意:

WebLogic Server 12.1.1をWebLogic Server 8.1がインストールされている既存のホーム・ディレクトリ脚注 1 にインストールする場合、デフォルトの場所WL_HOME\server\lib\mbeantypes(WL_HOMEは、9.0より前のバージョンのインストール先のルート・ディレクトリ)にあるすべてのカスタム・セキュリティ・プロバイダは自動的にアップグレードされます。すべてのカスタム・セキュリティ・プロバイダがデフォルトの場所に格納されている場合は、ここで説明するセキュリティ・プロバイダのアップグレード手順を実行する必要はありません。

脚注 1 この場所は、10.3.1より前のリリースのWebLogic ServerではBEAホーム・ディレクトリと呼ばれていました。リリース10.3.1からは、この場所をMiddlewareホーム・ディレクトリと呼び、MW_HOME変数で表すことになりました。

カスタム・セキュリティ・プロバイダがアップグレードされたかどうかを確認するには、WL_HOME\server\lib\mbeantypesディレクトリ(WL_HOMEは12.1.1インストールのルート・ディレクトリ)の、アップグレードされたセキュリティ・プロバイダsecurity_provider_name_Upgraded(security_provider_nameはセキュリティ・プロバイダの名前)を確認します。

WebLogicアップグレード・ウィザードでは、次のどちらかのモードでセキュリティ・プロバイダをアップグレードすることができます。

- グラフィカル - グラフィカル・ユーザー・インタフェースを使用して対話形式でセキュリティ・プロバイダをアップグレードする場合。

- サイレント - アップグレード要件をファイルで指定してバックグラウンドでセキュリティ・プロバイダをアップグレードする場合。

ドメイン内の各コンピュータのセキュリティ・プロバイダをアップグレードする必要があります。

次の項では、セキュリティ・プロバイダをアップグレードする方法について説明します。

- セキュリティ・プロバイダのグラフィカル・モードでのアップグレード

- セキュリティ・プロバイダのサイレント・モードでのアップグレード

セキュリティ・プロバイダのグラフィカル・モードでのアップグレード

次の項では、グラフィカル・モードでWebLogicアップグレード・ウィザードを使用してセキュリティ・プロバイダをアップグレードする方法について説明します。

- セキュリティ・プロバイダをアップグレードするためグラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

- セキュリティ・プロバイダをアップグレードする手順

注意:

グラフィカル・モードでアップグレード・ウィザードを実行するために使用するコンソールでは、JavaベースのGUIがサポートされていなければなりません。グラフィカル表示をサポートしていないシステム上でアップグレード・ウィザードをグラフィカル・モードで起動しようとすると、エラー・メッセージが表示されます。

セキュリティ・プロバイダをアップグレードするため
グラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

注意:

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

グラフィカル・モードでWebLogicアップグレード・ウィザードを起動してセキュリティ・プロバイダをアップグレードするには:

1. WebLogicドメインが稼働していないことを確認します。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

3. コマンド・プロンプトで、次のコマンドを入力します。

java weblogic.Upgrade -type securityproviders [-out file]

-out引数は省略可能です。これにより、すべての標準出力(stdout)とエラー・メッセージが書き込まれるファイルを指定することができます。デフォルトでは、これらのメッセージはコマンド・ウィンドウに書き込まれ、アップグレード・プロセスの終了時にそのサマリーが表示されます。このコマンドを実行すると、図3-1のようにWebLogicアップグレード・ウィザードが起動します。

図3-1 セキュリティ・プロバイダのWebLogicアップグレード・ウィザード

「図3-1 セキュリティ・プロバイダのWebLogicアップグレード・ウィザード」の説明

4. 「次へ」をクリックして、「アップグレード元のディレクトリの選択」ウィンドウに進みます。

セキュリティ・プロバイダをアップグレードする手順

表3-1に、WebLogicアップグレード・ウィザードを使用してセキュリティ・プロバイダをアップグレードする手順の概要を示します。

表3-1 セキュリティ・プロバイダをアップグレードする手順

手順

実行する操作

アップグレード元のディレクトリの選択

アップグレードする必要のあるセキュリティ・プロバイダJARが格納されているディレクトリを選択します。デフォルトでは、選択したディレクトリがカレント・ディレクトリです。

デフォルトでは、セキュリティ・プロバイダはWL_HOME\server\lib\mbeantypes(WL_HOMEはWebLogic Server 9.0より前のインストール先のルート・ディレクトリ)に格納されています。

注意: セキュリティ・プロバイダJARには、関連付けられているMBeanのMBean定義ファイル(MDF)が含まれている必要があります。MDFの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。JARファイルにMDFがない場合、関連付けられているセキュリティ・プロバイダのアップグレード・プロセスは正常に実行されません。

「次へ」をクリックして、「アップグレード先のディレクトリの選択」ウィンドウに進みます。

アップグレード先のディレクトリの選択

新しいセキュリティ・プロバイダJARファイルの保存先のディレクトリを選択します。デフォルトのディレクトリはWL_HOME\server\lib\mbeantypes(WL_HOMEはWebLogic Server 12.1.1のインストール先のルート・ディレクトリ)です。

注意: ドメインのアップグレードが確実に実行されるようにするには、アップグレードされたセキュリティ・プロバイダがデフォルトの保存先ディレクトリ(WL_HOME\server\lib\mbeantypes)に保存されるよう指定する必要があります。セキュリティ・プロバイダを別の場所に保存する必要がある場合は、ドメインのアップグレード・プロセスが完了してから、別の場所に移動できます。

「次へ」をクリックして、次のウィンドウに進みます。

セキュリティ・プロバイダのアップグレード進行中

ウィザードの進行状況(アップグレードされたJARの保存やアップグレード・プロセス中に作成された一時ファイルの削除)を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

セキュリティ・プロバイダJARには、関連付けられているMBeanのMBean定義ファイル(MDF)が含まれている必要があります。MDFの作成については、『Oracle WebLogic Serverセキュリティ・プロバイダの開発』を参照してください。JARファイルにMDFがない場合、関連付けられているセキュリティ・プロバイダのアップグレード・プロセスは正常に実行されません。例:

Now processing mySecurityProviderToo.jar ...
No MDFs (.xmls) found in the old security provider jar with
name mySecurityProviderToo.jar

MDFに未登録のタグがある場合は、アップグレード・プロセス中に警告が表示されます。この警告はアップグレードに影響しないので無視して構いません。ただし、MDFから未登録のタグを削除して、このメッセージが表示されないようにすることを薦めます。

ウィザードが製品と共にインストールされたセキュリティ・プロバイダJAR、すでにアップグレードされているセキュリティ・プロバイダJAR、または無効なセキュリティ・プロバイダJARを検出した場合、そのJARはアップグレードされません。例:

Not upgrading foo.txt because either this is a Out of the Box
Oracle Security Provider jar or this Security Provider jar is
already upgraded or this is not a valid archive (may be not a .jar)

「次へ」をクリックして、次のウィンドウに進みます。

アップグレード完了

アップグレードが完了したら表示されるアップグレード結果を確認します(さらなる検討を要する重要なメッセージなど)。

「完了」をクリックしてウィザードを閉じます。

セキュリティ・プロバイダのサイレント・モードでのアップグレード

たとえば、セキュリティ・プロバイダがリモート・コンピュータにある場合などに、WebLogicアップグレード・ウィザードをグラフィカル・モードで使用するのは合理的ではありません。このような場合、ウィザードをサイレント・モードで使用して、セキュリティ・プロバイダをアップグレードすることができます。

注意:

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

サイレント・モードでWebLogicアップグレード・ウィザードを起動してセキュリティ・プロバイダをアップグレードするには:

1. WebLogicドメインが稼働していないことを確認します。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

3. (オプション)アップグレード要件を定義するXMLスクリプトを作成します。詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

4. アップグレードするセキュリティ・プロバイダが格納されているディレクトリに移動します。

5. コマンド・プロンプトで、次のコマンドを入力します。

java weblogic.Upgrade -mode silent -type securityproviders [-responses xmlfile] [-out file]

-responses引数と-out引数は省略可能です。これらの引数は、次の設定のデフォルト値をオーバーライドする場合に含めます。

- アップグレード要件を定義するXMLファイルの場所。-responses引数でファイルを指定しない場合、ウィザードはデフォルト値をアップグレード・プロセスで使用します。XMLファイルの形式とデフォルト値の詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

- すべての標準出力(stdout)とエラー・メッセージが書き込まれる出力ファイル。-out引数でファイルを指定しない場合、これらのメッセージはコマンド・ウィンドウに書き込まれます。

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

10.xより前の環境でカスタマイズ・バージョンのノード・マネージャを使用している場合、WebLogicアップグレード・ウィザードを使用して、ノード・マネージャをWebLogic Server 12.1.1のアプリケーション環境で使用できるようアップグレードできます。

次の項では、この目的のためのWebLogicアップグレード・ウィザードの使用方法について説明します:

- ノード・マネージャのアップグレードの仕組み

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

注意:

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

ノード・マネージャの詳細は、Oracle WebLogic Serverのノード・マネージャ管理者ガイドのノード・マネージャの概要に関する項を参照してください。

ノード・マネージャのアップグレードの仕組み

ノード・マネージャのアップグレードでは、アップグレードするノード・マネージャのホーム・ディレクトリを指定します。WebLogicアップグレード・ウィザードは次のタスクを実行します。

- ノード・マネージャがWebLogic Server 12.1.1のアプリケーション環境で実行されるよう、指定されたディレクトリにあるノード・マネージャをアップグレードします。アップグレード・ウィザードはnodemanager.propertiesファイルをアップグレードしてNodeManagerSerializedSystemIni.datをnm_data.propertiesに変換します。

注意:

nodemanager.propertiesファイルは書込み可能にしてください。

- 既存のログと状態管理ファイルのバックアップを作成し、weblogic-nodemanager-backup.zipという名前のzipファイルに保存します。

既存のノード・マネージャ・ファイルは、アップグレード・プロセス中にすべて上書きされます。

ドメインをアップグレードするときに、ノード・マネージャの認可に使用されるユーザー名とパスワードを指定するよう求められます。詳細については、表5-1の「ノード・マネージャ資格証明の入力」を参照してください。任意の9.0以前のインストールからWebLogic Server 12.1.1にアップグレードする場合、ノード・マネージャによって使用されるリスニング・ポート番号は、アップグレード・プロセス中に保持されます。

注意:

12.1.1製品をインストールするとき、ノード・マネージャのリスニング・ポートを9.0より前のバージョンで使用されているリスニング・ポートと同じ番号に設定するようにしてください。ノード・マネージャのデフォルトのリスニング・ポート番号は5556です。

アップグレード・プロセスが完了したら、次のタスクを実行します。

- 「ステップ4: ノード・マネージャへのコンピュータの登録」の説明に従って、コンピュータをノード・マネージャに登録します。

- ノード・マネージャのユーザー名、パスワード、およびリスニング・ポートが適切に設定されていることを確認します。

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

WebLogic Server 12.1.1環境で実行する各ノード・マネージャ・インスタンスをアップグレードする必要があります。具体的には、ドメイン内のすべてのコンピュータのノード・マネージャをアップグレードする必要があります。WebLogicアップグレード・ウィザードでは、次のどちらかのモードでアップグレードを実行することができます。

- グラフィカル - グラフィカル・ユーザー・インタフェースを使用して対話形式でノード・マネージャをアップグレードする場合

- サイレント - アップグレード要件をファイルで指定してバックグラウンドでノード・マネージャをアップグレードする場合

ドメイン内の各コンピュータのノード・マネージャをアップグレードする必要があります。

次の項では、ノード・マネージャをアップグレードする方法について説明します。

- ノード・マネージャのグラフィカル・モードでのアップグレード

- ノード・マネージャのサイレント・モードでのアップグレード

ノード・マネージャのグラフィカル・モードでのアップグレード

次の項では、グラフィカル・モードでWebLogicアップグレード・ウィザードを使用してノード・マネージャをアップグレードする方法について説明します。

- ノード・マネージャをアップグレードするためグラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

- ノード・マネージャをアップグレードする手順

注意:

グラフィカル・モードでアップグレード・ウィザードを実行するために使用するコンソールでは、JavaベースのGUIがサポートされていなければなりません。グラフィカル表示をサポートしていないシステム上でアップグレード・ウィザードをグラフィカル・モードで起動しようとすると、エラー・メッセージが表示されます。

ノード・マネージャをアップグレードするため
グラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

注意:

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

グラフィカル・モードでWebLogicアップグレード・ウィザードを起動してノード・マネージャをアップグレードするには:

1. WebLogicドメインが稼働していないことを確認します。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

3. ノード・マネージャ・ディレクトリが10.0より前のバージョンのインストール・ディレクトリ、たとえばデフォルトのディレクトリであるWL_HOME/common/nodemanager(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)にある場合は、そのノード・マネージャ・ディレクトリの内容を、次に示す12.1.1のインストール・ディレクトリにコピーします。

MW_HOME/wlserver_12.1/common/nodemanager

この場合、12.1.1のインストール・ディレクトリにある、ノード・マネージャのコピーをアップグレードする必要があります。

注意:

現在のディレクトリ構造は維持されなければなりません。ログ・ファイル(.log)を新しい場所にコピーする必要はありません。

ノード・マネージャ・ディレクトリが10.0より前のバージョンのインストール先のディレクトリにない場合は、この手順を省略することができます。

4. コマンド・プロンプトで、次のコマンドを入力します。

java weblogic.Upgrade -type nodemanager [-out file]

-out引数は省略可能です。これにより、すべての標準出力(stdout)とエラー・メッセージが書き込まれるファイルを指定することができます。デフォルトでは、これらのメッセージはコマンド・ウィンドウに書き込まれ、アップグレード・プロセスの終了時にそのサマリーが表示されます。

このコマンドを実行すると、図4-1のようにWebLogicアップグレード・ウィザードが起動します。

図4-1 ノード・マネージャのWebLogicアップグレード・ウィザード

「図4-1 ノード・マネージャのWebLogicアップグレード・ウィザード」の説明

5. 「次へ」をクリックして、次のウィンドウに進みます。

ノード・マネージャをアップグレードする手順

表4-1に、WebLogicアップグレード・ウィザードを使用してノード・マネージャをアップグレードする手順の概要を示します。

表4-1 ノード・マネージャをアップグレードする手順

手順

実行する操作

ノード・マネージャ・ホーム・ディレクトリの選択

ローカルのディレクトリ階層を移動してアップグレードするノード・マネージャ・インスタンスのホーム・ディレクトリを選択します。

ノード・マネージャのホーム・ディレクトリには、nodemanager.propertiesファイル、ログ、およびその他の関連ファイルが格納されています。ノード・マネージャにより生成されるファイル・セットは、リリースとサービス・パックにより異なります。

ノード・マネージャのデフォルトのホーム・ディレクトリは、WL_HOME/common/nodemanager(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)。

「次へ」をクリックして、次のウィンドウに進みます。

ノード・マネージャ・ホーム・ディレクトリのアップグレード

ウィザードの進行状況(アップグレードされた構成の保存やアップグレード・プロセス中に作成された一時ファイルの削除)を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

このプロセスが完了したら、「次へ」をクリックして、次のウィンドウに進みます。

アップグレード完了

アップグレードが完了したら表示されるアップグレード結果を確認します(さらなる検討を要する重要なメッセージなど)。

「完了」をクリックしてWebLogicアップグレード・ウィザードを閉じます。

注意: ノード・マネージャを使用する前に、「ステップ4: ノード・マネージャへのコンピュータの登録」の説明に従って、コンピュータを登録する必要があります。この手順は、WebLogicドメインのアップグレード・プロセスが完了してから実行します。

ノード・マネージャのサイレント・モードでのアップグレード

たとえば、ノード・マネージャがリモート・コンピュータにある場合などに、WebLogicアップグレード・ウィザードをグラフィカル・モードで使用するのは合理的ではありません。このような場合、ウィザードをサイレント・モードで使用して、ノード・マネージャをアップグレードすることができます。

注意:

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

サイレント・モードでWebLogicアップグレード・ウィザードを起動してノード・マネージャをアップグレードするには:

1. ドメイン内のノード・マネージャとすべてのWebLogic Serverインスタンスが稼働していないことを確認します。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

3. ノード・マネージャ・ディレクトリが10.0より前のバージョンのインストール・ディレクトリ、たとえばデフォルトのディレクトリであるWL_HOME/common/nodemanager(WL_HOMEはWebLogic Serverのインストール先のルート・ディレクトリ)にある場合は、そのノード・マネージャ・ディレクトリの内容を12.1.1のインストール・ディレクトリにコピーします。
この場合、12.1.1のインストール・ディレクトリにある、ノード・マネージャのコピーをアップグレードする必要があります。

注意:

現在のディレクトリ構造は維持されなければなりません。ログ・ファイル(.log)を新しい場所にコピーする必要はありません。

ノード・マネージャ・ディレクトリが10.0より前のバージョンのインストール先のディレクトリにない場合は、この手順を省略することができます。

4. (オプション)アップグレード要件を定義するXMLスクリプトを作成します。詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

5. アップグレードするノード・マネージャ・ディレクトリに移動します。

6. コマンド・プロンプトで、次のコマンドを入力します。

java weblogic.Upgrade -mode silent -type nodemanager [-responses xmlfile] [-out file]

-responses引数と-out引数は省略可能です。これらの引数は、次の設定のデフォルト値をオーバーライドする場合に含めます。

- アップグレード要件を定義するXMLファイルの場所。-responses引数でファイルを指定しない場合、ウィザードはデフォルト値をアップグレード・プロセスで使用します。XMLファイルの形式とデフォルト値の詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

- すべての標準出力(stdout)とエラー・メッセージが書き込まれる出力ファイル。-out引数でファイルを指定しない場合、これらのメッセージはコマンド・ウィンドウに書き込まれます。

注意:

ノード・マネージャを使用する前に、「ステップ4: ノード・マネージャへのコンピュータの登録」の説明に従って、コンピュータを登録する必要があります。この手順は、WebLogicドメインのアップグレード・プロセスが完了してから実行します。

5 WebLogicドメインのアップグレード

12.1.1 WebLogicアップグレード・ウィザードを使用すると、WebLogic Server 8.1で作成されたドメインをアップグレードできます。また、このウィザードでは、WebLogic Server 9.xまたは10.xで作成されたWebLogicドメインを12.1.1にアップグレードすることもできますが、これは任意です。この種類のドメインは、変更せずにWebLogic Server 12.1.1で実行できます。

第6章「WebLogic Server 9.xまたは10.xアプリケーション環境から12.1.1へのアップグレード」を参照してください。

次の項では、この目的のためのWebLogicアップグレード・ウィザードの使用方法について説明します:

- WebLogicドメインのアップグレードの仕組み

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

- ドメインのアップグレード

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

WebLogicドメインのアップグレードの仕組み

WebLogicドメインのアップグレード時には、アップグレードするドメインを指定し、いくつかのプロンプトに回答します。WebLogicアップグレード・ウィザードは次のタスクを実行します。

1. 必要に応じて、元のドメイン・ディレクトリのバックアップを行います。
バックアップがリクエストされた場合、ウィザードはドメイン・ディレクトリのみをバックアップするため、ファイル権限は維持されません。「ステップ3: アプリケーション環境のバックアップの作成」で説明されているように、ドメイン、外部アプリケーション、およびアプリケーション・データベース・リソースをそれぞれ独立したプロセスでバックアップすることをお薦めします。

注意:

ウィザードにより作成されるバックアップ・ファイルには、機密情報が含まれる可能性があるため、ユーザーが保護する必要があります。

2. 起動スクリプトは停止スクリプトなどのスクリプトを再作成し、元のスクリプトの名前をorig-scriptname.bak(orig-scriptnameは元のスクリプトの名前。.bakは拡張子)に変更します。

注意:

元の起動スクリプトに対して行われたカスタマイズの内容は新しいスクリプトにコピーされません。たとえば、元のスクリプトでJAVA_OPTIONS環境変数にデフォルト以外の値が指定されている場合、指定されている値は新しいスクリプトでは保持されません。

3. 元のドメインをリストラクチャして、新しいディレクトリ構造を作成し、ドメインのコンポーネントを新しい場所に移動します。
リストラクチャにおいて、必要なディレクトリがすでに存在する場合は、そのディレクトリとその中にあるファイルおよびサブディレクトリがそのまま維持されます。

既存のサーバー・ログ・ファイルがドメイン内のservers/server_name/logs/pre-9.0-logsディレクトリ(server_nameはサーバーの名前)にコピーされます。

ドメイン・ディレクトリ構造に対する変更を確認するには、付録B「WebLogicドメイン・ディレクトリ構造の強化」を参照してください。

4. 構成ファイル(config.xml)に保存されている永続化された構成に関する情報をconfigディレクトリにアップグレードします。
ウィザードで構成ファイル(config.xml)のアップグレード中にリソースの重複が検出されたら、進行状況を表すウィンドウにメッセージが表示されます。この場合、最後に検出されたリソース定義が変換中に使用されます。

5. JMSファイル・ストア、JMS JDBCストア、トランザクション・ストアなどの永続データをアップグレードします。

注意:

JMS JDBCストアがドメインで使用される場合は、「ステップ6: 環境の設定」を参照してください。

JMS JDBCストアがアップグレードされたら、元のJMS JDBCストアは削除されます。キャパシティ・プランニングを行うときは、この点を考慮に入れてください。アップグレードが正常に完了したら、元のJMS JDBCストア表を削除できます。元のJMS JDBCストア表にはPrefixNameJMSSTOREおよびPrefixNameJMSSTATE(PrefixNameはJMS JDBCストアのPrefix Name属性の値)という名前が付けられます。

保持されているJMSメッセージをアップグレードしない場合は、アップグレードを実行する前にJMSファイル・ストアまたはJMS JDBCストア表を削除します。この場合、構成は変更されず、JMSメッセージのみが削除されます。JDBCストア表の管理の詳細は、『Oracle WebLogic Serverサーバー環境の構成』のJDBCストア表の管理に関する項を参照してください。

アップグレードが実行済みであることが検出されると、JMS JDBCまたはファイル・ストアはアップグレードされません。テスト・シナリオなど、同一の永続ストアを使用してドメインのアップグレードを複数回実行する必要がある場合は、次のようにアップグレード・プロセスを実行するたびにJMSデータを元に戻します。

- JMS JDBCストアの場合、アップグレード・プロセスによりPrefixNameWLSTORE(PrefixNameはJMS JDBCストアのPrefix Name属性の値)という名前の新しい表が作成されます。JMS JDBCストアを使用するドメインのアップグレード・プロセスを再実行する前に、この表を削除します。

- アップグレードを再実行する必要がある場合、必ず最初にバックアップ・バージョンのJMSファイル・ストアをリストアします。

6. 構成を保存します。

注意:

リモートの管理対象サーバーをアップグレードする場合、構成情報は保持されません。

7. さらなる検討を要するドメインのアップグレードに関する問題があれば、報告します。

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

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

- WebLogic Serverアプリケーションをアンデプロイする必要はありません。ほとんどのWebLogic Serverアプリケーションは、修正を加えることなくWebLogic Server 12.1.1のアプリケーション環境で動作します。実際の環境においてアプリケーションが機能変更の影響を受けるかどうかについては、付録A「WebLogic Server 12.1.1の旧リリースとの互換性」で互換性情報を確認してください。アプリケーションで非推奨になった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.1.1にアップグレードできません。

- 9.0からは、.wlnotdeleteディレクトリはWebLogic Server環境では使用されなくなりました。

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

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

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

<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.1にアップグレードした場合は、サーバーを起動する前に、setDomainEnv.shファイルの起動コマンドから-Xverify:noneを削除します。これを行うには、次の行の後でJAVA_OPTIONS=""を設定します。

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

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

ドメインのアップグレード

ウィザードでは、次のアップグレード・モードをサポートします:

- グラフィカル - 対話形式でドメインをアップグレードする場合、グラフィカル・ユーザー・インタフェースのドメイン・アップグレード・ウィザードを使用します。

- サイレント - ファイルにアップグレード要件を指定することで、WebLogicドメインをバックグラウンドでアップグレードできます。

注意:

暗黙モードを使用して、管理サーバーの起動時に自動的にWebLogicドメインをアップグレードすることもできます。詳細は、付録E「管理サーバー起動時におけるドメインのアップグレード(暗黙モード)」を参照してください。

ドメイン内のすべてのコンピュータのドメインをアップグレードする必要があります。リモートの管理対象サーバーのドメイン・ディレクトリの準備については、「ステップ5: リモートの管理対象サーバーのドメイン・ディレクトリの準備」を参照してください。

注意:

先に進む前に、以下のことを確認してください。

- 「アップグレードの準備」で説明されている必要な手順を実行済。

- 「ドメインのアップグレードに関する重要な注意事項」で説明されている重要な注意事項を確認済。

- WebLogicドメインが実行されていないことを確認済。

- JMSストアをバックアップ済。

次の項では、次のアップグレード方法について説明します。

- ドメインのグラフィカル・モードでのアップグレード

- ドメインのサイレント・モードでのアップグレード

ドメインのグラフィカル・モードでのアップグレード

次の項では、グラフィカル・モードでWebLogicアップグレード・ウィザードを使用してWebLogicドメインをアップグレードする方法について説明します。

- ドメインをアップグレードするためグラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

- WebLogicドメインをアップグレードする手順

注意:

グラフィカル・モードでアップグレード・ウィザードを実行するために使用するコンソールでは、JavaベースのGUIがサポートされていなければなりません。グラフィカル表示をサポートしていないシステム上でアップグレード・ウィザードをグラフィカル・モードで起動しようとすると、エラー・メッセージが表示されます。

ドメインをアップグレードするため
グラフィカル・モードでWebLogicアップグレード・ウィザードを起動する方法

Windowsプラットフォーム上でWebLogicアップグレード・ウィザードをグラフィカル・モードで開始してWebLogicドメインをアップグレードするには、Windowsの「スタート」メニューのOracleプログラム・グループから、「ドメイン・アップグレード・ウィザード」オプションを選択します(「プログラム」→「Oracle WebLogic」→「WebLogic Server 12c」→「ツール」→「ドメイン・アップグレード・ウィザード」)。

注意:

「ステップ6: 環境の設定」のステップ3で説明されているように、JDBCドライバ・クラスを指定するため環境をカスタマイズする必要がない場合にかぎり、このオプションを使用できます。

Windowsコマンド・プロンプトから、またはUNIXプラットフォーム上でWebLogicアップグレード・ウィザードをグラフィカル・モードで開始してWebLogicドメインをアップグレードするには:

1. WebLogicドメインが稼働していないことを確認します。

2. 必要に応じて、JMSストアをバックアップします。

3. コマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

4. 次のスクリプトを実行してドメインをアップグレードします。

- Windowsの場合: WL_HOME\common\bin\upgrade.cmd

- UNIXの場合: WL_HOME/common/bin/upgrade.sh

ログ・ファイルは、MW_HOME/user_projects/upgrade_logsディレクトリに格納されます。

WebLogicドメインをアップグレードするために、次のコマンドを使用することもできます。

java weblogic.Upgrade [-type domain] [-out file]

-type引数と-out引数は省略可能です。これらの引数は、次の設定のデフォルト値をオーバーライドする場合に含めます。

- 実行するアップグレードのタイプ。-type引数でタイプを指定しなければ、ドメインのアップグレードが実行されます。

- すべての標準出力(stdout)とエラー・メッセージが書き込まれる出力ファイル。-out引数でファイルを指定しない場合、これらのメッセージはコマンド・ウィンドウに書き込まれ、アップグレード・プロセスの終了時にそのサマリーが表示されます。

-out引数は省略可能です。これにより、すべての標準出力(stdout)とエラー・メッセージが書き込まれるファイルを指定することができます。デフォルトでは、これらのメッセージはコマンド・ウィンドウに書き込まれ、アップグレード・プロセスの終了時にそのサマリーが表示されます。

このコマンドを実行すると、図5-1のようにWebLogicアップグレード・ウィザードが起動します。

図5-1 WebLogicアップグレード・ウィザード

「図5-1 WebLogicアップグレード・ウィザード」の説明

5. JMS JDBCストアが使用されている場合は、対応するデータベースが実行中であることを確認します。

6. 「次へ」をクリックして、次のウィンドウに進みます。

WebLogicドメインをアップグレードする手順

表5-1に、WebLogicアップグレード・ウィザードを使用してドメインをアップグレードする手順の概要を示します。

注意:

この項で示す画面は、あくまでも表示の例です。実際の画面は、ドメインで使用されるリソースの組合せによって異なります。

表5-1 WebLogicドメインをアップグレードする手順

手順

実行する操作

WebLogicバージョンの選択

アップグレードするドメインのWebLogicバージョンを選択します。

「次へ」をクリックして、次のウィンドウに進みます。

アップグレードするドメインの選択

ローカルのディレクトリ階層を移動して、アップグレードするWebLogicドメインが格納されているディレクトリを選択します。

「次へ」をクリックして、次のウィンドウに進みます。

ドメインの検査

ウィザードによるドメインの検査の進行状況を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

カスタム・セキュリティ・プロバイダが使用されているドメインをアップグレードする場合、最初にカスタム・セキュリティ・プロバイダをアップグレードすることなくドメインをアップグレードしようとすると、エラー・メッセージが表示され、ウィザードが終了します。

このエラー・メッセージが表示された場合は、第3章「セキュリティ・プロバイダのアップグレード」の説明に従ってカスタム・セキュリティ・プロバイダをアップグレードしてから、ドメインのアップグレードをやり直します。

検査が完了したら(そしてエラーが検出されなければ)、次のウィンドウが自動的に表示されます。

管理サーバーの選択

新しいドメインで管理サーバーとして機能するサーバーを選択します。

注意 :ドメインで定義されているサーバーが1つしかない場合、このウィンドウは表示されません。このウィンドウは、アップグレードするドメインに複数のサーバーがある場合にのみ表示されます。

「次へ」をクリックして、次のウィンドウに進みます。

ノード・マネージャ資格証明の入力

ノード・マネージャの認可に使用するユーザー名とパスワード(および確認用パスワード)を入力します。

WebLogic Server 12.1.1の場合、ドメインごとにノード・マネージャのユーザー名とパスワードを指定する必要があります。デフォルトでは、ユーザー名とパスワードはweblogicに設定されています。ノード・マネージャを使用しない場合は、デフォルト値を変更せずにそのままにしておきます。

「次へ」をクリックして、次のウィンドウに進みます。

アップグレード・オプションの選択

- 現在のドメインをバックアップ(推奨): これを選択すると、元のドメインのディレクトリがバックアップされ、zipファイルに格納されます。このオプションはデフォルトで選択されています。
注意: ウィザードはドメイン・ディレクトリのみをバックアップするため、ファイル権限は維持されません。「ステップ3: アプリケーション環境のバックアップの作成」で説明されているように、ドメイン、外部アプリケーション、およびアプリケーション・データベース・リソースをそれぞれ独立したプロセスでバックアップすることをお薦めします。

- 「ログ・ファイルをバックアップ用のzipに追加」: これを選択すると、バックアップ用のzipファイルにログ・ファイルが含められます。ログ・ファイルの数と容量は多大になる可能性があるため、このオプションを無効にしてログ・ファイルをバックアップ・ファイルから除外することもできます。デフォルトでは、ログ・ファイルはバックアップ・ファイルに含められます。

- 「下位互換性フラグを設定しない」: 以前サポートされていた動作の一部が、WebLogic Server 9.0からJ2EE 1.4に準拠するよう変更されています。デフォルトでは、以前サポートされていた動作が新しいドメインで有効になるようフラグが設定されます。このオプションを選択すると、この下位互換性フラグは設定されません。下位互換性フラグの詳細は、「下位互換性フラグ」を参照してください。

ディレクトリ選択の解析と任意のタスク

ウィザードによるドメイン情報とオプション設定の処理の進行状況を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

処理が完了したら、次のウィンドウが自動的に表示されます。

ドメインのバックアップ

ウィザードによるドメインのバックアップの準備状況を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

処理が完了したら、次のウィンドウが自動的に表示されます。

ドメインのバックアップ・ディレクトリの選択

注意: 「アップグレード・オプションの選択」で説明したように現在のドメインをバックアップ・アップグレード・オプションを選択しなかった場合は、「ドメイン・ディレクトリのリストラクチャ」に進みます。

このウィンドウで、次の値を設定します。

- バックアップ・ディレクトリ: ローカル階層を移動し、バックアップzipファイルを保存するディレクトリを選択します。デフォルトでは、元のドメインのディレクトリが使用されます。

- バックアップ・ファイル名: バックアップ・ファイルの名前をテキスト・ボックスに入力します。デフォルトのファイル名はweblogic-domain-backup-domain.zip(domainはドメインの名前)です。

「次へ」をクリックして、次のウィンドウに進みます。

ドメインのバックアップ

ウィザードによるドメインのバックアップの進行状況を確認します。バックアップ・プロセスの進行状況をパーセント単位で表すバーと進行状況を通知するメッセージがウィンドウに表示されます。

注意: ウィザードによって作成されるバックアップ・ファイルには、機密情報が含まれる可能性があるため、ユーザーが保護する必要があります。

バックアップ・プロセスが完了したら、次のウィンドウが自動的に表示されます。

ドメイン・ディレクトリのリストラクチャ

ウィザードによるドメイン・ディレクトリのリストラクチャの進行状況を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

プロセスが完了したら、次のウィンドウが自動的に表示されます。

構成設定のアップグレード

ウィザードによる構成設定のアップグレードの進行状況を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

構成情報は、後で実行する手順まで保持されません。

構成のアップグレードが完了したら、次のウィンドウが自動的に表示されます。

保存されているメッセージおよびトランザクション・ログ・フォーマットのアップグレード

ウィザードによるドメイン内の永続メッセージ(JMSファイルとJDBCストア)とトランザクション(JTA)ログのアップグレードの進行状況を確認します。進行状況をパーセント単位で表すバーと進行状況を通知するメッセージがウィンドウに表示されます。

永続メッセージとトランザクション・ログのアップグレード・プロセスが完了したら、次のウィンドウが自動的に表示されます。

RDBMS Authenticatorセキュリティ・プロバイダのアップグレード

非推奨のRDBMSAuthenticatorをSQLAuthenticatorに置き換えるかどうかを指定します。

注意 :このウィンドウは、アップグレードするドメインにRDBMS Authenticatorセキュリティ・プロバイダがある場合にのみ表示されます。

「次へ」をクリックして、次のウィンドウに進みます。

アップグレードされた構成の保持

ウィザードの進行状況(アップグレードされた構成の保存やアップグレード・プロセス中に作成された一時ファイルの削除)を確認します。進行状況を通知するメッセージがウィンドウに表示されます。

注意 :リモートの管理対象サーバーをアップグレードする場合、構成情報は保持されません。

このプロセスが完了したら、「次へ」をクリックして、次のウィンドウに進みます。

アップグレード完了

アップグレードが完了したら表示されるアップグレード結果を確認します(さらなる検討を要する重要なメッセージなど)。

「完了」をクリックしてWebLogicアップグレード・ウィザードを閉じます。

ドメインのサイレント・モードでのアップグレード

注意:

サイレント・モードでは、WebLogicドメインのみがアップグレードできます。

たとえば、ドメインがリモート・コンピュータにある場合などに、WebLogicアップグレード・ウィザードをグラフィカル・モードで使用するのは合理的ではありません。このような場合、ウィザードをサイレント・モードで使用して、WebLogicドメインをアップグレードすることができます。

注意:

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

サイレント・モードでWebLogicアップグレード・ウィザードを起動してWebLogicドメインをアップグレードするには:

1. WebLogicドメインが稼働していないことを確認します。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

3. (オプション)アップグレード要件を定義するXMLスクリプトを作成します。詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

4. アップグレードするWebLogicドメインが格納されているディレクトリに移動します。例:

cd c:\bea\user_projects\domains\domain

domainはドメインの名前です。

5. コマンド・プロンプトで、次のコマンドを入力します。

java weblogic.Upgrade -mode silent -type domain [-responses xmlfile] [-out file]

-responses引数と-out引数は省略可能です。これらの引数は、次の設定のデフォルト値をオーバーライドする場合に含めます。

- アップグレード要件を定義するXMLファイルの場所。-responses引数でファイルを指定しない場合、ウィザードはデフォルト値をアップグレード・プロセスで使用します。XMLファイルの形式とデフォルト値の詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

- すべての標準出力(stdout)とエラー・メッセージが書き込まれる出力ファイル。-out引数でファイルを指定しない場合、これらのメッセージはコマンド・ウィンドウに書き込まれます。

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

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

- 引続きPointBaseを使用するようにドメインをアップグレードします。

- ドメインをアップグレードし、データベースをDerbyに移行します。

次の項では、これらの各選択肢を実行する方法について説明します。

アップグレードしたドメインでのPointBaseの使用

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

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

2. 「アプリケーション環境のアップグレード」と「アップグレード後の手順の完了」で説明する手順を実行します。
PointBaseに関するドメインの構成設定が保存されます。

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

4. PointBaseインストールをリストアします。

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

アップグレードしたドメイン・データベースのDerbyへの移行

サンプル・ドメインをWebLogic 12.1.1にアップグレードしてから、ドメイン・データベースをPointBaseからDerbyに移行する場合は、次の手順を実行します。

1. 「アップグレードの準備」の説明に従い、フル・インストーラを使用してWebLogic Server 12.1.1をインストールします。

2. 「アプリケーション環境のアップグレード」と「アップグレード後の手順の完了」で説明する手順を実行します。

3. PointBaseデータベースのスキーマおよび表をDerbyにインポートします。Apache Derby Webサイト(http://db.apache.org/derby/integrate/index.html)に、役立つヒントや情報があります。

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

- WL_HOME\common\derby\lib\derbynet.jar

- WL_HOME\common\derby\lib\derbyclient.jar

6 WebLogic Server 9.xまたは10.xアプリケーション環境から12.1.1へのアップグレード

次の項では、WebLogic Server 9.xまたは10.xからWebLogic Server 12.1.1リリースへのアプリケーション環境のアップグレード手順について説明します。

- 新しいドメインの作成

- 既存のドメインの更新

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

注意:

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

アプリケーションでのWebサービスのアップグレードに関する詳細は、第7章「WebLogic Webサービスのアップグレード」を参照してください。

新しいドメインの作成

ドメインを作成およびカスタマイズするプロセスがすでに自動化されている場合には、この方法が便利です。新規ドメインを作成するには、次の手順を実行します。

1. WebLogic Server 12.1.1ソフトウェアをインストールします。

2. 12.1.1にドメインを作成するには、12.1.1で提供されているデフォルトのドメイン・テンプレートを使用します。または、9.xのカスタム・テンプレートを使用して9.xにドメインを作成していた場合は、同じ方法で新しい12.1.1ドメインを作成します。
この手順は、構成ウィザードを使用して実行するか、またはWLSTなどのWebLogicスクリプト・ツールで作成した自動化スクリプトを使用して実行できます。構成ウィザードについては『構成ウィザードによるドメインの作成』、WLSTについては『Oracle WebLogic Scripting Tool』を参照してください。

12.1.1ドメイン・テンプレートを参照したり、12.1.1リリースで提供される新機能を実装したりするために、自動化スクリプトには適宜更新する必要があります。

たとえば、『Oracle WebLogic Serverの理解』のWebLogic Serverセキュリティの理解に関する項で説明されているように、WebLogic 9.1からはデフォルトのセキュリティ・プロバイダがXACMLベースになっています。必要に応じて、WebLogic 9.1より前のセキュリティ・プロバイダのサポートを追加するか、新しいXACMLベースのセキュリティ・プロバイダを使用するように適切な変更を加えてください。

3. 既存のWebLogic Server 9.xアプリケーションを、新しい12.1.1ドメインにデプロイします。

注意:

ステップ2でカスタム9.xテンプレートを使用した場合、すでに9.xアプリケーションがデプロイされていることがあります。

既存のドメインの更新

ドメインの作成が自動化されていない場合、テスト・ドメイン内のカスタマイズ情報を維持するには、既存のドメインの更新が便利です。既存のドメインは、次の2とおりの方法でアップグレードできます。

- 方法1: 手動更新

1. WebLogic Server 12.1.1ソフトウェアをインストールします。

2. ドメイン・ディレクトリ、アプリケーション、ドメイン外のアプリケーション・データ、ログ・ファイル(必要な場合)など、既存のアプリケーション環境をバックアップします。

3. WebLogic Server 12.1.1のインストール先を参照するようドメインのスクリプト・ファイルを更新します。たとえば、MW_HOME、MW_HOME、BEA_HOME、BEA_JAVA_HOME、JAVA_HOME、およびWL_HOMEに適切な値を設定します。

4. CLASSPATHを更新して、不要になったパス情報(12.1.1より前のリリースに適用されるパッチ・ファイル情報など)を削除します。

- 方法2: 自動更新
第5章「WebLogicドメインのアップグレード」の説明に従って、ドメイン・アップグレード・ウィザードを使用します。

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

9.0、9.1、または9.2で開発したBeehiveアプリケーションがある場合は、BEA WebLogic ServerのBeehive統合ガイドのアップグレード・パスに関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs100/beehive/introduction.html#upgrade)の説明に従って、それらをアップグレードする必要があります。

注意:

このリリースでは、WebLogic Platformアプリケーション・フレームワークとしてApache Beehiveを使用することは非推奨となりました。Oracle標準としてより機能性の高いアプリケーション・フレームワークを提供するADFを使用することをお薦めします。

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

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

ここで説明するトピックは以下のとおりです。

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

- 9.2または10.xのWebLogic Webサービス(JAX-WSまたはJAX-RPC)の12.1.xへのアップグレード

- 9.0または9.1のWebLogic Webサービス(JAX-WSまたはJAX-RPC)の12.1.xへのアップグレード

- 8.1のWebLogic Webサービスの12.1.xへのアップグレード

注意:

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

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

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

次の項では、10.3.xのRESTful Webサービスを12.1.x環境で実行できるように、使用環境をアップグレードするために必要な手順について説明します。

- Jersey 1.9共有ライブラリを使用する10.3.x RESTful Webサービスのアップグレード

- Jersey 1.1.5.1共有ライブラリを使用する10.3.x RESTful Webサービスのアップグレード

Jersey 1.9共有ライブラリを使用する
10.3.x RESTful Webサービスのアップグレード

10.3.x RESTful WebLogic WebサービスでJersey 1.9共有ライブラリを使用している場合は、12.1.x環境でアプリケーションを実行するための追加手順は不要です。この場合、システム・クラスパスにあるJersey 1.9 JARファイルはWebLogic Serverのシステム・クラスローダによってロードされます。

注意:

RESTful Webサービス・アプリケーションがサーブレットとパッケージ化されている場合、WebアプリケーションがServlet 3.0以下を使用しているかどうかに基づいて適切にパッケージ化されているか確認します。詳細は、『RESTful Webサービスの開発』のサーブレットとのパッケージ化に関する項を参照してください。

Jersey 1.1.5.1共有ライブラリを使用する
10.3.x RESTful Webサービスのアップグレード

注意:

Jersey 1.1.5.1 JAX-RS RI共有ライブラリは、下位互換性のためにのみ提供されています。WebLogic Serverシステム・クラスパスで使用可能なJersey 1.9 JAX-RS RI APIを使用するため、RESTful Webサービス・アプリケーションをアップグレードすることをお薦めします。

下位互換性のため、Jersey 1.1.5.1 JAX-RS RI共有ライブラリは12.1.xリリースのWebLogic Serverに付属しています。共有ライブラリは、WL_HOME/common/deployable-librariesディレクトリに格納されています。

表7-1に、Jersey JAX-RS RIバージョン1.1.5.1 Webサービスをサポートする構築済共有ライブラリを、対応する機能ごとにまとめています。共有ライブラリが必須か省略可能かも示します。

表7-1 Jersey JAX-RS RI 1.1.5.1の共有ライブラリ

機能

説明

必須/省略可能

Jersey

- 共有ライブラリ名: jersey-bundle

- JARファイル名: jersey-bundle-1.1.5.1.jar

- WARファイル名: jersey-bundle-1.1.5.1.war

- バージョン: 1.1.5.1

- ライセンス: SUN CDDL+GPL

必須

JAX-RS API

- 共有ライブラリ名: jsr311

- JARファイル名: jsr311-api-1.1.1.jar

- WARファイル名: jsr311-api-1.1.1.war

- バージョン: 1.1.1

- ライセンス: JSR311ライセンス

必須

JSON処理

- 共有ライブラリ名: jackson-core-asl

- JARファイル名: jackson-core-asl-1.1.1.jar

- WARファイル名: jackson-core-asl-1.1.1.war

- バージョン: 1.1.1

- ライセンス: Apache 2.0

省略可能

JSON処理

- 共有ライブラリ名: jackson-jaxrs

- JARファイル名: jackson-jaxrs-1.1.1.jar

- WARファイル名: jackson-jaxrs-1.1.1.war

- バージョン: 1.1.1

- ライセンス: Apache 2.0

省略可能

JSON処理

- 共有ライブラリ名: jackson-mapper-asl

- JARファイル名: jackson-mapper-asl-1.1.1.jar

- WARファイル名: jackson-mapper-asl-1.1.1.war

- バージョン: 1.1.1

- ライセンス: Apache 2.0

省略可能

JSONストリーミング

- 共有ライブラリ名: jettison

- JARファイル名: jettison-1.1.jar

- WARファイル名: jettison-1.1.war

- バージョン: 1.1

- ライセンス: Apache 2.0

省略可能

ATOM処理

- 共有ライブラリ名: rome

- JARファイル名: rome-1.0.jar

- WARファイル名: rome-1.0.war

- バージョン: 1.0

- ライセンス: Apache 2.0

省略可能

10.3.x RESTful Webサービスを12.1.x環境で実行し、Jersey 1.1.5.1共有ライブラリを引き続き使用するために、使用環境をアップグレードするには、次の手順を実行する必要があります。

1. Jersey 1.1.5.1共有ライブラリを1つ以上のWebLogic Serverインスタンスに登録します。
共有Java EEライブラリを1つまたは複数のWebLogic Serverインスタンスに登録するには、ターゲット・サーバーにライブラリをデプロイし、デプロイメントが共有されるように指定します。共有Java EEライブラリは、ライブラリを参照するアプリケーションをデプロイするのと同じWebLogic Serverインスタンスにターゲット指定する必要があります。

次に、Jersey JAX-RS RIの基本機能とJAX-RS APIをサポートする共有ライブラリのデプロイ例を示します。

weblogic.Deployer -verbose -noexit -source C:\myinstall\wlserver_10.3\common\deployable-libraries\jersey-bundle-1.1.5.1.war -targets myserver -adminurl t3://localhost:7001 -user system -password ******** -deploy -library

weblogic.Deployer -verbose -noexit -source C:\myinstall\wlserver_10.3\common\deployable-libraries\jsr311-api-1.1.1.war -targets myserver -adminurl t3://localhost:7001 -user system -password ******** -deploy -library

weblogic.Deployerの詳細は、『Oracle WebLogic Serverへのアプリケーションのデプロイ』のweblogic.Deployerコマンドライン・リファレンスを参照してください。

2. RESTful Webサービス・アプリケーションがサーブレットとパッケージ化されている場合、WebアプリケーションがServlet 3.0以下を使用しているかどうかに基づいて適切にパッケージ化されているか確認します。詳細は、『RESTful Webサービスの開発』のサーブレットとのパッケージ化に関する項を参照してください。

3. RESTful Webサービス・アプリケーションをデプロイします。

9.2または10.xのWebLogic Webサービス(JAX-WSまたはJAX-RPC)の12.1.xへのアップグレード

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

9.0または9.1のWebLogic Webサービス(JAX-WSまたはJAX-RPC)の12.1.xへのアップグレード

9.0または9.1のWebサービスで次のいずれかの機能を使用していた場合、WebLogic Server 12.1.xに再デプロイする前にWebサービスを再コンパイルする必要があります。

- 会話

- @weblogic.jws.Context JWSアノテーション

- weblogic.wsee.jws.JwsContext API

再コンパイルするには、Webサービスを実装するJWSファイルに対してjwsc Antタスクを再実行するだけです。

9.0または9.1のWebサービスでこれらの機能を使用していなかった場合、変更や再コンパイルを行わずにWebLogic Server 12.1.xに再デプロイできます。

8.1のWebLogic Webサービスの12.1.xへのアップグレード

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

- WebLogic JAX-RPCスタックへのアップグレード: これは、アップグレードに必要な作業レベルにおいて最も単純なアップグレード・パスです。WebLogic JAX-RPCスタックのXMLBeansサポートは8.1 WebLogic Webサービスと互換性があります。詳細は、「8.1のWebLogic WebサービスのWebLogic JAX-RPCスタックへのアップグレード」を参照してください。

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

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

この項では、WebLogic JAX-RPC実行時環境を使用するように8.1 WebLogic Webサービスをアップグレードする方法を説明します。WebLogic JAX-RPCのランタイムは、JSR 109: Implementing Enterprise Web Services仕様(http://www.jcp.org/en/jsr/detail?id=109)に基づいています。12.1.xのプログラミング・モデルでは、JSR 181: Web Services Metadata for the Java Platform仕様(JSR-181)(http://www.jcp.org/en/jsr/detail?id=181)で指定される標準JDK 1.5メタデータ・アノテーションを使用します。

8.1のWebサービスのアップグレードで行うタスクを大まかにまとめると次のようになります。以降の項の手順では、より詳しく説明します。

- Webサービスを実装するJavaクラスやステートレス・セッションEJBの8.1のJavaソース・コードを、JWSアノテーションを使用するように更新します。
12.1.xでは、WebLogic Webサービスは、JWSファイル(JWSアノテーションを含むJavaファイル)を使用して実装します。jwsc Antタスクは、常にWebサービスをプレーンJavaファイルとして実装します(ただし、JWSファイルに明示的にjavax.ejb.SessionBeanを実装する場合を除きます)。後者のケースは一般的ではありません。このプログラミング・モデルは、バックエンド・コンポーネントの種類(JavaクラスかEJBか)の指定が必要だった8.1のモデルとは異なります。

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

以下の項では、次のことが前提となっています。

- 8.1のWebサービスの生成にservicegenを使用したことがあり、より全般的には、WebLogic Serverで動作するWebサービスやその他のJava Platform, Enterprise Edition(Java EE)バージョン5アーティファクトを、開発環境でAntスクリプトを使用して繰り返し開発しています。この項の手順説明では、既存のAnt build.xmlファイルを更新する手順を説明します。

- 8.1のWebサービスのJavaクラスまたはEJBのソース・コードにアクセスできます。

この項では、以下の内容については説明しません。

- JMS実装の8.1 Webサービスのアップグレード(WebLogic WebサービスJAX-RPCランタイムは、JMS実装のサービスをサポートしていないためです)。

- 8.1より前のバージョンのWebサービスのアップグレード。

- 8.1のWebサービスを呼び出すクライアント・アプリケーションから12.1.xのWebサービスを呼び出すクライアント・アプリケーションへのアップグレード。12.1.x Webサービスを呼び出すクライアント・アプリケーションの記述方法の詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebサービスの呼出しに関する項を参照してください。

Javaクラス実装の8.1のWebLogic Webサービスの
12.1.xへのアップグレード: 主な手順

Javaクラス実装の8.1のWebサービスを、WebLogic WebサービスJAX-RPCランタイムを使用するようにアップグレードする手順:

1. コマンド・ウィンドウを開き、12.1.xのドメイン・ディレクトリのbinサブディレクトリにあるsetDomainEnv.cmd(Windows)またはsetDomainEnv.sh(UNIX)スクリプトを実行して、WebLogic Server 12.1.x環境を設定します。
WebLogic Serverドメインのデフォルトの場所は、MW_HOME/user_projects/domains/domainNameです。MW_HOMEはOracle製品の最上位のインストール・ディレクトリ、domainNameはドメインの名前です。

2. プロジェクト・ディレクトリを作成します。

prompt> mkdir /myExamples/upgrade_pojo

3. プロジェクト・ディレクトリの下に、srcディレクトリと、古い8.1のJavaクラスに対応する新しい12.1.xのJWSファイル(この手順で後述)のパッケージ名に相当するサブディレクトリを作成します。

prompt> cd /myExamples/upgrade_pojo
prompt> mkdir src/examples/webservices/upgrade_pojo

4. 8.1のWebサービスを実装する古いJavaクラスを、作業ディレクトリのsrc/examples/webservices/upgrade_pojoディレクトリにコピーします。必要に応じてファイル名を変更してください。

5. 次の手順に従ってJavaファイルを編集します。具体的な例については、「8.1のJavaファイルと対応する12.1.xのJWSファイルの例」にある新旧のサンプルJavaファイルを参照してください。

1. 必要に応じて、新しい12.1.xのソース環境を反映するようにJavaファイルのパッケージ名とクラス名を変更します。

2. import文を追加して、標準およびWebLogic固有のJWSアノテーションがインポートされるようにします。

3. 少なくとも、次のJWSアノテーションを追加します。

- JWSファイルがWebサービスを実装することを指定する標準の@WebServiceアノテーション(Javaクラス・レベルで追加)。
以下のアノテーションも追加することをお薦めします。

- Webサービスの種類(document-literal-wrapped、RPC-encodedなど)を指定する標準の@SOAPBindingアノテーション(クラス・レベルで追加)。

- デプロイされたWebサービスを呼び出すURLで使用されるコンテキストとサービスURIを指定するWebLogic固有の@WLHttpTransportアノテーション(クラス・レベルで追加)。

- 標準の@WebMethodアノテーション(Webサービス操作として公開されるメソッドごとにメソッド・レベルで追加)。
JavaファイルでのJWSアノテーションの使用に関する概要については、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のJWSファイルのプログラミングに関する項を参照してください。

4. 12.1.x Webサービスに引き継ぐ8.1 Webサービスの機能によっては、JWSファイルに他のアノテーションを追加することが必要な場合もあります。8.1では、これらの機能の多くをservicegenの属性を使用して構成していました。「servicegen属性とJWSアノテーションまたはjwsc属性のマッピング」の表に、8.1でservicegenの属性を使用して有効にしていた機能に対応するJWSアノテーションをまとめてあります(相当するアノテーションがある場合のみ)。

6. 8.1のWebサービスのビルドに使用していた古いbuild.xmlファイルを12.1.xの作業ディレクトリにコピーします。

7. Ant build.xmlファイルを更新して、servicegenの代わりにjwsc Antタスクとその他のサポート・タスクが実行されるようにします。
Antビルド・ファイルでbuild-serviceなどの新しいターゲットを作成し、前の手順で作成した新しいJWSファイルをコンパイルするjwsc Antタスク呼出しを追加することをお薦めします。このターゲットがいったん正常に機能すれば、古いservicegen Antタスクは削除できます。

次に示す手順は、build.xmlファイルを更新する際の主な手順です。詳細な手順については、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスの開発に関する項で説明する、標準の反復開発プロセスを参照してください。

次の各手順の例については、「8.1と更新された12.1.xのAntビルド・ファイルの例(Javaクラス実装のWebサービス)」を参照してください。

1. jwsc taskdefをbuild.xmlファイルに追加します。

2. build-serviceターゲットを作成し、この後の手順に従って12.1.xのWebサービスをビルドするのに必要なタスクを追加します。

3. jwscタスクをビルド・ファイルに追加します。srdir属性にsrcディレクトリ(この例では/myExamples/upgrade_pojo/src)を設定し、destdir属性に前の手順で作成したエンタープライズ・アプリケーションのルート・ディレクトリを設定します。
<jws>子要素のfile属性に、前の手順で作成した新しいJWSファイルの名前を指定します。

12.1.x Webサービスに引き継ぐ8.1 Webサービスの機能によっては、jwscタスクに追加の属性を指定することが必要な場合もあります。8.1では、これらの機能の多くをservicegenの属性を使用して構成していました。「servicegen属性とJWSアノテーションまたはjwsc属性のマッピング」の表で、servicegenの属性を使用して有効にしていた機能に相当するjwsc属性があるかどうかについて説明しています。

8. build-service Antターゲットを実行します。すべてのタスクを正しく完了すると、アップグレードされた12.1.xのWebサービスがエンタープライズ・アプリケーションに含まれます。

Webサービスのデプロイとテストの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項と、WebサービスのWSDLの参照に関する項を参照してください。

次の各項に示すサンプルJavaコードの場合、アップグレードされた12.1.xのWebサービスのWSDLを呼び出すURLは次のようになります。

http://host:port/upgradePOJO/HelloWorld?WSDL

8.1のJavaファイルと対応する12.1.xのJWSファイルの例

次のサンプルJavaクラスが8.1のWebサービスを実装していたものと仮定します。

package examples.javaclass;
/**
* Simple Java class that implements the HelloWorld Web service.   It takes
* as input an integer and a String, and returns a message that includes these
* two parameters.
*/
public final class HelloWorld81 {
/**
* Returns a text message that includes the integer and String input
* parameters.
*
*/
public String sayHello(int num, String s) {
System.out.println("sayHello operation has been invoked with arguments " + s + " and " + num);
String returnValue = "This message brought to you by the letter "+s+" and the number "+num;
return returnValue;
}
}

これに対応するものとして、Javaクラス実装の12.1.x WebサービスのJWSファイルを次に示します(相違点が太字で示されています)。一部のJWSアノテーションの値が、「8.1と更新された12.1.xのAntビルド・ファイルの例(Javaクラス実装のWebサービス)」に示す8.1のservicegen Antタスクの属性から取得されている点に注意してください。

package examples.webservices.upgrade_pojo;
// Import standard JWS annotations
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.soap.SOAPBinding;
// Import WebLogic JWS anntoation
import weblogic.jws.WLHttpTransport;
/**
* Simple Java class that implements the HelloWorld92 Web service.   It takes
* as input an integer and a String, and returns a message that includes these
* two parameters.
*/
@WebService(name="HelloWorld92PortType", serviceName="HelloWorld",
targetNamespace="http://example.org")
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
@WLHttpTransport(contextPath="upgradePOJO", serviceUri="HelloWorld",
portName="HelloWorld92Port")
public class HelloWorld92Impl {
/**
* Returns a text message that includes the integer and String input
* parameters.
*
*/
@WebMethod()
public String sayHello(int num, String s) {
System.out.println("sayHello operation has been invoked with arguments " + s + " and " + num);
String returnValue = "This message brought to you by the letter "+s+" and the number "+num;
return returnValue;
}
}

8.1と更新された12.1.xのAntビルド・ファイルの
例(Javaクラス実装のWebサービス)

次の単純なbuild.xmlファイルでは、8.1でservicegen Antタスクを使用してWebLogic Webサービスをビルドする方法を示します。この例では、8.1のWebサービスを実装するJavaファイルがすでにexamples.javaclass.HelloWorld81クラスにコンパイルされています。

<project name="javaclass-webservice" default="all" basedir=".">
<!-- set global properties for this build -->
<property name="source" value="."/>
<property name="build" value="${source}/build"/>
<property name="war_file" value="HelloWorldWS.war" />
<property name="ear_file" value="HelloWorldApp.ear" />
<property name="namespace" value="http://examples.org" />
<target name="all" depends="clean, ear"/>
<target name="clean">
<delete dir="${build}"/>
</target>
<!-- example of old 8.1 servicegen call to build Web Service -->
<target name="ear">
<servicegen
destEar="${build}/${ear_file}"
warName="${war_file}">
<service
javaClassComponents="examples.javaclass.HelloWorld81"
targetNamespace="${namespace}"
serviceName="HelloWorld"
serviceURI="/HelloWorld"
generateTypes="True"
expandMethods="True">
</service>
</servicegen>
</target>
</project>

これに対応するものとして、jwsc Antタスクを呼び出して12.1.xのWebサービスをビルドするbuild.xmlファイルを次に示します(この項で説明する該当タスクは太字で示してあります)。この例では、12.1.xのWebサービスを実装する新しいJWSファイルにHelloWorld92Impl.javaという名前が付けられています。

<project name="webservices-upgrade_pojo" default="all">
<!-- set global properties for this build -->
<property name="wls.username" value="weblogic" />
<property name="wls.password" value="weblogic" />
<property name="wls.hostname" value="localhost" />
<property name="wls.port" value="7001" />
<property name="wls.server.name" value="myserver" />
<property name="ear.deployed.name" value="upgradePOJOEar" />
<property name="example-output" value="output" />
<property name="ear-dir" value="${example-output}/upgradePOJOEar" />
<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />
<taskdef name="wldeploy"
classname="weblogic.ant.taskdefs.management.WLDeploy"/>
<target name="all" depends="clean,build-service,deploy" />
<target name="clean" depends="undeploy">
<delete dir="${example-output}"/>
</target>
<target name="build-service">
<jwsc
srcdir="src"
destdir="${ear-dir}">
<jws file="examples/webservices/upgrade_pojo/HelloWorld92Impl.java" />
</jwsc>
</target>
<target name="deploy">
<wldeploy action="deploy" name="${ear.deployed.name}"
source="${ear-dir}" user="${wls.username}"
password="${wls.password}" verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}" />
</target>
<target name="undeploy">
<wldeploy action="undeploy" name="${ear.deployed.name}"
failonerror="false"
user="${wls.username}" password="${wls.password}" verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}" />
</target>
</project>

EJB実装の8.1のWebLogic Webサービスの
12.1.xへのアップグレード: 主な手順

次の手順では、WebLogic WebサービスJAX-RPCランタイムを使用するようにEJB実装の8.1 Webサービスをアップグレードする方法について説明します。

12.1.xのWebサービスのプログラミング・モデルは、Webサービスの基底の実装を隠す点で8.1のモデルとはまったく異なります。WebサービスをJavaクラスで実装するかEJBで実装するかを前もって指定するのではなく、JWSファイルに明示的にjavax.ejb.SessionBeanを実装しないかぎり(一般的には実装しない)、jwsc Antタスクで常にプレーンJavaクラス実装が選択されます。このため、8.1のWebサービスは明示的にEJBで実装されていましたが、次の手順ではEJBクラスをインポートする方法やEJBGenを使用する方法は示されていません。かわりに、EJB実装の8.1のWebサービスに対応する12.1.xの標準的なJWSファイルを作成する方法を示します。

1. コマンド・ウィンドウを開き、12.1.xのドメイン・ディレクトリのbinサブディレクトリにあるsetDomainEnv.cmd(Windows)またはsetDomainEnv.sh(UNIX)スクリプトを実行して、WebLogic Server 12.1.x環境を設定します。
WebLogic Serverドメインのデフォルトの場所は、MW_HOME/user_projects/domains/domainNameです。MW_HOMEはOracle製品の最上位のインストール・ディレクトリ、domainNameはドメインの名前です。

2. プロジェクト・ディレクトリを作成します。

prompt> mkdir /myExamples/upgrade_ejb

3. プロジェクト・ディレクトリの下に、srcディレクトリと、8.1のEJB実装に対応する新しい12.1.xのJWSファイル(この手順で後述)のパッケージ名に相当するサブディレクトリを作成します。

prompt> cd /myExamples/upgrade_ejb
prompt> mkdir src/examples/webservices/upgrade_ejb

4. javax.ejb.SessionBeanを実装していた8.1 EJB Beanファイルを、作業ディレクトリのsrc/examples/webservices/upgrade_ejbディレクトリにコピーします。必要に応じてファイル名を変更してください。

注意:

8.1のホームおよびリモートEJBファイルをコピーする必要はありません。

5. 次の手順に従ってEJB Beanファイルを編集します。具体的な例については、「8.1のEJBファイルと対応する12.1.xのJWSファイルの例」にある新旧のサンプルJavaファイルを参照してください。

1. 必要に応じて、新しい12.1.xのソース環境を反映するようにJavaファイルのパッケージ名とクラス名を変更します。

2. 必要に応じて、EJBクラス(javax.ejb.*)をインポートするimport文を削除します。これらのクラスは、アップグレード後のJWSファイルでは必要ありません。

3. import文を追加して、標準およびWebLogic固有のJWSアノテーションがインポートされるようにします。

4. JWSファイルのクラス宣言からimplements SessionBeanコードを削除して、それ以降javax.ejb.SessionBeanが実装されないようにします。

5. EJB固有のメソッドをすべて削除します。

- ejbActivate()

- ejbRemove()

- ejbPassivate()

- ejbCreate()

6. 少なくとも、次のJWSアノテーションを追加します。

- JWSファイルがWebサービスを実装することを指定する標準の@WebServiceアノテーション(Javaクラス・レベルで追加)。
以下のアノテーションも追加することをお薦めします。

- Webサービスの種類(document-literal-wrapped、RPC-encodedなど)を指定する標準の@SOAPBindingアノテーション(クラス・レベルで追加)。

- デプロイされたWebサービスを呼び出すURLで使用されるコンテキストとサービスURIを指定するWebLogic固有の@WLHttpTransportアノテーション(クラス・レベルで追加)。

- 標準の@WebMethodアノテーション(Webサービス操作として公開されるメソッドごとにメソッド・レベルで追加)。

JavaファイルでのJWSアノテーションの使用に関する概要については、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のJWSファイルのプログラミングに関する項を参照してください。

7. 12.1.x Webサービスに引き継ぐ8.1 Webサービスの機能によっては、JWSファイルに他のアノテーションを追加することが必要な場合もあります。8.1では、これらの機能の多くをservicegenの属性を使用して構成していました。「servicegen属性とJWSアノテーションまたはjwsc属性のマッピング」の表に、8.1でservicegenの属性を使用して有効にしていた機能に対応するJWSアノテーションをまとめてあります(相当するアノテーションがある場合のみ)。

6. 8.1のWebサービスのビルドに使用していた古いbuild.xmlファイルを12.1.xの作業ディレクトリにコピーします。

7. Ant build.xmlファイルを更新して、servicegenの代わりにjwsc Antタスクとその他のサポート・タスクが実行されるようにします。
Antビルド・ファイルでbuild-serviceなどの新しいターゲットを作成し、前の手順で作成した新しいJWSファイルをコンパイルするjwsc Antタスク呼出しを追加することをお薦めします。このターゲットがいったん正常に機能すれば、古いservicegen Antタスクは削除できます。

次に示す手順は、build.xmlファイルを更新する際の主な手順です。詳細な手順については、次で説明する標準の反復開発プロセスを参照してください:

次の各手順の例については、「8.1と更新された12.1.xのAntビルド・ファイルの例(EJB実装の8.1のWebサービス)」を参照してください。

1. jwsc taskdefをbuild.xmlファイルに追加します。

2. build-serviceターゲットを作成し、この後の手順に従って12.1.xのWebサービスをビルドするのに必要なタスクを追加します。

3. jwscタスクをビルド・ファイルに追加します。srdir属性にsrcディレクトリ(この例では/myExamples/upgrade_ejb/src)を設定し、destdir属性に前の手順で作成したエンタープライズ・アプリケーションのルート・ディレクトリを設定します。
<jws>子要素のfile属性に、前の手順で作成した新しいJWSファイルの名前を指定します。

12.1.x Webサービスに引き継ぐ8.1 Webサービスの機能によっては、jwscタスクに追加の属性を指定することが必要な場合もあります。8.1では、これらの機能の多くをservicegenの属性を使用して構成していました。「servicegen属性とJWSアノテーションまたはjwsc属性のマッピング」の表に、servicegenの属性を使用して有効にしていた機能に対応するjwsc属性があるかどうかを示しています。

8. build-service Antターゲットを実行します。すべてのタスクを正しく完了すると、アップグレードされた12.1.xのWebサービスがエンタープライズ・アプリケーションに含まれます。

Webサービスのデプロイとテストの詳細は、『Oracle WebLogic Server JAX-RPC Webサービス・スタート・ガイド』のWebLogic Webサービスのデプロイとアンデプロイに関する項と、WebサービスのWSDLの参照に関する項を参照してください。

次の各項に示すサンプルJavaコードの場合、アップグレードされた12.1.xのWebサービスのWSDLを呼び出すURLは次のようになります。

http://host:port/upgradeEJB/HelloWorldService?WSDL

8.1のEJBファイルと対応する12.1.xのJWSファイルの例

次の3つの項に示すBean、ホームおよびリモートのクラスとインタフェースが8.1のステートレス・セッションEJB(つまり8.1のWebサービス)を実装していたものと仮定します。

「対応する12.1.xのJWSファイル」に、対応する12.1.xのJWSファイルを示します。8.1のクラスと12.1.xのクラスの相違点は太字で示してあります。一部のJWSアノテーションの値が、「8.1と更新された12.1.xのAntビルド・ファイルの例(EJB実装の8.1のWebサービス)」に示す8.1のservicegen Antタスクの属性から取得されている点に注意してください。

8.1 SessionBeanクラス

package examples.statelessSession;
import javax.ejb.CreateException;
import javax.ejb.SessionBean;
import javax.ejb.SessionContext;
/**
* HelloWorldBean is a stateless session EJB.  It has a single method,
* sayHello(), that takes an integer and a String and returns a String.
* <p>
* The sayHello() method is the public operation of the Web service based on
* this EJB.
*/
public class HelloWorldBean81 implements SessionBean {
private static final boolean VERBOSE = true;
private SessionContext ctx;
// You might also consider using WebLogic's log service
private void log(String s) {
if (VERBOSE) System.out.println(s);
}
/**
*   Single EJB business method.
*/
public String sayHello(int num, String s) {
System.out.println("sayHello in the HelloWorld EJB has "+
"been invoked with arguments " + s + " and " + num);
String returnValue = "This message brought to you by the "+
"letter "+s+" and the number "+num;
return returnValue;
}
/**
* This method is required by the EJB Specification,
* but is not used by this example.
*
*/
public void ejbActivate() {
log("ejbActivate called");
}
/**
* This method is required by the EJB Specification,
* but is not used by this example.
*
*/
public void ejbRemove() {
log("ejbRemove called");
}
/**
* This method is required by the EJB Specification,
* but is not used by this example.
*
*/
public void ejbPassivate() {
log("ejbPassivate called");
}
/**
* Sets the session context.
*
* @param ctx SessionContext Context for session
*/
public void setSessionContext(SessionContext ctx) {
log("setSessionContext called");
this.ctx = ctx;
}
/**
* This method is required by the EJB Specification,
* but is not used by this example.
*
*/
public void ejbCreate () throws CreateException {
log("ejbCreate called");
}
}

8.1 リモート・インタフェース

package examples.statelessSession;
import java.rmi.RemoteException;
import javax.ejb.EJBObject;
/**
* The methods in this interface are the public face of HelloWorld.
* The signatures of the methods are identical to those of the EJBean, except
* that these methods throw a java.rmi.RemoteException.
*/
public interface HelloWorld81 extends EJBObject {
/**
* Simply says hello from the EJB
*
* @param num               int number to return
* @param s                 String string to return
* @return                  String returnValue
* @exception               RemoteException if there is
*                          a communications or systems failure
*/
String sayHello(int num, String s)
throws RemoteException;
}

8.1 EJBホーム・インタフェース

package examples.statelessSession;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBHome;
/**
* This interface is the Home interface of the HelloWorld stateless session EJB.
*/
public interface HelloWorldHome81 extends EJBHome {
/**
* This method corresponds to the ejbCreate method in the
* HelloWorldBean81.java file.
*/
HelloWorld81 create()
throws CreateException, RemoteException;
}

対応する12.1.xのJWSファイル

8.1のファイルと12.1.xのファイルの相違点は太字で示してあります。一部のJWSアノテーションの値は、「8.1と更新された12.1.xのAntビルド・ファイルの例(EJB実装の8.1のWebサービス)」に示す8.1のservicegen Antタスクの属性から取得されています。

package examples.webservices.upgrade_ejb;
// Import the standard JWS annotations
import javax.jws.WebMethod;
import javax.jws.WebService;
import javax.jws.soap.SOAPBinding;
// Import the WebLogic specific annotation
import weblogic.jws.WLHttpTransport;
// Class-level annotations
@WebService(name="HelloWorld92PortType", serviceName="HelloWorldService",
targetNamespace="http://example.org")
@SOAPBinding(style=SOAPBinding.Style.DOCUMENT,
use=SOAPBinding.Use.LITERAL,
parameterStyle=SOAPBinding.ParameterStyle.WRAPPED)
@WLHttpTransport(contextPath="upgradeEJB", serviceUri="HelloWorldService",
portName="HelloWorld92Port")
/**
* HelloWorld92Impl is the JWS equivalent of the HelloWorld81 EJB that
* implemented the 8.1 Web Service.  It has a single method,
* sayHello(), that takes an integer and a String and returns a String.
*/
public class HelloWorld92Impl {
/** the sayHello method will become the public operation of the Web
*  Service.
*/
@WebMethod()
public String sayHello(int num, String s) {
System.out.println("sayHello in the HelloWorld92 Web Service has "+
"been invoked with arguments " + s + " and " + num);
String returnValue = "This message brought to you by the "+
"letter "+s+" and the number "+num;
return returnValue;
}
}

8.1と更新された12.1.xのAntビルド・ファイルの
例(EJB実装の8.1のWebサービス)

次の単純なbuild.xmlファイルでは、8.1でservicegen Antタスクを使用してEJB実装のWebLogic Webサービスをビルドする方法を示します。この例の後に、jwsc Antタスクを呼び出して12.1.xのWebサービスをビルドする場合の、対応するbuild.xmlファイルを示します。

<project name="ejb-webservice" default="all" basedir=".">
<!-- set global properties for this build -->
<property name="source" value="."/>
<property name="build" value="${source}/build"/>
<property name="ejb_file" value="HelloWorldWS.jar" />
<property name="war_file" value="HelloWorldWS.war" />
<property name="ear_file" value="HelloWorldApp.ear" />
<property name="namespace" value="http://examples.org" />
<target name="all" depends="clean,ear"/>
<target name="clean">
<delete dir="${build}"/>
</target>
<!-- example of old 8.1 servicegen call to build Web Service -->
<target name="ejb">
<delete dir="${build}" />
<mkdir dir="${build}"/>
<mkdir dir="${build}/META-INF"/>
<copy todir="${build}/META-INF">
<fileset dir="${source}">
<include name="ejb-jar.xml"/>
</fileset>
</copy>
<javac srcdir="${source}" includes="HelloWorld*.java"
destdir="${build}" />
<jar jarfile="${ejb_file}" basedir="${build}" />
<wlappc source="${ejb_file}" />
</target>
<target name="ear" depends="ejb">
<servicegen
destEar="${build}/${ear_file}"
warName="${war_file}">
<service
ejbJar="${ejb_file}"
targetNamespace="${namespace}"
serviceName="HelloWorldService"
serviceURI="/HelloWorldService"
generateTypes="True"
expandMethods="True">
</service>
</servicegen>
</target>
</project>

これに対応するものとして、jwsc Antタスクを呼び出して12.1.xのWebサービスをビルドするbuild.xmlファイルを次に示します(この項で説明する該当タスクは太字で示してあります)。

<project name="webservices-upgrade_ejb" default="all">
<!-- set global properties for this build -->
<property name="wls.username" value="weblogic" />
<property name="wls.password" value="weblogic" />
<property name="wls.hostname" value="localhost" />
<property name="wls.port" value="7001" />
<property name="wls.server.name" value="myserver" />
<property name="ear.deployed.name" value="upgradeEJB" />
<property name="example-output" value="output" />
<property name="ear-dir" value="${example-output}/upgradeEJB" />
<taskdef name="jwsc"
classname="weblogic.wsee.tools.anttasks.JwscTask" />
<taskdef name="wldeploy"
classname="weblogic.ant.taskdefs.management.WLDeploy"/>
<target name="all" depends="clean,build-service,deploy" />
<target name="clean" depends="undeploy">
<delete dir="${example-output}"/>
</target>
<target name="build-service">
<jwsc
srcdir="src"
destdir="${ear-dir}">
<jws file="examples/webservices/upgrade_ejb/HelloWorld92Impl.java" />
</jwsc>
</target>
<target name="deploy">
<wldeploy action="deploy" name="${ear.deployed.name}"
source="${ear-dir}" user="${wls.username}"
password="${wls.password}" verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}" />
</target>
<target name="undeploy">
<wldeploy action="undeploy" name="${ear.deployed.name}"
failonerror="false"
user="${wls.username}" password="${wls.password}" verbose="true"
adminurl="t3://${wls.hostname}:${wls.port}"
targets="${wls.server.name}" />
</target>
</project>

servicegen属性とJWSアノテーションまたはjwsc属性のマッピング

次の表に、8.1のservicegen Antタスクの属性と、それに対応する12.1.xのJWSアノテーションまたはjwsc属性を示します。

最初の列には、メインのservicegen Antタスクの属性と、servicegenの4つの子要素(<service>、<client>、<handlerChain>、および<security>)の属性が混在しています。

12.1.xのJWSアノテーションとjwsc Antタスクの詳細は、『Oracle WebLogic Server WebLogic Webサービス・リファレンス』のJWSアノテーション・リファレンスと「jwsc」を参照してください。

表7-2 servicegen属性とJWSアノテーションまたはjwsc属性のマッピング

servicegenまたはservicegenの子要素の属性

対応するJWSアノテーションまたはjwsc属性

contextURI

WebLogic固有の@WLHttpTransportアノテーションのcontextPath属性。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

destEAR

jwsc Antタスクのdestdir属性。

keepGenerated

jwsc AntタスクのkeepGenerated属性。

mergeWithExistingWS

対応する属性はありません。

overwrite

対応する属性はありません。

warName

jwsc Antタスクの<jws>子要素のname属性。

ejbJAR

(service子要素の属性)

jwsc Antタスクは、コンパイルされたEJBまたはJavaクラスからではなく、JWSファイルからWebサービス・アーティファクトを生成するため、直接的に対応するものはありません。

間接的に対応するのは、JWSファイルの名前を指定するjwsc Antタスクの<jws>子要素のfile属性。

excludeEJBs

(service子要素の属性)

対応する属性はありません。

expandMethods

(service子要素の属性)

対応する属性はありません。

generateTypes

(service子要素の属性)

対応する属性はありません。

ignoreAuthHeader

(service子要素の属性)

対応する属性はありません。

includeEJBs

(service子要素の属性)

対応する属性はありません。

javaClassComponents

(service子要素の属性)

jwsc Antタスクは、コンパイルされたEJBまたはJavaクラスからではなく、JWSファイルからWebサービス・アーティファクトを生成するため、直接的に対応するものはありません。

間接的に対応するのは、JWSファイルの名前を指定するjwsc Antタスクの<jws>子要素のfile属性。

JMSAction

(service子要素の属性)

JMS実装のWebサービスは12.1.xリリースではサポートされないため、対応するものはありません。

JMSConnectionFactory

(service子要素の属性)

JMS実装のWebサービスは12.1.xリリースではサポートされないため、対応するものはありません。

JMSDestination

(service子要素の属性)

JMS実装のWebサービスは12.1.xリリースではサポートされないため、対応するものはありません。

JMSDestinationType

(service子要素の属性)

JMS実装のWebサービスは12.1.xリリースではサポートされないため、対応するものはありません。

JMSMessageType

(service子要素の属性)

JMS実装のWebサービスは12.1.xリリースではサポートされないため、対応するものはありません。

JMSOperationName

(service子要素の属性)

JMS実装のWebサービスは12.1.xリリースではサポートされないため、対応するものはありません。

protocol

(service子要素の属性)

以下のいずれかのWebLogic固有アノテーション。

- @WLHttpTransport

- @WLJmsTransport

注意: これらはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

serviceName

(service子要素の属性)

標準の@WebServiceアノテーションのserviceName属性。

serviceURI

(service子要素の属性)

WebLogic固有の@WLHttpTransportまたは@WLJmsTransportアノテーションのserviceUri属性。

注意: これらはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

style

(service子要素の属性)

標準の@SOAPBindingアノテーションのstyle属性。

typeMappingFile

(service子要素の属性)

対応する属性はありません。

targetNamespace

(service子要素の属性)

標準の@WebServiceアノテーションのtargetNamespace属性。

userSOAP12

(service子要素の属性)

WebLogic固有の@weblogic.jws.Binding JWSアノテーションのvalue属性。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

clientJarName

(client子要素の属性)

対応する属性はありません。

packageName

(client子要素の属性)

直接的に対応する属性はありません。

クライアント・サイドJavaコードおよびアーティファクトを生成するには、clientgen AntタスクのpackageName属性を使用します。

saveWSDL

(client子要素の属性)

対応する属性はありません。

userServerTypes

(client子要素の属性)

対応する属性はありません。

handlers

(handlerChain子要素の属性)

標準の@HandlerChainまたは@SOAPMessageHandlersアノテーション。

name

(handlerChain子要素の属性)

標準の@HandlerChainまたは@SOAPMessageHandlersアノテーション。

duplicateElimination

(reliability子要素の属性)

直接的に対応する属性はありません。

Webサービスの信頼性のあるメッセージングのポリシー・アサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』のWebサービスの信頼性のあるメッセージングの使用に関する項を参照してください。

persistDuration

(reliability子要素の属性)

直接的に対応する属性はありません。

Webサービスの信頼性のあるメッセージングのポリシー・アサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

このリリースでは、対応する属性はJAX-RPC Webサービスに対してのみ有効です。『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』のWebサービスの信頼性のあるメッセージングの使用に関する項を参照してください。

enablePasswordAuth

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

encryptKeyName

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

encryptKeyPass

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

password

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

signKeyName

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

signKeyPass

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

username

(security子要素の属性)

直接的に対応する属性はありません。

メッセージ・レベルのセキュリティ・ポリシーのアサーションを含むWS-Policyファイルを指定するには、WebLogic固有の@Policy属性を使用します。

注意: これはWebLogic固有のアノテーションであるため、JAX-RPC Webサービスの生成にのみ使用可能であり、JAX-WS Webサービスの生成には使用できません。

『Oracle WebLogic Server WebLogic Webサービスの保護』のメッセージ・レベルのセキュリティの構成に関する項を参照してください。

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

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

WebLogic JAX-WSのランタイムは、JAX-WS (The Java API for XML-Based Web Services) 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はサポートしていません。rpc-encodedが必要な場合は、8.1 Webサービスを、JAX-WSではなくJAX-RPCモデルにアップグレードすることを検討してください。

- SOAP配列はJAX-WSではサポートされていませんが、JAX-RPCで使用できます。

JAX-WSの詳細は、次のドキュメントを参照してください。

- Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド

- Oracle WebLogic Server JAX-WS Webサービスの高度な機能のプログラミング

このページのスクリプトは、ナビゲーション目的のみのもので、内容を変更しません。

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

この項では、WebLogic Server 12.1.1にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。

このリリースおよび以前のリリースの、『Oracle WebLogic Serverの理解』のWebLogic Serverの互換性に関する項と、『Oracle WebLogic Serverの新機能』も参照してください。

互換性に関する検討事項は、次のように分類されます。すべてのケースにおいて、参照先は次のとおりです。

- 非推奨になった機能

- 下位互換性フラグ

ユーザーの状況に該当するその他の項は、WebLogic Server 12.1.1にアップグレードする前のWebLogic Serverのバージョンによって異なります。WebLogic Serverの現在のバージョンに基づいて参照する各項の一覧については、表A-1を参照してください。

表A-1 各バージョンのWebLogic Serverからのアップグレードに適用される項

WebLogic Serverのバージョン

これらの項を参照

10.3.5

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

上記のすべての項、および次の項:

capacityIncrement属性

Middlewareホーム・ディレクトリ

リソース登録名

10.0

上記のすべての項、および次の項:

SAML 2.0プロバイダ

RDBMSセキュリティ・ストア

更新されたWebLogicブランドのDataDirectドライバ

コンソール構成機能

使用されなくなったSNMP MIBリフレッシュ間隔とサーバー・ステータス・チェック間隔

9.2

上記のすべての項、および次の項:

非推奨となったWindows NT認証プロバイダ

下位互換性フラグ

JMX 1.2実装

9.1

上記のすべての項、および次の項:

SAML V2プロバイダ

保護されていないリソースを使用するBASIC認証

WebLogicの管理および構成スクリプト

9.0

上記のすべての項、および次の項:

XACMLセキュリティ・プロバイダ

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

8.1

上記のすべての項、および次の項:

セキュリティMBean

パスワードの暗号化

HTTPリクエストのセキュリティ

MBeanHomeへのセキュア・アクセス

Webサービスにおけるメッセージ・レベルのセキュリティ

JMSリソースのモジュール式構成およびデプロイメント

JMSメッセージID形式

メッセージ・ページングの改善

JTAトランザクション・ログの移行

管理コンソールの拡張アーキテクチャ

動的構成管理

JDBCリソースのモジュール式構成およびデプロイメント

スレッド管理

XML実装

XMLBeans実装とXQuery実装

デプロイメント記述子の検証および変換

非推奨となった起動クラスと停止クラス

リソース・アダプタ

WLEC

非推奨になった機能

WebLogic Serverの非推奨になった機能に関する情報は、My Oracle Support(https://support.oracle.com/)で入手できます。

- 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」で検索してください。

下位互換性フラグ

表A-2の構成フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル・モードでのアップグレード」で説明されているように、アップグレード中に「下位互換性フラグを設定しない」オプションを選択して無効にしないかぎり、下位互換性をサポートするためデフォルトで設定されます。

表A-2 下位互換性フラグ

カテゴリ

下位互換性フラグ

詳細については、次を参照...

セキュリティ

- EnforceStrictURLPattern :サーバーがURLパターンのサーブレット2.4仕様への厳密な準拠を強制するかどうかを指定します。アップグレード中、このフラグは、下位互換性をサポートするためfalseに設定されます。

- WebAppFilesCaseInsensitive : Webappコンテナおよび外部セキュリティ・ポリシーにおいて、URLパターン・マッチング動作がセキュリティ制約、サーブレット、フィルタ、仮想ホストなどの大文字と小文字を区別するかどうかを指定します。アップグレード中、このフラグは、9.0より前のリリースとの互換性をサポートするため、URLパターン・マッチングがWindows以外のすべてのプラットフォームで大文字と小文字を区別するよう、osに設定されます。WebLogic Server 9.0以降では、URLパターン・マッチングは、複数のオペレーティング・システムにまたがって厳密に行われます。

「SecurityConfigurationMBean」

Webアプリケーション

- backward-compatible :サポートされるJSPバージョンを指定します。Webアプリケーションのバージョン(バージョン2.4または2.5)とbackward-compatible要素の設定に応じて、WebLogic Server 12.1.1ではJSP 2.1またはJSP 2.0がサポートされます。
backward-compatibleは"jsp-descriptor"要素内に配置されます(『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』を参照)。

- AllowAllRoles: ロール名の設定にワイルドカード文字(*)を使用できるようにして、レルムのすべてのユーザーまたはロールがリソースの集合にアクセスできるよう指定します。WebLogic Server 9.0以降では、ロール名としてワイルドカード文字(*)を指定すると、Webアプリケーションのすべてのユーザーまたはロールがリソースの集合にアクセスできるよう指定します。

- FilterDispatchedRequestsEnabled :ディスパッチされたリクエストにフィルタを適用するかどうかを指定します。WebLogic Server 9.0以降では、この動作は、新しいDispatcher要素により明示的に設定されます。

- JSPCompilerBackwardsCompatible : JSP 2.0仕様に準拠しないJSPが使用できるかどうかを指定します。

- ReloginEnabled :元の資格証明がサポートされていない場合に、ユーザーが複数回Webページへのログインを試みることができるかどうかを指定します。WebLogic Server 9.0以降では、FORM/BASIC認証の動作は、403 (FORBIDDEN)ページを返すよう修正されています。

- RtexprvalueJspParamName : JSP <param name>タグで実行時の式の値を使用できるかどうかを指定します。WebLogic Server 9.0以降では、JSPコンパイラで実行時の式の値は使用できません。

「WebAppContainerMBean」

JVMの設定

WebLogic Server 11g以前のドメインをWebLogic Server 12.1.1ドメインにアップグレードする際は、次の操作が必要な場合があります。

- Java承認ディレクトリ(JRE_HOME/lib/endorsed)の場所の手動設定

- 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.dirパラメータを含めてください。

startWeblogic.sh -Djava.endorsed.dir=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または管理コンソールを使用して、-Djava.endorsed.dirs=/WL_HOME/endorsed")パラメータをServerStartMBeanのarguments属性に含めることができます。管理コンソールを使用中の場合、サーバーの「構成」>「サーバーの起動」タブでこのパラメータを「引数」フィールドに入力します。管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、または管理コンソールでサーバーの「起動」ボタンをクリックした際にこの属性は適用されます。

permgen領域の設定

管理対象サーバーの起動時にOutOfMemory: PermGen Spaceエラーが発生した場合は、permgen領域を128MB以上に手動設定し、最大permgen領域を256MB以上に拡張する必要があります。

注意:

ここで記述されているオプションではすべて、WL_HOMEを自分のWebLogic Serverインストールのフル・パスに置き換える必要があります。

これを実行するには、WLSTまたは管理コンソールを使用して、ServerStartMBeanのarguments属性に次のように指定します。管理コンソールを使用中の場合、サーバーの「構成」>「サーバーの起動」タブでこのパラメータを「引数」フィールドに入力します。管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、または管理コンソールでサーバーの「起動」ボタンをクリックした際にこの属性は適用されます。

startWeblogic.sh -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.1でKodoを永続プロバイダとして引き続き使用するアプリケーションは、更新する必要があります。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansバージョン3.0のプログラミング』の競合を解決するためのアプリケーションの更新に関する項を参照してください。

WebLogic Server 12.1.1から、JPA 2.0のサポートが組み込まれています。JPA 2.0では、ドメイン・モデリング、オブジェクト/リレーショナル・マッピング、EntityManagerインタフェース、問合せインタフェースおよびJava Persistence Query Language (JPQL)などの各機能が向上し、強化されています。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansバージョン3.0のプログラミング』のWebLogic ServerでのJPA 2.0とTopLinkの使用に関する項を参照してください。

WebLogic Server 10.3.2から、EJB 3.0アプリケーションでOracle TopLinkの機能を活用できます。Oracle TopLinkは、高度なオブジェクト永続性およびオブジェクト変換フレームワークであり、開発と保守にかかる労力を削減して、エンタープライズ・アプリケーションの機能性を高める開発ツールと実行時機能を提供します。詳細については、『Oracle Fusion Middleware Oracle TopLink開発者ガイド』を参照してください。

Webサービス

この項では、WebLogic Server 12.1.1から削除されているWebサービス機能、ならびにWebLogic Server 10.3.3以上で追加された新規のWebサービス機能について説明します。

注意:

「Webサービスにおけるメッセージ・レベルのセキュリティ」も参照してください。

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)に移行することをお薦めします。

新しい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より前のリリースでは、管理コンソールを使用して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サービスに関する項を参照してください。

セキュリティ

この項では、様々なWebLogic Serverリリースについて行われているセキュリティの変更について説明します。

SSLサポートの変更

この項では、様々なWebLogic Serverバージョンについて行われているSSLの変更について説明します。

Certicom SSLの実装

WebLogic Server 12.1.1から、Certicom SSLの実装は削除されています。この変更によって、『Oracle WebLogic Serverの保護』のSSLの構成に関する項に記述されているように、システム・プロパティの更新とスイッチのデバッグが必要になる場合があります。

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セキュリティの理解』のSecure Sockets Layer (SSL)に関する項を参照してください。

- JSSEの詳細は、『Java Secure Socket Extension (JSEE) Reference Guide』(http://download.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html)を参照してください。

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認可プロバイダおよびロール・マッピング・プロバイダは、この要件を満たしています。

ただし、カスタムのデプロイ可能な認可プロバイダまたはロール・マッピング・プロバイダで並列呼出しがサポートされていない場合は、セキュリティ・ポリシーとロールの並列変更を無効にし、かわりに同期メカニズムを強制的に使用する必要があります。この場合、各アプリケーションとモジュールはキューに入り、順番にデプロイされます。この同期強制メカニズムは、管理コンソールまたはRealmMBeanのDeployableProviderSynchronizationEnabled属性とDeployableProviderSynchronizationTimeout属性を使用することで有効にできます。

詳細は、『Oracle WebLogic Serverの保護』のデプロイメント時のセキュリティ・ポリシーとロール変更での同期の有効化に関する項を参照してください。

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認証プロバイダの構成に関する項を参照してください。

SAML 2.0プロバイダ

WebLogic Server 10.3では、SAML 2.0をサポートするため、SAML 2.0資格証明マッピング・プロバイダおよびSAML 2.0 IDアサーション・プロバイダが追加されました。これらの新しいプロバイダはそれぞれ、次を利用する場合にSAML 2.0アサーションの生成および消費に使用することができます。

- SAML 2.0 Webシングル・サインオン・プロファイル

- WS-Security SAMLトークン・プロファイル・バージョン1.1

SAML 2.0 Webシングル・サインオンでは、SAML 2.0資格証明マッピング・プロバイダで生成されるアサーションを消費できるのは、SAML 2.0 IDアサーション・プロバイダのみです。これらはSAML 1.1アサーションと互換性がありません。

SAML Token Profile 1.1は、リリース10.3のWebLogic Server Webサービスからサポートされるようになりました。また、SAML 2.0およびSAML 1.1アサーションがサポートされ、SAMLトークン・プロファイル1.0との下位互換性も保たれます。SAMLトークンのWebサービスに対する構成は、適切なWS-SecurityPolicyアサーションを利用して行います。

注意:

SAML Token Profile 1.1はWS-SecurityPolicyを通じてのみサポートされます。以前の「WebLogic Server 9.2セキュリティ・ポリシー」では、SAML Token Profile 1.0/SAML 1.1のみがサポートされます。

RDBMSセキュリティ・ストア

WebLogic Server 10.3では、次のセキュリティ・プロバイダで使用されるデータ・ストアとして、外部RDBMSを使用できるようになりました。

- XACML認可プロバイダ

- XACMLロール・マッピング・プロバイダ

- SAML 1.1の次のプロバイダ

- SAML IDアサーション・プロバイダV2

- SAML資格証明マッピング・プロバイダV2

- SAML 2.0の次のプロバイダ

- SAML 2.0 IDアサーション・プロバイダ

- SAML 2.0資格証明マッピング・プロバイダ

- WebLogic資格証明マッピング・プロバイダ

- PKI資格証明マッピング・プロバイダ

- 証明書レジストリ

このデータ・ストアはRDBMSセキュリティ・ストアと呼ばれますが、クラスタなどのドメイン内の複数のWebLogic ServerインスタンスでSAML 2.0サービスを使用する場合に強くお薦めします。ドメイン内にRDBMSセキュリティ・ストアが構成されている場合、セキュリティ・レルム内に作成されている上記のいずれかのセキュリティ・プロバイダのインスタンスは、自動的にRDBMSセキュリティ・ストアのみをデータ・ストアとして使用し、組込みLDAPサーバーは使用しません。ドメイン内に構成されている上記のリスト以外のWebLogicセキュリティ・プロバイダは、それぞれのデフォルト・ストアを使用します。たとえば、WebLogic認証プロバイダは組込みLDAPサーバーを使用します。

RDBMSセキュリティ・ストアを使用するには、まず、ドメインを作成して外部RDBMSサーバーを構成します。ドメインを起動する前に、RDBMSセキュリティ・ストアで必要になる表をデータ・ストア内に作成します。WebLogic Serverインストール・ディレクトリには、サポート対象のデータベースごとに、これらの表を作成する一連のSQLスクリプトが含まれています。

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

非推奨となったWindows NT認証プロバイダ

Windows NT認証プロバイダは、WebLogic Server 10.0以降では非推奨となっています。かわりに、それ以外のサポート対象の1つまたは複数の認証プロバイダを使用してください。

SAML V2プロバイダ

WebLogic Server 9.2では、SAML 1.1をサポートするため、SAML資格証明マッピング・プロバイダおよびSAML IDアサーション・プロバイダの新バージョンが追加されました。SAML資格証明マッピングV1プロバイダおよびSAML IDアサーションV1プロバイダは非推奨となったため、SAML資格証明マッピング・プロバイダおよびSAML IDアサーション・プロバイダの各V2バージョンを使用してください。

各プロバイダのバージョン番号は加算されてV2になっていますが、新しいSAMLセキュリティ・プロバイダにも、V1プロバイダと同じSAML 1.1標準が実装されています。

注意:

Webシングル・サインオンに関して、この項で説明しているSAML 1.1プロバイダは、SAML 2.0サービスが構成されているWebLogic Serverインスタンスとは互換性がありません。

XACMLセキュリティ・プロバイダ

WebLogic Server 9.1には、XACML認可プロバイダおよびXACMLロール・マッピング・プロバイダという2つの新しいセキュリティ・プロバイダが含まれています。WebLogic Serverの以前のリリースでは、独自のセキュリティ・ポリシー言語に基づいた認可プロバイダとロール・マッピング・プロバイダを使用していました。これらのXACMLセキュリティ・プロバイダでは、OASISの標準規格XACML (eXtensible Access Control Markup Language)2.0をサポートしています。これらのプロバイダでは、標準のXACML 2.0関数、属性、スキーマ要素で表現されたポリシーを、インポート、エクスポート、永続化および実行できます。

WebLogic Server 9.1以降を使用して作成したWebLogicドメインには、XACMLプロバイダがデフォルトで含まれています。これら新しいXACMLプロバイダは、WebLogic認可プロバイダ(DefaultAuthorizer)およびWebLogicロール・マッピング・プロバイダ(DefaultRoleMapper)で作成したポリシーやロールに対して完全な互換性があります。既存のWebLogicドメインを12.1.1にアップグレードして、現在指定されている認可プロバイダおよびロール・マッピング・プロバイダ(サード・パーティ・パートナのプロバイダ、オリジナルのWebLogic認可プロバイダおよびロール・マッピング・プロバイダなど)を引き続き使用できます。WebLogic Server独自のプロバイダを使用している既存ドメインを、必要に応じてXACMLプロバイダに移行することもできます(既存ポリシーのバルク・インポートも含む)。詳細は、『Oracle WebLogic Serverの理解』のWebLogic Serverのセキュリティの理解に関する項を参照してください。

セキュリティMBean

表A-3に、WebLogic Server 9.0におけるセキュリティMBeanの変更点を示します。

表A-3 WebLogic Server 9.0におけるセキュリティMBeanの変更点

セキュリティMBeanのタイプ

説明

すべてのセキュリティMBean

WebLogic Server 8.1では、セキュリティMBean属性を更新すると、値はセキュリティ構成と管理階層ではただちに有効になり、セキュリティ実行時階層ではサーバーを再起動すると有効になっていました。

WebLogic Server 9.0からは、セキュリティMBean属性の変更が構成、管理、および実行時階層でただちに有効になるか、サーバーを再起動すると有効になるかについては、この属性を動的な属性として設定するか動的でない属性として設定するかによって制御されます。詳細については、「動的構成管理」を参照してください。

RealmMBean、UserLockoutManagerMBean、およびすべてのセキュリティ・プロバイダMBean

- wls_getDisplayメソッドが非推奨となりました。そのかわりとして、新しいgetNameメソッドが使用されるようになりました。また、次のセキュリティ・メソッドが削除されました。

wls_getAttributeTag
wls_getConstructorTag
wls_getMBeanTag
wls_getNotificationTag
wls_getOperationTag

- セキュリティMBeanを構成するときにweblogic.Adminツール、および9.2より前のバージョンのJMXセキュリティAPIを使用することができなくなりました。ただし、これらのユーティリティとAPIは、セキュリティMBeanでのメソッドの表示および呼出しには使用できます。

セキュリティ・プロバイダMBeansの場合(のみ)

- セキュリティ・プロバイダを追加または削除するとき、サーバーを再起動しなければ、変更は有効になりません。

- 既存のセキュリティ・プロバイダを修正するとき、動的でない属性を修正する場合は、サーバーを再起動する必要があり、すべての変更(動的でない変更または動的な変更の両方)が有効になりません。詳細については、「動的構成管理」を参照してください。

すべてのカスタム・セキュリティ・プロバイダMBean

- デフォルトでは、カスタム・セキュリティ・プロバイダMBeanの属性はすべて動的でない属性です。詳細については、「動的構成管理」を参照してください。

- MBean属性を動的な属性として設定するには、MDFファイル内の属性をDynamic="true"と設定します。例:

<MBeanAttribute
Name        = "Foo"
Type        = "java.lang.String"
Dynamic = "true"
Description = "Specifies that this attribute is a dummy."
/>

パスワードの暗号化

権限のないアクセスからパスワードなどの重要なデータを保護するために、構成MBeanのいくつかの属性は暗号化されます。属性の値は、ドメインの構成ファイルに暗号化された文字列として保持されます。メモリー内の値が暗号化されたバイト配列として保存されるため、パスワードがメモリーから盗用されるリスクが軽減され、セキュリティがさらに強化されます。

9.0より前のリリースでは、クリア・テキスト形式または暗号化形式で、パスワードなどの暗号化する属性をconfig.xmlファイルで指定することができました。この場合、起動時にWebLogic Serverは、次回ファイルに書き込むときに情報を暗号化します。

WebLogic Server 9.0から、本番モードのときは、パスワードなどの暗号化する属性は構成ファイルで暗号化されなければなりません。開発モードのときは、パスワードなどの暗号化する属性はクリア・テキスト形式または暗号化形式のどちらでもかまいません。

次のように、weblogic.security.Encryptコマンド・ライン・ユーティリティを使用してパスワードを暗号化することができます。

java weblogic.security.Encrypt

ここで、パスワードを入力するよう求められます。パスワードを入力すると、暗号化されたバージョンが返されます。次に、暗号化されたパスワードを適切なファイルにコピーします。

このユーティリティの対象は、構成ファイルのパスワードだけではありません。これは、記述子ファイル(JDBCまたはJMS記述子など)およびデプロイメント・プランでパスワードを暗号化する場合にも使用できます。詳細は、Oracle WebLogic Serverのコマンド・リファレンスの「encrypt」を参照してください。

HTTPリクエストのセキュリティ

デフォルトでは、WebLogic ServerのインスタンスがHTTPリクエストに応答するとき、HTTPレスポンス・ヘッダーにWebLogic Serverのサーバー名およびバージョン番号は含まれません。この動作は、WebLogic Server 9.0より前のリリースとは異なります。

HTTPリクエストに応答するときにサーバー名とバージョン番号をHTTPレスポンス・ヘッダーに含めるには、管理コンソールでWebLogic Serverインスタンスの「サーバー・ヘッダーの送信」属性を有効にします。この属性は、「サーバー」→「サーバー名」→プロトコル→「HTTP」タブの詳細オプション・セクションにあります。この機能を有効にすると、攻撃者がWebLogic Serverの特定のバージョンの脆弱性についての知識がある場合、これによりセキュリティ・リスクが発生する可能性があります。

セキュリティを確保する方法の詳細は、『Oracle WebLogic Server本番環境の保護』の本番環境の保護に関する項を参照してください。

MBeanHomeへのセキュア・アクセス

9.0より前のリリースのWebLogic Serverでは、MBeanHomeへの匿名アクセスがデフォルトで可能でした。WebLogic Server 9.0以降では、セキュリティが強化されているため、MBeanHomeへの匿名アクセスはできなくなりました。

これは推奨されませんが、サーバーを起動するときに次のフラグを指定することにより、匿名アクセスを再び有効にすることができます。

-Dweblogic.management.anonymousAdminLookupEnabled

Webサービスにおけるメッセージ・レベルのセキュリティ

WebLogic Server 9.0から、Webサービスにおけるメッセージ・レベルのセキュリティが強化され、標準ベースのWeb Services Policy Framework (WS-Policy)を使用するようになりました。WS-Policyでは、XML Webサービス・ベースのシステム内にあるエンティティについての機能、要件、一般的な特性を表現する、柔軟で拡張性のある文法を使用できます。WS-Policyの詳細は、『Webサービスのためのセキュリティおよび管理者ガイド』のWS-SecurityPolicy 1.2ポリシー・ファイルの使用に関する項を参照してください。

8.1における実装は、Web Services Security (WSS)標準のOASISによる実装がベースとなっていました。この実装は9.0以降でも下位互換性のためにサポートされていますが、非推奨となっています。詳細については、http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wssを参照してください。

Webアプリケーション、JSP、およびサーブレット

次の項では、WebLogic Server 12.1.1におけるWebアプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。

- ActiveCache

- Coherenceのバージョン

- クラス・キャッシュ

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

- 保護されていないリソースを使用するBASIC認証

- 下位互換性フラグ

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

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」で検索してください。

ActiveCache

WebLogic Server 10.3.3以降では、WebLogic ServerにデプロイされているアプリケーションでのCoherenceデータ・キャッシュの使用が容易になり、セッション管理用のCoherence*WebとTopLink Gridをobject-to-relational永続フレームワークとしてシームレスに取り込めるようになりました。これらの機能の総称がActiveCacheです。

ActiveCacheでは、レプリケートおよび分散されたデータ管理とキャッシングのサービスが提供されており、このサービスを使用することで、アプリケーションのオブジェクトとデータをCoherenceクラスタ内のすべてのサーバーに対して利用可能にすることができます。

詳細は、ActiveCacheの使用を参照してください。

クラス・キャッシュ

リリース10.3.3で、WebLogic Serverでクラス・キャッシュを有効にできるようになりました。クラス・キャッシュを使用する利点を次に示します。

- サーバーの起動時間が短縮されます。

- パッケージ・レベルの索引により、すべてのクラスとリソースの検索時間が短縮されます。

クラス・キャッシュが開発モードでサポートされるのは、startWebLogicスクリプトを使用してサーバーを起動したときです。クラス・キャッシュはデフォルトでは無効になっており、本番モードではサポートされません。起動時間の短縮の程度は様々なJREベンダーによって異なります。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のクラス・キャッシュの構成に関する項を参照してください。

下位互換性フラグ

WebLogic Server 10.0以降では、この項および『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』のjsp-descriptorに関する項で説明されているように、WebLogic Server 9.2以前のリリースに対する下位互換性はjsp-descriptor要素内のbackward-compatible要素を使用してサポートされます。

JSP 2.1のサポートとJSP 2.0 Webアプリケーションとの互換性

JSP 2.1はWebLogic Server 10.0からサポートされています。Webアプリケーションのバージョン(バージョン2.4または2.5)とbackward-compatible要素の設定に応じて、WebLogic Server 10.0以降でもJSP 2.0がサポートされます。

バッファの接尾辞の設定およびサーブレット2.5パッケージの暗黙的なインポートについては、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』の下位互換性フラグに関する項を参照してください。

JSP 2.0のサポート

「下位互換性フラグ」で説明されているように、JSP 2.0はWebLogic Server 9.0以降でサポートされています。JSP 2.0のサポートに応じて、JSPの動作は次のように変更されています。

- JSPがセッションに参加していない場合(またはJSPが参加しているセッションが無効な場合)、次のコマンドが実行されると、IllegalStateExceptionがスローされます。

PageContext.getAttribute(name, PageContext.SESSION_SCOPE)

この例外は、このようなエラーが重要な問題でない場合は、捕捉して無視することができます。

- JspWriterImplがprintline関数ごとに\nをSystem.getProperty("line.separator")に置き換えるようになりました。この置換により、以下に該当するJSPで問題が発生します。

- 新しい行に表示される複数のpageディレクティブを含みます。例:

<%@ page import="com.foo.bar.*" %>
<%@ page import="com.foo.xyz.*" %>
...

- XML形式で出力を生成します。

- pageディレクティブに続いてXML宣言を生成します。

- Windowsシステムからサービスを受けています。この場合、pageディレクティブごとに\r\nが出力されます。

- Internet Explorerを使用して表示されます。
Internet Explorerで表示される場合、各pageディレクティブが空の\r\nを出力し、XML宣言(<?xml version="1.0" encoding="iso-8859-1"?>)が新しい行の後ろに表示されます。Internet Explorerは、宣言が検出されず、ページはコンパイルできるが表示できないことを通知するエラー・メッセージを表示します。

JspWriterImplに対する変更により生じた問題を解決するには、次のタスクのどちらかまたは両方を実行します。

- ページの最上部でXML宣言を定義します。

- 次のように、pageディレクティブを1つの宣言にグループ化します。

<%@ page import="com.foo.bar.*, com.foo.baz.*"
contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp" %>

- JSP <param name>タグで実行時の式の値を使用できなくなりました。例:

<jsp:param name="<%= AdminActions.RETURN_LINK %>" value="<%= returnlink %>" />

表5-1の「アップグレード・オプションの選択」行で説明されているように、ドメインのアップグレード中に「下位互換性フラグを設定しない」アップグレード・オプションを無効にするか、次のようにweblogic.xmlファイルでbackwardCompatibleフラグを有効にすることで、引き続きこの機能をサポートできます。

<jsp-descriptor>
<jsp-param>
<param-name>backwardCompatible</param-name>
<param-value>true</param-value>
</jsp-param>
</jsp-descriptor>

保護されていないリソースを使用するBASIC認証

WebLogic Serverバージョン9.2以降では、ターゲット・リソースにおいてアクセス制御が有効になっていない場合でも、HTTP BASIC認証を使用するクライアント・リクエストはWebLogic Server認証を通過しなければなりません。

この動作は、セキュリティ構成MBeanフラグ"enforce-valid-basic-auth-credentials"で指定します。(DomainMBeanを使用すると、そのドメインの新しいセキュリティ構成MBeanを取得できます。)このフラグは、非セキュアなリソースへのアクセスにおいて、無効なHTTP BASIC認証資格証明によるリクエストを許可するかどうかを指定します。

注意:

セキュリティ構成MBeanは、ドメイン全体のセキュリティ構成情報を提供します。enforce-valid-basic-auth-credentialsフラグは、ドメイン全体に影響します。

enforce-valid-basic-auth-credentialsフラグはデフォルトでtrueに設定されており、WebLogic Server認証が実行されます。認証に失敗すると、リクエストは拒否されます。したがって、ユーザーおよびパスワードの情報がWebLogic Serverに保持されている必要があります。

詳細は、『Oracle WebLogic Serverセキュリティのプログラミング』のリソースが非セキュアな場合のBASIC認証に関する項を参照してください。

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

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

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に移行できます。

詳細は、「評価版データベースを使用するドメインのアップグレード」を参照してください。

JDBC機能の変更点

以降の項では、JDBCサポートの変更点について説明します。

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

- セッション・アフィニティ・ポリシー

- 接続ラベリング

- ONSのデバッグ

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

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

- capacityIncrement属性

- JDBC 4.0サポート

- 更新されたWebLogicブランドのDataDirectドライバ

新しいJDBC機能の詳細は、『Oracle WebLogic Serverの新機能』のJDBCに関する項を参照してください。

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

操作性とパフォーマンスを向上させるため、WebLogic Server 12.1.1以上ではデータ・ソース・プロファイル・ログを使用してイベントが格納されます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のWebLogic JDBCリソースの監視に関する項を参照してください。

セッション・アフィニティ・ポリシー

WebLogic Server 12.1.1では、GridLinkデータ・ソースによってセッション・アフィニティ・ポリシーが使用され、パフォーマンスの向上のためにサーブレット・セッションのデータベース操作がRACクラスタ内の同じRACインスタンスに指示されます。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のGridLinkアフィニティに関する項を参照してください。

接続ラベリング

WebLogic Server 12.1.1では、アプリケーションでラベリングを使用することで、任意の名前/値のペア(ラベル)を特定の初期化状態の接続にアタッチできます。これによって接続を再初期化する時間とコストが最小限に抑えられるため、アプリケーションにおけるパフォーマンスが向上します。『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の接続のラベリングに関する項を参照してください。

ONSのデバッグ

WebLogic Server 12.1.1では、UCPおよびONSはインストールに含まれなくなりました。UCPおよびONSのデバッグの設定方法の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のUCP/ONSのデバッグの設定に関する項を参照してください。

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

WebLogic Server 12.1.1から、DataDirectのOracleタイプ4 JDBCドライバは、WebLogicブランドのDataDirectドライバと呼ばれるようになりました。オラクル社では『Oracle WebLogic Serverタイプ4 JDBCドライバ』のドキュメントの提供を停止するため、DataDirectドライバの詳細情報は今後提供されなくなります。WebLogic Server環境におけるWebLogicブランドのDataDirectドライバの構成および使用方法については引き続き、『Oracle WebLogic Server JDBCのプログラミング』のWebLogicブランドのDataDirectドライバの使用に関する項で情報を提供します。ドライバの動作の詳細はDataDirectのドキュメントを確認することをお薦めします。『Progress DataDirect for JDBC User's Guide Release 4.2』および『Progress DataDirect for JDBC Reference Release 4.2』(http://www.datadirect.com/index.html)を参照してください。

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

次のJDBCドライバは非推奨となりました。

- Oracle用のWebLogicタイプ4 JDBCドライバ
このドライバは、WebLogic Server 10.3で非推奨になり、削除されています。この非推奨のドライバのかわりに、WebLogic Serverにも付属しているOracle Thin Driverを使用してください。Oracle Thin Driverの詳細は、『Oracle WebLogic Serverタイプ4 JDBCドライバ』のWebLogic Serverでのサード・パーティJDBCドライバの使い方に関する項を参照してください。

- Sybase Jconnect 5.5および6.0ドライバ。これらのドライバは、サンプル・コードのデフォルト・インストールに関するOracleセキュリティ・ポリシーに従ってリリース10.3.3の時点でWebLogic Serverから削除されました。これらのドライバはSybaseからダウンロードできます。また、WebLogic Serverに付属しているOracleブランドのSybase用JDBCドライバを使用することもできます。

capacityIncrement属性

WebLogic Server 10.3.1以上のリリースでは、capacityIncrement属性は構成可能ではなく、1という値に設定されます。

JDBC 4.0サポート

10.3以降のWebLogic Serverは、JDBC 4.0仕様に準拠しています。ただし、次の拡張と例外を含みます。

- サーバー側では、SQLXMLが完全にサポートされています。RMIクライアント側では、SQLXMLを部分的にサポートしています。クライアント側で、API getSourceとsetResultを使用することはできません。

- WebLogic Server JDBCでは、標準のラッパー・パターン機能がサポートされており、サーバー側の機能を拡張します。JDBC標準では、インタフェースにラッパー操作のサポートが必要になります。WebLogic Serverでは、サーバー側の具象クラスとインタフェースの両方でラッパー操作がサポートされます。

- WebLogic Serverでは、次のように文プール管理が拡張されます。

- Statementインタフェースの場合:

- isPoolable()呼出しは常にfalseを返します。

- setPoolable()呼出しはプール可能状態を変更しません。

- PreparedStatementおよびCallableStatementインタフェースの場合:

- isPoolable()呼出しは現在のプール可能状態を返します。デフォルト値はtrueです。

- setPoolable()呼出しはプール可能状態を変更します。

- PreparedStatementまたはCallableStatementインタフェースの場合、close()メソッドを呼び出すと、次のことが起こります:

- 現在のプール可能状態がfalseの場合、PreparedStatementまたはCallableStatementが閉じられます。

- 現在のプール可能状態がtrueの場合、PreparedStatementまたはCallableStatementが文キャッシュに戻ります。

- 更新されたサード・パーティJDBCドライバ:

- Oracle Thin Driverが10gから11gに更新されました。

- PointBaseデータベース・サーバーとドライバが5.1から5.7に更新されました。

更新されたWebLogicブランドのDataDirectドライバ

WebLogic Serverに付属しているWebLogicブランドのDataDirectドライバは、DataDirectから提供されています。10.3においてDataDirectバージョン3.7に変更されました。これらのドライバの変更やJDBC 4.0のサポートの詳細は、『Oracle WebLogic Server JDBCのプログラミング』のWebLogicブランドのDataDirectドライバの使用に関する項を参照してください。

JMS

JMSの次の変更に注意してください。

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

- JMSリソースのモジュール式構成およびデプロイメント

- JMSメッセージID形式

- メッセージ・ページングの改善

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

WebLogic Server 12.1.1から、デフォルトのメッセージング・モードがマルチキャストからユニキャストに変更されました。

JMSリソースのモジュール式構成およびデプロイメント

WebLogic Server 9.0からJMS構成はモジュールとして格納されています。これは、新しいweblogic-jmsmd.xsdスキーマに準拠するXMLドキュメントで定義されます。JMSリソースのモジュール式デプロイメントにより、アプリケーションとJMS構成を別の環境にプロモートできます。たとえば、アプリケーションとそれに必要なJMS構成を、EARファイルを開くことなく、またJMSを手動で再構成することなく、テスト環境から本番環境にプロモートできます。

詳細については、次を参照してください:

- WebLogic JMSの構成と管理ガイドのこのリリースでのJMSの新機能と変更点に関する項(WebLogic Server 9.0版はhttp://download.oracle.com/docs/cd/E13222_01/wls/docs90/jms_admin/intro.html#WhatsNewJMS)

- 『Oracle WebLogic Server JMSの構成と管理』のJMSリソースの構成に関する項

- 『Oracle WebLogic Serverへのアプリケーションのデプロイ』のJDBC、JMS、およびWLDFアプリケーション・モジュールのデプロイに関する項

WebLogicアップグレード・ウィザードは、9.0より前のバージョンのJMSリソースを、ドメインのconfig\jmsディレクトリにコピーされるinterop-jms.xmlという名前のJMS Interopモジュール・ファイルに自動的に変換します。詳細は、『Oracle WebLogic Server JMSの構成と管理』のJMS Interopモジュールに関する項を参照してください。

JMS構成は次のように変更されています。

- 新しいJMSリソースを生成するとき、JMSモジュールですべての属性を定義する必要があります(つまり、9.0より前のバージョンの構成ファイルを使用しません)。

- 「永続ダウングレードを許可」オプションにより、永続ストアが構成されていないJMSサーバーにターゲット指定されている宛先に対して、永続メッセージを送信する場合に、JMSクライアントが例外を取得するかどうかを指定することができます。このオプションは、旧リリースとの下位互換性のために用意されています。
デフォルトでは、このオプションはfalseに設定されており、この場合、ストアが構成されていないJMSサーバーに永続メッセージを送信するときに、クライアントは例外を受け取ります。このオプションをtrueに設定した場合、永続メッセージは非永続メッセージに格下げされますが、送信処理は続行できます。このパラメータは、「ストアを有効化」パラメータが無効化されている場合(つまり、falseに設定されている場合)にのみ有効です。

詳細は、Oracle WebLogic Server MBeanリファレンスのJMSServerBeanのAllowsPersistentDowngradeに関する項を参照してください。

- デフォルトで、JMSサーバーの「一時的なテンプレート」属性が作成されます。旧リリースでは、デフォルトのテンプレートは提供されていませんでした。JMSサーバーの「一時的なテンプレート」属性を使用して一時的なテンプレートを構成することもできます。
「一時的な宛先をホスト」属性を設定して、一時的な宛先をホストするのにJMSサーバーを使用できるかどうかを指定することができます。旧リリースでは、一時的な宛先をホストするのにJMSサーバーを使用するには、「一時的なテンプレート」属性を設定する必要がありました。

- 分散宛先のJMSテンプレートは、WebLogic Server 9.0の時点でサポートされていないため無視されます。WebLogic Server 9.0以降、この機能は共通分散宛先に置き換えられます。詳細は、Oracle WebLogic ServerのJMSの管理と構成ガイドの共通分散宛先の作成に関する項を参照してください。

- JMS接続ファクトリのAllowCloseInOnMessage属性は、デフォルトで有効化されています。詳細は、Oracle WebLogic Server MBeanリファレンスの「ClientParamsBean」を参照してください。

- DeliveryFailureParamsBeanのgetExpirationLoggingPolicy属性は非推奨となりました。『Oracle WebLogic Server JMSの構成と管理』のメッセージ・ライフ・サイクルのロギングに関する項の説明に従って、メッセージのライフ・サイクル情報をロギングする機能を使用するようアプリケーションを更新することを推奨します。getExpirationLoggingPolicy属性により、アプリケーションに埋め込まれている先頭と末尾のスペースはすべて削除されることに注意する必要があります。

JMSメッセージID形式

JMSメッセージIDの形式は、WebLogic Server 9.0で変更されています。既存のコンシューマ、プロデューサ、およびサーバーで使用されている9.0より前のバージョンの形式は、引続きサポートされます。たとえば、既存のJMSコンシューマは、新しいJMSプロデューサまたはJMSサーバーから送信されたメッセージであっても、引続き9.0より前のバージョンの形式で確認することができます。

メッセージ・ページングの改善

WebLogic Server 9.0以降では、メッセージ負荷のピーク時にJVMヒープ・スペースを解放するメッセージ・ページング機能が、JMSサーバーでは常に有効に設定されています。また、ページ・アウトされたメッセージは、使用しているファイル・システムのディレクトリに格納できるため、管理者は専用のメッセージ・ページング・ストアを作成する必要はありません。ただし、最適なパフォーマンスを維持するには、メッセージのページング先のディレクトリをJMSサーバーの永久ストアが使用する以外のディレクトリに指定する必要があります。

Oracle WebLogic Serverのパフォーマンスおよびチューニング・ガイドのメッセージのページングによるメモリーの解放に関する項を参照してください。

メッセージング

この項では、WebLogic Server 12.1.1にアップグレードする際に認識が必要なメッセージの変更について説明します。

weblogic.jms.extension APIの変更

WebLogic Server 10.3.3から、weblogic.jms.extensions.WLMessageインタフェースの次の内部メソッドが、Oracle WebLogic Server APIリファレンス・ガイドから削除されています。

public void setSAFSequenceName(String safSequenceName);
public String getSAFSequenceName();
public void setSAFSeqNumber(long seqNumber);
public long getSAFSeqNumber();

アプリケーションでこれらの内部メソッドを使用しないでください。内部メソッドは、将来のリリースで予告なしに変更または削除される場合があります。

永続ストアの更新

WebLogic Server 10.3.3から、WebLogicファイル・ストアの動作とチューニング方法は、デフォルト・ファイル・ストアとカスタム・ファイル・ストアについて変更されています。

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環境変数を使用し続けることができます。

JTA

以降の項では、JTA機能の変更点について説明します。

- リソース登録名

- JTAトランザクション・ログの移行

リソース登録名

WebLogic Server 10.3.1以降では、XAデータ・ソース構成のリソース登録名の動作が変更されました。以前のリリースでは、JTAの登録名はデータ・ソースの名前のみでした。今後は、データ・ソース名とドメインの組合せになります。

詳細は、『Oracle WebLogic Server JTAのプログラミング』のXAResourceのトランザクションへの参加の登録に関する項を参照してください。

JTAトランザクション・ログの移行

ドメイン・レベルのJTA構成オプションはすべて従来の構成ファイルから保持されています。サーバー・レベルでのみ変更があります。WebLogic Server 9.0から、トランザクション・マネージャでは、デフォルトのWebLogic永続ストアを使用してトランザクション・ログ・レコードを保存します。アップグレード中、アップグレード・ウィザードは、トランザクション・ログ・レコードをデフォルト・ストアにコピーします。既存のサーバー構成に基づいて設定されるトランザクション・ログ・ファイルの接頭辞は、アップグレード中にトランザクション・ログ・ファイル({.tlog)を検索する目的にのみ使用され、アップグレード後は保持されません。

ドメイン全体が1つのコンピュータにある場合、アップグレード・ウィザードは、初期ドメイン・アップグレードにおいて、すべての管理対象サーバーのアップグレードを処理します(トランザクション・ログ・レコードをデフォルト・ストアにコピーします)。管理対象サーバーが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバーを個別にアップグレードする必要があります。

次の点に注意してください。

- 明示的なアップグレードが実行される場合(「ドメインのアップグレード」を参照)、トランザクション・リカバリはアップグレード・プロセス中には実行されませんが、サーバーを起動すると実行されます。

- 暗黙的なアップグレード(付録E「管理サーバー起動時におけるドメインのアップグレード(暗黙モード)」を参照)が実行される場合、トランザクション・リカバリはサーバー起動プロセスにおいて実行されます。

トランザクション・リカバリ・サービスの移行の準備においてトランザクション・ログ・ファイルをネットワーク・ストレージに配置した場合、アップグレード後、ログ・ファイルの場所は保持されません。このリリースでは、WebLogic Serverトランザクション・マネージャは、デフォルトのWebLogic永続ストアを使用してトランザクション・ログ・ファイルを保存します。デフォルトのWebLogic永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DATファイルを現在のデフォルト・ストアのデフォルトの場所からデフォルト・ストアの新しい場所に手動でコピーする必要があることに注意してください。

トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインを構成する必要があります。詳細は、『Oracle WebLogic Server JTAのプログラミング』のドメイン間トランザクションに対するドメインの構成に関する項を参照してください。

管理コンソール

以降の項では、管理コンソールに対する変更点について説明します。

- コンソール構成機能

- 管理コンソールの拡張アーキテクチャ

コンソール構成機能

WebLogic Server 10.3で管理コンソールの動作を構成するためのオプションが追加され、次のことを実行できるようになりました。

- 編集セッション中に他のアカウントによって変更されずに、構成を変更できるように、ドメイン構成をロックする

- 管理コンソール、UDDI、およびUDDIエクスプローラなどの内部アプリケーションを、サーバーの起動時ではなく、必要に応じて(最初のアクセス時に)デプロイするかどうかを指定する

- バナー・ツールバー領域に新たに追加された検索機能を利用して、この検索で指定した文字列が名前に含まれるWebLogic Server構成MBeanを検索する

- 障害が発生したサーバーやサービスを別のサーバーへ自動的に移行する追加機能を利用する

- Service Component Architecture (SCA)デプロイメントをデプロイおよび制御する

- Springアプリケーションを検査する

詳細については、WebLogic Server 10.3リリース・ノートの「WebLogic Serverの新機能」を参照してください。

管理コンソールの拡張アーキテクチャ

WebLogic Serverバージョン9.0の管理コンソールは、WebLogic Portalのフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。アーキテクチャが新しくなったため、管理コンソールを拡張する手順も新しくなりました。9.0よりも前のWebLogic Serverのリリース用に構築されたWebLogic Serverコンソールの拡張は、新しいインフラストラクチャでは機能しません。

WebLogic Server 10.3.2には次の機能が追加されました。

- サンプルのルック・アンド・フィールが提供されています。サンプルを変更して、WebLogic Server管理コンソールのカスタムのルック・アンド・フィールを作成できます。

- オンライン・ヘルプは作成し、console拡張に関連付けることができます。

WebLogic Server管理コンソールの拡張の詳細は、Oracle WebLogic Serverの管理コンソール拡張ガイドを参照してください。

バージョン9.2のコンソール拡張に関する重要な情報

WebLogic Serverバージョン9.2では、コンソール拡張が次のように変更されています。

- このリリース以前の管理コンソール拡張機能では、タグ・ライブラリ・ファイルのサード・パーティJSPタグ・ライブラリへのパス名を指定することにより、それらのライブラリのインポートが可能でした。たとえば、次のようになります。

<%@ taglib uri="/WEB-INF/beehive-netui-tags-template.tld" prefix="beehive-template" %>

WebLogic Serverインストールからサード・パーティJSPタグ・ライブラリを使用する管理コンソール拡張機能では、10.0より、タグ・ライブラリを指定する定義済みの絶対URIを使用する必要があります。例:

<%@ taglib uri="http://beehive.apache.org/netui/tags-template-1.0" prefix="beehive-template" %>

管理コンソールのweb.xmlファイルが、WebLogic Serverインストール内部のタグ・ライブラリにURIをマップします。このマッピング機能によって、ユーザーがJSPを変更しなくても、タグ・ライブラリのインストール・ディレクトリが認識されます。

古いパス名構文を使用してApache Struts、Apache Beehive、またはJSTLタグ・ライブラリをインポートするすべての管理コンソール拡張機能では、パス名をすべて新しいURIに更新する必要があります。

WebLogic Serverのコンソール拡張機能タグ・ライブラリ(console-html.tld)のURIは変更されていません(/WEB-INF/console-html.tld)。

詳細は、Oracle WebLogic Serverの管理コンソール拡張ガイドのJSPテンプレートとタグ・ライブラリに関する項を参照してください。

- 規則により、ポータル・インクルード・ファイル(.pinc)はポータル・ブック・ファイル(.book)という名前に変更されました。

完全修飾する必要のあるWebLogic PortalスケルトンURI参照

WebLogic Portalでは、すべての明示的なスケルトンURI参照を、Webアプリケーションを基準として完全修飾する必要があります。ただし、ドキュメントや一部のコンソール拡張例では、これらのスケルトンを基準とした相対参照が使用されていることがあります。次の不適切な例について検討します。

<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="singlelevelmenu_children2.jsp"/>

この例を正しく指定するには、次のようにします。

<netuix:singleLevelMenu markupType="Menu" markupName="singleLevelMenu" skeletonUri="/framework/skeletons/default/singlelevelmenu_children2.jsp"/>

このリリースでは、相対スケルトンURI参照を引続き使用できます。ただし、今後のリリースではこれらの相対参照は正しく機能しない可能性があるため、自分で記述したすべてのコンソール拡張は、完全修飾スケルトンURIを使用するように更新する必要があります。

使用されなくなったSNMP MIBリフレッシュ間隔とサーバー・ステータス・チェック間隔

WebLogic Server 10.0では、SNMPAgentMBean MBeanのMibDataRefreshInterval属性とServerStatusCheckIntervalFactor属性は非推奨となったため無視されます。

JMX 1.2実装

WebLogic Server 9.0では、JDK 5.0に含まれているJava Management Extensions (JMX)1.2実装が使用されています。9.0より前のリリースでは、JMX 1.0仕様をベースにした独自のJMX実装が使用されていました。

JMX 1.2参照実装の採用により、シリアライゼーションの互換性がなくなりました。参照実装においてシリアライゼーションの互換性はなくなりましたが、WebLogic Server 8.1用に作成されたJMXクライアントは、次のように9.2以降のリリースでも使用できます。

- JMXクライアントがWebLogic Server MBeanのみにアクセスし、weblogic.management.MBeanHomeのみを使用する場合は、アップグレードしなくてもWebLogic Server 9.2以降のインスタンスで実行できます。

- WebLogic Server 8.1クラスを使用するJMXクライアントは、次のすべての条件に該当すれば、WebLogic Server 9.2以降のJMXエージェントと対話できます。

- クライアントがWebLogic Server MBeanのみにアクセスします。

- クライアントがweblogic.management.MBeanHomeのみを使用します(JDK MBeanServerインタフェースを使用しません)。

- WebLogic Serverクラスが8.1 SP4で作成され、それに適切なパッチが適用されています。

- JMXクライアントで、WebLogic Server MBeanとの対話またはカスタムMBeanの作成と使用に標準のJMX MBeanServerインタフェースが使用されている場合は、WebLogic Server 9.2以降のインスタンス用のJDK起動オプション-Djmx.serial.form=1.0を含める必要があります。
この起動オプションを含めると、JVMがオブジェクトをシリアライズするときにJMX 1.0のクラス記述が使用されるようになります。このオプションは、JMX 1.0クライアントが標準のJDKクラスを使用してJMX 1.2エージェントと通信する場合に必要です。

- JMXクライアントがセキュリティ・プロバイダMBeanと対話する場合は、「セキュリティMBean」を参照してください。

JMXクライアントをWebLogic Server 12.1.1に準拠するよう更新することをお薦めします。9.0より前のリリースでは、WebLogic ServerはJMXレイヤーに対して、型付きAPIレイヤーをサポートしていました。使用するJMXアプリケーション・クラスでは、WebLogic Server MBeanの型保障インタフェースをインポートしたり、weblogic.management.MBeanHomeインタフェースを介してMBeanの参照を取得したり、MBeanメソッドを直接呼び出すことができました。

JMXの非推奨になった機能

MBeanHomeインタフェースは、9.0から非推奨となりました。このAPIのようなプログラミング・モデルを使用するかわりに、すべてのJMXアプリケーションで、標準のJMXプログラミング・モデルを使用してください。標準のJMX設計パターンでは、クライアントはjavax.management.MBeanServerConnectionインタフェースを使用して、実行時にMBean、属性、および属性タイプを検索します。このJMXモデルでは、クライアントはMBeanServerConnectionインタフェースを介して間接的にMBeanと対話します。

型保障インタフェース(weblogic.managementから使用可能)をインポートするクラスがある場合は、そのクラスを標準のJMXプログラミング・モデルを使用するよう更新することをお薦めします。詳細は、『Oracle WebLogic Server JMXによるカスタム管理ユーティリティの開発』のWebLogic Server MBeanに関する項を参照してください。

WebLogicの管理および構成スクリプト

MBeanの階層構造に加えられた変更により、9.2より前の構成および管理スクリプト(WLST、wlconfig、weblogic.Admin、Antなど)が12.1.1で動作する保証はなくなりました。WebLogic Server 9.2以降の新しい機能を利用するようスクリプトを更新することをお薦めします。MBean階層における新しい機能と変更の詳細は、表A-4にリストされたドキュメントを参照してください。

表A-4 リリースごとのWebLogic Serverの新機能

リリース

次の新機能の説明を参照

9.2

WebLogic Server 9.2の新機能:

http://download.oracle.com/docs/cd/E13222_01/wls/docs92/notes/new.html

10.0

WebLogic Server 10.0の新機能:

http://download.oracle.com/docs/cd/E13222_01/wls/docs100/notes/new.html

10.3

WebLogic Serverの新機能 バージョン10.3:

http://download.oracle.com/docs/cd/E12840_01/wls/docs103/notes/new.html

10.3.1

Oracle WebLogic Serverの新機能 11gリリース1 (10.3.1):

http://download.oracle.com/docs/cd/E12839_01/web.1111/e13852/toc.htm

10.3.2

Oracle WebLogic Serverの新機能 11gリリース1 (10.3.2):

http://download.oracle.com/docs/cd/E15523_01/web.1111/e13852/toc.htm

10.3.3

Oracle WebLogic Serverの新機能 11gリリース1 (10.3.3):

http://download.oracle.com/docs/cd/E14571_01/web.1111/e13852/toc.htm

10.3.4

Oracle WebLogic Serverの新機能 11gリリース1 (10.3.4):

http://download.oracle.com/docs/cd/E17904_01/web.1111/e13852/toc.htm

12.1.1

Oracle WebLogic Serverの新機能 12cリリース1 (12.1.1)

http://download.oracle.com/docs/cd/E24329_01/web.1211/e24494/toc.htm

アプリケーション・インフラストラクチャのアップグレードと非推奨となったスクリプト・ツールの詳細は、「ステップ1: アプリケーション・インフラストラクチャのアップグレード」を参照してください。

動的な構成管理

構成属性は、動的なものと動的でないものに分類されます。

- 動的な構成属性への変更は、アクティブ化するとただちに有効になり、その変更の影響を受けるサーバーまたはシステム・リソースを再起動する必要はありません。この種の変更がサーバーおよび実行時階層で有効になるのは、変更がアクティブ化されたときです。

- 動的でない構成属性への変更は、ただちには有効になりません。動的でない構成属性への変更を適用するには、サーバーまたはシステム・リソースを再起動する必要があります。

WebLogic Server 9.0から導入された変更管理プロセスにより、構成の変更をドメイン全体にわたってセキュアで確実に適用できます。バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、構成されているサーバーまたはシステム・リソースが動的でない属性の変更の影響を受ける場合、サーバーまたはシステム・リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更(動的な変更も含む)は有効になりません。この場合、システムの整合性状態を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお薦めします。

構成スクリプトをテストして、動的でない変更が適用されているかどうか確認し、適用されている場合はサーバーを再起動する必要があります。変更が動的でなく、サーバーの再起動が必要かどうかを判断するには:

- 変更をアクティブ化する前には、次を実行できます。

- 管理コンソールのチェンジ・センターに表示されている変更一覧を確認します。『Oracle WebLogic Serverの理解』の動的な変更および動的でない変更に関する項を参照してください。

- isRestartRequiredまたはshowChangesのどちらかのWLSTコマンドを使用します。詳細は、WebLogic Scripting Toolのコマンド・リファレンスを参照してください。

- 変更をアクティブ化した後には、次を実行できます。

- サーバー・ログで変更が動的でない変更として分類されているかどうかを確認します。

- 必要に応じて、変更されたオブジェクトに関連付けられているRestartRequired属性またはPendingRestartSystemResources属性の値を確認します。

どのセキュリティ属性が動的であるか動的でないかを確認するには、『Oracle WebLogic Serverの保護』のセキュリティ構成MBeanに関する項を参照してください。

詳細は、『Oracle WebLogic Serverドメイン構成の理解』の構成変更の管理に関する項を参照してください。

JDBCリソースのモジュール式構成およびデプロイメント

JDBCの構成を簡素化し、構成エラーが発生する可能性を低くするため、WebLogic Server 9.0からは、使用するJDBCリソースのタイプが少なくなっています。JDBC接続プールを構成してから、その接続プールを指し、JNDIツリーにバインドされるデータ・ソースまたはトランザクション・データ・ソースを構成するかわりに、接続プールを包含するデータ・ソースを構成できるようになりました。WebLogic Server 9.0で導入された簡素化されたJDBCリソースの構成の詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』の簡素化されたJDBCリソース構成に関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs90/jdbc_admin/jdbc_intro.html#simple_res_config)を参照してください。

次の項で説明するように、WebLogicアップグレード・ウィザードは、JDBCデータ・ソース、接続プール、マルチ・プール、およびデータ・ソース・ファクトリをWebLogic Server 12.1.1仕様に自動的に変換します。

- JDBCデータ・ソースとJDBC接続プール

- マルチプール

- データ・ソース・ファクトリ

注意:

アップグレードしたそれぞれのJDBCモジュールに内部プロパティ・セクションがあります。WebLogic Serverでは、下位互換性に対応するため、データ・ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBCデータ・ソース・ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。

WebLogic Server 9.0で非推奨になったJDBC機能、メソッド、インタフェース、およびMBeanの詳細は、『リリース・ノート』の非推奨になったJDBCの機能、メソッド、インタフェース、およびMBeanに関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs90/notes/new.html#deprecated_jdbc_features)を参照してください。

JDBCデータ・ソースとJDBC接続プール

アップグレード・ウィザードは、従来のJDBCデータ・ソース/接続プールの組合せを2つのデータ・ソース・システム・リソース・モジュールに変換します(1つはデータ・ソース用、もう1つは接続プール用)。

- 既存のデータ・ソースまたはトランザクション・データ・ソースに置き換わるデータ・ソースは、データ・ソース・パラメータを定義し、その接続プールと関連属性を定義するもう1つのデータ・ソースを参照する

- 既存の接続プールに置き換わるデータ・ソースは、JDBCドライバ・パラメータ、接続プール・パラメータ、およびXAパラメータを定義する

注意:

ドメインのアップグレードの1つのプロセスとして変換されるデータ・ソースのみが、その接続プールを定義するもう1つのデータ・ソースを参照することができます。それ以外のデータ・ソースは、それぞれ独自のデータベース接続プールを保有しています。

アップグレード時にアップグレード・ウィザードにより、データ・ソースのGlobalTransactionsProtocolパラメータが、変換されるデータ・ソースのタイプ(トランザクションまたは非トランザクション)と関連する接続プールで使用されるドライバのタイプに基づいて設定されます。これを表A-5に示します。

表A-5 グローバル・トランザクションのプロトコル・パラメータ設定

従来のデータ・ソース・タイプ

ドライバ・タイプ

2フェーズ・コミットのエミュレーション

GlobalTransactionProtocol

Txデータ・ソース

XA

N/A

TwoPhaseCommit

Txデータ・ソース

非XA

False

OnePhaseCommit(デフォルトでは明示的にセットされません)

Txデータ・ソース

非XA

True

EmulateTwoPhaseCommit脚注 1

データ・ソース

非XA

N/A

なし

脚注 1 使用する環境によっては、トランザクション処理にEmulateTwoPhaseCommitトランザクション・プロトコルではなくLoggingLastResource(LLR)トランザクション・プロトコルを使用するほうが、パフォーマンス上のメリットがあります。詳細は、『Oracle WebLogic Server JDBCデータ・ソースの構成と管理』のロギング・ラスト・リソース・トランザクション・オプションに関する項を参照してください。

マルチプール

アップグレード・ウィザードは、マルチプールを、データ・ソース間のロード・バランシングまたはフェイルオーバーを実現するデータ・ソース・オブジェクトのもう1つのインスタンスであるマルチ・データ・ソースに変換します。

データ・ソース・ファクトリ

データ・ソース・ファクトリは、WebLogic Server 9.0より非推奨となっており、下位互換性の維持だけを目的として含まれています。データ・ソース・ファクトリの変換は不要です。

スレッド管理

実行キューは、WebLogic Server 9.0の時点でデフォルトの方法ではないため、スレッド管理にはワーク・マネージャの概念を使用することをお薦めします。アプリケーション用のルールと制約を定義するには、ワーク・マネージャを定義して、それをWebLogicドメインに対してグローバルに適用するか、特定のアプリケーション・コンポーネントに対して限定的に適用します。詳細は、『Oracle WebLogic Serverサーバー環境の構成』のワーク・マネージャを使用したスケジューリング済作業の最適化に関する項を参照してください。

WebLogic Server 8.1では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上させるために8.1で実行キューを使用していた場合は、アプリケーション・ドメインのアップグレード後にも実行キューを引続き使用できます。アップグレードしたアプリケーションでユーザー定義実行キューを引続き使用できるようにするために、use81-style-execute-queuesというフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と、実行キューの構成および監視に関する詳細は、Oracle WebLogic Serverのパフォーマンスおよびチューニング・ガイドのWebLogic 8.1スレッド・プール・モデルを有効にする方法に関する項を参照してください。

XML実装

WebLogic Server 9.0からは、XMLのサポートが次のように変更されています。

- デフォルトのXMLパーサーは、Sun Java 2 JDK付属のXMLパーサーになりました。以前のデフォルトXMLパーサー、Apache Xercesパーサー(weblogic.apache.xerces.*)は9.0より非推奨となりました。
デフォルトで使用されるXMLパーサーを管理コンソールで修正することができます。XMLパーサーの構成については、『Oracle WebLogic Server XMLのプログラミング』のWebLogic Serverバージョン8.1と9.0のデフォルト・パーサーの違いに関する項を参照してください。

- WebLogic Server 9.0からは、Java Community Processの標準仕様であるStreaming API for XML (StAX)がサポートされています。これにより、XMLドキュメントを簡単に、直感的に解析および生成できます。また、StAXでは、9.0から非推奨となっているWebLogic XML Streaming APIよりも的確にXML解析を行うことができます。StAXの使用については、『Oracle WebLogic Server XMLのプログラミング』のStreaming API for XML (StAX)の使い方に関する項を参照してください。

- 所定の事前準備設定を行うことなしにsetAttributeメソッドとgetAttributeメソッドを使用してサーブレット内からXMLドキュメントを解析することができなくなりました。具体的には、9.0以降、weblogic.servlet.XMLParsingHelperと呼ばれるWebLogic Serverのサーブレット・フィルタ(デフォルトではすべてのWebLogic Serverインスタンスにデプロイされる)をWebアプリケーションの一部として構成する必要があります。詳細は、『Oracle WebLogic Server XMLのプログラミング』のサーブレットでのXMLドキュメントの解析に関する項を参照してください。

XMLBeans実装とXQuery実装

WebLogic Server 9.0から、XMLBean実装は内部BEAライブラリ(com.bea.xml)からApacheオープン・ソース・プロジェクト(org.apache.xmlbeans)に移動されています。

WebLogic Server 8.1のアプリケーションでXMLBeansを使用していた場合は、次の手順を実行する必要があります。

1. XMLBeansにより使用されているパッケージ名をcom.bea.xmlからorg.apache.xmlbeansに更新します。

2. XMLBeanスキーマを再コンパイルして、スキーマ・メタデータ・ファイル(.xsb)と生成されているコードを更新します。

9.0以降、XMLQuery (XQuery)実装は次の仕様に準拠しています。

- 「XQuery 1.0 and XPath 2.0 Data Model - W3C Working Draft 23 July 2004」(http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723)

- 「XQuery 1.0: An XML Query Language - W3C Working Draft 23 July 2004」(http://www.w3.org/TR/2004/WD-xquery-20040723)

WebLogic Server 8.1では、XQuery実装は「XQuery 1.0 and XPath 2.0 Functions and Operators - W3C Working Draft 16 August 2002」(http://www.w3.org/TR/2002/WD-xquery-operators-20020816)に準拠していました。この2002 XQuery実装は、9.0以降では非推奨となっています。

ほとんどの場合、9.0より前のバージョンのコードに含まれる簡単なXQueryおよびXPathは、10.0でも同じように動作します。XQueryおよびXPathの処理が意図したとおりの結果になるように、次のいずれかの方法で、XMLObject.selectPath()およびXMLObject.execQuery()のメソッド呼出しを必要に応じて確認または変更してください。

- 8.1と同様の動作を保証するには、既存のメソッド呼出しを変更し、新しい2004 XQueryエンジンではなく2002 XQueryエンジンを使用することを指定する新しいパラメータを含めるようにします。例:

import org.apache.xmlbeans.impl.store.Path;
XmlObject xo = ?
xo.selectPath(".//c", (new XmlOptions()).put(Path._forceXqr12002ForXpathXQuery));

注意:

2002 XQueryエンジンは、WebLogic Server 9.0以降では非推奨ですが、下位互換性のために残されています。このパラメータを指定する場合にのみ使用できます。指定しない場合は、2004 XQueryエンジンがデフォルトで使用されます。

- 2004 XQueryエンジンへの適合を保証するには、9.0より前のスクリプトを確認し、メソッド呼出しに渡されているXQuery文字列の構文またはセマンティクスに関して変更が必要になると考えられる点をすべて特定して、メソッドに適切な変更を加えます。

9.0から、XMLCursor.moveXML()の動作が変更されています。8.1では、移動されたフラグメント内にあったカーソルは、元のドキュメントに残ります。9.0以降では、カーソルはフラグメントと共に移動します。

デプロイメント記述子の検証および変換

この項では、リリース9.0より変更されたWebLogic Server環境におけるデプロイメント記述子の使用方法について説明します。

- デプロイメント記述子の検証は、9.0リリース以降のEJBGenツールとejbcツールでは、より厳密に行われるようになりました。たとえば、@ejbgen:relationでcmr-fieldが定義されている場合に、@ejbgen:cmr-fieldというタグの付いたメソッドがBeanクラスになければ、エラーが返されます。

注意:

ejbcはWebLogic Server 9.0から非推奨となりました。かわりにappcを使用してください。詳細は、『Oracle WebLogic Server WebLogic Enterprise JavaBeansのプログラミング』のappcリファレンスに関する項を参照してください。

- 9.0より前のバージョンのWebLogic Serverでは、次の構成ファイルからの抜粋が示すように、複数のモジュールを定義するアプリケーションは、META-INF\application.xmlデプロイメント記述子がアプリケーションの一部として定義されているかどうかに関係なく、正常にデプロイされます。

<Application Deployed="true" Name="SessionBeanLifeCycleBean"
Path="C:\bea\weblogic70\tools\deployment\ejb" TwoPhase="false">
<EJBComponent Name="CMFinderTestBean" Targets="myserver" URI="CMFinderTestBean.jar"/>
<EJBComponent Name="SessionBeanLifeCycleBean" Targets="myserver"
URI="SessionBeanLifeCycleBean.jar"/>
</Application>

9.0からは、デプロイされたアプリケーションが複数のモジュールを定義する場合は、META-INF\application.xmlデプロイメント記述子が必要です。このタイプのデプロイメント記述子が提供されなければ、アップグレードは正常に実行されず、次のようなエラー・メッセージが表示されます。

[J2EE Deployment SPI:260089]Unable to determine type of application at path 'C:\bea\weblogic70\tools\deployment\ejb' and upgrade will not succeed.

ドメインをアップグレードするとき、デプロイされたアプリケーションが適切なJava EEアプリケーション形式に準拠していることを確認してください。たとえば、必要に応じて、アプリケーションがMETA-INF\application.xmlデプロイメント記述子またはMETA-INF\weblogic-application.xmlデプロイメント記述子を定義していることを確認してください。

デプロイメント記述子の詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子の要素に関する項を参照してください。

- アプリケーションが最新のJava EE仕様およびWebLogic Serverリリースの機能を活用できるよう、アプリケーションをWebLogic Serverの新リリースにアップグレードするときに、デプロイメント記述子をアップグレードすることを推奨します。詳細は、『Oracle WebLogic Serverアプリケーションの開発』の以前のリリースのJ2EEおよびWebLogic Serverのデプロイメント記述子のアップグレードに関する項を参照してください。

非推奨となった起動クラスと停止クラス

アプリケーション・スコープの起動クラスと停止クラスは、WebLogic Server 9.0から非推奨となり、かわりにアプリケーションはアプリケーション・ライフサイクル・イベントに応答するようになりました。ドメイン・レベルのアプリケーション・スコープの起動クラスと停止クラスのかわりにライフサイクル・イベントを使用するようアプリケーション環境を更新することをお薦めします。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のアプリケーション・ライフサイクル・イベントのプログラミングに関する項を参照してください。

リソース・アダプタ

表A-6に、非推奨またはサポート対象外となったリソース・アダプタの構成設定を示します。新機能および変更点については、『Oracle WebLogic Serverの新機能』を参照してください。

表A-6 非推奨またはサポート対象外となったリソース・アダプタの構成設定

要素

WebLogic Server 9.0の時点...

Link-Refメカニズム

この要素は非推奨となっており、新しいJava EEライブラリ機能に置き換えられています。Java EEライブラリの詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有J2EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。

Link-Refメカニズムは、J2CA 1.0仕様に準拠して開発されたリソース・アダプタの場合は、このリリースでもサポートされています。1.0リソース・アダプタでのLink-Refメカニズムの使用の詳細は、『Oracle WebLogic Serverリソース・アダプタのプログラミング』の「weblogic-ra.xmlファイルの構成」、(非推奨)Link-Refメカニズムの構成に関する項を参照してください。

<shrink-period-minutes>

この要素は非推奨となっており、<shrink-frequency-seconds>に置き換えられています。これを使用して、縮小間隔を分単位ではなく秒単位で指定できます。

<shrink-frequency-seconds>要素は<shrink-period-minutes>要素をオーバーライドします(両方が設定された場合)。

<connection-maxidle-time>

この要素は非推奨となっており、<inactive-connection-timeout-seconds>に置き換えられています。これを使用して、接続タイムアウトを秒単位で指定できます。

<inactive-connection-timeout-seconds>要素は<connection-maxidle-time>要素をオーバーライドします(両方が設定された場合)。

<security-principal-map>

この要素はサポートされなくなりました。セキュリティ・プリンシパル・マップは管理コンソールを使用して構成されます。

weblogic-ra.xmlファイルから<security-principal-map>定義を削除する必要があります。削除しなければ、リソース・アダプタのデプロイメントが正常に実行されません。

<connection-cleanup-frequency>

この要素はサポートされなくなり、デプロイメントにおいて無視されます。

<connection-duration-time>

この要素はサポートされなくなり、デプロイメントにおいて無視されます。

WLEC

WLECは、WebLogic Server 8.1で非推奨となりました。WLECユーザーは、『Oracle WebLogic Server WLECのためのWebLogic Tuxedo Connector移行ガイド』の説明に従って、アプリケーションをWebLogic Tuxedo Connectorに移行する必要があります。

B WebLogicドメイン・ディレクトリ構造の強化

この付録では、WebLogic Serverディレクトリ構造の強化について説明します。この付録内の情報は、WebLogic Server 8.1からアップグレードする場合のみ該当します。

WebLogic Server 9.0から、WebLogicドメイン・ディレクトリ構造は次のように強化されました。

- 構成管理を効率化し、XMLファイルの検証を促進するため、WebLogic Serverでは、新たなdomain_name/configディレクトリが追加され、config.xmlを含む複数のファイル内のドメイン構成データをサポートできるようになりました。(ここで、domain_nameはドメイン・ディレクトリを示します。)従来のリリースでは、config.xmlファイルは、すべての構成情報が格納されるリポジトリでした。今回のリリースでは、configディレクトリの新しいサブディレクトリに診断、JDBC、JMS、ノード・マネージャの各サブシステムの構成モジュールが格納されるようになりました。各ファイルはXMLスキーマ定義に準拠しています。

- 起動スクリプトと停止スクリプトがdomain_name/binディレクトリに格納されるようになりました。従来のリリースでは、これらのスクリプトはドメインのルート・ディレクトリに格納されていました。

WebLogic Serverでは、ドメイン・ディレクトリ構造が強化されただけではなく、サーバー構成の変更を管理するためのユーティリティがサポートされるようになりました。このツールにより、構成の変更をドメイン全体にわたってセキュアで確実に適用することができます。詳細は、『Oracle WebLogic Serverドメイン構成の理解』の構成変更の管理に関する項を参照してください。

WebLogicのドメイン・ディレクトリ構造の詳細は、『Oracle WebLogic Serverドメイン構成の理解』のドメイン構成ファイルに関する項を参照してください。

図B-1は、WebLogic Server 10.0とWebLogic Server 8.1のドメイン・ディレクトリ構造の違いを示しています。

図B-1 WebLogic Server 12.1.1とWebLogic Server 8.1のディレクトリ構造

「図B-1 WebLogic Server 12.1.1とWebLogic Server 8.1のディレクトリ構造」の説明

次の項では、WebLogic Server 8.1のドメイン・ディレクトリ構造について説明します。

WebLogic Server 8.1のドメイン・ディレクトリ構造

WebLogic Server 8.1の環境における構成ウィザードで作成されたドメイン・ディレクトリ構造の内容は以下のとおりです。

- mydomain、petstoreなどのドメインと同じ名前のドメイン・ルート・ディレクトリ。このディレクトリには次のソフトウェアが格納されます。

- ドメインのconfig.xmlファイル

- サーバー・インスタンスの起動および環境の確立に使用するスクリプト

- ドメインのアプリケーションを格納するサブディレクトリ(通常はapplications)

ドメイン内のサーバー・インスタンスを初めて起動すると、ドメイン・ディレクトリに次のサブディレクトリが作成されます。

- セキュリティ情報が格納されたファイル

- ドメインレベルのログを格納するlogsディレクトリ

- ドメイン内で動作するサーバーごとのサーバー・ログおよびHTTPアクセス・ログを格納するディレクトリ

WebLogic Server 8.1のドメイン・ディレクトリ構造の詳細は、WebLogic Serverの構成および管理ガイドのWebLogic Serverドメインの概要に関する項(http://download.oracle.com/docs/cd/E13222_01/wls/docs81/adminguide/overview_domain.html)参照してください。デフォルトの構成テンプレートのディレクトリ構造の概要は、構成ウィザードによるWebLogicドメインの作成と構成のテンプレート・リファレンスに関する項(http://download.oracle.com/docs/cd/E13196_01/platform/docs81/confgwiz/tempref.html)参照してください。

C アップグレード・ウィザード・コマンド・ライン・リファレンス

この付録では、WebLogicアップグレード・ウィザードをコマンド・ラインから起動する方法の詳細を説明します。

WebLogicアップグレード・ウィザードを呼び出すコマンドの構文は次のとおりです。

java weblogic.Upgrade [-help | -h | -? | -usage] [-type type] [-mode mode] [-responses xmlfile] [-out file]

表C-1では、このコマンドで指定可能な各引数について説明します。

表C-1 WebLogicアップグレード・ウィザードのコマンド・ラインの引数

引数

説明

-help | -h | -? | -usage

ヘルプ情報を表示します。

-type type

アップグレードのタイプをdomain、nodemanager、またはsecurityprovidersのいずれかに設定します。デフォルト値はdomainです。

注意: -typeドメイン・オプションは、WebLogicドメインのサイレント・モードでのアップグレードにのみ使用できます。詳細は、「ドメインのサイレント・モードでのアップグレード」を参照してください。

-mode mode

アップグレードのモードをguiまたはsilentのどちらかに設定します。デフォルト値はguiです。

-responses xmlfile

サイレント・モードでのアップグレードで使用されるアップグレード要件を含むXMLファイルの場所を指定します。この引数は、-modeがsilentに設定されている場合にのみ有効です。レスポンス・ファイルの形式の詳細は、付録D「サイレント・アップグレード用XMLスクリプト・リファレンス」を参照してください。

-out file

標準出力とエラーが格納されるファイルを指定します。デフォルトでは、ログ出力はstdoutに送信されます。

例

- 対話モードでドメインをアップグレードするコマンド

java weblogic.Upgrade

- サイレント・モードでドメインをアップグレードするコマンド

java weblogic.Upgrade -mode silent -type domain

このページのスクリプトは、ナビゲーション目的のみのもので、内容を変更しません。

D サイレント・アップグレード用XMLスクリプト・リファレンス

この付録では、WebLogicアップグレード・ウィザードをサイレント・モードで実行する方法について説明します。

WebLogicアップグレード・ウィザードをサイレント・モードで使用する前に、アップグレード要件を定義するXMLスクリプトを作成してコマンド・ラインでウィザードに渡すことができます。

アップグレード・ウィザードは、サイレント・モードで実行した場合、実行するアップグレード・タスクのタイプを表す名前を持つXMLスクリプトをドメインのルート・ディレクトリから検索します。XMLスクリプトを検索できなければ、システムのデフォルト値が使用されます。

この付録では、次のサンプルXMLアップグレード・スクリプトを示します。

- セキュリティ・プロバイダのアップグレード・スクリプト

- ノード・マネージャのアップグレード・スクリプト

- ドメインのアップグレード・スクリプト

ここで説明しているように、これらのスクリプトの特定の値は、アップグレードしている環境の構成に応じて変更し、WebLogicアップグレード・ウィザードで変更後の値を使用することができます。この付録では、それらの値とデフォルト値を示し、その変更方法について説明します。

注意:

サイレント・モードでアップグレードできるのはWebLogicドメインだけです。

サンプルXMLスクリプトの変更について

サイレント・モードのアップグレード用のXMLスクリプトを作成するには、ここで提供されているいずれかのサンプル・スクリプトを変更します。次の点に注意してください。

- XML定義(<?xml version="1.0" encoding="UTF-8"?>)はXMLスクリプトの先頭に指定する必要があります。XML定義の前には、スペースも改行も入れないでください。

- 値を変更するときは、文字についてのXMLガイドラインに従う必要があります。つまり、<、>、[、]などXMLで予約済みの文字は使用できません。

- サンプル・スクリプトは、アップグレード対象のドメインのルート・ディレクトリに、XMLファイルとして保存します。その際、ここで示しているスクリプトと同じ名前を使用する必要があります。

セキュリティ・プロバイダのアップグレード・スクリプト

WebLogicアップグレード・ウィザードは、ドメインのセキュリティ・プロバイダをアップグレードするため、例D-1に示しているweblogic-upgrade-securityproviders-responses.xmlという名前のXMLスクリプトを検索します。変更可能な値は、太字で示しています。

例D-1 セキュリティ・プロバイダをアップグレードするためのサンプル・サイレント・モードXMLスクリプト

<?xml version="1.0" encoding="UTF-8"?>

<plugin-silent-responses>
</plugin-silent-responses>

<!--
<plugin-silent-responses>
<group name="SecurityProviderUpgradeGroup">
<plugin name="SecurityProviderUpgradeStepOne">
<input-adapter name="IA">
<bind-property name="selectedFileNames">
<value>__INPUT_DIRECTORY__</value>
</bind-property>
</input-adapter>
</plugin>
<plugin name="SecurityProviderUpgradeStepTwo">
<input-adapter name="IA">
<bind-property name="selectedFileNames">
<value>__OUTPUT_DIRECTORY__</value>
</bind-property>
</input-adapter>
</plugin>
</group>
</plugin-silent-responses>

表D-1に、このスクリプトに含まれるキーワード、それらのキーワードに対して指定可能な値、および変更しない場合にWebLogicアップグレード・ウィザードで使用されるデフォルト値を示します。

表D-1 セキュリティ・プロバイダをアップグレードするためのサイレント・モードXMLスクリプトの値

キーワード

設定する値

キーワード・デフォルト

INPUT_DIRECTORY

アップグレードする必要のあるセキュリティ・プロバイダJARが格納されているディレクトリのパス。例:

d:/bea/weblogic81/server/lib/mbeantypes

デフォルトでは、セキュリティ・プロバイダはWL_HOME\server\lib\mbeantypesに格納されています。ここで、WL_HOMEは9.0より前のインストールのルート・ディレクトリを示します。

実行されるアップグレード・ウィザードが格納されているディレクトリのパス。たとえば次のようになります。

c:\Oracle\Middleware\wlserver_12.1\server\lib\mbeantypes

OUTPUT_DIRECTORY

新しいセキュリティ・プロバイダJARファイルの保存先のディレクトリのパス。例:

d:/bea/wlserver_10.3/server/lib/mbeantypes

WL_HOME\server\lib\mbeantypes(WL_HOMEはWebLogic Server 10.xのインストール先のルート・ディレクトリ)

ノード・マネージャのアップグレード・スクリプト

WebLogicアップグレード・ウィザードは、既存のドメインのノード・マネージャをアップグレードするため、例D-2に示しているweblogic-upgrade-nodemanager-responses.xmlという名前のXMLスクリプトを検索します。変更可能な値は、太字で示しています。

例D-2 ノード・マネージャをアップグレードするためのサンプル・サイレント・モードXMLスクリプト

<?xml version="1.0" encoding="UTF-8"?>

<plugin-silent-responses>
</plugin-silent-responses>

<!--
<plugin-silent-responses>
<group name="NodeManagerPlugInGroup">
<plugin name="NodeManagerPlugIn">
<input-adapter name="IA">
<bind-property name="selectedFileNames">
<value>__NODE_MANAGER_HOME__</value>
</bind-property>
</input-adapter>
</plugin>
</group>
</plugin-silent-responses>

表D-2に、このスクリプトに含まれるキーワード、それらのキーワードに対して指定可能な値、および変更しない場合にWebLogicアップグレード・ウィザードで使用されるデフォルト値を示します。

表D-2 ノード・マネージャをアップグレードするためのサイレント・モードXMLスクリプトの値

キーワード

設定する値

キーワード・デフォルト

NODE_MANAGER_HOME

ローカルのディレクトリ階層を移動してアップグレードするノード・マネージャのディレクトリのパス。

デフォルトでは、ノード・マネージャのホーム・ディレクトリは、WL_HOME\common\nodemanagerに格納されています。ここで、WL_HOMEは9.0より前のインストールのルート・ディレクトリを示します。

実行されるアップグレード・ウィザードが格納されているディレクトリ。たとえばc:\Oracle\Middleware\wlserver_12.1\common\nodemanagerです。

ドメインのアップグレード・スクリプト

WebLogicアップグレード・ウィザードは、既存のドメインをアップグレードするため、例D-3に示しているweblogic-upgrade-domain-responses.xmlという名前のXMLスクリプトを検索します。変更可能な値は、太字で示しています。

注意:

表D-3で説明するように、キーワードADMIN_SERVER_NAMEにはデフォルト値がないため、ドメイン管理サーバーの名前を指定する必要があります。

例D-3 ドメインをアップグレードするためのサンプル・サイレント・モードXMLスクリプト

<?xml version="1.0" encoding="UTF-8"?>

<plugin-silent-responses>
</plugin-silent-responses>

<!-- SAMPLE BELOW -->
<!--
<plugin-silent-responses>
<group name="DomainSelectionGroup">
<plugin name="SelectWebLogicVersionPlugIn">
<input-adapter name="ChoiceIA">
<bind-property name="selectedChoiceIds">
<value>__WEBLOGIC_VERSION__</value>
</bind-property>
</input-adapter>
</plugin>
<plugin name="DomainDirectorySelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedFile">
<value>__DOMAIN_DIR__</value>
</bind-property>
</input-adapter>
</plugin>
</group>
<group name="PostDirSelectionGroup">
<plugin name="AdminServerSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<value>__ADMIN_SERVER_NAME__</value>
</bind-property>
</input-adapter>
</plugin>
<plugin name="NodeManagerCredentialsPlugIn">
<input-adapter name="UsernameIA">
<bind-property name="value">
<value>__NODE_MANAGER_USERNAME__</value>
</bind-property>
</input-adapter>
<input-adapter name="PasswordIA">
<bind-property name="value">
<value>__NODE_MANAGER_PASSWORD__</value>
</bind-property>
</input-adapter>
<input-adapter name="PasswordConfirmIA">
<bind-property name="value">
<value>__NODE_MANAGER_PASSWORD__</value>
</bind-property>
</input-adapter>
</plugin>
<plugin name="OptionalGroupsSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<value>__OPTIONAL_ACTION_1__</value>
<value> . . . </value>
</bind-property>
</input-adapter>
</plugin>
</group>
<group name="PostDirSelectionPost81Group">
<plugin name="AdminServerSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<value>__ADMIN_SERVER_NAME__</value>
</bind-property>
</input-adapter>
</plugin>
<plugin name="OptionalGroupsSelectionPlugIn">
<input-adapter name="IA">
<bind-property name="selectedChoiceIds">
<value>__OPTIONAL_ACTION_1__</value>
<value> . . . </value>
</bind-property>
</input-adapter>
</plugin>
</group>
<group name="DomainBackupGroup">
<plugin name="DomainDirectoryBackupPlugIn">
<input-adapter name="FileSelectionIA">
<bind-property name="selectedFileNames">
<value>__BACKUP_DIR__</value>
</bind-property>
</input-adapter>
<input-adapter name="TextIA">
<bind-property name="value">
<value>___BACKUP_FILE_NAME__</value>
</bind-property>
</input-adapter>
</plugin>
</group>
</plugin-silent-responses>

-->

表D-3に、このスクリプトに含まれるキーワード、キーワードに対して指定可能な値、および変更しない場合にWebLogicアップグレード・ウィザードで使用されるデフォルト値を示します。

表D-3 ドメインをアップグレードするためのサイレント・モードXMLスクリプトの値

キーワード

設定可能な値

キーワードのデフォルト値

WEBLOGIC_VERSION

アップグレード対象のドメインに含まれるWebLogic Serverのバージョン。脚注 1

アップグレード対象のドメインの構成ファイル(config.xml)で識別されているWebLogic Serverのバージョン。例: 8.1.4.0。

ソフトウェアのバージョン番号がドメインの構成ファイルで指定されていない場合、バージョン番号はデフォルトで8.1.0.0と表示されます。この場合、9.0より前のドメインの実際のバージョン番号とデフォルト値が一致しなくても問題はありません。

ADMIN_SERVER_NAME

ドメインの管理サーバー・インスタンスの名前。

注意 :このキーワードにはデフォルト値がないため、値を割り当てる必要があります。管理サーバー名を入力しない場合、このサイレント・アップグレード・スクリプトによって例外が生成され、処理が終了します。

デフォルト値は割り当てられていません。

DOMAIN_DIR

アップグレード対象のWebLogicドメインが格納されているディレクトリのパス。

アップグレード・ウィザードが実行されるディレクトリ。たとえばc:\bea\user_projects\domains\mydomainです。

NODE_MANAGER_USERNAME

ノード・マネージャのユーザー名。

weblogic

NODE_MANAGER_PASSWORD

ノード・マネージャのパスワード。

weblogic

NODE_MANAGER_PASSWORD

ノード・マネージャの確認パスワード。

weblogic

OPTIONAL_ACTION_1

次のオプションを1つまたは複数指定します。

- DOMAIN_DIRECTORY_BACKUP_SELECTED_VALUE
このオプションを指定すると、元のドメイン・ディレクトリのバックアップがzipファイルに保存されます。

- DOMAIN_DIRECTORY_BACKUP_LOG_FILES_INCLUDED_SELECTED_VALUE
このオプションを指定すると、バックアップ用のzipファイルにログ・ファイルが含められます。ログ・ファイルの数と容量は多大になる可能性があるため、このオプションを無効にしてログ・ファイルをバックアップ・ファイルから除外することもできます。デフォルトでは、ログ・ファイルはバックアップ・ファイルに含められます。

- SKIP_BACKWARDS_COMPATIBILITY_FLAGS_SELECTED_VALUE
9.0より前のバージョンのWebLogic Serverでサポートされていた動作の一部が、9.0以降はJ2EE 1.4に準拠するよう変更されています。デフォルトでは、以前サポートされていた動作が新しいドメインで有効になるようフラグが設定されます。このオプションを指定すると、下位互換性のためのこれらのフラグが設定されません。

OPTIONAL_ACTION_1は、複数のオプションのうちいずれかが使用されるように指定できることに注意してください。例:

DOMAIN_DIRECTORY_BACKUP_SELECTED_VALUE OR
DOMAIN_DIRECTORY_BACKUP_LOG_FILES_INCLUDED_SELECTED_VALUE OR
SKIP_BACKWARDS_COMPATIBILITY_FLAGS_SELECTED_VALUE

DOMAIN_DIRECTORY_
BACKUP_SELECTED_VALUE, DOMAIN_DIRECTORY_
BACKUP_LOG_FILES_INCLUDED_SELECTED_VALUE

BACKUP_DIR

バックアップ用のzipファイルが格納されるディレクトリのパス。

実行されるアップグレード・ウィザードが格納されているディレクトリ。たとえばc:\Oracle\Middleware\user_projects\domains\mydomainです。

BACKUP_FILE_NAME

バックアップ用のzipファイルの名前。

weblogic-domain-backup-mydomain.zip

脚注 1 WebLogic Serverの複数のバージョンを指定する場合は8.1 OR "9.0 or higher"のようにします。

E 管理サーバー起動時におけるドメインのアップグレード(暗黙モード)

この付録では、暗黙モードを使用してドメインをアップグレードする方法について説明します。

暗黙モードを使用すると、WebLogicドメインがサーバーの起動時に自動的にアップグレードされます。このモードは、管理サーバーのあるコンピュータでのみ有効です。また、このモードでのアップグレードは、開発環境において行うことをお薦めします。本番環境において暗黙モードでアップグレードを行うことはお薦めしません。

注意:

暗黙モードのアップグレードは、WebLogicドメインのアップグレードにのみ使用できます。

先に進む前に、「アップグレードの準備」の手順がすでに実行されていなければなりません。

暗黙モードでWebLogicアップグレード・ウィザードを起動するには:

1. WebLogicドメインが稼働していないことを確認します。

2. MS-DOSコマンド・プロンプト・ウィンドウ(Windows)またはコマンド・シェル(UNIX)を開き、「ステップ6: 環境の設定」の説明に従って環境を設定します。

3. WebLogic Server 12.1.1のインストール先を参照するようドメインの起動スクリプトを更新します。
たとえば、WL_HOMEがWebLogic Server 12.1.1インストールに設定されていることを確認します。例: c:\Oracle\Middleware\wlserver_12.1

デフォルトでは、WebLogicアップグレード・ウィザードでアップグレード・プロセスを開始する前にアップグレードを開始するかどうか確認するよう求められます。これを無効にするには、起動スクリプトでサーバーを起動する次のコマンド引数を指定します。

-Dweblogic.ForceImplicitUpgradeIfNeeded=true

4. ドメインの管理サーバーを起動します。
必要に応じて、アップグレードに関する確認のメッセージに応答します。

WebLogicアップグレード・ウィザードは、ドメイン・ディレクトリの生成に有効なバージョンのWebLogic Server (8.1)が使用されたかどうかを確認し、有効なバージョンである場合は、ドメインを自動的にアップグレードします。このプロセスが行われるのは、管理サーバーを初めて起動したときのみです。

注意:

暗黙的なアップグレードは、WebLogic Serverバージョン9.xまたは10.0から12.1.1へのアップグレード時には使用できません。12.1.1では、9.xまたは10.0のドメインを変更せずに実行できます。

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