リリース ノート

サービス パック 3 で解決された問題

サービス パックは累積的であり、サービス パック 3 には WebLogic Server 8.1 の以前のサービス パックで行われたすべての修正が含まれています。

以下の節では、WebLogic Server 8.1 SP3 で解決された問題について説明します。

• Administration Console
• クラスローダ
• クラスタ
• コンパイラ
• コンフィグレーション ウィザード
• コネクタ
• コア WebLogic Server
• デプロイメント
• EJB
• インストール
• J2EE
• JCOM
• JDBC
• jDriver
• JMS
• JNDI
• JSP
• JTA
• JVM
• ノード マネージャ
• 操作と管理
• プラグイン
• RMI/RMI-IIOP
• サンプル
• セキュリティ
• サーブレット
• SNMP
• ツール
• Web サービス
• WebLogic Type 4 JDBC ドライバ
• WebLogic Tuxedo Connector
• WLEC
• XML

Administration Console

変更要求番号	説明	修正されたリリース
CR111884 CR182433	WebLogic Tuxedo Connector では、インポートされたサービスについて、リソース名、ローカル ドメイン名、およびリモート ドメイン名の組み合わせがユニークでなければなりません。しかし、Administration Console ではインポートされた複数のサービスを同じリソース名で定義することができませんでした。 現在の Administration Console では、リソース名、ローカル ドメイン名、およびリモート ドメイン名の組み合わせに基づいてユニークなネーミングがなされるようになっています。	8.1 SP3
CR125041	Administration Console において、接続プールの待機に関する統計モニタ領域の値が正しく表示されない場合がありました。 待機数を正しく報告するためのチェック機能が追加されました。	8.1 SP3
CR126506	ユーザは、ポリシー定義ページが置き換えられるようにコンソール拡張をコンフィグレーションすることはできませんでした。 コードを追加したことで、CreateResourcesAction を使用して転送前に拡張を検索できるようになりました。	7.0 SP5 8.1 SP3
CR127617 CR134432	適切なパーミッションを持たないユーザが特定のディレクトリ内のファイルを読み込むと、コンソールで NullPointerException が発生していました。ユーザに適切なパーミッションがないため、空の配列が返されていました。 この問題は、適切なチェックを追加することで解決しました。適切なパーミッションを持たないユーザに対してファイルが表示されることはありません。	8.1 SP3
CR132229	Console ヘルプを修正したことで、Jolt および WLEC 接続プールをコンフィグレーションした際に、アドレスの区切り文字としてカンマが正しく識別されるようになりました。	8.1 SP3
CR132627	WebLogic Server を大きなヒープ サイズ (たとえば「-Xms3069m -Xmx3069m」や「-Xms2500m -Xmx2500m」) で開始すると、Administration Console の [サーバ｜モニタ｜パフォーマンス] に誤った値が表示されていました。最大メモリは常に 1 で、現在のヒープ サイズは負の値になっていました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR134434	デプロイメント プロセス中にシンボリック リンクが解決され、絶対パスがコンフィグレーション フィールド (config.xml) に保存されていました。 コードを修正したことで、シンボリック リンクが解決されなくなりました。	8.1 SP3
CR135294	コンソールでは、カスタム セキュリティ プロバイダを作成するために使用するカスタム セキュリティ MBean から情報を生成することができていませんでした。 コードが修正されて、コンソールが例外なく関連ページを生成するようになりました。	8.1 SP3
CR137213 CR174743	UNIX システムで Administration Console を使用して Web アプリケーションのロード順を変更した場合に、config.xml が正しく更新されていませんでした。アプリケーションのパスの先頭にある「/」文字が消失していました。 コードを修正したことで、関連する Console ページからロード順を変更した場合でも絶対値が更新され、パス属性は更新されなくなりました。	8.1 SP3
CR158522	文字列モニタ、ゲージ モニタ、またはカウンタ モニタをコンフィグレーションする際にポーリング間隔の範囲が正しく示されるように、コンソール ヘルプが更新されました。値の適切な範囲は、1 ～ 65535 秒です。	8.1 SP3
CR172232 CR178004	カスタム JDBC ドライバを使用する接続プールが作成された場合に、その JDBC ドライバがシステム クラスパスにないと、そのドライバの詳細プロパティ タブを編集することができず、サーバ インスタンスが Java.lang.ClassNotFoundException を送出していました。 システム クラスパスになくても JDBC ドライバがロードされるように、コードが修正されました。コンソールでは、XA 属性のない [接続｜詳細オプション] ページが表示されます。	8.1 SP3
CR173345	Administration Console の言語プリファレンスの設定に、以下の言語が追加されました。 Chinese Simplified/GB18030 Chinese Simplified/GB2312 Chinese Simplified/GBK Chinese Simplified/UTF-8 Chinese Traditional/Big5 Chinese Traditional/Big5-HKSCS Chinese Traditional/UTF-8 English English/UTF-8 Japanese/EUC-JP Japanese/Shift_JIS Japanese/UTF-8 Korean/EUC-KR Korean/UTF-8	8.1 SP3

クラスローダ

変更要求番号	説明	修正されたリリース
CR124348	クライアント プログラムでは、プロキシのクラスがシステムのクラスパスに追加されていないと、java.lang.reflect.Proxy を使用して WebLogic Server にデプロイされているプロキシ オブジェクトにアクセスできませんでした。オブジェクトがシステムのクラスパスにない場合、クライアントは ClassNotFoundException を受信していました。 システムのクラスローダだけでなくアプリケーション固有のクラスローダからもインタフェースをロードするように、resolveProxyClass() メソッドが追加されました。	6.1 SP6 7.0 SP5 8.1 SP3
CR128510	WebLogic Server 8.1 サーバが Calendar オブジェクトを WebLogic Server 6.1 または 7.0 クライアントに返した場合、そのクライアントでは ClassNotFoundException が送出されていました。この問題の原因は、JDK 1.4 での Calendar クラスの変更にありました。MsgAbbrevInputStream の readClassDescriptor() でクラスを解決しようとすると、ClassNotFoundException が発生していました。Java シリアライゼーションでは、対応するデータが読み込まれていないと、この ClassNotFoundException がスキップされていました。 MsgAbbreveInputStream readClassDescriptor() ではクラスが解決されないようにし、MsgAbbrevInputStream に resolveClass() を実装しました。	7.0 SP5 8.1 SP3
CR137120	クラスタ内の 2 つの管理対象サーバを順番に開始すると、次のエラーが発生していました。このエラーは、2 つの管理対象サーバを同時に開始した場合は発生していませんでした。 LinkageError : duplicate class definition この問題は、コードを修正することで解決されました。	8.1 SP3
CR161884 CR173695	EAR ファイルで、WAR ファイルに実在するクラスに対して「NoClassDefFoundError」および「IllegalStateException: zip file closed」メッセージが発生していました。 複数のスレッドが EAR ファイル内の WAR ファイルから 1 つのクラスをロードしようとすると、WEB-INF/lib ディレクトリ内のいくつかの JAR ファイルがロックされない可能性があったため、NoClassDefFoundError や IllegalStateException が発生していました。 この問題は、ファインダ内の zip 構造が破損しないようにするための同期をコードに追加することで解決しました。	8.1 SP3

クラスタ

変更要求番号	説明	修正されたリリース
CR111029	デフォルトの 30 秒のタイムアウト期間内にハートビートを受信しないと、クラスタ メンバーはタイムアウトになっていました。ハートビートは 10 秒ごとに送信され、サーバはハートビートの取得にその期間 3 回分 (トータルの待機時間は 30 秒) 待っていました。その 30 秒を過ぎると、クラスタ メンバーはタイムアウトになり、アクセス不能と宣言されていました。たとえば、セッション レプリケーション時にセカンダリ サーバが TCP レベルでアクセス不能になる場合、30 秒という期間は非常にアクセスの多い Web サイトでは長すぎる場合がありました。セカンダリがクラスタから削除される前に、プライマリは多くのセッションをセカンダリにレプリケートしようとし、その結果としてサーバがハングするか、サーバの速度が遅くなることがありました。 タイムアウト値 IdlePeriodsUntilTimeout は現在は調整可能です。この値は、config.xml の <Server IdlePeriodsUntilTimeout="3"> タグで設定します。通常、この値は調整する必要はなく、デフォルトの 3 のままにしておくようにしてください。ただし、負荷、アーキテクチャのリダンダンシ、および特定のアプリケーションの問題に依存する特定のケース、または特定のプロダクション シナリオでは、この値を慎重に調整すると、根本の原因が特定および修正されるまで問題を一時的に緩和できる場合があります。 この値を変更するときには特に慎重を期し、期待通りの動作になるようにピーク負荷時のアプリケーションのテストを十分に行ってください。あらゆる場面に当てはまるような推奨事項はないので、この値を変更する必要があるときには負荷とストレスのテストを必ず行ってください。	8.1 SP3
CR112326	レプリケート可能なオブジェクトの JNDI リバインドの間に、weblogic.cluster.BasicServiceOffer でメモリ リークが発生していました。この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR112874	重みベースのロード バランシングがコンフィグレーションされたクラスタにデプロイされている Bean に対して、ステートフル セッション Bean のクライアントがアクセスした場合に、最大および 2 番目に大きな重みを与えられている管理対象サーバがその順序で強制終了すると、クライアントから以下のメッセージが送出されていました。 <Jul 22, 2003 1:32:56 AM IST> <Warning> <Kernel> <No replica in list has the expected weight.Reverting to round-robin> 管理対象サーバが再起動されると、ロードバランシング アルゴリズムがラウンドロビンに切り替わっていました。分析の結果、管理対象サーバがダウンしたときにレプリカ リストが更新されていましたが、競合状態が原因で、RichReplicaList の最大の重みが正しくリセットされていなかったことが判明しました。 レプリカ リストのサイズが変更されたときには必ず最大の重みが再計算されるコード修正で、この問題は解決しました。	8.1 SP3
CR121113	HttpClusterServlet がエラー メッセージにスレッド名を出力していなかったため、エラー発生時の診断が困難でした。 ログに記録されたエラー メッセージにスレッド名が追加されるように GenericProxyServlet.trace() のコードを修正したことで、トラブルシューティングが容易になりました。	7.0 SP5 8.1 SP3
CR122924	クラスタ アドレスを次のように指定した場合、 t3://127.0.0.11:8001,127.0.0.12:9001 WebLogic Server はホーム ハンドルの生成時にポート番号を不正確に追加していました。 ユーザがすでにポート番号を指定しているかどうかをチェックし、その情報をもとにホーム ハンドルで使用する URL が正しく作成されるようになりました。	8.1 SP3
CR126406	クラスタ サービスがマルチキャスト ポートへのバインド後にプロセスの本当の uid または gid をセットしていたため、サーバをリスン ポートにバインドするとエラーが発生していました。 サーバをリスン ポートにバインドする際に、特権のある uid または gid のみが使用されるようにコードを修正しました。それ以降のサーバ開始プロセスでは、特権のない uid または gid が使用されます。	8.1 SP3
CR127375	重みベースのロード バランシング アルゴリズムを使用する単一ノード クラスタ内で、外部クライアントが EJB のリモート メソッドを呼び出すと ArrayIndexOutOfBoundsException が発生していました。 単一ノード クラスタが存在する場合は、WebLogic Server がフェイルオーバやロード バランシングを要求するレプリカを持たないようにしました。このチェックを追加したことで問題は解決しました。	8.1 SP3
CR127616 CR133899	クラスタ アフィニティが設定されていると、70 から 81 への相互運用において BasicReplicaHandler で NullPointerException が発生する場合がありました。 すべてのアフィニティ ハンドラに null チェックが追加されました。	8.1 SP3
CR130407	クラスタ内にサーバが 1 つしかない場合でも、クライアントがフェイルオーバしようとしていました。 この問題は、クラスタ内に複数のサーバがある場合にのみフェイルオーバが発生するようにコードを修正することで解決しました。	8.1 SP3
CR130507	セッション レプリケーションによって、クラスタ内のサーバ ノードがハングしていました。これは、セッションの lastAccessedtime がバッチ更新され、そのすべてが全セッションのハッシュテーブルに格納されていたことが原因です。バッチ更新の実行時には、すべての更新 (更新はすべてリモート呼び出し) が完了するまでこのハッシュテーブルがロックされていたため、他のスレッドがハッシュテーブルを更新できずパフォーマンスが低下していました。 コードを修正することで、BatchedLATUpdater のトリガ メソッド内に、元のハッシュテーブルの複製である新しいハッシュテーブル (ローカル変数) が作成されるようになりました。新しいハッシュテーブルをセッションの lastAccesstime へのアクセスに使用し、古いハッシュテーブルは複製されている間のみ同期されます。これにより、リモート呼び出しの実行中でも、他のスレッドがハッシュテーブルを使用することが可能になりました。	8.1 SP3
CR177367	クラスタの負荷が高いとき、またはセッションの固定が維持されなかったときに NPE が送出されていました。クラスタ ノードで負荷が大きい場合には、プラグインがそのノードから拒否された接続を取得し、リクエストをクラスタ内の他のノードにフェイルオーバしていました。どちらの状況でも、セッションはクラスタ内のいずれかのノードでランダムに変更または作成され、ある特定の場合には、プライマリが削除され、同じノードでそのセッション用にセカンダリが作成される可能性もありました。セカンダリ情報の取得にはプライマリが必要なので、セカンダリ情報を取得しようとするスレッドはすべて NPE で失敗していました。セカンダリの作成前にプライマリが削除される場合は、secondaryURL が null と算出されていました。 コードの修正により、WebLogic Server が null の secondaryURL をチェックするようになりました。さらに、この問題を通知するように警告メッセージがログに記録されるようになったので、予期される負荷に合わせてクラスタをコンフィグレーションすることができます。これにより、ロード バランサのコンフィグレーションまたはプラグインでセッションの固定が壊された場合に問題を解決できるようにもなります。	8.1 SP3

コンパイラ

変更要求番号	説明	修正されたリリース
CR136199	ejbc -idl によって生成される EjbObject.idl が CORBA3.0 に準拠していませんでした。 CORBA 2.6 以降では次のように説明されています。「3.2.3.1 エスケープされた識別子。 IDL の進化にともない、IDL 言語に追加された新しいキーワードが、既存の IDL およびその IDL を使用するプログラムで使用されている識別子と誤って衝突しています。これらの衝突を解決するには、IDL を修正するだけでなく、その IDL に依存するプログラミング言語のコードも修正しなければなりません。名前が変更された IDL 識別子の言語マッピング ルールを適用すると、マップされた識別子の名前 (たとえばメソッド名) が変更されてしまいます。この問題を最小限の労力で解決する場合は、識別子の前にアンダースコア (_) を追加することで識別子を語彙的に「エスケープ」できます。これは、キーワード チェックを無効にすること「のみ」を目的とした、単なる語彙的な慣習です。変更後の識別子には、その他すべての識別子処理ルールが適用されます。 たとえば、識別子 _AnIdentifier は、AnIdentifier として処理されます。」 既知の IDL 予約語にアンダースコア (_) を追加するコード変更により、この問題は解決しました。	8.1 SP3

コンフィグレーション ウィザード

変更要求番号	説明	修正されたリリース
CR128745	ドメイン コンフィグレーション ウィザードをサイレント モードで使用してドメイン コンフィグレーションを作成すると、Administration Console でユーザが複数回同じグループに割り当てられていました。 対応する割り当てがすでに行われている場合はエントリを追加しないようにコードが修正されました。	8.1 SP3
CR130268	結果としてエラーになる問題が発生した場合に、ドメイン コンフィグレーション ウィザードはゼロを返していました。 ユーザ スクリプト ファイルが見つからない場合にゼロ以外を返すようにコードが修正されました。	8.1 SP3
CR130536	WebLogic Server 8.1 のサービス パック 1 が動作し、Posix Performance Pack を使用している AIX 5.1 プラットフォームで、IBM JVM から SIGSEGV 11 (*) セグメンテーション違反が発生していました。 このエラーは次のようにして再現できます。 1. コンフィグレーション ウィザードで新しい WebLogic ドメインを作成します。 2. シェルでファイル ディスクリプタの制限を無制限 (ulimit -n) に設定します。 3. startWebLogic.sh スクリプトを実行します。 この問題は、無制限の設定を 1025 に自動的にリセットする resetFd() メソッドが commEnv.sh script で呼び出されるようにコードを修正することで解決しました。	8.1 SP3
CR132234	サイレントモードのスクリプトを使用して、Server 要素のログ子要素を作成および編集できるようになりました。 サイレントモードのコンフィグレーションを使用して、有効なコンフィグレーション オブジェクトとその子要素を作成および編集できるようになりました (カスタム セキュリティ オブジェクトを除く)。有効なコンフィグレーション オブジェクトの詳細については、『WebLogic Server コンフィグレーション リファレンス』を参照してください。サイレントモードのスクリプト コンフィグレーションの詳細については、『コンフィグレーション ウィザードの使い方』の「サイレント モードのコンフィグレーション スクリプトの作成」を参照してください。	8.1 SP3
CR132608	Solaris 2.9 で WebLogic Server Template Builder を使用してドメインを作成しようとすると、MySQL JDBC 接続プールの作成時に JDBC URL でエラーが発生していました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR135642	サイレント モードでコンフィグレーション ウィザードを実行すると、Oracle OCI ドライバの JDBC 接続プールの URL (jdbc:oracle:oci:@<DBName>) が Oracle Thin ドライバの URL (jdbc:oracle:thin:@<DBHost:port:DBName>) に間違って変換されていました。これが原因で、サーバの起動時に Oracle OCI ドライバを使用する JDBC 接続プールのデプロイメントが妨げられていました。 コンフィグレーション ウィザードは、どちらの Oracle JDBC ドライバの URL も受け入れるようになりました。	8.1 SP3

コネクタ

変更要求番号	説明	修正されたリリース
CR124102	アダプタの接続をトランザクションに登録するプロセスで例外が送出された場合、その接続の状態は正しくリセットされず、縮小によってクリーンアップされなくなっていました。 また、着信したアプリケーション リクエストで接続を使用することもできませんでした。このため、最終的には接続プールが枯渇していました。 接続の取得に失敗しても接続の状態が正しくリセットされるようにサーバ コードを修正しました。これにより、接続を縮小によってクリーンアップすること、および接続を以降のアプリケーション リクエストで使用することが可能になりました。	7.0 SP5 8.1 SP3
CR125399	接続プロキシ テストに失敗したアダプタでは、weblogic-ra.xml で inactive-connection-timeout-seconds が指定されている場合でも接続のアイドル状態の検出を無効にするべきでした。以前のリリースでは、サーバがそのようなアダプタを使用してアイドル クリーンアップを実行しようとして、NullPointerException が送出されていました。 現在は、プロキシ テストに失敗したアダプタでは idle-detection が適切に無効になります。その結果として、NullPointerException が発生しなくなりました。	8.1 SP3
CR126184 CR135205	一部のリソース アダプタで、コネクタ コンテナが誤って接続リークを報告することがありました。 この問題は、連続する呼び出しで同じハンドルを返すように ManagedConnection.getConnection() メソッドが実装されたアダプタで発生していました。 この問題が発生したのは、接続ハンドルの周囲にプロキシが作成されてしまうことが原因でした。プロキシが完全に作成され、同じ hashCode 値を開いたままのハンドルがあると、リークがあるかのようにコンテナが動作していました。 同じ hashCode を持つハンドルに関連付けられたカウントを、接続コンテナが追跡できるようになりました。このカウントは、開いたときに増分され、プロキシが完全に作成されたときに減分されます。これにより、ハンドルに関連付けられたすべてのプロキシが完全に作成された場合にのみコンテナがリークを報告することになり、誤ったリークが報告されることはなくなりました。	8.1 SP3
CR129392 CR133572 CR177908	メッセージング ブリッジをホストしている WebLogic Server インスタンスは、MQSeries 5.3 Queue Manager が停止して再起動したときに再起動する必要がありました。その理由は、メッセージング ブリッジが XASession オブジェクトを閉じようとしたときに MQSeries に対する呼び出しが失敗していたからです。その結果として、MQSeries Queue Manager が停止された後にそれに関連してリソースがクリーンアップされていませんでした。また、WebLogic Server のプロセスで使用されているオブジェクトがまだ存在することを検出して、Queue Manager が再起動していませんでした。 IBM のアップグレード CSD06 を MQSeries 5.3 に適用することで、この問題は解決します。その結果として、エラーが発生したり、WLS サーバ プロセスを停止したりする必要なく、Queue Manager を停止および再起動できるようになりました。	8.1 SP3
CR174339	接続をプールから永久に削除したときに、内部的にキャッシュされたオブジェクトの一部が適切にクリーンアップされていませんでした。このため、キャッシュが無制限に大きくなるおそれがありました。 コードを修正したことで、接続をプールから永久に削除すると、キャッシュされていたオブジェクトがクリーンアップされるようになりました。	8.1 SP3
CR175301	jRockit JVM に大きな負荷がかかると、WebLogic コネクタの ConnectionRuntimeMBeanImpl() API によって InstanceAlreadyExists 例外が送出されることがありました。これは、さまざまなオブジェクトに対して ConnectionInfo#hashCode() メソッドがユニークでないことがあったために発生していました。 以前のサービス パックでは、接続のハッシュコードを使用して MBean 名が生成されていました。 コードを改善したことで、同期化されたカウンタを使用して MBean 名が生成されるようになりました。これにより、リソース アダプタ接続のモニタに使用するすべての実行時 MBean はユニークな名前で生成されるようになっています。	8.1 SP3
CR176940	クラスタ内の複数のサーバにアダプタをデプロイすると、各サーバで作成された接続は XAResource を取得し、サーバはリソース登録に同じ名前を使用していました。このことが原因で、トランザクション マネージャは一部の処理に関して間違った XAResource で呼び出しを行おうとしていました。 リソース登録で使用される名前はサーバとドメインの名前で限定されるようになり、クラスタ内の複数のサーバにデプロイされたアダプタがリソース登録に異なる名前を使用するようになりました。	8.1 SP3

コア WebLogic Server

