ヘッダーをスキップ
Oracle® Fusion Middleware Oracle WebLogic Server アップグレード ガイド
11g リリース 1 (10.3.1)
B55562-01
  目次
目次

戻る
戻る
 
次へ
次へ
 

B WebLogic Server 10.3.1 の旧リリースとの互換性

この節では、WebLogic Server 10.3.1 にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。

『Oracle Fusion Middleware Oracle WebLogic Server のインフォメーション ロードマップ』の「WebLogic Server Compatibility」も参照してください。

互換性に関する検討事項は、以下のカテゴリに分類されます。

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 と 10.3.1 でも使用できます。

JMX クライアントを WebLogic Server 10.3.1 に準拠するよう更新することをお勧めします。9.0 より前では、WebLogic Server は JMX レイヤに対して、型付き API レイヤをサポートしていました。使用する JMX アプリケーション クラスでは、WebLogic Server MBean の型保障インタフェースをインポートしたり、weblogic.management.MBeanHome インタフェースを介して MBean の参照を取得したり、MBean メソッドを直接呼び出すことができました。

非推奨になった機能

MBeanHome インタフェースは、9.0 から非推奨となりました。この API のようなプログラミング モデルを使用する代わりに、すべての JMX アプリケーションで、標準の JMX プログラミング モデルを使用してください。標準の JMX 設計パターンでは、クライアントは javax.management.MBeanServerConnection インタフェースを使用して、実行時に MBean、属性、および属性タイプを検索します。この JMX モデルでは、クライアントは MBeanServerConnection インタフェースを介して間接的に MBean と対話します。

型保障インタフェース (weblogic.management から使用可能) をインポートするクラスがある場合は、そのクラスを標準の JMX プログラミング モデルを使用するよう更新することをお勧めします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean について」を参照してください。

動的コンフィグレーション管理

コンフィグレーション属性には、「動的なもの」と「動的でないもの」があります。

WebLogic Server 9.0 から導入された変更管理プロセスにより、コンフィグレーションの変更をドメイン全体にわたってセキュアで確実に適用できます。バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、コンフィグレーションされているサーバまたはシステム リソースが動的でない変更の影響を受ける場合、サーバまたはシステム リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更 (動的な変更も含む) は有効になりません。この場合、システムの整合性を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお勧めします。

コンフィグレーション スクリプトをテストして、動的でない変更が適用されているかどうか確認し、適用されている場合はサーバを再起動する必要があります。変更が動的でなく、サーバの再起動が必要かどうかを判断するには、次の手順に従います。

どのセキュリティ属性が動的であるか動的でないかを確認するには、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「セキュリティ コンフィグレーション MBean」を参照してください。

詳細については、『Oracle Fusion Middleware Oracle WebLogic Server ドメインのコンフィグレーションについて』の「コンフィグレーションの変更の管理」を参照してください。

スキーマのネームスペースと場所の変更

WebLogic Server 10.3.1 では、www.bea.com が含まれていたネームスペース URI とスキーマの場所が xmlns.oracle.com を参照するように変更されました。また、WebLogic Server のバージョン番号 (920、90) が削除されました。

