リリース ノート

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

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

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

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

Administration Console

変更要求番号	説明
CR093082	コンソールの SSL コンフィグレーションのページで、キーのエリアスとパスワードを設定できませんでした。 現在、SSL コンフィグレーションのページでは、ユーザがキーのエリアスとパスワードの設定値を変更した場合、それが表示されるようになりました。
CR103417	EJB のモニタ ページはキャッシュされていたため、適切に更新されていませんでした。 ブラウザのページをキャッシュするタグが削除されたため、ページが適切に更新されるようになりました。
CR106457	weblogic-rdbms-jar の weblogic-rdbms-bean 要素のみが XML に変換されていました。そのため、weblogic-rdbms-jar 要素が完全に表示されていませんでした。 現在の WebLogic Server では、weblogic-rdbms-jar.xml デプロイメント記述子のすべての要素が表示されるように weblogic-rdbms-jar 要素を XML に変換します。
CR106773	EJB にパッケージがない場合、EJB の完全パッケージから最初のパッケージ名を取り出そうとすると、indexOutOfBounds 例外が送出されます。 現在は、EJB にパッケージがない場合、jCOM コンポーネントのアクセスに対するポリシーを定義するときに、デフォルトのパッケージとしてアスタリスク (*) が表示されます。その結果、EJB にパッケージがない場合でも、indexOutOfBounds は送出されなくなりました。
CR111502	モジュールを割り当てるときに、Internet Explorer を使用して WebLogic Console から新しい WebLogic Portal アプリケーションをデプロイしようとすると、URL の長さが最大の制限を超えたためデプロイできませんでした。 現在の WebLogic Server では、アプリケーションの中の EJB と Web アプリケーションの名前を、URL の一部としてではなく、隠し属性として渡します。 その結果、複数のコンポーネントを持つアプリケーションが、javascript エラーなしでデプロイされるようになりました。
CR112354	WebLogic Server は、選択されたプール名があるかどうか ConnectionPool リストでチェックしていましたが、MultiPool リストではチェックしていませんでした。 現在は、選択されたプール名があるかどうか両方のリストでチェックします。また、Administration Console で、MultiPool に DataSource と TXDataSource を割り当てることができます。
CR119472	同じインスタンスを使用する 2 つのタグで実際の値が反映されていなかったため、 setTextId メソッドはテキストをリセットしていませんでした。 正しい値を表示するように、setTextId メソッドのテキストがリセットされるようになりました。
CR122362	Administration Console で、[サーバ｜プロトコル｜ HTTP] タブに [最大 POST 時間] 属性がありませんでした。 [サーバ｜プロトコル｜ HTTP] タブに [最大 POST 時間] 属性が表示されるようになりました。
CR122403	フィルタ処理は、「if name starts with」条件に基づいて行われていました。そのため、他の接続プールの名前が、指定されたプール名と同じ文字で始まっている場合、他の接続プールに割り当てられているサーバが返されました。 フィルタ処理は、完全一致を検索するように変更されました。指定された接続プールに割り当てられたサーバのみが返されるようになりました。
CR124223	コンポーネントがサーバの対象となっているかどうかを確認する際、サーバのみがチェックされ、クラスタはチェックされていませんでした。 現在の WebLogic Server では、サーバとそのサーバが属するクラスタをチェックします。その結果、クラスタの対象になっているコンポーネント (アプリケーション、JDBC 接続プールなど) は、サーバがそのクラスタに属していれば、サーバにデプロイされているものとして表示されます。
CR125334	サーブレットのテーブルでは、[URL パターン] をクリックしても配列が正しくソートされませんでした。属性の型が配列である場合、長さの異なる配列を比較するときに例外が送出されていました。 配列型の属性が正しくソートされ、例外が送出されないように、配列の属性を比較するメソッドが修正されました。
CR126074	WebLogic Server では、Context クラスの listBinding メソッドを使用し、すべてのオブジェクトを完全に解決しようとしていました。オブジェクトの解決に失敗すると例外が送出されました。 オブジェクトの解決は Administration Console で行われるようになりました。オブジェクトを解決できない場合、WebLogic Server はその名前に赤い丸を付けて表示します。
CR129373	WebLogic Server が属性を html に渡すとき、ピリオド (.) がアンダースコア (_) で置き換えられました。属性の修飾名にアンダースコア (_) が含まれている場合は、サーバに返されるときにピリオド (.) で置き換えられました。そのため、インスタンスが見つからず例外が送出されました。 現在の WebLogic Server では、修飾名にあるアンダースコア (_) をコロン (:) で置き換えます。属性名から属性の修飾名に変換されるときはその反対の処理が行われます。 こうして、修飾名のアンダースコア (_) は保持されます。
CR129518	リモート マシンを使用して WAR、RAR、または JAR ファイルをアップロードしようとしたとき、WebLogic Server が現在のパスを見つけられなかったため、ファイルがアップロードされずに、アップロード画面に戻っていました。 WebLogic Server は現在のパスを取得して、上記のタイプのファイルをアップロードできるようになりました。
CR129551	カスタム裁決プロバイダからデフォルト裁決プロバイダに戻すことはできませんでした。 レルムに裁決プロバイダがすでに存在している場合でも、そのプロバイダを置き換えるコードが追加されました。その結果、デフォルト裁決プロバイダに戻せるようになりました。
CR130110	相対パスではなく絶対パスが指定された場合に、アップロード ディレクトリの問題がありました。 WebLogic Server は、アップロードの際に相対パスか絶対パスかをチェックするようになりました。
CR130369	配列型の引数を持つ WebService メソッドに対してセキュリティ ポリシーを定義しようとすると、Administration Console で Javascript 実行時エラーが発生していました。 現在の WebLogic Server では、セキュリティ サブシステムに対応する形式の配列パラメータを持つメソッド シグネチャが作成されます。その結果、配列の引数を含むメソッドに対してポリシーを定義するときに、Javascript 実行時エラーが発生しなくなりました。
CR161951	Administration Console で [レルム｜ myrealm ｜プロバイダ｜認証] の順にクリックしたときに、カスタム認証プロバイダのページに [コンフィグレーション済み認証プロバイダの並べ替え] リンクが表示されませんでした。 現在は、コンソールでこの順にクリックすると [コンフィグレーション済み認証プロバイダの並べ替え] リンクが表示されます。
CR172966 CR129054	コンソール ログのログ メッセージが切り詰められていました。 現在は、エスケープ文字が正しく処理され、ログ メッセージが切り詰められることはなくなりました。
CR178780	WTC では、インポートされたサービス、エクスポートされたサービス、およびリモート ドメインが 1 つの組とみなされ、リソース名、ローカル ドメイン、およびリモート ドメインの組み合わせがユニークでなければなりません。Administration Console では、インポートされたサービス、エクスポートされたサービス、およびリモート ドメインを同じリソース名で定義することはできませんでした。 現在の WebLogic Server では、属性値だけでなく、その組がユニークかどうかをチェックします。
CR181865	Administration Console では、あるメンバーの JMS サーバが対象に指定されていない場合でも、JMS 分散送り先にそのメンバーを追加することができました。 現在は、メンバーの JMS サーバが対象に指定されていない場合、そのメンバーを JMS 分散送り先に追加することはできません。
CR183641	管理サーバを使用して、管理対象サーバ上で実行されるトランザクションの情報を取得したときに、情報が正しくありませんでした。 現在の WebLogic Server では、トランザクション情報を、そのトランザクションに関連付けられているサーバの 1 つから取得するようになりました。
CR184784 CR183444 CR201566 CR183444 CR132832 CR197295	WebLogic Server Administration Console では、グループ名、ユーザ名、およびロール名で、スペースやハイフンなどの特定の文字が使用できませんでした。そのため、他のアプリケーションで生成された、スペースやハイフンを含むユーザ証明書は、WebLogic Server では無効になる可能性がありました。 現在は、ユーザ名、グループ名、およびロール名で、これらの特殊な文字を使用できます。
CR186293	1. 左のナビゲーション ペインで、ブラウザから設定された言語が尊重されませんでした。コンソールのプリファレンスのページから設定された言語設定が尊重されていました。 2. コンソールの左右のナビゲーション ペインで、コンソールのプリファレンス設定ページから設定された言語が尊重されませんでした。 要求が行われるときに、サーバに accept-language ヘッダを渡すアプレットが作成されました。WebLogic Server は、左のナビゲーション ペインで、ブラウザから設定された言語を尊重するようになりました。 コンソール拡張機能はデプロイされるときに現在の言語をヘルパー クラスに渡します。それによって、コンソール拡張機能の適切なカタログが検索され、拡張機能が正しくローカライズされます。
CR187204	Administration Console のパフォーマンス モニタ グラフが、ガベージ コレクションを強制 ([ガベージコレクションを強制する] ボタンをクリック) した直後にフリーズしていました。 現在、グラフ収集スレッドはブラウザが閉じるまで停止しません。 その結果、パフォーマンス モニタ グラフはガベージ コレクションの強制後にフリーズしなくなりました。
CR189027	コンソールで Web アプリケーション テーブルの表示に時間がかかりました。デプロイされる Web アプリケーションが多くなるほど、Web アプリケーション テーブルの表示が遅くなりました。 現在の WebLogic Server では、Web アプリケーションの実行時 MBean を取得する際の呼び出しを少なくしました。 その結果、Web アプリケーション テーブルの表示が速くなり、デプロイされている Web アプリケーションが増えるにつれて速度が上がるようになりました。
CR190524	WebLogic Server は、WebLogic Server 8.1 SP2 から SP3 への移行後にコンソール拡張の NullPointerException を送出していました。 現在の WebLogic Server では、表示名属性と代わりの名前の属性がカタログに用意されています。この属性を使用すると、カタログでわかりやすい名前を保持し、サービス パック間の互換性を維持することができます。その結果、WebLogic Server は WebLogic Server 8.1 SP2 から SP3 への移行後にコンソール拡張の NullPointerException を送出しなくなりました。
CR190752	PoolParamsMBean の他の属性はコンソールに表示されていないのに、JDBC 接続プール固有のプロパティである RemoveInfectedConnectionsEnabled 属性は表示されていました。 現在、PoolParamsMBean の他の属性と一致するように、RemoveInfectedConnectionsEnabled 属性は表示できなくなりました。その結果、WebLogic Server は、アプリケーションスコープの JDBC 接続プールの記述子が編集されるときに例外を送出しなくなりました。

クラスローダ

変更要求番号	説明
CR177678	Class.getSigners() メソッドは、署名された jar ファイルにクラスが含まれている場合、証明書を返しませんでした。 現在の WebLogic Server では、jar ファイルからクラスをロードする場合、ZipFile ではなく JarFile からバイトを取得します。そのため、Class.getSigners() メソッドは、署名された jar ファイルからクラスがロードされた場合、証明書を返します。

クラスタ

変更要求番号	説明
CR177776 CR201676	レプリケートされたセッション http リクエストが、リクエストのプライマリとしてもセカンダリとしても機能していないサーバに届いた場合に、クラスタで分散デッドロックが発生しました。このような複数のリクエストがクラスタ内のサーバに届くと、この動作が原因でデフォルト スレッド プール内のすべてのスレッドが消費されて、ある時点になると、応答の受信に使用できるスレッドがデフォルト スレッド プール内にありませんでした。その結果分散デッドロックが発生しました。 このような状況でデッドロックが発生しなくなりました。

コネクタ

変更要求番号	説明
CR176209 CR183827	当初は out デバッグ文でトランザクション オブジェクトを使用していました。その結果 ConcurrentModificationException が発生しました。 デバッグ文からトランザクション オブジェクトが削除されたので、この例外はなくなりました。
CR184164	基本の RAR が最初にデプロイされる場合でも、RAR のグループがデプロイされると、警告 (BEA-190085) が送出されました。 ログ メッセージは、警告から情報メッセージに変更されました。
CR190895	コネクタ プールとプロセス接続リクエストのパフォーマンスを大幅に向上させる変更が行われました。 その 1 つは、weblogic-ra.xml 記述子に新しい use-first-available 要素を追加したことです。use-first-available を true に設定すると、コネクタ プールでは、すべての接続が同じ属性を共有しており、接続リクエストに対して、どの接続を利用しても同じになると想定します。このオプションを使用すると、コネクタ コンテナがアダプタの matchManagedConnection を呼び出す必要がなくなり、パフォーマンスが向上します。

コア WebLogic Server