変更要求番号	説明	修正されたリリース
CR098607 CR136879	アプリケーション A がアプリケーション B を使用している場合、アプリケーション B をルックアップする間に、アプリケーション A の J2EE コンテナがアプリケーション B の ClassFinder をアタッチして DependencyClassLoader を作成します。アプリケーション B を再デプロイすると、アプリケーション B が新しい ClassFinder を検出し、それ以降は古い ClassFinder が無効になります。クライアント リクエストが発生すると、サーバが古い DependencyClassLoader を使用しようとして例外を送出していました。 この例外の原因となる動作が変更され、ReplicaAwareRemoteObject.getPrimaryRepresentative() からの impl クラスのロードには DependencyClassLoader を使用しないことになりました。	7.0 SP5 8.1 SP3
CR105257 CR174955	IIOP 接続プールが初期化される前に WLECService.getConnectionPoolCount を呼び出すと、Null ポインタ例外 (NPE) が発生していました。 IIOP 接続プールが null の場合には 0 を返すためのコードを追加しました。	8.1 SP3
CR105444	-Dweblogic.Stdout および -Dweblogic.Stderr コマンドライン オプションの使用時に、ログ ファイルのパスが指定されているがディレクトリが存在しない場合、サーバが FileNotFound Exception を送出していました。 コマンドライン オプションで指定されたディレクトリ構造が存在しない場合にその構造を作成するようにコードを拡張することで、この問題は解決しました。	8.1 SP3
CR108993 CR133901	HPUX11 では、ネイティブの POSIX マルチプレクサを使用すると CPU の使用率が高くなっていました。 /dev/poll に基づいて、新しいマルチプレクサが設計されました。このマルチプレクサを有効にするには、MuxerClass プロパティを次のように設定します。 <Server ... MuxerClass="weblogic.socket.DevPollSocketMuxer" ...> サーバの起動時に、次のようなメッセージが表示されるはずです。 このメッセージが表示されれば、/dev/poll が有効になっています。 <Sep 9, 2003 5:29:28 PM PDT> <Info> <Socket> <BEA-000406> <DevPollSocketMuxer was built on Sep 8 2003 15:34:11> /dev/poll デバイスが使用できない場合はロードに失敗します。現時点では、以下の環境で使用できます。 パッチを当てた Solaris 7 および Solaris 8 以降 HP-UX 11.0 (PHKL_24064 パッチが必要) HP-UX 11i (PHKL_2546 パッチが必要)	8.1 SP3
CR109180	別のサーバをトランザクション コーディネータとして使用するサーバで開始されたトランザクションは、2 つのサーバがそれ以前にトランザクション コンテキストを交換していない場合にコミット時に失敗していました。この問題の原因は、JTA インターセプタに渡されるチャネルにリモート ピアではなくローカル サーバ上の情報が含まれていたことです。 適切なチャネルを JTA インターセプタに渡すようにコードが修正されました。	8.1 SP3
CR109307	これまでは、WebLogic Server 8.1 SP2 の管理対象サーバを 8.1 SP3 ドメインで起動することはできませんでした。コードを修正したことで、異なるサービス パック間の互換性が向上し、「管理サーバのサービス パック レベルが管理対象サーバのレベルと同じかそれ以上であれば、管理ドメイン内のサーバのサービス パック レベルが異なっていても構わない」とする WebLogic Server の互換性に関する説明に準拠しました。	7.0 SP5 8.1 SP3
CR109688 CR133876 CR133877 CR135235 CR176217	特定の条件のもとでは、InitialContext をルックアップする単純な Java クライアントで誤って「No version information」エラーが発生していました。 これは、ヘッダ バッファ内の改行が line.separator プロパティではなく「\n」になっていたことが原因でした。コードを修正して問題は修正されました。	7.0 SP5 8.1 SP3
CR116707	特定の Factory/Trader パターンを使用すると、ReplicaAwareRemoteRef 警告ログが出力され、クライアント サイドに次のように表示されていました。 [ReplicaAwareRemoteRef] : WARNING: client-side RA stub didn't find environment on thread 不適切なログがクライアントに出力されないようにコードを修正しました。	7.0 SP5 8.1 SP3
CR116712	WebLogic Server 6.1 SP4 では、Admin ツールを使用して WLECConnectionPoolRuntime で INVOKE を発行したときに、WLECConnectionRuntime MBean が更新されていませんでした。 分析の結果、WLECConnectionPoolRuntime MBean で resetConnectionPool() を呼び出したときにプールがリセットされないことが判明しました。この場合、古い接続は削除されていませんでした。 この問題は、コードを修正することで解決しました。古い接続に対応する MBean は、resetConnectionPool() が呼び出される前に登録解除されます。	6.1 SP6 8.1 SP3
CR120492 CR122551	HTTP トンネリングのパフォーマンスを向上させるため、トンネリングされる応答のコンテンツ長をセットしてキープアライブ接続を維持すると同時に、HTTP URL 接続のキャッシュを有効にするようにコードを修正しました。	7.0 SP5 8.1 SP3
CR120492 CR122551 CR171857	HTTP トンネリングのパフォーマンスを向上させるため、トンネリングされる応答のコンテンツ長をセットしてキープアライブ接続を維持すると同時に、HTTP URL 接続のキャッシュを有効にするようにコードを修正しました。	7.0 SP5 8.1 SP3
CR120811	WebLogic シン クライアントとアプレットを使用している場合に、concurrentModificationExceptions と JMSExceptions が送出されていました。調査の結果、以下の 2 つの問題があることがわかりました。 Sun ORB の実装に問題がありました。アプレットの仮想マシンがブラウザの更新で AppletContext を解放し、アプレット コンテキストのスレッド グループのすべてのスレッドを停止させていました。アプレット コンテキストの一部として ORB が初期化されると、リーダー スレッドがアプレット コンテキストのスレッド グループで作成されていました。ブラウザが更新されると、ORB のリーダー スレッドも停止されていました。 WebLogic シン クライアントは、アプレット コンテキスト グループで 2 つのスレッド (HeartbeatMonitor スレッドと RequestTimer スレッド) を作成していました。ブラウザが更新されると、それらのスレッドはアプレット コンテキスト グループの他のスレッドと一緒に停止されていました。 これらの問題は、以下の変更で解決しました。 アプレットのコンテキスト スレッド グループではなく、システム スレッド グループの子スレッド グループでリーダー スレッドが作成されるように、JDK 1.4.2_04 で Sun ORB の実装が変更されました。この変更により、orb が有効であるか、アプレットの JVM が有効である限りリーダー スレッドが有効であり続けるようになります。 WebLogic シン クライアントの TunnelResponse スレッドと HeartbeatMonitor スレッドが、アプレットのコンテキスト スレッド グループではなくシステム スレッド グループの子スレッドで作成されるようになりました。この変更により、アプレットの JVM が有効である限りそれらのスレッドが有効であり続けるようになります。この修正は、署名付きアプレットでのみ提供されます。	8.1 SP3
CR121311	使用中のリソースが原因で、サーバの停止が失敗していました。これは、アプリケーションの問題が原因で。JDBC 接続や JMS セッションなどのプールされたリソースをアプリケーションがリークしたか、サーバの停止が開始された後に、プールされたリソースへの参照をアプリケーションが保持していたかのいずれかです。 リソースが使用中でも、デフォルトでプールが停止されるようになりました。 JDBC 接続について、前の動作に戻すには、JDBCConnectionPoolMBean で ignoreInUseConnections="false" を設定します。	8.1 SP3
CR122361	監査を有効にしたメッセージに USER ID が記録されていませんでした。 <Aug 29, 2003 12:31:25 AM EDT> <Info> <Configuration Audit> <159909> <Configuration Auditing is enabled> 一方、監査を無効にしたメッセージには USER ID が記録されていました。 <Aug 29, 2003 12:31:31 AM EDT> <Info> <Configuration Audit> <159910> <USER system, Configuration Auditing is disabled> コードを修正したことで、どちらの監査メッセージにも USER ID が記録されるようになりました。	7.0 SP5 8.1 SP3
CR122706	別のクラスタの EJB を呼び出すクラスタにクラスタ化された Web アプリケーションをデプロイすると、AssertionError が送出されていました。分析の結果、インタフェース内のメソッドの計算時に、生成されたコードが正しいメソッドを使用していなかったことが判明しました。これが原因で、生成されたスタブからの誤ったクラスローダを使用していました。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR122878	MBean が KernelID によって削除されていました。このため、誰が削除操作を開始したかに関係なく、カーネルが MBean を削除したものとして記録されていました。 コードを修正したことで、現在の認証されたサブジェクトによって MBean が削除されるようになりました。	7.0 SP5 8.1 SP3
CR123509	キープアライブ機能に関連する IPlanet の変更が原因で、HTTP/1.0 リクエストに関して、t3s プロトコルを IPlanet でトンネリングする際にパフォーマンスが低下していました。この問題は、トンネリング リクエストに HTTP/1.1 を指定するようにコードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR123571 CR128843 CR183237	複数の T3 クライアントを同じマシンで同時に開始すると、2 つ以上のクライアントが同じ JVMID を取得するおそれがあり、その結果としてクライアントで例外やハングが発生していました。この問題が発生するのは、複数の T3 クライアントを同じマシンで同時に開始した場合のみです。この問題は、複数の JVMID が生成されるようにコードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR125245	PreferWebInfClasses が有効になっている場合に、複数のスレッドが Web アプリケーション内の同じクラスをロードしようとすると、java.lang.LinkageError: duplicate class definition: エラーが発生することがありました。この問題は、クラスを初めてロードする際に発生していました。 この問題は、ChangeAwareClassloader の loadClass メソッドが同期するようにコードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR125285	未処理の内部例外が原因で、WebLogic Server がアプリケーションのデプロイメント時に特定の例外を隠していました。この例外を処理するコード修正により、元の例外が再送出され、元の問題がデバッグしやすくなりました。	7.0 SP5 8.1 SP3
CR125440	WebLogic Server は、iiop リクエストの接続キーに基づいてエンドポイントをキャッシュしていました。接続キーは、接続確立時のホスト、ポート、およびタイプ情報に基づいていました。接続キーの確率方法が原因で、トンネリング リクエストは間違った Connection オブジェクトを使用していました。同じホストの複数のクライアントは、エンドポイントが違っていたので負荷テスト時に応答を受け取ることがありませんでした。 トンネリング リクエストが適切な Connection オブジェクトを使用するように、Connection オブジェクトでユニークな ID が作成されるようになりました。	8.1 SP3
CR126374	特定の実行キューに優先順位が設定されているにもかかわらず、実行スレッドの setPriority メソッドが呼び出されていませんでした。 実行スレッドが作成されたときに setPriority 呼び出すためのコードが追加されました。	8.1 SP3
CR126613	MDB の onMessage がスレッドで呼び出されたときに、そのスレッドと以前に関連付けられたトランザクションが適切にクリーンアップされなかったことが原因で次の例外が送出されていました。 weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Left-over JTA transaction found on MDB listener thread ] スレッドを使用して MDB の onMessage メソッドを呼び出す前にスレッドで古いトランザクションがクリーンアップされるようになりました。	8.1 SP3
CR127394	weblogic.jar を Ant タスク内の ClassPathElement として追加すると、weblogic.jar からのクラスのロードに AntClassLoader が使用されます。このプロセスは機能しますが、コンテキスト クラスローダがスレッドに正しくセットされていませんでした。スレッド上のコンテキスト クラスローダは、システム クラスローダのままになっていました。このため、スタブの生成時にクラスロードで問題が発生していました。 この問題は、WebLogic Server が作成する WLDeploy Ant タスクで修正されました。WLDeploy タスクを実装することで、コンテキスト クラスローダが正しくセットされます。	8.1 SP3
CR127455	管理サーバは、トリガを使用して各管理対象サーバにハートビートを送信することで、管理対象サーバが実行されていることを確認します。管理対象サーバが再起動したときには、古い管理対象サーバ用のトリガをキャンセルする必要があります。しかし、状況によっては、古い管理対象サーバ用のトリガが適切にキャンセルされない場合がありました。 コードを修正したことで、トリガが正しくキャンセルされるようになりました。	8.1 SP3
CR128417 CR134918 CR172274	サーバが TCP_NODELAY オプションを設定できるようにクライアントがソケットのリセットを行ったときに、サーバ側のソケットが IDLE 状態のままになることがありました。このため、それらの IDLE ソケットは適切にクリーンアップされていませんでした。 コードの変更により、ソケットで TCP_NODELAY オプションを設定するときに例外が発生した場合にサーバ側ソケットが確実にクリーンアップされるようになりました。	8.1 SP3
CR128445	weblogic.Admin コマンドライン ユーティリティを使用してサーバ インスタンスが起動されるたびに、ServerStartMbean のユーザ名とパスワードが設定されていました。 ユーザが weblogic.Admin を使用してサーバを起動しようとすると、WRITE 属性へのパーミッションがないために起動が失敗していました。 コードを修正したことで、ServerStart に WRITE 属性が設定されなくなりました。	7.0 SP5 8.1 SP3
CR128496	WebLogic Server 6.1 SP5 ドメインと 8.1 SP1 ドメインを相互運用しようとすると、InvalidClassException が発生していました。これは、6.1 SP5 が EJB 2.0 より前の仕様でリリースされていたのに対し、7.0 以降では EJB 2.0 仕様の最終仕様でリリースされており、この最終仕様で class javax.ejb.TransactionRolledbackLocalException が変更されていたことが原因です。このため、リリース 6.1 SP5 ドメインがこの例外を 8.1 ドメインに送信すると、ローカル クラスと着信した応答クラスの SVUID が異なるため、8.1 ドメインがこの例外オブジェクトをデシリアライズする際に InvalidClassException が発生し、例外を読み込むことができませんでした。 コードを修正したことで、一方のピアがリリース 6.1 ドメインの場合にはローカル クラスがロードされ、着信クラスに SVUID がスタンプされるようになりました。	8.1 SP3
CR128646	サーブレットの実行時に、汎用クラス ローダが WebLogic JDBC クラスを見つけることができませんでした。 この問題は、weblogic.utils.wrapper.WrapperFactory.java で JDBC クラスが null に設定されているかどうかを確認するチェック機能を汎用クラス ローダに追加することで解決しました。null に設定されている場合は、現在の classLoader(this.getClass().getClassLoader()) がロードされます。	8.1 SP3
CR129094	AIX プラットフォーム上の t3 プロトコルで TCP ウィンドウが縮小されるパフォーマンス上の問題が解決されました。	7.0 SP5 8.1 SP3
CR130376 CR133631 CR174605 CR175607 CR172366	ドキュメントの「サーバの起動と停止」の節では、CLASSPATH が長すぎる場合でも 1 行としてファイルに追加され、-classpath @filename としてアクセスできると説明されていました。しかし、beasvc が CLASSPATH ファイルの内容をロードしようとしたときに、ファイルが改行で終わらない場合に最後の文字が切り捨てられていました。 beasvc はファイルが正しく終了しているかどうかを確認し、適切にファイルを読み込むようになりました。	8.1 SP3
CR130409 CR178422	カスタム キュー上の「リソースを大量に消費する動作の遅い」リクエストを抑制するために -Dweblogic.kernel.allowQueueThrottling フラグを使用して実行キューの最大長を設定しても、クライアントは 503 応答を受け取ることなくタイムアウトを待たなければなりませんでした。 この問題は、呼び出し側でディスパッチの戻り値をチェックし、sendError() API を使用して 503 応答を返すようにコードを修正することで解決しました。	8.1 SP3
CR132704	サーブレットの Init メソッドから MBean.forceShutdown を使用し、かつ load-on-startup を使用している場合、サーバを正常にシャットダウンできず、[コントロール] タブの [このサーバを開始] ボタンも淡色表示のままになっていました。このリンクは、数分後に有効になりました。 この問題は、コードを修正することで解決しました。forceShutdown を呼び出すと、サーバのライフサイクル スレッドがハングすることなくサーバがシャットダウンされるようになりました。サーバの状態が正しく変更されるようになったため、サーバがシャットダウンししだいリンクが有効になります。	8.1 SP3
CR132994	Sun プラグインのバグが原因で、EJB のルックアップが失敗していました。しかし、このバグが原因で、WebLogic Server のバグも発生していました。 クラスタ内にサーバが 1 つしかなく、レプリカ リストが空であるにもかかわらず、別のサーバへのフェイルオーバが試行されていました。 この問題は、コードを修正することで解決しました。フェイルオーバは、レプリカ リストが空でない場合にのみ発生します。	8.1 SP3
CR135122	WebLogic Server インスタンス内のアプリケーションが同じサーバ インスタンス内の別のアプリケーションに対して RMI 呼び出しを行う際に、Call By Value (CBV) ラッパーの実装が使用されていました。CBV ラッパーの実装は、プリミティブ データ型と Date インスタンスを除くすべてのオブジェクト インスタンスの値を複製していました。 アプリケーション固有のコードが Date を派生し、Date クラスの独自の実装を提供した場合に、そのユーザ定義クラスを複製することで、オブジェクト インスタンスが別のサーバのクラスローダで作成されていました。別のサーバがそのインスタンスを呼び出し元のアプリケーションに割り当てた場合、ClassCastException が発生します。 この問題は、コードを修正することで解決されました。	8.1 SP3
CR135255	リクエストがネットワーク チャネル経由で届いた場合、サーバは JVMID の一部としてデフォルトのチャネル情報を書き込む代わりに、ネットワーク チャネルのアドレス情報を書き込みます。ストリームからのこの情報は、リクエストがデフォルトのチャネルまたはネットワーク チャネル経由で届いたかどうかを検知するために使用します。しかし、この方法ではサーバがデフォルト チャネルとネットワーク チャネルを識別できなかったため、ChunkedObjectOutputStream に EndPointStream インタフェースが実装されていませんでした。 この問題が原因で、パフォーマンスが低下していました。 ChunkedObjectOutputStream に EndPointStream インタフェースが実装されるようにコードを修正したことで、リクエストがどのチャネル経由で届いたかを JVMID クラスが識別できるようになりました。	8.1 SP3
CR135256	サーバは、ネットワーク チャネル情報ではなくデフォルト チャネルのアドレス情報を JVMID の一部として書き込んでいました。これが原因で、デフォルト チャネルがクライアントから認識できないためにクライアントが java.rmi.ConnectException を送出していました。 コードの修正により、サーバはアドレス情報を正しく書き込むようになりました。	8.1 SP3
CR136076	EJB ネットワーク チャネルでビジネス チャネルに接続することができませんでした。ネットワーク チャネルで接続リクエストを受信すると、サーバはその中にネットワーク チャネル情報を書き込むことで JVMID を正しく変換していました。しかし、サーバは rawAddress を変換してネットワーク チャネルのアドレスに基づいて計算していました。JVMID の同等性を維持するには、rawAddress を defaultChannel アドレスに基づいて計算しなければなりません。 コードを修正したことで、リクエストをネットワーク チャネルで受信した場合にも、rawAddress が常に defaultChannel アドレスに基づいて書き込まれるようになりました。	8.1 SP3
CR136250	プロキシ認証のためリクエストが再試行されたときに、HttpURLConnection が元のヘッダと Post データを送信していませんでした。その結果として、プロキシ認証が失敗していました。 コードの修正により、オリジナル リクエストのヘッダとデータが再試行時に再送信されるようになりました。	8.1 SP3
CR136756	サーバに接続しようとしたときに、クライアントが java.net.UnknownHostException 例外を送出していました。この例外は、そのクライアントがプライベート ネットワーク チャネルを持つサーバに接続したことがあるために送出されていました。新しい接続を開こうとする前に接続が存在するかどうかを判別できないときに、クライアントはこの例外を送出していました。 この問題を修正するコード修正が行われました。	8.1 SP3
CR172105 CR177136	weblogic.net.http.HttpURLConnection の setTimeout メソッドを呼び出したときに、指定した時間の倍の長さがかかる現象は解消されました。	8.1 SP3
CR172366	beasvc からイベント ログに出力されるメッセージが、日本語環境では正常に表示されませんでした。 コードを修正したことで、英語以外のすべての言語環境でも、英語のメッセージが出力されるようになりました。	8.1 SP3
CR173345	クライアントがアプレットであるかどうかを判別しようとするときに、WebLogic Server はシステム プロパティを読み取ろうとし、セキュリティ例外が送出された場合、そのクライアントはアプレットであると見なされていました。署名付きアプレットの場合はセキュリティ例外が送出されることはなく、実際にはアプレットである場合に誤って Java クライアントと見なされていました。このため、WebLogic Server は Java クライアントと署名付きアプレットを見分けることができませんでした。 コードの変更により、クライアントが署名付きアプレットであるかどうかを判断するだけでなく、WebLogic Server はアプレットのみで設定される追加プロパティを読み取るようになりました。	8.1 SP3
CR173958	フロントエンドとバックエンドの間のプロトコルを「セキュア」から「非セキュア」に変更した場合に、t3 を使用した 6.1 SP4 ドメインと 8.1 SP2 ドメインの相互運用性が正しく機能していませんでした。認証呼び出しの際に、フロントエンド QOS がバックエンドに伝播され、呼び出しに失敗していました。 この問題は、ブートストラップ認証呼び出しに「匿名」を使用することで解決しました。	8.1 SP3
CR174605	beasvc サービスは、SERVICE_CONTROL_INTERROGATE コントロール コードを受信したときにスレッド ダンプを生成していました。これが原因で、beasvc が他のツールから紹介されたときに無用なスレッド ダンプが生じる恐れがありました。 コードの修正により、カスタム コントロール コードを受信したときのみスレッド ダンプが生成されるようになりました。	8.1 SP3
CR175607	WebLogic Server をアンインストールした直後に Windows サービスとしてインストールしなおすと、誤ったレジストリ キーが作成されることがあったため、正常に起動できなくなる問題が発生していました。 コードを修正したことで、レジストリ キーがフラッシュされて正しく閉じられるようになりました。	8.1 SP3

デプロイメント

変更要求番号	説明	修正されたリリース
CR127393	この問題により、以下のメモリ リークが確認されていました。 アプリケーションをアンデプロイしても、EO オブジェクトの ClientRuntimeDescriptor がヒープに残る。 アプリケーションをアンデプロイしても、EJBCache オブジェクトがクリーンアップされない。 アプリケーションをアンデプロイしても、WebAppServletContext 固有の実行時 MBean が登録解除されない。 KeepAliveCache のタイマー オブジェクトにアプリケーション固有のクラスローダが保持される。 アプリケーションをアンデプロイしても、記述子オブジェクトが登録解除されない。 struts を使用するアプリケーションをアンデプロイしても、アプリケーション固有のクラスが Introspector キャッシュに保持されたままになる。 これらの問題は、コードを追加することで解決しました。	8.1 SP3
CR128537	weblogic.deployer ユーティリティは、Timeout パラメータが 60 分を超える値に設定されている場合でも次の例外を送出して 60 分後に終了していました。 <Error> <Deployer> <lcaix17.bea.com> <myserver> <ExecuteThread: '0' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149014> <Target myserver is not defined - error null> デプロイヤ オプションで指定されていない場合のみデフォルトのタイムアウトを使用するようにコードが修正されました。このようにして、タイムアウトが指定される場合にはデプロイメントがデフォルトの 60 分で失敗しないようになります。代わりに、タイムアウトが切れるのを待つことになります。	8.1 SP3
CR130062	weblogic.Deployer コマンドがラッパー クラスから使用されると、複数のドメインへのデプロイメントでエラーが発生するおそれがありました。これは、スレッド上に正しく認証されたサブジェクトがないのに、RMI 呼び出しが実行されることが原因でした。 コードを修正したことで、正しく認証されたサブジェクトが、デプロイメント アクティビティが完了するまで保持されるようになりました。	8.1 SP3
CR130592 CR133154 CR135864	管理対象サーバ独立 (MSI) モードの管理対象サーバでは、J2EE モジュールのタイプを識別するためのロジックでローカルまたはステ－ジングされたアプリケーションが使用されていませんでした。この問題は、サーバが J2EE モジュール タイプを識別できない結果として MSI モードで現れていました。 管理対象サーバの config.xml ファイルにオリジナル パスが存在しない場合は、stagingLocation を使用して J2EE モジュールのタイプを識別するようになりました。	8.1 SP3
CR132685	EJB モジュールは、キー化された実装クラスから派生した実装クラスを持つすべての EJB 名のリストに実装クラスをマッピングするためのマップを保持しています。このマップは、再デプロイメントの際に使用します。 この実装に以下の 2 つのバグがありました。 不必要なマップが EJB モジュールに保持されていた。 マップ内のリストに同じ EJB 名が繰り返し追加されていた。 これらのバグにより、EJB コンテナがより多くのメモリを消費し、サーバのメモリが枯渇する原因となっていました。 不必要なマップは削除され、まだリストに追加されていない EJB 名のみが追加されるようになりました。	8.1 SP3
CR133764	アプリケーションは展開 ear として正常にデプロイされ、META-INF ディレクトリにはリスナ クラスが定義されている weblogic-application.xml ファイルが格納され、リスナ クラスは APP-INF ディレクトリに配置されていました。拡張テンプレートが config_builder.cmd を使用して作成された後、作成された .jar ファイルから META-INF ディレクトリと APP-INF ディレクトリが失われて、アプリケーションをデプロイすることができませんでした。 この問題を修正するコード修正が行われました。	8.1 SP3
CR133864	wlconfig および wldeploy Ant コマンドを使用してアプリケーションをデプロイすると、デプロイメント タスクがハングしていました。 RMI キュー スレッドが、デプロイメントの実行中にタスクの完了をポーリングしないようにコードを修正しました。	8.1 SP3
CR134856	[デプロイ] タブの [停止] をクリックした後に、クラスタにデプロイされた Web アプリケーションの現在の状態が Administration Console に正しく表示されていませんでした。 この問題を修正するコード修正が行われました。	8.1 SP3
CR134938 CR137390	アプリケーションのアンデプロイ時にクラスローダの問題が発生していました。J2EE コンテナにはアプリケーション固有のクラスローダとクラスローダ ツリーが保持されており、これを使用してアプリケーション クラスとモジュール固有のクラスをロードします。アプリケーションに対してアンデプロイ コマンドが発行されると、クラスローダ内のモジュールをロールバックする前にクラスローダとクラスローダ ツリーを閉じていたため、サーブレットの destroy() メソッドから参照されているクラスで NoClassDefFoundError エラーが初めて発生していました。これは、サーブレットの destroy() がその特定のモジュールの rollback() から呼び出されていたためです。 クラスローダ内のモジュールをロールバックする前にクラスローダが閉じられないようにコードを修正しました。	8.1 SP3
CR135145	仮想ホストを対象とする Web アプリケーションを含んだアプリケーションは、デフォルト Web サーバを対象にしていないにもかかわらず、デプロイメントの実行中にデフォルト Web サーバ上の既存のアプリケーションを検索していました。このため、他のアプリケーションが同じコンテキスト パスでデフォルト Web サーバにデプロイされていると、仮想ホストのコンポーネントのデプロイに失敗していました。 デフォルト Web サーバを対象にしていないアプリケーションが、デフォルト Web サーバ上の既存のアプリケーションを検索しないようにコードを修正しました。	8.1 SP3
CR136885	サーバの起動時に、すべてのアプリケーションがステージングされていました。これには、現在のサーバで必要とされていないアプリケーションも含まれていました。この問題は config.xml ファイルの Application スタンザの StagedTargets プロパティのエントリから確認され、ステージ ディレクトリでは利用可能なすべてのアプリケーションがステージングされていました。 この問題を修正するコード修正が行われました。現在のサーバで必要なアプリケーションのみステージングされます。	8.1 SP3
CR175858	Administration Console でアプリケーションを削除しても、ステ－ジングされたディレクトリは削除されませんでした。 コードの修正により、ステージングされたディレクトリがアプリケーションの削除後に削除されるようになりました。	8.1 SP3

EJB

変更要求番号	説明	修正されたリリース
CR090405 CR091204	WebLogic Server では、新たに java.net.URL リソース接続ファクトリがサポートされました。これにより、EJB が java.net.URL リソース接続ファクトリを使用して、WebLogic Server 環境の外にある Web サーバへの HTTP 接続を取得できるようになりました。 この機能は、以下の方法でサポートされます。 Bean プロバイダで res-type java.net.URL の直接 URL が指定される場合は、指定された jndi-name で URL オブジェクトが作成され、java:comp/env にバインドされます。Bean プロバイダは、次のように (この場合は weblogic-ejb-jar.xml で) jndi-name を宣言します。 <resource-description> <res-ref-name>url/MyURL</res-ref-name> <jndi-name>http://www.rediff.com/<;;/jndi-name> </resource-description> Bean プロバイダは、有効な URL ではない文字列を提供します。Weblogic Server では、この文字列を、URL にマッピングされていて JNDI ツリーにもバインド済みのオブジェクトとして処理します。この場合、LinkRef がその jndi-name にバインドされます。 <resource-description> <res-ref-name>url/MyURL1</res-ref-name> <jndi-name>firstName</jndi-name> </resource-description> この URL には、Bean コード内の次のようなコードでアクセスできます。 URL url = (URL) context.lookup("java:comp/env/url/MyURL"); connection = (HttpURLConnection)url.openConnection();	7.0 SP6 8.1 SP3
CR103038	weblogic-ejb-jar.xml の <allow-remove-during-transaction> 要素が「False」に設定されていて、アプリケーションがトランザクションに参加しているステートフル セッション Bean を削除しようとした場合に、不適切な例外が送出されていました。 weblogic.ejb20.locks.LockTimedOutException は EJB 2.0 仕様では適切な例外ではなく、必要な例外 javax.ejb.RemoveException で置き換えられました。	8.1 SP3
CR108169	Administration Console を使用して EJB デプロイメント記述子を編集する際、誤ったメソッド名が表示されていました。 正しいメソッド名が表示されるようになりました。	8.1 SP3
CR109267	コンテナ管理の永続性と自動キー生成でエンティティ EJB を使用する場合に、一部の XA JDBC ドライバの使用時に次のエラーが送出されていました。 XAER_RMERR : A resource manager error has occurred in the transaction branch 自動キー生成のコードを変更することで、この問題は解決されました。	8.1SP3
CR110440	結合された (アプリケーション レベルの) キャッシュのエンティティ キャッシュ タイムアウトでは、いずれかの Bean の idle-timeout-seconds が 0 に設定されていると、idle-timeout-seconds> 0 に設定されている他の Bean もタイムアウト後にキャッシュから削除されていませんでした。 この問題は、idle-timeout-seconds の登録に関係するコードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR122524	schemaName が tableName で指定されていないと、DatabaseMetaData から tableName を取得する際に間違った文字列が渡されていました。 schemaName が tableName で指定されていなくても、DatabaseMetaData から tableName を取得する際に正しい文字列が渡されるようにコードを修正しました。	8.1 SP3
CR123213	ステートレス セッション Bean が、BMP ejbRemove から呼び出された場合にはフリー プールに返されていませんでした。このため、プールのサイズが最大値に達し、インスタンスの取得を待機している間にタイムアウトしていました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR125501	クライアントで EJB を削除して同じ主キーを持つ新しい EJB を作成した場合に、状況により WebLogic Server から Illegal Reentrant call error が送出されることがありました。 この問題を解決するコード修正が実装されました。	8.1 SP3
CR127187	cmp11 Bean について、バックグラウンドでのデータベースの削除が原因で、CacheFullException が送出されていました。 EJB を作成する際、キャッシュに Bean を挿入する前に、それがキャッシュ内に存在しているかどうかをチェックするように変更しました。これにより、バックグラウンドでのデータベース更新が原因で、キャッシュの状態が同期しなくなるおそれがなくなりました。 バックグラウンドでデータベースを更新しても、キャッシュの一貫性が維持されるようになりました。	8.1 SP3
CR127397 CR131629	ActivatableServerRef を使用するリモート オブジェクトで問題が発生していました。 エンティティ Bean は ActivatableServerRef を使用します。 ActivatableServerRef は、deactivate を呼び出した Bean メソッドを呼び出した後、activate を呼び出して Bean インスタンスを取得していました。deactivate では、Bean をプールにリリースしていました。しかし、状況によっては activate しか呼び出されない場合もありました。その場合、deactivate が呼び出されないため、Bean はリリースされていませんでした。 activate および deactivate の呼び出しは使用しないことになりました。ActivatableServerRef は、notifyRemoteCallBegin および notifyRemoteCallEnd を明示的に呼び出すように変更されました。	8.1 SP3
CR127872 CR135787	オプティミスティックな同時実行性を使用する EJB の enable-batch-operation が true に設定されていると、java.sql.BatchUpdateException: ORA-01006 または java.lang.ArrayIndexOutOfBoundsException が送出され、述句に null のパラメータがあるクエリと述句に null でないパラメータがあるクエリがバッチとして届いていました。 クエリがバッチ処理に適合しているかどうかをチェックするようにコードを修正しました。クエリが適合していない場合はバッチ処理がオフになり、クエリは複数の UPDATE 文を使用して実行されます。次のような警告メッセージがサーバ ログに送信されます。 <Apr 27, 2004 11:25:12 AM PDT> <Warning> <EJB> <BEA-011078> <The CMP EJB UserSession has enable-batch-operations set to true, however the update queries are not suitable for batching.Batched operations are turned off for this batch and the queries shall be executed with mutliple update statements.>	8.1 SP3
CR128063	MDB がサスペンドしたトランザクションを後で再開すると、別のスレッドでコミットまたはロールバックされていました。そのため、一部の XA 実装で問題が発生していました。 MDB コンテナを修正したことで、トランザクションが同じスレッドで開始およびコミットされるようになりました。	8.1 SP3
CR128956 CR133894 CR154779	JNDI 名が同じ 2 つの JMS ターゲットがドメインにある場合に、MDB のデプロイメントは同じ名前で 2 つの MDB プールを作成しようとしていました。その結果、同じ名前の 2 つの MessageDrivenEJBRuntimeMBeanImpl オブジェクトを作成しようとして、Instance Already Exists 例外が送出されていました。 この問題は、MDB 記述子で <provider-url> スタンザを指定したときに、それが外部 JMS プロバイダとして扱われるようにコードを修正することで解決しました。また、分散送り先または移行可能な送り先の最適化を実行するときに、現在のサーバまたは現在のクラスタと関連する JMS ターゲットのみが考慮されます。 他のクラスタの JMS ターゲットは考慮の対象になりません。 このようにして、ドメイン内の異なるクラスタの異なる JMS 送り先で JNDI 名が再利用されても MDB のデプロイメントは失敗しません。 また、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「MDB のデプロイメント オプション」で説明されているように、分散送り先や移行可能な送り先の最適化を行うには、MDB の記述子で <provider-url> スタンザを指定しないようにしてください。	8.1 SP3
CR128980 CR135722	MDB で同期式のメッセージ ポーリングが使用される場合、TIBCO JMS サーバが使用されると問題がありました。具体的には、受信されるメッセージの遅延の結果として、MDB コンテナのポーリングが最適化される恐れがありました。 最適化されたポーラーが使用されないようにコードが修正されました。TIBCO のメッセージ配信方式はこの方式ではうまく機能しないので、MDB では TIBCO JMS サーバを連続的にポーリングするポーラーが使用されるようになっています。また、そのようなポーラーは排他的なスレッドを必要とするので、MDB でディスパッチ ポリシーが指定されている場合は、この修正によりポーリングのための十分なスレッドが確保されます。あるいは、MDB の記述子で Bean の最大数を調整することもできます。 注意 : この修正は TIBCO JMS にのみ適用されるので、他の外部 JMS サーバは従来のメカニズムを継続して使用します。したがって、TIBCO 以外の外部 JMS サーバを使用する MDB の動作に変更はありません	8.1 SP3
CR129035 CR132804	CMP20 Bean が MS SQL Server データベースと自動キー生成を使用している場合で、delay-db-insert-until 要素が ejbPostCreate に設定されている場合、正確な ID セットを持たないエンティティ ローカル オブジェクトが関係セットにキャッシュされていました。この識別不能なエンティティ ローカル オブジェクトは、CMR フィールドでゲッター メソッドが呼び出されたときに返され、それが原因で ClassCast 例外が送出されていました。 この問題は、Bean で create を呼び出す前に dummyPK をエンティティ オブジェクト/エンティティ ローカル オブジェクトと関連付け、PK がわかった場合にそれを正確な ID に置き換えることで解決しました。	8.1 SP3
CR129185	WebLogic Server では、オプティミスティックな同時実行性 Bean を別のトランザクションにロードしていました。その際、現在のトランザクションをサスペンドして新しいトランザクションを開始し、オプティミスティックな同時実行性 Bean をロードして Oracle 以外のすべてのデータベースの古いトランザクションを再開していました。この動作は、SELECT の間にロックを取得するのを避けるためでした。しかし、Sybase のデフォルト動作では SELECT の間に共有ロックを取得しますが、文が完了する前でもリリースする必要があるため、上記のロード動作を変更しました。同時実行性 Bean がオプティミスティックである場合は、アイソレーション レベルが Read-Uncommitted または Read-Committed より高いときにのみ、Oracle 以外のデータベースのトランザクションをサスペンドおよび再開します。	7.0 SP5 8.1 SP3
CR129223	Optimistic 同時方式と cache-between-transaction を使用する CMP20 EJB が、多対多の関係では失敗していました。 cache-between-transactions 要素が true に設定されている場合、Bean は生成された多対多セットと一緒にキャッシュされ、それが原因で新しいトランザクションがキャッシュされた Bean、つまりキャッシュされたセットを使用していました。 セット内の以前にキャッシュされた値はクリアされず、したがってトランザクションの最後で M2NJoinTable の挿入が実行されるときに、ORA-00001: unique constraint violated error で失敗していました。 つまり、重複したキーを使用してレコードが挿入されようとしていたのです。 多対多セットはトランザクションごとに保持されるので、キャッシュされている多対多セットを新しいトランザクションでクリアすることでこの問題は解決しました。	8.1 SP3
CR129379 CR136730	EJB トランザクションが数多くのエンティティを新規に作成した場合や、JDBC を使用する数多くの Bean に EJB トランザクションが関係付けられている場合には、Oracle カーソルが枯渇するおそれがありました。これは、Oracle ドライバのバグと思われる現象を回避するため、WebLogic Server がトランザクションが終了するまで JDBC 文を閉じるのを遅らせてそのカーソルを保持していたためです。 この動作を変更したことで、トランザクションが終了するまでカーソルを保持する必要はなくなりました。	7.0 SP5 8.1 SP3
CR131848	BMP bean.java.rmi.RemoteException: EJB の「cache-between-transaction」が true に設定されていると、実行時に ClassCastException が送出されていました。 BMP および CMP20 Bean のチェックを追加したことで、ClassCastException は送出されなくなりました。	7.0 SP5 8.1 SP3
CR133602	WebLogic Server では、XAConnection を使用する場合に、SonicMQ バージョン 4.* 用の特別な処理コードを使用していました。このコードは Sonic 5.* バージョンでは必要なく、使用すると接続リークが生じていました。 コードの修正で、接続リークは解消されました。	7.0 SP5 8.1 SP3
CR133774	weblogic-application.xml DTD での max-beans-in-cache 要素の説明に誤りがありました。説明では、0 を指定すると max-beans-in-cache は無制限になるとされています。しかし、max-beans-in-cache を 0 に設定した場合、実際にはキャッシュ サイズも 0 に設定されるため、CacheFullException が発生していました。 上記の説明は DTD から削除されました。また、適合性チェックを追加することで、weblogic-application.xml の max-beans-in-cache が 0 に設定されないようにしました。キャッシュ サイズを大きく (無制限に) する必要がある場合は、デプロイメント記述子内の max-beans-in-cache の値を java.lang.Long.MAX_VALUE に設定します。これにより、weblogic-ejb-jar.xml 内の同じ要素の動作に適合します。	8.1 SP3
CR134082	セッション Bean (ステートフル、ステートレス共) およびメッセージ駆動型 Bean の Marathon General Panel に trans-timeout-seconds プロパティが含まれていませんでした。 このプロパティを、すべての EJB の General Panel に追加し、エンティティ Bean の Persistence Panel から削除しました。	8.1 SP3
CR135410	Bean をルックアップして初めてビジネス メソッドを呼び出す場合、ejbStore からの EntityContext.getCallerPrincipal() への呼び出しではユーザが「anonymous」として返されていました。その後、ejbStore を再度呼び出すと、正しいユーザ名が返されました。これは ejbStore 固有の問題であり、他のメソッドでは発生しません。 この問題は、コードを修正することで解決されました。	8.1 SP2 8.1 SP3
CR174119	cache-between-transaction 要素が true に設定されている場合、トランザクションがロールバックされると、Bean は無効になりますがそのままキャッシュに残っていました。また、cache-between-transaction が true の場合は、Bean がキャッシュ内にあるかどうかを findByPrimaryKey 実装がチェックしていました。したがって、無効な状態にある場合でも、Bean はキャッシュから再利用することができました。また、リモート メソッドが呼び出されたときにこれを返してロードすることも可能でした。 データベースから Bean をロードすると、トランザクションがすでにロールバックされていてデータベース内に行が存在しないことが原因で NoSuchObjectException が送出されていました。このため、無効な Bean が有効になってキャッシュから返されていました。 現在は、findByPrimaryKey で Bean がすでにキャッシュにあるかどうかを確認するときに、準備のできている Bean と有効な Bean のみがチェックされ、キャッシュ チェックで無効な Bean が返されないようになっています。キャッシュで Bean が見つからないと、findByPrimaryKey はデータベースに対してクエリを実行します。データベースで Bean が見つからない場合は、FinderException が送出されます。	8.1 SP3
CR174845	特定の条件のもとでは、read-timeout-seconds の時間を経過した後も ReadOnly エンティティ Bean がリフレッシュされていませんでした。 Bean がタイムアウトになるか無効になった場合にのみ、Bean の初期化、resultSet からのロード、および lastLoadTime の設定を実行するようにコードを修正しました。	8.1 SP3

