![]() ![]() ![]() ![]() |
この節では、WebLogic Server 10.3 にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。
また、「Oracle WebLogic Server 10g リリース 3 の互換性について」も参照してください。
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 でも使用できます。
weblogic.management.MBeanHome
のみを使用する場合は、アップグレードしなくても WebLogic Server 9.2、10.0、または 10.3 インスタンスで実行できる。 -Djmx.serial.form=1.0
を含める必要がある。
この起動オプションを含めると、JVM がオブジェクトをシリアライズするときに JMX 1.0 のクラス記述が使用されるようになります。このオプションは、JMX 1.0 クライアントが標準の JDK クラスを使用して JMX 1.2 エージェントと通信する場合に必要です。
JMX クライアントを WebLogic Server 10.3 に準拠するよう更新することをお勧めします。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 プログラミング モデルを使用するよう更新することをお勧めします。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean について」を参照してください。
コンフィグレーション属性には、「動的なもの」と「動的でないもの」があります。
WebLogic Server 9.0 から導入された変更管理プロセスにより、コンフィグレーションの変更をドメイン全体にわたってセキュアで確実に適用できます。バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、コンフィグレーションされているサーバまたはシステム リソースが動的でない変更の影響を受ける場合、サーバまたはシステム リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更 (動的な変更も含む) は有効になりません。この場合、システムの整合性を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお勧めします。
コンフィグレーション スクリプトをテストして、動的でない変更が適用されているかどうか確認し、適用されている場合はサーバを再起動する必要があります。変更が動的でなく、サーバの再起動が必要かどうかを判断するには、次の手順に従います。
isRestartRequired
または showChanges
のどちらかの WLST コマンドを使用する。詳細については、『WebLogic Scripting Tool ガイド』の「WLST コマンドおよび変数リファレンス」を参照してください。
どのセキュリティ属性が動的であるか動的でないかを確認するには、『WebLogic Server のセキュリティ』の「セキュリティ コンフィグレーション MBean」を参照してください。
詳細については、『ドメインのコンフィグレーションについて』の「コンフィグレーションの変更の管理」を参照してください。
JDBC のコンフィグレーションを簡素化し、コンフィグレーション エラーが発生する可能性を低くするため、WebLogic Server 9.0 からは、使用する JDBC リソースのタイプが少なくなっています。JDBC 接続プールをコンフィグレーションしてから、その接続プールを指し、JNDI ツリーにバインドされるデータ ソースまたは tx データ ソースをコンフィグレーションする代わりに、接続プールを包含するデータ ソースをコンフィグレーションできるようになりました。WebLogic Server 9.0 で導入された簡素化された JDBC リソースのコンフィグレーションの詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「簡素化された JDBC リソース コンフィグレーション」を参照してください。
以下の節で説明するように、WebLogic アップグレード ウィザードは、JDBC データ ソース、接続プール、マルチプール、およびデータ ソース ファクトリを WebLogic Server 10.3 仕様に自動的に変換します。
注意 : | アップグレードしたそれぞれの JDBC モジュールに内部プロパティ セクションがあります。WebLogic Server では、下位互換性に対応するため、データ ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBC データ ソース ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。 |
WebLogic Server 9.0 より非推奨となった JDBC 機能、メソッド、インタフェース、および MBean については、『リリース ノート』の「非推奨になった JDBC の機能、メソッド、インタフェース、および MBean」を参照してください。
アップグレード ウィザードは、従来の JDBC データ ソース/接続プールの組み合わせを 2 つのデータ ソース システム リソース モジュールに変換します (1 つはデータ ソース用、もう 1 つは接続プール用)。
アップグレード中、アップグレード ウィザードは、データ ソースの GlobalTransactionsProtocol
パラメータを、表 B-1 に示すように、変換するデータ ソースのタイプ (tx かどうか) と対応する接続プールで使用されるドライバのタイプに応じて設定します。
|
アップグレード ウィザードは、マルチプールを、データ ソース間のロード バランシングとフェイルオーバを実現するデータ ソース オブジェクトのもう 1 つのインスタンスであるマルチ データ ソースに変換します。
データ ソース ファクトリは、WebLogic Server 9.0 より非推奨となっており、下位互換性の維持だけを目的として含まれています。データ ソース ファクトリの変換は不要です。
以降の節では、JDBC サポートの変更点について説明します。
WebLogic Server は 10.3 より JDBC 4.0 仕様に準拠するようになりました。改善点と例外については、『リリース ノート』の「JDBC 4.0 サポート」を参照してください。
Oracle 用の WebLogic Type 4 JDBC ドライバは、WebLogic Server 10.3 で非推奨になりました。このドライバは WebLogic Server の次のリリースから削除される予定です。この非推奨のドライバの代わりに、WebLogic Server にも付属している Oracle Thin Driver を使用します。Oracle Thin Driver の詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「WebLogic Server でのサードパーティ JDBC ドライバの使い方」を参照してください。
WebLogic Server に付属している WebLogic Type 4 JDBC ドライバは、DataDirect から提供されています。10.3 より、これらのドライバは DataDirect Version 3.7 に更新されました。JDBC 4.0 のサポートを含む、これらのドライバの変更点については、『リリース ノート』の「更新された WebLogic Type 4 JDBC ドライバ」を参照してください。
WebLogic Server 10.3 では、Oracle 11g および 11g RAC (Real Application Clusters) がサポートされます。
『WebLogic JDBC のコンフィグレーションと管理』の「WebLogic Server での Oracle RAC の使い方」を参照してください。
JDBC サブシステムでは、集中管理されたデバッグへのアクセスおよびロギングを行うために、システム全体を対象とした新しい WebLogic 診断サービスを使用します。
詳細については、『WebLogic 診断フレームワーク コンソール拡張の使い方』を参照してください。
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 モジュール ファイルに自動的に変換します。詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS Interop モジュール」を参照してください。
JMS コンフィグレーションは以下のように変更されています。
永続ダウングレードを許可
] オプションにより、永続ストアがコンフィグレーションされていない JMS サーバに対象指定されている送り先に対して、永続メッセージを送信する場合に、JMS クライアントが例外を取得するかどうかを指定することができる。このオプションは、旧リリースとの下位互換性のために用意されている。
デフォルトでは、このオプションは false
に設定されており、この場合、ストアがコンフィグレーションされていない JMS サーバに永続メッセージを送信するときに、クライアントは例外を受け取ります。このオプションを true
に設定した場合、永続メッセージは非永続メッセージに格下げされますが、送信処理は続行できます。このパラメータは、[ストアを有効化
] パラメータが無効化されている場合 (つまり、false
に設定されている場合) にのみ有効です。
詳細については、『WebLogic Server MBean リファレンス』に記載されている「JMSServerBean」の「AllowsPersistentDowngrade」を参照してください。
一時的なテンプレート
] 属性が作成される。旧リリースでは、デフォルトのテンプレートは提供されていなかった。JMS サーバの [一時的なテンプレート
] 属性を使用して一時的なテンプレートをコンフィグレーションすることもできる。
[一時的な送り先をホスト
] 属性を設定して、一時的な送り先をホストするのに JMS サーバを使用できるかどうかを指定することができます。旧リリースでは、一時的な送り先をホストするのに JMS サーバを使用するには、[一時的なテンプレート
] を設定する必要がありました。
AllowCloseInOnMessage
属性は、デフォルトで有効化されている。詳細については、『WebLogic Server MBean リファレンス』に記載されている「ClientParamsBean
」を参照。DeliveryFailureParamsBean
の getExpirationLoggingPolicy
属性は非推奨となった。『WebLogic JMS のコンフィグレーションと管理』の「メッセージ ライフ サイクルのロギング」の説明に従って、メッセージのライフ サイクル情報をロギングする機能を使用するようアプリケーションを更新することを勧める。getExpirationLoggingPolicy
属性により、アプリケーションに埋め込まれている先頭と末尾のスペースはすべて削除されることに注意する必要がある。
JMS メッセージ ID の形式は、WebLogic Server 9.0 で変更されています。既存のコンシューマ、プロデューサ、およびサーバで使用されている 9.0 より前のバージョンの形式は、引き続きサポートされます。たとえば、既存の JMS コンシューマは、新しい JMS プロデューサまたは JMS サーバから送信されたメッセージであっても、引き続き 9.0 より前のバージョンの形式で確認することができます。
メッセージ負荷のピーク時に仮想メモリを解放するメッセージ ページング機能が、JMS サーバでは常に有効に設定されています。また、ページアウトされたメッセージは、使用しているファイル システムのディレクトリに格納できるため、管理者は専用のメッセージ ページング ストアを作成する必要はありません。ただし、最適なパフォーマンスを維持するには、メッセージのページング先のディレクトリを JMS サーバの永久ストアが使用する以外のディレクトリに指定する必要があります。
詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「メッセージのページングによるメモリの解放」を参照してください。
スレッド管理にはワーク マネージャの概念を使用することをお勧めします。実行キューは、WebLogic Server 9.0 からデフォルトの方法ではなくなりました。アプリケーション用のルールと制約を定義するには、ワーク マネージャを定義して、それを WebLogic Server ドメインに対してグローバルに適用するか、特定のアプリケーション コンポーネントに対して限定的に適用します。詳細については、『サーバ環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」を参照してください。
WebLogic Server 8.1 では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上させるために 8.1 で実行キューを使用していた場合は、アプリケーション ドメインのアップグレード後にも実行キューを引き続き使用できます。アップグレードしたアプリケーションでユーザ定義実行キューを引き続き使用できるようにするために、use81-style-execute-queues
というフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と、実行キューのコンフィグレーションおよび監視に関する詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic 8.1 スレッド プール モデルを有効にする方法」を参照してください。
ドメイン レベルの JTA コンフィグレーション オプションはすべて従来のコンフィグレーション ファイルから保持されています。サーバ レベルでのみ変更があります。WebLogic Server 9.0 から、トランザクション マネージャでは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ レコードを保存します。アップグレード中、アップグレード ウィザードは、トランザクション ログ レコードをデフォルト ストアにコピーします。既存のサーバ コンフィグレーションに基づいて設定されるトランザクション ログ ファイルのプレフィックスは、アップグレード中にトランザクション ログ ファイル (.tlog
) を検索する目的にのみ使用され、アップグレード後は保持されません。
ドメイン全体が 1 つのマシンにある場合、アップグレード ウィザードは、初期ドメイン アップグレードにおいて、すべての管理対象サーバのアップグレードを処理します (トランザクション ログ レコードをデフォルト ストアにコピーします)。管理対象サーバが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバを個別にアップグレードする必要があります。
トランザクション回復サービスの移行の準備においてトランザクション ログ ファイルをネットワーク ストレージに配置した場合、アップグレード後、ログ ファイルの場所は保持されません。このリリースでは、WebLogic Server トランザクション マネージャは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ ファイルを保存します。デフォルトの WebLogic 永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DAT ファイルを現在のデフォルト ストアのデフォルトの場所からデフォルト ストアの新しい場所に手動でコピーする必要があることに注意してください。
トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする必要があります。詳細については、『WebLogic JTA プログラマーズ ガイド』の「ドメイン間トランザクションに対するドメインのコンフィグレーション」を参照してください。
次の節では、セキュリティ機能に関する変更点について説明します。
Windows NT 認証プロバイダは、WebLogic Server 10.0 以降では非推奨となっています。代わりに、それ以外のサポート対象の 1 つまたは複数の認証プロバイダを使用してください。
WebLogic Server 9.2 から、XACML 認可プロバイダおよび XACML ロール マッピング プロバイダという 2 つの新しいセキュリティ プロバイダが含まれています。WebLogic Server の以前のリリースでは、独自のセキュリティ ポリシー言語に基づいた認可プロバイダとロール マッピング プロバイダを使用していました。これらの XACML セキュリティ プロバイダでは、OASIS の標準規格 XACML (eXtensible Access Control Markup Language) 2.0 をサポートしています。これらのプロバイダでは、標準の XACML 2.0 関数、属性、スキーマ要素で表現されたポリシーを、インポート、エクスポート、永続化および実行できます。
WebLogic Server 10.3 を使用して作成した WebLogic ドメインには、XACML プロバイダがデフォルトで含まれています。これら新しい XACML プロバイダは、WebLogic 認可プロバイダ (DefaultAuthorizer) および WebLogic ロール マッピング プロバイダ (DefaultRoleMapper) で作成したポリシーやロールに対して完全な互換性があります。既存の WebLogic ドメインを 10.3 にアップグレードして、現在指定されている認可プロバイダおよびロール マッピング プロバイダ (サード パーティ パートナのプロバイダ、オリジナルの WebLogic 認可プロバイダおよびロール マッピング プロバイダなど) を引き続き使用できます。WebLogic Server 独自のプロバイダを使用している既存ドメインを、必要に応じて XACML プロバイダに移行することもできます (既存ポリシーのバルク インポートも含む)。詳細については、「Oracle WebLogic Server 10g リリース 3 セキュリティ」を参照してください。
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 インスタンスとは互換性がありません。 |
WebLogic Server 10.3 では、SAML 2.0 をサポートするため、SAML 2.0 資格マッピング プロバイダおよび SAML 2.0 ID アサーション プロバイダが追加されました。これらの新しいプロバイダはそれぞれ、次を利用する場合に SAML 2.0 アサーションの生成および消費に使用することができます。
SAML 2.0 Web SSO では、SAML 2.0 資格マッピング プロバイダで生成されるアサーションを消費できるのは、SAML 2.0 ID アサーション プロバイダのみです。これらは SAML 1.1 アサーションと互換性がありません。
WebLogic Server 10.3 Web サービスでは SAML トークン プロファイル 1.1 がサポートされます。また、SAML 2.0 および SAML 1.1 アサーションがサポートされ、SAML トークン プロファイル 1.0 との下位互換性も保たれます。SAML トークンの Web サービスに対するコンフィグレーションは、適切な WS-SecurityPolicy アサーションを利用して行います。
注意 : | SAML Token Profile 1.1 は WS-SecurityPolicy を通じてのみサポートされます。以前の「WLS 9.2 セキュリティ ポリシー」では、SAML Token Profile 1.0/SAML 1.1 のみがサポートされます。 |
WebLogic Server 10.3 では、以下のセキュリティ プロバイダで使用されるデータストアとして、外部 RDBMS を使用できるようになりました。
このデータストアは RDBMS セキュリティ ストアと呼ばれ、クラスタ内など、ドメイン内に複数の WebLogic Server インスタンスがある環境で SAML 2.0 サービスを使用する際に使用することをお勧めします。ドメイン内に RDBMS セキュリティ ストアがコンフィグレーションされている場合、セキュリティ レルム内に作成されている上記のいずれかのセキュリティ プロバイダのインスタンスは、自動的に RDBMS セキュリティ ストアのみをデータストアとして使用し、組み込み LDAP サーバは使用しません。ドメイン内にコンフィグレーションされている上記のリスト以外の WebLogic セキュリティ プロバイダは、それぞれのデフォルト ストアを使用します。たとえば、WebLogic 認証プロバイダは組み込み LDAP サーバを使用します。
RDBMS セキュリティ ストアを使用するには、まず、ドメインを作成して外部 RDBMS サーバをコンフィグレーションします。ドメインを起動する前に、RDBMS セキュリティ ストアで必要になるテーブルをデータストア内に作成します。WebLogic Server インストール ディレクトリには、サポート対象のデータベースごとに、これらのテーブルを作成する一連の SQL スクリプトが含まれています。
RDBMS セキュリティ ストアを使用したいドメインが作成済みであっても、新しいドメインを作成し、そのドメインに既存のセキュリティ レルムを移行してください。既存のドメインには RDBMS セキュリティ ストアを組み込まないでください。詳細については、『WebLogic Server のセキュリティ』の「RDBMS セキュリティ ストアの管理」を参照してください。
WebLogic Server 10.3 ではパスワード検証プロバイダが提供されており、以下のいずれかの認証プロバイダで、コンフィグレーション可能なパスワードの構成ルール セットを適用するようにコンフィグレーションできます。
パスワード検証プロバイダでコンフィグレーションされている認証プロバイダを使用してパスワードを作成または変更する場合、パスワードは構成ルール セットと照合されて自動的に検証されます。パスワード構成ルールはコンフィグレーション可能であり、最小パスワード長、必要な英数字の最小文字数、必要な英数字以外の文字数などを制御することができます。
表 B-2 に、WebLogic Server 9.0 におけるセキュリティ MBean の変更点を示します。
|
|
|
権限のないアクセスからパスワードなどの重要なデータを保護するために、コンフィグレーション MBean のいくつかの属性は暗号化されます。属性の値は、ドメインのコンフィグレーション ファイルに暗号化された文字列として保持されます。メモリ内の値が暗号化されたバイト配列として保存されるため、パスワードがメモリから盗用されるリスクが軽減され、セキュリティがさらに強化されます。
9.0 より前のリリースでは、クリア テキスト形式または暗号化形式で、パスワードなどの暗号化する属性を config.xml
ファイルで指定することができました。この場合、WebLogic Server は、次に起動され、そのファイルに書き込むときに情報を暗号化します。
WebLogic Server 9.0 から、プロダクション モードのときは、パスワードなどの暗号化する属性はコンフィグレーション ファイルで暗号化されなければなりません。開発モードのときは、パスワードなどの暗号化する属性はクリア テキスト形式または暗号化形式のどちらでもかまいません。
次のように、weblogic.security.Encrypt
コマンドライン ユーティリティを使用してパスワードを暗号化することができます。
java weblogic.security.Encrypt
ここで、パスワードを入力するよう求められます。パスワードを入力すると、暗号化されたバージョンが返されます。次に、暗号化されたパスワードを適切なファイルにコピーします。
このユーティリティの対象は、コンフィグレーション ファイルのパスワードだけではありません。これは、記述子ファイル (JDBC または JMS 記述子など) およびデプロイメント プランでパスワードを暗号化する場合にも使用できます。詳細については、『コマンド リファレンス』の「Oracle WebLogic Server Java ユーティリティの使い方」に記載されている「encrypt」を参照してください。
WebLogic Server 10.3 のインスタンスが HTTP リクエストに応答するとき、HTTP 応答ヘッダにはデフォルトで、WebLogic Server のサーバ名およびバージョン番号は含まれません。この動作は、WebLogic Server 9.0 より前のリリースとは異なります。
HTTP リクエストに応答するときにサーバ名とバージョン番号を HTTP 応答ヘッダに含めるには、Administration Console で WebLogic Server の [Send Server Header を有効化] 属性を有効にします。この属性は、[サーバ|ServerName|プロトコル|HTTP] タブの [詳細オプション] セクションにあります。この機能を有効にすると、攻撃者が WebLogic Server の特定のバージョンの脆弱性についての知識がある場合、これによりセキュリティ リスクが発生する可能性があります。
セキュリティの確保の詳細については、『プロダクション環境の保護』の「プロダクション環境のセキュリティの確保」に記載されている「WebLogic Security サービスのセキュリティ」を参照してください。
9.0 より前のリリースの WebLogic Server では、MBeanHome
への匿名アクセスがデフォルトで可能でした。WebLogic Server 9.0 以降では、セキュリティが強化されているため、MBeanHome
への匿名アクセスはできなくなりました。
これは推奨されませんが、サーバを起動するときに次のフラグを指定することにより、匿名アクセスを再び有効にすることができます。
-Dweblogic.management.anonymousAdminLookupEnabled
WebLogic Server 9.0 から、Web サービスにおけるメッセージレベルのセキュリティが強化され、標準ベースの Web Services Policy Framework (WS-Policy) を使用するようになりました。WS-Policy では、XML Web サービス ベースのシステム内にあるエンティティについての機能、要件、一般的な特性を表現する、柔軟で拡張性のある文法を使用できます。WS-Policy の詳細については、『WebLogic 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
を参照してください。
WebLogic Server 8.1 Web サービスは 10.3 でも実行できますが、8.1 Web サービスの実行時エンジンは 9.0 以降では非推奨となっています。
9.2 から 10.0 へ、または 10.0 から 10.3 へ Web サービスをアップグレードする必要はありません。
WebLogic Server 7.0 Web サービスは、10.3 で実行するには、少なくとも 8.1 にアップグレードする必要があります。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「WebLogic Web サービスのアップグレード」を参照してください。
8.1 にアップグレードされた 7.0 Web サービスを含む、すべての 8.1 Web サービスを 10.3 にアップグレードすることをお勧めします。
既存の 8.1 Web サービスの 10.3 へのアップグレードについては、『JAX-RPC を使用した WebLogic Web サービスの開始』の「WebLogic Web サービスの旧リリースから 10g リリース 3 へのアップグレード」を参照してください。
注意 : | 「Web サービスにおけるメッセージレベルのセキュリティ」も参照してください。 |
以下の節では、WebLogic Server 10.3 における Web アプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。
WebLogic Server 10.3 から非推奨となった、またはサポートされていない Web アプリケーション機能については、『リリース ノート』の「非推奨になった機能」を参照してください。
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 に保持されている必要があります。
詳細については、『WebLogic Security プログラマーズ ガイド』の「リソースが非セキュアな場合の BASIC 認証について」を参照してください。
WebLogic Server 10.3 では、この節および『Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「jsp-descriptor
」で説明されているように、WebLogic Server 9.2 以前のバージョンに対する下位互換性が jsp-descriptor
要素内の backward-compatible
要素を通じてサポートされます。
JSP 2.1 は WebLogic Server 10.0 からサポートされています。Weblogic Server 10.3 では、Web アプリケーションのバージョン (バージョン 2.4 または 2.5) と backward-compatible
要素の設定に応じて、JSP 2.0 もサポートされます。
バッファのサフィックスの設定およびサーブレット 2.5 パッケージの暗黙的なインポートについては、『Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「下位互換性フラグ」を参照してください。
「下位互換性フラグ」で説明されているように、JSP 2.0 は WebLogic Server 9.0 以降でサポートされています。JSP 2.0 のサポートに応じて、JSP の動作は以下のように変更されています。
IllegalStateException
が送出される。PageContext.getAttribute(name, PageContext.SESSION_SCOPE)
この例外は、このようなエラーが重要な問題でない場合は、捕捉して無視することができます。
JspWriterImpl
が printline
関数ごとに \n
を System.getProperty("line.separator")
に置き換えるようになった。この置換により、以下に該当する JSP で問題が発生する。<%@ page import="com.foo.bar.*" %>
<%@ page import="com.foo.xyz.*" %>
...
\r\n
が出力される。
Internet Explorer で表示される場合、各 page ディレクティブが空の \r\n
を出力し、XML 宣言 (<?xml version="1.0" encoding="iso-8859-1"?>
) が新しい行の後ろに表示されます。Internet Explorer は、宣言が検出されず、ページはコンパイルできるが表示できないことを通知するエラー メッセージを表示します。
JspWriterImpl
に対する変更により生じた問題を解決するには、以下のタスクのどちらかまたは両方を実行します。
<%@ page import="com.foo.bar.*, com.foo.baz.*"
contentType="text/html" pageEncoding="UTF-8" errorPage="Error.jsp" %>
<param name>
タグで実行時の式の値を使用できなくなった。以下に例を示す。 <jsp:param name="<%= AdminActions.RETURN_LINK %>
" value="<%= returnlink %>" />
「アップグレード オプションの選択」で説明されているように、ドメインのアップグレード中に [下位互換性フラグを設定しない] アップグレード オプションを無効にするか、次のように 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
でダウンロード可能) では、マッピングの定義に次の構文を使用します。
これらの変更により、次の HttpServletRequest
メソッドの動作に変化が生じます。
動作の変更を説明するために、例として /abc/def.html
というリクエストが ServletA に解決される場合を考えます。
確実に null でないパス情報が返されるようにするには、/
(フォワード スラッシュ) のサーブレット マッピング文字列が出現するすべての箇所を /*
に置換します。
WebLogic Server 9.0 からは、XML のサポートが次のように変更されています。
weblogic.apache.xerces.*
) は 9.0 より非推奨となりました。
デフォルトで使用される XML パーサを Administration Console で修正することができます。XML パーサのコンフィグレーションについては、『WebLogic XML プログラマーズ ガイド』の「WebLogic Server バージョン 8.1 と 9.1 のデフォルト パーサの違い」を参照してください。
setAttribute
メソッドと getAttribute
メソッドを使用してサーブレット内から XML ドキュメントを解析することができなくなった。具体的には、9.0 以降、weblogic.servlet.XMLParsingHelper
と呼ばれる WebLogic Server のサーブレット フィルタ (デフォルトではすべての WebLogic Server インスタンスにデプロイされる) を Web アプリケーションの一部としてコンフィグレーションする必要がある。詳細については、『WebLogic XML プログラマーズ ガイド』の「サーブレットでの XML ドキュメントの解析」を参照。
WebLogic Server 9.0 から、XMLBean 実装は内部 BEA ライブラリ (com.bea.xml
) から Apache オープン ソース プロジェクト (org.apache.xmlbeans
) に移動されています。
WebLogic Server 8.1 のアプリケーションで XMLBeans を使用していた場合は、次の手順を実行する必要があります。
WebLogic Server 9.0 以降の XMLQuery (XQuery) 実装は、次の仕様に準拠しています。
http://www.w3.org/TR/2004/WD-xpath-datamodel-20040723
)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()
のメソッド呼び出しを必要に応じて確認および変更してください。
import org.apache.xmlbeans.impl.store.Path;
XmlObject xo = ?
xo.selectPath(".//c",(new XmlOptions()).put(Path._forceXqr12002ForXpathXQuery)
);
注意 : | 2002 XQuery エンジンは、WebLogic Server 9.0 以降では非推奨ですが、下位互換性のために残されています。このパラメータを指定した場合のみ 2002 XQuery エンジンが使用され、それ以外の場合は 2004 XQuery エンジンがデフォルトで使用されます。 |
9.0 から、XMLCursor.moveXML()
の動作が変更されています。8.1 では、移動されたフラグメント内にあったカーソルは、元のドキュメントに残ります。9.0 以降では、カーソルはフラグメントと共に移動します。
MBean の階層構造に加えられた変更により、9.2 より前のコンフィグレーションおよび管理スクリプト (WLST、wlconfig
、weblogic.Admin
、Ant など) が 10.3 で動作する保証はなくなりました。WebLogic Server 10.3 からの新しい機能を利用するようスクリプトを更新することをお勧めします。MBean 階層構造の新機能と変更点の詳細については、『リリース ノート』の「WebLogic Server の新機能」を参照してください。
アプリケーション インフラストラクチャのアップグレードと非推奨となったスクリプト ツールの詳細については、「手順 1 : アプリケーション インフラストラクチャのアップグレード」を参照してください。
この節では、リリース 9.0 より変更された WebLogic Server 環境におけるデプロイメント記述子の使用方法について説明します。
@ejbgen:relation
で cmr-field
が定義されている場合に、@ejbgen:cmr-field
というタグの付いたメソッドが Bean クラスになければ、エラーが返されます。注意 : | ejbc は WebLogic Server 9.0 から非推奨となりました。代わりに appc を使用してください。詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「appc リファレンス」を参照してください。 |
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
デプロイメント記述子の両方またはどちらかを定義していることを確認してください。
デプロイメント記述子の詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server 9.0 から非推奨となり、代わりにアプリケーションはアプリケーション ライフサイクル イベントに応答するようになりました。ドメイン レベルのアプリケーション スコープの起動クラスと停止クラスの代わりにライフサイクル イベントを使用するようアプリケーション環境を更新することをお勧めします。詳細については、『WebLogic Server アプリケーションの開発』の「アプリケーション ライフサイクル イベントのプログラミング」を参照してください。
以降の節では、Administration Console に対する変更点について説明します。
WebLogic Server 10.3 では、Administration Console の動作をコンフィグレーションするためのオプションが新たに追加され、以下のことを実行できるようになりました。
詳細については、『リリース ノート』の「WebLogic Server の新機能」を参照してください。
WebLogic Server バージョン 9.0 の Administration Console は、WebLogic Portal のフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。アーキテクチャが新しくなったため、Administration Console を拡張する手順も新しくなりました。9.0 以前の WebLogic Server のリリース用に構築された WebLogic Administration Console の拡張は、新しいインフラストラクチャでは機能しません。Administration Console の拡張の詳細については、『Administration Console の拡張』を参照してください。
WebLogic Server バージョン 9.2 では、コンソール拡張が以下のように変更されています。
<%@ 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
ファイルでは、これらの URI を、インストールされている WebLogic Server 内部のタグ ライブラリにマップします。このマッピングにより、JSP を変更する必要なく、インストール ディレクトリが再編成されます。
古いパス名構文を使用して Apache Struts、Apache Beehive、または JSTL タグ ライブラリをインポートするすべての Administration Console 拡張機能では、パス名をすべて新しい URI に更新する必要があります。
WebLogic Server のコンソール拡張機能タグ ライブラリ (console-html.tld) の URI は変更されていません (/WEB-INF/console-html.tld
)。
詳細については、『Administration Console の拡張』の「JSP テンプレートとタグ ライブラリ」を参照してください。
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 に、非推奨となった、またはサポートされなくなったリソース アダプタのコンフィグレーション設定を示します。新機能と変更点の詳細については、『リリース ノート』の「WebLogic Server の新機能」を参照してください。
WLEC は、WebLogic Server 8.1 で非推奨となりました。WLEC ユーザは、『Oracle WebLogic Tuxedo Connector 移行ガイド』の説明に従って、アプリケーションを WebLogic Tuxedo Connector に移行する必要があります。
WebLogic Server 10.0 では、SNMPAgentMBean MBean の MibDataRefreshInterval 属性と ServerStatusCheckIntervalFactor 属性は非推奨となったため無視されます。
表 B-4 のコンフィグレーション フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル モードでのアップグレード」で説明されているように、アップグレード中に [下位互換性フラグを設定しない] オプションを選択して無効にしない限り、下位互換性をサポートするためデフォルトで設定されます。
|
||
|
非推奨となった API および削除された API の詳細については、『リリース ノート』の「非推奨になった機能」を参照してください。
![]() ![]() ![]() |