変更要求番号	説明
CR126838 CR196450	WebLogic Server のスタック スレッドの警告メッセージが、単なる警告メッセージとして、個々のサーバ ログ ファイルにのみ記録されていました。メッセージをエラー メッセージに変更して、ドメイン レベルのログ ファイルにも記録されるようにしました。
CR127920 CR190968 CR197708	HeartbeatHelper オブジェクトはクライアント サイドでサーバの ping に使用されます。このオブジェクトがキャッシュされており、サーバの再起動時にクライアントが ping を試行すると、ping はそのサーバに拒否されました。その結果 IllegalStateException が発生しました。現在、HeartbeatHelper は cos NamingService からルックアップされます。キャッシュはされなくなりました。
CR175772	Linux 上でキープアライブ接続がタイムアウトした後、WebLogic Server はクライアントからの POST リクエストを受け付けることができませんでした。 現在は、ソケットを閉じる前に、ソケットの入出力を停止します。その結果、Linux 上でキープアライブ接続がタイムアウトした後に、クライアントからの POST リクエストを受け付けられるようになりました。
CR175808	ClusterRuntime MBean 名では、クラスタ名ではなくサーバ名を使用していました。 ClusterRuntimeMBean 名が正しく初期化されるようになりました。現在は ClusterRuntimeMBean 名が MBean に適切に反映されます。
CR176331	ソケットのクリーンアップ中にマルチプレクサから NullPointerException が送出されることがありました。 これは、プロトコル識別子に適切な多重化可能ソケットが設定されていない場合に発生しました。 現在は、識別の際に適切な多重化可能ソケットを設定して、例外を送出する場合に正しい多重化可能ソケットを使用できるようになりました。
CR178205 CR121483	管理サーバの MBean の getAttributes を呼び出すと、ConcurrentModificationException 例外が発生していました。 現在は、HashMap が 2 つのスレッドで同時に変更されることはありません。その結果、管理サーバの MBean の getAttributes が呼び出されるときに、ConcurrentModificationException 例外が送出されなくなりました。
CR179262	起動時に、weblogic.jms.common.DistributedDestinationManager と weblogic.cluster.MemberManager の間でデッドロックが発生しました。 MemberManager での同期化を減らして、デッドロックを解消しました。
CR180147	ネイティブ エラー メッセージを Unicode に変換するときに NTSocketMuxer でメモリ リークが発生しました。 現在は、jni 文字列から取得した文字ポインタを解放することで、メモリ リークを解消しています。
CR180291	ドメイン全体の管理ポートを使用するドメイン内の、同じコンピュータ上で複数のサーバ インスタンスが動作する場合は、操作を指示するエラー メッセージが表示されます。以下のいずれかを行う必要があります。 サーバ インスタンスをマルチホーム マシンでホストし、各サーバ インスタンスにユニークなリスン アドレスを割り当てます。 マシン上の 1 つのサーバ インスタンスを除くすべてのサーバ インスタンスでドメイン全体のポートを無効にします。ポートを無効にするには、Administration Console の [サーバ｜全般] ページの [詳細オプション] 部分の [ローカル管理ポートのオーバーライド] オプションを使用します。
CR181986	サービスとして実行している WebLogic Server で多数のスレッドを使用した場合、メモリ不足になることがありました。 beasvc.exe と beasvc64.exe で使用される予約スタック サイズを 1MB から 256KB に減らすことで、メモリの問題を解消しました。
CR182838 CR195712	LocalServerRef は hashCode メソッドを実装していなかったため、PK の異なる複数のエンティティ Bean が同じスタブを持つことになりました。 現在、LocalServerRef は hashCode メソッドを適切に実装します。
CR183683	デフォルト ID アサータがデフォルト レルムに照らして正しく断定していませんでした。 セキュリティを有効にして RMI-IIOP を使用し、サードパーティに接続する場合に、デフォルト ID アサータはデフォルト レルムに照らして正しく断定するようになりました。
CR184182 CR187177 CR199812	WebLogic Server は、以下のような状況でステートフル セッション Bean (SFSB) ハンドルのデシリアライズが行われると、NullPointerException を送出していました。 1) ハンドルのオブジェクトを解決する場合 2) RJVM を初期化する場合 3) BasicRemoteRef の EndPoint を取得する場合 このような状況で、WebLogic Server は NPE を送出しなくなりました。
CR184487 CR196822	クライアントが t3 上で http または https をトンネリングしているときに、クライアントのクラスパスにスタブがない場合、クライアントはバックエンドの WebLogic Server に対して直接接続を開こうとしました。 現在は、ネットワーク経由のクラスロードを行う場合、クライアントは直接接続を試行しないでトンネリングを使用します。
CR185841	多数の管理対象サーバを同時に起動するときに、管理サーバの CPU 使用率が高くなりました。 ServerMbean.getName() のリモート呼び出しの数を減らしました。その結果、大きなクラスタで管理対象サーバの起動時間が速くなり、管理サーバの CPU 使用率が下がりました。
CR188371	アプリケーションがステートレス セッション Bean のリモート スタブをキャッシュし、クラスタ内のすべてのサーバが再起動された場合に、スタブはリモート オブジェクトを利用できるサーバ ノードのリストを更新できず、フェイルオーバが正常に行われませんでした。この問題は、クラスタ ノードとの初期コンテキストを再確立するのに必要な情報をスタブが持たず、リモート メソッド呼び出しが失敗したために発生しました。 WebLogic Server バージョン 6.1 のコードでは、ステートレス セッション Bean スタブのスレッド環境を伝播していませんでしたが、WebLogic Server バージョン 7.0 以降のコードでは、アンマーシャリングを行って環境を設定し、フェイルオーバを機能させるために、この伝播が必要でした。 現在、クラスタ化可能なステートレス セッション Bean の実行時記述子では、propagate-environment 属性がデフォルトで true に設定されています。 この記述子が読み込まれ、アンマーシャリング時に環境が渡されるように propagateEnvironment が設定されます。これにより、フェイルオーバ ロジックでは、クラスタ ノードに再接続して、リモート オブジェクトを利用できるサーバ ノードの新しいリストを取得することができ、フェイルオーバが適切に行われるようになりました。
CR188709	ポート番号が 32K より大きい場合に、short として読み込まれてから int に変換されたとき、変換が適切に行われなかったため、結果が負の数になりました。 現在は変換が正しく行われます。
CR189337	CORBA Any を使用して特定のプリミティブ型を転送すると、Any に格納されたプリミティブ型が破損しました。Any に格納するときに非データビットのみをマスクするのではなく、一部のデータビットもマスクされていました。 マスクが変更されて、Any は想定どおりに動作するようになりました。
CR189338 CR190012	分散ガベージ コレクション (DBC) では CORBA オブジェクトをクリーンアップしていました。 現在はすべての CORBA オブジェクトが、DGC を使用せずに、ORB によって有効期間が制御されるようにコンフィグレーションされます。
CR189462 CR190010	インタフェース定義言語 (IDL) のワイド文字列は、連結された IDL 呼び出しで使用される場合に破損していました。 現在、連結された呼び出しでは、WebLogic Server が生成したスタブではなく、標準の IDL スタブを使用します。その結果、ワイド文字列は連結された呼び出しの場合でも破損しなくなりました。
CR190010 CR189462	WebLogic Server は、発信 IDL (Interface Definition Language) 呼び出しで TransactionalObject インタフェースを尊重せず、これらのインタフェースを使用する場合にトランザクションを伝播していませんでした。 IIOP サブシステムは TransactionalObject から継承した IDL インタフェースを尊重するようになりました。WebLogic Server から Object Transaction Service (OTS) 1.1 ORB (メインフレーム上の IBM ORB など) にトランザクションを伝播できるようになりました。
CR190490	サーブレットがソケットに書き込もうとすると、java.net.SocketException: Bad File Number 例外が送出されていました。 これは、サーブレットが、閉じられたソケットに書き込もうとすると発生する可能性があります。この例外には問題はありません。この例外は無視してログに記録しないようにコードを変更しました。
CR190595	IDL 文字列が 512k を超えると、転送時に MARSHAL 例外が発生していました。 文字列のサイズ制限が 64M に変更されました。WebLogic Server は 64M 以下の IDL 文字列を受け付けるようになりました。
CR191720 CR191721 CR191552	ネットワークの分割後、サーバがその分割を認識する前にクライアントが再接続した場合、クライアントは JNDI 認証中にハングしました。 現在の WebLogic Server は、クライアントからの、停止ではなくネットワークの分割があったという PeerGone を見失ったことを認識します。古い接続情報を削除して新しい接続を作成し、認証リクエストを再試行します。これにより、クライアントはハングしなくなりました。
CR191772	WebLogic Server は、トランザクションのコンテキストで、ORB から送られた LOCATION_FORWARD を受信した場合、トランザクションのないリクエストを再試行していました。その結果リモート側でトランザクションがロールバックしました。 WebLogic Server は LOCATION_FORWARD の結果として再試行されたリクエストに、トランザクションを適切に関連付けるようになりました。外部 ORB とのトランザクションの相互運用が正常に行われます。
CR192362 CR186757 CR200758	イベント ロギングが beasvc で適切に動作していませんでした。 イベント ロギングはイベント ソースを検索できず、適切なメッセージを報告していませんでした。 イベント ロギングでは、beasvc を指定して Windows サービスをインストールするときに、イベント ソースが適切に登録され、サービスが削除されるときに適切に登録解除されるようになりました。
CR192420	CORBA オブジェクトから EJB にトランザクションが伝播されるときに、rmi ツリーに CoordinatorImpl オブジェクトがエクスポートされました。これらのオブジェクトはアンエクスポートされなかったため、メモリ リークが発生しました。 メモリ リークが発生しないように、CoordinatorImpl オブジェクトのエクスポート方法を変更しました。
CR192644	インタフェース定義言語 (IDL) TimeBase が最新のものではありませんでした。そのため、org.omg.TimeBase.UtcT クラスには他の ORB との互換性がありませんでした。 TimeBase IDL は、CORBA 2.6 の OMG (Object Management Group) 参照 IDL に一致するように更新されました。その結果、org.omg.TimeBase.UtcT クラスはどの WebLogic Server クラスローダでも使用できるようになりました。
CR192818	weblogic.Admin LOCK コマンドは非推奨になっていますが、サーバをロックして特権のあるユーザのみに接続を許可し、新しいログインは拒否する必要があります。WebLogic Server では、LOCK コマンドを実行した後も新しいログインを許可していました。 現在の weblogic.Admin LOCK コマンドは想定どおりに動作します。WebLogic Server はサーバがロックされている場合、特権のあるユーザにのみ接続を許可します。
CR194333	weblogic.Deployer ツールは、クライアントで初期化されていない SecurityServiceManager の doesUserHaveAnyAdminRoles() メソッドを呼び出そうとしていました。その結果、サーバで管理ポートが有効になっている場合、NotYetInitializedException が送出されました。 weblogic.Deployer ツールは、SecurityServiceManager がクライアント上で初期化されていないため、クライアントの doesUserHaveAnyAdminRoles() メソッドを呼び出さなくなりました。
CR197951	管理対象サーバが NAT 機能を備えたロード バランサを経由して管理サーバと通信している場合、特定の状況において、管理対象サーバの DNS 名ではなく、プライベート IP アドレスが通信に使用されていました。 呼び出し側がプライベート IP アドレスと DNS 名の両方を提供している場合に、DNS 名を抽出して使用するユーティリティを作成しました。その結果、管理対象サーバが NAT 機能を備えたロード バランサを経由して管理サーバと通信している場合に、サーバはハングしなくなりました。
CR200264	CORBA Any を含む CORBA Any をマーシャリングしようとすると、ストリーム内のタイプコードの位置が 0 になったため、アサーション エラーが発生しました。 WebLogic Server はストリーム内の位置が 0 のタイプコードを受け付けるようになり、アサーション エラーは送出されなくなりました。

デプロイメント

変更要求番号	説明
CR092875	Deployer は再デプロイのためのソース オプションを null に設定していました。アップロードにはソース オプションが必要なため、再デプロイではアップロードが行われていませんでした。 現在の Deployer では、アップロードを伴う再デプロイが可能になりました。つまり、対象でアプリケーション ファイルを追加、変更、または削除できるようになりました。この変更点は、管理サーバ上のアプリケーションのアップロード済みソースにも適用されます。 upload オプションは非推奨になり、新しい sourcerootforupload オプションが導入されました。このオプションを使用すると、リモート マシン上のソースのルート ディレクトリやアーカイブされたアプリケーション jar ファイルを指定できます。このファイルは管理サーバのアップロード ディレクトリにアップロードされます。
CR110687	新しい EAR をデプロイしているときに管理対象サーバが停止した場合、アプリケーションの削除と再デプロイメントのロジックが適切に動作しませんでした。 デプロイメント中に管理対象サーバが停止してもロジックが適切に動作するようになりました。
CR125854	WebLogic Server は no-stage の場合にファイルのコピーや削除を行いませんが、これを通知するメッセージが送信されていませんでした。 現在の WebLogic Server では、no-stage のアプリケーションに対して weblogic.Deployer -delete_files オプションを使用する場合、ファイルを削除できないことを示す DeploymentNotification を送信します。この通知は、Deployer を verbose モードで実行する場合にのみ送信されます。
CR127141	サーバの正常な停止中、アプリケーションは任意の順序でアンデプロイされていました。 現在の WebLogic Server では、デプロイメントのときとは逆の順序でアプリケーションをアンデプロイします。 つまり、LoadOrder の数が一番大きいアプリケーションが最初に、LoadOrder の数が次に大きなアプリケーションが 2 番目にアンデプロイされます。LoadOrder が同じアプリケーション同士は、アルファベット順にデプロイされ、その逆の順序でアンデプロイされます。
CR128977	weblogic.Deployer ユーティリティは、デフォルトの対象にデプロイしていませんでした。 weblogic.Deployer を使用してアプリケーションをデプロイまたは起動する場合のデフォルトの対象が、管理サーバではなく、すでにデプロイされている対象に設定されました。その結果、weblogic.Deployer はデフォルトの対象を想定どおりにデプロイするようになりました。
CR177486 CR124375 CR134935 CR173172	WebLogic Server では、特に対象がクラスタまたは仮想ホストである場合に、対象にあるアプリケーションまたはコンポーネントのデプロイメント ステータスを確認するために多数の RMI 呼び出しを行っていました。また、対象のモジュール ステータスは、対象の正確なデプロイメント ステータスを表していませんでした。 現在、デプロイメント ステータスのページには、デプロイメント ステータスと可用性のステータスを集約したものが表示されます。コンポーネントの集約されたデプロイメント ステータスは、サーバの場合は [使用可能] または [使用不可能]、クラスタまたは仮想ホストにデプロイされている場合は [使用可能]、[使用不可能] または [一部使用可能] になります。[一部使用可能] は、そのコンポーネントがクラスタまたは仮想ホストの一部のサーバでのみ使用可能であることを表しています。 デプロイメント/可用性のステータスは、対象のサーバが正常停止または強制停止されたときに更新されます。 以上の変更の結果、クラスタ デプロイメントのステータス レポートを取得する際に必要な RMI 呼び出しの回数が最小限に抑えられました。
CR184089	discover が false に設定されている場合に、管理サーバ再起動すると、drs のバージョンがリセットされました。このため、管理サーバはより低いバージョンに置かれ、クラスタへの既存のアプリケーションの再デプロイメントが成功しませんでした。 現在は、discover が false に設定されている場合に、管理サーバを再起動すると、管理サーバは drs のバージョンを認識します。
CR186042	静的ファイルを再デプロイするときに管理対象サーバが停止している場合、静的ファイルは管理対象サーバに再デプロイされませんでした。 管理対象サーバが再起動すると、アプリケーション全体が再度ステージングされ、変更された静的ファイルは再デプロイされます。
CR189712 CR175585	デプロイメント タスクの対象が動作していない、またはアクセスできない場合に、デプロイ/再デプロイ/配布/削除など特定のデプロイメント タスクのステータスが、WebLogic Server Administration Console で「失敗」したものとして表示されました。 これらのタスクは実際には遅延しているだけで、失敗したわけではありませんでした。 現在、このようなタスクのステータスはコンソールに「遅延」として表示されます。 対象に対してこれらのタスクが実際に完了すると、アプリケーションやコンポーネントのデプロイメント/可用性のステータス (モジュール ステータス) は適切に更新されます。ただし、コンソールの [最後のアクションのステータス] カラムに表示される遅延したステータスは更新されません。最後のアクションのステータスは、アプリケーションやコンポーネントの現在のデプロイメント ステータスを表していません。 また、タスクが遅延した場合、WebLogic Server は weblogic.management.ManagementException ではなく weblogic.management.DeferredDeploymentException を送出するようになりました。
CR190088	再デプロイメントの際にアプリケーションの一部のモジュールのみがサーバにデプロイされた場合、アプリケーション ライフサイクル リスナの preStop イベントが発行されませんでした。 現在の WebLogic Server では、分割デプロイメント (一部のモジュールがある対象にデプロイされ、残りのモジュールが別の対象にデプロイされること) がある場合、再デプロイメントの際にアプリケーション ライフサイクル リスナの preStop を呼び出します。
CR191908	Deployer ツールまたは wldeploy ANT タスクで verbose オプションを使用する場合、Deployer ツールも wldeploy ANT タスクもタスク完了通知を待機していなかったため、タスクを開始するとすぐに終了していました。 現在の Deployer ツールと wldeploy ANT タスクでは、verbose オプションを使用している場合でも、タスク完了通知を待機してから終了するようになりました。
CR192094 CR195074	WebLogic Server が履歴を取る目的でデプロイメント タスク オブジェクトを利用する場合、メモリ リークがありました。いくつかのデプロイメント アクション (デプロイ、アンデプロイ、停止、起動、再デプロイなど) の後に OutOfMemoryError が発生しました。大きなアプリケーションのデプロイメント アクションの場合は、すぐに OutOfMemoryError が発生しました。 これらのデプロイメント タスク オブジェクトが原因でメモリがリークしないように、コードが変更されました。
CR192097	クラスタ内のあるサーバで固定アプリケーションが非アクティブ化されると、そのアプリケーションがデプロイされている、クラスタ内の他のすべてのサーバでも非アクティブ化されていました。 deactivate コマンドが要求された特定の clusteredServer 上でのみ固定アプリケーションが非アクティブ化されるように、-deactivate、-stop および -unprepare コマンドに対する固定デプロイメントの動作を変更しました。 たとえば、次のコマンドの場合、 java weblogic.Deployer -deactivate -name myPinnedApp -targets MS1 クラスタ CLS1 内の MS1 上でのみ myPinnedApp が非アクティブ化されます。クラスタ CLS1 内の他のサーバにあるアプリケーションは非アクティブ化されません。 この新しい動作は、クラスタにデプロイされているアプリケーションや、クラスタ内の 1 つのサーバに固定されているアプリケーションには影響しません。クラスタ内の複数のサーバに固定されているアプリケーションにのみ影響を与えます。
CR192196	WebLogic Server 8.1 クライアントが、WebLogic 7.0 の管理サーバに対して DeployerRuntime.getDeployerRuntime(MBeanHome) を呼び出すと、InstanceNotFoundException が送出されました。 DeployerRuntime.getDeployerRuntime(MBeanHome) の実装が変更されました。その結果、WebLogic Server 8.1 クライアントは WebLogic 7.0 の管理サーバから、InstanceNotFoundException が送出されることなく DeployerRuntime MBean を取得できるようになりました (逆の場合も同様)。
CR193897	サーブレット フィルタの実装がシステム クラスパスにあり、サーブレット クラスが変更されている場合に、WebLogic Server は Web アプリケーションを自動的に再デプロイしませんでした。 現在のサーブレット フィルタは、フィルタがシステム クラスローダによってロードされる場合でも、Web アプリケーション クラスでの変更を考慮します。 servlet-reload-check-secs フラグが -1 以外の値に設定されている場合、この機能はプロダクション モードではなく開発モードで使用することをお勧めします。
CR195576	アプリケーション ポーラーは、applications フォルダから無効なディレクトリ構造を持つアプリケーションをデプロイする際に、送出された例外を捕捉しませんでした。その結果、このような無効なアプリケーションがデプロイされた後、残りのアプリケーションのデプロイが失敗しました。 現在のアプリケーション ポーラーでは、applications フォルダから無効なディレクトリ構造を持つアプリケーションをデプロイする際に、送出された例外を捕捉します。したがって無効なアプリケーションの障害がログに記録され、残りの有効なアプリケーションが正常にデプロイされるようになりました。
CR197220	アプリケーションが external_stage を使用してデプロイされるときに、管理対象サーバはアプリケーションを見つけられなかったため、MSI モードでの起動に失敗しました。 管理対象サーバは MSI モードでの起動時にアプリケーションを見つけられるようになりました。その結果、アプリケーションは適切にデプロイされ、管理対象サーバは MSI モードで適切に起動します。
CR197999	現在の wldeploy Ant ツールは、ステージングされたアプリケーションをデプロイするオプションをサポートしています。

EJB