インストール

変更要求番号	説明	修正されたリリース
CR103125 CR172837	beasvc に追加された「-log:C:/temp/xxx.log」オプションに問題がありました。 このオプションを使用すると、すべての stdout/stderr がログ ファイルにリダイレクトされます。プロダクションでは、このファイルがすぐにかなりのサイズまで大きくなっていました。 Windows では、このファイルをコピーしたり、ファイル名を変更したりすることはできませんでした。 Windows サービスでこのログ ファイルをローテーションするためのコードを追加しました。 詳細については、http://edocs.beasys.co.jp/e-docs/wls/docs81/adminguide/winservice.html を参照してください。	6.1 SP6 8.1 SP3
CR107512	プロキシで Smart Update を使用することには問題がありました。Smart Update のプロセスにおいて、ハードコード化されたプロキシ設定が引き継がれないか、認識されていませんでした。 現在は、appBoot から Smart Update ユーティリティに以下のコマンドライン システム プロパティを自動的に渡すことでプロキシがサポートされています。 http.proxyHost http.proxyPort http.proxySet https.proxyHost https.proxyPort https.proxySet ログの優先順位の設定も、Smart Update に渡されるようになっています。	8.1 SP3
CR121882	tmp ファイルシステムが小さすぎるか、一杯である場合に、汎用の UNIX インストーラが紛らわしいエラー メッセージを送出していました。 -Djava.io.tmpdir プロパティの設定先を十分なスペースがあるファイルシステムとするようにコードが変更されました。	8.1 SP3
CR125514	config_builder.sh スクリプトが実行されたときに、Configuration Template Builder が起動せず、「Unable to instantiate GUI, defaulting to console mode」というメッセージが生成されていました。しかし、コンソール モードで起動することはなく、コマンド プロンプトに戻っていました。 これは、正しい動作です。ただし、現在では、コンソールが「The Configuration Template Builder is not supported in console mode」というメッセージを示すようになっています。 Configuration Template Builder は、グラフィカル モードでのみ起動できます。したがって、Configuration Template Builder を実行するマシンにアタッチされたコンソールは、Java ベースの GUI をサポートしている必要があります。Windows ベースのコンソールはすべて Java ベースの GUI をサポートしています。UNIX ベースのコンソールで Java ベースの GUI をサポートしているのは一部のものだけです。詳細については、『コンフィグレーション ウィザードの使い方』の「WebLogic Configuration Template Builder の開始」を参照してください。	8.1 SP3

J2EE

変更要求番号	説明	修正されたリリース
CR107166	EJB 実装が継承されるカスタム クラスローダ構造を使用すると、NoClassDefFound エラーが生じていました。 この問題は、モジュール クラスローダを実装クラスローダの親として設定することで解決しました。	8.1 SP3
CR112618	$CLASSPATH に weblogic.jar がないと、wlcompile が失敗していました。 wlcompile が、Ant タスクの taskdef で参照されている weblogic.jar ファイルを検出するためのコードが追加されました。	8.1 SP3
CR125191	アプリケーション パスが相対パスで、JVM user.dir が WebLogic ルート ディレクトリと同じでない場合、デプロイメントでアプリケーション パスが正しく解決されていませんでした。 現在は、weblogic.RootDirectory パスを使用して相対パスを解決するようになっています。	8.1 SP3
★ＯCR125191Ｏ★	BootStrap.apply() が、J2EEutils.getDeploymentCategory() で使用されていませんでした。 パスが存在しない場合、BootStrap.apply() を呼び出すことで、SlaveDeployer.resolveStagingPath() を使用して正しくパスが解決されるようになりました。	8.1 SP3
CR126403 CR134398	100 個以上のモジュールからなるアプリケーションをデプロイすると、デプロイメントに非常に長い時間がかかっていました。これが、サーバの起動時間を長くする原因にもなっていました。 J2EEApplicationContainer コードが、特定の条件をアサートし、このアクティビティの一部として文字列を組み立てようとしていました。 コードを追加したことで、デプロイメント時にサイズの大きい不必要な文字列は生成されなくなりました。	8.1 SP3
CR137465	すべてのリスナでたった 1 つのクラス ファインダが使用されていたので、それは各呼び出しでリセットされていました。 そのクラス ファイルでは、最後のリスナの URI しか使用できませんでした。 URI のエントリごとに新しいクラス ファインダが作成され、それをアプリケーション クラスローダで利用できるようにコードが修正されました。	8.1 SP3
CR173871	大きな EAR ファイルをコンパイルすると、appc コンパイラでメモリが枯渇していました。 現在は、生成された EJB ファイルのコンパイルはデフォルトでインラインで行われるようになっています。この修正以前のデフォルトの動作では、コンパイラ プロセス (デフォルトでは javac) が生成されていました。この動作では、ExtraEJBCOptions に -J オプションを指定しなければならない場合があるため、これを生成されたコンパイラ プロセスに渡していました。インラインでのコンパイルに変更された後のデフォルトの動作では、ExtraEjbcOptions に -J オプションを指定する必要はなくなりました。	8.1 SP3

JCOM

変更要求番号	説明	修正されたリリース
CR095485	ロードの間に閉じた COM オブジェクトが原因で、ソケットが CLOSE_WAIT 状態のままになるおそれがありました。 ソケットを、endOfStream で閉じるように変更しました。	7.0 SP5 8.1 SP3
CR172074	サブジェクトと関連付けられたスレッド コンテキスト オブジェクトが null の場合に、jCom は NullPointerException を送出していました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR182512	Microsoft Security Bulletin MS04-011 が適用されたときに、COM to Java クライアントで障害が起きていました。 この問題は解決されています。	8.1 SP3

JDBC

変更要求番号	説明	修正されたリリース
CR099912	HighestNumUnavailable がデフォルトで 0 に設定され、そのことが原因で、一度にすべてをテストおよび解放するためにアイドル状態のすべての接続がロックされていました。この状態では接続が必要以上に長く保持され、適切にサイズ設定されていると思われるプールから予期しない ResourceException が送出されていました。 新しいコードにより、HighestNumUnavailable が接続を一度に 1 つずつテストおよび解放するようになりました。secondsToTrustIdleConnection という新しいコンフィグレーション可能属性も追加されました。この属性を使用すると、設定された秒数内で使用されている場合は接続のテストをスキップすることができます。	8.1 SP3
CR108826	WebLogic Server のマルチプールで、時間ベースのフェイルオーバを定義するオプションが提供されていませんでした。セカンダリ接続プールへのフェイルオーバがトリガされる正確な状況があいまいになっていました。有効な接続がないと判断するまでに、プールのすべての接続を確認していました。プライマリ データベースがダウンした場合は、接続がセカンダリ データベースにフェイルオーバされるまで不明の時間待つ必要がありました。 接続をプライマリ データベースに返す前に時間のチェックを実行するオプションが提供されるように、コードが追加されました。「JDBC マルチプールのフェイルオーバ機能の拡張」を参照してください。	7.0 SP5 8.1 SP3
CR111231 CR128673	以前のリリースの WebLogic Server では、JDBC Tx データソースで BLOB カラムが使用されたときにメモリ リークが発生していました。 コードを修正して問題は解決されました。	6.1 SP6 7.0 SP4 8.1 SP3
CR120411	アプレットがデータソースを介して接続を行い、そのアプレットが強制終了された場合に、WebLogic Server はリーク検出メッセージを出力していました。そのメッセージは誤って送信されることがあり、JDBC/WLS のログ用に正しくフォーマットされていませんでした。 現在は、接続リークが検出されると JDBCLogger を使用してメッセージがフォーマットされます。	8.1 SP3
CR120455	WebLogic Server 6.1 サービスパック 2 でメモリ リークが見つかりました。このリークは、WebLogic XA ドライバを使用するデータベースで TxDataSource を使用して BLOB カラムにアクセスするときに発生していました。この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR120533	JDBC ログの名前が「.log」をサフィックスとして指定された場合に、JDBC のロギングが期待通りにローテーションされていませんでした。WebLogic Server が再起動されたときに、前のログ ファイルが新しい JDBC ログで上書きされていました。 問題を修正するために、JDBCService.initLog() が修正されました。	8.1 SP3
CR124017	Informix データベースで PoolShrinking が有効な場合に、XAConnectionPool が SQLException で失敗していました。 JDBC XAConnection ラッパー コードの修正で、この問題は解決されました。	8.1 SP3
CR124933	Oracle の BLOB が、再割り当てできると接続プールによって判断された後にプール内の接続を使用することがありました。 プールの接続を閉じるか、トランザクションを終了する前に BLOB が完全に処理されるようにするコードが追加されました。	8.1 SP3
CR125844	idle-connection-timeout をコンフィグレーションすると、意図しないスレッドのブロックまたはデッドロックが生じることがありました。その理由は、idle-timeout の期間に変更がないが、DBMS の応答を依然として待っている接続を JDBC プールが再利用しようとする場合があるからです。 JDBC プールがアイドル状態の接続を正しく認識するようにコードが修正されました。 注意 : idle-connection-timeout のコンフィグレーションの目的は、常軌を逸したトランザクションやデッドロックのトランザクションを停止することではありません。	8.1 SP3
CR126808	それぞれに 1 つのアプリケーション スコープのデータソースを持つ 2 つのアプリケーションが同じサーバにデプロイされており、それらのデータソースの名前が同じ場合は、InstanceAlreadyExistsException が送出されていました。 必要に応じてプール名がアプリケーション固有になるようにコンフィグレーションするためのコードが追加されました。	7.0 SP5 8.1 SP3
CR126950 CR174756	コストベースのオプティマイザで Oracle STATS パッケージを実行するなどして DB 側のカーソルが破棄された場合に、WLS 側の JDBC 接続のキャッシュされている PreparedStatement が無効になっていました。 このシナリオが原因で例外が送出された場合に備えて、PreparedStatement のキャッシュを WebLogic Server で透過的にクリアする手段はありませんでした。WebLogic Server が再起動されるか、WebLogic Server Administration Console または JMX の呼び出しによってキャッシュがクリアされるまで、WebLogic Server のキャッシュにある PreparedStatement は無効なままでした。 現在は、エラーが発生したときに PreparedStatement のキャッシュがクリアされるようになっています。	8.1 SP3
CR127615 CR161930	直接的にどの接続も参照していない一方で、ステートメントのマップは含まれた状態の「ConnectionEnv」オブジェクトが、接続プールに保持されたままになっていました。結果として、それらのステートメントに保持される、ステートメントを作成した接続への参照とデータベース オブジェクトの階層構造も解放されていなかったため、メモリ リークが発生していました。 このような ConnectionEnv オブジェクトを適宜解放するコードを追加して、メモリ リークを解消しました。	8.1 SP3
CR127720	新しいバージョンの JDBC ドライバは、接続のトランザクションの状態を追跡します。接続でローカル トランザクションがアクティブな場合、その接続で XA の操作は実行できず、xa_start() が呼び出されたときに XAER_PROTO または XAER_RMERR が生じていました。結果として、アプリケーションでは、ローカル トランザクションを開始したが終了していないコード中の場所を絞り込む冗長なプロセスを実行しなければなりませんでした。 この問題は、特殊な XA 接続がプールに 2 度解放されないように回復メソッドのコードが修正されて解決しました。	7.0 SP5 8.1 SP3
CR127891	接続リーク ファイルのフォーマットが、情報が読みやすくなるように修正されました。	6.1 SP6 8.1 SP3
CR128117	複数の名前で JNDI ツリーにバインドされるようにデータ ソースをコンフィグレーションできるようになりました。1 つの JDBC 接続プールを指し示す複数のデータ ソースをコンフィグレーションする代わりに、複数名のデータ ソースを使用できます。 詳細については、Administration Console オンライン ヘルプの「複数の名前を持つデータ ソースの JNDI ツリーへのバインディング」を参照してください。	8.1 SP3
CR128156 CR134273 CR161930	プール内の JDBC 接続を置換するコードが置換されたオブジェクトのすべての参照を完全に削除しなかったので、接続の置換のたびにメモリが大きくなっていました。この問題は、getVendorConnection() メソッドの使用時に確認されていました。 現在は WebLogic Server がプール内の接続を置換したときに、その置換は他のオブジェクトから参照されないようになっています。これで、置換された接続がガベージ コレクションできるようになります。	8.1 SP3
CR128419 CR132944	正常な停止の過程で、jdbc.log への BufferedOutputStream が完全にフラッシュまたはクローズされず、バッファでデータの損失が生じる恐れがありました。 BinaryOutputStream が JDBCService.prepareToSuspend() メソッドの closed() でクローズされるようにコードが修正されました。	8.1 SP3
CR128545	Informix で、テーブル名に大文字が含まれている場合に、RowSet のバッチ更新が失敗していました。Informix では、すべてのメタデータ名で小文字が使用されます。WebLogic Server の RowSet の実装は、メタデータに依存してバッチ更新を行います。 WebLogic Server の RowSet の実装は、Informix JDBC ドライバを使用するときにメタデータ名を小文字に変換するようになりました。	8.1 SP3
CR130306	jta.DataSource で refreshAndEnlist を実行するときに、WebLogic Server が tx.enlist() を呼び出していましたが、refreshAndEnlist の呼び出しで例外が発生した場合に接続がプールに返されていませんでした。 コードの修正により、例外が捕捉され、接続がプールに解放されるようになりました。	7.0 SP5 8.1 SP3
CR131575	JDBC 接続リークに関する以下のような偽りの警告が送出されることがありました。 [SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n この警告を送信するリーク検出コードは、現在は廃止されています。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR131702	負荷が高い状態で接続プールをリセットしようとしたときに、DataSource.commit() と RESET_POOL の間でデッドロックが生じていました。 weblogic.jdbc.common.internal.ConnectionPool.reset() メソッドで、接続プールは更新される前にサスペンドされ、その後に再開されてデッドロックが回避されるようになりました。	8.1 SP3
CR132293 CR134921	特定の JDBC 接続では、実行中の文が復帰するのをドライバが待たなければならなくて、トランザクションをロールバックする呼び出しが直ちに処理されていませんでした。 この遅延が起きないようにするために、WebLogic Server が進行中のトランザクションをロールバックする過程にあるときには、Statement.cancel() を呼び出して実行中の文をすべて中止するようにするコードが実装されました。	8.1 SP3
CR132675	特定トランザクション内のすべての非 XA 接続に対する isClosed() メソッドで、いずれかの接続に対する Connection.close() 呼び出しの後に true が返されていました。 トランザクションに参加しているすべてのユーザに同じ基底の接続の独立したラッパーを提供するようにコードが修正されました。	8.1 SP3
CR132839	test-connections-on-reserve が有効で、アイソレーション レベルが TransactionReadCommitted の場合、顧客が Ingres ドライバを使用しているときに SQLException が発生します。EJB のトランザクション アイソレーション レベルは、TRANSACTION_READ_COMMITTED です。この EJB を呼び出すと、「SQLState(25000) vendor code(5932) ca.edbc.util.EdbcEx: SET TRANSACTION: This statement is not allowed.」という SQLException でデータベース接続が失敗します。 DBMS ロックをすでに保持している接続で失敗していた呼び出しが成功するようになったことを除いて、変更はありません。	8.1 SP3
CR134364	ResourcePoolMaintanenceTask がアクティブではないすべてのリソースをタイムアウトにするときに、同期の問題 (デッドロックではない) が発生していました。ResourcePoolMaintanenceTask は接続プールのロックを取得して、それからすべての接続を確認していました。 しかし、その時点で接続がアクティブであり、別のオブジェクトでロックされている場合、ResourcePoolMaintanenceTask はそのロックを取得するのに待たなければなりませんでした。その結果として、速度が低下し、エンド ユーザにとってはサーバが「フリーズ」したようになっていました。タスクは完了しますが、時間が非常に長くかかっていました。 コードの修正により、接続プール全体がロックされることがないようになりました。 この問題は、タイムアウト値をゼロに設定して再利用プロセスをオフにすることでも回避できます。	8.1 SP3
CR135116 CR172353	WebLogic Server が予期せずに JTS 接続の自動コミット モードを変更していました。この問題は、WebLogic Server が予約時の接続テストに失敗したときに発生していました。JTS 接続はグローバル トランザクションを受け入れ、接続はユーザ トランザクション内にあるので、ユーザ トランザクションの境界が尊重されなければなりません。さらに、接続テストはユーザにとって暗黙の動作でなければなりません。以前のリリースでは、そうではありませんでした。 この問題は、コードを修正することで解決されました。	8.1 SP3
CR136624	JDBC 接続プールの接続作成の再試行頻度が接続の再試行を有効にするように設定されている (つまり 0 以外に設定されている) 場合、接続作成の再試行ロジックはアプリケーションが接続を予約しようとしたときに呼び出されていました。データベースが利用できない場合は、待機と再試行のサイクルの過程でスレッドがハングしていました。 接続予約要求は以前のリリースのように成功するか、すぐに失敗するようになっています。	8.1 SP3
CR136681	wlconfig ant タスクが、プールを正しく削除していませんでした。この問題は、JDBC 接続マネージャのコード内にあります。 この問題は、コードを修正することで解決されました。	8.1 SP3
CR136746	JDBC ドライバの明示的なネーミングをクラス VendorId で使用できるようにする拡張要求。 この顧客拡張は、コードの修正を通じて実現されました。	6.1 SP7 8.1 SP3
CR137180	81SP1 から 81SP2 へのアップグレードにおける weblogic.jdbc.vendor.oracle.OracleStatement の変更で、Oracle 9 ドライバの互換性が失われました。インタフェース weblogic.jdbc.vendor.oracle.OracleStatement のメソッド getDBDescription() の戻り値の型が、81SP1 の DBColumn[] から 81SP2 の Object[] に変更されました。この変更により、顧客が java.sql.Statement オブジェクトを動的プロキシでラップしたいときに 81SP2 が Oracle 9 ドライバと互換性がなくなるようになってしまいました。 この問題は、コードを修正することで解決しました。OracleStatement.java において、getDBDescription および getBinds の 2 つの非サポート メソッドについてそのリファレンスが削除されました。	8.1 SP3
CR174025	JDBC 接続プールの「パージ ポリシー」を求める要求に対応して、StatementTimeout 属性と TestStatementTimeout 属性が JDBC 接続プールに追加され、JDBC 接続プールからのデータベース接続で文を実行できる時間を制限できるようになりました。 詳細については、『WebLogic JDBC プログラマーズ ガイド』の「JDBC 接続プールのテスト機能の拡張」を参照してください。	8.1 SP3
CR174126	複数の異なる Prepared Statement を 1 つのトランザクションで使用すると、XA 対応の Statement キャッシュでバグが発生し、閉じられていない JDBC 文のハンドルが失われていました。このことが原因で、Oracle のすべての利用可能なカーソルがすぐに消費およびリークされていました。 XA 対応の Statement キャッシュを実装するために使用されるコレクション オブジェクトが修正されました。	8.1 SP3
CR174575 CR175701	配列のインデックスがスレッドセーフでない状態でインクリメントされることが原因で、負荷が大きいときに IndexOutOfBoundsException を発して JDBC マルチプールが失敗していました。 スレッドセーフになるように、コードが修正されました。	8.1 SP3
CR174658	WebLogic のデータソースを使用している Java クライアントで「PeerGone」例外が発生したときに、接続に関連するトランザクション コンテキストが正しくクリーンアップされていませんでした。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR177220	マルチサーバ ドメインで、グローバル トランザクションに参加しているクライアントが次の例外を受け取っていました。 weblogic.transaction.RollbackException: delist() failed on resource jdbcXAPool データソースが null の場合はリソース マネージャが設定されないように、コードが変更されました。 データソースが初期化されると、リソース マネージャは VendorXAResource によってラップされます。	8.1 SP3
CR180097	JDBC 接続プールの「CountOfTestFailuresTillFlush」プロパティで、文のキャッシュがクリアされていませんでした。 この問題は、コードを修正することで解決しました。 「フラッシュ プール」機能の使い方の詳細については、『WebLogic JDBC プログラマーズ ガイド』の「JDBC 接続プールのテスト機能の拡張」を参照してください。	8.1 SP3
CR208038	サイレント スクリプト モードで JDBC 接続プールを作成する際に MaxCapacity パラメータが 1 に設定されている場合、Administration Console で誤ってこのパラメータの値が 15 と表示されていました。 この問題は解決されています。	8.1 SP3

jDriver

変更要求番号	説明	修正されたリリース
CR113462	Oracle の NLS_LANG が設定されている環境で BigDecimal 型を使用しているときに、WebLogic Server から NumberFormatException が送出されていました。米式の数字の定義に合わせて Oracle の NLS_NUMERIC_CHARACTERS パラメータを使用しているときには、この問題は発生していませんでした。この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR125135	デフォルトの WebLogic jDriver for Oracle/XA データ ソースは、oracleXATrace パラメータの値を false ではなく true に設定します。 このため、config.xml で oracleXATrace="false" を設定してトレース ファイルを明示的に無効にしない限り、時間とともに大きくなる xa_poolname*.trc 形式のトレース ファイルがドライバによって作成されていました。 oracleXATrace の値が指定されていない場合に、デフォルト値が false に設定されるようにコードが修正されました。	7.0 SP5 8.1 SP3
CR125135	デフォルトの WebLogic jDriver for Oracle/XA データ ソースは、oracleXATrace パラメータの値を false ではなく true に設定します。 このため、config.xml で oracleXATrace="false" を設定してトレース ファイルを明示的に無効にしない限り、時間とともに大きくなる xa_poolname*.trc 形式のトレース ファイルがドライバによって作成されていました。 oracleXATrace の値が指定されていない場合に、デフォルト値が false に設定されるようにコードが修正されました。	7.0 SP5 8.1 SP3
CR127949	Statement.getResultSet() が、不要な新しい ResultSet ラッパーを生成することがありました。 この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR129220	WebLogic Server Oracle jDriver は、ガベージ コレクション用に CLOB オブジェクトを正しく解放していませんでした。 この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR129220	WebLogic Server Oracle jDriver は、ガベージ コレクション用に Clob オブジェクトを正しく解放していませんでした。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR134285 CR137123 CR181738	weblogic.db.oci.OciLob クラスでは、データベースから返された BLOB データまたは CLOB データの byteArray を保持する 2 つのクラス レベルの変数が定義されていました。このバイト配列はかなり大きくなる場合があるので、OciLob の各インスタンスはガベージ コレクションが行われるまですぐにヒープを一杯にしていました。テストを追加して、クラス レベルの変数 retBArray[] と retCArray[] をメソッドに移動する OciLob を修正したことにより、変数がスタックに割り当てられるようになり、OciLob オブジェクト インスタンスのサイズが削減されて、全体的なヒープの使用量が減少しました。 メモリ ヒープの使用量を削減するためにグローバル変数 retBArray と retCArray をメソッド レベルに移動するコードが追加されました。	6.1 SP? 7.0 SP5 8.1 SP3
CR136168	WebLogic jDriver は、負荷が大きい状態で Long raw 型を使用しているときに、Oracle エラー メッセージ ORA-02392 でサーバをクラッシュさせることがあります。 この問題を解決するコード修正が実装されました。	8.1 SP3
CR142730	長いデータベースの停止の後、TestConnectionsOnReserve が true に設定されている XA jDriver for Oracle を使用する JDBC 接続プールが、データベースとの接続を回復および再作成できていませんでした。以下のエラー メッセージが送出されていました。 <Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: open failed for XAResource 'oracleXAPool' with error XAER_RMERR : A resource manager error has occurred in the transaction branch. さらに <Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: LDA pool exhausted - make sure you call Connection.close() その停止の間に、JDBC 接続プールが接続を再作成しようとしたが、失敗したときに、その接続の試行がクリーンアップされず、(LDA において) Oracle クライアントのリソースが枯渇していたことが問題でした。 jDriver は、失敗した接続作成の試行をクリーンアップするようになっています。	8.1 SP3
CR172462	AL32UTF8 文字セットが使用されているときに、WebLogic Server jDriver が Oracle 9.2 で正しく機能していませんでした。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3

JMS

変更要求番号	説明	修正されたリリース
CR110911	新しいメッセージがキューに追加された場合に、順序付き再配信が必ずしも正しく機能していませんでした。 コードが追加された結果、制約に従っていれば順序付き再配信は正しく機能するようになりました。	8.1 SP3
CR110991 CR117044	JMSServerRuntimeMBean のメソッド getHealthState はパブリック メソッドではなくなりました。	7.0 SP5 8.1 SP3
CR112112CR135792 CR181852	サーバの起動時に、JMS のコードが DestinationRuntimeMBean を作成し、それらを MBeanServer に登録していませんでした。それらの destinationMBean が登録される前に、FileStore に保存されているサブスクライバ用の DurableSubscriberRuntimeMBean (DestinationMBean の子) が作成および登録されていました。サブスクライバはその名前に親コンポーネントを持たず、コンソールでそれらを調べるときに親のスコープから抜け落ちます。 送り先の恒久サブスクライバの登録は、送り先が登録された後で、かつ送り先が通知される前に行われるようになりました。恒久サブスクライバは、JMS 送り先をモニタするときにコンソールから抜け落ちることはありません。	8.1 SP3
CR121041	同じマシン上で動作し、同じドメインの 2 つの管理対象サーバで動作している 2 つの JMS トピックの間でメッセージング ブリッジが機能しているときに、問題が発生していました。WebLogic Server の起動時にメッセージング ブリッジが起動されたときに、次の警告メッセージが送出されていました。メッセージは転送できませんでした。 ####<Aug 20, 2003 12:49:11 PM MST> <Warning> <MessagingBridge> <slsol4.bea.com> <server2> <ExecuteThread: '10' for queue: 'de fault'> <kernel identity> <> <200026> <Bridge "Test Messaging Bridge" encountered some problems to one of its adapters or underlying systems.It stopped transferring messages and will try to reconnect to the adapters shortly. (Exception caught was ja va.lang.Exception: javax.resource.spi.IllegalStateException: Managed connection is closed at weblogic.jms.adapter.JMSManagedConnection.checkIfDestroyed(JMSManagedConnection.java:263) at weblogic.jms.adapter.JMSManagedConnection.sendEvent(JMSManagedConnection.java:231) at weblogic.jms.adapter.JMSBaseConnection.throwResourceException(JMSBaseConnection.java:1266) at ... 分析の結果、恒久トピック用にコンフィグレーションされており、利用可能な JMS ストアがないためにブリッジがメッセージ リスナを作成できなかったことが判明しました。 ブリッジはリソース例外をログに記録しようとして内部エラーに遭遇していたので、顧客はブリッジのエラーの理由を知ることができませんでした。 ブリッジで適切なリソース例外を送出できるようにコードを修正することで、この問題は解決しました。現在は、ブリッジによって適切な例外がログに記録されます。	7.0 SP5 8.1 SP3
CR121226	移行したときの起動時に、メッセージング ブリッジが NullPointerException で失敗していました。 起動前に正しく初期化されるように移行可能コードが修正され、メッセージング ブリッジがエラーなく正常に移行できるようになりました。	8.1 SP3
CR121741	MBean を使用して MQ-WLS ブリッジを停止するときに、一貫性を欠く動作が行われていました。この例外は、トランザクション セッションで Recover() が有効なオペレーションでないために起こっていました。 コード変更により、recover() を呼び出す前にセッションが非トランザクションであることが確認されるようになりました。	7.0 SP5 8.1 SP3
CR121760	WebLogic Server のメッセージング ブリッジを使用して WebMethods 6.0 JMS を WebLogic Server と統合した場合に、InvalidDestinationException が送出されていました。メッセージを WebLogic Server に送信するときに、WebMethods 6.0 は ack を要求します。ブリッジは、WebMethods が com.wm.broker.jms.Destination 型を期待しているときに weblogic.jms.DestinationImpl 型の ack を送信します。結果として例外が送出されました。 WebLogic Server が 2 つの JMS 実装間でブリッジ機能を提供しているとき、要求されるのは、メッセージの確認応答を適切な型に変換することです。通常のメッセージでは、その仕事が正しく行われているように思われます。 分析の結果、標準の WebLogic JMS クライアントが、送信する WebMethods メッセージを渡され、WebLogic 送り先を使用してその WebMethods メッセージで setJMSDestination を呼び出そうとしていたことが判明しました。WebMethods は、このときに InvalidDestinationException を送出します。 InvalidDestinationException を捕捉して無視するコード変更で、この問題は解決しました。	7.0 SP5 8.1 SP3
CR123194	WebLogic Server の以前のサービスパックでは、サーバ インスタンスがダウンしたがそのクライアントはアクティブなままの場合に、JMS 仕様どおりの JMSException ではなく、JMS から実行時例外 weblogic.rmi.extensions.RemoteRuntimeException が送出されていました。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR124286 CR128684	MQSeries の停止が原因で MDB が MQSeries との接続を失った場合、リソースは登録を解除されず、MQSeries は WebLogic Server が再起動されるまで解決されない準備されたトランザクションと一緒に放置されていました。 JMSConnectionPoller は、接続エラーが原因で JMS との接続が切断された場合に unregisterResource を呼び出すように変更されました。アンデプロイメント、移行、シャットダウンなどの他の理由で接続が切断される場合、registeredResource は null に設定されていました。 MQSeries に接続された MDB が WLS を再起動する必要なくメッセージを処理していれば、MQSeries が停止されて再起動された場合にトランザクションの回復は正しく行われるようになりました。	8.1 SP3
CR125014 CR171724	JMS クライアントと JMS サーバとの接続の確立と切断を繰り返したときに、サーバ サイドでメモリ リークが発生して OutOfMemoryError が生じていました。 この問題を修正するコード修正が行われました。	8.1 SP3
CR125693	JMSConnectionFactoryMBean の flowMinimum 属性の有効な最小値が 1 に変更になっていたので、一貫性を保つため、flowMaximum 属性の有効な最小値も 1 に変更されました。	7.0 SP5 8.1 SP3
CR125979	クラスタ内で JMS ブリッジを設定すると、そのブリッジを起動するときに管理対象サーバから次の例外が送出され、JMS メッセージを目的地に送信できないことがありました。 <Oct 16, 2003 3:12:49 PM PDT> <Notice> <WebLogicServer> <BEA-000360> <Server started in RUNNING mode> <Oct 16, 2003 3:23:17 PM PDT> <Error> <JMS> <BEA-040368> <The following exception has occurred: java.lang.NullPointerException at weblogic.jms.bridge.internal.MessagingBridge.startInternal(MessagingBridge.java:519) at weblogic.jms.bridge.internal.MessagingBridge.execute(MessagingBridge.java:956) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.Kernel.execute(Kernel.java:336) at weblogic.kernel.Kernel.execute(Kernel.java:321) at ... 管理対象サーバの Started 属性が「false」から「true」に変更され、アダプタがデプロイされていないクラスタ化されたコンフィグレーションで、ブリッジが正しく開始されるようにコードが修正されました。	8.1 SP3
CR126183	最大アイドル時間の設定値に達した後に、アイドル状態のブリッジがメッセージをログに記録していました。 アイドル状態のブリッジによって記録される反復的なログ メッセージ「Bridge X start transferring messages」が抑制されるようにするコードが追加されました。 ブリッジが停止されて再起動されるか、例外に遭遇して再起動された場合は、「Bridge <bridgename> starts transferring messages」というログ メッセージが記録されますが、反復的なメッセージがアイドル状態のブリッジによってログに記録されることはありません。	7.0 SP5 8.1 SP3
CR126671	ブリッジ アダプタがクラスタにデプロイされている場合に、メッセージング ブリッジが通知リスナを登録していませんでした。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR127260	MessagingBridgeRuntime MBean が、次の weblogic.Admin ユーティリティ コマンドで停止していませんでした。 java weblogic.Admin -url t3://127.0.0.1:7001 -username weblogic -password weblogic INVOKE -type MessagingBridgeRuntime -method stop MessagingBridge の開始メソッドと停止メソッドは、実行時に MessagingBridge を開始および停止する方法について情報提供の例外を送出するようになりました。	7.0 SP5 8.1 SP3
CR128596	7.0 SP2 クラスタから 8.1 SP2 クラスタへ分散送り先を使用してメッセージング ブリッジ経由でメッセージが送信されるときに、8.1 SP2 クラスタのサーバの 1 つがバウンスされる場合に、メッセージ フローが止まってしまうことがありました。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR132606	同じ WebLogic Server インスタンス上にある分散トピック メンバーについて、Administration Console の保留メッセージ数のカウンタが正しくありませんでした。リモートの分散トピック メンバーでは、カウンタは正しく示されていました。 他の非リモート分散トピック メンバーに転送するときに、分散トピックの参照カウントを適切に管理するようにコードが修正されました。	8.1 SP3
CR133155	起動時に JDBC ストアから JMS メッセージを復元するのに、長い時間がかかっていました。getTables プレフィックスに JMS を含めることで、この問題は解決しました。 この問題は、コードを修正することで解決しました。	8.1SP3
CR133474	移行した JMS サーバが元のホスト サーバ インスタンスに再び移行された後に、メッセージが MDB に正しくディスパッチされていませんでした。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR134155	トピック セッションからの JMS メッセージが、受信側がトランザクション セッションを使用して作成され、AUTO-ACKNOWLEDGE が使用され、メッセージがロールバックされた場合にメモリ リークを生じさせていました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR137145	IIOP を使用する一部の JMS シン クライアントは、登録を実行するとき、およびハートビート障害によるコールバックの通知のときにサーバが同じロックを使用することが原因でハングしていました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR172511	最初にすべての JMSConsumer クライアントを閉じる前に JMSConnection セッションを閉じると、メモリ リークが発生する恐れがありました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR172780	Tibco サーバを再起動すると、ラップされた JMS オブジェクト (ForeignJMSConnectionFactory) がそれ以降にメッセージングを送信できず、次のセキュリティ例外が送出されていました。 weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: ForeignJMSConnectionFactoryConfig Action: read, Target: Password weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: ForeignJMS ConnectionFactoryConfig Action: read, Target: Password 再接続時に ForeignJMSConnectionFactory が必要とするユーザ名とパスワードにアクセスするための KERNEL_ID が認識されるように JMSConnectionHelper API がコード修正されて、この問題は解決しました。	8.1 SP3
CR173565	XA トランザクションが失敗したときに、JMS メッセージが 2 度配信されていました。 失敗したトランザクションを処理し、曖昧な状態のトランザクションがあることをユーザに通知するために適切なエラー メッセージをログに記録するように、コードが修正されました。 この修正の前は、曖昧な状態にあるトランザクションのメッセージはすべてロールバックされ、メッセージがメモリにあるために再配信されていました。しかし、ストア内のレコード (ある場合) はそのレコードのストアのハンドルが無効であるために正しく更新されず、レコード (ある場合) はストアに残されていました。したがって、JMS サーバが再起動されたときに、メッセージは再配信されてメッセージの重複が生じていました。 現在は、曖昧な状態にあるトランザクションのメッセージは、JMS サーバが再起動しないと回復できないようになりました。JMS サーバの再起動なしにメッセージを回復しようとすると、RMERR が生じます。	8.1 SP3
CR176366	getObject() メソッドが onMessage() API の Boolean.TYPE で設定された場合に、次の JMSException が送出されていました。 javax.ejb.EJBException: nested exception is:weblogic.jms.common.JMSException: Error deserializing object weblogic.jms.common.JMSException: Error deserializing object weblogic.jms.common.resolveClass() API. のコード修正で、この問題は解決しました。	8.1 SP3
CR178405	期限切れメッセージの調査時に、java.util.ConcurrentModificationException が送出されていました。 この問題は、コードを修正することで解決しました。	8.1 SP3

JNDI

変更要求番号	説明	修正されたリリース
CR110136 CR176352	NamingException の内容をクライアントがデシリアライズできないときに、NestedException の一部としてサーバから NamingException が送出されていました。NamingException には WLContextImpl オブジェクトが含まれており、このオブジェクトをデシリアライズするためには、WebLogic Server はロードバランシングのための環境をスレッド上に必要としていました。 この問題は、スレッド上に環境がない場合にデフォルト環境を初期化することで修正されました。	8.1 SP3
CR125793 CR185265	InitialContext の取得を試みるときに、WebLogic Server はスタブ名の取得にかなりの時間を費やしていました。 WebLogic Server が PeerInfo から静的にスタブ名を生成するように、コードが追加されました。	8.1 SP3

JSP

変更要求番号	説明	修正されたリリース
CR104429CR134313	JSP が更新されて手動で再コンパイルされ、更新された JSP クラス ファイルが jspWorkingDir にコピーされた場合に、WebLogic Server は再コンパイルが必要かどうかを確認せずに、更新された JSP ページを再コンパイルしていました。 新しいパラメータ -Dweblogic.jsp.alwaysCheckDisk を true に設定すると、WebLogic Server はディスク上の JSP クラスをチェックして JSP の再コンパイルが必要かどうか確認します。このパラメータはデフォルトで false であり、デフォルトの動作は変わりません。	7.0 SP5 8.1 SP3
CR107421	jsp:useBean の含まれている JSP が内部クラスを使用する場合に、コンパイルが失敗していました。 jsp:useBean 内では内部クラスで常に「$」クラス セパレータを使用します。「$」ではなく常に「.」セパレータが使用される「型」が内部で生成されるように、JSP コンテナが修正されました。	8.1 SP3
CR111423	WAR ファイルにパッケージ化されている場合、アプリケーションのサブコンテキストに格納されているプリコンパイルされた JSP は常に WebLogic Server へのデプロイメント時に再コンパイルされていました。JSP が展開されたアーカイブ ディレクトリからデプロイされる場合、または JSP が WAR ファイルのルートコンテキストにある場合には、この問題は起こりませんでした。 この問題は、jar 形式と zip 形式で使用されるタイムスタンプの丸め方式の違いが原因で発生していました。丸め方式が違うことで、(1 秒だけ) 古いタイムスタンプが WAR ファイル内のクラス ファイルに記録されていまい、それが原因でサーバがクラスを再コンパイルしていました。 コンパイルされた JSP クラスのタイムスタンプを 1 秒だけ進めるようにコードが修正され、JSP が再コンパイルされないようになりました。	6.1 SP6 8.1 SP3
CR111655	以前は、日本語の文字が含まれている JSP で JavaServer Pages Standard Tag Library (JSTL) タグを使用することはできませんでした。 このような JSP を実行すると、次のエラーが発生していました。 java.io.IOException: javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x82) was found in the CDATA section." ページ ディレクティブで pageEncoding 属性が指定されていない場合、バイト ストリーム (タブライブラリの検証に使用) はデフォルトのエンコーディングを使用して作成されていました。 pageEncoding が指定されていない場合は contentType 属性で定義されている文字エンコーディングが使用されるようにコードを修正して、この問題は解決されました。	7.0 SP5 8.1 SP3
CR112794	正しく解析されないコピーで JSP が更新され、そのことが原因でデッドロックが生じていました。 この問題は、JSP の更新時にチェックを追加するコード変更で解決されました。	7.0 SP5 8.1 SP3
CR120914	WebLogic Server フォーム検証タグ ライブラリを使用する場合に、要求パラメータが次以降の JSP から利用できていませんでした。この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR123659	WebLogic Server は、JSP タグでコメントを許可していませんでした。 JSP タグの java/xml コメントを解析するコードが追加され、xml コメントは生成された java ファイルで無視され、java コメントは維持されるようになりました。	8.1 SP3
CR124505	コンパイル済みクラスが WAR ファイルに格納されている JSP が、再コンパイルの必要がないときに再コンパイルされていました。最大 1.75 秒のタイムスタンプの差違が示されていました。 新しいタイム バッファ ロジックが適用され、タイム バッファが 1 秒から 2 秒に変更されました。クラスがプリコンパイルされている WAR ファイル内の JSP は再コンパイルされなくなりました。	8.1 SP3
CR127515 CR068074	jsp ファイルに javac エラー文がある場合、jsp コンテナはブラウザとログ ファイルの両方でエラー メッセージを適切に表示していました。 weblogic.jspc の使用時には、メッセージは壊れていました。 コードを修正して問題は修正されました。	8.1 SP3
CR127944	jspc コードで、WebLogic Server はユーザから提供された JSP 記述子のオプションを解析していました。そのようなオプションの 1 つは、どのタイプのコンパイラを使用するのかを提案する compileFlags 属性でした。 このフラグは、weblogic.xml で文字列 compileFlags によって示されます。WebLogic Server では文字列 compilerFlag をチェックしていたため、この記述子要素が無視されていました。 jspc コードで compilerFlags から compileFlags に文字列の比較を変更するコードが追加されました。compileFlags オプションでコンパイラ フラグを指定すると、それは jspc によって尊重されます。	8.1 SP3
CR130057	wlpackage Ant タスクを使用して展開 EAR アプリケーションをビルドするときに、JSP ファイルのタイムスタンプが保持されていませんでした。このことが原因で、すでにコンパイルされている場合でも、JSP が不要に再コンパイルされることがありました。 この問題は、wlpackage がコピーしたファイルのタイムスタンプを保持するようにコードを修正して解決されました。	8.1 SP3
CR130438	次のように taglib と CDATA が JSP ページにある状態で、変換エラーが発生していました。 sample.jsp : <%@ page contentType="text/xml" %> <?xml version="1.0" encoding="iso-8859-1" ?> <%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c"%> <ablock> <![CDATA[ This is a cdata block ]]> </ablock> weblogic.jspc コンパイラを使用してこの JSP をコンパイルすると、次のように出力されます。 "sample.jsp": Translation of /sample.jsp failed: javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException: The element type "jsp:text" must be terminated by the matching end-tag "</jsp:text>"., " コードの修正により、XML 構文の内容を JSP ドキュメントに変換しながら CDATA の存在が確認されるようになりました。	8.1 SP3
CR133172 CR178872 CR179626	jspc コンパイラの「compileAll」オプションで、WEB-INF ディレクトリ内の JSP が無視されていました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR133453 CR177115	プリコンパイルされた JSP が期限切れチェックに失敗していました。 この問題は、期限切れチェックのロジックを追加するコード修正で解決されました。	8.1 SP3
CR172250	weblogic.jspc には、下位互換性のプロパティがありませんでした。 backwardcompatible という新しいコマンドライン フラグが weblogic.jspc に追加されました。true に設定すると、6.x 以前の WebLogic Server との下位互換性を維持して Web アプリケーションがコンパイルされます。この新しい「下位互換性」フラグを使用すると、WebLogic Server 6.x を使用しているかのように Web アプリケーションをコンパイルできます。	8.1 SP3
CR172380	struts ベースのアプリケーションが EAR ファイルのプリコンパイルに失敗し、次の例外を送出していました。 <Error> <Deployer> <149205> <The Slave Deployer failed to initialize the application dos due to error weblogic.management.ManagementException: 149233 - with nested exception: [java.lang.ExceptionInInitializerError]. java.lang.ExceptionInInitializerError: java.lang.NullPointerException コードの修正によりこの問題は解決され、すべての JSP をプリコンパイルする前にスレッド クラス ローダが ServletClassLoader() メソッドに設定されるようになりました。これで、struts クラスと、後で struts ライブラリがロードしようとする他のクラスのロードで同じクラスローダが使用されるようになります。	8.1 SP3
CR175937	展開 webapp 形式の場合は、タイム ゾーンを移動するときに JSP が再コンパイルされていました。 展開 webapp で、期限切れチェック ロジックが追加されました。	8.1 SP3

