> WebLogic のアプリケーション環境のアップグレード > WebLogic Server 10.0 の旧リリースとの互換性

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

     前  次    目次     
ここから内容

WebLogic Server 10.0 の旧リリースとの互換性

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

また、「BEA WebLogic Server 10.0 の互換性について」も参照してください。

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

 

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

JMX クライアントを WebLogic Server 10.0 に準拠するよう更新することをお勧めします。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/docs100/jmx/understandWLS.html) を参照してください。

 

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

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

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

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

どのセキュリティ属性が動的であるか動的でないかを確認するには、『WebLogic Server のセキュリティ』の「セキュリティ コンフィグレーション MBean」(http://edocs.beasys.co.jp/e-docs/wls/docs100/secmanage/mbeans.html) を参照してください。

詳細については、『ドメインのコンフィグレーションについて』の「コンフィグレーションの変更の管理」(http://edocs.beasys.co.jp/e-docs/wls/docs100/domain_config/changes.html) を参照してください。

 

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

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

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

注意 : アップグレードしたそれぞれの JDBC モジュールに内部プロパティ セクションがあります。WebLogic Server では、下位互換性に対応するため、データ ソースの管理に内部プロパティが使用されます。また、従来の属性の一部は、JDBC データ ソース ファイルのプロパティ属性でプロパティとして保持されています。内部プロパティを手動で編集しないでください。

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

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

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

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

表 B-1 グローバル トランザクションのプロトコル パラメータ設定
従来のデータ ソース タイプ
ドライバ タイプ
2 フェーズ コミットのエミュレーション
GlobalTransactionProtocol
Tx データ ソース
XA
なし
TwoPhaseCommit
Tx データ ソース
非 XA
False
OnePhaseCommit (デフォルトでは明示的にセットされない)
Tx データ ソース
非 XA
True
EmulateTwoPhaseCommit1
データ ソース
非 XA
なし
なし

1使用する環境によっては、トランザクション処理に EmulateTwoPhaseCommit トランザクション プロトコルではなく LoggingLastResource (LLR) トランザクション プロトコルを使用するほうが、パフォーマンス上のメリットがあります。詳細については、『WebLogic JDBC のコンフィグレーションと管理』の「ロギング ラスト リソース トランザクション オプションについて」(
http://edocs.beasys.co.jp/e-docs/wls/docs100/jdbc_admin/jdbc_datasources.html#llr) を参照してください。

マルチプール

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

データ ソース ファクトリ

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

 

JDBC デバッグの強化

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

詳細については、『WebLogic 診断フレームワーク コンソール拡張の使い方』を参照してください。

 

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

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

詳細については、以下を参照。

WebLogic アップグレード ウィザードは、10.0 より前のバージョンの JMS リソースを、ドメインの config\jms ディレクトリにコピーされる interop-jms.xml という名前の JMS Interop モジュール ファイルに自動的に変換します。詳細については、『WebLogic JMS のコンフィグレーションと管理』の「JMS Interop モジュール」(http://edocs.beasys.co.jp/e-docs/wls/docs100/jms_admin/overview.html#jms_interop_modules) を参照してください。

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

 

JMS メッセージ ID 形式

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 環境のコンフィグレーション』の「ワーク マネージャを使用したスケジューリング済み作業の最適化」(http://edocs.beasys.co.jp/e-docs/wls/docs100/config_wls/self_tuned.html) を参照してください。

WebLogic Server 8.1 では、処理は複数の実行キュー内で実行されていました。パフォーマンスを向上するために 8.1 で実行キューを使用していた場合は、アプリケーション ドメインのアップグレード後にも実行キューを引き続き使用できます。アップグレードしたアプリケーションでユーザ定義実行キューを引き続き使用できるようにするために、Use81StyleExecuteQueues というフラグが用意されています。このフラグを使用すれば実行プールの自己チューニングが無効になり、この下位互換性が確保されます。下位互換性フラグの有効化と実行キューの監視に関する詳細については、『WebLogic Server パフォーマンス チューニング ガイド』の「WebLogic 8.1 のスレッド プール モデルの使用」(http://edocs.beasys.co.jp/e-docs/wls/docs100/perform/appb_queues.html) を参照してください。

 

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

ドメイン レベルの 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/docs100/jta/trxcon.html#interop) を参照してください。

 

セキュリティ

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

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

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

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

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.0 を使用して作成した WebLogic ドメインには、XACML プロバイダがデフォルトで含まれています。これら新しい XACML プロバイダは、WebLogic 認可プロバイダ (DefaultAuthorizer) および WebLogic ロール マッピング プロバイダ (DefaultRoleMapper) で作成したポリシーやロールに対して完全な互換性があります。既存の WebLogic ドメインを 10.0 にアップグレードして、現在指定されている認可プロバイダおよびロール マッピング プロバイダ (サード パーティ パートナーのプロバイダ、オリジナルの WebLogic 認可プロバイダおよびロール マッピング プロバイダなど) を引き続き使用できます。WebLogic Server 独自のプロバイダを使用している既存ドメインを、必要に応じて XACML プロバイダに移行することもできます (既存ポリシーのバルク インポートも含む)。詳細については、「BEA WebLogic Server 10.0 セキュリティ」(http://edocs.beasys.co.jp/e-docs/wls/docs100/security.html) を参照してください。

SAML V2 プロバイダ

WebLogic Server 9.2 では、SAML 資格マッピング プロバイダおよび SAML ID アサーション プロバイダの新バージョンが追加されました。SAML 資格マッピング V1 プロバイダおよび SAML ID アサーション V1 プロバイダは非推奨となりました。SAML 資格マッピング プロバイダおよび SAML ID アサーション プロバイダの各 V2 バージョンを使用してください。

各プロバイダのバージョン番号は加算されて V2 になっていますが、新しい SAML セキュリティ プロバイダにも、V1 プロバイダと同じ SAML 1.1 標準が実装されています。

セキュリティ MBean

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

表 B-2 WebLogic Server 9.0 におけるセキュリティ MBean の変更点
セキュリティ MBean のタイプ
説明
すべてのセキュリティ MBean
WebLogic Server 8.1 では、セキュリティ MBean 属性を更新すると、値はセキュリティ コンフィグレーションと管理階層ではただちに有効になり、セキュリティ実行時階層ではサーバを再起動すると有効になった。
WebLogic Server 9.0 からは、セキュリティ MBean 属性の変更がコンフィグレーション、管理、および実行時階層でただちに有効になるか、サーバを再起動すると有効になるかについては、この属性を動的な属性として設定するか動的でない属性として設定するかによって制御される。詳細については、「動的コンフィグレーション管理」を参照。
RealmMBean、UserLockoutManagerMBean、およびすべてのセキュリティ プロバイダ MBeans
  • 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 記述子など) およびデプロイメント プランでパスワードを暗号化するのにも使用できます。詳細については、『WebLogic Server コマンド リファレンス』の「WebLogic Server Java ユーティリティの使い方」に記載されている「encrypt」(http://edocs.beasys.co.jp/e-docs/wls/docs100/admin_ref/utils.html) を参照してください。

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

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

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

セキュリティの確保の詳細については、『プロダクション環境のセキュリティ』の「プロダクション環境のセキュリティの確保」に記載されている「WebLogic Security サービスのセキュリティ」(http://edocs.beasys.co.jp/e-docs/wls/docs100/lockdown/practices.html) を参照してください。

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 の詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「メッセージレベルのセキュリティ コンフィグレーションに対する WS-Policy ファイルの使い方の概要」(http://edocs.beasys.co.jp/e-docs/wls/docs100/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 を参照してください。

 

Web サービス

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

9.2 の Web サービスを 10.0 にアップグレードする必要はありません。

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

8.1 にアップグレードされた 7.0 Web サービスを含む、すべての 8.1 Web サービスを 10.0 にアップグレードすることをお勧めします。既存の 8.1 Web サービスのアップグレードについては、『WebLogic Web サービス入門』の「 WebLogic Web サービスの旧リリースから 10.0 へのアップグレード」を参照してください。

注意 : 「Web サービスにおけるメッセージレベルのセキュリティ」も参照してください。

 

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

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

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

WebLogic Server 10.0 から非推奨となった、またはサポートされていない Web アプリケーション機能については、『リリース ノート』を参照してください。

保護されていないリソースを使用する 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 はユーザとパスワードを認識しておく必要があります。

詳細については、『WebLogic Security プログラマーズ ガイド』の「リソースが非セキュアな場合の BASIC 認証について」を参照してください。

下位互換性フラグ

WebLogic Server 10.0 では、この節および『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 パッケージの暗黙的なインポートについては、『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』の「下位互換性フラグ」を参照してください。

JSP 2.0 のサポート

「下位互換性フラグ」で説明されているように、JSP 2.0 は WebLogic Server 9.0 以降でサポートされています。JSP 2.0 のサポートに応じて、JSP の動作は以下のように変更されています。

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

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

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

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

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

 

XML 実装

WebLogic Server 9.0 からは、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) と生成されているコードを更新します。

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 の階層構造に加えられた変更により、既存のコンフィグレーションおよび管理スクリプト (WLST、wlconfig、weblogic.Admin、Ant など) が 10.0 で動作する保証はなくなりました。WebLogic Server 10.0 からの新しい機能を利用するようスクリプトを変更することをお勧めします。MBean 階層構造の新機能と変更点の詳細については、『リリース ノート』の「WebLogic Server 10.0 の新機能」( http://edocs.beasys.co.jp/e-docs/wls/docs100/notes/new.html) を参照してください。

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

 

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

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

 

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

アプリケーション スコープの起動クラスと停止クラスは、WebLogic Server 9.0 から非推奨となり、代わりにアプリケーションはアプリケーション ライフサイクル イベントに応答するようになりました。ドメイン レベルのアプリケーション スコープの起動クラスと停止クラスの代わりにライフサイクル イベントを使用するようアプリケーション環境を更新することをお勧めします。詳細については、『WebLogic Server アプリケーションの開発』の「アプリケーション ライフサイクル イベントのプログラミング」(http://edocs.beasys.co.jp/e-docs/wls/docs100/programming/lifecycle.html) を参照してください。

 

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

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

Administration Console の拡張の詳細については、『Administration Console の拡張』(http://edocs.beasys.co.jp/e-docs/wls/docs100/console_ext/index.html) を参照してください。

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

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

完全修飾する必要のある 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 を使用するように更新する必要があります。

 

リソース アダプタ

次の表に、非推奨となった、またはサポートされなくなったリソース アダプタのコンフィグレーション設定を示します。新機能と変更点の詳細については、『WebLogic リソース アダプタ プログラマーズ ガイド』の「このリリースでの新機能と変更点」(http://edocs.beasys.co.jp/e-docs/wls/docs100/resadapter/intro.html#features) を参照してください。

表 B-3 非推奨となった、またはサポートされないリソース アダプタのコンフィグレーション設定
要素
WebLogic Server 9.0 での変更点
Link-Ref メカニズム
この要素は、非推奨となっており、新しい Java EE ライブラリ機能に置き換えられている。Java EE ライブラリの詳細については、『WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの作成」(http://edocs.beasys.co.jp/e-docs/wls/docs100/programming/libraries.html) を参照。
Link-Ref メカニズムは、J2CA 1.0 仕様に準拠して開発されたリソース アダプタの場合は、9.0 でもサポートされている。1.0 リソース アダプタでの Link-Ref メカニズムの使用の詳細については、『WebLogic リソース アダプタ プログラマーズ ガイド』の「weblogic-ra.xml ファイルのコンフィグレーション」に記載されている「(非推奨) Link-Ref メカニズムのコンフィグレーション」(http://edocs.beasys.co.jp/e-docs/wls/docs100/resadapter/creating.html#wp1248263) を参照。
<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 ユーザは、『WebLogic Tuxedo Connector 移行ガイド』( http://edocs.beasys.co.jp/e-docs/wls/docs100/wlec_migration/index.html) の説明に従って、アプリケーションを WebLogic Tuxedo Connector に移行する必要があります。

 

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

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

 

下位互換性フラグ

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

表 B-4 下位互換性フラグ 
カテゴリ
下位互換性フラグ
詳細情報
セキュリティ
  • EnforceStrictURLPattern : サーバが URL パターンのサーブレット 2.4 仕様への厳密な準拠を強制するかどうかを指定する。アップグレード中、このフラグは、下位互換性をサポートするため false に設定される。
  • WebAppFilesCaseInsensitive : Webapp コンテナおよび外部セキュリティ ポリシーにおいて、URL パターン マッチング動作がセキュリティ制約、サーブレット、フィルタ、仮想ホストなどの大文字と小文字を区別するかどうかを指定する。アップグレード中、このフラグは、9.0 より前のリリースとの互換性をサポートするため、URL パターン マッチングが Windows 以外のすべてのプラットフォームで大文字と小文字を区別するよう、os に設定される。WebLogic Server 9.0 以降では、URL パターン マッチングは、複数のオペレーティング システムにまたがって厳密に行われる。
SecurityConfigurationMBean (http://edocs.beasys.co.jp/e-docs/wls/docs100/wlsmbeanref/mbeans/SecurityConfigurationMBean.html)
Web アプリケーション
  • backward-compatible : サポートされる JSP バージョンを指定する。Web アプリケーションのバージョン (バージョン 2.4 または 2.5) と backward-compatible 要素の設定に応じて、Weblogic Server 10.0 では JSP 2.1 または JSP 2.0 がサポートされる。

    • 『WebLogic Server Web アプリケーション、サーブレット、JSP の開発』で説明されているように、backward-compatible は、jsp-descriptor 要素内に存在する。

  • 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 (http://edocs.beasys.co.jp/e-docs/wls/docs100/wlsmbeanref/mbeans/WebAppContainerMBean.html)

 

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

この節では、WebLogic Server 9.0 から非推奨となった、または削除された API について説明します。

注意 : 10.0 の環境で 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.tools.wsdlp に置き換える必要があります。
注意 : 8.1 のパッケージである weblogic.webservice.tools.wsdlp と、9.0 および 9.2 のパッケージである weblogic.webservice.wsdl は公開されていません。
注意 : 「Web サービス」も参照してください。

非推奨となった API

非推奨となった API については、http://e-docs.bea.com/wls/docs100/javadocs/deprecated-list.html を参照してください。

削除された API

この節では、WebLogic Server 9.0 で削除された API について説明します。

WebLogic Server 10.0 で非推奨となった API

表 B-5 に、WebLogic Server 10.0 で非推奨となった API を示します。

表 B-5 WebLogic Server 10.0 で非推奨となった API
パッケージ名
インタフェース/クラス/例外
メソッド/変数
weblogic.jws
WLHttpsTransport
*
weblogic.logging
ConsoleFormatter
ConsoleFormatter(weblogic.management.configuration.LogMBean)
weblogic.logging.log4j
WLLog4jLogEvent
setThrowableInfo(weblogic.logging.ThrowableInfo)
weblogic.logging.log4j
WLLog4jLogEvent
getThrowableInfo()
weblogic.wsee.jws
JwsContext
getLogger(java.lang.String)
weblogic.wsee.jws
SoapFaultException
 
weblogic.wsee.jws.util
Logger
*

WebLogic Server 8.1 で非推奨となり、10.0 で削除された API

次の表に、WebLogic Server 8.1 で非推奨となり、WebLogic Server 10.0 で削除された API を示します。

表 B-6 WebLogic Server 8.1 で非推奨となり、10.0 で削除された API
パッケージ名
インタフェース/クラス/例外
メソッド/変数
weblogic.jms
ServerSessionPoolFactory
createServerSessionPool(javax.jms.Connection, int, int, boolean, java.lang.String,java.io.Serializable)
weblogic.jms
ServerSessionPoolFactory
getServerSessionPool(javax.jms.QueueConnection, int, boolean, int, java.lang.String)
weblogic.jms
ServerSessionPoolFactory
getServerSessionPool(javax.jms.TopicConnection, int, boolean, int, java.lang.String)
weblogic.time.common
ScheduledTriggerDef
setDispatchPolicy(java.lang.String)

WebLogic Server 7.0 で非推奨となり、10.0 で削除された API

表 B-7 に、WebLogic Server 7.0 で非推奨となり、WebLogic Server 10.0 で削除された API を示します。

表 B-7 WebLogic Server 7.0 で非推奨となり、10.0 で削除された API
パッケージ名
インタフェース/クラス/例外
メソッド/変数
weblogic.common
WLSerializable
*
weblogic.io.common
T3File
*
weblogic.io.common
T3FileInputStream
*
weblogic.io.common
T3FileOutputStream
*
weblogic.io.common
T3FileSystem
*
weblogic.security
AuthenticationException
 
weblogic.security
Certificate
*
weblogic.security
Cipher
*
weblogic.security
Cipher3EDE
*
weblogic.security
CipherCBC
*
weblogic.security
CipherException
 
weblogic.security
Coder
*
weblogic.security
CoderException
 
weblogic.security
CoderInputStream
*
weblogic.security
CoderOutputStream
*
weblogic.security
DES
*
weblogic.security
DiffieHellman
*
weblogic.security
DigestInputStream
*
weblogic.security
DigestOutputStream
*
weblogic.security
DigestSignature
*
weblogic.security
Entity
*
weblogic.security
HexOutputStream
*
weblogic.security
JDK11Certificate
*
weblogic.security
KeyManagementException
*
weblogic.security
MD5RandomBitsSource
*
weblogic.security
NullCipher
*
weblogic.security
NullOutputStream
*
weblogic.security
PKCS5
*
weblogic.security
Padding
*
weblogic.security
RC4
*
weblogic.security
RSA
*
weblogic.security
RSAKey
*
weblogic.security
RSAMDSignature
*
weblogic.security
RSAPrivateKey
*
weblogic.security
RSAPrivateKeyPKCS8
*
weblogic.security
RSAPublicKey
*
weblogic.security
RSApkcs1
*
weblogic.security
RandomBitsSource
*
weblogic.security.SSL
BadMACException
 
weblogic.security.SSL
Biguint
*
weblogic.security.SSL
CipherSpec
*
weblogic.security.SSL
RecordInputStream
*
weblogic.security.SSL
SSLCertificate
*
weblogic.security.SSL
SSLParams
*
weblogic.security.SSL
SSLSocket
*
weblogic.security.SSL
SessionParams
*
weblogic.security.SSL
TrustManager
certificateCallback(weblogic.security.X509[],int)
weblogic.security
Signature
*
weblogic.security
SimpleRandomBitsSource
*
weblogic.security
SpinnerRandomBitsSource
*
weblogic.security
StreamCipher
*
weblogic.security
Streamable
*
weblogic.security
SymmetricCipher
*
weblogic.security
TeeOutputStream
*
weblogic.security
X500Name
*
weblogic.security
X509
*
weblogic.security.acl
CertAuthentication
authenticate(java.lang.String,weblogic.security.Certificate[],boolean)
weblogic.security.acl
CertAuthenticator
authenticate(java.lang.String,weblogic.security.Certificate[],boolean)
weblogic.security.acl
SSLUserInfo
setSSLCertificate(weblogic.security.X509)
weblogic.security.acl
Security
receiveSecurityMessage(weblogic.rjvm.JVMID, weblogic.security.acl SecurityMessage)
weblogic.security.acl
SecurityMessage
execute(weblogic.rjvm.JVMID)
weblogic.security.audit
Audit
certificateInvalid(java.lang.String, java.lang.Object,weblogic.security.X509)
weblogic.security.audit
Audit
rootCAInvalid(java.lang.String,java.lang.Object, weblogic.security.X509)
weblogic.security.audit
AuditProvider
certificateInvalid(java.lang.String, java.lang.Object,weblogic.security.X509)
weblogic.security.audit
AuditProvider
rootCAInvalid(java.lang.String, java.lang.Object,weblogic.security.X509)
weblogic.security.service
InvocableResource
toString()
weblogic.security.service
MBeanResource
*
weblogic.security.service
RealmAdapterAclResource
*
weblogic.servlet.security
AuthFilter
doSuccessAuth(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
weblogic.servlet.security
AuthFilter
doFailAuth(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
weblogic.servlet.security
AuthFilter
doPreAuth(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
weblogic.servlet.security
AuthFilter
service(javax.servlet.ServletRequest, javax.servlet.ServletResponse)
weblogic.servlet.security
ServletAuthentication
authObject(java.lang.String, java.lang.Object,javax.servlet.http.HttpSession, javax.servlet.http.HttpServletRequest)
weblogic.servlet.security
ServletAuthentication
authObject(java.lang.String, java.lang.Object,javax.servlet.http.HttpSession, javax.servlet.http.HttpServletRequest)
weblogic.servlet.security
ServletAuthentication
weak(java.lang.String, java.lang.String,javax.servlet.http.HttpSession)
weblogic.xml.sax
XMLInputSource
*

これまで非推奨とならず、9.0 で削除された API

次の表に、これまで非推奨となることなく、WebLogic Server 9.0 で削除された API を示します。これらの API が削除された理由は、特に記載のない限り、関連する機能がサポートされなくなったためです。

注意 : 表中の * (アスタリスク) はワイルドカード文字です。

表 B-8 これまで非推奨とならず、9.0 で削除された API
パッケージ名
インタフェース/クラス/例外
メソッド/変数
weblogic.apache
*
*
weblogic.common
CallbackDispatcher
CallbackDispatcher(weblogic.common.ClientCallback, boolean)
T3ResourceDef
T3ResourceFactory
*
weblogic.jdbc.common
 
*OracleBlob.*
*OracleConnection.*
*OracleCallableStatement.*
*OracleLobCloser.*
*OracleClob.*
weblogic.jms
 
*VirtualDestination.*
weblogic.jms.extensions
JMSHelper
*getRepositoryForDomain.*
weblogic.jndi
Environment
*getProviderRJVM.*
*getSecuritySubject.*
*getUseIIOPServiceProvider.*
*setProviderRJVM.*
*setSecuritySubject.*
*setUseIIOPServiceProvider.*
WLContext
*PROVIDER_RJVM.*
*USE_IIOP_SERVICE_PROVIDER.*
weblogic.logging
ConsoleHandler
*isLoggable.*1
FileStreamHandler
*isLoggable.*1
WLLevel
*WLLevel.*
WLLogRecord
*setId.*
*setMachineName.*
*setServerName.*
*setThreadName.*
*setTransactionId.*
*setUserId.*
weblogic.management
 
*WebServiceLegalHelper.*
AdminServerAdmin
*
DeploymentException
getApplication()
DistributedManagementException
MAX_EXCEPTIONS
LocalAdminServer
*
ManagedServerAdmin
*
RemoteMBeanServer
java.lang.String getSharedCommoMBeanRepositoryIdentifier(javax.management.ObjectName)
java.util.List getCommoMBeans(javax.management.ObjectName)
tools
*
WebLogicObjectName
WebLogicObjectName(java.lang.String, java.lang.String)
UndeploymentException
getApplication()
utils
InvalidPasswordException
InvalidPredicateException
weblogic.management.configuration
*
*
weblogic.management.runtime
*
*
weblogic.management.security
BaseMBeanImpl
*getRequiredModelMBean.*
ProviderMBean
*setRealm*
RealmMBean
*setAdjudicator*
*setUserLockoutManager*
weblogic.management.security.authentication
UserLockoutManagerMBean
*setRealm*
weblogic.management.timer
Timer
void addNotification(weblogic.time.common.internal.TimerNotification)
java.lang.String getDispatchPolicy()
void removeNotification(weblogic.time.common.internal.TimerNotification)
void removeNotification(weblogic.time.common.internal.TimerNotification, boolean)
void run()
void setDispatchPolicy(java.lang.String)
void start(java.lang.ThreadGroup,java.lang.String,int)
weblogic.net.http
HttpClient
 
HttpsClient
 
HttpUnauthorizedException
 
HttpURLConnection
*
HttpsURLConnection
*
KeepAliveCache
 
KeepAliveStream
 
MessageHeader
 
weblogic.rmi
Naming
void bind(java.lang.String, weblogic.rmi.Remote)
weblogic.rmi.Remote lookup(java.lang.String)
void rebind(java.lang.String, weblogic.rmi.Remote)
weblogic.security
HMAC
*
Key
*
weblogic.security.providers.authentication
*
*
weblogic.security.providers.authorization
*
*
weblogic.security.service
Auditor
*
SecurityManager
*
WebResource
*
WebServiceResource
void initialize(java.lang.String)
void main(java.lang.String[])
WebServiceResource WebServiceResource(weblogic.security.service.WebResource, java.lang.String, java.lang.String[], java.lang.String[])
weblogic.security.spi
KeyStoreProvider
 
weblogic.security.SSL
HostnameVerification
 
HostnameVerifier
*verify(java.lang.String, java.lang.String)
*verify(java.net.InetAddress, weblogic.security.X509)
SSLClientInfo
 
SSLSocketFactory
*SSLSocketFactory()
weblogic.servlet.logging
FormatStringBuffer
*
HttpAccountingInfo
java.lang.String getFirstLine.*
weblogic.servlet.proxy
GenericProxyServlet
 
GenericProxyServlet
ProxyConnection
ProxyConnectionPool
HttpClusterServlet
RequestInfo
Server
ServerList
HttpProxyServlet
 
weblogic.webservice.async
KernelFeederImpl
ExecuteTask void execute(weblogic.kernel.ExecuteThread)
weblogic.webservice.client
BaseWLSSLAdapter
void main(java.lang.String)
void _setStrictChecking(boolean)
JSSEAdapter
javax.net.ssl.SSLSocketFactory getSocketFactory()
void setSocketFactory(javax.net.ssl.SSLSocketFactory)
SSLAdapterFactory
void main(java.lang.String)
weblogic.xml
xpath
*XMLNodeXPath.*
weblogic.xml.security.specs
SecuritySpec
java.lang.String getName()
weblogic.xml.security.wsse
SecurityElementFactory
weblogic.xml.security.wsse.Token createToken(java.lang.String, java.lang.String, javax.xml.namespace.QName)
UsernameToken
String getPasswordType()

1API 機能は java.util.logging.Handler クラスによりサポートされます。


ページの先頭       前  次