変更要求番号	説明
CR055396	EJB QL 構文エラーが発生したときに、誤った XML ファイル参照を含むエラー メッセージが生成されました。 EJB QL で構文エラーがあった場合、次のようなメッセージが生成されるようになりました。 [java] ERROR: Error from ejbc: Error while reading 'META-INF/ejb-jar.xml' or 'META-INF/weblogic-cmp-rdbms-jar.xml'.
CR087261	EJBDeployer はメッセージ駆動型 Bean のログに不適切なデプロイメント メッセージを書き込んでいました。 メッセージ駆動型 Bean がデプロイされるときに正しいメッセージが記録されるようになりました。
CR122203	EJB 仕様では、cmp および cmr フィールドは小文字で始めるように規定されています。ただし、大文字/小文字の概念がない文字セットもあります。そのような文字セットが使用された場合、準拠チェッカーは、cmp または cmr フィールドが小文字で始まっていないという理由で例外を送出していました。 現在の準拠チェッカーでは、cmp または cmr フィールドが大文字で始まっていて、文字セットに大文字/小文字の概念がある場合にのみ、準拠例外を送出します。
CR127369 CR195223	複数の 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 名をユニークにするためのコードを追加して、名前が衝突する可能性を排除しました。
CR128850	enable-call-by-reference を false 設定した後にも、メソッド パラメータが参照として渡されていました。これは正しい動作です。このパラメータはシリアライズ可能でなかったため、値としてではなく参照として渡されていました。 現在は、enable-call-by-reference が false に設定されていて、リモート インタフェースのビジネス メソッドにシリアライズ可能でない引数がある場合は、パラメータが参照として渡されることを説明した警告が表示されます。
CR131561	CMP EJB に対する TableQuery 検証では、検証クエリの WHERE 句が DB2 のクエリ オプティマイザによって最適化されていなかったため、ホストで動作中の DB2 データベースでテーブル全体のスキャンが行われていました。そのためクエリの実行時間が長くなりました。 現在は、TableQuery 検証を行う場合、DB2 データベースでは、「WHERE 1=0」オプションの代わりに「FETCH FIRST 1 ROWS ONLY」オプションが使用されます。その結果、パフォーマンスが最適化されました。 この変更は DB2 データベースに固有のものであり、他のデータベースには適用されません。他のデータベースでは TableQuery 検証で引き続き「WHERE 1=0」が使用されます。
CR132853	メッセージ駆動型 Bean で同期的なメッセージ ポーリング方式を使用する場合、Sonic JMS サーバが使用されると問題がありました。メッセージ駆動型 Bean コンテナのポーリングの最適化によって、メッセージの受信が遅延しました。 この問題を回避するため、最適化されたポーラーは使用しないでください。Sonic のメッセージ配信方式はこの方式ではうまく機能しないため、SONIC JMS サーバを連続的にポーリングするポーラーを使用してください。 このメッセージ駆動型 Bean の新しい動作は、TIBCO および Sonic JMS プロバイダにのみ適用されます。 CR128980 と CR135722 を参照してください。
CR135125	読み込み専用 EJB に対してセッター メソッドが呼び出され、セッターが実行されなかった場合に、例外が送出されませんでした。 現在は、読み込み専用 EJB に対してセッターが呼び出された場合、WebLogic Server は EJBException を送出します。
CR173231 CR189040	内部クラスが引数として ejbCreate などの EJB メソッドに渡された場合、生成されたコードでは、内部クラスの引数が正しい表現に変換されていませんでした。 内部クラスの引数が内部クラスの正しい表現に変換されるように、コード生成を修正しました。
CR173260	order-database-operations が true に設定されており、同じトランザクション内でエンティティ Bean が削除されてから同じ主キーで作成された場合、WebLogic Server は OptimisticConcurrencyException を送出していました。 現在は、このような状況で OptimisticConcurrencyException を送出しなくなりました。
CR175158	Exclusive 同時方式を使用していて、キャッシュにロードされている BMP エンティティ Bean が、idle-timeout-secs を過ぎてもタイムアウトしませんでした。この BMP Bean は、Database、ReadOnly、および Optimistic などの他の同時方式の場合でもタイムアウトしませんでした。 現在、Exclusive 同時方式を使用する BMP Bean は、idle-timeout-seconds を過ぎるとキャッシュから削除されます。
CR177114	以下のような状況で、EJB のデプロイ中にシーケンスを検証する際に例外が送出されました。 1) グローバル シノニムが使用されていて、schemaName が指定されていない場合。 2) その EJB の接続プールを作成したユーザ以外のユーザがシーケンスを所有している場合。 現在の WebLogic Server では、スキーマ名が指定されていない場合でも、Oracle シーケンスを ALL_SEQUENCES ビューに対して検証します。そのため、EJB のデプロイ中に検証例外を送出しなくなりました。
CR178404 CR192516	WHERE 句で NOT 論理演算子が使用されていて、そのオペランドが OR 演算子を含む条件式 (WHERE NOT (lefthand_cond_exp OR righthand_cond_exp) など) である場合、クエリの解析中に NullPointerException が発生しました。 OR 演算子が適切に処理されるようになりました。
CR183557	1 つのトランザクションで親と子が作成される場合、CMR コレクションに 1 つではなく 2 つの関係エンティティが含まれていました。この問題は、Bean が SqlServer で auto-key-generation を使用し、delay-database-insert-until が ejbCreate に設定されている場合に起こりました。 この問題を修正する変更が行われました。
CR184154	ejbc の実行中に WebLogic Server が生成した weblogic-cmp-rdbms-jar.xml の Java クラスで、Resultset が不適切に解放されていました。そのため、JDBC ログが「java.sql.SQLException」でいっぱいになりました。 EJB の生成コードに、JDBC オブジェクトが閉じられる順序を修正するコードが追加されました。 Resultset が正しく解放されるようになりました。
CR184780 CR128984	weblogic-ql 要素でファインダに対して定義された Oracle SELECT_HINT が、生成された SQL クエリに含まれていませんでした。 現在は含まれるようになりました。
CR186325	WebLogic Server 8.1 では、key-cache-size がデータベース内のシーケンスのインクリメント値と等しくなければならなかったため、準拠チェックが追加されました。key-cache-size がデータベースのインクリメント値と等しくない場合、WebLogic Server はデプロイメント中に次のエラーを送出しました。 The ORACLE SEQUENCE named 'test_sequence' with INCREMENT value '1' '[EJB:011065]The ORACLE SEQUENCE named 'test_sequence' does not have INCREMENT value '1' in the database' 現在は、key-cache-size に、データベース内のシーケンスのインクリメント値以下の値を指定できます。 key-cache-size の値がデータベースのインクリメント値より大きい場合は、重複したキーが生成される可能性があるため、例外が送出されます。 EJB をデプロイメントするとき、シーケンスの検証中に以下のルールが適用されます。 1) key-cache-size <DB INCREMENT_BY は許可されますが、不十分なキー (10, 20, 30) が生成されるという警告が出されます。 2) key-cache-size = DB INCREMENT_BY は許可されます。 これは現在と同じ動作です。 3) key-cache-size> DB INCREMENT_BY は許可されません。重複したキーが生成される可能性があるため、デプロイメントは許可されません。 これに従い、<create-default-dbms-tables> のさまざまな値に関する他のルールも変更されました。 一般に、Prod シーケンス (ユーザによって定義されたシーケンスなど) は変更されません。Dev シーケンス (WebLogic Server によって作成されたシーケンスなど) は変更されます。 1、5、10 ... という順序でシーケンスを生成したり、負の数の -1、-5、-10 ... というシーケンスを生成する必要がある場合は、key-cache-size を 1 に設定し、データベースの INCREMENT_BY を 5 に設定します。ただし、key-cache-size が 1 であるため、コンテナは常にデータベースに問い合わせて次の autoKey を取得します。そのため、データベース シーケンスで設定された INCREMENT_BY に従うことになります。
CR186949	EJB コンテナはフリー プール内に初期数の Bean を作成する前に JMS 接続を開始していました。そのため、コンテナに送信されたメッセージを処理するために、コンテナが別の Bean インスタンスをインスタンス化することがありました。 現在は、JMS 接続を開始する前に、initial-beans-in-free-pool でコンフィグレーションされた数のインスタンスを作成して、メッセージを受け付けるようになりました。
CR187121	デプロイメント記述子で idleTimeoutSecs に 60000000 などの大きな値を設定した場合、ミリ秒数に変換するために 1000 を掛けると、オーバーフローして負の値になります。その結果、パッシベーションされた Bean をディスクから削除するトリガが絶えず発行されることになり、CPU 使用率が高くなります。 タイムアウト値をミリ秒単位で格納する EJB コンテナ内の変数 (idleTimeoutMS、sessionTimeoutMS、readTimeoutMS など) の型が int から long に変更されました。これにより数値のオーバーフローは防止されます。
CR187304	Database 同時方式を使用している場合に、BMP が同じトランザクションで重複した行を作成しようとすると、ClassCastException が発生しました。 Bean を作成するときに、その Bean がすでに存在しているかどうかをチェックするようになりました。
CR188022	コミット時に行を挿入するときに、特定の状況において、EJB コンテナは DuplicateKeyException を送出し、誤った主キーを原因として報告していました。 コミット時に行を挿入するときの例外処理を簡略化しました。文のバッチを挿入するときに、SQLException がある場合はそのまま送出されます。SQLException と共にエラーの詳細が表示されます。 これは、エラーの原因となったバッチ内の正確な文を報告するという、ドライバの制限に従っています。その行がバッチの一部として挿入されない場合にのみ、重複したキーを検出するチェックが行われて報告されます。
CR188814	BLOB または CLOB カラムの更新後に PreparedStatement と ResultSet が閉じられていませんでした。 現在の WebLogic Server では、BLOB/CLOB カラムを更新するときに PreparedStatement と ResultSet が閉じられます。
CR189544	EJB メソッドの引数として、内部クラスに含まれている内部クラスが渡された場合、不適切なコードが生成されていました。 現在の WebLogic Server では、内部クラスの表現を変換して、内部クラスに含まれている内部クラスを適切に処理します。
CR189847	ステートフル セッション Bean (SFSB) のインメモリ レプリケーションが原因でメモリ リークのような状況が発生しました。 メモリ リークは発生していませんでしたが、ヒープ メモリが効率的に使用されていませんでした。現在は、SFSB のインメモリ レプリケーションでヒープ メモリが効率的に使用されます。
CR190831	EJB メソッドの戻り値の型として内部クラスの配列が使用される場合、不適切なコードが生成されました。 現在は、内部クラスの配列を処理する場合、内部クラスの表現を変換して正しいコードを生成します。
CR191003 CR186958	Bean の fk-column も同じ Bean の cmp-field にマップされる場合、EJB のデプロイ中に、MetaData を伴う検証が失敗しました。 現在は、Bean の foreign-key カラムも同じ Bean の cmp-field にマップされる場合、WebLogic Server は、fk-column がすでに追加されていれば、それ以上追加しません。その結果、MetaData を使用する場合にカラム名の検証が失敗しなくなりました。
CR191351	自動キー生成では、データベースのデフォルトの数に <key-cache-size> で定義されたキャッシュ サイズを加えて新しいキーを生成していました。 現在は、auto-key-generation に select-first-sequence-key-before-update タグが追加されました。このタグは、自動主キー生成の動作を指定するために使用します。 select-first-sequence-key-before-update が true に設定されている場合、EJB コンテナはデータベースからシーケンス値を取得する必要があります。EJB コンテナは、シーケンス テーブル内の現在の値に 1 を加えて主キーを生成してから、現在の値に key-cache-size を加えたものでテーブル内の値を更新します。たとえば、シーケンス テーブル内の現在の値が 100、key-cache-size が 100 である場合、EJB コンテナは (テーブル内の現在の値に 1 を加えて) 101 という主キーを生成してから、テーブル内の値を (現在の値に key-cache-size を加えた) 200 で更新します。 デフォルトでは、select-first-sequence-key-before-update は false に設定されています。
CR192682 CR106774	EJB CMP を使用する場合、WebLogic Server は EJB-QL キーワードの between を>=? AND <=? に変換していました。その結果、特定のプラットフォーム上の DB2 (特に大きなテーブル) に対するクエリで長い時間がかかっていました。 現在は、>=? AND <=? の代わりに EJB-QL キーワード between を使用するため、DB2 に対するクエリが速くなりました。
CR193685	コンテナ管理による永続性 (CMP) では PreparedStatement を使用して SQL を実行するようになりました。
CR197639	現在、WebLobic Server の CMP20 EJB では、DB2 および Informix データベースで自動主キー生成をサポートします。
CR198962 CR201394	WHERE 句で IS EMPTY または IS NOT EMPTY を使用する ejbSelect クエリを含む EJB をコンパイルしているときに、EJB コンパイラでエラーが発生しました。 ejbSelect クエリはこの条件でエラーを引き起こさなくなりました。

インストール

変更要求番号	説明
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

変更要求番号	説明
CR103309 CR195836 CR197966	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-70.00.jsp のセキュリティ勧告を参照してください。
CR125308	weblogic-application.xml ファイルへの更新が、再デプロイ時にロードされていませんでした。 weblogic-application.xml ファイル内の JDBC 接続プール定義への変更を、JDBCModule がデプロイ時に考慮するようになりました。
CR132360	WebStart において weblogic.j2eeclient.Main が機能していませんでした。 client jar ファイルは、WebStart クライアントによってロードされ、クラスパス内で使用できる引数です。しかし、このファイルがカレント ディレクトリで使用できず、エラーの原因となっていました。 client jar ファイルをシステム クラスパスからロードするためのシステム プロパティ (weblogic.j2ee.client.isWebStart) が WebLogic Server に追加され、weblogic.j2eeclient.Main が WebStart で機能するようになりました。
CR192609	weblogic-application.xml で classloader-structure 機能を使用していると、ClasspathServlet が次のような形式で要求されたファイルを提供できませんでした。 http://host:port/bea_wls_internal/classes/appName@compName/mydir/Foo.class ClasspathServlet のコードが修正され、このような特定のリクエストを処理できるようになりました。

JCOM

変更要求番号	説明
CR184188、CR187469、CR202505、CR198780	java2com を使用していると、JCOM_OUTGOING_CONNECTION_TIMEOUT が尊重されていませんでした。 JCOM_OUTGOING_CONNECTION_TIMEOUT に指定した値が SO_TIMEOUT に設定されるようになりました。 WebLogic Server をこのシステム プロパティで起動すると、タイムアウト後に com 呼び出しが中断されます。

JDBC

変更要求番号	説明
CR175793	サーバの起動時に LogRemoteExceptionsEnabled を使用すると、InstanceNotFoundException が送出されていました。 AdminMbeanHome を呼び出す代わりに、ローカルの MBeanHome を使用して getMBean を実行するように修正されました。これにより、サーバの起動時に LogRemoteExceptionsEnabled を使用しても、InstanceNotFoundException は送出されなくなりました。
CR179600	特定の文が失敗した状況で、プールの statement キャッシュが文を閉じるのを怠ったため、DBMS セッションでカーソルのリークが発生しました。 この問題を解決する変更が行われました。カーソルのリークは発生しなくなりました。
CR181368	クリーンアップ中に、autoCommit(true) モードにリセットされる autoCommit(false) モードの接続が見つかると、すべての DBMS ロックが解除されていました。これは Oracle では不正な処理です。 WebLogic Server では、トランザクションを中断するとすべてのトランザクション コンテキストがロールバックされますが、idle-connection コードでは進行中のトランザクションがあるかどうかを判断できず、cleanup() を呼び出しても、ユーザが構築したローカルの Oracle トランザクションに対しては十分ではありませんでした。 inactive-conn-timeout で、cleanup() 中にすべてのトランザクションがロールバックされるようになりました。
CR182879	マルチプールと接続プールが同じ名前でも起動時にエラーが送出されず、DataSource と TxDataSource でその名前が対象にされていました。 上記の場合にはエラーが送出されるようになりました。
CR183355	JTS 接続の初期化が失敗した際に、接続がプールに返されていませんでした。 JTS 接続の初期化に失敗したら、プール接続を返すように修正されました。
CR183884	Informix JDBC Driver を使用して XA JDBC 接続プールを作成すると、生成される URL において hostname プロパティと servername プロパティが入れ替わっていました。 生成される URL において、hostname プロパティと servername プロパティが正しく配置されるようになりました。
CR184819	複数の RAC インスタンスがコンフィグレーションされている場合に、1 番目の RAC インスタンスが停止しても、マルチプールがフェイルオーバしていませんでした。 マルチプールが正しくフェイルオーバするように修正されました。
CR186957 CR198022	結果セットを 2 回以上閉じると、jdbc.log ファイルに SQLException が記録されていました。 結果セットを繰り返し閉じても無視されるようになり、jdbc.log ファイルに SQLException が記録されなくなりました。
CR189281 CR191429	接続が確立された際のスタック トレースが保持されていなかったため、接続がリークした場合のメッセージに有用な情報が含まれていませんでした。 接続が作成された際のスタック トレースが配信されるように修正され、コードの診断に有用な情報が提供されるようになりました。これは、後で接続を閉じる際には無視されます。
CR190700	JDBC の setTypeMap(map) および getTypeMap() に対する呼び出しが、XA Connection(JTA) において次の例外によって失敗していました。 java.sql.SQLException: java.sql.SQLException: Cannot set type map setTypeMap(map) および getTypeMap() APIs が JTAConnection に実装されました。これにより、これらの API を呼び出しても、SQLException は発生しなくなりました。
CR194051	MetaData.getColumns() がトランザクション内で呼び出され、ResultSet が明示的に閉じられない場合に、Oracle Database カーソルがリークしていました。 接続が閉じられると、作成されたすべての PreparedStatement と ResultSet も閉じられるようになりました。その結果、MetaData.getColumns() を呼び出しても、Oracle Database カーソルはリークしなくなりました。
CR196738	MSSQLServer4 ドライバの Statement.cancel() メソッドによって JDBC 接続が破損していました。接続が閉じられた後に、トランザクション内の JDBC 文が閉じられていませんでした。 MSSQLServer4 ドライバの Statement.cancel() メソッドが修正されて操作不能になったため、接続が破損することはなくなりました。この修正は、トランザクションのロールバックには影響しません。
CR197163	JDBC 接続プールの接続テストが、大量のデータベース リソースを消費していました。これは、テストごとに新しい文が作成されており、そのたびに DBMS が SQL を解析してプランニングする必要があったためです。 接続のテスト用に準備された単一の文をプールが再利用するように修正し、パフォーマンスが向上しました。ただし、テスト SQL 内でアプリケーション DBMS のテーブルまたはプロシージャが参照されている場合や、実行時にこれらが構造的に変化する場合 (インデックスが追加されるなど) は、テスト PreparedStatement のクエリ プランが無効になる可能性があります。その結果、後続のテストが失敗し、接続とテスト文が置換されます。通常、Administration Console によって推奨されるテスト SQL にはテーブルの構造的な変更は含まれていないため、接続を不必要に再利用する問題が発生する可能性は最小化されています。
CR199348	外部クライアントがプールへの RMI 接続を使用し、これらを正しく閉じたにもかかわらず、RMI SerialConnection オブジェクトの finalize() メソッドからリークされた接続に関する警告を受信していました。 is-closed フラグが修正され、クライアントがこれらの不正な警告を受信することはなくなりました。
CR200403	resetStatementProfile() メソッドの呼び出し時にトレースを取得するには、トレースが再有効化されていても WebLogic Server を再起動する必要がありました。 既存のファイルとライターが必ず閉じられ、新規作成が試行されるまでは再利用されなくなりました。その結果、resetStatementProfile() メソッドの呼び出し時に、WebLogic Server を再起動しなくてもトレースを取得できるようになりました。
CR200672	MS と Sybase のプールのテスト SQL としては、「select count(*) from sysobjects」が推奨されていました。しかし、このシステム テーブルは非常に大きいため、クエリにかなりの時間がかかり、DDL を必要とする DBMS の同時実行性に問題がありました。 推奨されるデフォルトのクエリ テキストが変更されました。クエリの実行時間がかなり短縮され、DBMS の同時実行性の問題も解消されました。

jDriver