JTA

変更要求番号	説明	修正されたリリース
CR112772	config.xml のトランザクション タイムアウト属性のコンフィグレーション値に関係なく、トランザクションが 30 秒でタイムアウトになっていました。 WebLogic JTA が起動時に、コンフィグレーションされているトランザクション タイムアウトを利用するように、コードが修正されました。
CR113226	リソース名の文字数が 64 文字を超えている場合、WebLogic Server は接続プールのテスト時に例外を送出する恐れがありました。 この問題は、最初の 64 文字だけで一意性がテストされたために起こっていました。64 文字を超えるリソース名が適切に処理されるように、コードが修正されました。	7.0 SP5 8.1 SP3
CR122212	Usertransaction でタイムアウト例外が発生すると、そのトランザクションはロールバックのマークが付けられていました。実際のロールバックはタイマーでスケジューリングされ、非同期で行われていました。 この状況において、顧客がトランザクションで明示的に rollback() を呼び出した場合、その呼び出しはロールバックを直に行うことも、タイマーがロールバックを実行するのを待つこともしませんでした。再び直接 begin() を呼び出すと、タイマーによってロールバックされるトランザクションとスレッドがまだ関連付けられているので IllegaStateException が送出されます。 rollback() の呼び出しは、ロールバックが実行されたときのみ復帰します。このシナリオでは、トランザクションはタイマーによってロールバックされることが内部でマーキングされているので、rollback() は直ちに復帰し、手動のロールバック処理は開始されませんでした。 他の例外条件が原因で rollback() メソッドが呼び出された場合に、トランザクションがすぐにスレッドから削除され、begin() をすぐに再び呼び出すことができるように、コードが追加されました。	8.1 SP3
CR122842	古いリソースと同じ名前で新しいリソースを登録した場合に、それ以降の XA トランザクション操作が新しいリソースを利用することができませんでした。トランザクション操作は、継続してオリジナルのリソースを利用しようとしていました。 同じ名前を持った 2 つ目のリソースの代用が可能なように、コードが追加されました。	7.0 SP5 8.1 SP3
CR124503	WebLogic Server はトランザクションそれ自体ではなくトランザクション マネージャで同期化されていたので、呼び出されるべきメソッドは setRollbackOnlyUnsync ではなく setRollbackOnly でした。 setRollbackOnly が同期化されるようにコードが追加されました。	8.1 SP3
CR173964	WebLogic JMS と Oracle XA をリソース マネージャとして XA トランザクションを実行した場合、Xa.prepare が実行されているときに Oracle との接続を切断すると、XAER_RMFAIL が返される場合があります。つまり、WebLogic Server により Oracle 側でトランザクションが曖昧なまま放置されることになります。この状況において、Oracle には準備状態で作成されたグローバル トランザクションがありますが、そのトランザクションが WebLogic Server によってロールバックされることはなく、結果としてテーブルはロックされ、それ以降の呼び出しは ORA-1591 エラーで返されます。 コードの修正により、RMERR または RMFAIL が Xa.prepare で受信された場合は、リソースでロールバックを呼び出すことができるようになりました。	8.1 SP3
CR177865	JTA の回復プロセスで、サーバの正常な停止が阻止されていました。 この問題は、サーバ停止時の JTA、JMS、および JDBC サービスの停止順をこの並び順に変更することで解決しました。	8.1 SP3
CR182243	接続がトランザクションの下に作成され、現在のトランザクションへの登録が失敗したときに (つまりその接続はプールに返されない)、JDBC 接続リークが発生していました。 コードを修正して問題は解決されました。	8.1 SP3

JVM

変更要求番号	説明	修正されたリリース
CR125688 CR177828	JRockit JVM の使用時に、UNC パスを使って java.io.File.getCanonicalPath() を呼び出すと、次に示すエラーが送出されていました。 java.io.IOException: \\UNC path: The file name, directory name, or volume label syntax is incorrect. このエラーは、DeployerRuntimeMBean を使用して、アプリケーションのソース ファイルのパスが記述子ファイルで URL としてリストされている (file://localhost/D:/myfolder/myapp.ear または file:/localhost//D|/myfolder/myapp.ear など) EAR ファイルをデプロイしたときに発生していました。 バージョン 1.4.2_04 では、JRockit は適切に UNC パスを処理します。	8.1 SP3
CR135783	WebLogicMBeanMaker の動作結果が JDK のバージョン 1.4.1_05 とバージョン 1.4.2_03 で異なっていました。 JDK 1.4.1_05 の場合、クラス ファイルが格納されていないソース フォルダが指定されると、WebLogicMBeanMaker はそのエラーを何の通知もなく無視し、MBean の JAR ファイルを作成していました。 JDK 1.4.2_03 の場合、WebLogicMBeanMaker はソース パスにクラス ファイルがない場合は失敗します。 現在、WebLogicMBeanMaker の動作は JDK 1.4.1 と JDK 1.4.2 で同じになっています。	8.1 SP3
CR136167	JDK 1.4.2_03 および JDK 1.4.2 の問題が原因で、ロケールが日本の場合に Administration Console でサーバ ログを表示できませんでした。 WebLogic Server 8.1SP3 には JDK 1.4.2_04 が含まれており、このバージョンは日本語ロケールでのサーバ ログの表示を妨げていた問題が修正されています。	8.1 SP3

ノード マネージャ

変更 要求 番号	説明	修正されたリリース
CR076968 CR177156	UnixProcessControl|NodeManager.c は、JavaProcessControl と同じように SIGKILL を送信しなければならないときに SIGTERM をオフラインで送信していました。 コード変更の後、UnixProcessControl はオフラインで SIGKILL を返すようになりました。	7.0 SP6 8.1 SP3
CR120410	ノード マネージャが停止されて再起動されると、再起動の後に、ノード マネージャはそのノード マネージャが管理対象サーバをモニタしていることを検出することがありました。 ノード マネージャは管理対象サーバのコンタクトを 180 秒間待ち、その後に管理対象サーバを再起動しようとしていました。管理対象サーバには、ノード マネージャに繰り返しコンタクトしようとするタイマーがあります。そのタイマーの間隔は指数的に拡大し、管理対象サーバは 2、4、8、16... 秒後にコンタクトを試行していました。ノード マネージャが長い時間経った後に起動されると、管理対象サーバのタイマーの間隔は 180 秒を超える可能性があり、そうなるとノード マネージャは管理対象サーバがダウンしているかのように振る舞うようになります。また、管理対象サーバはノード マネージャで障害が発生した後にタイマーを開始していませんでした。その理由は、NumberFormatException を受信し、スレッドが終了していたからです。 以下の 2 つの変更が実装されました。 1) 管理対象サーバのタイマーの間隔が、ノード マネージャが再起動を試行する間隔 180 秒より小さい最大 128 秒に制限されます。 2) ノード マネージャで障害が発生すると、管理対象サーバは例外を受信していました。 その例外は NodeManagerCommandListener で捕捉され、ノード マネージャに定期的に接続を試行するためにタイマー スレッドが開始されます。	8.1 SP3
CR127930 CR135441	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_51.00.jsp のセキュリティ勧告を参照してください。	7.0 SP5 8.1 SP3

操作と管理