Oracle WebLogic Server スキーマのホーム (http://www.oracle.com/technology/weblogic/index.html) を参照してください。また、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「XML デプロイメント記述子」を参照してください。

JDBC リソースのモジュール式コンフィグレーションおよびデプロイメント

JDBC のコンフィグレーションを簡素化し、コンフィグレーション エラーが発生する可能性を低くするため、WebLogic Server 9.0 からは、使用する JDBC リソースのタイプが少なくなっています。JDBC 接続プールをコンフィグレーションしてから、その接続プールを指し、JNDI ツリーにバインドされるデータ ソースまたは tx データ ソースをコンフィグレーションする代わりに、接続プールを包含するデータ ソースをコンフィグレーションできるようになりました。WebLogic Server 9.0 で導入された簡素化された JDBC リソースのコンフィグレーションの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「簡素化された JDBC リソース コンフィグレーション」(http://e-docs.bea.com/wls/docs90/jdbc_admin/jdbc_intro.html#simple_res_config) を参照してください。

以下の節で説明するように、WebLogic アップグレード ウィザードは、JDBC データ ソース、接続プール、マルチプール、およびデータ ソース ファクトリを WebLogic Server 10.3.1 仕様に自動的に変換します。

WebLogic Server 9.0 で非推奨になった JDBC 機能、メソッド、インタフェース、および MBean については、『リリース ノート』の「非推奨になった JDBC の機能、メソッド、インタフェース、および MBean」(http://e-docs.bea.com/wls/docs90/notes/new.html#deprecated_jdbc_features) を参照してください。

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

アップグレード ウィザードは、従来の JDBC データ ソース/接続プールの組み合わせを 2 つのデータ ソース システム リソース モジュールに変換します (1 つはデータ ソース用、もう 1 つは接続プール用)。

  • 既存のデータ ソースまたは tx データ ソースに置き換わるデータ ソースは、データ ソース パラメータを定義し、その接続プールと関連属性を定義するもう 1 つのデータ ソースを参照する

  • 既存の接続プールに置き換わるデータ ソースは、JDBC ドライバ パラメータ、接続プール パラメータ、および XA パラメータを定義する


    注意 :

    ドメインのアップグレードの 1 つのプロセスとして変換されるデータ ソースのみが、その接続プールを定義するもう 1 つのデータ ソースを参照することができます。それ以外のデータ ソースは、それぞれ独自のデータベース接続プールを保有しています。

アップグレード中、アップグレード ウィザードは、データ ソースの GlobalTransactionsProtocol パラメータを、表 B-1 に示すように、変換するデータ ソースのタイプ (tx かどうか) と対応する接続プールで使用されるドライバのタイプに応じて設定します。

表 B-1 グローバル トランザクションのプロトコル パラメータ設定

従来のデータ ソース タイプ ドライバ タイプ 2 フェーズ コミットのエミュレーション GlobalTransactionProtocol

Tx データ ソース

XA

なし

TwoPhaseCommit

Tx データ ソース

非 XA

False

OnePhaseCommit (デフォルトでは明示的にセットされない)

Tx データ ソース

非 XA

True

EmulateTwoPhaseCommit脚注 1 

データ ソース

非 XA

なし

なし


脚注 1 使用する環境によっては、トランザクション処理に EmulateTwoPhaseCommit トランザクション プロトコルではなく LoggingLastResource (LLR) トランザクション プロトコルを使用するほうが、パフォーマンス上のメリットがあります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」を参照してください。

マルチプール

アップグレード ウィザードは、マルチプールを、データ ソース間のロード バランシングとフェイルオーバを実現するデータ ソース オブジェクトのもう 1 つのインスタンスであるマルチ データ ソースに変換します。

データ ソース ファクトリ

データ ソース ファクトリは、WebLogic Server 9.0 より非推奨となっており、下位互換性の維持だけを目的として含まれています。データ ソース ファクトリの変換は不要です。

JDBC 機能の変更点

以降の節では、JDBC サポートの変更点について説明します。

新しい JDBC 機能の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server の新機能』の「JDBC」を参照してください。

JDBC 4.0 サポート

WebLogic Server 10.3 は、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 に更新された。

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

以下の JDBC ドライバは非推奨となりました。

  • Oracle 用の WebLogic Type 4 JDBC ドライバ

    このドライバは、WebLogic Server 10.3 で非推奨になりました。WebLogic Server の次のリリースでは削除される予定です。この非推奨のドライバの代わりに、WebLogic Server にも付属している Oracle Thin Driver を使用してください。Oracle Thin Driver の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Type 4 JDBC ドライバ ガイド』の「WebLogic Server でのサードパーティ JDBC ドライバの使い方」を参照してください。

  • Sybase Jconnect 5.5 および 6.0 ドライバ。これらのドライバは、サンプル コードのデフォルト インストールに関する Oracle セキュリティ ポリシーに従って 10.3.1 から削除されました。これらのドライバは Sybase からダウンロードできます。また、WebLogic Server に付属している Oracle ブランドの Sybase 用 JDBC ドライバを使用することもできます。

更新された WebLogic Type 4 JDBC ドライバ

WebLogic Server に付属している WebLogic Type 4 JDBC ドライバは、DataDirect から提供されています。10.3 において DataDirect バージョン 3.7 に変更されました。これらのドライバの変更や JDBC 4.0 のサポートの詳細については、WebLogic Server 10.3 の『リリース ノート』の「更新された WebLogic Type 4 JDBC ドライバ」を参照してください。

Oracle 11g RAC のサポート

WebLogic Server 10.3.1 では、Oracle 11g および 11g RAC (Real Application Clusters) がサポートされます。このリリースでは、データ ソースおよびマルチ データ ソースを Oracle RAC ノード上で実行されるサービスに接続するためのサポートも追加されました。

『Oracle Fusion Middleware Oracle WebLogic Server JDBC のコンフィグレーションと管理』の「WebLogic Server での Oracle RAC の使い方」を参照してください。

JDBC デバッグの強化

JDBC サブシステムでは、集中管理されたデバッグへのアクセスおよびロギングを行うために、システム全体を対象とした新しい WebLogic 診断サービスを使用します。

Oracle Fusion Middleware Using the Diagnostic Framework Console Extension for Oracle WebLogic Server』を参照してください。

JMS リソースのモジュール式コンフィグレーションおよびデプロイメント

WebLogic Server 9.0 から JMS コンフィグレーションはモジュールとして格納されています。これは、新しい weblogic-jmsmd.xsd スキーマに準拠する XML ドキュメントで定義されます。JMS リソースのモジュール式デプロイメントにより、アプリケーションと JMS コンフィグレーションを別の環境にプロモートできます。たとえば、アプリケーションとそれに必要な JMS コンフィグレーションを、EAR ファイルを開くことなく、また JMS を手動で再コンフィグレーションすることなく、テスト環境からプロダクション環境にプロモートできます。

詳細については、以下を参照してください。

WebLogic アップグレード ウィザードは、9.0 より前のバージョンの JMS リソースを、ドメインの config\jms ディレクトリにコピーされる interop-jms.xml という名前の JMS Interop モジュール ファイルに自動的に変換します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JMS のコンフィグレーションと管理』の「JMS Interop モジュール」を参照してください。

JMS コンフィグレーションは以下のように変更されています。

JMS メッセージ ID 形式

JMS メッセージ ID の形式は、WebLogic Server 9.0 で変更されています。既存のコンシューマ、プロデューサ、およびサーバで使用されている 9.0 より前のバージョンの形式は、引き続きサポートされます。たとえば、既存の JMS コンシューマは、新しい JMS プロデューサまたは JMS サーバから送信されたメッセージであっても、引き続き 9.0 より前のバージョンの形式で確認することができます。

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

メッセージ負荷のピーク時に仮想メモリを解放するメッセージ ページング機能が、JMS サーバでは常に有効に設定されています。また、ページアウトされたメッセージは、使用しているファイル システムのディレクトリに格納できるため、管理者は専用のメッセージ ページング ストアを作成する必要はありません。ただし、最適なパフォーマンスを維持するには、メッセージのページング先のディレクトリを JMS サーバの永久ストアが使用する以外のディレクトリに指定する必要があります。

『Oracle Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド』の「メッセージのページングによるメモリの解放」を参照してください。

スレッド管理

スレッド管理にはワーク マネージャの概念を使用することをお勧めします。実行キューは、WebLogic Server 9.0 からデフォルトの方法ではなくなりました。アプリケーション用のルールと制約を定義するには、ワーク マネージャを定義して、それを WebLogic Server ドメインに対してグローバルに適用するか、特定のアプリケーション コンポーネントに対して限定的に適用します。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server サーバ環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。

WebLogic Server 8.1 では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上させるために 8.1 で実行キューを使用していた場合は、アプリケーション ドメインのアップグレード後にも実行キューを引き続き使用できます。アップグレードしたアプリケーションでユーザ定義実行キューを引き続き使用できるようにするために、use81-style-execute-queues というフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と、実行キューのコンフィグレーションおよび監視に関する詳細については、『Oracle Fusion Middleware Oracle WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic 8.1 スレッド プール モデルを有効にする方法」を参照してください。

JTA

以降の節では、JTA 機能の変更点について説明します。

リソース登録名

WebLogic Server 10.3.1 では、XA データ ソース コンフィグレーションのリソース登録名の動作が変更されました。以前のリリースでは、JTA の登録名はデータ ソースの名前のみでした。今後は、データ ソース名とドメインの組み合わせになります。

詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「XAResource のトランザクションへの参加の登録」を参照してください。

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

ドメイン レベルの JTA コンフィグレーション オプションはすべて従来のコンフィグレーション ファイルから保持されています。サーバ レベルでのみ変更があります。WebLogic Server 9.0 から、トランザクション マネージャでは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ レコードを保存します。アップグレード中、アップグレード ウィザードは、トランザクション ログ レコードをデフォルト ストアにコピーします。既存のサーバ コンフィグレーションに基づいて設定されるトランザクション ログ ファイルのプレフィックスは、アップグレード中にトランザクション ログ ファイル (.tlog) を検索する目的にのみ使用され、アップグレード後は保持されません。

ドメイン全体が 1 つのマシンにある場合、アップグレード ウィザードは、初期ドメイン アップグレードにおいて、すべての管理対象サーバのアップグレードを処理します (トランザクション ログ レコードをデフォルト ストアにコピーします)。管理対象サーバが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバを個別にアップグレードする必要があります。

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

トランザクション回復サービスの移行の準備においてトランザクション ログ ファイルをネットワーク ストレージに配置した場合、アップグレード後、ログ ファイルの場所は保持されません。このリリースでは、WebLogic Server トランザクション マネージャは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ ファイルを保存します。デフォルトの WebLogic 永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DAT ファイルを現在のデフォルト ストアのデフォルトの場所からデフォルト ストアの新しい場所に手動でコピーする必要があることに注意してください。

トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする必要があります。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server JTA プログラマーズ ガイド』の「ドメイン間トランザクションに対するドメインのコンフィグレーション」を参照してください。

エンタープライズ Java Beans (EJB)

このリリースでは、EJB 3.0 アプリケーションで Oracle TopLink の機能を活用できます。Oracle TopLink は、高度なオブジェクト永続性およびオブジェクト変換フレームワークであり、開発と保守にかかる労力を削減して、エンタープライズ アプリケーションの機能性を高める開発ツールと実行時機能を提供します。詳細については、『Oracle Fusion Middleware Developer's Guide for Oracle TopLink』を参照してください。


注意 :

Oracle Kodo は、WebLogic Server 10.3.1 において非推奨となりました。

Oracle Fusion Middleware ホーム ディレクトリ

WebLogic Server 10.3.1 では、BEA ホーム ディレクトリが Oracle Fusion Middleware ホーム ディレクトリ (通常は短く Middleware ホームと呼ぶ) に変更されました。このディレクトリのデフォルト パスは <drive:>Oracle/Middleware です。この変更が WebLogic Server に及ぼす影響は以下のとおりです。

この変更は、マシン上の既存の WebLogic Server、カスタム ドメイン、アプリケーション、スクリプトには影響しません。これまでどおり BEA_HOME 環境変数を使用することも可能です。

セキュリティ

次の節では、セキュリティ機能に関する変更点について説明します。

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

Windows NT 認証プロバイダは、WebLogic Server 10.0 以降では非推奨となっています。代わりに、それ以外のサポート対象の 1 つまたは複数の認証プロバイダを使用してください。

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 ドメインを 10.3.1 にアップグレードして、現在指定されている認可プロバイダおよびロール マッピング プロバイダ (サード パーティ パートナのプロバイダ、オリジナルの WebLogic 認可プロバイダおよびロール マッピング プロバイダなど) を引き続き使用できます。WebLogic Server 独自のプロバイダを使用している既存ドメインを、必要に応じて XACML プロバイダに移行することもできます (既存ポリシーのバルク インポートも含む)。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のインフォメーション ロードマップ』の「セキュリティ」を参照してください。

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 インスタンスとは互換性がありません。

SAML 2.0 プロバイダ

WebLogic Server 10.3 では、SAML 2.0 をサポートするため、SAML 2.0 資格マッピング プロバイダおよび SAML 2.0 ID アサーション プロバイダが追加されました。これらの新しいプロバイダはそれぞれ、次を利用する場合に SAML 2.0 アサーションの生成および消費に使用することができます。

  • SAML 2.0 Web シングル サインオン (SSO) プロファイル

  • WS-Security SAML トークン プロファイル バージョン 1.1

SAML 2.0 Web SSO では、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 Token Profile 1.0 と下位互換性があります。SAML トークンは、WS-SecurityPolicy アサーションを適切に使用することで Web サービスでコンフィグレーションされます。


注意 :

SAML Token Profile 1.1 は WS-SecurityPolicy を通じてのみサポートされます。以前の「WLS 9.2 セキュリティ ポリシー」では、SAML Token Profile 1.0/SAML 1.1 のみがサポートされます。

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

Oracle Internet Directory 認証プロバイダと Oracle Virtual Directory 認証プロバイダという 2 つの新しい LDAP 認証プロバイダが WebLogic Server に追加されました。これらの認証プロバイダを使用すると、Oracle Internet Directory LDAP サーバと Oracle Virtual Directory LDAP サーバにユーザとグループを格納したり、両サーバからユーザとグループを読み取ったりできます。

これらの新しいセキュリティ プロバイダのコンフィグレーションと使用の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server のセキュリティ』の「LDAP 認証プロバイダのコンフィグレーション」を参照してください。

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 Fusion Middleware Oracle WebLogic Server のセキュリティ』の「RDBMS セキュリティ ストアの管理」を参照してください。

パスワード検証プロバイダ

パスワード検証プロバイダは、WebLogic Server 10.3 で追加されました。以下のいずれかの認証プロバイダでコンフィグレーションし、コンフィグレーション可能なパスワードの構成ルール セットを適用できます。

  • WebLogic 認証プロバイダ

  • SQL 認証プロバイダ

  • LDAP 認証プロバイダ

  • Active Directory 認証プロバイダ

  • iPlanet 認証プロバイダ

  • Novell 認証プロバイダ

  • Open LDAP 認証プロバイダ

パスワード検証プロバイダでコンフィグレーションされている認証プロバイダを使用してパスワードを作成または変更する場合、パスワードは構成ルール セットと照合されて自動的に検証されます。パスワード構成ルールはコンフィグレーション可能であり、最小パスワード長、必要な英数字の最小文字数、必要な英数字以外の文字数などを制御することができます。

セキュリティ MBean

表 B-2 に、WebLogic Server 9.0 におけるセキュリティ MBean の変更点を示します。

表 B-2 WebLogic Server 9.0 におけるセキュリティ MBean の変更点

セキュリティ MBean のタイプ 説明

すべてのセキュリティ MBean

WebLogic Server 8.1 では、セキュリティ MBean 属性を更新すると、値はセキュリティ コンフィグレーションと管理階層ではただちに有効になり、セキュリティ実行時階層ではサーバを再起動すると有効になった。

WebLogic Server 9.0 からは、セキュリティ MBean 属性の変更がコンフィグレーション、管理、および実行時階層でただちに有効になるか、サーバを再起動すると有効になるかについては、この属性を動的な属性として設定するか動的でない属性として設定するかによって制御される。詳細については、「動的コンフィグレーション管理」を参照。

RealmMBeanUserLockoutManagerMBean、およびすべてのセキュリティ プロバイダ 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 = "この属性はダミーであることを指定"
    />
    

パスワードの暗号化

権限のないアクセスからパスワードなどの重要なデータを保護するために、コンフィグレーション MBean のいくつかの属性は暗号化されます。属性の値は、ドメインのコンフィグレーション ファイルに暗号化された文字列として保持されます。メモリ内の値が暗号化されたバイト配列として保存されるため、パスワードがメモリから盗用されるリスクが軽減され、セキュリティがさらに強化されます。

9.0 より前のリリースでは、クリア テキスト形式または暗号化形式で、パスワードなどの暗号化する属性を config.xml ファイルで指定することができました。この場合、WebLogic Server は、次に起動され、そのファイルに書き込むときに情報を暗号化します。

WebLogic Server 9.0 から、プロダクション モードのときは、パスワードなどの暗号化する属性はコンフィグレーション ファイルで暗号化されなければなりません。開発モードのときは、パスワードなどの暗号化する属性はクリア テキスト形式または暗号化形式のどちらでもかまいません。

次のように、weblogic.security.Encrypt コマンドライン ユーティリティを使用してパスワードを暗号化することができます。

java weblogic.security.Encrypt

ここで、パスワードを入力するよう求められます。パスワードを入力すると、暗号化されたバージョンが返されます。次に、暗号化されたパスワードを適切なファイルにコピーします。

このユーティリティの対象は、コンフィグレーション ファイルのパスワードだけではありません。これは、記述子ファイル (JDBC または JMS 記述子など) およびデプロイメント プランでパスワードを暗号化する場合にも使用できます。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server コマンド リファレンス』の「encrypt」を参照してください。

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

WebLogic Server 10.3.1 のインスタンスが HTTP リクエストに応答するとき、HTTP 応答ヘッダにはデフォルトで、WebLogic Server のサーバ名およびバージョン番号は含まれません。この動作は、WebLogic Server 9.0 より前のリリースとは異なります。

HTTP リクエストに応答するときにサーバ名とバージョン番号を HTTP 応答ヘッダに含めるには、Administration Console で WebLogic Server の [Send Server Header を有効化] 属性を有効にします。この属性は、[サーバServerNameプロトコルHTTP] タブの [詳細オプション] セクションにあります。この機能を有効にすると、攻撃者が WebLogic Server の特定のバージョンの脆弱性についての知識がある場合、これによりセキュリティ リスクが発生する可能性があります。

セキュリティを確保する方法の詳細については、『Oracle Fusion Middleware 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 の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server 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 サービス

WebLogic Server 8.1 Web サービスは 10.3.1 でも実行できますが、8.1 Web サービスの実行時エンジンは 9.0 以降では非推奨となっています。

Web サービスを 9.2 から 10.0 へ、または 10.0 から 10.3 または 10.3.1 へアップグレードする必要はありません。

WebLogic Server 7.0 Web サービスは、10.3.1 で実行するには、少なくとも 8.1 にアップグレードする必要があります。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「WebLogic Web サービスのアップグレード」(http://e-docs.bea.com/wls/docs81/webserv/migrate.html) を参照してください。

8.1 にアップグレードされた 7.0 Web サービスを含む、すべての 8.1 Web サービスを 10.3.1 にアップグレードすることをお勧めします。

既存の 8.1 Web サービスの 10.3.1 へのアップグレードについては、『Oracle Fusion Middleware Oracle WebLogic Server JAX-RPC を使用した Web サービス入門』の「WebLogic Web サービスの旧リリースから 10g リリース 3 へのアップグレード」を参照してください。

新しい Web サービス機能

WebLogic Server 10.3.1 には以下の新機能が追加されました。

  • 新たな開発ツール、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 Fusion Middleware Oracle WebLogic Server の新機能』の「Web サービス」を参照してください。

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

以下の節では、WebLogic Server 10.3.1 における Web アプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。

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

WebLogic Server 10.3.1 から非推奨またはサポート対象外となった Web アプリケーション機能については、『Oracle Fusion Middleware Oracle WebLogic Server の新機能』の以下のトピックを参照してください。

保護されていないリソースを使用する 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 Fusion Middleware Oracle WebLogic Server Security プログラマーズ ガイド』の「リソースが非セキュアな場合の BASIC 認証について」を参照してください。

下位互換性フラグ

この節および『Oracle Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「jsp-descriptor」で説明されているように、WebLogic Server 10.3.1 での 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.3.1 では JSP 2.0 もサポートされます。

バッファのサフィックスの設定およびサーブレット 2.5 パッケージの暗黙的なインポートについては、『Oracle Fusion Middleware 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)
    

    この例外は、このようなエラーが重要な問題でない場合は、捕捉して無視することができます。

  • JspWriterImplprintline 関数ごとに \nSystem.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> 
    

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

Sun Microsystems のサーブレット 2.3 仕様 (http://java.sun.com/products/servlet/download.html#specs でダウンロード可能) では、マッピングの定義に次の構文を使用します。

  • / (フォワード スラッシュ) 文字だけが含まれるサーブレット パス文字列は、アプリケーションのデフォルト サーブレットを表す。サーブレット パスは、リクエスト URI からコンテキスト パスを削除したパス (この場合は null) に解決される。

  • 1 個の * (アスタリスク) で始まる文字列は、拡張子マッピングを指定する。

これらの変更により、次の HttpServletRequest メソッドの動作に変化が生じます。

  • getPathInfo

  • getServletPath

動作の変更を説明するために、例として /abc/def.html というリクエストが ServletA に解決される場合を考えます。

  • / が ServletA にマップされると、servletPath="abc/def.html" および pathInfo=null になる。

  • /* が ServletA にマップされると、servletPath="" および pathInfo="abc/def.html" になる。

確実に null でないパス情報が返されるようにするには、/ (フォワード スラッシュ) のサーブレット マッピング文字列が出現するすべての箇所を /* に置換します。

XML 実装

WebLogic Server 9.0 からは、XML のサポートが次のように変更されています。

XMLBeans 実装と XQuery 実装

WebLogic Server 9.0 から、XMLBean 実装は内部ライブラリ (com.bea.xml) から Apache オープン ソース プロジェクト (org.apache.xmlbeans) に移動されています。

WebLogic Server 8.1 のアプリケーションで XMLBeans を使用していた場合は、次の手順を実行する必要があります。

  1. XMLBeans により使用されているパッケージ名を com.bea.xml から org.apache.xmlbeans に更新します。

  2. XMLBean スキーマを再コンパイルして、スキーマ メタデータ ファイル (.xsb) と生成されているコードを更新します。

WebLogic Server 9.0 以降の XMLQuery (XQuery) 実装は、次の仕様に準拠しています。

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() のメソッド呼び出しを必要に応じて確認および変更してください。

9.0 から、XMLCursor.moveXML() の動作が変更されています。8.1 では、移動されたフラグメント内にあったカーソルは、元のドキュメントに残ります。9.0 以降では、カーソルはフラグメントと共に移動します。

WebLogic の管理およびコンフィグレーション スクリプト

MBean の階層構造に加えられた変更により、9.2 より前のコンフィグレーションおよび管理スクリプト (WLST、wlconfigweblogic.Admin、Ant など) が 10.3.1 で動作する保証はなくなりました。WebLogic Server 10.3.1 からの新しい機能を利用するようスクリプトを更新することをお勧めします。MBean 階層構造の新機能と変更点の詳細については、以下のトピックを参照してください。

アプリケーション インフラストラクチャのアップグレードと非推奨となったスクリプト ツールの詳細については、「手順 1 : アプリケーション インフラストラクチャのアップグレード」を参照してください。

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

この節では、リリース 9.0 より変更された WebLogic Server 環境におけるデプロイメント記述子の使用方法について説明します。

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

アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server 9.0 から非推奨となり、代わりにアプリケーションはアプリケーション ライフサイクル イベントに応答するようになりました。ドメイン レベルのアプリケーション スコープの起動クラスと停止クラスの代わりにライフサイクル イベントを使用するようアプリケーション環境を更新することをお勧めします。詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「アプリケーション ライフサイクル イベントのプログラミング」を参照してください。

Administration Console

以降の節では、Administration Console に対する変更点について説明します。

Administration Console のコンフィグレーション機能

WebLogic Server 10.3 で Administration Console の動作をコンフィグレーションするためのオプションが追加され、以下のことを実行できるようになりました。

  • ドメイン コンフィグレーションのロック。これにより、編集セッション中に他のアカウントによって変更されずに、コンフィグレーションを変更できます。

  • Administration Console、UDDI、および UDDI エクスプローラなどの内部アプリケーションをデプロイするかどうかの指定。サーバの起動時ではなく、最初のアクセス時に必要に応じてデプロイするかどうかを指定できます。

  • バナー ツールバー領域に新たに追加された検索機能の利用。この検索で指定した文字列が名前に含まれる WebLogic Server コンフィグレーション MBean を検索できます。

  • 障害が発生したサーバやサービスを別のサーバへ自動的に移行する追加機能の利用。

  • Service Component Architecture (SCA) のデプロイメントおよび制御。

  • Spring アプリケーションの検査。

詳細については、WebLogic Server 10.3 の『リリース ノート』の「WebLogic Server の新機能」を参照してください。

Administration Console の拡張アーキテクチャ

WebLogic Server バージョン 9.0 の Administration Console は、WebLogic Portal のフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。アーキテクチャが新しくなったため、Administration Console を拡張する手順も新しくなりました。9.0 以前の WebLogic Server のリリース用に構築された WebLogic Administration Console の拡張は、新しいインフラストラクチャでは機能しません。

WebLogic Server 10.3.1 では以下の機能が追加されました。

  • サンプルのルック アンド フィールが提供されている。サンプルを変更して、Administration Console のカスタムのルック アンド フィールを作成できます。

  • オンライン ヘルプを作成して、コンソール拡張に関連付けることができる。

Administration Console の拡張の詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console の拡張』を参照してください。

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

WebLogic Server バージョン 9.2 では、コンソール拡張が以下のように変更されています。

  • このリリース以前の Administration Console 拡張機能では、サード パーティ JSP タグ ライブラリへのパス名を指定することにより、それらのライブラリのインポートが可能であった。たとえば、次のようになります。

    <%@ taglib uri="/WEB-INF/beehive-netui-tags-template.tld" prefix="beehive-template" %> 
    

    WebLogic Server インストールからサード パーティ JSP タグ ライブラリを使用する Administration Console 拡張機能では、10.0 より、タグ ライブラリを指定する定義済みの絶対 URI を使用する必要があります。以下に例を示します。

    <%@ taglib uri="http://beehive.apache.org/netui/tags-template-1.0" prefix="beehive-template" %> 
    

    Administration Console の web.xml ファイルが、WebLogic Server インストール内部のタグ ライブラリに URI をマップします。このマッピング機能によって、ユーザが JSP を変更しなくても、タグ ライブラリのインストール ディレクトリが認識されます。

    古いパス名構文を使用して Apache Struts、Apache Beehive、または JSTL タグ ライブラリをインポートするすべての Administration Console 拡張機能では、パス名をすべて新しい URI に更新する必要があります。

    WebLogic Server のコンソール拡張機能タグ ライブラリ (console-html.tld) の URI は変更されていません (/WEB-INF/console-html.tld)。

    詳細については、『Oracle Fusion Middleware Oracle WebLogic Server Administration Console の拡張』の「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 を使用するように更新する必要があります。

リソース アダプタ

表 B-3 に、非推奨またはサポート対象外となったリソース アダプタのコンフィグレーション設定を示します。新機能および変更点については、『Oracle Fusion Middleware Oracle WebLogic Server の新機能』を参照してください。

表 B-3 非推奨またはサポート対象外となったリソース アダプタのコンフィグレーション設定

要素 WebLogic Server 9.0 での変更点

Link-Ref メカニズム

この要素は非推奨となっており、新しい Java EE ライブラリ機能に置き換えられている。Java EE ライブラリの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 J2EE ライブラリおよびオプション パッケージの作成」を参照。

Link-Ref メカニズムは、J2CA 1.0 仕様に準拠して開発されたリソース アダプタの場合は、このリリースでもサポートされている。1.0 リソース アダプタでの Link-Ref メカニズムの使用の詳細については、『Oracle Fusion Middleware 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>

この要素はサポートされなくなった。セキュリティ プリンシパル マップは Administration Console を使用してコンフィグレーションされる。

weblogic-ra.xml ファイルから <security-principal-map> 定義を削除する必要がある。削除しなければ、リソース アダプタのデプロイメントが正常に実行されない。

<connection-cleanup-frequency>

この要素はサポートされなくなり、デプロイメントにおいて無視される。

<connection-duration-time>

この要素はサポートされなくなり、デプロイメントにおいて無視される。


WLEC

WLEC は、WebLogic Server 8.1 で非推奨となりました。WLEC ユーザは、『Oracle Fusion Middleware Oracle WebLogic Server Tuxedo Connector 移行ガイド』の説明に従って、アプリケーションを WebLogic Tuxedo Connector に移行する必要があります。

使用されなくなった SNMP MIB 更新間隔とサーバ状態チェック間隔

WebLogic Server 10.0 では、SNMPAgentMBean MBean の MibDataRefreshInterval 属性と ServerStatusCheckIntervalFactor 属性は非推奨となったため無視されます。

下位互換性フラグ

表 B-4 のコンフィグレーション フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル モードでのアップグレード」で説明されているように、アップグレード中に [下位互換性フラグを設定しない] オプションを選択して無効にしない限り、下位互換性をサポートするためデフォルトで設定されます。

表 B-4 下位互換性フラグ

カテゴリ 下位互換性フラグ 詳細については、以下を参照

セキュリティ

  • 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 10.3.1 では JSP 2.1 または JSP 2.0 がサポートされる。

    backward-compatiblejsp-descriptor 要素内に配置される (『Oracle Fusion Middleware 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


非推奨となった API と削除された API

WebLogic Server 10.3.1 の非推奨になった機能に関する情報は、My Oracle Support (https://metalink.oracle.com) で入手できます。WebLogic Server 10.3 で非推奨になった機能については、『Oracle Fusion Middleware Oracle WebLogic Server の新機能』の「非推奨になった機能 (WebLogic Server 10.3)」を参照してください。