変更要求番号	説明
CR185527	XA 用の JDriver を使用している場合に、DataBaseMetadata を使用してメタデータにアクセスすると失敗することがあり、結果として java.sql.SQLException が発生していました。 DatabaseMetaData にメタデータ情報の取得に使用する文への参照が保持されるようになり、短時間でガベージ コレクトされることはなくなりました。その結果として、メタデータへのアクセスが失敗しなくなりました。 OPEN 文のカーソルを保持するデータベース管理システムの場合は、DatabaseMetaData オブジェクトがガベージ コレクトされる前に、保持された文が 1 つの DBMS カーソルを要求します。

JMS

変更要求番号	説明
CR135578 CR200466	非恒久トピック メッセージでそのトピックの再配信遅延が保留になったままコンシューマを終了した場合に、非恒久トピックの保留バイト数が正しく更新されていませんでした。 再配信パラメータがコンフィグレーションされた状態でコンシューマを終了した場合でも、非恒久トピック メッセージにおいて JMS 統計の保留バイト数が正しく調整されるようになりました。コンシューマが完全に終了しても、確認応答されていない非恒久トピック メッセージで再配信が試行されることはなくなりました。
CR173542 CR188526	JMS 分散キューの使用時に複数のクラスタ メンバー間で Java レベルのデッドロックが生じていました。ロックされたオブジェクトは weblogic.jms.backend.BEQueue と weblogic.jms.common.DistributedDestinationManager でした。 この問題は、オブジェクトの同期化を修正することで解決されました。
CR180414	JMSEnumeration がクライアントにメッセージを提供する際に、メッセージのコピーが作成されていませんでした。サーバ内部でブラウザを使用するサーブレットなどは、他に送信されるメッセージを編集することが可能でした。 ブラウザがローカルの接続を使用する場合には、メッセージのコピーが提供されるようになりました。
CR182338	RedeliveryLimit がコンフィグレーションされている場合に、RedeliveryLimit に達した回数が ConnectionFactory の MessagesMaximum の設定値を超えると、レシーバがメッセージの処理を停止していました。 たとえば、RedeliveryLimit=0、MessagesMaximum=10 の場合に、レシーバがメッセージを受信して sesssion.recover() を 10 回呼び出したとします。この場合、レシーバはメッセージの処理を停止し、コンソールでは 10 個のメッセージが保留されていました。 コードが追加され、RedeliveryLimit に達したためにキューからメッセージが削除されたら、ウィンドウ カウンタが調整されるようになりました。
CR184045	シャットダウン時に移行可能な JMSServer の登録解除が失敗すると、JMS がログに例外を記録していました。 シャットダウン済みまたはサスペンド済みの移行可能な JMSServer の登録解除が失敗しても、JMS がログに例外を記録しなくなりました。
CR184821	MessagingBridge.ProcessMessage() で WebLogic Server がメッセージをまったく受信しないと、トランザクションがロールバックされてメソッドから戻っていました。scan_unit 遅延で再試行が発生するため、1 秒の遅延が生じていました。 MessagingBridge.ProcessMessage() で WebLogic Server がメッセージをまったく受信しなくても、scan_unit を待って 1 秒後に再試行するのではなく、トランザクションをロールバックしたら即座に再試行するようになりました。この修正により、ブリッジ内での待ち時間による遅延がなくなりました。
CR185785 CR126613	onMessage() の間にトランザクション マネージャによってトランザクションがロールバックされた場合に、スレッドが正しくクリーンアップされていませんでした。 トランザクションの TimedOutException が原因で onMessage() の処理中にトランザクションがロールバックされた場合でも、MDB メッセージの処理中には AssertionError が送出されなくなりました。
CR187945	メンバーが動的に追加されたときに、JMS の DistributedDestination ロード バランサが既存のコンシューマを認識していませんでした。 メンバーが分散送り先に追加されたときに、そのメンバーにコンシューマがあるかどうかをチェックするように修正されました。これにより、ロード バランサが正しくロード バランシングを行うのに必要な情報が提供されるようになりました。
CR188040	ServerDebugMBean() JMS 属性を変更したときに、WebLogic JMS が通知を受信していませんでした。 ServerDebugMBean() を使用して、「DebugJMS」ServerDebugMBean 属性を動的に有効または無効にできるようになりました。これにより、JMS デバッグ フラグを動的に有効または無効にできるようになりました。
CR188264 CR194959 CR188391 CR190095	再配信制限に達したときに、ウィンドウ パイプライン (MessagesMaximum) が正しく管理されていませんでした。 再配信制限に達した場合でもウィンドウ パイプラインが正しく調整され、メッセージの処理が停止することはなくなりました。
CR189899	同期 API 呼び出しで peerGoneException が検出されると、この例外が ExceptionListener に転送されていました。この動作は、同期 API 呼び出しの仕様に違反しています。 JMS が、他に報告する先がない場合にのみ例外を ExceptionListener に転送するように修正されました。PeerGoneException が同期 JMS API 呼び出しの間に検出された場合でも、ExceptionListener には転送されません。このような場合には、例外が同期 JMS API から LostServerException として送出されます。
CR189957 CR191998 CR195727	JMS サーバが初期のクライアント接続で peerGone を検出する前に、リモート シン クライアントの接続で切断および再接続が発生すると、失われた接続を検出したときに、誤って古い接続と新しい接続の両方がクリーンアップされていました。 この動作は修正され、新しい接続を失うことはなくなりました。
CR190438	weblogic.jms.backend.BEQueue オブジェクトと weblogic.jms.backend.BEConsummer オブジェクトの間で Java レベルのデッドロックが生じていました。 この問題は、ロックの階層を更新して送り先が最初にロックされるようにすることで解決しました。
CR190843	Oracle 10G ドライバと 8i サーバを使用している場合に JMSState テーブルおよび JMSStore テーブルでビューを使用すると、JMSServer を起動したときに SQLException が発生していました。 Oracle 10G ドライバと 8i サーバを使用している場合に JMSState テーブルおよび JMSStore テーブルでビューを使用しても、JMSServer がエラーなしで起動するようになりました。
CR192455	拡張により、JMS JDBC ストアのパフォーマンスが大幅に改善しました。その結果、JDBC はコンフィグレーションされた接続プールから 2 つの JDBC 接続を予約できるようになりました (これまでは 1 つのみ)。
CR192466	Administration Console を更新したことにより、メッセージング ブリッジのコンフィグレーション プロセスが簡素化されました。
CR197857	JMS が最小フロー率を維持していませんでした。実際の最小フロー率は、コンフィグレーションされた値のおよそ 2 倍になっていました。接続ファクトリでデフォルトのフロー制御設定 (FlowMinimum=50) を使用している場合、毎秒 50 メッセージではなく毎秒約 100 メッセージの最小フローを維持していました。 JMS 送り先が指定されたバイトまたはメッセージしきい値を超えると、フロー制御がプロデューサ用に開始され、FlowMinimum (デフォルトでは 50) に達するまで抑制されるようになりました。最小フロー率は、しきい値を超えている限り維持されます。 この修正により、JMS が最小フロー率を正しく維持するようになったため、これまでに比べフロー制御がかなり遅くなっています。 以前 (リリース 8.1 sp4 より前) のフロー制御の動作を維持するには、FlowMinimum を 2 倍の値に設定し、これまでデフォルト値を使用していた接続ファクトリで FlowMinimum=100 を追加します。

JNDI

変更要求番号	説明
CR186048	WebLogic Server では、war ファイルのデプロイ時に Web アプリケーション用の環境が作成されます。この環境をビルドするため、JNDI ツリーからオブジェクトをルックアップする InitialContext が作成されます。jndi.properties がクラスパスに含まれていたため、jndi.properties に指定されたプロパティから InitialContext が作成されていました。 環境をビルドした後もこの InitialContext が閉じられていなかったため、jndi.properties に指定したユーザがスタックの一番上に残っていました。このため、サーバがデプロイメントの際に MBean 属性を変更しようとすると問題が発生していました。 環境をビルドした後に InitialContext を閉じるようになりました。
CR191092	分散トピックをホストする管理対象サーバを強制停止して再起動すると、再起動後にもかかわらず分散トピックがメッセージを受信しなくなっていました。 クラスタ レイヤ内のコードが修正され、分散トピック リストへのトピックの再追加が妨げられることはなくなりました。

JSP

変更要求番号	説明
CR131694	AIX では、エスケープ シーケンスが欠落していたため、ISO-2022-JP 文字が文字化けすることがありました。 AIX で ISO-2022-JP 文字が文字化けしないように修正されました。
CR136784	Web アプリケーションの weblogic.xml ファイルで pageCheckSeconds が -1 に設定されていると、weblogic.Deployer ユーティリティを使用して Web アプリケーションの一部を再デプロイすることができませんでした。 weblogic.xml ファイルで pageCheckSeconds が -1 に設定されていても、修正された Web アプリケーションの一部を weblogic.Deployer を使用して再デプロイできるようになりました。
CR179636	文字列のサイズ制限 (64K) が原因で、非常に長い文字列で構成されるマルチバイト JSP のコンパイルに失敗していました。JVM の 64K 制限を回避するための文字列分割に失敗し、次の例外が発生していました。 java.lang.ClassFormatError: jsp_servlet/_docs/_pas5e/__gp5e0305001 (Illegal constant pool type) 文字列サイズの制限なしで、マルチバイト JSP がサポートされるようになりました。
CR180854	JSP 解析エラーが発生すると、ファイル ストリームが閉じられていないために JSP ソース ファイルがロックされていました。このため、JSP ファイルを更新することができませんでした。 入出力ストリームを明示的に閉じるようにすることで、JSP ファイルを更新できるようになりました。
CR185726	2000 を超える JSP ファイルで weblogic.jspc を実行すると、OutOfMemory エラーが発生していました。 -Dweblogic.jspc.useUniqueJspClassLoader フラグが追加され、これを true に設定すると各 JSP が個別のクラスローダにロードされるようになりました。これにより、OutOfMemory 例外は発生しなくなりました。
CR185870 CR197362	JSP ファイルで wl:cache タグを使用すると、同じ JSP ファイルの複数のインスタンスを実行したときに長い時間がかかり、デッドロックが発生していました。 Weblogic Server JSP コンテナのコードが修正され、デッドロックを回避できるようになりました。 その結果、JSP ファイルで wl:cache タグを使用してもデッドロックは発生しなくなりました。
CR191143	標準アクションおよびカスタム アクション以外を表す XML 要素の本文内のテキストが変換されていませんでした。 このテキストを出力の現在の値に渡して変換するように修正されました。
CR197629	wl:cache タグの async 属性が、非推奨になっていたため機能していませんでした。 async を追加しなおしました。wl:cache は正しく機能するようになっています。async="true" に設定されている場合、wl:cache タグを使用する前に JSP ページのデータをフラッシュすることはできません。

JTA

変更要求番号	説明
CR125476	トランザクションが準備フェーズにあり、XAER_RMERR または XAER_RMFAIL が送出された場合に、トランザクションがロールバックされずに保留されたままになりました。 このような状況でトランザクションがロールバックされるようになりました。
CR130073	アプリケーションが WTC を介して Tuxedo 7.1 から WebLogic Server に複数のロールバックを発行すると、一部の Oracle XA 接続がリークし、プールに戻されていませんでした。XA Debug では、XA End が呼び出されないために接続がクリーンアップされないことが示されていました。 XA End を呼び出すようにすることで、接続がプールに戻されるようになり、メモリ不足エラーは発生しなくなりました。
CR134081	unregister の呼び出しまたはリソースのエラーによってリソース アダプタの登録が解除されると、そのリソース アダプタに対するすべてのトランザクション操作が失敗していました。 サービス パック 5以降では、登録が解除されたリソース アダプタと同じ名前のリソース アダプタが登録されていれば、1 番目のリソース アダプタに対するすべてのトランザクションが 2 番目のリソース アダプタで操作できるようになります。
CR176663 CR198213	TLOG から回復したトランザクションに非 XA の参加リソースがある場合、このトランザクションを完了することができませんでした。 コードが修正され、上記のトランザクションも問題なく完了できるようになりました。
CR184585	スレッド アフィニティ動作が可能な XAResource 実装のサポートが追加されました。
CR184941	サーバをバックアップするため手動で JTA を移行した後に、クラッシュした WebLogic Server を起動しようとしても起動できませんでした。 サーバをバックアップするため手動で JTA を移行した後でも、クラッシュした WebLogic Server を再起動すると起動できるようになりました。
CR188558	タイマー スレッドがオフになる前に WebLogic Server を停止すると、一部のリソースのチェックポイントが TLOG に記録されていませんでした。WebLogic Server を再起動しても、これらのリソースの回復処理は実行されず、保留になっていたトランザクションは保留のままになっていました。 リソースがローカルで調整され、かつリソースのチェックポイントを記録する必要がある場合は、トランザクションをリソースに登録するとフラグが立てられ、トランザクションが 2 フェーズであれば準備時間にリソースのチェックポイントが TLOG に記録されるようになりました。

JTS

変更要求番号	説明
CR189994 CR197412	connection.close において、自動コミットが false に設定されていると、データベースへの更新がコミットされていました。 これを回避するため、接続プールをリセットして操作を破棄する際、物理的な接続を閉じる前にロールバックを実行するように修正されました。 これにより、データの整合性を維持するため、setAutoCommit(false) が使用されている場合でも、リセットや破棄によって物理的な接続を閉じる際に、デフォルトで機能がコミットされないようになりました。
CR196085	トランザクションが進行中でなくなると、ユーザがそれ以上の JDBC を実行できないようにするためのチェックによってすべての public Statement メソッドが保護されます。しかし、トランザクションがロールバックされた場合には、WebLogic Server 自体が進行中の文で cancel() を呼び出し、WebLogic Server がユーザとして認識されてチェックによってブロックされていました。このため、次の例外が送出されていました。 java.sql.SQLException: The transaction is no longer active cancel() 呼び出しのチェックが削除されました。その結果、トランザクションがロールバックした場合でも SQLException は送出されなくなりました。

JVM

変更要求番号	説明
CR122722	マルチプロセッサ システムではまれに、Sun JDK の競合状況によって java.lang.Error UnsupportedCharsetException が発生し、実行中のアプリケーションが終了することがありました。 Sun では、文字セットのロード方法を設計し直して JDK 1.4.2_05 の問題を解決しました (BugParade 4838512 を参照)。WebLogic Server では何も変更されていません。また、WebLogic Server には影響はありません。

ノード マネージャ

変更要求番号	説明
CR173733 CR197202	CustomTrustKeyStorePassPhrase が暗号化され、nodemanager.config ファイルにクリア テキストで表示されることはなくなりました。
CR184261	同じサーバに対して start リクエストと kill リクエストが同時に発行された場合、管理サーバとノード マネージャでスレッドがハングしていました。 現在は、重複したリクエストがないかどうかをチェックして、スレッドがハングしないように適切な処理が行われます。
CR184760	Red Hat Enterprise Linux 3.0-1 では、ノード マネージャが POSIX 準拠でない SIGCHLD を無視していたため、ノード マネージャにより管理対象サーバが突然停止されると、管理対象サーバが消滅していました。 この問題は他の種類の UNIX では発生していなかったため、Linux OS i686 についてのみコードを POSIX 準拠に修正しました。 その結果、管理対象サーバは問題なく停止処理できるようになり、Linux でも余計なプロセスが発生しなくなりました。
CR186592 CR206553	以下の場合に、ノード マネージャがソケットをリークしていました。 1. 管理サーバからノード マネージャにサーバ起動リクエストが送信され、これが正しく閉じられなかった場合 2. 重複した起動/停止リクエストが同じサーバに送信された場合 ソケット接続が突然切断された場合でも、ソケットとその基底のストリームが正しく閉じられるようになりました。
CR189124	ノード マネージャが管理対象サーバを起動すると pid ファイルが作成されますが、UNIX プラットフォームでは pid が pid ファイルに書き込まれていませんでした。 UNIX プラットフォームでも、pid が pid ファイルに書き込まれるようになりました。
CR193193 CR202754	デフォルト キューのすべてのスレッドがスタックしていると、ノード マネージャが管理対象サーバを再起動していませんでした。 デフォルト キューのすべてのスレッドがスタックし、他のアプリケーション キューがない場合でも、サーバが障害状態にあることをノード マネージャが検知して再起動するようになりました。

操作と管理