変更 要求 番号	説明	修正されたリリース
CR099488	WebLogic Server は、管理ポートの URL を誤って判定していました。コードの修正により、URL はまず管理ポート (有効な場合) に基づいて判定され、それが有効でない場合は、管理チャネル (有効な場合) に基づいて判定されるようになりました。	7.0 SP6 8.1 SP3
CR105572	wlconfig Ant タスクを使用して、実行中のサーバ インスタンスに対し JMS サーバと 2 つの JMS キューを作成すると、Administration Console では、JMS サーバと 2 つの JMS キューが正しく作成されて表示されました。ただし、wlconfig では誤って 2 つ目の JMS キューを </JMSServer> 終了タグの外に配置したため、config.xml ファイルが適切に更新されませんでした。 この問題はコードの修正によって解決されました。	8.1 SP3
CR106122 CR124247	以前のリリースの WebLogic Server では、MLET 要素の NAME 属性の指定が必要でした。 JMX 使用に準拠するため、NAME 属性は省略可能になりました。	7.0 SP4 8.1 SP3
CR111199	管理サーバを再起動してから、2 つの管理対象サーバを同時に起動すると、CPU の消費が大きくなっていました。1 つの管理対象サーバは初期化を完了し、もう 1 つは初期化を開始した後に停止していました。 kill -QUIT pid を使用して、次のようにメイン スレッドが HashMap.rehash でスタックしていたことが判明しました。 "main" prio=5 tid=0x29240 nid=0x1 runnable [0xffbec000..0xffbedbd4] at java.util.HashMap.rehash(HashMap.java:292) at java.util.HashMap.put(HashMap.java:344) at weblogic.management.internal.DynamicMBeanImpl$XInfo.get(DynamicMBeanImpl.java:2270) at weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:195) at weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:167) at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:70) at weblogic.jms.frontend.FEConsumer.<init>(FEConsumer.java:100) at weblogic.jms.frontend.FESession$3.run(FESession.java:952) at .... コードの修正により、サイズ変更なしでもすべての MBean 属性を収容できるようにデフォルト HashMap のサイズが拡張され、HashMap へのスレッド アクセスが同期化されました。	7.0 SP6 8.1 SP3
CR113455 CR132578 CR185306	weblogic.Admin コマンドは、メイン クラスに復帰します。メイン クラスは、例外が送出されたかどうかによって判断される終了コードを返します。 コマンドが成功したときに、不要な例外が送出されていました。 WebLogic Server は、コマンドが成功したときに例外を送出しなくなりました。	8.1 SP3
CR120398	weblogic.common.internal.AdminProxy のコードが、呼び出し側が管理ユーザでない場合に例外を送出していました。 オペレータ ユーザのリクエストは、デフォルト キューにディスパッチされていました。 サーバは、保留中のリクエストがデフォルト キューにあるかのように振る舞って停止時にハングしていました。管理ユーザのリクエストは、デフォルトとは違うキューにディスパッチされていました。 ユーザがオペレータかどうかを確認し、オペレータである場合は、そのユーザにサーバの停止を許可するように、コードが追加されました。また、オペレータ ユーザのリクエストがデフォルト以外のキューにディスパッチされるようにするコードも追加されました。これで、この問題は解決されます。	8.1 SP3
CR120926	管理ポートまたは admin チャネルが使用されている場合に url で間違ったポートが指定されていたので、管理対象サーバへのリモート接続を試みようとしたときに管理対象サーバのログを表示することができませんでした。 適切なポートを使用し、QOS_ADMIN を設定して操作を実行するように WebLogic Server が更新されました。	8.1 SP3
CR121015	プロパティに @exclude が付けられている場合に、MBean の監査でクリアテキストのパスワードが記録されていました。 コードの修正により、暗号化された属性の値を WebLogic Server がクリアテキストで出力しないようになりました。	8.1 SP3
CR121728	拡張 : カスタム認証プロバイダの MBean は、WebLogic のディレクトリ ツリーの WL_HOME\server\lib\mbeantypes ディレクトリに配置する必要がなくなりました。 MBean タイプをインストールするデフォルトのディレクトリは、WL_HOME\server\lib\mbeantypes です。ただし、サーバを起動するときに -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用すれば、追加ディレクトリで MBean タイプが検索されます。<dir> は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Server は常に最初に WL_HOME\server\lib\mbeantypes から MBean タイプをロードし、続いて追加ディレクトリ内を検索してその中の有効なアーカイブを (例外に関係なく) すべてロードします。たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY の場合、最初に WL_HOME\server\lib\mbeantypes から MBean タイプがロードされてから、dirX および dirY にある有効なアーカイブがロードされます。 このオプションは引き続き使用する必要があり、使用しない場合はサーバを起動できなくなります (たとえば、このオプションを使用し、ユーザを作成した後に alternateTypesDirectory オプションを使用しないことを決めた場合)。 詳細については、『WebLogic Security サービスの開発』の「WebLogic Server 環境に MBean タイプをインストールする」を参照してください。	7.0 SP5 8.1 SP3
CR121856 CR132551 CR179078 CR183921	時間フォーマットされたログ ファイルで無限ループが生じ、以下の問題が発生していました。 起動時に、次のローテーション時刻が設定されていませんでした。 起動時に複数のログ ファイルが作成されていました。 ログ ファイルが閉じられるときに WebLogic Server が例外をログ ファイルに記録しようとしていたので、ログ ファイルは 2 度ローテーションされていました。ローテーション時に、WebLogic Server は閉じられたファイルに書き込もうとして例外が送出されていました。 ログ ファイルが制限を受けていても、WebLogic Server はログ ファイルが指定されたファイル数を超えることを許していました。古いログ ファイルを削除するコードが用意されていませんでした。 現在は、適切なローテーション時刻が起動時に設定されるようになっています。 ローテーション時に例外が送出されても、WebLogic Server はファイルにログを記録しなくなりました。ただし、代わりに標準出力に出力されます。 各ローテーションの後、WebLogic Server はファイル数が制限を超えているかどうか確認するようになりました (制限されている場合)。古いログ ファイルは削除されるようになっています。	8.1 SP3
CR122204	カスタム COMMO Bean のある管理対象サーバが管理サーバを再起動することなく再起動された場合、その管理対象サーバは COMMO Bean のインスタンスを作成することができませんでした。次の例外が発生していました。 javax.Management.InstanceAlreadyExistsException is thrown, and the Detailed message in the exception is, The Object name specified 'wlidomain:Name=t,Server=managed1,Type=AppViewRuntime' is not unique across the domain.Please choose an unique Object Name 分析の結果、ダウンしたときに管理サーバの MBeanServer で Mbean が登録解除されていなかったことが判明しました。このため、再起動時に管理対象サーバは Bean を再作成することができませんでした。管理サーバでは、その Bean の名前を持つ Bean インスタンスがインスタンス化された Bean のリストにまだ存在していたのです。Mbean の名前は、ドメインの中でユニークでなければなりません。 この問題は、管理対象サーバのサーバ固有のすべての Bean がサーバのダウン時に登録解除されるようにコードを修正して解決されました。 管理対象サーバがダウンしたときに、管理サーバは PeerGoneEvent を受信し、その管理対象サーバと関連付けられているすべての MBean を登録解除します。	7.0 SP5 8.1 SP3
Cr122839	MBean を使用して、あるいは config.xml ファイルで手作業で SqlStmtProfilingEnabled の値を設定し、MBean を通じてその値を取得しようとした場合に、その値が表示されませんでした。代わりに、「It appears that no attributes have been specified for this MBean」というメッセージが返されていました。 この問題は、コードを追加することで解決しました。	8.1 SP3
CR123821	weblogic.Admin SHUTDOWN コマンドを使用してサーバ インスタンスを停止できませんでした。 weblogic.admin がデフォルトの URL (t3://localhost:7001) を適切に使用するようにコードを修正しました。	8.1 SP3
CR124099 CR135050	デプロイ対象としていないサーバに、アプリケーションがデプロイされました。 アプリケーションのデプロイメントの前に対象を確認するように、コードが追加されました。	8.1 SP3
CR126529 CR173999	Weblogic MBeanLoader は次のエラー メッセージを生成しました。 weblogic.management.commo.WebLogicMBeanLoader security.xml Exception in thread "main" weblogic.management.ManagementError: [Management:141113] The management subsystem was accessed prior to its initialization. weblogicMBeanLoader/weblogicMBeanDumper の初期化コードを修正して、この問題を解決しました。	8.1 SP3
CR126570 CR132988	以前のサービス パックでは、java.util.logging.Logger の log メソッドに対応していませんでした。 コードを修正してこの問題を解決しました。	8.1 SP3
CR126615	WebLogic Server が文字列ではなくブール値であることを想定していたため、-Dweblogic.ProductionModeEnabled=true が正しく処理されていませんでした。 この問題は、ant タスクで WebLogic Server がこれを文字列として処理するようにコードを追加することで解決されました。	8.1 SP3
CR126930 CR181748 CR183828	WebLogic Server 8.1 では、ログ ローテーションの方法が変更されました。 ログ ローテーションは、時間だけでなく、ログ ファイルへの出力アクティビティでも引き起こされていました。つまり、ローテーション時にメッセージがない場合、WebLogic Server は更新があるまでログをローテーションしていませんでした。 この問題は、サーバ起動後の最初のログ アクティビティに基づいて最初にローテーションを行った後、WebLogic Server がスケジュールに則ってログをローテーションするように強制することで解決されました。	8.1 SP3
CR127698 CR132901	管理対象サーバは、管理サーバがプロダクション モードで起動したときのみプロダクション モードで起動されていました。他の場合では、管理対象サーバは開発モードで起動されていました。 管理対象サーバの ProductionModeEnabled のロジックを修正するコードが追加されました。	8.1 SP3
CR128032 CR174966 CR177166	Deployers グループのユーザは、コンソールから、あるいはコマンドライン ツール weblogic.Deployer を使用してアプリケーションをデプロイできませんでした。アプリケーションのデプロイメントには、特定の属性の書き込みパーミッションと他のアクションの実行パーミッションが必要でした。 クラスタ、サーバ、仮想ホストなどのさまざまな対象にアプリケーションをデプロイできるように、Deployers グループのユーザにパーミッションが追加されました。	8.1 SP3
CR128061 CR177278	Administration Console を使用して新しい管理対象サーバ ノードをコンフィグレーションする際に、管理サーバが再起動されるまでコンソールで新しいサーバ インスタンスの実行キューをコンフィグレーションすることができませんでした。 管理サーバが起動した後に作成された新しいサーバ ノードが編集可能なデフォルトの実行キューを持つようなりました。	8.1 SP3
CR128506	ログ ファイルはサーバのディレクトリ パスに相対的な場所には格納されませんでした。 ログ ファイル MBean は、サーバの起動場所 (ディレクトリ) を認識するようになったため、ログが認識およびローテーションされるようになりました。	8.1 SP3
CR129439	ローカル コンテキストのルックアップとローカル サーバの実行時 MBean の呼び出しが失敗しました。 サーバの実行時 MBean がクラス タイプ別に呼び出される場合、null の代わりに「*」ドメインを使用するようにコードを変更しました。	8.1 SP3
CR129539	StdoutEnabled フラグが false に設定されている weblogic.logging.NonCatalogLogger が、クライアント サイドのロギング用にログ出力を Administration Console に表示し、この値を無視していました。 consoleHandler ロガーが stdoutEnabled フラグを認識するようになりました。	8.1 SP3
CR130042	コンフィグレーション ファイル (config.xml) が他の XML ファイルを参照している場合に、WebLogic Server の起動が失敗していました。 コードの修正で、JDK 1.4 XML パーサに関するこの問題は解決されました。しかし、config.xml ファイルが .xml 拡張子であるという事実を除いて、WebLogic Server は config.xml を XML 準拠のファイルとして扱うことはなく、マニュアルでそのような XML 様式の参照が推奨されることもありません。	8.1 SP3
CR130142	クラスタ コンフィグレーションにおいて、管理対象サーバで新しいユーザまたはグループを作成しようとした後に userExists() の呼び出しが失敗することがあります。 userExists() API を使用した新規ユーザのルックアップは管理サーバで行われ、既存ユーザのルックアップはローカルの管理対象サーバで行われるようにコードを修正して、この問題は解決されました。	8.1 SP3
CR130413 CR168268	属性変更監査の通知で、属性の古い値が新しい値として出力されました。 コードの修正により、特定の属性の新しい値として正確な値が使用されるようになりました。 Administration Console から監査情報を取得する方法の詳細については、『WebLogic Security サービスの開発』の「監査プロバイダ」を参照してください。	8.1 SP3
CR130441	バージョン 8.1 の以前のサービスパックでは、weblogic.Admin が「commotype」構文を正しく処理していませんでした。このことが原因で、サンプルのセキュリティ プロバイダに障害が発生していました。 サンプルをビルドし、サーバを起動して、ドメインを設定しようとしたときに、javax.management.MBeanException エラーが何度も受信されていました。 コードの修正により、weblogic.Admin が「commotype」構文を正しく処理できるようになりました。その結果、サンプル セキュリティ プロバイダはこのサービスパックで適切に動作します。	7.0 SP5 8.1 SP3
CR132445	デフォルト URL で、weblogic.Admin が正しく機能していませんでした。たとえば、java weblogic.Admin -username ss -password ss VERSION では結果が返されないが、-url t3://localhost:7001 を追加すると正しい結果が返されていました。 コードの変更後は、デフォルト URL がすでに内部にあるようになったので weblogic.Admin は入力 URL で null をチェックするようになりました。	7.0 SP5 8.1 SP3
CR132824	クラスタにデプロイされている Web アプリケーションで、Administration Console に表示される Web アプリケーションのサーブレット数が、java.lang.ClassCastException により間違っていました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR133879	weblogic.properties MBean 変換ツールは、内部サーバ オペレーションで使用されるものとは違う別個の MBeanServer を使用します。したがって、変換対象の MBean が MBeanServer で見つからずに変換が失敗する場合には、invalidAttributeValueException が送出されていました。 MBean プロパティの変換の進行中において、例外を送出する前に weblogic.properties コンバータの使用する MBean が MBeanServer に存在するかどうかをチェックするようにコードが修正されました。	8.1 SP3
CR136488	拡張子に関係なくプラグイン メカニズムによってあらゆるファイルがロードされ、サーバの開始時エラーが発生します。lib/mbeantypes の .jar ファイルのみセキュリティ プロバイダと見なし、他のサフィックスのファイルは無視する必要があります。 以前は、.../lib/mbeantypes ディレクトリにあるファイルがすべてセキュリティ プロバイダとして扱われ、サーバの起動時にロードされていました。このような処理は、ファイルの拡張子に関係なく行われていました。現在は、.jar または .zip が拡張子のファイルだけがセキュリティ プロバイダとして扱われます。ファイルの拡張子が .jar または .zip ではないセキュリティ プロバイダがロードされることを当てにしている場合、そのセキュリティ プロバイダはロードされなくなっているのでドメインが開始されることはありません。 そのようなセキュリティ プロバイダ ファイルは、サーバの起動前に名前を変更しないと正しく機能しません。	8.1 SP3
CR137144	ドメイン ログをローテーションするときに LogRotationException が送出されました。この問題は、ロガーがログ インデックス (0001) を生成し、新しいログ ディレクトリが同じ名前のファイルを格納している現在のログ ディレクトリにローテーションされたときに発生しました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR161933 CR177137	以前のリリースとの相互運用性を実現するため、以下の weblogic.Server コマンドライン オプションが復活しました。 -Dweblogic.management.rmiQueueSize -Dweblogic.management.htmlQueueSize	8.1 SP3
CR172130	MBean ルックアップの実行中に名前の指定に失敗して、Null ポインタ例外が発生しました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR172534 CR174686	同期化ブロックを最小限に抑えて過度なスレッドの待機を減らすことにより、WebLogic Server のパフォーマンスが向上しました。	8.1 SP3
CR172579	起動クラスで JDK1.4 ロギング API の LogManager.getLogManager().readConfiguration() を使用すると、stdout が停止されて、それ以降ログ メッセージを使用できなくなりました。 この問題を解決するために、WebLogic Server は匿名ロガーを使用するようになりました。	8.1 SP3
CR172872	クラスタ化されたサーバのノードが停止されたときに、それが移行マネージャのアクティブなサーバのリストから削除されていませんでした。このため、移行可能サーバが削除されて再作成された場合に、InstanceNotFoundException (INFE) が送出されていました。 現在は、移行可能サーバを停止する場合に、移行マネージャのアクティブ サーバ リストをひとつひとつ調べていくときに INFE は無視されます。	8.1 SP3
CR173623	起動時に、管理サーバは管理対象サーバを見つけることができませんでした。 コードを修正してこの問題を解決しました。	8.1 SP3
CR175233	サーバを停止するときに、管理対象サーバの再検出プロセスに関連するメソッドが不適切に呼び出されていました。また、デプロイメントのコールバック ハンドラでは古いコンフィグレーション MBean 参照を使用しました。 この問題は解決され、管理対象サーバの再検出メソッドはサーバの停止時に呼び出されなくなりました。また、古いコンフィグレーション MBean の参照を回避するため、コールバック ハンドラは管理 MBean の参照を使用するようになりました。	8.1 SP3
CR177510	大きな EAR ファイル (600MB) に属するモジュールを追加または再デプロイすると非常に時間がかかりました。 Web アプリケーション モジュールのコードを変更してパフォーマンスを改善しました。 Web アプリケーション モジュールでは、モジュール全体を変更する場合に、モジュールの更新間隔を考慮するようになりました。 大きなアプリケーション デプロイメントの起動時間を減らすため、コンフィグレーション済みアプリケーションのステージング対象属性を永続化するように、デプロイメントが変更されました。 アプリケーション デプロイメント時の、管理サーバと管理対象サーバ間のリモート呼び出しのトラフィックを減らしました。	8.1 SP3
CR180117	ロギング ハンドラ (WLErrorManager.error) で、致命的なエラーを報告するときにロギング コードが繰り返されていたため、別のロギング スレッドでロギング デッドロックが発生しました。 コードを変更して、ロギング ハンドラが致命的なエラーを報告するときのロギング デッドロックを防止しました。	8.1 SP3
CR186194 CR183447 CR125018	userLockoutManager の特定の操作が、ローカルの管理対象サーバではなく、誤って管理サーバ上で実行されていました。 操作が正しいサーバで実行されるようにコードを変更しました。	7.0 SP5 8.1 SP3

プラグイン

変更 要求 番号	説明	修正されたリリース
CR084303	WebLogic Server プロキシ プラグインでは、クライアントからサーバに送信できる HTTP コマンドを制限しました。現在、プラグイン コードの検証ルールでは、WebDAV 実装に必要な以下の HTTP コマンドが許可されています。 DELETE GET HEAD OPTIONS POST PUT *COPY LOCK MKCOL MOVE PROPFIND PROPPATCH SEARCH UNLOCK	6.1 SP7 7.0 SP5 8.1 SP3
CR105123	(ISAPI) iisforward.dll が使用されていない場合に DefaultFileName が機能しませんでした。この問題は次のような場合に見られました。 仮想ディレクトリがコンフィグレーションされている。 MIME タイプが * (すべてをプロキシ) にコンフィグレーションされている。 iisproxy.ini に DefaultFileName が追加された。 ファイル名の指定がない、ディレクトリに対するリクエストの場合、DefaultFileName は使用されませんでした。この問題は、コードを修正することで修正されました。	6.1 SP7 8.1 SP3
CR105173	(NSAPI) クライアント側で、応答がクライアントに送信されるのを止めた場合に (応答を完全に受信する前にブラウザを閉じるなど)、Web サーバ ログに 500 [WRITE TOCLIENT ERROR] が記録されました。 Web サーバの状態モニタ ツールでは、サーバの状態に問題があることを示すために 500 エラーを使用していました。これはサーバの状態についての問題ではなく、クライアントが応答を終了させた問題であるため、エラーは 500 ではないはずです。 リクエストと応答のパスは次のようになります。 クライアント -> プロキシ Web サーバ -> プラグイン -> wls 予期される応答のパスは次のとおりです。 クライアント <- プロキシ Web サーバ <- プラグイン <- wls WebLogic Server が応答を正常に送信したものの、Web サーバはその応答をクライアントに完全に送信せず、クライアントは通信を中断し、Web サーバの access.log には 500 エラーが記録されました。通常このエラーはサーバに問題があることを表します。 クライアントが接続を中断した場合は 500 エラーが生成されないように、コードの変更を実装しました。	6.1 SP7 8.1 SP3
CR113033	(ISAPI) WebLogic Server 6.1 サービス パック 4 で、プラグインは _wl_proxy フォルダに対する WLTempDir フラグを認識しませんでした。フラグを使用するようにコードを修正しました。	6.1 SP7 8.1 SP3
CR113093	[Apache] 次のように、リクエストを別の場所にルーティングするために、httpd.conf で複数の MatchExpression パラメータを使用する場合、 MatchExpression *.jsp WebLogicHost=localhost|WebLogicPort=8001 MatchExpression *.html WebLogicCluster=localhost:8001,localhost:8003 各リクエストが同じグローバル パラメータ情報を上書きしたため、リクエストが間違った場所に送信されました。上記の例では、この問題によって *.jsp リクエストがポート 8003 のサーバに送信されました。 各リクエストでパラメータ情報の独自のコピーを使用するようにコードを修正しました。	6.1 SP7 8.1 SP3
CR122207	(NSAPI) KeepAliveEnabled と DynamicServerList の両方が有効になっている場合、プラグインはソケットを CLOSE_WAIT 状態に置く可能性がありました。この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR122754	(ISAPI) WebLogic Server サービス パック 4 で、プラグイン パラメータ WLExludeByPathOrMimeType は、MIME タイプに基づいて転送する場合に機能しませんでした。この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR122755	(ISAPI) 以前の WebLogic Server サービス パックでは、「.wlforward」が URL に手動で付加されるとプラグイン フィルタは回避されました。最初のリクエストに .wlforward の MIME タイプが含まれる場合は 404 エラーを送出するようにコードを修正しました。	6.1 SP6 8.1 SP3
CR123120 CR123775	(Apache、NSAPI) プラグイン経由で POST メソッドが使用され、Content-Length が定義されていない場合、プロキシ ログ ファイルには次のようなメッセージが含まれました。 POST and PUT requests *must* contain a Content-Length. Content-Length が定義されていない場合はコンテンツ長をゼロ (0) に設定するようにコードを修正しました。	6.1 SP6 8.1 SP3
CR124433	WlForwardPath=/ を指定して IIS をコンフィグレーションしている場合、プラグインはサーバが停止していてもリクエストを転送しようとしました。エラー ページはクライアントに提供されませんでした。この状況ではパスを適切に除外するようにプラグインを修正しました。	6.1 SP6 8.1 SP3
CR124464	(NSAPI) プラグインのクラッシュを引き起こす可能性のあるメモリ リークが検出されました。この問題は、例外オブジェクトが削除された後にプラグインがそのオブジェクトにアクセスしたために発生しました。例外オブジェクトから例外コードを取得した後でそのオブジェクトを削除するようにコードを修正しました。その結果メモリ リークが発生しなくなります。	6.1 SP6 8.1 SP3
CR125690	(ISAPI) 9 個の IIS サーバとクラスタ化された 9 個の WebLogic Server インスタンスが含まれるコンフィグレーションで、IIS が数時間おきにクラッシュして、イベント ログにイベント 37 が書き込まれました。wlproxy ログには次のメッセージがありました。 Thu Oct 09 13:01:46 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1269 of .\iisproxy.cpp Reader::fill() メソッドは、初期バッファの増加中に十分なメモリを割り当てていませんでした。 バッファの最後をマークするのに使用される 4 バイトが失われ、その結果コア ダンプになりました。この問題は、コードを修正することで解決しました。	6.1 SP6 8.1 SP3
CR126103	(NSAPI) NSAPI が HP11.00 上で動作し、2 つの Solaris マシン (それぞれに WebLogic Server インスタンスが 3 つずつ) 上にある 6 ノード クラスタにプロキシしている場合、負荷テスト中にメモリ消費量が徐々に増加して、約 50 分後に ns-httpd プロセスがクラッシュしました。HP11.00 または Solaris では同じ負荷テストがクラッシュしませんでした。proxy.cpp のコードではネイティブ システム コールである strdup() が使用されていて、これによってシステム メモリがプログラムのヒープ領域に割り当てられていました。WebLogic Server は Iplanet の FREE マクロを使用して、以前に割り当てられた領域を不要になった時点で解放しました。FREE は strdup() によって割り当てられた領域を解放しなかったため、メモリ リークが発生しました。 FREE マクロが解放の対象を認識できるように、proxy.cpp 内の strdup() ネイティブ システム コールを、Iplanet の STRDUP マクロですべて置き換えることにより、この問題を解決しました。	6.1 SP6 8.1 SP3
CR126568	(NSAPI) プラグインは POST リクエスト内の %0A を適切に処理しませんでした。 最後に %0A のある POST リクエストが NSAPI プラグイン経由で WebLogic Server に送信されたところ、本文のストリームに余分なデータが追加されて、ヘッダが本文の最後に現れました。リクエストは WebLogic Server に直接送信されて正しく処理されました。 HTTP/0.9 応答を適切に検出および処理するようにプラグインのコードを変更することで、この問題は解決されました。	6.1 SP6 8.1 SP3
CR126982	(NSAPI) WLExcludePathOrMimeType が設定されている場合、そのファイル タイプは WebLogic Server へのリクエストから除外されますが、iplanet はそれらのファイルの提供に失敗しました。 たとえば、.jpg を含む .jsp への以下のようなリクエストが送信されました。 <Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object> .jsp へのリクエストは WebLogic Server にプロキシされ、.jsp は .jpg なしで表示されました。Iplanet は jpg の提供に失敗しました。iplanet のアクセス ログには以下のメッセージが含まれていました。 10.40.4.117 - - [28/Oct/2003:11:45:34 -0500] "GET /weblogic/images/logo_tm_onwt.jpg HTTP/1.1" 500 305 I get the following in wlproxy.log: Tue Oct 28 11:45:35 2003 ============================= new request =============================== Tue Oct 28 11:45:35 2003 INFO: SSL is not configured Tue Oct 28 11:45:35 2003 URI=[/hello.jsp] Tue Oct 28 11:45:35 2003 attempt #0 out of a max of 5 Tue Oct 28 11:45:35 2003 general list: trying connect to '10.40.4.117'/7001/7001 at line 1224 for '/hello.jsp' Tue Oct 28 11:45:35 2003 INFO: New NON-SSL URL Tue Oct 28 11:45:35 2003 Going to check the general server list Tue Oct 28 11:45:35 2003 WLS info : 10.40.4.117:7001 recycled?0 Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept]=[*/*] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-language]=[en-us] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-encoding]=[gzip, deflate] Tue Oct 28 11:45:35 2003 Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)] WLExcludePathOrMimeType が設定されているため、WebLogic Server はリクエストを処理せずに、制御が Web サーバに渡されて、Web サーバがリクエストの処理を続行しなければなりません。 この問題は、コードを変更することで解決しました。	6.1 SP6 8.1 SP3
CR127231	503 HTTP ステータスを受け取った後で、リクエストがクラスタ内の使用可能な次のサーバにフェイルオーバしませんでした。READ_ERROR_FROM_SERVER または CONNECTION_REFUSED 例外が発生するまで、同じサーバが繰り返し試行されました。 現在のコードでは、503 HTTP ステータス エラーを受け取ったら、サーバを障害が発生したものとしてマークし、使用可能なサーバを取得してリクエストを再送信します。すべてのリクエストが使用可能な次のサーバにフェイルオーバするようになりました。	7.0 SP5 8.1 SP3
CR127658	ある接続がプールから取得されたものの、サーバ インスタンスがその接続をすでに閉じていた場合、HALF_OPEN_SOCKET_RETRY 例外が送出されました。その結果、以前の接続オブジェクトが削除されて、同じサーバへの新しい接続オブジェクトが作成されました。 HALF_OPEN_SOCKET_RETRY 例外を適切に処理するコードを追加して、問題を解決しました。	7.0 SP5 8.1 SP3
CR127973	サーブレット セッションに永続的なクッキーが追加された後に、ISAPI プラグインでエラーが発生することがありました。 クッキー解析コードを修正することで問題を解決しました。	7.0 SP5 8.1 SP3
CR128518 CR136974 CR173517 CR173985	(Apache) WebLogic Server の再起動後にプラグインがセッションを中断しました。この問題は、Apache 1.3.x が、受信するリクエストを処理するために複数の子プロセスを作成するために発生しました。各プロセスは独自のサーバ リストを保持しており、サーバリストでは各サーバ エントリが JVMID によってユニークに識別されます。WebLogic Server はプロセスに JVMID を指定します。サーバ インスタンスは再起動時に新しい JVMID を生成します。そのため、プラグインで JVMID が更新されない場合、新しい JVMID を含むクッキーを備えたリクエストは、対応するプライマリ サーバのプラグインを見つけることができません。 コードの修正により、クッキーから抽出された JVMID がサーバ リストに格納されている JVMID と一致しない場合は、WebLogic Server が JVMID を更新するようになりました。	8.1 SP3
CR129026	ISAPI プラグインにおけるメモリ リークはコードの変更により修正されました。	7.0 SP5 8.1 SP3
CR129138	(NSAPI) NSAPI プラグインがバックエンドの WebLogic Server インスタンスで名前解決を実行する場合、名前解決では sysGetHostByName が使用されていました。これにより getHostByName が呼び出され、さらにそのメソッドでは、開いているファイル記述子に最大数の制限がある内部メソッドを呼び出されていました。その結果、名前解決が失敗することがありました。 プライマリ サーバとセカンダリ サーバを検索するためのクッキー解析と JVMID の置換を修正して、この問題を解決しました。	7.0 SP5 8.1 SP3
CR129342	ISAPI プラグインは、WL-PATH-TRIM 値ではなく WL-PATH-TRIM HTTP ヘッダ値を WebLogic Server に送信しました。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR129442	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp のセキュリティ勧告を参照してください。	8.1 SP3
CR129471	以前のサービス パックでは、Apache プラグインは WLTempDir パラメータを認識しませんでした。この問題は修正されました。	7.0 SP5 8.1 SP3
CR131640	Sun Java System Web Server (旧 Sun ONE Web Server) 用プラグイン提供の要求。 現在、Sun Java System Web Server は完全にサポートされています。 詳細については、「WebLogic Platform サポート対象のコンフィグレーション」の「サポート対象の Web サーバおよびブラウザ、ファイアウォール」を参照してください。	7.0 SP5 8.1 SP3
CR132399	HP-UX 11i 上の WebLogic Server と Apache 2.0.48 の動作確認に対する要求。 詳細については、「WebLogic Platform サポート対象のコンフィグレーション」の「サポート対象の Web サーバおよびブラウザ、ファイアウォール」を参照してください。	8.1 SP3
CR132690	Netscape 4.0 を使用している場合、WebLogic プラグインは http://hostname:port/ を http://hostname:port/index.html に変換しませんでした。 コードの修正により、この問題は解決されました。	8.1 SP3
CR133641	iPlanet を使用している場合に、ホスト名検証で問題が発生して以下のメッセージを受け取りました。 INFO: Host () doesn't match (), validation failed ERROR: SSLWrite failed コードを修正してこの問題を解決しました。	8.1 SP3
CR134413	(Apache) プラグインは 302 応答に対する重複した HTTP ヘッダおよび本文を生成しました。プラグインとバックエンド サーバの間に問題はありませんでしたが、Apache サーバが余分な 302 応答を追加していました。 request_handler メソッドの戻り値を OK に戻すコードを追加しました。	7.0 SP5 8.1 SP3
CR135002	複数の仮想ホストを持つ Apache コンフィグレーションにおいて、仮想ホストの 1 つで WebLogic Server プラグインに対して SecureProxy=ON がコンフィグレーションされていて、他の仮想ホストでは SecureProxy または WLProxySSL を使用しない場合に、SSL がコンフィグレーションされていない仮想ホストで、プラグインがバックエンドの WebLogic Server との SSL 接続を試行しました。これによりパフォーマンスの問題が発生しました。 コードを変更して、SSL 接続を開始する必要があるかどうかを決定する新しいパラメータを提供することで、この問題を解決しました。	8.1 SP3
CR135259	サーバが停止しているときに、プラグインが誤ったステータス コードを返しました。 コードの修正により、この問題は解決されました。	8.1 SP3
CR136374	ブラウザと Apache の間で SSL を使用するように Apache がコンフィグレーションされている場合、WebLogic プラグインはリクエストをパスに基づいてルーティングできませんでした。 コードの修正により、この問題は解決されました。	8.1 SP3
CR171978	iisforward.ini ファイルで FilterPriorityLevel が設定されている場合、転送パスが途切れました。 コード修正の実装により、iisforward.ini ファイルで仮想ホストが定義されていない場合は、iisforward.dll ファイルのロード元と同じ場所にある iisforward.ini ファイルが使用されるようになりました。	8.1 SP3
CR172072	WLExcludePathOrMimeType パラメータの機能を拡張して、Location タグ レベルで使用できるようにしました。 WLExcludePathOrMimeType パラメータは、グローバルに定義するだけでなく、Location タグ レベルでローカルに定義できるようになりました。このプロパティをローカルに定義する場合、グローバル プロパティがオーバーライドされることはありませんが、2 つのパラメータの結合が定義されます。	8.1 SP3
CR172497	(NSAPI) 拡張子によるプロキシを行うときに「pluginparams.ErrorPageTest」が失敗しました。 MIME タイプによるプロキシの場合、ErrorPage がローカルにロードされるのを回避するには、WLExcludePathOrMimeType プロパティを使用します。 SUN One Web Server バージョン 6.1 の場合は、追加のコンフィグレーション手順が必要です。 1. obj.conf ファイル内のデフォルト オブジェクトから NameTrans fn="ntrans-j2ee" name="j2ee" を削除します。 2. magnus.conf ファイルから Init fn="load-modules" shlib="C:/Sun/WebServer6.1/bin/https/bin/j2eeplugin.dll" shlib_flags="(global|now)" を削除します。 詳細については、Sun のドキュメント (http://docs.sun.com/source/817-1831-10/agjava.html#wp1084 323) を参照してください。	8.1 SP3
CR173581 CR173878	(Apache) プラグインは、クライアントが接続を閉じている場合でも、「error page is unavailable (エラーページは利用不可能です)」という紛らわしいログ メッセージを apache error.log に記録していました。 この問題は、誤ったログ メッセージをコメント アウトするようにコードを変更することで解決しました。	8.1 SP3
CR173653	WLExcludePathOrMimeType プロパティは、Location タグ内で定義される場合は、グローバル スコープを持つべきではありませんでした (ただし、Location タグの外で定義される場合は、グローバル スコープを持つべきでした)。 定義された適切な Location パスに一致するリクエストにのみ WLExcludePathOrMimeType プロパティが適用されるようにコードを変更することで、この問題を解決しました。	8.1 SP3
CR174431	(NSAPI) Iplanet プラグインは EINTR OS エラーを正常に処理するようになりました。	8.1 SP3
CR174777	[iPlanet] パイプに障害が発生したために、iPlanet ログ ファイルで POST_TIMEOUT エラーが発生しました。 POST データを WebLogic Server に送信しているときに EPIPE エラーが発生した場合は HALF_OPEN_SOCKET_RETRY 例外を送出するように、コードを追加しました。	8.1 SP3
CR175672	(Apache) Debug が OFF に設定されている場合でも、WebLogic プラグインが wlproxy ログ ファイルを開こうとすると Apache サーバがハングします。 デバッグが無効になっている場合はログ ファイルが設定されないようにコードを修正しました。	8.1 SP3
CR175989	(Apache) prefork オプション (マルチプロセスのみ) ではなく worker オプション (マルチスレッド) を使用している場合に、Apache サーバがコアダンプを生成しました。 ロックおよびロック解除のロジックを修正してこの問題を解決しました。	8.1 SP3
CR177707	リリース 7.0 SP02 のプラグインとクライアント証明書を一緒に使用していたとき、WebLogic Server は正常に動作しました。ただし、リリース 8.1 SP02 にアップグレードした後、サーバ ログに以下のエラーが報告されました。 Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException このエラーは、8.1 SP02 プラグインがサーバ インスタンスに送信するときに WL-Proxy-Client-Cert ヘッダを切り詰めたために発生していました。 WebLogic Server に送信されるリクエストに WL-Proxy-Client-Cert がゆるやかに (lazily) 追加されるようにコードを変更しました。	8.1 SP3
CR179537	(ISAPI) Microsoft Windows プラットフォームで、IIS プロキシ プラグインによりヒープが破損しました。 この問題は、内部コードを修正することで解決しました。	8.1 SP3
CR180236	リリース 8.1 SP02 のプラグインとクライアント証明書を一緒に使用した場合、以下のエラーが報告されました。 Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException. このエラーは、WebLogic Server インスタンスに送信するときにプラグインが WL-Proxy-Client-Cert ヘッダを切り詰めていたために発生していました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR187184	VirtualHost タグで複数の Location タグを使用する場合、PathPrepend パラメータが適切に機能しませんでした。 Location タグの内部で定義されるカスタム プロパティがローカルに格納され、グローバル プロパティと衝突しないようにコードを修正しました。	8.1 SP3

RMI/RMI-IIOP

変更 要求 番号	説明	修正されたリリース
CR124596	BEA ORB に追加されたオプションの機能により、ブートストラップ時に再接続が行われ、ハードウェア ロードバランサが接続の試行を適切にバランシングできるようになりました。 この機能と制限の詳細については、『WebLogic RMI over IIOP プログラマーズ ガイド』の「ハードウェア ロード バランサと RMI over IIOP の併用」を参照してください。 注意 : この機能は、WebLogic Server 8.1 SP3 には部分的にしか実装されていません。詳細については「RMI/IIOP に関する確認済みの問題」を参照してください。	8.1 SP3
CR126232	デフォルトでフラグメンテーションが有効になっていたため、パフォーマンスが低下しました。 フラグメンテーションはデフォルトで無効になりました。その結果パフォーマンスの低下はなくなります。	8.1 SP3
CR128594	WebLogic Server は AIX 上の Java オブジェクトを読み込むときに、タイプコードのエイリアスを処理できませんでした。エイリアス ラッパーを破棄するようにコードを変更しました。	6.1SP6 8.1 SP3
CR129099	IIOP は、応答のないクライアントへの送信が失敗したときに、明示的にソケット接続を閉じませんでした。 コードを修正して問題は解決されました。	8.1 SP3
CR132427	シン クライアントが複数のスレッドを使用して、サイズの大きな複合オブジェクトを IIOP 経由で同時に送信すると、以下の例外が発生しました。 Exception in thread ;ExecuteThread: '23' for queue: 'weblogic.kernel.Default'; org.omg.CORBA.MARSHAL: stream corrupted: reading past end of chunk at: 186504 vmcid: 0x0 minor code: 0 completed: No これは、応答における GIOP バージョンの不一致が原因でした。この不一致は、応答の断片と帯域外のハートビート メッセージを交互に配置することにより引き起こされたものです。応答に正しい GIOP バージョンを配置するようにコードを修正して、この問題を解決しました。	8.1 SP3
CR136505 CR136542	IIOP クライアントがトランザクションを開始し、WLS 8.1 ORB 内にホストされた CORBA オブジェクトのメソッドを実行した場合、トランザクションがあるスレッドで開始され、別のスレッドで終了したために、ロールバック例外が発生しました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR136877 CR175151	コンテナが RMI スタブを不適切にキャッシュしたため、RMI オブジェクトをキャストする際に ClassCastException の問題が発生しました。 ある Web アプリケーションの RMI スタブが作成された後に、別の Web アプリケーションが前者と同じ RMI インタフェースを使用してルックアップを行うと、前者の Web アプリケーションのスタブが返されます。したがって ClassCastException が発生します。これは Web アプリケーション同士でクラスローダに互換性がないことが原因です。この問題は、ルックアップが T3 および HTTP 上で行われる場合にのみ発生します。IIOP には適切なキャッシングの実装がなかったため、ClassCastException の原因にはなりません。 この問題は、コードを修正することで解決しました。JNDI ツリー内の同じ RMI オブジェクトをルックアップする 2 つの Web アプリケーションは、どちらかの Web アプリケーションが以前の呼び出しでロードしたスタブを使用する代わりに、個別のスタブを持つようになりました。これが正しい動作です。	8.1 SP3
CR137508	サーバで PeerGone の処理をする場合、マルチプレクサが接続を閉じるよう要求すると、サーバはクライアントを ping します。この ping がハングすると、マルチプレクサはソケットを停止しなくなります。 この問題を修正するため、現在 WebLogic Server では、ハングがエラーと見なされるように、クライアントを ping する前にエラーのフラグを設定します。	8.1 SP3
CR176358	wlclient.jar および wljmsclient.jar シン クライアントを使用して、スタンドアロン JMS クライアントにおける ExceptionListener の機能をテストしているときに、接続が停止すると以下のエラーが発生しました。 Error: CORBA COMM_FAILURE 1398079696 Maybe; nested exception is: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe スレッド上の現在のユーザが null の場合は、代わりに匿名ユーザを使用するように、シン クライアントのコードを変更しました。	8.1 SP3
CR178242	32k より大きな SSL ポートを使用する ORB に、WebLogic Server からアクセスできませんでした。そのようなポートは unsigned short ではなく signed short として解釈されるため、32k より大きなポートは負の数に変換されていました。 ポートを unsigned short として扱うようにコードを変更しました。	8.1 SP3
CR178243	外部 IOR の string_to_object() メソッドを呼び出して確立された IIOP 接続に対して、SSL が実施されませんでした。この問題は、SSL タグに SSL ポートがあり、ブートストラップが SSL 上で行われる場合、またはプレーン ポートがない場合にのみ SSL が使用されるために発生しました。 ORB の関数を使用してブートストラップを行う場合はプロトコルを確認するようにコードを修正しました。それに伴い、weblogic.corba.orb.ORBProtocol プロパティを iiops に設定することで、string_to_object() メソッドを使用して SSL を実施できるようになりました。	8.1 SP3
CR179987	IIOP プロトコルを使用する場合 (たとえば、WebLogic Server シン クライアントを使用する場合や、外部のアプリケーション サーバと相互運用する場合)、null のパスワードを使用してログインしようとすると、null ポインタ例外が発生しました。この障害は T3 プロトコルを使用する場合には発生しませんでした。 IIOP を使用する場合に null のパスワードが許可されるようにコードを変更しました。	8.1 SP3
CR181321	WebLogic シンクライアント JAAS 実装では 64 文字を超えるパスワードが許可されていませんでした。 この問題はコードの修正によって解決されました。	8.1 SP3

サンプル

変更 要求 番号	説明	修正されたリリース
CR130313	WebLogic クラスタ化サンプルの weblogic.xml の DOCTYPE に、誤ったエンティティがありました。 「BEASystems」の「BEA」と「Systems」の間にスペースを追加しました。 最終的な正しい DOCTYPE 定義は次のようになります。 <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 8.1//EN" "http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd";;>	8.1SP3
CR132509	MedRec アプリケーションに含まれている .NET C# サンプル (%WEBLOGIC_HOME%\samples\server\medrec\src\clients\CSharpClient\bin\ReleaseCSharpClient.exe) を使用した場合、クライアントは患者のレコードを正常に取得しましたが、クライアント アプリケーションから「Save Changes」を行おうとすると、日付フィールド エラーが示されました。 コードの変更により日付の検証が修正されました。	8.1 SP3

セキュリティ

変更 要求 番号	説明	修正されたリリース
CR090199	以前は、サーバの再起動時に WebLogic Server を正常に停止するために使用する、UNIX マシンの init.d スクリプトでは、weblogic.Admin を呼び出す際にコマンドラインでユーザ名とパスワードを指定する必要がありました。 起動 ID ファイルを使用するとこのセキュリティ ホールは解消されます。新しいコマンドの StoreUserConfig が、weblogic.Admin ユーティリティと weblogic.Deployer ユーティリティに追加されました。 このコマンドを使用すると、事前に作成された起動 ID (および SerializedSystemIni.dat) ファイルの場所を指定できます。	7.0 SP5 8.1 SP3
CR105933	LDAP プロトコルが接続フィルタ ルールによってサポートされていなかったため、WebLogic Server は LDAP サーバからの接続をフィルタ処理できませんでした。 フィルタ処理できるプロトコルのリストに LDAP を追加したので、現在は LDAP からの接続をフィルタ処理できます。	7.0 SP5 8.1 SP3
CR106192	セキュリティ デバッグ フラグ <ServerDebug DebugSecurityAtn="true" DebugSecurityAtz="true" ...> を StdoutDebugEnabled="true" StdoutSeverityLevel="64" と一緒に設定した場合、サーバはユーザ パスワードをクリア テキストで stdout にロギングしました。 ログ ファイルに書き込まれる文からパスワード文字列を削除することにより、この問題を解決しました。	7.0 SP5 8.1 SP3
CR107359 CR135441	CR107359 では、ノード マネージャがコンフィグレーション済みのプライベート キー パスワードをパスワードとして使用し、暗号化サービスをインスタンス化する問題が報告されました。これは、暗号化サービスをインスタンス化できないために、ノード マネージャのコンフィグレーションが変更されて、新しいプライベート キー パスワードがコンフィグレーションされる場合の問題でした。 内部的な文字列をパスワードとして使用して暗号化サービスをインスタンス化するように、ノード マネージャが変更されました。ただし、暗号化された既存のプロパティを、新しい暗号化サービスで複合化することはできません。したがって、既存のプロパティは、古いサービスで複合化してから新しいサービスで暗号化し直す必要があります。 ノード マネージャは、サービス パックのインストール後 (またはパッチの適用後) に最初に再起動されるときに、この変換を行います。以降の再起動では、新しい暗号化サービスがインスタンス化されます。	8.1 SP3
CR107373 CR178661	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_52.01.jsp のセキュリティ勧告を参照してください。	8.1 SP3
CR108624 CR128228	パフォーマンス チューニングの機能が強化され、LDAP ディレクトリでのグループ メンバシップ検索の深さを制限できる新しい属性が追加されました。メンバシップの階層に従って検索を調整し、グループ メンバシップが見つからないことがわかっている検索を排除することができます。 追加された新しい属性は、GroupMembershipSearching と MaxGroupMembershipSearchLevel です。	7.0 SP5 8.1 SP3
CR112147	weak、strong、authenticate など既存の ServletAuthentication API メソッドは、呼び出し側に LoginException を伝播していませんでした。weak メソッドや authenticate メソッドと同様に動作する、オーバーライドされた login メソッドが 2 つ追加されました。strong メソッドと同様に動作する assertIdentity メソッドも追加されました。これらの新しいメソッドは呼び出し側コードに LoginException を伝播します。	8.1 SP3
CR112233 CR121114 CR133071 CR135017	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_61.00.jsp のセキュリティ勧告を参照してください。	8.1 SP3
CR112471	組み込み LDAP サーバのグループ検索には [グループすべてのフィルタ] は含まれていませんでした。[グループすべてのフィルタ] が含まれるようにコードを追加しました。このフィルタは Administration Console から有効にします。	8.1 SP3
CR112820 CR112875 CR135819	weblogic.security.SSL.TrustManagerJSSE インタフェースで、カスタムの TrustManager には certificateCallback() の動作を制御する設定が含まれていました。この設定は validateErr の変数によってオーバーライドされました。 コードを修正して問題は解決されました。現在、WebLogic Server の SSL は、カスタム トラスト マネージャによって返される結果を評価します。	7.0 SP5 8.1 SP3
CR120233 CR123481 CR178414	カスタム監査とカスタム ロール マッパーをコンフィグレーションしているときに java.lang.ArrayStoreException が送出される問題は、コードの変更により解決しました。	8.1 SP3
CR120850	WebLogic Server 6.1 SP05 で、weblogic.net.http.HttpsURLConnection が https.nonProxyHosts 環境変数を受け取りませんでした。この問題は次の状況で見られました。 クライアント <--> プロキシ <---> サーバ クライアントは WebLogic Server の内部で動作していることも、スタンドアロンの Java プログラムの場合もあります。対象のホストが https.nonProxyHosts で指定されている場合でも、リクエストは常にプロキシを経由しました。代わりに、http.nonProxyHosts でホストが指定されている場合は、問題は発生しません。proxyHost が定義されていても、proxyHost ではなくホストへの直接の接続が確立されます。 分析の結果、proxyHost が定義されている場合でも、https.nonProxyHosts で指定されているホストに直接接続するロジックがわかりました。この問題は、http.nonProxyHosts では発生せず、https.nonProxyHosts でのみ発生しました。 proxyHost が定義されている場合でも、https.nonProxyHosts で指定されているホストに直接接続するために、適切なロジックが開発されました。	6.1 SP6 8.1 SP3
CR121043	JSP で直接設定されたプロパティが、HTTP クライアントで取得および設定されませんでした。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR121310 CR127992 CR155332	双方向 SSL が Web サービス クライアントで適切に動作しませんでした。 WLSDEBUG マクロを使用するように convertToCertiom() メソッドの WEBLOGIC_X509_WORKAROUND バリエーションを更新して、この問題を解決しました。	8.1 SP3
CR123182	ID アサーションに使用される X509 トークンが、リクエスト ヘッダではなく証明書から取得されていました。X509 ID アサーションがコンフィグレーションされていない場合にもこの問題が発生しました。 セキュリティ レルムの ID アサーション プロバイダが X509 トークンを使用するようにコンフィグレーションされているかどうかを判別するために、テストを追加しました。X509 がコンフィグレーションされていない場合、ID アサーションに使用されるトークンを決定する際に、X509 トークン タイプは無視されます。	8.1 SP3
CR123716	サーバの停止に関するセキュリティ ポリシーが、サーバのすべてのライフサイクル メソッドに適用されていました。 サーバの停止にのみ適用されるようにセキュリティ ポリシーを更新しました。	8.1 SP3
CR125592 CR196597	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-66.00.jsp のセキュリティ勧告を参照してください。
CR124746 CR175051 CR175045	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_48.01.jsp のセキュリティ勧告を参照してください。	7.0 SP5 8.1 SP3
CR125911	パフォーマンス チューニングの機能が強化され、グループ メンバシップ検索の深さを制限できる新しい属性が追加されました。メンバシップの階層に従って検索を調整し、グループ メンバシップが見つからないことがわかっている検索を排除することができます。 新しい属性は GroupMembershipSearching および MaxGroupMembershipSearchLevel です。その場合は、『WebLogic Security の管理』の「WebLogic 認証プロバイダおよび LDAP 認証プロバイダのパフォーマンスの向上」を参照してください。	7.0 SP5 8.1 SP3
CR126062	LDAP ディレクトリからデータをインポートするときに NullPointerException が発生する場合がありました。 例外を回避するコードが追加されました。	8.1 SP3
CR126275	ドメインで監査 MBean (または同様のサーバ以外の MBean) がコンフィグレーションされている場合、管理対象サーバは起動時にその MBean に通知リスナを追加しようとしました。管理対象サーバは次に NotificationRelay リスナをキャストしようとしましたが、例外が発生しました。 WebLogic Server は NotificationRelay リスナをキャストしなくなりました。	8.1 SP3
CR126829	WebLogic Security フレームワークは、weblogic-ra.xml デプロイメント記述子ファイルにコンフィグレーションされているセキュリティ ポリシーを無視していました。 Java セキュリティ ポリシーと WebLogic セキュリティ ポリシーを組み合わせることで、この問題を解決しました。weblogic-ra.xml デプロイメント記述子ファイルで指定されたセキュリティ ポリシーが尊重されるようになりました。	8.1 SP3
CR126837	iPlanetAuthenticator MBean によって使用される listGroupMembers 実装を介してユーザのリストを取得する際に問題がありました。具体的には、listGroupMembers() メソッドが空のカーソルを返しました。 StaticMemberDNAttribute のデフォルト値を「uniquemember」に変更して、この問題を解決しました。	8.1 SP3
CR127426	他の LDAP 認証プロバイダが静的グループを使用するのに対し、WebLogic 認証プロバイダは動的グループを使用してグループ メンバシップを表現していました。GroupReader MBean の isMember() メソッドで使用される再帰的検索では静的グループを想定していたため、WebLogic 認証プロバイダでグループ メンバシップの検索が適切に動作しませんでした。 コードを追加して、動的グループを扱うように再帰的検索を更新しました。GroupReader MBean の isMember() メソッドの動作は、LDAP ベースのすべての認証プロバイダで一貫性を持つようになりました。	8.1 SP3
CR127964	組み込み LDAP サーバがアプリケーションの処理中に破損する可能性があります。この状況では ArrayIndexOutOfBounds 例外が発生します。 ArrayIndexOutOfBounds 例外を修正するコードが追加されました。	8.1 SP3
CR128054	WebLogic セキュリティ システムの署名の実装では、誤って発信メッセージで dsig:Id 属性を使用し、着信メッセージの dsig:Id のみをチェックしていました。 コードを修正して問題は解決されました。	8.1 SP3
CR128150 CR130280 CR135329	「Deployer」グローバル ロールのユーザが以下のタスクを実行できませんでした。 JDBC 接続プールを作成後にテストする (Administration Console または weblogic.Admin TEST_POOL から) JDBC 接続プールの Statement キャッシュをクリアする JDBC 接続プールをサスペンド、強制サスペンド、破棄、強制破棄、または停止する JDBC 接続プールを再開するまたは有効にする J2EE アプリケーションまたはアプリケーション コンポーネントをクラスタにデプロイまたはアンデプロイする Deployer はこれらのタスクの実行を許可されるようになりました。	8.1 SP3
CR128873	クラスパスに他の JCE プロバイダがあるときに RC4 が動作せず、その結果 SSL ハンドシェークが終了しました。 ハンドシェーク アルゴリズムとして RC4 が使用されていても、nCiphr JCE プロバイダがある場合に SSL ハンドシェークが中断しなくなりました。	8.1 SP3
CR130467 CR168230 CR172100	WebLogic Server ドメインに 2 つの Active Directory 認証プロバイダがあり、同じ Active Directory LDAP サーバを使用するようにコンフィグレーションされている場合、両方のプロバイダが LDAP サーバに同時にアクセスしようとすると、LDAP サーバへの接続が失敗しました。WebLogic Server は無効な接続をクリアするために再起動する必要がありました。 Active Directory 認証プロバイダに [接続再試行制限] 属性が追加されました。この属性を指定すると、最初の接続が失敗した場合、LDAP サーバへの接続が再試行されます。	8.1 SP3
CR131535	サーバ インスタンスが Verisign SGC/Stepup 証明書を使用してコンフィグレーションされている場合、SSL ハンドシェークが次の例外により失敗します。 <<WLS Kernel>> <> <BEA-000430> <isMessageComplete javax.net.ssl.SSLProtocolException: FATAL Alert:UNEXPECTED_MESSAGE - A message out of sequence was received. Verisign SGC/Stepup 証明書のサポートを追加することで、この問題を解決しました。	8.1 SP3
CR131659	SSLSocketFactory.getJSSE の呼び出しで行われた同期化よって、パフォーマンスが過度に影響を受けました。 この問題はコードの修正によって解決されました。	8.1 SP3
CR132276	カスタム キーストアを含むドメインで、Operator セキュリティ ロールを持つユーザが、ノード マネージャを使用して管理対象サーバを起動できませんでした。このエラーは、Operator セキュリティ ロールが、管理対象サーバの起動に必要となる、保護された属性へアクセスするパーミッションを持っていないために発生しました。 コードの修正により、Operator セキュリティ ロールを割り当てられたユーザは、ノード マネージャを使用して、Administration Console から管理対象サーバを起動できるようになりました。	8.1 SP3
CR132346 CR174423	ProxyAuthenticator のコンストラクタが呼び出されず、SSLLayeredSocket を使用しなかったため、java.net.ConnectException が発生しました。 プロキシ認証されたソケットを使用するように T3SJvmConnection.newSocket メソッドを変更しました。	8.1 SP3
CR132949 CR178812	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_55.00.jsp のセキュリティ勧告を参照してください。	8.1 SP3
CR133655 CR183238	接続プールのコードが適切に動作しなかったため、LDAP 検索の速度が低下しました。たとえば、サードパーティ製 LDAP による認証が遅くなりました。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR134110	ユーザ名およびパスワードと -upload フラグを指定して STOREUSERCONFIG を使用すると、weblogic.Deployer ユーティリティが java.io.FileNotFoundException を送出しました。 いかなる場合でも Deployer が userconfig を使用するように、コードを追加しました。	7.0 SP6 8.1 SP3
CR134367	File.canWrite() における JVM のバグが原因で、setUID スクリプトを使用する場合にコンフィグレーション ファイル (config.xml) を変更できませんでした。 コードの変更による回避策を WebLogic Server に実装しました。File.canWrite() の問題の詳細については、http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4993360 を参照してください。	8.1 SP3
CR135488	以前は、セキュリティ プロバイダのディレクトリにあるファイルはどれもセキュリティ プロバイダとして扱われ、ファイル拡張子に関係なくサーバの起動時にロードされていました。現在は、拡張子が .jar または .zip のファイルだけがセキュリティ プロバイダとして扱われます。 他の拡張子を使用するセキュリティ プロバイダはロードされなくなります。ドメインでセキュリティ プロバイダに他のファイル拡張子を使用している場合は、サービス パック 3 に合わせて変更してください。	7.0 Sp5、8.1 SP3
CR136262 CR182644	組み込み LDAP には、1000 件までの検索の制限がありました。 この問題は、コードを修正することで解決しました。組み込み LDAP は、検索クエリの実行時に、もっと多くの要素を返すことができます。	8.1 SP3
CR137054	アプレットで setIgnoreTrustValidation(true) メソッドを使用すると java.lang.ExceptionInInitializerError が発生しました。 アプレットのセキュリティ マネージャが SSL ハンドシェークを許可するように、コード修正を実装しました。	8.1 SP3
CR171885 CR099476	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_59.00.jsp のセキュリティ勧告を参照してください。	8.1 SP3
CR172151	t3s を使用した後でローカル コンテキストを作成するときに、認証エラーが発生しました。 この問題はコードの変更により解決されました。コンテキストを閉じるときに、スレッドから証明書がクリアされます。	8.1 SP3
CR172510	認証の際に、セキュリティ レルムのデフォルト認証プロバイダは、LDAP に格納されているのと同じ大文字/小文字を使用して、サブジェクトにユーザ プリンシパル名を設定する必要があります。サブジェクトはクライアントがログインの際に使用した大文字/小文字で設定されました (LDAP ではユーザ名の大文字/小文字は区別されます)。 Administration Console で WebLogic LDAP 認証プロバイダの [詳細] タブに UseRetrievedUserNameAsPrincipal 属性を追加することで、この問題を解決しました。この属性が有効な場合は、入力されたユーザ名ではなく、LDAP からユーザ名を取得して認証用のプリンシパル名として使用します。	8.1 SP3
CR172548	デフォルト ドメイン ディレクトリにある DefaultAuditRecorder.log ファイルのサイズが非常に大きくなり、使用可能なディスク スペースを使い果たす可能性があります。 監査ログ ファイルが書き込まれるディレクトリを指定するためのコマンドライン引数を提供することで、この問題を解決しました。 -Dweblogic.security.audit.auditLogDir 詳細については、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」を参照してください。	8.1 SP3
CR173632	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-60.00.jsp のセキュリティ勧告を参照してください。	8.1 SP3
CR173853	デフォルト ドメイン ディレクトリにある DefaultAuditRecorder.log ファイルのサイズが非常に大きくなり、使用可能なディスク スペースを使い果たす可能性があります。 [★Ｏローテーション時間 (分)Ｏ★] 属性を導入することでこの問題を解決しました。この属性では、新しい DefaultAuditRecorder.log ファイルを作成するまでに待機する分数を指定できます。指定された時間が経過すると、監査ファイルが閉じられて新しいバックアップ ファイルが作成されます。 詳細については、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」を参照してください。	8.1 SP3
CR174021	Active Directory のグループ メンバシップを問い合わせるときのパフォーマンスが効率的でないことがわかりました。 コードを修正してこの問題は解決されました。 詳細については、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」の章で「WebLogic 認証プロバイダおよび LDAP 認証プロバイダのパフォーマンスの向上」の節を参照してください。	8.1 SP3
CR175135	UserInfo を拡張したカスタム オブジェクトが認証用に InitialContext に渡されませんでした。そのため下位互換性がなくなります。 ユーザが UserInfo を拡張したカスタム オブジェクトを認証用に渡した場合、このオブジェクトが処理されるように、Security Mbean と Administration Console の [互換性｜全般] タブに [カスタム オブジェクト認証を有効化] 属性が追加されました。この属性はパフォーマンスに影響するため、デフォルトでは無効になっています。	8.1 SP3
CR177133	t3s プロトコルに対する接続フィルタが説明されているとおりに動作しませんでした。 コードを修正して問題は解決されました。	8.1 SP3
CR177514	Administration Console を使用すると、特殊な文字 (ドイツ語のウムラウトなど) を含むパスワードで新しいユーザを作成できました。 ただし、新しいユーザがそのパスワードでログインしようとしても、パスワードが受け入れられませんでした。 LDAP エントリからパスワードのバイトを UTF-8 で取得するコードによって、この問題を解決しました。	8.1 SP3
CR178854	WebLogic Server 8.1 の以前のサービス パックに付属していたデモ用証明書と信頼性のある CA 証明書は、2004 年 5 月 14 日で期限が切れ、基本制御機能で動作しなくなります。今回のサービス パックには、基本制御機能で動作する、信頼性のある CA 証明書の更新版が含まれています。証明書 (democert.pem、democert1024.pem、ca.pem、ca1024.pem, trusted.crt、demo.crt) がファイルとして提供されています。 WebLogic Server 8.1 の以前のサービス パックを使用している場合は、http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp の指示に従って、更新されたデモ用証明書と信頼された CA 証明書にアップグレードできます。	8.1 SP3
CR179066	サーバの起動時に、LDAP コードで静的なアプリケーション デプロイメントがフリーズしました。この状況は、EJB などのコンポーネントに対するセキュリティ ロールをデプロイするときに発生しました。LDAP コードで通知がなかったためにフリーズが発生しました。 組み込み LDAP のコードを修正してこの問題を解決しました。	8.1 SP3
CR182276	iPlanet LDAP サーバは、明示的なユーザ検索を実行しているときにワイルドカード検索を返しました。 「正確な名前の検索」のアルゴリズムにも一致するように、「ワイルドカード検索」のアルゴリズムを修正しました。	8.1 SP3
CR182650	CSIv2 (Common Secure Interoperability Version 2) および GSS (Generic Security Service) トークンに基づく ID アサーションを使用する場合、特定の長さのプリンシパル名が適切にデコードされませんでした。その結果、IdentityAssertionProvider が呼び出されなかったり、切り詰められたプリンシパル名で呼び出されたりしました。 コードの修正により、GSS トークンが適切にエンコードおよびデコードされるようになりました。	8.1 SP3

サーブレット

変更 要求 番号	説明	修正されたリリース
CR098500	ディレクトリにマルチバイトの名前のファイルがある場合、ディレクトリ インデックス ページが壊れて、対応するインデックスのファイルにアクセスできなくなる可能性がありました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR108034	接続を切断するユーザによって生成された不適切なエラー メッセージが抑制されていました。	7.0 SP5 8.1 SP3
CR108350	Administration Console で、ログ ファイル フォーマットが共通ログ フォーマット (CLF) と拡張ログ フォーマット (ELF) の間で動的に変更できると不正に表示されていました。このコンフィグレーション パラメータを変更する場合にはサーバの再起動が必要になることを正しく示すように、コードが変更されました。	7.0 SP5 8.1 SP3
CR108577 CR175505	アンデプロイメント時にモジュールの順序が考慮されませんでした。 このロジックは修正されています。モジュールは、デプロイされたときと逆の順序で、非アクティブ化されてロールバックされるようになりました。	7.0 SP5 8.1 SP3
CR109885 CR135207	障害の発生したセカンダリ ノードへのセッション レプリケーションによって、プライマリ ノードがハングしました。プライマリ ノードはセカンダリ ノードに接続しようとし、他のスレッドが待機しなければならないロックを保持しているようでした。 コードを修正して問題は解決されました。	7.0 SP5 8.1 SP3
CR110692	WebAppComponentRuntimeMBean には、アプリケーションが設定するクッキーに関する情報の取得に使用できるメソッドが含まれています。たとえば、アプリケーションが設定するクッキーを識別するコメントと名前を取得できます。	8.1 SP3
CR110798	JSP で weblogic.servlet.security.ServletAuthentication.killCookie(req) を呼び出すと、セッションはクリーン アップされずに WebLogic Server に残りました。コードの修正により、killCookie(req) が完了する直前にセッションが無効化されるようになりました。	7.0 SP5 8.1 SP3
CR120281	HttpServletRequest.getParameterValues(String) は、パラメータ値を 2 回返すことがありました。 分析の結果、転送されたリクエストのクエリ パラメータは、適切に解析されたパラメータ値が 2 回返される方法で解析チェックが行われていました。 コードを修正して問題は解決されました。	8.1 SP3
CR120440	シングル サインオン コンフィグレーションに複数の Web アプリケーションがデプロイされていて、あるアプリケーションが weblogic.servlet.security.ServletAuthentication.invalidateAll(request) を呼び出した場合、それ以外のアプリケーションの HttpSessionListeners はセッション タイムアウトが発生するまで呼び出されませんでした。これは、最初の Web アプリケーションに関連付けられたセッションのみが無効化の対象として登録されていたことが原因で発生しました。ユーザが認証された後、以降のセッションは登録されませんでした。 コードを修正したことで、必要に応じて invalidateAll(request) によって、すべての Web アプリケーションのセッション ID とコンテキスト パスの両方が無効化の対象として登録されるようになりました。	6.1 SP6 8.1 SP3
CR121175	HTTPClusterServlet は、セッション クッキーの JVMID によって識別されるプライマリ インスタンスとは異なるサーバ インスタンスへリクエストをルーティングしました。 HTTPClusterServlet は、リクエストを複数のクラスタ化されていない管理対象サーバにプロキシしていました。バックエンドのサーバ インスタンス上の Web アプリケーションは、index.jsp および frameset.jsp で構成されていました。Web アプリケーションの開始点は index.jsp であり、そこでセッションが作成されます。index.jsp は <jsp:forward> を使用してリクエストを、フレームセットを含む frameset.jsp に転送します。 index.jsp が初めてプロキシ サーバ (HTTPClusterServlet) によってアクセスされると、応答してセッションが作成され、クッキーが設定されました。index.jsp が frameset.jsp に転送すると、(フレームセット内の各 JSP に対する) 新しいリクエストがクッキーと共に送信されました。断続的にクッキーはリクエスト内に見つかりましたが、リクエストがサーバ リスト内のサーバ (プライマリ サーバ以外) に送信され、セッションは消失しました。プロキシ ログには次のようなエントリがありました。 <Thu Aug 21 15:41:15 PDT 2003>: Found cookie: -1339390245 <Thu Aug 21 15:41:15 PDT 2003>: In-bound headers: <Thu Aug 21 15:41:15 PDT 2003>: Content-Length: 117 <Thu Aug 21 15:41:15 PDT 2003>: #### Trying to connect with server -1189081773!172.17.26.74!7201!443 この問題は、サーバ リストを更新するロジックを変更することで解決しました。リスト内のサーバの JVMID を更新すると、サーバがリストから削除され、更新されてから再びリストに追加されるようになりました。オブジェクトを更新するだけではリストのソートは行われませんでした。	7.0 SP5 8.1 SP3
CR121359	JSTL 終了タグでタグ名と山括弧 (>) の間にスペースが含まれていると weblogic.utils.ParsingException が発生しました。 この問題は、タグ名と「>」の間にゼロまたは 1 個のスペースを許可するように、コードを修正することで解決されました。	7.0 SP5 8.1 SP3
CR121846	サーバは、拡張ログ フォーマット ヘッダを書き込む前に、標準のログ エントリをログ ファイルに書き込むことができました。この状況は、ログ ローテーション中に、複数のスレッドが同時に新しいログ ファイルに書き込もうとすると発生する場合がありました。 コードを修正したことで、ログ ローテーションを処理するスレッドが、ログ ヘッダの書き込みが終了するまで新しいログ ファイルに排他的にアクセスするようになりました。	6.1 SP6 8.1 SP3
CR124174	WebAppComponentMBean の以下のセッター メソッドは非推奨になりました。 SessionCookieName、SessionCookieComment、SessionCookieDomain、SessionCookiePath、および SessionIDLength。	8.1 SP3
CR124600	WebLogic Server は、ELF ロギング サービスの初期段階で高い負荷がかかると ELF ヘッダの読み込みに失敗することがありました。この状況は、複数のスレッドが ELF ロギングの初期段階を同時に呼び出した場合に発生しました。 コードを修正して、初期のメソッドをゆるやかに (lazily) 呼び出さずに、コンストラクタに移動しました。	8.1 SP3
CR125846	サーブレット仕様に従って、正確に一致するパターンはワイルドカード パターンより優先されなければなりませんが、これが正しく機能していませんでした。たとえば、"/TestPath/*" が "WildcardServlet" に対応し、"/TestPath" が "ExactMatchServlet" に対応するときに、受信する相対 URI が '/TestPath' である場合、WildcardServlet ではなく、ExactMatchServlet が提供される必要がありました。 この問題は、パターン マッチング機能に適切な変更を行うことで解決しました。	7.0 SP5 8.1 SP3
CR127050	以下の場合に NullPointerException が発生することがありました。 スレッド t1 が getLogStream() を呼び出して、logStream フィールドの値が null かどうかをチェックした。 別のスレッド t2 がログ ファイルのローテーションを試みて、logStream 値を null に変更した。 getLogStream() メソッドが t2 によって変更された logStream 値を返した。 WebLogic Server は同期ブロック内の logStream 値を返すように なりました。	8.1 SP3
CR127621	weblogic.management.configuration.WebServerMBean の値 maxKeepAliveSecs がコンフィグレーション可能になりました (最大値 300 秒)。	8.1 SP3
CR127644	javax.servlet.http.HttpSessionActivationListener および javax.servlet.http.HttpSessionBindingListener は使用可能なリスナ インタフェースですが、APPC 用の WebAppDescriptorComplianceChecker で欠落していたので、wlappc を使用したコンパイル時にエラーが発生します。 欠落していたインタフェースが追加されました。	8.1 SP3
CR128051	転送を行うリクエストをポストするクライアントに対して、次の警告メッセージが表示されることがあります。 "Warning: One of the getParameter family of methods called after reading from the ServletInputStream(), can't mix these two!". 転送されたリクエストはポスト パラメータが解析された後にのみ、クエリ パラメータの取得を試みるようにコードが修正されました。その結果、警告メッセージは表示されなくなりました。	8.1 SP3
CR128234 CR174645	CR121053 によって作成されたパッチでは、SessionListener の sessionDestroyed() メソッドからセッション ID にアクセスし、ネットワーク チャネル名が null の場合に、NPE が発生しました。 ネットワーク チャネルの null 値をチェックするようにコードを変更しました。 関連付けられたリクエストがなく、したがってネットワーク チャネル名が返されないために、NPE が発生しました。これはユーザ エラーにより発生したものですが、NPE の送出は適切な応答ではありません。最適な解決策はデフォルトのネットワーク チャネル名を返すことです。ただし、この方法はネットワーク チャネルが使用されている場合は適していません。	8.1 SP3
CR128420	breakUpAndWriteItOutAsNecessary() は 1 行あたり最大 72 バイトを適用するためにマニフェスト ヘッダを分割しようとし、出力ストリームに一度に 1 行を書き込みました。この問題の原因は、改行の開始オフセットが間違っていることでした。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR128464	デプロイメントを繰り返しているときに、web.xml ファイルの welcome-file-list エントリが WebLogic Workshop で無視されました。 この問題は、インデックス ファイルを提供する前に、ファイルが存在するかどうかのチェックが行われたために発生しました。分割ディレクトリ アプリケーションの docroot (src ディレクトリと想定されるが、WebLogic Workshop アプリケーションでは outdir ディレクトリになる) にファイルが存在しなかったため、ファイルが検出されませんでした。 src ディレクトリと outdir ディレクトリの両方でインデックス ファイルを検索するようにコードを変更しました。	8.1 SP3
CR128624 CR132552	アプリケーションが http://localhost:7001/WebApp/target.jsp#section4 のような HTML アンカー タグが含まれている URL をエンコードしようとすると、結果の URL は http://localhost:7001/WebApp/target.jsp#section4;jsessionid= 16OXDN2vax5g2lbGucG4uspB9h6vzhaZw8KtDLl5urAhK96dqvfo!-1835542719 のように不正なものになりました。 アンカー タグは URL の末尾になければならないので、無視されます。正しい URL は、http://localhost:7001/WebApp/target.jsp;jsessionid= 16OXDN2vax5g2lbGucG4uspB9h6vzhaZw8KtDLl5urAhK96dqvfo!-1835542719#section4 のようになります。 元の URL にクエリ文字列がない場合にはアンカーを探し、そのアンカーをエンコードされた URL の末尾に追加するように、コードを追加しました。	7.0 SP5 8.1 SP3
CR128679	save-sessions が有効になっている Web アプリケーションでは、アンデプロイメント時にメモリ リークが発生し、Object.hashCode がユニークであることについて間違った想定が行われていました。 コードの修正により、Web アプリケーションのコンテキスト パスが必ずセッション データのキーとして使用されるようになり、アンデプロイメント時にはセッション データが削除されるようになりました。	8.1 SP3
CR129211	ServletOutputStream.write(byte) を使用してバッファ サイズを超える書き込みを行うと、無限ループが発生しました。 バッファがいっぱいで、かつ、autoflush が false に設定されている場合に境界条件のチェックを更新するようにコードを修正することで問題は解決されました。	7.0 SP5 8.1 SP3
CR129553	サーブレット コンテキスト リスナは、アプリケーション (Web アプリケーション) のアンデプロイメント時には web.xml ファイルでの宣言に対する逆の順序で呼び出されませんでした。 コードの修正により、サーブレット コンテキスト リスナがアンデプロイメント時に逆の順序で呼び出されるようになりました。そのため、コンテキスト リスナ順の間違った動作を前提としているすべてのアプリケーションはサーブレット仕様の要件に従い、この変更による影響を受けます。	8.1 SP3
CR130051	session 属性がシリアライズされず、無効にできないメモリ セッション データに対して、常に次の警告メッセージがログに記録されます。 <Warning> <HTTP Session> <BEA-100061> <Web application: ServletContext(id=13577225,name=SessionServlet,context-path=/SessionServlet) tried to place a non-serializable attribute: simplesession.time into the session: 1PNw8xxxxx.This attribute will be lost upon redeployment.This message is logged only once per session.> この問題は、コードを修正することで次のように解決しました。 この警告メッセージはサーバが開発モードで実行されている場合にのみログに記録されます。 メモリ セッション データに対しては、この警告メッセージは save-sessions-enabled フラグが true に設定されている場合にのみログに記録されます。	8.1 SP3
CR130182	サーブレットとフィルタが属性を使用し、かつ、フィルタがクラスローダの変更の有無をチェックした後にサーブレット クラスが更新された場合、サーブレットとフィルタのクラスローダ間の相違が原因となって ClassCastException が発生することがありました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR130487	旧バージョンの WebLogic Server の JSP クラスがバージョン 8.1 のサーバ インスタンスにデプロイされていることが原因で、webauction テストの実行中に次のエラー メッセージが表示されました。 java.lang.NoSuchMethodError: weblogic.servlet.jsp.StaleChecker.isResourceStale これは、バージョン 8.1 向けに stalechecker インタフェースが変更されたためです。この問題は、コードを修正することで解決しました。そのため、isStale() メソッドが例外を送出すると、例外は捕捉され JSP が再生成されます。	8.1 SP3
CR132321	サーブレット フィルタからラップされた応答を持つ HttpProxyServlet を使用すると ClassCastException が発生しました。 コードの修正により、応答ラッパーの場合には元の応答が取得されるようになりました。	8.1 SP3
CR132447	SESSIONID 名がサブ文字列としてヘッダに含まれているクッキーがある場合、SESSIONID が予期せずに変更されました。 この問題は、クッキー ヘッダから SESSIONID を解析するロジックを修正することで解決しました。 この新しい変更により、既存の SESSIONID または既存のセッションが存在する場合は新しい SESSIONID は作成されません。	8.1 SP3
CR132488	Administration Console で weblogic.xml を編集すると、SAXParseException が生成されました。 コードの修正により、Administration Console を介して weblogic.xml が生成される場合には、weblogic810-web-jar.dtd に従って weblogic.xml の要素の順序が変更されました。	8.1 SP3
CR132522	デフォルトの Web アプリケーションのない Web サーバでは、欠落したリソースに対する HTTP リクエストは次のような不正な日付ヘッダが含まれた応答を受信しました。 HTTP/1.1 404 Not Found Date: Thu, 01 Jan 1970 00:00:00 GMT このヘッダは、RFC2616 のセクション 14.18 に基づいて無効です。この問題は、コードを修正することで解決しました。	8.1 SP3
CR133291	デフォルトの fileServlet によるファイルの送信中にクライアントがリクエストを取り消すと、プロトコル例外 excjava.net.ProtocolException: Didn't meet stated Content-Length が発生していました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR133558	null 値が渡されると、ServletContext.setAttribute が NullPointerException を送出しました。 この問題は、setAttribute() に null 値が渡されると removeAttribute() を呼び出すようにコードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR134412	Struts フレームワークを使用する Web アプリケーションでは、アプリケーションのエラー ページに対してクラスローダと環境コンテキストが正しく設定されませんでした。 Web アプリケーションのエラー ページに対してクラスローダと環境コンテキストが正しく設定されるようにコードを修正しました。	8.1 SP3
CR134414	シリアライズ可能なサーブレット リクエスト属性を追加し、これをシリアライズできない値で上書きすると、元の値が新しい値をマスクします。 シリアライズ可能な値がシリアライズできない値に置き換えられる場合には、シリアライズ可能な属性の HashMap テーブルからの値の削除が必要に応じて試みられるように、コードを修正しました。	8.1 SP3
CR134767 CR130216	開発モードでは、ファイルのタイムスタンプが最後のデプロイメントから変更されると、servlet-init が 2 回呼び出されていました (1 回目はデプロイメント サブシステム、2 回目は App-Poller による呼び出し)。 コードの修正により、WebLogic Server が実行状態でなくなるまで GenericPoller がデプロイされないようになりました。	8. 1 SP3
CR134813	サーブレット 2.4 仕様に従って、サーブレット、コンテキスト リスナ、およびフィルタを初期化するようにコードが修正されました。	8.1 SP3
CR136273	Internet Explorer からファイルをダウンロードしようとすると、以下のエラーが発生しました。 "Internet Explorer Cannot download a .txt from localhost Internet Explorer was not able to open this internet site.The requested site is either unavailable and cannot be found.Please try again later." このエラーは、ブラウザが Content-Disposition ヘッダと Cache-Control ヘッダの両方が設定されている状況に対応できなかったために発生しました。 Content-Disposition ヘッダと Cache-Control ヘッダの両方が設定されているかどうかをチェックするコードを追加しました。両方のヘッダがある場合は、ユーザにその状況を通知してコードのデバッグに役立てるための、以下の警告メッセージがログに記録されます。 ####<May 4, 2004 7:13:40 PM PDT> <Warning> <HTTP> <mint> <myserver> <ExecuteThread: '13' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-1 01324> <Some Browsers may fail when both "Content-Disposition" and "Cache-Control" are set.>	8.1 SP3
CR136735	カスタム ロガーを使用し getRemoteUser を呼び出すと、セッション データのメモリ リークがサーブレット コンテナで発生しました。 セッション データの参照回数は、リクエストをロギングしている間にカスタム ロガーが HttpAccountingInfo.getRemoteUser()、getRemoteUse()、getRequestedSessionId()、getUserPrincipal()、または isRequestedSessionIdValid() を呼び出すと増加する場合があります。これは、これらのメソッドが SessionInternal オブジェクトを取得しようとするためです。しかし参照回数は減少しません。 この問題は、コードを修正することで解決しました。コードの変更によって、ServletRequestImpl の getRemoteUse()、getRequestedSessionId()、getUserPrincipal()、および isRequestedSessionIdValid() から返される値は、リクエストのロギング前に HttpAccountingInfoImpl オブジェクトにキャッシュされ、カスタム ロガーが HttpAccountingInfo のメソッドを呼び出すとキャッシュされた値が使用されるようになりました。これにより、参照回数が増加しなくなります。	8.1 SP3
CR137009	Administration Console は wapEnabled 属性の設定を無視していました。 ユーザにより wapEnabled が有効にされ、URLRewriting が true に設定された場合は、URL 内に返される sessionid に特殊文字が含まれず、長さが 52 文字未満になるように、コードを修正しました。	8.1 SP3
CR137162	WebLogic Server は .war を作成したときに、ディレクトリ リストのエントリを追加しませんでした。 コードの修正によって、ユーザが .war ファイルのデプロイメント記述子を編集して変更を永続化すると、新しい .war ファイルには、ディレクトリとファイルの両方の適切なエントリが含まれるようになりました。	7.0 SP5、8.1 SP3
CR143448	サーブレット コンテナの内部呼び出しで java.lang.IllegalStateException: HttpSession is invalid 例外が発生します。同じセッション ID を使用する他のスレッドが ServletRequestImpl.syncSession() の処理中にセッション オブジェクトを無効化すると、SessionData.putValue() または SessionData.isNew() の呼び出し時に IllegalStateException が発生する場合があります。 セッションが他のスレッドによって無効化されている場合は、IllegalStateException を無視してください。	6.1 SP07 8.1 SP3
CR173782	JavaServer Faces v1.0 参照実装の最終バージョンの一部のサンプルは、起動時の事前のロードに失敗します。次の ServletException が表示されます。 <Mar 16, 2004 10:31:09 AM MST> <Error> <HTTP> <BEA-101216> <Servlet: "Faces Servlet" failed to preload on startup in Web application: "jsf-guessNumber". javax.servlet.ServletException この問題は、サーブレット リスナを登録するためのロジックを Web アプリケーションの起動時に追加することで解決しました。これは、アプリケーションの lib フォルダにある .tld ファイルで定義されます。	8.1 SP3
CR176207	FormBasedAuthentication で、ユーザがフォームベースのログイン ページを使用して認証を受ける前と後に、要求された URL が適切に格納されませんでした。 元のリクエストの完全な URL (http または https プロトコル方式を含む) を格納するために、weblogic.xml ファイルに次のパラメータが追加されました。 <container-descriptor> <retain-original-url> true </retain-original-url> </container-descriptor>	8.1 SP3
CR176941	GenericProxyServlet.readStatus が時おり失敗することがありました。この問題は、バックエンド サーバによってすでに閉じられた接続を GenericProxyServlet が再利用する場合に発生しました。 ハーフオープン状態のソケットの例外が発生し、接続ヘッダをフィルタが除外する場合には、同じリクエストを再試行するようにコードを修正して、この問題を解決しました。	8.1 SP3
CR177512	GenericProxyServlet が ResponseWrapper に含まれていて、コンテンツ長がゼロである場合、GenericProxyServlet は java.io.DataInputStream.read() メソッドからの戻り値を長時間待機していました。 そのような場合は DataInputStream が読み込まれないようにコードを変更しました。	8.1 SP3
CR177521	ClassPathServlet は Web アプリケーションの WEB-INF\classes ディレクトリからクラスをロードできませんでした。これは、(application.xml におけるこのモジュールの context_root の記述に基づいて) プレフィックスとして余分なフォワード スラッシュ「/」を使用して Web アプリケーション モジュールが作成されたことが原因です。そのため、J2EE アプリケーション コンテナはこのモジュールの適切なクラスを見つけることができませんでした。 Web アプリケーション モジュール名の余分なフォワード スラッシュを考慮するように、ClassPathServlet にロジックを追加することで、この問題を解決しました。 また、J2EE コンテナを変更して、「/」プレフィックスを使用せずに新しいデプロイメントの Web アプリケーション モジュール名を作成するようにしました。	8.1 SP3
CR178684	servletContext.getRealPath() メソッドが正規のパスを返していませんでした。 ServletContext.getRealPath() メソッドで正規のパスを検証するようにコードを修正しました。	8.1 SP3
CR129064	HTTP リクエストが iPlanet プラグインを通じて送信される際、WebLogic クラスタ 2 に対する動的サーバのリストが誤って設定されることはなくなっています。	7.0 SP6 8.1 SP3

SNMP

変更 要求 番号	説明	修正されたリリース
CR109689	サードパーティのコレクタ タスクを使用して SNMP 情報を収集した場合、以下のメッセージがログに記録されました。 <Error> <SNMP Agent> <000000> < Unable to set Entry Field Value ...> この問題を解決するコード修正が実装されました。	8.1 SP3
CR113122	WebLogic Server SNMP エージェントが sysUpTime に対して返した値は、SNMP エージェントが初期化されてからの期間を正確に報告しませんでした。 この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR121478 CR136137	特定のトークン名が SNMP で許可されている 64 バイトより長くなっていました。 トークン名を 64 バイトより短くするためのコードが追加されました。	8.1 SP3
CR135708	SNMP カウンタ モニタの作成時に表示される、種類のドロップダウンのリストから JMSDestinationRuntimeMBean が欠落しています。 [SNMP ｜トラップ｜モニタ｜カウンタ モニタ｜新しい Counter Monitor のコンフィグレーション] を参照してください。 Bean 自体は MIB ファイルに存在しており、MIB エクスプローラおよび weblogic.Admin GET コマンドの両方で取得できます。 この問題は、JMSDestinationRuntime をすべてのモニタ (文字列、ゲージ、JMX、およびカウンタ) のドロップダウン メニューに追加するようにコードを修正して解決されました。	8.1 SP3

ツール

変更 要求 番号	説明	修正されたリリース
CR125017	wldeploy Ant タスクでは、failonerror 属性がサポートされていませんでした。この属性を設定すると、エラーが発生しました。 WebLogic Server が failonerror 属性を認識するように、コードが追加されました。	8.1 SP3
CR125428	WebLogic Builder は multiplicity 属性の内容をすべて小文字で保存していました。 エンタープライズ JavaBeans 仕様バージョン 2.0 に準拠するようにコード修正を実装しました。	8.1 SP3
CR127407	システム クラスパスに weblogic.jar ファイルがない状態で appc を使用すると、次のエラーが送出されました。 java.util.MissingResourceException: Can't find bundle for base name weblogic.i18n.J2EELogLocalizer, locale en_US コードの修正により、システム クラスパスに weblogic.jar ファイルがない場合には Ant で正しいクラスローダを実装できるようになりました。 注意 : Ant バージョン 1.6 は、weblogic.jar ファイルに付属しているバージョンと互換性がありません。外部の Ant ファイルを実行する場合は、システム クラスパスから weblogic.jar ファイルを削除する必要があります。	8.1 SP3
CR127628	無効な URL に対してエラー メッセージが生成されませんでした。 この問題は、接続の作成時に送出可能な例外を捕捉するコードを追加することで解決しました。	8.1 SP3
CR130352	WLServer Ant タスクでは、指定されたプロパティがないコンフィグレーション ファイル (config.xml) が作成される場合がありました。分析の結果、MBean の変更を config.xml に書き込む saveDomain を WLServer が明示的に呼び出していなかったことが判明しました。代わりに、WLServer は saveDomain を呼び出すトリガに依存していました。問題は、WLServer によるサーバの起動と停止があまりに高速で、トリガの発生が遅れてしまう場合があることでした。 この問題は、saveDomain の呼び出しを WLServer Ant タスク内に置き、サーバが停止される前に config.xml が強制的に書き出されるようにすることで解決しました。	7.0 SP5 8.1 SP3
CR131740	JDBC 接続プール コンフィグレーションの properties 属性に対して複数の値を渡す wlconfig Ant タスクの機能に問題がありました。 コードの修正により、Ant および WebLogic コマンドライン ユーティリティで複数のプロパティを持つ JDBC 接続プールを設定できるようになりました。	8.1 SP3
CR134423	DDInit ユーティリティは、アプリケーションに数多くの EJB がある場合にデプロイメント記述子を作成できませんでした。 コードの修正により、DDInit ユーティリティは Java エンコーディング文字列が含まれるドキュメントを開くことができるようになりました。	8.1 SP3
CR136468	tld ファイルにマルチバイト文字が含まれている場合、ヘッダがファイル エンコーディングに一致しませんでした。Builder を使用してタグ ライブラリを編集する場合、tld ファイルはデフォルト エンコーディングで保存されます。たとえば、日本語の Windows では Shift_JIS になります。ただし、ヘッダのエンコーディングはファイルのエンコーディングに関係なく ISO-8859-1 でした。 コードを修正してこの問題を解決しました。	8.1 SP3
CR173675	Windows 2003 Server 上で Ant 1.5 を実行し、JDK 1.4.2_0x を使用すると、ntvdm.exe の問題が発生して、ビルドが失敗しました。 この問題は、コードを修正することで解決しました。	8.1 SP3

Web サービス

変更 要求 番号	説明	修正されたリリース
CR091230	WebLogic Server clientgen Ant タスクで、WSDL ファイル内に不正にハイフンを残せるようになっていました。これにより、生成される Java コードに、ハイフンが含まれるクラス名およびメソッド名が存在することになりました。これは、java では無効です。 NameUtils に対する修正により、clientgen でハイフンを削除できるようになりました。さらに、JAXRPC メソッドおよびクラスに対しては、結果の文字列が Java キーワードでもある場合には、WebLogic Server は JAXRPC 仕様 1.0 および 1.1 により、それに _ を追加します。	7.0 SP5 8.1 SP3
CR102959	UDDI 処理が失敗すると、「dispositionReport」が返されました。 SAAJ クラスを使用することで、dispositionReport XML が作成されました。 ネームスペースがまだ定義されていない場合には、SOAPElement.addChildElement(Name name) が「name」のネームスペースを宣言するようになりました。	8.1 SP3
CR103985	startWebLogic.cmd スクリプトの「Setting javax.xml.soap.MessageFactory」にプロパティを設定した場合、JSP や Servlet の org.xml.sax.driver、org.xml.sax.parser、javax.xml.soap.MessageFactory、および javax.xml.rpc.ServiceFactory に対して適切に機能しませんでした。 コードの修正により、WebLogic Server はプロパティの設定前にそれがすでに設定済みであるかどうかをチェックし、設定されていない場合はそのプロパティにデフォルト値を設定するようになりました。	7.0 SP5 8.1 SP3
CR105715	WebLogic Server clientgen Ant タスクで、WSDL ファイル内に誤ってハイフンを残せるようになっていました。これにより、生成される Java コードに、ハイフンが含まれるクラス名およびメソッド名が存在することになりました。これは、java では無効です。 NameUtils に対する修正により、clientgen でハイフンを削除できるようになりました。さらに、JAXRPC メソッドおよびクラスに対しては、結果の文字列が Java キーワードでもある場合には、WebLogic Server は JAXRPC 仕様 1.0 および 1.1 により、それに _ を追加します。	7.0 SP5 8.1 SP3
CR106741	複数のサービス エントリがある状態で useServerTypes=True と設定すると、正しいタグが解析されず、web-services.xml の複数のタグが解析されませんでした。結果として、web-services.xml の最初のタグだけが正しく処理されていました。 この問題は、web-services.xml で正しいタグを検索し、すべてを処理するコードを追加することで解決しました。 useServerTypes=True が設定されているクライアントに対して、複数のサービス エントリが処理されるようになりました。	8.1 SP3
CR107934	servicegen のセキュリティ セクションに encryptKeyName 属性と encryptKeyPass 属性が指定されていない場合、生成される web-services.xml ファイルの EncryptionSpec 属性において EncryptBody 設定が「true」になっていました。その結果 SOAP メッセージが暗号化されました。 web-services.xml ファイルが正しく生成されるようにコードを修正して、この問題を解決しました。	8.1 SP3
CR108659	アプリケーション リソースが webserviceclient.jar と同じクラスローダによってロードされなかった場合、エラーが発生しました。WebLogic Server が複数のクラスローダによってロードされたアプリケーション リソースを正しく処理できるように、コードが追加されました。	8.1 SP3
CR120263	一部のセキュリティ仕様の変更により、タイムスタンプがセキュリティ ヘッダ内部で必ず生成されるように WebLogic Server が更新されました。	8.1 SP3
CR120796	同じ WSDL 内に異なるスタイルに設定されている複数の <soap:operation> が存在することはスタイルの混在する Web サービスであり、サポートされていません。 現在では、<soap:operation> は <soap:binding> をオーバーライドします。 複数の処理がある場合、<soap:operation> は同じ値に設定されなければなりません。ただし、<soap:binding> が <soap:operation> と異なる値に設定されている場合は、<soap:operation> は <soap:binding> をオーバーライドします。	8.1 SP3
CR121394 CR128988 CR174095	ISAPI フィルタを介して Web サービス内でメソッドを呼び出すと、次の例外が発生しました。 java.lang.IllegalArgumentException: Illegal MimeHeader name or value この問題は、コードを修正することで解決しました。	7.0 SP5 8.1 SP3
CR121683	信頼性のあるメッセージングが有効になっていない場合、WSDL ファイルで <wsr:reliability persistDuration="60000"> エントリが生成されました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR122033	Web サービスに添付されている画像が正しく機能しませんでした。この問題は、ユーザが Web サービスに java.awt.Image を添付し、その画像が不適切にシリアライズまたはデシリアライズされた場合に発生しました。 シリアライゼーションおよびデシリアライゼーションを修正するコードが追加されました。	8.1 SP3
CR122156	OASIS WSS 仕様の x509 プロファイルの新しい草案では、x509 証明書の参照モデルが変更されました。 KeyIdentifier の SKID の値タイプを (X509SubjectKeyIdentifier に) 変更し、IssuerDN と Serial を SecurityTokenReference に組み込めるようにするためのコードが追加されました。	8.1 SP3
CR122502	信頼性のある SOAP メッセージングを使用して、送信側の WebLogic Server インスタンスから受信側の WebLogic Server インスタンスに Web サービスを呼び出す場合、送信側はコンフィグレーションされている再試行の制限を超えて呼び出しの再試行を続けました。再試行は、受信側が再起動されるか、またはトランザクションのタイムアウト値を超過したために送信側のコンテナがクライアントを強制停止するまで続きました。指定されている再試行の制限を遵守できないことにより、トランザクションが長時間実行され、クライアントがハングしました。 送信側がコンフィグレーションされている再試行の制限を超えて再試行を行わないようにするコードが追加されました。	8.1 SP3
CR124690	simpleType に final 属性が含まれる場合、autotype が weblogic.xml.schema.model.parser.XSDParseException: invalid attribute "final" in element "xsd:simpleType" というメッセージで失敗します。 simpleType で final 属性を使用できるようにコードを修正しました。	8.1 SP3
CR124892	autotype では、anyType から派生する型に対して型マッピングを作成できませんでした。 SOAPElement にマップされる他の型に依存する型 (anyType など) は、SOAPElement 自体にマップされる必要があります。以前は 'hasA' 依存関係のみが考慮されていました。 anyType から派生する型を SOAPElement にマップするコードが追加されました。	8.1 SP3
CR125082	機能の拡張により、WebLogic XML デジタル署名 API が提供されました。この API には、SOAP メッセージに対してデジタル署名および検証を行うクラスが含まれています。 詳細については、「WebLogic XML デジタル署名 API の使い方」を参照してください。	8.1 SP3
CR125852 CR130095 CR137242	Apache AXIS クライアントは、Message 要素と ErrorCode 要素に同じネームスペース プレフィックスがなかったため、SOAP 応答メッセージを拒否していました。この問題は、WebLogic Server が最上位要素のみを修飾していたために発生しました。 コードを修正して、最上位レベルの要素が修飾されているかどうかを判別するシステム プロパティ -Dweblogic.xml.schema.binding.qualifytoplevelelementonly を導入しました。有効な値は次のとおりです。 true - 最上位要素を修飾します。デフォルト値です。 false - 最上位要素を修飾しません。 Apache AXIX クライアントのユーザはこの値を false に設定してください。	8.1 SP3
CR126960 CR175031	WebLogic Express 8.1 ライセンスでサーバを起動すると、NullPointerException が発生しました。 この例外を削除するコードが追加されました。	8.1 SP3
CR127276 CR178573	SOAP メッセージにインターレースの SOAP 添付ファイルがあり、MIME ヘッダの start パラメータが content ID ヘッダに一致していない場合、例外が送出されました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR127344	Java Bean のアクセサがチェック済み例外を送出すると、servicegen が失敗しました。 WebLogic Server は、チェック済み例外を捕捉して、実行時例外 weblogic.xml.schema.binding.PropertyException と共に再送出できるようになりました。	8.1 SP3
CR127391	SOAP HTTP バインディングでは、Web サービス内で例外が発生すると、サーバはその例外を表す SOAP Fault 応答と共に HTTP 500「Internal Server Error」を送出しなければならないことになっています。 多くの Web サービス クライアントでは、Web サービスに HTTP 接続を行うために URL 接続が使用されます。WebLogic Server は java.net.HttpURLConnection を異なるバージョンでオーバーライドしました。WebLogic のバージョンは、ステータス コードが 400 以上の場合に getInputStream メソッドからの例外を送出しました。 例外が送出されたので、Web サービス クライアントには入力ストリームを取得する方法がありませんでした。このため、HTTP SOAP バインディング仕様に違反していました。 WebLogic Server は、500 エラーで入力ストリームを取得できるようになりました。	8.1 SP3
CR127396 CR176324 CR184605	例外がパッケージの異なる別の例外を拡張した場合、clientgen は正しい例外の型を生成しませんでした。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR127409	WebLogic Server は、クライアント サイドではリクエスト/応答デバッグを表示するだけでした。 ブラウザが使用されている場合は、デバッグ メッセージはサーバに送信されました。Java クライアントが使用されている場合は、メッセージはクライアントで表示されなければなりませんでした。 クライアント デバッグとサーバ デバッグの両方が表示されるようになりました。	8.1 SP3
CR127610	スタブを生成すると、提供されている types.xml からの型マッピング情報が JAX-RPC デフォルトで上書きされるため、間違ったパラメータ クラスが使用されました。 types.xml からの型マッピング情報は上書きされなくなりました。スタブに対してプログラミングを行うクライアントは、型に対応するクラスではなく、XML 要素に対応するクラスをパラメータとして使用する必要があります。	8.1 SP3
CR127687	WSDL が JPD から生成され、java クライアントがメソッドの呼び出しに使用された場合、クライアントからの入力リクエスト xml は無効であり、NullPointerException が発生しました。 この問題は、コードを追加することで解決しました。	8.1 SP3
CR128214 CR136606	source2wsdd タスクの mergeWithExistingWS 属性を使用して、既存の web-services.xml ファイルを新しいファイルと結合できませんでした。 mergeWithExistingWS="True" を設定する場合の source2wsdd タスクを修正し、source2wsdd に新しい targetNameSpace 属性を追加して、この問題を解決しました。 この変更の結果、web-services.xml に 2 つのサービスがある場合は WSDL ファイルを生成できません。つまり、source2wsdd タスクで wsdlFile 属性を指定できません。WSDL は 1 つの web-services.xml につき 1 つのサービスに対してのみ生成されるためです。	8.1 SP3
CR128255	.Net クライアント (暗号化に 512 ビットのキーを使用) がセキュアな WebLogic Web サービス (暗号化に 1024 ビットのキーを使用) を呼び出す場合、以下の例外が発生しました。 Unhandled Exception: System.Web.Services.Protocols.SoapException: Exception during processing: java.lang.AssertionError: weblogic.xml.stream.XMLStreamException: Unable to decrypt EncryptedKey - with nested exception: [weblogic.xml.security.encryption.EncryptionException: Invalid input length for decryption.Length should be multiple of 128 - Block Size.- with nested exception: [com.rsa.jsafe.JSAFE_InputException: Invalid input length for decryption.Length should be multiple of 128 - Block Size.]](see Fault Detail for stacktrace) 変更を行って、暗号化/複合化キーの不一致を説明するわかりやすいエラー メッセージを用意しました。 Unable to decrypt EncryptedKey: key size of encryption/decryption mismatched	8.1 SP3
CR128446	clientgen Ant タスクは、複数のサービスが定義された WSDL に対するクライアント jar ファイルを生成できず、以下のエラーを送出しました。 Client FAIL Exception during Service Create javax.xml.rpc.JAXRPCException: unable to find port:SubmitStatusRequest This may be because the WSDL file and the generated stub is out sync. Doing clientgen again may fix this problem. この問題は、コードを修正することで解決しました。	8.1 SP3
CR128747	wsdl2service によって生成されたサービス インタフェースは、「part」で「element」が使用される場合にカスタム例外を送出しませんでした。次に例を示します。 <message name="WSException"> <part element="cio:WSException" name="WSException"/> </message> ただし、次のように、「element」の代わりに「type」を使用すると適切に動作しました。 <message name="WSException"> <part name="WSException" type="cio:WSExceptionType" /> </message> コードを変更して、「part」で「element」が使用される場合に wsdl2service が適切に例外を生成するようにしました。	8.1 SP3
CR128771	セキュアな WebLogic Web サービスを暗号のみで呼び出す場合に、セキュリティ コンフィグレーション例外が送出されました。 応答に署名がない場合は署名鍵の指定が必要なくなるようにコードを変更しました。	8.1 SP3
CR129010	スキーマ ファイルが wsdl ファイルと同じディレクトリにない場合、clientgen Ant ツールを実行すると以下のエラーが発生しました。 [clientgen] Finished Schema2Java parameter validation [clientgen] schemaURL file:/C:/edrive/462245/AaisTransactionManagerService.WSDL [clientgen] java.io.FileNotFoundException: C:\edrive\462245\Ont.xsd (The system cannot find the file specified) [clientgen] at java.io.FileInputStream.open(Native Method) [clientgen] at java.io.FileInputStream.<init>(FileInputStream.java:103) [clientgen] at java.io.FileInputStream.<init>(FileInputStream.java:66) [clientgen] at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) [clientgen] at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.fetchSchemaLocation(SimpleSchemaResolver.java:120) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.doExternalLookup(SimpleSchemaResolver.java:90) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.resolveSchemaLocation(SimpleSchemaResolver.java:68) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclusion(XSDSchema.java:533) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclusion(XSDSchema.java:524) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclude(XSDSchema.java:489) 以前のサービス パックでは、WebLogic Web サービスは WSDL ファイルとインクルードされるスキーマが同じディレクトリに格納されることを想定していました。変更によって、Web サービスはスキーマの相対的なインクルードをサポートするようになりました。次に例を示します。 a.wsdl --- インポート ---> b/b.xsd --- インクルード ---> b/c/c.xsd	8.1 SP3
CR129536	clientgen Ant タスクをドキュメント指向の Web サービスで使用すると、次の例外が発生しました。 [clientgen] weblogic.xml.schema.model.XSDValidityException: unable to resolve type name コードを修正して問題は解決されました。	8.1 SP3
CR130300	スタンドアロンの Java Web サービス クライアントからのビジネス プロセスの呼び出し中に、XMLBean からルート要素を取得しようとすると、ClassCastException が送出されました。WebLogic Server は匿名のインライン型に対して xsi:type を書き出しました。これにより、XMLBean からのルート要素の取得時に WebLogic Workshop で ClassCastException が発生しました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR130490	WebLogic Server 8.1 の以前のサービス パックでは、Web サービスの「InclusiveNameSpaces」が正しく実装されていませんでした。Web サービス仕様に従って、次に示すように、ドキュメントで明白に使用されているすべてのネームスペースは InclusiveNameSpaces PrefixList に追加される必要があります。 <c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="n1"></c14n:InclusiveNamespaces> 旧 8.1 のサービス パックでは、「PrefixList」の属性ではなく、「InclusiveNameSpaces」タグの値としてネームスペースを配置していました。次に例を示します。 <c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"; >n1/c14n:InclusiveNamespaces> 現在では WebLogic Web サービスは、"PrefixList" 属性を使用することで Web サービス仕様に準拠しています。そのため、リリース 8.1 サービス パック 2 以前によって署名されているドキュメントはサービス パック 3 で検証できません (この逆も同様)。	8.1 SP3
CR131753 CR120847	org.w3c.dom.Document をドキュメント/リテラル型の Web サービスに渡すと、XML はツリーの次の子ノードまで削除されました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR132583	http-soap12=true である Web サービスの clientJar を生成しようとすると、次の例外で失敗しました。 weblogic.webservice.tools.wsdlp.WSDLParseException: transport not supported:http://schemas.xmlsoap.org/soap12/http 以前のサービス パックでは、clientgen コマンドの実行時に WSDL ファイル内の SOAP 1.1 HTTP 転送のみがチェックされました。コードの修正により、clientgen の実行時に WSDL ファイル内の SOAP 1.1 HTTP 転送および SOAP 1.2 HTTP 転送の両方がチェックされるようになりました。	8.1 SP3
CR132914	Web サービスの SSL クライアントでは、実行後ソケットが CLOSE_WAIT 状態のままになっていました。 この問題は、実行後クライアントでソケットを適切に閉じるように、コードを修正することで解決しました。	8.1 SP3
CR134014	wsdl2service Ant タスクは、サービスのインタフェースを生成するだけでした。デフォルトでは、実装クラスを生成しませんでした。 コードの修正により、wsdl2service Ant タスクは「generateImpl」が true に設定されている場合、実装クラスのインタフェースとスケルトンを生成するようになりました。 詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「Web サービス Ant タスクとコマンドライン ユーティリティ」を参照してください。	8.1 SP3
CR134913	WebLogic Server は、タイムスタンプが含まれていた .NET 署名された XML ドキュメントを検証できません。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR134931	WebLogic Web サービスには現在、以下の 2004 年 4 月 6 日付の OASIS 標準 Web Services Security 1.0 (最終バージョン) 仕様が実装されています。 Web サービス セキュリティ : SOAP メッセージ セキュリティ Web サービス セキュリティ : ユーザ名トークン プロファイル Web サービス セキュリティ : X.509 トークン プロファイル サービス パック 2 は、その時点ではこの仕様の最新バージョンであった、草案バージョン 1.0 を実装していました。 この実装は、以前のバージョン 8.1 サービス パックと下位互換性がありません。この互換性の欠如の詳細については、「WebLogic Server 8.1 SP3 の新機能」を参照してください。 Web サービスのセキュリティの詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」を参照してください。	8.1 SP1
CR135317	webservice Ant タスクは、autotype Ant タスクのある第 2 レベルのインクルードに従いませんでした。 最初のスキーマが 2 番目のスキーマをインポートし、2 番目のスキーマが別のスキーマを含んでいた場合、WebLogic Server はこのインクルードされているスキーマを検索しませんでした。このため、autotype は失敗しました。 この問題は、コードを修正することで解決されました。WebLogic Server はインポートされたスキーマの子インクルードを検索するようになりました。	8.1 SP3
CR136582	Weblogic 8.1 Web サービス サーブレットの前にフィルタを追加し、フィルタの最後でカスタマイズされた HttpServletRequestwrapper インスタンスを doFilter(req, resp) 呼び出しに渡すと、ClassCastException が発生しました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR136804	web-services.xml 記述子に <xsd:documentation> の余分な要素が含まれていました。たとえば、<xsd:annotation> <xsd:documentation> <xsd:documentation> などです。 余分な <xsd:documentation> タグは削除されました。	8.1 SP3
CR137520	servicegen を使用して、javax.jms.JMSException を送出するサービス メソッドに対する Web サービスを生成すると、weblogic.xml.schema.binding.BindingException 例外が発生しました。 コードを修正してこの問題を解決しました。	8.1 SP3
CR137522	web-services.xml ファイルから WSDL ファイルを作成すると、web-services.xml ファイルにある処理の順序が WSDL に保持されませんでした。 この問題は、web-services.xml の生成時に WSDL ファイルに表示される処理の順序を保持するように、コードを修正することで解決しました。	8.1 SP3
CR172993	ドキュメント スタイルの Web サービスでは、サービスのエンドポイントによって不正なネームスペース プレフィックスが返されるため、クライアントはユーザ定義の例外を捕捉できませんでした。 この問題はコードの修正によって解決されました。	8.1 SP3
CR173969	Web サービスのエンドポイントは、「Accept-Charset: UTF-8, UTF-16」がリクエスト ヘッダに含まれている HTTP リクエストを理解できませんでした。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR175093	-Dweblogic.webservice.i18n.charset=UTF-8 プロパティを設定すると、警告メッセージ <Unrecognized property: webservice.i18n.charset> が生成されます。 この問題は、このプロパティを管理 admin に追加して、この警告メッセージを削除することで解決しました。	8.1 SP3
CR175471	発信プロキシ サーバ (iPlanet Web プロキシ サーバ) を介して外部 Web サービスにアクセスすると、SOAP 障害が返されました。この問題は、HTTP および HTTPS を使用した、プロキシ認証が有効になっているプロキシ サーバを介したリモートの Web サービスの呼び出しが許可されていなかったために発生しました。 Web サービス クライアントのプロキシ サーバを介した HTTP および HTTPS トンネリングが許可されるように、コードを修正しました。	8.1 SP3
CR178574	servicegen Ant タスクは、サービス メソッドが java.sql.SQLException を送出した場合に以下のエラーで失敗しました。 weblogic.xml.schema.binding.BindingException: No default constructor was found for class java.lang.StackTraceElement loaded from file:/usr/bea/jdk141_03/jre/lib/rt.jar!/java/lang/StackTraceElement.class. All classes that will be serialized or deserialized must be non-interface, non-abstract classes that provide a public default constructor - with nested exception: [java.lang.NoSuchMethodException: java.lang.StackTraceElement] この問題は、コードを修正することで解決しました。	8.1 SP3
CR179311	Web サービス クライアントで、子要素や属性を持たない空の SOAP ヘッダ要素を送信しようとした場合に、外部の Web サービスが呼び出されませんでした。たとえば、<env:Header/> のような場合です。 子要素および属性がない場合、空の SOAP ヘッダ要素は送信されないようにコードを修正しました。	8.1 SP3

WebLogic Type 4 JDBC ドライバ

変更 要求 番号	説明	修正されたリリース
CR127143 CR128664	DB2 用の XA ドライバ トランザクションで DB2 用の XA WebLogic Type 4 JDBC ドライバを使用している場合、PreparedStatement の実行およびトランザクションのコミット後は PreparedStatement を再利用できませんでした。 この問題は、ドライバのコードを修正することで解決されました。	8.1SP3
CR127310	Microsoft SQL Server および Sybase 用のドライバ MS SQL Server および Sybase 用の WebLogic Type 4 JDBC ドライバでは、<stored_proc_name>;<versionNumber> のような完全なストアド プロシージャ名を持つストアド プロシージャのバージョンがサポートされていませんでした。 この問題は、ドライバのコードを修正することで解決しました。	8.1SP3
CR127434	Sybase 用の XA ドライバ トランザクションが別の JDBC ドライバを使用して準備された場合に、XA WebLogic Type 4 JDBC ドライバで XARecover が失敗しました。 この問題は、ドライバのコードを修正することで解決しました。	8.1 SP3
CR127655	Microsoft SQL Server 用の XA ドライバ MS SQL Server 用の XA WebLogic Type 4 JDBC ドライバで、パフォーマンスが低下しました。この問題は、ドライバのコードを修正することで解決されました。	8.1SP3
CR127834	DB2 用のドライバ バッチ更新後に commit() を呼び出すと、データベース接続がリセットされました。この問題は、ドライバのコードを修正することで解決されました。	8.1SP3
CR128654	DB2 用の XA ドライバ XA 接続の作成時に、ドライバは不明な警告メッセージをエラー メッセージとして解釈し、接続を作成できませんでした。 この問題は、ドライバのコードを修正することで解決されました。	8.1SP3
CR128742	DB2、Informix、Microsoft SQL Server、および Sybase 用のドライバ DATE および TIMESTAMP データ型に以下の問題がありました。 DB2 - Connection.setAutocommit(true) で実行されている場合に TIMESTAMP データ型を使用すると、サーバのプロトコル エラーにより失敗しました。 Informix - TIMESTAMP データ型を認識しませんでした。 MS SQL Server - DATE データ型から TIMESTAMP データ型へデータを暗黙的に変換できませんでした。 Sybase - DATE データ型および TIMESTAMP データ型を認識しませんでした。 この問題は、ドライバのコードを修正することで解決されました。現在ではこれらのドライバで DATE データ型および TIMESTAMP データ型がサポートされています。	8.1SP3
CR129559	Oracle 用のドライバ 日本語ロケールで YYYY-MM-DD および YY-MM-DD の日付フォーマットを使用すると、TO_DATE 関数が SQL 例外で失敗しました。 この問題は、ドライバのコードを修正することで解決しました。	8.1SP3
CR132575 CR133146	Microsoft SQL Server 用の XA ドライバ XA WebLogic Type 4 JDBC ドライバを使用しているクライアントに対しては、DBMS はクライアントの接続解除を検出できません。クライアントの接続解除によってトランザクションが破棄される場合があり、破棄されたトランザクションをタイムアウトさせる方法はありませんでした。 破棄されたトランザクションをタイムアウトさせる設定がドライバに追加されました。 MS SQL Server 用の XA WebLogic Type 4 JDBC ドライバを使用している場合は、XASetTransactionTimeout が内部で自動的に true に設定され、ドライバでトランザクションのタイムアウト設定が利用できるように、WebLogic Server が更新されました。 XASetTransactionTimeout 属性の詳細については、「XAResource のトランザクション タイムアウトのサポート」を参照してください。	8.1SP3
CR133508	DB2、Informix、Oracle、および Sybase 用のドライバ 数多くのパラメータを持つ PreparedStatement を使用すると、StackOverflowError が発生しました。 この問題は、ドライバのコードを修正することで解決しました。	8.1SP3
CR134410	Sybase 用のドライバ CallableStatement を複数回使用すると、不正な値が返されました。この問題は、ドライバのコードを修正することで解決されました。	8.1SP3
CR178619	DB2 および Microsoft SQL Server 用の XA ドライバ ドライバは NOTA (-4) ではなく RMERR (-3) というエラー コードを返しました。その結果、トランザクションは回復時に解決される代わりに、AbandonTimoutSeconds まで再試行されました。 この問題は、ドライバのコードを修正することで解決されました。	8.1SP3

WebLogic Tuxedo Connector

変更 要求 番号	説明	修正されたリリース
CR100556	XOPEN 標準データ型は Tuxedo ではサポートされているが、WebLogic Tuxedo Connector ではサポートされていませんでした。 XATMI 必須のバッファ タイプをサポートする 3 つの新しい型が、weblogic.wtc.jatmi に追加されました。新しい型は、TypedXOctet (X_OCTET バッファ タイプを実装し、TypedCArray とセマンティクスが同じ)、TypedXCommon (X_COMMON バッファタイプを実装)、および TypedXCType (X_C_TYPE バッファタイプを実装) です。これらの型は、TypedView とセマンティクスおよび使用方法が同じです。	8.1 SP3
CR125533	CLASSPATH に EJBJAR ファイルが含まれていない場合には、セッション Bean のサービス メソッドの呼び出しによってオブジェクト レプリケーションのロジックがトリガされ、その結果、TypedFML._tmpresend が呼び出されます。CARRAY フィールドが null の場合、_tmpresend はフィールド長を (FLDID_SIZE + FLDLEN_SIZE ではなく) 0 と記録します。 最終的には、_tmpostrecv が呼び出され、フィールド長は FLDID_SIZE + FLDLEN_SIZE と想定されます。_tmpresend はこの情報を記録しなかったため、負の値がフィールド長として読み込まれました。現在、フィールド長に対するチェックではフィールド長が 0 であるかどうかが検査されるため、NegativeArraySize 例外が送出されます。 フィールド長をチェックし、それが 0 以下であるかどうかを判別するコードが _tmpostrecv に追加されました。	7.0 SP5 8.1 SP3
CR127636	tBridge FML または Queue のサンプルの実行中、tBfrom2jms は tBsend2jms からの quit を認識しませんでした。その結果、タイムアウト エラーが発生しました。 この問題は、weblogic.jms.Tux2JmsQueue からのメッセージを受信するように tBfrom2jms のコードを変更することで解決しました。現在では quit は受信されます。	8.1 SP3
CR128909	受信する Java 文字列参照が null の場合、エンコーディング ルーチンの viewj コンパイラのパラメータは false に設定されます。-modify_string オプションを使用する場合は、コンパイラは空の文字列に null を追加する必要があります。 修正により、エンコーディング ルーチンのパラメータは null 文字列に対して true に設定され、null を空の文字列に追加できるようになりました。	8.1 SP3
CR129485	xdr_decode_bstring メソッドは、CARRAY の実際のバイトと共に埋め込みバイトを返しました。 コードの修正により、xdr_decode_bstring は埋め込みバイトを破棄するようになりました。	8.1 SP3
CR134794	WLS/WTC v7.0sp4 tBridge は、CARRAY 型メッセージ (ByteMessage) または Qmessage の CorrelationID を Tuxedo から WebLogic JMS に伝播しませんでした。 CARRAY メッセージが Tuxedo キューから受信されると、CorrelationID を JMS メッセージに設定するように、コードが追加されました。	8.1 SP3
CR136356	現在の WebLogic Tuxedo Connector は VIEW の文字列に対して使用されないスペースを埋め込まないので、WebLogic Tuxedo Connector FML/VIEW はサイズの大きい文字列型で失敗しました。 WebLogic Tuxedo Connector は常に VIEW ファイルで指定されている文字列の固定長を送信するようになりました。	8.1 SP3
CR137437	TPNOTRAN フラグが設定されている WebLogic Tuxedo Connector の tpcall が失敗して、トランザクションが強制的にロールバックされました。 これは、tpcall の試行が失敗した場合に、TPNOTRAN フラグが設定されているかどうかに関係なくトランザクションがロールバックとしてマークされていたために発生します。 修正により、tpcall に対して TPNOTRAN フラグが設定されている場合は、トランザクションがロールバックとしてマークされなくなりました。	8.1 SP3
CR173656	WebLogic Tuxedo Connector ユーティリティ ルーチンは、xdr_encode_string_length メソッドによって入力に null 文字列が検出されると、null ポインタ例外を送出する場合があります。 修正により、null 入力文字列に対するチェックが追加されました。	8.1 SP3
CR180469	WebLogic Tuxedo Connector は複数の Tuxedo ドメインが存在するトランザクションを調整します。最初のドメインが 2 フェーズ コミットの第 1 フェーズで ROLLBACK を決定しても、他の Tuxedo ドメインはロールバックされませんでした。 XAException を送出する前に、すべての Tuxedo ブランチがロールバックされるようになりました。	8.1 SP3

WLEC

変更 要求 番号	説明	修正されたリリース
CR121105	WLEC クライアントでは、WLEC 接続プールに関する以下の問題が発生しました。 Administration Console において ConnectionPool が正しく表示されない。 登録解除されたエンドポイントにより COMM_FAILURES が発生する。 これらの問題を解決するコード修正が実装され、WLEC 接続プールの全体的なパフォーマンスが向上しました。	8.1 SP3
CR132509	WLEC 経由で呼び出しを行うクライアントは、接続数が maxpoolsize を超えるまでは、既存の接続を再利用しないで、新しい WLEC 接続を優先的に作成していました。このしきい値に達すると、接続が再利用されました。 WLEC 接続プールを使用する場合のシステム パフォーマンスとリソース使用率を向上させるため、コードを修正しました。	8.1 SP3

XML

変更 要求 番号	説明	修正されたリリース
CR126140	weblogic-application.xml でカスタム xml パーサをコンフィグレーションすると、NullPointerException が発生する場合がありました。この問題は、コードを追加することで解決しました。	8.1 SP3
CR130177	javax.xml.transform.Source をパラメータまたは戻り値として使用すると、ドキュメント指向のサービスで null ポインタ例外が発生しました。 この問題は、コードを修正することで解決しました。	8.1 SP3
CR172469	以前のサービス パックでは、WebLogic Server XML パーサ クラス オブジェクトを JAXP プロパティ ファイルから決定できませんでした。 XML パーサ クラス オブジェクトを JAXP プロパティで定義するには、javax.xml.parsers.DocumentBuilderFactory=weblogic.xml.jaxp.RegistryDocumentBuilderFactory javax.xml.parsers.SAXParserFactory=weblogic.xml.jaxp.RegistrySAXParserFactory javax.xml.transform.TransformerFactory=weblogic.xml.jaxp.RegistrySAXTransformerFactory というエントリを $java.home/lib/jaxp.properties ファイルに追加します。	8.1 SP3
CR180943	8.1 アプリケーションまたはドメインを 8.1 SP2 または SP3 にアップグレードするときに UnsupportedOperationException が発生する場合がありました。この例外で「This operation requires xqrl.jar」という誤ったエラー メッセージが表示されました。クエリが複雑すぎるため処理できないことを示すように、このエラー メッセージを変更しました。 注意 : この例外は、wlxbean.jar ファイルがサーバの CLASSPATH に含まれていないために発生した可能性があります。したがって、アップグレード処理中にこの例外が発生した場合は、wlxbean.jar がサーバの CLASSPATH に含まれていることを確認してください。	8.1 SP3