WebLogic のアプリケーション環境のアップグレード
|
 |
 |
|
この節では、WebLogic Server 9.1 にアップグレードする前に検討する必要がある、互換性に関する重要な情報について説明します。
注意 : 『BEA WebLogic Server 9.1 の互換性について』(http://edocs.beasys.co.jp/e-docs/wls/docs91/compatibility/compatibility.html) も参照してください。
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.1 でも使用できます。
weblogic.management.MBeanHome のみを使用する場合は、アップグレードしなくても WebLogic Server 9.1 インスタンスで実行できる weblogic.management.MBeanHome のみを使用する (JDK MBeanServer インタフェースを使用しない)-Djmx.serial.form=1.0 を含める必要があるこの起動オプションを含めると、JVM がオブジェクトをシリアライズするときに JMX 1.0 のクラス記述が使用されるようになります。このオプションは、JMX 1.0 クライアントが標準の JDK クラスを使用して JMX 1.2 エージェントと通信する場合に必要です。
JMX クライアントを WebLogic Server 9.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 プログラミング モデルを使用するよう更新することをお勧めします。詳細については、『JMX によるカスタム管理ユーティリティの開発』の「WebLogic Server MBean について」(http://edocs.beasys.co.jp/e-docs/wls/docs91/jmx/understandWLS.html) を参照してください。
コンフィグレーション属性には、「動的なもの」と「動的でないもの」があります。.
WebLogic Server 9.0 から導入された変更管理プロセスにより、コンフィグレーションの変更をドメイン全体にわたってセキュアで確実に適用できます。バッチ変更メカニズムにより、動的な変更と動的でない変更が混在する場合に、動的な変更の適用が制御されます。具体的には、コンフィグレーションされているサーバまたはシステム リソースが動的でない変更の影響を受ける場合、サーバまたはシステム リソースが再起動されるまで、現在または将来のバッチにおいても、他の変更 (動的な変更も含む) は有効になりません。この場合、システムの整合性を維持し、将来の変更の適用を可能にするため、バッチ変更が完了すると同時にエンティティを再起動することをお勧めします。
コンフィグレーション スクリプトをテストして、動的でない変更が適用されているかどうか確認し、適用されている場合はサーバを再起動する必要があります。変更が動的でなく、サーバの再起動が必要かどうかを判断するには、次の手順に従います。
http://edocs.beasys.co.jp/e-docs/wls/docs91/intro/console.html) の説明に従って、Administration Console のチェンジ センタに掲載されている変更リストを表示する。isRestartRequired または showChanges のどちらかの WLST コマンド を使用する。詳細については、『WebLogic Scripting Tool ガイド』の「WLST コマンドおよび変数リファレンス」(http://edocs.beasys.co.jp/e-docs/wls/docs91/config_scripting/reference.html) を参照。どのセキュリティ属性が動的であるか動的でないかを確認するには、『WebLogic Server のセキュリティ』の「セキュリティ コンフィグレーション MBean」(http://edocs.beasys.co.jp/e-docs/wls/docs91/secmanage/mbeans.html) を参照してください。
詳細については、『ドメインのコンフィグレーションについて』の「コンフィグレーションの変更の管理」(http://edocs.beasys.co.jp/e-docs/wls/docs91/domain_config/changes.html) を参照してください。
JDBC のコンフィグレーションを簡素化し、コンフィグレーション エラーが発生する可能性を低くするため、WebLogic Server 9.0 からは、使用する JDBC リソースのタイプが少なくなっています。JDBC 接続プールをコンフィグレーションしてから、その接続プールを指し、JNDI ツリーにバインドされるデータ ソースまたは tx データ ソースをコンフィグレーションする代わりに、接続プールを包含するデータ ソースをコンフィグレーションできるようになりました。簡素化された JDBC リソースのコンフィグレーションの詳細については、『Configuring and Managing WebLogic JDBC』 の「Simplified JDBC Resource Configuration」(http://edocs.beasys.co.jp/e-docs/wls/docs91/jdbc_admin/jdbc_intro.html#simple_res_config) を参照してください。
以下の節で説明するように、WebLogic アップグレード ウィザードは、JDBC データ ソース、接続プール、マルチプール、およびデータ ソース ファクトリを WebLogic Server 9.1 仕様に自動的に変換します。
注意 : アップグレードしたそれぞれの JDBC モジュールに内部プロパティ セクションがあります。WebLogic Server では、下位互換性に対応するため、データ ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBC データ ソース ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。
非推奨となった JDBC 機能、メソッド、インタフェース、および MBean については、『リリース ノート』の「非推奨になった JDBC の機能、メソッド、インタフェース、および MBean」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#deprecated_jdbc_features) を参照してください。
アップグレード ウィザードは、従来の JDBC データ ソース/接続プールの組み合わせを 2 つのデータ ソース システム リソース モジュールに変換します (1 つはデータ ソース用、もう 1 つは接続プール用)。
注意 : ドメインのアップグレードの 1 つのプロセスとして変換されるデータ ソースのみが、その接続プールを定義するもう 1 つのデータ ソースを参照することができます。それ以外のデータ ソースは、それぞれ独自のデータベース接続プールを保有しています。
アップグレード中、アップグレード ウィザードは、データ ソースの GlobalTransactionsProtocol パラメータを、次の表に示すように、変換するデータ ソースのタイプ (tx かどうか) と対応する接続プールで使用されるドライバのタイプに応じて設定します。
|
|
|||
EmulateTwoPhaseCommit トランザクション プロトコルではなく LoggingLastResource (LLR) トランザクション プロトコルを使用するほうが、パフォーマンス上のメリットがあります。詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」 http://edocs.beasys.co.jp/e-docs/wls/docs91/jdbc_admin/jdbc_datasources.html#llr) を参照してください。アップグレード ウィザードは、マルチプールを、データ ソース間のロード バランシングとフェイルオーバーを実現するデータ ソース オブジェクトのもう 1 つのインスタンスであるマルチ データ ソースに変換します。
データ ソース ファクトリは、このリリースでは非推奨となっており、下位互換性の維持だけを目的として含まれています。データ ソース ファクトリの変換は不要です。
WebLogic Server 9.0 では、JMS コンフィグレーションはモジュールとして格納されます。これは、新しい weblogic-jmsmd.xsd スキーマに準拠する XML ドキュメントで定義されます。JMS リソースのモジュール式デプロイメントにより、アプリケーションと JMS コンフィグレーションを別の環境にプロモートできます。たとえば、アプリケーションとそれに必要な JMS コンフィグレーションを、ERA ファイルを開くことなく、またJMS を手動で再コンフィグレーションすることなく、テスト環境からプロダクション環境にプロモートできます。
http://edocs.beasys.co.jp/e-docs/wls/docs91/jms_admin/intro.html#WhatsNewJMS)http://edocs.beasys.co.jp/e-docs/wls/docs91/jms_admin/overview.html)http://edocs.beasys.co.jp/e-docs/wls/docs91/deployment/deploy.html#deploy_resources)WebLogic アップグレード ウィザードは、9.0 より前のバージョンの JMS リソースを、ドメインの config\jms ディレクトリにコピーされる interop-jms.xml という名前の JMS Interop モジュール ファイルに自動的に変換します。詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS Interop モジュール」(http://edocs.beasys.co.jp/e-docs/wls/docs91/jms_admin/overview.html#jms_interop_modules) を参照してください。
JMS コンフィグレーションは以下のように変更されています。
永続ダウングレードを許可] オプションにより、永続ストアがコンフィグレーションされていない JMS サーバで対象指定されている送り先に対して、永続メッセージを送信する場合に、JMS クライアントが例外を取得するかどうかを指定することができる。このオプションは、旧リリースとの下位互換性のために用意されている。 デフォルトでは、このオプションは false に設定されており、この場合、ストアがコンフィグレーションされていない JMS サーバに永続メッセージを送信するときに、クライアントは例外を受け取ります。このオプションを true に設定した場合、永続メッセージは非永続メッセージに格下げされますが、送信処理は続行できます。このパラメータは、[ストアを有効化] パラメータが無効化されている場合 (つまり、false に設定されている場合) にのみ有効です。
詳細については、『WebLogic Server MBean リファレンス』に記載されている「JMSServerBean」の「AllowsPersistentDowngrade」(http://edocs.beasys.co.jp/e-docs/wls/docs91/wlsmbeanref/mbeans/JMSServerMBean.html#AllowsPersistentDowngrade) を参照してください。
一時的なテンプレート] 属性が作成される。旧リリースでは、デフォルトのテンプレートは提供されていなかった。JMS サーバの [一時的なテンプレート] 属性を使用して一時的なテンプレートをコンフィグレーションすることもできる。[一時的な送り先をホスト] 属性を設定して、一時的な送り先をホストするのに JMS サーバを使用できるかどうかを指定することができます。旧リリースでは、一時的な送り先をホストするのに JMS サーバを使用するには、[一時的なテンプレート] を設定する必要がありました。
http://edocs.beasys.co.jp/e-docs/wls/docs91/jms_admin/advance_config.html#jms_distributed_destination_create) を参照。AllowCloseInOnMessage 属性は、デフォルトで有効化されている。詳細については、『WebLogic Server MBean リファレンス』の「ClientParamsBean」(http://edocs.beasys.co.jp/e-docs/wls/docs91/wlsmbeanref/mbeans/ClientParamsBean.html) を参照。DeliveryFailureParamsBean の getExpirationLoggingPolicy 属性は非推奨となった。『WebLogic JMS のコンフィグレーションと管理』の「メッセージ ライフ サイクルのロギング」(http://edocs.beasys.co.jp/e-docs/wls/docs91/jms_admin/troubleshoot.html#message_life_cycle_logging) の説明に従って、メッセージのライフサイクル情報をロギングする機能を使用するようアプリケーションを更新することを勧める。getExpirationLoggingPolicy 属性により、アプリケーションに埋め込まれている先頭と末尾のスペースはすべて削除されることに注意する必要がある。
JMS メッセージ ID の形式は、WebLogic Server 9.0 で変更されています。既存のコンシューマ、プロデューサ、およびサーバで使用されている 9.0 より前のバージョンの形式は、引き続きサポートされます。たとえば、既存の JMS コンシューマは、新しい JMS プロデューサまたは JMS サーバから送信されたメッセージであっても、引き続き 9.0 より前のバージョンの形式で確認することができます。
スレッド管理にはワーク マネージャの概念を使用することをお勧めします。実行キューは、WebLogic Server 9.0 からデフォルトの方法ではなくなりました。アプリケーション用のルールと制約を定義するには、ワーク マネージャを定義して、それを WebLogic Server ドメインに対してグローバルに適用するか、特定のアプリケーション コンポーネントに対して限定的に適用します。詳細については、『WebLogic Server 環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」(http://edocs.beasys.co.jp/e-docs/wls/docs91/config_wls/self_tuned.html) を参照してください。
WebLogic Server 8.1 では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上するために 8.1 で実行キューを使用していた場合は、アプリケーション ドメインのアップグレード後にも実行キューを引き続き使用できます。アップグレードしたアプリケーションでユーザ定義実行キューを引き続き使用できるようにするために、Use81StyleExecuteQueues というフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と実行キューの監視に関する詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「ユーザ定義の実行キュー」(http://edocs.beasys.co.jp/e-docs/wls/docs91/perform/appb_queues.html) を参照してください。
ドメイン レベルの JTA コンフィグレーション オプションはすべて従来のコンフィグレーション ファイルから保持されています。サーバ レベルでのみ変更があります。WebLogic Server 9.0 から、トランザクション マネージャでは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ レコードを保存します。アップグレード中、アップグレード ウィザードは、トランザクション ログ レコードをデフォルト ストアにコピーします。既存のサーバ コンフィグレーションに基づいて設定されるトランザクション ログ ファイルのプレフィックスは、アップグレード中にトランザクション ログ ファイル (.tlog) を検索する目的にのみ使用され、アップグレード後は保持されません。
ドメイン全体が 1 つのマシンにある場合、アップグレード ウィザードは、初期ドメイン アップグレードにおいて、すべての管理対象サーバのアップグレードを処理します (トランザクション ログ レコードをデフォルト ストアにコピーします)。管理対象サーバが複数の異なるマシンにある場合は、「アプリケーション環境のアップグレード」の説明に従って、各管理対象サーバを個別にアップグレードする必要があります。
トランザクション回復サービスの移行の準備においてトランザクション ログ ファイルをネットワーク ストレージに配置した場合、アップグレード後、 ログ ファイルの場所は保持されません。WebLogic Server 9.0 では、WebLogic Server トランザクション マネージャは、デフォルトの WebLogic 永続ストアを使用してトランザクション ログ ファイルを保存します。デフォルトの WebLogic 永続ストアの場所をネットワーク上の場所に移動することによっても、同じ結果が得られます。DAT ファイルを現在のデフォルト ストアのデフォルトの場所からデフォルト ストアの新しい場所に手動でコピーする必要があることに注意してください。
トランザクションが複数のドメインにまたがる場合は、ドメイン間トランザクションが可能なようにドメインをコンフィグレーションする必要があります。詳細については、『WebLogic JTA プログラマーズ ガイド』の「ドメイン間トランザクションに対するドメインのコンフィグレーション」(http://edocs.beasys.co.jp/e-docs/wls/docs91/jta/trxcon.html#interop) を参照してください。
次の節では、セキュリティ機能に関する変更点について説明します。
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 ドメインを 9.1 にアップグレードして、現在指定されている認可プロバイダおよびロール マッピング プロバイダ (サードパーティ パートナーのプロバイダ、オリジナルの WebLogic 認可プロバイダおよびロール マッピング プロバイダなど) を引き続き使用できます。WebLogic Server 独自のプロバイダを使用している既存ドメインを、必要に応じて XACML プロバイダに移行することもできます (既存ポリシーのバルク インポートも含む)。詳細については、『BEA WebLogic Server 9.1 セキュリティ』(http://edocs.beasys.co.jp/e-docs/wls/docs91/security.html) を参照してください。
WebLogic Server 9.1 には、SAML 資格マッピング プロバイダおよび SAML ID アサーション プロバイダの新バージョンが追加されています。SAML 資格マッピング V1 プロバイダおよび SAML ID アサーション V1 プロバイダは非推奨となりました。SAML 資格マッピング プロバイダおよび SAML ID アサーション プロバイダの各 V2 バージョンを使用してください。
各プロバイダのバージョン番号は加算されて V2 になっていますが、新しい SAML セキュリティ プロバイダにも、V1 プロバイダと同じ SAML 1.1 標準が実装されています。
次の表に、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 記述子など) およびデプロイメント プランでパスワードを暗号化するのにも使用できます。詳細については、『WebLogic Server コマンド リファレンス』の「WebLogic Server Java ユーティリティの使い方」に記載されている「encrypt」(http://edocs.beasys.co.jp/e-docs/wls/docs90/admin_ref/utils.html) を参照してください。
デフォルトでは、WebLogic Server 9.0 のインスタンスが HTTP リクエストに応答するとき、HTTP 応答ヘッダには、WebLogic Server のサーバ名およびバージョン番号は含まれません。この動作は、WebLogic Server 9.0 以前のリリースとは異なります。
HTTP リクエストに応答するときにサーバ名とバージョン番号を HTTP 応答ヘッダに含めるには、Administration Console で WebLogic Server の [Send Server Header を有効化] 属性を有効にします。この属性は、[サーバ｜ServerName｜プロトコル｜HTTP] タブの [詳細オプション] セクションにあります。
セキュリティの確保の詳細については、『プロダクション環境のセキュリティ』の「プロダクション環境のセキュリティの確保」に記載されている「WebLogic セキュリティ サービスのセキュリティ」(http://edocs.beasys.co.jp/e-docs/wls/docs91/lockdown/practices.html) を参照してください。
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-Policy ファイルの使い方の概要」(http://edocs.beasys.co.jp/e-docs/wls/docs90/webserv/security.html#ws_policy) を参照してください。
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 サービスは 9.1 でも実行できますが、8.1 Web サービスの実行時エンジンは 9.0 以降では非推奨となっています。
WebLogic Server 6.1 または 7.0 Web サービスは、9.1 で実行するには、8.1 にアップグレードする必要があります。詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「WebLogic Web サービスのアップグレード」(http://edocs.beasys.co.jp/e-docs/wls/docs81/webserv/migrate.html) を参照してください。
8.1 にアップグレードされた 6.1 および 7.0 Web サービスを含む、すべての 8.1 Web サービスを 9.1 にアップグレードすることをお勧めします。既存の 8.1 Web サービスのアップグレードについては、『WebLogic Web サービス プログラマーズ ガイド』の「8.1 Web サービスの 9.1 へのアップグレード」(http://edocs.beasys.co.jp/e-docs/wls/docs91/webserv/upgrade.html) を参照してください。
注意 : 「Web サービスにおけるメッセージレベルのセキュリティ」も参照してください。
以下の節では、WebLogic Server 9.0 における Web アプリケーション、JSP、およびサーブレットの重要な互換性に関する情報について説明します。
WebLogic Server 9.0 から非推奨となった、またはサポートされていない Web アプリケーション機能については、『リリース ノート』の「非推奨のおよび廃止された Web アプリケーションの機能」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#deprecated_and_obsolete_web_application_features) を参照してください。
JSP 2.0 は WebLogic Server 9.0 からサポートされています。具体的な詳細については、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』(http://edocs.beasys.co.jp/e-docs/wls/docs91/webapp/index.html) を参照してください。
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 が出力される。<%@ 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 でダウンロード可能) では、マッピングの定義に次の構文を使用します。
/ (フォワード スラッシュ) 文字だけが含まれるサーブレット パス文字列は、アプリケーションのデフォルト サーブレットを表します。サーブレット パスは、リクエスト URI からコンテキスト パスを削除したパス (この場合は null) に解決されます。* (アスタリスク) で始まる文字列は、拡張子マッピングを指定します。これらの変更により、次の HttpServletRequest メソッドの動作に変化が生じます。
動作の変更を説明するために、例として /abc/def.html というリクエストが ServletA に解決される場合を考えます。
/ が ServletA にマップされると、servletPath="abc/def.html" および pathInfo=null になります。/* が ServletA にマップされると、servletPath="" および pathInfo="abc/def.html" になります。確実に null でないパス情報が返されるようにするには、/ (フォワード スラッシュ) のサーブレット マッピング文字列が出現するすべての箇所を /* に置換します。
WebLogic Server 9.0 からは、XML のサポートが次のように変更されています。
weblogic.apache.xerces.*) は、9.0 からは非推奨となっている。デフォルトで使用される XML パーサを Administration Console で修正することができます。XML パーサのコンフィグレーションについては、『WebLogic XML プログラマーズ ガイド』の「WebLogic Server バージョン 8.1 と 9.1 のデフォルト パーサの違い」(http://edocs.beasys.co.jp/e-docs/wls/docs91/xml/overview.html#deprecated_xerces) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs91/xml/stax.html) を参照。 setAttribute メソッドと getAttribute メソッドを使用してサーブレット内から XML ドキュメントを解析することができなくなった。具体的には、9.0 以降、weblogic.servlet.XMLParsingHelper と呼ばれる WebLogic Server のサーブレット フィルタ (デフォルトではすべての WebLogic Server インスタンスにデプロイされる) を Web アプリケーションの一部としてコンフィグレーションする必要がある。詳細については、『WebLogic XML プログラマーズ ガイド』の「サーブレットでの XML ドキュメントの解析」(http://edocs.beasys.co.jp/e-docs/wls/docs91/xml/programming.html#apps005) を参照。
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 は、9.1 でも同じように動作します。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 の階層構造に加えられた変更により、既存のコンフィグレーションおよび管理スクリプト (WLST、wlconfig、weblogic.Admin、Ant など) が 9.1 で動作する保証はなくなりました。WebLogic Server 9.0 からの新しい機能を利用するようスクリプトを変更することをお勧めします。MBean 階層構造の新機能と変更点の詳細については、『リリース ノート』の「WebLogic Server 9.1 の新機能」(http://edocs.beasys.co.jp/e-docs/wls/docs91/notes/new.html) を参照してください。
アプリケーション インフラストラクチャのアップグレードと非推奨となったスクリプト ツールの詳細については、「手順 1 : アプリケーション インフラストラクチャのアップグレード」を参照してください。
WebLogic Server 9.0 から非推奨となった、またはサポートされなくなったアプリケーション デプロイメント機能については、『リリース ノート』の「非推奨のサポートされないデプロイメント機能」(http://edocs.beasys.co.jp/e-docs/wls/docs90/notes/new.html#deprecated_and_unsupported_deployment_features) を参照してください。
この節では、リリース 9.0 より変更された WebLogic Server 環境におけるデプロイメント記述子の使用方法について説明します。
@ejbgen:relation で cmr-field が定義されている場合に、@ejbgen:cmr-field というタグの付いたメソッドが Bean クラスになければ、エラーが返されます。注意 : ejbc は WebLogic Server 9.0 から非推奨となりました。代わりに appc を使用してください。詳細については、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「appc リファレンス」(http://edocs.beasys.co.jp/e-docs/wls/docs91/ejb/appc_ejbc.html) を参照してください。
META-INF\application.xml デプロイメント記述子がアプリケーションの一部として定義されているかどうかに関係なく、正常にデプロイされます。<Application Deployed="true" Name="SessionBeanLifeCycleBean"</Application>
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"/>
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.
ドメインをアップグレードするとき、デプロイされたアプリケーションが適切な J2EE アプリケーション形式に準拠していることを確認してください。たとえば、必要に応じて、アプリケーションが META-INF\application.xml デプロイメント記述子と META-INF\weblogic-application.xml デプロイメント記述子の両方またはどちらかを定義していることを確認してください。
デプロイメント記述子の詳細については、『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」(http://edocs.beasys.co.jp/e-docs/wls/docs91/programming/app_xml.html) を参照してください。
http://edocs.beasys.co.jp/e-docs/wls/docs91/programming/overview.html#ddconverter) を参照してください。
アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server 9.0 から非推奨となり、代わりにアプリケーションはアプリケーション ライフサイクル イベントに応答するようになりました。ドメイン レベルのアプリケーション スコープの起動クラスと停止クラスの代わりに新しい 9.0 のライフサイクル イベントを使用するようアプリケーション環境を更新することをお勧めします。詳細については、『WebLogic Server アプリケーションの開発』の「アプリケーション ライフサイクル イベントのプログラミング」(http://edocs.beasys.co.jp/e-docs/wls/docs91/programming/lifecycle.html) を参照してください。
WebLogic Server 9.0 では、Administration Console の設計が全面的に刷新されています。WebLogic Server 9.0 の Administration Console は、WebLogic Portal のフレームワークに基づいて構築されているため、よりオープンで拡張性の高い設計になっています。
アーキテクチャが新しくなったため、Administration Console を拡張する手順も新しくなりました。旧リリース用に構築された WebLogic Administration Console の拡張は、新しいインフラストラクチャでは機能しません。
Administration Console の拡張の詳細については、『Administration Console の拡張』(http://edocs.beasys.co.jp/e-docs/wls/docs91/console_ext/index.html) を参照してください。
次の表に、非推奨となった、またはサポートされなくなったリソース アダプタのコンフィグレーション設定を示します。新機能と変更点の詳細については、『WebLogic リソース アダプタ プログラマーズ ガイド』の「このリリースでの新機能と変更点」(http://edocs.beasys.co.jp/e-docs/wls/docs91/resadapter/intro.html#features) を参照してください。
|
|
|
|
|
|
|
|
|
|
|
|
WLEC は、WebLogic Server 8.1 で非推奨となりました。WLEC ユーザは、『WebLogic Tuxedo Connector 移行ガイド』(http://edocs.beasys.co.jp/e-docs/wls/docs91/wlec_migration/index.html) の説明に従って、アプリケーションを WebLogic Tuxedo Connector に移行する必要があります。
以下のコンフィグレーション フラグは、ドメインをアップグレードするときに下位互換性をサポートするために使用することができます。これらのフラグは、「ドメインのグラフィカル モードでのアップグレード」で説明されているように、アップグレード中に [下位互換性フラグを設定しない] オプションを選択して無効にしない限り、下位互換性をサポートするためデフォルトで設定されます。
|
|
|
|
|
この節では、WebLogic Server 9.0 から非推奨となった、または削除された API について説明します。
注意 : 9.1 の環境で WebLogic Server 8.1 MedRec アプリケーションを構築する場合は、medrec/src/common/web/com/bea/medrec/utils/MedRecWebAppUtils.java と medrec/src/clients/com/bea/medrec/webservices/swing/EditProfileFrame.java の 2 つの Java ファイルで、weblogic.webservice.tools.wsdlp パッケージへの参照を新しいパッケージ名である weblogic.webservice.wsdl に置き換える必要があります。
8.1 のパッケージである weblogic.webservice.tools.wsdlp と、9.0 および 9.1 のパッケージである weblogic.webservice.wsdl は公開されていません。
「Web サービス」も参照してください。
非推奨となった API については、『BEA WebLogic Server 9.1 API Reference』の「Deprecated API」(http://e-docs.bea.com/wls/docs91/javadocs/deprecated-list.html) を参照してください。
この節では、WebLogic Server 9.0 で削除された API について説明します。
次の表に、WebLogic Server 8.1 で非推奨となり、WebLogic Server 9.0 で削除された API を示します。
次の表に、WebLogic Server 7.0 で非推奨となり、WebLogic Server 9.0 で削除された API を示します。
次の表に、これまで非推奨となることなく、WebLogic Server 9.0 で削除された API を示します。これらの API が削除された理由は、特に記載のない限り、関連する機能がサポートされなくなったためです。
注意 : 表中の * (アスタリスク) はワイルドカード文字です。
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
java.util.logging.Handler クラスによりサポートされます。
|
|
|