変更要求番号	説明
CR101263 CR184396	管理対象サーバを含むドメインの管理サーバで EXISTS_POOL コマンドを実行すると、指定したプールが管理サーバにデプロイされていさえすれば True が返されていました。接続プール名はドメイン内でユニークでなければならないため、本来であれば指定したプールがサーバ上だけでなくドメイン内にも存在する場合に True を返すべきでした。 指定した名前のプールがドメイン内にコンフィグレーションされている場合に True が返されるように修正されました。
CR108002	weblogic.Admin CREATE_POOL が、8.1 で非推奨になった RefreshMinutes を使用していました。Administration Console では TestFrequencySeconds の値が取得されていたため、CREATE_POOL を使用して refreshPeriod を設定しても Administration Console には表示されていませんでした。 Ant タスクを使用して JDBCConnectionPoolMBean の属性を設定する場合に、refreshMinutes ではなく TestFrequencySeconds が使用されるように修正されました。
CR108496	コンソールで EJB デプロイメント記述子を編集すると、デプロイされた EJB jar ファイルで <global/> タグが <global>true</global> に変更されていました。 getGlobalRole メソッドの空タグが追加され、永続化後も検証が失敗しなくなりました。
CR111896	WL.Admin -batchupdate コマンドでは、バッチ ファイルに引用符や二重引用符で囲んだ文字列を含めることができませんでした。 このコマンドを処理する前に引用符や二重引用符が削除されるように修正し、バッチ ファイルに引用符で囲んだ文字列を含めることができるようになりました。
CR112292	接続が失敗しても weblogic.Admin TEST_POOL が例外を送出していなかったため、1 ではなく 0 が返されていました。 接続のテストが失敗した場合に例外が確実に送出されるように修正されました。
CR121202	ユーザがデプロイメントを実行すると、サーバにスケジューリングされた作業と対話することがあり、コンフィグレーション リポジトリのロギングや保存の間にデッドロックが生じていました。 ロックを順序付けし、ロギング メッセージを同期コードの外に移動しました。
CR126191	weblogic.Admin ツールで DESTROY_POOL コマンドを使用すると、単にすべてのユーザが切断され、プールがサスペンドされていました。本来であればドメイン コンフィグレーションから削除されるべきプールが、 実際には削除されていませんでした。 DESTROY_POOL でプール コンフィグレーションが削除されるようになりました。プールをサスペンドするには、DISABLE_POOL または SUSPEND を使用してください。
CR126499	「ping」コマンドが失敗すると、誤った終了コード 0 が返されていました。 エラーの場合に正しい終了コードが返されるように修正されました。
CR127031	wlconfig Ant タスクを使用して JMSQueue または JMSTopic を作成しようとすると、NullPointerException が発生しました。親属性が使用された場合にのみ例外が発生しました。以下のエラー メッセージが生成されました。 BUILD FAILED <file:<drive>:/..../build.xml:6>: Error invoking MBean command: java.lang.NullPointerException 現在は親属性が正しく処理され、NullPointerException は発生しなくなりました。
CR127379	管理対象サーバに再接続する際、config.xml に指定されたホスト名ではなく、IP アドレスを使用していました。その結果、ホスト名の検証が機能していませんでした。 ホスト名を使用して再接続するように修正され、ホスト名の検証が機能するようになりました。
CR127563	システム プロパティ net.http.URLStreamHandlerFactory が、認識されるプロパティのリストに含まれていなかったために認識されていませんでした。 認識されるプロパティのリストに追加され、認識されるようになりました。
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Ｏ でも機能しません。 [ヘルプ] メニューには、これらのコマンドは表示されなくなりました。
CR134843	FileCount を実行すると、ログ ローテーション前に取得したディレクトリ コンテンツのキャッシュ値が使用されていました。これらの値には最新のログ ファイルが含まれておらず、ファイル数が設定された値よりも 1 つ多いことがありました。 ローテーション後にディレクトリ コンテンツを再読み込みするように修正したことで、FileCount が正しく実行されるようになりました。
CR135573	管理対象サーバを MSI モードで起動したときに、msi-config.xml ファイルが正しくレプリケートされていませんでした。 キャッシュ済みの値を使用する代わりに、サーバが MSI モードで実行されているかどうかを毎回チェックするようになりました。その結果、管理対象サーバを MSI モードで起動したときに、msi-config.xml ファイルが正しくレプリケートされるようになりました。
CR172017	JMX を使用してリモート サーバ上に新しいサーバを作成する場合、同じ名前のサーバがすでに存在していても、WebLogic Server は NullPointerException を送出しなくなりました。
CR174775	システム プロパティ management.discover が、認識される WebLogic Server プロパティのリストに含まれていなかったため、認識できないプロパティ警告を生成していました。プロパティの機能には問題はありませんでしたが、警告メッセージが表示されていました。 認識される WebLogic Server プロパティのリストにシステム プロパティ management.discover が追加され、警告メッセージは表示されなくなりました。
CR175474	Web アプリケーションがデプロイされているサーバが利用できない状況でその Web アプリケーションを削除すると、コード アサーション エラーが送出されていました。 アサーションが削除され、Web アプリケーションの削除処理が継続されるようになりました。 上記の状況でアサーション エラーが送出されることはなくなりました。
CR175911	システム プロパティ weblogic.jsp.windows.caseSensitive が、認識される WebLogic Server プロパティのリストに含まれていなかったため、認識できないプロパティ警告を生成していました。プロパティの機能には問題はありませんでしたが、警告メッセージが表示されていました。 認識される WebLogic Server プロパティのリストにシステム プロパティ weblogic.jsp.windows.caseSensitive が追加され、警告メッセージは表示されなくなりました。
CR176445 CR183762	アプリケーションの EJB の割り当てにネストされた作成コマンドを使用しようとすると、NullPointerException が送出されていました。 ネストされた作成コマンドを処理しても NullPointerException は送出されなくなりました。
CR177106	generateConfig が、Sun ではなく JAVA_VENDOR SUN を使用して起動スクリプトを生成していました。 起動スクリプトが Sun を使用して正しく生成されるように修正されました。
CR177534	管理対象サーバのログ メッセージが書き込まれていて転送する必要がある場合でも、メッセージはドメイン ログに転送されていませんでした。これには 2 つの理由があります。 1) LogManager.readConfiguration を使用し、WebLogic Server ハンドラをルート ロガーから削除したり、ルート ロガーに追加したりすると、ログは不意に閉じられていました。 2) 管理対象サーバで、大きなスタック トレースのあるログ メッセージがドメイン ログに転送されると、ドメイン ログの転送メカニズムはメッセージの転送を中止しました。 コードを変更してこの問題を解決しました。現在、メッセージはドメイン ログに想定どおりに転送されます。
CR17997、CR248538	ログ ローテーションで、Info タイプのメッセージとして記録されるべきメッセージ BEA-170017 および BEA-170018 が Alert タイプのメッセージとして記録されていました。 ログ ローテーション メッセージ BEA-170017 および BEA-170018 が変更され、Info タイプのメッセージとして記録されるようになりました。Alert となる BEA-170017 および BEA-170018 に依存していたプログラムや動作は、Info に依存するように変更する必要があります。
CR182115	指定された名前の MBean が存在しないと、weblogic.Admin ツールがカスタム タイプの MBean (commo) を取得しようとしていました。その結果、監査記録が紛らわしいものになっていました。 指定された名前の MBean が存在しない場合には、commo MBean をルックアップしたり作成したりする代わりに、weblogic.Admin ツールが InstanceNotFoundException を送出するようになりました。その結果、監査記録が紛らわしくなくなりました。
CR182686	起動クラスやサーブレットでシステム プロパティを設定している間に、ConcurrentModificationException が送出されることがありました。 プロパティを同期するように修正したことで、システム プロパティの設定時に ConcurrentModificationException が送出されることはなくなりました。
CR183420	getFullPath が @excluded だったため、クライアントからは利用できませんでした。 アプリケーションから applicationMBean.getFullPath() を呼び出すと、管理サーバのアプリケーション パスを取得できるようになりました。
CR183836 CR197100 CR187104	ログ記録をキャッシュすると、OutOfMemory 状態になっていました。 オプションが追加され、キャッシュするログ メッセージの数を 0 から無制限の間でコンフィグレーションできるようになりました。このオプションを指定しない場合のデフォルト値は、これまでどおり 500 です。
CR183961	WebLogic Server Ant タスク「nice shutdown」に、コンフィグレーション可能な遅延時間がありませんでした。 「Delay=」機能が追加され、停止前に秒単位で遅延を指定できるようになりました。
CR184080 CR177963	weblogic.Deployer を使用して EAR のデプロイ/再デプロイを繰り返すサイクルにおいて、管理対象サーバの永続的な世代領域が、OutOfMemory エラーが報告されるまで肥大化していました。 Mbean が登録解除されたときにメタデータのハッシュマップ エントリを削除するように修正されました。これにより、デプロイと再デプロイを繰り返すことによる OutOfMemory エラーは発生しなくなりました。
CR184787	Administration Console で、[デプロイメント記述子] ページのセッション パラメータにおいて PersistentStoreType の「replicated_if_clustered」の値が表示されていませんでした。その結果、記述子が保持されていると、記述子に別の値が追加されていました。 Administration Console に値が表示され、記述子に正しい値が追加されるようになりました。
CR185307	WLConfig Ant タスクで、「parent」を使用して「Parent」MBean 属性を設定していました。 WLConfig Ant タスクで正しい属性が使用されるように修正されました。
CR186644	Administration Console で LoadOrder 属性を修正すると、誤って PathURI 属性が更新されていました。 デプロイメント後は PathURI を設定不可にすることで、LoadOrder を修正したときに誤って PathURI が更新されることはなくなりました。
CR191198	ErrorDestination 親要素を、WLConfig スクリプトと WL 管理スクリプトを使用して JMS Queue に設定することができませんでした。 WLConfig スクリプトと WL 管理スクリプトが正しく機能するようになりました。これらを使用して ErrorDestination をデプロイ済みサーバに設定できます。
CR191340 CR252299	-Dweblogic.Stdout オプションと -Dweblogc.Stderr オプションを同時に使用して標準エラーと標準出力をファイルにパイプする場合、weblogic.Stderr オプションで指定されたログ ファイルに、標準出力が誤って書き込まれました。一方、-Dweblogc.Stderr オプションが使用されていても、標準エラーはどのログ ファイルにも書き込まれませんでした。 現在は、-Dweblogic.Stdout および -Dweblogc.Stderr オプションを使用して標準エラーと標準出力をファイルにパイプすると、標準エラーと標準出力は正しいログに記録されます。
CR191350	以下のプロパティに問題がありました。 -Dweblogic.Stdout=myserver/myserver_stdout.log -Dweblogic.Stderr=myserver/myserver_stderr.log これらのプロパティは認識される WebLogic Server プロパティのリストに含まれていなかったため、これらを使用すると認識できないプロパティが生成されていました。プロパティの機能には問題はありませんでしたが、警告メッセージが表示されていました。 認識される WebLogic Server プロパティのリストにこれらのプロパティが追加され、警告メッセージは表示されなくなりました。
CR194076	WebLogic のロギング レベルが FINE に設定されており、WebLogic Server に大きな負荷がかかると、すべてのロギングがハングしていました。 ログ記録キャッシュへのアクセスが同期化され、パフォーマンスが向上しました。 WebLogic のロギング レベルが FINE に設定されていて、WebLogic Server に大きな負荷がかかっても、ロギングはハングしなくなりました。
CR194477	WebLogic Server WLCONFIG Ant タスクで内部データ構造が正しく初期化されておらず、セキュリティ MBean (COMMO MBean) を正しく処理できていませんでした。その結果、WLCONFIG Ant タスクでカスタム プロバイダを作成すると、NullPointerException が発生していました。 WLCONFIG を修正したことで、セキュリティ MBean を正しく処理できるようになり、WLCONFIG Ant タスクでカスタム プロバイダを作成しても NullPointerException は発生しなくなりました。
CR196774	WebLogic Server の起動時に WebLogic コンフィグレーション プロパティが使用され、そのプロパティが WebLogic Server 管理サブシステムにとって不明なものであると、重大度が WARNING のメッセージがログに記録されていました。 メッセージの重大度が INFO に引き下げられ、メッセージの本質を正確に反映するようメッセージ テキストが変更されました。
CR197981 CR200953	メッセージ ブリッジをクラスタにデプロイした場合、サーバの再起動後に通知リスナ メッセージを正しく受信できなくなっていました。 コードを修正したことで、通知が正しく配信されるようになり、ブリッジを適切にデプロイして発見できるようになりました。
CR202252	登録済みの RemoteNotificationListener を実装する MBean の登録を解除すると、メモリ リークが発生していました。その結果、ガベージ コレクションではこのメモリをクリーンアップすることができませんでした。この問題が原因で、メモリ不足の状態になる場合がありました。 MBean 上のすべてのリスナは、登録解除前に削除されるようになりました。これにより、登録済みの RemoteNotificationListener を実装する MBean の登録を解除しても、メモリ リークは発生しなくなりました。

プラグイン

変更要求番号	説明
CR095984	NSAPI プラグインを使用している場合、ファイル サイズが 30KB を超えると、413 メッセージではなく IE 6.0 の DNS エラー メッセージを受信していました。 MaxPostSize コンフィグレーションの動作が、プラグインの有無にかかわらず同じになるように修正されました。
CR100070	Apache-WLS プラグインで処理するすべてのリクエストのデバッグを有効にするか無効にするかを 1 つのグローバル デバッグ フラグで指定していたため、各仮想ホストの WLLogFile を保守するのが容易ではありませんでした。 デバッグ オプションを最上位レベルで指定し、これを仮想ホストや Location タグごとに上書きできるようになりました。
CR136968	response.addHeader メソッドを使用した場合に、Weblogic Server が複数のヘッダを受け付けていませんでした。 プラグインが、WWW-Authenticate に複数の値を保持できるように修正されました。
CR178792	(Apache) HTTP リクエストには、Content-Length または Transfer-Encoding のいずれかのヘッダを含めることができます。 しかし、Transfer-Encoding ヘッダが「chunked」に設定されたリクエストが入出力エラーで失敗していました。 Transfer-Encoding ヘッダが「chunked」に設定されたリクエストをサポートするためのコードが追加されました。
CR180417	クッキーが POST データの一部である場合に、プラグインがクッキーの抽出時に POST データを破損していました。 POST データからクッキーを適切に抽出するためのコードが追加されました。
CR180560	プラグインが WebLogic Server に対して新しい接続を確立しても、ログ ファイルにソケット情報 (localhost:localport remotehost:remoteport) が出力されていませんでした。 プラグインが WebLogic Server に対して新しい接続を確立すると、ローカル ホスト名とローカル ポート番号を含むログ メッセージが追加されるようになりました。
CR180724	初期のクッキーが Web サーバ 1 で作成されクラスタ 1 に送信されたにもかかわらず、このクッキーが再度アプリケーションにヒットすると、Web サーバ 2 を経由し、クラスタ 1 に転送される代わりにクラスタ 2 に送信され、新しいセッションが作成されていました。 WLCrossOverEnabled が正しく機能するように修正されました。
CR182434	rq-> srvhdrs に渡されるヘッダに大文字と小文字が混在していました。本来は、すべて小文字でなければなりません。 Content-Type、Content-Length、および Transfer-Encoding ヘッダがすべて小文字で NSAPI に渡されるように修正されました。
CR182971	DNSRefreshInterval のたびに ServerList が削除され、その結果コア ダンプになっていました。 リスト内のすべてのサーバを DNS ルックアップし、前回のチェック以降にサーバが 1 つでも変更されていたら ServerInfo 構造を更新するように修正されました。
CR183188	ISAPI プラグインでは、Transfer-Encoding ヘッダが chunked に設定されているリクエストを処理できませんでした。 ISAPI が上記のリクエストを処理できるようにするための機能が追加されました。
CR183311	シングルスレッド マルチプロセス モジュールを使用している場合に Apache が停止すると、最初にタイマー スレッドを停止しようとしていました。このタイマー スレッドは存在しないため、コア ダンプが発生していました。 Apache をシングルスレッド マルチプロセス モジュールで使用している場合には、タイマー スレッドが作成されないように修正されました。
CR183390	WebLogic Server が catch ブロック内部から例外を送出していたため、iPlanet でエラーが発生することがありました。 WebLogic Server が catch ブロックから例外を送出しないように修正されました。
CR185089	クライアントが接続を閉じたために WRITE_ERROR_TO_CLIENT 例外が発生すると、IIS プラグインが HTTP ステータス コード 500 (内部サーバ エラー) を送信していました。 IIS プラグインが WRITE_ERROR_TO_CLIENT 例外を捕捉したら HTTP ステータス コード 503 を送信するように修正されました。
CR185668	Apache プラグインで MatchExpressions を使用して複数のクラスタにプロキシすると、リクエストの転送に使用する URL のセグメントの削除 (PathTrim 属性で指定) が失敗していました。 MatchExpressions 解析に strtok API を使用しないようにして再実装したことで問題が解決しました。
CR186148	ページが見つからない場合に、Apache プラグインが 503 エラーではなく 500 エラーを返していました。 プラグインが正しいエラー (503) を返すように修正されました。
CR186148	ページが見つからない場合に、Apache プラグインが 503 エラーではなく 500 エラーを返していました。 プラグインが正しいエラー (503) を返すように修正されました。
CR186470	IIS プラグインを使用している場合に、ファイアウォール経由で新しい接続を大量に作成すると HTTP ステータス 302 となり、接続が閉じられていました。 HTTP ステータス コードが 302 の場合には、接続が再利用されるように修正されました。
CR187282	プラグインが HTTP1.1 仕様の一部 (要求/応答に Content-Length ヘッダと Transfer-Encoding: Chunked ヘッダの両方がある場合は Content-Length ヘッダを無視しなければならない) に準拠していなかったため、プールから接続を再利用した場合にエラーが発生することがありました。 CTE がオンになっている場合は contectLength として -1 を返すように修正されました。
CR187577	VirtualHost タグで複数の Location タグを使用している場合、リクエストが複数の Location に一致すると Apache プラグインが不正な URL を生成していました。 特別に指定しない限り、Apache プラグインで正規表現マッチングが使用されないように修正されました。
CR187578	httpd.conf で KeepAliveEnabled を ON にコンフィグレーションすると、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 がスレッドセーフでないため、これを strchr で置き換えたことでエラーが発生しなくなりました。
CR189933 CR199045	WebLogic Server プラグインがスレッド セーフではありませんでした。SrvrInfo 配列のメモリ アドレスとそのサイズが他のスレッドにも渡されており、他のスレッドから修正することが可能でした。これらが他のスレッドによって修正された場合、最初のスレッドが無効なメモリ位置にアクセスし、セグメント エラーが発生するおそれがありました。 WebLogic Server プラグインがスレッド セーフに修正されました。SrvrInfo 配列を他のスレッドに渡す前に、読み込み専用のコピーを作成するようになりました。
CR190562	Solaris において、WebLogic Server への Post データの送信中にプラグインがパイプの障害を検知すると、リクエストが再試行されなくなっていました。Solaris で sendPostData がパイプ障害を報告すると、WebLogic Server が HALF_OPEN_SOCKET_RETRY 例外を送出するように修正されました。
CR191552	非推奨になったプロパティ MaxSkips が MaxSkipTime に置き換えられました。しかし、この新しいプロパティがコード全体で使用されていませんでした。その結果、パラメータ MaxSkipTime のデフォルト値 (10) を変更することができませんでした。 MaxSkipTime がコード全体で使用されるようになり、この値を変更できるようになりました。
CR192875	readPostDataIntoFile() が try/catch ブロックから新しい例外を送出すると、iPlanet サーバがクラッシュしていました。 一時ファイルに Post データを書き込む際にエラーが発生したら、readPostDataIntoFile() が例外を送出する代わりに例外を返すように修正され、この問題は発生しなくなりました。
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() がサーバの状態を更新するようになりました。
CR198530	非 SSL と SSL のどちらを使用した場合でも、Apache プラグインから WebLogic Server に If-Modified-Since ヘッダが送信されていませんでした。 この問題は解決されています。
CR199045	SSL および非 SSL コンフィグレーションを使用してさまざまなパス値が複数のオブジェクト タグでコンフィグレーションされていると、プラグインが SSL リクエストと非 SSL リクエストを正しく切り替えることができませんでした。 グローバル フラグ (convertDNSSToIP) をリクエストごとのフラグ (ConfigInfo 構造内に移動) で置き換えたことで、プラグインが SSL リクエストと非 SSL リクエストを正しく切り替えることができるようになりました。
CR199446 CR200295	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 proxy のホスト検索で大文字と小文字が区別されなくなりました。これにより、ホスト名のマッチングでも、大文字と小文字が区別されなくなりました。
CR201736	ISAPI プラグインを使用したときに WL-Proxy-SSL ヘッダが欠落しないように修正されました。

