サービス パック 1 から 6 で解決済みの問題

以下の節では、WebLogic Server 7.0 の以前のサービス パックで修正されている問題を説明します。 サービス パックは累積的であり、サービス パック 6 にはそれ以前にリリースされた WebLogic Server 7.0 用のサービス パックで行われたすべての修正が含まれます。最新のサービス パックで解決された問題の説明については、「サービス パック 7 の解決済みの問題」を参照してください。

• WebLogic Server 7.0 サービス パック 6 のソリューション

• WebLogic Server 7.0 サービス パック 5 のソリューション

• WebLogic Server 7.0 サービス パック 4 のソリューション

• WebLogic Server 7.0 サービス パック 3 のソリューション

• WebLogic Server 7.0 サービス パック 2 のソリューション

• WebLogic Server 7.0 サービス パック 1 のソリューション

 

---

WebLogic Server 7.0 サービス パック 6 のソリューション

以下の節では、WebLogic Server 7.0 サービス パック 6 で解決された問題について説明します。

• Administration Console

• クラスタ

• コネクタ

• コア サーバ

• デプロイメント

• EJB

• インストール

• インターナショナライゼーション

• J2EE

• JCOM

• JDBC

• jDriver

• JMS

• JNDI

• JSP

• JTA

• JVM

• ノード マネージャ

• 操作と管理

• プラグイン

• RMI

• サンプル

• セキュリティ

• サーブレット

• SNMP (Simple Network Management Protocol)

• Web サービス

• WLEC

• XML

Administration Console

変更要求番号	説明
CR097378	Web アプリケーション デプロイメント記述子の編集中に、Administration Console で NullPointerException 例外が発生することがありました。 WebLogic Server は記述子が null かどうかをチェックしていませんでした。null の場合は記述子を解析できなくなりました。 そのため NullPointerException が送出されました。 記述子が null の場合は、適切なエラー アクションが呼び出されて、正しいメッセージが表示されるようになりました。
CR106965	Administration Console では、[すべてのエンティティ EJB ランタイムのモニタ...] または [すべてのメッセージ駆動型 EJB ランタイムのモニタ...] で、同様の名前を持つ複数の EJB JAR ファイルの情報が誤って含まれていました。 現在の Administration Console では、選択したスコープに関連付けられた MBean のみが表示されます。
CR132429	Administration Console には、最後に入力したユーザを記憶するように、ユーザから指示するオプションはありませんでした。 デフォルトでは、最後に入力したユーザは 1 週間有効なクッキーとして保存されていました。 現在、Administration Console のログイン フォームには [このコンピュータに ID を記憶] というチェックボックスがあります。 このチェックボックスはデフォルトでチェックされています。 このチェックボックスをチェックしない場合、WebLogic Server は現在のセッションのユーザ ID のみを記憶します。
CR130110	相対パスではなく絶対パスが指定されている場合にアップロード ディレクトリの問題が発生しました。 WebLogic Server はアップロードの際に相対パスか絶対パスかをチェックするようになりました。
CR079771	WebLogic Server はクラスタの起動やドメインの起動/強制停止の操作結果を報告するために、ブラウザにファイル リンクを送信していました。 そのリンクは、ブラウザが管理サーバと同じマシンで実行される場合にのみ機能しました。 これはすべてのプラットフォームで同様でした。 WebLogic Server は、ファイルを処理してブラウザに HTML 形式で出力を送信するアクション リンクを送信するようになりました。
CR172233	プロバイダのユーザ/グループ リストにアクセスしているときに、あるプロバイダが停止していると、Administration Console ではリストが空白になりました。 現在の Administration Console では、アクセス可能なプロバイダのユーザ/グループ リストが表示され、停止しているプロバイダがある場合はエラーが表示されます。
CR174734	削除したレルムを再作成すると、InstanceAlreadyExistException が発生していました。 現在は、削除したレルムを再作成しても InstanceAlreadyExistException が送出されないように、レルムは完全に削除されます。
CR180635	Administration Console のブラウザからアーカイブ ファイルをアップロードしているときに、指定したパスとは関係のないドメイン ディレクトリにアーカイブ ファイルがアップロードされました。 現在の WebLogic Server では、ファイルが正しいディレクトリにアップロードされるように、ファイルをサーバにアップロードするときにアップロード ディレクトリ プロパティを使用します。
CR181865	Administration Console では、JMS サーバが対象になっていない場合でも、JMS 分散送り先にメンバーを追加することができました。 現在は、そのメンバーの JMS サーバが対象として指定されていない場合、JMS 分散送り先にメンバーを追加することはできません。
CR096998	Administration Console を使用して CMP EJB デプロイメント記述子を編集するときに、WebLogic Server は NoSuchMethodException を送出しなくなりました。
CR106399	examples ドメインで Administration Console からメソッド パーミッションを作成してサーバを再起動した場合、WebLogic Server は「page not found」例外を送出していました。 ejb20 用の MethodPermission.jsp を追加して問題を解決しました。
CR188452	Administration Console はサーバ ログを表示できませんでした。 代わりに、例外が送出されました。 コードの修正で、この問題は解消されました。 現在は、サーバ ログが Administration Console に表示されます。
CR081329	Administration Console の更新機能が修正されました。 [更新] ボタンをクリックしても以前のようにページが開かれることはありません。代わりに、現在開いているページが更新されます。
CR206741	WebLogic Server は、特に対象がクラスタまたは仮想ホストである場合に、その対象上のコンポーネントのデプロイメント ステータスを検索するために、非常に多数の RMI 呼び出しを行っていました。 また、対象のコンポーネント ステータスは、その対象の正確なデプロイメント ステータスを表していませんでした。 コンポーネントの可用性ステータスは、そのコンポーネントがサーバ上で動作しているかどうかを示すものです。 対象のクラスタまたは仮想ホストのすべてのサーバ上にある、特定のコンポーネントの現在の可用性も示します。 可用性ステータスは、対象のサーバが正常停止または強制停止するときに更新されます。 デプロイメント ステータスと可用性ステータスを集約して、コンポーネントのデプロイメント ステータスが表示されるようになりました。 コンポーネントの集約されたデプロイメント ステータスは、コンポーネントが 1 つのサーバにデプロイされている場合は [使用可能] または [使用不可能]、クラスタまたは仮想ホストにデプロイされている場合は [使用可能]、[使用不可能]、または [一部使用可能] になります。 [一部使用可能] デプロイメント ステータスは、そのコンポーネントがクラスタまたは仮想ホストの一部のサーバでのみ使用可能であることを表しています。 この変更の結果、クラスタ デプロイメントのステータス レポートを取得するのに必要な RMI 呼び出しの数が最小限に抑えられ、パフォーマンスが向上しました。
CR214994	Administration Console の [サーバ｜モニタ｜バージョン] ページでは、システム プロパティ java.vm.vendor が正しく表示されるようになりました。
CR178658	サーバとクラスタのコンフィグレーションに [Servlet Extension Case Sensitive] 属性が追加されました。 また、セキュリティ ドメイン コンフィグレーションには [Web App Files Case Insensitive] 属性が追加されました。 これらの属性では、win32 以外のすべてのプラットフォームにおいて、Java Server Pages (JSP) のファイル ルックアップで大文字/小文字を区別するかどうかを指定します。標準の win32 ファイル システムにおけるファイル ルックアップでは、常に大文字/小文字は区別されません。 win 32 以外の大文字/小文字を区別しないファイル システム (UNIX の NT Samba マウントや、大文字/小文字を区別しないモードでインストールされた Mac OS など) で、大文字/小文字を区別しないルックアップを指定すると (これらの属性を false に設定する)、JSP はそのソース コードを返さなくなります。 たとえば、JSP が Samba マウントから提供されていて、大文字/小文字を区別しないルックアップを指定した場合、WebLogic Server はすべてのファイル名拡張子を小文字に変換してから JSP をルックアップします。 使用できる値と用法 : 1. OS (デフォルト値): WebLogic Server はパターン マッチングに関してオペレーティング システムに依存する。 2. True: WebLogic Server はオペレーティング システムに関係なく大文字/小文字を区別しない。 3. False: WebLogic Server はオペレーティング システムに関係なく大文字/小文字を区別する。

クラスタ

変更要求番号	説明
CR177776	WebLogic Server では、レプリケートされたセッション http リクエストが、そのリクエストのプライマリでもセカンダリでもないサーバに届いたときに、クラスタで分散デッドロックが発生しました。 このようなリクエストがクラスタ内のサーバにいくつも送られると、それが原因でデフォルト スレッド プールのすべてのスレッドが消費されて、ある時点になると、デフォルト スレッド プールには応答を受信するために使用できるスレッドがなくなります。 その結果分散デッドロックが発生します。 WebLogic Server では、このような状況でデッドロックが発生しなくなりました。
CR206375	クラスタ内で http リクエストをロード バランシングすると、以下のような誤ったエラー メッセージが報告されることがありました。 Error while primary becoming secondary,[No old secondary found for roid:<roid>] or [No new primary found for roid:<roid>] このエラー メッセージは、プラグインまたはロード バランサで、セッション維持のコンフィグレーションに問題があることを示しています。 WebLogic Server は、問題を説明し、ロード バランサまたはプラグインでセッション維持のコンフィグレーションをチェックするように指示する、正しいメッセージを表示するようになりました。

コネクタ

変更要求番号	説明
CR184893	RAR からのクラスローディングの速度が低下しなくなりました。

コア サーバ

変更要求番号	説明
CR108791	サーバ状態が SHUTDOWN_IN_PROCESS のときに Runtime.getState が呼び出されると、WebLogic Server は誤った文字列を返していました。 現在の WebLogic Server は、サーバの状態を表す正しい文字列を返します。 アプリケーションが以前の誤った文字列定数に依存していた場合は、文字列定数を変更する必要があります。
CR125000 CR129560	クラスタ サービスでは、マルチキャスト ポートへのバインド後にプロセスの実際の uid/gid を設定していました。 その結果、WebLogic Server がリスン ポートへのバインド後にユーザを切り替えようとしたときに、エラーが発生しました。 現在、WebLogic Server は、ポートへバインドする場合を除いて、サーバの起動時にバインド後の uid/gid を使用し、すべてのポートでリスンした後でのみ実際の uid/gid に切り替えます。
CR121483	モニタ サブシステムが abbrev テーブルの値を読み込もうとしていて、同時に abbrev テーブルが rjvm レイヤによって変更されていたときに、ConcurrentModificationException が送出されました。 HashMap が 2 つのスレッドから同時に変更されないように、モニタ サブシステムにデータを送信する前にキー セットを複製することで、ConcurrentModificationException を回避しました。
CR130376	ドキュメントの「サーバの起動と停止」の節では、CLASSPATH が長すぎる場合でも 1 行としてファイルに追加され、-classpath @filename としてアクセスできると説明されていました。 しかし、beasvc が CLASSPATH ファイルの内容をロードする際に最後の文字を削除してしまうことがあったため、上記の説明どおりには機能していませんでした。 この問題は、ファイルが改行で終わっていない場合にのみ発生していました。 この問題は解決済みです。
CR133631	beasvc.exe でコンフィグレーションされている Windows サービスを停止する場合、停止クラスを指定するときにタイムアウトが発生することがありました。 beasvc.exe の停止スレッドとメイン スレッドの間で競合状態が発生したため、サービスがタイムアウトしていました。 競合状態を修正したため、Windows サービスはタイムアウトしなくなりました。
CR135225	RJVM と NTSocketMuxer の間でデッドロックが発生していました。 WebLogic Server がディスパッチ中に IORecord でロックを保持しないようにするコードを追加しました。そのためデッドロックは発生しなくなりました。
CR105444	-Dweblogic.Stdout および -Dweblogic.Stderr コマンドライン オプションを使用してログ ファイルのパスを指定したものの、そのディレクトリが存在しない場合に、サーバは FileNotFound Exception を送出していました。 コマンドライン オプションで指定されたディレクトリ構造が存在しない場合は、そのディレクトリを作成するようにコードを改良して、この問題を解決しました。
CR099356、CR099005、CR186191	JVMSocketManager で競合状況が発生すると、MuxableSocketDiscriminator.isMessageComplete が NullPointerException を送出し、その結果 JVMSocketManager が無限ループに入っていました。 現在は、JVMSocketReader が静的イニシャライザで必要な情報を初期化するので、初期化は 1 回だけ行われて、無限ループは発生しません。
CR130409	カスタム キュー上の「リソースを大量に消費する動作の遅い」リクエストを抑制するために -Dweblogic.kernel.allowQueueThrottling フラグを使用して実行キューの最大長を設定しても、クライアントは 503 応答を受け取ることなくタイムアウトを待機していました。 この問題は、呼び出し側のディスパッチの戻り値をチェックし、sendError() API を使用して 503 応答を返すようにコードを修正することで解決しました。
CR174955、CR105257	IIOP 接続プールが初期化される前に WLECService.getConnectionPoolCount を呼び出すと、NullPointerException が発生していました。 現在は、IIOP 接続プールが null の場合には 0 を返します。 その結果、WLECService.getConnectionPoolCount を呼び出したときに NullPointerException が送出されなくなりました。
CR180426	WebLogic Server がクラスタ内で動作しているときに、クラスタの DNS 名が設定されていない場合、警告メッセージが表示されました。 この警告メッセージによってクラスタのパフォーマンスが低下していました。 現在は、クラスタ アドレスがネットワーク チャネルで設定されていない場合、クラスタ アドレスは常にクラスタ MBean から読み込まれます。 その結果、警告メッセージによるクラスタのパフォーマンスの問題は起きなくなりました。
CR180532	ドメイン ログとサーバ ログが同時にローテーションするときに、デッドロックが発生することがありました。 現在、WebLogic Server はログをローテーションする間はメッセージをログに記録しません。 その結果、ログのローテーション時にデッドロックが発生しなくなりました。
CR173958、CR185090	フロントエンドとバックエンドの間のプロトコルを「セキュア」から「非セキュア」に変更した場合に、t3 を使用した 6.1 SP4 ドメインと 7.0 SP5 ドメインの相互運用性が正しく機能しませんでした。 認証呼び出しの際に、フロントエンド QOS がバックエンドに伝播され、呼び出しに失敗していました。 この問題は、ブートストラップ認証呼び出しに「匿名」を使用することで解決しました。
CR175607	WebLogic Server をアンインストールした直後に Windows サービスとしてインストールしなおすと、誤ったレジストリ キーが作成されることがあったため、正常に起動できなくなる問題が発生していました。 コードを修正したことで、レジストリ キーがフラッシュされて正しく閉じられるようになりました。
CR179262	起動時に、weblogic.jms.common.DistributedDestinationManager と weblogic.cluster.MemberManager の間でデッドロックが発生しました。 MemberManager での同期化を減らしたため、デッドロックは起きなくなりました。
CR182838	LocalServerRef が hashCode メソッドを実装していなかったため、異なる PK を持つ複数のエンティティ Bean が同じスタブを保持してました。 現在、LocalServerRef は hashCode メソッドを正しく実装しています。
CR185841	多数の管理対象サーバを同時に起動する場合、管理サーバの CPU 使用率が高くなりました。 現在の WebLogic Server では、ServerMbean.getName() に対するリモート呼び出しの回数が減っています。 その結果、大きなクラスタで管理対象サーバの起動時間が速くなり、管理サーバの CPU 使用率が下がりました。
CR172366	beasvc.exe からイベント ログに出力されるメッセージが、日本語環境では正常に表示されませんでした。 コードを修正したことで、英語以外のすべての言語環境でも、英語のメッセージが出力されるようになりました。
CR181986	サービスとして実行される WebLogic Server が多数のスレッドを使用すると、メモリ不足になることがありました。 beasvc.exe と beasvc64.exe で使用される予約スタック サイズを 1MB から 256KB に減らすことで、メモリの問題を解消しました。
CR182684	beasvc サービス ハンドラが呼び出されるたびに、beasvc ログは呼び出されたことを示す行を追加していました。 次に例を示します。 Tue Apr 27 11:52:17 2004] [I] [service_ctrl] 4 そのため、サーバで実際のアクティビティがないときにログが一杯になりました。 デバッグ文を削除して、ログの問題を解消しました。
CR188371	アプリケーションがステートレス セッション Bean のリモート スタブをキャッシュしたときに、クラスタ内のすべてのサーバを再起動すると、スタブでは、リモート オブジェクトが使用できるサーバ ノードのリストを更新できなくなり、フェイルオーバが失敗しました。 スタブにはクラスタ ノードで初期コンテキストを再確立するのに必要な情報がなく、リモート メソッドの呼び出しが失敗したためにこの状況が発生しました。 WebLogic Server のコードは、WebLogic Server 6.1 ではステートレス セッション Bean スタブのスレッド環境を伝播していませんでしたが、WebLogic Server 7.0 以降ではアンマーシャリングの際に、フェイルオーバが動作する環境を設定するために必要です。 現在、クラスタ対応のステートレス セッション Bean の実行時記述子では、propagate-environment 属性がデフォルトで true に設定されています。 アンマーシャリングの際に環境が渡されるように、記述子が読み込まれて propagateEnvironment が設定されます。 これにより、フェイルオーバ ロジックはクラスタ ノードを再接続して、リモート オブジェクトが使用できるサーバ ノードの新しいリストを取得し、フェイルオーバを適切に行えるようになりました。
CR190417	リクエストがプライマリでもセカンダリでもないサーバに届いた場合、リクエストはセッション ID にあるホストとポートの情報を使用してセカンダリ サーバ上でセッションをルックアップして、既存のセカンダリからセッションを取得していました。リクエストは既存のセカンダリからセッションを正常に取得した後で、既存のセッションを削除して新しいセッションを作成しようとしました。 2 つのリクエストが同時に発生した場合、分散デッドロックが発生する可能性がありました。これらのリクエストは「レプリケーション」スレッド キューに届きますが、「レプリケーション」スレッド キューには 2 つのスレッドしかなく、応答を読み取るために使用できる他のスレッドがないためです。 問題を修正するコードを WebLogic Server に追加したため、デッドロックは発生しなくなりました。
CR190507	ReplicationManager の一方向の呼び出しに関する問題を修正しました。
CR203523	以前のリリースの WebLogic Server で表示されていた以下のログ メッセージが復活しました。 <Warning> <WebLogicServer> <000333> <Queue usage is greater than QueueLengthThresholdPercent "3%" of the maximum queue size. We'll try to allocate ThreadsIncrease "5" thread(s) to help.>
CR206459	クライアントサイドで作成できる最大スレッド数の制限 (50) を修正しました。 現在、クライアントサイドで作成できる最大スレッド数の制限は 65536 に設定されています。
CR183620	ドメイン コンフィグレーション ウィザードから生成される管理対象サーバの起動スクリプト (startManagedWebLogic.sh または startManagedWebLogic.cmd) には、次のような誤った行が含まれていました。 cd @USERDOMAIN_HOME この誤った行が原因で次のエラーが発生しました。 C:¥bea70sp5¥user_projects¥mydomain>echo off The system cannot find the path specified. この問題を修正するために、現在のドメイン コンフィグレーション ウィザードは文字列を置換しています。

デプロイメント

変更要求番号	説明
CR179645	WebLogic Server では、大きな JAR ファイルを復元する速度が向上しました。
CR183537、CR187458	アプリケーションの再デプロイ時に対象が指定されない場合、weblogic.Deployer はデフォルトの対象として管理サーバを追加していました。 現在は、対象が指定されなかった場合、デプロイされていたアプリケーションは現在のすべての対象に適切に再デプロイされます。 新しいアプリケーションはデフォルトで管理サーバにデプロイされます。
CR192196	WebLogic Server 8.1 クライアントが WebLogic 7.0 管理サーバに対して DeployerRuntime.getDeployerRuntime(MBeanHome) を呼び出した場合、InstanceNotFoundException が発生していました。 DeployerRuntime.getDeployerRuntime(MBeanHome) の実装が変更されました。 その結果、WebLogic Server 8.1 クライアントが WebLogic 7.0 管理サーバから (または WebLogic Server 7.0 クライアントが WebLogic 8.1 管理サーバから) DeployerRuntime MBean を取得しても InstanceNotFoundException は発生しなくなりました。
CR124450	サーバが開発モードで動作している場合に、Microsoft Windows エクスプローラを使用して、サーバ上にデプロイされている EAR ファイルをアプリケーション ディレクトリから削除しようとした場合、以下のエラーは発生しなくなりました。 Cannot delete abc.ear:there has been a sharing violation, The source or destination file may be in use.

EJB

変更要求番号	説明
CR055396	EJB QL の構文エラーが発生したときに、WebLogic Server は誤った XML ファイルの参照を含むエラー メッセージを生成しました。 EJB QL に構文エラーがある場合、WebLogic Server は次のようなメッセージを生成するようになりました。
CR060229	Administration Console はステートフル EJB とエンティティ EJB の [コミットしたトランザクション数]、[ロールバックしたトランザクション数] または [トランザクションのタイムアウト総数] を表示していませんでした。 Administration Console でこれらの項目をモニタできるようになりました。
CR087261	EJBDeployer はメッセージ駆動型 Bean のログに誤ったデプロイメント メッセージを書き込んでいました。 メッセージ駆動型 Bean がデプロイされるときに正しいメッセージがログに記録されるようになりました。
CR127369	複数の Bean が同じ Java クラスに基づいている場合、AssertionError が送出されることがありました。 このエラーは以下の条件が満たされると発生しました。 1. Bean A が Bean X と多対 1 の関係にある （一方向の関係）。 2. Bean B が Bean X と多対 1 の関係にある （一方向の関係）。 3. Bean A と B は同じ Java クラスに基づいた別々のデプロイメントである。 Bean の関係を処理する場合、WebLogic Server は cmr-field 名のリストを保持します。cmr-field 名が宣言されていない場合は、Bean のクラス名に基づいて cmr-field 名を作成します。 上記の場合では、Bean X の関係を処理するとき、Bean A との関係の cmr-field 名と Bean B との関係の cmr-field 名が作成されます。 これらのクラス名は同じであるため、作成される cmr-field 名も同じになります。 そのため AssertionError が発生します。 cmr-field 名をユニークにするためのコードを追加して、名前が衝突する可能性を排除しました。
CR108169	Administration Console を使用して EJB デプロイメント記述子を編集する際、誤ったメソッド名が表示されていました。 正しいメソッド名が表示されるようになりました。
CR135410	Bean をルックアップして初めてビジネス メソッドを呼び出す場合、ejbStore からの EntityContext.getCallerPrincipal() への呼び出しではユーザが「anonymous」として返されていました。 その後、ejbStore を再度呼び出すと、正しいユーザ名が返されました。 これは ejbStore 固有の問題であり、他のメソッドでは発生しません。 この問題は解決済みです。
CR187121	デプロイメント記述子で idleTimeoutSecs に 60000000 のような大きな値が設定されている場合、1000 を掛けてミリ秒に変換すると、負の値にオーバーフローしていました。 その結果、パッシベーションされた Bean をディスクから消去するトリガが頻繁に発生して、CPU の使用率が高くなりました。 タイムアウト値をミリ秒単位で保持する EJB コンテナの変数 (idleTimeoutMS、sessionTimeoutMS、readTimeoutMS など) が int 型から long 型に変更されました。 これにより数値のオーバーフローは発生しなくなりました。
CR189847	ステートフル セッション Bean (SFSB) のインメモリ レプリケーションが原因でメモリ リークのような状況が発生しました。 メモリ リークは発生していませんでしたが、ヒープ メモリが効率的に使用されていませんでした。 現在は、SFSB のインメモリ レプリケーションでヒープ メモリが効率的に使用されます。
CR196593	NRUCache でのロックの競合が原因で、ステートフル セッション Bean (SFSB) のレプリケーション時にサーバがハングしていました。 SFSB のレプリケーション時にサーバがハングしないように、NRUCache でのロックの競合を削減しました。
CR197817	WebLogic Server がエンティティ Bean のファインダ メソッドを実行すると、NullPointerException が送出されていました。 NullPointerException を解消するため、現在の生成コードでは Bean が null の場合も予期しており、Bean は適切に処理されるようになりました。
CR132510	Optimistic 同時方式を使用し、cache-between-transaction が true に設定されたエンティティ Bean で、リレーションシップ キャッシングを有効にした場合、WebLogic Server は IllegalStateException を送出しなくなりました。
CR205974	コレクションの値を持つ CMR フィールドが、作成元のトランザクション以外のトランザクションでアクセスされた場合に、WebLogic Server は IllegalStateException を送出しなくなりました。 その結果、WebLogic Server は、キャッシング設定の有効/無効に関係なく、ファインダ クエリから正しい結果セットを配信します。
CR203644	インメモリ レプリケート セッションによりレプリケートされたクラスタ内のステートフル セッション Bean は、インスタンスがパッシベーションされた後、またはクラスタ インスタンスが停止した後に NoSuchObjectException または LeasedRemoteRef エラーを送出しなくなりました。

インストール

変更要求番号	説明
CR121040	サービスをアンインストールして再インストールしないと、WebLogic Server Windows サービスのパスワードを変更することはできませんでした。 現在は、サービスを再インストールしないでもパラメータを編集できるように、edit オプションが用意されています。 個別のまたは複数のオプションを次のように同時に編集できます。 beasvc -edit -svcname:wls_service -javahome:"C:¥java¥java142_05" -password:"blah" (このコマンドでは javahome および password パラメータの値が変わります) このオプションはサービスの再起動時に有効になります。

インターナショナライゼーション

変更要求番号	説明
CR079432	MessageLocalizer は、l10ngen ユーティリティを使用して、ローカライズされたカタログ ファイルに l10n_package 属性を設定していませんでした。 MessageLocalizer はローカライズされたカタログ ファイルに l10n_package 属性を正しく設定するようになりました。

J2EE

変更要求番号	説明
CR132360	weblogic.j2eeclient.Main が WebStart で動作しませんでした。 このクライアント jar ファイルは、WebStart クライアントによってロードされる引数であり、クラスパスに設定されていました。 しかし、現在のディレクトリで使用できなかったため、エラーが発生しました。 システム クラスパスからクライアント jar ファイルをロードするために、WebLogic Server にシステム プロパティ (weblogic.j2ee.client.isWebStart) が追加されました。 weblogic.j2eeclient.Main は WebStart で動作するようになりました。
CR103309	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-70.00.jsp のセキュリティ勧告を参照してください。
CR186016	アプリケーションの再デプロイ時に、WebLogic Server 7.0 サービス パック 5 以前と同様、J2EEApplicationContainer によって JDBCModule のような内部モジュールが再デプロイされるようになりました。
CR097079	アプリケーションが管理対象サーバから削除されるとき、サーバのステージング ディレクトリから補助的な jar ファイルも削除されるようになりました。
CR103506	名前にピリオド「.」が入っているディレクトリが含まれた展開形式の .ear ディレクトリをデプロイするときに、NullPointerException は送出されなくなりました。

JCOM

変更要求番号	説明
CR185934	Microsoft Security Bulletin MS04-011 が適用されたときに、COM to Java クライアントで障害が起きていました。 この問題は解決されています。
CR199844	例外が発生すると COM ソケットがリークしていました。 例外が発生した場合、COM ソケットは適切に閉じられるようになりました。

JDBC

変更要求番号	説明
CR136746	JDBC ドライバの明示的なネーミングはクラス VendorId で使用できませんでした。 この問題は解決済みです。
CR127720	新しいバージョンの JDBC ドライバは、接続のトランザクションの状態を追跡します。 接続でローカル トランザクションがアクティブな場合、その接続で XA の操作は実行できず、xa_start() が呼び出されたときに XAER_PROTO または XAER_RMERR が生じていました。 結果として、アプリケーションでは、ローカル トランザクションを開始したが終了していないコード中の場所を絞り込む冗長なプロセスを実行しなければなりませんでした。 この問題は、特殊な XA 接続がプールに 2 度解放されないように回復メソッドのコードを修正して解決しました。
CR174126	複数の異なる Prepared Statement を 1 つのトランザクションで使用すると、XA 対応の Statement キャッシュでバグが発生し、閉じられていない JDBC 文のハンドルが失われていました。 このことが原因で、Oracle のすべての利用可能なカーソルがすぐに消費およびリークされていました。 XA 対応の Statement キャッシュを実装するために使用されるコレクション オブジェクトが修正されました。
CR177220	マルチサーバ ドメインで、グローバル トランザクションに参加しているクライアントが次の例外を受け取っていました。 weblogic.transaction.RollbackException: delist() failed on resource jdbcXAPool データソースが null の場合はリソース マネージャが設定されないように、コードが変更されました。 データソースが初期化されると、リソース マネージャは VendorXAResource によってラップされます。
CR180097	JDBC 接続プールの「CountOfTestFailuresTillFlush」プロパティで、文のキャッシュがクリアされていませんでした。 この問題は、コードを修正することで解決しました。 「フラッシュ プール」機能の使い方の詳細については、『WebLogic JDBC プログラマーズ ガイド』の「JDBC 接続プールのテスト機能の拡張」を参照してください。
CR184819	WebLogic Server マルチプールは、RAC の複数のインスタンスがコンフィグレーションされていて、最初の RAC インスタンスが停止した場合に、フェイル オーバしていませんでした。 現在、マルチプールは正しくフェイル オーバします。
CR182410	負荷の高い状況で、WebLogic Server の速度が大幅に低下しました。 weblogic.jdbc.common.internal.MultiPool.searchLoadBalance() メソッドから同期化を削除して、負荷の高い状況での速度低下を解消しました。
CR189978	プールのコンフィグレーションが誤っているか、データベースが応答しない場合に、アクティブ化されないプールが作成される可能性がありました。 プールがアクティブ化されない場合、WebLogic Server は ResourceException を送出しました。 この例外が送出されたとき、JDBC マルチプールはアクティブな次のプールにフェイル オーバしませんでした。 現在、WebLogic Server はプールがアクティブ化されないというメッセージと共に ConnectDisabledException を送出します。 JDBC マルチプールはこの例外を検出して対応し、使用可能な別のプールがあれば再試行します。 その結果、JDBC マルチプールは、リスト内にアクティブ化されないプールがあった場合、アクティブなプールにフェイル オーバするようになりました。
CR187604	JTS Statement ラッパーの getMoreResults および getResultSet を呼び出した場合、既に閉じられた同じ結果セットが返されることはなくなりました。
CR196738	MSSQLServer4 ドライバの Statement.cancel() メソッドによって JDBC 接続にエラーが起きていました。 接続が閉じられた後に JDBC 文がトランザクション内で閉じられていませんでした。 MSSQLServer4 ドライバの Statement.cancel() メソッドが変更されて、ノー オペレーション命令となったため、接続でエラーが起きなくなりました。 この変更はトランザクションのロールバックには影響しません。
CR197163	JDBC 接続プールの接続のテストでは、DBMS に毎回 SQL の解析とテストを要求する単純な文がテストのたびに新しく作成されていたため、大量のデータベース リソースを消費していました。 プールは接続のテストで 1 つの Prepared Statement を再利用するようになったため、パフォーマンスが向上しました。 ただし、アプリケーションの DBMS テーブルやプロシージャがテスト SQL で参照されていて、実行時に構造的に変更される場合 (インデックスの追加など)、テスト用 PreparedStatement のクエリの実施が無効になる可能性があります。 その結果、以降のテストが失敗して、接続とテスト文は置き換えられます。 通常、Administration Console で指示されるテスト SQL には、構造的なテーブルの変更は含まれないので、接続の不必要な再利用の問題は最小限に抑えられています。
CR203460	XAConnectionFactory によってプールの接続が作成されるときに、その seconds-to-trust 値が設定されていない場合はデフォルトのままでした。 現在は seconds-to-trust 値が設定されます。
CR193357	JDBC のリフレッシュ機能では、予約されていない接続の数を誤って数えていました。 JDBC のリフレッシュ機能は予約されていない接続の数を正しく数えて、不要な処理をしなくなりました。
CR087241	XA 呼び出しと Oracle ドライバを使用する JDBC アプリケーションで、トランザクションがサスペンドされて再開されるときに行を取得する際に、「ORA-01002: フェッチ順序が無効です」エラーが発生していました。 XA 呼び出しで Oracle 10g thin ドライバを使用する場合のこの問題を修正するために、AddOracleFlagToXAResource フラグが追加されました。 XA 呼び出しを使用する場合に「ORA-01002: フェッチ順序が無効です」エラーを回避するには、Oracle 10g thin ドライバを使用して JDBCConnectionPool フラグを有効にする必要があります。

jDriver

変更要求番号	説明
CR142730、CR190124、CR190125	長いデータベースの停止の後、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 は、失敗した接続作成の試行をクリーンアップするようになりました。
CR136168	WebLogic jDriver は、負荷が大きい状態で Long raw 型を使用しているときに、Oracle エラー メッセージ ORA-02392 でサーバをクラッシュさせることがあります。 修正コードを実装して、この問題を解決しました。
CR172462	AL32UTF8 文字セットが使用されているときに、WebLogic Server jDriver が Oracle 9.2 で正しく機能していませんでした。 この問題は、コードを修正することで解決しました。

JMS

変更要求番号	説明
CR099554、CR195519	環境によっては、JMS メッセージが保留状態にあるサーバが停止されるか、クラッシュした場合に、保留中のメッセージがサーバの再起動時に回復されませんでした。 保留中メッセージがサーバの再起動時に回復されるようになりました。
CR135578	非恒久トピックで、未処理の非恒久トピック メッセージが再配信遅延のためにまだ保留中のときに、コンシューマが終了した場合、このトピックの保留中バイト数の数字が正しく更新されていませんでした。 現在は、JMS の統計で、再配信遅延パラメータがコンフィグレーションされている場合にコンシューマが終了したとき、非恒久トピック メッセージの保留中バイト数は適切に調整されます。 コンシューマが終了した場合、確認応答されていない非恒久トピック メッセージに対して再配信遅延は実施されません。
CR134155	トピック セッションからの JMS メッセージが、受信側がトランザクション セッションを使用して作成され、AUTO-ACKNOWLEDGE が使用され、メッセージがロールバックされた場合にメモリ リークを生じさせていました。 コードを修正してこの問題は解決されました。
CR178775	JMS クライアントが WebLogic Server に対して JMS 接続を繰り返し開いて閉じた場合、JMSConnection と DispatcherWrapper などの関連するオブジェクトはクライアントサイドとサーバサイドの両方で解放されませんでした。 このため、OutOfMemoryError が発生しました。このエラーは、クライアントが JMS 接続を 1 つ開いて保持している間に、他の JMS 接続を開いて閉じると発生します。 コードの変更により、この問題は修正されました。
CR179737	競合状況が原因で、JMS が失われた接続を検出してクリーンアップできなくなる場合がありました。 このような競合状況の発生を防ぐために再試行ロジックが強化されました。
CR173565	XA トランザクションが失敗したときに、JMS メッセージが 2 度配信されていました。 失敗したトランザクションを処理し、曖昧な状態のトランザクションがあることをユーザに通知するために適切なエラー メッセージをログに記録するように、コードが修正されました。 この修正の前は、曖昧な状態にあるトランザクションのメッセージはすべてロールバックされ、メッセージがメモリにあるために再配信されていました。 しかし、ストア内のレコード (ある場合) はそのレコードのストアのハンドルが無効であるために正しく更新されず、レコード (ある場合) はストアに残されていました。 したがって、JMS サーバが再起動されたときに、メッセージは再配信されてメッセージの重複が生じていました。 現在は、曖昧な状態にあるトランザクションのメッセージは、JMS サーバが再起動しないと回復できないようになりました。 JMS サーバの再起動なしにメッセージを回復しようとすると、RMERR が生じます。
CR183572	JMS IOThreadPool 名が誤っていたため、WebLogic Server のすべての JMS ストアが同じ 2 つのスレッドを共有していました。 その結果、3 つ以上の JMS ストアが同じ WebLogic Server 上で動作している場合、パフォーマンスが低下する可能性がありました。 JMS IOThreadPool 名が正しくなったため、パフォーマンスが低下する可能性はなくなりました。
CR178405	期限切れメッセージの調査時に、java.util.ConcurrentModificationException が送出されていました。 この問題は、コードを修正することで解決しました。
CR182338	ConnectionFactory で RedeliveryLimit がコンフィグレーションされている場合、RedeliveryLimit の到達回数が MessagesMaximum の設定よりも大きくなると、レシーバはメッセージの処理を停止します。 例 : RedeliveryLimit=0, MessagesMaximum=10。 レシーバは 1 つのメッセージを受け取ると sesssion.recover() を 10 回呼び出します。 レシーバがメッセージの処理を停止すると、コンソールには保留中メッセージ数として 10 と表示されます。 コードを追加して、RedeliveryLimit に達したためにキューからメッセージが削除される場合のウィンドウ カウンタを調整するようにしました。
CR188040	WebLogic JMS は ServerDebugMBean() の JMS 属性が変更されたときに通知を受け取っていませんでした。 現在は、ServerDebugMBean() を使用して、ServerDebugMBean の「DebugJMS」属性を動的に有効または無効にできます。 これによって、ユーザは JMS のデバッグ フラグを動的に有効または無効にできます。
CR187945	JMS DistributedDestination ロード バランサは、メンバーが動的に追加されたときに、既存のコンシューマを認識しませんでした。 現在の WebLogic Server は、ロード バランサが適切にロード バランシングするために必要な情報を持てるように、分散送り先にメンバーが追加されるときに、メンバーがコンシューマを持つかどうかをチェックします。
CR190438	weblogic.jms.backend.BEQueue オブジェクトと weblogic.jms.backend.BEConsummer オブジェクトの間で、Java レベルのデッドロックが見つかりました。 送り先が最初にロックダウンされるようにロックの階層構造を更新することで、この問題を解決しました。
CR197857	JMS は最小フロー率を保持していました。 実際の最小フロー率はコンフィグレーションされた値の約 2 倍でした。 接続ファクトリのデフォルトのフロー制御設定 (FlowMinimum=50) を使用する場合、JMS は 1 秒間に 50 メッセージではなく、約 100 メッセージの最小フローを保持していました。 現在は、JMS 送り先で指定されたバイト数またはメッセージしきい値を超えた場合に、プロデューサに対するフロー制御が開始されると、フローは FlowMinimum (デフォルトは 50) にまで抑制され、しきい値を超えている間は、その最小フロー率が維持されます。 この変更によって、JMS は最小フロー率を正しく保持するようになったため、以前よりもフローが大幅に抑えられました。 以前のフロー制御の動作 (8.1 sp4 リリースよりも前の動作) を維持するには、FlowMinimum のコンフィグレーションを 2 倍にして ConnectionFactories に FlowMinimum=100 を追加します。この値は以前のデフォルト値を想定したものです。
CR187610	ブリッジは、ブリッジのディスパッチ リクエストに対して、メッセージング ブリッジのスレッド プールを使用していませんでした。 現在は、メッセージング ブリッジのスレッド プールがコンフィグレーションされている場合、ブリッジはそれを使用します。 メッセージング ブリッジのスレッド プールにコンフィグレーションされている使用可能なスレッド数が十分でない場合、ブリッジはデフォルトの実行スレッド プールを使用します。 ブリッジは、コンフィグレーションされているメッセージング ブリッジのスレッド プール サイズが不十分な場合、警告メッセージをログに記録し、代わりにデフォルト実行プールからスレッドを取得します。

JNDI

変更要求番号	説明
CR197207	EJB 呼び出しの応答で、JNDI ルックアップが静的ブロックから実行された場合に、Java クライアントがハングしました。 問題を修正するため、新しいシステム プロパティ (-Dweblogic.rjvm.t3.dispatchOnCompleteMessage) が追加されました。 このプロパティはクライアントサイドで有効にする必要があります。 このプロパティを有効にすると、t3 リクエストはソケット リーダー スレッド以外のスレッドで処理されます。

JSP

変更要求番号	説明
CR087857	JSP ページまたはサーブレットによって文字セット エンコーディングが設定された場合に、ServletOutputStream.write(int) メソッド (引数として int 型を取る) は指定された文字セット エンコーダを使用してエンコードされたデータを受け取りました。 WebLogic Server は ServletOutputStream.write(int) が呼び出され場合はバイナリ データをエンコードしなくなりました。
CR101992	セッション内にローカルの EJBObject 参照を持つ Web アプリケーションで、再デプロイ後に javax.ejb.EJBException が発生することがありました。 例外を捕捉してメッセージをログに記録するコードを追加しました。 現在、このような状況では、シリアライゼーション エラーを示すエラー メッセージがログに記録されて、HttpSession、ServletRequest または ServletContext の getAttribute() が null を返します。
CR174837	WebLogic Server ではカスタムの PageContext 実装を許可していませんでした。 生成された JSP に含まれていた weblogic.servlet.jsp.PageContextImpl への不要なキャストは削除されました。 その結果、カスタムの PageContext 実装が使用できるようになりました。
CR172380、CR198902	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 ライブラリがロードしようとする他のクラスのロードで同じクラスローダが使用されるようになります。
CR085091	リクエストが保護されたリソースに対する条件付きの GET (Is-Modified-Since ヘッダを設定) である場合、カスタム エラー ページを提供できなくなる問題がありました。 定義されている場合はカスタム エラー ページが提供されるようにロジックを修正しました。
CR180425	WebLogic Server はリクエストがプロキシから来ていない場合でも wlsproxy 固有のヘッダを送信していました。 コードを追加して、リクエストがプロキシから来たかどうかをチェックして適切なヘッダを送信するようにしました。

JTA

変更要求番号	説明
CR130073	アプリケーションが WTC を介して Tuxedo 7.1 から WebLogic Server に複数のロールバックを発行すると、一部の Oracle XA 接続がリークし、プールに戻されていませんでした。 XA Debug では、XA End が呼び出されないために接続がクリーンアップされないことが示されていました。 XA End を呼び出すようにすることで、接続がプールに戻されるようになり、メモリ不足エラーは発生しなくなりました。
CR125476	トランザクションが準備フェーズにあり、XAER_RMERR または XAER_RMFAIL が送出された場合に、トランザクションがロールバックされずに保留されたままになりました。 このような状況でトランザクションがロールバックされるようになりました。
CR184941	サーバをバックアップするため手動で JTA を移行した後に、クラッシュした WebLogic Server を起動しようとしても起動できませんでした。 サーバをバックアップするため手動で JTA を移行した後でも、クラッシュした WebLogic Server を再起動すると起動できるようになりました。
CR202386	トランザクション マネージャは、新しいリソース マネージャに関連付けられたオブジェクトの xa_start() の呼び出しに失敗していました。 この問題を修正するために、デフォルトの登録が標準化されました。 アプリケーションが registerResosource() を呼び出さない場合、リソースは標準のリソースとしてトランザクション マネージャに登録されます。
CR188558	タイマー スレッドがオフになる前に WebLogic Server を停止すると、一部のリソースのチェックポイントが TLOG に記録されていませんでした。 WebLogic Server を再起動しても、これらのリソースの回復処理は実行されず、保留になっていたトランザクションは保留のままになっていました。 リソースがローカルで調整され、かつリソースのチェックポイントを記録する必要がある場合は、トランザクションをリソースに登録するとフラグが立てられ、トランザクションが 2 フェーズであれば準備時間にリソースのチェックポイントが TLOG に記録されるようになりました。
CR173464	キャッシュされているコーディネータを取得するときに、スレッドは早期通知状態に入らなくなりました。以前はこのためにサーバがハングしていました。
CR211194	MQSeries リソースの場合は、XA.end (TMSUSPEND)、XA.end (TMFAIL)、XA.rollback という順序の XA 呼び出しシーケンスを呼び出して、MQSeries でメモリ リークが発生しないようにしています。

JVM

変更要求番号	説明
CR132228、CR188670	問題のない IOExceptions が日本語ロケールで抑制されていませんでした。 現在、WebLogic Server はネイティブ IO を有効にする場合、デフォルトではロケールを C に設定します。 ロケールを C に設定しない場合は、以下のシステム プロパティを使用できます。 -Dweblogic.nativeIO.useDefaultLocale=true 英語以外のロケールでは、問題のない例外が抑制されます。

ノード マネージャ

変更要求番号	説明
CR135917	stderr に対する fdopen が失敗した場合に、NodeManager のネイティブ コードが原因で、セグメンテーション違反が起きることがありました。 この問題は修正されています。
CR076968	オフライン メソッドが呼び出された場合、プロセス終了信号として SIGTERM ではなく SIGKILL を連続して送信するように、NodeManager を更新しました。
CR128517	Administration Console を使用してマシンをコンフィグレーションし、NodeManager をコンフィグレーションしない場合に、サーバの状態を問い合わせると、デフォルトでは NodeManager に対して問い合わせが行われます。 NodeManager が必要ない場合は、マシン コンフィグレーションで ListenPort を 0 に設定してください。 これにより、NodeManager がコンフィグレーションされていないことがサーバに伝わり、サーバは NodeManager への問い合わせを行わなくなります。

操作と管理

変更要求番号	説明
CR132947	ドメイン内の管理対象サーバの停止後にそのドメインの管理サーバが停止すると、管理サーバから常に java.rmi.ConnectException が送出されていました。 この問題は修正されています。
CR187170	配列型の属性が変更されたとき (配列の要素が追加または削除されたとき) に、AttributeAdd/Remove 通知が送信されませんでした。 そのため特定のデプロイメントが適切に実行されていませんでした。 現在 WebLogic Server では AttributeChange 通知に加えて、配列型の属性値が変更されたときに AttributeAdd/Remove 通知が送信されるようになっています。
CR108496	コンソールで EJB デプロイメント記述子を編集すると、デプロイされた EJB jar ファイルで <global/> タグが <global>true</global> に変更されていました。 getGlobalRole メソッドの空のタグが追加され、永続化後も検証が失敗しなくなりました。
CR126191	weblogic.Admin ツールで DESTROY_POOL コマンドを使用した場合、単にすべてのユーザの接続が切断されてプールがサスペンド状態になるだけでした。 ドメイン コンフィグレーションからプールが削除されるはずでしたが、実際にはそうではありませんでした。 DESTROY_POOL により、プールのコンフィグレーションが削除されるようになりました。 プールをサスペンドするには、DISABLE_POOL または SUSPEND を使用してください。
CR134167	EXISTS_POOL が予期されたとおりに機能していませんでした。 このコマンドの検索対象は実行時 MBean でしたが、これは、プールが存在している場合であっても、存在したりしなかったりする MBean でした。 文書化されていないコマンド DELETE_POOL は、接続プールを削除するための内部実装ですが、この機能が外部的には DESTROY_POOL として文書化されていました。 またヘルプ メニューにも、いくつか文書化されていないコマンドについての表示がありました。 EXISTS_POOL コマンドの実装は、プールの存在確認の検索対象としてコンフィグレーション MBean を使用するようになりました。 DESTROY_POOL コマンドは、基底の DELETE_POOL 実装を利用するようになりました。 weblogic.Admin のヘルプ メニューに表示されていたコマンドで、文書化されていないものは、現在すべて無効化されています。 無効化されたコマンドは、TEST_POOL、REMOVE_POOL、SUSPEND_POOL、SHUTDOWN_POOL、RESUME_POOL、DELETE_POOL などです。 これらのコマンドは今後サポートされなくなり、7.0 SP5 では機能しなくなる予定です。 ヘルプ メニューにも表示されなくなっています。
CR171906、CR179030、CR208205	Operator ロールに属するユーザによって管理対象サーバが実行されている場合に、管理サーバが起動しませんでした。 Operator ロールのユーザに対し、管理サーバの再起動および管理対象サーバへの再接続の操作が許可されました。 その結果、現在では Operator ロールに属するユーザによって管理対象サーバが実行されていても、管理サーバを起動できるようになっています。
CR179524、R203851、CR213673	サーバが実行されているにも関わらずサーバ ログをエディタまたはビューアで開いていると、ログがフリーズしました。これは、サーバがログ ローテーションの最中またはその後に、ログの記録のためにログ ファイルを再度開くことができなかったためでした。 ロガーに再試行ロジックを実装し、最初の試行が失敗した場合には代わりのログ ファイルへのローテーションが試行されるようにしたため、すべての試行が失敗してもログの記録が続行されるようになりました。
CR177510 CR135356	大きな EAR ファイル (600MB) の一部であるモジュールの追加または再デプロイには、非常に長い時間がかかっていました。 Web アプリケーション モジュールのコードを変更した結果、パフォーマンスが向上しました。 現在、Web アプリケーション モジュールでは、モジュール全体を変更するような差分のある場合にモジュールの更新が考慮されるようになっています。 大きなアプリケーションをデプロイしたときの起動時間を短縮するため、コンフィグレーションされているアプリケーションのステージングされた Targets 属性を保持するように、デプロイメント方法が変更されました。 アプリケーションのデプロイメント中に発生する、管理サーバおよび管理対象サーバ間のリモート呼び出しのトラフィックが低減されました。
CR182686	起動クラスまたはサーブレットでシステム プロパティを設定しているときに、ConcurrentModificationException が送出されることがありました。 プロパティの同期をとるように変更した結果、システム プロパティの設定時に ConcurrentModificationException が送出されることはなくなりました。
CR184787	Administration Console において、デプロイメント記述子のセッション パラメータに関するページで、PersistentStoreType の「replicated_if_clustered」値が表示されませんでした。 結果として記述子が永続化されたときに、その記述子に違う値が設定されていました。 Administration Console でこの値が表示され、正しく記述子に追加されるようになりました。
CR187170	配列型の属性が変更されたとき (配列の要素が追加または削除されたとき) に、AttributeAdd/Remove 通知が送信されませんでした。 そのため特定のデプロイメントが適切に実行されていませんでした。 現在 WebLogic Server では AttributeChange 通知に加えて、配列型の属性値が変更されたときに AttributeAdd/Remove 通知が送信されるようになっています。
CR190237	WebLogic Portal 環境で実行する場合に WebLogic Server MbeanHome の getAllMBeans() メソッドが例外を送出していました。 WebLogic Server MBeanHome Helper では WebLogic Portal MBean クラスの場所を示す追加情報が必要であり、既存のロジックを修正する必要がありました。 WebLogic Portal 環境で ClassNotFound 例外が送出されなくなりました。
CR188701	管理サーバが停止しているときに管理対象サーバを再起動すると、デプロイメントに失敗していました。 サーバによりアプリケーションがステージングされる際に、そのデプロイ対象であるアプリケーションにステージング モードのセットがない場合、誤ったステージング モードが使用されていました。 ステージング モードのセットを持たないが、ステージング モード セットを使用してデプロイされるアプリケーションについても、正しいステージング モードで適切にデプロイメントされるようになりました。
CR190822	JDBC 接続プールのクローン作成処理が機能していませんでした。 サーバが対象とされている場合にも、JDBC 接続プールのクローン作成処理が機能するようになりました。
CR200310	MSI モードで実行すると、アプリケーション マネージャが 2 度起動されていました。 MSI モードで実行しても、アプリケーション マネージャが 1 度だけ起動するようになりました。
CR135521	Commo MBean を作成または削除する際に、IllegalArgumentException が送出されなくなりました。 現在では、タイプが null の場合には InstanceNotFoundException が送出されます。 wlconfig などのクライアントでこの例外が捕捉され、JMX MBean Home を使用して MBean の属性値が取得されます。
CR182072	config.xml ファイルの ConfigurationVersion 属性の値が、サービス パックの更新後に変更されるようになりました。 現在、この属性は、サーバが起動されるたびに管理サーバと同じバージョンに設定されます。
CR100218	ExecuteQueueMBean.setThreadPriority() の値はユーザからコンフィグレーションできないため、パブリック javadoc から削除されました。
CR109591	Administration Console で 'myserver_%yyyy%_%MM%_%dd%_%hh%_%mm%.log というログの場所を見つけられませんでした。 この問題を修正するため、現在では次のような形式をもとにファイル名の検索を試行するようになっています。 myserver_yyyy_MM_dd_hh_mm.log 次に示す形式は使用されません。 myserver_%yyyy%_%MM%_%dd%_%hh%_%mm%.log myserver_yyyy_MM_dd_hh_mm.log 形式を使用してもファイル名を検索できない場合には、FileNotFoundException が送出されます。
CR124169	JMX を使用して MessagingBridge を停止またはアンデプロイするときに、アサーション エラーが送出されることはなくなりました。
CR202449	管理サーバ上にサーバ インスタンスが作成される際に、そのデフォルト キューが管理サーバの再初期化時まで初期化されていませんでした。 サーバ インスタンスの作成時またはクローン作成時に、デフォルト キューが初期化されるようになりました。
CR208697	removeNotification() を呼び出して複数の中間要素を削除するときに、WebLogic Server では notificationID 変数がデクリメントされていました。 その後に allNotification[] の最後の要素に対してアクセスが試行されると、 InstanceNotFoundException が送出されていました。 notificationID 変数の値が allNotification[] のサイズよりも小さくなっていたため、結果として最後の要素に対するアクセスが不可能でした。 コードの変更によりこの問題は修正され、removeNotification() が呼び出されたときに ArrayOutOfBoundException が送出されなくなりました。さらに、InstanceNotFoundException は通知インスタンスが利用不可能な場合にのみ送出されるようになりました。 したがって、allNotification[] の最後の要素に対してアクセスが試行された場合に、InstanceNotFoundException が送出されることはなくなりました。
CR211194	XA 呼び出し手順 XA.end (TMSUSPEND) に続いて XA.rollback が呼び出された場合に、MQSeries でメモリ リークが発生することはなくなりました。
CR211815	MBean の登録解除プロセスで使用されるロックのシーケンスは、デッドロックを回避するために修正されるようになりました。

プラグイン

変更要求番号	説明
CR095984	NSAPI プラグインの使用時にファイル サイズが 30KB を超えたとき、413 メッセージではなく、IE 6.0 の DNS エラー メッセージが受信されていました。 MaxPostSize コンフィグレーションの動作が、プラグインを使用しているかどうかに関わらず同じになりました。
CR100070	プラグインが処理するすべてのリクエストに対してデバッグの有効化または無効化を決定するグローバル デバッグ フラグが 1 つしかなかったため、Apache-WLS プラグイン内の各仮想ホストの WLLogFile を管理するのは困難でした。 デバッグ オプションを一番上のレベルで指定し、各仮想ホストまたは location タグの内部で上書きできるようになりました。
CR136968	WebLogic Server では、response.addHeader メソッドが使用される場合に複数のヘッダを受け付けていませんでした。 プラグインで WWW 認証の際に複数の値が許可されるようになりました。
CR171978	iisforward.ini ファイルで FilterPriorityLevel が設定されている場合に、転送パスが途切れていました。 修正コードの実装により、iisforward.ini ファイルで仮想ホストが定義されていない場合は、iisforward.dll ファイルのロード先と同じ場所にある iisproxy.ini ファイルが使用されるようになりました。
CR172072	WLExcludePathOrMimeType パラメータの機能が拡張され、Location タグ レベルでの使用が可能になりました。 現在 WLExcludePathOrMimeType パラメータは、グローバルで定義するだけでなく、Location タグ レベルでローカルにも定義できます。 このプロパティをローカルに定義しても、グローバル プロパティはオーバーライドされませんが、2 つのパラメータの結合が定義されることになります。
CR173581、CR173878	プラグインにより、クライアントが接続を閉じている場合にも、「error page is unavailable」という紛らわしいログ メッセージが apache error.log に記録されていました。 この誤ったログ メッセージをコメント アウトするようにコードを変更することで、この問題は解決しました。
CR174431	Iplanet プラグインが EINTR OS エラーを正常に処理するようになりました。
CR175672	Apache サーバは、WebLogic プラグインが wlproxy ログ ファイルを開こうとすると、Debug が OFF に設定されている場合にもハングしていました。 デバッグが無効になっている場合はログ ファイルが設定されないように、コードが修正されました。
CR175989	prefork オプション (マルチプロセスのみ) ではなく worker オプション (マルチスレッド) を使用している場合に、Apache サーバではコアダンプが生成されていました。 ロックおよびロック解除のロジックを修正することで、この問題は解決されました。
CR177707	リリース 7.0 SP02 のプラグインとクライアント証明書を一緒に使用した場合、WebLogic Server は正常に動作していました。 しかし、リリース 7.0 SP06 へのアップグレード後、サーバ ログに以下のエラーが報告されました。 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 このエラーは、7.0 SP06 プラグインがサーバ インスタンスへの送信時に WL-Proxy-Client-Cert ヘッダを切り詰めていたために発生していました。 WebLogic Server に送信されるリクエストに WL-Proxy-Client-Cert が切り詰められていない状態で追加されるように、コードを変更しました。
CR179537	Microsoft Windows プラットフォームで、IIS プロキシ プラグインによりヒープの破損が発生していました。 この問題は、内部コードを修正することで解決しました。
CR180236	7.0 の以前のリリースのプラグインとクライアント証明書を一緒に使用した場合、以下のエラーが報告されていました。 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 ヘッダを切り詰めていたために発生していました。 この問題は、コードを修正することで解決しました。
CR178792	HTTP リクエストには Content-Length または Transfer-Encoding のいずれかのヘッダを指定できます。 Transfer-Encoding ヘッダを「chunked」に設定したリクエストが IO エラーで失敗していました。 Transfer-Encoding ヘッダを「chunked」に設定したリクエストをサポートするコードが追加されました。
CR180560	WebLogic Server に対する新しい接続の作成時に、プラグインではソケットの情報 (localhost:localport remotehost:remoteport) をログ ファイルに出力していませんでした。 プラグインによって WebLogic Server に対する新しい接続が作成されるときに、ローカル ホスト名とローカル ポート番号を伴ったログ メッセージが追加されるようになりました。
CR180417	POST データにクッキーが含まれている場合、クッキーの抽出中にプラグインによって POST データが破損されていました。 POST データからのクッキー抽出を修正するコードを追加しました。
CR180724	最初のクッキーが Web サーバ 1 から作成されてクラスタ 1 に送信されたとします。 そのクッキーが再びアプリケーションにヒットした場合、クッキーが Web サーバ 2 に送られ、クラスタ 1 ではなくクラスタ 2 に送信されて、新しいセッションが作成されていました。 現在の WebLogic Server では WLCrossOverEnabled 機能が正しく動作するようになっています。
CR182434	rq->srvhdrs に渡されたヘッダが、完全に小文字になっておらず、大文字と小文字が混在した状態でした。 Content-type、content-length および transfer-encoding ヘッダは現在、完全に小文字で NSAPI に渡されるようになっています。
CR182971	DNSRefreshInterval ごとに ServerList が削除されていたため、コア ダンプが発生していました。 リスト内のすべてのサーバについて DNS ルックアップが行われ、最後にチェックした後に変更されたサーバがあった場合に、ServerInfo の構造が更新されるようになりました。
CR183188	ISAPI プラグインでは Transfer-Encoding ヘッダが chunked に設定されているリクエストを処理できませんでした。 機能の追加により、ISAPI でそのようなリクエストを処理できるようになりました。
CR183311	シングルスレッド マルチプロセス モジュールを使用しているときに Apache が停止する場合、最初にタイマー スレッドの停止が試行されていました。 このタイマー スレッドは存在していないため、コア ダンプが発生していました。 Apache がシングルスレッド マルチプロセス モジュールと共に使用されている場合に、タイマー スレッドが作成されなくなりました。
CR183390	WebLogic Server では例外を catch ブロックの中から送出しており、そのために iPlanet が失敗することがありました。 例外は catch ブロックから送出されなくなりました。
CR185089	IIS プラグインでは、クライアントが接続を閉じたために WRITE_ERROR_TO_CLIENT 例外が発生すると、HTTP ステータス コード 500 (内部サーバ エラー) を送信していました。 WRITE_ERROR_TO_CLIENT 例外が捕捉された場合にも、IIS プラグインから HTTP ステータス コード 500 が送信されなくなりました。
CR185668	Apache プラグインを使用し、MatchExpression を使用して複数のクラスタにプロキシする場合、リクエストの転送に使用される URL のセグメントが PathTrim 属性によって削除されていませんでした。 strtok API を使用しないで MatchExpression 解析を実装しなおすことで、この問題は修正されました。
CR186148	Apache プラグインではページが見つからなかったときに、適切に 503 エラーを返すのでなく、500 エラーを返していました。 プラグインから適切なエラーが返されるようになりました。
CR186470	IIS プラグインを使用しているときに、ファイアウォールを介して多数の新しい接続を作成すると、HTTP ステータス 302 が発生し、接続が閉じていました。 HTTP ステータス コードが 302 の場合に、接続が再利用されるようになりました。
CR187282	HTTP 1.1 仕様では、リクエストまたは応答に Content-Length ヘッダと Transfer-Encoding: Chunked ヘッダの両方が含まれている場合、Content-Length ヘッダを無視する必要があると規定されています。プラグインがこの規定にしたがっていなかったため、プールの接続の再利用を伴う特定のシナリオで、エラーが発生することがありました。 CTE が有効になっている場合、contentLength が -1 として返されるようになりました。
CR187577	VirtualHost タグで複数の Location タグが使用されている場合、リクエストに一致する場所が複数あると、Apache プラグインでは誤った URL が生成されていました。 指定されない限り、Apache プラグインで正規表現マッチングが使用されなくなりました。
CR187578	httpd.conf で KeepAliveEnabled をオンにコンフィグレーションすると、KeepAliveSecs はデフォルトで 20 に設定され、 このデフォルト設定を変更することはできませんでした。 コードの追加により、KeepAliveSecs がコンフィグレーション可能になりました。
CR188811	リクエストにクエリ文字列がある場合、WLExcludePathOrMimeType が正しく機能しませんでした。 http://webserver:port/weblogic/something.jsp?value=123 のようなリクエストが除外されず、http://webserver:port/weblogic/something.do?name=test.jsp のようなリクエストが転送されませんでした。 プラグインで、除外のチェックをするときにクエリ文字列が無視されるようになりました。
CR189251	負荷がかかっている状況で、仮想ホストのプラグイン プロパティを取得しているときに、セグメンテーション エラーが発生していました。 strtok API はスレッドセーフではないため、strtok API を strchr で置き換えることでエラーを解消しました。
CR190562	Solaris 上で、WebLogic Server に post データを送信しているときに、プラグインで破損パイプ エラーが発生すると、リクエストが再試行されませんでした。 Solaris 上で sendPostData によりパイプの破損が報告された場合、HALF_OPEN_SOCKET_RETRY 例外が送出されるようになりました。
CR189933	WebLogic Server プラグインはスレッド セーフではありませんでした。 SrvrInfo 配列のメモリ アドレスとそのサイズが他のスレッドにも渡されており、他のスレッドで修正することが可能でした。 他のスレッドで修正された場合、最初のスレッドは無効なメモリ位置にアクセスすることになり、セグメント エラーが発生するおそれがありました。 WebLogic Server プラグインがスレッド セーフになり、 さらに WebLogic Server によって、他のスレッドに渡す前に SrvrInfo 配列の読み込み専用コピーが作成されるようになりました。
CR191552	非推奨になったプロパティ MaxSkips が MaxSkipTime に置き換えられていました。 しかし、この新しいプロパティはコード全体で使用されていなかったため、 MaxSkipTime パラメータのデフォルト値 10 を変更できませんでした。 MaxSkipTime がコード全体で使用されるようになり、この値を変更できるようになりました。
CR192875	readPostDataIntoFile() の try/catch ブロックから新しい例外が送出された場合に、iPlanet サーバがクラッシュしていました。 readPostDataIntoFile() が、一時ファイルへの post データの書き込み中にエラーに遭遇した場合、例外を送出するのではなく、例外を返すようになったため、この問題は発生しなくなりました。
CR193447	クッキーに、提示されたプライマリとセカンダリの情報を分ける区切り記号「|」が含まれていませんでした。 その結果、parseJVMID() で常にプライマリ サーバの情報が返され、セカンダリ サーバの情報が無視されていました。 プライマリとセカンダリの情報を分けるためにクッキーがトークン化され、抽出された両方の値に対して parseJVMID() を呼び出すように修正されました。 これにより、parseJVMID() でプライマリ サーバとセカンダリ サーバの両方の情報が返されるようになりました。
CR193985	「creating timer thread in child」メッセージが、ログ レベル [warn] で記録されていました。 これらのメッセージがログ レベル [info] で記録されるように修正され、メッセージの本質をより的確に反映するようになりました。
CR194141	getRequestURI が戻り値をデコードすべきでないことを示している場合にも、Apache プラグインが WebLogic Server にリクエストを渡す前に URI をデコードしていました。 Apache プラグインが、URI をはじめにデコードせずに WebLogic Server に渡すように修正されました。
CR194464	内部の initJVMID() の呼び出しでは、接続が拒否された場合にもサーバの状態が GOOD から BAD に更新されていませんでした。 その結果、すでに停止しているサーバにアクセスしようとして時間が浪費されていました。 サーバがすでに BAD とマークされている場合には、initJVMID() がそのサーバをスキップして次のサーバに移るよう修正されました。 また、接続が拒否された場合に、initJVMID() がサーバの状態を更新するようになりました。
CR199045	SSL および非 SSL コンフィグレーションを使用してさまざまなパス値が複数のオブジェクト タグでコンフィグレーションされていると、プラグインが SSL リクエストと非 SSL リクエストを正しく切り替えられませんでした。 グローバル フラグ (convertDNSSToIP) をリクエストごとのフラグ (ConfigInfo 構造内に移動) で置き換えたことで、プラグインが SSL リクエストと非 SSL リクエストを正しく切り替えられるようになりました。
CR201736	ISAPI プラグインを使用している場合に、WL-Proxy-SSL ヘッダが欠落しないようになりました。
CR199446	Apache プラグインでは、Location タグと LocationMatch タグで正規表現がサポートされていませんでした。 Apache プラグインで POSIX 正規表現がサポートされるようになりました。 次のような Location タグは、今後は無効です。 <Location */app/*> ... </Location> このタグは、次のように変更する必要があります。 <Location /app/> ... </Location> 以下に、Location タグで一般的に使用するエントリについて示します。 リクエストが特定のパスに一致する場合 : /app/* これは、次のように変更する必要があります。 /app/ リクエストが特定のパスで始まる場合 : /app/* これは、次のように変更する必要があります。 ^/app/ リクエストが特定の MIME タイプに一致する場合 : */*.jsp これは、次のように変更する必要があります。 ¥.jsp
CR199668	ホスト名のマッチングで大文字と小文字が区別されていたため、ホスト検索時に「HostName」と「hostname」がマッチングしませんでした。 iisforward.ini を使用したプロキシのホスト検索で大文字と小文字が区別されなくなりました。 これにより、ホスト名のマッチングでも、大文字と小文字が区別されなくなりました。
CR202898	Apache プラグインに HEAD リクエストが送信された場合に、HttpResponse のヘッダから Content-Length ヘッダが欠落しなくなり、Content-Type ヘッダが壊れることもなくなりました。
CR205009	ルート ユーザが Apache プラグイン (リビジョン 158) を起動すると、コア ダンプが発生する問題が修正されました。
CR209778	ConnectRetrySecs で、カスタム値がコンフィグレーション ファイルで指定したとおりに使用されるようにコードが修正されました。 現在 ConnectRetrySecs は、Apache と正しく連携するようになっています。
CR209383	FileCaching が OFF に設定されているにもかかわらず、POST データがチャンク化される問題が解決しました。
CR207694	リクエスト中に「Expect: continue-100」が見つかった場合、「HTTP/1.1 100 Continue」が NSAPI による応答の本文ではなくヘッダに格納されるようになりました。
CR205760	リクエストの読み込み中に INSUFFICIENT_BUFFER エラーが送出された場合、新しいメモリが割り当てられましたが、 メソッド内でこのメモリが解放された後に、このメモリに対するアクセスが行われていました。 メモリの解放がルーチンの最後に行われるように修正されました。
CR199080	プラグインが WebLogic Server への接続に失敗した場合、GETLASTERROR がログに記録されるようになりました。 また、プラグインが WebLogic Server に接続している間に発生したすべてのエラーについても、ログ メッセージとして記録されます。
CR128730	HttpClusterServlet が再利用された接続を使用してリクエストをプライマリに送信する場合、HttpClusterServlet は接続にエラーがあるかどうかについて、再接続が可能な時間内に判断できませんでした。 その結果、HttpClusterServlet はセカンダリへのフェイル オーバーを行っていませんでした。 HttpClusterServlet で、リクエストが正常にプライマリに送信されたかどうかのチェックが行われるようになりました。 さらに、プライマリへのリクエストが正常に送信されず、かつ使用した接続が再利用されたものだった場合、HttpClusterServlet はプライマリに対して新しい接続の作成を試行するようになりました。 後続のリクエストも失敗して例外が送出された場合には、HttpClusterServlet によってセカンダリへのフェイル オーバーが行われます。
CR208303	AIX では、errno 変数がスレッド セーフではありませんでした。 errno 変数をスレッド セーフにするため、Makefile.aix に -D_THREAD_SAFE が追加されました。
CR218680	リクエストごとに、HTTP ステータス コードが正しく設定されるようになりました。

RMI

変更要求番号	説明
CR177353	アプリケーション クライアントのコードで、リモート スタブをキャッシュし、クラスタにデプロイされているステートレス セッション Bean のリモート メソッドを呼び出す場合、リモート オブジェクトが使用可能であるクラスタ ノードを追跡したリストが、呼び出しのたびにリフレッシュされていました。 このリストは、いずれかのノードが回復可能な例外で失敗した場合に、呼び出しをフェイルオーバするために使用されていました。 ここで問題になっていたのは、アプリケーション クライアントが以前の呼び出しでスタブをキャッシュしていて、クラスタ全体が再起動された場合に、フェイルオーバが動作しないということでした。 フェイルオーバの再試行ロジックが適切ではありませんでした。 元のロジックでは n 個のノードを持つクラスタで n-1 の再試行回数を許可していましたが、 クラスタ全体を再起動したときキャッシュ済みのスタブは古いリストを保持している状態で、 古いリストを調べているうちに、すべての再試行回数が消費されていました。 そしてその上で、ロジックの最後の試行でリストのリフレッシュが行われる場合がありました。 たとえクライアント サイド スタブにリストの新しいコピーがあっても、既に n-1 回の試行制限に達しているため、フェイルオーバが行われることはありませんでした。 アプリケーション クライアントにキャッシュされたリモート スタブが、既存のリストにあるすべてのノードでリモート メソッド呼び出しが失敗した場合にのみ、リストをリフレッシュするようになりました。 また、リストがリフレッシュされた場合、スタブには最後に 1 度フェイルオーバの機会が与えられ、 これに失敗した場合にはスタブからアプリケーションに例外が送出され、失敗しなかった場合にはフェイルオーバが透過的に動作し続けるように修正されています。
CR188748	ゲッターおよびセッター操作でリポジトリ ID を生成するときに、ゲッターまたはセッターに予約されたキーワードが含まれていると余分な「_」が追加されることがあり、 それによってリモート呼び出しが失敗することがありました。 余分なアンダースコアを削除するように修正されました。
CR197396	サーバ インスタンスがクライアントへの IIOP (発信) 応答のために addIndirection を呼び出す間に、マシンに搭載されている CPU の使用率が 100 % に達することがなくなりました。 その結果、パフォーマンスが向上しています。
CR197824	WebSphere 5.1 から WebLogic server に対して EJB 呼び出しが試行されるときにデータとして HashMap が使用されていると、WebLogic server から UNMARSHAL 例外が送出されていました。 この問題を解決するため、WebLogic Server で外部サービス コンテキストが適切に処理されるようになりました。

サンプル

変更要求番号	説明
CR132509	MedRec アプリケーションに含まれている .NET C# サンプル (%WEBLOGIC_HOME%¥samples¥server¥medrec¥src¥clients¥CSharpClient¥bin¥ReleaseCSharpClient.exe) を使用した場合、クライアントで患者のレコードは正常に取得されていましたが、クライアント アプリケーションから「Save Changes」を行おうとすると、日付フィールド エラーが示されました。 コードの変更により日付の検証が修正されました。
CR133641	iPlanet を使用している場合に、ホスト名検証で問題が発生して、以下のメッセージが受信されていました。 INFO: Host () doesn't match (), validation failed ERROR: SSLWrite failed コードを修正してこの問題は解決されました。

Security

変更要求番号	説明
CR121646	クライアント証明書が Extended Key Usage を critical に設定した状態で WebLogic Server に送信されると、BAD_CERTIFICATE エラーが受信され、SSL 接続が終了していました。 EnhancedKeyUsage を追加サポートすることで、この問題は解決されました。 現在 WebLogic Server では Enhanced Keyusage を critical に設定した状態のクライアント証明書が受け付けられるようになっています。
CR126837	iPlanetAuthenticator MBean で使用される listGroupMembers 実装を介して、ユーザのリストを取得する場合に問題がありました。 具体的には、listGroupMembers() メソッドが空のカーソルを返していました。 StaticMemberDNAttribute のデフォルト値を「uniquemember」に変更することで、この問題は解決しました。
CR137523	ファイル レルムが refresh() メソッドを呼び出しているときにユーザを定義すると、同期化の問題が発生してユーザ テーブルが壊れていました。 ファイル レルムがリフレッシュを実行している間にユーザを定義した場合にも例外が発生されることのないように、ファイル レルムの機能が向上しました。
CR180972	WebLogic Server では送信リクエストごとに新しい SSLSocketFactory を作成していたため、発信 SSL 接続のパフォーマンスが JSSE と比べて低速化していました。 リクエストに証明書がない場合には、SSLSocketFactory がキャッシュされるようになりました。
CR182860、CR187047、CR194416、CR214190、CR214191、CR214192	Web ブラウザからセキュア ポートを介してプレーン テキストを送信した場合に、SSL がメッセージ ヘッダを誤って解釈し、メッセージの終了前にさらにデータがあるとして待機していました。 この遅延により、SSL ハンドシェーク機能に問題が発生していました。 SSL ハンドシェークを完了しようとしてサーバで CPU が使用され、その使用率が 100 % に達していました。 この問題の原因は、読み込まれたバイト数についての演算エラーでした。 この演算上の問題は修正されました。 現在では、セキュア ポートに対してプレーン テキストのメッセージを送信しようとした場合、クライアントはより早い段階でエラーを受け取るようになり、CPU 使用率が 100 % に達することによるサーバのハングは発生しなくなりました。
CR185438	WebLogic Server と外部 LDAP サーバとの間に、ロード バランサまたはファイア ウォールがコンフィグレーションされている場合、外部 LDAP サーバへの接続が切断されることがありました。 接続が切断された場合に WebLogic Server によって自動的に接続がリフレッシュされるように修正され、ユーザ リクエストの処理中に接続が切断した場合にも、そのリクエストが完了するようになりました。
CR186916	SubjectUtils.isUserInGroup には 2 つの点で問題がありました。 特定のクラスのプリンシパルのみを取得するには、各プリンシパルを評価しながらプリンシパルのセットを作成した後、そのプリンシパルのセットを検索して、あるプリンシパルが検索対象のグループに属しているかどうかを調べる必要がありました。 ここでは事実上、プリンシパルに対して 2 つの検索が行われていました。1 つはサブジェクトのすべてのプリンシパルを取得するための検索、もう 1 つはグループ名に関する検索です。 javax.security.auth.Subject インタフェースから AuthenticatedSubject を取得して、サブジェクトがグループ内にあるかどうかを検索しようとしても、そのサブジェクトが認証されていない限りできませんでした。 つまり、サブジェクトを認証してから、サブジェクトが属しているグループを判別するという追加のサイクルが必要でした。 解決策 : 現在は、すべてのプリンシパルをサブジェクトから取得し、指定された WLSGroup を調べるために 1 回だけ検索をするようになりました。 さらに、第 1 パラメータとして AuthenticatedSubject を取る 2 つ目のメソッドが追加され、 それら両方のパブリックな isUserInGroup () メソッドが、サブジェクトではなくプリンシパルのセットを使用する内部的な isUserInGroup () メソッドを呼び出すように変更されています。 このメソッドを使用することで、サブジェクトから AuthenticatedSubject に変換する必要がなくなります。
CR136414	WebLogic Server では、VeriSign の証明書を使用しているサイトへの HTTPS URL 接続との間に SSL ハンドシェークを成立できませんでした。 この問題は修正されています。
CR161839	TTL キャッシュ内での同期が適切に処理されなかったために、ArrayIndexOutofbounds 例外が発生していました。 TTL キャッシュに同期化処理を追加したことで、この問題は解決されました。
CR177647	特定のケースで、双方向の SSL 通信を確立するために、サーバの証明書がクライアントの証明書として使用されていました。 コードの変更により、この問題は修正されました。
CR186439	単一のクラスタを含むドメインを Administration Console を介して起動した場合に、LDAP サーバのロック メカニズムが正しく機能するようになりました。 その結果、管理対象サーバが起動中にハングすることはなくなりました。
CR189238	認証のために ServletAuthentication.weak を使用している場合、ユーザ名とパスワードを入力した時点で NoSuchElement 例外が送出されました。 この問題を解決するために、要素を返す前にサイズをチェックするように InvalidLogin を変更しました。
CR194315	ファイル レルムのリフレッシュにより NullPointer 例外が発生する可能性がありました。 コードの変更により、この問題は解決されました。 今後は、ファイル レルムがリフレッシュされても NullPointer 例外が発生することはありません。
CR178854	WebLogic Server 7.0 の以前のサービス パックに同梱されていたデモ用証明書および信頼性のある CA 証明書の中に、2004 年 5 月 14 日で期限の切れているものや Basic Constraints 機能と連携しないものがありました。 WebLogic Server 7.0 サービス パック 2 には、Basic Constraints 機能と連携する、更新済みの信頼性のある CA 証明書が含まれており、 それらの証明書 (democert.pem、democert1024.pem ca.pem、ca1024.pem、trusted.crt、demo.crt) はファイルとして提供されています。 WebLogic Server 7.0 の以前のサービス パックを使用していて、信頼性のある CA 証明書が期限切れだったり、Basic Constraints 機能と連携しないデモ用証明書が含まれていたりする場合には、http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp で詳細について参照してください。
CR189285	iPlanet LDAP 認証プロバイダを使用する場合、WebLogic Server には iPlanet LDAP サーバへの接続のプールが保持されます。 プールされている接続は、実際には Big IP への接続であり、 Big IP では定期的にアイドル接続を閉じるようにコンフィグレーションされています。 そのため、WebLogic Server から iPlanet LDAP サーバに対してクエリまたはコマンドを発行した場合に、その iPlanet LDAP サーバへの接続が Big IP によって閉じられていることがありました。 その場合にも、この問題を説明する例外が送出されていませんでした。 iPlanet LDAP サーバへの接続に問題がある場合、その LDAP サーバから例外が送出されて Web 層に伝播されるように修正されました。 その結果、WebLogic Server からも適切な情報を含む例外メッセージが送出されるようになっています。
CR205373	LDAP 接続プール内に無効な接続がある場合、ユーザの認証が失敗して LoginException が返されていました。 接続プールの既存の LDAP 接続を使用したログインが失敗した場合、プール内に新しい接続が作成されて、その接続が使用されるようになりました。 その結果、LDAP 接続のタイムアウトによってユーザのリクエストが失敗することはなくなりました。
CR210229	ServletAuthentication.weak() メソッドの呼び出しで、EmptyStack 例外が発生することはなくなりました。
CR194073	現在、WebLogic Server は critical とマークされた場合にのみ extendedkeyusage 拡張を処理します。 その結果、双方向 SSL 通信中にサーバ サイドで BAD_CERTIFICATE 例外は送出されなくなりました。
CR045135	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-65.00.jsp のセキュリティ勧告を参照してください。
CR125592 CR196597	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-66.00.jsp のセキュリティ勧告を参照してください。
CR127930 CR107359	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_51.00.jsp のセキュリティ勧告を参照してください。
CR128940	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp のセキュリティ勧告を参照してください。
CR157157	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-71.00.jsp のセキュリティ勧告を参照してください。
CR171885	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_59.00.jsp のセキュリティ勧告を参照してください。
CR172187	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-69.00.jsp のセキュリティ勧告を参照してください。
CR175310	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_64.00.jsp のセキュリティ勧告を参照してください。
CR175966	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-72.00.jsp のセキュリティ勧告を参照してください。
CR128940	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-67.00.jsp のセキュリティ勧告を参照してください。

サーブレット

変更要求番号	説明
CR120545	weblogic-applicaiton.xml にカスタム xml パーサをコンフィグレーションしているときに、Null Pointer 例外が送出されることはなくなりました。
CR121297	エラー ページが適切なユーザに転送されるように修正されました。
CR112793	クライアントで接続が切断された場合、WebLogic Server ではその後、リクエストが処理されていませんでした。 WebLogic Server にシステム プロパティ ProxyForConnectionResets が追加されました。 このプロパティはデフォルトで false に設定されています。 ProxyForConnectionResets を true に設定すると、処理中にクライアントによって接続が切断された場合にも、HttpClusterServlet によるリクエストの処理が続行されます。 結果として、クライアントで接続が切断されてもリクエストが処理されるようになりました。
CR106348、CR125989	リスナの障害により、Web アプリケーションがアンデプロイされずに不安定な (デプロイされた) 状態のままになっていました。 リスナに障害があった場合 (デプロイメントが完全に成功しなかった場合)、Web アプリケーションのデプロイメントがロール バックされるようになりました。
CR134351	WebLogic Server の HttpURLConnection にデフォルトの読み取りタイムアウト値を設定するために、weblogic.http.client.defaultReadTimeout フラグが導入されました。 このフラグが設定されている場合、JVM 上に新しく作成される HttpURLConnection はすべてデフォルトでこの値を保持することになります。 この値は、特定の接続で setTimeout または setReadTimeout を呼び出すことでオーバーライド可能です。 このフラグを使用しない場合、デフォルトの値は -1 になります。値はミリ秒単位で指定する必要があります。
CR132447	部分文字列として SESSIONID 名を含むヘッダ内にクッキーが存在した場合、SESSIONID に予期しない変更が見られました。 クッキーのあるヘッダから SESSIONID を解析するロジックを修正した結果、この問題は解決しました。 今回の変更により、既存の SESSIONID または既存のセッションがある場合には、新しい SESSIONID が作成されなくなっています。
CR143448	サーブレット コンテナの内部呼び出しで java.lang.IllegalStateException: HttpSession is invalid 例外が発生します。 同じセッション ID を使用する他のスレッドが ServletRequestImpl.syncSession() の処理中にセッション オブジェクトを無効化すると、SessionData.putValue() または SessionData.isNew() の呼び出し時に IllegalStateException が発生する場合があります。 セッションが他のスレッドによって無効化されている場合には、IllegalStateException を無視するようにしてください。
CR128519、CR132321、CR130021	HttpProxyServlet の使用時にサーブレット フィルタからのラップされた応答が関与すると、ClassCastException が発生していました。 コードの修正により、応答ラッパーが使用されている場合に元の応答が取得されるようになりました。
CR175651	Struts ベースのアプリケーション内で RequestProcessor.getServletContext() メソッドを呼び出したときに、NullPointerException が送出されていました。 この問題を修正するために、WebLogic Server の起動スクリプト ファイルにシステム プロパティ weblogic.http.requestCompletionTimeoutSecs が追加されました。 このフラグに指定する値は、コンテナが処理中の作業をすべて終了する前に待機する秒数を示します。 デフォルトの値は 0 秒で、このフラグに設定をしない場合、コンテナは待機を行いません。 サーブレット コンテナは、どのような Web アプリケーションをデプロイまたはアンデプロイする前にも、このフラグに指定された秒数だけ待機します。
CR184726	転送されたリクエストをポストするクライアントで、weblogic.httpd.inputCharset が設定されている場合にパラメータが失われることはなくなりました。
CR176941	GenericProxyServlet.readStatus が断続的に失敗します。 この問題は、バックエンド サーバによってすでに閉じられた接続を GenericProxyServlet が再利用した場合に発生します。 オープン途中ソケット例外が発生して接続のヘッダがフィルタにより除去された場合に、同じリクエストが再試行されるようにコードを修正したことで、この問題は解決しました。
CR172672	WebLogic Server によってすでに閉じられている接続を HttpClusterServlet が再利用しようとすると、SocketException が捕捉され、WebLogic Server が BAD とマークされていました。 再利用された接続の使用時に、HttpClusterServlet が SocketException を捕捉した場合、新しい接続で改めて同じ WebLogic Server への接続が試行されるようになりました。
CR195698	external_stage 領域で古い WAR モジュールを新しいものに置き換えると、404 エラーが発生していました。 実際のアプリケーションを一時フォルダにステージングすることにより、この問題は解決されました。
CR200450	ブラウザから渡されるロケールのバリアントが原因で、Weblogic Server の検証ルールに予期しない結果が発生していました。 ロケールのヘッダを解析するロジックで、そのバリアント部分が考慮されていませんでした。 言語ヘッダの解析中にロケールのバリアントが考慮されるようになりました。 言語ヘッダは次のような形式になります。 lang-country-variant;q=weight
CR207481	受信 JSP リクエストの URI がフィルタ内で変換された場合に、Web コンテナで同じ変換済み URL に対して JSPStub が重複して生成され、結果としてメモリ リークが発生していました。 コードの変更によりこの問題は修正され、Web コンテナで重複する JSPStub が作成されることはなくなりました。
CR188237	HttpClusterServlet の使用時に HttpServletReponse オブジェクトでカスタム出力ストリームを使用する場合に発生していた問題が、解決されました。 現在、クライアントでは HttpServletReponse オブジェクト内でカスタム出力ストリームを使用できるようになっています。
CR172214	デフォルトの HttpServer から Web アプリケーションをアンデプロイする処理が、デフォルトの HttpServer にはデプロイされていない場合にも行われていました。 Web アプリケーションがデフォルトの HttpServer にデプロイされている場合にのみ、デフォルトの HttpServer からのアンデプロイ処理が行われるようになりました。
CR209387	Java クライアントで setTimeout() メソッドが使用されていて、Java クライアントから呼び出しを実行した場合、HTTPURLConnection が HTTP 呼び出しを (2 度ではなく) 1 度だけ実行するようになりました。
CR211410	ChunkUtils.is2chunk が無限ループでスタック状態に陥ることがなくなりました。 その結果、WebLogic Server のパフォーマンスが向上しました。
CR188953	weblogic.cache.filter.CacheFilter を使用してキャッシュされたページに対して複数のユーザがアクセスした場合に、JSP ページがハングすることがなくなりました。
CR129064	HTTP リクエストが iPlanet プラグイン経由で送信される場合に、誤って動的サーバ リストが WebLogic クラスタ 2 に設定されることはなくなりました。

Simple Network Management Protocol (SNMP)

変更要求番号	説明
CR109689、CR103678	サードパーティのコレクタ タスクを使用して SNMP 情報を収集した場合、以下のメッセージがログに記録されていました。 <Error> <SNMP Agent> <000000> < Unable to set Entry Field Value ...> 修正コードを実装して、この問題を解決しました。

Web サービス

変更要求番号	説明
CR127391	SOAP HTTP バインディングでは、Web サービス内部で例外が発生した場合、サーバは HTTP 500 「Internal Server Error」と、その例外を示す SOAP 障害応答を送出する必要があると規定されています。 多くの Web サービス クライアントでは Web サービスへの HttpConnection を作成するために URLConnection が使用されますが、 Weblogic Server では java.net.HttpURLConnection を異なるバージョンでオーバーライドしていました。 そして、ステータス コードが 400 以上の場合、WebLogic のバージョンで getInputStream メソッドから例外が送出されていました。 この例外が送出された後には、Web サービス クライアントが入力ストリームを取得する手段がなく、これは SOAP HTTP バインディングの仕様に違反していました。 500 エラー発生時に入力ストリームが取得されるように修正されました。
CR181695	autotype で継承が適切に処理されていませんでした。 types.xml ファイル内で、派生型が基底型を拡張していませんでした。 autotype に継承機能が追加され、継承が適切に処理されるようになりました。
CR182069	autotype に typeMappingFile を設定した場合、予期されるとおりに機能しませんでした。 この問題は修正され、 autotype で typeMappingFile から既存の型が取得されるようになりました。
CR175471 CR175536	外部 Web サービスに発信プロキシ サーバ (iPlanet Web プロキシ サーバ) を介してアクセスすると、SOAP 障害が返されていました。 この問題は、プロキシ認証が有効なプロキシ サーバを介したリモート Web サービスの呼び出しに、http および https を使用することが許可されていないために発生していました。 http および https がプロキシ サーバをトンネリングして Web サービス クライアントに到達できるように、コードが変更されました。
CR177611	autotype によって生成された型マッピング ファイルを servicegen で使用すると、web-service.xml 内でネームスペースの問題が発生していました。 servicegen で、autotype により生成された型マッピング ファイル内のネームスペースが認識されるようになりました。
CR183555	JAX-RPC クライアントで、SESSION_MAINTAIN_PROPERTY を使用してセッションを維持することができませんでした。 SESSION_MAINTAIN_PROPERTY が次のように設定されている場合に、セッションの維持がサポートされるようになりました。 呼び出し側オブジェクトの設定 : call.setProperty(Call.SESSION_MAINTAIN_PROPERTY, "true"); または call.setProperty(Call.SESSION_MAINTAIN_PROPERTY, new Boolean("true")); スタブ側オブジェクトの設定 : (Stub)port)._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, "true"); または (Stub)port)._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, new Boolean("true"));
CR186319	xml ファイル内に 32 個を超えて連続するスペースがある場合、ファイルの解析に長い時間がかかっていました。 バッファのサイズが拡大され、より効率的な xml ファイルの解析が可能になりました。
CR197698	クライアントサイドのパッチが原因で、Web サービスの HTTPS クライアントが java.net.UnknownHostException: null で失敗することはなくなりました。
CR185173	WebLogic Server 6.1.4 の動的クライアントから WebLogic Server 7.0.2 の Web サービスを呼び出して、VersionMaker ユーティリティを介して webserviceclient+ssl.jar ファイルを実行してから、変更された jar ファイルをWebLogic Server 6.1.x 環境で使用した場合に、 java.lang.NoClassDefFoundError が送出されなくなりました。

WLEC

変更要求番号	説明
CR121105	WLEC クライアントでは、WLEC 接続プールに関する以下の問題が発生していました。 Administration Console で ConnectionPool が適切に表示されない。 登録解除されたエンドポイントにより COMM_FAILURES が発生する。 これらの問題を解決するコード修正が実装され、WLEC 接続プールの全体的なパフォーマンスが向上しました。

WebLogic Tuxedo Connector

変更要求番号	説明
CR136608	WTC で Tuxedo に応答を送信する前には、XA.End を呼び出す必要があります。 しかし WTC では TP/TPA 呼び出しにおいて、XA.End を呼び出す前に、Tuxedo に応答を送信していました。 結果として競合状況が発生し、XA.End が呼び出される前に元のスレッドで XA.Start が開始される場合がありました。 成功した応答と失敗した応答のすべてのパスをクリーン アップし、Tuxedo へのどのような応答の前にも XA.end が呼び出されるようになりました。
CR172581	WebLogic Server 7.0 の次に示す WTC FML メソッドでは、WebLogic Server 8.1 で同じメソッドを実行した場合に比べてパフォーマンスが低下していました。 次のメソッドで低下が見られました。 TypedFML32._tmpostrecv() Fget() Foccurs() Fadd() これらのメソッドについて、WebLogic Server 7.0 sp6 の時点で WebLogic Server 8.1 からの移植が実施されました。
CR175113	スレッド不足により、スループットが低下していました。 WTC では受信するリクエストに対して、InboundEJBRequest 型のオブジェクトを生成する移植スレッドを生成し、さらにそのオブジェクトを実行するために別のスレッドを生成します。 そしてスレッドの実行は「デフォルト」実行キューから行われます。 InboundEJBRequest によって実行される EJB アプリケーションの処理速度が、入力リクエストが (リモート Tuxedo ドメインから) 到着する速度と比べて遅かった場合に、スレッド不足が発生することがあり、結果として、まずは「デフォルト」実行キューでバックログが発生し、続いて入力リクエストが失われていました。 処理速度の遅い EJB アプリケーションを、専用のスレッド プールで実行できるようになりました。 WTCService では、「weblogic.wtc.applicationQueue」という名前の実行キューが WTC アプリケーション実行のための専用キューとして認識されます。 このキューが事前にコンフィグレーションされていない場合、システム プロパティ weblogic.wtc.applicationQueueSize が設定されていることが分かれば、このキューは (WTC の起動時に) 明示的に作成されます。
CR177212	WTC リクエストに対して、NullPointerException が送出されていました。 WTC で StringBuffer を初期化する前に、Utilities.xdr_decode_string の戻り値がチェックされるようになりました。
CR179410	WTC で再接続の後に古い接続がクリーン アップされていませんでした。 Tuxedo ドメインと WTC は ON_STARTUP 接続ポリシーを使用して接続されます。 Tuxedo ドメインの実行されるマシンが停止していた場合、マシンの回復時に WTC で古い接続のクリーン アップが行われていませんでした。 同じリモート ドメインで新しい接続が受け取られた場合に、古い接続が切断されるようになりました。

XML

変更要求番号	説明
CR120545	weblogic-applicaiton.xml にカスタム xml パーサをコンフィグレーションしているときに、NullPointerException が送出されることがなくなりました。
CR135726	特定のスキーマ作成が処理されない場合は、SOAPElement にマップされます。 この問題の発生時には、サポートされていないスキーマ作成に遭遇したことが autotype では示されず、生成されたクラスを調べた場合にのみ何らかの処理に誤りがあることが示されていました。

 

---

WebLogic Server 7.0 サービス パック 5 のソリューション

以下の節では、WebLogic Server 7.0 サービス パック 5 (SP5) で解決された問題を説明します。ここで示す解決済みの問題のリストは、定期的に更新されます。

• Administration Console

• クラスローダ

• クラスタ

• コネクタ

• コア サーバ

• デプロイメント

• EJB

• JCOM

• JDBC

• jDriver

• JMS

• JSP

• JTA

• ノード マネージャ

• 操作と管理

• プラグイン

• RMI

• セキュリティ

• サーブレット

• SNMP (Simple Network Management Protocol)

• WebLogic Tuxedo Connector

• Web アプリケーション

• Web サービス

Administration Console

変更要求番号	説明
CR091775	Administration Console からディスパッチ ポリシーをコンフィグレーションできるようになりました。 この属性をコンフィグレーションするには、[Web アプリケーション記述子の編集] を選択して、新しいウィンドウで [weblogic-web-app] を選択します。 右側に [Dispatch Policy] 属性が表示されます。
CR126506	ユーザはコンソール拡張をコンフィグレーションして、ポリシー定義ページを置き換えることができませんでした。 転送前に拡張を検索するための CreateResourcesAction を有効にするコードが追加されました。
CR132700、CR135127、CR174568	GraphApplet の getParameter() メソッドは、最小または最大ヒープ サイズの値を取得するために使用されます。 WebLogic Server は Integer.parseInt を使用して文字列値を変換していましたが、数が 2G を超える場合はこの解析が失敗して、[モニタ｜パフォーマンス] タブの applet-weblogic.management.console.applets.GraphApplet に誤った値が表示されました。 WebLogic Server は Long.parseLong を使用して、2G を超える場合でもヒープの正しい値を取得するようになりました。
CR100745	Web アプリケーションのデプロイ タブで、アプリケーションが仮想ホストにデプロイされていることが表示される場合は正しく、仮想ホストの対象にデプロイされていることが表示される場合は正しくありませんでした。コードを変更してこの問題を解決しました。

クラスローダ

変更要求番号	説明
CR128510	MsgAbbrevInputStream の readClassDescriptor() はクラスを解決しようとしましたが、不明なクラスに関する ClassNotFoundException が発生しました。 対応するデータが読み込まれていない場合、Java シリアライゼーションはこの ClassNotFoundException をスキップしました。 現在、MsgAbbreveInputStream readClassDescriptor() はクラスを解決しなくなり、MsgAbbrevInputStream は resolveClass() を実装しています。
CR124348	クライアント プログラムは、プロキシ クラスがシステム クラスパスに追加されていないと、java.lang.reflect.Proxy を使用して、WebLogic Server にデプロイされたプロキシ オブジェクトにアクセスできませんでした。 オブジェクトがシステム クラスパスにない場合、クライアントは ClassNotFoundException を受け取りました。 システム クラスローダだけでなく、アプリケーション固有のクラスローダからインタフェースをロードするために、resolveProxyClass() メソッドが実装されました。
CR111924	リモート サーバ上の EJB からローカル サーバ上の EJB に送出されたユーザ定義の例外を処理する場合、WebLogic Server は ClassNotFoundException を送出しました。 この状況は、ユーザ定義の例外がローカル EJB のクラスローダに含まれている場合でも発生しました。 例外を処理するソケット リーダーが、アプリケーション クラスローダではなくシステム クラスローダを使用したために問題が発生しました。 この問題は、コードを修正して解決されました。

クラスタ

変更要求番号	説明
CR107471、CR128979、CR136731	クラスタで HTTP トンネリングを使用する場合に、クライアントが次のメッセージを受け取りました。 java weblogic.Admin -url http://colma:17683 -username system -password password PING 10 <May 29, 2003 10:14:18 AM PDT> <Error> <RJVM> <000515> <execute failed java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '0'java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '0' at weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch(HTTPClientJVMConnection.java:422) at weblogic.rjvm.http.HTTPClientJVMConnection.execute(HTTPClientJVMConnection.java:305) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)> Failed to connect to <urldeleted> due to: <urldeleted>:Bootstrap to <urldeleted> failed. It is likely that the remote side declared peer gone on this JVM] この問題は、プラグインが各トンネル リクエストを次のサーバへラウンドロビンしようとしたために発生しました。 リクエストは同じサーバに固定されていませんでした。 この問題は、jsessionid クッキーを設定し、それをプラグインに送り返すことで状態がクライアントで管理されるようにコードを修正して解決されました。
CR112874	WebLogic Server 6.1 SP03 で、ステートフル セッション Bean のクライアントが、クラスタにデプロイされている Bean にアクセスし、そのクラスタでは重みベースのロード バランシングがコンフィグレーションされている場合、重みが 1 番目と 2 番目の管理対象サーバがその順番で強制停止されると、クライアントは次のメッセージを送信しました。 <Jul 22, 2003 1:32:56 AM IST> <Warning> <Kernel> <No replica in list has the expected weight. Reverting to round-robin> 管理対象サーバを再起動すると、ロード バランシング アルゴリズムはラウンドロビンに切り替わりました。 分析の結果、管理対象サーバがダウンしたときにレプリカ リストが更新されましたが、競合状態が原因で、RichReplicaList の最大の重みが正しくリセットされなかったことがわかりました。 レプリカ リストのサイズが変わったら最大の重みを再計算するようにコードを変更して、問題を解決しました。
CR111029	クラスタ メンバーは、デフォルトの 30 秒間のタイムアウト期間内にハートビートを受信しないと、タイムアウトしました。 ハートビートは 10 秒ごとに送信され、サーバはハートビートの取得を 3 期間 (合計待機時間は 30 秒) 待機してから、メンバーをタイムアウトしてクラスタ メンバーが使用不可能であると宣言しました。 たとえば、セッション レプリケーション中に、セカンダリ サーバが TCP レベルで使用できなくなった場合、非常にビジーな Web サイトでは 30 秒の期間が長すぎることもありました。 セカンダリがクラスタ ビューから削除される前に、プライマリは多数のセッションをセカンダリにレプリケートしようとし、その結果サーバがハングしたり速度が低下したりしました。 現在は「IdlePeriodsUntilTimeout」の値を調整できるようになっています。 config.xml ファイルの <Server IdlePeriodsUntilTimeout="3"> タグで設定します。 通常、この値は調整しないでデフォルト (3) のままにしてください。 ただし、特定の状況では、アーキテクチャや特定のアプリケーションの問題、または特定の製品のシナリオにおける負荷や利用可能な冗長性に応じて、この値を慎重に調整すると、根本的な原因を特定して修正するまでの間、一時的に問題が軽減される可能性があります。 この値を変更する場合は十分に注意し、最大負荷のシナリオでアプリケーションを十分にテストして予期される動作を確認することをお勧めします。 すべてのシナリオに対応する推奨事項はないため、この値を変更する必要がある場合は、負荷テストが絶対に必要です。
CR125966	サーバ インスタンスが停止される途中でレプリケーション リクエストを処理し、syncSession 中に ClassCastException が発生しました。Web コンテナが ReplicatedSessionContext から MemorySessionContext への型キャストを行おうとしたためです。 コードの変更後、サーバ インスタンスは停止される途中でレプリケーション リクエストを処理しなくなりました。
CR129234	ReplicatedSessionContext に 2 つのハッシュテーブルがあり、1 つはサーバがプライマリとなっているセッションを格納して、もう 1 つはサーバがセカンダリとなっているセッションを格納しています。 セカンダリ セッションのハッシュテーブルには sessionId というキーと ROID という値があります。 セッションが無効化されて、セッションを削除する要求がセカンダリ サーバに届くと、WebLogic Server は ROID を ReplicatedSessionContext に渡し、ROID と値を比較するためにハッシュテーブル内の値を検索した後、エントリを削除しました。 WebLogic Server は ROID ではなく sessionId を渡すことで、この動作を回避するようになりました。
CR127849	クラスタ ノードで均一でないアンバインドとリバインドを行うと、サーバが初期化されていないリモート参照をクライアントに返して、AssertionError が発生する場合があります。 この問題は、アンバインド時にプライマリの代理が null に設定されるようにコードを変更して解決されました。
CR112326	レプリケート可能オブジェクトの JNDI リバインド中に weblogic.cluster.BasicServiceOffer でメモリ リークが発生しました。 この問題は、コードを修正して解決されました。
CR116954	デフォルト Web アプリケーションがデプロイされていない場合に、応答ヘッダ内のクラスタ サーバ リストを取得するために、HttpClusterServet がダミーのリクエスト「/WLDummyInitJVMIDs」を送信したとき、WebLogic Server は次のようなデバッグ メッセージをログに記録しました。 ####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <foo> <ms1foo> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1foo) found no context for "/WLDummyInitJVMIDs". This request does not match the context path for any installed web applications and there is no default web application configured.> コードを変更して問題を解決しました。
CR121113	HttpClusterServlet はエラー メッセージにスレッド名を出力しなかったため、エラーが発生したときに問題の診断が困難でした。 トラブルシューティングに役立つように、ログに記録されるエラー メッセージにスレッド名を含めるように GenericProxyServlet.trace() のコードを変更しました。
CR127643、 CR129319	Web アプリケーション内で宣言されたインタフェースを実装した動的プロキシが HttpSession に入り、そのセッションがレプリケート可能であった場合に、WebLogic Server ではセカンダリ サーバでそのインタフェースのクラスをロードすることができませんでした。 動的プロキシを正しく解決するために、セカンダリ サーバではインタフェースのあるアプリケーションの名前が必要です。 ストリームで applicationName を書き込むために、MsgAbbrevOutputStream で annotateProxyClass が実装されました。 受信側で、resolveProxyClass はこのアプリケーション名を使用してアプリケーションからインタフェースのクラスをロードします。 この変更の結果、(アプリケーション アーカイブに格納されたインタフェースを実装する) 動的プロキシは HttpSession に入れて、正しくレプリケートすることができます。 副作用はないはずです。

コネクタ

変更要求番号	説明
CR131745	LocalTransaction のトランザクション サポートを指定したリソース アダプタでは、使用可能な接続プールに接続が解放されるまで、接続のトランザクション状態はリセットされませんでした。 別のスレッドが直ちにそのスレッドを選択して使用しようとすると、接続は登録されず、適切に共有されない可能性がありました。 コードの変更後、トランザクション状態は、トランザクションが完了したら直ちにリセットされるようになりました。これは、利用可能なプールに接続が返される前に行われます。

コア サーバ

変更要求番号	説明
CR131692	7.0 の停止プロセスでは、アプリケーション レベルのスレッドと WebLogic Server インフラストラクチャの処理を実行しているスレッドが区別されていませんでした。 新しい接続のリクエストを拒否すると、WebLogic Server が不適切な動作をしました。 たとえば、ノード マネージャが停止途中のサーバを再起動しようとしたり、現在のセッションのセッション レプリケーションが失敗したり、サーバが不明な状態にあるとコンソールが報告したり、といったことです。 サーバの正常な停止を支援するコードが追加されました。
CR125245	PreferWebInfClasses が有効になっている状況で、複数のスレッドが Web アプリケーションの同じクラスをロードしようとすると、java.lang.LinkageError: duplicate class definition: エラーが発生するおそれがありました。 この問題は、クラスが最初にロードされるときに発生しました。 ChangeAwareClassloader の loadClass メソッドを同期化するコード変更で、この問題は解決しました。
CR103999	WebLogic Server では、「Unrecognized property: webservice.client.ssl.strictcertchecking」というエラーが表示されることがありました。 このエラーは、渡されたシステム プロパティをプロパティのリストで見つけられないことが原因でした。 このエラーは、プロパティのリストでシステム プロパティが渡されていないことが原因です。 このエラー メッセージはプロパティが無効になることを示すわけではなく、プロパティがプロパティ リストに追加されたら、このメッセージは表示されないはずです。
CR103032	ステートフル セッション Bean の [トランザクション中の削除を許可] 属性をユーザが編集できるように、Administration Console が更新されました。
CR100705	管理サーバがダウンしている場合に SecurityConfigurationMBean.findDefaultRealm() を失敗させてしまうような、管理サーバへの依存が SecurityConfigurationMBean にありました。 管理サーバがダウンしている場合はローカル MBean サーバで処理を実行するメカニズムを提供することで、この問題は解決しました。
CR100373、CR130592	J2EE モジュールのタイプを判別するロジックで、管理対象サーバ用のアプリケーションのローカル コピーまたはステージングされたコピーが使用されていませんでした。 この問題は、J2EE モジュールのタイプをサーバが判別できない結果として MSI モードで表面化していました。 オリジナルのパスが管理対象サーバの config.xml ファイルにない場合は、stagingLocation を使用して J2EE モジュールのタイプが判別されます。
CR122939	プライマリ サーバとのセッションを維持できないことが原因で、分散デッドロックが発生していました。 プライマリでもセカンダリでもないサーバにリクエストが到着すると、セカンダリだけでなくプライマリでも既存のセッションの削除が試行され、現在のサーバで新しいセッションが作成されて、新しいセカンダリが登録されます。 その過程で、このサーバは非ブロッキング キュー上のセッションを削除するリモート要求をプライマリに対して行い、プライマリ サーバは非ブロッキング キュー上のそれ自体を削除する削除呼び出しをセカンダリ サーバに対して行います。 そのようなリクエストが複数ある場合、非ブロッキング キューにはスレッドが 2 つしかないので現在のサーバで応答を受信する他のスレッドは存在せず、そのために分散デッドロックが発生します。 WebLogic Server は、非ブロッキング キューに入ってくるリクエストを処理している間は新しいリモート要求を行わなくなりました。 これで、この問題は解決されます。非ブロッキング キューに、応答を受信するスレッドが常に存在するようになるからです。
CR130352	WebLogic Server 8.1 からサービス パック 4 の 7.0 にバックポートされた WLServer ant タスクは、指定されたプロパティのない config.xml ファイルを作成することがありました。 分析の結果、WLServer が明示的には saveDomain (config.xml に MBean の変更を書き込む) を呼び出していないことが判明しました。 その代わりに、WLServer は saveDomain を呼び出すトリガに依存していました。 問題は、WLServer があまりにも速くサーバを起動および停止するために、トリガが時間的に間に合わないことがあったことでした。 saveDomain の呼び出しを WLServer ant タスクに配置し、サーバが停止する前に config.xml が強制的に書き込まれるようにすることで、この問題は解決しました。
CR129002	ユーザが分散送り先のメンバーを一切コンフィグレーションしない場合でも、WebLogic Server は Administration Console からの JMS 分散送り先のコンフィグレーションを許可します。 ただし、そのコンフィグレーションが無効な場合はサーバが再起動に失敗していました。 JMSLegalHelper のリーガル チェックが緩和された後は、分散送り先がコンフィグレーションされているがメンバーは割り当てられていない場合でも、サーバが起動できなくなることはなくなりました。
CR128648	weblogic.deployer WLConfig タスクがすべての IllegalArgumentException をそのまま受け入れ、それが原因で暗号化されたシステム パスワードの機能に関連するビルド エラーが起きていました。 この問題は、コードを修正して解決されました。
CR128445	weblogic.Admin が、サーバ インスタンスで使用されるたびに ServerStartMbean のユーザ名とパスワードを設定していました。 ユーザが同じことをしようとした場合は、WRITE 属性へのアクセス権がなく失敗していました。 この問題は、ServerStart で WRITE 属性が設定されないようにするコード変更で解決しました。
CR126280	管理サーバを再起動すると、ドメイン管理ポート例外が生じていました。 MSI モードをチェックするコードが RMI 起動サービスに追加されました。 この修正で、例外が発生しなくなりました。
CR125309	weblogic.Admin の SHUTDOWN または FORCESHUTDOWN から、不正確な戻りコード ステータスが返されていました。 weblogic.Admin の SHUTDOWN または FORCESHUTDOWN からの戻りステータスを修正するコードが追加されました。 注意 : 不正確なステータス コードに依存しているアプリケーションは、記述し直す必要があります。
CR125285	FileDistributionServlet は、sendError() メソッドの呼び出し後に復帰しなければなりません。 sendError() の後に (それがメソッドの中で行う最後のことでない場合に) FileDistributionServlet のすべてのメソッドから復帰するためのコードが追加されました 。
CR125018	よくある特定のプロキシ処理が、それらが実行されるべきローカル サーバで実行されていませんでした。 ローカル呼び出しのマップを実装して userLockoutManager の呼び出しがローカルで行われるようにするコードが追加されました。 UserLockoutManager は、管理サーバではなくローカル サーバの情報を返すようになりました。
CR093109	WebLogic Server ドメイン全体を強制停止すると、管理対象サーバだけが強制停止されるのではなく、管理サーバが強制停止されていました。 この問題は、コードを修正して解決されました。
CR094219	サーバとドメインのロギングが、次のようにして期待通りに機能していませんでした。 ドメイン ログ ファイルが、時間でローテーションするようにコンフィグレーションされているにもかかわらずローテーションできていませんでした。 [Limit Log Files] オプションが、SimpleDateNamed ログ ファイルで正しく機能していませんでした。 コードの変更で以上の問題は修正され、SimpleDateFormat を使用してログ ファイルに名前を付ける場合にログの fileCount 制限が強制されるようになりました。
CR094410	DebugHttp が ServerDebugMBean でアクティブ化された場合に、WebLogic Server は SocketResetExceptions を単純なデバッグ メッセージではなくエラーとして報告していました。 この問題に対処するために、このデバッグ メッセージを報告するための logMuxableSocketResetException() がメッセージ カタログに追加されました。
CR098578	Bootstrap サーブレットが、管理サーバが実際には完全に起動していなかったり、RUNNING 状態にないときに SUCCESS ステータスを返していました。 コードの変更の後、Bootstrap サーブレットは管理サーバの ServerRuntime MBean の取得を試行し、そのステータスをチェックして成功のステータスを返す前にサーバが RUNNING モードにあることを確認するようになりました。 管理サーバの起動と接続を試行する管理対象サーバは現在、管理対象サーバが起動しているときに管理サーバが RUNNING 状態にない場合は「Booted in MSI mode」を返します。
CR098607、CR136879	アプリケーション A がアプリケーション B を使用している状況で、アプリケーション B をルックアップしているときに、アプリケーション A の J2EE コンテナがアプリケーション B の ClassFinder をアタッチすることで DependencyClassLoader を作成します。 アプリケーション B の再デプロイメント時に、アプリケーション B は新しい ClassFinder に遭遇し、その古い ClassFinder はその時点で有効ではなくなっています。 クライアント リクエストで、サーバは古い DependencyClassLoader を使用しようとし、例外を送出します。 例外を生じさせた動作は、変更されました。 ReplicaAwareRemoteObject.getPrimaryRepresentative() から impl クラスをロードする目的で DependencyClassLoader が使用されることはなくなりました。
CR104269	Administration Console で新しいカスタム認証プロバイダをコンフィグレーションし、その制御フラグとデフォルト認証プロバイダの制御フラグを両方とも SUFFICIENT に設定し、サーバを再起動して、set attribute コマンドを使用し、サーバを再び再起動した場合に、セキュリティ エラー メッセージが受信され、サーバを起動することができませんでした。 この問題は、コードを修正して解決されました。
CR105338	ファイルの最大数に達したときに、WebLogic Server は管理サーバと管理対象サーバの両方でロギングを停止していました。 次のエラー メッセージがドメイン ログ ファイルに出力された後、サーバのロギング サービスが停止していました。 ####<Apr 21, 2003 3:17:39 PM GMT+09:00> <Alert> <Log Management> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-170017> <The log file .¥myserver¥myserver.log will be rotated. Reopen the log file if tailing has stopped. This can happen on some platforms like Windows.> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Critical> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:¥bea81ga¥mydomain¥myserver¥myserver.log' raised several exceptions. Shutting it down> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Error> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:¥bea81ga¥mydomain¥myserver¥myserver.log' raised exception when opening. Exception weblogic.logging.LogRotationException null> ####<Apr 21, 2003 3:17:40 PM GMT+09:00> <Error> <Logging> <KESATO01> <myserver> <ExecuteThread: '10' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <000000> <Handler: 'C:¥bea81ga¥mydomain¥myserver¥myserver.log' raised exception when opening. Exception weblogic.logging.LogRotationException null> この問題が発生すると、すべてのログ メッセージがサーバ ログ ファイルに出力されませんでした。 分析の結果、WebLogic Server はローテーション時にログ ファイルを閉じて、ログ ローテーションが失敗した場合に、ログ ファイルが閉じられたままになってしまうということが判明しました。 新しいログ ファイルで間違ったインデックスが生成されたときに、ログ ローテーションは失敗していました。 最新のタイムスタンプを持つファイルが最後のインデックスであると当然のごとく想定されていたので、そのインデックス名を持つファイルが既に存在しているかどうかがチェックされていませんでした。 WebLogic Server はログ ファイルが既に存在する場合にログ ファイルを削除しようとせず、rename() が成功かどうかを確認していませんでした。 また、時間ベースのログ ローテーションの場合に、マルチ CPU マシンで、同じミリ秒内に複数のローテーションが行われていました。 この問題は、コードの修正で解決しました。
CR105516	WebLogic Server 7.0 の以前のサービス パックでは、複数のフェイルオーバが必要なときにステートフル セッション EJB のフェイルオーバが機能していませんでした。 同じブラウザ ウィンドウで次のように呼び出しを行うと、クラスタの 1 つのノードだけが生き残る場合に java.rmi.ConnectException が送出されていました。 1. 3 つすべてのクラスタ ノードが動作しています。 2. ノード 1 に対して呼び出しを行い、EJB を作成して、リモートを http セッションに格納します (HTTP セッションのレプリケーションが有効になっている)。 3. ノード 1 を強制停止します。 4. セカンダリ ノード 2 に対して呼び出しを行い、EJB のリモートがレプリケートされた HTTP セッションから取得され、EJB の呼び出しが成功します。 この EJB の呼び出しの後、再びリモートが HTTP セッションに格納されます。 5. ノード 2 を強制停止します。 6. ノード 3 に対して呼び出しを行い、HTTP セッションから EJB のリモートを取得します。 WebLogic Server はノード 2 の EJB をルックアップしようとし、ノード 3 は使用しようとしませんでした。 ノード 3 で次の例外が送出されていました。 java.rmi.ConnectException: Could not establish a connection with -3088833905169218734S:172.23.64.38:[7001,7001,7002,7002 ,7001,7002,-1]:mydomain:managed2, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:275) at weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408) at weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:255) この問題は、コードを修正して解決されました。
CR106957	WebLogic Server 7.0 の以前のサービス パックでは、AIX 5.2 上で IBM の MQWorkflow と一緒に動作している場合に、WebLogic Server でサーブレットが MQWorkflow Java API を呼び出したときに、MQWorkflow でエラーが生じていました。 この問題は、ネイティブ IO (パフォーマンス パック) が無効になっている場合、または libmuxer.so ライブラリがクラスパスから削除されている場合は Windows では起こりませんでした。 分析の結果、「言語コード」(エンコーディング パラメータ) が適切な「en-us」に設定されず、「c」に設定されていたことが判明しました。 この問題は、コードを修正して解決されました。
CR108727	WebLogic Server 7.0 の以前のサービス パックでは、管理サーバが以下のコマンドライン オプションで起動していました。 weblogic.management.discover.interval = 60 weblogic.management.discover.retries = 6 weblogic.management.internal.debug = true 障害の後 (java.rmi.ConnectException が送出される)、管理対象サーバは検出されて、正常に再接続されましたが、OutOfMemoryError が生じていました。 その後は、管理対象サーバ上の MBean の呼び出しが次の例外で失敗していました。 java.rmi.NoSuchObjectException: RemoteInvokable - id: '267' 分析の結果、ManagedServerReDiscoveryChecker スレッドが停止して、管理対象サーバが検出されなくなっていたことが判明しました。 この問題は、必要なときに必ず検出スレッドが実行されるように再試行ロジックを変更して解決しました。
CR109307	以前は、SP3 ドメインでは SP2 の管理対象サーバを起動できませんでした。 コード変更の結果、異なるサービス パックが互換性を持つようになり、「管理ドメイン内のサーバは、管理サーバが管理対象サーバと同じかそれ以上のサービス パック レベルにある限りどのサービス パック レベルであってもかまわない」という WebLogic Server の互換性に関する一文と調和するようになりました。
CR109391、CR123398、 CR174565	以前のサービス パックでは、WebLogic Server は ServletContext の中にあればシリアライズできないオブジェクトであってもデシリアライズしようとしていました。その結果として、NotSerializableException が送出されていました。 ServletContext で、シリアライズできないオブジェクトはデシリアライズされなくなりました。
CR109688、CR135235	特定の状況下では、InitialContext をルックアップしているシンプルな Java クライアントが偽の「バージョン情報がない」エラーを受信していました。 問題は、ヘッダ バッファの改行が line.separator プロパティではなく「¥n」でマーキングされていたことです。 この問題は、コードの変更で解決されました。
CR110233、CR121682	プロダクション モードで動作しているサーバ インスタンスが不適切に ¥applications フォルダをチェックし、そのチェックを記録するための一時ファイルにエントリを作成していました。 開発モードでは、サーバの起動時に、アプリケーションは自動的に ¥applications フォルダでアンデプロイされて再デプロイされます。 コードの修正で、この問題は解決されました。
CR111239	失われた JMS 接続がクリーンアップされていませんでした。 クライアント (トピック サブスクライバ) は、JMS サーバとは異なるマシンで動作してました。 クライアントとサーバ間の顧客のネットワーク接続が失われたときに、サブスクライバ、セッション、および接続のクローズと再確立の後、最初のサブスクライバが削除されていないことが Administration Console で示されていました (コンソールでは 2 つのサブスクライバが表示されていた)。 接続ファクトリの <MessagesMaximum> 値に達すると、新しいメッセージが発行されるたびに「保留メッセージ数」値が増加します。 分析の結果、ネットワークの停止が原因で、クライアントの peerGone メッセージがサーバ インスタンスに到達していなかったことが判明しました。 peerGone を宣言した後、クライアントはサーバ インスタンスに再接続しようとしていました。サーバ インスタンスは古い rjvm で peerGone を宣言することなく古い接続を新しい接続に置き換えて、そのために JMS オブジェクトがメモリに残される結果となっていました。 同じクライアントからの同じプロトコルの重複接続を検出したときに、サーバが古い rjvm で peerGone を宣言し、新しい rjvm と新しい接続の新しい ConnectionManager を作成するようにコードを変更して、この問題は解決しました。
CR116707	WebLogic Server は特定の Factory/Trader パターンが使用されたときに ReplicaAwareRemoteRef 警告ログを提供し、次のメッセージをクライアント側で表示していました。 [ReplicaAwareRemoteRef] : WARNING: client-side RA stub didn't find environment on thread コード変更の後は、不適切なログがクライアントに対して出力されなくなりました。
CR116712	以前のサービス パックでは、INVOKE が管理ツールを使用して WLECConnectionPoolRuntime で発行された場合に WLECConnectionRuntime MBeans が更新されていませんでした。 分析の結果、resetConnectionPool() が WLECConnectionPoolRuntime MBean で呼び出されたときに、プールがリセットされていないことが判明しました。 古い接続が削除されていませんでした。 この問題は、コードを修正して解決されました。 現在、古い接続に対応する MBean は resetConnectionPool() の呼び出しの前に登録が解除されるようになっています。
CR120492、CR122551	HTTP トンネリングのパフォーマンスを向上させるためのコード変更で、キープアライブ接続が維持されるようにトンネリングされる応答のコンテンツ長が設定され、HTTP URL 接続のキャッシュも可能になりました。
CR121801	WebLogic Server 8.1 で導入された wlconfig ツールが、サービス パック 5 から 7.0 で利用できるようになりました。
CR134971	(サーバ サイドから) 例外メッセージ フィールドの一部として <<no stack trace available>> が送信されたとき、rmi レイヤはサーバ サイド スタック トレースとして例外を繰り返し追加していました。 そのためログ ファイルが一杯になりました。 この状況は、サーバでヒープが不足し、アプリケーション コード (EJB + サーブレット) によって NullPointerException が送出されたときに明らかになりました。 WebLogic Server は例外メッセージ フィールドを解析してこの特殊な例外を捕捉し、例外は 1 回だけ追加されるようになりました。
CR122112	weblogic.management.timer.Timer クラスを使用して EJB に対する呼び出しが行われた場合に、EJB のホーム インタフェースのルックアップで次の例外が送出されていました。 java.lang.ClassCastException: Cannot narrow remote object to examples.ejb20.timer.SourceDataHome at weblogic.iiop.PortableRemoteObjectDelegateImpl.narrow(PortableRemoteObjectDelegateImpl.java:200) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject.java:132) at examples.ejb20.timer.webapp.TimerServlet.callEjb(TimerServlet.java:61) at examples.ejb20.timer.webapp.TimerServlet.access$000(TimerServlet.java:23) at examples.ejb20.timer.webapp.TimerServlet$MyNotificationListener.handleNotification(TimerServlet.java:81) at weblogic.time.common.internal.TimerListener$1.run(TimerListener.java:48) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:685) at weblogic.time.common.internal.TimerListener.deliverNotification(TimerListener.java:44) at weblogic.management.timer.Timer.deliverNotifications(Timer.java:382) at weblogic.time.common.internal.TimerNotification$1.run(TimerNotification.java:112) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:685) at weblogic.time.common.internal.TimerNotification.execute(TimerNotification.java:109) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210) 分析の結果、呼ばれる側の ContextClassLoader を WebLogic Server が Timer クラスに格納していなかったことが判明しました。 そのために、通知が追加されたクラスローダとは異なるクラスローダで通知が実行されていました。 結果として、ClassCastException が送出されていました。 この問題は、通知が追加されたときに呼ばれる側の ContextClassLoader を保存するコード変更で解決されました。 通知イベントを配信する一方で、保存されたクラスローダは配信側 ExecuteThread の contextClassLoader として設定されます。
CR122361	監査有効化メッセージが、USER ID を記録していませんでした。 <Aug 29, 2003 12:31:25 AM EDT> <Info> <Configuration Audit> <159909> <Configuration Auditing is enabled> 反対に、無効化メッセージは USER を記録していました。 <Aug 29, 2003 12:31:31 AM EDT> <Info> <Configuration Audit> <159910> <USER system, Configuration Auditing is disabled> コード変更の後、両方の監査メッセージとも USER ID を記録するようになりました。
CR122706	別のクラスタの EJB を呼び出す、クラスタにデプロイされたクラスタ化されている Web アプリケーションが、AssertionError を送出していました。 生成されたコードではインタフェースのメソッドを計算する際に適切なメソッドを使用していなかったため、生成されたスタブから間違ったクラスローダが使用されるようになっていたことが、分析でわかりました。 コードを変更してこの問題を解決しました。
CR122878	MBean が KernelID で削除されていました。 その結果、削除操作が何によって開始されても、監査プロバイダはカーネルが MBean を削除したと記録していました。 コード変更の後、MBean は現在の認証されたサブジェクトによって削除されるようになりました。
CR123571	同じマシン上で複数の T3 クライアントを同時に起動すると、それらの複数のクライアントが同じ JVMID を取得し、例外が生じるか、クライアントがハングする可能性がありました。 この問題は、同じマシン上で同時に複数の T3 クライアントを起動したときのみ発生していました。 この問題は、JVMID を生成するコードを修正して解決しました。
CR129094、CR133591、CR135254、CR135255、CR124861、CR132275	AIX プラットフォームでの t3 プロトコルの TCP ウィンドウ縮小に関連するパフォーマンス上の問題が解決されました。
CR135488	以前は、セキュリティ プロバイダ ディレクトリのファイル (デフォルトは /lib/mbeantypes) は、そのファイル拡張子に関係なくセキュリティ プロバイダとして扱われ、サーバの起動時にロードされていました。 WebLogic Server 7.0 のサービス パック 5 からは、拡張子が .jar または .zip のファイルだけがセキュリティ プロバイダとして扱われます。 他の拡張子を使用するセキュリティ プロバイダは、ロードされなくなりました。 ドメインでセキュリティ プロバイダに別のファイル拡張子が使用されている場合、サービス パック 5 ではそれらを変更してください。

デプロイメント

変更要求番号	説明
CR110897、CR125329、CR129494	アプリケーションをデプロイした後でアンデプロイし、その後でサーバを再起動した場合に、サーバから IllegalArgumentException が送出されていました。 分析の結果、J2EE コンテナが起動中に、コンフィグレーションされているがデプロイされていないアプリケーションについて処理していなかったことが分かりました。 そのようなアプリケーションは <Application> スタンザ内で Deployed="false" となっていることから識別されます。 J2EE コンテナのコードが変更されて、このような周辺条件の場合にも処理が行われるようになりました。
CR127393	以下のメモリ リークが確認されました。 1) EJB オブジェクトにおけるメモリ リーク。 EO オブジェクトの ClientRuntimeDescriptors は、アプリケーションがアンデプロイされた後もヒープに保持されていました。 2) J2EEApplicationContainer の EJBCache におけるメモリ リーク。 EJBCache オブジェクトは、アプリケーションがアンデプロイされた後にクリーンアップされませんでした。 3) WebAppServletContext の実行時 MBean におけるメモリ リーク。 WebAppServletContexts に固有の実行時 MBean は、アプリケーションのアンデプロイ後に登録解除されていませんでした。 4) KeepAliveCache のタイマーにおけるメモリ リーク。 KeepAliveCache のタイマー オブジェクトは、アプリケーション固有のクラスローダに保持されていました。 5) J2EEApplicationContainerFactory の ddMap におけるメモリ リーク。 記述子オブジェクトは、アプリケーションがアンデプロイされた後に登録解除されていませんでした。 6) Introspector キャッシュが原因のメモリ リーク。 アプリケーション固有のクラスは、Struts を使用するアプリケーションをアンデプロイした後も Introspector キャッシュによって保持されていました。 以下の機能を実行するコードが追加されました。 1) EO オブジェクトをアンエクスポートすると、アプリケーションのアンデプロイ時に、EO オブジェクトに関連付けられている ClientRuntimeDescriptor オブジェクトが削除されるようになりました。 2) アプリケーションのアンデプロイ時に EJBCache をクリアします。 3) アプリケーションのアンデプロイ時に、WebAppServletContext に固有の実行時 MBean を登録解除します。 4) KeepAliveCache は、アプリケーションのコンテキストに入る前に、タイマーを初期化します。 5) アプリケーションのアンデプロイ時にデプロイメント記述子をクリアします。 6) アプリケーションのアンデプロイ時に Introspector キャッシュをフラッシュします。
CR136176	LoadBeforeAppActivation="true" を設定した結果、StartupClass が 2 回呼び出されました。 PostDeploymentStartupClass に該当しない場合はサーバが無視するようにコードを追加しました。
CR102296	ブール型属性の LoadBeforeAppActivation が StartupClassMBean に追加されたため、起動クラスがデプロイされる順序には 3 つの異なる設定があります。 デフォルト : サーバ インスタンスが JMS および JDBC サービス、EJB、およびアプリケーションをデプロイした後。 LoadBeforeAppActivation=true: サーバ インスタンスが JMS および JDBC サービスをデプロイした後で、EJB とアプリケーションをデプロイする前。 LoadBeforeAppDeployment=true: サーバ インスタンスが JMS および JDBC サービス、EJB、およびアプリケーションをデプロイする前。
CR109645	削除後にアプリケーションが 2 度目にコンフィグレーションされるときに、アプリケーション内のコンポーネントには正しい対象がありませんでした。 管理 MBean に対する変更はコンフィグレーション MBean に伝播されていませんでした。 現在は、コンフィグレーション MBean を更新する場合、対象がクラスタであれば、WebLogic Server はクラスタ内のサーバを取得して、各サーバごとに、サーバ名に基づいてコンフィグレーション MBean のオブジェクト名を作成してから、コンフィグレーション MBean を更新します。
CR111065	ある特定の状況では、SlaveDeployer の初期化から、デプロイメント タスクのデルタ リストが作成されていました。 コードの修正により、デプロイメント タスクのデルタの作成には、MasterDeployer が常に使用されるようになりました。
CR134122、CR134119	StatefulEJBObject.remove() を呼び出すと、このメソッドに対するパーミッションがない場合でも、EJB オブジェクトがアンエクスポートされました。 この問題は、コードを変更して解決されました。
CR128932	Administration Console は、クラスタ内の管理対象サーバの 1 つが正常に停止した場合に、クラスタに割り当てられたアプリケーションがデプロイされていないことを報告しました。 コードを変更してこの問題は解決しました。

EJB

変更要求番号	説明
CR127334、CR133975	既にパッシベーションされて削除された EJB に対して remove() が呼び出され、EJB の EOImpl インスタンスがガベージ コレクションされない場合に、メモリ リークが発生しました。 コードを変更してこの問題は解決しました。
CR132510	この問題は、集合値 cmr-field が、作成元のトランザクションとは別のトランザクションでアクセスされたために発生しました。 現在のトランザクションが、生成された oneToManySet の作成元のトランザクション (createTx) と同じかどうかをチェックするためのコードが追加されました。 同じでない場合は、oneToManySet の createTx を現在のトランザクションに設定します。
CR131848	BMP の「cache-between-transactions」が true に設定されている場合、実行時に ClassCastException が送出されました。 bean.java.rmi.RemoteException: EJB ClassCastException を回避するために BMP および CMP20 Bean のチェックが追加されました。
CR103038	[トランザクション中の削除を許可] を「False」に設定している場合に、アプリケーションがトランザクション中にステートフル セッション Bean を削除しようとすると、不正確なエラー メッセージが表示されました。 weblogic.ejb20.locks.LockTimedOutException は EJB 2.0 仕様で求められた例外ではなく、以下の必要な例外で置き換えられています。 javax.ejb.RemoveException
CR132853、CR128980、CR135722	メッセージ駆動型 Bean が同期的なメッセージ ポーリング方法を使用しているときに、Sonic JMS サーバを使用すると、メッセージ駆動型 Bean コンテナのポーリングの最適化によって、メッセージの受信が遅延する場合がありました。 この問題を回避するには、最適化されたポーラーを使用しないでください。 Sonic のメッセージ配信方式はこの方法ではうまく動作しないため、Sonic JMS サーバを連続的にポーリングするポーラーを使用してください。 新しいメッセージ駆動型 Bean の動作は、TIBCO および Sonic JMS プロバイダにのみ適用できます。
CR133602	XA 接続が使用される場合、WebLogic Server は SonicMQ 4.* 用に特別な処理コードを使用します。 このコードは SonicMQ 5.* では不要になりました。 このため、接続リークが発生しました。 WebLogic Server MDB コンテナにある SonicMQ 5.* では特別なコードを使用しないでください。
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 の値の設定を許可しないように、準拠チェックが追加されました。 キャッシュに大きなサイズ (無限) を設定する必要がある場合は、DD で max-beans-in-cache の値を java.lang.Long.MAX_VALUE に設定することができます。 これにより weblogic-ejb-jar.xml の同じ要素の動作にも準拠します。
CR126413	WebLogic JDriver (Type 2) を使用する場合、blob/clob cmp-field をデータベースに永続化しているときに、CMP Bean が ClassCastException を送出しました。 Oracle Type4 および WebLogic Type2 ドライバの両方で LOB (Blob および Clob) のキャストを処理するコードを追加しました。
CR129185	WebLogic Server は Optimistic 同時方式の Bean を別のトランザクションでロードしました。現在のトランザクションをサスペンドして新しいトランザクションを開始し、その Bean をロードしてから、Oracle 以外のデータベースに対する古いトランザクションを再開することで、SELECT 中にロックを取得しないようにしました。 Sybase のデフォルトの動作では、SELECT 中に共有ロックが取得されますが、その文が完了する前にロックが解放されるため、ロードの動作を変更しました。 concurrency-strategy が Optimistic である場合、WebLogic Server は、isolation-level が Read-Uncommitted または Read-Committed よりも高い場合にのみ、Oracle 以外のデータベースに対するトランザクションをサスペンドしてから再開するようになりました。
CR127397	エンティティ Bean は、ActivatableServerRef を使用して activate を呼び出し、Bean インスタンスを取得します。 Bean のメソッドを呼び出した後、ActivatableServerRef は deactivate を呼び出して、Bean をプールに解放します。 問題は、アプリケーションから EJB が呼び出されるときに、deactivate が呼び出されず、Bean が解放されないことでした。 ActivatableServerRef は notifyRemoteCallBegin および notifyRemoteCallEnd を明示的に呼び出すようになりました。
CR127361	メンバー変数としてリモート オブジェクトを含む Bean のパッシベーションを行うときに、EJBReplacer はリモート オブジェクトを考慮しないため NotSerializableException を送出しました。 コードの変更後、Bean インスタンスがメンバー変数としてリモート オブジェクトを含む場合は、EJBReplacer が必要に応じてリモート オブジェクトを変換するようになりました。
CR079164	自動主キー生成テーブル設定中のエラーに関してサーバが表示した、役に立たないデプロイメント エラー メッセージは、ネストされた例外メッセージをより明確に提示する詳細なメッセージに置き換えられました。
CR093520	あるタイムゾーンのマシンで JSP をプリコンパイルし、それと同じ JSP を別のタイムゾーンのサーバにデプロイする場合、WebLogic Server は JSP を再コンパイルすることがありました。 この問題は、WebLogic Server が、(JAR ユーティリティによって埋め込まれた) JSP のローカル タイムスタンプと、生成されたクラス ファイル内のタイムスタンプを比較して、JSP をチェックしたために発生しました。 コンパイル時にタイムゾーンを保存し、そのタイムゾーンをデプロイメント時に使用して再コンパイルが必要かどうかを決定することで、この問題を解決しました。
CR106136	以前の WebLogic Server 7.0 サービス パックでは、delay-updates-until-end-of-tx が false に設定されている場合、EJB 1.1 CMP Bean のゲッター メソッドは isModified() を呼び出しませんでした。 セッション EJB は エンティティ EJB のゲッター メソッドを呼び出しました。 両方の EJB にはコンテナ管理のトランザクションがあり、トランザクション属性は Required に設定されていました。 ゲッター メソッドが呼び出されるたびに、続いて ejbStore() が呼び出されます。delay-updates-until-end-of-tx は false でした。 ただし、Bean の ejbStore が呼び出される前に、コンテナはトランザクションがコミットするまで isModified メソッドを呼び出しませんでした。 ejbStore は、Bean の isModified メソッドの結果に応じて、postInvoke() から呼び出されるようになりました。 この修正で問題は解決されました。
CR108084	送信側が JMS メッセージをポストして、メッセージ駆動型 Bean がトリガされたときに、MDB がデータベースのデータを取得しない場合、メッセージが消失します。 この問題は、確認済みの Oracle XA の制限によって発生しました。この制限では、サスペンドされたトランザクションが、開いている結果セットを無効にします。 コードを変更して問題を解決しました。
CR110917	大きな負荷がかかっているときに WebLogic Server のステートフル セッション Bean サンプル (examples.ejb20.basic.statefulSession) を実行すると、OutOfMemoryError が発生しました。 「out-of-the-box」コンフィグレーションは次の設定のように変更されました。 home-is-clusterable = true replication-type = InMemory アプリケーション アーカイブは 2 つの管理対象サーバから成るクラスタにデプロイされました。 Java クライアントは次の手順を実行しました。 ホームをルックアップする。 EJB のインスタンスを作成する。 buy および sell メソッドを呼び出す。 EJB の remove メソッドを呼び出す。 そのような要求でクラスタをロードすると、メモリ不足の状況が生じます。 クライアントのアクションが停止したときに、サーバ インスタンスは回復しませんでした。コンソールは高いヒープ使用率を報告し続けました。 分析の結果、セカンダリの EJBObject がアンエクスポートされず、その結果メモリ リークになったことがわかりました。 この問題は、セカンダリの EJBObject をアンエクスポートするようにコードを変更して解決されました。
CR111551	以前のサービスの WebLogic Server 7.0 で、EJBC は java.lang.ClassCastException: oracle.sql.BLOB エラーを引き起こす CMP コードを生成しました。 分析の結果、クエリに対して生成された CMP RDBMS コードが正しくないことがわかりました。 WebLogic Server 7.0 SP05 より前では、サーバサイド JDBC は RMI ドライバを経由して、プール ドライバ、次に DBMS ドライバにアクセスします。 WebLogic Server 7.0 SP05 からは、RMI ドライバは外部クライアントでのみ呼び出されるようになりました。 サーバ サイド クライアント コードはプール ドライバに直接アクセスし、DBMS ドライバ の BLOB を RMI ラッパでラップしないで直接返します。 この変更では、コードを oracle.sql.BLOB instead of weblogic.jdbc.common.OracleBlob に直接キャストすることが必要です。 この問題は、SP05 以降の動作を反映するコードを生成するように EJBC を修正することで解決されました。
CR111670	connectionPool の作成に失敗した後で (たとえば、無効な URL またはドライバ クラスを使用する)、プールを正常に作成することはできませんでした。 この問題は、connectionPool が正常に作成されるかどうかに関係なく、 connectionPool を作成する前に connectionPool MBean が作成されたために発生しました。 以降にプールを作成しようとすると、同じタイプの 2 つ目の MBean を作成するときに失敗します。 connectionPool の作成中に例外が発生した場合は、関連付けられた MBean を削除するように JDBCService を変更することで、問題を解決しました。
CR112074	ビジネス メソッドのコンテナ管理の関係において、update の呼び出しとそれに続く remove の呼び出しを実行するときに、トランザクションの途中で ejbStore が呼び出されました。 BaseEntityManager.caseDeleteRemove() メソッドの内部で flushModifiedBeans() メソッドが呼び出されたために、余分な ejbStore が発生しました。 カスケード削除の場合に flushModifiedBeans() が呼び出されるようにコードを変更して、この問題を解決しました。
CR112558	フェイルオーバがクラスタ内のステートフル セッション Bean に対して機能しませんでした。次の例外が発生しました。 Start server side stack trace: java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'de.roland24.common.system.session.BackendSessionHome' on server: 't3://192.168.201.52:0 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java:78) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:188) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionData.java:426) この問題はコードを変更して修正されました。
CR112265	EJBGEN タグを使用してコンテナ管理による永続性 EJB をビルドするときに、以下の例外を受け取りました。 <Jul 17, 2003 2:49:20 PM MDT> <Info> <EJB> <010097> <Exception during the invocation of EJB "Customer(Application: classproject, EJBComponent: xpersistence_ejb. jar)" with primary key "[CustomerPK guidStr:4E9A50DD-8E1B-F2B5-24E7-860ADE3BE707 ]": java.lang.NullPointerException at com.zbc.las.commercial.persistence.test.CustomerPK.hashCode(CustomerPK.java:24) at com.zbc.las.commercial.persistence.test.CustomerPK.equals(CustomerPK.java:32) at com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6__WebLogic_CMP_RDBMS_customerOrders_Set.add(CustomerBean_b3dzi6__WebLogic_CMP_RDBMS_customerOrders_Set.java:289) at com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6__WebLogic_CMP_RDBMS_customerOrders_Set.addAll(CustomerBean_b3dzi6__WebLogic_CMP_RDBMS_customerOrders_Set.java:328) at com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6__WebLogic_CMP_RDBMS.setCustomerOrders(CustomerBean_b3dzi6__WebLogic_CMP_RDBMS.java:672) at com.zbc.las.commercial.persistence.test.CustomerBean_b3dzi6_ELOImpl.setCustomerOrders(CustomerBean_b3dzi6_ELOImpl.java:268) at java.lang.reflect.Method.invoke(Native Method) at com.zbc.las.framework.core.persistence.EjbHelper.setRelations(EjbHelper.java:594) at com.zbc.las.framework.core.persistence.EjbHelper.setRelations(EjbHelper.java:351) at com.zbc.las.commercial.persistence.test.CustomerBean.setOrders(CustomerBean.java:302) at .... この問題は、コードを修正して解決されました。
CR112703	JMSConnectionPoller は、リモートのユーザ名とパスワードを取得するために WebLogic Security フレームワークに渡す必要のある、ユーザの ID を認識しませんでした。 このリモートのユーザ名とパスワードは、リモート JMS サーバ (MQ、WebLogic など) との JMS 接続を確立するために必要です。 この問題は修正により解決されていますが、ユーザは MDB のセキュリティ ID をコンフィグレーションする必要があります。 手順については、『WebLogic エンタープライズ JavaBeans プログラマーズ ガイド』の「メッセージ駆動型 Bean のセキュリティ ID のコンフィグレーション」を参照してください。
CR112838、CR112225	BLOB については、その生成されたコードで、WebLogic Server は ObjectOutputStream.writeObject と ObjectInputStream.readObject を呼び出して、データベースでの読み書きの前にオブジェクトをシリアライズまたはデシリアライズします。 それらの呼び出しは、余分なヘッダ情報を追加します。 writeObject メソッドはオブジェクトのクラス、クラスのシグネチャ、クラスの非 transient および非静的フィールドの値を書き込み、加えてそのすべてのスーパータイプが書き込まれます (これが、データベースで余分なヘッダが見られる理由)。 それらの呼び出しで、ユーザが WebLogic Server のみを使用して BLOB を設定および取得する場合に問題が起こることはありません。なぜなら、readObject を使用してバイトが適切なオブジェクトに変換されるからです (例の余分なヘッダ情報が必要)。 ただし、BLOB が他のベンダまたはプログラマによって次のようにしてデータベースに直接挿入された場合は、 OutputStream os = ((weblogic.jdbc.common.OracleBlob) lob).getBinaryOutputStream(); os.write(this.tiffImage); // byte[] tiffImage 問題が起こることがあります。WebLogic Server が readObject を使用しても、ヘッダ情報がないからです。 WebLogic Server を使用して挿入されたデータについては、バイトを読み込む他のプログラムは余分なヘッダ情報を直に取得し、そして失敗します。 <serialize-byte-array-to-oracle-blob> が、永続性の動作をコントロールするために追加されています。 この要素を使用すると、OracleBlob にマップされた byte[] 型の cmp-field がシリアライズされるべきかどうかを指定できます。 このタグは、weblogic-cmp-rdbms 記述子の新しい互換性スタンザに追加されています。 SP2 より前のバージョンでは、OracleBlob にマップされた byte[] 型の cmp-field をシリアライズするのがデフォルトの動作でした。 現在は、byte[] は BLOB から取得された OutputStream に直接書き込まれます。 以前の動作に戻すには、このタグの値を true に設定します。
CR113161、CR12220、CR110917	サーバのコアにあるクラスタ化可能なステートフル EJB で発生したメモリ リークは、コードの変更により解決されました。
CR116696、CR121886	byte[] データが 4K より大きい場合、preparedStatement の setBytes() メソッドに問題がありました。 setBinaryStream() メソッドを setBytes() メソッドで置き換えることで、この問題を解決しました。 その結果、cmp11 で生成されるコードが変わりました。 この修正を利用するユーザは、EJB に対して ejbc を再実行し、新しいコードを生成する必要があります。 新しいコードを生成しないと、この変更の効果はありません。
CR120450	CMP-field と CMR-field を同じカラムにマップしたときに java.lang.IndexOutOfBoundsException が発生しました。 コードを変更してこの問題を解決しました。
CR121378	WebLogic Server 7.0 SP03 で、Bean 管理による永続性 (BMP) EJB を使用する場合、BMP Bean を使用して flushModifiedBeans を試行したときに ClassCastException が発生しました。 <Aug 25, 2003 9:39:35 AM EDT> <Info> <EJB> <010040> <Exception in ejbStore: java.lang.ClassCastException: com.logica.mdch.morse.business.meterpoints.MeterPointXBean_vm8ya9_Impl java.lang.ClassCastException: com.logica.mdch.morse.business.meterpoints.MeterPointXBean_vm8ya9_Impl at weblogic.ejb20.manager.ExclusiveEntityManager.flushModified(ExclusiveEntityM anager.java:693) at weblogic.ejb20.internal.TxManager$TxListener.flushModifiedKeys(TxManager.jav a:749) at weblogic.ejb20.internal.TxManager.flushModifiedBeans(TxManager.java:329) at weblogic.ejb20.manager.BaseEntityManager.flushModifiedBeans(BaseEntityManage r.java:1644) at 分析の結果、他の EJB とのトランザクションに関与している Exclusive 同時方式の BMP が、ファインダを実行する前に、変更された Bean をデータベースと同期させているときに、例外が発生したことがわかりました。 ExclusiveEntityManger の flushModified のコードでは BMP の場合を考慮せず、デフォルトとしてコンテナ管理による永続性を想定していました。 ClasscastException を回避できるように問題を解決しました。 変更の結果、TX の内部で Bean に対してファインダが呼び出されるときに、BMP EJB の ejbStore メソッドがトランザクションで複数回呼び出される可能性があります。 ユーザ コードでは、トランザクションにおける ejbStore の複数の呼び出しに対応する必要があります。
CR122052、CR110440、CR121949、CR132495	組み合わせキャッシュ (アプリケーション レベルのキャッシュ) を使用するエンティティ キャッシュのタイムアウトに関して、いずれかの Bean の idle-timeout-seconds が 0 に設定されていてる場合、idle-timeout-seconds > 0 に設定されている他の Bean も、タイムアウト後にキャッシュから削除されません。 idle-timeout-seconds の登録に関するコードを変更することで、問題を解決しました。
CR123213	BMP ejbRemove から呼び出された場合に、ステートレス セッション Bean がフリー プールに返されませんでした。 その結果、プールは最大サイズに達し、インスタンスの取得中にタイムアウトしました。 コードを変更してこの問題を解決しました。

JCOM

変更要求番号	説明
CR095485	COM オブジェクトがロード中にクローズされると、ソケットが CLOSE_WAIT 状態のままになる可能性がありました。 ソケットが endOfStream でクローズされるようになりました。

JDBC

変更要求番号	説明
CR120455	WebLogic Server 6.1 サービス パック 2 でメモリ リークが検出されました。 このリークは、WebLogic XAドライバと共に使用しているデータベースの BLOB カラムへのアクセスに TxDataSource を使用した場合に発生していました。 この問題は、コードを修正して解決されました。
CR127460	rmi_jndi および rmi_driver 層での WebLogic Server jDriver for Oracle バージョン 817、901 および 920 に関して、JDBCHelper クラスを終了する際の接続で複数の ClassCastExceptions が送出されました。 コードを変更して問題を解決しました。
CR126511	Oracle OCI NativeXA では、接続が作成されたスレッド以外のスレッドがその接続を使用することはできません。 WebLogic Server の接続プール アルゴリズムは、どのスレッドでも接続を使用できることを前提としていました。 以前の WebLogic Server 接続プール アルゴリズムで Oracle OCI NativeXA を使用すると、XAException を受け取りました。 コードを変更して、WebLogic Server 8.1 から PinnedToThread 接続プール アルゴリズムをバックポートし、どのスレッドもすべての接続プールに対する独自の接続を保持できるように、接続をスレッドに固定できるようになりました。
CR108826	現在のマルチプールは時間に基づくフェイルオーバを定義するオプションを提供していません。 望ましいのは、セカンダリ接続プールへのフェイルオーバがトリガされるような状況です。 フェイルオーバがプール内のすべての接続に対して行われてから、プールは正常な接続がないと判断します。 ネットワークの障害を回避するために、10 分間ですべてのチェックが失敗したらセカンダリ データベースにフェイルオーバするような、時間に基づくオプションが求められます。 プライマリが正常な状態になったらプライマリにフェイルバックできるフェイルバック メカニズムも必要です。 たとえば、セカンダリがリモート データセンタにある場合、リモートで実行するときは応答時間が長くなります。プライマリ データベースが停止しているときは対応できますが、プライマリがバックアップされたときは対応しません。 つまり、プライマリ データベースが停止した場合は、セカンダリ データベースへ接続をフェイルオーバする前に、xx 時間待機する必要があります。 プライマリ データベースが使用可能になっても、指定するまでプライマリに戻るべきではありません。 処理内容を指定するオプションや実行時チェックを用意し、これらのフラグが有効な場合はプライマリに戻るなどの処理を行うことがきます。
CR130306、CR135909	jta.DataSource で refreshAndEnlist を実行するときに、WebLogic Server は tx.enlist() を呼び出しましたが、refreshAndEnlist 呼び出しで例外が発生すると、接続はプールに返されませんでした。 例外を捕捉し、接続をプールに解放するようにコードを変更しています。
CR129379	EJB トランザクションが多数の新しいエンティティを作成するか、JDBC を使用する多数の Bean に関与した場合、WebLogic Server では Oracle カーソルが不足する危険が生じました。予期される Oracle ドライバのバグを回避しようとして、WebLogic Server がトランザクションの終了まで JDBC 文のクローズを遅延し、その文のカーソルを保持していたためです。 この動作は変更されて、トランザクションが終了するまでセッションがカーソルを保持する必要はなくなりました。
CR127949、CR131743	Statement.getResultSet() が不要な新しい ResultSet ラッパを生成することがありました。 コードを変更して問題を解決しました。
CR127720	新しいバージョンの JDBC ドライバは接続のトランザクション状態を追跡します。 ある接続でローカル トランザクションがアクティブな場合、XA 操作を実行できないため、その接続に対して xa_start() を呼び出すと、XAER_PROTO または XAER_RMERR が発生しました。 その結果、アプリケーションは、ローカル トランザクションが開始されたものの終了しなかった箇所を、コード内で絞り込むという面倒な処理を行わなければなりませんでした。 回復メソッドで、特別な XA 接続がプールに 2 度解放されるのを防ぐようにコードを変更することで、問題を解決しました。
CR126808	それぞれアプリケーション スコープのデータソースを持つ 2 つのアプリケーションが同じサーバにデプロイされていて、データソースが同じ名前である場合、InstanceAlreadyExistsException が送出されました。 必要に応じて、プール名をアプリケーション固有の名前にコンフィグレーションするコードを追加しました。
CR133835	文または結果セットが閉じられていない場合、ガベージ コレクションされるときに、必要な場合は finalize() メソッドがそれらを閉じます。 必要性のテストには、接続が既に閉じられていた場合に役に立たない例外を送出するメソッドが含まれていました。 例外は送出されなくなりました。
CR099363	負荷テストにおいて、接続プールの更新間隔が 15 分に設定されていて、予約時の接続テストとリリース時の接続テストが false に設定されているときに、その JDBC 接続プールは weblogic.common.ResourceException: No available connections in pool 例外を送出しました。 この問題は、プール内の接続の一部だけが使用されていると、その他の接続はすべて、コンフィグレーションされた更新テスト間隔が経過した時点でのテスト用に予約されてしまうために発生しました。 コードを変更して、この状況を解決する新しいアルゴリズムを実装しました。
CR103603	DatabaseMetaData meta = dbCon.getMetaData();ResultSet rs = meta.getColumns(null,meta.getUserName(),"dual".toUpperCase(),"%"); を ユーザ トランザクションまたはトランザクション対応 EJB で呼び出す場合、接続が閉じられるときに ResultSet が明示的に閉じられない場合、以降の呼び出しでは Oracle データベース カーソルをリークします。 カーソルはサーバが停止するまで保持されて、データベースがカーソル不足になるリスクが生じます。 WebLogic Server は接続を閉じるときに ResultSet を明示的に閉じるようになりました。
CR108478	Oracle 920 thin ドライバを使用する 2 つの JDBC 接続プールが含まれるコンフィグレーションで、1 つ (非 XA) は JMSJDBCStore 用に、もう 1 つ (XA) はデータ挿入用に使用する場合、グローバル トランザクション中にクライアントが JMS キューとデータベースにメッセージを置きました。 クライアントはこのアクションを繰り返し処理してから終了しました。 この後、クラッシュ (kill -9 または System.exit()) 後に WebLogic Server を再起動すると、クライアントがグローバル トランザクションを再び開始するときに、次の例外が送出されます。 Unknown Exception during dataInsert java.sql.SQLException: XA error: XAER_PROTO より強力なエラー処理コードを追加して、回復動作を修正しました。
CR108826	WebLogic Server 7.0SP5 では、マルチプールに以下の拡張が施されました。 接続要求のルーティングの改良。 失敗した接続プールが回復したときの自動フェイルバック。 マルチプール内の使用中の接続プールのフェイルオーバ。 マルチプールに対するフェイルオーバおよびフェイルバック コールバック。 詳細については、『WebLogic JDBC プログラマーズ ガイド』の「マルチプールのフェイルオーバの拡張」を参照してください。
CR110486	リモート クライアントは JDBC 接続の Prepared Statement キャッシュをクリアできるようになりました。 以前は、weblogic.jdbc.rmi.SerialConnection クラスのオブジェクトは WLConnection を実装していませんでした。したがって、リモート クライアントは clearPrepareStatementCache() メソッドを呼び出すことができませんでした。 この制限は、コードを変更して修正されました。
CR112295	マルチプールの DataSource を管理サーバにデプロイできましたが、管理対象サーバへのデプロイは失敗して、次の ResourceException が発生しました。 weblogic.common.ResourceException: DataSource(multiDataSource) can't be created with non-existent Pool (connection or multi) (multiPool) at weblogic.jdbc.common.internal.DataSourceManager.createDataSource(DataSourceManager.java:251) at weblogic.jdbc.common.internal.DataSourceManager.createAndStartDataSource(DataSourceManager.java:106) at weblogic.jdbc.common.internal.JDBCService.addDeployment(JDBCService.java:190) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:330) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployments(DeploymentTarget.java:590) at weblogic.management.mbeans.custom.DeploymentTarget.updateServerDeployments(DeploymentTarget.java:568) at weblogic.management.mbeans.custom.DeploymentTarget.updateDeployments(DeploymentTarget.java:240) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at ... 分析の結果、DataSourceManager.validateConnectionPool() メソッドの間に例外が発生したことがわかりました。この問題は、コードを修正して解決されました。
CR117729	weblogic.JTAJDBC が有効になっている場合、WebLogic Server はドライバのベンダとバージョンを次のように出力します。 <Aug 5, 2003 3:22:55 PM PDT> <Debug> <JDBC XA> <000000> < -tx:null- -pool:OracleThinXAPool- Vendor:Oracle 8.1.7 XA> Oracle の場合、WebLogic Server は実際のバージョンに関係なく、バージョンを「Vendor:Oracle8.1.7 XA」と出力しました。 コードを変更して問題を解決しました。
CR120531、CR126189	WebLogic Server 7.0 の以前のサービス パックでは、接続が既に解放されている場合に、weblogic.Admin RESET_POOL (または相当する API) を使用して接続プールをリセットすると、次のような例外が発生しました。 <Aug 13, 2003 1:33:11 PM EST> <Error> <HTTP> <[WebAppServletContext(7096795,jdbc_webapp,/jdbc_webapp)] Servlet failed with Exception java.lang.Error: 1 Was already released:weblogic.jdbc.common.internal.Connection ガベージ コレクションの後、サーバは次のような接続リークの警告を 表示しました。 <Aug 13, 2003 1:33:19 PM EST> <Warning> <JDBC> <A JDBC pool connection leak was detected. A Connection leak occurs when a connection obtained from the pool was not closed explicitly by calling close() and then was disposed by the garbage collector and returned to the connection pool. The following stack trace at create shows where the leaked connection was created. Stack trace at connection create: at weblogic.jdbc.pool.Connection.<init>(Connection.java:55) at [...] 接続リークの警告がなくなるようにコードを修正しました。プールをリセットするときに接続が既に解放されている場合は、サーバは今後も前述のエラーを適切に表示します。
CR120971	標準の JDBC 呼び出しに JTS 接続を使用する前に、ベンダ接続を取得する場合、jts.Connection.getVendorConnection() メソッドは null を返しました。 すべての標準呼び出しは基底の接続を確立しましたが、getVendorConnection() は確立しませんでした。 この問題は、コードを修正して解決されました。
CR127891	接続リーク ファイルの形式を変更して情報を読みやすくしました。
CR131575、CR132652	WebLogic Server は JDBC 接続リークについて警告する、次のコードで始まるバグを送出することがありました。 [SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n この警告を送信したリーク検出コードは使用されなくなりました。コードを変更してこの問題を解決しました。

jDriver

変更要求番号	説明
CR125135	デフォルトでは、WebLogic jDriver for Oracle/XA データソースの oracleXATrace パラメータの値は false ではなく true に設定されています。 このため、config.xml で oracleXATrace=?false? を設定してトレース ファイルを特に無効にしない限り、ドライバは時間がたつとサイズが大きくなる xa_poolname*.trc の形式でトレース ファイルを作成します。 値が指定されていない場合は oracleXATrace のデフォルト値を false に設定するようにコードを修正しました。
CR129220	WebLogic Server Oracle jDriver はガベージ コレクションで Clob オブジェクトを適切に解放しませんでした。 コードを変更してこの問題を解決しました。
CR113462	Oracle の NLS_LANG を設定した環境で BigDecimal 型を使用する場合に、WebLogic Server は NumberFormatException を送出しました。 この問題は、アメリカ式の数字の定義に合わせるために Oracle の NLS_NUMERIC_CHARACTERS パラメータを使用する場合は発生しませんでした。この問題は、コードを修正して解決されました。

JMS

変更要求番号	説明
CR135798	トランザクション MDB の場合にメッセージング パイプラインが適切に管理されていませんでした。 優先順位の高い新しいメッセージがキューに到達した場合、既にパイプラインにあるメッセージは発信されませんでした。 そのため、目的の動作を実現するには、メッセージ パイプラインのサイズを最小限に抑えることが重要でした。 トランザクション MDB からの確認応答の際に、ウィンドウ数をデクリメントするようにコードを修正しました。 トランザクション MDB のメッセージング パイプラインは MessagesMaximum 設定を受け付けます。
CR110120	ある管理対象サーバから別の管理対象サーバに JMS サーバを移行し、メッセージを送信した後で、その JMS サーバを最初の管理対象サーバに再び移行すると、次のような例外が発生しました。 <Jun 23, 2003 4:18:49 PM EDT> <Error> <JMS> <040366> <JMS Distributed Destination member "S2_BE1_T1" in "DT1" unable to accept connection from remote member "S1_BE1_T1" due to exception weblogic.jms.common.JMSException: Failed to setup system subscription because destination S2_BE1_T1 is not avaiable (shutdown, suspended or deleted). <Jun 23, 2003 4:19:54 PM EDT> <Error> <JMS> <040366> <JMS Distributed Destination member "S1_BE1_T1" in "DT1" unable to accept connection from remote member "S2_BE1_T1" due to exception weblogic.jms.common.JMSException: Consumer already exists 分析の結果、JMS が複数の WebLogic Server Aggregatable オブジェクトを 1 つのサーバ インスタンスに内部的にバインドする一方で、WebLogic Server JNDI は 1 つのサーバにつき 1 つの Aggregatable のみを想定しており、その結果、最初の JMS Aggregatable が 2 番目の JMS Aggregatable で置き換えられたことがわかりました。 WebLogic Server JNDI では、この状況に対処する JMS の内部的な API が提供されるようになったため、すべてのオブジェクトが保持されます。
CR132606	同じ WLS サーバにある分散トピック メンバーに対して、コンソールの保留中メッセージのカウンタが間違っていました。 リモートの分散トピック メンバーに対するカウンタは適切でした。 他の非リモート分散トピック メンバーに転送する場合に、分散トピック参照のカウントを適切に管理するようにコードを変更しました。 すべてのメッセージが正常に受信および応答確認された後で、分散トピック メンバーの予期しない保留中メッセージが表示されることはなくなりました。
CR128596	分散送り先を使用したブリッジを介して 7.0 SP2 クラスタから 8.1 SP2 クラスタへメッセージを送信する場合に、8.1 SP2 クラスタのいずれかのサーバからバウンスされると、メッセージ フローが滞留することがありました。 コードを変更してこの問題を解決しました。
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 start および stop メソッドは、MessagingBridge の実行時の起動および停止方法を提供する例外を送出するようになりました。
CR126183	最大アイドル時間の設定を過ぎた後に、アイドル状態のブリッジがメッセージをロギングしていました。 アイドル状態のブリッジによってロギングされる「Bridge X start transferring messages」という繰り返しのログ メッセージを抑制するコードを追加しました。 ブリッジを停止して再起動したり、例外が発生してブリッジを再起動したりする場合、「Bridge "bridgename" starts transferring messages」というログ メッセージが表示されますが、アイドル状態のブリッジによってメッセージが繰り返しロギングされることはありません。
CR125693、CR092468	JMSConnectionFactoryMBean の flowMinimum 属性の有効な最小値が 1 に変更されました。したがって、整合性を保つために、flowMaximum 属性の有効な最小値も 1 に変更されました。
CR133155	WebLogic Server は起動時に JDBC ストアから JMS メッセージを回復するのに時間がかかり過ぎました。 getTables プリフィックスに JMS を含めることで問題を解決しました。
CR103001、CR127436	メッセージング ブリッジ送り先をホストしているサーバが利用できない場合に、WebLogic Server は長過ぎる例外を表示しました。 短い例外メッセージを表示するようにコードを修正しました。
CR107729、CR113714、CR124985	コンシューマのない送り先で期限切れのメッセージが蓄積する問題は、コードを変更してアクティブなメッセージ有効期限のサポートを追加することで解決しました。 この機能を使用すると、コンシューマを持たない送り先から期限切れメッセージを削除できます。 アクティブなメッセージ有効期限を有効にするには、スキャンの間にシステム プロパティ -Dweblogic.jms.ExpirationScanIntervalSecs="number of second(s)" を使用します。 ゼロおよび負の数を指定するとこの機能は無効になります。
CR108665	JMS サーバは、キュー ブラウザの参照リストにまだあるかどうかに関係なく、期限切れのページアウト メッセージを永続ストアから削除することがありました。 その結果、多くのメッセージが列挙値リストでまだ使用可能である場合でも、ページング IO 例外により列挙値の処理が終了することがありました。 コードの変更によってページングの処理が改良され、問題は解決されました。
CR111159	JMS のフロントエンドとバックエンドが同じ場所になく、フロントエンドの FEProducerSendRequest が Failure/JMSException を受け取った後で、別のスレッドで FEProducerFiniteStateMachine を再開すると、フェイルオーバされません。 分析の結果、プロデューサ ロード バランサが送り先メンバーを選択するものの、メッセージを送り先に追加しようとするとバックエンドが例外を送出する場合、フロントエンドは例外を適切に処理せず、送信先として別の分散送り先メンバーを選択しました。 フロントエンド プロデューサがバックエンドから例外を捕捉して、使用可能な別の分散送り先メンバーを選択して再試行するようにコードを変更することで、問題を解決しました。 他のメンバーが使用可能でない場合は、送信側アプリケーションに例外が返されます。
CR110991、CR117044	JMSServerRuntimeMBean のメソッド getHealthState はパブリック メソッドではなくなりました。
CR112845	クライアントとフロント エンド (JMS 接続ファクトリが割り当てられているサーバ) が同じ場所にあり、JMS 分散送り先メンバーが別の VM 上にある場合、JMS ディスパッチャは JMS 送信操作のフェイルオーバを処理できませんでした。 コードを変更してこの問題を解決しました。
CR120619	JMS テンプレートを持つ JMS サーバからすべての対象を削除して、JMS サーバに再び割り当てようとすると、WebLogic Server は例外を送出しました。 <Aug 13, 2003 4:50:58 PM PDT> <Error> <JMS> <Failed to deploy JMS Server "server_name" due to weblogic.jms.common.JMSException: Error initializing JMSServer server_name. weblogic.jms.common.JMSException: Error initializing JMSServer server_name at weblogic.jms.backend.BackEnd.initialize(BackEnd.java:448) at weblogic.jms.JMSService.createBackEnd(JMSService.java:906) at weblogic.jms.JMSService.addJMSServer(JMSService.java:1273) at weblogic.jms.JMSService.addDeployment(JMSService.java:1169) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:364) at weblogic.management.mbeans.custom.DeploymentTarget.addDeployment(DeploymentTarget.java:150) at java.lang.reflect.Method.invoke(Native Method) [...] JMS サービスが一時的送り先ファクトリを RMI ランタイムにエクスポートし、ファクトリが JNDI からアンバインドされるときにファクトリ参照が削除されなかったために、この問題が発生しました。 ファクトリがアンバインドされるときに一時的送り先ファクトリの参照が削除されるようにコードを修正しました。 JMS テンプレートを持つ JMS サーバの対象を削除して再び割り当てても例外が発生しなくなりました。
CR121011、CR131700	ストアにメッセージが格納されていて、そのメッセージの ReplyTo が分散送り先であり、ストアと同じクラスタにない場合、JMSServer の再起動時に NPE が発生します。 ドメイン間通信に MessagingBridge を使用する WebLogic Server が 2 つありました。 送信側アプリケーションが JMSReplyTo フィールドを ドメイン 1 にある DistributedDestination に設定した後、メッセージがブリッジ経由で送信され、ドメイン 2 にある JMSStore に到着しました。 ドメイン 2 にある JMSServer を再起動すると、JMS はストアに書き込まれた分散送り先メンバー インスタンスの configMBeanName を検索しようとしましたが、この名前はドメイン 1 に属しているので見つかりませんでした。 ここで障害が発生しました。 ログには次のようなメッセージが含まれていました。 ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <hwbachp> <managed5_hwbwl98> <main> <kernel identity> <> <040108> <User connection factory "BridgeJMSnnn" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <nnn> <managed5_nnnn> <main> <kernel identity> <> <040108> <User connection factory "Wnnn_JMSConnectionFactory" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <nnn> <managed5_nnnn> <main> <kernel identity> <> <040108> <User connection factory "nnnQueueFactory" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <hwbachp> <managed5_hwbwl98> <main> <kernel identity> <> <040108> <User connection factory "WLI_B2B_TopicFactory" is started.> ####<Aug 7, 2003 1:36:13 PM BST> <Info> <JMS> <hnnn> <managed5_nnnn> <main> <kernel identity> <> <040108> <User connection factory "RNQueueFactory" is started.> JMS が configMBeanName を見つけられない場合、そのインスタンス名を使用して replyTo フィールドの DestinationImpl (非 DD キュー) を作成するようにコードを変更して、問題を解決しました。 replyTo キューは、分散送り先からこのシナリオの通常の送り先にダウングレードされました。 変更後の動作 : サーバの再起動時にメッセージがストア内にあり、そのメッセージには a) ReplyTo がある、b) この ReplyTo はこのストアが属するクラスタと同じクラスタにはない、c) この ReplyTo は分散送り先である場合、この ReplyTo は通常の送り先として組み込まれます。 configMBeanName が (別のクラスタから) 見つからないために replyTo が分散送り先から通常の送り先にダウングレードされるので、この replyTo を使用するクライアントは LoadBalancing を取得しません。
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 und erlying 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 ストアがなかったため、メッセージ リスナの作成に失敗したことがわかりました。 リソース例外をログに記録しようとすると、ブリッジで内部エラーが発生したため、ユーザはブリッジが失敗した理由を確認できませんでした。 ブリッジが適切なリソース例外を送出できるようにコードを変更して、問題を解決しました。 現在はブリッジによって正しい例外がロギングされます。 <Aug 27, 2003 9:32:35 AM CDT> <Warning> <MessagingBridge> <200026> <Bridge "TopicBridge" 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 java.lang.Exception: javax.resource.ResourceException: Error setting message listener . . . . . . -------------- Linked Exception ------------ javax.resource.ResourceException: Error creating asynchronous consumer or setting message listener . . . . . . -------------- Linked Exception 2 ------------ weblogic.jms.common.JMSException: No store for durable consumer . . .
CR121741	MBean を使用して MQ-WLS ブリッジを停止しているときに矛盾した動作が起きました。 次の抜粋は停止で使用されたコードです。 MessagingBridgeMBean bridge = (MessagingBridgeMBean)mbeanHome. getAdminMBean(bridgeName, "MessagingBridge"); bridge.setStarted(false); for(int i=0;i<serverList.length;i++) { target=(TargetMBean) mbeanHome.getAdminMBean(serverList[i],"Target"); bridge.removeTarget(target); ブリッジの割り当てが解除されて、次の例外により停止することがありました。 <Aug 27, 2003 9:24:08 AM PDT> <Info> <MessagingBridge> <200034> <Bridge "reverseBridge" is shut down.> <Aug 27, 2003 9:24:08 AM PDT> <Error> <Connector> <190008> <Error closing connection instance for XA Transaction Resource Adapter.> javax.resource.spi.IllegalStateException: Managed connection is closed at weblogic.jms.adapter.JMSManagedConnection.checkIfDestroyed (JMSManagedConnection.java:263) at weblogic.jms.adapter.JMSManagedConnection.cleanup(JMSManagedConnection.java:128) at weblogic.connector.common.internal.XATransResourceFactory.cleanUp (XATransResourceFactory.java:325) at .... 分析の結果、MessagingBridge.shutdown() が MessagingBridge.cleanup() を呼び出した後、ソース接続に対する recover() を呼び出したことがわかりました。 Recover() はトランザクション セッションに対する有効な操作ではないため、例外が発生しました。 recover() を呼び出す前に、セッションがトランザクション セッションではないことを検証するように、コードの変更を実装しました。
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 を送信します。次の例外が送出されました。 javax.jms.InvalidDestinationException: Destination must be of class: com.wm.broker.jms.Destination at com.wm.broker.jms.Message.setJMSDestination(Message.java:896) at weblogic.jms.client.JMSProducer._send(JMSProducer.java:380) at weblogic.jms.client.JMSProducer.send(JMSProducer.java:172) at weblogic.jms.adapter.JMSBaseConnection.sendInternal(JMSBaseConnection.java:5 71) at weblogic.jms.adapter.JMSBaseConnection.send(JMSBaseConnection.java:528) at weblogic.jms.adapter.JMSConnectionHandle.send(JMSConnectionHandle.java:131) at java.lang.reflect.Method.invoke(Native Method) at weblogic.connector.common.internal.ConnectionWrapper.invoke(ConnectionWrappe r.java:101) at $Proxy115.send(Unknown Source) at weblogic.jms.bridge.internal.MessagingBridge.onMessageInternal(MessagingBrid ge.java:1160) at weblogic.jms.bridge.internal.MessagingBridge.onMessage(MessagingBridge.java: 1093) at com.wm.broker.jms.MessageConsumer.deliverMessage(MessageConsumer.java:682) at com.wm.broker.jms.Session$MessageDeliveryThread.run(Session.java:1431) WLS は 2 つの JMS 実装間にブリッジ機能を提供しており、要求はメッセージの確認応答を正しいタイプに変換することでした。 この要求は通常のメッセージに対しては適切に行われているようです。 分析の結果、標準の WebLogic JMS クライアントは送信する WebMethods メッセージを渡され、WebLogic 送り先を使用して WebMethods メッセージに対し setJMSDestination を呼び出そうとしたことがわかりました。このとき、WebMethods は InvalidDestinationException を送出しました。 InvalidDestinationException を捕捉して無視するようにコードを変更することで、問題を解決しました。
CR122749	キュー内のすべてのメッセージに JMSCorrelationID が設定されていない場合、DestinationKey JMSCorrelationID をキーにしてソートすると NullPointerException になる可能性がありました。 DestinationKey JMSType の場合にも同じ失敗が起きる可能性がありました。 compareTo を呼び出す前に、null の JMSCorrelationID と null の JMSTypes がないかどうかチェックするようにコードを変更しました。 その結果、ソートは NullPointerException を送出せずに適切に動作します。
CR123194	以前の WebLogic Server 7.0 サービス パックで、サーバ インスタンスが停止してもクライアントがアクティブな場合、JMS は JMS 仕様で想定される JMSException ではなく、実行時例外 weblogic.rmi.extensions.RemoteRuntimeException を送出しました。 サービス パック 5 でコードを変更して問題を解決しました。
CR123675	非恒久メッセージに対する最適化コードの問題が原因で、送り先が無効になることがありました。 そのため、負荷の大きな状況でメッセージをページアウトするときに、次のような例外が発生しました。 <Sep 12, 2003 9:54:12 PM EDT> <Error> <Kernel> <BEA-000802> <ExecuteRequest failed java.lang.NullPointerException. java.lang.NullPointerException at weblogic.jms.common.MessageImpl.writeExternal(MessageImpl.java:1622) at weblogic.jms.common.TextMessageImpl.writeExternal(TextMessageImpl.java:92) at weblogic.jms.store.ObjectIOBypassImpl.writeObject(ObjectIOBypassImpl.java:155) at weblogic.jms.store.BufferDataOutputStream.writeObject(BufferDataOutputStream.java:175) at weblogic.jms.store.FileIOStream.write(FileIOStream.java:506) at weblogic.jms.store.StoreRequest.doTheIO(StoreRequest.java:282) at weblogic.jms.store.JMSStore.execute(JMSStore.java:493) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170) この問題は、コードを修正して解決されました。
CR128723、CR081630	コンシューマのロード バランサにおけるタイミングの問題が原因で、ServerAffinity を有効にすると、ローカル メンバーの方が適切な場合に、誤ってリモート メンバーを選択するという動作が起きました。 以前のサービス パックでは、ServerAffinity を有効にすると以下のプリファレンスが設定されます。 1) コンシューマを持たないローカル メンバーを取得する 2) ローカル メンバーを取得する 3) コンシューマを持たないリモート メンバーを取得する 4) リモート メンバーを取得する サービス パック 5 では、ServerAffinity を有効にすると以下のプリファレンスが設定されます。 1) コンシューマを持たないローカル メンバーを取得する 2) コンシューマを持たない任意のメンバーを取得する 3) ローカル メンバーを取得する 4) 任意のメンバーを取得する

JSP

変更要求番号	説明
CR172250	weblogic.jspc のプロパティには下位互換性がありませんでした。 weblogic.jspc の新しいコマンドライン フラグ backwardcompatible を追加しました。 true に設定すると、Web アプリケーションは WebLogic Server 6.ｘ 以前との下位互換性を維持してコンパイルされます。 新しい「backwardcompatibility」フラグを使用すると、WebLogic Server 6.ｘ と同じように Web アプリケーションをコンパイルできます。
CR133760	サーバは、「compilerclass」文字列ではなく「compilerClass」文字列を使用して、サーブレット コンフィグレーションから初期化パラメータを読み込もうとしました。 JSP 記述子要素は compilerclass であるため、JSPServlet はそれに応じて変更されました。 JSPServlet のコードに、メソッド config.getInitParameter("compilerClass") を config.getInitParameter("compilerclass") に変更するコードを追加しました。 そのため、JSP 記述子要素の「compilerclass」で対応されるようになりました。
CR093625	サーバが JSP ページの JSP include に対して出力を誤って送っていました。 コードの変更に従い、すべてのラッパーが削除された場合は isResponseWrapper がリセットされます (たとえば、すべてのラッパーが JSP 本文タグからの NestedBodyResponse ラッパーだった場合。ラッパーが weblogic.servlet.internal.RemoveWrapperOnForward を実装しているとき、それらは転送時に削除されるためです)。
CR127836	ルート コンテキストのサブコンテキストにある JSP は、展開形式ではなく、WAR ファイルにパッケージ化された Web アプリケーションとしてデプロイされている場合、プリコンパイルされました。 コードを変更してこの問題を解決しました。
CR126007	JSP が別の JSP から転送されたときに、マルチバイト文字列パラメータが失われました。 この問題は、パラメータ エンコーディングが EUC-JP または ISO2022JP で、POST メソッドによって送信された場合にのみ発生しました。 エンコーディングが変更されていない場合は POST パラメータを再解析しないようにコードを変更しました。
CR092039	JSP の文字セット値の周囲に余分な引用符がある場合、WebLogic Server は UnsupportedEncodingException を送出しました。 たとえば、次のタグは例外を引き起こしました。 <%@ page contentType="text/html; charset=¥"Shift_JIS¥"" %> この問題は、コードを修正して解決されました。
CR093520	あるタイムゾーンのマシンで JSP をプリコンパイルし、それと同じ JSP を別のタイムゾーンのサーバにデプロイする場合、WebLogic Server は JSP を再コンパイルすることがありました。 この問題は、WebLogic Server が、(JAR ユーティリティによって埋め込まれた) JSP のローカル タイムスタンプと、生成されたクラス ファイル内のタイムスタンプを比較して、JSP をチェックしたために発生しました。 コンパイル時にタイムゾーンを保存し、そのタイムゾーンをデプロイメント時に使用して再コンパイルが必要かどうかを決定することで、この問題を解決しました。
CR098514	JSP カスタム タグの属性にある文字列リテラルの途中で改行するとコンパイル エラーが発生しました。次に例を示します。 <%@ taglib prefix="c" uri="http://java.sun.com/jstl/core";; %> <c:if test="${ sessionScope.sessionID == null or sessionScope.dummy == null }"> There is no Session ID! </c:if> 上記のコードによって次のエラーが発生しました。 unclosed string literal _c_if0.setTest(weblogic.utils.StringUtils.valueOf("${ sessionScope.sessionID == null //[ /ifTest.jsp; Line: 17] JSP カスタム タグの属性値の中に改行文字を格納できるようにコードを変更することで、問題を解決しました。
CR104429、CR134313	WebLogic Server は、更新された JSP クラス ファイルが jspWorkingDir にコピーされた後で JSP ページを再コンパイルしました。 新しいパラメータ -Dweblogic.jsp.alwaysCheckDisk を true に設定すると、WebLogic Server は古くなった JSP クラスをディスクからチェックします。 このパラメータはデフォルトで false に設定されているため、デフォルトの動作は変更ありません。
CR111024、CR134046、CR111897	Cache タグを使用した次のフラグメントのある JSP で、 <wl:cache name="email_portlet" key="request.email_portlet_key" scope="session" timeout="60"> time=<%= new java.text.SimpleDateFormat("kk:mm:ss.SSS").format(new Date()) %><br> key=<%= key %><br> <% for (int i=0; i<100; i++) { // just a delay try { Thread.sleep(10); } catch (Exception e) { } } refreshed = true;%> 10 ユーザを同時にロードする場合、10 スレッドが weblogic.cache.CacheSystem.waitOnLock() でデッドロックしました。 コードを変更してこの問題を解決しました。
CR111423、CR127336	WAR ファイルにパッケージ化される場合、アプリケーションのサブコンテキストに格納されたプリコンパイル済み JSP が、WebLogic Server にデプロイされるときに常に再コンパイルされました。 JSP が展開されたアーカイブ ディレクトリからデプロイされる場合、または JSP が WAR ファイルのルート コンテキストにある場合は、この問題は発生しませんでした。 この問題は、jar および zip フォーマットで使用されるタイムスタンプの四捨五入動作の違いが原因で発生しました。 四捨五入の違いによって、WAR ファイル内のクラス ファイルで (1 秒差の) 古いタイムスタンプが記録され、サーバによるクラスの再コンパイルがトリガされました。 コンパイル済み JSP クラスのタイムスタンプを 1 秒進めるようにコードを修正しました。それによって、JSP は再コンパイルされなくなります。
CR111655	これまで、日本語文字を含む JSP では JavaServer Pages 標準タグ ライブラリ (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 属性で定義された文字エンコーディングを必ず使用するようにコードを変更して、問題を修正しました。
CR112794	適切に解析されていないコピーで JSP が更新されたため、デッドロックが発生しました。 JSP 更新中のチェックを追加するようにコードを変更することで、問題を解決しました。
CR117477	response.sendRedirect で、Content-Type が text/html ではなく text/plain にデフォルトで設定されました。 その結果、WebLogic Server は text/html Content-Type を必要とするコンテンツに対して 503 ステータスのページを返しました。 コードの変更後は、sendRedirect がアクティブになるまでは、Context-Type がまだ定義されていない場合 text/html がデフォルトのタイプになります。 この変更後は、text/plain Content-Type に依存している受信者は失敗することに注意してください。
CR120914	WebLogic Server のフォーム検証タグ ライブラリを使用する場合、以降の JSP でリクエスト パラメータが使用できませんでした。この問題は、コードを修正して解決されました。
CR123520、CR106226	WebLogic Server 7.0 サービス パック 4 で、JSP 本体タグで PageContext.include() または forward() メソッドが使用され、インクルードまたは転送されるサーブレットで HttpServletResponse.getOutputStream() が呼び出されると、次の例外が発生しました。 java.lang.IllegalStateException: Cannot use ServletOutputStream because a Writer is being used. Use getWriter() instead. このインクルード要求はおそらく JSP 本体タグにネストされていました。 コードを変更して問題を解決しました。

JTA

変更要求番号	説明
CR111475	JTARuntime MBean は、調整を行っていないサーバについての統計値をインクリメントしていました。 トランザクションを開始し、管理対象サーバにあるリソースを取得して (その管理対象サーバをコーディネータとする)、次に管理サーバにあるリソースを取得し、トランザクションをコミットすると、両方のサーバの JTARuntime MBean が TransactionTotalCount として 1 を返しました。 コードの変更により、WebLogic Server は調整を行っているサーバについての統計のみを更新するようになりました。
CR122842	新しいリソースを古いリソースと同じ名前で登録する場合、以降の XA トランザクション処理を新しいリソースに対して行うことができませんでした。 元のリソースにアクセスしようとし続けました。 同じ名前の 2 番目のリソースに置き換えられるようにコードを追加しました。
CR127412	PinnedToThread が有効になっている場合、または Oracle OCI NativeXA ドライバを使用する場合、アプリケーションは接続を取得できませんでした。 この問題は、コードを変更して解決されました。
CR113226	リソース名が 64 文字を超える場合、WebLogic Server は接続プールのテスト中に次の例外を送出する可能性がありました。 java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occurred in the transaction branch start() failed on resource 'weblogic.jdbc.jta.DataSource' null at weblogic.jdbc.jta.DataSource.enlist(DataSource.java:1167) at weblogic.jdbc.jta.DataSource.refreshXAConnAndEnlist(DataSource.java:1133) at weblogic.jdbc.jta.Connection.getXAConn(Connection.java:153) at weblogic.jdbc.jta.Connection.prepareStatement(Connection.java:241) [...] この問題は、最初の 64 文字だけがユニークかどうかをテストされたために発生しました。 64 文字より長いリソース名を適切に処理するようにコードを変更しました。
CR134081	unregister の呼び出しやリソースの障害によってリソース アダプタが登録解除されると、そのリソース アダプタを対象とするすべてのトランザクション処理が失敗します。 サービス パック 5 からは、同じ名前の 2 つ目のリソースアダプタが登録される場合、最初のリソース アダプタを対象としていたすべてのトランザクションは、2 つ目のリソース アダプタ上で動作するようになりました。
CR126201	複数サーバのドメインで、別のアドレスまたはポート番号を使用するために管理対象サーバを再起動すると、JTA サブシステムはアドレス情報の更新に失敗しました。 変更後のサーバを再起動すると次の例外が発生しました。 javax.naming.CommunicationException. Root exception is java.net.ConnectException: t3://ip_address:port_number: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused; No available router to destination [...] アドレスまたはポートの変更に応じて、新しいアドレス情報を管理サーバから取得するようにコードを修正しました。

ノード マネージャ

変更要求番号	説明
CR104285、CR124729	ノード マネージャの共有オブジェクト コードは、サーバ インスタンスの起動時に特定のコード パスがとられたときにセグメント違反を引き起こすことがありました。 IBM の zLinux JDK を使用したときにも同じコード パスで問題が発生していました。 これらの問題は、ノード マネージャのコード修正により解決しました。
CR127930	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_51.00.jsp のセキュリティ勧告に関する情報を確認してください。
CR125829	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp のセキュリティ勧告に関する情報を確認してください。

操作と管理

変更要求番号	説明
CR099488	WebLogic Server は管理ポートの URL を誤って計算していました。 最初に管理ポート (有効な場合) に基づいて、次に管理チャネル (有効な場合) に基づいて、URL が正しく計算されるようにコードを変更しました。
CR128713	JMSQueue の ErrorDestination を設定するときに、ユーザは beanshell 例外を受け取ることがありました。 特定の状況では JMSQueue に親が設定されませんでした。リーガル チェックは親を使用するため、ErrorDestination の設定は失敗しました。 チェックのために JMSQueue の名前から親の JMSServer を取得するコードを追加して、リーガル チェックを修正しました。
CR134167	EXISTS_POOL が予期されるとおりに動作しませんでした。 プールが存在していても、存在する場合もしない場合もある実行時 MBean を探していました。 文書化されていないコマンド DELETE_POOL は接続プールを削除する内部的な実装でしたが、この機能は外部に対して DESTROY_POOL として文書化されていました。 ヘルプ メニューには文書化されていないコマンドもいくつか表示されました。 EXISTS_POOL コマンド実装は、コンフィグレーション MBean を探して、プールが存在するかどうかをチェックするようになりました。 DESTROY_POOL コマンドは基底の DELETE_POOL 実装を使用するようになりました。 weblogic.Admin ヘルプ メニューに表示されていた文書化されていないコマンドはすべて無効になりました。 コマンドには TEST_POOL、REMOVE_POOL、SUSPEND_POOL、SHUTDOWN_POOL、RESUME_POOL、DELETE_POOL があります。 これらは今後サポートされず、7.0 SP5 では動作しません。 ヘルプ メニューにこれらのコマンドは表示されなくなりました。
CR136210	パラメータを渡す必要がある場合に、コードは runAs を実行しようとしました。 スタックにパラメータを渡す代わりに、コードはパラメータをオブジェクト変数に隠そうとしました。 また、トークン方式を使用して、runAs() から呼び出すログ メソッドを特定しようとしました。 これらのオブジェクト変数は同期化されませんでした。 その結果、同じメッセージが何度もログに記録されることがありました。 コードをより明確でスレッド セーフにする匿名の内部クラスを使用するように、コードを変更しました。 ログ ハンドラのコードはログ ファイルに書き込むために同期化されました。
CR130441	dev2dev のサンプル セキュリティ プロバイダは、7.0 の以前のサービス パックでは正常に機能しませんでした。 サンプルをビルドするときに、サーバを起動してドメインを設定しようとすると、多数の javax.management.MBeanException エラーを受け取りました。 サーバが「commotype」を管理ツールに対するフラグと見なせるように、コードを変更しました。
CR101109	クラスタ内の管理対象サーバに対する JDBC ロギングを有効にすると、コンソールは起動時にエラーを表示しました。 このエラーは JDBC ロギングに影響を与えず、JDBC ロギングは適切に動作しました。 コードを追加して、管理対象サーバでのサーバ デバッグ メッセージのロギングを修正しました。
CR121228	ユーザ ID が監査ログ メッセージに記録されるようになりました。
CR121216	DomainMBean.AdministrationMBeanAuditingEnabled 属性の @exclude および @non-configurable タグが削除されました。
CR132445	weblogic.Admin はデフォルト URL で適切に動作しませんでした。次に例を示します。 java weblogic.Admin -username ss -password ss VERSION 上記のコマンドは結果を返しませんでしたが、-url t3://localhost:7001 を追加すると正しい結果を返しました。 コードの変更後、weblogic.Admin は入力 URL が null かどうかをチェックするようになりました。weblogic.Admin は既に内部的にデフォルト URL を持っているためです。
CR111199	管理サーバを起動して、2 つの管理対象サーバを同時に起動すると、CPU を大幅に消費しました。 一方の管理対象サーバが初期化を完了して、もう一方が初期化を開始すると停止しました。 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 へのスレッド アクセスを同期化するようにコードを変更して、問題に対応しました。
CR111287	Convert weblogic.properties ユーティリティは web.xml と weblogic.xml に DOCTYPE を追加しませんでした。 web.xml と weblogic.xml の先頭にそれぞれ次の文を追加するように、ユーティリティを修正しました。 <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd";> <!DOCTYPE weblogic-web-app PUBLIC "-//BEA Systems, Inc.//DTD Web Application 7.0//EN" "http://www.bea.com/servers/wls700/dtd/weblogic700-web-jar.dtd";> CONFIGURATION: WebLogic Server 7.0 SP2
CR120987	管理対象サーバのログが、指定された RootDirectory ではなく NodeManager のホーム ディレクトリ (NODEMGR_HOME) に誤って作成されました。 access.log および tlog ファイルは RootDirectory に正しく作成されました。 管理対象サーバのリモート スタートができるように、あるマシンで NodeManager がコンフィグレーションされていました。 コンソールにある管理対象サーバの [リモート スタート] タブで、管理対象サーバの RootDirectory とログの FileName が指定されました。 config.xml には管理対象サーバの次のスタンザが含まれていました。 <Server ExpectedToRun="true" ListenAddress="172.23.64.45" ListenPort="27023" Machine="MyMachine" Name="m1" ServerVersion="7.0.3.0" StdoutSeverityLevel="64"> <COM Name="m1"/> <ExecuteQueue Name="default" ThreadCount="15"/> <IIOP Name="m1"/> <JTAMigratableTarget Cluster="" Name="m1" UserPreferredServer="m1"/> <JTARecoveryService Name="m1"/> <KernelDebug Name="m1"/> <Log FileName="m1/m1.log" Name="m1"/> <SSL Name="m1"/> <ServerDebug Name="m1"/> <ServerStart Name="m1" OutputFile="/home/support/BEA/wlserver7.0sp3/user_projects/jay1/./NodeManagerClientLogs/jay1_m1/startserver_1061321008754.log" Password="{3DES}7v6S0vZT+xUhhbWkLEq23A==" RootDirectory="/home/support/BEA/wlserver7.0sp3/user_projects/jay1" Username="system"/> <WebServer Name="m1"/> </Server> この問題は、コードを変更して修正されました。
CR121839	コマンドラインから有効にする場合、DomainMBean インスタンスは監査状態を反映しませんでした。 -Dweblogic.AdministrationMBeanAuditingEnabled スイッチによってコマンドラインで MBean 監査を有効にすると、Domain MBean インスタンスでも、DomainConfig MBean インスタンスでも、属性が true に設定されていませんでした。 監査は有効になりましたが、MBean にその事実が反映されませんでした。 ドメインの MBean 属性をサーバ起動時にシステム プロパティから設定するようにコードを修正することで、問題を解決しました。
CR121728	機能強化 : カスタム認証プロバイダの MBean を、WL_HOME¥server¥lib¥mbeantypes ディレクトリにある WebLogic インストール ツリーの内部に配置する必要はなくなりました。 WL_HOME¥server¥lib¥mbeantypes は MBean タイプをインストールするためのデフォルト ディレクトリです。 ただし、WebLogic Server に追加のディレクトリで MBean タイプを検索させるには、サーバの起動時に -Dweblogic.alternateTypesDirectory=<dir> コマンドライン フラグを使用します。<dir> はディレクトリ名のカンマ区切りのリストです。 このフラグを使用する場合、WebLogic Server は常に、最初に WL_HOME¥server¥lib¥mbeantypes から MBean タイプをロードします。次に、追加のディレクトリを検索して、そのディレクトリにある有効なアーカイブを (拡張子に関係なく) すべてロードします。 たとえば、-Dweblogic.alternateTypesDirectory = dirX,dirY の場合、WebLogic Server は最初に WL_HOME¥server¥lib¥mbeantypes から MBean タイプをロードし、次に dirX および dirY にある有効なアーカイブをロードします。 このオプションを使用し続けないと、サーバを起動できなくなることに注意してください (たとえば、このオプションを使用してユーザを作成した後で、alternateTypesDirectory オプション使用しないことにした場合など)。 詳細については、『WebLogic Security サービスの開発』の「WebLogic Server 環境に MBean タイプをインストールする」を参照してください。
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 を登録解除します。
CR136718	「ルート ディレクトリ」のコンフィグレーションが、ノード マネージャを使用する場合に機能するようになりました。

プラグイン

変更要求番号	説明
CR134413	Apache プラグインが原因で、302 応答の http ヘッダと本文が重複していました。 プラグインとバックエンド サーバの間に問題はありませんでしたが、Apache サーバが 302 応答を追加していました。 request_handler メソッドの戻り値を OK に戻すコードが追加されました。
CR113033	以前のサービス パックでは、ISAPI プラグインが _wl_proxy フォルダの WLTempDir フラグを認識していませんでした。 このフラグを使用するようにコードが修正されました。
CR132699	アプリケーション サーバがダウンした場合に、Apache アクセス ログが 500 エラーを記録すべきところ、代わりに次のような 200 コードが返されていました。 [Mon Jan 05 12:58:21 2004] [notice] Apache/2.0.44 (Unix) configured -- resuming normal operations [Mon Jan 05 12:58:25 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:27 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:29 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:31 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:33 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 [Mon Jan 05 12:58:35 2004] [error] CONNECTION_REFUSED [os error=13, line 1566 of ../nsapi/URL.cpp]: 172.18.137.68:7232 errno = 115 この問題は解決済みです。
CR130060	IIS プラグインのパフォーマンス上の問題は、サービス パック 5 で、指定されたコンテンツ長と等しいデータが既に読み込まれているかどうかが確認されるようにするコード変更によって解決されています。
CR129471	以前のサービス パックでは、Apache プラグインは WLTempDir パラメータを認識していませんでした。 この問題は修正されています。
CR129342	ISAPI プラグインは、WL-PATH-TRIM 値の代わりに WL-PATH-TRIM HTTP ヘッダ値を WebLogic Server に送信していました。 コードを変更してこの問題を解決しました。
CR129138	NSAPI プラグインがバックエンドの WebLogic Server インスタンスで名前の解決を実行したときに、その名前の解決では sysGetHostByName が使用され、sysGetHostByName では getHostByName が呼び出され、getHostByName では開いているファイル記述子の数量制限がある内部メソッドが呼び出されて、名前の解決が失敗することがありました。 クッキー解析を修正し、JVMID を代用してプライマリ サーバおよびセカンダリ サーバを見つけるようにすることで、この問題は解決しました。
CR129026、CR129323	ISAPI プラグインのメモリ リークが、コードの変更で修正されました。
CR127973	サーブレット セッションに永続クッキーを追加した後で、ISAPI プラグインが失敗することがありました。 クッキー解析コードを修正して問題は解決されました。
CR127658	プールから接続を取得しても、サーバ インスタンスが既にその接続を閉じている場合は、HALF_OPEN_SOCKET_RETRY 例外が送出されて、前の接続オブジェクトが削除され、同じサーバに接続する新しいオブジェクトが作成されていました。 この問題は、HALF_OPEN_SOCKET_RETRY 例外を適切に処理するコードを追加することで解決しました。
CR127231	503 HTTP ステータスを受信した後に、リクエストがクラスタ内の次に利用可能なサーバにフェイルオーバされていませんでした。 READ_ERROR_FROM_SERVER 例外または CONNECTION_REFUSED 例外が送出されるまで、同じサーバで繰り返し試行されていました。 503 HTTP ステータス エラーを取得した時点でサーバに「bad」とマークし、次に利用可能なサーバを取得して、リクエストを再送信するコードが追加されました。 現在は、すべてのリクエストが次に利用可能なサーバに正常にフェイルオーバされます。
CR132840	アプリケーション サーバがダウンしたときに、Apache アクセス ログで 500 エラーではなく 200 コードが不適切に記録されていました。コードを変更してこの問題を解決しました。
CR135002	複数の仮想ホストがある Apache コンフィグレーションで、1 つの仮想ホストだけが WebLogic Server プラグインで SecureProxy=ON がコンフィグレーションされており、それ以外の仮想ホストでは SecureProxy または WLProxySSL が使用されない場合に、SSL がコンフィグレーションされていない仮想ホストで、プラグインがバックエンド WebLogic Server との SSL 接続を試行していました。 これが原因で、パフォーマンス上の問題が生じていました。 コードを変更してこの問題は解決しました。
CR112503	NSAPI プラグインではヘッダの文字比較で大文字と小文字が区別されていましたが、現在は区別されません。
CR123775、CR123120	Post メソッドを使用して Apache プラグイン経由でリクエストを転送すると、プラグインは content-length を 0 に設定し、wlproxy.log は次のメッセージを記録していました。 POST and PUT requests *must* contain a Content-Length この問題は、コードを修正して解決されました。
CR121726、CR121341	のセキュリティ勧告に関する情報を確認してください。
CR110991、CR117044、CR120970、CR120978	プライマリ サーバから PROTOCOL_ERROR メッセージを受信したリクエストは、次のようなメッセージも受信していました。 Mon Jun 30 21:52:57 2003 general list: trying connect to '10.84.133.182'/7305/7306 at line 1257 for .. このメッセージは、セカンダリ サーバではなく一般リストの別のサーバにフェイルオーバが適用されていることを示しています。 この問題は、コードを修正して解決されました。
CR126982	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> WebLogic Server にプロキシされ、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 サーバでリクエストの処理を継続できなければなりません。 この問題は、コードを修正して解決されました。
CR126568	NSAPI プラグインを通じて WebLogic Server に送信された、最後に %0A のある POST リクエストが、正常に処理されていませんでした。 このリクエストは本文のストリームに余計なデータを追加し、ヘッダが本文の最後に現れていました。 WebLogic Server に直に送信されたリクエストは、正確に処理されていました。 HTTP/0.9 応答を正確に検出および処理するようにプラグインのコードを修正することで、この問題は解決しました。
CR126103	負荷テストにおいて、HP11.00 上で動作する NSAPI が 2 台の Solaris マシンにまたがる 6 ノードのクラスタ (各マシンに 3 つの WebLogic Server インスタンス) にプロキシしているときに、メモリ消費が絶え間なく上昇し、約 50 分後に、ns-httpd プロセスがクラッシュしていました。 同じ負荷テストが、HP11.00 または Solaris ではクラッシュしませんでした。 分析の結果、プログラムのヒープ領域にシステム メモリを割り当てるネイティブのシステム呼び出し proxy.cpp used strdup() のコードに問題があることが判明しました。 WebLogic Server は、Iplanet の FREE マクロを使用して、不要になった割り当て済みの領域を解放します。 FREE では strdup() の呼び出しで割り当てられた領域が解放されないので、メモリ リークが発生していました。 この問題は、proxy.cpp のすべてのネイティブ strdup() システム呼び出しを Iplanet の STRDUP マクロで置換し、どの領域を解放するのか FREE マクロが指示されるようにすることで解決しました。
CR125690	9 つの IIS サーバとクラスタ化されている 9 つの WebLogic Server インスタンスが含まれているコンフィグレーションで、IIS が数時間おきにクラッシュし、Event 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 バイトが失われ、その結果としてコア ダンプが生じていました。この問題は、コードを修正して解決されました。
CR125545	クライアントが (たとえば応答が完了する前にブラウザを閉じることで) 応答が送信されてくるのを中断した場合に、プラグインが 500 [WRITE TO CLIENT ERROR] を Web サーバのログ ファイルに書き込んでいました。 このことが原因で、状態モニタ ツールが 500 エラーを Web サーバの問題として解釈してしまう恐れがありました。この問題は、コードを修正して解決されました。
CR124464	リクエストが HALF_OPEN_SOCKET_RETRY, "Unexpected EOF reading HTTP status - request retry" メッセージを受け取った直後に、プラグインが iPlanet のクラッシュを引き起こす恐れがありました。 例外オブジェクトから例外コードを取得し、それからオブジェクトを削除するようにコードが修正されました。
CR124433	IIS で WlForwardPath=/ がコンフィグレーションされている場合に、サーバがダウンしていてもプラグインがリクエストを転送しようとしていました。 クライアントにエラー ページが提供されることはありませんでした。 この状況ではパスが適切に除外されるようにプラグインが修正されました。
CR123925	プラグインは、500 エラー メッセージでブラウザに応答することがありました。 この問題には、以下の 3 つの症状もありました。 IIS のアクセス ログが次のメッセージを示していました。 Out-of-process+ISAPI+extension+request+failed. 500 1726 99122 2003 84078 Windows のイベント ログが、Event ID 37 を記録していました。 Event Type: Warning Event Source: W3SVC Event Category: None Event ID: 37 Date: 8/26/2003 Time: 6:45:03 PM User: N/A Computer: name Description: Out of process application '/LM/W3SVC/2/Root/caf' terminated unexpectedly. For additional information specific to this message please visit the Microsoft Online Support site located at:http://www.microsoft.com/contentredirect.asp. wlproxy.log のエントリが次のように示していました。 Fri Nov 21 19:06:31 2003 Write to the browser failed: calling URL::close at line 1270 of .¥iisproxy.cpp Fri Nov 21 19:06:31 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1271 of .¥iisproxy.cpp この問題は、コードを修正して解決されました。
CR123120	POST メソッドがプラグインを通じて使用され、かつ Content-Length が定義されていない場合に、プロキシ ログ ファイルに次のようなメッセージが記録されていました。 POST and PUT requests *must* contain a Content-Length Content-Length が定義されていない場合に、0 のコンテンツ長が設定されるようにコードが修正されました。
CR122755	?.wlforward? が手動で URL に追加された場合に、プラグイン フィルタが迂回されていました。 初期リクエストの MIME タイプが .wlforward である場合に 404 エラーが送出されるように、コードが修正されました。
CR122754	プラグイン パラメータ WLExludeByPathOrMimeType が、MIME タイプで転送を行うときに機能していませんでした。この問題は、コードを修正して解決されました。
CR122207	KeepAliveEnabled と DynamicServerList が両方とも有効になっている場合に、プラグインがソケットを CLOSE_WAIT 状態のままにする恐れがありました。この問題は、コードを修正して解決されました。
CR121688、CR121943	URL で感嘆符 ?!? が ?%21? で置換されている場合に、プラグインがクッキーの解析に失敗していました。 この置換は通常、URL 書き換えの使用時に WAP ゲートウェイによって行われます。 URL の文字を正しく解析するように、コードが修正されました。
CR113093	次のように、httpd.conf で複数の MatchExpression パラメータを使用してリクエストをさまざまな場所に転送する場合に、 MatchExpression *.jsp WebLogicHost=localhost|WebLogicPort=8001 MatchExpression *.html WebLogicCluster=localhost:8001,localhost:8003 各リクエストが同じグローバル パラメータ情報を上書きし、リクエストが間違った場所に転送されていました。 上の例では、*.jsp のリクエストがポート 8003 のサーバに転送されることになります。 各リクエストがそれ専用のパラメータ情報を使用するように、コードが修正されました。
CR111167	WebLogic Server 7.0 の以前のサービス パックでは、ISAPI プラグインを使用すると、HTTP 応答の Date ヘッダが 2 つになっていました (1 つは WebLogic Server によって挿入され、1 つは IIS で挿入される)。 この Date ヘッダの重複は、Date ヘッダは 1 つだと想定している特定のキャッシング サービスで問題を生じさせていました。 この問題は、WebLogic Server で挿入された Date ヘッダを除去するように ISAPI プラグインを更新することで解決しました。
CR110664	プラグインのコードが例外を捕捉できず、それが原因で iPlanet サーバが sendResponse フェーズでクラッシュしていました。 例外が捕捉されるように、プラグインのコードが修正されました。
CR109755	ワイルドカード文字 (*/?) 以外の正規表現が含まれたコンフィグレーション パラメータが、プラグインで無視されていました。 この問題は、次のようにしてパラメータを使用するときに 404 エラーを生じされる恐れがありました。 LocationMatch "/weblogic/(abc|def)/ghi" この問題は、コードを修正して解決されました。
CR108092	WebLogic Server 7.0 の以前のサービス パックでは、修正されたクッキーに遭遇したときに ISAPI プラグインが未処理の例外エラーを Windows のイベント ログに記録していました。 イベント テキストは、次のような行で始まっていました。 The HTTP Server encountered an unhandled exception while processing the ISAPI Application. この問題は、ISAPI プラグインのコード修正で解決しました。
CR105123	iisproxy.ini ファイルで仮想ディレクトリをコンフィグレーションし、MIME タイプをワイルドカード * (すべてをプロキシ) でコンフィグレーションして、DefaultFileName を追加した場合に、ファイル名のないディレクトリに対するリクエストで、DefaultFileName が使用されていませんでした。 コードを変更してこの問題は解決しました。
CR105173、CR135917	クライアントが (たとえば応答が完全に受信される前にブラウザを閉じることで) 応答が送信されてくるのを中断した場合に、500 [WRITE TO CLIENT ERROR] が Web サーバのログに不適切に記録されていました。 この種の応答の失敗で、500 エラーがログに記録されることはなくなりました。
CR091910	WebLogic Server 7.0 の以前のサービス パックでは、<IfModule mod_weblogic.c> を使用している場合に Apache プラグインが PathPrepend を読み込みませんでした。 この問題は、Apache 1.3.x および Apache 2.0.43 用のプラグインで発生していました。 この問題は、PathPrepend プロパティと MatchExpression プロパティが <IfModule mod_weblogic.c> タグの中で共存している場合にのみ発生していました。 PathTrim プロパティでも同じことが起こっていました。 この問題は、コードを修正して解決されました。
CR106764	Netscape プラグインのスレッドは長い時間 (デフォルトは 5 分、WLIOTimeoutSecs でコンフィグレーションすることも可能) 重要なロックを取得することができたので、他のすべてのスレッドがブロックされて、Web サーバがハングしたようになっていました。 この問題は、プラグインのコードを修正することで解決しました。
CR087204	PathTrim パラメータと PathPrepend パラメータを一緒に使用しても、末尾に不要な「/」の付いた URL が作られなくなりました。

RMI

変更要求番号	説明
CR124596	BEA ORB に追加されたオプションの機能により、ブートストラップ時に再接続が行われ、ハードウェア ロードバランサが接続の試行を適切にバランシングできるようになりました。 この機能と制限の詳細については、『WebLogic RMI over IIOP プログラマーズ ガイド』の「ハードウェア ロード バランサと RMI over IIOP の併用」を参照してください。
CR125261	ファット クライアント アプリケーションが、サービス パック 3 およびサービス パック 4 を適用した WebLogic Server 7.0 を使用している場合に、ステートレス セッション EJB を呼び出すクライアントをインスタンス化し、メモリ リークを起こしていました。 この問題は、Appmanager のコンテキスト クラスローダを使用することで解決しました。この変更後、-Dweblogic.LoadStubUsingContextClassLoader オプションは使用できなくなります。
CR127333	サーバが応答を書き込んでいる途中で RMI/IIOP クライアントが強制停止されたときに、それ以降の一部のクライアント要求が MarshalException で失敗していました。 初期クライアント接続が切断された場合に、間接マップがプールに戻されるときにクリアされていませんでした。 その特定のマップをプールから使用する以降のクライアントは、MarshalException で失敗していました。 コードを修正した結果、クライアントが強制的に終了された場合でも間接マップが適切にクリアされるようになりました。
CR121079	最初のリクエストを行うときに、WebLogic Server-IIOP ランタイムがワイド文字列の送信に適切なコードセットを選択していませんでした。 現在は、すべてのリクエストでワイド文字列の送信に適切なコードセットが選択されます。 WebLogic Server との相互運用が正しく機能するようになっています。
CR128594	以前のサービス パックでは、WebLogic Server は AIX 上の Java オブジェクトを読み込むときにタイプコードのエイリアスを処理できていませんでした。 エイリアス ラッパーを破棄するように、コードが修正されました。
CR124377	シンクライアント .jar (wlclient.jar) を使用しているクライアント アプリケーションが EJB にアクセスしたときに、WebLogic Server は java.rmi.UnmarshalException を送出することがありました。 次に示すのは、サーバ側の例外の一部です。 java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.IOException: Serializable readObject method failed internally.java.rmi.UnmarshalException: error unmarshalling arguments; nested exception is: java.io.IOException: Serializable readObject method failed internally at com.ejb_cvps36_EOImpl_WLSkel.invoke(Unknown Source)[...] 次に示すのは、クライアント側の例外の一部です。 java.rmi.MarshalException: CORBA MARSHAL 0 No; nested exception is:org.omg.CORBA.MARSHAL: vmcid: 0x0 minor code: 0 completed: No at com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.mapSystemException(ShutdownUtilDelegate.java:97) at javax.rmi.CORBA.Util.mapSystemException(Util.java:65) [...] この問題は、クライアントで weblogic.jar を使用したときには発生しませんでした。 この問題に対応するように、コードが修正されました。
CR109844、CR113715	InitialContext の作成とクローズが繰り返されているときの DGCServerHelper クラスのメモリ リークに起因するメモリ不足エラーで、分散ガベージ コレクションを管理するヘルパー オブジェクトが不必要に作成されます。 この問題は、コードの変更で解決されました。
CR106281	WebLogic Server 7.0 の以前のサービス パックでは、負荷が大きいときにレプリケートされたセッション Bean が原因で、ヒープの使用量が上昇し、OutOfmemoryErrors が生じていました。 分析の結果、ガベージ コレクションが強制されたときでも examples.ejb20.basic.statefulSession.TraderBean_5ysgq2_EOImpl オブジェクトがガベージ コレクションされていなかったことが判明しました。 クラスタ化されたステートフル セッション Bean では、weblogic.rmi.cluster.PrimarySecondaryRemoteObject の EOImpl オブジェクト プライマリへの強い参照が保持されていました。 Bean で remove が呼び出されないので、EOImpl の参照が eoMap から削除されることはありませんでした。 session-timeout-seconds が経過した後、パッシベーションされた Bean が削除されたときに EO がアンエクスポートされるように、コードが修正されました。
CR131692	ejb メソッドから派生例外を送出するときに、iiop レイヤが基本例外ではなく派生例外の Full Value Description を追加していました。クライアントが戻って基本例外の情報を取得するときに、サーバはその情報を持たず、例外を送出していました。 派生クラスの Full Value Description を作成するときに、基本クラスの Full Value Description も作成されるようにコードが追加されました。

セキュリティ

変更要求番号	説明
CR135710	backendstandard には、アンデプロイなどの一部の操作を遅延させる wait(1000) がありました。 コードを変更して wait(1000) を削除し、tp.wait() を導入しました。
CR172774	以下のように、LDAP で証明書を保持するバイナリ フィールド ("userCertificate" または "userCertificate;binary") に合わせて CertificateAttribute を定義する必要があります。 現在のデフォルトは "userCertificate" です。 1. userCertificate LDAP ブラウザから証明書をロードする場合、バイナリ型の属性 userCertificate が作成されます。この属性の値は証明書のデータです。 証明書にアクセスするには CertificateAttribute="userCertificate" を定義する必要があります。 2. userCertificate;binary 次のように ldapmodify を使用して新しい属性を追加する場合、 ldapmodify -p 1155 -D Principal -w Password dn: cn=[e-mail],ou=Certs,dc=bea,dc=com changetype: modify add: userCertificate userCertificate;binary:: MIICxDCCAi2gAwIBAgIBIDANBgkqh..... userCertificate;binary という属性が作成されて、そこに証明書データがロードされます。 この証明書にアクセスするには CertificateAttribute="userCertificate;binary" を定義する必要があります。
CR121114、CR134158、CR134159、CR135017、CR130506	SocketImpl クラスが IOException を捕捉せず、再送出を続けた結果、ソケットが閉じなくなっていました。 この問題は、ソケットを閉じ、IOException を送出するコードを追加することで解決しました。 この変更の結果、アイドル状態のソケットは存在しなくなりました。
CR120748	以前のリリースの WebLogic Server には、LDAP X509 ID アサータがありませんでした。 LDAP X509 ID アサータの使用を許可するコードが追加されました。
CR112147	weak、strong、authenticate などの既存の ServletAuthentication API メソッドが、LoginException を呼び出し元に伝達していませんでした。 weak および authenticate メソッドと同じように機能する、2 つのオーバーライドされたログイン メソッドが追加されました。 strong メソッドと同じように機能する assertIdentity メソッドも追加されています。 これらの新しいメソッドは、LoginException を呼び出し側コードに伝達します。
CR124746、CR175051、CR175045	のセキュリティ勧告に関する情報を確認してください。
CR132503	Web サービスのクライアントはローカル ID を直接 Certicom SSL コンテキストにロードしていましたが、Web サービスの HttpsURLConnection クラスは接続をその特定の Certicom SSL コンテキストと関連付けていませんでした。 接続は現在は、HttpsURLConnection クラス (SSL コンテキストをパラメータとして取る) によって SSL コンテキストと関連付けられるようになりました。
CR130355	重複したエントリを追加したときに、例外が無害であっても、メソッドを完了することなく DefaultCredentialMapperLDAPHelper が例外を送出していました。 コードの修正によって、DefaultCredentialMapperLDAPHelper が重複エントリの追加時に例外を無視するようになりました。
CR128002	接続プールが正しく管理されていず、プールのサイズがリクエストの生成する負荷に対して十分ではありませんでした。 これらの問題が原因で、ユーザの認証時にパフォーマンス上の問題が生じていました。 プールの問題は、コードの修正で解決しました。 さらに、LDAP 接続プールのサイズを設定するオプションも追加されました。 そのオプションは、-Dweblogic.security.providers.authentication.LDAPDelegatePoolSize です。
CR127259	DefaultAuditRecorder のバックアップ ファイル名の月フィールドで、間違った値が示されていました。 表現を修正するコードが追加されました。 現在は、正しい値が示されるようになっています。
CR125409	2 つの管理対象サーバが同時に起動された場合に、アプリケーションのデプロイの過程で LDAP エントリを作成するために同じコードが 2 回実行されていました。 同期がなされていないために、LDAP で重複エントリが作成されていました。 id カウンタを更新する前に同期化の過程でエントリの有無をチェックするコードが追加されました。 重複エントリが誤って作成されている場合に、WebLogic Server はエントリの作成を防止する例外を送出します。
CR064593、CR121607	SSL の存続期間とキャッシュ サイズの制御に使用される以下のコマンドライン引数は、WebLogic Server 7.0 で無視されなくなりました。 -Dweblogic.security.SSL.sessionCache.size= sessioncachesize -Dweblogic.security.SSL.sessionCache.ttl= sessioncachetimetolive
CR097734、CR090472	リクエストをプロキシするときに SSLLayeredSocket が SSLIOContext を作成せず、プロキシ サーバを通じて SSL のトンネリングを行っている間に NullPointerException が生じていました。 SSLIOContext を作成し、それをコンテキスト テーブルに追加するコードの変更で、この問題は解決しました。
CR105933	接続フィルタのルールで LDAP プロトコルが許されていなかったために、WebLogic Server は LDAP サーバからの接続をフィルタ処理することができませんでした。 フィルタ処理可能なプロトコルのリストに LDAP が追加されたので、ldap からの接続がフィルタ処理可能になりました。
CR106192	セキュリティ デバッグ フラグ <ServerDebug DebugSecurityAtn="true" DebugSecurityAtz="true" ...> を StdoutDebugEnabled="true" StdoutSeverityLevel="64" と一緒に設定した場合に、ユーザのパスワードがクリア テキストで stdout に記録されていました。 この問題は、ログ ファイルに書き込まれる文からパスワード文字列を削除することで解決しました。
CR106294、CR132596、CR120273	埋め込み LDAP トランザクションの処理で、コンフィグレーションされた待機時間だけアプリケーションの削除が遅延されていました。 コードを変更してこの問題は解決しました。
CR106532	双方向 SSL が有効になっている場合、サーバは IdentityAssertion を自動的に呼び出します。これはクライアント/サーバのシナリオでは適切ですが、接続が WebLogic Server のインスタンス間の場合は問題が生じます。 そのシナリオは次のとおりです。 クライアントが WebLogic Server のインスタンス 1 にアクセスし、双方向 SSL で適切に認証されます。 インスタンス 1 はインスタンス 2 の EJB を双方向 SSL で呼び出し、インスタンス 2 はインスタンス 1 の証明書に基づいて認証を行います。 以下の 2 つの問題があります。 1. 真のユーザはインスタンス 1 ではなくクライアントであるのに、インスタンス 2 ではインスタンス 1 の証明書の DN に基づいてユーザはインスタンス 1 だと認識します。 2. 認証が必須であってはなりません。 SSL 接続ではクライアント証明書を強制できなければなりませんが、信頼性のある WebLogic Server ドメインを使用する場合には IdentityAssertion チェックを無効にします。 コードの修正によって、証明書の認証がコンフィグレーション可能になりました。 双方向 SSL の過程で提示された証明書を処理して IdentityAssertion を実行したくない場合は、サーバの起動時に -Dweblogic.security.disableIdentityAssertion=true を使用します。
CR107363	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_40.00.jsp のセキュリティ勧告を参照してください。
CR108021	セキュリティ サブジェクトと一緒に格納された情報の損失を引き起こしていた問題が、次のようにして解決されました。 双方向の証明書あるいはヘッダまたはクッキーのトークンを使用してユーザがログインするときに新しいキャッシュが使用されて、ID アサーションのパフォーマンスが向上します。 サーバは 6.x 以前の WebLogic Server インスタンスから、または run-as タグ付きのサーブレットまたは EJB が実行されたときに RMI 呼び出しを受信します。 ユーザが削除されても、キャッシュの TTL に達するまでその削除されたユーザについて ID アサーションが継続して行われます。 キャッシュの TTL のデフォルトは 5 分であり、次のようにしてコマンドラインで調整できます。 -Dweblogic.security.identityAssertionTTL=N for N > 0 sets the cache TTL to N seconds N = 0 sets the cache TTL to infinity N < 0 disables the cache altogether
CR108624、CR128228	パフォーマンス チューニングの拡張機能として、グループ メンバーシップ検索の深さを制限するための新しい属性が追加されました。 メンバーシップの階層に基づいて検索を調整し、グループ メンバーが見つからないことがわかっている検索を排除できます。 新しい属性は、GroupMembershipSearching と MaxGroupMembershipSearchLevel です。
CR110242	realm.getGroups() の呼び出しで使用される LDAPConnection がその結果を保持し、getGroups() の繰り返し処理でも使用されるプールへ復帰していませんでした。 これが原因で、開いている LDAP 接続が急増していました。 コードの修正後、LDAP 接続はグループ イテレータに対する getGroups() 呼び出しに関連付けられ、イテレータにそれ以上要素がなくなった時点で閉じるようになりました。
CR110977	ACLCacheTTLPositive で java.lang. Integer.MAX_VALUE を指定すると、java.lang.IllegalArgumentException が送出されていました。 この問題は、イベントが次の順序で行われた後に発生していました。 1. CompatibilityRealm モードで WebLogic Server を起動します。 2. キャッシング レルムで、ACL キャッシュを有効にし、ACL Cache Positive TTL = java.lang.Integer.MAX_VALUE の値を指定し、変更を保存します。 3. WebLogic Server を再起動します。 WebLogic Server から次の例外が送出されます。 <Jun 25, 2003 4:31:44 PM PDT> <Notice> <Management> <140005> <Loading configuration D:¥opt¥weblogicapps¥ecommerce¥.¥config.xml> <Jun 25, 2003 4:31:47 PM PDT> <Info> <Logging> <000000> <FileLogger Opened at D:¥opt¥weblogicapps¥ecommerce¥.¥logs¥ecommerce¥myserver.log> <Jun 25, 2003 4:31:50 PM PDT> <Critical> <WebLogicServer> <000364> <Server failed during initialization. Exception:java.lang.IllegalArgumentException: ttl<= 0 java.lang.IllegalArgumentException: ttl <= 0 at weblogic.security.acl.TTLCache.<init>(TTLCache.java:195) at weblogic.security.acl.TTLCache.<init>(TTLCache.java:173) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:478) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:375) at weblogic.security.acl.CachingRealm.<init>(CachingRealm.java:350) at ... この問題は、ttlcache の作成コードを修正することで解決しました。
CR111305	ログインしたクライアントが Web アプリケーション リソースにその表示前にアクセス可能かどうかを、webflowCheckAccess() メソッドが明示的にチェックするようになりました。
CR112971、CR104667	WebLogic Server 7.0 の以前のサービス パックと一緒にリリースされていた NetScape LDAP API に、複数のスレッドが LDAPConnThread の deregister() を呼び出したときにデッドロックを生じさせるバグがありました。 サービス パック 5 のコード変更で、この問題は解決しました。
CR113459	以前のサービス パックでは、ノード マネージャのプロパティ ファイルを削除すると問題が起こっていました。 ノード マネージャのプロパティ ファイルは常に、<saved logs dir>/NodeManagerInternal ディレクトリに作成されます。 NodeManagerInternal の内容を定期的に保管および削除することでノード マネージャのプロパティ ファイルが削除されるので、ノード マネージャのプロパティ ファイルに格納された証明書のパスワードを解読できず、ノード マネージャが正しく機能していませんでした。 ノード マネージャのプロパティ ファイルを user.dir で指定されたディレクトリ (ファイルが NodeManagerInternalにない場合) または user.dir ディレクトリに作成するようにコードを修正することで、この問題は解決しました。
CR120233	IPlanet 5.1 Authenticator を使用してカスタム監査プロバイダおよびカスタム ロール マッピング プロバイダをコンフィグレーションするときに java.lang.ArrayStoreException が送出される問題が、コードの修正によって解決されました。
CR120850	weblogic.net.http.HttpsURLConnection が、https.nonProxyHosts 環境変数を無視していました。 WebLogic Server 内で動作しているか、スタンドアロンの Java プログラムであるかに関係なく、クライアントからのリクエストが、https.nonProxyHosts で対象ホストが指定されている場合でも常にプロキシを経由していました。 https.nonProxyHosts が SSLParams で検出されると、プロキシされるべきホストの内部リストが作成されます。 SSLSocket が作成および初期化されると、ホストがこのリストに照らし合わせて比較されます。 ホストがリストにある場合、そのホストはソケットを開くために使用されます。 ホストがリストにない場合は、proxyHost を使用してソケットが開かれます (proxyHost がない場合はすべて無効であり、ホストを使用してソケットが開かれる)。 コードを変更してこの問題を解決しました。 現在は、ユーザが以下のプロパティを設定できるようになっています。 http.proxyHost http.proxyPort http.nonProxyHosts https.proxyHost https.proxyPort https.nonProxyHosts (新しいプロパティ) http と https のどちらの場合でも、ソケットが開かれる proxyHost を定義できます。 しかし、proxyHost が定義されている場合でも、直接接続されるべきホストのリスト (nonProxyHosts) を定義することもできます。 https.nonProxyHosts が追加されたことで、https.proxyHost が定義されている場合でも、ssl を使用して常に直接接続されるべきホストを指定することができるようになりました。
CR120852	動的グループ属性 memberURL の文字列値で、LDAP URL の LDAP 検索フィルタ部分に予約文字 (スラッシュ「/」など) が含まれている場合に、MalformedURLException が送出されていました。 たとえば、次の URL では、 ldap://text replaced:389/dc=text replaced2??sub?(&(|(objectclass=person) objectclass=groupofuniquenames))(uid=*text replaced/2*)) 次の例外が送出されていました。 <Jun 23, 2003 12:30:35 PM EDT> <Debug> <SecurityDebug> <000000> <advance dyn group entry = LDAPEntry: cn=slashgroup,ou=Groups, dc=text replaced; LDAPAttributeSet: LDAPAttribute {type='cn', values='dynamicgroup001,slashgroup'} LDAPAttribute {type='memberURL', values='ldap:///dc=text replaced??sub?(&(|(objectclass=person)(objectclass=groupofuniquenames))(uid=*htext replaced/2*))'}> <Jun 23, 2003 12:30:35 PM EDT> <Debug> <SecurityDebug> <000000> <advance member url = ldap:///dc=text ... 分析と調査の結果、以下のことが判明しました。 LDAP URL で「/」は不正ではないが、URL の区切り文字なので避ける必要がある。 WebLogic Server は、動的グループの繰り返し処理の間に LDAPUrl オブジェクトを使用してフィルタを取得していた。 その url フィルタ部分に「/」のような特殊文字が含まれている場合、LDAPUrl クラスはそれらの文字を適切に処理しません。 LDAPRealm オブジェクトを使用せずにフィルタを取得するようコードを修正して、この問題は解決しました。
CR120932	CertificateServlet で提供された HTML ページが、ラジオ ボタンに間違った値を表示していました。ラジオ ボタンで 2048 が表示されていましたが、そのボタンを使用すると 1024 ビットの証明書になっていました。 この問題は、コードの変更で解決されました。
CR121043、CR134995	JSP で直接設定されたプロパティが、HTTP クライアントで取得および設定されていませんでした。 コードを変更してこの問題は解決しました。
CR121135、CR123865	LANG が univ.utf8 に設定されている場合に、特定の状況で 2 つの WebLogic Server インスタンス間の双方向 SSL 通信を失敗させる内部例外が、JDK 1.3.1_08 から送出されていました。 コードを変更してこの問題は解決しました。
CR121646	Extended Key Usage が critical に設定されているクライアント証明書が WebLogic Server に送信されたときに、BAD_CERTIFICATE エラーが受信され、SSL 接続が終了していました。 分析の結果、WebLogic Server が SSL の Enhanced KeyUsage をサポートしていないことが判明しました。 この問題は、EnhancedKeyUsage のサポートを追加することで解決しました。 現在は、Enhanced Key Usage が critical に設定されている証明書を WebLogic Server が受け入れるようになっています。
CR122642	サービス パック 2 からサービス パック 3 にアップグレードした後に、[セキュリティ｜ユーザ｜レルム｜myrealm｜ユーザ] 画面を表示しようとすると、WebLogic Administration Console がハングしていました。 サービス パック 5 のコード変更で、この問題は解決しました。
CR124164、CR090738	資格エンジンは以前は、ロール式のオペランドの数を 100 に制限していました。 この制限は、さまざまな属性値を制限していました。 たとえば、weblogic-ejb-jar.xml の security-role-assignment 内の role にマップできる principal-name 要素の最大数は 50 に制限されていました。 principal-name 要素が 50 を超えると、アプリケーションのデプロイメント時に weblogic.entitlement.data.EnCreateException が送出されていました。 ロール式のオペランド数が制限されないようにコードを修正することで、この問題は解決しました。
CR126106、CR090472	アプリケーションのデプロイメント時に、LDAP のエントリがまず管理サーバに書き込まれ、その後に管理対象サーバに書き込まれていました。 以前のサービス パックでは、管理サーバへの書き込みが失敗した場合に、管理対象サーバへの書き込みなしに呼び出しが戻され、それが原因で EJB セキュリティ レイヤが適切なロールを返さなくなっていました。 LDAP のコードを修正することで、この問題は解決しました。
CR133655、CR128002	接続プールのコードが正しく機能せずに、LDAP 検索の速度が低下し、それが原因でたとえばサードパーティ LDAP との認証が遅くなっていました。 コードを変更してこの問題を解決しました。

サーブレット

変更要求番号	説明
CR128624、CR171907	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 の末尾にそのアンカーを付けるように、コードが追加されました。
CR123333	Web アプリケーションのフォームベースの認証は、「j_username」および「j_password」でマルチバイト文字を許可せず、それによって JSP でのリクエスト エンコーディングが妨げられていました。 マルチバイト文字が原因で認証が失敗していました。 JSP で文字エンコーディングを指定するには、「j_character_encoding」を次のように使用します。 <form method="POST" action="j_security_check"> <input type="text" name="j_username"> <input type="password" name="j_password"> <input type="hidden" name="j_character_encoding" value="Shift_JIS" > </form> 注意 : j_character_encoding は J2EE に準拠していません。 コードを変更してこの問題は解決しました。
CR132522	デフォルト Web アプリケーションのない Web サーバで、見つからないリソースに対する HTTP リクエストが次のように間違った日付ヘッダのある応答を受信していました。 HTTP/1.1 404 Not Found Date: Thu, 01 Jan 1970 00:00:00 GMT このヘッダは、RFC2616 のセクション 14.18 によれば妥当ではありません。コードを変更してこの問題を解決しました。
CR129237	HttpServletRequest.getServletPath() または HttpServletRequest.getPathInfo() を呼び出したサーブレットは、ServletMapping が *.<value> に対応していて、URL にピリオド「.」が含まれている場合に間違った値を受け取っていました。 解析エラーを修正することで、この問題は解決しました。
CR129211	ServletOutputStream.write(byte) を使用してバッファ サイズ以上を書き込むと、無限ループが生じていました。 バッファが一杯で自動フラッシュが false に設定されている場合の境界条件のチェックを更新するコードの修正で、この問題は解決しました。
CR128986	プロトコル例外の後に、ensureContentLength メソッドの問題が原因で新しいライセンスを処理しようとしているときにサーバがハングしていました。コードを変更してこの問題を解決しました。
CR128420	breakUpAndWriteItOutAsNecessary() が、1 行に最大 72 バイトの制限を実施するためにマニフェスト ヘッダを切り離そうとし、1 度に 1 行ずつ出力ストリームに書き込んでいました。 この問題は、新しい行の開始オフセットが間違っていたことが原因でした。 コードを変更してこの問題を解決しました。
CR127708	HttpParsing.unescape() が、パス /foo/..%c0%../ を /foo/.. にデコードしていました。その理由は、sun.io.ByteToCharUTF8.convert() が、UTF8 で有効ではないバイト (0xc0 など) に遭遇した場合に残りのバイトの変換を止めてしまうからです。 この問題は、JDK 1.4 では発生していませんでした。 この問題は、無効な UTF-8 シーケンスを U+FFFD 文字で置換する WebLogic Server UTF-8 コンバータによって解決しました。 この修正の結果、HttpParsing.unescape() はパス /foo/..%c0%../ を /foo/..?%.. にデコードします。
CR125846	サーブレット仕様によれば、ワイルドカード パターンよりも完全パターンの方が優先されなければなりません。 しかし、これは正確に機能していませんでした。 たとえば、「/TestPath/*」が「WildcardServlet」に対応し、「/TestPath」が「ExactMatchServlet」に対応する場合に、入力の相対 URI が「/TestPath」の場合は、WildcardServlet ではなく ExactMatchServlet が提供されなければなりません。 この問題は、パターン マッチングを適切に変更することで修正されました。
CR125048	server/bin/fastfile.dll からのデバッグ情報が、Administration Console で出力されていました。 ソース コードを変更することなくバイナリを再構築することで、この問題は解決しました。
CR133558	null 値が渡されたときに、ServletContext.setAttribute が NullPointerException を送出していました。 この問題は、setAttribute() に null 値が渡されたときに removeAttribute() を呼び出すようにするコード変更で解決しました。
CR084455	ローテーション時にすべての HTTP リクエストを拡張フォーマットでログに記録するように WebLogic Server がコンフィグレーションされている場合に、ローテーションがスケジュールされた後に約 1 分間隔で次のエラーが送出されていました (1 分はログ フラッシュの時間間隔の設定)。 ####<Aug 20, 2002 9:00:00 PM PDT> <Error> <HTTP myapp> <host2> <myserver> <ExecuteThread: '6' for queue: 'default'> <system> <> <000000> <Exception flushing HTTP log file> java.io.IOException: Failed to rename log file on attempt to rotate logs at weblogic.servlet.logging.LogManagerHttp.rotateLog(LogManagerHttp.java:168) at weblogic.servlet.logging.LogManagerHttp.access$2(LogManagerHttp.java:148) at weblogic.servlet.logging.LogManagerHttp$RotateLogTrigger.trigger(LogManagerHttp.java:432) at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:229) at weblogic.time.server.ScheduledTrigger.execute(ScheduledTrigger.java:69) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) ####<Aug 20, 2002 9:00:05 PM PDT> <Error> <HTTP myapp> <host2> <myserver> <ExecuteThread: '7' for queue: 'default'> <system> <> <000000> <Exception flushing HTTP log file>... 分析の結果、ログが不適切にフラッシュされていたことが判明しました。 この問題は、ローテーション時にログがフラッシュされず、ログ ファイル名で null 値がチェックされるようにコードを修正することで解決しました。
CR088785、CR122315	HTTP アクセス ログで、cs-uri フィールドが指定されている場合に、URI の基本部分とクエリ部分の両方ではなく基本部分のみが記録されていました。この問題は、コードを修正して解決されました。
CR092625、CR112910	HTTP のロギングを無効にして起動され、かつログ ファイルが存在していない管理対象サーバで HTTP のロギングを有効にした場合に、WebLogic Server が NullPointerException を送出していました。 その管理対象サーバへの各 HTTP アクセスで、次の例外が送出されていました。 java.lang.NullPointerException at weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:292) at weblogic.servlet.internal.HttpServer.log(HttpServer.java:865) at weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1044) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2265) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) この問題は、コードを修正して解決されました。
CR095945	CGIServlet は、WAR Web アプリケーションの CGI スクリプトを、それらが実行できるように抽出します。 以前、サーブレットは現在の作業ディレクトリを設定せずにそれらのスクリプトを呼び出していました。 つまり、サブスクリプトを適切に呼び出すことができていなかったのです。 コードの変更によって、現在の作業ディレクトリが設定されるようになり、CGI スクリプトが WAR Web アプリケーションのサブスクリプトを呼び出せるようになりました。
CR096459	HTTP 1.0 でサーブレットまたは JSP のフラッシュを実行するときに、WebLogic Server がときどきソケットを閉じることができず、ソケットがタイムアウトになるまでクライアントが待機するようになっていました。この問題は、コードを修正して解決されました。
CR103339	サーブレットの出力で、Transfer-Encode タイプの値として、HTTP/1.1 仕様で要求されている小文字の chunked ではなく、先頭を大文字にした Chunked が使用されていました。 小文字の「chunked」が Transfer-Encode タイプとして使用されるように、コードが修正されました。
CR103482、CR120943、CR129041	セカンダリ サーバの孤立セッションの問題をそのセッションを無効化することで解決した回避策が、負荷テスト時に「プライマリが見つからない」エラーを生じさせる競合状態を作り出していました。 コードを変更してこの問題を解決しました。
CR103925、CR125206	setAttribute メソッドは、hashCode の同一性のみをチェックしていました。 現在は、equals メソッドの結果で古いオブジェクトと新しいオブジェクトをチェックするようにもなりました。
CR104245	負荷が大きい状況で、2 サーバ コンフィグレーションのプライマリ サーバとセカンダリ サーバの両方が同じレプリケート セッションにアクセスすると、セッション レプリケーションのデッドロックが発生します。 両方のサーバが同じセッション データをレプリケートしようとします。プライマリ ロールのサーバは、ReplicatedSessionData をロックして、セカンダリ サーバを更新しようとします。 同時に、もう一方のサーバも同じことを実行し、最初のサーバがそのセカンダリ コピーを更新するのを待ちます。 レプリケーション呼び出しは最初のサーバのレプリケーション スレッド キューに入り、同じセッション データのプライマリとして機能している同じサーバの別のスレッドによって保持されたセッション データのロックを取得できるまで更新を終了できません。 各サーバはプライマリとしてレプリケーションを試行し、セカンダリとして同じセッションを更新しようとし続けて、相互のデッドロックに陥ります。 サーバがデッドロックに陥ると、セッションのアクセスとレプリケーションが関わるすべてのリクエストがブロックされ、リクエストが蓄積されていきます。 2 つのサーバがプライマリとセカンダリの状態を行き来し続けると、「Got stale replication request」がログに記録されます。 同期メソッドの代わりに同期オブジェクトを使用するコード変更で、この問題は解決しました。
CR108034	ユーザが接続を切断することで生成されていた不適切なエラー メッセージが、生成されないようになりました。
CR108350	Administration Console では、ログ ファイル フォーマットを共通ログ フォーマット (CLF) と拡張ログ フォーマット (ELF) の間で動的に変更できるという情報が誤って示されていました。実際には、そのような変更にはサーバの再起動が必要です。 このコンフィグレーション パラメータの変更にはサーバの再起動が必須であることを適切に示すように、コードが変更されました。
CR108385	WebLogic Server クラスタの前でプロキシとして機能している HttpClusterServlet を使用してクラスタ インスタンスにチャンクデータをポストしようとしたときに、NumberFormatException が生成されていました。HttpClusterServlet のプロキシを経由しないダイレクトのリクエストは、エラーがでることなく成功していました。 チャンク転送エンコーディングされたデータは既にコア サーバでデコードされているということを考慮し、HttpClusterServlet が不必要にデータを再デコードすることがないようにコードを変更して、この問題は修正されました。
CR108577	アンデプロイメントで、モジュールの順序が考慮されていませんでした。 このロジックは修正済みです。 現在、モジュールはそれらがデプロイされた正確に逆の順序で非アクティブ化およびロールバックされます。
CR108607	WebLogic Server では、アプリケーションが FOP (Formatting Objects Processor) 出力メソッドのある XSL を使用してアーカイブ ファイルから画像を取得するとエラーが生成されていました。 この問題は、展開形式でデプロイされたアプリケーションでは起こりませんでした。 この問題は、コードを修正して解決されました。
CR109479、CR110838	JnlpDownloadServlet は、WAR ファイルのタイムスタンプを利用して、クライアントのリソースが Web サーバ上のものより古いかどうかを判断します。 タイムスタンプを取得するために、JnlpDownloadServlet は URLConnection.getLastModified() メソッドを呼び出します。 しかし、getLastModified() メソッドは 0 を返していました。 ZipURLConnection.getLastModified() が zip ファイル (したがって WAR ファイル) の変更時刻を返すように、コードが修正されました。
CR109885	障害の発生したセカンダリ ノードへのセッション レプリケーションで、プライマリ ノードがハングしていました。 プライマリ ノードは、セカンダリ ノードへの接続を試行し、他のスレッドが待ち続けなければならないロックを保持しているようになっていました。 コードを変更してこの問題は解決しました。
CR109958	プロキシ サーブレットを使用してリクエストを処理している場合に、WebLogic Server は HTTPS を使用する受信リクエストでのみ SecureProxy 設定に従っていました。 受信リクエストが HTTP を使用している場合は、プロキシ サーブレットで SecureProxy が有効になっていても WebLogic Server は HTTPS 接続を使用していませんでした。この問題は、コードを修正して解決されました。
CR110798	JSP で weblogic.servlet.security.ServletAuthentication.killCookie(req) を呼び出すと、クリーンアップされることなくセッションが WebLogic Server に留まっていました。 killCookie(req) が完了する直前にセッションが無効化されるように、コードが修正されました。
CR110832	config.xml の WebAppComponent で DebugEnabled が true に設定されている場合に、WebLogic Server は Web アプリケーションのデプロイメントで NullPointerException を送出していました。 この問題は、コードを修正して解決されました。
CR110910	KeepAliveEnabled が true に設定されている場合、大きなファイルのダウンロードがキャンセルされた後に HttpClusterServlet が NumberFormatException を送出していました。 分析の結果、クライアントがファイルのダウンロードをキャンセルしたときに、残りのデータが入力ストリームに残されていたことが判明しました。 ソケットが以降のリクエストで再利用される場合に、サーブレットが残りのデータを読み込んでしまい、その結果として例外が送出されていました。 この問題は、ダウンロードがキャンセルされた場合に入力ストリームから残留データが排出されるようコードを修正して解決しました。
CR110914	TrackingEnabled が false に設定されている場合、リクエストごとに新しいセッションが作成されていましたが、それらのセッションは無効化されていませんでした。 TrackingEnabled が false に設定されている場合にセッションが直ちに無効化されるように、コードが修正されました。 これは正常な動作です。
CR111090、CR090886	-Dweblogic.webservice.transport.http.full-url が True に設定されている場合、Web サービスは HTTPS プロトコルを使用して呼び出すことができませんでした。 コードを変更してこの問題は解決しました。
CR111531	[Sending UTF-8 Only] オプションが無効になっている場合、Weblogic Server 7.0 は 2 バイト文字の含まれているファイル名を処理しませんでした。 名前に 2 バイト文字のあるファイルにアクセスしようとすると、404 (File not found) エラーが生じていました。 この問題は、コードを修正して解決されました。
CR111752	特定の条件下では、useByteStream が true に設定されている CGIServlet を使用した場合に、WebLogic Server が NullPointerException を送出していました。 この問題は、1 つのフレームに静的な URL リンクがあり、もう 1 つのフレームで CGIServlet が使用されているフレームセットを使用している場合に発生していました。 他方のフレームでページが完全にダウンロードされる前に静的リンク付きのフレームをユーザが選択すると、IO 例外が捕捉されて次のようにユーザに示されていました。 java.lang.NullPointerException at weblogic.utils.Executable$Drainer.run(Executable.java:366) この問題は、コードを修正して解決されました。
CR112799	WebLogic Server は、IOException が発生した後でも出力ストリームに書き込もうとしていました。 IOException を処理しない Web アプリケーションで予期しないソケットの切断が起こった場合に、このことで CPU の使用率が 100% になっていました。 Org.apache.xml.serialize.XMLSerializer は、プロセスが終了するまで IOException を無視します。これが原因で、HTTP 応答の一部として HTML ドキュメントを返す途中で IOException が発生したときに問題が生じていました。 IOException が発生した後には出力ストリームへの書き込みが停止されるように、コードが修正されました。
CR112910、CR092625	HTTP のロギングを無効にして起動され、かつログ ファイルが存在していない管理対象サーバで HTTP のロギングを有効にした場合に、WebLogic Server が NullPointerException を送出していました。 その管理対象サーバへの各 HTTP アクセスで、次の例外が送出されていました。 java.lang.NullPointerException at weblogic.servlet.logging.LogManagerHttp.log(LogManagerHttp.java:292) at weblogic.servlet.internal.HttpServer.log(HttpServer.java:865) at weblogic.servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1044) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2265) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) この問題は、コードを修正して解決されました。
CR114936	クライアントが進行中のリクエストをキャンセルした場合でも、WebLogic Server は入力ストリームを排出していました。このために、CPU リソースが消費されていました。 入力ストリームが排出されないよう接続が破棄されるように、コードが修正されました。 この修正の結果として、クライアントへの書き込み中に IOException が発生した場合、GenericProxyServer はこの接続を再利用せず、次のリクエストでは新しい接続を作成します。
CR116209	顧客がシリアライズ可能な ServletContext 属性を追加し、それをシリアライズできない値で上書きした場合は、元の値によって新しい値がマスクされていました。 この問題は、属性のハッシュテーブルから古い値が削除されないことが理由で発生していました。 シリアライズ可能な値をシリアライズできない値で置換する場合に、必要であれば、属性のハッシュテーブルから値が削除されるようにコードが修正されました。
CR120228、CR124369	展開された EJB および Web アプリケーションとそれらの MANIFEST ファイル (クラスパスに共有クラス) が格納された展開されたエンタープライズ アプリケーションは、WebLogic Server 7.0 SP2 では機能しましたが、WebLogic Server 7.0 SP3 では機能していませんでした。 共有クラスが見つかりませんでした。 この問題は、MANIFEST ファイルのクラスパス エントリを展開されたアプリケーションのクロスローダに追加するコード変更で解決しました。
CR120281	HttpServletRequest.getParameterValues(String) からパラメータ値が 2 度返されることがありました。 分析の結果、転送されたリクエストのクエリ パラメータが、適切に解析されたパラメータ値が 2 回返される方法で解析されていたことが判明しました。 コードを変更してこの問題は解決しました。
CR120440	複数の Web アプリケーションがシングル サインオン コンフィグレーションにデプロイされ、1 つのアプリケーションが weblogic.servlet.security.ServletAuthentication.invalidateAll(request) を呼び出したときに、その他のアプリケーションの HttpSessionListeners がセッションのタイムアウトが起こるまで呼び出されていませんでした。 最初の Web アプリケーションと関連するセッションだけが無効化用に登録されていたことが、この問題の原因でした。ユーザが認証された後に、それ以降のセッションは登録されていませんでした。 すべての Web アプリケーションのセッション ID とコンテキスト パスの両方が、invalidateAll(request) で必要に応じて無効化できるよう登録されるように、コードが修正されました。
CR121094、CR129364	クラスタとそのクラスタにもマップされた VirtualHost の両方にデプロイされた Web アプリケーションを再デプロイすると、InstanceNotFoundException が生じていました。 この問題は、コードを変更して解決されました。
CR121175	HTTPClusterServlet が、セッション クッキーの JVMID で識別されたプライマリ インスタンスとは異なるサーバ インスタンスにリクエストを転送していました。 HTTPClusterServlet は、クラスタ化されていない複数の管理対象サーバにリクエストをプロキシしていました。 バックエンド サーバ インスタンスの Web アプリケーションは、index.jsp と frameset.jsp で構成されていました。 Web アプリケーションの起点は index.jsp であり、そこでセッションが作成されます。 index.jsp は <jsp:forward> を使用してリクエストを frameset.jsp (フレームセット) に転送します。 プロキシ (HTTPClusterServlet) を通じて最初に index.jsp にアクセスすると、セッションが作成され、クッキーが設定されます。 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 を更新すると、そのサーバはリストから削除され、更新されて、それからリストに戻されるようになりました。 単純にオブジェクトを更新しても、リストはソートされませんでした。
CR121343、CR133921、CR129538、CR129537、CR174336	複数のフレームが使用されている場合に、セカンダリ JVMID の算出時に競合状態が生じていました。あるスレッドで、セカンダリ JVMID の算出によりメンバー変数値がリセットされ、それによって競合状態が生じていたようでした。 コード変更の後、セカンダリ JVMID の算出で競合状態が生じなくなりました。
CR121359	JSTL の終了タグのタグ名と右山括弧 (>) の間にスペースがある場合に (例 : </c:if >)、weblogic.utils.ParsingException が発生していました。 <%@ taglib uri="/WEB-INF/c.tld" prefix="c" %> Full stack trace: <Aug 25, 2003 12:46:23 PM EDT> <Error> <HTTP> <101017> <[ServletContext(id=53171 81,name=TempApp,context-path=/TempApp)] Root cause of ServletException weblogic.utils.ParsingException: Could not complete parsing, unmatched tags: if otherwise when choose if forEach if at weblogic.servlet.jsp.JspLexer.parse(JspLexer.java:976) at weblogic.servlet.jsp.JspParser.doit(JspParser.java:90) at weblogic.servlet.jsp.JspParser.parse(JspParser.java:213) at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:119) at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:258 ) at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:353) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:211) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl. java:517) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm pl.java:351) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubIm pl.java:306) . タグ名と「>」の間でスペースを 1 回まで使えるようにコードを変更することで、この問題は解決しました。
CR121846	WebLogic Server 7.0 の以前のサービス パックでは、サーバが、拡張ログ フォーマットのヘッダを書き込む前に標準ログ エントリをログ ファイルに書き込むことができました。 このような状況は、ログ ローテーションで、複数のスレッドが新しいログ ファイルに同時に書き込もうとしたときに起こる可能性がありました。 ログ ヘッダが書き込まれる後まで、ログ ローテーションを処理するスレッドが新しいログ ファイルに排他的にアクセスするように、コードが修正されました。
CR122177	ファイルが見つからないときに、FileServlet が 404 ではなく 200 の応答コードを返していました。 ファイルが見つからないときは 404 が返されるように、コードが修正されました。
CR122551、CR122556、CR129248、CR134888	コンテンツ長が -1 で、書き込まれたバイトが 0 の場合に、トンネリングされたリクエストについて ServletOutputStreamImpl が次の例外を送出していました。 Servlet failed with IOException.java.net.ProtocolException: Didn't meet stated Content-Length, wrote: '0' bytes instead of stated: '-1' bytes. コードを変更してこの問題は解決しました。
CR124524、CR127621	weblogic.management.configuration.WebServerMBean の値 maxKeepAliveSecs が、最大 300 秒までコンフィグレーションできるようになりました。
CR127888、CR111024	キャッシュ フィルタの使用時に、負荷のかかっている状態でサーバがハングしていました。 分析の結果、ロックされている範囲と比べてロックされているキーのバランスが取れていないことが判明しました。 コードを変更してこの問題を解決しました。
CR134414	以前のサービス パックでは、シリアライズ可能なサーブレット リクエスト属性を追加して、それをシリアライズできない値で上書きすると、元の値によって新しい値がマスクされていました。 コードを変更してこの問題は解決しました。

SNMP (Simple Network Management Protocol)

変更要求番号	説明
CR113122	sysUpTime で WebLogic Server SNMP エージェントから返された値が、SNMP が初期化されてから経過した時間を正確に示していませんでした。 コードを変更してこの問題は解決しました。

Web アプリケーション

変更要求番号	説明	問題が修正されたリリース
CR175651	対象事項 コンテナが、Web アプリケーションのアンデプロイメント中または再デプロイメント中に、処理中の Web アプリケーション リクエストの完了を待機しませんでした。 その結果 Web アプリケーションがコンテキストの使用に依存している場合に、コンテキストが有効でなくなっていることに起因して、アンデプロイ後に NullPointerException が発生していました。 解決方法 解決策として、起動スクリプト ファイルに -D オプション (すなわち weblogic.http.requestCompletionTimeoutSecs) が導入されました。 このフラグに指定される値は、コンテナが処理中の作業の完了を待機する秒数を示します。 デフォルトの値は 0 秒です。つまり、このフラグを指定しない場合、コンテナは完了を待機しません。	7.0 SP4

WebLogic Tuxedo Connector

変更要求番号	説明
CR125533	CLASSPATH に EJB JAR ファイルが含まれていない場合、セッション Bean のサービス メソッドの呼び出しで、TypedFML._tmpresend の呼び出しにつながるオブジェクト レプリケーション ロジックが開始されます。 CARRAY フィールドが null の場合、_tmpresend はフィールド長を (FLDID_SIZE + FLDLEN_SIZE ではなく) 0 として記録します。 最終的には、_tmpostrecv が呼び出され、フィールド長は FLDID_SIZE + FLDLEN_SIZE だと見なされます。 _tmpresend はこの情報を記録しなかったので、負の値がフィールド長として読み込まれていました。 現在、フィールド長で行われるチェックは、それが 0 であるかどうかをチェックします。 これが、NegativeArraySize 例外の理由です。 フィールド長をチェックし、それが 0 以下であるかどうかを判別するためのコードが _tmpostrecv で追加されました。
CR074356	リダイレクトに Name 属性がなかったので、複数の tBridge リダイレクトをお互いに区別することができませんでした。 tBridge リダイレクトに、コンフィグレーション可能な Name 属性が追加されました。
CR110812	Tuxedo Connector キュー ブリッジは、WebLogic Tuxedo デバッグ オプションが設定されていない場合でも WebLogic Server のログにデバッグ メッセージを書き込んでいました。 Administration Console の [Tuxedo Queuing Bridge Connections] タブ ページのタイムアウト値で指定された間隔で、デバッグ メッセージはログに記録されていました。 たとえば、タイムアウト値が 60 秒に設定されている場合は、次のようにデバッグ メッセージが記録されていました。 ####<25-Jun-03 12:49:30 BST> <Debug> <WTC> <jdunn01> <adminserver> <Thread-11> <kernel identity> <59:223361a20602d183> <180046> </tBexec/tuxQ2jmsQ/TPException TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0> ####<25-Jun-03 12:50:30 BST> <Debug> <WTC> <jdunn01> <adminserver> <Thread-11> <kernel identity> <60:223361a20602d183> <180046> </tBexec/tuxQ2jmsQ/TPException TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0> ####<25-Jun-03 12:51:31 BST> <Debug> <WTC> <jdunn01> <adminserver> <Thread-11> <kernel identity> <61:223361a20602d183> <180046> </tBexec/tuxQ2jmsQ/TPException TPETIME(13):0:0:TPED_MINVAL(0):QMNONE(0):0> ...... この問題は、コードを変更して解決されました。
CR121355	応答メッセージの TypedCArray バッファが、不適切に 4 バイト アラインでパディングされていました。TypedCArray オブジェクトでは、パディングを行うべきではありません。 CARRAY メッセージ バッファを使用して wtc サービスに対して tpcalls を行う Tuxedo クライアントのテストでは、次のような結果が出ていました。 wtc サービスが 174 バイトを送り返す場合、tuxedo クライアントは 176 バイトを受信する wtc サービスが 175 バイトを送り返す場合、tuxedo クライアントは 176 バイトを受信する wtc サービスが 176 バイトを送り返す場合、tuxedo クライアントは 176 バイトを受信する wtc サービスが 177 バイトを送り返す場合、tuxedo クライアントは 180 バイトを受信する この問題は、サービスが別の tuxedo ドメイン ゲートウェイで動作している場合には起こっていませんでした。 この問題は、コードを修正して解決されました。
CR121432	weblogic.wtc.tbridge.tBexec クラスで、tpenqueue を実行しているときに、コードが null の replyQ をチェックし、見つかった場合はコンフィグレーションされているリクエスト キューの名前で置換していました。 このチェック機能は廃止され、NULL は replyQ でコンフィグレーション可能な値になっています。
CR122953	weblogic.wtc.jatmi.TypedFML32 クラスの Fchg(FmlKey key, Object value) メソッドが、前のすべてのエントリを規定どおりに null 値で適切に設定していませんでした。 この問題は、コードを修正して解決されました。

Web サービス

変更要求番号	説明
CR122845	SOAP Attachments API for Java (SAAJ) が実装されていなかったので、バージョン 7.0 では SOAPFaultException 例外の java.xml.soap.Detail オブジェクトを作成することができませんでした。 この問題は、WebLogic API weblogic.webservice.util.FaultUtil をエクスポーズするコード変更で解決されました。 このコード変更には、Detail オブジェクトを作成するための newDetail() メソッドが含まれています。 注意 : weblogic.webservice.util.FaultUtil API は、WebLogic Server のバージョン 8.1 以降では非推奨になります。 それらのバージョンでは、SAAJ API を使用して Detail オブジェクトを作成します。
CR120594	clientgen の typeMappingFile で指定されたカスタム型マッピング ファイルは無視されていました。 この問題は、カスタム型マッピング ファイルを設定し、デフォルトのマッピング ファイルをオーバーライドすることで解決しました。
CR103985	startWebLogic.cmd スクリプトの「Setting javax.xml.soap.MessageFactory」でのプロパティの設定が、JSP およびサーブレットの org.xml.sax.driver、org.xml.sax.parser、javax.xml.soap.MessageFactory、および javax.xml.rpc.ServiceFactory で機能していませんでした。 コード変更の後、WebLogic Server は実際に設定する前にプロパティが既に設定されているかどうかを確認し、設定されていない場合はデフォルト値に設定します。
CR129061	Apache SOAP クライアントはパラメータを取るメソッドでは WebLogic Server Web サービスに適切に接続しますが、パラメータなしのメソッドの場合はサーバ側で次のエラーが生成されていました。 javax.xml.soap.SOAPException: Found SOAPElement ['']. But was not able to find a Part that is registered with this Message which corresponds to this SOAPElement コードを変更してこの問題を解決しました。
CR126896	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_47.00.jsp のセキュリティ勧告に関する情報を確認してください。
CR089677	クラス weblogic.xml.schema.binding.FaceUtils は webservices.jar にありましたが、webserviceclient.jar にはありませんでした。 クライアントが複合パラメータ (Java オブジェクトのリストなど) を Web サーバに渡すときにこのクラスが存在しないことが明らかになると、その不在が原因でエラーが発生していました。
CR090950、CR172603	クライアント側のハンドラで SOAPElement.getElementName() にアクセスすると、ClassCastException が生じていました。SOAPElement が、javax.xml.soap.Name を実装していない名前クラスで作成されていたからです。 この名前クラスは、javax.xml.soap.Name に変換されるようになりました。
CR091230	clientgen Ant タスクは、WSDL から Java コードを生成するときにアンダースコア (_) を削除していました。 コードを変更してこの問題を解決しました。
CR097344	autotype コード ジェネレータが、型のない属性または型が匿名の属性を適切に処理していませんでした。 コードの修正で、この問題は解決されました。
CR099339	-Dweblogic.webservice.verbose=true でサーバを起動すると、詳細出力でリクエストと応答 XML ではなく応答 XML が 2 回表示されます。 最初の出力のタイトルは、それが応答であっても「Request」となります。 コード変更の後は、Dweblogic.webservice.verbose が有効になっている場合に、SOAP リクエストと応答が適切にサーバ側の stdout に出力されるようになりました。
CR105715	WebLogic Server の clientgen Ant タスクが、WSDL ファイルにハイフンが残ることを不適切に許していました。 これが原因で、生成された Java コードは Java では許されていないハイフンのあるクラス名やメソッド名を持っていました。 NameUtils の修理により、clientgen がハイフンを削除するようになりました。 また、JAXRPC のメソッドとクラスについては、生成された文字列が Java のキーワードでもある場合、WebLogic Server は JAXRPC 仕様 1.0 および 1.1 に従って _ を先頭に付けます。
CR106741	clientgen の複数のサービスで useServerTypes を指定しても、正しく機能していませんでした。複数のサービス エントリを持つ servicegen を実行して、useServerTypes=true を指定したクライアントを生成する場合に、型ファイルがクライアント用にエンタープライズ アプリケーションから必ずしもコピーされず、型コードの生成でゲッターとセッターのメソッド名から「_」が削除されていました。 現在は、クライアントが useServerTypes=true を設定する servicegen タスクで複数のサービスを指定できます。 たとえば、次のように指定しても機能するようになりました。 <target name="ear"> <servicegen destEar="RetailServicesServerBEA" warName="RetailServicesServerBEAWebApp"> <service javaClassComponents="com.hp.wsmo.demo.retail.webservice. products.ProductsWS"targetNamespace="http://localhost:70 01/javaclass"; serviceName="Products" serviceURI="/Products" expandMethods="true"> <client packageName="com.hp.wsmo.demo.retail.client.bea. products" clientJarName="PRODUCTS.jar" useServerTypes="true" /> </service> <service javaClassComponents="com.hp.wsmo.demo.retail.webservice. orders.OrdersWS"targetNamespace="http://localhost:7001/ javaclass"; serviceName="Orders" serviceURI="/Orders" expandMethods="true" style="rpc"> <client packageName="com.hp.wsmo.demo.retail.client.bea.orders" clientJarName="ORDERS.jar" useServerTypes="true" /> </service>
CR107542、CR136469	7.0 の以前のサービス パックでは、リクエストをソケットに書き込むときに URL パスのみが Request-Line で使用され、Web サービスの URI の HTTP クエリと参照パラメータは Web サービスに渡されていませんでした。 クエリと参照パラメータは、それらがある場合はリクエストの URI に追加されるようになりました。
CR111879	Date を引数として使用する Web サービスをテストするときに、Web サービスで、ユーザ名とパスワードを要求するセキュリティ ダイアログが表示されていました。 この問題は、引数が文字列に変更されたときには起こりませんでした。 セキュリティ ダイアログを排除し、Date 引数を使用するときに適切にサービスを呼び出すコード変更で、この問題は解決しました。
CR112443、CR109898、CR126134	メソッドにパラメータとして org.w3c.dom.Document[] を渡すと、次の行で始まる SOAPException が送出されていました。 javax.xml.soap.SOAPException: Found SOAPElement [<anyType> <this xmlns="mynamespace"> <f:that xmlns:f="yournamespace"> <or> a lot of random &lt; </or> <f:the> </f:the> <f:other> foo bar blaz</f:other> </f:that> </this> </anyType>]. But was not able to find a Part that is registered with this Message which corresponds to this SOAPElement ... コードを修正してこの問題を解決しました。
CR112940	サービス パック 5 の WebLogic Server では、以前は欠けていた SOAPHeader クラスの以下のメソッドが実装されました。 examineHeaderElements extractHeaderElements examineMustUnderstandHeaderElements examineAllHeaderElements extractAllHeaderElements
CR120076	リクエストの偽の認可ヘッダが原因で、Web アプリケーションでセキュリティ制約が定義されていない場合でも、Web サービス エンジンが基本認証を実行しようとしていました。 コードを変更してこの問題は解決しました。
CR120548	WebLogic Server 7.0 の SP02 と SP03 では、ユーザが次のクライアント呼び出しを使用して webservices.basic.statelessSession サンプル Web サービスにアクセスした場合に、 String returnVal = port.sayHello(4, "¥n¥n <--spaces and ¥¥n¥¥n"); 先頭のスペース (改行とスペース) が削除され、サーバ側では現れていませんでした。 この問題は、コードを修正して解決されました。
CR120741	クライアントが静的であるか、動的であるか、あるいは Web サービスのテスト ホーム ページであるかに関係なく、Web サービスのオペレーションに char を渡すときに問題が発生していました。 パラメータとして char を渡すと、次のアサーション エラーが生じていました。 run: [java] weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ invalid class: class java.lang.String ] [java] at weblogic.utils.Debug.assertion(Debug.java:84) [java] at weblogic.xml.schema.binding.internal.builtin.JavaCharSerializer.getContentFromObject(JavaCharSerializer.java:23) [java] at weblogic.xml.schema.binding.internal.builtin. XSDSimpleTypeSerializer.writeContentToStream(XSDSimple TypeSerializer.java:137) [java] at weblogic.xml.schema.binding.internal.builtin.XSDSimpleTypeSerializer.writeContents(XSDSimpleTypeSerializer.java:130) [java] at weblogic.xml.schema.binding.CodecBase.serializeInitialWrite(CodecBase.java:370).... この問題は、コードを修正して解決されました。
CR121394、CR128988	ISAPI フィルタを使用して Web サービスでメソッドを呼び出すと、次の例外が生じていました。 java.lang.IllegalArgumentException: Illegal MimeHeader name or value コードを変更してこの問題は解決しました。
CR122716	基本型のネームスペースが異なる場合に、Clientgen では拡張型の生成されたクラスをコンパイルすることができませんでした。 分析の結果、異なるパッケージの基本クラスがインポートされないことが判明しました。 完全なパッケージ名を使用して基本クラスの名前が生成されるようになって、この問題は解決しました。

 

---

WebLogic Server 7.0 サービス パック 4 のソリューション

以下の節では、WebLogic Server 7.0 サービス パック 4 (SP4) で解決された問題を説明します。ここで示す解決済みの問題のリストは、定期的に更新されます。

• Administration Console

• クラスタ

• コネクタ

• EJB

• EJB

• JDBC

• JMS

• JSP とサーブレット

• JTA

• ノード マネージャ

• セキュリティ

• ツール

• Web サービス

Administration Console

変更要求番号	説明
CR091853	3 ノードのクラスタが複数の独立した Solaris 2.8 マシン上にある場合は、デフォルトの実行キューにアクセスするときに管理サーバから InstanceNotFound 例外が送出されていました。 この問題は解決済みです。
CR104066	アプリケーション ポーラーが原因で CPU の使用率が高くなることがありました。 現在、adminMBeanHome.getMBeansByType("Application") は各ポーリング間隔で 1 回のみ実行されるようになっています。
CR105456	互換性セキュリティの使用時に Administration Console で [セキュリティ｜レルム｜CompatibilityRealm｜プロバイダ｜裁決｜RealmAdapterAdjudicator] ノードの [詳細] タブを選択すると、javax.management.AttributeNotFoundException が生じます。 [詳細] タブは、属性 RequireUnanimousPermit を探していました。この属性は、RealmAdapterAdjudicator MBean では指定されなくなっています。この問題は解決済みです。
CR106122	WebLogic Server 7.0 では、以前は MLET 要素の NAME 属性を指定する必要がありました。 JMX 仕様に準拠するために、NAME 属性は必ずしも指定する必要がなくなりました。
CR110224	クラスタ環境では、getMBeansByType を使用して MBean にアクセスするために初期コンテキストが管理対象サーバから取得された場合に、管理サーバを再起動すると次の行で始まる例外が送出されていました。 java.rmi.ConnectException: This RJVM has already been shutdown 管理対象サーバの再接続で JNDI をリバインドすることで問題は解決されました。
CR110557	Monitors グループのみに属するユーザは、デプロイメント、サーバの状態、およびクラスタをモニタすることができませんでした。 この問題は解決済みです。

クラスタ

変更要求番号	説明
CR108127	プライマリ サーバ A からセカンダリ サーバ B に切り替えると、サーバ B が A をセカンダリとして再登録することなくプライマリ サーバとして再登録されていました。 サーバ A からサーバ B に切り替えて、再びサーバ A に戻すと、セッションが古くなっていました。 サーバ A のプライマリ ステータスは、サーバ B がプライマリ サーバになったときに削除されるようになりました。

コネクタ

変更要求番号	説明
CR106960	RAR が EAR に含まれている場合、その EAR の再デプロイメントは失敗していました。コネクタ モジュールのコードが再デプロイメントを適切に処理しなかったためです。 コネクタ モジュールの再デプロイ ロジックを修正することで問題は解決しました。

EJB

変更要求番号	説明
CR106041	ejbc で、BMP (Bean 管理の永続性) Bean のオプティミスティックな同時方式を許可しない準拠チェックが実行されるようになりました。 オプティミスティックな同時方式は、EJB 2.0 の CMP (コンテナ管理の永続性) Bean の機能です。 「WebLogic Server EJB コンテナとサポートされるサービス」の「EJB の同時方式」を参照してください。
CR103391	Microsoft の JDBC ドライバには制限があり、そのため、行とカラムから成る特定の結果セットについて、getXXX メソッドを 1 行につき 1 度しか呼び出すことができません。 この制限は、クエリ カラムの中にテキスト カラムまたは画像カラムが含まれている場合にのみ適用されていました。 WebLogic Server で生成された JDBC は (たとえば getLong(1) を使用して) 行からキー値を取得し、その結果セットを、getLong(1) を再実行して、最初のカラム値を含むすべてのカラム値を読み込む別のルーチンに渡していました。 この再実行により、Microsoft のドライバは例外を送出していました。 この問題は、resultSet の主キー カラムが 2 回解析されるのを防止するコード修正で解決されました。
CR105966	weblogic-cmp-rdbms-jar.xml の field-group エントリに CMR フィールドが含まれていると、次のエラーでコンパイルが失敗していました。 D:¥AA¥bea70sp1¥weblogic700¥samples¥server¥src¥examples¥ejb20¥relationships¥Fathr¥EJB_Problem2>java weblogic.ejbc fatherError.jar fathersonError.jar ejbcgen¥temp_lr_sahre_jb8¥SonBean_1saa__WebLogic_CMP_RDBMS.java:909: incompatible types found : <null> required: int __WL_bean.__WL_isLoaded[null] = true; 1 error Exec failed .. exiting この問題は解決済みです。
CR106774	WebLogic Server で生成された EJB SQL クエリでは、「>= AND <=」が演算子として使用されていました。 IBM DB2 は「<=」を処理せず、したがって同じ機能の「BETWEEN」を必要としません。 DB2 では、生成された EJB SQL が「>= AND <=」の代わりに BETWEEN を使用するようになり、NOT BETWEEN も適切に処理するようになりました。

JDBC

変更要求番号	説明
CR109941	weblogic-application.xml で指定された情報に基づいて localDataSource オブジェクトを作成すると、NullPointerException が送出されていました。 メソッド weblogic.jdbc.common.internal.LocalDataSource.defineDriverProps は、PoolParamsMBean、ConnectionCheckParamsMBean、および XaParamsMBean について null 値をチェックしていませんでした。 この問題は解決済みです。

JMS

変更要求番号	説明
CR108665	JMS サーバは、キュー ブラウザの参照リストにまだそのメッセージがあるのに永続ストアから期限切れメッセージを削除し、その結果としてページング IO 例外が送出されていました。 コードの変更によってページングの処理が改良され、問題は解決されました。
CR109599	Microsoft SQLServer 2000 を使用して JMS JDBC ストアを作成すると、メッセージがキューにある状態でサーバを再起動した場合に例外が生じていました。 クエリとカラム取得の順序を変更することで問題は解決しました。

JSP とサーブレット

変更要求番号	説明
CR103304	jsp_precompile は、カスタム クラスの拡張版を含むすべての種類の JSP で機能するようになりました。
CR096041、CR108111	WebLogic Server で、ウェルカム ファイルを返すときにリダイレクト (HTTP ステータス コード 302) が使用されなくなりました。 8.1 SP2 および 7.0 SP4 より前のバージョンの WebLogic Server では、302 (moved temporary) ステータス コードとウェルカム ファイルの場所を返していました。 WebLogic Server バージョン 8.1 SP2、7.0 SP4、およびそれ以降では、200 (OK) ステータス コードが返されてウェルカム ファイルの内容が表示されます。 この変更の結果、WebLogic Server のパフォーマンスは向上していますが、ウェルカム ファイルの相対 URL が別の場所を指していて 404 Not Found エラーになることがあります。
CR107419	次のような、2 バイト文字をパラメータの値として設定する JSP コードでは、 <jsp:include page="included.jsp"> <jsp:param name="title" value="<%= java.net.URLEncoder.encode(¥"[double byte characters]¥") %>"/> </jsp:include> 指定された 2 バイト文字が URL エンコーディングされたコードに変更されていました。この問題は解決済みです。

JTA

変更要求番号	説明
CR111719	XA 接続プールで必須の属性 KeepXAConnTillTxComplete は、XA アイソレーション レベルが変更されている場合のみチェックを行うようになりました。

ノード マネージャ

変更要求番号	説明
CR105924	ノード マネージャは、管理サーバが再起動した後に管理対象サーバを停止することができませんでした。 ノード マネージャは、停止時に管理対象サーバのステータスを適切に更新するようになっています。

セキュリティ

変更要求番号	説明
CR105443	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp のセキュリティ勧告を参照してください。
CR110892	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35.jsp のセキュリティ勧告を参照してください。
CR112886	ヘッダの ID アサーション命名規約 (WL-PROXY-CLIENT-*) が、WL-PROXY-CLIENT-KEYSIZE、WL-PROXY-SECRET-KEYSIZE、および WL-PROXY-CLIENT-IP と対立していました。 それらのヘッダを ID アサーション ヘッダとしてフィルタ処理することで、Client-Cert ID アサーション エラーが防止されました。

ツール

変更要求番号	説明
CR112500	weblogic.Admin コマンドは、指定されたユーザとパスワードが認証されないときに正確な終了コードを返しませんでした。 たとえば、存在しないユーザの例を次に示します。 java weblogic.Admin -username george -password hamilton -url t3://localhost:7001 lock この例ではエラー メッセージとユーザが認証されなかったことを示すスタック トレースが返されましたが、終了コードは成功を示していました。 この問題は解決済みです。

Web サービス

変更要求番号	説明
CR104199	.NET C# クライアントを使用して WebLogic Server Web サービスにアクセスし、要求した 2 つの文字列が返される場合に (最初の文字列は結果、2 番目の文字列は in/out パラメータ)、返された 2 つの文字列の順序が正しくありませんでした。 2 番目の文字列が結果として返され、in/out パラメータは null として返されていました。 コードの変更により、返される最初のアクセサが戻り値になります。
CR092268	ファイアウォールの内側で動作するクライアントは、Web サービス スタブでプロパティを設定する必要がありました。 この問題は、2 つの新しいプロパティ weblogic.webservice.client.proxyusername と weblogic.webservice.client.proxypassword の導入によって解決されました。
CR100098	SSL で保護された Web サービスの動的クライアントは、ポート番号がエンドポイント URL に含まれていない場合に機能しませんでした。 デフォルトの SSL リスン ポート 443 が現在は自動的に指定されます。
CR103512 CR107171	スタブで設定された一部のプロパティが、MessageContext にコピーされていませんでした。 コードを変更した後、WebLogic Server は以下の使用事例をサポートするようになりました。 エンドポイントは、次のフローで修正できます。 Stub->MessageContext in handleRequest->MessageContext in handleResponse->StubCall->MessageContext in handleRequest->Call タイムアウトは、次の順序で設定できます。 Stub->MessageContext in handleRequest Call->MessageContext in handleRequest
CR108579	配列またはユーザ定義の型を使用した、ドキュメントリテラル形式の Web サービスからの SOAP 応答に、不適切にネームスペースで修飾された要素が含まれていて、その結果として .Net が一部のデータを無視してました。 この問題は、ネームスペース情報を SOAP 要素に渡すことで解決しました。
CR109150	weblogic.webservice.tools.versioning.VersionMaker ユーティリティで作成されたポータブル スタブを使用すると、NoClassDefFoundError 例外が生じていました。 wsclient70.jar には、クライアントサイド メッセージ ロガーではなくサーバサイド メッセージ ロガーが含まれていました。 wsclient70.jar を更新することで、この問題は解決しました。
CR110168	clientgen タスクで作成された、配列を返すサービスのクライアントは、サーバから返された XML が明示的に配列のサイズを指定していない場合には失敗していました。 サイズの指定されていない SOAP 配列の場合、オブジェクトは配列が作成される前にリストに格納されるようになりました。
CR110384	wspackage に codecDir が欠けていることで、NullPointerException が生じていました。 codecDir は現在は wspackage で必須ではありません。 この問題は解決済みです。
CR111187	weblogic.webservice.binding.soap.HttpResponse クラスで、メソッド getBodyAsString が「String index out of range」エラーを送出していました。 コードの変更により、メソッドはエンドの代わりにボディの長さを使用するようになり、問題は解決されます。

 

---

WebLogic Server 7.0 サービス パック 3 のソリューション

以下の節では、WebLogic Server 7.0 サービス パック 3 で解決された問題を説明します。

• Administration Console

• コネクタ

• コア サーバ

• デプロイメント

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

• EJBJDBC

• jDriver

• JMS

• JNDI

• JSP とサーブレット

• JTA

• プラグイン

• RMI/RMI-IIOP

• セキュリティ

• システム管理

• ツール

• Web サービス

• WebLogic Tuxedo Connector

• XML

Administration Console

変更要求番号	説明
CR069284	Administration Console の [ドメイン｜コンフィグレーション｜アプリケーション] タブで [自動デプロイを有効化] 属性をコンフィグレーションできなくなりました。自動デプロイメントの制御については、『WebLogic Server アプリケーションの開発』の「自動デプロイメント」を参照してください。
CR069927	[サーバ｜モニタ｜プロセス出力] を選択し、表示オプションを選択しても、出力が表示されませんでした。ノード マネージャが動作している状態で [ノード マネージャ出力を表示] を選択すると、ノード マネージャがクラッシュしました。 コードの修正で、この問題は解決されました。
CR076953	状況依存 (右クリック) メニュー項目の [個別の Bean のポリシーとロールを定義...] を使用してロールを作成し、(同じ状況依存メニューとフォームを使用して定義された) ポリシーにロールを追加する場合、目的のリソースは外部 JCom クライアントからは使用できません。 状況依存メニュー項目ではスコープ ロールが作成され、スコープ ロールの外部にあるクライアントはリソースを使用できません。 JCom ノードに [Define JCom Roles] メニュー項目を追加し、修正されたスコープに現在のクライアントが含まれるようにすることで、この問題を解決しました。
CR078764	Web サービスに対する Administration Console のセキュリティ設定が正しく機能しませんでした。 Administration Console で Web サービスに対してポリシーとロールを設定できないようにコードを変更しました。
CR081673	Administration Console で作成されたレルムには RealmMBean の UserLockoutManager がありませんでした。 Administration Console で新しいレルムを作成すると ULMbean が作成されるようになりました。
CR081673	新しいセキュリティ レルムを作成すると、[ユーザ ロックアウト] タブに「User lockout feature not supported by the configured providers」というメッセージが表示されました。この問題は、新しいセキュリティ レルムの作成時にユーザ ロックアウト マネージャが作成されるようにコードを修正することで解決されました。
CR082335	ユーザおよびグループのリスト用に Administration Console によって作成されるカーソルがクローズされない場合に、メモリ リークが発生する可能性がありました。 コードの修正によって、カーソルはクローズされます。
CR083530	[サーバ｜ログ｜HTTP] コンソール ページに、新しい属性 LogTimeInGMT が追加されました。この属性では、ホスト コンピュータで指定されたローカル タイム ゾーンに関係なく、HTTP ログ メッセージのタイム スタンプがグリニッジ標準時で書き込まれることを指定します。
CR088262	JMS サーバの移行可能な対象が保存され、対象が以前の設定に戻される問題が修正されました。
CR089652	Administration Console から管理対象サーバの SSL ポートを無効にすると、次のような AssertionError が発生しました。 weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ ServerIron for server not found ] 検証プロセスで管理対象サーバのコンフィグレーション MBean をチェックするようにすることで、問題を修正しました。
CR090059	WebLogic Server Administration Console では、WebLogic Security サービスのセキュリティ チェックの実行方法を指定する必要があります。 これを指定するには、WebLogic Server の起動時に設定するコマンドライン引数である fullyDelegateAuthorization フラグを使用します。 fullyDelegateAuthorization フラグの値が false の場合、WebLogic Security サービスは関連付けられているデプロイメント記述子 (DD) でセキュリティが指定されている URL および EJB リソースでのみセキュリティ チェックを行います。これはデフォルト設定です。 『WebLogic リソースのセキュリティ』の「fullyDelegateAuthorization フラグについて」を参照してください。
CR090266	config.xml の Application タグには、Administration Console から設定できない LoadOrder 属性があります。 コードを変更して、モジュール ページに設定を追加しました。
CR090266	Administration Console から config.xml 内の Application タグの LoadOrder 属性を設定できませんでした。 アプリケーション モジュール (Application、ConnectorComponent、EJBComponent、WebAppComponent、JDBCPoolComponent) に LoadOrder 属性を追加して、この問題を修正しました。
CR090481	以前のサービス パックでは、NTFS ボリュームに WebLogic Server をインストールした場合、代わりのログ ファイルの場所を指定すると、Administration Console でサーバ ログを表示できませんでした。ログの場所の設定は次のとおりです。 <Server Name="myserver" ServerVersion="7.0.0.0"> <Log FileName="c:¥temp¥myserver.log" Name="myserver"/> </Server> サーバは java.io.FileNotFoundException を送出しました。 FileName 属性の呼び出しをカスタムのゲッターに移動して (以前の FileStreamHandler への依存を解消して)、LogFileSearchServlet が MBean から直接 FileName 属性を取得するようにすることで、この問題を解決しました。
CR091170	Examples サーバ上で新しい Web アプリケーション、EJB、またはコネクタを複製しようとすると、Administration Console には次のようなメッセージの予期しないエラー ページが表示されました。 javax.management.InvalidAttributeValueException: Path is NULL 解決策として、ApplicationTable、EJBComponentTable、WebAppComponentTable、ConnectorComponentTable から [クローン] アイコンを削除しました。
CR091325	Administration Console から JMS トピックおよびキューのポリシーをコンフィグレーションできるようになりました。
CR091359	Administration Console のオプション [Web Application｜webapp1｜モニタ｜すべての アクティブな Web アプリケーションのモニタ...] は、EAR ファイル内の Web アプリケーションでは失敗していました。 この問題は、コードを修正して解決されました。
CR093289	Administration Console に表示されるログ メッセージで、UTF8 エンコーディングの使用時にそのテキストの一部が切り捨てられる問題が修正されました。
CR095556	アクセス ログの [ローテーション時間] の日付の書式として 00:00 を指定すると、Administration Console は次のような AssertionError を送出していました。 weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Could not parse LogRotationTimeBegin: 00:00 because Unparseable date: "00:00" ] Log MBean と WebServer MBean に時間の書式の検証を追加することで、問題を修正しました。
CR095694	日本語の weblogic.properties ファイル コンバータと関連するファイル ブラウザの表示上の問題が修正されました。
CR098353	TransactionLogFileWritePolicy 属性が 7.0 SP01 で追加されましたが、Administration Console でエクスポーズされませんでした。 この属性を設定するフィールドが、[サーバ｜ログ｜JTA] タブに追加されました。
CR099721	Administration Console を使用して [CookieMaxAgeSecs] を編集した後で、値が編集前の値に戻ることがありました。 コードを変更して値の下限を削除することで、問題を修正しました。
CR102982	[クライアント証明書プロキシを有効化] チェック ボックスがサーバの [チューニング] タブに表示されていましたが、この属性はチューニングに関係ありません。 [クライアント証明書プロキシを有効化] フィールドは、サーバの [コンフィグレーション｜一般] タブに移動しました。
CR103104	UserReader MBean は Administration Console にユーザを表示しませんでした。 認証プロバイダは、UserReader ではなく UserEditor を実装する場合に Console にユーザを読み込むことができます。ユーザを読み込もうとすると、「ユーザの作成をサポートする認証プロバイダがありません。」というメッセージが表示されます。 グループの場合 (GroupEditor および GroupReader インタフェース) にも同じことが発生します。 Administration Console は userEditor.CreateUser メソッドを呼び出し、UserReader.listUsers メソッドを呼び出しませんでした。 適切なプロバイダ タイプを探すように MBean を修正しました。
CR105624	サーバが MSI (管理対象サーバ独立) モードで起動された場合、管理対象サーバのアドレスとポートから WebLogic Server Administration Console にアクセスできました。 コードを変更して、この不適切なアクセスを制限しました。
CRO68646	weblogic.Admin ユーティリティでは、指定されたプロトコルに関係なく T3 プロトコルが使用されていました。 たとえば、コマンド「java weblogic.Admin - url http://localhost:7001」では T3 を使用して、localhost:7001 でリスンするサーバ インスタンスに接続していました。 このユーティリティは、指定すれば HTTP または HTTPS を使用するように更新されています。それらのプロトコルを使用するには、HTTP トンネリングを有効にする必要があります。 Administration Console オンライン ヘルプの「HTTP プロトコルのコンフィグレーション」を参照してください。

クラスタ

変更要求番号	説明
CR086319	特定の状況で、管理サーバの下で動作する管理対象サーバの停止時に、ノード マネージャが不要なスタック トレースを書き込みました。 この問題は、クエリの応答が返される前に管理対象サーバが一定期間待機するために HttpUrlConnection.getInputStream が返されないことで発生しました。 これは、管理対象サーバを継続的にモニタするための意図的な動作でした。 ただし、管理対象サーバが停止するときに、遅れたサーブレット応答は送信されず、ソケットがクローズされました。 続いてノード マネージャは接続を再び開こうとしましたが、サーバが動作していないため openServer 呼び出しは失敗しました。 これに応じて、openServer によって ConnectException が送出されログに記録されました。 ノード マネージャは不要なスタック トレースを書き込まなくなりました。
CR093809	スタック トレースが、セッションのルックアップ エラーから生じていました。セカンダリ サーバ インスタンスが停止されていました。対応した要求のログ エントリを作成するときに、HTTP サーバはセッションからユーザ情報を取得しようとしました。結果として、それがダウンしていてもセカンダリ サーバをルックアップしようとして、次のようなスタックトレースが生じていました。 <Dec 26, 2002 7:17:55 PM EST> <Error> <HTTP Session> <Error looking up session for id:2LcR6Ool2IC5qNtFZhThJClYVYEXt9KWG2ciXmAXZ4XiBAHPiHx4!-13795051 94!stcasfi01b.usa-ed.net!8001!7002!-1127797657!stcasfi02b.usa-ed. net!8001!7002 java.rmi.ConnectIOException: Server is being shut down Start server side stack trace: java.rmi.ConnectIOException: Server is being shut down at weblogic.rjvm.RJVMImpl.dispatchRequest(RJVMImpl.java:692) at weblogic.rjvm.RJVMImpl.dispatch(RJVMImpl.java:666) at... プライマリ サーバは利用可能なサーバのリストから新しいセカンダリを適切に選択していたので、セッション データは失われませんでした。 この問題は、コードを修正して解決されました。現在、サーバはセッションではなく ThreadLocal からユーザ情報を取得します。
CR094561	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-26.01.jsp のセキュリティ勧告に関する情報を確認してください。
CR094837	次のような手順で ClassCastException が発生しました。サーバを定義する。サーバをクラスタに割り当てる。サーバと同じ名前の Unix マシンを作成する。Unix マシンとサーバを互いに割り当てる。管理サーバを停止および再起動する。クラスタまたはサーバ リストからサーバ名を選択する。 管理対象サーバを起動する場合にも ClassCastException が発生しました。 起動時に UnresolvedMBean を解決するプロセスでの問題を修正して、この問題を解決しました。
CR104430	クライアントがクラスタ内の 1 番目と 2 番目のサーバ (クライアントのプライマリ サーバとセカンダリ サーバ) から 3 番目のサーバに切り替えるときに、クラスタ化されたサーバでセッションが失なわれる可能性がありました。 プロセスは最初の 2 つのサーバからセッションを削除します。クライアントがプライマリ サーバに戻ると、プライマリ サーバは 3 番目のサーバ上ではなく、セカンダリ サーバ上でセッションを探しました。 3 番目のサーバ上でセッション情報からセッションを再作成し、プライマリおよびセカンダリ サーバからセッションを完全に削除するようにコードを修正して、問題を解決しました。
CR105482	2 つの実行中の管理対象サーバが含まれるクラスタで新しい管理対象サーバを起動すると、実行中のいずれかのサーバで ConcurrentModificationException が発生しました。 クラスタのメンバーが同期化の要件を満たすようにコードを変更して、問題を修正しました。
CR105698	2 つのクラスタ間に同じ JNDI 名の 2 つの分散キューがあり、メッセージ駆動型 Bean が両方のクラスタにデプロイされている場合、メッセージはいずれかのクラスタのみで消費されました。 メッセージ駆動型 Bean はドメイン内の分散キューの集合全体に機能し、メンバーを適切に追加するようになりました。
CR106384	クラスタ内に 1 つの管理サーバと 2 つの管理対象サーバがありました。 application1.ear には EJB と Web アプリケーションが含まれていました。EJB はクラスタにデプロイされていました。Web アプリケーションは仮想ホストにデプロイされ、仮想ホストはクラスタに割り当てられていました。 application1.ear には、仮想ホストのデフォルト Web アプリケーションとしてコンフィグレーションされた application1.war が含まれていました。さらに、各クラスタ ノードには独自のデフォルト Web アプリケーションがありました。 デプロイメントは成功しましたが、application1.ear をアンデプロイしようとすると以下の例外が発生しました。アプリケーションは、ドメイン全体を再起動しても再デプロイできませんでした。 Exception caught for task Unprepare application application1 on mycluster,application1: Start server side stack trace: java.lang.reflect.UndeclaredThrowableException: java.lang.reflect.InvocationTargetException: javax.management.ListenerNotFoundException: listener: ServletContext(id=559103557,name=DefaultWebApp,context-path=) Web コンテナは、すべての WAR をアンデプロイして、デフォルト Web アプリケーションをアンデプロイしようとしました。デフォルト Web アプリケーションはすでにアンデプロイされているため、最初の WAR は成功しましたが、2 番目の WAR は失敗しました。 対象の Web アプリケーションのコンテキストが http サーバ上に存在しない場合、デフォルト Web アプリケーションがアンデプロイされないようにコードを変更しました。その修正で、問題は解決されました。
CR107273	クラスタで、MulticastTTL に値「0」を設定すると、WebLogic Server は設定を無視してデフォルト値の 1 を取得し、次のようなエラーを送出しました。 "clusterdomain:Name=mycluster,Type=Cluster" is smaller than the minimum allowed: 1 値を「0」にできるようにコードを変更して問題を解決しました。
CR134233、CR102655	WebLogic Server 6.1 SP04 では、シリアライズされていないオブジェクトのレプリケートが失敗した後にセッション レプリケーションが機能を停止していました。 シリアライズされていないデータをセッション オブジェクトに設定する JSP の呼び出しでは、次のような予測可能な例外が送出されていました。 <Mar 19, 2003 2:58:23 PM PST> <Error> <Cluster> <All session objects should be serializable to replicate. Please check the objects in your session. Failed to replicate non serializable object> その後、それ以降のすべてのリクエストについて、セッションがレプリケートされず、次の例外が生じていました。 <Mar 19, 2003 2:58:48 PM PST> <Debug> <Cluster> <Unable to create secondary for -8956818414963087828> この問題は、コードを修正して解決されました。 現在は、シリアライズできないオブジェクトに遭遇したときに、メソッドは他のセカンダリを試すことなく復帰します。
CR110385	2 つの管理対象サーバ間の NetworkChannel で URL を作成するときに HomeHandleImpl クラスで間違ったポート番号が作成されないように、listenPort と sslListenPort はデフォルト値で初期化されるようになりました。

コネクタ

変更要求番号	説明
CR069426	max-capacity と initial-capacity が同じ場合に RAR をデプロイすると、コンフィグレーション例外が送出されていました。 max-capacity と initial-capacity が等しいときに値が考慮されないよう、weblogic-ra.xml の .xpi の capacity-increment のチェックが変更されました。 また、max-capacity と initial-capacity が等しい場合には増加容量をゼロに設定できるようになっています。
CR086862	「Unable to locate context: java:/comp/env/WebLogic Server-connector-resref」などの、説明のつかないログ メッセージがコネクタのログ ファイルに記録されていました。 コネクタの担当チームが、拡張の意味で大量のログ メッセージを削除しました。
CR091106	コネクタ RAR ファイルの再デプロイ後、WebLogic Server の組み込み LDAP サーバは管理対象サーバへのデータの複製を停止していました。 コードの変更によって、レプリケーションの動作は改善されます。
CR100707	7.0 SP3 より前の WebLogic Server で JCA を使用すると、java.naming.CompositeName で java.lang.ClassCastException が送出されていました。 WebLogic Server 8.1 で JCA を使用した場合は、Web アプリケーションの場合に、resource-ref のエントリ (Auth、SharingScope) で null が返されていました。 この問題は内部エラーが原因で発生し、コードの修正で解決されました。
CR101761	7.0 SP3 より前の WebLogic Server で JCA を使用する場合に、java.naming.CompositeName で java.lang.ClassCastException が送出されていました。 WebLogic Server 8.1 で JCA を使用した場合は、Web アプリケーションの場合に、resource-ref のエントリ (Auth、SharingScope) で null が返されていました。 この問題は内部エラーが原因で発生し、コードの修正で解決されました。
CR101906	クライアントは EJB のメソッドを呼び出しました。ManagedConnection (MC) と EIS の間で接続が失敗したときに、XA トランザクションの場合に、コンテナは XA トランザクションがロールバックされた後で 60 秒ごとに XAResource.rollback と ManagedConnection.cleanup を呼び出しました。EIS に対する以降の呼び出しは java.lang.NullPointerException 例外になりました。 <Mar 21, 2003 5:50:52 PM PST> <Error> <Connector> <190041> << JCA Resource Adapter for ClearPath MCP_eis/comsRAJNDINAMEBrazil > The returned ManagedConnection instance is null> <Mar 21, 2003 5:50:52 PM PST> <Info> <EJB> <010051> <EJB Exception during invocation from home: drummer.CedarBank.CedarBankBeanBrazil_ris6bf_HomeImpl@12fc36 threw exception: java.lang.NullPointerException java.lang.NullPointerException at drummer.CedarBank.CedarBankBeanBrazil.cedarBank(CedarBankBeanBrazil.java:130) at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl.cedarBank(CedarBankBeanBrazil_ris6bf_EOImpl.java:46) at drummer.CedarBank.CedarBankBeanBrazil_ris6bf_EOImpl_WebLogic Serverkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362) at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:785) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134) WebLogic Server は接続を破棄する前にトランザクションの完了を待機していませんでした。 コードの修正で、この問題は解決されました。
CR106388	ra-link-ref 要素を使用する RAR (「論理的な」RAR) をデプロイするときに、論理的な RAR デプロイメントは、weblogic-ra.xml デプロイメント記述子で指定された正しいプール名または max-capacity を取得しませんでした。そのため WebLogic Integration で予期しない動作が発生しました。 要素は正しく機能するようになりました。

コア サーバ

変更要求番号	説明
CR070887	JDK1.3.1 では、java.net.HttpURLConnection で getInstanceFollowRedirects() および setInstanceFollowRedirects() というメソッドが追加されました。これらのメソッドを使用すると、特定の HttpURLConnection で URL のリダイレクトを無効にできます。 HttpURLConnection は、setInstanceFollowRedirects() で設定されたフラグを無視していました。 この問題は、InstanceFollowRedirects の設定に従ってプロセスがリダイレクトするように WebLogic Server の HttpURLConnection リダイレクト ロジックをコード修正して解決されました。
CR071415	WebLogic Server のセキュリティ マネージャが有効になっていて、ポリシー ファイルが設定されているときに、JSP のコンパイル時に javac に path /usr/lib が付加されましたが、java.security.AccessControlException になりました。 Executable.resolveExecutable() は、javac コンパイラの位置を確認するときに間違ったパスを検索していました。 Executable.resolveExecutable() が java.library.path を検索する前に JavaCompiler で指定された絶対パスを検索するように、コードを変更しました。
CR077170	WebLogic Server 6.1 SP03 では、管理サーバが停止された後に管理対象サーバを停止すると例外が発生しました。この問題は、アクションが次の順序で行われたときに発生しました。 管理サーバと管理対象サーバを起動する。 管理サーバを停止する。 管理対象サーバの ServerConfigMBean の「停止」メソッドを呼び出す。 次の例外が送出されました。 Unexpected Exception Start server side stack trace: java.rmi.ConnectException: Unable to get direct or routed connection to: '-19546889165621794S:dwarkamai:[7001,7001,-1,-1,7001,-1,-1]:OAMdomain:adminServer' at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109) at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:127) at... weblogic.Admin からの shutdown コマンドは、成功していました。 この問題は、管理サーバがダウンした後で管理対象サーバを停止するときに発生する例外を捕捉することで解決しました。
CR083209	NTSockedMuxer で Windows XP をサポートできるようにコードが修正されました。
CR083762	クライアント上のデータ ソースから接続を取得しようとしたときに NoSuchObjectExceptions が原因で障害が発生しました。次のメッセージが送出されました。 Error dropping table: Unexpected Exception java.rmi.NoSuch ObjectException: The object identified by: '275' could not be found. Either it was has not been exported or it has been collected by the distributed garbage collector. at weblogic.rjvm.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:109) at weblogic.rmi.internal.BasicRemoteRef. invoke(BasicRemoteRef.java:120)at weblogic.jdbc.common. internal.RmiDataSource_WebLogic Servertub.getConnection(Unknown Source) at com.bea.cts.CTSDeployment.executeSQL(CTSDeployment. java:2445)at com.bea.cts.CTSDeployment.undeploy(CTS Deployment.java:711) at com.sun.cts.harness.Suite Synchronizer.continueToUndeployApps(SuiteSynchronizer.java:1082) at com.sun.cts.harness.SuiteSynchronizer. undeployApps(SuiteSynchronizer.java:982) at com.sun.cts. harness.SuiteSynchronizer.doDeployment(SuiteSynchronizer.java:289) at com.sun.cts.harness.CTSGUIHarnessObserver. starting(CTSGUIHarnessObserver.java:167) at javasoft.sqe. javatest.TestRunner$Notifier.starting(TestRunner.java:287) at javasoft.sqe.javatest.TestRunner$Worker.runTest (TestRunner.java:239)at javasoft.sqe.javatest.TestRunner$ Worker.run(TestRunner.java:221) 分析の結果、クライアントにまだその参照があるにもかかわらず、データ ソースがガベージ コレクションされていることが判明しました。 この問題は、クライアントが参照するオブジェクトでガベージ コレクションが行われないようにガベージ コレクションをコード修正して解決されました。
CR087364	Administration Console で [トンネリングを有効化] 属性を変更するには、新しい値が有効になるようにサーバを再起動する必要があります。 この問題は、サーバを再起動することなくトンネリングを有効化できるようにコード修正して解決されました。
CR087808、CR095487	Sunblade 100 シングル CUP Solaris マシンでは、2 つの独立したサーバ インスタンスが相互に InitialContext をルックアップできませんでした。 一方のサーバ インスタンスが InitialContext をルックアップし、同じマシン上の 2 番目のサーバ インスタンスが同じマシン上の InitialContext をルックアップしようした後、次の例外が発生しました。 <2002/10/09 4:23:56:JST> <Debug> <ConnectionManager> <Attempt to sendMsg using a closed connection> javax.naming.CommunicationException. Root exception is java.rmi.ConnectException: Attempt to sendMsg using a closed connection at weblogic.rmi.internal.BasicOutboundRequest.sendReceive(BasicOutboundRequest.java:85) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:262) at weblogic.rmi.cluster.ReplicaAwareRemoteRef.invoke(ReplicaAwareRemoteRef.java:229) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy45.lookup(Unknown Source) at weblogic.jndi.internal.WLContextImpl.lookup(WLContextImpl.java:341) at javax.naming.InitialContext.lookup(InitialContext.java:345) at com.bea.samples.servlet.TestServlet.service(TestServlet.java:40) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:265) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:200) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2546) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2260) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) この問題は、Sun Enterprise 上では再現されませんでした。localhost の代わりに IP アドレスを使用してルックアップを実行すると、Sun Blade でこの問題は発生しませんでした。 分析の結果、クライアントの RJVM が重複する T3JVMConnections を閉じようとすることが判明しました。サーバに対して CMD_REQUEST_CLOSE が発行され、RJVM が閉じられました。ただし、サーバがこのメッセージをキューに入れると、RJVM は閉じたものとしてマークされました。 コードの変更により、重複接続を検出しているときの RJVM の停止が防止され、CMD_REQUEST_CLOSE はサーバに配信されません。
CR088022	WebLogic Server Administration Console では、ノード マネージャで管理サーバおよび管理対象サーバを起動するときに接続情報が表示されません。 コードの修正により、ナビゲーション ツリーでサーバ名を右クリックして [接続を表示] を選択することで接続情報を表示することができます。
CR089454	リクエスト キューによる実行キューの待機を -D フラグで制限して、受信トラフィックを抑制できるようになりました。
CR092454	クライアント仮想マシンから CommoMBeanServerProxy クラスを介して COMMO Bean にアクセスするメソッドは、「bean」の値を設定するコードが Kernel.isServer() によって回避された後で、ObjectName が MBean インスタンスまたは MBean タイプ オブジェクト名のどちらであるかを確認しようとすると、Null ポインタ例外をトリガすることがありました。 コードの変更により、早い回避が防止されます。
CR092704	WebLogic Server 6.1 SP02 では、ソケット リーダー スレッドがブロックされることが原因で頻繁にハングが発生しました。POLL ロックを所有するスレッドが SSL ソケットを閉じようとしましたが、sendRecord() メソッドにおいて必要な出力ストリームのロックを取得できないために、処理を進めることができませんでした。スタック トレースは次のようなものでした。 "ExecuteThread: '23' for queue: 'default'" daemon prio=5 tid=0x6d6c40 nid=0x24 waiting for monitor entry [0xe4e81000..0xe4e81a28] at weblogic.security.SSL.SSLSocket.sendRecord(SSLSocket.java:1049) at weblogic.security.SSL.SSLSocket.sendAlert(SSLSocket.java:1007) at weblogic.security.SSL.SSLSocket.close(SSLSocket.java:1153) at weblogic.security.SSL.SSLSocket.close(SSLSocket.java:1141) at weblogic.socket.SocketMuxer.closeSocket(SocketMuxer.java:236 アボートによる停止に対するクローズでは SSL ソケットがソケットにデータを書き込まないよう、コードが修正されました。
CR092933	次のコンフィグレーションで、スレッド ダンプ エラーが発生しました。 VM: java.version='1.3.1_02' os.name='windows 2000' java.vendor.url='http://java.sun.com/' Hotspot クライアントおよび Version 1.3.1_x 仮想マシンに対して JVM_DumpAllStacks シンボルがグローバルに宣言されていなかったため、スレッド ダンプが失敗しました。 1.3.1_X Hotspot クライアント/サーバ JVM において、weblogic.Admin を使用するスレッド ダンプが可能になりました。
CR093320	サーブレット コンテナに関する内部的な問題により、クラスがロードできなくてもソースが返されていました。この問題は、WebLogic Server 8.1 サーバ上の JDBC 接続プールからデータベース接続を取得する WebLogic Server 7.0SP2 クライアントをテストしているときに確認されました。このエラーが原因で、クライアントはデータベース接続を取得できませんでした。 この問題は、コードを修正して解決されました。
CR094697	クライアントで「Server XYZ failed to shutdown successfully ...」というエラー メッセージが表示されてもサーバが適切に停止する問題が、コードの修正で解決されました。
CR094724	HPUX 上の WebLogic Server ネイティブ ライブラリが、(aCC ではなく) cfront を使用してコンパイルされていました。 aCC は、1998 年に cfront に取って代わった ANSI C コンパイラです。 その結果、互換性のないランタイム ライブラリがロードされていました (cfront のコンパイルでは libC.2、aCC でコンパイルされた SUN の Java では libCsup.2)。互換性のないランタイム ライブラリはクラッシュを引き起こします。 この問題は、hpux11 で aCC を使用するように WebLogic Server のビルドを修正して解決されました。
CR095487	同じサーバを示す異なるサーバ URL で複数の getInitialContext() 呼び出しを試行する t3 クライアント。通常の状況では、クライアントはそれが重複接続であると判断し、CLOSE メッセージをサーバに送信して、自分側の接続を閉じます。サーバは、この重複接続を削除します。状況によっては、CLOSE メッセージは非同期 IDENTIFY リクエストのためにキューに入れられ、クライアントは CLOSE の配信を待つことなく接続の自分の側を閉じます。サーバはこのソケットが削除されていることを検出し、そうでなければ正常な RJVM を停止する ConnectionManager の shutdown を発行します。 コードの修正によって、CLOSE メッセージが配信されないときに重複接続を閉じるときの RJVM 停止が防止されます。
CR096049	クラスタが管理サーバと 2 つの管理対象サーバで構成されているシステムでは、管理対象サーバの再起動に問題があります。 管理対象サーバの片方が動作しているマシンを再起動した後、その管理対象サーバは再起動できず、次の例外が送出されます。 <Jan 22, 2003 5:27:49 PM EST> <Error> <Deployer> <149204> <The Deployment framework was unable to register with the Data Replication Service. RegisterException due to underlying exception java.rmi.RemoteException: Failed to send message to URL t3://admtest1:7001; nested exception is: javax.management.InstanceNotFoundException: myDomain:Location=AdminServer,Name=***servername***,ServerRuntime=AdminServer,Type=DeploymentTaskRuntime この問題は、管理対象サーバがコンフィグレーション MBean に基づいてアプリケーションをロードできるようにコードを修正して解決されました。
CR096291	BeanA の doSomethingOnA で 1 つの EJB ビジネス メソッドを呼び出す起動クラス。このメソッドは BeanB のホーム インタフェースを取得し、次の ClassCastException が送出されます。 <29 janv. 03 13:21:19 CET> <Info> <EJB> <010051> <EJB Exception during invocation from home: test_ccex.a.BeanABean_124zg1_HomeImpl@5c5ca2 threw exception: java.lang.ClassCastException: Cannot narrow remote object to test_ccex.b.BeanBHome java.lang.ClassCastException: Cannot narrow remote object to est_ccex.b.BeanBHo me at weblogic.iiop.PortableRemoteObjectDelegateImpl.narrow(Porta bleRemoteObjectDelegateImpl.java:223) at javax.rmi.PortableRemoteObject.narrow(PortableRemoteObject. java:132) at test_ccex.a.BeanABean.doSomethingOnA(BeanABean.java:49) at test_ccex.a.BeanABean_124zg1_EOImpl.doSomethingOnA(BeanABea n_124zg1_EOImpl.java:46) at java.lang.reflect.Method.invoke(Native Method) at com.csg.am.dcf.weblogic.startup.BeanExecutor.startup(BeanEx ecutor.java:183) at weblogic.t3.srvr.StartupClassRunner.invokeStartup(StartupCl assRunner.java:141) at weblogic.t3.srvr.StartupClassRunner.invokeClass(StartupClas sRunner.java:122) at weblogic.t3.srvr.StartupClassRunner.access$0(StartupClassRu nner.java:113) at weblogic.t3.srvr.StartupClassRunner$1.run(StartupClassRunne r.java:86) at weblogic.security.service.SecurityServiceManager.runAs(Secu rityServiceManager.java:744) at weblogic.t3.srvr.StartupClassRunner.run(StartupClassRunner. java:71) at java.lang.Thread.run(Thread.java:479) コードの修正で、RemoteObjectReplacer のクラスロードの問題は解決されました。
CR097077	多くの発信 RMI 呼び出しを行うカスタム レルムを使用するときに、発信呼び出しを行うことによってリーダー スレッドがブロックされ、応答を読み込むためのスレッドが残されませんでした。この問題は、リーダー スレッドの RJVM レイヤからの BootServicesImpl.invoke メソッドが原因で発生します。 BootServicesImpl は、デフォルトの実行キューにディスパッチできるように RMI レイヤに移動されました。
CR099307、 CR102154、 CR100469、 CR104186、 CR104352、 CR103539	重複した t3 接続をクローズするときに、ロックが取得される順序が原因で、スレッド (PosixSocketMuxer および RJVM ConnectionManager) がデッドロック状態に入るおそれがありました。 マルチプレクサで要求をディスパッチするときに FDRecord ロックが行われないようになりました。
CR099489	InitialContext からルックアップした後、PortableRemoteObject を使用してホーム インタフェースが限定されたときに java.lang.ClassCastException が送出されていました。 コードの修正により、返される型は正しく限定されました。
CR100177	weblogic.security.service.ServerResource の使用が、Administration Console でのサーバ リソースの作成方法、およびドキュメントと一致していませんでした。T3 サーバを保護する目的で使用する場合、WebLogic リソースの名前は常に「T3Srvr」でした。他のすべてのケースでは、基盤のサーバの名前が WebLogic リソースの名前として使用されていました。 この問題は、基盤のサーバの名前を常に WebLogic リソースの名前として使用することで解決されました。
CR101720	接続フィルタを有効にすると、Connection rejected メッセージが蓄積されて、ログ ファイルが一杯になっていました。 新しい ConnectionLogger プロパティを使用すると、そのようなメッセージをログ ファイルに記録するかどうかをコンフィグレーションできます。
CR102848	CoreHealthMonitor は、大量の作業を実行しているときに ExecuteThreadManager ロックを保持して、デッドロックを招き、Administration Console がフリーズしました。CoreHealthMontor が ExecuteThreadRuntimeMBean を使用してスタック スレッドのリストを取得し、ETM ロックを保持しているときに ExecuteThreadManager 内のすべての場所からのロギングを回避するように、コードを変更しました。
CR103721	t3 クライアントは、クラスタ化された EJB からコンテンツ スイッチを介して InitialContext を取得するときにタイムアウトし、次のような例外が送出されました。 javax.naming.CommunicationException. Root exception is java.net.ConnectException: t3://10.161.39.60:9001: Bootstrap to: 10.161.39.60/10.161.39.60:9001' over: 't3' got an error or timed out at weblogic.rjvm.RJVMFinder.findOrCreate(RJVMFinder.java:180) at weblogic.rjvm.ServerURL.findOrCreateRJVM(ServerURL.java:262) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:323) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:221) at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:149) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:668) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:246) at javax.naming.InitialContext.init(InitialContext.java:222) at javax.naming.InitialContext.<init>(InitialContext.java:198) at Test.main(Test.java:34) ロード バランサで t3 クライアントのサポートを取り入れて、この問題を解決しました。
CR103967	WebLogic Server 実行スレッドの子スレッドは、正しいコンテキスト クラスローダを継承していませんでした。 この問題は、サーブレットまたはタイマー (java.util.Timer) によって作成される EJB にも当てはまります。 java.lang.Thread が独自のメンバー変数を子スレッドに直接割り当てるため、WebLogic Server 実行スレッドは独自のコンテキスト クラスローダを保持し、これらの実行スレッドの子スレッドは継承しません。 java.lang.Thread に同じコンテキスト クラスローダを設定して、この問題を解決しました。

デプロイメント

変更要求番号	説明
CR089760	weblogic.Deployer ユーティリティで、EAR ファイルをデプロイするときに「alternate descriptor」エラーが生成されました。次に例を示します。 Module: module_name Error: Alternative descriptor descriptor_name can't be found. この問題は、EAR が抽出されたディレクトリで WebLogic Server が記述子ファイルを検索しなかったために発生しました。 weblogic.Deployer は、EAR を正しくデプロイするように修正されました。
CR090678	ドメインの管理サーバを再起動すると、そのドメイン内のすべての管理対象サーバで自動的に EJB が再デプロイされました。 管理サーバを起動してもドメインの管理対象サーバで EJB が再デプロイされないようにコードが修正されました。
CR090678	EAR ファイルの一部としてデプロイされたアプレットにアクセスするために、WebLogic Server では不適切な CODEBASE 値を必要としていました。 たとえば、Web アプリケーション (MyWar.war) にパッケージ化され、EAR ファイル (MyEar.ear) の一部としてデプロイされたアプレットでは、次のような CODEBASE が必要でした。 CODEBASE=/bea_WebLogic Server_internal/classes/[e-mail] MyWar.war は、アプレットを格納する WAR ファイルの名前です。 これは、Web アプリケーションで MyWar の CONTEXT-ROOT が明示的に定義されている場合でも同じでした。 この問題は、CONTEXT-ROOT ではなく Web アプリケーションの URI を使用してデプロイメントが行われたことが原因で発生しました。 現在は、CONTEXT-ROOT (EAR ファイルの application.xml 記述子で定義されている場合) を使用して Web アプリケーションがデプロイされるようにコードが修正されています。 たとえば、上記の EAR ファイルで Web アプリケーションに MyWar の CONTEXT-ROOT が指定されている場合、アプレットの適切な CODEBASE は次のようになります。 CODEBASE=/bea_WebLogic Server_internal/classes/MyEar@MyWar
CR100857	weblogic.Deployer で (-activate -upload フラグで) Web アプリケーションを更新しても、適切に動作しませんでした。Web アプリケーションはロードされる前に、非アクティブ化され、ロールバックされて破棄されました。これは別の修正によって発生したリグレッションです。 適切な状況で Web アプリケーションをロールバックするようにコードを変更しました。
CR101755	Web コンテナが Tomcat 4.0 で EJB コンテナが WebLogic Server7.0SP1 であるときに、名前が異なり、別々のクラスローダを使用するものの、同じクラスを使用している 2 つの Web アプリケーションが Tomcat 上にデプロイされている場合、1 つ目の Web アプリケーションは EJB を呼び出せますが、2 つ目の Web アプリケーションは ClassCastException により呼び出しに失敗します。 新しい -D フラグを使用すると、クライアントは必ずコンテキスト クラスローダ上にスタブを生成することになります。-D フラグは次のとおりです。 -Dweblogic.LoadStubUsingContextClassLoader="true"
CR101760	停止している管理対象サーバから Web アプリケーションを削除すると、次のようなエラーになりました。 <Warning> <Management> <149311> <Rejecting deployment operations to non-running server, mgd1> <Warning> <Deployer> <149004> <Failures detected initiating weblogic.management.ManagementException: Rejecting deployment operations to non-running server, mgd1 task for application Remove application MyWebApp on mgd1> Web アプリケーションは削除されませんでした。 コードを変更し、WebServer および VirtualHost MBean から関連する WebAppComponentMBean 参照を削除することで問題を修正しました。
CR102928	VirtualHost にデプロイされた EAR 内の Web アプリケーションは、ドメインの再起動時に再デプロイされませんでした。 仮想ホストに割り当てられたアプリケーションがドメインの再起動時に再起動されるようにコードを変更して、問題を解決しました。
CR108934	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp のセキュリティ勧告に関する情報を確認してください。

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

変更要求番号	説明
CR101796	WebLogic Server 7.0 SP2 では、サイレント モードで使用されるコンフィグレーション ウィザード テンプレートによって、使用できないドメインが作成されました。 silent.xml のコードを変更して問題を修正しました。

EJB

変更要求番号	説明
CR056023	データベース内の対応する行が select for update または update 文でロックされる場合、CMP エンティティ EJB はタイムアウトしませんでした。トランザクションをロールバックする前に実行中の JDBC 文に取り消しが送信されるように、コードを変更しました。 データベース内の対応する行がロックされる場合でも、トランザクションのタイムアウトが発生するときに EJB がタイムアウトするようになりました。
CR063837	存在しないデータベース テーブルおよびカラムがあるかどうかを EJB コンテナが検証しようとすると次のエラーが送出されました。 weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Table: Cmp_Birthday Full Table Check failed, but table all columns were found! ] at weblogic.ejb20.utils.TableVerifier.verifyTableAndColumnsExist( TableVe rifier.java:371) at weblogic.ejb20.utils.TableVerifier.verifyTableExistsAndCreate Maybe(Ta bleVerifier.java:391) この問題は、コードを修正して解決されました。
CR068572	EJB クエリ言語 (EJB-QL) は、新しい Upper および Lower 関数で、大文字/小文字を区別しない検索をサポートするようになりました。
CR081512 CR097906 CR094280	同時方式がオプティミスティックである場合、トランザクション内で行われた更新が Finder メソッドで見つかりませんでした。つまり、include-updates 機能が失敗していました。 オプティミスティックな同時方式で include-updates が機能するようにコードが修正されました (Oracle データベースの場合)。
CR081951	クライアントがステートレス セッション Bean を呼び出して、その Bean が Bean 管理の永続性エンティティ Bean を呼び出していました。そのエンティティ Bean は、TreeMap をセッション Bean に返していました。その結果、負荷のある状態で次の例外が送出されていました。 Tue Jul 16 11:46:54 PDT 2002:<E> <Adapter> Exception thrown by rmi server: [386851657836047808S172.17.24.65:[8001,8001,8002,8002,8001,-1]/262] java.util.ConcurrentModificationException at java.util.TreeMap$Iterator.next(TreeMap.java:1023) at java.util.TreeMap.writeObject(TreeMap.java:1498) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectOutputStream.invokeObjectWriter(ObjectOutputStream.java:1864)... 分析の結果、TreeMap の WriteObject() に対する現在の呼び出しがオブジェクトのシリアライゼーションを完了して復帰する前にエンティティ Bean が以降の呼び出しを処理し始め、その結果として ConcurrentModificationException が送出されることが判明しました。 この動作は、Bean が EJB コンテナ レイヤでロックされ、RMI レイヤでシリアライズされることに起因しています。 この問題は、RMI アクティベーション コールバックを使用して EJB をプールに戻すことで解決しました。
CR087151	stateless-bean-is-clusterable が False に設定されたクラスタ内のステートレス セッション Bean が次のようなエラーを生成しました。 <Mar 14, 2003 3:35:00 PM PST> <Error> <Cluster> <Conflict start: You tried to bind an object under the name ejb20-statelessSession-TraderHome_EO in the JNDI tree. The object you have bound from 172.17.24.112 is non clusterable and you have tried to bind more than once from two or more servers. Such objects can only deployed from one server.> クラスタ化されていないスタブで、JNDI バインディングはレプリケートされなくなりました。
CR087151	ステートレス セッション Bean では、weblogic-ejb-jar.xml に次の行があり、 <stateless-bean-is-clusterable>False</stateless-bean-is-clusterable> Bean がクラスタにデプロイされている場合に、次のエラーが生成されます。 <Mar 14, 2003 3:35:00 PM PST> <Error> <Cluster> <Conflict start: You tried to bind an object under the name ejb20-statelessSession-TraderHome_EO in the JNDI tree. The object you have bound from 172.17.24.112 is non clusterable and you have tried to bind more than once from two or more servers. Such objects can only deployed from one server.> コードの修正により、クラスタ化されていないスタブの JNDI バインディングはレプリケートされません。
CR088156、CR124471	PersistenceManagerImpl.releaseResources() メソッドが、別のスレッド (weblogic.transaction.internal.ServerTransactionImpl.commit()) でトランザクションをコミットするために接続が使用されている JDBC 文を閉じるときに、次のデッドロックが生じました。 FOUND A JAVA LEVEL DEADLOCK: ---------------------------- "ExecuteThread: '180' for queue: 'default'": waiting to lock monitor 0xcbb28 (object 0xdee1d070, a oracle.jdbc.driver.OraclePreparedStatement), which is locked by "ExecuteThread: '73' for queue: 'default'" "ExecuteThread: '73' for queue: 'default'": waiting to lock monitor 0xcbc78 (object 0xdec416b8, a oracle.jdbc.driver.OracleConnection), which is locked by "ExecuteThread: '180' for queue: 'default'" 調査の結果、EJB コンテナが早まって文を閉じてしまうことが判明しました。 現在は、PersistenceManagerImpl.releaseResources() が適切なタイミングで文を閉じるようにコードが修正されています。
CR089759	UserTransaction コンテキストを使用して ejbStore() から context.getCallerPrincipal() を呼び出すと、次の例外が送出されていました。 <Oct 24, 2002 5:52:24 AM PDT> <Info> <EJB> <Exception from ejbStore:javax.ejb.EJBException: ejbStore: nulljavax.ejb.EJBException: ejbStore: null at AccountBean.ejbStore(AccountBean.java:99) この問題は、EJB 仕様のセクション 21.2.5.1 に準拠するために SP02 で導入された変更の結果です。この問題は修正されています。
CR089822	weblogic.ejbc の -classpath オプション (コンパイル時のクラスパスの設定に使用され、システムまたはシェルのクラスパスをオーバーライドする) が機能するようになりました。以前は次のエラーで失敗していました。 "ERROR: Error from ejbc: Unable to load a class specified in your ejb-jar.xml: examples.ejb20.basic.statelessSession.TraderBean" "ERROR: ejbc found errors"
CR089936	WebLogic Server クラスタにデプロイされた、クラスタ化されているコンテナ管理の永続性 Bean で、WebLogic Server が ejbload() を間違って呼び出していました。ejbLoad() は、EJB が同じクラスタ内の別のサーバから修正された後に、Bean が要求されるたびに呼び出されていました。 同時方式が Optimistic で、cache-between-transactions と home-is-clusterable が両方とも有効になっていました。 この問題は、ejbLoad() の最初の呼び出しの後に Bean の状態が適切に更新されなかったことが原因で発生しました。 Bean の状態が正しく更新されるようにコードが修正されました。
CR090104	記述子にアイソレーション レベルを指定した EJB が実行時に例外を受け取っていました。 WebLogic Server は、誤ったベンダの回避策をチェックしていました。supportsTxIsolationUponEnlistment ではなく supportsTxIsolation をチェックしていました。 また、トランザクションがアクティブなときにアイソレーション レベルを設定または再設定する際のルールや動作は、さまざまなデータベース ベンダやドライバによって異なります。 たとえば、WebLogic Server jDriver/XA for Oracle を使用する場合、アイソレーション レベルはトランザクション ブランチの作成時にのみ設定し、ブランチを結合または再開するときには設定できません。 コードを変更して両方の問題を修正しました。
CR090192	max-beans-free-pool が No LIMIT に設定されているステートレス セッション Bean がデプロイメント時に applications ディレクトリにコピーされると、デプロイメントは次のエラーにより失敗しました。 <Nov 5, 2002 4:59:00 PM EST> <Error> <Deployer> <BEA-149201> <The Slave Deployer failed to complete the deployment task with id 7 for the application _appsdir_BasicStatelessTraderBean_jar. weblogic.management.ApplicationException: Prepare failed. Task Id = 7 { Module Name: BasicStatelessTraderBean, Error: [EJB:011025]The XML parser encountered an error in your deployment descriptor. Please ensure that your DOCTYPE is correct. You may wish to compare your deployment descriptors with the WebLogic S erver examples to ensure the format is correct. The error was: Path .weblogic-ejb-jar.weblogic-enterprise-bean.caching-descriptor.ma x-beans-in- free-pool.: [EJB:010136]Param must be an integer. 問題は、「NO LIMIT」のホワイト スペースの解析にありました。 max-beans-in-free-pool が NO LIMIT として指定されている場合に、それが int の最大値に設定されるようにコードが修正されました。
CR090515	Administration Console の [待機総数] フィールドで、Exclusive 同時方式のエンティティ Bean およびステートフル セッション Bean へのアクセスを待っているクライアントの数が間違って報告されていました。この数は、クライアントがロックを取得するか、タイムアウトになったときに正しくデクリメントされるようになりました。
CR091263	ステートレス セッション Bean が、関連 Bean を更新しようとしました。Oracle 制約違反の SQL 例外が原因でトランザクションがロールバックされた後、ステートレス セッション Bean にアクセスする試みで次のエラーが発生しました。 com.cpships.ecomm.exception.FatalException: EJB Exception: javax.ejb.TransactionRolledbackLocalException: Illegal Reentrant call to RelatedCompanyHomeRemote with primary key: 30: weblogic.ejb20.InternalException: Illegal Reentrant call to RelatedCompanyHomeRemote with primary key: 30 調査の結果、weblogic.ejb20.manager.DBManager.remove() メソッドが実行された後、setBusy フラグ (Bean が使用できるかどうか、つまり Bean がビジー状態かどうかを示す) が正しく False に設定されないことが判明しました。 この問題は解決済みです。
CR091352	4 レベルのリレーションシップ キャッシングで、ejbc のコード生成が次の例外を発して失敗していました。 Found 4 semantic errors compiling "D:/labs/cluster70/src/com/bea/ps/cmr_orders/ejbcgen/com/bea/ps/cmr_orders/CustomerBean_1q1rpd__WebLogic_CMP_RDBMS.java": 789. if (__WL_bean__orderLines != null) <-------------------> *** Error: No entity named "__WL_bean__orderLines" was found in this environment. 791. __WL_bean__orderLines.__WL_add__WL_item_field_(__WL_eo); <-------------------> *** Error: "__WL_bean__orderLines" is either a misplaced package name or a non-existent entity. 1310. if (__WL_bean__orderLines != null) { <-------------------> *** Error: No entity named "__WL_bean__orderLines" was found in this environment. 1312. __WL_bean__orderLines.__WL_add__WL_item_field_(__WL_eo); <-------------------> *** Error: "__WL_bean__orderLines" is either a misplaced package name or a non-existent entity. 分析の結果、キャッシングが 4 レベル以上の場合、prevCmrFieldName 文字列を作成するときに RDBMSCodeGenerator.java によって余分な文字が削除されていることが判明しました。 RDBMSCodeGenerator.java の修正により、この問題は解決されました。
CR091436	ルックアップに外部 InitialContextFactory() 呼び出しを使用するメッセージ駆動型 Bean が繰り返し接続の試行を行い、かつ JMS プロバイダがアクセス不能の場合、接続や他のリソースが急速に増えて、サーバのリソースが枯渇していました。 より詳しい調査の結果、JMSConnectionPoller() が InitialContexts を適切に閉じていないことが判明しました。この問題は、コード上で修正されました。
CR091774	コンテナ管理による関係の Finder メソッドが実行されたときに、EJB が cache-between-transactions を True に設定してオプティミスティックな同時方式を使用する場合でも、WebLogic Server が同じエンティティ EJB への 2 回目のアクセス用に間違ってデータベースから状態をロードしようとしていました。この問題は、コード上で修正されました。
CR094073	BMP エンティティ Bean の処理が、EJB 2.0 仕様に準拠して変更されました。EJB の仕様に従い、EJB コンテナはファインダ メソッドの実行前に EJBStore を呼び出してエンティティ Bean の状態を同期化するようになりました。この変更は、findByPrimaryKey メソッドに影響しません。
CR094524	WebLogic Server 6.1 SP3 では、多対 1 のコンテナ管理の関係を持つ読み込み専用の EJB で LockTimedOutException が生じていました。 この問題は、if condition チェックを rdb.isReadOnly() から READONLY_EXCLUSIVE_CONCURRENCY チェックに変更して解決されました。
CR094629、 CR098386	1 対 1 のコンテナ管理の関係を持つ 2 つの Bean が、同じトランザクションで作成されました。 両方の Bean で delay-database-insert-until が Commit に設定されていても、架空の SQL SELECT 文が発行されました。 大量のデータが扱われる状況では、一括挿入の真のメリットは余計な SELECT の結果としてパフォーマンスが低下したせいで実現されていませんでした。 余計な SELECT が発行されないようにコードが変更されています。
CR094776	エンティティ EJB の作成が試行されたが失敗した場合に、Administration Console の [プールの使用中 Bean 数] がまるで作成が成功したかのようにインクリメントされました。 この問題は修正済みです。
CR094861	String[] を持つ複数の属性が EJB に含まれている場合に、ejbc コンパイラで次のエラーが送出されました。 C:¥public¥383031>java weblogic.ejbc ejb11_basic_containerManaged.jar ejbcgen¥examples¥ejb11¥basic¥containerManaged¥AccountBean_rp7qqq __WebLogic_CMP_R DBMS.java:499: byteArray is already defined in ejbFindByPrimaryKey(java.lang.Str ing) byte[] byteArray = __WL_rs.getBytes(5); ^ ejbcgen¥examples¥ejb11¥basic¥containerManaged¥AccountBean_rp7qqq __WebLogic_CMP_R DBMS.java:611: byteArray is already defined in ejbFindAccount(double) byte[] byteArray = __WL_rs.getBytes(5); ^ ejbcgen¥examples¥ejb11¥basic¥containerManaged¥AccountBean_rp7qqq __WebLogic_CMP_R DBMS.java:732: byteArray is already defined in ejbFindBigAccounts(double) byte[] byteArray = __WL_rs.getBytes(5); ^ ejbcgen¥examples¥ejb11¥basic¥containerManaged¥AccountBean_rp7qqq __WebLogic_CMP_R DBMS.java:838: byteArray is already defined in ejbFindNullAccounts() byte[] byteArray = __WL_rs.getBytes(5); ^ ejbcgen¥examples¥ejb11¥basic¥containerManaged¥AccountBean_rp7qqq __WebLogic_CMP_R DBMS.java:1236: byteArray is already defined in ejbLoad() byte[] byteArray = __WL_rs.getBytes(5); ^ 5 errors Exec failed .. exiting この問題は、EJB 1.1 でのみ発生しました。 生成されたコードのバイト配列でユニークな変数が作成されるようにコードが変更されました。
CR095023	EJB デプロイメント記述子は、トークン "${APPNAME}" を使用して、JNDI 名にバインドして参照することができます。 ただし、LocalJNDI 名は、デプロイメント時に解決する "${APPNAME}" トークンをサポートしていませんでした。 現在は、デプロイメント時に、アプリケーション名トークンの置換用に LocalJNDI 名が変換されるようになりました。
CR095030	WebLogic Server 7.0 SP1 では、ステートフル セッション EJB のデプロイメントが次の ClassCastException で失敗しました。 Unable to deploy EJB: MetaDataBS from csam_dcf3_server_ejb_depl.jar: java.lang.ClassCastException: weblogic.ejb20.deployer.SessionBeanInfoImpl at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.setMethodDescri ptors(ClientDrivenBeanInfoImpl.java:745) at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.prepare(Client DrivenBeanInfoImpl.java:907) at weblogic.ejb20.deployer.EJBDeployer.setupBeanInfo(EJBDeployer.ja va:1041) at weblogic.ejb20.deployer.EJBDeployer.prepare(EJBDeployer.java:124 5) at weblogic.ejb20.deployer.EJBModule.prepare(EJBModule.java:242) at weblogic.j2ee.J2EEApplicationContainer.prepareModule(J2EEApplica tionContainer.java:1504) at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationCo ntainer.java:690) at weblogic.j2ee.J2EEApplicationContainer.prepare(J2EEApplicationCo ntainer.java:576) at weblogic.management.deploy.slave.SlaveDeployer.processPrepareTas k(SlaveDeployer.java:1064) at weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(Sla veDeployer.java:732) at weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCallba ckHandler.java:24) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134) この問題は、setMethodDescriptors() がセッション Bean を間違ってエンティティ Bean として識別していたことが原因で発生しました。 この問題は修正されています。
CR095090	同じトランザクション内で、delay-database-until-insert が Commit に設定され、ejbRemove() が呼び出された場合に、Bean の削除は java.rmi.NoSuchObjectException によって失敗します。 delay-database-insert-until が Commit に設定されている場合はコンテナ キャッシュをチェックして Bean を削除するようにコードが変更されました。
CR095141	クラスタ化されたコンフィグレーションと最近未使用 (NRU) キャッシング方式で、インスタンス化された Bean インスタンスの数が max-beans-in-cache を超えたときに、コンテナはステートフル セッション Bean のパッシベーションを正しく行いませんでした。 クラスタ化された環境で、WebLogic Server は ReplicatedStatefulSessionManager を使用して新しい NRUCache を作成します。 調査の結果、レプリケートされたステートフル SessionManager がキャッシュに登録されないために、Bean はアクティブ キューから非アクティブ キュー、さらに空きキューへと正しく移動されないため、CacheFullExceptions になることが判明しました。 コードの修正で、この問題は解決されました。
CR095173	idle-timeout-seconds 要素は、ステートフル セッション Bean でパッシベーションが行われるまで、つまりキャッシュから削除されてディスクに書き込まれるまで EJB コンテナが待機する時間を指定します。 EJB コンテナでは、パッシベーションされた EJB をディスクから削除するまでの待機時間を指定するためにもこの要素を使用していました。 ただし、idle-timeout-seconds より長い時間ステートフル セッション Bean がディスクに残ることを望むユーザもいました。 ステートフル セッション Bean がキャッシュに留まる時間と、それらがディスクに留まる時間を別々の要素で指定できることが望まれていたのです。 WebLogic Server 7.0 サービス パック 3 では、新しい要素の session-timeout-seconds が導入されます。この要素では、アイドル状態のステートフル セッション Bean がディスクから削除されるまでの EJB コンテナの待機時間を指定します。
CR095290	delay-database-insert-until が Commit に設定され、同時方式がオプティミスティックであるエンティティ EJB をトランザクションの中で更新しようとするアプリケーションの試みは、NullPointerException で失敗しました。 問題は、delay-database-insert-until の値が Commit の場合、WebLogic Server は EJB が作成された時点でオプティミスティック同時方式のバージョン カラムを初期化しないということです。 オプティミスティック同時方式のバージョン カラムが一括挿入用に初期化されるようコードが変更されました。
CR095545	ejb-name が同じでも、JNDI マッピングは異なる 2 つのメッセージ駆動型 Bean を同じ WebLogic Server インスタンスにデプロイしようとしたときに、最初の Bean は正常にデプロイされましたが、2 番目の Bean のデプロイメントは次の例外で失敗しました。 weblogic.management.ManagementException: - with nested exception: [javax.management.InstanceAlreadyExistsException: jpdomain:Location=jpserver,Name=MessageQueueHandlerBean,ServerRu ntime=jpserver,Type=EJBMessageDrivenRuntime] at weblogic.management.runtime.RuntimeMBeanDelegate.register(Runtim eMBeanDelegate.java:96) at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeM BeanDelegate.java:83) at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeM BeanDelegate.java:53) at weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeM BeanDelegate.java:63) at weblogic.ejb20.deployer.MessageDrivenRuntimeMBean.<init>(Message DrivenRuntimeMBean.java:18) at weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(Message DrivenBeanInfoImpl.java:450) at weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java: 1299) at weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:1005) この問題の原因は、MessageDrivenRuntimeMBean の名前がユニークでないことにありました。現在は、名前がユニークになるようにコードが変更されています。
CR095632	基本的な Java クライアントは、ステートレス セッション Bean を Facade として使用して、エンティティ EJB を作成し、ファインダ メソッドと読み込み専用 Bean を使用してその EJB を読み込み、エンティティ Bean を更新して、再びエンティティ EJB を読み込みました。 transaction-attribute が Supports に設定されている場合、クライアントは更新された値を読み込みました。 transaction-attribute が Required または RequiresNew に設定されている場合は、クライアントは古い値を読み込みました。 調査の結果、キャッシュのタイムアウトが 0 に設定されているために、ファインダ メソッドがタイムアウトになった Bean を更新しなかったことが判明しました。 キャッシュのタイムアウトが 0 でも Bean が更新されるようにコードが変更されました。
CR096182	動的な EJB-QL は基底の SQL に MAX_INT として誤って長い引数を渡し、検索が失敗しました。コードの修正で、この問題は解決されました。
CR096395	エンティティ Bean がアンデプロイされるときに、コンテナは unsetEntityContext の呼び出しに失敗しました。 エンティティ Bean がアンデプロイされるときにプールをクリーンアップするために、BaseEntityManager に undeploy メソッドが追加されました。その修正で、問題は解決されました。
CR096800	WebLogic Server 6.1 が WebLogic Server 7.0 の呼び出し側に対して EJB 例外を送出すると、呼び出し側ではエラー メッセージを伴うシリアライゼーション エラーを代わりに受け取ります。 これは、WebLogic Server 6.1 で EJBException のシリアル バージョン ユニーク識別子 (SVUID) が間違っていたためです。 WebLogic Server 7.0 は現在 WebLogic Server 6.1 と通信するときに正しい SVUID を識別して受け付け、その接続上で送信します。 7.0 に取り入れられた以前の解決策には不備がありました。
CR096848	6.1 SP04 では、CMP 2.0 Bean で <is-modified-method-name> が呼び出されていませんでした。 Bean のメソッドを呼び出すたびに ejbStore() を呼び出し、後でストアを回避するかどうかを判定していました。 そのため、<is-modified-method-name> を頻繁に使用するアプリケーションでは、パフォーマンスの問題が発生していました。 この問題は、CMP EJB 2.0 用に <is-modified-method-name> 関数を実装することで解決されました。
CR097890	WebLogic Server は、同じ時間に JMSPoller の複数のトリガをスケジューリングしていました。それらすべてがデフォルトの JMS キューを占有して、デッドロックが起きていました。 トリガが重複してスケジューリングされないようにコードが変更されました。
CR097913	動的な EJB-QL 要求で COUNT と EXISTS を結合すると、SQL が無効になり、次の例外が送出されました。 [java] javax.ejb.FinderException: Exception in dynamicQuery while preparing or executing statement: 'weblogic.jdbc.rmi.SerialStatement@62b30' [java] java.sql.SQLException: ORA-00937: not a single-group group function [java] [java] java.sql.SQLException: ORA-00937: not a single-group group function サブクエリの解析時に main select list に不要なカラムが追加されていました。 パーサのコードを修正して問題は解決されました。
CR098188	メッセージ駆動型 Bean が、別のサーバ上の JMS キューからメッセージを消費していました。その JMS サーバは機能していませんでした。 weblogic.ejb20.internal.MDListener ではなく、UserTransaction.commit method から例外が送出されました。 MDListener は、動作を継続していました。 それ以降の JMS からの MDB の呼び出しは、すでにスレッドにトランザクションがあるために UserTransaction.begin で失敗しました。 MDListener が新しいトランザクションを開始する前に現在のトランザクションをサスペンドするようコードが変更されています。
CR098923	JAR のすべてのメッセージ駆動型 EJB で実行されるように mdbPoolInfo.start() メソッドが変更されました。その JAR の最初の MDB で失敗しても、すべての MDB で実行されます。
CR099420	2 次元配列が引数として指定された場合、ejbc コンパイラは次のエラーで失敗しました。 ERROR: Error from ejbc: Unable to set the method permission for method "isAuthorized(java.lang.String,[[java.lang.String)". No matching method could be found. Please verify the method signature specified in the ejb-jar.xml file matches that of your EJB. ERROR: ejbc found errors. weblogic.ejb20.deployer.mbimpl.MethodDescriptorImpl クラスの makeMethodParameter() メソッドは、渡される配列の次元に応じて適切なメソッド パラメータ シグネチャを生成するように修正されました。
CR100822	クラスタ化されたメッセージ駆動型 Bean の動作を変更して、パフォーマンスを最適化しました。以前は、MDB が JMS に接続する場合、JMS 接続がクラスタ全体でバランシングされるように、標準のクラスタ ロードバランシング アルゴリズムが使用されました。 可能な場合、MDB はメッセージをホストする (接続の受信元である) 同じ JVM に、JMS 接続を導きます。これにより、リソースにアクセスするときに MDB によって作成されるホップ数が削減されます。
CR100832	オプティミスティックな同時方式が有効な場合、暗黙の書き込みがチェックされないため、カラムのバージョン番号は正しく更新されませんでした。オプティミスティックな同時方式で暗黙の書き込みがチェックされるようにコードを変更しました。
CR101226	WebLogic Server 7.0 SP1 で、自動テーブル作成が断続的に次のエラーにより失敗しました。 weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Table: Cmp_Birthday Full Table Check failed, but table all columns were found! ] at weblogic.ejb20.utils.TableVerifier.verifyTableAndColumnsExist(Ta bleVe rifier.java:371) at weblogic.ejb20.utils.TableVerifier.verifyTableExistsAndCreateMay be(Ta bleVerifier.java:391) at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.populateFieldSQ LType Map(RDBMSPersistenceManager.java:499) at weblogic.ejb20.cmp.rdbms.RDBMSPersistenceManager.setup(RDBMSPers isten ceManager.java:122) at weblogic.ejb20.manager.BaseEntityManager.setupPM(BaseEntityManag er.ja va:192) at weblogic.ejb20.manager.BaseEntityManager.setup(BaseEntityManager .java :168) at weblogic.ejb20.manager.DBManager.setup(DBManager.java:123) at weblogic.ejb20.deployer.ClientDrivenBeanInfoImpl.deploy(ClientDr ivenB eanInfoImpl.java:807) at weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java: 1234) 調査の結果、クエリの発行に preparedStatement が使用されていたことがわかりました。prepared statement は Oracle データベースから削除できるため、断続的なアサーション エラーが発生する可能性があります。 preparedStatement の代わりに Statement を使用するようにコードを修正しました。
CR101248	CMP Bean が JDBC 接続プールをリークしていました。 ejbFindByPrimaryKey() が releaseResources() を呼び出すときに問題が発生しました。 ResumeTransaction が失敗した場合、WebLogic Server がリソースを解放して JDBC 接続リークの可能性を回避するように、RDBMSCodeGenerator を変更しました。
CR102180	100 個の EJB を含む JAR ファイルで ejbc コンパイラが失敗しました。 オペレーティング システムに関係なく渡されるファイル数に基づいた @tempfile 機能を使用することで、問題を修正しました。
CR102481	一部の Bean 管理のステートフル セッション Bean では、キャッシュが一杯でアクティベーションとパッシベーションが発生するときに、Bean インスタンスの数が max-beans-in-cache よりも大きい場合に、Bean が境界を定めるトランザクションで IllegalStateException が発生しました。 コードの変更により、パッシベーション リクエストごとに 1 つのリプレーサが作成され、そのため各スレッドがそれ専用のリプレーサを持つことになります。
CR104046	delay-database-insert-until が Commit に設定されている場合に、「複数テーブル」の Bean を作成するときにオプティミスティックな同時方式のバージョン カラムが初期化されませんでした。 RDBMSCodeGenerator.perhapsAssignOptimisticField() から、CMP Bean がマップされたすべてのテーブルのバージョン カラムを設定する生成済みコードが返されるように、コードを変更しました。
CR105857	Bean 管理の永続性を持ち、同時方式が exclusive に設定されている EJB が、キャッシュ内の Bean を検索するのではなく、ejbFindByPrimaryKey を呼び出しました。 EJB がキャッシュ内の Bean を検索するようにコードを変更して、問題を解決しました。

相互運用性

変更要求番号	説明
CR095804	WebLogic Server 7.0 SP2 クライアントが WebLogic 8.1 サーバ インスタンスから Coordinator リモート オブジェクトを取得しようとすると、リモート スタブを CoordinatorOneway インタフェースにキャストするときに ClassCastException が送出されていました。 このため、8.1 調整サーバへコミットを渡すことができませんでした。 クラスロード機能を修正するコードの変更で問題は解決されました。

JDBC

変更要求番号	説明
CR087870	WebLogic Server 7.0 の以前のリリースでは、高可用性アルゴリズムの JDBC マルチプールは最初の接続プールの DBMS がネットワークから削除された場合はフェイルオーバされませんでした。この問題は、コードの修正で解決されました。
CR088525	以前の WebLogic Server 7.0 サービス パックで、値が「/////」の JSP パラメータが、getParameter() によって値が「/」であると解釈されました。 この問題は、コードを修正して解決されました。
CR090379	WebLogic Server 7.0 の以前のリリースでは、JDBC 接続プールを通じて 1 つの JDBC オブジェクトを指し示す複数の ResultSet を誤って作成すると OutOfMemoryError が発生しました。各 ResultSet からは、RMI オブジェクトが生じました。ResultSet を閉じても、すべての RMI オブジェクトが閉じたわけではありません。この問題は、コードの修正で解決されました。
CR092453	WebLogic Server 6.1 SP04 では、Oracle 9.2 に付属する CLASSES12.zip の Oracle Thin XA により、EJB を呼び出すステートレス セッション Bean において、「Configuration Changes saved to the repository」というメッセージの後で XAER_PROTO が発生していました。 START SLEEP 2: After updating thevalue to 1... DONE SLEEP 2: After updating thevalue to 1... START SLEEP 2: After updating thevalue to 2... DONE SLEEP 2: After updating thevalue to 2... START SLEEP 2: After updating thevalue to 3... DONE SLEEP 2: After updating thevalue to 3... START SLEEP 2: After updating thevalue to 4... DONE SLEEP 2: After updating thevalue to 4... START SLEEP 2: After updating thevalue to 5... DONE SLEEP 2: After updating thevalue to 5... Current value is 5 < Dec 6, 2002 10:26:59 PM MST> <Info> <Management> <Configuration changes for domain saved to the repository.> SQLException -- XA error: XAER_PROTO : Routine was invoked in an improper context start() failed on resource 'OracleXA' null Current value is 0 この問題は、Oracle クライアント 9.2.0.[01] の確認済みの問題が原因で発生しており、9.2.0.2 で解決されます。WebLogic Server では、9.2.0.[01] の問題を回避するためにコード修正が行われました。
CR092791	WebLogic Server 6.1 で、Oracle Thin Client ドライバに基づく接続プールを介して、特定の Oracle オブジェクト (Array、Struct、その他) を使用できませんでした。 Oracle Thin Client ドライバによって返されるオブジェクトがシリアライズ可能でもリモートでもないため、RMI を通じて渡すことができません。 WebLogic Server 7.0 SP3 では、新しい パッケージ weblogic.jdbc.vendor.oracle にこれらのオブジェクトのプロキシが含まれており、接続プールを介して渡されるようになりました。
CR093038	WebLogic Server 7.0 SP3 では、Oracle 仮想プライベート データベース (Virtual Private Database : VPD) がサポートされています。VPD を使用することで、アプリケーション定義のファイングレイン アクセス コントロールをサーバで実施し、Oracle 9i データベース サーバ内のアプリケーション コンテキストのセキュリティを確保できます。 詳細については、『WebLogic JDBC プログラマーズ ガイド』の「Oracle 仮想プライベート データベースによるプログラミング」を参照してください。
CR093649	ejb2jsp ユーティリティは、String 以外のパラメータ タイプを含むメソッドに対して間違ったタグ クラスを生成していました。 タグ ライブラリ ジェネレータが getAttributeString ではなく getAttribute を使用するように変更して、問題を修正しました。
CR094645	0 以外の開始インデックスを getStatementProfiles() メソッドに渡すと、トレースは、指定した開始インデックスではなく、.tsf ファイルの先頭からデータを返しました。 この問題は、コードの修正で解決されました。
CR094729	JDBCConnectionPoolRuntimeMBean.getStatementProfiles() メソッドは、それが呼び出された MBean インスタンスの poolName に基づいて結果をフィルタ処理しませんでした。 getStatementProfiles メソッドを呼び出した場合、その結果にはトレースがアクティブ化されているすべての接続プールの文が含まれていました。 JDBCConnectionPoolRuntimeMBean インスタンスは 1 つの接続プールに専用のものなので、その結果は誤ったものでした。 この問題は、MBean インスタンスの poolName に基づいて結果を適切にフィルタ処理するように JDBCConnectionPoolRuntimeMBean.getStatementProfiles() メソッドを修正して解決されました。
CR095059	JDBCStatementProfile.getTimeTaken() は、JDBC の操作が実行に要した実際の時間を返す代わりに常にゼロを返したので、その操作の開始時刻と終了時刻が常に等しくなっていました。 weblogic/jdbc/common/internal/ProfileStorage.java のコード修正で、この問題は解決されました。
CR095962	JDBC 接続を置き換えようとするスレッドが ResourceAllocator の resetThisOne() メソッドで不必要に同期がとられ、リソースが浪費されていました。 スレッドが平行して接続を置き換えるように ResourceAllocator のコードが変更されました。
CR095994	以前のバージョンの WebLogic Server は、接続リーク プロファイルがなく、weblogic.jdbc.rmi.internal.ConnectionImpl に接続リーク検出ロジックがありませんでした。 SerialConnection.java および ConnectionImpl.java のコードを変更して、この問題を解決しました。
CR096268	DBMS が利用できない場合に、makeConnection() in ConnectionEnvFactory.java がクライアントの代わりに 2 回 DBMS に接続しようとしていました。 この問題は、接続が 1 回のみ試行されるように修正されています。
CR096922	負荷のある状態で、WebLogic Server が ResourceAllocator.markBorrowed() を呼び出し、JMX が ConnectionPoolRuntimeMBeanImpl.getConnectionDelayTime() を呼び出すと、デッドロック状態が発生しました。 ResourceAllocator.java のコード修正で、この問題は解決されました。
CR097832	Weblogic Server 6.1 SP04 シン ドライバ、Solaris 8、JDK 1.3.1_04、および Oracle 8.1.7.4. というコンフィグレーションでは、接続の更新が有効になっていると、デッドロックが発生しました。スタック トレースは次のようなものでした。 "ExecuteThread: '35' for queue: 'default'" daemon prio=5 tid=0x45ac68 nid=0x30 waiting for monitor entry [0xce901000..0xce9019d8] at weblogic.jdbc.common.internal.ConnectionEnv.destroy(ConnectionEnv.java:571) at weblogic.common.internal.ResourceAllocator weblogic.jdbc.common.internal.ConnectionEnv.destroy と weblogic.common.internal.ResourceAllocator.release は両方とも同期メソッドです。 この問題は、weblogic/jdbc/common/internal/ConnectionEnv.java のコード修正で解決されました。
CR099363	WebLogic Server 6.1 SP04 では、負荷テストにおいて、接続プールの更新間隔を 15 分に設定し、TestConnsOnReserve と TestConnsOnRelease を false に設定すると、次の例外が送出されました。 weblogic.common.ResourceException: No available connections in pool ODSConnectionPool この問題は、プール内の接続の一部だけが使用されていると、その他の接続はすべて、更新テスト間隔が経過した時点でのテスト用に予約されてしまうために発生しました。 このような状態で、クライアントが接続を要求すると、例外が送出されました。 次の 2 つの動作を実装するようにコードを修正して、この問題は解決されました。 他に何も変更せず、まったく同じ条件で使用すると、更新テストは一度にただ 1 つの接続を予約してテストし、直ちに接続を解放します。これにより、すべての接続がロックされる問題は解決されます。 プールの定義に対してドライバ プロパティ secondsToTrustAnIdlePoolConnection を追加し、このプロパティに正の整数を設定した場合には、プールは、その更新間隔中に DBMS に対して正常に接続されたことがわかっているプール接続については、テストを行いません。 これで refresh と testConnsOnReserve が高速化されます。
CR099507	Prepared Statement を閉じるときに、ConnectionEnv.java の cleanUpStatementForReUse() メソッドが、MS SQL ドライバで実装されていない clearBatch() を呼び出していました。その結果として、次の例外が送出されました。 java.sql.SQLException: This JDBC 2.0 method is not implemented exception. 害のない呼び出しが許可され、例外が送出されないようにコードが変更されました。
CR101419	build-jdbc.xml で、RmiDataSource がクラスタ対応として作成されませんでした。 そのため、DataSource のフェイルオーバが妨げられていました。 DataSources および TXDataSources をクラスタ対応として作成し、問題を解決しました。
CR102698	weblogic.Admin CREATE_POOL で接続プールを作成しようとすると、次の例外が発生しました。 ./wlg-create-pool.sh No permission to create ConnectionPool Start server side stack trace: weblogic.common.ResourceException: No permission to create ConnectionPool at weblogic.jdbc.common.internal.JDBCService.createPool(Ljava.util.Properties;Lweblogic.secur ity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at weblogic.jdbc.common.internal.ConnectionPool.createPool(Ljava.util.Properties;Lweblogic.se curity.acl.internal.AuthenticatedSubject;)V(Unknown Source) at weblogic.jdbc.common.internal.ConnectionPool.createPool(Ljava.util.Properties;)V(Unknown S ource) at weblogic.jdbc.common.internal.ConnectionPool_WebLogic Serverkel.invoke(ILweblogic.rmi.spi.InboundReque st;Lweblogic.rmi.spi.OutboundResponse;Ljava.lang.Object;)Lweblogic.rmi.spi.OutboundResponse;(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(Lweblogic.rmi.internal.MethodDescriptor;Lweblo gic.rmi.spi.InboundRequest;Lweblogic.rmi.spi.OutboundResponse;)V(Unknown Source) at weblogic.rmi.internal.BasicServerRef$1.run()Ljava.lang.Object;(Unknown Source) at weblogic.security.service.SecurityServiceManager.runAs(Lweblogic.security.acl.internal.Aut henticatedSubject;Lweblogic.security.acl.internal.AuthenticatedSubject;Ljava.security.PrivilegedExcep tionAction;)Ljava.lang.Object;(Unknown Source) at weblogic.rmi.internal.BasicServerRef.handleRequest(Lweblogic.rmi.spi.InboundRequest;)V(Unk nown Source) at weblogic.rmi.internal.BasicExecuteRequest.execute(Lweblogic.kernel.ExecuteThread;)V(Unknown Source) at weblogic.kernel.ExecuteThread.execute(Lweblogic.kernel.ExecuteRequest;)V(Unknown Source) at weblogic.kernel.ExecuteThread.run()V(Unknown Source) at java.lang.Thread.startThreadFromVM(Ljava.lang.Thread;)V(Unknown Source) 調査の結果、WebLogic Server が属性として非推奨の aclName を要求していたことがわかりました。コードの修正で、この問題は解決されました。
CR102740	JDBC 接続プールの XAPreparedStatementCacheSize が Administration Console で公開されました。
CR102792	SP2 の変更では、isolation-level の設定を許可しないドライバでアイソレーション レベルが許可されていました。 DB2 JDBC ドライバではアイソレーション レベルの変更が許可されているため、チェックが呼び出されず、アイソレーション レベルの変更は不適切な時点で行われます。 つまり、デプロイメント記述子で isolation-level を設定している EJB は、デプロイメント記述子のアイソレーション レベルがデフォルトの「READ-COMMITED」と同じ場合でも、例外を送出することがあります。 アイソレーション レベルが現在のレベルと同じ場合は設定が行われないようにコードを変更して、この問題を修正しました。
CR103256	コードを変更した結果、JDBCSessionContext および JDBCSessionData の bubblecaches に関する JDBC のパフォーマンスが向上しました。
CR103321	JDBCConnectionPoolRuntimeMBean の getConnectionsTotalCount メソッドは予期されるとおりに機能しませんでした。 この JDBCConnectionPoolRuntimeMBean でプールが初期化されてからの JDBC 接続の総数を返すものですが、代わりに、任意の時点の接続の最大数 (MaxCapacity 以下) を返していました。 ResourceAllocator.java の getTotalConnections() のコードを変更して問題を修正しました。
CR103560	SQL UPDATE の PreparedStatement は、同じ接続上で CallableStatement を使用した後に機能しませんでした。 データベースで何も変更されなかったときに getUpdateCount はゼロを返しました。 これは、JDBC 接続の weblogic.oci.min_bind_size プロパティを設定するときに発生しました。コードを変更してこの問題を解決しました。
CR104523	DatabaseMetaData.getDriverVersion() は無効なバージョン文字列を返していました。コードの修正で、この問題は解決されました。
CR106522	WebLogic Server jDriver for MS SQLServer は Microsoft JDBC ドライバの jdbc:microsoft:... URL を誤って受け付ける可能性があります。JVM が両方のドライバを使用する場合、最初に WebLogic Server ドライバをロードすると、Microsoft ドライバが使用できなくなります。 この jDriver は非推奨になりました。
CR106767	アプリケーションが複数回 JDBC オブジェクトをクローズしようとすると、WebLogic Server は例外を送出するようになりました。

jDriver

変更要求番号	説明
CR088387	jDriver 上で XADataSource を使用すると、ヒープ サイズが減少して OutOfMemoryError が発生しました。 weblogic.jdbc.oci.Connection クラスでは、トランザクションの結果セットの LOB フィールドは、Connection.addLob() メソッドで接続に登録されます。登録された LOB は、以下のいずれかの条件が発生すると、ネイティブ jDriver ライブラリ内の対応するオブジェクトと共に解放されます。 接続レベル (この Connection は weblogic.jdbc.oci.Connection) で Connection.commit()/Connection.rollback()/Connection.close() が呼び出される。 SQL 文が実行されて、接続が autoCommit モードに設定される (つまり、非 TX データ ソースまたはプールからの直接接続)。 OCI SQL 呼び出しからの戻りコードが、データベース レベルでコミット/ロールバックが発生したことを示している。 XADataSource が使用されているときは、上記の条件はいずれも当てはまりません。結果として、結果セット内の jDriver の LOB フィールドは、JVM ヒープ内では解放されませんでした。 closeLob () を呼び出すよう weblogic.jdbc.oci.xa.DataSrcThreadInfo.java のコードを修正することで、この問題を解決しました。
CR090025	WebLogic Server 6.1 SP04 では、jDriver for Oracle 9.2 が AL32UTF8 文字セット (Unicode バージョン 3.1) をサポートしていません。 NLS_LANG を AMERICAN_AMERICA.AL32UTF8 に設定すると、weblogic.jdbc.oci.Connection.<init>(Connection.java:246) で次のエラーが発生します。 java.sql.SQLException: Unsupported Oracle codeset: al32utf8. Set weblogic.codeset in your connection Properties to a valid JDK codeset which is compatible with the Oracle codeset defined in your NLS_LANG setting. NLS_LANG=AMERICAN_AMERICA.UTF8 のときは、「ORA-01461: can bind a LONG value only for insert into a LONG column」というエラーが発生します。これは、クライアントとデータベースの文字セットが一致していないことを示しています。 weblogic/db/oci/OciConnection のコードを修正することで、この問題は解決しました。
CR090761	WebLogic Server 7.0 の以前のリリースでは、WebLogic jDriver for Oracle で StringIndexOutOfBoundsException が発生しました。この問題は、ResultSet が中サイズ (数百行) の複数のクエリでときどき発生しました。この問題は、コードの修正で解決されました。
CR091151	WebLogic Server 6.1 SP03 および SP04 では、jDriver for Oracle の ResultSet.getBigDecimal() メソッドが正しい値を返しませんでした。 たとえば、9999999999.999999 という値は 9999999999.999998 に丸められていました。 この問題は、コードを修正して解決されました。
CR096730	WebLogic Server 7.0、7.0 SP1、および 7.0 SP2 に付属の WebLogic jDriver for MS SQL Server は、MS SQL Server 2000 SP3 データベースへの接続で使用されるときに次のエラーを送出しました。 java.sql.SQLException: I/O exception while talking to the server, java.io.EOFException Unable to connect, please check your server's version and availability. この問題は、コードを修正して解決されました。
CR098071	WebLogic Server の以前のリリースにバンドルされていた Oracle Thin ドライバ 9.2.0 には、ときどきデータ エラーを引き起こすエラーがありました。現在は、ドライバが Oracle 提供の新しいバージョンに変わっています。

JMS

変更要求番号	説明
CR101298	長期間存続する JMS 接続で、一定間隔のハートビート チェックがありませんでした。 JMS がアイドル状態の場合は、接続を有効に保つために、接続が 5 分ごとにデータベースを ping するようにコードを変更しました。
CR080289	WebLogic Server 7.0 では、UserPassword が null の場合にメッセージング ブリッジが正しく機能しませんでした。 メッセージング ブリッジが null 以外の UserName と null の UserPassword でコンフィグレーションされている場合、明確なエラー メッセージなく起動に失敗しました。 この問題は、コードを修正して解決されました。
CR083933	WebLogic Server 6.1 SP03 では、負荷の大きい状況下で JMS サーバが NullPointerException を送出していました。 <Warning> <JTA> <XA resource [JMS_JMSServer1JDBCStore] has not responded in the last 120 second(s).> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 > この問題は、実行スレッド 400、JMS スレッド 200、接続プールの接続 100 というコンフィグレーションで確認されました。例外は、負荷テストで、恒久サブスクライバに対する毎秒約 10 個のメッセージ (約 2K) を JMS サーバに対して発行すると発生しました。分散トランザクションはなく、JMS JDBC ストアに対する接続プールには Sybase ドライバが使用されていました。 この問題は、コードを修正して解決されました。
CR089583	WebLogic Server 6.1 SP02 では、トランザクション恒久サブスクライバのサブスクライブを取り消そうとすると JMSException が発生しました。 weblogic.jms.common.JMSException: Subscription clientID.vIJAY in use, uncommitted/unacknowledged messages at weblogic.jms.backend.BEConsumer.delete(BEConsumer.java:1784) at weblogic.jms.backend.BEManager.removeSubscription(BEManager.java:204) 分析の結果、確認応答されていないメッセージのカウントをメッセージごとに 2 回インクリメントし、1 回だけデクリメントしていることが判明しました。 そのため、確認応答されていないメッセージのカウントは常に 0 より大きくなり、恒久サブスクライバのサブスクライブを取り消そうとすると例外が送出されました。> この問題は、確認応答されていないメッセージのカウントと懸案の恒久サブスクライバに対するコードの修正で解決されました。
CR089682	WebLogic Server 6.1 SP03 では、メッセージング ブリッジの接続再試行の値 (下限、上限、および増分) が正しく機能しませんでした。この問題は、メッセージング ブリッジが 2 つの WebLogic JMS サーバ間でメッセージを送信するようにコンフィグレーションされており、JMS サーバが両方とも同じ WebLogic Server インスタンスで動作している場合に発生しました。JMS サーバの 1 つを対象から外すと、次のエラーが発生しました。 <Error> <Connector> <Error granting connection request.> 再試行の試みは、接続再試行パラメータによって指定された間隔で行う必要があります。 ただし、起動時のデフォルト値 (下限 = 15、上限 = 60、増分 = 5) では、次のような動作になりました。 1. 接続を試みて失敗する - OK 2. 15 秒後に 2 回目の接続を試みる - OK 3. それ以降は、5 秒間隔で接続を試みる - NOT OK <Error> <Connector> <Error granting connection request.> <Error> <Connector> <Error granting connection request.> <Error> <Connector> <Error granting connection request.> <Error> <Connector> <Error granting connection request.> <Error> <Connector> <Error granting connection request.> デフォルト パラメータのいずれかを変更すると、増分は正しくなりました。しかし、上限値には達しませんでした。デフォルト値の場合、55 までしか達しませんでした。 コードの修正で、再試行値のロジックが修正されました。
CR090403	WebLogic Server 7.0 SP02 では、JTA トランザクション内で JMS キューに複数のメッセージを入れると、その後にトランザクションがロールバックされた場合に、Administration Console で不正確な情報が表示されました。 コードの修正で、トランザクションのロールバックでの receivedCounts が調整されました。
CR091195	WebLogic Server 6.1 SP04 においてのみ、MDB が受信した永続キュー メッセージに対して適切に確認応答が行われず、Administration Console のモニタ機能で「BYTES PENDING」と表示されました。 MDB が受信したメッセージは、サーバをシャットダウンして再起動すると再配信されました。 EJB のトランザクション記述子が「NotSupported」に設定されている時の MDB の確認応答に関するコードを修正することで、この問題は解決しました。
CR091827	WebLogic Server 6.1 SP02 では、Oracle Thin Driver を使用して接続プールが作成され、JMS JDBC ストアが (JDBC のロギングを有効にして) そのプールを使用するようにコンフィグレーションされている場合に、「Connection has already been closed」という SQL 例外が生成されました。このエラー メッセージの後、JDBC ログ ファイルには何も記録されませんでした。 コードの修正で、JDBC のログ エラーが防止されます。
CR091844	WebLogic Server 7.0 SP01 では、JMS キューからまだメッセージを受信している ServerSessionPool のある QueueConnection で「stop」を呼び出すと、エンドレス ループが生じ、CPU 使用率が 100% になっていました。 この問題は、コードを修正して解決されました。
CR092110	WebLogic Server 7.0 SP01 では、JMS 接続ファクトリのフロー制御設定が FlowMinimum を 2、FlowMaximum を 8 に設定するようにコンフィグレーションされていました。 サーバを再起動した後は、次のコンフィギュレーション例外が送出されました。 <Critical> <WebLogic Server> <000364> <Server failed during initialization. Exception:weblogic.management.configuration.ConfigurationException: invalid value '8' for attribute 'FlowMaximum' of MBean "mydomain:Name=MyJMS Connection Factory,Type=JMSConnectionFactory". この問題は、FlowMinimum フィールドと FlowMaximum フィールドのリーガル チェックを廃止することで解決しました。これは、このリリースで実行できるリーガル チェックの制限です。
CR092464	WebLogic Server 6.0 SP02 と SP04 では、恒久トピック サブスクライバが JMS サーバに接続され、メッセージがそのトピックに送信されると、そのメッセージが受信側で受信されてコミットされていても Bytes Current Count の値がメッセージのサイズ分だけ増やされていました。 Messages Current Count の対応する値は影響を受けませんでした。 恒久トピック サブスクライバが JMS サーバに接続されていない状態で、トピックに送信されたメッセージがある場合は、Messages Current Count と Bytes Current Count の両方が増やされました。 恒久トピック サブスクライバが JMS サーバに再び接続されると、それに応じて Messages Current Count と Bytes Current Count が両方とも減らされました。この不一致の結果として、恒久トピック サブスクライバに未処理のメッセージがなくても「Bytes Current Count」の値はゼロになりません。 分析の結果、backend/BEConsumer.java addMessages() において bytesCurrentCount が不適切に更新され、Administration Console に正しくない統計が表示されていることが判明しました。 この問題は、コードを修正して解決されました。
CR092468	WebLogic Server 7.0 SP01 では、JMS 接続ファクトリの (フロー制御の) FlowMinimum の最小許容値 0 がメッセージ プロデューサに悪い影響を持つという分析結果が出ました。値を 0 にするとプロデューサでメッセージの送信を完全に止められるように思えますが、実際には、メッセージは少しずつ送信され続けるようになっていました。 この問題は、FlowMinimum の最小許容値を 1 に変更することで解決しました。
CR093177	WebLogic Server 7.0 SP01 では、メッセージング ブリッジに関する Administration Console のラベル、オンライン ヘルプ、およびログ メッセージが、[最大待機時間] 属性および [増加遅延] 属性の測定方法と一致していませんでした。これらの属性は、「ミリ秒」ではなく「秒」を単位とします。 この問題は、それらの属性の単位が「秒」であることを反映して Administration Console のラベル、オンライン ヘルプ、およびログ メッセージを修正することで解決しました。
CR093712	WebLogic Server SP04 では、メッセージング ブリッジの [最大待機時間] の設定値に達した後、メッセージがサーバのログ ファイルに記録されていました。多くのメッセージング ブリッジがコンフィグレーションされている場合は、ログ ファイルがすぐに一杯になり、場合によっては非常に大きくなるようになっていました。 それらのメッセージは、現在はメッセージング ブリッジで実行時のデバッグが有効になっている場合だけ生成されるようになりました。
CR094414	WebLogic Server 7.0 SP02 のメッセージング ブリッジのドキュメントでは、メッセージング ブリッジの [Execute Thread Pool Size] フィールドの値は -1 でも有効であり、この値を使用すれば、このスレッド プールが無効になって、すべてメッセージング ブリッジが WebLogic Server のデフォルト スレッド プールを使用するようになるとされていましたが、このフィールドの値 -1 は実際には許可されていませんでした。 コードの修正により、[Execute Thread Pool Size] を「-1」に設定することができるようになりました。
CR094670	WebLogic Server 7.0 SP01 では、信頼性のあるセキュリティ関係を確立していない WebLogic Server ドメインをメッセージング ブリッジを使用して相互運用するときに次のセキュリティ エラー メッセージが生成されました。 java.lang.SecurityException: Invalid Subject: principals=[searchuser] WebLogic Server のセキュリティでは、信頼性のないドメイン間の同期処理が可能となりました。
CR096229	WebLogic Server 7.0 では、分散送り先を通じてアクセスされた場合、物理送り先のセキュリティに効果がありませんでした。 たとえば、分散送り先に物理的なキュー メンバーが 2 つ (SecQ1 と SecQ2) あり、いずれかの物理キューにメッセージを「送信」するための JMS セキュリティ特権がユーザに与えられていない場合でも、そのユーザは分散送り先を通じて正常にメッセージを送信することができました。 この問題は、分散送り先の物理送り先メンバーと照らし合わせてセキュリティをチェックすることで解決されました。
CR096854	ユーザがクラスタ内の 1 つのサーバでメッセージング ブリッジを設定し、その後にそのブリッジをクラスタ内の別のサーバに移行しました。その場合に、2 番目のサーバを起動すると次の例外が発生しました。 (java.lang.Exception: java.lang.NullPointerException at weblogic.jms.bridge.internal.MessagingBridge.getConnections(MessagingBridge.java:714) at weblogic.jms.bridge.internal.MessagingBridge.execute(MessagingBridge.java:919) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134) メッセージング ブリッジは移行可能なターゲットを対象とされた場合に初期化手順の 1 段階をスキップし、その結果としてブリッジはコンフィグレーションからリソース アダプタの情報を取得できませんでした。 NullPointerException は、ブリッジが後でリソース アダプタにアクセスしようとしたときに発生していました。 この問題は、移行可能ターゲットの場合のメッセージング ブリッジの初期化コードを修正して解決されました。
CR097451	WebLogic Server 7.0 SP01 では、ステートレス EJB のトピック メッセージが接続の開始前に TopicSubscriber クライアントに配信されていました。 コードの修正により、接続の開始前にメッセージが配信されることがなくなります。
CR097538	WebLogic Server 7.0 SP01 では、JMS セレクタの長さ属性が 3 未満の場合に次の解析セレクタ エラーが発生しました。 weblogic.jms.common.InvalidSelectorException: Error parsing selector この問題は、コードを修正して解決されました。
CR097963	WebLogic Server 7.0 では、JMS サーバに着信キューと発信キューがあり、別のサーバにある MDB が1 対 1 の関係でその着信キューからのメッセージを消費し、その発信キューへのメッセージを生成する場合に、それはすべて MDB によって開始されたトランザクションの中で行われていました。 そのトランザクションは、MDB がメッセージを発信キューに入れたときに終了していました。JMS サーバが停止して再起動した場合、メッセージは失われていました。10,000 メッセージの負荷で、一部 (少量) のメッセージが失われていました。 コードの修正により、XASession は CLIENT_ACK 確認応答を実行します。
CR098049	WebLogic Server 7.0 SP01 では、重複したメッセージ ID が JMS で生成される可能性がありました。 この問題は、コードを修正して解決されました。
CR098268	WebLogic Server 7.0 SP01 では、メッセージ駆動型 MBean が、XAConnectionFactory を使用している場合に XAConnection を開いていました。つまり、トランザクション非対応 MDB の場合、コンテナは XASession を使用して接続し、それがクライアントの確認応答だと気付いていなかったので、「確認応答」は呼び出されず、メッセージは確認応答されていませんでした。 コードの修正によってこの動作は変更されました。そのため、返される接続ファクトリのタイプに関係なく、MDB のコンテナは XA が必須の場合に XAConnection と XASession のみを作成します。
CR098280	XAQueueConnection または XATopicConnection オブジェクトを使用して XA 非対応セッションを作成する場合の、セッション作成メソッドの動作が変更されました。この変更の前は、次のような動作でした。 XAQueueConnection.createQueueSession は XAQueueSession を作成する XATopicConnection.createTopicSession は XATopicSession を作成する いずれの場合も、ユーザ指定の確認応答モードとトランザクション フラグは無視されて、AUTO_ACKNOWLEDGE モードと false のトランザクション設定で置き換えられました。 一方、新しい動作では、XAQueueConnection.createQueueSession および XATopicConnection.createTopicSession メソッドが、QueueConnection および TopicConnection の対応するメソッドとまったく同様に、次のように動作します。 QueueConnection.createQueueSession は QueueSession を作成する TopicConnection.createTopicSession は TopicSession を作成する XAQueueConnection.createQueueSession は QueueSession を作成する XATopicConnection.createTopicSession は TopicSession を作成する さらに、ユーザ指定の確認応答モードとトランザクション フラグ設定は、これらの 4 つの各メソッドで受け付けます。 上記の 4 つの接続メソッドは、接続ファクトリで XAServerEnabled フラグが有効になっている場合、異なる動作をします。 このフラグが有効な場合、4 つのすべてのメソッドは、サーバ上で呼び出された場合は XAQueueSession (または XATopicSession) セッションを作成し、クライアント上で呼び出された場合は XA 非対応の QueueSession または TopicSession セッションを作成します。 作成されたセッションはユーザ指定の確認応答モードを受け付けますが、XA をサポートしているため、トランザクション フラグは無視されます。 以前のバージョンの WebLogic Server 7.0 では、XAConnectionFactoryEnabled フラグが有効になっているときに接続ファクトリから作成される接続オブジェクトは、XAQueueConnection または XATopicConnection オブジェクトのように動作しました。 新しい動作の変更によって、XAQueueConnectionFactory または XATopicConnectionFactory に接続を明示的にキャストして、いずれかの createXA メソッドを呼び出さない限り、この動作は見えなくなりました。 この変更の前は、接続ファクトリで XAConnectionFactoryEnabled フラグを設定する場合、接続ファクトリをいずれかの XA 接続ファクトリ クラスにキャストしていなくても、createQueueSession と createTopicSession の動作が異なっていました。
CR098280	WebLogic Server 7.0 SP01 では、クライアントサイドおよびサーバサイドで、XAConnection オブジェクトの createSession() メソッドを呼び出すと XASession オブジェクトが作成されていました。 XASession オブジェクトの createSession() を呼び出すと非 XA「セッション」オブジェクトが作成されるように変更されています。
CR098692	WebLogic Server 6.1 SP04 では、ガベージ コレクションまたはトランザクション タイムアウトの後に JMS キューでのメッセージの同期受信が停止しました。 この問題は、JMS ディスパッチャのコードをリファクタリングしてスレッド管理を改善することで解決しました。
CR099455	WebLogic Server 7.0 SP01 では、コンシューマに向けて送信されたメッセージがフロントエンド セッションに到着したが、そのメッセージがすでに閉じているコンシューマに向けられている場合、リストが特に考慮なく切り詰められて、メッセージが失われる可能性がありました。 この問題は、潜在的な競合状態を防止するコード修正で解決されました。
CR100015	dispatch-policy がメッセージ駆動型 Bean で対応されるようになりました。つまり、メッセージ駆動型 Bean をユーザ定義の実行キューに割り当てることができるようになったのです。
CR100076	WebLogic Server 7.0 では、JMS サーバが WebLogic Server インスタンス (server1) から別のインスタンス (server2) に移行された場合、その JMS サーバは server1 で非アクティブ化され、そのすべての送り先がサスペンドされていました。ただし、送り先がサスペンドされるときに、メモリ内のメッセージはクリーンアップされませんでした。そのため、JMS サーバが server1 に再び移行されたときに、移行前に JMS サーバ上にあったすべてのメッセージが server2 でキューから出されている場合でも表示されていました。 JMS サーバが server2 に移行された後に server1 でメモリ内のメッセージがクリーンアップされたときには、重複メッセージはないはずです。 この問題は、JMS サーバを別の WebLogic Server インスタンスに移行するときにメモリ内のメッセージのリストをクリーンアップすることで解決しました。
CR100083	WebLogic Server 7.0 では、JMS サーバと関連付けられた実行時 MBean (JMSServerRuntimeMBean と JMSDestinationRuntimeMBean) が、JMS サーバがサスペンドされた後に管理サーバから登録解除されませんでした。その結果、JMS サーバが移行可能の対象をターゲットとしている場合に、それらの MBean の 2 つのインスタンスが、JMS サーバが別のサーバに移行された後も Administration Console のモニタ ページに表示されます。1 つのインスタンスが元のサーバ インスタンスにあり、もう 1 つのインスタンスが JMS サーバの移行先サーバにあったのです。 実行時 MBean の登録解除と登録のプロセスが、現在は適切に処理されるようになっています。
CR101298	ファイアウォールの生存期間が切れるなどして、長い時間アイドル状態の JMS JDBC 接続が「bad」とマークされた場合に、JMS がその「bad」の接続を使用しようとして失敗していました。この失敗がすぐに復帰するか、8〜10 分ほどかかるかは、チューニング パラメータによって決まります。 この問題は、JMS がアイドル状態の場合に、接続を維持するために 5 分ごとにデータベースに ping を実行するようコードを修正して解決されました。5 分が選ばれたのは、どのファイアウォールのタイムアウトよりも短い時間だと考えられたからです。
CR103213	サーバが JMS メッセージの送信に失敗したときに、クライアントでエラー メッセージが表示されませんでした。トランザクション マネージャはメッセージが異常であると宣言し、JMS はリソースの取得に失敗したときにメッセージをロールバックしていました。 トランザクションの取得の失敗はクライアントに通知されるようになりました。コミットが失敗したことも報告されます。
CR105237	IIOP プロトコルで JMS を使用しているときに、クライアントによる異常な切断がサーバで正しく検出されませんでした。 そのため、クライアントに関連付けられたステートフル情報 (JMS クライアント ID など) で問題が発生しました。 異常な切断は適切に検出されて処理されるようになりました。
CR105337	負荷のかかる状況で、テスト JMS アプリケーションに次の例外が発生しました。 java.lang.OutOfMemoryError weblogic.jms.common.TransactionRolledBackException: at weblogic.jms.backend.BEConsumer.expireTimeout(BEConsumer.java:1620) at weblogic.jms.backend.BEXATranEntryBlockingConsumer.startRollback(BEXATranEntryBlockingConsumer.java:72) at weblogic.jms.backend.BEXAResource.rollback(BEXAResource.java:1205) at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:1400) at weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:664) at weblogic.transaction.internal.ServerSCInfo.startRollback(ServerSCInfo.java:365) at weblogic.transaction.internal.ServerTransactionImpl.localRollback(ServerTransactionImpl.java:1521) at weblogic.transaction.internal.ServerTransactionImpl.globalRollback(ServerTransactionImpl.java:2142) at weblogic.transaction.internal.TransactionImpl$1.execute(TransactionImpl.java:1656) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:211) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:198) weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.rollbackAfterRecover(FESession.java:1773) at weblogic.jms.frontend.FESession.recover(FESession.java:1373) at weblogic.jms.frontend.FESession.invoke(FESession.java:2253) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:339) at weblogic.jms.client.JMSSession.recoverGuts(JMSSession.java:868) at weblogic.jms.client.JMSSession.rollback(JMSSession.java:632) at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback(DefaultJmsQueueReceiver.java:184) at com.ncr.crm.framework.jms.DemoMessageConsumer.run(JmsMemoryLeakDemo.java:163) at java.lang.Thread.run(Thread.java:479) ----------- Linked Exception ----------- weblogic.jms.common.JMSException: Only one thread may use a JMS Session at a time. at weblogic.jms.frontend.FESession.recover(FESession.java:1219) at weblogic.jms.frontend.FESession.invoke(FESession.java:2253) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:609) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncNoTran(DispatcherImpl.java:339) at weblogic.jms.client.JMSSession.recoverGuts(JMSSession.java:868) at weblogic.jms.client.JMSSession.rollback(JMSSession.java:632) at com.ncr.crm.framework.jms.DefaultJmsQueueReceiver.rollback(DefaultJmsQueueReceiver.java:184) at... 調査の結果、WebLogic JMS のガベージ コレクション機能は、リンクされた長いリストを扱うときにメモリを再要求するために速度が遅くなることが判明しました。リストを分割するようにコードを変更しました。その修正で、問題は解決されました。
CR105980	分散キューの各メッセージごとに QueueReceiver を作成して、QueueReceiver が停止された後で永続化しているときにメモリ リークが発生しました。 コードを変更して、BasicServiceOffer および DistributedDestinationImpl オブジェクトのメモリ リークを修正しました。
CR106789	使用されていない JMS オブジェクトが開いたままであることが原因で、メモリ リークが発生していました。 次の修正によって問題は解決されました。 - 同じ送り先上で作成されたすべてのプロデューサの送り先が正規化された。 - FEProducer を DispatcherWrapperState に置き換えるときに、正しい DispatcherWrapperState からリスナが削除された。 - FEProducer を無条件にクローズするときに、正しい DispatcherWrapperState からリスナが削除された。 - BackEnd が停止するときに、FrontEnd 上の一時的な送り先のリークが削除された。

JNDI

変更要求番号	説明
CR084381	JNDI コンテキストの list("") メソッドが、正しいクラス名を返していませんでした。 現在は、「list」メソッドを使用したときに WebLogic Server から実際のクラス名が返されます。
CR087237	サーバで kill -STOP が呼び出されたときに RMI のフェイルオーバが長い時間かかっていました。 コードの変更により、フェイルオーバに必要な時間が短縮されました。
CR093700	JNDI ツリーがリバインドで適切に更新されていませんでした。 クラスタ ノードの 1 つからクラスタ可能リモート オブジェクトを JNDI アンバインドしても、そのオブジェクトがアンバインドされたノードに呼び出しが届いたときにそのオブジェクトがまだアクセス可能な状態になっていました。この問題は修正済みで、リモート メソッド呼び出しでは次に利用可能なノードが選択されます。
CR093799	複合名に対してコンテキスト ルックアップを行うと、名前の全体または一部が解決できない場合に NameNotFoundException が発生していました。 RemainingName が CompositeName である場合は、列挙があるはずです。 残りの名前は単一文字列として扱われ、WebLogic Server は CompositeName の作成時に「.」をセパレータとして渡していました。現在は、「.」セパレータが「/」に適切に置換され、列挙が正しく作成されるようになっています。
CR103148、CR110890	WebLogic Server 7.0 SP2 では、LoadBeforeAppDeployments が true に設定されている場合、起動クラスは LOCAL_JNDI_NAME のローカル インスタンス MBeanHome (weblogic.management.home.localhome) にアクセスできませんでした。次のようなエラー メッセージにより失敗しました。 Unable to resolve 'weblogic.management.home.localhome' Resolved: 'weblogic.management' Unresolved:'home' 他の JNDI 名のバインディングを起動クラスで使用できるように AdminService へ移動することで、問題を修正しました。
CR106853	動的プロキシ オブジェクトをローカル JNDI ツリーにバインドしようとすると、ClassNotFoundException が発生しました。 コードを変更して、resolveProxyClass() を実装し、アプリケーションからインタフェースをロードするためにスレッド コンテキスト クラスローダを使用することで、問題を修正しました。

JSP とサーブレット

変更要求番号	説明
CR083597	<%@ page contentType="text/html;charset=UTF-8" %> などのページ ディレクティブを使用してコンテンツ タイプが設定されるときに、そのコンテンツ タイプは正しく設定されず、目的の出力が得られませんでした。 この問題は、コードの変更によって取り除かれました。
CR088044	HTTP のログ オプションとして「拡張フォーマット」を選択し、サーバを再起動すると、Null ポインタ例外が送出されました。 logManagerHttp の作成時に access.log ファイルを開くコードを追加することで、この問題は取り除かれました。
CR088350	HttpProxyServlet は、サードパーティのサーバに到達できませんでした。 この問題は、サーバが ContentLength を送信せず、データをいつまでも送信し続けることが原因で発生しました。 コンテンツの長さがなく、チャンク転送されていない場合、サーバはストリームの最後まで読み込みます。 HttpProxyServlet は、バイト単位で読み書きするように変更されています。
CR088747	weblogic.xml で CookiePath を明示的に設定していない Web アプリケーションに対するリクエストの後で、ユーザ エージェントは WebLogic Server セッションを再確立できませんでした。 WebLogic Server は、同じドメインからの 2 番目のクッキーが存在し、それがリクエストの URL と一致するパスを指定している場合でも、weblogic.xml で指定されたクッキー名と名前が同じ最初のクッキーを使用します。 以前は、クッキー ベクトルの後方へ向かって JSESSIONID を検索していましたが、検索方向は前方に変更されています。
CR088759	redirect-with-absolute-url 機能が、j_security_check では機能しませんでした。応答の Location ヘッダがまだ絶対パスでした。 redirect-with-absolute-url が FormSecurityModule で対応されるようにコードが修正されています。
CR089347	ネットワーク チャネルでは、getServerPort メソッドは、FrontendHTTPPort 値が config.xml の WebServer 要素で設定されている場合に FrontendHTTPPort の値を返します。 (WebLogic Server の前にプロキシがある場合など) HOST ヘッダに WebLogic Server デフォルト リスン ポート以外のポートが含まれている場合は、FrontendHTTPPort を指定することで、HOST ヘッダで指定されたポートではなく WebLogic Server ポートが getServerPort() から返されるようになります。 ただし、この FrontendHTTPPort 値は、別のポートで動作しているネットワーク チャネルの場合も含めてすべての getServerPort() の呼び出しで返されていました。 request.getAttribute("weblogic.servlet.network_channel.port") を使用して、リクエストが受信されたポートの値が返されるようにコードが修正されています。
CR089582	リクエストに Host ヘッダがない場合に、不正確な Date ヘッダが返されていました。 この問題は、エラー メッセージを送信する前にリクエストの開始時刻を設定することで修正されました。
CR089868	CR083654 を修正するために作成されたパッチを適用すると、マルチバイトのヘッダが不正確になっていました。 この問題は、WebServer に UseHeaderEncoding オプションを追加することで解決されました。
CR090188	チャンク転送では、WebLogic Server はデータに付加されたチャンク サイズを扱っていました。 setChunking は、ServletRequestImpl の mergePostParams から、request.setInputStream 直後の MuxableSocketHttp に移動しています。
CR090465	ユーザ定義のエラー ページがある Web アプリケーションをホストすると、WebLogic Server が、400 番のエラーに対して Connection: close ヘッダを設定しないで次の応答を返し、直ちに接続を閉じていました。 HTTP/1.1 400 Bad Request Date: Thu, 01 Jan 1970 00:00:00 GMT Content-Length: 463 Content-Type: text/html Last-Modified: Thu, 07 Nov 2002 21:56:52 GMT <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> この問題は、コードを修正して解決されました。
CR090555	Http ヘッダに X_WEBLOGIC_CLUSTER_LIST がない場合は、X_WEBLOGIC_CLUSTER_HASH をチェックするコードのためにサーバ リストが作成されませんでした。 この問題は、応答ヘッダでハッシュの後にリストが送信される場合にサーバでハッシュを格納できるようにすることで修正されました。
CR091759	RequestDispatcher.forward が、URL ヘッダのバージョン番号を削除していました。 この問題は、forward() の実行時に setRequestURI() で processPathParameters を false に設定して修正されました。
CR091831	HttpURLConnection の WebLogic Server 実装は、POST メソッドの使用時にサーバ側でキープアライブ接続がタイムアウトになっているかどうかをチェックしなかったので、フラッシュ時にエラー「Connection aborted by peer: socket write error」が発生していました。 サーバでキープアライブを無効にすると、問題がなくなります。キープアライブの期間を長くしても、異なる長さのスリープで同じ問題が発生しました。 タイムスタンプの更新前に HttpClient が非 null であるようにするチェック機能が追加されました。
CR091922	サーブレット コンテナがエラー ページにログイン例外を渡していませんでした。 現在、エラー JSP は例外にアクセスできます。
CR092039	WebLogic Server は、JSP タグの charset の値に余分な引用符があると UnsupportedEncodingException を送出していました。 この問題は、ヘッダの属性値で HTTP 仕様のサポートを追加することで解決しました。
CR092039	WebLogic Server 6,1 SP03 では、JSP タグの charset の値に余分な引用符があると、JspParser から UnsupportedEncodingException が送出されていました。 <%@ page contentType="text/html; charset=¥"Shift_JIS¥"" %> 上のように余計な引用符があると、次のエラーが発生していました。 java.lang.RuntimeException: Unknown/unsupported charset: "Shift_JIS" - java.io.UnsupportedEncodingException: Charset: '"Shift_JIS"' not recognized, and there is no alias for it in the WebServerMBean WebLogic Server が、HTTP 仕様を適切にサポートしていませんでした。 この問題は、引用符付き文字列およびコメントのサポートを Content-Type ヘッダの charset 属性値に追加することで解決されました。
CR092173	ファイル サーブレットの GET 機能はバイトの範囲をサポートするようになりました。
CR092255	クッキーの引用符が、WebLogic Server によって取り除かれていました。その結果、特定の環境ではクッキーの値が読み取れなくなっていました。現在は、引用符がクッキーに残されるようにコードが変更されています。
CR092377	Web アプリケーションの web.xml ファイルで、 <user-data-constraint> <description>USE SSL</description> <transport-guarantee>CONFIDENTIAL</transport-guarantee> </user-data-constraint> リソースに対してこのように設定し、HTTP を使用してその保護されたリソースにアクセスすると、リソースを表示する許可が与えられていないことを通知するエラーがサーバから送出されていました。サーバは、サーブレット仕様 2.3 のページ 87 に従って認証し、HTTPS に切り替える機会をユーザに与えていませんでした。 現在、コンテナは元のリクエストが HTTP 経由で、リソースが INTEGRAL または CONFIDENTIAL に設定されている場合はクライアントを HTTPS ポートにリダイレクトするようになっています。
CR092428	WebLogic Server は、Netscape クッキーの「,」を文字として受け入れていませんでした。 カンマは現在は Netscape のクッキーで許可されています。その理由は、RFC2109 クッキーでのみカンマは区切り文字として使用できるからです。
CR092545	リクエストがプロキシ経由で発行され、その最初のリクエストが終了する前に同じリクエストが再び発行されると、例外が発生していました。 プロキシは、クライアントへの書き込みに失敗しても (接続がブラウザによって閉じられても) IIS から入力ストリームを排出するようになりました。
CR092778	WebLogic Server 6.1 SP04 では、HttpRequest の JISAutoDetect エンコーディングで、次の UnsupportedEncodingException が送出されました。 java.io.UnsupportedEncodingException: JISAutoDetect at sun.io.Converters.getConverterClass(Converters.java:102) at sun.io.Converters.newConverter(Converters.java:133) at sun.io.CharToByteConverter.getConverter(CharToByteConverter.java:62) at weblogic.servlet.internal.ServletRequestImpl.setCharacterEncoding(ServletRequestImpl.java:344) ... この問題は、WebLogic Server 6.1 SP03 では起こりませんでした。 この問題の原因は、ServletRequestImpl.java が sun.io.ByteToCharConverter. ではなく CharToByteConverter クラスを使用していたことです。CharToByteConverter は、入力コンバータ用です。CharToByte は、出力コンバータ用です。JISAutoDetect は、入力ストリームでのみ使用できます。 この問題は、コードを修正して解決されました。
CR093014	Java のコメントが複数のスクリプトレットにまたがると、jspc が失敗していました。 ScriptletScopeLexer が Java のコメント全体をスキップするようにするコードを追加して問題は解決されました。
CR093112	JSP に <%@ include file="./file.inc" %> のような行があり、file.inc に <%@ taglib uri="/c.tld" prefix="c" %> のような行があり、c.tld にバリデータがある場合は、<%@ include file="./file.inc"%> およびタグ ライブラリの使用に関するJSP コンパイラ エラーが返されていました。 この問題は、XML フォーマットに変換される JSP ページの currentURI の参照を追加することで修正されました。この修正の結果、アプリケーション ルートを基準とした、インクルードされた JSP の相対的な位置を実装で計算することができます。
CR093167	HTTPClusterServlet を使用してバックエンド クラスタ上のセキュアな Web アプリケーションにアクセスする場合、ユーザ名とパスワードの入力後に Internet Explorer が 30 秒間「ハング」します。 WebLogic Server は現在は、Connection: Close ヘッダ要求がブラウザにプロキシされている場合はクライアントとプロキシ サーバ間の接続を閉じるようになりました。
CR093209	プロパティがアプリケーションの java プロトコルに設定された、正常にデプロイされている Web アプリケーションがアクセスされたときに、WebLogic Server から NullPointerException が送出されていました。 現在は、source.getURL() の null 値がチェックされます。
CR093209	新規にインストールした WebLogic Server 6.1 SP04 では、プロパティが Java プロトコルに設定されている、正常にデプロイされた Web アプリケーションにアクセスすると、null ポインタ例外が送出されていました。ブラウザからは、500 番のサーバ内部エラーが返されました。この問題は、アップグレード インストールでは発生しませんでした。 <Dec 16, 2002 11:59:05 AM PST> <Error> <HTTP> <[WebAppServletContext(2092664,sampleApp,/sampleApp)] Servlet failed with Exception java.lang.NullPointerException at weblogic.servlet.JSPServlet.service(JSPServlet.java:132) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:2637) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2359) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120) 分析の結果、 ZipSource.getURL() のエラーであることが判明しました。この問題は、source.getURL() の null 値をチェックするロジックを追加することで解決しました。
CR093625	サーバが、JSP ページの JSP includes に対して出力を誤って送っていました。 この問題は、includes、forwards、wrapped-responses、および JSP BodyTags の処理を統一するようにサーブレット エンジンを変更して解決されました。
CR093634	新しいパラメータ [WebLogic プラグインを有効化] が WebLogic Server に追加されました。 getRemoteAddr を呼び出すと、クライアントの IP アドレスではなく HttpClusterServlet の IP アドレスが返されていました。その理由は、HttpClusterServlet が独自のヘッダ「WL-Proxy-Client-IP」を設定せず、したがってソケットの IP アドレスを使用していたからです。 この問題はコードで修正されました。
CR093755	無害の警告メッセージがコードから削除されました。 context.log.error("Warning: One of the getParameter family of methods called after reading from the ServletInputStream(), can't mix these two!"); が無効になりました。
CR094190	JVM 仕様に従って、メソッド サイズのサイズ制限は 64K です。WebLogic Server 6.1 SP03 で、JSP に多数の本文タグがあるときに、生成された java コードが __jspService メソッドの 64K の制限を超えました。 この問題は、コードを変更して解決されました。 フォーム <my:tag ... /> の BodyTag が空である場合、生成されるコード (通常は本文の範囲を設定する) が、StandardTagLib.java の静的メソッドへの単一の呼び出し (JSP ソースから普通に呼び出されたと BodyTag に認識させる) によって置き換えられるようになりました。
CR094416	以前のバージョンの WebLogic Server 7.0 では、更新されていなくてもすべての JSP を事前にコンパイルしていました。 コードの変更により、WebLogic Server のインスタンスが再起動したときに一時ディレクトリが上書きされないようになりました。
CR094488	HTTP を使用して開始されたセッションで、セッション データを損失することなく HTTPS リソースに安全にアクセスできるようにする新しい機能が追加されました。この新しい機能を有効にするには、config.xml の WebServer 要素に AuthCookieEnabled="true" を追加します。 <WebServer Name="myserver" AuthCookieEnabled="true"/> このように設定すると、HTTPS 接続を通じて認証する場合に新しいセキュアなクッキーがブラウザに送信されます。いったん設定すると、クッキーがブラウザから送信される場合にのみ、セッションは他のセキュリティ制約 HTTPS リソースにアクセスできます。 注意: 普通の HTTP で認証する場合、HTTPS リソースでセキュアなクッキーは設定されず、必要ともされません。 保護されていない HTTPS リソースにアクセスする場合、クッキーは検証されません (ブラウザから送信されないため)。 この動作により、ブラウザはユーザのログインなしに、保護されていない HTTPS リソースにアクセスできます。
CR094663	3 サーバ クラスタと IIS プロキシ プラグインを使用して負荷テストを実行し、クラスタ内のいずれか 1 つのサーバを停止すると、IIS プロキシから 500 エラーが送出されました。 原因は、解析エラーとサーバ アフィニティの問題にありました。 これらの問題は、コードで修正されています。
CR095713	Unix プラットフォーム (Solaris、Linux) の場合に、セカンダリ サーバでレプリケート セッションが失われていました。 web.xml (j2ee 記述子) の session-config 要素は非推奨ではありません。値は分単位です。 weblogic.xml (BEA 固有の記述子) の要素は秒単位の値をとり、web.xml で定義された値に優先します。
CR096399	JSP コンパイル エラーが不適切に処理されていました。 フィルタは HttpServletResponseWrapper getWriter ではなく OutputStream と通信して、次の結果になりました。 java.lang.IllegalStateException: strict servlet API: cannot call getWriter() after getOutputStream() at weblogic.servlet.internal.ServletResponseImpl.getWriter(ServletResponseImpl.java:171) at weblogic.servlet.internal.ServletRequestImpl.reportJSPFailure(ServletRequestImpl.java:227) at weblogic.servlet.internal.ServletRequestImpl.reportJSPCompilationFailure(ServletRequestImpl.java:239) at weblogic.servlet.jsp.JspStub.reportCompilationFailure(JspStub.java:523) at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:430) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:210) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:517) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:351) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:445) at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:20) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at WebLogic ServerBugFilter.doFilter(WebLogic ServerBugFilter.java:27) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:27) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5418) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:744) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3086) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2544) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:153) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:134)... WebLogic ServerBugFilter.doFilter after ラッパー対応の RequestCallback を実装して問題を修正しました。
CR097719	WebLogic Server SP02、SP03、および SP04 では、WAP デバイスから特定の POST リクエストを取得するときに、Web アプリケーションで java.util.ConcurrentModificationException が送出されていました。 <29.jan.03 13:03:05 WET> <Error> <HTTP> <[WebAppServletContext(2810713,TnMFF,/TnMFF)] Servlet failed with Exception java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.next(HashMap.java:736) at weblogic.utils.enumerations.IteratorEnumerator.nextElement(IteratorEnumerator.java:25) at com.colibria.core.xmlswitch.XMLSwitch.getQueryStringXML(XMLSwitch.java:347) at ... 分析の結果、charset がリクエストの content-type と関連付けられている場合に、アプリケーションでコードがそのエンコーディングを使用してデータを再び読み取り、クエリ パラメータを再設定していることが判明しました。アプリケーションは既に列挙オブジェクトを持っており、それを検索して (request.getParameterNames)、パラメータの値を取得しようとします (request.getParameterValues(k))。その時点で、クエリのパラメータは消去されており、getParameterValues メソッドがそれを設定しようとした結果、例外が発生します。 文字セットがリクエストの content-type と関連付けられている場合にデータを再び読み取ることができるよう、消去されたクエリ パラメータを設定するようにコードを修正して、この問題は解決しました。
CR098366	サーバが起動した直後に、一部のサーバ リクエストが拒否されていました。その理由は、リスン スレッドがリクエストの受信を始める前に MBean がサーバの状態を更新しなかったからです。 この問題は、Web コンテナ内でブール フラグを使用してリスン スレッドのサーバ状態を更新することで解決されました。
CR098518	次の EJB/Web アプリケーションの設定によってクラス キャスト例外が発生しました。 Servlet Filter1 --> WebApp1 -- forward to WebApp2 ctx --> Servlet Filter2(WebApp2) --> Ejb Lookup (fails) 2 つの Web アプリケーション間で転送するときに、サーブレット フィルタではなくサーブレット内で EJB ルックアップを行うことで、この問題を修正しました。
CR100172	複数のチャンクになったリクエストがサーブレットにポストされると、多くのリクエストが NumberFormationException で失敗しました。ほとんどの場合、代替リクエストは正常に処理され、次のリクエストが失敗しました。この問題は、リクエストが同じ接続で行われている場合に発生しているようでした。例外のスタック トレースは次のようなものでした。 <ExecuteThread: '11' for queue: 'default'> <kernel identity> <> <101017> <[ServletContext(id=4864139,name=387551,context-path=)] Root cause of ServletException> java.lang.NumberFormatException: at java.lang.Integer.parseInt(Integer.java:430) at weblogic.utils.http.HttpChunkInputStream.readChunkSize(HttpChunkInputStream.java:118) at weblogic.utils.http.HttpChunkInputStream.initChunk(HttpChunkInputStream.java:72) 分析の結果、PostInputStream に 2 つの問題があることが判明しました。 PostInputStream を再利用するときに、制御変数 readAllChunks をリセットしていなかった。 isChunkComplete がチャンクの終了を正しく検出していなかった。 PostInputStream でストリームを最後まで読み取り、HttpChunkInputStream でチャンクの終わりを正しく検出するようコードを修正して、この問題は解決しました。
CR100298	フィルタ サーブレットを使用する、つまり HTTPServletRequest に加えて HTTPRequest ラッパー クラスを使用した Web サービスが ClassCastException エラーになりました。WebLogic Server はリクエストのタイプが weblogic.servlet.internal.ServletRequestImpl であると予期していたためです。 コードの修正で、この問題は解決されました。
CR100572	URI が正しくないリクエストをプラグインから受け取ると、WebLogic Server は次のスタック トレースを送出していました。 <Mar 8, 2003 3:27:20 PM PST> <Error> <Socket> <BEA-000421> <Uncaught Throwable i n processSockets java.lang.NullPointerException. java.lang.NullPointerException... この問題は、コードを修正して解決されました。
CR100837	WebLogic Server 6.1 SP04 が、JSP ページの JSP includes に対して出力を誤って送っていました。 この問題は、コードを修正して解決されました。
CR102036	削除された JSP ページに最初にアクセスすると、「404 File Not Found」でなはく JspFileNotFoundException が発生しました。このページへの以降のアクセスでは適切に 404 が返されました。 削除された JSP ページが常に 404 を返すように問題を修正しました。
CR102446	WebLogic Server 7.0 の以前のバージョンで、JSP が管理サーバの MBeanServer 上に ModelMBean を登録するように、管理サーバ上で動作する Web アプリケーションから JSP を呼び出し、その後管理対象サーバを停止して再起動すると、サーバは次のメッセージにより失敗しました。 <Critical> <WebLogicServer> <000364> <Server failed during initialization. Exception:weblogic.management.configuration.ConfigurationException: - with nested exception: [java.lang.ClassCastException: javax.management.modelmbean.ModelMBeanInfoSupport] java.lang.ClassCastException: javax.management.modelmbean.ModelMBeanInfoSupport at weblogic.management.commo.Commo.createMBean(Commo.java:530) at weblogic.management.internal.RemoteMBeanServerImpl.createCommoMBeanLocally(RemoteMBeanServerImpl.java:941) at weblogic.management.ManagedServerAdmin.syncToAdminServerCommo(ManagedServerAdmin.java:406) at weblogic.management.ManagedServerAdmin.initializeCommo(ManagedServerAdmin.java:444) at weblogic.management.Admin.start(Admin.java:307) at weblogic.t3.srvr.T3Srvr.initialize1(T3Srvr.java:679) at weblogic.t3.srvr.T3Srvr.initialize(T3Srvr.java:589) at weblogic.t3.srvr.T3Srvr.run(T3Srvr.java:277) at weblogic.Server.main(Server.java:32) weblogic.management.commo.Commo.java のコードを変更して問題を解決しました。
CR102628	次の JSP コードでは、 <jsp:plugin type="applet" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/" height="800" width="500" type="applet" jreversion="1.3.1_06" nspluginurl="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; iepluginurl="http://java.sun.com/products/plugin/1.1.3/ jinstall-113-win32.cab#Version=1,1,3,0" > 以下の HTML が生成されます。 <embed type="application/x-java-applet;version=1.3.1_06" pluginspage="http://java.sun.com/products/plugin/1.1.3/plugin-install.html"; height="800" width="500" code="examples.applets.PhoneBook1.class" codebase="/bea_WebLogic Server_internal/classes/DefaultWebApp@DefaultWebApp/"> 生成された HTML コードは Netscape で失敗しました。Netscape は SUN のサイトからではなく WebLogic Server からプラグインをダウンロードしようとしました。 pluginspage 行を codebase 行の前に移動すると、コードは Netscape 上で正しく動作しました。 アプレット属性の順序が正しくなるようにコードを修正して、問題を解決しました。
CR102675	あるページで taglib ディレクトリを通じて taglib を 1 回インポートし、そのページに含まれる 2 番目のページでも同じ taglib をインポートする場合、無効な XML は次のようなブラウザ出力になります。 Error 500--Internal Server Error From RFC 2068 Hypertext Transfer Protocol -- HTTP/1.1: 10.5.1 500 Internal Server Error The server encountered an unexpected condition which prevented it from fulfilling the request. ログ ファイルの出力は次のようになります。 <[ServletContext(id=287644,name=jspVal.war,context-path=/jspVal)] Servlet failed withIOException java.io.IOException: javax.servlet.jsp.JspException: The taglib validator rejected the page: "Exception TestValidator XML parsing: org.xml.sax.SAXParseException: Attribute "xmlns:valtest" was already specified for element "jsp:root". -- stack trace written to stderr., "... weblogic.servlet.jsp.jsp2xml.Jsp2XmlOutputter のコードの変更により、JSP の XML 表示の生成中に、重複しているタグ プレフィックスは無視されます。
CR102769	サーブレットまたは JSP から別の JSP ページにリクエストを転送したときに、queryString が access.log に記録されませんでした。 また、access.log は転送されたリクエストは記録しましたが、元のリクエストは記録しませんでした。 RequestDispatcherImpl のコードを変更して問題を修正しました。
CR103289	HttpClusterServlet は POST データのセッション ID を正しく解析しませんでした。 HttpClusterServlet からクラスタにリクエストを送信して、セッションを確立し、クッキーなしで POST パラメータにセッション ID を含めて 2 番目のリクエストを送信すると、サーブレットはセッションを認識しません。 サーブレットは POST データからセッション ID を抽出できるようになりました。
CR103473	jspc のコマンドラインのコンパイルでパフォーマンスが改良されました。複数のコンパイラ プロセスではなく、1 つのコンパイラ プロセスが各 JSP に分岐されるようになりました。さらに、複数の JSP で使用される TLD は、JSP ごとではなく、すべての JSP で 1 回だけ解析されるようになりました。
CR105395	JSP がユーザ ログインなしで Security.getCurrentUser() を呼び出すと、次の例外が発生しました。 java.lang.NullPointerException at weblogic.security.acl.Security.getCurrentUser(Security.java:301) wlrealm null 設定を許可して例外を送出しないようにコードを変更しました。

JTA

変更要求番号	説明
CR088171	WebLogic Server 7.0 の以前のリリースでは、調整サーバがトランザクションの開始サーバでない場合にサーバによって開始されたトランザクションをコミットまたはロールバックすると予期しない例外が送出されていました。 コミットまたはロールバックの完了を待っている従属的な開始サーバは、予期しない例外 (たいていは調整サーバの再起動から生じる PeerGoneException) によって割り込まれ、トランザクションのステータスが「unknown」に変更されていました。 再起動した調整サーバは、トランザクションを適切に解決できませんでした。 コードの変更により、調整サーバで再起動後にトランザクションを適切に解決できるようになりました。
CR091628	javax.transaction.xa.XAResource インタフェースでは、メソッド setTransactionTimeout() が定義されています。このメソッドを使用すると、トランザクション マネージャは、XAResource インスタンスに関する操作のために、リソース マネージャにトランザクション タイムアウトを設定できます。 アプリケーションがグローバル トランザクションでリソース マネージャにアクセスするとき、WebLogic Server のトランザクション マネージャはこのメソッドを呼び出していませんでした。 以下のプロパティが、config.xml ファイルで JDBCConnectionPool オブジェクトに追加されています。 XASetTransactionTimeout-トランザクション マネージャが XAResource.start の呼び出し前に XAResource.setTransactionTimeout を呼び出すかどうかを指定します。 true または false を指定できます。 true に設定すると、トランザクション マネージャは秒単位のグローバル トランザクション タイムアウトをセッション タイムアウトとして Oracle に渡します。 false に設定すると、トランザクション マネージャは XAResource.setTransactionTimeout を呼び出しません。 このパラメータのデフォルト値は、false です。 XATransactionTimeout-XASetTransactionTimeout が true に設定されている場合に、XATransactionTimeout 値がセッション タイムアウトとして Oracle に渡されます (OpenString で SesTm を設定するのと同じ)。 このパラメータを 0 に設定すると、セッション タイムアウトが秒単位のグローバル トランザクション タイムアウトに設定されます。 このパラメータのデフォルト値は、0 です。 これらのパラメータは、XA JDBC ドライバを使用してデータベース接続を作成する接続プールでのみ有効です。非 XA JDBC ドライバを使用する接続プールでは無視されます。 これらのパラメータは、Administration Console では表示されません。
CR091882	WebLogic Server 7.0 の以前のリリースでは、トランザクションが複数の WebLogic Server インスタンスにまたがる場合に問題の発生するおそれがあります。一部のコンフィグレーションでは、トランザクションが余計な状態を積み重ねて完了までの時間が延び、トランザクションがタイムアウトになる場合があります。この問題は、コードの変更によって修正されました。
CR091925	WebLogic Server 7.0 の以前のリリースでは、例外が捕捉されない場合にクラスタ化された管理対象サーバの回復移行サービスで問題が発生するおそれがありました。 その結果、クラスタの他のメンバーが動作していない場合に管理対象サーバの起動が失敗する場合がありました。この問題は、コードの変更によって修正されました。
CR092301、CR107866	WebLogic Server 7.0 の以前のリリースでは、コンフィグレーションによっては、トランザクションの調整中に NullPointerException 例外が発生するおそれがあります。この問題は、コードの変更によって修正されました。
CR093406	WebLogic Server 7.0 では、サーバの再起動時のトランザクション回復処理が新しく検出されたリソースのために遅延していました。WebLogic Server 7.0 SP3 では、サーバによって検出されるとすぐにリソースでトランザクション回復処理が開始されます。
CR097013	サブコーディネータ サーバは、サーバの停止後に不明なトランザクションを自動的に回復せず、DBA による手動のロールバックまたはコミットが必要でした。 調査の結果、サブコーディネータのコードでは、サーバの再起動後にリモートの参加コンポーネントを追跡できないことがわかりました。リモートの参加コンポーネントを正しく追跡するために、コードにチェックポイントを追加しました。
CR098273	WebLogic Server 7.0 では、トランザクション ログの古いエントリが原因で、サーバの再起動時に不要な回復のオーバーヘッドが生じることがありました。この問題は、コードを修正して解決されました。
CR098318	WebLogic Server 7.0 SP1 では、トランザクションの古い状態が、誤ってリモート サーバにトランザクションの影響を及ぼす可能性のある専用の通信スレッドと関連付けられ、その結果として java.lang.IllegalStateException 例外が生成される場合があります。この問題は、コードの変更によって修正されました。
CR099554	WebLogic Server 7.0 SP1 では、環境によっては、JMS メッセージが保留状態にあるサーバが停止されるか、クラッシュした場合に、保留中のメッセージがサーバの再起動時に回復されません。この問題は、コードを修正して解決されました。
CR099830	JTA の移行は、トランザクションがクラスタ内の 2 つのサーバに伝播された後に NullPointerException または ConnectException で失敗する場合がありました。 NullPointerException <Feb 28, 2003 6:38:44 PM JST> <Warning> <JTA> <110213> <The activation of Transaction Recovery Service for server [serverB] fails. java.lang.NullPointerException at... ConnectException <2003/02/27 13:11:20:JST> <Warning> <JTA> <110213> <The activation of Transaction Recovery Service for server [server1] fails.> java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination at... 調査の結果、サーバが応答しないときの通知と、そのサーバの情報がキャッシュから削除されたときの通知でコードが競合状態を引き起こしていることが判明しました。 サーバが応答しないという通知がキャッシュのクリアの後である場合、もう一方の管理対象サーバは応答しない管理対象サーバの tlog の位置を探そうとしたときに NULLPointerException に遭遇します。 コードの修正で、この問題は解決されました。
CR100898	トランザクションがロールバックした場合、トランザクションに参加するリソースを持たないサーバがトランザクションに参加していると、トランザクションが完了しない場合がありました。 トランザクションは調整を行っているサーバ上に存在し続け、ロールバックするリソースがないことをサーバに通知する再試行を続けていました。 最終的に、トランザクションは破棄されました。すべての参加リソースがロールバックの通知を受けましたが、完了した後で、調整を行っているサーバ上でコールバックが処理されない場合がありました。 リソースを持たないサーバにも対応し、すべてのサーバ/リソースが通知を受けたら直ちに状態をロールバック済みに設定するよう、ロールバック非同期応答処理のロジックを変更することで、この問題は解決しました。
CR101135	トランザクション タイムアウト処理の過程で、準備されている各トランザクションについて、現在のサーバがそのトランザクションの従属参加コンポーネントである場合に、トランザクション マネージャはコーディネータに一方通行の RMI メッセージを送信してトランザクションのステータスを確認します。 コーディネータが再起動されている場合は、JTA サブシステムがトランザクション ログからコミット レコードの読み込みを終了する前に、このステータス要求がディスパッチされることがあります。 このケースでは、ステータス要求がディスパッチされ、トランザクション マネージャの確認されたトランザクションのマップにクエリ対象のトランザクション ID が存在するかどうかがチェックされていました。 tlog がまだ処理されていないので、コーディネータの再起動より前にトランザクションがコミット ポイントを過ぎていても、TM はロールバックの決定で従属参加コンポーネントに応答していました。 このシナリオでは、トランザクションの結果が混在していました。つまり、ステータス要求を行った従属参加コンポーネントのリソースはロールバックされ、トランザクションの他のリソースはコミットされます。 JTA サブシステムの初期化の前に checkStatus() リクエストが処理されないよう、コードが修正されました。これで、トランザクションの結果が混在しなくなります。
CR106174	トランザクションの 1 つを除いてすべての参加リソースが prepare コマンドに XA_RDONLY フラグで応答する場合に、トランザクション マネージャはコミット レコードを不必要に書き込んでいました。 コードを変更してこの問題を解決しました。ログ レコードを書き込む前に、サーバは第 2 フェーズを必要とする参加リソースの数をチェックするようになりました。数が 1 の場合、トランザクションはコミット レコードを生成しません。
CR106174	トランザクションの 1 つを除いてすべてのリソースが prepare に XA_RDONLY フラグで応答する場合、トランザクション マネージャは 1 フェーズ コミットを発行して参加リソースを保留しなければなりません。 ただし、このシナリオの場合、トランザクション マネージャはコミット レコードを不必要に書き込んでいました。 ログ レコードを書き込む前に、トランザクション マネージャが第 2 フェーズを必要とする参加リソースの数をチェックし、数が 1 の場合は書き込みがスキップされるようにコードを変更しました。その修正で、問題は解決されました。
CR106177	リモートの beforeCompletion コールバックを処理するときに、トランザクション マネージャは登録されたオブジェクトを呼び出す前にトランザクション コンテキストを再開していました。 静的に登録されたリソースは、トランザクションがスレッド上で再開されるときに取得されませんでした。そのため beforeCompletion ロジックはトランザクションの一部として追加の更新を実行できなくなりました。 トランザクション マネージャは静的に登録されたリソースを取得できるようになりました。
CR106177	リモートの beforeCompletion コールバックを処理するときに、TM は登録されたオブジェクトを呼び出す前にトランザクション コンテキストを再開します。ただし、静的に登録されたリソースは、トランザクションがスレッド上で再開されるときに取得されませんでした。 そのようなリソースの取得を実行して、beforeCompletion ロジックがトランザクションの一部として追加の更新を実行できるようにコードを変更しました。その修正で、問題は解決されました。

操作と管理

変更要求番号	説明
CR098464	LogManager で同期が使用される場合、スレッドでデッドロックが発生していました。 ある程度の同期をなくすことでこの問題は修正され、デッドロックは発生しなくなりました。Eliminating some synchronization in LogManager fixed the problem. There is no more deadlock.

プラグイン

変更要求番号	説明
CR096850	アプリケーション (負荷テスト中のアプリケーションを含む) から iPlanet サーバへの接続が複数回試行された後、サーバがクラッシュしなくなりました。
CR086224	NSAPI プラグインは POST データから SESSIONID を読み込みませんでした。 分析の結果 getPreferredServersFromCookie() の問題が判明しました。 POST データとして session.getId() が保持されるときに、getId() に余分な文字列 |time が含まれていました。 この問題は、コードを修正して解決されました。
CR091791	バックエンド サーバから新しい動的サーバ リストを受け取ると、Apache プラグインは keepAliveSecs を 0 にリセットしていました。 その結果、タイマがプールからすべての接続を削除していました。このため、事実上、接続プールは壊されていました。 コードの修正で、この問題は解消されました。
CR092484	クラスタで、動的サーバ リストが Apache プラグインによって不適切に解析されていました。 この問題は解決済みであり、サーバ リストは 5.1 までバージョンを遡って正しく解析されるようになっています。
CR092756	バックエンド WebLogic Server から HTTP 503 の応答を受け取っても、ISAPI プラグインがフェイルオーバしていませんでした。 コードの修正で、WebLogic Server から HTTP 503 の応答を受け取ったときにプラグインがフェイルオーバするようになりました。
CR093530	PathTrim の値は大文字と小文字が区別され、ISAPI プラグインでは大文字と小文字が区別されないようにする必要がありました。 コードの修正により、PathTrim 値で大文字と小文字が区別されないようになりました。
CR093595	長い URI および weblogichost の代わりに weblogiccluster を使用している場合に、Apache プラグインが予期せず停止していました。 コードの修正により、バッファ サイズが URI の長さの限界まで増やされ、それによって問題が解決されました。
CR094768	クッキーの POST の解析が、ISAPI プラグインで正しく実装されていませんでした。 ISAPI プラグインは現在は、content-type が application/x-www-form-urlencoded の場合のみ POST を解析します。
CR096625	X_WEBLOGIC_FORCE_JVMID ヘッダが、Apache プラグインによってクラスタ内のサーバ インスタンスに送信されていました。 X_WEBLOGIC_FORCE_JVMID は、サーバ リストがクラスタ化されていず、現在のサーバに jvmid がまだない場合以外は送信するべきではありません。 この問題は、コードを修正して解決されました。
CR097132	Apache プラグインを、Linux-IA64 用に作成する必要がありました。 バイナリ ファイルとライブラリが作成されており、新しいプラグインが入手可能になっています。
CR097202 CR103161	WebLogic Server とブラウザの間で 128 ビットのステップ アップ証明書を使用するプラグインを含むコンフィグレーションでは、WebLogic 側でブラウザの暗号強度を定義する必要がありました。ブラウザには、40 ビットまたは 128 ビットの強度がありました。ブラウザの暗号強度を取得するには、次のコードを使用していました。 (Integer)httpRequest.getAttribute("javax.servlet. request.key-size") ただし、ブラウザは 128 ビットより小さい暗号サイズを使うように設定されていましたが、返される値は常に 128 でした。 この問題は、HTTPS_KEYSIZE で接続の強度が指定されることが原因でした。128 ビットの証明書がプラグインでは使用されていたので、ブラウザで使用される強度に関係なく 128 が返されていました。リクエストが WebLogic Server に転送されると、ブラウザの強度に応じて 40 または 128 が返されました。 プラグインは、HTTPS_KEYSIZE ヘッダまたは HTTPS_SECRETKEYSIZE ヘッダを変更しません。 このニーズを満たすために、WL-Proxy-Client-Keysize および WL-Proxy-Client-Secretkeysize という 2 つの新しいヘッダが実装されました。 両方のヘッダの値とも、request.getHeader() で取得できます。
CR100361	READ_ERROR_FROM_CLIENT、READ_ERROR_FROM_SERVER、READ_ERROR_FROM_FILE、WRITE_ERROR_TO_FILE という新しい例外型が、NSAPI プラグイン用に追加されました。
CR101428	ISAPI プラグインの使用時、リクエストに複数のクッキーが含まれているときに、JSESSIONID という名前ではないが、JSESSIONID クッキーの直後にくるクッキーは取り除かれて、WebLogic Server に配信されませんでした。 この問題は、コードを修正して解決されました。
CR101596	ssl_certchain_verify_callback メソッドで、証明書の検証が失敗した事例のエラー条件として SSLNoErr が返されていました。 たとえば、CA 証明書が critical とマークされていない基本的な制約を持ち、(デフォルトの「strong」ではなく) strict 設定が有効になっている事例や、証明書が CA としてマークされていない事例などがあります。 この問題は、このような失敗の事例で (SSLNoErr ではなく) X509CertChainInvalidErr を返すことで解決されました。
CR102616	NSAPI プラグインは、名前が DNS サーバからの IP アドレスのリストを返し、プラグインが WebLogicHost = 'DNS name' でコンフィグレーションされる場合に、DNS 名に対する動的な DNS ルックアップをサポートするようになりました。

RMI/RMI-IIOP

変更要求番号	説明
CR108317	一部のアクセサは、ejbc 生成の IDL (Interface-Definition-Language) で正しくマッピングされていませんでした。 この問題は解決済みです。
CR090979	また別のサーバにアクセスするサーバにアクセスするクライアントでプリンシパルと資格を設定した場合に、プリンシパルのサーバ間の資格伝播が適切ではありませんでした。 コードの修正により、適切な資格伝播が行われるようになりました。
CR090987	WebLogic は、サーバから ROID を取得してそれをクライアントに返すことに失敗し、次の例外を送出していました。 java.rmi.UnmarshalException: failed to unmarshal class weblogic.cluster.replication.ROID; nested exception is: java.rmi.UnmarshalException: null; nested exception is: org.omg.CORBA.MARSHAL vmcid: 0x0 minor code: 0 completed: No コードの修正により、クラスは正しくマーシャリングされます。
CR093107	CosNaming で使用されるクラスタ化された参照に実際の参照が 1 つ含まれており、IIOP のフェイルオーバ処理が JNDI レベルで正しく機能しなくなっています。 参照が JNDI にバインドされていませんでした。 コードを修正してこの問題を解決しました。
CR093561	コードの修正で、クラスタ対応オブジェクトの置換が改善されました。
CR094795	ファット クライアントはステートレス EJB に接続して、Vector を拡張するクラスを返すメソッドを呼び出します。Vector を拡張するクラスは、その独自のシリアライゼーションを使用してシリアライゼーションの最適化を向上させます。 ファット クライアントは、この Vector クラスの内容を表示します。RMI-IIOP がプロトコルとして使用される場合、Vector は空です。 分析の結果、writeReplace の呼び出しが遅すぎることが判明しました。 リポジトリ ID がすでに書き込まれているので、解決すべきクラスではなく実際のクラスが読み込まれていました。 コードの修正により、Externalizable クラスで writeReplace が正しく呼び出されます。
CR096476	MBean プロパティ Server.IIOP.IdleConnectionTimeout は、接続が閉じるまでにアイドル状態でいられる時間をコンフィグレーションします。 WebLogic Server には、同様のクライアントサイド プロパティがありませんでした。 コードの修正により、アイドル状態のタイムアウトと保留のタイムアウトが実装されました。保留のタイムアウトは、DGC の期間の長さと数で管理します。 アイドル時間のタイムアウトを 100 秒 (デフォルトは 240 秒) に設定するには、次のようにします。 -Dweblogic.iiop.IdleConnectionTimeout=100 保留のタイムアウトを 5 分 (デフォルトは 60 秒) に設定するには、次のようにします。 -Dweblogic.DGCIdlePeriodsUntilTimeout=5 期間の長さを設定するには、次のようにします。 -Dweblogic.PeriodLength=120000 (for 120 s) 接続は、その接続のアイドル期間が経過していない場合にタイムアウトになります。保留のタイムアウトは常にアイドル状態のタイムアウトより長いものと想定されます。保留のタイムアウトは、すでに応答を待っている発信接続で使用します。
CR098713	WebLogic Server は IIOP valuetype の発信チャンキングをサポートしていません。つまり、Externalizable クラスへの変更をサポートしていませんでした。 コードの修正により、発信チャンキングのサポートが実装されました。
CR099693	7.0 (G.A.、SP01、および SP02) では、クライアントが t3 プロトコルを使用してファイアウォールから WebLogic Server にアクセスすると、サーバは初期化されていない接続上でメッセージをルーティングしようとするため、クライアントはエラーを受け取りました。 サーバの ExternalDNSName が指定されました。 初期接続時に、クライアントはサーバ インスタンスの ExternalDNSName へリクエストを送信しました。 サーバ インスタンスからの応答にある JVMID は、サーバの内部 IP アドレスと内部 DNS 名を必要としています。クライアントからの以降のリクエストは認識されませんでした。 コードの修正で、この問題は解決されました。
CR100480	コードの修正によって、複数のスレッドで競合する認証が実行されている場合に、IIOP クライアントのコンテキスト ID (シンクライアントを含む) が正しく維持されるようになりました。
CR100831	クライアントがあるクラスタ内のサーバ上にあり、別のクラスタ内のサーバのレプリカ対応スタブを使用している場合、ローカル サーバはレプリカ リストに載ることができず、そのために優先ホストが無視されていました。 この問題は、ローカル アフィニティ (リモート クラスタの呼び出し時に取得されない) をチェックするようにコードを修正することで解決されました。ローカル アフィニティを取得できない場合は、優先ホストがレプリカ リストと照合されます。 レプリカ リストに一致がない場合にのみ、ホストはロード バランシング アルゴリズムを使用してリストから選択されることになります。
CR101186	バグが原因で、IIOP 経由での例外の相互運用性が実現されていませんでした。 具体的には、JDK 1.4.x で動作するサーバ (つまり 8.1) で送出された例外が、JDK 1.3.1 で動作する 7.0.x サーバで理解できていませんでした。 これは、MARSHAL 例外です。 2 つのバグがありました。1 つはシーケンスの処理に、もう 1 つはクラスが FVD (FullValueDescription) で記述される方法にありました。現在は、IIOP 経由で例外の相互運用性が実現されています。
CR107137	CORBA および IIOP を介したクライアント/サーバ アクセスで、マーシャリング エラーとインダイレクション エラーが生成されました。 コードを変更して、インダイレクション中の hashCodes の生成を修正しました。IndirectionWrapper についても修正しました。

セキュリティ

変更要求番号	説明
CR080488、CR091569	ユーザ/グループ管理のセキュリティ サービス プログラミング インタフェース (SSPI) をサポートするサンプル カスタム認証プロバイダが、dev2dev のサンプル セキュリティ プロバイダのコード例に含まれていました。また、カスタム監査プロバイダもコード例に追加されました。 詳細については、http://dev2dev/codelibrary/code/security_prov81.jsp を参照してください。
CR084874	2 つの信頼性のあるドメインの中で、Java クライアントがドメイン 1 のサーバ 1 のステートレス セッション Bean 1 を呼び出します。この Bean は、ドメイン 2 のサーバ 2 のステートレス セッション Bean 2 を呼び出します。 最初のサーバを呼び出すユーザは、ロール Admin (デフォルト) を持つグループ Administrators のユーザ system です。 Bean 1 から Bean 2 への呼び出しで t3 プロトコルが使用されている場合、プリンシパルは適切に伝播されていました。 Bean 1 から Bean 2 への呼び出しが IIOP 呼び出しで、ロール Admin をユーザ system にマッピングするセキュリティ ロールの割り当てが weblogic-ejb-jar.xml にある場合、プリンシパルは適切に伝播されていました。 ただし、Bean 1 から Bean 2 への呼び出しが IIOP 呼び出しで、セキュリティ ロールの割り当てでロール Admin がグループ Administrators にマッピングされている場合は、org.omg.CORBA.NO_PERMISSION エラーが発生していました。 プリンシパルの伝播は、現在はあらゆる状況で適切に行われます。
CR085094	1 つの管理サーバと 1 つの管理対象サーバを含むドメインを作成した後で、2 つのサーバに対して -Djava.security.manager を有効にすると java.io.Filepermissions エラーが返されて、AdminServer ログで <Error> <EmbeddedLDAP> <000000> <Error parsing Entry #19: access denied (java.io.FilePermission .¥myserver¥ldap¥ldapfiles¥EmbeddedLDAP.data read)> と報告されました。 この問題は、weblogic.policy ファイルを更新することで解決されました。ファイルには、ユーザ アプリケーションへのパーミッションの付与に関する情報と、grant 文のサンプルが追加されました。 weblogic.policy は Weblogic Server Examples、Pet Store、および Workshop に対して機能します。ユーザ コンフィグレーションで使用するには、変更が必要になります。手順はファイル上部のコメントに示されています。
CR090101	WebLogic Server は証明書チェーンの各証明書が認証局によって発行されたことを保証しませんでした。この問題は、誰かが信頼性のある認証局から個人用証明書を取得し、その証明書を使用して他の証明書を発行しても、WebLogic Server は無効な証明書を検出できないことを意味しました。このリリースでは、WebLogic Server で使用するすべての X509 V3 CA 証明書は CA として定義される基本制約拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが保証されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。証明書検証に合格しない証明書チェーンを持つ WebLogic Server が起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録されます。 詳細については、「SSL 証明書検証」を参照してください。
CR090147	Active Directory LDAP 認証プロバイダを使用している場合に、ユーザの検索フィルタがユーザ名での「¥」の使用をサポートしていませんでした。 LDAPv3 の属性構文の定義の仕様では、ユーザ検索フィルタでの「¥」の使用がサポートされています。「¥」の使用がサポートされるように、ユーザ検索フィルタのコードが更新されています。
CR090218	メソッド getCurrentUser と getCurrentSubject は、現在のスレッドに関連付けられたユーザのユーザ ID を返します。 WebLogic Server 7.0 の以前のサービス パックでは、RequestDispatcher.forward を使用してあるサーブレットから別のサーブレットに転送した場合、これらのメソッドは null (または空の文字列) を返しました。 1 つの JSP またはサーブレットから別の JSP またはサーブレットへ転送されるリクエストが、セッションで認証されたユーザを送信するようにコードを修正して、この問題を解決しました。
CR091972	WebLogic Server の以前のリリースでは、SSL のライセンス チェックで 128 ビットとライセンスを使用した IP アドレスが必要とされていました。ライセンス チェックの元々の目的は以下のようなものでした。 WebLogic Server の実行時を除いて、顧客が Certicom SSL ランタイムを使用できないようにするため。これは、BEA System が Certicom と結んだ契約の 1 つの条件でした。 SSL が使用できる強度を決めるため (国内または輸出)。これは政府の規制でした。 BEA では、サーバ上で動作していない Java クライアントがサーバから Java クライアント マシンにライセンスをコピーすることを推奨していました。しかし、SSL コードのライセンス チェックの実装は IP の検証を要求していました。このため、サーバの SSL ライセンスはクライアント マシンで使用することができませんでした。ライセンス チェックの IP 検証は現在は廃止になっています。現在は、ライセンスをサーバから Java クライアント マシンにコピーすることができます。
CR092236	Active Directory LDAP 認証プロバイダを使用している場合に、ユーザ検索フィルタがユーザ名での自然言語文字の使用をサポートしていませんでした。 LDAPv3 の属性構文の定義の仕様では、ユーザ検索フィルタでの自然言語文字の使用がサポートされています。 自然言語文字の使用がサポートされるように、ユーザ検索フィルタのコードが更新されています。
CR093533	互換性レルムのレルム アダプタ認証プロバイダは、ユニークな ID で User オブジェクトを作成するのではなく、User オブジェクトの認証済みユーザ名を使用していました。 この問題により、単純認証 (ユーザ名とパスワード) を実行するカスタム セキュリティ レルムとの下位互換性が壊されていました。 レルム アダプタ認証プロバイダのコードが、ユニークな ID で User オブジェクトが作成されるように修正されています。
CR093813	ノード マネージャ キー ファイル weblogic.nodemanager.keyPassword の暗号化されたプライベート キーにアクセスするために使用するパスワードが、プレーン テキストでアクセス可能なものでした。 ノード マネージャ プロパティ ファイル nodemanager.properties を作成して、問題を解決しました。
CR094038	WebLogic Security フレームワーク内のリソース エンジンで、階層キャッシングの最適化が廃止されています。リソース キャッシュは、リソースをキーとして使用するように更新されています。 キャッシュは、各キャッシュ ヒットで resource.equals() を実行して、ハッシュ コードの衝突を防止するようになりました。リソースの文字列表現と親がリソースにキャッシュされるので、階層がキャッシュされた後は、キャッシュを 1 回ルックアップするだけで、リソースのパス名を取得できます。この変更で、WebLogic Server のパフォーマンスが向上します。
CR094215	weblogic.security.ntrealm.NTRealm username password を呼び出すと、常に例外が送出されていました。この問題は解決済みです。
CR094548	WebLogic Server 7.0 の以前のバージョンでは、2 つのグループがネストされていることを WebLogic Server に認識させるには、LDAP 内のグループを互いに明示的に追加する必要がありました。LDAP ツリー内でグループを別のグループに追加して暗黙的なネストを行うと、認識されませんでした。 階層によるグループ メンバーシップ チェックを実行するように LDAP プロバイダを変更して、この問題を解決しました。次のようにプロパティを設定します。 -Dweblogic.security.hierarchyGroupMemberships="true"
CR095689	双方向 SSL と weblogic.servlet.security.ServletAuthentication.strong() メソッドを使用すると、例外が発生していました。 サーブレット コードの認証部分の import が、サーブレット仕様で定義されている java.security.cert.X509Certificate ではなく javax.security.cert.X509Certificate を使用していました。 サーブレットのコードでは、java.security.cert.X509Certificate が使用されるようになりました。
CR095789	ユーザが非常に多いグループを扱うときに、LDAP レルム v2 のパフォーマンスが低下していました。この問題が原因で、WebLogic Portal サーバがハングしてタイムアウトになる可能性がありました。この問題は、次のメソッドの呼び出しに関連していました。 netscape.ldap.LDAPMessageQueue.waitForMessage (LDAPMessageQueue.java:179) 具体的には、groupDN の多くのグループが LDAP レルム v2 で検索されており、それらすべてのグループで Group.isMember メソッドが連続して呼び出された場合にその呼び出しがハングします。通常、サーバは数百の呼び出しが連続して行われた後にハングします。 LDAP レルム v2 のコードがこの問題を解決するために更新されており、ユーザの多いグループを扱うときにパフォーマンスが向上しています。
CR095836	Administration Console の [ドメイン｜Domain Wide Security Settings｜組み込み LDAP] で、バックアップ分数のデフォルト値が正しく計算されて報告されるようになりました。
CR096488	RDBMS セキュリティ レルムを使用する 6.1 セキュリティ コンフィグレーションを使用すると、サーバが (したがって互換性セキュリティも同様に) 起動しません。 1. RDBMS レルムの config.xml エントリでは、RealmClassName、DatabaseDriver、および DatabaseURL 属性を明示的に示す必要があります。6.x で RDBMS セキュリティ レルムを使用する場合、それらの値は RDBMS コード サンプルとサンプル データベースが使用されているものと想定していました。 2. WebLogic Server バージョン 7.0 で使用するためには、HimselfAAA のコードを再コンパイルする必要があります。WebLogic Server 6.x では、RDBMS コード サンプルでプライベートな Admin API がエクスポーズされていました。この問題は確認済みです。 詳細については、「セキュリティのアップグレード」を参照してください。 3. セキュリティ レルムをロードする Weblogic Server のコードは、RealmClassName 属性が空である場合の適切な対処を行っていませんでした。このコードはすでに更新されており、レルム クラス名を指定する必要があることを明確に示す例外が送出されます。
CR096589	weblogic.servlet.security.ServletAuthentication.strong() はクラス キャスト例外により失敗しました。 調査の結果、間違った証明書クラスをインポートしていたことがわかりました。コードの修正で、この問題は解決されました。
CR096934	WebLogicBeanMaker は AuthenticationMBI クラス コンストラクタによって生成された例外を認識していなかったため、AuthenticationProvider の構築でエラーが認識されませんでした。 エラーの伝播を確実にするようにコードを変更して、問題を解決しました。
CR098083	WebLogic Server の過去のリリースでは、有効性を証明できないパスワードを受信したときに WebLogic 資格マッピングから通知が出されていませんでした。この問題は解決済みです。WebLogic 資格マッピング プロバイダは、有効性を証明できない暗号化パスワードを受信したときに例外を送出するようになりました。
CR098084	WebLogic Server の過去のリリースでは、WebLogic 資格マッピング プロバイダによって組み込み LDAP サーバに格納されたパスワードがクリア テキストでした。WebLogic 資格マッピング プロバイダは、組み込み LDAP サーバに格納するときにパスワードを暗号化するようになりました。
CR098242	ノード マネージャでは、ユーザの認可レベルに関係なく、クリアされたユーザ名とパスワードが提供されるため、管理対象サーバを認可なしで起動することができました。 ノード マネージャはユーザに対するセキュリティ チェックを実行するようになりました。
CR100174	Bouncy Castle JCE プロバイダは 7.0 SP3 より前ではテストされておらず、SSL と一緒に機能するには特別なコードが必要です。このリリースでは、BouncyCastle プロバイダ JCE がプラグインされた時点で検出し、代わりに内部の暗号化方式を使用するように処理するコードを SSL に追加しました。サーバサイド アプリケーションで BouncyCastle JCE プロバイダを使用しても、例外が発生しなくなりました。プラグインされても SSL はそのプロバイダを使用しませんが、例外は発生しません。
CR100592	サポートされている LDAP サーバの 1 つでユーザ アカウントが無効になった場合 (たとえばアカウントが長い期間無効になっているか、障害が原因でロックされている場合)、LDAP セキュリティ レルムからそのアカウント (ユーザ名/パスワード) を使用するためには、サーバを再起動する必要があります。次の例外が送出されました。 <[WebAppServletContext(2052089,WebCM-Outages,/Webbed-Outages)] Servlet failed with Exception netscape.ldap.LDAPException この問題は解決済みです。
CR100762	WebLogic Server の以前のリリースでは、実行時に SunJCE プロバイダをアンロードするコードがまだ使用されていました。この問題により、SSL プロトコルがサーバ インスタンスで有効になっている場合に WebLogic Server で Sun JCE プロバイダを使用することができませんでした。 この問題は解決済みです。 JDK 1.4 クライアントと Sun JCE を使用している顧客は、JDK 1.4 JCE の実装のパフォーマンスの問題に起因するパフォーマンスの低下を経験する場合があります。 クライアントが Sun JCE プロバイダを必要としない場合は、次のように JDK/re/lib/security/java.security ファイルから Syncs プロバイダをコメントアウトします。 security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.net.ssl.internal.ssl.Provider security.provider.3=com.sun.rsajca.Provider #security.provider.4=com.sun.crypto.provider.SunJCE #security.provider.5=sun.security.jgss.SunProvider
CR100797	WebLogic Server のデフォルト接続フィルタが HTTPS プロトコルを適切に処理していませんでした。この問題は解決済みです。
CR101652	WebLogic Server の以前のリリースでは、XML サーバが SSL プロトコルをサポートしていなかったのでサードパーティ XML サーバとのセキュアな接続を確立できませんでした。 次の回避策を利用できます。 1. WebLogic クライアント (WebLogic Server にデプロイされた JavaServer Page (JSP)) を作成します。 2. Java の仕様に従って Java 認証局クラスを作成します。この認証局は、XML サーバに接続するために使用する名字とパスワードを取得する必要があります。 3. weblogic.policy ファイルで Java 認証局クラスのネット パーミッションを指定します。ネット パーミッションは、Java VM のすべてのユーザに与えられます。これで潜在的なセキュリティの弱さが生じるので、慎重に使用する必要があります。 4. java.net.HttpConnection を使用して、XML サーバとの接続を確立します。 5. WebLogic Server の起動時に -DUseSunHttpHandler をコマンドライン引数として指定します。
CR102351	Eracom および Entrust サード パーティ セキュリティ プロバイダはこのリリースで動作確認されました。
CR102351	7.0 SP2 では SSL 暗号化処理に JCE プロバイダを使用できるようになりました。 ただし、すべての JCE プロバイダが同じように機能するわけではありません。各プロバイダでは、特別な処理と予測が必要です。 ERACOM/Entrust JCE プロバイダが SSL と共に機能するには、特別なコードが必要です。 コードを SSL に追加して、ERACOM/Entrust プロバイダがプラグインされた時点で検出し、内部の暗号化方式を使用するようにしました。ERACOM/Entrust JCE プロバイダはサーバサイド アプリケーションで機能するようになりました。
CR105809	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-33.jsp のセキュリティ勧告に関する情報を確認してください。
CR106027	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.01.jsp のセキュリティ勧告に関する情報を確認してください。
CR106357	複数の認可プロバイダをインストールした場合、Web アプリケーションに対してポリシーを定義できませんでした。 この問題は修正済みです。

システム管理

変更要求番号	説明
CR063279	WebLogic Server の config.xml 内の複数の要素に同じオブジェクト名がある場合、後の方の要素が前の要素のコンフィグレーションを上書きします。これは通知されずに行われていました。WebLogic Server は標準出力にエラー メッセージ (ID=150012) を送出するようになりました。
CR082422	Unix では、新しくデプロイされたファイルは、ルート ディレクトリに移動してからそのファイルの親ディレクトリに移動しない限り、ファイル リストまたはディレクトリ リストに表示されませんでした。 file_chooser.jsp のコードを変更して、この問題を解決しました。
CR091205	WebLogic Server SNMP MIB では、applicationRuntimeIndex と cacheMonitorRuntimeIndex で OID (1.3.6.1.4.1.140.625.105.1.1) が重複していました。 cacheMonitorRuntime は現在はユニークな OID (1.3.6.1.4.1.140.625.10) を使用しています。
CR091224	EJBComponentRuntimeMBean.getEJBRuntimes() を呼び出すと、ASSERTION FAILED エラーに続いて ArrayStoreException が生じる問題が修正されました。
CR092877	削除された管理対象サーバの ServerLifecycleRuntimeMBean と ServerConfigMBeans は、管理サーバが再起動されるまで存在し続けました。 管理対象サーバを削除するとこれらの MBean が削除されるようになりました。
CR092946	SNMP を使用し、管理サーバを起動するときに次の例外が発生するバグを修正しました。 java.lang.ClassNotFoundException: weblogic.management.snmp.agent.VirtualHost
CR093481	WebLogic Server の起動時に weblogic.Domain と weblogic.apache.xerces.maxentityrefs が両方とも設定される場合に不要なエラー メッセージを表示していた問題が修正されました。
CR093816	動的 MBean の使用時に NPE を生じさせる問題が修正されました。
CR093824	ドメイン全体の管理ポートを使用している場合に次の例外を生じさせていた、管理サーバの再起動時の問題が修正されました。 この例外はドメイン全体の管理ポートが使用されていない場合には発生せず、ドメインが最初に起動されるときにも例外は送出されませんでした。 <Emergency> <Configuration Management> <150009> <Errors detected attempting to connect to admin server ...
CR094966	管理対象サーバが動作している状態で管理サーバを再起動させた後に、アプリケーションのデプロイメントを失敗させていた問題が修正されました。
CR096544	HP-UX で、WebLogic Server の以前のバージョンから 7.0 に以降するときに、OutOfMemory エラーで失敗することがありました。 この問題は、Ant スクリプト内にハードコード化された JDK への参照によって発生しました。 参照を変数に置き換えて、問題を修正しました。
CR096726	MBeanHome.deleteMBean() の呼び出し時に NPE を生じさせていた問題が修正されました。
CR097071	システム管理サブシステムの SUID の非互換性が修正されました。
CR099002	T3S プロトコル用のバインディングが新しく実装されました。
CR099474	RequiredModelMBean の getAttributes() は、javax.management.Attribute オブジェクトを含む javax.management.AttributeList を返しますが、WebLogic Server 7.0 の JMX 実装では、RequiredModelMBean によって返される AttributeList には、javax.management.Attribute オブジェクトとしてではなく、MBean 属性の値が直接含まれていて、次の例外が発生しました。 java.lang.ClassCastException: java.lang.String at weblogic.management.internal.RemoteMBeanServerImpl.getAttributes(RemoteMBeanServerImpl.java:210) at weblogic.management.internal.RemoteMBeanServerImpl_WebLogic Serverkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:362) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:313) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:821) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:308) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest.java:30) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189)End server side stack trace at com.adventnet.beasupport.client.JMXConverter.convertInvocationTargetException(JMXConverter.java:744) at com.adventnet.beasupport.client.ProxyMBeanServer.getAttributes(ProxyMBeanServer.java:511) at com.adventnet.beasupport.client.WebLogicClient.getAttributes(WebLogicClient.java:593) at com.adventnet.beasupport.client.WebLogicClient.cmdline(WebLogicClient.java:1279) at com.adventnet.beasupport.client.WebLogicClient.access$000(WebLogicClient.java:15) at com.adventnet.beasupport.client.WebLogicClient$2.run(WebLogicClient.java:1293) GetAttributes メソッドは Attribute オブジェクトを返すようになりました。
CR100756	weblogic.Admin ユーティリティから JMSServer の Store プロパティを次のように設定すると、 java weblogic.Admin -url t3://localhost:7001 -username system -password weblogic SET -mbean examples:Name=examplesJMSServer,Type=JMSServer -property Store examples:Name=examplesJMSFileStore,Type=JMSStore 次の例外が送出されました。 <Mar 10, 2003 3:32:15 PM EST> <Error> <Management> <141033> <Error importing MBean examples:Name=examplesJMSFileStore,Type=JMSStore to server examplesServer.javax.management.InstanceNotFoundException: examples:Name=examplesJMSFileStore,Type=JMSStore コンフィグレーション MBean の WebLogicObjectName の属性を設定するときにチェックすることで、この問題は部分的に修正されました。 コードでは、Bean が有効なものかどうかをチェックして、InvalidAttributeValueException を送出します。 これは管理サーバのログに記録され、JMSServer は使用可能なままですが、ファイル ストアは設定されません。
CR101738	管理対象サーバは次のスタック トレースにより失敗しました。 java.rmi.ConnectException: This RJVM has already been shutdown -1425673232662082784S:WebLogic ServerDEBUG1:[53101,53101,53102,53102,53101,53102,-1]:WebLogic Servere1:ADMIN Start server side stack trace: java.rmi.ConnectException: This RJVM has already been shutdown -1425673232662082784S:WebLogic ServerDEBUG1:[53101,53101,53102,53102,53101,53102,-1]:WebLogic Servere1:ADMIN at weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java(Compiled Code)) at weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java(Compiled Code)) at weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java(Compiled Code)) at weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java(Compiled Code)) at weblogic.management.internal.AdminMBeanHomeImpl_WebLogic Servertub.getMBean(Unknown Source) at weblogic.management.deploy.slave.SlaveDeployer.getTargetVirtualHosts(SlaveDeployer.java(Compiled Code)) at weblogic.management.deploy.slave.SlaveDeployer.getCompsFromTask(SlaveDeployer.java(Compiled Code)) at weblogic.management.deploy.slave.SlaveDeployer.processRemoveOrDeactivate(SlaveDeployer.java:1240) at weblogic.management.deploy.slave.SlaveDeployer.commitUpdate(SlaveDeployer.java:1533) at weblogic.drs.internal.SlaveCallbackHandler$2.execute(SlaveCallbackHandler.java:34) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java(Compiled Code)) at.. 調査の結果、管理対象サーバ上で動作するアプリケーション スレーブ デプロイヤは、初期化されたときに、管理サーバの Admin MBeanHome をルックアップしてキャッシュし、使用していたことがわかりました。 管理サーバの Admin MBeanHome を、スレーブ デプロイヤの初期化時にキャッシュするのではなく、必要なときにルックアップするようにコードを変更しました。その修正で、問題は解決されました。
CR101856	クラスタに 1 つの管理サーバと 2 つの管理対象サーバが含まれていました。 Application1.ear に EJB と Web アプリケーションが含まれていました。EJB はクラスタにデプロイされ、Web アプリケーションは仮想ホストにデプロイされて、その仮想ホストはクラスタに割り当てられていました。 Application1.ear には、仮想ホストのデフォルト Web アプリケーションとしてコンフィグレーションされた Application1.war が含まれていました。さらに、各クラスタ ノードには独自のデフォルト Web アプリケーションがありました。 Application1.ear をアンデプロイすると、次の例外が発生しました。 deactivating application application1 on server2 deactivating application application1 on server1 deactivated application application1 on server2 unpreparing application application1 on server2 deactivated application application1 on server1 unpreparing application application1 on server1 failed application application1 on server2 failed application application1 on server1 Exception caught for task Unprepare application application1 on mycluster,application1: Start server side stack trace: java.lang.reflect.UndeclaredThrowableException: java.lang.reflect.InvocationTargetException: javax.management.ListenerNotFoundException: listener: ServletContext(id=559103557,name=DefaultWebApp,context-path=) アプリケーションは、ドメイン全体を再起動しても再デプロイできませんでした。 調査の結果、Application Mbean unstageTargets() メソッドが、仮想ホストのアンステージングで不正なインデックスを使用していることがわかりました。 コードの修正で、この問題は解決されました。
CR102149	Solaris 上で、トランザクション セッションで同期的に 21,000 の永続化されたメッセージを受信すると、WebLogic Server インスタンスは OutOfMemoryError になりました。 解放される長いリストを再要求するときに、ガベージ コレクタの速度が低下しました。リンクされたリストを分割して、問題を修正しました。
CR105736	7.0 で SessionID のフォーマットが変更されたため、Cisco Loadbalancer などの一部のロードバランシング アプリケーションはセッションの維持を使用できなくなりました。 新しいサーバ起動フラグ -Dweblogic.servlet.useExtendedSessionFormat=true によって、ロードバランシング アプリケーションでセッションの維持に必要な情報を保持します。
CR105777	RemoteException が迅速なキャッシングの valuetype として扱われないため、例外の伝播が正しく機能しませんでした。 実際の valuetype のみをキャッシュすることで問題を修正しました。
CR105831	展開された Web アプリケーションが docroot からクラスをロードできました。 この不適切なクラスロードの動作は無効になりました。
CR106198	GroupReaderMBean で、メンバー名にカンマが含まれているときに isMember が失敗しました。 カンマを含むメンバー名を許可するようにコードを変更して、この問題を解決しました。
CR106687	Examples サーバ上のリンクがローカル ファイルを指している場合、ユーザがリモートのブラウザからそのリンクにアクセスしても機能しません。 リモート ユーザがサンプルのドキュメントを参照できるように、examplesWebApp の weblogic.xml に virtual-mapping を追加して、問題を修正しました。 アクティブ化するには、<virtual-directory-mapping> の <local-path> 値をサンプルのインストール場所 (d:/bea/weblogic/samples/server/src など) で置き換えて、weblogic.xml の virtual-mapping を正しくコンフィグレーションします。
CR107043	bootclasspath に weblogic.jar を指定して WebLogic Server で t3 接続を確立すると、次の例外が発生しました。 java.lang.NullPointerException at weblogic.rmi.internal.StubGenerator.getStubClass(StubGenerator.java:632) at weblogic.rmi.internal.StubGenerator.generateStub(StubGenerator.java:656) at weblogic.rmi.internal.StubGenerator.generateStub(StubGenerator.java:651) at weblogic.rmi.extensions.StubFactory.getStub(StubFactory.java:59) at weblogic.jndi.WLInitialContextFactoryDelegate.newRootNamingNodeStub(WLInitialContextFactoryDelegate.java:489) at weblogic.jndi.WLInitialContextFactoryDelegate.newRemoteContext(WLInitialContextFactoryDelegate.java:452) at weblogic.jndi.WLInitialContextFactoryDelegate.newContext(WLInitialContextFactoryDelegate.java:372) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:339) at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:221) at weblogic.jndi.WLInitialContextFactory.getInitialContext(WLInitialContextFactory.java:149) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:671) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:242) at javax.naming.InitialContext.init(InitialContext.java:218) スタブの生成に引数として指定できるクラスローダを使用するようにコードを変更して、問題を修正しました。

ツール

変更要求番号	説明
CR074714	WebLogic Builder の [WebLogic 設定] パネルで、RAR の [増加容量] が [最大容量] と [初期容量] の差より大きい場合に、WebLogic Builder は RAR のロードに失敗し、「weblogic.xml.process.: capacity-increment should be less than or equal to ( max_capacity-initial_capacity)」で始まる SAXProcessorException を出力していました。 コードを変更してこの問題を解決しました。
CR072039	[EJB Relations] パネルに示された関連が、名前のアルファベット順にソートされるようになりました。
CR073975	メソッド名とトランザクション属性が、新しいメソッドを作成する上で必須の情報になりました。
CR074198	Bean クラスのメソッドが、[Add method] ダイアログの [Method name] 選択リストに表示されなくなりました。ホーム、ローカル ホーム、リモート インタフェース、およびローカル インタフェースのメソッドは表示されます。
CR074591	デプロイメント ダイアログは、事前に更新しなくても、失敗したデプロイメントのステータスが正確に表示されるようになりました。
CR075935	エンティティ Bean の [詳細設定] パネルでは、選択リストに、コンテナ管理の永続性エンティティ Bean が修正されたときに無効化できるすべての読み込み専用エンティティ Bean が表示されていませんでした。現在は、そのような Bean がすべてリストに表示されます。
CR078807	デプロイメント記述子で参照されるクラスをコンパイルせずにプロジェクトを開くと、Builder から誤った AssertionError が送出されていました。現在は、クラスが見つからないことを通知する警告がユーザに示されます。
CR081472	WebLogic Builder で、ローカル インタフェースを持たない Bean に誤って JNDI 名が割り当てられることがなくなりました。
CR082276	WebLogic Builder の検証ユーティリティが、アーカイブされたモジュールではなく展開されたモジュールで更新されたクラス ファイルを検出します。Builder は、プロジェクトを閉じて再び開いたときにアーカイブされたモジュールと展開されたモジュールの両方で更新されたクラス ファイルを検出します。
CR085188	プロジェクトからすべての CMP フィールドを削除すると、Builder によって weblogic-rdbms-cmp-jar.xml が壊される場合があります。プロジェクトからすべての CMP フィールドを削除しようとすると、警告が表示されます。
CR085270	Builder の関連の追加ウィザード、ファインダの追加ウィザード、および CMP の追加ウィザードで、関係の作成を中断またはキャンセルできるようになりました。
CR088145	Builder で、無効な CMP ノードがアクティブになったときに警告が表示されるようになりました。
CR091665	以前のリリースでは、Bean の [CMP Fields] ノードで行を追加し、その後にテーブル ビューでそれを削除すると、AssertionError が送出されていました。この問題は、Builder のユーザ インタフェースで不完全に定義されたプロパティが原因でしたが、現在は修正されています。
CR091720	CMP Bean と同様に、BMP Bean でも詳細設定パネルが表示されるようになりました。
CR093246	新しいデプロイメント記述子要素 <allow-remove-during-transaction> が weblogic-ejb-jar.xml デプロイメント記述子に追加されました。 このタグはステートフル セッション Bean 用に追加されたものであり、<stateful-session-descriptor> タグの子です。ただし、WebLogic Builder で表示されることはありません。 この問題は、WebLogic Builder のセッションの [詳細設定] パネルに [Allow remove during transaction] チェック ボックスを追加することで解決されました。
CR093579	weblogic.Deployer を使用して、Deployers グループのユーザとしてクラスタにアプリケーションをデプロイすると、アプリケーションはデプロイされますが、次の例外が発生しました。 weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[velvet, Deployers], on ResourceType: Cluster Action: execute, Target: addDeployment at weblogic.management.internal.Helper$IsAccessAllowedPrivilegeAction.run(Helper.java:2034) クラスタのデプロイメントに対する ACL を追加して問題を修正しました。
CR093658	VirtualHostMBean の getLogFileName を呼び出すと、不正なパスが返されました。
CR093833	weblogic.Deployer を使用して、サーバを指定しないで管理対象サーバに再デプロイすると、アプリケーションは管理サーバにデプロイされました。 weblogic.Deployer ユーティリティを変更して問題を解決しました。
CR094825	weblogic.Admin は無効な URL 引数を適切に処理しませんでした。次に例を示します。 java weblogic.Admin https://hostname:8888 サーバが動作していない場合は「Failed to connect」エラー メッセージになるはずですが、説明もなくコマンドが終了したり、ハングしたりすることがありました。 問題は解決済みです。 javax.net.ssl.SSLSocketImpl.close によって送出された例外が捕捉され、適切なエラー メッセージが表示されるようになりました。
CR095915	同じプロジェクトの別の関連と名前が同じ関連を作成することが、WebLogic Builder ではできなくなりました。
CR096615	エンティティ Bean の [チューニング] パネルのキャッシュ テーブルが、キャッシュの参照がない場合は無効になるようになりました。キャッシュの参照がない場合にキャッシュ テーブルの要素をクリックすると、エラーが発生していました。
CR096719	WebLogic Builder は、エンティティ Bean のプール設定をエクスポーズしていませんでした。 この問題は、エンティティ Bean のプール パネルをチューニング サブノードに追加することで解決されました。
CR096848	6.1 SP04 では、CMP 2.0 Bean で <is-modified-method-name> が呼び出されていませんでした。 Bean のメソッドを呼び出すたびに ejbStore() を呼び出し、後でストアを回避するかどうかを判定していました。 そのため、<is-modified-method-name> を頻繁に使用するアプリケーションでは、パフォーマンスの問題が発生していました。 この問題は、CMP EJB 2.0 用に <is-modified-method-name> 関数を実装することで解決されました。
CR098134	weblogic.Admin はパスワードを要求しますが、入力する前に例外を送出しました。 コードを変更してこの問題を解決しました。
CR098709 Tools	SET 操作を実行する時に、クライアントは MBean に対応する WebLogicObjectname を作成しました。 ただし、親など他のメンバーは正しく設定されませんでした。 そのため WebLogicObjectname の一貫性がなくなりました。 値が WebLogicObjectname に属するすべての属性を修正して問題を解決しました。
CR098985	setWebLogic ServerEnv.sh スクリプトでは extEnv.sh スクリプトの検索に失敗する場合がありました。 extEnv.sh スクリプトの相対アドレスがすべてのシステム シェルで機能しないことが問題でした。 参照を全体で読み込み可能な相対アドレスに置き換えて、問題を修正しました。
CR099260	関連の追加ウィザードで、既存の関連の名前を変更できるようになりました。既存の関連の名前フィールドは、以前は読み込み専用でした。
CR099865	以前は、Bean のデフォルト トランザクション属性をリセットすると、プロジェクトの他の Bean のトランザクション属性もリセットされていました。複数のトランザクション属性を持つ複数のメソッドが、1 つのトランザクション属性を持つ 1 つのメソッドとして再定義されることがありました。この動作は発生しなくなりました。
CR099911	以前は、Bean 管理の永続性を利用する一部の Bean が、デプロイメント記述子ファイルのトランザクション タイムアウト設定と一致しない期間でタイムアウトになっていました。BMP Bean は、デプロイメント記述子に従って CMP Bean と同じように動作するようになりました。
CR099913	WebLogic Builder の以前のバージョンでは、一部のコントロールが不適切に利用可能になっていました。たとえば、アプリケーションで自動キー生成が無効になっていても Oracle シーケンスの名前値を入力することができました。WebLogic Builder のインタフェース全体でコントロールが適切に有効および無効になるようになりました。
CR099913	WebLogic Builder の自動キー生成フレームで、すべてのフィールドが一貫性を持って有効または無効になりませんでした。 たとえば、<automatic-key-generation> タグのない JAR を開いて、[Automatic Key Generation] タブをロードした場合に、チェック ボックスのチェックは外されていますが、それでも値を入力することができました。 この問題は、フィールドが規則に従って無効になるようにコードを修正することで解決されました。
CR099917	トランザクション間のキャッシングの設定が永続的ではなかったので、Bean の [チューニング] パネルを表示し、同時方式を選択して、[cache-between-transactions] をチェックすることができましたが、プロジェクトを開き直すと、設定が「False」に戻っていました。この設定は永続化されるようになりました。
CR100288	ファインダ メソッドの更新が、永続化されないことがありました。自動コミットの設定が原因でしたが、問題は修正されています。
CR100756	weblogic.Admin で JMSFileStore を設定するときに間違った Type 設定を使用すると、再起動するまでサーバが使用できなくなることがありました。 間違った Type 設定がある場合は、管理サーバのログに記録される InvalidAttributeValueException が発生するようになりました。
CR103174	デバッグ モードで起動されたサーバが、config.xml からデバッグ フラグが削除されるまでデバッグ モードを保持するように、サーバを起動するコマンドラインのデバッグ フラグはドメイン コンフィグレーション ファイルに永続化されていました。 コードの修正により、コマンドライン フラグは config.xml に書き込まれなくなりました。
CR105436	java weblogic.marathon.ddinit.WebInit stageDir は weblogic.xml および web.xml 内のサーブレット コンポーネントの生成に失敗しました。 問題の原因はコード内のリグレッションです。修正して問題を解決しました。

Web サービス

変更要求番号	説明
CR106013	クラスパス内の weblogic.jar のクライアント コードで java.net.HttpURLConnection.getResponseCode は 200 を返しましたが、コンテナ内で動作しているときに java.net.HttpURLConnection.getResponseCode は同じ URL に対して 404 を返しました。 404 メッセージの原因は、WebLogic Server の内部から HttpURLConnection を使用すると、EJB コードが weblogic.net.http.HttpURLConnection のインスタンスを受け取ることでした。 setRequestProperty() は、値が空の文字列であるヘッダを無視しました。 SOAPAction ヘッダは http://www.xmethods.net/interfaces/query をホストする Apache サーバで必要でした。 使用するプロトコル ハンドラを指定できるので、Sun の実装をコード内で使用することができます。 次の単純なサーブレットで例示します。 package test; import java.io.*; import java.util.*; import javax.servlet.*; import javax.servlet.http.*; import java.net.*; public class ProtocolHandlerTest extends HttpServlet { public void service(HttpServletRequest request, HttpServletResponse response) { try { URL testUrl_1 = new URL(null, "http://www.yahoo.com:80/";, new sun.net.www.protocol.http.Handler()); URLConnection huc_1 = testUrl_1.openConnection(); URL testUrl_2 = new URL(null, "http://www.yahoo.com:80/";); URLConnection huc_2 = testUrl_2.openConnection(); System.out.println("huc_1 = "+huc_1.getClass().getName()); System.out.println("huc_2 = "+huc_2.getClass().getName()); } catch (java.net.MalformedURLException mue) { } catch (java.io.IOException ioe) { } }}
CR078871	デプロイされた Web サービスの WSDL を生成するときに、WebLogic Web サービスの実行環境は、操作を実装する EJB メソッドによって送出される例外を WSDL の <soap:fault> 要素に正確にマッピングするようになりました。 以前は、それら Web サービス固有の例外は間違って <soap:body> 要素にマッピングされていました。
CR079631	clientgen Ant タスクは、clientgen の呼び出しが含まれている build.xml ファイルの <classpath> 子要素を正しく受け入れるようになりました。
CR079776	UDDI クライアント API の weblogic.uddi.client.service.Inquiry.findService メソッドの Javadoc が更新され、このメソッドを使用するときにはサービス名だけでなくビジネス キーも指定するように明示されました。
CR082779	weblogic.webservice.client.WebLogic ServerSLAdapter インタフェースの実装が、それが開いた SSL 接続にユーザ証明書を伝播できるようになりました。以前は、SSL を介してクライアント側の証明書を使用した Web サービスの呼び出しで認証を実行することができませんでした。
CR083861	WebLogic Web サービス ランタイムが、WebLogic Web サービスを実装するステートレス セッション EJB から送出されたときに javax.xml.rpc.soap.SOAPFaultException 例外を変更しなくなりました。 以前は、誤って EJBException にラップされていました。
CR084960	Web サービス ランタイムが、呼び出し対象の Web サービスが例外を送出した場合に HTTP 500「Internal Server Error」例外をクライアントに適切に伝播するようになりました。実際の例外は、適切に SOAP 障害に格納されます。
CR087303	次の WSDL ファイルの処理中に、clientgen ant タスクは無効なクラスを作成しました。 wsdl:message name="UploadCBProfileRequest"> <wsdl:part name="body" element="tns:TRAMSDATA"/> <wsdl:part name="authHeader" element="tns:AuthenticationHeader"/> </wsdl:message> <wsdl:portType name="RelMgrPortType"> <wsdl:operation name="uploadCBProfile"> <wsdl:input message="tns:UploadCBProfileRequest"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="RelMgrSOAPBinding" type="tns:RelMgrPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http";/> <wsdl:operation name="uploadCBProfile"> <soap:operation soapAction="" style="document"/> <wsdl:input> <soap:body parts="body" use="literal"/> <soap:header wsdl:required="true" message="tns:UploadCBProfileRequest" part="authHeader" use="literal" xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/";> </soap:header> </wsdl:input> </wsdl:operation> </wsdl:binding> 結果として生成されたタスクには、重複した uploadCBProfile() 引数が含まれていました。 調査の結果、コードでは、メッセージにヘッダ部分が既にある場合でも追加されることが判明しました。コードの修正で、この問題は解決されました。
CR087529	WebLogic Server 6.1SP03 では、samples¥examples¥webservices¥rpc¥weatherEJB にあるサンプル Web サービスのクライアントが wsgen で生成され、client.jar のみを使用してデプロイされていました (weblogic.jar なし)。非 SSL Web サービスが Java クライアントによって呼び出されると、次の例外が送出されていました。 << Missing class files in servicegen client.jar. Getting Exception in thread "main" java.lang.NoClassDefFoundError: weblogic/net/http/HttpsURLConnection at weblogic.soap.http.SoapContext.lookup(SoapContext.java:87) at javax.naming.InitialContext.lookup(InitialContext.java:350) at com.verizon.client.client.main(client.java:72) >> 分析の結果、何も手を加えていない最低限の機能には weblogic.net.http.HttpsURLConnection クラスが必要であり、client.jar にこのクラスを含める必要があることが判明しました。 この問題は、weblogic.net.http.HttpsURLConnection を client.txt に追加することで解決しました。
CR090882	WebLogic Server で JRockit JVM を使用する場合に、UDDIExplorer を使用して Web サービスを正常にプライベート UDDI レジストリにパブリッシュできるようになりました。 以前は、サービスをプライベート レジストリにパブリッシュすると、UDDIExplorer エラー「E_fatalError(10500): a serious technical error has occurred while processing the request」が返されました。同じパブリッシュ操作が、デフォルトの Sun JVM では常に適切に機能してきました。
CR092549	非組み込みデータ型コンポーネント (シリアライゼーション クラス、Java クラスなど) を生成する Web サービス Ant タスクが、サポートされていない XML スキーマ データ型 xsd:union を、サポートされていない XML スキーマ型のデフォルト Java クラス SOAPElement に正しく変換できるようになりました。以前は、Ant タスクはエラーを生じて失敗していました。
CR095044	WebLogic Web サービス ランタイムが、WebLogic Server から受け取った例外の詳細を CDATA にラップするようになり、SOAP 障害の詳細に無効な XML が含まれているかもしれなかった以前の問題が修正されました。 無効な XML の例としては、<no stracktrace available> などの WebLogic Server メッセージが <> の中に配置され、無効な <<no stacktrace available>> になっていました。
CR095109	verbose モードが明示的に有効化されていない限り、ハンドラ実装の操作がある Web サービスをデプロイするときに、WebLogic Server を起動したコマンド ウィンドウに次の警告が出力されなくなりました。 WARNINIG: Unable to find a javaType for the xmlType:datatype. Make sure that you have registered this xml type in the type mapping Using SOAPElement instead. Web サービス ランタイムがこのケースでは必要のない型マッピング情報をチェックしているので、この警告は紛らわしく、誤解を生みます。
CR095561	servicegen Ant タスクが、typeMappingFile 属性と一緒に使用され、指定された types.xml ファイルに JAX-RPC 命名規約に従っていない非組み込み Java データ型のクラス名が含まれている場合にエラーを返さなくなりました。独自のシリアライゼーション クラス、非組み込み Java データ型などを作成する場合は、Java データ型にどのような名前でも付けることができます。
CR095741	WebLogic Web サービス ランタイムが、xsd:dateTime の時刻部分を適切に扱うようになりました。以前は、タイムゾーンのオフセットが適切に処理されなかったことが原因で、タイムゾーン次第で時刻が変わっていました。
CR096906	WebLogic Web サービス ランタイムが、xsd:dateTime データ型を適切に処理するようになりました。以前は、タイムゾーンが正であるときに dateTime 値のタイムゾーン オフセット部分から「+」の文字が省略されていました。
CR103937	SSL 接続を中止したときに、しばらくの間 CLOSE_WAIT が続いて、ソケットが開いたままになることがあります。 コードを変更してソケットのリークを修正しました。
CR104719	次のシグネチャで Web サービスを実装すると、 public void echoDom(Document doc) コンパイル エラーが発生しました。 ビルド時または実行時にドキュメント スタイルの type-mapping に void を追加できないようにし、ドキュメント スタイルの void 部分の書き込みをできないようにし、ドキュメント スタイルのドキュメント シリアライザでラッパー要素を使用できないようにすることで、この問題を解決しました。
CR104783	clientgen は複合型に対するシリアライザとデシリアライザを作成しませんでした。 clientgen はモデル グループへの単一の参照を含む複合型を扱うようになりました。
CR106392	invocation-style="one-way" で実行すると、以下の抜粋に示すように、その操作の <binding> セクションに <output> が含まれる WSDL になります。 <portType name="MyServicePort"> <operation name="sayNothing"> <input message="tns:sayNothing" /> </operation> </portType> <binding name="MyServicePortSoapBinding" type="tns:MyServicePort"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"; /> <operation name="sayNothing"> <soap:operation soapAction="" style="document" /> <input> <soap:body use="literal" namespace="http://tempuri.org/"; /> </input> <output> <soap:body use="literal" namespace="http://tempuri.org/"; /> </output> </operation> </binding> この動作は「rpc」と「document」の両方のスタイルの Web サービスで確認されました。この WSDL に対して Microsoft の WSDL.EXE を実行すると、検証が失敗し、続いて .Net クライアント プロキシまたはスタブの生成が失敗します。 一方向のバインディングでは出力メッセージの生成を停止するようにコードを変更して、問題を解決しました。
CR107254	Hewlett-Packard は HP Apache-based Web Server バージョン 1.3.x のサポートを中止したため、WebLogic Server は HP 用の Apache 1.3 プラグイン を削除しました。
CR108332	シン クライアント (wlclient.jar) を使用する場合、IIOP ストリームの破損を示すマーシャリング例外が発生することがありました。 この問題は、J2SE 1.4 の複数のマイナー バージョンにおいて、プロトコルとして IIOP または T3 が指定されているものの、クライアントのクラスパスに weblogic.jar がない場合に発生しました。 この問題は、カスタム マーシャリングされた valuetype のエンコーディングとデコーディングの問題と、valuetype をマーシャリングする時の WebLogic Server によるインダイレクションの追跡方法の問題が原因で発生しました。 これらの問題は解決されました。

WebLogic Tuxedo Connector

変更要求番号	説明
CR074963	大きな Field Manipulation Language (FML) テーブル (約 4000 エントリ) を作成するときには、mkfldclass[32] によってハッシュ テーブルへの各エントリをインスタンス化するメソッドが生成されていました。大きな FML テーブルの場合、この 1 つのメソッドで JVM のサイズ制限を超えてしまいます。 この問題は、動的なフィールド テーブル ロード メカニズムを実装することで解決されました。 詳細については、「mkfldclass32 クラスに対する DynRdHdr プロパティの使用」を参照してください。
CR089100	viewj メソッドと viewj32 メソッドは、多数のフィールドが含まれるビュー ファイルをコンパイルするときに巨大な Java クラスを作成する場合があります (コンストラクタ メソッドのコードのバイト数が 65535 を超える)。 分析の結果、コンストラクタのコードの大部分はフィールドや配列要素に null 値を割り当てるものであり、削除可能であることが判明しました。 この問題は、ビュー ファイルのコンパイル時に冗長なコードを抑制するようにコードを修正することで解決されました。
CR092860	WTC を使用して Tuxedo 8 Corba オブジェクトにアクセスすると、JavaIDL Reader スレッド リークが発生していました。シンプルなサンプル アプリケーションを実行すると、WebLogic Server が動作する JVM で JavaIDL Reader スレッドが連続的に発生していました。それらのスレッドは、サーバが停止されるまで破棄されませんでした。 分析の結果、finalize() が適切なときに呼び出されていないことが判明しました。 ORB.destroy() の呼び出しを追加するようにコードが修正されて、問題は解決しました。

XML

変更要求番号	説明
CR087201	(Apache の Xerces に基づく) 組み込み XML パーサが、日本語の文字が含まれる XML ファイルの解析時に java.lang.ArrayIndexOutOfBoundsException 例外を送出しなくなりました。
CR090137	(Apache の Xalan に基づく) 組み込み XML トランスフォーマが、XSL スタイルシートを使用して XML ファイルを HTML ファイルに変換するときに </META> タグを適切に追加するようになりました。以前は、出力 HTML ファイルで </META> タグが生成されず、XML が無効になっていました (HTML ファイルはブラウザで適切に表示されていた)。
CR095073	以前は、特定のタイプの XML ファイルで、反復処理が増加して解析の応答時間が遅くなっていました。この問題は現在は修正されています。
CR100068	次のような条件で、日本語文字で JSP の JSTL タグを使用すると衝突が発生しました。 1. JSP のページ エンコーディングを Shift_JIS で定義する。 <%@ page pageEncoding="Shift_JIS" %> 2. JSP でマルチバイト文字 (日本語) を使用する。 3. 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., " at weblogic.servlet.jsp.Jsp2Java.outputs(Jsp2Java.java:124) at weblogic.utils.compiler.CodeGenerator.generate(CodeGenerator.java:258) at weblogic.servlet.jsp.JspStub.compilePage(JspStub.java:353) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:211) at weblogic.servlet.jsp.JspStub.prepareServlet(JspStub.java:164) at weblogic.servlet.internal.ServletStubImpl.getServlet(ServletStubImpl.java:517) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:351) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:445) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:306) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:5445) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:780) at weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:3105) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2588) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:189) makeXMLStream のエンコーディングが正しくないことが判明しました。エンコーディングを UTF-8 に変更して問題を解決しました。

 

---

WebLogic Server 7.0 サービス パック 2 のソリューション

以下の節では、WebLogic Server 7.0 サービス パック 2 で解決された問題を説明します。

• Administration Console

• クラスローダ

• クラスタ

• コネクタ

• コア サーバ

• デプロイ

• EJB

• サンプル

• インストーラ

• インターナショナライゼーション

• jCOM

• JDBC

• jDriver

• JMS

• JNDI

• JTA

• JTS

• その他

• ノード マネージャ

• プラグイン

• RMI/RMI-IIOP

• セキュリティ

• サーブレットと JSP

• ツール

• WebLogic Tuxedo Connector

• Web サービス

• XML

Administration Console

変更要求番号	説明
CR074370	デプロイメント記述子エディタで EJB 記述子の値を変更すると、javax.management.AttributeNotFoundException が発生していました。 この問題は解決済みです。
CR074653	Administration Console デプロイメント記述子エディタで、メモリまたはディスクへの書き込み時に「&」が「&amp」で置換されるようになりました。「&」は XML ファイルで「&amp」としてエスケープしなければならない特殊文字であり、これを行わないとデプロイメントが失敗する可能性があるからです。
CR074677	WebLogic Server のバージョン 6.x で作成されたドメインをアップグレードすると、ユーザ system は、Administration Console へのアクセスを明示的に許可するようになりました。
CR074933	翻訳されたオンライン ヘルプが表示されませんでしたが、いまは表示されるようになっています。
CR079805	対象サーバに割り当てる Web アプリケーションが複製サーバに割り当てる Web アプリケーションとして表示されるようになりました。
CR081366	1 つまたは複数のサーバがコンフィグレーションされているマシンで、その削除が失敗しなくなりました。
CR081445	Netscape 4.7 ブラウザで EJB のモニタ ページが空白になることがなくなりました。
CR082345	WebLogic 7.0.0.0 では、JDBC ドライバが $CLASSPATH にない場合、コンソールから NPE が送出されました。この問題はこのリリースで修正されています。
CR082942	ユーザ パスワードを変更して [続行] をクリックしたときに NullPointerException が送出されなくなりました。
CR083242	レルム アダプタ ATN プロバイダが 7.x セキュリティ レルムに追加されたときにサーバを再起動できるようになりました。
CR083330	Administration Console でマルチプールをクラスタに割り当てることができるようになりました。
CR083465	[サーバ｜サービス｜ブリッジ｜すべてのメッセージ ブリッジ ランタイムのモニタ] をクリックしても 404 エラーが発生しなくなりました。
CR083530	ログのタイムスタンプがグリニッジ標準時 (GMT) で押されるように指定するためのコンフィグレーション オプションが Administration Console に追加されました。
CR084558	サンプルの WebLogic Portal Server に付属している Pipeline EJB の EJB デプロイメント記述子を編集する場合に、javax.management.AttribtuteNotFound などの MBean 例外で失敗しなくなりました。
CR084856	日本語環境で [セキュリティ｜ユーザ｜ユーザのロックを解除] が文字化けすることがなくなりました。
CR085101	Administration Console を使用して EJB メソッドで適切にポリシーを定義できるようになりました。
CR086107	Administration Console でグローバル Admin/Operator/Monitor/Deployer ロールを使用できるようになりました。
CR087802	EJB デプロイメント記述子を編集しても、NullPointerException が送出されなくなりました。
CR089044	ブラウザがサポートされていないときにブラウザ警告ページが Administration Console に表示されなくなりました。
CR092102	Administration Console がスレッド プールをモニタするように設定されている場合に、管理サーバが OutOfMemory 例外を送出しなくなりました。

クラスローダ

変更要求番号	説明
CR056911	.ear ファイル内の 2 つの別々の .war ファイルがそれぞれ独自のシングルトン インスタンスをインスタンス化し、アプリケーションの実行時に結果が不正になっていました。 この問題は修正済みです。
CR081377	デプロイメント時にコンテキスト クラス ローダを通じてクラスをロードできるようになり、ClassNotFound 例外が送出されなくなりました。
CR082466	ClassFinder に複数のエントリが追加されていました。 その結果、ClassLoader.getResources が重複したエントリのある列挙値を返していました。 この問題は修正されています。
CR083752	クライアント クラスは、java コマンド ラインで -Xbootclasspath 引数を使用して weblogic.jar を指定する場合に InitialContext を正常に作成できるようになりました。

クラスタ

変更要求番号	説明
CR043366	WebLogic Server 6.1 では、どのプラットフォームで動作する場合でも、クラスタ アドレスを次のようなカンマ区切りの IP アドレスのリストとして指定すると、 IPaddress1, IPaddress2 または IPaddress1:7011, IPaddress2:7011 クラスタ内の管理対象サーバの起動時に次のようなエラー メッセージが発行されました。 <main> <system> <> <000101> <Cannot resolve ClusterAddress: IPaddress1:7011, IPaddress2:7011 クラスタは正常に起動しますが、カンマ区切りのリストは解決されませんでした。 ドメインを開発モードに設定する場合、カンマ区切りの IP アドレスのリスト形式で指定されるクラスタ アドレスをサポートするように、コードの変更が実装されました。この形式はプロダクション モードの操作ではサポートされません。この形式を使用すると、EJB ハンドルが正しく管理されず、フェイルオーバに問題が発生する可能性があります。 プロダクション モードで、クラスタ アドレスは、クラスタ内の管理対象サーバにマップされた DNS 名として指定する必要があります。
CR074236	クラスタワイドの JNDI ツリーの作成と MDB のデプロイメントに関連するタイミングの問題により、起動時に NameNotFoundException が発生しました。 MDB の ejbCreate メソッドは、クラスタ内の単一のノードに固定された EJB のサービスを呼び出しました。アプリケーションの要件に関する理由のため、このノードは最初に起動されます。 2 番目のノードが起動されるときに、initial-beans-in-pool の設定が 0 より大きい MDB がデプロイされると、Bean は NameNotFoundException を送出しました。これは、固定された EJB のホーム インタフェースがまだ JNDI ツリーにバインドされていないために発生しました。初期プールの設定が 0 の MDB がデプロイされる場合は、ノードは正常に起動し、JNDI が追いつく機会があるため、最初のメッセージがキューに入れられるときに Bean は正しく動作しました。 ClusterMBean の MemberWarmupTimeoutSeconds 属性を実装することで、この問題は解決されました。デフォルト値は 0 で、クラスタが待機しないことを意味します。デフォルトでは、クラスタの起動シーケンスは変更されないままです。値を > 0 に設定すると、クラスタ メンバーは起動時にその時間だけ待機して、他のメンバーと同期します。 すべての MDB は待機時間の経過後にデプロイされます。
CR078455	6 つのノードを持ち、Web アプリケーションをホストするクラスタを 7 時間実行すると、繰り返しハングするようになりました。 F5/Big IP ロード バランサが、WebLogic Server 6.1 SP2 を実行する 3 つのサーバから成るクラスタにリクエストを転送し、次に IIS および ISAPI プラグインが、6 つの WebLogic Server 6.1 SP2 サーバから成るクラスタにプロキシする、というコンフィグレーションでした。ホスト マシンは JDK 1.3.1 を実行する Solaris 8 デュアル CPU サーバでした。 プラグインはプライマリまたはセカンダリ以外のサーバ インスタンスにリクエストを転送し、WebLogic Server はリモート ROIDImpl をルックアップして呼び出していました。 ROIDLookup および Replication Manager RMI オブジェクトのローカル スタブを作成して、スタブの JNDI ルックアップを避けるという修正によって、この問題は解決されました。 また、ROIDLookup の呼び出しではレプリケーション スレッドを使用して、デフォルト実行スレッドが使用できないときでも確実に実行し、起こり得るハングを回避しています。
CR078677	Web アプリケーションはクラスタにデプロイされました。 WebLogic Server6.1 SP2 の管理対象サーバの正常停止中に、HttpClusterServlet はフェイルオーバしませんでした。Web アプリケーションはアンデプロイされ、停止シーケンス中にリクエストを受信したときにコンテキストへの一致を見つけることができませんでした。透過的なフェイルオーバの代わりに、「page not found」エラーがブラウザに表示されました。この問題はサーバがクラッシュする場合には発生せず、正常停止中にのみ発生しました。 サーバ状態のチェックと、コンテキストが null の場合に SERVICE_UNAVAILABLE (503) を返すロジックを実装して、プラグインがクライアントに 404 (NOT FOUND) を返さずにフェイルオーバできるようにしたことで、この問題は修正されました。
CR080153	NT マルチホーム システムでは、管理対象サーバの検出モードにある管理サーバは、URL ホストがホスト名と同じで、ホスト名が複数の IP アドレスに解決される場合に、再起動しませんでした。 ホスト名が複数のアドレスに解決される場合、管理サーバはどの管理対象サーバを管理しているのか確実に特定できないためエラーが発生し、管理サーバの再起動は完了しませんでした。 アドレスがマルチホームの場合、管理対象サーバの起動時に管理サーバに対してドット区切りの IP アドレスが指定されたかどうかを特定するためのチェックが Admin.java に追加されました。それに当てはまる場合は、次のメッセージが表示されます。 'The admin server url "http://qa700:9001"; cannot be used with managed-server-discovery-mode because the hostname resolves to multiple ip addresses. Please turn off discovery mode or set just one ip address for this host.'
CR080976	タイムアウト オプションを指定して管理サーバを停止すると次のエラー メッセージが出力される問題が修正されました。 Expected RemoteException, RuntimeException, or Error but received: 'class weblogic.rjvm.PeerGoneException.' エラーは訂正されました。 タイムアウト オプションを指定して停止すると、「The shutdown sequence has been initiated」というメッセージが出力されるようになりました。
CR082443	クラスタのデバッグ フラグを有効にできないため、ログ ファイルのサイズが大きくなりました。 weblogic.cluster.ClusterDebug.java で、デバッグ メッセージがログに記録されるかどうかを制御するフラグが true に設定されていて、変更できなかったために、この問題が発生しました。 config.xml で、次のようにタグを使用してフラグをコンフィグレーションできるようにしたため、問題は解決されました。 <ServerDebug DebugCluster="true" Name="myserver"/>
CR083532	ReplicaAwareRemoteRef.getCurrentReplica の Null ポインタ例外により、停止が完了する前に停止プロセスが終了していました。 このエラーは修正されました。

コネクタ

変更要求番号	説明
CR080250	weblogic-ra.xml 記述子ファイルなしで RAR をデプロイしても NullPointerException が発生しなくなりました。
CR082608	JCA 接続ファクトリが、利用可能な接続を使用しないで新しい接続を取得しようとする問題が修正されました。
CR086251	WebLogic Server の停止中に、メッセージング ブリッジ アダプタのアンデプロイメントで NullPointerException が送出されなくなりました。
CR089279	WebLogic Server は、非推奨となったデフォルトの weblogic-ra.xml 要素を保存しなくなりました。

コア サーバ

変更要求番号	説明
CR032447	意図的にサーバを停止したときに「Emergency」メッセージが発行されなくなりました。
CR058358	EJB および Web アプリケーションで alt-dd デプロイメント記述子要素を適切に処理できるようになりました。
CR062756	ソケット読み取りがブロックされて、JDK バージョン 1.3.1 でサーバがハングする問題が解決されました。
CR068646	トンネリングがサーバ Bean で無効になっている場合に、HTTP トンネリングで weblogic.admin が成功しなくなりました。
CR070429	-Dweblogic.safeCommoBoot=true フラグを指定してサーバを起動することで、前回の正常な COMMO コンフィグレーションを使用して再起動できるようになりました。
CR071796	デフォルト以外のディレクトリから起動したサーバで、そのアプリケーションを確認できるようになりました。
CR074265	weblogic.t3.srvr.ListenThread の MAX_BACKOFF_BETWEEN_FAILURES を使用することで、サーバ リスン スレッドがソケット接続を承認しようとしている場合に「Failed to listen on port」メッセージを送信する期間をコンフィグレーションできるようになりました。詳細については、weblogic.t3.srvr.ListenThread javadoc の getMaxBackoffBetweenFailures() および setMaxBackoffBetweenFailures() を参照してください。
CR077831	AppletArchiver ユーティリティを使用してクライアント jar ファイルを生成し、対象アプレットが javax.swing.JApplet クラスをそのノードで使用する場合、エラーが送出されなくなりました。
CR079547	クラスタ化環境で JMS サーバへの恒久サブスクライバを作成するときに、InvalidClientIDException 例外と NameAlreadyBound 例外が発生しなくなりました。
CR080744	さまざまなマルチプレクサの問題が解決されました。
CR081176	ServerLifeCycleRuntimeBean の getState および getStateVal プロパティの動作がほぼ同じになりました。
CR082026	WebLogic Server がクライアントでソケットを登録するたびに JavaSocketMuxer で新しいスレッドが作成されることがなくなりました。
CR082348	WebLogic Server コンソールで wlidomain を停止しても java.lang.ThreadDeath が発生しなくなりました。
CR082533	以前のバージョンおよびサービス パック (6.1SP3) では、ChangeAwareClassLoader からの一部のデバッグ メッセージが stdout に不適切に書き込まれました。このバグはこのリリースで修正されています。
CR083654	WebLogic Server 6.1SP3 のパフォーマンスは、Microsoft WAS Tool からの連続的なリクエストで若干影響を受けます。応答でマルチバイト文字セットをコンテンツ タイプとして使用するサーブレットおよび JSP の修正によって、パフォーマンスが改善されました。
CR084977	「ルート」ID が、サーバの起動後に .wlnotdelete の制御を保持しなくなりました。
CR085544	NT サービスから weblogic.Server.stop() を呼び出して WebLogic Server インスタンスを停止しても NullPointerException が送出されなくなりました。
CR085659	RJVM の同期コードが、マシンの切断中に EJB のファイルオーバを制限しなくなりました。
CR085669	HPUX で、SAP JCO が Java 仮想マシン (JVM) のクラッシュを引き起こさなくなりました。
CR086108	WebLogic Server 6.1SP3 は WebLogic Server 7.0 SP2 と比較すると CPU 時間をより多く消費するため、ListenThread においてパフォーマンスが低下します。 サーバのスロットリングが、アクティブなソケットの情報をキャッシュすることでパフォーマンスを低下させていました。 この問題は修正済みです。
CR086425、CR84172	MTU (Large Message Transmission Unit) によってパフォーマンスの低下が発生しなくなりました。
CR086552	Java のシリアライゼーション中に、java.io.OptionalDataException が送出されなくなりました (WebLogic Server 7.0SP1)。
CR086758	Web 層と EJB 層を備えたアプリケーションで、EJB 層が ConnectionManager を閉じたときにその EJB 層と対話する Web 層がハングして、以下のような例外を送出することがなくなりました。 <Sep 24, 2002 8:43:58 AM PDT> <Info> <RJVM> <Failure in heartbeat trigger for RJVM: '7831636024374910916S:10.10.10.187:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@3bedf2 - id: '7831636024374910916S:10.10.10.187:[8001,8001,8002,8002,8001,8002,-1]:webserver:sourcingWebserver' connect time: 'Tue Sep 24 06:15:16 PDT 2002'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1348) at ...
CR087180	管理対象サーバが完全に停止する前に管理対象サーバから管理サーバへの接続が早まって終了してしまうことがなくなりました。 7.0SP01 では、次のような例外が送出されていました。 <Oct 1, 2002 3:22:42 PM PDT> <Warning> <rmi> <080006> <Failed to associate the transaction context with the response while marshalling an exception: java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@7d37fa - id: '2847122412264039151S:172.17.24.65:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver' connect time: 'Tue Oct 01 15:18:40 PDT 2002'' has already been shut down java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@7d37fa - id: '2847122412264039151S:172.17.24.65:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver' connect time: 'Tue Oct 01 15:18:40 PDT 2002'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java:1564) at
CR087254	IIOP のパフォーマンスの低下が解決されました。
CR088056	ビルドの日付がマルチプレクサ ライブラリに埋め込まれるようになりました。
CR088415	ulimit -n を unlimited に設定したときに AIX 上のサーバがクラッシュしなくなりました。
CR089035	クラスタ内の単純なステートレス セッション Bean にアクセスするときに、IllegalArgumentException: port out of range が送出されなくなりました。.
CR089144	カスタム CallRouter による EJB のデプロイメントが、IllegalArgumentException で失敗しなくなりました。
CR092183	PosixMuxer が Interrupted System Call 例外を送出しなくなりました。
CR092375	メソッドが対話状態にある場合に、手動によるハンドルのルックアップとそれに続く保存およびキャッシュが機能していませんでした。これは、EJBHandle オブジェクトのシリアライゼーションとデシリアライゼーションを変更することで修正されています。

デプロイ

変更要求番号	説明
CR110897、CR125329、 CR129494	アプリケーションをデプロイし、その準備を解除してからサーバを再起動した場合、サーバは IllegalArgumentException を送出していました。 分析の結果、J2EE コンテナが、コンフィグレーションされているがデプロイはされてないアプリケーションを起動時に処理していないことが判明しました。 そのようなアプリケーションは、<Application> スタンザで Deployed="false" となっていました。 J2EE コンテナのコードが修正され、この周辺条件に対応するようになりました。
CR049340	コンソールでアプリケーションをインストールするか、開発モードでアプリケーションをアプリケーション ディレクトリにコピーする場合、applications.xml で定義された順番でコンポーネントがデプロイされるようになりました。
CR080216	Web アプリケーションを断続的にホット デプロイまたは手動でデプロイしても、NoSuchObjectException: Bean is already undeployed 例外が送出されなくなりました。
CR080537、CR084907	起動クラスがアプリケーションより前にデプロイされるようにマークされている (LoadBeforeAppDeployments が True に設定されている) にもかかわらず、サーバの起動時にアプリケーションがデプロイされた後でロードされる問題を修正しました。
CR080929	weblogic.refresh は、ワイルドカード文字を使用して指定されたファイル名に対しても機能するようになりました。
CR081311	DTD の SaxParseException は、重要度が Info ではなく Warn になりました。
CR082263	weblogic.deploy におけるクロスプラットフォーム パスの非互換性の問題がなくなりました。weblogic.deploy は Web アプリケーション (.war ファイル) を Windows 2000 マシンから Solaris 上で動作するクラスタに正常に更新できるようになりました。
CR083179	web.xml および weblogic.xml の resource-ref 要素と resource-description 要素が同期していない場合に、エラー メッセージは一般的な情報ではなく問題の ResourceReference を示すようになりました。
CR083652	アプリケーションが起動時に 2 回ではなく 1 回デプロイされるようになりました。
CR085762	管理対象サーバに割り当てられたアプリケーションは、管理対象サーバが動作していない場合でも正しくデプロイされます。
CR085979	カスタム MBean が定義されている場合に、MBeanHome.getAllMBeans() が java.lang.IllegalArgumentException を送出しなくなりました。
CR087830	管理対象サーバに割り当てられたアプリケーションは、Administration Console から管理サーバを停止して再起動した後でも正しくデプロイされることが報告されています。
CR089098	この問題は解決済みです。 Web アプリケーションは仮想ホストに割り当てられ、仮想ホストは管理対象サーバに割り当てられています。 Web アプリケーションで JSP が変更されます。 Web アプリケーションで行われた変更は、新しいリクエストが送信されたときにまだブラウザに表示されていないため、アンデプロイとその後の再デプロイが失敗します。

EJB

変更要求番号	説明
CR062512	7.0 において、Required および NotSupported の TX 属性を持つステートフル セッション Bean がある場合、パフォーマンスが若干低下する問題が修正されました
CR060965	EJB QL クエリで等号記号 '=' の前後のスペースが不要になりました。
CR063275	WebLogic Server EJB では、byte-cmp フィールドにファインダ メソッドを書き込むことができませんでした。 これは、「EJB QL で許される型は、エンティティ Bean と依存オブジェクトの抽象スキーマ型、cmp-field の定義済みの型、およびリモート エンティティ Bean のエンティティ オブジェクト型である」という J2EE EJB-QL の定義に準拠していません。 この問題は WebLogic Server 6.1 SP01 で発見されました。このエラーはビルド時に発生しました。 ejbc: [java] [java] ERROR: Error from ejbc: Error while reading 'META-INF/weblogic-cmp-rdbms-jar.xml'. The error was: [java] [java] invalid query: In EJB containerManaged, for a query defined in the ejb-jar.xml file with a method signature, findFk(byte[]), we failed to find a corresponding method in the remote home interface, local home interface, or bean class that matches this signature. Note that class parameters such as java.lang.String must be fully qualified, thus 'String' would not match 'java.lang.String'. [java] WebLogic Server EJB は、byte-cmp フィールドでファインダ メソッドをサポートするようになりました。
CR063502	java.lang.Long 用の自動主キー生成がサポートされました。
CR076272	ホットデプロイされた EJB のエラー レポート機能が向上しました。
CR079616	WHERE 句のないサブクエリで、不正な SQL が生成されなくなりました。
CR079745	weblogic-ejb-jar.xml に別の .xml ファイルが含まれている場合でも ejbc はデプロイメントを正確に実行するようになりました。
CR080030	EJB 1.1 Bean を EJB 2.0 に更新するときに、weblogic-ejb-jar.xml の is-modified-method-name タグによって java.lang.NoSuchMethodException が送出されなくなりました。
CR080569	EJBCacheRuntime 統計でマイナス値が報告されなくなりました。
CR080985	インメモリ レプリケーションのライセンスが検出されない場合、EJB コンテナはエラーを送出する代わりにこの状況を適切に処理するようになりました。
CR081735	dispatchPolicy オプションが ejbc と rmic の両方のパブリック オプションになりました。
CR081753	Bean を何度デプロイおよびアンデプロイしようとしても、サーバがメモリ不足にならなくなりました。
CR081807	home-is-clusterable が False に設定されている場合に、サーバがクラスタ内の他のノードに通知を送信しなくなりました。
CR081817	weblogic-ejb-jar.xml ファイルで dispatchPolicy を設定する Bean レベルのオプションが用意されました。
CR082182	ejbc 出力ディレクトリのソース ファイルが、ejbc の実行時に誤って削除されてしまうことがなくなりました。
CR082350	6.1 SP3 には、EJB 処理サイズが大幅に増加してしまう問題がありました。 この問題は解決済みです。
CR082451	JMS プロバイダが WebLogic 固有ではない状況でサードパーティ jar が適切にロードされるようになりました。
CR082566	Microsoft SQLServer を使用する場合に Bean 単位のペシミスティックな同時方式がサポートされるようになりました。ペシミスティック ロックは、DD で use-select-for-update タグを使用すると実行できます。これは MSSQL Server では機能しません。該当する SQL は次のような形式になります。 SELECT ... FROM ... WITH(UPDLOCK) WHERE ... DD の database-type タグが SQL Server の場合は、すべての SELECT クエリで「WITH(UPDLOCK)」のサポートを追加してください。
CR082787	以前のバージョンでは、create() および remove() メソッドを TX_SUPPORTS にすると、ステートフル セッション Bean の基本的なロックおよびロック解除機能が破壊されました。 この問題は、create() および remove() を TX が指定されていないコンテキストで実行するように制限することで修正されました。
CR083050	WebLogic Server 6.1SP# では、ejbRemove() の context.getCallerPrincipal() を呼び出すと、以下のような例外が送出されました。 <Jul 31, 2002 4:52:17 PM EDT> <Error> <HTTP> <[WebAppServletContext(4292442,test,/test)] Servlet failed with Exception weblogic.ejb20.interfaces.PrincipalNotFoundException: Error. Method SecurityHelper.getCallerPrincipal returned a NULL Principal. The CallerPrincipal Stack has been corrupted. One cause of corruption might be: A Bean has Created its own Threads. Note that this would be in violation of EJB2.0 Final Spec Chapter: Runtime Management 24.1.2 at weblogic.ejb20.internal.EJBRuntimeUtils.getCallerPrincipal(EJBRuntimeUtils.java:526) at ... これはこのリリースで修正されています。
CR083239	EJB QL NOT MEMBER 句によって無限ループが発生しなくなりました。
CR083240	EJB QL NOT MEMBER 句と WHERE 句の組み合わせによって不正なクエリが作成されなくなりました。
CR083689	コンテナ管理の永続的な自動キー生成を SQLServer と一緒に使用できるようになりました。
CR084407	以前の一部のバージョンでは、ExclusiveEntityManager が Bean をプールに正しく返しませんでした。ExclusiveEntityManager からの Bean の場合、Bean はキャッシュから出るとフリー プールに戻されませんでした。これはこのリリースで修正されています。
CR084938	アプリケーション スコープ キャッシュを使用する読み取り専用 Bean の read-timeout-seconds をコンフィグレーションできるようになりました。
CR084978	[追加 EJB コンパイラ オプション] フィールドが Administration Console に追加され、ヒープ サイズなどのオプションを Administration Console で ejbc に渡すことができるようになりました。
CR085320	Administration Console の「アイドル Bean 数」の値が増え続けなくなりました。
CR085903	メッセージ駆動型 Bean のアンデプロイメント時に ejbRemove() が適切に呼び出されるようになりました。
CR088223	パッシベーション時の Bean 管理の永続性ステートフル セッション Bean のシリアライゼーションに関する問題が修正されました。
CR088526	WebLogic Server 6.1 SP3 では、EJB コンテナは「BMT を使用する場合、Tx はロールバックに設定されず、例外が送出される」という EJB 2.0 の規約に違反しています。このリリースでは、コンテナは例外をログに記録し (以前のバージョンでも機能)、Bean インスタンスを削除して (以前のバージョンでも機能)、トランザクションをロールバックとしてにマークします (以前のバージョンでは機能しない)。また、トランザクションはスレッドに関連付けられます。
CR090356	EJB コンテナがセキュリティ ロール情報を不適切に解析する問題が修正されました。
CR093776	weblogic-cmp-rdbms-jar.xml でカラムが LongString として定義されている場合に ejbc が不正な構文のコードを生成しなくなりました。

サンプル

変更要求番号	説明
CR055626	webapp security サンプルの login.jsp ファイルでは、ユーザ ログイン時の URL エンコーディングが有効になりました。
CR069680	JdbcTable.jsp サンプルの問題を修正しました。ユーザ名とパスワードのデータベース接続プロパティを変数名のリテラルに設定しなくなりました。変数の内容が正しく使用されます。
CR085521	r3client Web サービス サンプルの package-summary.html ファイルが不完全だった問題を修正しました。ファイルには必要な情報がすべて含まれています。

インストーラ

変更要求番号	説明
CR084521	コンフィグレーション ウィザードで、PetStore ドメインにコンフィグレーションの正しくない JMSJDBCStore が作成されなくなりました。
CR088287	コンソール モードの場合、コンフィグレーション ウィザードが管理対象サーバを作成するときに不正な SSL ポートを生成しなくなりました。

インターナショナライゼーション

変更要求番号	説明
CR074933	Administration Console のヘルプで、日本語の翻訳が表示されずに 404 または英語が表示されることがなくなりました。

jCOM

変更要求番号	説明
CR076584	手動で介入しないと生成されたクラスがコンパイルされない com2java.exe の問題が修正されました。

JDBC

変更要求番号	説明
CR062827	Prepared Statement コードで、null ポインタ例外が送出されなくなりました。 問題は、Prepared Statement オブジェクトが null に設定されることでした。
CR072605	Prepared Statement キャッシュがデフォルトでオフになりました。デフォルトの Prepared Statement キャッシュ サイズは 0 です。
CR082011	weblogic.admin コマンドライン インタフェースで接続プールを作成しても、次の認証エラーが起こらなくなりました。 java.lang.ClassCastException: weblogic.security.service.PrincipalAuthenticator
CR083928	WebLogic Server JDBC は NLS_LANG パラメータ WE8MSWIN1252 をサポートします。
CR085559	Oracle のダウンが原因でユーザ トランザクションがロールバックされない場合に、トランザクションで使用される JDBC 接続が解放されていました。結果として、プールには使用可能な接続がありませんでした。この問題は解決済みです。
CR087803	WebLogic Server は Oracle 9.0.1 を使用する JMSServer に対してコンフィグレーション済みの JDBC ストアを作成できるようになりました。
CR087930	以前は、Prepared Statement キャッシュ機能は、最初に setLong()、setFloat()、または setDouble() で使用された文のカラムに対する setInt() の呼び出しをサポートしていませんでした。また、最初は setNull(i, BIGINT) にバインドされていたカラムに対して setInt() を呼び出すと、「再解析カーソル」に関する SQLException が発生しました。 JDBC Connection Pool MBean の新しい XA Prepared Statement キャッシュ (デフォルトで有効、デフォルト値は 5) を公開し、他にもコードを変更して、不足している機能を提供しました。 [Prepared Statement キャッシュ サイズ] のデフォルト値も 0 から 5 に増加し、この機能がデフォルトで有効になりました。 使用制限を含む詳細については、「Prepared Statement キャッシュのパフォーマンスの向上」を参照してください。
CR089185	jDriver/Oracle XA および Oracle Thin XA を使用してトランザクションのアイソレーションを設定できるようになりました。以前は、設定しようとすると次のエラーが発生しました。 get exception: java.sql.SQLException: Due to vendor limitations, setting transaction isolation for "Weblogic OCI XA" JDBC XA driver is not supported
CR090378	JDBC 接続プールを通じて連続的に Select を実行しても、OutOfMemory エラーが発生しなくなりました。 WebLogic Server の以前のリリースでは、閉じられることなく破棄される JDBC オブジェクトがアプリケーション コードによって作成された場合に、そのオブジェクトは失われますが、ガベージ コレクションが行われた後でもメモリが保持されるか、カーソルが開かれたままになっていました。 そのようなオブジェクトがあまりにも多く作成された場合には、サーバが最終的にメモリ不足になり、データベースはカーソル不足になる可能性がありました。 WebLogic Server 7.0SP2 では、破棄された JDBC オブジェクトがガベージ コレクションの前に閉じられるようにコードが修正されました。 注意: 破棄されたオブジェクトと同一の JDBC オブジェクトをすぐに作成する場合、WebLogic Server は元の JDBC オブジェクトのクローンを作成します。 ただし、元のリーク オブジェクトが閉じられると、クローンも影響を受けます。 『WebLogic JDBC プログラマーズ ガイド』の「JDBC オブジェクトを閉じる」で説明されているベスト プラクティスに従うと、JDBC オブジェクトの破棄を回避できます。

jDriver

変更要求番号	説明
CR059097	statement.cancel メソッドが WebLogic jDriver for Oracle と連携して動作するようになりました。
CR068911	ResultSet.getCharacterStream() が Oracle LONG 型で使用できるようになりました。
CR078427	Oracle jDriver で weblogic.jdbc.pool.Driver を通じて PreparedStatement を使用する場合、パラメータが適切にクリアされず、jDriver はデータベースに (パラメータの新しいデータと以前のデータが) 結合されたデータを挿入していました。
CR078936	HP プラットフォームで、weblogic.jdbc.connectionPool.oraclePool を使用して Oracle データベースに接続しようとしても、SIGSEGV 11 HP エラーが発生しなくなりました。
CR082484	Prepared Statement に 511 より多くのパラメータがある場合、jDriver for Oracle で ArrayIndexOutOfBoundsException が発生しなくなりました。制限は 512 から 1024 に変更されました。

JMS

変更要求番号	説明
CR063743	メッセージ駆動型 Bean がオブジェクト メッセージの確認応答を行うようになりました。メッセージはメッセージ リスト キューに適切に格納されるようになりました。
CR077805	ヌル文字列のユーザ プロパティ- setStringProperty(propertyName, null)-で、プロパティ名が Message.propertyExists() に反映されるようになりました。
CR077898	serverSession プールを使用するときに Message.getJMSDestination() が null を返さなくなりました。
CR078439	以前のバージョンでは、クライアントとサーバの両方がクラスタ環境で同じ場所に配置される (サーバサイド テスト) 場合に、JMSSession.commit メソッドが以下のスタック トレースと同様の例外を送出しました (HP AS および Sol MS)。 EXCEPTION: java.lang.Error: transaction suspended twice Start server side stack trace: java.lang.Error: transaction suspended twice at weblogic.jms.dispatcher.Request.forceSuspendTransaction(Request.java:874) at weblogic.jms.dispatcher.Request.sleepTillNotified(Request.java:200) at ... この問題はこのリリースで修正されています。
CR078702	メッセージをリモート サーバにディスパッチするときに、JMSDispatcher スレッドにセキュリティ コンテキストに関する問題が発生しなくなりました。
CR079944	JMS キュー ブラウザの処理が修正され、メッセージ列挙全体が走査されていなくてもブラウザの終了時に関連メモリがクリーンアップされるようになりました。
CR080301	WebLogic Server 6.1SP2 では、MessageListener は TransactedSession がロールバックされた後にメッセージを受信しません。メッセージ リスナは、一定のブロックのメッセージを処理し、一定の rollback() 呼び出しを実行した後で滞留する可能性があります。 この滞留は JMS キューから 2 回目の一括フェッチが行われる際に発生する可能性があります。つまり、[最大メッセージ] パラメータが 10 の場合、最初の 10 メッセージは正しく処理されますが、メッセージ リスナは 11 番目または 12 番目のメッセージで滞留します。[最大メッセージ] パラメータが 1 の場合、滞留は 2 番目のメッセージまたは 3 番目のメッセージで発生します。これは、キューのコミットにおける内部データ構造を適切に維持することで、現在のリリースで修正されました。
CR081306	恒久トピック サブスクライバ用の JMS メッセージの再配信のバッチ サイズが 10 に制限されなくなり、コンフィグレーション可能になりました。
CR081429	jDriver と Oracle 8.1.7. を使用して接続プールを作成し、このプールを使用して JMS 用の JDBCStore をコンフィグレーションし、JDBC を有効化したときに、"java.sql.SQLException: Connection has already been closed" エラーが送出されなくなりました。
CR082826	JMS メッセージング ブリッジの終了、アンデプロイ、または停止時に恒久サブスクリプションが誤って解除されることがなくなりました。
CR083196、CR088255	メッセージ キューを保持する送り先サーバが停止している場合に JMS メッセージング ブリッジがメッセージを削除することがなくなりました。
CR083290	クラスタ内のサーバの回復が改善され、サーバ間通知が適切に処理されるようになりました。ネットワーキング レベル、RMI レベル、および JMS で変更が加えられました。
CR083794	ServerAffinity プロパティが False に設定されているトピックにメッセージを送信するときに NullPointerException が発生しなくなりました。
CR089114	特定のクラスのアプリケーションの場合、WebLogic JMS はトピック サブスクライバ セレクタをインデックス処理することでそれらを大幅に最適化できるようになりました。これらのアプリケーションは、1 つまたは複数のユニークな ID と、それらの ID に基づいてフィルタ処理される何千ものサブスクライバを含むメッセージを持ちます。 一般的な例としては、各サブスクライバが異なるユーザに対応し、各メッセージに 1 つまたは複数の対象ユーザのリストが含まれるインスタント メッセージング アプリケーションがあります。
CR084175	MessagingBridge がメッセージを処理している間に WebLogic Server インスタンスが終了および再起動された場合、メッセージが失われなくなりました。
CR084182	MessageListener または ExceptionListener を Null に設定したときに NullPointerException が送出されなくなりました。
CR084374	メッセージング ブリッジが初期コンテキストを確立できなかったときに表示されるエラー メッセージにそのブリッジのパスワードが含まれなくなりました。
CR085179	JDBC ストアを閉じたときに未処理 JMS I/O 要求が削除されなくなりました。
CR085766	recover の後に ClearProperties を呼び出したときにメッセージ プロパティが削除されなくなりました。
CR086110	JMS セキュリティ ポリシーのメッセージ キュー参照がチェックされるようになり、匿名ユーザはメッセージ キューを参照できなくなりました。
CR086125	セレクタ コードが最適化されたため、ユニークな単純セレクタごとに多数のサブスクライバがある場合のパフォーマンスが 30% まで向上しました。
CR086413	分散送り先メッセージに不正な生成時間または期限切れ時間が含まれなくなりました。
CR086495	JMSServer のアンデプロイメント (デプロイメントの削除) で InstanceNotFound 例外が送出されなくなりました。
CR086976	DB2 が動作する AS400 コンフィグレーションで JDBC ストアを作成できるようになりました。
CR087131	Redelivered フラグは、False に設定される必要があるときには True に設定されなくなりました。
CR087524	JMS DurableSubscriber の保留数がマイナスの値に設定されなくなりました。
CR088952	JMS クライアント プログラムが異常切断されたときに、サーバサイドの関連リソースが完全にクリーンアップされるようになりました。
CR089730	createTopic("BackendName/TopicName") が正常に動作するようになりました。
CR090508	メッセージの replyTo が分散送り先に設定されているときにメッセージが誤ってキューに残らなくなりました。

JNDI

変更要求番号	説明
CR083705	WebLogic Server 7.0 では JNDI ルックアップと EJB の使用に関して、パフォーマンスの低下が若干ありました。 生成済みの JNDI 関連スタブを許可することでこの問題を修正しました。ejbc には、コンパイル中にスタブとスケルトンを生成する新しいフラグ (disableHotCodeGen) があります。
CR085463	WebLogic Server 6.1 SP3 では、ネットワーク接続が切断されていると、JNDI ルックアップのフェイルオーバに長い時間がかかりました。これはこのリリースで修正されています。

JTA

変更要求番号	説明
CR064403	XA driver + SSB を使用したトランザクション タイムアウト後に XAConnection がサーバの再起動まで使用できなくなる問題が修正されました。
CR073072	JTA トランザクションのタイムアウト値を 20,000,000 以上に設定したときに例外 (javax.transaction.SystemException: start() failed) が発生しなくなりました。
CR073649	トランザクションのタイムアウト後に XA 接続プールから接続を呼び出したときに XA-PROTO エラーが送出されなくなりました。
CR080755	Oracle XA シン ドライバに関するデッドロックの問題が修正されました。
CR090618	HP で JTA と JMS の "direct-write" ファイル I/O オプションを使用できるようになりました。

JTS

変更要求番号	説明
CR064301	DBA は不明な分散トランザクションを手動で解決する必要がなくなりました。WebLogic Server が自動的に解決します。

その他

変更要求番号	説明
CR042655	拡張ログ ファイル フォーマットで access.log を使用する場合、現地時間でなくすべて GMT で時刻が指定されるようになりました。
CR072188	サーバ ライフサイクル操作を実行するために管理サーバとノード マネージャ間で確立されるネットワーク接続がタスク完了後に閉じるようになりました。
CR073023	リモート サーバを起動しようとしたときにノード マネージャが OutputHandler エラーを送出しなくなりました。
CR068646	MBean は、HttpdEnabled が false に設定され、TunnelingEnabled が false に設定されていても HTTP でアクセスできなくなりました。
CR071796	サーバがデフォルト以外のディレクトリから起動できるようになりました。
CR079110、CR083257	weblogic.Admin DELETE コマンドで WTCServer 実行時 MBean を削除するときに、削除の前に WTC がアンデプロイされませんでした。この問題は解決済みです。
CR079455	デプロイメントの失敗により ConfigurationError が発生して、サーバ プロセスが停止していました。この問題は解決済みです。
CR080016	アプリケーションが管理サーバではなく管理対象サーバを対象とする仮想ホストに割り当てられている場合、管理サーバの起動時に java.lang.reflect.UndeclaredThrowableException が発生する問題が修正されました。
CR080324	WebLogicMBean.setParent() は Javadoc でパブリック メソッドとして公開されています。
CR080740	NT サービスに正常停止機能が追加されました。beasvc に -stopclass オプションがあります。 このオプションを設定すると、このクラスの stop() メソッドが呼び出されて停止を実行します。
CR082081	SERVERLOG コマンドライン ユーティリティは、セキュアな T3 プロトコルが使用される場合に失敗しなくなりました。 以前は次のようなコマンドでした。 Dweblogic.security.SSL.trustedCAKeyStore=%WL_HOME%¥server¥lib¥cacerts -Dweblogic.security.SSL.ignoreHostnameVerification=true weblogic.Admin -url t3s://localhost:7502 -username system -password password SERVERLOG "2002/07/17 13.00" "2002/07/17 14.00" 次のようなメッセージが発生しました。 Unable to get log file:unknown protocol: https
CR082910	カスタム MBean を EAR 内に登録する場合、JMX/MBean を使用して JDBC 接続プールを削除しようとしたときに、java.lang.ClassNotFoundException で失敗することがなくなりました。
CR083220	新しい COMMO MBean をインスタンス化しようとしても、クライアント サイドで javax.management.MBeanException が送出されなくなりました。
CR083400	セキュアな T3 プロトコルを使用する場合に、管理対象サーバの起動がスタック オーバーフロー例外により失敗することはなくなりました。
CR084607	JMS トピックとキューが、クラスタ内で実行時に正しく作成されるようになりました。 以前は、トピックは作成されたように見えましたが、JMS サーバの送り先のリンクをクリックすると次のような例外が発生していました。 java.lang.reflect.UndeclaredThrowableException javax.management.InstanceNotFoundException
CR085315	AIX 4.3 において、管理サーバの実行中に管理対象サーバを起動したときに、WebLogic Server プロセスが NullPointerException により終了することがなくなりました。
CR085914	SNMP リクエストが、管理対象サーバの停止後にタイムアウトにならなくなりました。
CR086913	WebLogic Platform ドメインで、WebLogic Server は起動時に以下の 3 つのプロパティを認識するようになりました。 weblogic.jws.ProductionMode weblogic.servlet.ClasspathServlet.disableStrictCheck weblogic.SystemDataStoreConfigDirectory
CR088449	WebLogic Server は、起動時に以下のプロパティを認識するようになりました。 weblogic.classloader.preprocessor weblogic.oci.selectBlobChunkSize weblogic.PosixSocketReaders
CR090721	WebLogic java プロセスのファイル記述子数が、サーバ プロセスが不能になる程に制御できなくなることがなくなりました。
CR092471	ドメイン ログの時間に基づいたローテーションが、サーバの再起動時に失敗することがなくなりました。

ノード マネージャ

変更要求番号	説明
CR071591	ノード マネージャは、HTTP 接続の開始を試みることで管理対象サーバの障害を検出することがなくなりました。 現在は、ノード マネージャが接続障害を受信した場合、ノード マネージャの出力で接続例外が示されることがあります。
CR072188	タスクの完了後に、管理サーバはノード マネージャで確立した接続を正しく閉じるようになりました。以前は失敗し、サーバのファイル記述子の不足が生じました。
CR079205	ノード マネージャは weblogic.policy を正しく解析するようになりました。子プロセスのコマンドラインにプロパティをコピーするときに等号を追加しなくなりました。
CR081183	ノード マネージャがクラスタを強制停止するときに、競合状況が発生しなくなりました。 この問題により java.net.ConnectException:Connection refused: connect エラーが発生していました。

プラグイン

変更要求番号	説明
CR079186	すべてのプラグインは、HTTP 1.1 仕様に従って、折り返されたヘッダを正しく解析するようになりました。 以前は折り返されたヘッダがあると、不正なヘッダを示すエラー メッセージが発生しました。
CR087997	Apache プラグインはセッション クッキーのプライマリ jvmid を正しく解析するようになりました。
CR089033、CR088914 CR088915	証明書チェーンの攻撃やセキュリティ リスクに対するプラグインの脆弱性を修正しました。
CR079973	NSAPI で Idempotent が Off に設定されている場合、フェイルオーバは適切に無効になります。 ConnectTimeoutSecs を 0 に設定してもコア ダンプは発生しなくなりました。
CR080219	IPlanet は、すべての WebLogic Server インスタンスが停止された場合にコア ダンプしなくなりました。
CR080382	実際にはページが使用できる場合に「error page is unavailable」というメッセージは表示されなくなりました。
CR082093	負荷が大きい状況で、プロキシ プラグインがアプリケーション サーバに誤った余分な呼び出しを行っていました。iPlanet は呼び出しを受け取ると、呼び出しを 1 回だけアプリケーション サーバに送信するようになりました。
CR082096、 CR083386	ISAPI で Idempotent が Off に設定されている場合、フェイルオーバは適切に無効になります。
CR082113	以前は、ISAPI プラグインはクライアントからのデータの読み込み時にエラーを受け取ると、バックエンドの WebLogic Server に不完全なデータ (リクエスト) を送信しようとしました。 この状況は、プラグインが HTTP POST リクエストを読み込んでいるときに、エンド ユーザがブラウザの中止ボタンを押した場合などに発生していました。 送信中のデータが予定のバイト数に一致しないため、プラグインは sendRequest フェーズでエラーを受け取っていました。 この問題は発生しなくなりました。
CR082206	IPlanet では、プロキシからの一部の画像を除外して、パスによるプロキシを実行できる WLExcludePathOrMimeType フラグが用意されました。
CR082939	セッション トラッキングにクッキーではなく URLRewriting プロパティを使用する場合、セッションが維持されるようになりました。以前は、URLRewriting を設定してもセッションが正しくトラッキングされませんでした。
CR083643	NSAPI において、netbuf_getc() が非常に遅く、POST データ内の '¥0' と 0 を区別できないというパフォーマンスの問題が修正されました。
CR085192	ISAPI および NSAPI プラグインでは、KeepAlive 機能がデフォルトで有効になりました。
CR085922	NSAPI において、netbuf_getbytes() が iWS4.x を使用する Java クライアントで失敗することがなくなりました。
CR086518	IPlanet において、クエリ文字列とアンカーの両方が含まれる URL を使用してリダイレクトを実行する場合、アンカーが誤って最後のクエリ文字列メンバーの値部分の一部と見なされる問題を修正しました。
CR089746	セッションのキャッシュと KeepAlive 機能は、セキュアなセッションに対して有効になりました。

RMI/RMI-IIOP

変更要求番号	説明
CR079918	RMI オブジェクトをデータベースに格納するという試みが、動的プロキシ オブジェクトのシリアライズに問題があることで失敗することがなくなりました。
CR081265	クラスタへの呼び出し中に発生し、AssertionError として示されたレプリカ リストの問題を修正しました。
CR081510	RMI オブジェクトの IOR における CSIv2 のサポートを示す実行時記述子は、デフォルトで Supported に設定されるようになりました。 以前は、デフォルトで None に設定されていました。
CR081764	負荷が大きい状況で再起動するとサーバのハングを引き起こす、IIOP 初期化時のデッドロックを修正しました。
CR081923	IncompatibleClassChange エラーを発生させる、スタブ生成時のメモリ リークを修正しました。
CR083018	WebLogic Server で、間接的な型コードを使用して Any をアンマーシャリングできない問題が修正されました。これは IBM との相互運用性の問題を招いていました。
CR083936	WebLogic Server を使用して Orbix 2000 2.0 とのトランザクションを調整できない一連の問題を修正しました。
CR085703	例外の応答が発生する場合にリクエストが閉じてしまうことはなくなりました。
CR086300	サーバ コンテキストのレプリカ リストで、ドメイン名フィールド (WebLogic Server がサーバ名を配置する) が正しく設定されるようになりました。
CR086350	例外クラス名が大文字の「I」で終わる場合、生成された IDL が破損する問題を修正しました。
CR088777	循環参照は IDL の生成で正しく処理されるようになりました。以前は、クラスに循環参照が含まれている場合、-iiop -idl オプションを指定してクラスをコンパイルしようとすると失敗しました。
CR088778	TopLink で間接的な方法を使用しても、Assertion エラーは送出されなくなりました。
CR090010	weblogic.ejbc が多次元配列に対する不正な IDL モジュール宣言を生成する問題を修正しました。

セキュリティ

変更要求番号	説明
CR066491	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-17.jsp のセキュリティ勧告を参照してください。
CR072154	sslclient サンプルの問題が以下のように修正されました。 Package-Summary.html に空白のクラスが含まれなくなった WebLogic Server_home が Samples_home に置き換えられた MyListener クラスがキットに実装された
CR072432	証明書データが Administration Console に表示されない問題が修正されました。
CR072954	SSL はアプレットで正常に動作するようになりました。
CR073187	TLS_RSA_WITH_DES_CBC_SHA 暗号スイートがエクスポート可能になりました。
082040	WebLogic 監査プロバイダのログ ファイルの場所が変更されました。監査はセキュリティ レルムを対象にコンフィグレーションされますが、各サーバ インスタンスはサーバ ディレクトリに存在する独自のログ ファイルに書き込みを行います。 新しい格納場所は、WL_HOME¥mydomain¥myserver¥ DefaultAuditRecorder.log です。
CR084170	旧リリースでは、WebLogic Server は証明書チェーンの各証明書が認証局によって発行されたことを保証しませんでした。この問題は、誰かが信頼性のある認証局から個人用証明書を取得し、その証明書を使用して他の証明書を発行しても、WebLogic Server は無効な証明書を検出できないことを意味しました。このリリースでは、WebLogic Server で使用するすべての X509 V3 CA 証明書は CA として定義される基本制約拡張を備えている必要があります。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが保証されます。デフォルトでは、この条件を満たしていない認証局の証明書は拒否されます。 詳細については、「SSL 証明書検証」を参照してください。
CR085072	weblogic.xml または weblogic-ejb-jar.xml ファイルでセキュリティ ポリシーを定義するには、ドメインに ¥lib ディレクトリを作成し、次に weblogic.policy ファイルで ¥lib ディレクトリにパーミッションを付与する必要がありました。 この確認済みの問題はこのリリースで修正されています。 セキュリティ ポリシーの定義については、『WebLogic リソースのセキュリティ』を参照してください。
CR085203	WebLogic Integration では、WebLogic Server との対話中に SSL セッションを再開する問題が発生しなくなりました。
CR085805	カスタム認可プロバイダのコード例は、その web.xml ファイルが不正であったため正常に機能しませんでした。 このファイルは、url-pattern として */ を使用すべきときに * を使用してそのページを保護していました。 更新されたコード例は、次の URL からダウンロードできます。 http://dev2dev.bea.com/code/
CR086589	javax.security.auth.login.LoginContext.logout() メソッドは LoginContext のサブジェクトからプリンシパルおよび資格情報を削除しませんでした。このため、ユーザはログアウトされませんでした。 この確認済みの問題はこのリリースで修正されています。
CR086709	保護されている JNDI リソースに、許可のないユーザはアクセスできなくなりました。
CR088081	階層的な WebLogic リソース (JMS、JDBC、サーバなど) は getParentResource() メソッドからのアクションを正常に処理するようになりました。
CR088784	JSP からステートフル セッション Bean を呼び出すと以下のセキュリティ違反が発生しました。 java.rmi.AccessException:Security Violation: user username has insufficient permission to access EJB このエラーは、確立されたセキュリティ コンテキストが正常に閉じられないために発生しました。 JSP の最後で ServletAuthentication.runAs(Subject subject, HTTPServletRequest request) を使用すると、初期セキュリティ コンテキストが閉じられない場合にユーザが HTTPServletRequest に追加されます。
CR089059	WebLogic Server は、KeyUsage 制約がクリティカルとして設定され、KeyEncipherment 制約が設定されていないデジタル証明書を拒否します。 SSL V3.0 を使用する WebLogic Server の旧バージョンは、この状況でも証明書を拒否しませんでした。TLS V1.0 を使用する WebLogic Server のこのリリースは、この状況で証明書を拒否します。 回避策 : パッチ CR089059_70sp1.jar を適用してください。
CR090360	ServerIron モニタ製品は、サーバの状態チェック中に要求を SSL ポートに送信します。この状態チェック中、SSLIOConect と関連 SSL オブジェクトが解放されず、メモリ不足エラーが発生しました。 この確認済みの問題はこのリリースで修正されています。
CR090401	ユーザ グループに未認証ユーザは含まれなくなりました。 この確認済みの問題はこのリリースで修正されています。
CR091796	IPlanet 認証プロバイダで動的グループが正常に動作するようになりました。
CR091922	WebLogic Server のサーブレット コンテナは、J2EE 仕様で指定されているとおりにログイン例外をエラー ページに受け渡しませんでした。 この確認済みの問題はこのリリースで修正されています。
CR092167、CR085441	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-29.jsp のセキュリティ勧告に関する情報を確認してください。
CR077050	クラスタ内のレプリケートされた LDAP データベースにユーザを追加した場合、そのユーザが管理対象サーバにレプリケートされるのに非常に長い時間がかかる問題が修正されました。

サーブレットと JSP

変更要求番号	説明
CR065967	type オプションが指定され、型が配列であるときに (型が文字列として扱われるため) タグ ライブラリが失敗する問題が修正されました。
CR068577	生成されたコードで method_releaseTags() が jsp:forward の一部として呼び出されない問題が修正されました。JSP の本文中で転送が発生するとタグがリリースされるようになりました。
CR070417	サーブレットが HTTP/1.1 でアプレットにメッセージを送信すると、すべてのメッセージが送信されるまでアプレットがハングする問題が修正されました。これは、サーブレットが送信したメッセージをアプレットが並列受信しなかったからです。
CR075419	「%」が含まれている URL が正常にロードされるようになりました。
CR044926、CR075799	2 バイト プラットフォームで、「}」を含む JSP ファイルから Java コードを生成できるようになりました。
CR072474	jsp:usebean を使用する場合、jspc は非推奨のメソッドを含んだクラス ファイルを生成しなくなりました。
CR075668	JSP がルート ディレクトリ以外のディレクトリに格納され、相対パス名で表現されている場合に jspc が正常に機能するようになりました。
CR078551	jsp:include が存在しない JSP を参照すると、FileNotFoundException が送出されるようになりました。
CR081353	javax.servlet.jsp.PageContext.out 属性は本体コンテンツ タグ用に正常にクリーンアップされ、出力が正常にブラウザに送信されるようになりました。
CR082310	page contentType ディレクティブを含む JSP を展開 Web アーカイブ (WAR) で削除および上書きできるようになりました。
CR083227	JSP ファイルに jsp:setProperty プロパティが含まれ、このタグが参照する Bean に属性 String [][] として多次元配列が含まれる場合、jspc はコンパイル可能コードを生成できるようになりました。
CR083597	page contentType ディレクティブを使用する場合、コンテンツ タイプは正しく設定されるようになりました。
CR83804	WebLogic Server では、応答がクライアントにコミットされない限り、ユーザがバッファ サイズをリセットできるようになりました。 7.0 および 7.0SP1 では、バッファがコミットされていない場合、サーバは illegalStateException を送出し、setBufferSize が ServletOutputStream.write() の後に呼び出されました。 これにより、バッファをフラッシュする前の setBufferSize の呼び出しに依存するサーブレット/フィルタで問題が発生しました。
CR083848	別の JSP からのコンテンツを含めるときに JSP 内の日本語が文字化けしないようになりました。
CR084593	JSP は contentType が不正な文字セットに設定されていることを正確に検出するようになりました。
CR085702	JSP コンパイル エラーの行番号がエラー メッセージと正確に一致するようになりました。
CR086908	jspc 解析エラー メッセージがより詳細になり、誤った記述子を素早く発見できるようになりました。
CR087090	jspc が同一のタグ ライブラリを使用する複数の JSP を呼び出す方法により、jspc 実行時間が効率化されました。
CR088019	共通の一時ディレクトリを共有するために複数の仮想ホストのデプロイ済みリソースが競合する問題が修正されました。これを解決するために、一時ディレクトリのパスにサーバ名を追加しました。 この副作用として、compile-on-startup JSP クラスが管理サーバから管理対象サーバにデプロイされなくなります。 しかし、これは意図的な結果ではありません。適切にデプロイするには、weblogic.jspc を使用してサーバの起動前にこれらのクラスを事前にコンパイルし、WEB-INF/classes ディレクトリにデプロイします。
CR088301	インクルードされたリソース (「リソース A」) が、JSP BodyTag の内部で Forward ディスパッチされた別のリソース (「リソース B」) からディスパッチされたとき、サーブレットの出力ストリームに送信されない問題が修正されました。
CR088525	jsp:include は jsp:param (値が "/////" の場合) を適切に転送するようになりました。
CR092089	Web アプリケーションに複数バイト名のファイルが存在する場合、WebLogic Server がそれをコンパイルせずディレクトリの内容を返す問題が修正されました。
CR093291	クラスパスの問題を解決したことにより、JSP をコンパイルするときに .jar ファイルを適切に発見できるようになりました。
CR061493	URL が JSP 名前/値パラメータとして指定されて JSP が含まれた場合、その URL は異なるエンコード体系が指定されたときに削除されなくなりました。
CR070090	WebLogic Server はキャッシュ プロキシがクッキーをキャッシュしないように cache-control を適切に指定するようになりました。
CR074840	ppath と pathtrim を持つプロキシがクライアントと WebLogic Server 間で使用され、フォームベースの認証が使用される場合、クライアントがプロセスにリダイレクトされない問題が修正されました。
CR077780	WebLogic Server はサーブレット要求のディスパッチ後にクリーンアップとキューへの再登録を適切に行って、メモリ リークを防ぐようになりました。
CR078698	access.log ファイルはサイズに基づいて正確にローテーションされるようになりました。
CR079014	次に示す新しい setTimeout() メソッドを使用して、HTTP 永続接続の存続期間をクライアント サイドでコンフィグレーションできるようになりました。 URL u = new URL(url); HttpURLConnection hu = new HttpURLConnection(u); hu.setTimeout(5*1000); BufferedReader in = new BufferedReader(new InputStreamReader(hu.getInputStream()));
CR079767	applications/.wlnotdelete ファイルに格納されていた一時ファイルは、不要になったとき (アプリケーションが再デプロイまたは削除されたとき) に削除されるようになりました。
CR80090	定義されている場合、FrontendHTTPPort、FrontEndHTTPSPort、および FrontEndHost はリダイレクトされる URL を作成するときに HOST ヘッダに優先するようになりました。
CR080384	不正なステータス行があるリクエストで検出されたときに HttpClusterServlet がリクエストをサーバに転送するのを停止する問題が修正されました。
CR080613	クッキー内の引用符で囲まれた値でカンマが正しく解析されない問題が修正されました。
CR080751	アプリケーションが ServletException を拡張するカスタマイズされた例外を送出するときに誤ったメッセージが表示される問題が修正されました。
CR080855	absolutURI を含む HTTP リクエストが適切なコンテキスト パス、リクエスト URI、およびリクエスト URL で実行されるようになりました。
CR080903	デプロイメント時に Web アプリケーションが 2 度展開される問題が修正されました。
CR081071	不正なプロセスが NullPointerException を送出せずに適切に終了するようになりました。
CR081253	TransferEncoding が Chunked に設定されている HTTP リクエストをサーバが適切に解析するようになりました。
CR081418	PrintNulls オプションが weblogic700-web-jar.dtd から失われないようになりました。
CR081484	HttpSessionListener を使用し、PersistentStoreType が replicated に設定されているときにセッション属性が失われないようになりました。
CR081521	.ear または .war ファイルの JSP から CGI スクリプトを呼び出すときに CGI 出力が正確に表示されるようになりました。
CR082156	isRequestedSessionIdValid() で常に値 true が返されていました (つまり、URL でセッション ID を変更してもリクエスト セッション ID が有効となっていました)。 無効なセッションが適切に検出されて無効としてレポートされるようになりました。
CR082580	URL にアクセスした場合、フォームベースの認証が起動され認証が成功したときに HTTP POST パラメータが適切に保存されるようになりました。
CR083191	Administration Console にサーブレット実行時間の無効な値が表示される問題が修正されました。
CR083487	<url-pattern> が完全一致したときに CGIServlet が動作するようになりました。
CR083517	HttpClusterServlet は、SecuryProxy が設定されているときにリクエストを SSL に適切にプロキシするようになりました。
CR083624	HTTP 1.0 リクエストがヘッダで HTTP 1.1 応答を適切に返すようになりました。
CR083912	Oracle Thin Driver 8.1.7.3 を使用するときに JDBC セッションの永続が失敗する問題が修正されました。
CR084002	仕様に従って、204 HTTP 応答にメッセージ本文が含まれなくなりました。
CR084076、CR086280	Keepalive 接続でサーブレットにアクセスしているときに不正なリクエストが作成される問題が修正されました。
CR084165	HTTP セッション トラッキングは、PersistentStoreType が jdbc に設定されているときに維持されるようになりました。
CR084167	応答ラッパーを使用する場合、取り込みまたは転送によって JSP の出力を別の JSP に委託するときに IllegalStateException が送出されなくなりました。
CR084649	WebLogic の CGI サーバは、その中で実行するスクリプトに対する SERVER_URL、 HTTP_COOKIE、および QUERY_STRING 環境変数を提供するようになりました。
CR084785	GenericProxyServlet はラップされた応答を処理するようになりました。
CR084958	HttpURLConnection ハンドラが getErrorStream() を実装するようになったため、エラー ページからカスタム応答を読み取ることができるようになりました。
CR085735	URLRewritingEnabled が false に設定されている場合にも JSESSSIONID が URL にエンコードされてしまい、404 エラーが発生する問題が修正されました。
CR085843	ejb-local-ref が Web アプリケーションに対して動作するようになりました。
CR086026	CacheSessionCookie のデフォルトが true となり、最初の表示で問題が発生しなくなりました。
CR086052	発信 (WebLogic Server から) HTTPS 接続で後続のスラッシュ '/' が不要になりました。
CR086099	Java 1.3.1 と Java 1.4.0 間の java.net.Socket.isConnected() の動作の変更から発生した NullPointerException バグが修正されました。
CR086416	サーブレット エンジンは、コンソール ページをロードしようとするときに SocketWriteError を送出しなくなりました。
CR086481	Web アプリケーションがファイルをアップロードしようとしたときに ArrayIndexOutOfBounds 例外が発生しなくなりました。コードを再作成して、バッファ オーバーフロー、およびバッファが一部しか読み込まれないケースに対処しました。
CR086677、CR087573、 CR088528	JDBC 永続性に関して、後続の要求がセッションの永続性の完了前に許可され、データの損失が発生する問題が修正されました。
CR087647	HttpURLConnection のタイムアウトが正確に行われるようになりました。
CR087984	サーバの停止時に ServletContextListener を HttpSessionListener の前に呼び出すと予期しない結果が発生する問題が修正されました。
CR088166	サーバがより正確に XML 終了タグを検出するようになり、例外を回避できるようになりました。
CR088478、 CR086490	クラスタ化サーバ用の WebLogic Server プラグインで MaxSkips 機能が非推奨になり、代わりに MaxSkipTime を使用するようになりました。 MaxSkipTime は、プラグインが「bad」(障害が発生したサーバを表す) とマークされたサーバへの接続を再試行するまでの時間を設定します。
CR089229	HttpClusterServlet 呼び出しでパフォーマンスが 10 パーセント低下する問題が修正されました。
CR089923	jspc が現在のディレクトリにファイルを作成できない問題が修正されました。
CR090665	サーブレット フィルタは、応答をクライアントに送信するために chain.doFilter() の呼び出し後に応答ラッパーの flushBuffer() を明示的に呼び出す必要がなくなりました。
CR091699	response.sendRedirect() は、絶対 URL の代わりに相対 URL にリダイレクトするようになりました。
CR091878	Web アプリケーションのアンデプロイによって IndexOutOfBoundsException が発生することがなくなりました。
CR092778	HttpRequest 用の JISAutoDetect エンコードで例外が発生する問題が修正されました。
CR095166	iisproxy のクッキー解析が修正されました。クライアントが複数のクッキーを送信するときにプロキシはプライマリ サーバに正確に留まるようになりました。
CR080778	セッション モニタを有効にしても、トラフィックが増加して管理サーバが新しいセッションを作成するたびにハングすることはなくなりました。

ツール

変更要求番号	説明
CR073688	WebLogic Builder では、[サーブレット/フィルタ マップ｜フィルタ マッピング｜追加] で、サーブレット名と URL パターンの両方の値を入力できるようになりました。
CR073715	.jar ファイルに複数のコンテナ管理の永続性 (CMP) 記述子ファイルが含まれている場合、WebLogic Builder にすべての記述子ファイルが表示されるようになりました (これまでは最初に発見したファイルしか表示されなかった)。
CR073877	WebLogic Builder がコンテナ管理の永続性エンティティ Bean を作成する場合、<trans-attribute> 値のデフォルトとして Required が使用されます。
CR074052	WebLogic Builder は enable-call-by-reference のデフォルト値として True を正しく表示するようになりました。
CR074059	WebLogic Builder に、デプロイメント記述子をユーザが指定した場所にエクスポートする機能が追加されました。
CR074208	WebLogic Builder で resultTypeMapping を設定する場合、新しいファインダ/選択メソッドを追加すると正しく機能するようになりました。
CR074246	WebLogic Builder がアーカイブを最初に展開するときにタイムスタンプを保持できない問題を修正しました。この問題によって、EJB コンテナが誤ってすべての JSP をあらかじめコンパイルする場合がありました。
CR074247	WebLogic Builder で、既存のファインダに含まれているのと同じメソッド名を持つファインダを追加するとツリーは更新されるがテーブルは更新されない問題が修正されました。
CR074602	WebLogic Builder はクラスを検証する前に再ロードするようになりました。
CR074603	WebLogic Builder はクラスをデプロイする前に検証するようになりました。
CR074634、CR074955、CR074972	WebLogic Builder の関連ウィザードを使用して既に複数の関連がコンフィグレーションされている CMP の関連を編集しても例外は送出されなくなりました。
CR074639	WebLogic Builder の編集パネルを使用してファインダ メソッドの名前を編集した場合、その変更が XML に正しく伝播されるようになりました。[ファインダ] ポップアップ ダイアログを使用して編集した場合、その変更は XML にも編集パネルにも正しく伝播されます。
CR074876	WebLogic Builder は [オプション] ダイアログでサーバの接続情報を保存し、正しく伝播するようになりました。 以前は [オプション] ダイアログの値は [server connect] ダイアログに表示される値と関連がありませんでした。修正によって、その情報は [オプション] 画面で入力された値と同期するようになりました。
CR075005	WebLogic Builder でコンポーネントを開くときに無効なドライブを指定しても (テキスト ボックスに無効なドライブを入力して〔Enter〕を押し、[開く] を選択する)、NullPointerException 例外が発生しなくなりました。
CR075006	WebLogic Builder は 1 対 多の関係を正しく作成するようになりました。
CR080967	WebLogic Builder は weblogic-cmp-rdbms-jar.xml file を正しく解析および編集するようになりました。
CR081296	NullPointerException を発生させる DDInit の問題を修正しました。次のコマンドを発行します。 java weblogic.marathon.ddinit.EJBInit project.jar where project.jar is a well-formed ejb jar no longer provokes this error: Exception in thread "main" java.lang.NullPointerException
CR081483	WebLogic Builder では、verify-column の値が設定されていない場合、同時方式をデフォルトで Read に設定してエラーを防ぎます。
CR082562	WebLogic Builder は use-select-for-update をサポートするようになりました。
CR083151	コマンドラインの DDInit は EAR ファイルに対して機能するようになりました。
CR084570	DDInit は EAR ファイルの application.xml に加えて weblogic-application.xml を作成するようになりました。
CR085493	EJBGen に global-role タグが追加されました。
CR086073	サーバ ダイアログを取り消しても、WebLogic Builder はエラー メッセージを誤って表示しなくなりました。
CR086546	DDInit は、同等でなければならない 2 つの関係が同等でないことを正しく判別するようになりました。
CR089867	WebLogic Builder は dbms-column-type の LongString および SybaseBinary タイプをサポートするようになりました。

WebLogic Tuxedo Connector

変更要求番号	説明
CR077476	WTC トランザクションが TPEV_SENDONLY の不正な処理のために誤ってロールバックされる問題が修正されました。
CR078774	Tuxedo /Q からメッセージを取得する接続を使用して、WTC/tBridge によってメッセージを処理しても、一定時間の経過後にメッセージの取得が停止しなくなりました。
CR082312	TPNOBLOCK フラグが設定された tpcall が失敗しなくなりました。
CR084435	接続ポリシーが ON_DEMAND または ON_STARTUP に設定された場合、フェイルオーバおよびフェイルバックの状況で発生する問題を修正しました。
CR084903	WebLogic Tuxedo Connector simpappcns サンプルはマルチプラットフォーム環境をサポートするようになりました。

Web サービス

変更要求番号	説明
CR070387	データ型の非標準のマッピングが無視されなくなりました。
CR073899	WebLogic Web サービスは、SOAP 障害の生成時に余計な非 CDATA 文字を追加しなくなりました。
CR076625	ユーザは、デプロイメント記述子要素で portTypeName を指定できるようになりました。
CR076706	XML ノードの余分なスペース文字の解析に関する問題が修正されました。
CR077855	Java クライアントが Web サービスにアクセスするときに NullPointerExceptions を発生させる不正な content-type 設定が修正されました。
CR078115	Administration Console で [個別のサービスのポリシーとロールを定義...] を選択したときに NullPointerException が送出されなくなりました。
CR081938	ハンドラを使用せずに添付ファイル付き SOAP を処理する Web サービス例が追加されました。
CR082626	パフォーマンスを向上させるシリアライゼーションが効率化されました。
CR082779	HttpsURLConnection が SSLContext から ID を正確に取得するようになりました。
CR083278	JAX-RPC クライアントスタブ生成が正常に機能しない問題が修正されました。
CR083410	カスタム SoapfaultException が正確に詳細フィールドを埋め込むようになりました。
CR083813	JavaBean 配列型が適切に処理されるようになりました。
CR083919	重複要素を持つ継承型に対する XML データ バインドが失敗しなくなりました。
CR084168	WSDL 生成で再帰型が処理されるようになりました。
CR084220	WebLogic 動的クライアントがスタイル style="document" WebService を呼び出せるようになりました。
CR084591	シリアライゼーションとデシリアライゼーションでの月と日の形式の処理が修正されました。
CR085214	日付をパラメータとして渡すと java.Lang.IllegalArgumentException が発生する問題が修正されました。
CR085246	XSD 列挙が WSDL 生成で認識されるようになりました。
CR085888	アノテーション ドキュメントを含むスキーマ インポートを持つ WSDL が失敗しなくなりました。
CR086231	生成される WSDL で重複する例外メッセージが発行される問題が修正されました。
CR087883	xsd:base64Binary 型の要素を持つ大きな値について、Web サービス応答でコンテンツ長が正確に設定されるようになりました。

XML

変更要求番号	説明
CR080961	org.xml.sax.helpers.AttributesImpl.removeAttribute() の呼び出しが SAX エラーで失敗する Xerces1.3.1 の問題を修正しました。
CR081372	DocumentBuilder.parse() は、入力エンコーディングが Unicode の場合、マルチスレッド セーフになりました。
CR088349	Java Web サービス クライアントから WebLogic Workshop で生成された Web サービスへの要求で、UTF-8 または UTF-8 のサブセットではない文字エンコーディングを使用すると、次のクライアントサイド例外により失敗しました。 javax.xml.rpc.soap.SOAPFaultException: Invalid request 上記のサーバサイド例外 : java.io.CharConversionException: Malformed UTF-8 char -- is an XML encoding declaration missing? 調査により、クライアントでは XML 宣言ではなく HTTP ヘッダでのみ文字エンコーディング情報が指定されていたことがわかりました。 Workshop Web サービスは XML 宣言のエンコーディングに従って動作します。指定されていない場合は UTF-8 になります。 リクエストに有効な UTF-8 文字ではない文字が含まれている場合、エラーが発生します。 クライアントは、HTTP ヘッダと XML 宣言の両方にエンコーディング情報を含むように変更されました。その修正で、問題は解決されました。

 

---

WebLogic Server 7.0 サービス パック 1 のソリューション

以下の節では、WebLogic Server 7.0 サービス パック 1 で解決された問題を説明します。

• コンソール

• コア サーバ

• デプロイ

• EJB

• サンプル

• インターナショナライゼーション

• JDBC

• JMS

• JNDI

• JTA

• JTS

• その他

• RMI/RMI-IIOP

• セキュリティ

• サーブレットと JSP

• ツール

• WebLogic Tuxedo Connector

• Web サービス

コンソール

変更要求番号	説明
CR068366	コンソールのコンテキスト パスの変更が、コンソール アプリケーションのデプロイに適切に影響するようになりました。
CR069887	load.mlet ファイルが myserver ディレクトリで作成される問題が修正されました。 この問題は、weblogic.Server を使用して myserver とは異なるフォルダに新しいドメインを作成すると発生しました。 load.mlet ファイルは削除され、myserver ディレクトリは作成されなくなりました。
CR076739	ローカル ステートレス セッション EJB デプロイメントの JNDI ツリーを表示するときに [オブジェクト クラス]、[オブジェクト ハッシュ コード]、および [文字列へのオブジェクト] フィールドが空白になる問題が修正されました。
CR077126	コンソールでサーブレットをモニタできるように weblogic.xml param ConsoleMain Attribute をコンフィグレーションできない問題が修正されました。
CR081366	1 つまたは複数のサーバがコンフィグレーションされているマシン オブジェクトをユーザが削除できない問題が修正されました。
CR082942	コンソールでユーザのパスワードが変更されて [続行] がクリックされたときに Null ポインタ例外が送出される問題が修正されました。
CR083460	HP_UX での Netscape のサポートに合わせて WebLogic Server が更新されました。
CR083578	[Server Protocols] タブの [メッセージの最大サイズ] テキスト フィールドのサイズが大きくなり、入力されたすべての桁が表示されるようになりました。
CR084114	[WebApp Monitoring] タブで、Web アプリケーションのパフォーマンスをモニタしているときに例外が送出される問題が修正されました。

コア サーバ

変更要求番号	説明
CR055987	HttpURLConnection のタイムアウト オプションが実装されました。
CR066230	ユーザが名前属性 (ドメイン名に合わせて config.xml ファイルで設定) を設定できるようになりました。 config.xml ファイルを手作業で編集し、ドメイン名とは異なる FileName 属性を指定してドメインに Log 要素を追加した場合、サーバはドメインと同じ名前のドメイン ログを作成して使用していました。
CR074835	java.net.HttpURLConnection の変更に対応するように WebLogic Server が変更されました。
CR074888	サーバが 2 つのクラスタでプライマリ サーバが停止されようとしているときに HttpSession のフェイルオーバでエラー 503 を生じさせる問題が修正されました。
CR075321	Operator ロールで weblogic.Admin コマンドを使用して START コマンドを発行できない問題が修正されました。 NoAccessRuntimeException が発生していました。
CR077831	javax クラスをローカルでロードできます。その結果、AppletArchiver ユーティリティを使用してクライアント JAR ファイルを生成するときに発生した問題が修正されました。 問題のアプレットのコードで java.swing.JApplet が使用される場合に、アプレット ビューアで output.jar. java.io.FileNotFound エラーが生成されていました。
CR077919	オブジェクトが StubInfo 型で参照が LocalServerRef である場合に、元のオブジェクトと参照を LeasedRemoteReference に変更させるメソッド replaceObject() の問題が修正されました。
CR079738	大きなメモリ構造の参照が静的である場合に発生した問題が修正されました。この問題を修正するために、クラスローダの参照 WebAppComponent および WebAppServletContext に NULL が割り当てられました。
CR080324	setParent がパブリック API にエクスポーズされていないことが原因で JMS サーバ上の送り先 MBean の配列から新しい送り先 MBean を呼び出すときにエラーを発生させた問題が修正されました。
CR080779	セッションのモニタを有効にした後、セッションが作成されるたびに管理サーバがハングする問題が修正されました。
CR081193	WebLogic Server が数時間動作した後に stdout へのロギングが停止する問題が修正されました。例外は送出されず、サーバは動作を続けていました。さらに、Windows 環境では〔Ctrl〕+〔Break〕の機能が停止し、Unix プラットフォームでは kill -3 でのスレッド ダンプの生成が停止していました。
CR083485	t3 をデフォルト プロトコルとして使用した場合に発生する問題が修正されました。この問題は、t3 クライアントを JavaSocketMuxer でハングさせていました。この修正の結果、t3 クライアントはデフォルト接続にブートストラップする代わりに適切な受信時接続を使用します。

デプロイ

変更要求番号	説明
CR070498	実際のアプリケーションを削除していない場合には、ユーザはアプリケーション MBean を削除できなくなりました。
CR080401	複数のコンテキスト ルートが正しく機能するのを妨げていた問題が修正されました。
CR080914	アプリケーション スコープの接続プールでリソース記述子を使用できるようになりました。 その結果、WebLogic Server では、resource-ref-name 要素で JNDI 名が定義されているかどうかを確認し、ローカル レベルでルックアップを実行して、DataSource が存在する場合にそれを comp/env にバインドすることができるようになりました。
CR081311	web-app.xml ファイルの DTD のチェックで、適切な警告重大度レベルではなく情報重大度レベルの SAXParseException が生成される問題が修正されました。
CR082195	weblogic.Deployer により、クラスタに利用できないメンバーがある場合でも、管理者がクラスタの利用可能なすべてのメンバーを正常にデプロイできるようになりました。
CR082263	Windows 2000 システムから Solaris システム上のサーバにデプロイされた Web アプリケーション WAR ファイルを、weblogic.Deploy で更新できない問題が修正されました。
CR083179	Web アプリケーションの web.xml および weblogic.xml の resource reference デプロイメント記述子に、同期していない resource-ref 要素および resource-description 要素がある場合に表示される WebLogic Server 例外メッセージが改善されました。 以前は、表示される例外メッセージに、問題を生じさせた実際の resource reference 名が含まれていませんでした。

EJB

変更要求番号	説明
CR050001	マルチバイト文字の EJB-QL サポートが提供され、句 '=' および 'IN' で固定漢字文字列を処理できない EJB-QL の問題が修正されました。
CR057074	beans-in-use-number の値が beans-in-cache-number より大きくなる問題が修正されました。この情報は、コンソールのモニタ セクションに表示されます。
CR060965	パーサは、EJB QL クエリで記号 '=' の前後にスペースを許可するようになりました。
CR073297	メッセージ駆動型 Bean が送り先に再接続しようとしても失敗する問題が修正されました。再接続が失敗すると、そのたびにログ メッセージが作成されます。再接続は 10 秒ごとに試行されるので、修正前はログ ファイルがすぐに一杯になっていました。
CR074781	PointBase データベースでテーブルの自動生成が機能しない問題が修正されました。
CR075219	ロールとポリシーが EJB で施行されるようになりました。
CR075273	WAR ファイルの DDInit で weblogic.xml ファイルが出力または作成されない問題が修正されました。 web.xml ファイルは出力されましたが、WEB-INF ディレクトリには作成されませんでした。
CR077104	Required トランザクション属性を持つ読み込み専用エンティティ Bean 間の EJB 2.0 コンテナ管理の関係 (CMR) の 1 対多の関係で、コレクションにアクセスしようしたときに IllegalStateException が生成されなくなりました。
CR077986	EJB 2.0 ejb.jar.xml ファイルにおいて、ワイルドカード「*」がメソッド パーミッションの <unchecked/> で機能するようになりました。
CR078297	同時方式をオプティミスティックに設定した場合にコンテナ管理による永続性 (CMP) のキャッシングが期待通りに機能するようになりました。 以前は、キャッシュが更新される代わりに、2 回目のトランザクションで ejbLoad が呼び出されている、つまりデータベースが外部の変更で更新されていたものと考えられます。
CR078350	生成されたクエリが適切でないためにクエリの生成で CTS 障害が生じる問題が修正されました。
CR079086	JNDI 情報に LDAP サーバを使用するメッセージ駆動型 Bean が、javax.management.MalformedObjectNameException でデプロイに失敗することがなくなりました。
CR079471	SelectDistinct が動的クエリで機能するようになりました。 EJB QL select 句に SelectDistinct のある動的クエリでは重複が返されていました。 Select Distinct を使用する場合、EJB コンテナは重複した結果を排除します。
CR080115	ユーザが CMP Clob 値を出力したときに null 値が返されなくなりました。
CR080783	EJB でグローバル セキュリティ ロールが確実にマークおよび処理されるようになりました。 role-name 要素にグローバルに指定されたプリンシパルが割り当てられる場合は、global-role 要素を weblogic700-ejb-jar.xml ファイルの security-role-assignment スタンザで定義する必要があります。
CR080920	完全委任のセキュリティ チェックを可能にする実行時フラグが追加されました。 以前は、セキュリティ チェックは実行されませんでした。JDBC リソースに対してコンソールで設定されたポリシーは有効にならず、不適切な JDBC リソースがコードによって設定され、新しいプールを作成するための管理リソースを設定する手段がありませんでした。
CR081398	同時方式が排他的で、トランザクション間でキャッシュを使用する Bean 間に 1 対多の関係を持つ EJB 2.0 CMP Bean で illegalException が生成されなくなりました。
CR081807	home を JNDI ツリーにバインドする前に ejb.Deployer がコンテキスト オブジェクトで replicatebindings を true に固定することが原因で発生した問題が修正されました。 この問題が原因で、WebLogic Server がクラスタの他のノードに通知を送信しようとすると、NameAlreadyBoundExcedption が発生していました。
CR082406	WebLogic Server を Sybase データベースおよび Sybase XA ドライバと使用した場合で、EJB の CMP フィールドがバイナリのときにドライバから暗黙の変換エラーが送出されなくなりました。
CR082451	JMS プロバイダが WebLogic 固有でない状況でメッセージ駆動型 Bean のサードパーティ JAR ファイルが正しくロードされず、ClassNotFoundException が発生する問題が修正されました。
CR082749	WebLogic Server 7.0 SP1 の weblogic-rdbms20-persistence-700.dtd に新しいタグが追加されました。その新しいタグ use-select-for-update は、Bean 単位でペシミスティックな同時方式を強制します。このフラグの説明は次のとおりです。 <!-- このフラグに「true」を指定すると、データベースから Bean がロードされるときに SELECT ... FOR UPDATE 句が使用されます。これは、トランザクション レベルではなく Bean レベルで設定する点で、トランザクション アイソレーション レベルの TRANSACTION_READ_COMMITTED_FOR_UPDATE とは異なります。 有効な値は「true」、「True」、「false」、または「False」 デフォルト値 : False 使用される場所 : weblogic-rdbms-bean 導入されたバージョン : WebLogic Server 7.0 SP1 --> <!ELEMENT use-select-for-update (#PCDATA)>

サンプル

変更要求番号	説明
CR073117	RMI-IIOP のサンプルが修正され、ejb cppclients の古い情報が更新されました。サーバ MBean の DefaultGIOPMinorVersion="1" が iiop MBean の DefaultMinorVersion='1' に変更されました。
CR074373	JMS サンプルでタイプ ミスが修正されました。サンプルの手順説明「WebLogic Server のコンフィグレーション」で、手順 10 の後に、JAR 名から -appsdir が抜けていました。
CR075073	セキュリティ プロバイダのサンプルが完成し、WebLogic Server の BEA dev2dev Online (dev2dev) から入手できるようになりました。
CR077817	PointBase コンソールでデフォルト URL が間違っている問題が修正されました。 デフォルト URL で、サーバの後にコロンが抜けていました。
CR078175	WebLogic Server Petstore の手順説明で Petstore EAR ファイルの間違ったディレクトリが参照される問題が修正されました。
CR079455	examples-dataSource-demoPool データソースが oraclePool に変更された場合にサンプル サーバの起動時に致命的な初期化例外が発生する問題が修正されました。この問題は、EJB サンプルの実行時に発生しました。
CR080073	PointBase ファイルがアップグレードされ、アプリケーション データでマルチバイト文字セットのデータを使って CLOB の更新を行うときに PointBase サーバがハングする問題が修正されました。
CR080501	WebLogic Server 製品配布キットに Web サービス サンプルが新たに追加されました。
CR082913	wtc.tBridge サンプルでエラーと例外を生じさせる問題が修正されました。javadocs が更新され、サンプルの実行前に JMS サーバを設定する手順説明が提供されるようになりました。

インターナショナライゼーション

変更要求番号	説明
CR063067	WebLogic Builder のメニュー、アクション、およびドキュメントがインターナショナライズされました。その中には、AppFrame と MainAppFrame のメニューおよびコンソールのアクションが含まれます。

JDBC

変更要求番号	説明
CR080487	DBMS のロールバックが失敗した場合に JTD ドライバがプール接続をリークしなくなりました。
CR082072	JTS 接続の自動コミット動作が機能しない問題が修正されました。
CR082964	Oracle 9.2 に対する以下の WebLogic Server サポートが提供されました。 Oracle 9.0.1 に対する WebLogic Server jDriver サポート Oracle 9.2 に対する WebLogic Server jDriver サポート (動作確認済み) WebLogic Server for Oracle 9.0.1 にバンドルされた従来の Oracle 提供シン ドライバ WebLogic Server for Oracle 9.2 にバンドルされた新しい Oracle 提供シン ドライバ (Oracle で承認審査中)

JMS

変更要求番号	説明
CR063743	Object 型のメッセージ駆動型 Bean がオブジェクト メッセージの確認応答を行うようになりました。
CR075514	コンソールの [メッセージング ブリッジ] タブの [最大待機時間] 属性ラベルで、アイドル時間の単位として (秒) と表示されるべきときに (ミリ秒) と表示される問題が修正されました。
CR075894	[Monitor Durable Subscriber] テーブルで [削除] アイコンが表示されていませんでした。 このため、Administration Console ではトピックから恒久サブスクライバを削除することができませんでした。 このアイコンは現在は表示されます。
CR077814	クライアントの実行時に weblogic.jms.backend.BEMessageReference でメモリ リークが起こらなくなりました。
CR078833	新しい TLOG および JMS ファイル ストアの書き込みオプションが追加されました。このリリースでは、JMS ファイル ストアでの同期書き込み「SynchronousWritesEnabled?」を無効にするコマンドライン -D パラメータが非推奨となっています。適切な方法は、新しいコンソールまたは MBean のコンフィグレーションを使用することです。
CR079855	独自の一般ブリッジ アダプタはコンフィグレーションできないことをユーザに示すドキュメントが用意されました。その説明によると、JMS 以外のメッセージング製品を使用するユーザはサード パーティ OEM ベンダを利用するか、BEA プロフェッショナル サービスに連絡して非 JMS のソース送り先またはターゲット送り先にアクセスできるようにする必要があります。
CR080078	メッセージが適切な送り先に配信できなかった後に JMS メッセージの再配信制限が変わらずにいることがなくなりました。

JNDI

変更要求番号	説明
CR081839	T3Client から InitialContext() を取得するときに NamingException が発生しなくなりました。

JTA

変更要求番号	説明
CR059175	SQL 文を実行している EJB の後に同じトランザクション内で RMI 呼び出しが続く場合に XAException が発生しなくなりました。

JTS

変更要求番号	説明
CR064301	アプリケーションが異常終了したときに不明な分散トランザクションが作成される問題が修正されました。 アプリケーションが再起動された後も、その不明な分散トランザクションは存在し続け、DBA が手動で解決しなければなりませんでした。

その他

変更要求番号	説明
CR067750	アプリケーション スコープのプールの名前とグローバル プールの名前が互いに重複しているかどうかを確認するチェック機能が追加されました。
CR068158	SNMP MIB リファレンスが更新され、新しい WebLogic Server SNMP MBean および属性の説明が追加されました。
CR067987	WebLogic Server のマニュアルで File T3 についてのすべての言及が非推奨とされました。
CR072268	単純な型からの complexType の継承がサポートされるようになりました。
CR072949	障害が本当か偽りかをネイティブ レイヤから分析するために例外メッセージがチェックされます。 問題は、ノード マネージャが管理対象サーバで forceShutdown コマンドを実行しようとし、それによってエラーがユーザに報告され、紛らわしいメッセージがノード マネージャのログに書き込まれる結果になることです。
CR073988	移行可能なサービスをホストしている管理対象サーバのモニタをノード マネージャが再開しない問題が修正されました。
CR074006	複数の MBean 属性が同じ oid を持つ問題が修正されました。
074653	「&」は XML ファイルで「&amp」としてエスケープしなければならない特殊文字であるために、メモリまたはディスクへの書き込み時に「&」が「&amp」で置換される、WebLogic Server Administration Console のデプロイメント記述子エディタの問題が修正されました。
CR075521	一部の検索で間違ったファイルを表示させる重複ファイルを削除することで、オンライン ヘルプの検索の問題が修正されました。
CR075538	ノード マネージャが次のように定義するサーバの特定の状態を説明したドキュメントが提供されました。 ノード マネージャでは、サーバの再起動時に使用するために、管理対象サーバについて独自の内部的な状態が定義されています。ドメインでノード マネージャを使うときは、これらの状態を観察できます。 FAILED_RESTARTING-ノード マネージャは、現在、障害が発生した管理対象サーバを再起動しています。 ACTIVATE_LATER-現在の RestartInterval において MaxRestart 回の再起動が試みられており、ノード マネージャは次の RestartInterval でさらに再起動を試みます。 FAILED_NOT_RESTARTABLE-サーバで障害が発生しましたが、サーバの AutoRestart 属性または AutoKillIfFailed 属性が False に設定されているため、ノード マネージャはサーバを再起動できません。 FAILED_MIGRATABLE-サーバで障害が発生しましたが、サーバの HostsMigratableServices 属性が True に設定されているため、ノード マネージャはサーバを再起動できません。
CR078272	iPlanet プラグインが 64 ビットをサポートする Tru54unix プラットフォームで機能しない問題が修正されました。 64 ビットのサポートを使用するには、iPlanet 6x プラグインの以下の 2 つのバイナリをインストールし、iPlanet 4x プラグイン用の既存のバイナリを置換する必要があります。 libproxy.so libproxy128.so これらのバイナリを入手するには、BEA のサポートに問い合わせてください。
CR078782	コネクタ記述子コードが weblogic-ra.xml ファイルのエンコーディングに従わない問題が修正されました。データは、JMV のデフォルト エンコーディングで読み込まれていました。現在、XML ヘッダのエンコーディング仕様はデプロイメント記述子ファイルと RAR ファイルで適切に処理されます。
CR079186	すべてのプラグインで、折り返されたヘッダが HTTP 1.1 仕様に従って正しく解析されるようになりました。
CR079462	アプリケーション スコープのプールの詳細が weblogic-application.xml ファイルで確実に処理されるようになりました。この修正により、ローカル プロパティが指定されていない場合はグローバル プロパティが使用されることになります。 また、ドライバ、url、および接続プロパティが weblogic-application.xml の jdbc-connection-pool スタンザにない場合に、JDBCDataSourceFactopry の定義は必ずしも使用されません。
CR079672	WarClassFinder.getSource で JVM のクラッシュが引き起こされる問題の解決策が提供されました。
CR079683	jsp.include の使用時に CTE を使用した Apache プラグインで発生する問題が修正されました。 チャンク転送エンコーディングされた HEX 値は、mod_wl_ssl_so の使用時にブラウザに表示されます。
CR079831	7.0 メッセージ カタログの DTD にロギング可能な属性が含まれなかった問題が修正されました (その DTD がこの機能に対応するように更新されなかったため)。これはメッセージ カタログのパーサにとっては問題ではありませんでしたが、汎用 XML エディタでは問題となっていました。
CR079973	Idempotent が OFF および ConnectTimeoutSecs がゼロに設定されているサーバへの接続が複数回試行される問題が、Idempotent が OFF の場合はフェイルオーバを防止し、ConnectTimeoutSecs がゼロの場合はコア ダンプを防止することで解決されました。
CR080016	アプリケーションが仮想ホストをターゲットとしており、その仮想ホストが管理対象サーバおよび管理サーバをターゲットとしている場合に、WebLogic 管理サーバの起動中にそのアプリケーションをデプロイすると発生した問題が修正されました。
CR080073	マルチバイト文字セットのデータがアプリケーション データで使用されている場合に、CLOB の更新時に PointBase サーバがハングする問題が修正されました。
CR080219	WebLogic Server のすべてのインスタンスを停止するときに iPlanet でコア ダンプが生じる問題が修正されました。
CR080249	WebLogic Server 7.0 の管理サーバが NT サービスとして設定されている場合にノード マネージャと通信できない問題が修正されました。
CR080257	HTTP リクエストの最初の行が正しくフォーマットされていない場合に NegativeArraySizeException が発生する問題が修正されました。
CR080382	次の設定で NSAPI プラグインを使用しているときに、予期しないエラー メッセージが iPlanet Web Server のエラー ログに記録される問題が修正されました。 ErrorPage=[any]
CR080746	ネイティブ Web サーバ プラグインで 64 ビット プラットフォームのサポートが提供されました。
CR080931	CallableStatement を使用した後に PreparedStatement が min_bind_size と機能しない Oracle jDriver の問題が、db¥oci¥OciConnection.java を変更することで修正されました。
CR081377	デプロイメント時にコンテキスト クラス ローダを通じてクラスをロードしたときに発生する問題が修正されました。
CR081625	WebLogic Server に PointBase 4.3 が追加されました。
CR082081	t3 の使用時に weblogic.Admin SERVERLOG コマンドライン ユーティリティが失敗する問題が修正されました。
CR082093	プロキシに呼び出しが到達するたびにアプリケーション サーバに対して複数の呼び出しが行われる、WebLogic Server および NSAPI プラグインの問題が修正されました。
CR082096	Idempotent が OFF に設定されている場合に発生し、IIS プロキシ プラグインでサーバの後にすべての POST リクエストに対して 1 度の再試行を試みさせる問題が修正されました。
CR082113	WebLogic Server-ISAPI プラグインがクライアントからのデータの読み込み時にエラーを受信し、バックエンドの WebLogic Server に不完全なデータ (リクエスト) を送信したときに発生する問題が修正されました。
CR082939	ISAPI プラグインの問題が修正され、セッション ID の異なる形式に対応するようになりました。
CR083151	EAR ファイルでコマンドライン ddinit が機能しない、weblogic.Builder の問題が修正されました。
CR083174	セッションに新しい値を追加するときに最新の IIS プラグインが機能しない問題が修正されました。 たとえば、IIS では、メソッド KeepAliveEnabled=true が正しくフェイルオーバされません。
CR083643	POST データを読み込もうとするときの NSAPI プラグインのパフォーマンスが改善されました。 問題は、POST データで ¥0 と 0 を区別するときに発生しました。

RMI/RMI-IIOP

変更要求番号	説明
CR073691	RMI-IIOP のトレース機能が実装されました。
CR074790	アプレット内で RMI-IIOP を使用するときに AccessControlExceptions が生じる問題が修正されました。
CR076974	リクエストがないときに weblogic.rmi.ReplyOnError.execute が失敗する問題が修正されました。
CR079387	RMI-IIOP でサブコンテキストが壊れる問題が修正されました。JNDI でサブコンテキストをルックアップすると、代わりにルート コンテキストが表示されます。
CR079439	Any のメソッドで渡された文字列が不正確にコード化される問題が修正されました。この問題は、Object、Serializable、または Externalizable の宣言型を持つリモート関数に文字列を渡すときに発生します。
CR079454	interop listBindings がまったく機能しない問題が修正されました。
CR079645	OBJECT_NOT_EXIST などの CORBA プロトコル例外が間違って RMI-IIOP java.rmi.MarshalException にマッピングされています。
CR079648	IOR が TransactionFactory に対して定義されず、それが原因でユーザがクライアントから OTS TransactionFactory を取得できない問題が修正されました。
CR079918	動的プロキシがシリアライズ可能でないために発生する問題が修正されました。この問題は、RMI オブジェクトが各クライアントで EJB からクライアントへのコールバック リクエストを容易にするために使用されたときに発生しました。
CR080239	IDL パッケージの名前が正しく管理されない問題が修正されました。
CR080259	boxed RMI シーケンスのコンポーネント型で valuetype の間違ったシーケンスが生成される問題が修正されました。
CR080306	特定の環境において、valuetype の例外で継承した基本クラスが脱落する問題が修正されました。
CR081135	リクエストのサービス コンテキストが大きい場合にフラグメンテーションとなる問題が修正されました。
CR081923	IncompatibleClassChangeError を発生させる RMI/IIOP スタブ コード生成の問題が修正されました。 生成されたスタブでは、RemarshalException が正しく処理されませんでした。
CR083018	WebLogic Server で、間接的な型コードを使用して Any のメソッド型をアンマーシャリングできない問題が修正されました。

セキュリティ

変更要求番号	説明
CR069969	WebLogic Server で信頼性のある CA をロードできるようにする新しいアルゴリズムが作成されました。以前は、ユーザが信頼性のある CA をコンフィグレーションしなかった場合、WebLogic Server では JDK cacerts ファイルからデフォルトの信頼性のある CA をロードしていました。
CR070307	相互 SSL 用にコンフィグレーションされているサーバをユーザが起動したときに発生するサーバ障害の問題が修正されました。
CR071894	デフォルト キーストアで、プライベート キーまたはルート CA キーストアがコンフィグレーションされているが、ファイルが存在しないか、指定の場所にない場合に情報メッセージがログに記録されるようになりました。
CR072902	信頼性のある証明書をロードするためのアルゴリズムが修正されました。
CR073082	Solaris 上で証明書を生成するときに、CertGen で、証明書の共通名フィールドにドメイン名が追加されることがなくなりました。 Solaris 上で HostNameVerification が有効になっても、それはホスト名の不一致が原因で失敗します。
CR073665	iPlanet プロキシ サーバを通じて HTTPS をトンネリングするときに、ProtocolException が発生しなくなりました。
CR073941	デフォルト キーストアでエラー メッセージをログに記録できるようになりました。
CR074102	Administration Console でデフォルトのクッキー名を使用できなくなる問題が修正されました。別の Web アプリケーションを通じてコンソールをロードしようとした場合に、コンソールと同じクッキー (ADMINCONSOLESESSION) を持つように Web アプリケーションをコンフィグレーションしない限りは、シングル サインオンでアクセスすることができませんでした。 結果として、コンソールと Web アプリケーションのシングル サインオン (SSO) メカニズムの間でクッキー名の衝突が生じていました。
CR074612	jdk ディレクトリで指定された cacert ファイルが存在せず、信頼性のある cacert ファイルの位置がコマンドラインで指定されたことが原因で WebLogic Server の起動時に SSL が起動しない問題が修正されました。
CR075172	SSL ハンドシェークが、コンフィグレーションされているルート キーストアで CA 証明書を見つけることができないときに生じる問題が修正されました。
CR075901	埋め込み LDAP に 50000 ユーザがロードされている状態でユーザを表示するときの、コンソールのリストの処理方法に関する問題が修正されました。
CR076409	NTSocket Muxer のクラッシュを生じさせる問題が修正されました。この問題は、サーバへの接続を作成する Perl スクリプトの使用時に表面化しました。そのスクリプトが原因で、Web サーバがクラッシュしました。
CR076945	LDAP ファイルの破損の可能性が原因で WebLogic Server の起動時に発生する問題が修正されました。この問題では、よく java.lang.OutOfMemory エラーが生じます。
CR078249	LDAP V2 レルムのネストされたグループが機能しなくなる問題が修正されました。
CR078797	EJB コンテナがすべてのメソッド (除外されていないまたはチェックされているメソッドを除く) でメソッド パーミッションを確認したときに、セキュリティ制限の設定されていないメソッドでユーザが実行パーミッションを拒否される問題が修正されました。
CR078887	埋め込み LDAP サーバへの匿名ログインを無効にして、匿名ログインを禁止にする手段が提供されました。
CR080072	プライベート キー ストア、エリアス、およびパスワードが config.xml ファイルで指定された 7.0 SSL コンフィグレーションを持つ 7.0 バージョンの WebLogic Server がデフォルトで 6.x SSL コンフィグレーションになる問題が修正されました。
CR080490	DefaultKeyStore プロバイダが非 JKS JDK キーストアをサポートしない問題が修正されました。
CR080508	厳重なサーブレット セキュリティをサポートできるように WebResource が更新されました。
CR080567	LDAP からのエラー メッセージが管理サーバのログに表示される問題が修正されました。VDE サーバは、現在、変更ログの短縮の後に正しくレプリケートするようになりました。
CR081494	ロール マッピングおよび AccessDecision セキュリティ サービス プロバイダ インタフェース (SSPI) は、コンテキスト ハンドラを介して HttpServletRequest および HttpServletResponse オブジェクトにアクセスできるようになりました。次に例を示します。 HttpServletRequest req = (HttpServletRequest) context.getValue("HttpServletRequest"); HttpServletResponse res = (HttpServletResponse) context.getValue("HttpServletResponse"); 応答から返される情報はクッキーに設定できます。これらのオブジェクトは URL リソースでのみ機能します。このコードは、他のすべてのタイプの WebLogic リソースでは null を返します。
CR083125	weblogic.security.service.URLResource クラスが Windows 上で他のプラットフォームとは異なる動作をする問題が修正されました。Windows 上で、このクラスは contextPath と URI を小文字に変換していました。この問題は、contextPath と URI が Windows 上では大文字と小文字が区別されないことが原因で発生しました。 デフォルトの動作を変更するには、以下のフラグのいずれかを設定する必要がありました。 -Dweblogic.security.URLResourceCaseMapping=on -Dweblogic.security.URLResourceCaseMapping=off -Dweblogic.security.URLResourceCaseMapping=os フラグを on に設定すると、contextPath と URI が常に小文字にマッピングされます。 フラグを off に設定すると、contextPath と URI は小文字にマッピングされません。 フラグを os に設定すると、contextPath と URI は Windows 上では小文字にマッピングされます。 このフラグは、Windows マシンとそれ以外のマシンが混在する環境でドメインを実行する場合にのみ設定する必要がありました。 その場合、フラグを on に設定することで、すべてのプラットフォームで問題が解決されましたが、Windows 以外のシステムで大文字と小文字が区別されなくなりました。

サーブレットと JSP

変更要求番号	説明
CR042655	access.log ファイルの拡張ログ フォーマットの時刻書式でエラーが修正されました。時刻は GMT で表示されるようになりました。
CR074096	匿名ユーザとして実行されたときにサーブレットの <init> メソッドで MBean アクセスが存在しない問題が修正されました。 run-as identify の代わりに使用される、2 つの新しい要素が weblogic.xml デプロイメント記述子ファイルに追加されました。
CR074843	式が Null の場合に空の文字列を出力するために使用する JSP のリクエスト時属性で文字列 Null が出力されるように WebLogic Server がアップグレードされました。 WebLogic Server の旧バージョンでは、JSP のリクエスト時属性 (<%= expr %>) は、式が Null の時には空の文字列を出力します。現在は、文字列「null」を出力するようになっています。JSP の仕様では、式のデフォルトは「null」でなければならないと規定されています。 ただし、weblogic.xml に printNulls という名前の新しいフラグが導入されています。 フラグのデフォルト値 true は、デフォルトの出力が「null」であることを意味しています。 このフラグを false に設定すると、「null」の式が "" として出力されます (以前の動作)。 weblogic.xml の printNulls タグのコンフィグレーション: <weblogic-web-app> <jsp-descriptor> <jsp-param> <param-name>printNulls</param-name> <param-value>false</param-value> </jsp-param> </jsp-descriptor> </weblogic-web-app> また、次のように指定して weblogic.jspc からコンパイルできます。 -noPrintNulls これにより、JSP の式の「null」も "" (空の文字列) として示されます。
CR075805	weblogic.servlet.security.ServletAuthentication に新しい runAs メソッドを追加することで、HttpSession の現在の主体を設定する手段が実装されました。
CR076330	サーバが名前にピリオドのある JAR ファイルから Web アプリケーション クラスをロードできない問題が修正されました。
CR077823	プラグインのパラメータ情報の更新を反映して、『管理者ガイド』と『WebLogic Server における Web サーバ プラグインの使い方』のプラグイン情報が更新されました。
CR077944	JSP2XmlOutputter が dequote() を不適切に呼び出して解析エラーが生じる JSP タグの問題が修正されました。
CR078698	サイズが 2MB を超えたときに access.log ファイルがサイズを基準にローテーションされることを妨げる問題が修正されました。
CR078725	チャンク転送エンコーディングされた応答を HttpClusterServlet がデコードする問題が修正されました。
CR079892	複数のブラウザ ウィンドウから CGI スクリプトを実行し、そのプロセスの途中ですべてのブラウザで停止ボタンを押したときに CPU 使用率が 100% になる問題が、文字セットが Context-Type で定義されている巨大な CGI スクリプトを実行するときにハング スレッドを防ぐことで修正されました。
CR079924	weblogic.xml ファイルに新しい要素 wl-dispatch-policy を追加することで、web-app レベルでディスパッチ ポリシーを定義する機能が提供されました。
CR080090	FrontEndHTTPPort、FrontEndHTTPSPort、および FrontEndPort が普遍的に優先されるようになりました (定義されている場合)。これらは、リダイレクト時に常に使用する必要があります。
CR080445	WebLogic Server が config.xml ファイルの server セクションの WeblogicPluginEnabled=true を認識できない問題が修正されました。これが原因で、不正確なクライアント マシンのアドレスがヘッダで渡されていました。
CR080554	IIS および iPlanet が WebLogic Server に URL 書き換えのための jsessionid 識別子を渡さない問題が、EncodeSessionIdInQueryParams プロパティを導入することで修正されました。
CR080608	weblogic.servlet.security.ServletAuthentication weak 文字列で常に FAILED_AUTHENTICATION が返される問題が修正されました。
CR080613	引用符で囲まれた文字列値で特殊文字を使用できるように WebLogic Server が更新されました。以前は、クッキーの引用符で囲まれた値でカンマを使用できませんでした。
CR080648	指定されたロールをグローバル ロールとしてマークする global-role という新しい属性が追加されました。
CR080751	エラー ページのカスタム例外へのマッピングに関する問題が修正されました。この問題は、ServletException を拡張したカスタム例外クラスがサーブレット 2.3 仕様に完全に準拠していなかったことが原因で発生しました。
CR080772	ユーザが文字セットに余計な引用符を付けた場合に UnsupportedEncodingExecption を発生させた問題が修正されました。
CR080791	HttpClusterServlet および HttpProxyServlet で折り返されたヘッダを正しく処理する機能が提供されました。
CR081253	WebLogic Server がチャンク コーディングされた HTTP リクエストを正しく解析できない問題が修正されました。
CR081484	PersistentStoreType が replicated として指定された HttpSessionListener を使用したときにセッション属性が失われる問題が修正されました。
CR081521	JSP から呼び出された CGI スクリプトが WAR ファイルまたは EAR ファイルで機能しない問題が修正されました。
CR081792	HttpServletRequestWrapper の型チェックが緩和されて、サーブレット エンジンで HttpServletRequestWrapper の代わりに ServletRequestWrapper を使用できるようになりました。
CR082156	isRequestedSessionIdValid() で常に値 true が返される (つまり、URL でセッション ID を変更してもリクエスト セッション ID が有効となる) 問題が修正されました。
CR082238	CacheSessionCookie というセッション記述子が weblogic.xml ファイルに追加されました。 この記述子は、デフォルトで false に設定されます。 true に設定すると、Cache-Control ヘッダが追加されません。
CR082310	ユーザが展開された WAR ファイルで「page contentType」ディレクティブのある JSP を削除または上書きできない問題が修正されました。解決策は、JSP パーサの入力ストリームが使用後に確実に閉じられるようにすることでした。
CR082461	FileServlet が機能しない問題が修正されました。 docHome パラメータが指定されている場合に目的のファイル名を作成するために使用される PATH_INFO の先頭に SERVLET_PATH が付加されないようになりました。
CR082636	空の auth 制約で fullSecurityDelegation モードのアクセスが制限されない問題が修正されました。
CR083200	WebLogic Server が nonProxyHosts を正しくフィルタ処理できない問題が修正されました。 WebLogic Server は、http.nonProxyHosts と nonProxyHosts の両方に対応するようになりました。
CR083517	SecureProxy が有効な場合でも HttpClusterServlet で SSL にリクエストをプロキシできない問題が修正されました。
CR083654	マルチバイト文字セットをコンテンツ タイプとして使用するサーブレットおよび JSP のパフォーマンスを向上させることで、パフォーマンスの問題が改善されました。

ツール

変更要求番号	説明
CR074535	DDinit が再帰的な関連を認識できない、weblogic.Builder の問題が修正されました。
CR074535	DDinit が再帰的な関連を認識できない、weblogic.Builder の問題が修正されました。
CR074570	DDinit が cmr フィールドを cmp フィールドと間違える、weblogic.Builder の問題が修正されました。
CR074620	関係が 1 対 1 の場合でもウィザードの [Bi-directional] フィールドがチェックされている場合は CMP フィールド タイプが有効になる、weblogic.Builder の問題が修正されました。
CR074629	ユーザが [Connect to Server] ダイアログ ボックスで何らかの参照アクションに対して取り消しボタンを押したときに [Illegal DatasSource] ダイアログ ボックスが表示される、weblogic.Builder の問題が修正されました。
CR074689	[create duplicate environments] フィールドをチェックすることで不完全な XML が生成される、weblogic.Builder の問題が修正されました。
CR074764	ステートフル セッション Bean のチューニング パネルに欠けている [set cache-type] フィールドが [Session Advanced] パネルに追加されました。
CR074773	XMLElement ジェネレータで、allow-concurrent-calls の指定されたステートフル セッション EJB の XML コードを生成できない問題が修正されました。
CR074995	ユーザが関係を削除したときに、XML は削除されるが、モジュールは modified とマークされない、weblogic.Builder の問題が修正されました。モジュールが閉じるときに、ユーザには変更の保存が求められませんでした。
CR075034	[EJB|Tuning|Cluster] パネルで新しい多重呼び出し不変メソッドを追加すると java.lang. IllegalArgumentException が発生する、weblogic.Builder の問題が修正されました。
CR075521	さまざまなトピックの検索で間違ったページが表示される、weblogic.Builder オンライン ヘルプの問題が修正されました。
CR075537	実行中のドメインのクラスタに追加されたサーバがサーバの新しいクラスタにデプロイされない、weblogic.Deployer の問題が修正されました。 クラスタにサーバを追加して、管理対象サーバを再起動した場合、そのクラスタをターゲットとし、そのクラスタにデプロイされていた Web アプリケーションは追加サーバで自動的にデプロイされません。
CR075672	methods-are idempotent が非推奨になったため、weblogic.Builder で [Methods Are Idempotent] チェックボックスが削除されました。ステートレス セッション EJB で多重呼び出し不変のメソッドを追加する手段が開発されました。多重呼び出し不変のメソッドは、[クラスタ] パネルで指定できるようになりました。
CR075937	weblogic.Builder が EJB デプロイメント記述子 max-cache-size で無効な値を書き込む問題が修正されました。
CR077171	DDinit がコンテナ管理の永続性 (cmp) 記述子で間違ったバージョンを設定する、weblogic.Builder の問題が修正されました。
CR078747	weblogic.Builder が ejb11_container_managed.jar ファイルを開くことができない問題が修正されました。
CR081213	weblogic.Builder のステート Bean の [一般] タブでステートレス セッション Bean とステートフル セッション Bean のチェックボックスを切り替えるときに nullPointerException が発生する問題が修正されました。
CR081325	DDInit が Web アプリケーションの EJB Ref と Resource Ref および Bean の Resource Ref で JNDI 名を割り当てない、weblogic.Builder の問題が修正されました。

WebLogic Tuxedo Connector

変更要求番号	説明
CR078774	Tuxedo /Q からメッセージを取り出したときに応答がなくなる、tBridge セッションの接続の問題が修正されました。

Web サービス

変更要求番号	説明
CR066226	WebLogic Server で、相互 SSL 認証に RPC タイプの Web サービスを提供できるようになりました。
CR069027	wsdl クライアントと協調して複合データ型の使われる Web サービスを呼び出すのを妨げる問題が修正されました。
CR072268	WebLogic Web サービスでは、単純な型から継承された complexTypes のある XML スキーマはサポートされていません。
CR073539	余計な「/」が誤って付けられていた、Web サービスのホーム ページの壊れたリンクが修正されました。
CR075634	生成されたスタブが echo"Struct で doc/lit を処理できない問題が修正されました。
CR076677	wsdl クライアントと協調して複合データ型の使われる Web サービスを呼び出すのを妨げる問題が修正されました。
CR077849	英語の環境でマルチバイト文字列が Web サービスによって壊される問題が修正されました。
CR077855	URL.getContext() の使用時に Java クライアントから Web サービスにアクセスしようとすると NullPointerException が発生する問題が修正されました。
CR078313	スタブ クライアントの.net サービスとの相互運用が失敗したときに断続的に発生する接続の問題が修正されました。
CR078442	サービスの生成で protocol=https を使用した場合と使用しない場合の両方で生成された Web サービスのホーム ページに HTTPS を通じてアクセスすることで認証ログイン ダイアログが表示される問題が修正されました。
CR078804	Web Services Stateless Session サンプルで非パブリック API import weblogic.ejb.GenericSessionBean が使用される問題が修正されました。
CR079620	SOAP メッセージが RFC2376 に準拠しました。
CR079976	clientgen などのタスクの使用時に HTTP プロキシ サーバを指定しようとして発生する問題が、proxyHost 属性および proxyPort 属性を clientgen に追加することで修正されました。
CR079984	Web サービスのサンプルに webservices.jar ファイルがあるかどうかを確認する機能が無効になりました。
CR080152	WebLogic Server の dateTime の解析に関する問題が修正されました。
CR080154	HTTP プロトコル、およびメソッド シグネチャで int または string の配列を使用したときに認証画面が表示される問題が修正されました。
CR080264	SOAP 応答が HTTP ヘッダに必須の utf-8 contentType を持たない問題が修正されました。
CR080961	XML パーサ Xerces 1.3.1 の org.xml.sax.helpers.AttributesImpl.removeAttribute() 呼び出しのバグに対する対処法が開発されました。
CR081570	プロパティの set または get メソッドがないときに servicegen が失敗する問題が、ゲッター メソッドとセッター メソッドの両方を持たない Java Bean プロパティを無視することで解決されました。