RMI/RMI-IIOP

変更要求番号	説明
CR131692	派生した例外が ejb メソッドから送出される場合、その例外には iiop レイヤによって Full Value Description が追加されていましたが、基底の例外には追加されていませんでした。その後クライアント側から基底の例外の情報を取得しようとすると、サーバにその情報がないため例外が送出されていました。 コードを追加して、派生した例外に対する Full Value Description の作成時に、基底の例外の Full Value description も作成されるようにしました。
CR176676	RMI タイムアウトを使用すると、リモート呼び出しを行う RMI クライアントは、呼び出したリモート メソッドが呼び出されたサーバから返されていない場合でも、復帰することができます。つまり、RMI クライアントは応答受信時の通知を待機しません。アプリケーションの性質によっては、応答が到着するまでに時間がかかることがあります。そのような場合、呼び出し側の待機スレッドはブロックされます。RMI タイムアウトでは、リモート メソッドごとにタイムアウト値を指定できるように、(weblogic.ejbc/weblogic.rmic 時に) ハンドルを提供します。
CR177353	アプリケーション クライアントのコードでリモート スタブをキャッシュしてクラスタにデプロイされている SLSB 上のリモート メソッドを呼び出した場合、リモート オブジェクトを利用できるクラスタ ノードを記録するリストが呼び出しごとに更新されていました。このリストは、いずれかのノードが回復可能な例外で失敗した場合に、呼び出しをフェイルオーバするために使用されていました。これに関連して、アプリケーション クライアントで以前の呼び出しからスタブをキャッシュした後でクラスタ全体が再起動されると、フェイルオーバが機能しないという問題がありました。 フェイルオーバ アルゴリズムにおける再試行のロジックが適切ではありませんでした。元々このロジックでは、n 個のノードを持つクラスタに対して n-1 回の再試行が許可されていました。クラスタ全体が再起動されても、キャッシュされたスタブには古い情報を持つリストが含まれたままになりいます。上記の再試行ロジックがその古いリストを走査対象としたため、許可されている再試行の回数を使い果していました。この再試行ロジックで走査対象とするリストを更新する可能性があるのが最終回の試行時だったため、その時点でクライアント サイドのスタブにリストの新しいコピーがあった場合にも、すでに n-1 の試行回数制限に達しているという理由からフェイルオーバが試行されませんでした。 アプリケーション クライアントにキャッシュされているリモート スタブで、既存のリストにあるすべてのノードに対してリモート メソッド呼び出しが失敗した場合にのみ、リストが更新されるようになりました。 その結果スタブには、リストが更新された場合にも、最後に一度フェイルオーバのチャンスが与えられることになりました。この最後の試行が成功しないと、スタブからアプリケーションに例外が送出されます。例外が送出されない場合には、フェイルオーバ機能は仕様どおりに透過的に続行します。
CR179595	再デプロイ中に古いファインダが再利用されていました。そのため、新しいインタフェースと一致する新しいスケルトンが生成されませんでした。代わりに、新しいリモート インタフェースに対して古いスケルトンが使用されていました。 クラスローダが再起動したときに新しいファインダが作成されるようになりました。
CR183490 CR192555	スタブがデシリアライズされたときに、サーバがスタブの接続を呼び出さず、"Delegate not set" という例外が発生していました。 さらに、クラスタへの接続でスタブが取得されたときに問題が発生していました。 スタブがクラスタに接続されたという情報が、デシリアライズされた後には失われていました。デシリアライズ後のスタブには、そのスタブが最後に接続されていたサーバの情報のみが記憶されていました。 com.sun.corba.se.internal.javax.rmi.CORBA.StubDelegateImpl から派生したクラスが拡張されました。StubDelegateImpl から派生した新しいクラスでは、writeObject メソッドと readObject メソッドがオーバーライドされています。オブジェクトの書き込み時に clusterURL も書き込まれるように、またオブジェクトの読み込み時にクラスタの URL も読み込まれるようになり、デシリアライズされたスタブの接続が呼び出されるようになりました。 この新しい機能にアクセスするには、あるシステム プロパティをクライアント サイドに設定する必要があります。プロパティの名前が javax.rmi.CORBA.StubClass なので、追加後のクライアント サイドのスクリプトには以下のような記述が含まれることになります。 -Djavax.rmi.CORBA.StubClass=weblogic.corba.client.iiop.WLStubDelegate
CR184662	ステートフル セッション Bean (SFSB) ハンドルのシリアライズで、IIOP プロトコルを使用している場合に NO_IMPLEMENT 例外が発生しなくなりました。
CR188229 CR196372	JDBCWrapper オブジェクトが、Connection、Statement、ResultSet の各オブジェクトが閉じられた後にもヒープに存在していました。 Connection、Statement、ResultSet の各オブジェクトが閉じられた後に、このような JDBCWrapper オブジェクトがガベージ コレクトされるようになりました。
CR189042	現在の WebLogic Server では、シン クライアントを使用した IIOPS リクエストのプロキシが可能になっています。
CR189042	Squid などの送信用ウェブフィルタを介して IIOPS リクエストをプロキシできませんでした。このようなウェブフィルタでは、HTTP リクエストと HTTPS リクエストのみが許可されていました。 シン クライアントで CONNECT コマンドを使用して、ウェブフィルタを介するプロキシ ソケットを作成できるようになりました。現在では、IIOPS リクエストでこのプロキシ ソケットを使用できます。
CR189067	RMI オブジェクトをホストしているアプレットが、分散ガベージ コレクション (distributed garbage collection : DGC) のタイムアウト期間である 4 分をすぎた時点で、分散ガベージ コレクションの対象になっていました。こうしたアプレットでは DGCServer 用の関連する rtd ファイルをダウンロードできず、それに対して 256 以上の oid を割り当てていました。結果として RMI オブジェクトに対して期間が延長されていなかったため、アプレットが分散ガベージ コレクションの対象になっていました。 この問題を修正するために、ClasspathServlet で .dtd および rtd ファイルを提供できるようにしました。
CR190380	IIOP 接続が初回使用時以降、不規則に失敗するように見える場合がありました。現在では、こうした接続が適切にクリーンアップされ、不規則に失敗するように見えることはなくなりました。
CR192252	ハードウェア ロードバランサで IIOP を利用した場合に、システム プロパティ reconnectOnBootstrap が BEA ORB で適切に動作するようになりました。
CR192648	シン クライアントで SocketImpl クラスを使用した場合に、ネットワーク関連の障害が発生していました。これは、J2SE が SocketImpl クラスを実装を決定する方法に問題があったことが原因でした。 シン クライアントが変更されて、この J2SE の問題が回避されるようになりました。その結果、クライアントはファイア ウォールを介して正しく接続できるようになっています。
CR194465	シン クライアントとトンネリング機能が使用されている場合に、フェイルオーバ中にアプレットでバックエンド サーバのパブリック アドレスの解決が試行され、セキュリティ例外が発生していました。 現在では、トンネリング中のパブリック アドレスの解決は行われません。その結果、シン クライアントとトンネリング機能が使用されていても、フェイルオーバ中にセキュリティ例外が発生しなくなりました。
CR195105	WebLogic Server から不正なポート情報が送信されていたため、スタブのダウンロードの試行中にクライアントが不正なポートに対して接続を試みていました。結果として、wlclient.jar と t3s を併用してシン クライアントを実行できませんでした。 サーバが正しいアドレスおよびポート情報をクライアントに送信するように、CodebaseComponent クラスが変更されました。その結果、シン クライアントがファイア ウォールを介して動作できるようになりました。
CR199420	AsyncMessageSender を使用すると、大きなメッセージの送信時にスレッドがスタックしていました。負荷が継続する状況では、スレッドは無限にスタックしたままでした。 スレッドによる送信がバッチ処理で行われるようになったため、AsyncMessageSender を使用して大きなメッセージを送信した場合にも、スレッドはスタックしなくなりました。

セキュリティ

変更要求番号	説明
CR112486 CR199852	CredentialMapper の持つ特権が、ユーザの資格マッピングをすべての場合において変更するためには不十分でした。 ユーザの資格マッピングをすべての場合に変更するのに十分な特権を持つようになりました。
CR121761	ParsePolicies クラスは特定のパーミッションを適切に解析していませんでした。 この問題は解決されています。
CR124562	WebLogic ログは WLSUser を拡張したプリンシパルを無視していました。そのため、ユーザ フィールドに誤ったプリンシパルが表示されることがありました。 現在は、WebLogic ログは WLSUser を拡張したカスタム プリンシパルを表示します。
CR125177	WebLogic Server は weblogic.security.providers.authentication.LDAPAtnLoginModuleImpl でグループの循環性をチェックしていませんでした。その結果、バックエンドの LDAP グループが自身をメンバーとして持っている場合、多数の LDAPConnections が作成されたためにサーバがクラッシュしました。 現在は IgnoreDuplicateMembership というフラグがあります。このフラグをチェックすると、ユーザが属しているグループのリストにすでに追加されているグループが追加される場合に、警告が出されます。この場合、WebLogic Server は重複したグループを無視します。デフォルトでは、このフラグはチェックされていません。 このフラグはプロダクション モードで機能しますが、プロダクション モードでのパフォーマンスに影響を与えるため、開発モードでのみ使用することをお勧めします。
CR132634	組み込み LDAP サーバで DirContext.close を使用する場合にメモリ リークが検出されました。 この問題は解決されています。
CR132656	起動時に -Dweblogic.security.URLResourceCaseMapping=off というフラグが使用され、サーバが正しく起動された場合にも警告メッセージが表示されていました。 こうした不正な警告は表示されなくなりました。
CR135587	weblogic.system.BootIdentity ファイルの使用は、weblogic.admin ユーティリティの SHUTDOWN と FORCESHUTDOWN 処理でのみサポートされていました。 weblogic.admin ユーティリティの機能が拡張されて、すべての処理で weblogic.system.BootIdentity ファイルの使用がサポートされるようになりました。
CR172261	WebLogic Server の SSL プロトコルの Certicom 実装では、JDK によって同期されたクラスを使用します。この同期が原因で SSL セッション スレッドがハングしていました。 SSL 実装で、JDK の外部で同期されたクラスが使用されるようになりました。この変更で SSL セッション スレッドの問題は解決しました。
CR172912	2 つの信頼性のある CA 証明書が同じサブジェクト名を持っている場合、WebLogic SSL 実装では最初の証明書のみを使用していました。その結果、SSL クライアントがピア証明書の検証チェックに失敗することがよくありました。 この問題は解決されています。現在は、2 つの信頼性のある CA 証明書が同じサブジェクト名を持っている場合、SSL 実装では、提示されたピア証明書に対する適切な信頼性のある CA 証明書を見つけます。
CR175966	http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04-72.00.jsp のセキュリティ勧告を参照してください。
CR176306	組み込み LDAP サーバ用の多重化可能ソケットで、メッセージ長の計算が不正確でした。その結果、組み込み LDAP 内のデータが管理対象サーバのクラスタにレプリケートされていませんでした。 利用可能なバイトおよび LDAP メッセージが正しく計算されるようになりました。
CR177522	JMS 呼び出しの際にコンテキストが開かれて、サブジェクトのスタックにサブジェクトがプッシュされました。コンテキストが閉じられてもサブジェクトが削除されなかったため、余分なサブジェクトがスタックに残されました。 アプリケーションが処理を続行し、ある時点で保護されたリソースにアクセスすると、その余分なサブジェクトが現在のサブジェクトとしてスタックから取得されました。場合によっては、そのサブジェクトが必要な権限を持っていないため、リソースへのアクセスが拒否されました。コンテキストを閉じるとスタックからサブジェクトが削除されて、正しいサブジェクトがスタックの一番上に戻りました。
CR177523 CR189057	接続をプロキシしている場合に、ホスト名検証において対象のシステムのホスト名ではなくプロキシのホスト名が検証され、検証エラーが発生していました。 対象のシステムのホスト名が検証されるようになりました。
CR179633	クライアント プログラムが WebLogic Server への相互認証された SSL 接続を確立しようとすると、接続を確立してそのタスクを 1 回だけ実行することができました。それ以降に接続を確立しようとしても失敗しました。 この問題は解決されています。
CR180729	組み込み LDAP サーバを使用していて、グループ メンバシップが判断されるときに、LDAP の etc/group および etc/passwd ディレクトリからのメンバシップ情報が処理されていませんでした。 etc/group および etc/passwd ディレクトリに指定されているメンバシップ情報の結合と取得が行われるようになりました。
CR180841	セキュリティ サービス マネージャに areWebAppFilesCaseInsensitive() を追加すると、大文字/小文字の設定の計算がクライアント プロセスで変更されました。その結果、ある URL リソースで、セキュリティ ロールおよびセキュリティ ポリシーのコンフィグレーションと表示が失敗しました。 この問題は解決されています。
CR180972	発信 SSL 接続のパフォーマンスが JSSE の場合と比較して遅くなっていました。これは、各送信リクエストに対して新しい SSLSocketFactory が作成されていたためでした。 リクエストに対する証明書がない場合には、SSLSocketFactory がキャッシュされるようになりました。
CR181263	weblogic.management.username コマンドライン プロパティが無視されていました。 ユーザ名を取得するには、boot.properties ファイルを検索するか、ユーザに入力を促す以外に方法がありませんでした。 利用可能な boot.properties ファイルがない場合に weblogic.management.username コマンドライン プロパティを使用してユーザ名を取得できるように、コードを追加しました。 WebLogic Server では、以下のようなプロセスでユーザ名を取得します。 1. boot.properties ファイルが存在する場合には、boot.properties ファイルを検索する。 2. weblogic.management.username コマンドライン プロパティを使用したユーザ名の取得を行う。 3. ユーザにユーザ名の入力を促す。
CR182006	x509 証明書に対する SubjectAlternativeName 拡張が重大 (クリティカル) としてマークされていたことが原因で、証明書認証が失敗しました。 x509 証明書でこの拡張が重大 (クリティカル) としてマークされていても、SSL ハンドシェーク中にその証明書が検証されるようになりました。
CR182702	web.xml ファイルで (/*) を指定して Web アプリケーションが制限されている場合に、ルートディレクトリ (/) へのアクセスに制約がありませんでした。たとえば、アプリケーションが foo であり、web.xml でポリシーが (/*) と定義されている場合、結果として /foo は保護されませんでした。 現在は、web.xml ファイルで (/*) を指定して Web アプリケーションが制限されている場合、ルート ディレクトリ (/) へのアクセスは制約されます。
CR182860	Web ブラウザがセキュア ポートを介してプレーン テキストを送信した場合に、SSL はメッセージ ヘッダを誤って解釈し、メッセージが終了するまでに実際より多くのデータを待機していました。この遅延によって SSL ハンドシェークで問題が発生しました。サーバは SSL ハンドシェークを完了しようとして CPU を 100% 使用していました。この問題は、読み込まれるバイト数の数値エラーが原因で起きました。 この数値の問題は解決されました。セキュア ポートにプレーン テキストのメッセージを送信したクライアントは、より早くエラーを受け取ります。サーバは CPU の使用率が 100% になってハングすることはなくなりました。
CR184203	サーバをクラスタに追加すると、追加されたサーバはクラスタ内の他のサーバから同期を目的として情報を取得していました。クラスタが SSL ポートのみを使用するようにコンフィグレーションされていて、SSL 接続を確立するためにクライアントの証明書が必要な場合に、同期が失敗していました。この問題は、新しいサーバ (SSL クライアント) がクラスタ内の他のサーバに証明書を提示していなかったことが原因でした。 この問題は解決されています。
CR185283 CR197577	T3 または IIOP プロトコルを使用する場合、WebLogic Server インスタンス間でセキュリティ コンテキスト (javax.security.auth.Subject) が伝播されていませんでした。 現在は、サーバから発信 CSIv2 セッションが確立されるたびに、WebLogic 資格マッピング プロバイダが呼び出されます。資格マッピング プロバイダは、AuthenticatedSubject プリンシパルではなく、着信 CSIv2 プリンシパルを使用してセキュリティ コンテキストを伝播します。WebLogic 資格マッピング プロバイダは着信プリンシパルの資格にはアクセスできないことに注意してください。 資格が必要な場合は、WebLogic 資格マッピング プロバイダがアクセスできるように、カスタム認証プロバイダで資格をサブジェクトに追加する必要があります。
CR185315 CR199865	WebLogic Server における LDAP サーバの実装には、独自のスレッドで動作する接続ハンドラ検索がありました。ただし、この実装ではスレッドを正しく開始および停止していなかったため、スレッドのメモリが回復されていませんでした。 接続ハンドラがスレッドとして実行されないように実装を変更しました。この変更によって、通常どおりにメモリが回復されます。
CR185438	WebLogic Server と外部 LDAP サーバの間にロード バランサまたはファイアウォールがコンフィグレーションされている場合に、外部 LDAP サーバへの接続が中断されることがありました。 現在では、接続が中断された場合に自動的に更新されるようになり、ユーザのリクエストは処理中に接続が中断された場合にも完了します。
CR185792	LDAP 接続が LDAP サーバによって削除された場合、WebLogic は新しい接続を取得していました。ただし、古くなった接続は消去されていませんでした。 互換性レルムを使用する場合、古くなった LDAP 参照が正しく消去されるようになりました。
CR186186	Certicom のコードでは UTF8 を不適切に処理していました。String のバイトを個々の文字として扱っていたため、スカンジナビアの文字を使用したときに NullPointerException が発生しました。 現在は UTF8 を正しく処理します。
CR186916	SubjectUtils.isUserInGroup には 2 つの点で問題がありました。 特定のクラスのプリンシパルのみを取得するには、各プリンシパルを評価しながらプリンシパルのセットを作成した後、そのプリンシパルのセットを検索して、あるプリンシパルが対象のグループに属しているかどうかを調べる必要がありました。ここでは事実上、プリンシパルに対して 2 つの検索が行われていました。1 つはサブジェクトのすべてのプリンシパルを取得するための検索、もう 1 つはグループ名に関する検索です。 javax.security.auth.Subject インタフェースから AuthenticatedSubject を取得して、サブジェクトがグループ内にあるかどうかを検索しようとしても、そのサブジェクトが認証されていない限りできませんでした。つまり、サブジェクトを認証してから、サブジェクトが属しているグループを判別するという追加のサイクルが必要でした。 解決策 : 現在は、すべてのプリンシパルをサブジェクトから取得し、指定された WLSGroup を調べるために 1 回だけ検索するようになりました。 最初のパラメータとして AuthenticatedSubject を取る 2 つ目のメソッドを追加しました。どちらの public isUserInGroup () メソッドも、サブジェクトではなくプリンシパルのセットを使用する内部的な isUserInGroup () メソッドを呼び出すように変更されました。このメソッドによって、サブジェクト (Subject) から AuthenticatedSubject に変換する必要がなくなりました。
CR190679	検証プロセスでコンフィグレーションの変更を検出しなかったため、保持されている認証されたサブジェクトが 2 番目のセッションで再使用可能でした。 指定した時間を過ぎて行われたリクエスト中に、存在する認証されたサブジェクトを再認証する機能が新しく追加されて、この問題は解決しました。
CR191229	証明書認証がコンフィグレーションされている場合に、保護されていないリソースに対する認可が行われていました。その結果、匿名ユーザのアクセスが拒否されていました。 現在は、証明書認証がコンフィグレーションされている場合に、保護されていないリソースに対する認可は行われなくなりました。
CR191419	weblogic.security.X500Name クラスに Serializable メソッドが実装されるようになりました。
CR193305	ServletContextListener から JDBCConnection MBean に問い合わせた後、Administration Console から関連する EAR をデプロイすると、アプリケーションが正常にデプロイされた場合でも NoAccessRuntime 例外が送出されました。 この問題は解決されています。
CR196410	WebLogic Server セキュリティ レルムを互換性セキュリティのレルムと相互運用している場合に、認証されたサブジェクトが尊重されませんでした。 デフォルトでは、認証されたサブジェクトをネットワーク経由で受け取った場合には、そのサブジェクトは尊重されません。WebLogic Server Administration Console に [許可された WLSUser プリンシパル] 属性が追加されました。WebLogic 認証プロバイダでこの属性を有効にすると、認証されたサブジェクトをネットワーク経由で受け取った場合にもサブジェクトは尊重されます。
CR196578	WebLogic Server 6.1 と WebLogic Server 8.1 を相互運用している場合に、8.1 のサーバ インスタンスに対して送信された認証されたユーザが、適切に尊重されませんでした。その結果、java.rmi.AccessException が送出されました。 認証されたユーザは認証されたサブジェクトに変更されました。 現在では、WebLogic Server 6.1 を WebLogic Server 8.1 と相互運用した場合にも java.rmi.AccessException は送出されません。
CR199331	このリリースでは weblogic.servlet.security.CertificateServlet インタフェースが非推奨になっています。したがって Certificate Request Generator も非推奨です。Certificate Request Generator サーブレットの代わりに、Sun Microsystems の keytool ユーティリティを使用してください。
CR201690	getLatestFailure() メソッドは NoSuchElementException を送出しなくなりました。

サーブレット

変更要求番号	説明
CR087857	JSP ページまたはサーブレットによって文字エンコーディングが設定された場合に、ServletOutputStream.write(int) メソッドが (引数として int 型をとるにもかかわらず) 指定された文字セットのエンコーダを使用してエンコードされたデータを受け取っていました。 ServletOutputStream.write(int) が呼び出された場合に、バイナリ データがエンコードされなくなりました。
CR106348	リスナで障害があったため、Web アプリケーションがアンデプロイされずに、不安定な (デプロイされた) 状態のままになりました。 リスナで障害が発生した場合 (デプロイメントが正常に行われていない場合)、Web アプリケーション デプロイメントはロールバックされます。
CR108736 CR191543	init に対する呼び出しの作成中にユーザによって ServletException にラップされた例外が送出されると、ServletException の例外の原因が失われ、さらに ServletException 用に出力された行番号が正しくありませんでした。 現在ではこの問題は適切に処理されています。この例外のログは正しい行番号と ServletException の根本的な原因を出力するようになりました。
CR134351	WebLogic Server の HttpURLConnection に対してデフォルトの読み込みタイムアウトを設定するために、weblogic.http.client.defaultReadTimeout フラグが導入されました。 このフラグを設定すると、JVM で作成される新しい HttpURLConnection には、その値がデフォルトで設定されます。この値は、特定の接続に対する setTimeout または setReadTimeout 呼び出しでオーバーライドできます。このフラグを使用しない場合、デフォルト値は -1 になります。値はミリ秒単位で指定します。
CR136410	HTTP アクセス ログのサイズに基づくローテーションが、マルチプロセッサ マシンでは適切に機能していませんでした。いくつかのログ ファイルが作成された後でローテーションが正しく動作しなくなり、最終的にはファイルの同じ 2 つの世代に対する上書きを開始していました。 比較関数が修正されて、新しいログ ファイルが必要に応じて作成されるようになりました。
CR172077 CR193354	Web アプリケーションのデプロイ中に、インストールされたアプリケーションが application.xml 内のモジュールの順序にしたがってデプロイされていませんでした。 サーバの起動時に ServletInitService.resume によって、デプロイされた Web アプリケーションの preloadResources が呼び出されましたが、サーブレットは必ずしも Web アプリケーションがデプロイされた順序で呼び出されるわけではありませんでした。 サーバの起動時に、あらかじめロードされたサーブレットが Web アプリケーションがデプロイされたのと同じ順序で呼び出されるようになりました。
CR172088	壊れた If-Modified-Since Http ヘッダを含むリクエストに対して HTTP 500 エラーが返されていました。 If-Modified-Since Header が不正な場合には、その If-Modified-Since Header が無視されるようになりました。
CR172672	すでに閉じられている接続を HttpClusterServlet が再利用しようすると、HttpClusterServlet は SocketException を受け取り、WebLogic Server を BAD とマークしていました。 接続の再利用時に HttpClusterServlet が SocketException を受け取ると、HttpClusterServlet が新しい接続を使用して同じ WebLogic Server に接続を試みるようになりました。
CR174501	複数の Web アプリケーションがシングル サインオンに参加している場合、いくつかの Web アプリケーションでセッションが無効化されませんでした。 すべての Web アプリケーションでセッションが適切に無効化されるようになりました。
CR175097 CR173748	Web アプリケーション デプロイメントで web-inf/lib JAR ファイルを .wlnotdelete ディレクトリに抽出しているときに、JAR ファイルのタイム スタンプが保持されていませんでした。その結果、JSP コンパイルが失敗していました。 現在は、.wlnotdelete ディレクトリに抽出されるときに JAR ファイルのタイムスタンプは保持されます。
CR175651	サーバのアンデプロイメント中またはシャットダウン中に、Web アプリケーションに対する処理中のリクエストを完了できるようにするには、weblogic.xml の以下の要素を使用します。 <container-descriptor> <inflight-request-timeout-secs>120</inflight-request-timeout-secs> </container-descriptor> プロパティ inflight-request-timeout-secs にはサーバが待機する秒数が秒単位で示されます。デフォルトでは、サーバは処理中の作業を待機しません。
CR175781	weblogic.net.http.HttpUrlConnection の HttpUrlConnection.getOutputStream() が複数回呼び出された場合に、OutputStream から以前の内容が削除されていました。 それまでに OutputStream に書き込まれていたデータが失われていました。 接続が存在するかどうかがチェックされ、存在する場合には OutputStream がリセットされないようになりました。
CR177095	weblogic.appc を使用していて、アプリケーション コードでコンテキスト クラスローダを使用している場合に、WEB-INF\lib ディレクトリのクラスに対して ClassNotFoundException が送出されていました。 このような状況で ClassNotFoundException が送出されることはなくなりました。
CR177730	シングル サインオンを利用している場合に wl_authcookie が転送されませんでした。 セッションが明示的にログアウトされるか無効化されるまで、wlauthcookie が再利用されるようになりました。Web アプリケーション間に渡って wlauthcookie を再利用することで、新しいユーザが最初の Web アプリケーションにログインしても、シングル サインオンが有効のままになりました。
CR179800 CR181640 CR173782	JavaServer Faces v1.0 参照実装の最終バージョンの一部のサンプルは、起動時の事前のロードに失敗します。次の ServletException が表示されます。 <Mar 16, 2004 10:31:09 AM MST> <Error> <HTTP> <BEA-101216> <Servlet: "Faces Servlet" failed to preload on startup in Web application: "jsf-guessNumber". javax.servlet.ServletException この問題は、サーブレット リスナを登録するためのロジックを Web アプリケーションの起動時に追加することで解決しました。これは、アプリケーションの lib フォルダにある .tld ファイルで定義されます。
CR179941	オプティミスティックなシリアライゼーションが有効になっていて、リクエストがサーブレット コンテキストを超えてディスパッチされる場合に、getAttribute(name) のコンテキストとリクエスト属性がシリアライズおよびデシリアライズされませんでした。 ClassCastExceptions を回避するためには、Web アプリケーションに共通する属性を共通の親クラスローダのスコープ (アプリケーション スコープなど) の中に含めるか、Web アプリケーションが同じアプリケーションに属さない場合にはシステム クラスパスに配置する必要があります。 オプティミスティックなシリアライゼーションが無効になっている場合 (デフォルトの状態) には、getAttribute(name) のコンテキストとリクエスト属性はシリアライズおよびデシリアライズされ、ClassCastException は回避されます。 オプティミスティックなシリアライゼーションを有効にするには、以下のコマンドライン フラグを使用します。 "-Dweblogic.servlet.optimisticSerialization=true"
CR181747 CR189395 CR200944	response.addHeader メソッドを使用した場合に、Weblogic Server は WWW-Authenticate ヘッダの複数の値を受け付けていませんでした。 WebLogic Server は WWW-Authenticate に複数の値を保持できるようになりました。
CR181754	WebLogic Server がサスペンド状態の場合にも、保護されたリソースに対して新しいリクエストが送信されると、その保護されたリソースのリクエスト用に新しいセッションが作成されていました。 リクエストをリダイレクトする前に、サスペンド状態かどうかがチェックされるようになりました。
CR184326 CR188237	HttpClusterServlet は内部ストリームに対して書き込みを行っており、クライアントに独自の外部ストリームを使用する独自の応答ラッパーがあるケースが無視されていました。 クライアントに独自の応答ラッパーがある場合、応答用の外部ストリームではなく独自の外部ストリームが適切に使用されるようになりました。
CR184745	DirectoryIndexEnabled が使用されていて、対象のディレクトリにマルチ バイト名のファイルがあると、ディレクトリ インデックス ページが壊れて適切に取得されませんでした。 GBK と MS950 に対する java-iana のマップを保持して、マルチ バイト名のファイルを適切に取得できるようになりました。
CR184997	この CR (キャンディデート版リリース) では、date オプションでコンフィグレーションされた HTTP ログ ローテーションが考慮されます。 あるローテーション期間中に何もアクティビティがなかった場合、HTTP ログ ローテーションではその期間がすぎてもログ ファイルのローテーションを行っていませんでした。特定のローテーション期間におけるアクティビティの有無に関わらず、ローテーション期間をすぎたときには常にローテーションが行われるようにロジックが追加されました。
CR185289	自動フラッシュが 「false」 に設定されていて、コンテンツ長がバッファ サイズの制限を超える場合に、ChunkOutput.writeStream で無限ループが発生していました。 新しいリクエストが処理されるたびに自動フラッシュのフラグをリセットするコードを追加して、この問題を解決しました。
CR185289	自動フラッシュが 「false」 に設定されていて、コンテンツ長がバッファ サイズの制限を超える場合に、ChunkOutput.writeStream で無限ループが発生していました。 新しいリクエストが処理されるたびに自動フラッシュのフラグをリセットするコードを追加して、この問題を解決しました。
CR185885	サーバの正常な停止の過程で Web アプリケーションが登録解除されるときに、HTTP コンテナから 503 Service Unavailable ではなく 404 が返されていました。このため、プラグインでフェイルオーバを試行できませんでした。 サーバがサスペンド状態になった場合に、ステータス コード 503 が返されるようになりました。
CR188348	WebLogic Server の HttpURLConnection は、http.keepAlive が無効になっている場合でも、 Connection: Keep-Alive ヘッダ (または Proxy-Connection: Keep-Alive ヘッダ) を送信していました。 現在は、-Dhttp.keepAlive=false プロパティを指定して Keep-Alive を無効にすることができます。
CR190652	WebLogic Server は、RequestDispatcher を呼び出す HEAD リクエストを行う場合に例外を送出しなくなりました。
CR191347 CR178729	Web アプリケーションを管理対象サーバにデプロイしてからその管理対象サーバが停止すると、Web アプリケーションを削除してからコンソールを使用して再コンフィグレーションしても、Web アプリケーションはその管理対象サーバに再デプロイされませんでした。 新しいバージョンの Web アプリケーションは、管理対象サーバの停止中に再コンフィグレーションした場合にも、その管理対象サーバに再デプロイされます。
CR191427	cs-uri フィールドが指定されている場合に、クエリ文字列が 2 度ロギングされていました。 現在では、cs-uri フィールドが指定されていても、クエリ文字列は 2 度ロギングされません。
CR191946	WebLogic Server の Web アプリケーション コンテナで、Weblogic の内部 Web アプリケーションのセキュリティが初期化されていませんでした。その結果、プロキシ ヘッダ WL-Proxy-Client-Cert が無視されていました。 現在は、WebLogic Server の Web アプリケーション コンテナで、Weblogic の内部 Web アプリケーションのセキュリティが初期化されます。プロキシ ヘッダ WL-Proxy-Client-Cert は無視されなくなりました。
CR193743	同じ外部 Web アプリケーションに対して複数の include() 呼び出しが行われたときに、セッションが失われました。 この問題は解決されています。
CR194121	ChunkUtils で ChunkTransferDisabled を true に設定すると、java.lang.NullPointerException が送出されました。 この問題は解決されています。
CR195698	external_stage 領域で古い WAR モジュールを新しいモジュールで置き換えると、404 エラーが発生していました。 temp フォルダに実際のアプリケーションをステージングすることでこの問題を解決しました。
CR197121	WebAppServletContext.getResourcePaths() で、Web アプリケーションの weblogic.xml にコンフィグレーションされている仮想ディレクトリに加えて、Web アプリケーションのルート ディレクトリ下のディレクトリとファイルも返されるようになりました。
CR198536	WebLogic Server に予想外の障害が発生した場合に、access.log ファイルから ELF ヘッダが失われることがありました。これは、ログがローテーションされたときに ELF ヘッダが即座にフラッシュされていなかったことが原因でした。 ログのローテーション後に ELF ヘッダが即座にフラッシュされるようになりました。その結果、access.log ファイルから ELF ヘッダが失われなくなりました。
CR199958	(EAR の) application.xml ファイルまたは (特定の Web アプリケーションの) weblogic.xml ファイルに context-root がない場合、WebLogic Server は context-root を、WAR ファイルの名前から (.war を除いて) 取得するか、Web アプリケーションが展開形式の場合はルート ディレクトリの名前から取得していました。取得した context-root が既存の Web アプリケーションですでに使用されている場合は、ユニークにするためにカウンタ (/foo-1、/foo-2 など) を付加していました。 たとえば、/root/apps/app1/foo.war がデプロイされていて、application.xml または weblogic.xml ファイルで context-root が指定されていない場合、/foo という context-root が取得されます。その後で、/root/apps/app2/foo.war から別のアプリケーションがデプロイされると、context-root の衝突を避けるために、/foo-1 という context-root が取得されます。 同じ名前の WAR ファイルを何度もデプロイできるため、このメカニズムは便利でした。ただし、クラスタのデプロイメントでは問題が起きていました。 WebLogic Server 8.1 SP4 以降のリリースには、このカウンタのメカニズムはありません。現在は、context-root の衝突が起きた場合、WebLogic Server はアプリケーションのデプロイを許可しません。そのため、現在は application.xml ファイルまたは weblogic.xml ファイルでユニークな context-root を指定する必要があります。
CR199958	Web アプリケーション モジュールの数が増加したときに、Web アプリケーション モジュールのコンテキスト ルートの表示が壊れることがありました。 現在の WebLogic Server では、同じコンテキスト ルートに対する複数のアプリケーションのデプロイメントをサポートしていません。 代わりに、コンテキスト ルートに以下の例に示すようなインデックスが追加されました。 以前のコンテキストルート : /test 現在のコンテキスト ルート : /test-1、/test-2 など 現在では、Web アプリケーション モジュールの数が増加しても Web アプリケーション モジュールのコンテキスト ルートの表示が壊れないようになっています。
CR200043	Weblogic Server の検証ルールの下では、ブラウザから渡されたロケールのバリアントが予期しない結果を招いていました。ロケールのヘッダの解析ロジックで、バリアントの部分が考慮されていませんでした。 言語ヘッダの解析中にロケールのバリアントが考慮されるようになりました。言語ヘッダはたとえば次のような形式になります。 lang-country-variant;q=weight

SNMP

変更要求番号	説明
CR083630	SNMP トラップおよび通知内の特定の文字列がローカライズされていませんでした。 文字列にマルチバイト文字が含まれていると、その文字列が正しく表示されませんでした。 String 型の値がローカライズおよびインターナショナライズされ、マルチバイト文字がサポートされるようになりました。現在は、ログ メッセージ トラップの日本語文字が適切に表示されます。
CR190218	Integer 型の戻り値を持つ double 型の属性値に対する自動キャストが失敗していました。 データ型間の変換が、値を返す前に適切に行われるようになりました。その結果、Integer 型の戻り値を持つ double 型の属性値に対して自動キャストが失敗しなくなりました。
CR194161	SNMP サービスが停止されたときに、管理対象サーバが動作している場合にも、ドメインにコンフィグレーションされている各サーバに対して serverDown トラップが送信されていました。 現在では、SNMP サービスが停止されて管理対象サーバが動作している場合には、SendAutomaticTrapsEnabled 属性の設定が true のときに限って、管理サーバに対してのみ serverDown トラップが送信されるようになっています。

ツール

変更要求番号	説明
CR124030	アプリケーションの .ear ファイルを Marathon 内で開いた場合に、何も変更していないのに無効な記述子が書き出され、その結果アプリケーションが appc に合格しませんでした。 アプリケーションを Marathon で開いても内容が壊れないようになりました。
CR136334	負荷のかかった状態で BEA JDBC ドライバを使用すると、以下のエラーが発生していました。 java.lang.OutOfMemoryError: unable to create a new native thread この問題は解決されています。
CR183190	パッケージの dynamicSections で java.sql.SQLException は発生しなくなりました。

Web サービス

変更要求番号	説明
CR136707 CR196499	Web サービスの内部で HttpServletRequest を取得できなかったため、リモート クライアントの IP を取得できませんでした。 現在の WebLogic Server では、Web サービス内部の HttpServletRequest を WebServiceSession.getRequest() を介して取得するためのパブリック API が提供されています。これは HttpServletRequest にキャストされる必要があります。 以下のような方法で HttpServletRequest の取得が可能になっています。 WebServiceContext wsContext = WebServiceContext.currentContext(); WebServiceSession vHttp = wsContext.getSession(); String remoteAddr = ((HttpServletRequest)(vHttp.getRequest())).getRemoteAddr();
CR161835	信頼性のある Web サービスを JMS 転送機能と併用すると、AssertionError が発生していました。 信頼性のある Web サービスと JMS 転送機能との併用がサポートされるようになりました。
CR172119	WebLogic Server では、SOAP の制限により WSDL (Web Services Description Language) での過負荷オペレーションがサポートされていません。しかしながら、こうしたオペレーションの検出が clientgen の実行時に行われていなかったため、clientgen がコンパイル エラーで失敗していました。 WSDL での過負荷オペレーションがあった場合に、clientgen で WSDLParseException が送出されるようになり、コンパイル エラーが発生しなくなりました。
CR172463	Web サービス クライアントからサーバに対して JSESSIONID クッキーのみを渡すことができました。 非 JSESSIONID のクッキーの使用がサポートされるようになりました。
CR176392	WebLogic Server 8.1 のサービスの呼び出しに、WebLogic Server 6.1 をベースとした Java コンポーネントを使用しようとすると、weblogic.webservice.WebServiceLogger を呼び出そうとしたときにエラーが発生していました。 wsclient81.jar に weblogic.webservice.WebServiceLogger.class が含まれるようになり、このエラーは解消されました。
CR177273	テスト ページで、java.lang.String 以外のデータ型の空白を入力すると受け付けられませんでした。 テスト ページで、すべての組み込み Java データ型の空白の入力が受け付けられるようになりました。
CR177611	autotype で生成された型マッピング ファイルを servicegen で利用した場合に、web-service.xml にネームスペースに関する問題が発生していました。 servicegen で、autotype で生成された型マッピング ファイルのネームペースが認識されるようになりました。
CR178683	xml メッセージの署名検証プロセスにおけるマルチスレッドについての問題を回避するために、8.1 sp3 で XMLSignature.validate() に同期機能が追加されていました。その結果、パフォーマンスは逆に低下していました。 xml メッセージの署名検証プロセスにおけるマルチスレッドの問題が解消され、パフォーマンス向上のために同期機能を削除しました。
CR180643 CR200646	以下の手順を踏んだときに、GenericClassLoader でメモリ リークが発生していました。 1. Web サービス アプリケーションをデプロイする 2. Web サービスを呼び出す 3. Web サービス アプリケーションをアンデプロイする GenericClassLoader に関するメモリ リークは発生しなくなりました。
CR181775	xmlType が既知のスキーマの要素ではない場合、デプロイ中に動的に型が生成されます。そのため生成された wsdl では、インポートされた元のスキーマでの要素名が保持されていませんでした。 システム プロパティ -Dweblogic.webservice.noDynamicTypeGeneration を追加して、このプロパティを true に設定すると元の要素名が保持されるようにしました。
CR181987	2 つの問題が報告されていました。 1. アプリケーションのアンデプロイメント後に、JMS キュー内の最初のメッセージの配信が失敗していました。 2. 2 つのポートが同じ処理を指している場合に WebServiceOperationRuntime MBean が 2 度作成され、そのために javax.management.InstanceAlreadyExistsException が発生していました。 アプリケーションがアンデプロイされたときにも、最初のメッセージが配信されるようになりました。 2 つのポートが同じ処理を指している場合にも、WebServiceOperationRuntime MBean が 2 度作成されなくなりました。
CR182483	応答において、無効な XML 文字が文字参照を介してエンコードされていませんでした。 無効な XML 文字が文字参照を介してエンコードされるようになりました。
CR183382	複合型の内部で属性として QName 型が使用されている場合に、その QName 型が正しくマーシャリングされませんでした。 複合型の内部で属性として使用されている場合にも QName 型がマーシャリングされるようになりました。
CR183555 CR192555 CR192568	JAX-RPC クライアントでは、SESSION_MAINTAIN_PROPERTY を使用したセッションの固定が維持されませんでした。 現在は、SESSION_MAINTAIN_PROPERTY が以下のように設定されている場合に、セッションの固定がサポート されます。 Call オブジェクトで次のように設定します。 call.setProperty(Call.SESSION_MAINTAIN_PROPERTY, "true"); または call.setProperty(Call.SESSION_MAINTAIN_PROPERTY, new Boolean("true")); Stub オブジェクトで次のように設定します。 (Stub)port)._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, "true"); または (Stub)port)._setProperty(Stub.SESSION_MAINTAIN_PROPERTY, new Boolean("true"));
CR183676 CR195447 CR128604	シーケンスおよび要素を含む複合型が定義されていて、シーケンスに maxOccurs> 1 とある場合、応答において要素の配列に不要な外部レイヤの追加が試行され、結果として「weblogic.xml.stream.XMLStreamException: attempt to add an attribute to a null start element.」例外が送出されていました。 条件のチェックがさらに追加されて、要素の配列に不要な外部レイヤが追加されることはなくなりました。
CR185228	「weblogic.webservice.client.ssl.strictcertchecking」が false に設定されていない場合に Web サービスの SSL クライアントがサービスへの接続に失敗していました。 このプロパティが true または false のどちらに設定されていても、サービスに接続できるようになりました。
CR185260 CR196682	autotype で XML スキーマの複合型の JavaBean 表現を生成する場合、その複合型の選択ブロックに属性および要素の両方が含まれていると、生成された JavaBean 表現に不備がありました。選択ブロックの要素に対する Bean のセッター関数により、Bean に関連付けられているすべての属性の値が消去されていました。 属性値が消去されないようにコードを追加したことで、XML スキーマの複合型の適切な JavaBean 表現が生成されるようになりました。
CR186319	xml ファイルに 32 個を超える連続した空白がある場合、ファイルの解析に長い時間がかかっていました。 バッファ サイズを増加して、xml ファイルをより効率的に解析できるようにしました。
CR187327	WebLogic Workshop 8.1.2 で生成された Web サービスの WSDL に対するクライアント jar の生成に clientgen を使用すると、以下のエラーが発生しました。 weblogic.xml.schema.binding.internal.builtin.XSDDurationSerializer; overridden method does not throw weblogic.xml.schema.binding.SerializationException clientgen を使用して、このようなクライアント jar を生成できるようになりました。
CR188548	clientgen で [WebserviceName].XML が作成された場合に Web サービスのクラス名にマルチバイト エンコーディングが含まれていると、XML はシステムのデフォルトのエンコーディングで作成され、ファイル内ではエンコーディングが指定されませんでした。 デフォルトで、ヘッダおよび内容の書き出しに、指定されたエンコーディング (-Dweblogic.webservice.i18n.charset) または UTF-8 が使用されるようになりました。
CR189853	weblogic81.webservice.util.FaultUtil の fillDetail メソッドで以下のコードが使用されていました。 Throwable.getCause。これは JDK 1.4 API 仕様のメソッドです。JDK 1.3 では、Throwable クラスに getCause メソッドは存在しません。 そのため、WebLogic Server 6.1 のクライアントを使用して、WebLogic Server 8.1 SP3 (またはそれ以前) の Web サービスに対して HTTPS を介したアクセスを行うと、以下のエラーが発生していました。 java.lang.NoSuchMethodError at weblogic81.webservice.util.FaultUtil.fillDetail(FaultUtil.java:84) NoSuchMethodError を補足することでこの問題は修正され、エラーも解消されました。
CR190030	clientgen の実行時に codegen で protected の指定されたコンストラクタ Enumeration が呼び出され、親クラスが SimpleType の場合に SOAPElement のマッピングが子クラスに伝播していませんでした。その結果、clientgen はコンパイル エラーを 2 つ送出して失敗していました。 Enumeration コンストラクタの呼び出しが試行されなくなったため、親クラスが SimpleType の場合にも SOAPElement のマッピングが子クラスに伝播されるようになりました。したがって、clientgen も期待通りにコンパイルされます。
CR190527	Web サービスに対してメッセージ レベルのセキュリティが有効化されている場合に、リクエストのメッセージが特定のサイズを超えると、そのリクエストのメッセージを暗号化しようとしたときに JSAFE_InvalidUseException が送出されていました。 大きなリクエストのメッセージに対して暗号化を試行する場合にも、JSAFE_InvalidUseException が送出されなくなりました。
CR192510	Weblogic Web サービス クライアントで、セキュアな非 WebLogic Web サービスの呼び出しに WSSEClientHandler を使用している場合、クライアントが応答の処理時に SOAPException: unknown source type を受け取っていました。 このような状況で例外が送出されなくなりました。
CR195535	wsdl2service から生成された web-services.xml ファイルでは URI が Web サービス名になっていました。この URI は、クライアント アプリケーションで Web サービスの呼び出しに使用する URL の serviceURI 部分であるべきでした。 現在では、wsdl2service から生成された web-services.xml ファイルの URI に、以下の例で完全な URL に含まれた serviceURI にあたる部分が使用されます。 http(s)://host:port/contextURI/serviceURI Web サービスの呼び出しに使用する完全な URL が上記の形式にしたがっていない場合には、正しい URI を web-services.xml ファイルに手動で入力する必要があります。
CR195817	HTTPS が使用されている場合には、weblogic.webservice.binding.BindingInfo.setTimeout() メソッドを使用して Web サービス クライアントのタイムアウトを設定しても、クライアントに対して効力を持ちませんでした。 現在では、HTTPS を使用していても、このメソッドでクライアントに有効な設定ができます。
CR197241	webserviceclient+ssl.jar ファイルには重複したクラスが存在するため、jarsigner を使用してこのファイルを署名できませんでした。以下の例外が送出されていました。 jarsigner: unable to sign jar: java.util.zip.ZipException: duplicate entry: weblogic/utils/StringUtils.class jar ファイル内の重複したエントリが削除されました。その結果、現在では jarsigner を使用して webserviceclient+ssl.jar ファイルを署名できるようになり、例外も送出されません。
CR197698	クライアントサイドのコード変更の結果、Web サービスの HTTPS クライアントが java.net.UnknownHostException: null で失敗しないようになりました。
CR198996	SOAP メッセージ内の Content-type ヘッダの文字セット名が単一引用符で囲まれている場合に (以下の例を参照)、いくつかの非 WebLogic の Web サービスに対して WebLogic Server から SOAPFaultException が送出されていました。 Content-Type: text/xml; charset='utf-8' この文字セット名を囲む単一引用符は不要なため、削除されました。文字セット名での単一引用符の使用に起因していた SOAPFaultException は送出されなくなりました。
CR199190	WSDL (Web Service Description Language) のスキーマに 225 を超える子要素を持つ要素が定義されている場合に、clientgen によって生成された Bean のソースのコンパイルが失敗していました。 現在の WebLogic Server では 225 を超えるパラメータを取るコンストラクタは生成されなくなり、この問題は解決されました。
CR199783	Web サービス クライアントで weblogic.webservice.rpc.timeoutsec が設定されている場合に、再試行が行われていました。 現在の WebLogic Server では、Web サービス クライアントで weblogic.webservice.rpc.timeoutsec が設定されている場合には再試行を行わなくなっています。

WebLogic Tuxedo Connector

変更要求番号	説明
CR127288	ローカル ドメインで、リモート Tuxedo ドメインの CORBA C++ サーバに対する WTC を介した CORBA リクエストを作成すると、WTC がハングしていました。 WTC がハングしていたのは、CORBA リクエストの送信先のリモート Tuxedo ドメインで対象とする CORBA C++ サーバがクラッシュしていて、WTC が WLS ExecuteThread を拘束していたためでした。
CR182219 CR201408	WTC をコンフィグレーションした後で、サーバの JNDI ツリーで Tuxedo ドメインを検索すると、TGIOP プロトコルを使用した Tuxedo への接続が試行されます。このプロトコルはサーバが管理するプロトコル リストにないため、UNKNOWN_QOS エラーが発生します。不明なプロトコルが使用された場合には、そのプロトコルの QOS の取得は試行されません。また、セキュアでないポートに対する接続がセキュアなプロトコルを使用して行われようとしているかをチェックするセキュリティ チェックが省略されます。
CR185475	CALL_SET_TRANSACTION_TIMEOUT を true に設定することにより、XA 対応トランザクションの Oracle に対するタイムアウトがサポートされました。
CR185974	Tuxedo CORBA サーバが停止している場合に、Tuxedo に対するトランザクション対応の CORBA 呼び出しが無限にハングします。トランザクションはドメインに渡って GWTX_ACTIVE (TMGACTIVE) のままであり、setTransactionTimeout() を無視します。
CR186628	WTC サービスがアンデプロイされたときに、tBridge がクリーンアップされません。このため tBridge のスレッドがリークします。
CR187267	スレッドを多数使用した場合に、WTC であまりに多くのコンテキストの切り替えが発生します。
CR187873	トランザクション対応のアクティビティが進行しているときに強制停止が行われると、エラー状態に陥ります。WLS が起動できずに、メモリ リークが発生します。
CR189922	CARRAY 型のフィールドが空 (長さがゼロ) の場合、Tuxedo では意図される通りに長さをゼロとして取得できず、4 バイトが返されます。
CR189983	WTC サービスをアンデプロイしてから再デプロイした場合に、the tBridge のリダイレクト機能が再開されません。
CR194516	トランザクションにおいて、WTC を介して (Tuxedo CORBA サーバでの ATMI エラーに起因する) CORBA 例外を受け取った場合に、WLS の実行スレッドが無限にハングします。
CR196598	不明な WTC リモート Tuxedo ドメインから WTC に対して接続が試みられると、WTC メモリ リークが発生していました。
CR198265	xa_end を呼び出すときに WTC によって XA の例外が補足されません。
CR201408	この問題は CR182219 と同じです。 WTC をコンフィグレーションした後で、サーバの JNDI ツリーで Tuxedo ドメインを検索すると、TGIOP プロトコルを使用した Tuxedo への接続が試行されません。このプロトコルはサーバが管理するプロトコル リストにないため、UNKNOWN_QOS エラーが発生します。不明なプロトコルが使用された場合には、そのプロトコルの QOS の取得は試行されません。また、セキュアでないポートに対する接続がセキュアなプロトコルを使用して行われようとしているかをチェックするセキュリティ チェックが省略されます。
CR201682	WTC エクスポートはローカル アクセス ポイントおよびリモート名によってユニークに識別され、リソース名によっては識別されません。

WebLogic Workshop

変更要求番号	説明
CR189420	配列リストが繰り返しがあるとして扱われ、繰り返し処理された結果、ConcurrentModificationException が送出されていました。 同期に関する問題が解消された結果、ConcurrentModificationExceptions は送出されなくなりました。

XML

変更要求番号	説明
CR135726	特定のスキーマの構成を処理できない場合、そのスキーマの構成は SOAPElement にマップされます。 この場合、サポートされていないスキーマの構成を検知したことについて autotype では何も示されず、生成されたクラスを調査した場合にのみ、何らかの問題があることが示されました。 特定のスキーマの構成を処理できずに SOAPElement にフォール バックされた場合に、警告メッセージが示されるようになりました。
CR175990	WebLogic Server の組み込み Xerces で、URI 中のエスケープされないマルチバイト文字列が受け付けられませんでした。 現在の WebLogic Server では、マルチバイト文字列は UTF-8 文字エンコーディングに基づいてエスケープされます。
CR184002 CR198219	SOAP の署名された文書の最後から </soap:Envelope> タグが削除されていて、証明書でその点を許容しないにも関わらず、この問題が検証を通っていました。 文書の形式が正常でない場合に XMLSignatureMalformedException が送出されるようになりました。