ORACLE JAPAN Server Release 6.1

 

  |  

  WebLogic Server ホーム   |     リリース ノート   |   前へ   |   次へ   |   目次   |   索引   |   PDF 版

解決済みの問題

 

以下の節では、WebLogic Server 6.1 のサービス パックで解決された問題について説明します。サービス パックは累積的であり、現行リリースのサービス パック 6 にはそれ以前にリリースされた WebLogic Server 6.1 用のサービス パックで行われたすべての修正が含まれます。

 


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

この節では、WebLogic Server 6.1 SP07 で解決された問題を示します。

この節に示されている情報は暫定的なものであり、変更されることがあります。

変更要求番号

説明

CR184891

アプリケーションをリモート サーバにアップロードする際に使用されるコンソール JSP では、サーバが開発モードでない場合に ApplicationManager.update() メソッドを呼び出していた。

ProductionMode が有効な場合の ApplicationManager.update() の呼び出しを削除した。 アップロードされるアプリケーションは、プロダクション モードが有効な場合は自動的にデプロイされなくなった。

CR097378

Web アプリケーション デプロイメント記述子の編集中に、Administration Console で NullPointerException 例外が発生することがあった。

WebLogic Server は記述子が null かどうかをチェックしていなかった。null の場合は記述子を解析できなくなる。 そのため NullPointerException が送出された。

記述子が null の場合は、適切なエラー アクションが呼び出されて、正しいメッセージが表示されるようになった。

CR097036

サーブレット 2.3 仕様に従って getServletContext のコードが変更されたため、コンソール ページで正しいアイコンが取得されなかった。

console.war の images サブディレクトリへのパスを提供するように、buildIconList() のコードを変更した。

ナビゲーション アプレットで正しいアイコンが表示されるようになった。

CR044503

[パーミッション] を空白にして新しい ACL を作成すると、予期しないエラーが発生した。 原因は、名前に null や空白の値がないかどうかチェックされない場合があることだった。

適切なチェックが追加されて、null の名前に対するメッセージが修正された。

CR082966

GraphApplet の getParameter() は、最大または最小ヒープ サイズの値を取得するために使用する。 戻り値の型は long だが、WebLogic Server は Integer.parseInt を使用して文字列値に変換していた。 ヒープ サイズが 2GB を超えるときにこの解析が失敗すると、デフォルト値の 1 がコンソールに表示された。 そのため、現在の空きメモリが負の数字で報告されることがあった。

WebLogic Server は Long.parseLong を使用して、ヒープが 2GB を超える場合でも、ヒープの正しい値を取得するようになった。

CR079771

WebLogic Server はクラスタの起動やドメインの起動/強制停止の操作結果を報告するために、ブラウザにファイル リンクを送信していた。 そのリンクは、ブラウザが管理サーバと同じマシンで実行される場合にのみ機能した。 これはすべてのプラットフォームで同様だった。

WebLogic Server は、ファイルを処理してブラウザに HTML 形式で出力を送信するアクション リンクを送信するようになった。

CR077058

JMSJDBCStore が作成されるときの、[接続プール] ドロップ ダウン リストから [なし] オプションが削除された。

JDBCConnectionPool を null にする機能を追加して、リストに [なし] が表示されるようにした。

CR069130

web.xml ファイルに誤りのあるアプリケーションがアプリケーション ディレクトリに追加されたとき、Administration Console はそのアプリケーションが起動時にデプロイされていなくても、デプロイ済みとして報告した。

WebLogic Server はそのようなアプリケーションをアンデプロイ済みとして正しく報告するようになった。

CR075168

WebLogic Server はトークンの区切り文字として大なり記号「>」を使用していた。 そのため、カスタム メッセージに「>」が含まれていると、表示の際にメッセージが切り詰められていた。

WebLogic Server はログに書き込むときに最後のトークンを切り詰めなくなった。

Administration Console

変更要求番号

説明

CR128510

MsgAbbrevInputStream の readClassDescriptor() がクラスを解決しようとすると、不明なクラスに対する ClassNotFoundException が発生していた。 Java シリアライゼーションでは、対応するデータが読み込まれていないと、この ClassNotFoundException がスキップされる。

MsgAbbrevInputStream の readClassDescriptor() は不明なクラスを解決しようとしなくなった。また、MsgAbbrevInputStream は resolveClass() を実装した。

クラスローダ

変更要求番号

説明

CR135131

weblogic.cluster.MulticastObjectListener は objectAdded の呼び出しの際にロックされて、HashMap のロックを待機していた。一方別のスレッドでは、MulticastReceiver が HashMap をロックし、MulticastObjectListener でのロックを試行していた。 このため Java レベルのデッドロックが発生した。

ロックの順序を変更してデッドロックを排除した。

CR127765

クラスタ内のあるノードが再起動されたときに、最初に他のクラスタ メンバーとの同期を取ろうとしたところ、あるサーバが他のサーバをクラスタ ビューに追加した。

クラスタ ノードがリスン ポートを開く前に、このクラスタ ノードにセカンダリとしてリクエストが入ると、エラーが発生した。それ以降、このクラスタ ノードでセカンダリを作成する要求はすべて失敗した。

現在のクラスタの同期化では、ノードが起動されると、最初にクラスタ内のすべての実行中ノードを識別し、その後で自身を識別するブロードキャストを送信するようになった。 したがって、起動されたクラスタ ノードは、リスン ポートを開いた後で他のノードによって識別される。

CR127643

Web アプリケーション内で宣言されたインタフェースを実装した動的プロキシが HttpSession に入り、そのセッションがレプリケート可能であった場合に、WebLogic Server ではセカンダリ サーバでそのインタフェースのクラスをロードすることができなかった。

アプリケーション アーカイブに格納されたインタフェースを実装する動的プロキシが HttpSession に入り、正しくレプリケートされるようになった。

CR111029

デフォルトの 30 秒間のタイムアウト期間中にハートビートを受信しなかった場合、クラスタ メンバーはタイムアウトしていた。 ハートビートは 10 秒おきに送信される。クラスタ メンバーがタイムアウトして使用不能であると宣言されるまで、サーバはハートビートの受信を 3 期間 (合計待機時間は 30 秒) 待機していた。 たとえば、セッション レプリケーション中にセカンダリ サーバが TCP レベルで使用できなくなった場合、非常にビジーな Web サイトでは 30 秒の待機期間は長すぎることもあった。 セカンダリがクラスタ ビューから削除される前に、プライマリが多数のセッションをセカンダリにレプリケートしようとした場合、サーバがハングしたり速度が低下したりしていた。

現在、タイムアウト値 IdlePeriodsUntilTimeout はチューニング可能になった。 config.xml ファイルの <Server IdlePeriodsUntilTimeout="3"> タグで設定される。 通常はこの値はチューニングせず、デフォルト (3) のままにしておくのがよい。 ただし、負荷、アーキテクチャで許容される冗長性、特定のアプリケーションの問題、プロダクション環境の特定の状況などによっては、この値を慎重にチューニングすることで、根本的な原因を特定して修正するまでの間、問題を一時的に軽減することができる。

この値を変更するときは特に注意し、アプリケーションに最大の負荷をかけて十分にテストを行い、予期しない動作を確認することを推奨する。 あらゆる状況に当てはまる推奨事項はないため、この値を変更する必要がある場合は、負荷のテストを必ず行うこと。

クラスタ

変更要求番号

説明

CR184914

サービスの停止中にセグメンテーション違反があった。 あるサービスを停止するときにロギング サービスが停止して、不正なアクセスが発生した。

サービスを停止するときのセグメンテーション違反を修正するコードを追加した。

CR182684

beasvc サービス ハンドラが呼び出されるたびに、beasvc ログは呼び出されたことを示す行を追加していた。

次に例を示す。

Tue Apr 27 11:52:17 2004] [I] [service_ctrl] 4

そのため、サーバで実際のアクティビティがないときにログが一杯になった。

デバッグ文を削除して、ログの問題を解消した。

CR181986

サービスとして実行される WebLogic Server が多数のスレッドを使用すると、メモリ不足になることがあった。

beasvc.exe と beasvc64.exe で使用される予約スタック サイズを 1MB から 256KB に減らすことで、メモリの問題を解消した。

CR176614

WebLogic Server 70 (または 81) のサーバから WebLogic Server 61 のサーバ/クライアントに渡されたステートフル セッション Bean (SFSB) ハンドルが、シリアライゼーション コードで ClassNotFoundException により失敗した。

WebLogic Server 6.1 のサーバに比べて、WebLogic Server 70 および 81 のサーバは EJB コンテナの SFSB に異なる PK メカニズムを使用している。

相互運用性の要件をサポートするために 6.1 に必要なクラスを追加して、ClassNotFoundException を回避した。

CR174605

ドキュメントの「サーバの起動と停止」の節では、CLASSPATH が長すぎる場合でも 1 行としてファイルに追加され、-classpath @filename としてアクセスできると説明されていた。 しかし、beasvc は CLASSPATH ファイルの内容をロードするとき、ファイルの末尾に改行がない場合に最後の文字を削除した。

beasvc はファイルの最後が正しいかどうかを判断し、それに従ってファイルを読み込むようになった。

CR173958

フロントエンドとバックエンドの間のプロトコルを「セキュア」から「非セキュア」に変更した場合に、t3 を使用した 6.1 SP4 ドメインと 8.1 SP2 ドメインの相互運用性が正しく機能していなかった。 認証呼び出しの際に、フロントエンド QOS がバックエンドに伝播され、呼び出しに失敗していた。

この問題は、ブートストラップ認証呼び出しに「匿名」を使用することで解決した。

CR172366

beasvc.exe からイベント ログに出力されるメッセージが、日本語環境では正常に表示されなかった。

コードを修正したことで、英語以外のすべての言語環境でも、英語のメッセージが出力されるようになった。

CR135225

RJVM と NTSocketMuxer の間でデッドロックが発生していた。

WebLogic Server がディスパッチ中に IORecord でロックを保持しないようにするコードを追加した。そのためデッドロックは発生しなくなった。

CR134971

(サーバ サイドから) 例外メッセージ フィールドの一部として <<no stack trace available>> が送信されたとき、rmi レイヤはサーバ サイド スタック トレースとして例外を繰り返し追加していた。 そのためログ ファイルが一杯になった。 この状況は、サーバでヒープが不足し、アプリケーション コード (EJB + サーブレット) によって NullPointerException が送出されたときに明らかになった。

WebLogic Server は例外メッセージ フィールドを解析してこの特殊な例外を捕捉し、例外は 1 回だけ追加されるようになった。

CR133880

大きな負荷がかかっている場合、T3File クライアントが OutputStream/InputStream を閉じるときに ArrayIndexOutOfBoundsException を送出することがあった。

WebLogic Server はループを開始する前にベクトル上でロックを取得するようになった。

CR175607

WebLogic Server をアンインストールした直後に Windows サービスとしてインストールしなおすと、誤ったレジストリ キーが作成されることがあったため、正常に起動できなくなる問題が発生していた。

コードを修正したことで、レジストリ キーがフラッシュされて正しく閉じられるようになった。

CR130409

カスタム キュー上の「リソースを大量に消費する動作の遅い」リクエストを抑制するために -Dweblogic.kernel.allowQueueThrottling フラグを使用して実行キューの最大長を設定しても、クライアントは 503 応答を受け取ることなくタイムアウトを待たなければならなかった。

この問題は、呼び出し側のディスパッチの戻り値をチェックし、sendError() API を使用して 503 応答を返すようにコードを修正することで解決した。

CR130376

ドキュメントの「サーバの起動と停止」の節では、CLASSPATH が長すぎる場合でも 1 行としてファイルに追加され、-classpath @filename としてアクセスできると説明されていた。 しかし、beasvc が CLASSPATH ファイルの内容をロードする際に最後の文字が削除してしまうことがあったため、上記の説明どおりには機能していなかった。 この問題は、ファイルが改行で終わっていない場合にのみ発生していた。

コードを修正したことで、beasvc はファイルが正しく終了していることを確認した上で読み込むようになった。

CR129094

AIX プラットフォームにおける、t3 プロトコルでの TCP ウィンドウの縮小に関連するパフォーマンスの問題は解決された。

CR122939

プライマリ サーバとのセッションを維持できないことが原因で、分散デッドロックが発生していた。 プライマリでもセカンダリでもないサーバにリクエストが到着すると、セカンダリだけでなくプライマリでも既存のセッションの削除が試行され、現在のサーバで新しいセッションが作成されて、新しいセカンダリが登録される。 その過程で、このサーバは非ブロッキング キュー上のセッションを削除するリモート要求をプライマリに対して行い、プライマリ サーバは非ブロッキング キュー上のそれ自体を削除する削除呼び出しをセカンダリ サーバに対して行う。 そのようなリクエストが複数ある場合、非ブロッキング キューにはスレッドが 2 つしかないので現在のサーバで応答を受信する他のスレッドは存在せず、そのために分散デッドロックが発生する。

WebLogic Server は、非ブロッキング キューに入ってくるリクエストを処理している間は新しいリモート要求を行わなくなった。 これで、この問題は解決される。非ブロッキング キューに、応答を受信するスレッドが常に存在するようになるからである。

コア

変更要求番号

説明

CR135367

EJBStatelessHomeRuntimeMBean の実装クラスではプールの統計の正しい詳細を提供していなかった。

実行時 MBean メソッドで正しいプールの統計を提供するようにコードが変更された。MBean の呼び出しで正しいデータが示されるようになった。

CR127097

ステートフル EJB のモニタ ページでは、出力の前にマシン名が表示されていなかった。

そのため、エントリが示しているのがどのマシンかわからなかった。

ステートフル EJB のモニタ ページにマシン名が追加された。

CR124026

6.1 で read-only 同時方式が Exclusive 同時方式を使用した。 この設計で、Bean への排他的アクセスは保証されるが、1 対多の関係で生成されるセットへの排他的アクセスは保証されなかった。 2 つのクライアントが同じセットへアクセスし、そのセットに対してイテレータを同時に呼び出すと、NullPointerException が発生した。

WebLogic Server は、2 つのクライアントが 1 つのセットに対してイテレータを呼び出しても NullPointerException を送出しなくなった。

CR104539

CR102308

WebLogic Server 6.1 SP04 で、Administration Console がエンティティ Bean の待機に関する不正確な値を報告した。

この問題は、waiterCurrentCount 属性を追加したことによって解決された。この属性は、クライアントがロック待機を開始するときに増加し、ロックを取得またはクライアントがタイムアウトしたときに減少する。

CR096398

EJBContext.getRollbackOnly() は、トランザクションがロールバック用にマークされていて、まだロールバックされていない場合に「true」を返した。 トランザクションがロールバックされた後だと「false」を返した。

EJBContext.getRollbackOnly() はトランザクションが既にロールバックされている場合でも「true」を返すようになった。

CR060229

Administration Console はステートフル EJB とエンティティ EJB の [コミットしたトランザクション数]、[ロールバックしたトランザクション数] または [トランザクションのタイムアウト総数] を表示していなかった。

Administration Console でこれらの項目をモニタできるようになった。

CR087261

EJBDeployer はメッセージ駆動型 Bean のログに誤ったデプロイメント メッセージを書き込んでいた。

メッセージ駆動型 Bean がデプロイされるときに正しいメッセージがログに記録されるようになった。

EJB

変更要求番号

説明

CR079432

MessageLocalizer は、l10ngen ユーティリティを使用して、ローカライズされたカタログ ファイルに l10n_package 属性を設定していなかった。

MessageLocalizer はローカライズされたカタログ ファイルに l10n_package 属性を正しく設定するようになった。

I18N

変更要求番号

説明

CR142730

長いデータベースの停止の後、TestConnectionsOnReserve が true に設定されている XA jDriver for Oracle を使用する JDBC 接続プールが、データベースとの接続を回復および再作成できていなかった。 以下のエラー メッセージが送出された。

<Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: open failed for XAResource 'oracleXAPool' with error XAER_RMERR : A resource manager error has occurred in the transaction branch.

および

<Warning> <JDBC> <001096> <Refreshing this bad pool connection failed weblogic.common.ResourceException: java.sql.SQLException: LDA pool exhausted - make sure you call Connection.close()

その停止の間に、JDBC 接続プールが接続を再作成しようとしたが、失敗したときに、その接続の試行がクリーンアップされず、(LDA において) Oracle クライアントのリソースが枯渇していたことが問題だった。

jDriver は、失敗した接続作成の試行をクリーンアップするようになった。

CR134285

weblogic.db.oci.OciLob クラスでは、データベースから返された BLOB データまたは CLOB データの byteArray を保持する 2 つのクラスレベルの変数が定義されていた。 このバイト配列はかなり大きくなる場合があるので、OciLob の各インスタンスはガベージ コレクションが行われるまですぐにヒープを一杯にしていた。

さらなるテストと、クラス レベルの変数 retBArray[] と retCArray[] をメソッドに移動する OciLob の修正により、変数がスタックに割り当てられるようになり、OciLob オブジェクト インスタンスのサイズが削減されて、全体的なヒープの使用量が減少した。

メモリ ヒープの使用量を削減するためにグローバル変数 retBArray と retCArray をメソッド レベルに移動するコードが追加された。

CR172462

AL32UTF8 文字セットが使用されているときに、WebLogic Server jDriver が Oracle 9.2 で正しく機能していなかった。

この問題は、コードを修正することで解決した。

CR136168

WebLogic jDriver は、負荷が大きい状態で Long raw 型を使用しているときに、Oracle エラー メッセージ ORA-02392 でサーバをクラッシュさせることがある。

この問題を解決するコード修正が実装された。

CR129220

WebLogic Server Oracle jDriver は、ガベージ コレクション用に Clob オブジェクトを正しく解放していなかった。

WebLogic Server は Clob オブジェクトを正しく解放するようになった。

JDriver

変更要求番号

説明

CR127949

Statement.getResultSet() が、不要な新しい ResultSet ラッパーを生成することがあった。

コードを修正して問題は解決された。

CR184143

JDBCConectionPool のプロパティに埋め込まれたパスワードが暗号化されなかった。

コードを変更して Properties 属性からパスワードを削除した。

以下のセキュリティ勧告を参照。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA04_53.00.jsp

CR182410

負荷の高い状況で、WebLogic Server の速度が大幅に低下した。

weblogic.jdbc.common.internal.MultiPool.searchLoadBalance() メソッドから同期化を削除して、負荷の高い状況での速度低下を解消した。

CR133612

サービス パック 7 では、Oracle Thin ドライバが最新の 9.2.0.4 ドライバ (3rdparty/oracle/920 ディレクトリの classes12.zip) に変更された。

CR131575

次のように始まる JDBC 接続のリークに関する誤った警告が送出されることがあった。

[SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: /n

この警告を送信するリーク検出コードは、現在は廃止されている。 この問題は、コードを修正することで解決した。

CR130306, CR135909

jta.DataSource で refreshAndEnlist を実行するときに、WebLogic Server が tx.enlist() を呼び出していたが、refreshAndEnlist の呼び出しで例外が発生した場合に接続がプールに返されていなかった。

コードの修正により、例外が捕捉され、接続がプールに解放されるようになった。

CR129379

EJB トランザクションが多数のエンティティを新しく作成した場合や、JDBC を使用する多数の Bean に 関与している場合に、Oracle カーソルが不足するおそれがあった。これは、Oracle ドライバのバグと思われる現象を回避するため、WebLogic Server がトランザクションが終了するまで JDBC 文を閉じるのを遅らせてそのカーソルを保持していたためである。

この動作を変更したことで、トランザクションが終了するまでカーソルを保持する必要はなくなった。

CR127720

新しいバージョンの JDBC ドライバは、接続のトランザクションの状態を追跡する。 接続でローカル トランザクションがアクティブな場合、その接続で XA の操作は実行できず、xa_start() が呼び出されたときに XAER_PROTO または XAER_RMERR が生じていた。 結果として、アプリケーションでは、ローカル トランザクションを開始したが終了していないコード中の場所を絞り込む冗長なプロセスを実行しなければならなかった。

この問題は、特殊な XA 接続がプールに 2 度解放されないように回復メソッドのコードが修正されて解決した。

JDBC

変更要求番号

説明

CR123194

WebLogic Server 6.1 の以前のサービスパックでは、サーバ インスタンスがダウンしたがそのクライアントはアクティブであり続けている場合に、JMS 仕様どおりの JMSException ではなく、JMS から実行時例外 weblogic.rmi.extensions.RemoteRuntimeException が送出されていた。

この問題はコードの修正によってこのサービス パックで解決された。

CR126192

長期間の JMS 接続で定期的なハートビート チェックが不十分だった。

コードの変更により、JMS が接続の ping を怠るときは、データベースが 5 分おきに接続を更新するようになった。

CR182338

ConnectionFactory で RedeliveryLimit がコンフィグレーションされている場合、RedeliveryLimit の到達回数が MessagesMaximum の設定よりも大きくなると、レシーバはメッセージの処理を停止する。

例 : RedeliveryLimit=0, MessagesMaximum=10。 レシーバは 1 つのメッセージを受け取ると sesssion.recover() を 10 回呼び出す。 レシーバがメッセージの処理を停止すると、コンソールには保留中メッセージ数として 10 と表示される。

コードを追加して、RedeliveryLimit に達したためにキューからメッセージが削除される場合のウィンドウ カウンタを調整するようにした。

CR126183

最大アイドル時間の設定値に達した後に、アイドル状態のブリッジがメッセージをログに記録していた。

アイドル状態のブリッジによって記録される反復的なログ メッセージ「Bridge X start transferring messages」が抑制されるようにするコードが追加された。

ブリッジが停止されて再起動されるか、例外に遭遇して再起動された場合は、「Bridge bridgename starts transferring messages」というログ メッセージが記録されるが、反復的なメッセージがアイドル状態のブリッジによってログに記録されることはない。

CR133155

起動時に JDBC ストアから JMS メッセージを復元するのに、長い時間がかかっていた。 getTables プレフィックスに JMS を含めることで、この問題は解決された。

JMS

変更要求番号

説明

CR136746

JDBC ドライバの明示的なネーミングをクラス VendorId で使用できるようにする拡張要求。

コードを変更してこの拡張を実現した。

JNDI

変更要求番号

説明

CR127959

応答ラッパーを使用し、JSP に渡された元の応答で getOutputStream を呼び出すコードを実行すると、NestedBodyResponse で常に IllegalStateException が送出されていた。

NestedBodyResponse から getWriter() と getOutputStream() を一緒に使用できないようにした。これにより、例外が誤って送出されることがなくなった。

CR133291

デフォルトの fileServlet によるファイルの送信中にクライアントがリクエストを取り消すと、プロトコル例外 excjava.net.ProtocolException: Didn't meet stated Content-Length が発生していた。

この問題は、コードを修正することで解決した。

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/..?%.. にデコードする。

CR143448

サーブレット コンテナの内部呼び出しで java.lang.IllegalStateException: HttpSession is invalid 例外が発生する。 同じセッション ID を使用する他のスレッドが ServletRequestImpl.syncSession() の処理中にセッション オブジェクトを無効化すると、SessionData.putValue() または SessionData.isNew() の呼び出し時に IllegalStateException が発生する場合がある。

セッションが他のスレッドによって無効化されている場合は、IllegalStateException を無視すること。

CR134414

シリアライズ可能なサーブレット リクエスト属性を追加し、これをシリアライズできない値で上書きすると、元の値が新しい値をマスクする。

シリアライズ可能な値がシリアライズできない値に置き換えられる場合には、シリアライズ可能な属性の HashMap テーブルからの値の削除が必要に応じて試みられるように、コードを修正した。

CR132522

デフォルト Web アプリケーションのない Web サーバで、HTTP リクエストが見つからないリソースを要求すると、次のような誤った日付ヘッダを含む応答を受け取った。

HTTP/1.1 404 Not Found Date: Thu, 01 Jan 1970 00:00:00 GMT

このヘッダは、RFC2616 のセクション 14.18 に従うと有効ではない。 この問題は、コードを修正することで解決した。

CR173042,

CR110910

KeepAliveEnabled が true に設定されている場合、大きなファイルのダウンロードがキャンセルされた後に HttpClusterServlet が NumberFormatException を送出していた。

分析の結果、クライアントがファイルのダウンロードをキャンセルしたときに、残りのデータが入力ストリームに残されていたことが判明した。 以降のリクエストで再利用される場合に、サーブレットが残りのデータを読み込んでしまい、その結果として例外が送出されていた。この問題は、ダウンロードがキャンセルされた場合に入力ストリームから残留データが排出されるようコードを修正して解決した。

CR133558

null 値が渡されると、ServletContext.setAttribute が NullPointerException を送出した。

この問題は、setAttribute() に null 値が渡されると removeAttribute() を呼び出すようにコードを修正することで解決した。

CR129211

ServletOutputStream.write(byte) を使用してバッファ サイズより大量の書き込みを行うと、無限ループが発生した。

バッファが一杯で、かつ、autoflush が false に設定されている場合に境界条件のチェックを更新するようにコードを修正することで問題は解決された。

CR128986

プロトコル例外の後に、ensureContentLength メソッドの問題が原因で新しいライセンスを処理しようとしているときにサーバがハングしていた。

サーバがこの処理中にハングしないようにコードを変更した。

CR128420

breakUpAndWriteItOutAsNecessary() は 1 行あたり最大 72 バイトを適用するためにマニフェスト ヘッダを分割しようとし、出力ストリームに一度に 1 行の書き込みを行った。 この問題の原因は、改行の開始オフセットが間違っていることだった。

この問題は、コードを修正することで解決した。

CR127836

ルート コンテキストのサブコンテキストにある JSP は、展開形式ではなく、WAR ファイルにパッケージ化された Web アプリケーションとしてデプロイされている場合、プリコンパイルされた。

JSP は展開形式でデプロイされるときにプリコンパイルされるようになった。

CR127090

JSP は同じ名前の属性を持つ複数の MBean を使用していたため、表示されるときに、実際には重複していないのに属性が重複しているように見えた。

同じ属性名を持つ MBean の属性の表示ラベルが変更された。 現在は区別できるようになっている。

CR116209

シリアライズ可能な ServletContext 属性を追加し、それをシリアライズできない値で上書きした場合は、元の値によって新しい値がマスクされていた。 WebAppServletContext.transientAttributes の値は、元の値が WebAppServletContext.attributes から削除されないために表示されなかった。

シリアライズ可能な値をシリアライズできない値で置換する場合に、WebLogic Server が属性のハッシュテーブルから元の値を削除するようになった。

CR121343

複数のフレームが使用されている場合に、セカンダリ JVMID の算出時に競合状態が生じていた。 あるスレッドで、セカンダリ JVMID の算出によりメンバー変数値がリセットされ、それによって競合状態が生じていた。

コード変更の後、セカンダリ JVMID の算出で競合状態が生じなくなった。

CR120932

CertificateServlet で提供された HTML ページが、ラジオ ボタンに間違った値を表示していた。ラジオ ボタンで 2048 が表示されていたが、そのボタンを使用すると 1024 ビットの証明書になっていた。

このラジオ ボタンで正しい 2048 ビットの証明書が生成されるようになった。

CR091831

POST メソッドを使用したときにキープアライブ接続がサーバサイドでタイムアウトしたかどうかが、HttpURLConnection の WebLogic Server 実装でチェックされなかった。そのため、フラッシュ時に Connection aborted by peer: socket write error が発生した。

タイムスタンプを更新する前に HttpClient が null でないことを確認するためのチェックを追加した。

CR108034

接続を切断するユーザによって生成された不適切なエラー メッセージが抑制されていた。

JSP とサーブレット

変更要求番号

説明

CR099554

環境によっては、JMS メッセージが保留状態にあるサーバが停止されるか、クラッシュした場合に、保留中のメッセージがサーバの再起動時に回復されなかった。

保留中メッセージがサーバの再起動時に回復されるようになった。

JTA

変更要求番号

説明

CR132228

問題のない IOExceptions が日本語ロケールで抑制されていた。

現在、WebLogic Server はネイティブ IO を有効にする場合、デフォルトではロケールを C に設定する。 ロケールを C に設定しない場合は、以下のシステム プロパティを使用できる。

-Dweblogic.nativeIO.useDefaultLocale=true

英語以外のロケールでは、問題のない例外が抑制される。

JVM

変更要求番号

説明

CR113085

MBean を使用して、あるいは config.xml ファイルで手作業で SqlStmtProfilingEnabled の値を設定し、MBean を通じてその値を取得しようとした場合に、その値が表示されなかった。 代わりに、「It appears that no attributes have been specified for this MBean」というメッセージが返されていた。

JDBCConnectionPoolMBean の SqlStmtProfilingEnabled 属性を公開して、このエラーを解消した。

CR104435

KernelDebugMBean のオプションである DebugDGCEnrollment と ForceGCEachDGCPeriod を有効にできなかった。 weblogic.management.configuration.KernelDebugMBean には有効な属性を「set」する方法がなかった。

セッター シグネチャはこれらの属性に対する boolean を取らなかったため、これらのフラグの値をデフォルトから変更できなかった。

これらの属性のセッターで boolean を受け付けるようになった。

CR081349

ExecuteQueueRuntimeMBean を出力するときに、weblogic.Admin ツールで ExecuteThreads 属性が正しく表示されなかった。

ExecuteThreads 属性のエントリは読み取り可能な文字列値として表示されるようになった。

CR094219

ドメイン ログとサーバ ログのファイル名が日時に基づいている場合に (SimpleDateFormat)、以下の機能が完全に機能しなかった。

  1. これらのタイプのログがローテーションされなかった。

  2. FileCount が設定されている場合でも、ログ ファイルの合計数が制限されなかった。FileFilter はファイル名のパターンが原因でこれらのファイルをリストできなかったため、古いログ ファイルを削除するコードが適切な場所になかった。

これらのタイプのファイル名に対するファイルのローテーションが実装された。各ローテーション後に、ファイル数が制限されている場合は、その制限を超えているかどうかチェックされる。 その後で古いログ ファイルが削除される。

操作と管理

変更要求番号

説明

CR186148

Apache プラグインはページが見つからなかったときに、正しい 503 エラーではなく 500 エラーを返した。

プラグインは正しいエラーを返すようになった。

CR185668

Apache プラグインを使用し、MatchExpressions を使用して複数のクラスタにプロキシする場合、PathTrim 属性はリクエストの転送に使用される URL のセグメントを削除しなかった。

strtok API を使用しないで MatchExpressions 解析を実装しなおして、この問題を修正した。

CR185089

IIS プラグインは、クライアントにより接続が閉じられたことで WRITE_ERROR_TO_CLIENT 例外が発生すると、HTTP ステータス コード 500 (内部サーバ エラー) を送信していた。

IIS プラグインは WRITE_ERROR_TO_CLIENT 例外が発生しても HTTP ステータス コード 500 を送信しなくなった。

CR180417

Web ブラウザが「&」を含む POST データを何度か送信した。 クラスタ用にコンフィグレーションされている NSAPI プラグインでデータが処理されると、その POST データは破損した。 2 つ目の「&」が削除されたため、WebLogic Server のアプリケーションはクライアントから正しいデータを取得できなかった。

POST データの破損エラーを修正するコードを追加した。

CR136816

プライマリ サーバが見つからなかった場合、リクエストはリスト中の次の使用可能サーバによって処理された。 セカンダリ サーバは無視された。

プライマリ サーバが見つからないがセカンダリ サーバが存在する場合、リクエストはリスト中の別のサーバで処理されるのではなく、セカンダリ サーバに転送されるようになった。

CR183390

WebLogic Server は catch ブロックの中から例外を送出していた。そのために iPlanet が失敗することがあった。

WebLogic Server は catch ブロックから例外を送出しなくなった。

CR183311

シングルスレッド マルチプロセス モジュールを使用しているときに Apache が停止すると、Apache は最初にタイマー スレッドを停止しようとした。 このタイマー スレッドは存在していないため、コア ダンプが発生した。

Apache がシングルスレッド マルチプロセス モジュールで使用されている場合、WebLogic Server はタイマー スレッドを作成しなくなった。

CR183188

ISAPI プラグインは Transfer-Encoding ヘッダが chunked に設定されているリクエストを処理できなかった。

ISAPI がそのようなりクエストを処理できるように機能が追加された。

CR182434

rq->srvhdrs に渡されたヘッダは、大文字/小文字が混在せずに完全に小文字であるべきだったが、小文字になっていなかった。

Content-type、content-length および transfer-encoding ヘッダは完全に小文字で NSAPI に渡されるようになった。

CR175787

WebLogic Server は Iplanet プラグインで CONNECTION_REFUSED エラーを送出していた。

ソケットをポーリングして WRITE 操作があるかどうかを調べた後、ソケットのステートが以下のいずれかである場合、プラグインは CONNECTION_REFUSED 例外を送出しない。

有効なステートは以下のとおり。

POLLOUT

POLLWRBAND

POLLWRNORM

CR173985

(Apache) WebLogic Server の再起動後にプラグインがセッションを中断した。

これは Apache 1.3.x が、受信するリクエストを処理するために複数の子プロセスを作成するためである。 各プロセスは独自のサーバリストを保持しており、サーバリストでは各サーバ エントリが JVMID によってユニークに識別される。JVMID は WebLogic Server によって指定されるもので、リクエストが正常に処理されると更新される。 サーバ インスタンスは再起動されると、新しい JVMID を生成する。 そのため、プラグインで JVMID が更新されない場合、新しい JVMID を含むクッキーを備えたリクエストは、対応するプライマリ サーバのプラグインを見つけることができない。

コードの修正により、クッキーから抽出された JVMID がサーバリストに格納されている JVMID と一致しない場合は、WebLogic Server が JVMID を再度更新するようになった。

CR136968

WebLogic Server は、response.addHeader メソッドが使用される場合に複数のヘッダを受け付けなかった。

プラグインは WWW 認証に複数の値を許可するようになった。

CR135002

複数の仮想ホストを持つ Apache コンフィグレーションにおいて、仮想ホストの 1 つで WebLogic Server プラグインに対して SecureProxy=ON がコンフィグレーションされていて、他の仮想ホストでは SecureProxy または WLProxySSL を使用しない場合に、SSL がコンフィグレーションされていない仮想ホストで、プラグインがバックエンドの WebLogic Server との SSL 接続を試行した。 これによりパフォーマンスの問題が発生した。

SSL 接続を開始する必要があるかどうかを判断するために、内部メソッドに新しい引数が追加された。

CR134413

Apache プラグインは 302 応答に対する重複した HTTP ヘッダおよび本文を生成した。 プラグインとバックエンド サーバの間に問題はなかったが、Apache サーバが余分な 302 応答を追加していた。

request_handler メソッドの戻り値を OK に戻すコードを追加した。

CR132840

アプリケーション サーバがダウンしたときに、Apache アクセス ログで 500 エラーではなく 200 コードが不適切に記録されていた。 この問題は、コードを修正することで解決した。

CR132426

httpd.conf ファイルでプラグイン パラメータ「QueryFromRequest」が使用される場合、

Apache サーバの起動時に以下の構文エラーが発生した。

Syntax error on line 971 of C:/Program Files/Apache

Group/Apache2/conf/httpd.con f:Invalid command 'QueryFromRequest', perhaps misspelled or defined by a module not included in the server configuration.

Apache 2.0 プラグインは「QueryFromRequest」パラメータをサポートするようになった。

CR131640

WebLogic Server は Sun One 6.1 Web サーバ用プラグインの提供を要求された。

現在、SUN ONE 6.1 Web サーバは完全にサポートされている。

CR180236

リリース 8.1 SP02 のプラグインとクライアント証明書を一緒に使用した場合、以下のエラーが報告された。

Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException.

サーバ インスタンスに送信するときにプラグインが WL-Proxy-Client-Cert ヘッダを削除したためにエラーが発生した。

この問題は、コードを修正することで解決した。

CR179537

(ISAPI) Microsoft Windows プラットフォームで、IIS プロキシ プラグインによりヒープが破損した。

この問題は、内部コードを修正することで解決した。

CR177707

リリース 7.0 SP02 のプラグインとクライアント証明書を一緒に使用していたとき、WebLogic Server は正常に動作した。 ただし、リリース 8.1 SP02 にアップグレードした後、サーバ ログに以下のエラーが報告された。

Failed to parse the client certificate in header: WL-Proxy-Client-Cert. Ignoring this certificate. java.security.cert.CertificateException: Could not parse certificate: java.io.EOFException

8.1 SP02 プラグインが、サーバ インスタンスに送信するときに WL-Proxy-Client-Cert ヘッダを削除したためにエラーが発生した。

WebLogic Server に送信されるリクエストに WL-Proxy-Client-Cert がゆるやかに (lazily) 追加されるようにコードを変更した。

CR175989

(Apache) prefork オプション (マルチプロセスのみ) ではなく worker オプション (マルチスレッド) を使用している場合に、Apache サーバがコアダンプを生成した。

ロックおよびロック解除のロジックを修正してこの問題を解決した。

CR175672

(Apache) Debug が OFF に設定されている場合でも、WebLogic プラグインが wlproxy ログ ファイルを開こうとすると Apache サーバがハングした。

デバッグが無効になっている場合はログ ファイルが設定されないようにコードを修正した。

CR174777

[iPlanet] パイプに障害が発生したために、iPlanet ログ ファイルで POST_TIMEOUT エラーが発生した。

POST データを WebLogic Server に送信しているときに EPIPE エラーが発生した場合は HALF_OPEN_SOCKET_RETRY 例外を送出するように、コードを追加した。

CR174431

(NSAPI) Iplanet プラグインは EINTR OS エラーを正常に処理するようになった。

CR173653

WLExcludePathOrMimeType プロパティは、Location タグ内で定義される場合は、グローバル スコープを持つべきではなかった (ただし、Location タグの外で定義される場合は、グローバル スコープを持つべだった)。

定義された適切な Location パスに一致するリクエストにのみ WLExcludePathOrMimeType プロパティが適用されるようにコードを変更することで、この問題を解決した。

CR173581

CR173878

(Apache) プラグインは、クライアントが接続を閉じている場合でも、「error page is unavailable」という紛らわしいログ メッセージを apache error.log に記録していた。

この問題は、誤ったログ メッセージをコメント アウトするようにコードを変更することで解決した。

CR172497

(NSAPI) 拡張子によるプロキシを行うときに「pluginparams.ErrorPageTest」が失敗した。

MIME タイプによるプロキシの場合、ErrorPage がローカルにロードされるのを回避するには、WLExcludePathOrMimeType プロパティを使用する。

SUN One Web Server バージョン 6.1 の場合は、追加のコンフィグレーション手順が必要になる。

  1. obj.conf ファイル内のデフォルト オブジェクトから NameTrans fn="ntrans-j2ee" name="j2ee" を削除する。

  2. magnus.conf ファイルから Init fn="load-modules" shlib="C:/Sun/WebServer6.1/bin/https/bin/j2eeplugin.dll" shlib_flags="(global|now)" を削除する。

詳細については、Sun のドキュメント (http://docs.sun.com/source/817-1831-10/agjava.html#wp1084 323) を参照。

CR172072

WLExcludePathOrMimeType パラメータの機能を拡張して、Location タグ レベルで使用できるようにした。

WLExcludePathOrMimeType パラメータは、グローバルに定義するだけでなく、Location タグ レベルでローカルに定義できるようになった。 このプロパティをローカルに定義する場合、グローバル プロパティがオーバーライドされることはないが、2 つのパラメータの結合が定義される。

CR171978

iisforward.ini ファイルで FilterPriorityLevel が設定されている場合に、転送パスが途切れた。

コード修正の実装により、iisforward.ini ファイルで仮想ホストが定義されていない場合は、iisforward.dll ファイルのロード元と同じ場所にある iisforward.ini ファイルが使用されるようになった。

CR133641

iPlanet を使用している場合に、ホスト名検証で問題が発生して以下のメッセージを受け取った。

INFO: Host () doesn't match (), validation failed

ERROR: SSLWrite failed

コードを修正してこの問題を解決した。

CR130060

IIS プラグインのパフォーマンス上の問題は、サービス パック 5 で、指定されたコンテンツ長と等しいデータが既に読み込まれているかどうかが確認されるようにするコード変更によって解決されている。

CR129471

以前のサービス パックでは、Apache プラグインは WLTempDir パラメータを認識しなかった。 この問題は修正された。

CR129342

ISAPI プラグインは、WL-PATH-TRIM 値ではなく WL-PATH-TRIM HTTP ヘッダ値を WebLogic Server に送信した。

WebLogic Server は正しい値を受信するようになった。

CR129138

NSAPI プラグインがバックエンドの WebLogic Server インスタンスで名前解決を実行する場合、名前解決では sysGetHostByName を使用していた。そこで getHostByName が呼び出され、さらにそのメソッドでは、開いているファイル記述子に最大数の制限がある内部メソッドを呼び出した。その結果、名前解決が失敗することがあった。

プライマリ サーバとセカンダリ サーバを検索するためのクッキー解析と JVMID の置換を修正して、この問題を解決した。

CR129026, CR129323

ISAPI プラグインにおけるメモリ リークはコードの変更により修正された。

CR127973

サーブレット セッションに永続的なクッキーが追加された後に、ISAPI プラグインでエラーが発生することがあった。

クッキー解析コードを修正することで問題を解決した。

CR127658

[ISAPI] プールから接続を取得しても、WebLogic Server が既にその接続を閉じている場合は、HALF_OPEN_SOCKET_RETRY 例外が送出された。

HALF_OPEN_SOCKET_RETRY 例外を受け取った後に、要求が再試行されるようになった。

CR084303

WebLogic Server プロキシ プラグインでは、クライアントからサーバに送信される可能性のある HTTP コマンドを制限している。 現在、プラグイン コードの検証ルールでは、WebDAV 実装に必要な以下の HTTP コマンドが許可されている。

DELETE

GET

HEAD

OPTIONS

POST

PUT

*COPY

LOCK

MKCOL

MOVE

PROPFIND

PROPPATCH

SEARCH

UNLOCK

CR127231

503 HTTP ステータスを受け取った後で、リクエストがクラスタ内の使用可能な次のサーバにフェイル オーバしなかった。 READ_ERROR_FROM_SERVER または CONNECTION_REFUSED 例外が発生するまで、同じサーバが繰り返し試行されていた。

現在のコードでは、503 HTTP ステータス エラーを受け取ったら、サーバを障害が発生したものとしてマークし、使用可能なサーバを取得してリクエストを再送信する。 すべてのリクエストが使用可能な次のサーバにフェイル オーバするようになった。

プラグイン

変更要求番号

説明

CR175112

IIOP メッセージの送信に使用されるメソッドが同期化されていなかったため、複数のスレッドが同時にデータの送受信を行うと、基底のデータの破損につながった。

メソッドは同期化されたので、現在はマルチスレッド環境で正しく動作するようになった。

RMI-IIOP

変更要求番号

説明

CR177353

クライアントがリモート (スタブ) を受け取り、クラスタにデプロイされているステートレス セッション Bean のリモート メソッドを呼び出す場合、呼び出しのたびにレプリカ リストが更新されて、クラスタ全体の再起動時にフェイルオーバが動作しなかった。 該当する再試行ロジックが正しくなかった。

WebLogic Server は n 個のノードを持つクラスタで n-1 の再試行回数を許可していた。 クラスタ全体を再起動したとき、スタブは古いレプリカを持っていたため、すべての再試行が行われた。 最後の試行でレプリカ リストを更新していた。 WebLogic Server にレプリカ リストの新しいコピーがあっても、フェイルオーバは試行されなかった。

WebLogic Server は、リストが空の場合、またはリストのレプリカが正常に呼び出されない場合にのみ、レプリカ リストを更新するようになった。 レプリカ リストが処理中に更新されると、サーバはフェイルオーバの機会をもう一度与える。 この最後の機会が成功しなかった場合、WebLogic Server はアプリケーションに例外を送出する。

RMI

変更要求番号

説明

CR132509

MedRec アプリケーションに含まれている .NET C# サンプル (%WEBLOGIC_HOME%¥samples¥server¥medrec¥src¥clients¥CSharpClient¥bin¥ReleaseCSharpClient.exe) を使用した場合、クライアントは患者のレコードを正常に取得したが、クライアント アプリケーションから「Save Changes」を行おうとすると、日付フィールド エラーが示された。

コードの変更により日付の検証が修正された。

サンプル

変更要求番号

説明

CR179663

WebLogic Server Administration Console を使用して LDAP ユーザを表示するときに NullPointer 例外が発生した。

コードを追加して NullPointer 例外を解消した。

CR174299

WebLogic Server Administration Console の [SSL] タブの [Java を使用] 属性が適切に機能しなかった。

この属性の動作を修正した。

CR172567

管理サーバとリモートの管理対象サーバの両方で証明書の名前が同じ場合、WebLogic Server はリモートの管理対象サーバで、管理サーバの証明書を使用した。

ローカルの証明書のみをロードするように、SSL リスン スレッドを更新した。

CR161836

WebLogic Server はセッションで AuthenticatedUserName ではなく AuthenticatedUser を設定していた。

AuthenticatedUsername を設定するようにサーブレット認証を変更し、ClassCast 例外を解決した。

CR127722

ホスト名検証が失敗したものの setExpectedName() メソッドが定義されている場合、WebLogic Server はメソッドで定義されたホスト名を無視して接続を中断していた。

WebLogic Server はホスト名検証チェックを最初に実行するようになった。 チェックが失敗すると、WebLogic Server は ExpectedName() メソッドを使用してホスト名を検証する。 その検証にも失敗した場合、接続は拒否される。

CR112619

アプレットが t3s プロトコルを使用して初期コンテキストを取得しようとすると、NullPointerException が送出されていた。

アプレットに対する基本的な制約チェックを更新した結果、NullPointerException が解消された。

CR124746, CR175051, CR175045

コードの変更により、WebLogic Server はデフォルトでは HTTP TRACE リクエストをサポートしていない。 WebLogic Server 6.1 以降で HTTP TRACE のサポートを有効にする場合は、クラスタまたはサーブレットで HttpTraceSupportEnabled="true" を設定する。 5.1 では、weblogic.httpd.httpTraceSupport.enabled=true を設定する。

セキュリティ勧告 BEA04-48.01 を参照。

CR112220

WebLogic Server は管理サーバのホスト名を、ノード マネージャの管理証明書に対して検証していたため、エラーが発生した。

ノードマネージャのホスト名検証は、ノードマネージャのホスト ファイルに対してのみ行われるようになった。

セキュリティ

変更要求番号

説明

CR113122

WebLogic Server SNMP エージェントが sysUpTime に対して返した値は、SNMP エージェントが初期化されてからの期間を正確に報告していなかった。

初期化されてからの期間が正確に報告されるようになった。

CR103678,

CR109869

サードパーティのコレクタ タスクを使用して SNMP 情報を収集した場合、以下のメッセージがログに記録さた。

<Error> <SNMP Agent> <000000> < Unable to set Entry Field Value ...>

この問題を解決するコード修正が実装された。

SNMP

変更要求番号

説明

CR121105

WLEC クライアントでは、WLEC 接続プールに関する以下の問題が発生した。

Administration Console で ConnectionPool が適切に表示されない。

登録解除されたエンドポイントが引き起こす COMM_FAILURES。

これらの問題を解決するコード修正が実装され、WLEC 接続プールの全体的なパフォーマンスが向上した。

WLEC

 


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

この節では、WebLogic Server 6.1 SP06 で解決された問題を示します。

クラスローダ

変更要求番号

説明

CR101547

静的データの含まれるシングルトン クラスが格納されたエンタープライズ アプリケーションをデプロイするときにメモリ リークが発生していた。 この問題は、シングルトン クラスを Web アプリケーションとしてデプロイしたときには発生しなかった。

この問題は、アプリケーション クラスローダの修正で解決した。

CR104513

WebLogic Server 6.1 サービス パック 2 で行われた CR069506 の修正により、1 つのマニフェスト ファインダが他のマニフェスト エントリを再帰的に参照する場合にクラスローダがファイルを検索できなかった。 この問題は、このケースに対処するように Classloader.getResources() を修正することで解決した。

CR111924

リモート サーバの EJB からローカル サーバの EJB に送出されたユーザ定義例外を処理するときに、WebLogic Server から ClassNotFoundException が送出されていた。 この問題は、ユーザ定義例外がローカル EJB のクラスローダに含まれている場合でも起こっていた。 この問題は、例外を処理するソケット リーダーがアプリケーション クラスローダではなくシステム クラスローダを使用していたことが原因。

この問題は、コードを修正して解決された。

CR124348

プロキシ クラスがシステムのクラスパスに追加されていない限り、クライアント プログラムで java.lang.reflect.Proxy を使用して、WebLogic Server にデプロイされたプロキシ オブジェクトにアクセスすることができなかった。 オブジェクトがシステムのクラスパスにない場合、クライアントは ClassNotFoundException を受け取っていた。

resolveProxyClass() メソッドが実装され、システム クラスローダだけでなくアプリケーション固有のクラスローダからもインタフェースがロードされるようになった。

クラスタ

変更要求番号

説明

CR103807

WebLogic Server 6.1 SP04 では、weblogic.rmi.cluster.BasicReplicaList.add(BasicReplicaList.java:61) で null ポインタ例外が送出されていた。 この問題は、管理対象サーバが障害後に再起動されたときに発生していた。 再起動時に、NPE が発生し、クラスタ内のすべてのサーバ インスタンスを再起動しなければならなかった。 このエラーはタイミングに関連しており、コードの修正で解決した。

CR104430

クライアントがクラスタ内の 1 番目と 2 番目のサーバ (クライアントのプライマリ サーバとセカンダリ サーバ) から 3 番目のサーバに切り替えるときに、クラスタ化されたサーバでセッションが失なわれる可能性があった。 プロセスは最初の 2 つのサーバからセッションを削除する。クライアントがプライマリ サーバに戻ると、プライマリ サーバは 3 番目のサーバ上ではなく、セカンダリ サーバ上でセッションを探した。

3 番目のサーバ上でセッション情報からセッションを再作成し、プライマリおよびセカンダリ サーバからセッションを完全に削除するようにコードを修正して、問題を解決した。

CR107471

WebLogic Server 6.1 SP02 では、クラスタで 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 クッキーを設定し、それをプラグインに送り返すことで状態がクライアントで管理されるようにコードを修正して解決された。

CR108127

WebLogic Server 6.1 SP04 では、セカンダリ セッションを更新しようとしたときにエラーが発生していた。 サーバ A、サーバ B、およびサーバ C という 3 つのクラスタ化されたサーバ インスタンスがあるとする。

1) サーバ A でセッションを開始する (プライマリ A、セカンダリ C)。

2) ロード バランシング ハードウェアがサーバ C にセッションを移行する (プライマリ C、セカンダリ B)。

3) ロード バランシング ハードウェアがセッションをサーバ A に再び移行する。

次のエラーがサーバ A で発生していた。

<Jun 4, 2003 4:24:56 PM PDT> <Debug> <Cluster> <Error updating secondary for 3535724191309537720 on 7312270160516507840S:<IPaddressdeleted>: [7005,7005,7002,7002,7005,7002,-1]:<IPaddressdeleted>:7005, <IPaddressdeleted>:7005,<IPaddressdeleted>:7005:mydomain:myserver3. Re-creating secondary.>

次のエラーがサーバ C で発生していた。

<Jun 4, 2003 4:24:56 PM PDT> <Info> <Cluster> <Lost 0 replication updates of object 3535724191309537720. Re-fetching secondary.>

この問題は、コードを変更して解決された。

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 の最大の重みが適切にリセットされていなかったことが判明した。

レプリカ リストのサイズが変わったときに必ず max weight が再計算されるようにコード修正して、この問題は解決した。

CR116954

HTTPClusterServlet からの InitJVMID リクエストで web アプリケーション コンテナが 404 メッセージを返し、その結果としてログ ファイルがメッセージで一杯になっていた。

####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <petunia> <ms1petunia> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1petunia) found no context for "/WLDummyInitJVMIDs".

この問題は、WebLogic Server に常にデプロイされている内部 Web アプリケーションに InitJVMID リクエストを送信することで解決した。

コネクタ

変更要求番号

説明

CR109463

トランザクションが 2 つのリソース アダプタへの接続を取得し、それらのアダプタが両方とも同じリソース マネージャを使用していた場合に、WebLogic Server が片方の接続だけクリーン アップしていた。 接続は、トランザクションのコミット前に閉じられていた。 この問題は、javax.resource.spi.ResourceAllocationException として表面化した。

この問題は、同じリソース マネージャを使用した 2 つめの接続をトランザクション マネージャが無視したことが原因だった。 この問題は、コードを修正して解決された。

CR121418

新しい接続を割り当てるときに、コネクタ コンテナが記述子 MBean を使用してコンフィグレーション情報を取得していた。 記述子 MBean は管理サーバ上にあるので、管理対象サーバは管理サーバにアクセスできないと新しい接続を割り当てることができない。 管理サーバがダウンしている場合は、新しい接続を割り当てるプロセスから次の例外が送出されていた。

weblogic.rmi.extensions.RemoteRuntimeException

コンテナは、アダプタのデプロイ後にコンフィグレーション情報をローカルに格納するように修正された。 管理対象サーバは、新しい接続の割り当てで記述子 MBean ではなくこのローカルのコンフィグレーション情報を使用するようになった。

CR125555

リソース アダプタから MetaData 情報を取得するときに、WebLogic Server サービス パック 5 ではオブジェクトの使用前に戻り値で null がチェックされていなかった。 これが原因で、NullPointerException と接続障害が発生する可能性があった。

getMetaData() の呼び出し後に戻り値で null がチェックされるようにコードが修正された。 ManagedConnection.getMetaData() のアダプタ実装が null 値を返しても、WebLogic Server は NullPointerException を送出しなくなり、MetaData はログに記録されない。

コンソール

変更要求番号

説明

CR100006

ドメインの中に 2 つの管理サーバがあり、Administration Console を通じてそれらのサーバにアクセスしようとしたときに、WebLogic Server は次の NullPointerException を表示することがあった。

java.lang.NullPointerException
at
weblogic.management.console.helpers.UrlHelper.buildIconList(UrlHelper.java:149)
at weblogic.management.console.helpers.UrlHelper.getIcon(UrlHelper.java:174)
at
weblogic.management.console.tags.SmartNavNodeTag.getIcon(SmartNavNodeTag.jacva:111)
at
weblogic.management.console.tags.SmartNavNodeTag.inferStuffFromContext(SmartNavNodeTag.java:96)
at
weblogic.management.console.tags.SmartNavNodeTag.doStartTag(SmartNavNodeTag.java:44)
at
weblogic.management.console.webapp._domain.__nav._jspService(__nav.java:301)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:27)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
at
weblogic.servlet.internal.RequestDispatcherImpl.forward(RequestDispatcherImpl.java:250)

[...]

この問題は、コードを修正して解決された。

CR102824

Solaris 8 で WebLogic Server SP02 から SP04 にアップグレードした後、顧客がコンソールにログインしたときに、ログ ファイルに次の例外が記録される。 それでも、コンソールは機能を続ける。

java.lang.NullPointerException at weblogic.management.console.utils.ConsoleComparator.compare(ConsoleComparator.java:81) at java.util.Arrays.mergeSort(Arrays.java:1176) at java.util.Arrays.sort(Arrays.java:1123) at java.util.Collections.sort(Collections.java:116) at weblogic.management.console.utils.MBeans.sort(MBeans.java:1103) at weblogic.management.console.tags.DeclareBeanSetTag.doStartTag(DeclareBeanSetTag.java:99) at weblogic.management.console.webapp._domain.__nav_services._jspService(__nav_services.java:982) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262) at weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:490) at weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:316) at weblogic.servlet.jsp.PageContextImpl.include(PageContextImpl.java:116) at ...

分析の結果、MBean が null の displayName を返していたことが判明した。 この問題は、コードを修正して解決された。

CR105598

Active Directory LDAP を使用した新しいテストで、メンバー名にカンマ (,) が含まれている場合に group.isMember() の呼び出しが失敗する問題が発見された。 この問題は、コードを修正して解決された。

コア

変更要求番号

説明

CR071415

WebLogic Server 6.1 SP02 では、WebLogic Server のセキュリティ マネージャが起動して、ポリシー ファイルを設定する場合に、JSP のコンパイル時にパス /usr/lib が javac の先頭に付加され、java.security.AccessControlException が生じていた。

この問題は、コードを修正して解決された。

CR094410

DebugHttpServerDebugMBean でアクティブ化された場合に、WebLogic Server は SocketResetException を単純なデバッグ メッセージではなくエラーとして報告していた。 この問題に対処するために、このデバッグ メッセージを報告するための logMuxableSocketResetException() がメッセージ カタログに追加された。

CR096091

WebLogic Server 6.1 SP04 と SP05 では、ファイルからクラスパスを使用して WebLogic Server を Windows サービスとして起動する場合にクラスパス ファイルの長さが約 2K を超えていると、

“Thread created successfully! Exception in thread “main” java.lang.NoClassDefFoundError: weblogic/Server”

というエラーが送出される。

この問題は、ファイルからのクラスパスの読み出しに関連するエラーを修正して解決した。

CR102058

クライアントで URLClassLoader を使用する場合に、リモート メソッド呼び出しで NoClassDefFoundError が生じていた。

c:¥java¥java131_07¥bin¥java -classpath ".;client.jar;C:¥home¥ravia¥weblogic¥dev¥src700¥3rdparty¥weblogicaux.jar" URLTest qa146 9901 ejb20-statefulSession- TraderHome installadministrator installadministrator java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:106) at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:401) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:162) at java.lang.ClassLoader.loadClass(ClassLoader.java:294) at java.lang.ClassLoader.loadClass(ClassLoader.java:250) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:190) at weblogic.utils.classfile.utils.CodeGenerator.generateClass(CodeGenerator.java:71) at ...

この問題は、ThreadContextClassLoaderAugmentableSystemClassLoader の親として設定することで解決した。

CR103525

WebLogic Server 6.1 SP04 では、次のエラーが発生していた。

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Old socket closed and released FD before FDRecord still exists,...

この問題は、マルチプレクサの外側でのソケットのクローズが適切に処理されるようにコードを修正することで解決した。

CR103774

Solaris および Windows 2000 バージョンの WebLogic Server は、次のようなソケット例外をログに記録していた。

<Apr 3, 2003 11:40:07 AM EST> <Error> <socket> <000424> <IOException on socket: weblogic.servlet.internal.MuxableSocketHTTP@1eca988 - idle timeout: '30000' ms, socket timeout: '0' ms, fd: 53 java.net.SocketException: Connection reset java.net.SocketException: Connection reset
at
java.net.SocketInputStream.read(SocketInputStream.java:168) at
weblogic.socket.PosixSocketMuxer.readBytesProblem(PosixSocketMuxer.java:876)
at
weblogic.socket.PosixSocketMuxer.deliverGoodNews(PosixSocketMuxer.java:767)
at
weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:694)
at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:213)
ad.run(ExecuteThread.java:189)
>

ただし、これらのメッセージはサーバまたはアプリケーションの欠陥を示していない。 サーバがデバッグ モードの場合のみ上記の例外が表示されるようにコードが修正された。

CR103967

WebLogic Server 6.1 SP04 では、WebLogic Server 実行スレッドの子スレッドが適切なコンテキスト クラスローダを継承していなかった。 この問題は、サーブレットまたは EJB がタイマー (java.util.Timer) を作成するときに共通に発生していた。

分析の結果、java.lang.Thread が独自のメンバー変数を子スレッドに直接割り当てるために、WebLogic Server 実行スレッドは独自のコンテキスト クラスローダを保持し、それらの実行スレッドの子スレッドはコンテキストを継承しないことが判明した。

この問題は、コードを修正して解決された。

CR104218

WebLogic Server 6.1 SP04 では、CR100665_61sp4.jar のパッチを当てた Solaris 8 サーバで次の例外が発生していた。

<Apr 23, 2003 3:36:27 PM CDT> <Error> <Posix Performance Pack> <Uncaught Throwable in processSockets java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:750) at java.util.HashMap$EntryIterator.next(HashMap.java:792) at java.util.HashMap.putAllForCreate(HashMap.java:408) at java.util.HashMap.clone(HashMap.java:624) at java.util.HashSet.clone(HashSet.java:217) at weblogic.socket.PosixSocketMuxer.closeSockets(PosixSocketMuxer.java:486) at weblogic.socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:589) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

この問題は、コードを修正して解決された。

CR105426

WebLogic Server には、wlntio_g.dll という名前のファイルが付属する。このファイルは、wlntio.dll のデバッグ バージョン (デバッグ目的にのみ必要)。 WebLogic Server 6.0 サービス パック 2 には、wlntio_g.dll の間違ったバージョンが含まれていた。このファイルは、デバッグでの使用時に次のようなスタック トレースを生じさせる恐れがあった。

<NT Performance Pack> NATIVE.malloc(): allocated at 0x08DAD008 numAllocs 1
numFrees 0
NATIVE: start io on 1972 with addr 0x08dad008
NATIVE: GetQueuedCompletionStatus on 1972 with addr 0x08dad008
<May 6, 2003 11:17:19 AM EDT> <Error> <NT Performance Pack> <failure in
processSockets() - GetData: 'weblogic.socket.NTSocketMuxer$GetData - native
pointer: '0', numBytes: '0''
java.lang.NoSuchFieldError: fd
at weblogic.socket.NTSocketMuxer.getNextSocket(Native Method)
at
weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:589)
at
weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:24)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)>

サービス パック 6 には、適切なバージョンの wlntio_g.dll が含まれている。

CR105516

WebLogic Server 6.1 SP04 では、複数のフェイルオーバが必要なときにステートフル セッション EJB のフェイルオーバが機能していなかった。

3 ノードのクラスタでは、JSP がレプリカ対応ステートフル セッション EJB の作成または呼び出しを行う。 リモートの EJB スタブは、http セッションに格納される。 ステートフル セッション EJB の各呼び出しの後に、更新された EJB スタブが EJB レプリカ リスト (プライマリ/セカンダリ) の変更を反映して http セッションでも更新される。

同じブラウザ ウィンドウで次のように呼び出しを行うと、クラスタの 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)

この問題は、コードを修正して解決された。

CR105814

WebLogic Server 6.1 SP04 では、AIX 上で close_waits が動作しているのが確認された。

分析の結果、WebLogic Serve 6.0 のクライアントが WebLogic Server 6.1 インスタンスに接続したときに、WebLogic Server がソケットをリークしていたことが判明した。 この問題は、ソケットをマルチプレクサに登録することなくマルチプレクサを通じて WebLogic Server が MuxableSocket を閉じようとしたときに発生していた (ソケットは t3 によって要求された後、マルチプレクサに登録できる前に拒絶された)。 この問題は、コードを修正して解決された。

CR106957

WebLogic Server 6.1 SP04 では、AIX 5.2 上で IBM の MQWorkflow と一緒に動作している場合に、WebLogic Server でサーブレットが MQWorkflow Java API を呼び出したときに、MQWorkflow でエラーが生じていた。 この問題は、ネイティブ IO (パフォーマンス パック) が無効になっている場合、または libmuxer.so ライブラリがクラスパスから削除されている場合は Windows では起こらなかった。

分析の結果、WebLogic Server が「language code」(エンコーディング パラメータ) を当然そうであるべき「en-us」に設定せず、「c」に設定していたことが判明した。 この問題は、コードを修正して解決された。

CR107598

WebLogic Server 6.1 SP03 と SP04 では、管理サーバの再起動で次のエラーが生じていた。

java.rmi.ConnectException: This RJVM has already been shutdown

この問題は、次の手順を行うと必ず発生していた。

  1. サーバ インスタンスが少なくとも 2 つのマシン上にあるクラスタをコンフィグレーションする。

  2. サンプル EJB をクラスタにデプロイする。

  3. 管理サーバを再起動する。

  4. EJB の対象からクラスタを外す。

  5. クラスタを再び EJB の対象とする。

次のエラーが生じていた。

<Feb 5, 2003 7:03:27 PM PST> <Info> <J2EE> <Undeployed: ejb_basic_statelessSession> java.rmi.ConnectException: This RJVM has already been shutdown -7152222714009328 37S:172.17.25.250:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver
at
weblogic.rjvm.RJVMImpl.getOutputStream(RJVMImpl.java:280)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:408)
at
weblogic.rmi.internal.BasicRemoteRef.getOutboundRequest(BasicRemoteRef.java:97)
at
weblogic.rmi.internal.BasicRemoteRef.invoke(BasicRemoteRef.java:125)
at
weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy7.getMBeanServer(Unknown Source)
at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java:253)
この問題は、古くなった MBean の参照を削除するようにコードを修正して解決した。

CR109339

WebLogic Server 6.1 SP05 では、アプレットでカーネルを初期化するときにセキュリティ例外が発生していた。 この問題は、コードの修正で解決された。

CR109590

WebLogic Server 6.1 SP04 では、AIX と一緒に動作している場合に、IIOP 経由でリモート オブジェクトに対して行われるメソッド呼び出しがハングしていた。

このケースでは、非 WebLogic Server のサーバがリモート オブジェクトをホストしている。 WebLogic Server 上で動作する EJB が、IIOP 経由で WebLogic Server ではないサーバ上のリモート オブジェクトを呼び出す。 このメソッド呼び出しは、無限にハング状態を続ける。 メソッド呼び出しは単純なものだった (ブール値を返すだけ)。 スレッド ダンプは次のような内容だった。

“ExecuteThread: '11' for queue: 'default'" (TID:0x300C12A8, sys_thread_t:0x35649A58, state:CW, native ID:0x1011) prio=5 at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:429) at weblogic.iiop.SequencedRequestMessage.waitForData(SequencedRequestMessage.java:24) at weblogic.iiop.EndPointImpl.sendReceive(EndPointImpl.java:641) at weblogic.iiop.OutboundRequestImpl.sendReceive(OutboundRequestImpl.java:43) at weblogic.iiop.IIOPRemoteRef.invokeInternal(IIOPRemoteRef.java:128) at weblogic.iiop.IIOPRemoteRef.invoke(IIOPRemoteRef.java:90) at weblogic.rmi.internal.ProxyStub.invoke(ProxyStub.java:35) at $Proxy70.isRunning(Unknown Source) at java.lang.reflect.Method.invoke(Native Method) at weblogic.iiop.IIOPInvocationHandlerImpl.invoke(IIOPInvocationHandlerImpl.java:285) at $Proxy71.isRunning(Unknown Source) at...

分析の結果、クラスローダに問題があることが判明した。 コードの修正で、この問題は解決された。

CR110347

WebLogic Server 6.1 SP05 では、EJB スタブがクラスパスにない場合に、コンテキストのルックアップ (およびオブジェクトへの割り当て) で IllegalArgumentException が送出される。

この問題は、ステートフル セッション EJB (WebLogic Server に付属する examples.ejb20.basic.statefulSession) が 1 つの WebLogic Server サーバにデプロイされている場合に発生していた。 EJB ホーム オブジェクトで JDNI ルックアップが実行され、戻り値がクラス オブジェクトに割り当てられていた。 クライアントのクラスパスには weblogic.jar は含まれていたが、クライアントのクラスは含まれていなかった。

コンテキストのルックアップは、次のコードで実行されていた。

Context ctx = new InitialContext(ht); Object objref = ctx.lookup("ejb20-statefulSession-TraderHome");

ルックアップは WebLogic Server 6.1 SP03 では成功したが、WebLogic Server 6.1 SP05 では失敗していた。 次のような例外が送出された。

java.lang.IllegalArgumentException: java.lang.IllegalArgumentException: interface examples.ejb20.basic.statefulSession.

TraderHome は、クラスローダから見えていなかった。JVM で verbose のクラスローディングが設定されている状況で、examples.ejb20.basic.statefulSession.TraderHome クラスが (クラスパスにはないが) WebLogic Server 6.1 SP03 では正常にロードされていることが判明した。 WebLogic Server 6.1 SP05 では、そのクラスをロードしようとしたときに障害が発生していた。

この問題は、ClientRuntimeDescriptor が現行のクラスローダを使用するようにコードを修正することで解決した (それが GenericClassLoader である場合)。

CR110892

異なる資格を使用して localhost で InitialContext() を呼び出すと、現在のユーザが変更されていた。

この問題は、WebLogic Integration のビジネス オペレーションが WebLogic Portal アプリケーションにデプロイされた EJB に JMS メッセージを送信するときに見受けられた。 そのビジネス オペレーションは、ステートレス セッション Bean を使用して実装されていた。 EJB を見つけるために、ビジネス オペレーションは定義済みのユーザ資格を使用して WebLogic Portal ホストとポートの InitialContext を取得していた。 WebLogic Portal と WebLogic Integration が同じサーバ インスタンスにデプロイされている場合は、InitialContext() を呼び出すことによって、WebLogic Integration がワークフローを閉じるのを防止する WLI 環境に変化が生じる。 WebLogic Integration の「完了した」タスクは、次の例外を送出していた。

####<Jun 30, 2003 6:51:10 PM EDT> <Info> <B2B> <deletedstring> <deletedstring> <ExecuteThread: '14' for queue: 'default'> <kernel identity> <38:d06db1d7b915f0cd> <000000> <<B2B-BPM-Plugin> INFO: Log from Workflow: :::: Usecases BPM_AI_asyncWLP [12001] async ::: Done> ####<Jun 30, 2003 6:51:11 PM EDT> <Info> <EJB> <deletedstring> <deletedstring> <ExecuteThread: '14' for queue: 'default'> <kernel identity> <> <010099> <Message-Driven EJB: EventListener's transaction was rolledback. The transaction details are: Xid=38:d06db1d7b915f0cd(4745279),Status=Rolled back. [Reason=weblogic.transaction.internal.AppSetRollbackOnlyException],numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=60,ServerResourceInfo[JMS_JMSWLIStore]=(state=rolledback,assigned=si_server,xar=JMS_JMSWLIStore),ServerResourceInfo[weblogic.jdbc.jts.Connection]=(state=rolledback,assigned=si_server,xar=weblogic.jdbc.jts.Connection@3431bd),SCInfo[si_domain+si_server]=(state=rolledback),properties=({weblogic.jdbc=t3://10.61.7.124:8501}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=si_server+10.61.7.124:8501+si_domain+t3+, Resources={WebLogic DBMS Adapter...

分析の結果、現在のサーバの URL を使用して「new InitialContext(p)」を呼び出すと、呼び出しで使用されたユーザと現在のスレッドが関連付けられることが判明した。 この問題は、コンテキスト オブジェクトを閉じるロジックをコード変更することで解決した。 詳細については、http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-35 を参照。

CR116712

WebLogic Server 6.1 SP04 では、INVOKE が管理ツールを使用して WLECConnectionPoolRuntime で発行された場合に WLECConnectionRuntime MBeans が更新されていなかった。

分析の結果、resetConnectionPool()WLECConnectionPoolRuntime MBean で呼び出されたときに、プールがリセットされていないことが判明した。 古い接続が削除されていなかった。

この問題は、コードを修正して解決された。 現在、古い接続に対応する MBean は resetConnectionPool() の呼び出しの前に登録が解除されるようになっている。

CR117200

WebLogic Server 6.1 SP05 では、管理対象サーバが管理サーバに接続できないときに weblogic.socket.PosixSocketMuxer のデッドロックが検出されていた。 次に示すのは、スレッド ダンプからの抜粋。

1wasLKDEADLOCK Deadlock detected!!!
NULL
NULL
2LKDEADLOCKTHR Thread “ExecuteThread: '0' for queue:
'__weblogic_admin_rmi_queue'” (0x8461B8A0) 3LKDEADLOCKWTR is waiting for:
4LKDEADLOCKMON sys_mon_t:0x84D183A8 inflaming: 0x00000000: 4LKDEADLOCKOBJ weblogic.socket.PosixSocketMuxer$FDRecord@31FD4B10/31FD4B18:
3LKDEADLOCKOWN which is owned by: 2LKDEADLOCKTHR Thread “ExecuteThread: '98' for queue: 'default'” (0x767D26E0)
3LKDEADLOCKWTR which is waiting for:
4LKDEADLOCKMON sys_mon_t:0x83AD8C18 inflaming: 0x00000000:
4LKDEADLOCKOBJ weblogic.rjvm.ConnectionManagerServer@31FA3430/31FA3438:
3LKDEADLOCKOWN which is owned by:
2LKDEADLOCKTHR Thread “ExecuteThread: '0' for queue: '__weblogic_admin_rmi_queue'” (0x8461B8A0)

次の例外も送出される。

java.rmi.ConnectException: The connection manager to ConnectionManager for: 'weblogic.rjvm.RJVMImpl@2a7512ad - id: '8419466038107054512S:10.32.197.52:[7001,7001,-1,-1,7001,-1,-1]:bossapp:AdminServer' connect time: 'Fri. Aug 01 09:43:07 CST 2003'' has already been shut down at weblogic.rjvm.ConnectionManager.getOutputStream(ConnectionManager.java(Compiled Code)) at...

分析の結果、PosixSocketMuxer のデッドロックの原因は FDRecord ロックと ConnectionManager ロックの競合であることが判明した。 1 つのスレッドが FDRecord ロックを保持しつつ、FDRecord がクリーンアップを実行するのを待っている別のスレッドに保持された ConnectionManager ロックを待っているのである。

コードの修正でこの競合は解消された。 現在、FDRecord ロックはディスパッチの間は保持されなくなっている。

CR122280

コンテキストワイドなセッションで、WebLogic Server はオブジェクトがシリアライズ可能かどうかセッションに追加する前にチェックしていなかった。 この問題で、次のエラーが引き起こされる恐れがあった。

Could not deserialize context attribute
java.io.NotSerializableException:
com.app.name
at
java.io.ObjectOutputStream.outputObject(ObjectOutputStream.java(Compiled Code))
at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled Code))
at
weblogic.servlet.internal.AttributeWrapper.getObject(AttributeWrapper.java(CompiledCode))
at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java(Compiled Code))
at
weblogic.servlet.internal.WebAppServletContext.getAttribute(WebAppServletContext.java(Compiled Code))

setAttribute() がセッションへの追加前にシリアライズ可能オブジェクトをチェックするようにコードが修正された。

CR123571

同じマシン上で複数の T3 クライアントを同時に起動すると、それらの複数のクライアントが同じ JVMID を取得し、例外が生じるか、クライアントがハングする可能性があった。 この問題は、同じマシン上で同時に複数の T3 クライアントを起動したときのみ発生していた。 この問題は、JVMID を生成するコードを修正して解決した。

CR124763

WebLogic Server サービス パック 6 より前は、クラスタ内のすべてのサーバ インスタンスがサーバのリスン ポートをクラスタ通信のマルチキャスト ポートとして使用していた。 サーバのリスン ポートと異なるマルチキャスト ポートをクラスタで使用することはできなかった。

このサービス パックでは、クラスタで使用するマルチキャスト ポートを指定するための新しい任意指定の Java プロパティ -Dweblogic.cluster.multicastport=port_number が導入される。 この新しいプロパティを使用するには、すべてのクラスタ メンバーがその起動スクリプトで同じ -Dweblogic.cluster.multicastport 値を指定する必要がある。

起動時に -Dweblogic.cluster.multicastport が指定されないと、サーバは引き続きリスン ポートをクラスタ通信のマルチキャスト ポートとして使用する。

デプロイメント

変更要求番号

説明

CR102324

このサービス パックがリリースされる前は、WebLogic Server はデプロイメント エラーと関連するネストされた例外をログに記録していなかった。 ログに記録されたテキストは、次のようにデプロイメント エラーのみを示していた。

<Mar 28, 2003 1:10:51 AM PST> <Error> <J2EE> <Error deploying application application_name: Caught IOException for path=path_to_application>

次のようにデプロイメント エラーだけでなくネストされた例外もログに記録されるようにコードが修正された。

<Mar 28, 2003 1:10:51 AM PST> <Error> <J2EE> <Error deploying application_name: with deployment error Caught IOException for path=path_to_application and nested error java.io.FileNotFoundException: File not found>

EJB

変更要求番号

説明

CR056023

Oracle データベースにアクセスする CMP2.0 EJB は、データベースがロックされている場合にタイムアウトにならなかった。

この問題は、trans-timeout-seconds が「10」などのゼロ以外の値に設定されている状態で、ロックされたデータベース テーブルに対して ejb2.0 cmp の例が実行されたときに見受けられた (テーブルは SQLplus「lock table ejbaccounts in exclusive mode」を使用してロックされていた)。 テーブルがロックされている状態でクライアントが実行されると、そのクライアントはアカウントを作成しようとして無限にハング状態を続けていた。 SQLplus を使用してデータベース ロックが解除された後は、クライアントでロールバック例外が発生していた。 トランザクションのタイムアウト時には、ロールバックが行われなければならない。

分析の結果、タイムアウト期間が切れて、タイマーが TransactionRolledBack メッセージをデータベースに送信したときに、データベースがロックを解除していないことが判明した。

この問題は、Oracle Thin ドライバの行レベルのロックについて以下の手段で解決した。

  • 接続のロールバックの前に、weblogic.jdbc.jts.Connection クラスの internalRollback メソッドで canceAllStatementsBeingUsed を実行する

  • 開いているすべての文を反復処理してそれらをキャンセルし、接続がロールバックされ、SQL 例外を無視するようにする新しいメソッド canceAllStatementsBeingUsedweblogic.jdbc.common.internal.ConnectionEnv クラスに導入する

この修正は、Oracle Thin ドライバの行レベルのロックについてのみ有効。

CR098343

WebLogic Server 6.1 SP02 と SP04 では、トランザクションが 2 つのサーバ インスタンスに分散されているときに JDBC 接続がプールに戻らなかった。 JDBC 属性 KeepXAConnTillTxCompletetrue に設定されていた。 このイベント シーケンスにより、次の問題が発生した。

  1. サーバ インスタンス 1 でユーザ トランザクションを開始する。

  2. JMS メッセージを永続キューに格納する。 JMS サーバおよびキューはサーバ インスタンス 2 に存在する。

  3. サーバ インスタンス 2 で EJB を更新する。

  4. トランザクションをコミットする。

エラー メッセージは生成されなかった。 更新が実行され、メッセージが JMS キューに格納された。 しかし、ejb 接続プール内に「使用中」のままになっている接続が存在した。 この手順を何度も繰り返すと、接続プール内の接続が使い果たされる。

この問題は、トランザクションが単一のサーバ インスタンスで行われるか、または JMS メッセージがトランザクション スコープの外のキューに格納される場合には発生しなかった。

この問題は、aftercompletion コールバックで接続が解放されるようにコードを修正したことで解決された。

CR099041

WebLogic Server 6.1 SP04 では、顧客が使用しているアプリケーションの特定の EJB でメソッドを呼び出している間に次の例外がランダムに生成されることが報告された。

java.lang.ClassCastException: java.lang.String at weblogic.utils.classfile.DoubleKey.equals(DoubleKey.java:24) at java.util.Hashtable.get(Hashtable.java:318) at weblogic.utils.classfile.ConstantPool.find(ConstantPool.java:58) at weblogic.utils.classfile.ConstantPool.getUtf8(ConstantPool.java:251) at weblogic.utils.classfile.expr.ClassInfo.addField(ClassInfo.java:86) at weblogic.utils.classfile.expr.DotClassExpression.code(DotClassExpression.java:34) at weblogic.utils.classfile.expr.InvokeExpression.code(InvokeExpression.java:31) at weblogic.utils.classfile.expr.ExpressionStatement.code(ExpressionStatement.java:19) at weblogic.utils.classfile.expr.TryCatchStatement.code(TryCatchStatement

この問題は、weblogic.utils.classfile.DoubleKeyequals() メソッドをコード修正することで解決した。

CR099626

WebLogic Server 6.1 SP03 では、ejbc が ejbSelect クエリで無効な SQL を生成していた。 このクエリは、テーブル エリアスが不正確に生成されて次のエラーが生じていたので失敗していた。

ORA-00904: invalid column name

この問題は、コードを修正して解決された。

CR099760

EJB 1.1 CMP Bean でフィールドの最適化が実装されたので、更新があっても値は変更されなかったフィールドがデータベースに書き込まれなくなった。 この最適化は、プリミティブおよび不変オブジェクトでのみ実行される。

CR100246

テストでステートフル EJB を削除しようとしたときに LockTimeoutException が発生していた。 処理は次のように行われていた。

  1. テスト時に、エンティティ Bean のリモート メソッドの中でステートフル セッション Bean を作成する (local/localhome インタフェース)。

  2. ステートフル セッション Bean のビジネス メソッドを呼び出す (このメソッドが今度はさまざまなタイプの Bean を作成する)。

  3. ステートフル セッション Bean の削除を試行する。

remove の呼び出しで、次の例外が送出される。

Nov 18, 2002 12:51:33 AM PST> <Info> <EJB> <010049> <EJB Exception in method: remove: weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:LibraryInfoEJB with primary key:85335648642269185 timed-out after waiting 0 ms. The transaction or thread requesting the lock was:Thread[ExecuteThread: '6' for queue: 'default',5,Thread Group for Queue: 'default']. weblogic.ejb20.locks.LockTimedOutException: The lock request from EJB:LibraryInfoEJB with primary key:85335648642269185 timed-out after waiting 0 ms. The transaction or thread requesting the lock was:Thread[ExecuteThread: '6' for queue: 'default',5,Thread Group for Queue: 'default'].
at
weblogic.ejb20.locks.ExclusiveLockManager$LockBucket.lock(ExclusiveLockManager.java:449)
at weblogic.ejb20.locks.ExclusiveLockManager.lock(ExclusiveLockManager.java:259)
at
weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java:248)
at weblogic.ejb20.manager.StatefulSessionManager.acquireLock(StatefulSessionManager.java

この問題は、weblogic-ejb-jar.xml デプロイメント記述子の新しい要素 <allow-remove-during-transaction> を追加することで解決した。 この要素を true に設定すると、上の例外は発生しない。

CR101918

ホットスポットがあり、ネイティブ IO が無効化された NT 上で、ejb20 ホーム メソッドのテスト中に次のエラーが送出された。

java.lang.IllegalStateException: zip file closed at java.util.zip.ZipFile.ensureOpen(ZipFile.java:377)atjava.util.zip.ZipFile.getEntry(ZipFile.java:138)at eblogic.utils.classloaders.ClasspathClassFinder.getSourcesInternal(ClasspathClassFinder.java:225)at weblogic.utils.classloaders.ClasspathClassFinder.getSource(ClasspathClassFinder.java:155)at weblogic.utils.classloaders.MultiClassFinder.getSource(MultiClassFinder.java:53)at weblogic.utils.classloaders.MultiClassFinder.getClassSource(MultiClassFinder.java:45)at weblogic.utils.classloaders.GenericClassLoader.findLocalClass(GenericClassLoader.java:303)at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:161)weblogic.rmi.internal.BasicRuntimeDescriptor.getClientRuntimeDescriptor(BasicRuntimeDescriptor.java:526)...

分析の結果、この問題はアンデプロイメント時の未キャンセルのトリガが関連していることが判明した。 以下の修正で問題は解決された。

  • ejbc の最後に Utilities クラスで静的クラスローダ エントリが削除されるように rmic のコードが修正された。

  • スレッドを再利用する前にコンテキスト クラスローダがクリーニングされるように ExecuteThread が修正された。

  • Exclusive 同時方式の cmp/bmp がアンデプロイされるときにトリガがキャンセルされるように ejb のコードが修正された。

CR102028

接続プールの作成で Oracle Thin ドライバを使用するときに、DB QueryString が不適切に生成されていた。

  1. Oracle Thin ドライバを使用して接続プールを作成する。

  2. テスト ケース ejb20/relations/FindersTest/testStringFunctionLOCATE() を実行する。

  3. 上のテスト ケースは、ejb20/relations/finder.ts ファイルから実行できる。

  4. EJB の「ComputerEJB」、「EmployeeEJB」、および「FinderEmployeeEJB」が必ず、この Thin ドライバを使用して作成された接続プールを使用するようにする。

  5. これを実行すると、「Invalid Character」エラーが生じる。

スタック トレースは次のとおり。

javax.ejb.FinderException: Problem in findByNameEquals while preparing or executing statement: 'weblogic.jdbc.jts.PreparedStatement@55c5eb': java.sql.SQLException: ORA-00911: invalid character java.sql.SQLException: ORA-00911: invalid character at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:134) at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:289) at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:573) at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol...

この問題は、適切な SQL クエリが生成されるようにコード修正することで解決した。

CR102180

WebLogic Server SP03 では、100 EJBs を使用して .jar のスタブとスケルトンをコンパイルするときに ejbc が失敗していた。 次の例外が発生した。

java.io.IOException: CreateProcess: c:¥VisualCafe¥bin¥sj.exe -classpath c:¥java¥java130¥jre¥lib¥rt.jar;
c:¥java¥java130¥jre¥lib¥i18n.jar;c:¥java¥java130¥jre¥lib¥sunrsasign.jar;c:¥java¥java130¥jre¥classes;
c:/java/java130/lib/tools.jar;D:/weblogic/dev/src/3rdparty/jconnect/jConnect.jar;D:/weblogic/src_130sj/license;D:/weblogic/dev/src/3rdparty/oracle/816/classes12.zip;
D:/weblogic/src_130sj/classes;D:/weblogic/src_130sj/lib/xmlx.jar;D:/weblogic/src_130sj/lib/ejb20.jar;D:/weblogic
/dev/src/3rdparty/weblogicaux.jar;D:/weblogic/dev/src/3rdparty/cloudscape/lib/cloudscape.jar;D:/weblogic/src_130sj/classes_ifmx4;
D:/weblogic/src_130sj/classes_mssql4;D:/weblogic/src_130sj/tools;c:/java/java130/jre/lib/rt.jar;D:¥raviWork¥ejb...

この問題は、コンパイラのコマンドラインの長さ制限が原因。 この問題は、javac @tempfile 機能を使用することで解決した。この機能を使用すると、一時ファイルを使用してファイル名をコンパイラに渡すことができる。

CR102308

WebLogic Server 6.1 SP04 では、Administration Console でエンティティ Bean の待機について不正確な値が報告されていた。

この問題は、waiterCurrentCount 属性を追加したことによって解決された。この属性は、クライアントがロック待機を開始するときに増加し、ロックを取得またはクライアントがタイムアウトしたときに減少する。

CR103047

WebLogic Server 6.1 SP03 では、MDB のトランザクション タイムアウトがログに記録されないという報告があった。 JMS 送り先からのメッセージを処理するために MDB が要する時間がトランザクションのタイムアウト制限を超えると、トランザクションがロールバックされ、メッセージは再配信用に送り先に戻されるが、transaction-timeout または transaction-rollback メッセージがログに記録されていなかった。

この問題は、トランザクション タイムアウトを報告するように MDListener のコードを修正することで解決された。

CR103978

WebLogic Server 6.1 SP02 では、以下の状況下で Web アプリケーションがセッションからリモート オブジェクトを取得できていなかった。

  • Web アプリケーションがドメイン 1 の管理サーバにデプロイされている

  • EJB がドメイン 2 のクラスタ内の 1 つの管理対象サーバにデプロイされている

  • Web アプリケーションが、EJB がデプロイされている管理対象サーバの URL を使用して EJB のルックアップを行った

  • Web アプリケーションがリモート オブジェクトを作成して、それを HttpSession に追加した

  • Web アプリケーションが、次の例外を発してセッションからリモート オブジェクトを取得するのに失敗した

<Apr 21, 2003 11:42:47 AM PDT> <Error> <HTTP Session> <Error reconstructing the EJBObject put into session for name: trader java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'statelessSession.TraderHome' on server: 't3://acaoclust:7001 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java :80) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:179) at weblogic.servlet.internal.session.SessionData.getAttribute(SessionDat a.java:390) at jsp_servlet.__remoteejb._jspService(__remoteejb.java:119) at weblogic.servlet.jsp.JspBase.service(JspBase.java:27) at

このエラーは、EJB がクラスタではなく 1 つの管理対象サーバにデプロイされているにもかかわらず、Web アプリケーションが HttpSession からリモート EJB オブジェクトを取得するのにクラスタの URL を使用したことが原因だった。

この問題は、コードの修正で解決された。 現在、EJB ハンドル (HomeHandle) は、weblogic-ejb-jar.xml ファイルの home-is-clusterable デプロイメント要素の指定に従って、EJB ホームがクラスタ化可能でない場合は、EJB がデプロイされているサーバの URL を使用するようになっている。 クラスタの URL は、home-is-clusterable が true の場合だけ使用される。

CR104414

WebLogic Server 6.1 SP04 では、クラスパスが長い場合にサーバ側で ejbc コンパイル エラーが発生していた。次のエラーが発生していた。

[EJBCompiler] : Compiling EJB sources Warning: UNIXProcess.forkAndExec native error: The parameter or environment lists are too long. <Apr 24, 2003 2:55:27 PM GMT> <Error> <J2EE> <Error deploying application applicationname: Unable to deploy EJB: monitor/EMAServerManager.jar from monitor/EMAServerManager.jar: Compiler failed executable.exec(java.lang.String[javac, -nowarn, -classpath, ................................long classpath which is not shown here............................................................)
at
weblogic.ejb20.ejbc.EJBCompiler.compileEJB(EJBCompiler.java(Compiled Code))
at
weblogic.ejb20.deployer.Deployer.runEJBC(Deployer.java(Inlined Compiled Code))
at
weblogic.ejb20.deployer.Deployer.compileEJB(Deployer.java(Compiled Code))

この問題は、-compilerclass オプションを指定してインライン コンパイルを使用し、compilerclass の compile メソッドが呼び出されるように callcompile フラグの代わりに noexit を使用することで解決した。

CR105609

WebLogic Server 6.1 SP04 のサーブレットまたはステートレス セッション Bean が WebLogic Server 6.1 SP02 にデプロイされたステートフル セッション Bean を呼び出したときに Null ポインタ例外が送出されていた。 スタック トレースは次のとおり。

java.lang.NullPointerException at weblogic.ejb20.internal.HandleImpl.readExternal(HandleImpl.java:101) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1212) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.java:2263) at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:519) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1412) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at java.util.ArrayList.readObject(ArrayList.java:531) at java.lang.reflect.Method.invoke(Native Method) at java.io.ObjectInputStream.invokeObjectReader(ObjectInputStream.java:2214) at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1411) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236) at

分析の結果、スタブのスタンプがハンドルで押されている場合のステートフル セッション Bean のハンドルの相違に関連するハンドルの問題を解決するために、ハンドルの通信フォーマットが WebLogic Server 6.1 SP02 後に拡張されていることが判明した。 ステートレス セッション Bean の場合には、スタブにハンドルは追加されない。

この問題は、ステートレス セッション Bean の「ハンドルなし」が許可されるようにコードを修正することで解決した。

CR106136

WebLogic Server 6.1 SP04 では、delay-updates-until-end-of-tx が false に設定されている場合に、EJB 1.1 CMP Bean のゲッター メソッドが isModified() を呼び出していなかった。

セッション EJB が、エンティティ EJB のゲッター メソッドを呼び出していた。 両方の EJB に、トランザクション属性が Required に設定されたコンテナ管理のトランザクションがあった。 ゲッター メソッドの各呼び出しの後には ejbStore() の呼び出しが続き、delay-updates-until-end-of-txfalse だった。 しかし、Bean で ejbStore を呼び出す前に、コンテナが isModified メソッドを呼び出していなかった。 isModified() メソッドは、トランザクションがコミットされたときにのみ呼び出されていた。

ejbStore は、Bean での isModified メソッドの結果に応じて postInvoke() から呼び出されるべき。 この問題は、コードを修正して解決された。

CR111551

WebLogic Server 6.1 SP05 では、java.lang.ClassCastException: oracle.sql.BLOB エラーを生じさせる CMP コードを EJBC が生成していた。

分析の結果、クエリ用に生成された CMP RDBMS コードが不正確であることが判明した。 WebLogic Server 6.1 SP05 より前は、サーバ側の JDBC は RMI ドライバ、プール ドライバを経由して DBMS ドライバに辿り着いていた。 WebLogic Server 6.1 SP05 からは、RMI ドライバは外部クライアントでのみ呼び出される。 サーバ側のクライアント コードは直にプール ドライバにアクセスし、そのプール ドライバが RMI ラッパーでラップされていない BLOB を直に DBMS ドライバに返す。 この変更では、weblogic.jdbc.common.OracleBlob ではなく oracle.sql.BLOB に直接コードがキャストされる必要がある。

この問題は、SP05 以降の動作を反映するコードが生成されるように EJBC を修正することで解決した。

CR111771

WebLogic Server 6.1 SP02 では、Bean がアンデプロイされたときにデータベースが矛盾した状態のまま置かれていた。 この問題は、次の呼び出しシナリオで起こっていた。

webApp <--> OuterBean <--> InnerBean

Bean はステートレス セッション Bean であり、コンテナ管理のトランザクションを使用し、trans-attribute=Required が設定されている。 OuterBean.m() はテーブルに行を挿入してから、別のテーブルに行を挿入する InnerBean.m() を呼び出す。 このシナリオは単一トランザクションのコンテキスト内で起こるので、両方のテーブルに同じ数の行がある。 Bean は、別々の jar にパッケージ化される。 OuterBean は InnerBean のホームをキャッシュし、すべてが 1 つのサーバにデプロイされる。 InnerBean は、テストの過程でサーバを対象から外す。 この場合に、テーブルは矛盾した状態に置かれる (OuterBean はそれ以上テーブルに行を挿入しないが、InnerBean は引き続き行う)。

分析の結果、InnerBean がアンデプロイされた後に、TxManager.undeploy が処理中のトランザクションをロールバックし、それ以上トランザクションが登録されないようにそのインスタンスに応答なしのマーキングをすることが判明した。 OuterBean と InnerBean は同じエンタープライズ アプリケーションにパッケージ化されており、呼び出しは参照によって行われ、RMI を経由していた。 ホームと Bean は OuterBean にキャッシュされていたので、InnerBean がアンデプロイされた後でも、呼び出されたリモート メソッドはサービスが提供されていた。 InnerBean がアンデプロイされた後、OuterBean が InnerBean.insert() を呼び出したときに、その呼び出しと関連するトランザクションがあった (OuterBean によって開始されたもの)。 preInvoke では、TxListener が設定され、トランザクションが TxManager に登録される。 TxManager への登録の間、インスタンスは応答なしと判断され、WebLogic Server はトランザクションをロールバックして通知なしに復帰する。 トランザクションが登録されていないので、InnerBean.insert() 内で取得されたデータベース接続は呼び出されたトランザクション内にはなく、OuterBean で実行されたロールバックは InnerBean で挿入された行に影響を与えない。その結果として、OuterBean はそれ以上テーブルに行を挿入しないが、InnerBean は挿入を続ける、という状況が生まれる。 (Bean がアンデプロイされたのでトランザクションをロールバックした後) 通知なく復帰することが問題の原因。

この問題は、BaseEJBManager の preInvoke でデプロイメントのステータスをチェックし、アンデプロイされた Bean に呼び出しが届かないようにするコード修正で解決した。

CR115026

WebLogic Server 6.1 SP02 では、MDB が MQSeries 上でリスンしている状態で、WebLogic Server 側の MQSeries の java スレッドが MQSeries の障害および MQSeries の再起動のときに適切に閉じられていなかった。 障害または再起動のたびに、MQSeries の AsyncThread の数が 2 倍になっていた。

この問題は、JMSConnectionPoller.createJMSConnection() の障害とクリーン アップのコードを改良することで解決した。

JDBC

変更要求番号

説明

CR098343

トランザクションが 2 つのサーバ インスタンスに分散されているときに JDBC 接続がプールに戻らなかった。 JDBC 属性 KeepXAConnTillTxComplete が true に設定されていた。 このイベント シーケンスにより、次の問題が発生した。

  1. サーバ インスタンス 1 でユーザ トランザクションを開始する。

  2. JMS メッセージを永続キューに格納する。 JMS サーバおよびキューはサーバ インスタンス 2 に存在する。

  3. サーバ インスタンス 2 で EJB を更新する。

  4. トランザクションをコミットする。

エラー メッセージは生成されなかった。 更新が実行され、メッセージが JMS キューに格納された。 しかし、EJB 接続プール内に「使用中」のままになっている接続が存在した。 この手順を何度も繰り返すと、接続プール内の接続が使い果たされてしまった。

この問題は、トランザクションが単一のサーバ インスタンスで行われるか、または JMS メッセージがトランザクション スコープの外のキューに格納される場合には発生しなかった。

この問題は、aftercompletion コールバックで接続が解放されるようにコードを修正したことで解決された。

CR099872

Exception during commit of transaction スタック トレース例外のメッセージに接続プール名が含まれているが、データ ソース名が含まれていなかった。 <Exception during commit of transaction Xid=39:74a54046e2c2bb30(5962554),Status=Rolled back. [Reason=ja vax.transaction.xa.XAException: JDBC driver does not support XA, hence cannot be a participant in two-phase commit. To force this participation, set the EnableTwoPhaseCommit property on the corresponding JDBCTxDataSource property, to true. Pool = CatPhase1]...

スタック トレースの内容を拡張して、データ ソースの名前が含まれるようにした。

CR103046

JDBC 接続プールの使用時に Statement.close() を発行しても、基底の ResultSet に関連付けられたすべてのリソースが解放されていなかった。それが原因で、OutOfMemoryError が生じる恐れがあった。 この問題は、接続プールを通じて Statement を閉じるときにのみ発生していた。 明示的に ResultSet 自体を閉じるとき、またはドライバを直接使用しながら文を閉じるときには発生していなかった。

この問題は、コードを修正して解決された。

CR103299

このサービス パックでは、次のスタック トレースを生じさせていたリーク検出コードのエラーが修正される。

[SerialConnection] : Connection Leak detected!!!!!!java.lang.Throwable: StackTrace at creation of connection: Start server side stack trace:
java.lang.Throwable: StackTrace at creation of connection: at weblogic.jdbc.rmi.SerialConnection.<init>(SerialConnection.java:47) at weblogic.jdbc.pool.Connection.writeReplace(Connection.java:1427) at java.lang.reflect.Method.invoke(Native Method)at java.io.ObjectStreamClass.invokeMethod(ObjectStreamClass.java:1615) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:303) at weblogic.common.internal.ChunkedObjectOutputStream.writeObject(ChunkedObjectOutputStream.java:115) at weblogic.rjvm.MsgAbbrevOutputStream.writeObject(MsgAbbrevOutputStream .java:82) at weblogic.jdbc.common.internal.RmiDataSource_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:398) at weblogic.rmi.cluster.ReplicaAwareServerRef.invoke(ReplicaAwareServerRef.java:114) at weblogic.rmi.internal.BasicServerRef$1.run(BasicServerRef.java:339) at weblogic.security.service.SecurityServiceManager.runAs(SecurityServiceManager.java:850) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:334) at weblogic.rmi.internal.BasicExecuteRequest.execute(BasicExecuteRequest .java:30)at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:215) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:191) End server side stack trace

CR103321

WebLogic Server 6.1 SP04 では、JDBCConnectionPoolRuntimeMBeangetConnectionsTotalCount() メソッドが期待通りに機能していなかった。 インスタンス化からのプール内の JDBC 接続の総数を返す代わりに、インスタンス化からの最大接続数を返した。

この問題は、メソッド コードの修正によって解決された。

CR103421

WebLogic Server 6.1 のサービス パック 3 と 4 では、BigDecimal データ型が関わるトランザクションで、そのトランザクションがリモートの DataSource を取得する前にローカルの DataSource を取得した場合に SQLWarning 例外が送出されていた。 スタック トレースのテキストは次のとおり。

java.sql.SQLException: java.sql.SQLWarning: Exhausted Resultset
Start server side stack trace:
weblogic.common.internal.WLSQLWarning: Exhausted Resultset
at
weblogic.jdbc.common.internal.DriverProxy.getWLSQLFromSQLException(DriverProxy.java:2
at
weblogic.jdbc.common.internal.ResultSetProxy.execute(ResultSetProxy.java:716)
at weblogic.t3.srvr.ClientRequest.execute(ClientContext.java:769)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
End server side stack trace

この問題は、T3 ドライバがキャッシュのデータではなく常にリモートの結果セットで getBigDecimal() を問い合わせていたことが原因。

この問題は、コードを修正して解決された。

CR103619

このサービス パックでは、isClosed() メソッドと JTS 接続の問題が修正される。 それらの問題は、Sun の JDBC 用 CTS を実行したときに検出された。

CR106767

アプリケーションが複数回 JDBC オブジェクトをクローズしようとすると、WebLogic Server は例外を送出するようになった。

CR108580

WebLogic Server は、ConnectionLeakProfile オブジェクトの作成前に null のプール名をチェックできず、次の例外を生じさせていた。

java.lang.NullPointerExceptionat java.lang.String.<init>(String.java:193) at weblogic.jdbc.common.internal.ConnectionLeakProfile.<init>(ConnectionLeakProfile.java:21)at weblogic.jdbc.rmi.internal.ConnectionImpl.unreferenced(ConnectionImpl .java:144) at weblogic.rmi.internal.BasicServerRef$UnreferencedExecuteRequest.execute(BasicServerRef.java:702) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:234 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:210)

この問題は、コードを修正して解決された。

CR112607

接続プールの URL またはパスワードが正確でない場合でも、WebLogic Server 6.1 サービス パック 4 では初期容量 0 の新しい JDBC 接続プールが作成されていた。 URL またはパスワードが正しくない場合は JDBC 接続プールの作成が失敗するようにコードが修正された。

CR120455

WebLogic Server 6.1 サービス パック 2 でメモリ リークが検出された。 このリークは、データベース上の BLOB カラムに TxDataSource を使用してアクセスしたときに発生していた (WebLogic XA ドライバを使用)。 この問題は、コードを修正して解決された。

CR120531

WebLogic Server サービス パック 5 では、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
[...]

接続リーク警告が表示されることのないようにコードが修正された。それでも、サーバはプールがリセットされる時点で接続が既に解放されている場合は初期例外を適切に表示する。

CR121671

WebLogic Server サービス パック 4 では、weblogic.jdbc.jta.ResultSet.getType() メソッドがそれ自体を再帰的に呼び出して、次のようなスタック オーバーフロー例外を引き起こす恐れがあった。

java.lang.StackOverflowError
at weblogic.jdbc.jta.ResultSet.checkIfClosed(ResultSet.java:106)
at weblogic.jdbc.jta.ResultSet.getType(ResultSet.java:507)
at weblogic.jdbc.jta.ResultSet.getType(ResultSet.java:508)

この問題は、コードを修正して解決された。

CR125135

デフォルトでは、WebLogic jDriver for Oracle/XA のデータ ソースは oracleXATrace パラメータの値を false ではなく true に設定する。 このことが原因で、config.xmloracleXATrace=”false” を設定してトレース ファイルを無効にしない限り、ドライバは時間が経つにつれて大きくなる xa_poolname*.trc という形式のトレース ファイルを作成していた。

値が指定されていない場合は oracleXATrace のデフォルト値が false に設定されるようにコードが修正された。

CR125705

JDBC マルチプールの使用時に、WebLogic Server は接続の試行時点で初期プールが完全に予約されている場合にクライアントにリソース例外を送出し、バックアップ プールから接続を提供することに失敗していた。 代わりに ConnectDeadException を送出するようにコードが修正された。マルチプールでは、リストの次のプールにフェイルオーバする理由としてこの例外を解釈する。

CR127891

情報が読みやすくなるように、接続リーク ファイルの形式が修正された。

jDriver

変更要求番号

説明

CR104968

WebLogic jDriver for Oracle/XA は、Oracle RDBMS インスタンスで設定された NLS_NUMERIC_CHARACTERS パラメータを正しく処理していなかった。 このことが原因で、データベースの小数点としてカンマ (‘,’) が使用されている場合に、double 値または float 値を取得するときに java.sql.SQLException が生じていた。

java.sql.SQLException: java.lang.NumberFormatException - '1,2'
at weblogic.jdbc.oci.ResultSet.getFloat(ResultSet.java:312)
at weblogic.jdbc.jta.ResultSet.getFloat(ResultSet.java:190)
at
weblogic.jdbc.rmi.internal.ResultSetImpl.getFloat(ResultSetImpl.java:224)
at
weblogic.jdbc.rmi.internal.ResultSetStraightReader.getFloat(ResultSetStraightReader.java:67)
at
weblogic.jdbc.rmi.SerialResultSet.getFloat(SerialResultSet.java:219)
at examples.servlets.DBAccess.service(DBAccess.java:54)
at
[...]

この問題は、非 XA バージョンの WebLogic jDriver for Oracle では起こらなかった。 この問題は、コードを修正して解決された。

CR107474

WebLogic Server 6.1 サービス パック 3 では、close() が実行された後に OciObjectStream がバッファを破棄していなかった。 この問題は、コードを修正して解決された。

CR113462

WebLogic Server サービス パック 5 は、Oracle の NLS_LANG 設定を使用した環境で BigDecimal 型を使用すると NumberFormatException を送出していた。 この問題は、アメリカ式の数字の定義にあわせて Oracle の NLS_NUMERIC_CHARACTERS パラメータを使用したときには起こらなかった。 この問題は、コードを修正して解決された。

JMS

変更要求番号

説明

CR103001

WebLogic Server は、メッセージング ブリッジ送り先のホスト サーバがアクセス不能な場合に過度に長い例外を表示していた。 短い例外メッセージが表示されるようにコードが修正された。

CR104538

JMS のデッドロックは、BESession.java close(long lastSequenceNumber) メソッドを修正することで修正された。 デッドロックは、次のような部分的なスレッド ダンプで調べることができた。

ExecuteThread: '9' for queue: 'queue_1'" daemon prio=5
tid=0x2757938 nid=0x5e waiting for monitor entry [0xce97f000..0xce97fc68]
at weblogic.jms.backend.BETopic._addMessageToConsumers(BETopic.java:590)
at weblogic.jms.backend.BETopic.addMessageToConsumers(BETopic.java:296)
at
weblogic.jms.backend.BEMessageWriteListener.storeIOComplete(BEMessageWriteListener.java:85)
at weblogic.jms.store.StoreRequest.execute(StoreRequest.java:342)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

"ExecuteThread: '14' for queue: 'queue_2'" daemon prio=5 tid=0x57b200
nid=0x54 waiting for monitor entry [0xd1b7f000..0xd1b7fc68]
at weblogic.jms.backend.BESession.stop(BESession.java:386)
at weblogic.jms.backend.BESession.close(BESession.java:434)
at weblogic.jms.backend.BESession.close(BESession.java:1083)
at weblogic.jms.backend.BESession.invoke(BESession.java:1024)
at
weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:585)....

CR112750

サーバが 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 サーバの対象の解除と再設定で、例外が送出されることはなくなった。

CR122749

EJBComponentRuntimeMBean.getEJBRuntimes() を呼び出すと、ASSERTION FAILED エラーに続いて ArrayStoreException が生じる問題が修正された。

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)

この問題は、コードを修正して解決された。

JNDI

変更要求番号

説明

CR105592

WebLogic Server 6.1 サービス パック 5 では、サーバが、環境をスレッドにプッシュしない ReadOnlyWrapper から環境をポップしようとしていた。 このことが原因で、次の AssertionErrorEmptyStackException が生じていた。

java.util.EmptyStackException
at weblogic.utils.collections.Stack.pop(Stack.java:82)
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:79)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
at
weblogic.jndi.factories.java.ReadOnlyContextWrapper.close(ReadOnlyContextWrapper.java:30)
[...]
--------------- nested within: ------------------
weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ attempt to pop from an empty stack ] - with nested exception:
[java.util.EmptyStackException]
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:81)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
[...]

ReadOnlyWrapper でポップが試行されないようにコードが修正された。

CR105761

このサービス パックには、サーバでの JNDI ルックアップのパフォーマンスを大幅に向上させる新しい JNDI キャッシング メカニズムが含まれている。

CR100726

WebLogic Server クラスタの単一メンバーをステートレス セッション EJB の対象に設定し、デプロイメント記述子で home-is-clusterablestateless-bean-is-clusterable を false に設定しなかった場合に、WebLogic Server は適切に ClassNotFoundException をログに記録するようになった。

CR110916

コンテキストが ejbCreate() メソッドで作成され、Context.close() がそれに続いて ejbRemove() メソッドで呼び出された場合に WebLogic Server は EmptyStackException を送出していた。 次に例外テキストの一部分を示す。

java.util.EmptyStackException
at weblogic.utils.collections.Stack.pop(Stack.java:82)
at
weblogic.kernel.ResettableThreadLocalStack.pop(ResettableThreadLocalStack.java:79)
at
weblogic.jndi.internal.ThreadEnvironment.pop(ThreadEnvironment.java:18)
at weblogic.jndi.internal.WLContextImpl.close(WLContextImpl.java:72)
at javax.naming.InitialContext.close(InitialContext.java:476)
[...]

この問題は、コードを修正して解決された。

JSP

変更要求番号

説明

CR088525

以前の WebLogic Server 6.1 サービス パックで、値が「/////」の JSP パラメータが、getParameter() によって値が「/」であると解釈された。

この問題は、コードを修正して解決された。

CR092039

WebLogic Server は、JSP の charset 値に余計な引用符を付けた場合に UnsupportedEncodingException を送出していた。 たとえば、次のタグは例外を送出する。

<%@ page contentType="text/html; charset=¥"Shift_JIS¥"" %>

この問題は、コードを修正することで解決した。

CR093014

WebLogic Server 6.1 SP02 では、あるスクリプトレットで始まり、次のスクリプトレットで終わる Java コメントで次の例外が生じていた。

<22.07.2002 14:12:24 CEST> <Error> <HTTP> <[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at weblogic.servlet.jsp.ScriptletScopeLexer.mCLOSE_BRACE(ScriptletScopeLexer.java:527) at weblogic.servlet.jsp.ScriptletScopeLexer.mTOKEN(ScriptletScopeLexer.java:232) at weblogic.servlet.jsp.ScriptletScopeLexer.nextToken(ScriptletScopeLexer.java:159) at weblogic.servlet.jsp.ScriptletScopeLexer.parse(ScriptletScopeLexer.java:119) at weblogic.servlet.jsp.JspLexer.mSCRIPT(JspLexer.java:4367) at weblogic.servlet.jsp.JspLexer.mSTANDARD_THING(JspLexer.java:2173) at ....

この問題は、ScriptletScopeLexer が Java コメント全体をスキップするようにコードを修正して解決した。

CR093520

あるタイムゾーンにあるマシン上で JSP をプリコンパイルし、その同じ JSP を別のタイムゾーンにあるサーバにデプロイした場合には、WebLogic Server がその JSP を再コンパイルすることがあった。 この問題は、WebLogic Server が JSP のローカル タイムスタンプ (JAR ユーティリティによって埋め込まれた) を、生成されたクラス ファイルのタイムスタンプと比較して JSP をチェックしていたことが原因。

この問題は、コンパイル時にタイム ゾーンを保存し、デプロイメント時にそのタイム ゾーンを使用して再コンパイルが必要かどうか判断することで解決した。

CR100823

JSP をコピーで更新し、そのコピーが正しく解析されない場合に、WebLogic Server はデッドロック状態に陥っていた。 この問題は、2 つの別個のデッドロックが絡んでいた。 それらのデッドロックは、JSP スタブ レベルで例外を送出および評価し、getJarFiles() で不要なスレッドの同期をなくすことで発生しなくなった。

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 上で正しく動作した。

アプレット属性の順序が正しくなるようにコードを修正して、問題を解決した。

CR103214

compilerclass JSP パラメータを設定すると、WebLogic Server は次のように compilerclass=null メッセージを起動ログに記録していた。

JSPServlet with initArgs '[JspConfig:
verbose=true,packagePrefix=jsp_servlet,-compiler= C:¥61sp4¥jdk131/bin/javac,compileFlags=,workingDir=C:¥61sp4¥wlserver6.1¥config¥examples¥applications¥ examplesWebApp¥WEB-INF¥_tmp_war_examples_examplesWebApp,pageCheckSeconds=1,superclass=weblogic.servlet.jsp. JspBase,keepgenerated=false,precompileContinue=false, compilerSupportsEncoding=true,encoding=null,defaultfilename=index.jsp,compilerclass= null,noTryBlocks=false]'>

この問題は、compilerclass の設定が起動時に使用されなかったことが原因。 JSP のコンパイルでは正しい設定が使われていた。 サーバの起動時に適切なパラメータ値が取得されるようにコードが修正された。

CR105229

WebLogic Server は空の BodyTags を評価できず、次の例外が生じていた。

<ExecuteThread: '14' for queue: 'weblogic.kernel.Default'> <<WLS Kernel>> <>
<BEA-101017>
<[ServletContext(id=12216222,name=xmlxTestApp,context-path=/xmlxTestApp)]
Root cause of ServletException.
javax.servlet.jsp.JspException: Could not find file:
java.io.FileNotFoundException: Could not find appropriate xml file
at weblogicx.xml.tags.XsltTag.doEndTag(XsltTag.java:280)
at jsp_servlet.__xsltprocessor._jspService(__xsltprocessor.java:195)
at weblogic.servlet.jsp.JspBase.service(JspBase.java:33)
at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run(ServletStubImpl.java:1053)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:387)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:305)
at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:6304)
at
weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:317)
at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:118)
at
weblogic.servlet.internal.WebAppServletContext.invokeServlet(WebAppServletContext.java:361
[...]

この問題は、コードを修正して解決された。

CR105772

WebLogic Server は、次のように空の要素タグを使用して空のボディ タグを指定したタグ ライブラリが JSP で使用されている場合に JSP 解析エラーを表示していた。

<%@taglib uri="/problem-taglib" prefix="c" %>
<html>
<head><title>Problem scenario</title></head>
<body>
<table border="1"><tr><th>Local file content</th>
<th>Included file content</th></tr>
<tr>
<td>Cell containing data from the original JSP</td>
<td><c:import url="IncludedResource.jsp" /></td>
</tr>
</table>
</body>
</html>

この問題は、次のように空のボディ コンテンツに終了要素タグが追加された場合には起こらなかった。

<td>Cell containing data from the original JSP</td>
<td><c:import url="IncludedResource.jsp" ></c:import></td>

この問題は、コードを修正して解決された。

CR106072

JSP ファイルが変更されていて再コンパイルが必要かどうか WebLogic Server が確認する秒間隔を設定する pageCheckSeconds 属性が、JSP が最初に修正されたときには機能していなかった。

この問題は、最初に JSP が呼び出されたときに WebLogic Server が lastStaleCheck を設定しなかったことが原因。

lastStaleCheck が設定されていない場合は現在の時刻に設定されるようにコードが修正された。 この修正で、JSP は不必要に再コンパイルされなくなる。

CR107042

JSP compilerclass パラメータの値として com.sun.tools.javac.Main を指定した場合、WebLogic Server は JSP へのアクセスがあると突然に終了していた。 この問題は、コードを修正して解決された。

CR111423

WAR ファイルにパッケージ化されている場合、アプリケーションのサブコンテキストに格納されたコンパイル済み JSP は WebLogic Server へのデプロイメントのたびに再コンパイルされていた。 この問題は、JSP が展開されたアーカイブ ディレクトリからデプロイされた場合、または WAR ファイルのルートコンテキストに JSP がある場合には起こらなかった。

この問題は、jarzip で使用されるタイムスタンプの丸め方法が異なることが原因だった。 丸めの矛盾により、古い方のタイムスタンプ (1 秒差) が WAR ファイル内のクラス ファイルに記録され、サーバがクラスを再コンパイルすることになっていた。

コンパイル済み JSP クラスのタイムスタンプを 1 秒進めて JSP の再コンパイルを防止するようにコードが修正された。

CR120914

WebLogic Server のフォーム検証タグ ライブラリを使用すると、リクエスト パラメータが次以降の JSP から利用できていなかった。 この問題は、コードを修正して解決された。

CR127515

WebLogic Server 6.1 SP02 では、weblogic.jspc による javac エラー メッセージが日本語インストールでは壊れていた。 この問題は、DataInputStream ではなく InputStreamReader を使用するようにコードを修正して解決された。

JTA

変更要求番号

説明

CR082504

Sybase jConnect/XA ドライバの使用時には、接続プールに戻された後に接続が再利用できなかった。 これが原因で次の例外が生じ、結局はプールの利用可能な接続が使用されていた。

XA error: XAER_RMERR : A resource manager error has occured in the
transaction branch start() failed on resource 'ZeusPool': XAER_RMERR : A
resource manager error has occured in the transaction branch
javax.transaction.xa.XAException

この問題は、Sybase が DDL の呼び出しのローカル トランザクションを開始し、接続がプールに戻されたときにそのトランザクションがクリーンアップされたかったことが原因。

DDL の呼び出しで生成されたローカルの Sybase トランザクションが終了するように、接続のクリーンアップ コードが修正された。

CR091192

このサービス パックには、回復まで 5 分待つのではなく、トランザクション リソース マネージャを直ちに回復する拡張機能が含まれている。

CR091974

XA の回復で XID が返されない場合に、WebLogic Server 6.1 サービス パック 3 は NullPointerException を送出する恐れがあった。

java.lang.NullPointerException
at
weblogic.transaction.internal.ServerResourceInfo.rollback(ServerResourceInfo.java:721)
at
weblogic.transaction.internal.ServerSCInfo.rollback(ServerSCInfo.java:318)
at
weblogic.transaction.internal.ResourceDescriptor.rollbackXids(ResourceDescriptor.java:1160)
at
weblogic.transaction.internal.ResourceDescriptor.recover(ResourceDescriptor.java:1060)
at
weblogic.transaction.internal.ResourceDescriptor.access$9(ResourceDescriptor.java:1029)
at
weblogic.transaction.internal.ResourceDescriptor$1.execute(ResourceDescriptor.java:770)
at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

XID の有無をチェックして例外が送出されないようにコードが修正された。

CR098273

トランザクション ログの古いエントリが原因で、サーバの再起動時に不要な回復のオーバーヘッドが生じることがあった。 この問題は、コードを修正して解決された。

CR103327

トランザクションがタイムアウトになった後、2 つのスレッドが同じトランザクション ID をロールバックしようとして、次のようなエラーになる場合があった。

XA.end FAILED (rm=pool_name, xar=pool_name, error code: XAER_RMERR : A resource manager error has occured in the transaction branch, message: null>
oracle.jdbc.xa.OracleXAException
at oracle.jdbc.xa.OracleXAResource.checkError(OracleXAResource.java:659)
at oracle.jdbc.xa.client.OracleXAResource.end(OracleXAResource.java:305)
at weblogic.jdbc.jta.VendorXAResource.end(VendorXAResource.java:47)

この問題は、コードを修正して解決された。

CR103601

WebLogic Server 6.1 SP03 と SP04 では、weblogic.transaction.internal.XidImpl の「equals」メソッドに渡されたオブジェクトが XidImpl のインスタンスでない場合は (たとえば String 型など)、次の例外が送出される。

java.lang.ClassCastException: java.lang.String at weblogic.transaction.internal.XidImpl.equals(XidImpl.java:114) at test.main(test.java:9)

この問題は、型の不一致をチェックして報告するようにコードを修正して解決した。

CR113226

リソース名が 64 文字を超えている場合、WebLogic Server 6.1 サービス パック 4 は接続プールのテスト時に次の例外を送出することができた。

java.sql.SQLException: XA error: XAER_RMERR : A resource manager error has occured 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 文字を超えるリソース名が正しく処理されるようにコードが修正された。

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

ノード マネージャの共有オブジェクト コードは、サーバ インスタンスの起動時に特定のコード パスがとられたときにセグメント違反を引き起こすことがあった。 IBM の zLinux JDK を使用したときにも同じコード パスで問題が発生していた。 これらの問題は、ノード マネージャのコード修正により解決した。

CR125829

ノード マネージャのリスン ポートに誤りのあるデータが送信されると、ノード マネージャがクラッシュして回復しなかった。 これはノード マネージャの通常の処理中には発生せず、誤りのある特定のデータがポートに送信される場合にのみ発生する。 この問題は、コードを修正することで解決した。

詳細については、http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_42.00.jsp を参照。

OA&M (操作と管理)

変更要求番号

説明

CR090118

WebLogic Server 6.1 SP03 以降では、Administration Console デプロイメント記述子エディタによって bea¥wlserver6.1 ディレクトリの下に jarxxxx という名前で作成される一時ディレクトリ (bea¥wlserver6.1¥jar7018 など) が削除されなかった。

分析の結果、内部ファイルのオープン ファイル ストリームが原因で、一時ディレクトリが削除されていないことがわかった。

この問題は、コードを修正することで解決した。

CR093653

WebLogic Server 6.1 SP04 では、管理対象サーバにデプロイされている展開された Web アプリケーションを更新すると、管理対象サーバにステージングされている展開されたアプリケーションには更新が反映されるが、.wlnotdelete ディレクトリの .war ファイルには反映されなかった。 サーバの再起動後に旧バージョンのアプリケーションがデプロイされた。

weblogic.refresh を使用してアプリケーションを更新すると、更新された .jsp は、管理対象サーバにステージングされている展開形式のアプリケーションにはコピーされるが、元のバージョンの .war にはコピーされなかった。

この問題は、ローカルのデプロイメント ファイルからアプリケーション エントリを削除するようにコードを修正することで解決した。

この変更の結果、アプリケーションの最新のバージョンは、更新の後で管理対象サーバが再起動されるときに、ソースから管理対象サーバのステージング領域にコピーされる。

CR093687

WebLogic Server SP03 で、起動クラスに対して LoadBeforeAppDeployments=true が設定されている場合、起動クラスが動的接続プールを作成してサーバ インスタンスに割り当てると、サーバがハングした。 例外は報告されなかった。

分析の結果、同期化の問題が判明したが、コードの修正により解決された。

CR095967

WebLogic Server SP03 および SP04 で、管理対象サーバと管理サーバを同時に停止したときに、管理対象サーバが管理サーバに再接続しようとした。

この問題は、停止モードまたはサスペンド モードにあるときに、管理対象サーバが管理サーバに再接続しないようにコードを変更することで解決した。

CR097152

WebLogic Server SP03 および SP04 で、管理サーバを再起動すると次のようなエラーが発生した。

Admin restart causes java.rmi.ConnectException: This RJVM has already been shutdown.

この問題は、次の手順を行うと常に発生する。

  1. 2 つ以上のマシン上にクラスタ インスタンスが配置されたクラスタをコンフィグレーションする。

  2. サンプルの EJB をデプロイしてクラスタに割り当てる。

  3. 管理サーバを再起動する。

  4. コンソールを表示して、クラスタから EJB の割り当てを解除し、適用する。次にその EJB をクラスタに再び割り当てて、変更を適用する。

この問題は、weblogic.management.internal.MBeanProxyAdminMBeanHome の古いスタブを使用していたことと、管理サーバが再起動されたときに AdminMBeanHome オブジェクト インスタンス (動的プロキシ スタブ) が有効ではなくなったために発生した。

この問題は、コードを修正することで解決した。

CR099973

WebLogic Server 6.1 サービス パック 3 で、license_update_file を指定して UpdateLicense ユーティリティを使用しても、ライセンス ファイルが正しく更新されなかった。 このため、サーバの起動時に次のような例外が発生した。

$$$$$$$$$$$$$$$$ License Exception $$$$$$$$$$$$$$$$

Unable to start WebLogic Server !!
WebLogic: license signature validation error!

この問題は、コードを修正することで解決した。

CR102593

WebLogic Server 6.1 SP04 で、ServletSessionRuntimeMBean を取得するときに ClassCastException が発生した。

この問題は 2 ノード クラスタで見受けられた。特定のユーザが 2 つのノードのいずれかに既にログオンしたかどうかを判別するために、アプリケーションは各クラスタ ノードの WebAppComponentRuntime から ServletSessionRuntimeMBean の配列を取得する。

呼び出し手順は次のとおり。

  1. 呼び出し : ノード 1 ---> test.jsp (HTTP セッションが作成される)

  2. 呼び出し : ノード 2 ---> test.jsp から (GET を介して) /ctrl/* サーブレットにデータを送信する

この呼び出し手順を同じ HTTP セッションで何度か繰り返すと、WebAppComponentRuntime.getServletSessions() メソッドで ClassCastException が発生する。

ClassCastException: java.lang.ClassCastException: $Proxy79 at weblogic.servlet.internal.session.SessionData.getServletSessionRuntimeMBean(SessionData.java:271) at weblogic.servlet.internal.session.SessionContext.getServletSessionRuntimeMBean(SessionContext.java:199) at weblogic.servlet.internal.session.SessionContext.getServletSessionRuntimeMBeans(SessionContext.java:216) at weblogic.servlet.internal.WebAppServletContext.getServletSessionRuntimeMBeans(WebAppServletContext.java:2442) at weblogic.servlet.internal.WebAppRuntimeMBeanImpl.getServletSessions(WebAppRuntimeMBeanImpl.java:126) at java.lang.reflect.Method.invoke(Native Method) at...

この問題は、ServletSessionRuntimeMBean が実装 (SessionData.javaServletSessionRuntimeMBeanImpl) に不適切にキャストされたために発生した。

この問題は、コードを修正することで解決した。

CR102860

このリリースでは JMX のメモリ リークを解決した。 このリークは WebLogic Server 6.1 SP02 で負荷テストの実行中に検出された。 JMX を数日間実行する場合、ガベージ コレクション後のヒープの消費量が 17MB から 40MB に増加した。

CR103735

WebLogic Server SP03 で、ドメインとドメイン内のクラスタが同じ名前である場合、ドメインの config.xml ファイルにある Targets 属性のエントリが重複する。 次のような状況が観察された。

アプリケーションをコンソールからクラスタに最初に割り当てたとき、問題は発生せず、対象は config.xml に正しく反映された。

管理サーバを再起動した後、Administration Console はアプリケーションがクラスタに割り当てられたことを表示せず、クラスタ内の管理対象サーバでは、アプリケーションが JNDI ツリーにバインドされたものとして示されなかった。 対象はそれでも config.xml に正しく反映されていた。

ユーザが Administration Console を使用してアプリケーションをクラスタに再び割り当てると、config.xml の Targets 属性にはクラスタ名が 2 回出現した。

<Application Deployed="true" Name="seb" Path=".¥config¥rom¥applications"> <WebAppComponent Name="seb" Targets="rom,rom" URI="seb.war"/> </Application>

どのバージョンの WebLogic Server でも、すべての対象ドメイン、クラスタ、サーバ、および仮想ホストはユニークな名前を持つ必要があるため、この問題が発生した。

この問題は、属性が対象である場合、解決する際に weblogic.managment.internal.UnresolvedMBean.java DomainMBean を無視するようにコードを修正することで解決された。

CR105338

WebLogic Server SP03 では、最大ファイル数に達すると、管理サーバと管理対象サーバの両方のロギングが停止される。

次のようなエラー メッセージがドメイン ログ ファイルに出力された後で、サーバのロギング サービスが停止する。

####<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 が新しいログ ファイルの誤ったインデックスを生成したときに、ログ ローテーションが失敗した。 最新のタイム スタンプを持つファイルが最新のインデックスを持つと見なされたためである。 そのインデックスを持つファイルが既に存在しているかどうかはチェックされていなかった。 WebLogic Server は、ログ ファイルが既に存在する場合はログ ファイルを削除しようとせず、rename() が成功したかどうかを確認しなかった。

また、時間に基づいたログ ローテーションの場合、マルチ CPU マシンでは、複数のローテーションが同じミリ秒内に発生した。 この問題はコードを修正することで変更された。

CR108448

WebLogic Server 6.1 SP05 で、管理対象サーバを再起動すると警告が発生した。 管理サーバと管理対象サーバが動作していて、管理対象サーバが停止した。 管理サーバは管理対象サーバが動作していないことを認識した。 管理対象サーバを再起動すると、次のような警告が発行された。

<Warning> <Management> <c4wlg001> <node001> <ExecuteThread: '1' for queue: '__weblogic_admin_rmi_queue'> <system> <> <141029> <Unable to reconnect to Admin Server running at http://c4wlg001:7001 from Managed Server - node001.> weblogic.management.configuration.ConfigurationException: Server: node001 is already running. at weblogic.management.Admin.registerManagedHome2AdminHome(Admin.java:1679) at weblogic.management.Admin.reconnectToAdminServer(Admin.java:1637) at weblogic.t3.srvr.ServerRuntime.reconnectToAdminServer(ServerRuntime.java:413) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.invokeLocally(DynamicMBeanImpl.java:636) at weblogic.management.internal.DynamicMBeanImpl.invoke(DynamicMBeanImpl.java:621) at...

管理対象サーバは正常に起動している。

分析の結果、不適切な時点でエラー チェックが実行されたために JNDI ツリーが適切に更新されないことがわかった。 この問題は、コードを修正することで解決した。

CR108727

WebLogic Server SP04 で、CR071109_610sp2.jar を実行し、次のコマンドライン オプションを指定して管理サーバを起動した。

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 スレッドが実行を停止したために、管理対象サーバが検出されなかったことがわかった。 この問題は、検出スレッドが必要なときに常に動作するように再試行ロジックを変更することで解決した。

CR127860

WebLogic Server 6.1 SP05 で、管理サーバが動作していないときに管理対象サーバで停止クラスが呼び出された。 次のような例外が送出された。

<29.10.2003 10:48:16 CET> <Notice> <WebLogicServer> <Started WebLogic Managed Server "managed1" for domain "mydomain" running in Production Mode>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <The disabling of server logins has been requested by system>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <Server logins have been disabled.>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <Server shutdown has been requested by system>
<29.10.2003 10:49:54 CET> <Alert> <WebLogicServer> <The shutdown sequence has been initiated.> <29.10.2003 10:49:56 CET> <Emergency> <Server> <Unable to initialize the server: 'Fatal initialization exception Throwable: weblogic.rmi.extensions.RemoteRuntimeException - with nested exception: [java.rmi.ConnectException: Could not establish a connection with 4622510611903127260S:172.23.64.209:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver, java.rmi.ConnectException: Destination unreachable; nested exception is: java.net.ConnectException: Connection refused: connect; No available router to destination] java.rmi.ConnectException: Could not establish a connection with 4622510611903127260S:172.23.64.209:[7001,7001,7002,7002,7001,7002,-1]:mydomain:myserver, 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:276)
at
weblogic.rjvm.RJVMImpl.getRequestStream(RJVMImpl.java:428)..

この問題は、管理レイヤを停止する前に停止クラスを実行するようにコードを変更することで修正された。

CR122538

WebLogic Server で JMX クライアント アプリケーションが getAllMBeans() を使用した場合、次のような例外が送出された。

Exception in thread "main" java.lang.ClassNotFoundException:
weblogic.management.descriptors.ejb11.MailServiceMBean
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:183)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:281)
at java.lang.ClassLoader.loadClass(ClassLoader.java:250)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:310)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:190)
at weblogic.management.internal.Helper.findClass(Helper.java:831)
[...]
--------------- nested within: ------------------
weblogic.management.configuration.ConfigurationError - with nested exception:
[java.lang.ClassNotFoundException:
weblogic.management.descriptors.ejb11.MailServiceMBean]
at
weblogic.management.internal.Helper.getAdminOrConfigMBeanInfo(Helper.java:118)
[...]

この問題は、コードを修正することで解決した。

プラグイン

変更要求番号

説明

CR087204

[Apache] WebLogic Server 6.1 SP03 で、PathTrimPathPrepend が URL の末尾に予期しない「/」を追加した。 元の URL に PathTrim が追加されて「/」になった後で、PathPrepend 変数に余分な「/」が付加された。

この問題は、コードを修正することで解決した。

CR091910

[Apache] WebLogic Server 6.1 SP03 で、Apache プラグインは、<IfModule mod_weblogic.c> の使用時に PathPrepend を読み込んでいなかった。 この問題は、Apache 1.3.x および Apache 2.0.43 用のプラグインで発生していた。

この問題は、コードを修正することで解決した。

CR092970

[Apache] WebLogic Server 6.1 SP04 で、Apache プラグインはソケットを CLOSE_WAIT 状態のままにした。 分析の結果、WebLogic Server は sendRedirect を返すときにソケットを閉じていないことがわかった。 この問題は、コードを修正することで解決した。

CR092327

[Apache] WebLogic Server 6.1 SP04 で、VirtualHosts が使用されるときに WLLogFile の設定が機能しなかった。 ログ ファイルのデフォルトは /tmp/wlproxy.log

CR100070、CR107200

[Apache] 2 つの仮想ホストが Apache サーバで使用される場合は、各仮想ホストが独自の WLLogFile を定義している。 このパラメータの値は、2 つの仮想ホストに定義された WLLogFile 値の間を切り替わり続ける。

2 つの問題があった。1 つは、WebLogic Server がサーバの起動時に 1 度だけ WLLogFile を設定していたことで、もう 1 つは WebLogic Server がそれを VirtualHost から取得する前に設定していたことである。

Apache プラグインで各仮想ホストの WLLogFile を設定することで問題は修正された。

CR100601、CR105658、CR108747

(NSAPI) WebLogic Server 6.1 サービス パック 3 に付属のプラグインは、WL-Proxy-Client-IP ヘッダを使用してクライアントの IP アドレスを送信していた。 このことは、さまざまな環境で問題を引き起こしていた。以前のサーバは、プラグインが X-Forwarded-For および Proxy-Client-IP ヘッダを使用してクライアントの IP アドレスを送信するものと想定していたからである。

WL-Proxy-Client-IP だけでなく X-Forwarded-For および Proxy-Client-IP の両ヘッダが含まれるようにコードが修正されたので、さまざまな環境で修正なしにクライアントのアドレスを取得できるようになった。

CR101937

(NSAPI) HTTP リクエストに expect-continue ヘッダが含まれている場合、プラグインのクライアントが HTTP/1.0 を使用した場合でも、プラグインは 100 (Continue) 応答を送信していた。 HTTP/1.1 仕様に準拠するようにコードを修正して、クライアントが HTTP/1.0 以前を使用している場合 (または、リクエストに expect-continue ヘッダがない場合)、プラグインが 100 (Continue) ステータスで応答しないようにした。

CR102616

(NSAPI、Apache) NSAPI プラグインで、DNS サーバから IP アドレスのリストが返され、プラグインが WebLogicHost = 'DNS name' でコンフィグレーションされている場合に、DNS 名の動的な DNS ルックアップがサポートされるようになった。

CR105123

(ISAPI) すべてのバージョンの WebLogic Server で、iisforward.dll が使用されている場合に DefaultFileName が機能しない。 問題は次の場合に発生した。

  • 仮想ディレクトリがコンフィグレーションされている。

  • MIME タイプが * (すべてをプロキシする) にコンフィグレーションされている。

  • iisproxy.iniDefaultFileName が追加されている。

ファイル名のない、ディレクトリに対するリクエストで、DefaultFileName が使用されない。 この問題は、コードを修正することで修正された。

CR105173

(WLS-NSAPI) WebLogic Server 6.1 SP04 で、クライアントへの応答の送信をクライアントが止めると (応答を完全に受信する前にブラウザを閉じるなど)、Web サーバのログに 500 [WRITE TOCLIENT ERROR] が記録される。

この動作は、Web サーバの状態モニタ ツールを使用してサーバの状態を判断するクライアントには受け入れることができない。この問題は通常、リクエストから応答までにかなり時間がかかる場合に発生する。

Web サーバの状態モニタ ツールは 500 エラーを使用して、サーバの状態に何らかの問題があることを示しているが、これはサーバの状態の問題ではなく、応答を終了したクライアントの問題であるため、500 エラーではないはずである。

リクエストと応答のパスは次のとおり。

クライアント -> proxyWebserver -> プラグイン -> wls

予期される応答のパスは次のとおり。

クライアント <- proxyWebserver <- プラグイン <- wls

ただし、WebLogic Server が応答を正常に送信したものの、Web サーバがその応答をクライアントに完全に送信しなかった場合に、クライアントが通信を中断すると、Web サーバの access.log には、通常はサーバに問題があることを示す 500 エラーが記録される。

そのような状況では、別のエラーが記録されるか、または何も記録されないというのがユーザの考えである。

クライアントが接続を中断した場合に 500 エラーが生成されないように、コードの変更を実装した。

CR106764

(NSAPI) プラグインのスレッドが長い期間クリティカル ロックを取得できたことで (デフォルトで 5 分、あるいは WLIOTimeoutSecs でコンフィグレーション)、他のすべてのスレッドがブロックされ、WebLogic Server がハングしているように見えていた。 この問題は、プラグインをコード修正して解決した。

CR107254

(Apache) Hewlett-Packard では HP Apache-based Web Server バージョン 1.3.x のサポートを停止したので、WebLogic Server は HP 用の Apache 1.3 プラグインを削除した。

CR108092

(ISAPI) WebLogic Server 6.1 サービス パック 4 で、ISAPI プラグインは、修正されたクッキーに遭遇したときに未処理の例外エラーを Windows のイベント ログに記録していた。 そのイベント テキストは次の行で始まっていた。

The HTTP Server encountered an unhandled exception while processing the ISAPI Application.

この問題は、ISAPI プラグインのコード修正で解決した。

CR109755

[Apache] ワイルドカード文字 (*/?) 以外の正規表現が含まれるコンフィグレーション パラメータをプラグインが無視していた。 このことが原因で、次のようなパラメータを使用した場合に 404 エラーが生じることがあった。

LocationMatch "/weblogic/(abc|def)/ghi"

この問題は、コードを修正することで解決した。

CR110664

(NSAPI) プラグイン コードが例外の捕捉に失敗し、代わりに、Windows プラットフォーム上の iPlanet サーバが sendResponse フェーズでクラッシュした。 例外を捕捉するようにプラグイン コードを変更した。

CR111167

(ISAPI) WebLogic Server 6.1 サービス パック 2 で、ISAPI プラグインを使用すると、HTTP 応答に 2 つの日付ヘッダ (WebLogic Server が挿入するヘッダと IIS が挿入するヘッダ) が含まれる。 日付ヘッダの重複が原因で、単一の日付ヘッダを想定している特定のキャッシング サービスで問題が発生した。

この問題は、WebLogic Server によって挿入される日付ヘッダを除外するように ISAPI プラグインを更新することで解決された。

CR113033

(ISAPI) WebLogic Server 6.1 サービス パック 4 で、プラグインは _wl_proxy フォルダの WLTempDir フラグを認識しなかった。 フラグを使用するようにコードを修正した。

CR113093

[Apache] 次のように、httpd.conf で複数の MatchExpression パラメータを使用して、さまざまな場所にリクエストをルーティングする場合、

MatchExpression *.jsp WebLogicHost=localhost|WebLogicPort=8001
MatchExpression *.html WebLogicCluster=localhost:8001,localhost:8003

各リクエストが同じグローバル パラメータ情報を上書きしたために、リクエストが誤った場所に送信された。 上の例では、この問題の結果 *.jsp リクエストがポート 8003 のサーバに送信された。

各リクエストがパラメータ情報の独自のコピーを使用するようにコードを修正した。

CR121341

(Apache) このサービス パックでは、URL 書き換えを行うプラグインを使用する場合にサービス拒否攻撃が起こるおそれのある問題が解決されている。 http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03_39.00.jsp のセキュリティ勧告 BEA03-39.00 を参照。

CR121688

(Apache) URL 内の感嘆符「!」が「%21」で置換されると、プラグインがクッキーの解析に失敗した。この置換は一般に、URL 書き換えを使用するときに WAP ゲートウェイによって行われる。 URL 内の文字を正しく解析するようにコードを修正した。

CR121943

[Apache] URL 内の「%1」が「%21」で置換された場合に、プラグインはクッキーを解析しなかった。 この置換は、WAP ゲートウェイと URL 書き換えを使用する場合に発生した。 この問題は、コードを修正することで解決した。

CR122207

(NSAPI) KeepAliveEnabledDynamicServerList の両方が有効である場合、プラグインはソケットを CLOSE_WAIT 状態のままにする可能性があった。 この問題は、コードを修正することで解決した。

CR122754

(ISAPI) WebLogic Server 6.1 サービス パック 4 で、MIME タイプで転送するときに、プラグイン パラメータ WLExludeByPathOrMimeType が機能しなかった。 この問題は、コードを修正することで解決した。

CR122755

(ISAPI) WebLogic Server 6.1 サービス パック 4 で、URL に「.wlforward」が手動で追加されると、プラグイン フィルタが無視された。 初期リクエストに .wlforward の MIME タイプがある場合は 404 エラーを送出するようにコードを変更した。

CR123120、CR123775

(Apache、NSAPI) プラグインを介して POST メソッドが使用され、Content-Length が定義されていなかった場合、プロキシ ログ ファイルには次のようなメッセージが含まれる。

POST and PUT requests *must* contain a Content-Length

Content-Length が定義されていない場合はコンテンツ長をゼロ (0) に設定するようにコードを変更した。

CR123925

(ISAPI) プラグインがブラウザに対して 500 エラー メッセージで応答する場合があった。 この問題にはさらに、以下の 3 つの兆候があった。

  1. IIS アクセス ログに次のメッセージが表示された。

    Out-of-process+ISAPI+extension+request+failed. 500 1726 99122 2003 84078

  2. Windows イベント ログはイベント 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.

  3. 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

この問題は、コードを修正することで解決した。

CR124433

(ISAPI) IIS が WlForwardPath=/ でコンフィグレーションされている場合、プラグインはサーバが停止している場合でも転送しようとした。 クライアントにエラー ページは表示されなかった。 この状況でパスを適切に除外するようにプラグインを修正した。

CR124464

(NSAPI) プラグインのクラッシュを引き起こす可能性のあるメモリ リークが検出された。 この問題は、オブジェクトが削除された後でプラグインが例外オブジェクトにアクセスしたために発生した。 例外オブジェクトから例外コードを取得した後でオブジェクトを削除し、メモリ リークが発生しなくなるようにコードを修正した。

CR125545

(NSAPI) クライアントへの応答の送信をクライアントが止めた場合 (応答が完了する前にブラウザを閉じるなど)、プラグインは Web サーバのログに 500 [WRITE TOCLIENT ERROR] を書き込んだ。 500 エラーを Web サーバの問題として解釈する状態モニタ ツールで問題が発生することがあった。

この問題は、コードを修正することで解決した。

CR125690

(ISAPI) 9 個の IIS サーバと 9 個のクラスタ化された WebLogic Server インスタンスを含むコンフィグレーションで、IIS が数時間おきにクラッシュし、イベント ログにイベント 37 が書き込まれた。 wlproxy ログにには次のメッセージが含まれていた。

Thu Oct 09 13:01:46 2003 *******Exception type [WRITE_ERROR_TO_CLIENT] raised at line 1269 of .¥iisproxy.cpp

診断の結果、初期バッファの増加中に Reader::fill() メソッドが十分なメモリを割り当てていなかったことがわかった。 バッファの最後をマークするための 4 バイトが失われており、そのためにコア ダンプが発生した。 この問題は、コードを修正することで解決した。

CR126103

(NSAPI) 負荷テスト中、HP11.00 上で動作する NSAPI が 2 つの Solaris マシン (それぞれに WebLogic Server インスタンスが 3 つずつ) 上の 6 ノード クラスタにプロキシする場合、メモリ消費量が徐々に増加して、約 50 分後に ns-httpd プロセスがクラッシュした。

HP11.00 または Solaris では同じ負荷テストはクラッシュしなかった。

分析の結果、proxy.cpp のコードがネイティブ システム呼び出しの strdup() を使用していることがわかった。 strdup() はシステム メモリをプログラムのヒープ領域に割り当てる。 WebLogic Server は Iplanet の FREE マクロを使用して、以前に割り当てられた領域を必要なくなった時点で解放する。 FREE は strdup() 呼び出しで割り当てられた領域を解放しないため、メモリ リークが発生した。

FREE マクロが解放する対象を認識するように、proxy.cpp 内のすべてのネイティブ strdup() システム呼び出しを Iplanet の STRDUP マクロで置き換えることで、この問題を解決した。

CR126568

(NSAPI) プラグインは POST リクエスト内の %0A を正常に処理しなかった。

末尾に %0A があり、NSAPI プラグインを介して WebLogic Server に送信される POST リクエストが正常に処理されなかった。 リクエストは本文のストリームに関係のないデータを追加し、ヘッダは本文の最後に出現した。 WebLogic Server に直接送信されたリクエストは正しく処理されて適切に機能する。 末尾の %0A を正常に処理できるプラグインが必要である。

HTTP/0.9 応答を正しく検出して処理するようにプラグインのコードを変更することで、この問題を解決した。

CR126982

(NSAPI) WLExcludePathOrMimeType が設定されている場合、そのファイル タイプは WebLogic Server へのリクエストから除外されるが、iplanet はそれらのファイルを代わりに処理できなかった。

たとえば、.jpg を含む .jsp に対して次のようなリクエストがあった。

<Object name="test5" ppath="*/weblogic/*"> Service fn="wl_proxy" WebLogicHost="lorna" WebLogicPort="7001" PathTrim="/weblogic" Debug="ALL" DebugConfigInfo="ON" WLExcludePathOrMimeType="*.jpg" </Object>

.jsp に対するリクエストは WebLogic Server にプロキシされて、.jsp は .jpg なしで表示された。 iplanet は jpg を処理できなかった。iplanet のアクセス ログには次のメッセージが含まれていた。

10.40.4.117 - - [28/Oct/2003:11:45:34 -0500] "GET /weblogic/images/logo_tm_onwt.jpg HTTP/1.1" 500 305 I get the following in wlproxy.log: Tue Oct 28 11:45:35 2003 ============================= new request =============================== Tue Oct 28 11:45:35 2003 INFO: SSL is not configured Tue Oct 28 11:45:35 2003 URI=[/hello.jsp] Tue Oct 28 11:45:35 2003 attempt #0 out of a max of 5 Tue Oct 28 11:45:35 2003 general list: trying connect to '10.40.4.117'/7001/7001 at line 1224 for '/hello.jsp' Tue Oct 28 11:45:35 2003 INFO: New NON-SSL URL Tue Oct 28 11:45:35 2003 Going to check the general server list Tue Oct 28 11:45:35 2003 WLS info : 10.40.4.117:7001 recycled? 0 Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept]=[*/*] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-language]=[en-us] Tue Oct 28 11:45:35 2003 Hdrs from Client:[accept-encoding]=[gzip, deflate] Tue Oct 28 11:45:35 2003 Hdrs from Client:[user-agent]=[Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0)]

WLExcludePathOrMimeType を指定した場合、WebLogic Server はリクエストを処理せず、Web サーバがリクエストの処理を続行できるように Web サーバに制御を渡すはずである。

この問題は、コードを修正することで解決した。

RMI

変更要求番号

説明

CR106281

WebLogic Server 6.1 SP04 で、大きな負荷がかかっているときにセッション Bean をレプリケートすると、ヒープ使用率が上がり、OutOfmemoryErrors が生じていた。

分析の結果、ガベージ コレクションが強制されても examples.ejb20.basic.statefulSession.TraderBean_5ysgq2_EOImpl オブジェクトがガベージ コレクションされないという事実が判明した。 クラスタ化されたステートフル セッション Bean では、プライマリ オブジェクト EOImpl の強い参照が weblogic.rmi.cluster.PrimarySecondaryRemoteObject に維持されていた。 Bean で remove は絶対呼び出されないので、EOImpl の参照が eoMap から削除されることはなかった。

session-timeout-seconds の後、パッシベーションされた Bean が削除されたときに EO をアンエクスポートするようにコードが修正された。

RMI/IIOP

変更要求番号

説明

CR112991

WebLogic Server 6.1 SP04 インスタンスから WebLogic Server 7.0 SP02 インスタンス上で動作する EJB へ IIOP 呼び出しを行うと、IIOP 接続がアイドル状態でタイム アウトしたときに例外が発生した。 例外は WebLogic Server 7.0 側で発生した。WebLogic Server 7.0 が応答を返送しようとすると、接続が閉じられた。 例外は 6.1 サーバには送信されず、クライアント スレッドがハングする。

WebLogic Server 7.0 SP02 の例外は次のとおり。

<Jul 29, 2003 5:21:55 PM PDT> <Error> <IIOP> <002013> <Complete failure to send exception class java.rmi.MarshalException: java.rmi.MarshalException: IOException while sending; nested exception is: java.io.IOException: Attempt to send message on closed socket. java.rmi.MarshalException: IOException while sending; nested exception is: java.io.IOException: Attempt to send message on closed socket java.io.IOException: Attempt to send message on closed socket at weblogic.iiop.MuxableSocketIIOP.send(MuxableSocketIIOP.java:362) at weblogic.iiop.EndPointImpl.send(EndPointImpl.java:1078) at weblogic.iiop.OutboundResponseImpl.sendThrowable(OutboundResponseImpl.java:194) at weblogic.rmi.internal.BasicServerRef.handleThrowable(BasicServerRef.java:473) at weblogic.rmi.internal.BasicServerRef.postInvoke(BasicServerRef.java:440) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:328) 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) >

分析の結果、接続を閉じたというメッセージが正しく処理されていないことがわかった。 このエラーは、コードを修正することで解決した。

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 を使用する場合は発生しなかった。 コードを修正してこの問題に対応した。

CR128594

このサービス パックより前では、WebLogic Server は AIX 上で Java オブジェクトを読み込むときに typecode を処理できなかった。 エイリアス ラッパーを破棄するようにコードを修正した。

CR128660

WebLogic Server は解釈できない着信コンテキストに対してリフレクションを使用した。 その結果、AIX 上の IIOP クライアントは失敗した。IBM ORB はサービス コンテキストに基づいてストリームの形式を想定するためである。 IIOP クライアントを AIX 上で使用できるように、サービス コンテキストを正しく処理するようにコードを修正した。

セキュリティ

変更要求番号

説明

CR067670

カスタム セキュリティ レルムを使用するように WebLogic Server をコンフィグレーションした場合、レルムが使用できないと、WebLogic Server は起動しなかった。 このサービス パックでは新しい起動コマンド -Dweblogic.security.RealmFailureOk=true を導入した。このコマンドを使用すると、レルムが使用できない場合にサーバが起動できる。 このコマンドの場合、サーバはコンフィグレーション済みのカスタム レルムではなくファイル レルムを使用して起動する。

このコマンドは WebLogic Server 6.x でのみ使用できるもので、他のバージョンのサーバには実装されていない。

警告: このコマンドを使用する場合、管理者は注意する必要がある。 カスタム レルムが (認証ではなく) 認可に対してのみコンフィグレーションされていて、ユーザ ストアがファイル レルムである場合、-Dweblogic.security.RealmFailureOk=true を指定してサーバを起動するとセキュリティで保護されない可能性がある。

このオプションは Administration Console にアクセスするときにのみ使用し、サーバが正常に起動できるようにカスタム レルムを再コンフィグレーションする。 -Dweblogic.security.RealmFailureOk=true を指定して起動したサーバにアプリケーションがアクセスしないようにすること。

CR093292

WebLogic Server サービス パック 5 に CR093292 パッチを適用すると、サーバは次のようなメッセージをログに記録し始めた。

java.io.IOException: Length is Zero
at weblogic.security.SSL.GenericCipher.input(GenericCipher.java:196)
at weblogic.security.SSL.SSLCiphertext.input(SSLCiphertext.java:68)
at weblogic.security.SSL.SSLSocket.getRecord(SSLSocket.java:1147)
[...]

これらのメッセージはデバッグに利用することのみを目的としていた。 メッセージがログに記録されないようにコードを修正した。

CR093813

ノード マネージャ キー ファイル内の暗号化されたプライベート キーへアクセスするためのパスワード weblogic.nodemanager.keyPassword が、プレーン テキストでアクセス可能になっていた。

この問題は、ノード マネージャ プロパティ ファイル nodemanager.properties を作成することで解決した。

CR100703

別のユーザがロック アウトされた後に、認証済みユーザが WebLogic Server 6.1 SP04 にアクセスできなくなる可能性があった。 この問題は Novell eDirectory で発生する可能性があった。 あるユーザが誤ったパスワードを何度も入力してロック アウトされた後に、他の認証済みユーザがサーバにアクセスできなくなり、次のような 500 エラーを受け取った。

<[WebAppServletContext(7814505,security,/security)] Servlet failed with Exception
netscape.ldap.LDAPException: error result (53); NDS error: login lockout
(-197);
DSA is unwilling to perform
[...]

この問題は、このような場合に送出される LDAPException を捕捉して、LDAP サーバへの接続を破棄することで修正された。

CR102452

クロスサイト スクリプティングの問題が解決された。 http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp のセキュリティ勧告 BEA03-36.01 を参照。

CR102712

HTTP トンネリングを使用したクライアントと比較すると、HTTPS トンネリングを使用して EJB にアクセスした Java クライアントはパフォーマンスが低下し、ソケットの使用率が増加した。 WebLogic Server はソケットを再利用しないでリクエストごとに新しいソケットを作成した。 この問題は、コードを修正することで解決した。

CR105443

クロスサイト スクリプティングの問題が解決された。 Security Advisory BEA03-36.00 を参照。

CR105513

このサービス パックには新しいプロパティ weblogic.security.SSL.trustManager がある。このプロパティを使用すると、HttpsURLConnection を使用して別のサーバに接続している場合に、カスタム トラスト マネージャを指定できる。 このプロパティを使用すると、ビジネス ロジックを目的として、SSL ハンドシェーク中に CA ルートを取得できる。

警告: この機能は WebLogic Server 6.1 のみで実装されており、WebLogic Server 7.x 以降のリリースでは使用できない。

CR108265

WebLogic Server 6.1 SP04 で、CachingRealm.refresh() が呼び出されると HTTP リクエストが失敗する場合があった。 このサーブレットはキャッシュとデータベースを同期させる。 クラスタは基本レルムとして RDBMS レルムを使用した。

Web アプリケーションの index.html を呼び出す HTTP リクエストの簡単な状態チェックが、次の例外により失敗する場合があった。

<Error> <HTTP> <hanptl02> <managedServer2> <ExecuteThread: '9' for queue: '__weblogic_admin_rmi_queue'> <> <> <101020> <[WebAppServletContext(1014083,healthcheck02,/healthcheck02)] T_[ubg粲 Exception 窿篝竢_”s箏竊箏篌_B> java.lang.NullPointerException: Start server side stack trace: java.lang.NullPointerException at weblogic.security.acl.GroupImpl.addMember(GroupImpl.java:46) at weblogic.security.acl.OwnerImpl.<init>(OwnerImpl.java:32) at weblogic.security.acl.AclImpl.<init>(AclImpl.java:164) at weblogic.servlet.security.internal.SecurityModule.auditPerm(SecurityModule.java:358)

分析の結果、2 つのスレッドが CachingRealm に同時にアクセスしていたことがわかった。たとえば、更新サーブレットがキャッシュをクリアする一方で、index.jsp へのリクエストはそのキャッシュからクリアされたユーザを見つけようとした。

この問題は、コードを修正することで解決した。

CR111041

Web アプリケーションが HTTPS 接続を確立しようとして、リモート サーバとのハンドシェークに時間がかかった場合に、WebLogic Server は関連付けられた SSL ソケットをタイム アウトしなかった。 実行スレッドは無期限に「スタック」状態になり、結局サーバがロックされた。 HTTPS 接続でタイムアウト値が強制されるようにコードを修正した。

CR112563

WebLogic Server はパスワードをファイルに格納するときにプライベート キー パスワードを暗号化しなかった。 パスワードをファイルに書き戻すときにパスワードが自動的に暗号化されるようにコードを修正した。 最初の起動時に、WebLogic Server はパスワードが暗号化されているかどうかを検証し、必要な場合はパスワードをファイル内で暗号化する。

WebLogic Server はドメインに関連付けられた暗号化サービスを使用する。 つまり、パスワード ファイルは、そのファイルが作成されたドメインでのみ使用できる。

注意: WebLogic Server がパスワードをファイルに書き込む前に、プライベート キー パスワードのプレーン テキストのコピーを保護すること。 このサービス パック レベルでは、サーバの起動後にファイルからプレーン テキストの パスワードを取得することはできない。

CR113459

WebLogic Server 6.1 SP05 で、CR093813_61sp5.jar において、ノード マネージャ プロパティ ファイルを削除すると問題が発生した。

ノード マネージャ プロパティ ファイルが、常に <saved logs dir>/NodeManagerInternal ディレクトリに作成されていた。 このユーザは NodeManagerInternal の内容を定期的にアーカイブして削除していた。 ノード マネージャ プロパティ ファイルが削除されるため、ノード マネージャ プロパティ ファイルに格納されている証明書パスワードが解読できず、ノード マネージャが正しく動作しなかった。

この問題は、ノード マネージャ プロパティ ファイルが NodeManagerInternal または user.dir に見つからない場合には、user.dir で指定したディレクトリに作成されるようにコードを修正することで解決した。

CR120850

WebLogic Server 6.1 SP05 で、weblogic.net.http.HttpsURLConnection は https.nonProxyHosts 環境変数を受け付けなかった。 問題は次のシナリオで発生した。

クライアント <--> プロキシ <---> サーバ

クライアントは WebLogic Server の内部で動作している場合も、スタンドアロンの Java プログラムの場合もある。リクエストは、対象のホストが https.nonProxyHosts で指定されている場合でも、常にプロキシ経由になった。 代わりに、ホストが http.nonProxyHosts で指定されている場合には、問題は発生しない。proxyHost ではなくホストへの直接接続が確立される。

分析の結果、proxyHost が定義されている場合でも、https.nonProxyHosts で指定されたホストへ直接接続するためのロジックが明らかになった。 この問題は https.nonProxyHosts でのみ発生し、http.nonProxyHosts の場合は発生しなかった。

proxyHost が定義されている場合でも、https.nonProxyHosts で指定されたホストへ直接接続するために、適切なロジックを開発した。

CR121206

WebLogic Server 6.1 SP05 で、外部 LDAP サーバを使用するときに、開いている LDAP 接続の数が増加し続けた。

この問題は、コードを修正することで解決した。

CR121920

WebLogic Server 6.1 サービス パック 3 で、WebLogic Server JSSE を使用して Socket.getSendBufferSize() を呼び出すと次のようなエラーが発生した。

java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketGetOption(Native Method)
at java.net.PlainSocketImpl.getOption(PlainSocketImpl.java:190)
at java.net.Socket.getSendBufferSize(Socket.java:527)
[...]

getSendBufferSize() を適切にオーバーライドして委託するようにコードを修正した。

CR121921

LDAPDelegate.groupContainsInternal() メソッドは、グループのリストに目的のグループが含まれているかどうかを最初にチェックしないで、リストの再帰的検索を実行した。 このパフォーマンスの問題は、groupContainsInternal() がまずグループ リストを検索して、目的のグループが含まれているかどうかを判別するように更新することで解決された。

サーブレット

変更要求番号

説明

CR080998

SP06 より前のバージョンの WebLogic Server 6.1 は、HTTP/1.1 仕様のセクション 14.35 に記載されている Range ヘッダ フィールドの定義をサポートしていなかった。 この問題は、コードを修正することで解決した。

CR084455

WebLogic Server 6.1 SP03 が、すべての HTTP リクエストを拡張フォーマットでログに記録するようにコンフィグレーションされている場合、ローテーション時に、ローテーションがスケジュールされてから約 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 値がないかどうかチェックするようにコードを変更することで、解決された。

CR086234

FileServletindexDirectories 機能はインターナショナライズされていなかったため、マルチバイトのファイル名を表示または使用できなかった。 この問題は、コードを修正することで解決した。

CR088785

HTTP アクセス ログで、cs-uri が指定されている場合、WebLogic Server は URI の基本部分とクエリ部分の両方ではなく、基本部分のみを記録していた。 この問題は、コードを修正することで解決した。

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)

この問題は、コードを修正することで解決した。

CR095945

Unix 上で動作する WebLogic Server 6.1 SP05 で、WAR 内の CGI スクリプトを実行するために抽出する CGIServlet が、現在の作業ディレクトリを設定しないでスクリプトを呼び出していた。

CGI スクリプトが WAR Web アプリケーションに含まれていてもサブスクリプトを呼び出せるように、現在の作業ディレクトリを設定するように修正を実装した。

CR095981

WebLogic Server 6.1 SP01、SP02、SP03、および SP04 で、precompile=true を指定して JSP ファイルをコンパイルする場合、weblogic.xml<charset-mapping> が無視されていた。

結果として、一部の 2 バイト文字セットが、<charset-mapping> で指定された文字のエンコーディングとコンパイル済みクラスで指定された文字のエンコーディングの不一致のために取り違えられていた。

分析の結果、プリコンパイラにエラーがあることが判明した。 この問題は、コードを修正することで解決した。

CR096459

HTTP 1.0 でサーブレットまたは JSP 内のフラッシュを呼び出すとソケットがうまく閉じない場合があり、ソケットがタイムアウトになるまでクライアントが待機する原因となっていた。 この問題は、コードを修正することで解決した。

CR100590

HttpClusterServlet 実装が更新されて、WebLogicCluster パラメータのデフォルトのポート番号が 443 に変更された。 更新後の実装は、WebLogicCluster パラメータが正しく指定されていない場合にエラーを報告しなかった。

HttpClusterServlet 実装が以前の以下の動作と一致するように、コードを修正した。

  • WebLogicCluster は SSL ポート番号の指定に host:port:sslport という形式を使用する。

  • WebLogic Server は、SSL ポートが指定されていない場合にエラーをログに記録し、デフォルト SSL ポートの 7002 を使用する。

CR100645

attributeReplaced() を介して受け取ったイベントに対して HttpSessionBindingEvent.getValue() を呼び出す場合、HttpSessionAttributeListener インタフェースを実装するオブジェクトが正しい値を受け取らなかった。 サーブレット 2.3 仕様に記載されているように古い属性値を返すのではなく、getValue() は新しい方の値を返した。 この問題は、コードを修正することで解決した。

CR101061

このサービス パックより前は、WebLogic Server インスタンスにパッチが適用されている場合、weblogic.version を呼び出すと、正しいバージョン情報が表示されなかった。 weblogic.version が正しいバージョンおよびパッチ情報を次の形式で表示するようにコードを変更した。

WebLogic Server version date build with patch [, patch] [...]

次に例を示す。

WebLogic Server 8.1 03/20/2003 246620 with CRXXXX, CRXXXX, CRXXXXX

CR101838

WebLogic Server SP04 で、CGIServlet の動作が変更されていたため、ファイル名に拡張子がない CGI スクリプトの実行に影響するおそれがあった。 たとえば、ファイル web.xml で CGI ディレクトリを定義し、サーブレット マッピングを次のようにしたとする。

<param-name>cgiDir</param-name>
<param-value>/home/user/cgi-bin</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>CGIServlet</servlet-name>
<url-pattern>/cgi-bin/*</url-pattern>
</servlet-mapping>

この場合、myscript というスクリプトを /home/user/cgi-bin ディレクトリに格納すると、http://localhost/mywebapp/cgi-bin/myscript のような URL は、スクリプト名を指定しないと /home/user/cgi-bin にマップされた (この問題は、myscript.ksh のように拡張子を付けたスクリプトでは発生しなかった)。

CGIServlet の動作が以前のリリースと一致するようにコードを修正した。 上記の例であれば、URL http://localhost/mywebapp/cgi-bin/myscript/home/user/cgi-bin/myscript にマップされるようになった。

CR102262

null の HTTP-Version フィールドを含む HTTP リクエストを解析した後で、WebLogic Server は次のような例外を送出した。

java.lang.NullPointerException
at
weblogic.servlet.internal.ServletRequestImpl.initInputEncoding(ServletRequestImpl.java:727)
at
weblogic.servlet.internal.ServletRequestImpl.mergePostParams(ServletRequestImpl.java:565)
at
weblogic.servlet.internal.ServletRequestImpl.parseQueryParams(ServletRequestImpl.java:489)
at
weblogic.servlet.internal.ServletRequestImpl.getParameter(ServletRequestImpl.java:686)
at
weblogic.servlet.internal.ServletRequestImpl.initSessionInfo(ServletRequestImpl.java:1481)
at
weblogic.servlet.internal.ServletRequestImpl.getSession(ServletRequestImpl.java:1345)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:1010)
at
weblogic.servlet.internal.ServletContextImpl.invokeServlet(ServletContextImpl.java:910)
at
weblogic.servlet.internal.ServletContextManager.invokeServlet(ServletContextManager.java:279)
at
weblogic.socket.MuxableSocketHTTP.invokeServlet(MuxableSocketHTTP.java:403)
at
weblogic.socket.MuxableSocketHTTP.execute(MuxableSocketHTTP.java:285)
at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:130)

リクエストで指定されていない場合はデフォルト バージョンとして HTTP/0.9 を使用するようにコードを修正した。

CR102574

サーブレットのクライアントを強制的に停止すると、WebLogic Server でメモリ使用率が上昇した。これは OutOfMemoryError になる可能性がある。 この問題は、コードを修正することで解決した。

CR102689

クロスサイト スクリプティングの潜在的な脆弱性に対応するため、生成後のエラー ページを調べて修正した。 クロスサイト スクリプティングの問題の詳細については、http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/SA_BEA03_36.00.jsp のセキュリティ勧告 BEA03-36.01 を参照。

CR102769

拡張ログ フォーマットを使用して HTTP トランザクションをログに記録する場合、WebLogic Server は、あるサーブレットまたは JSP から別のサーブレットまたは JSP へ送信されたリクエストのクエリ パラメータ (cs-uri-query) を記録しなかった。 また、WebLogic Server はクライアントの元のリクエスト URI ではなく、転送されたリクエストの URI (cs-uri-stem) を記録した。

転送される HTTP トランザクションをログに記録する場合、元のリクエストの URI とクエリ文字列を access.log に記録するようにコードを修正した。

CR103059

<servlet-mapping> 要素の 1 文字の <url-pattern> 値は、web.xml デプロイメント記述子で適切に処理されていなかった。 たとえば、<url-pattern>*.f</url-pattern> では welcome.f にアクセスしようとしたときに 404 File Not Found エラーが生成されたが、<url-pattern>*.oop</url-pattern>welcome.oop にアクセスしようとしたときに適切に機能していた。

この問題は既に解決されており、1 文字の <url-patterns> は適切に機能するようになっている。

CR103256

コードを変更したことで、JDBC のJDBCSessionContext および JDBCSessionData 内のバブル キャッシュに関係するパフォーマンスが向上した。

CR103289

HttpClusterServlet は POST データのセッション ID を正しく解析していなかった。

HttpClusterServlet を介してリクエストをクラスタに送信し、セッションを確立してから、クッキーがなく、POST パラメータにセッション ID のある 2 番目のリクエストを送信すると、サーブレットはセッションを認識しなかった。

サーブレットは POST データからセッション ID 抽出できるようになった。

CR103339

サーブレットの出力において、Transfer-Encode の値が「Chunked」と大文字になっていた。HTTP/1.1 仕様では小文字で「chunked」とする必要がある。 コードを修正したことで、Transfer-Encode タイプが小文字で「chunked」と出力されるようになった。

CR103925

setAttribute メソッドは、hashCode の同一性のみをチェックしていた。 現在は、equals メソッドの結果で古いオブジェクトと新しいオブジェクトをチェックするようにもなった。

CR104975

ログ ローテーションが失敗すると、WebLogic Server はログ ファイルを再び開けなかった。 この場合、ログ ファイルをフラッシュするトリガが java.io.IOException: Bad file descriptor を送出する可能性があった。 この問題は、コードを修正することで解決した。

CR105016

HttpClusterServlet はクラスタ内の WebLogic Server がハングした場合に障害の回数を増やすことができなかった。 そのため、クラスタ内の各サーバが HungServerRecoverSeconds よりも長い時間スリープするか、クラスタ内の 3 つのサーバのうち 2 つが HungServerRecoverSeconds より長くスリープした場合、HttpClusterServlet は無限ループに陥った。 障害の回数が適切にインクリメントされるようにコードを修正した。

CR105339

サービス パック 5 で、WebLogic Server は TagExtraInfo クラスを使用したタグ呼び出しの変数定義を作成しなかった。 (サービス パック 4 以前と同様に) 変数定義が作成されるようにコードを修正した。

CR106186

サーブレットでバッファ サイズをゼロに設定すると、サーブレットは応答に失敗し、サーバで無限ループを開始した。 WebLogic Server は最後に次のような警告を表示した。

"Suspend Checker Thread" prio=10 tid=0x23eb90 nid=0xfec runnable
<May 14, 2003 10:53:34 AM PDT> <Warning> <WebLogicServer> <000337>
<ExecuteThread: '10' for queue: 'default' has been busy for "1,181" seconds working on the request "Http Request: servlet_uri", which is more than the configured time (StuckThreadMaxTime) of "600" seconds.>

この問題は、コードを修正することで解決した。

CR107419

JSP コードでパラメータの値として 2 バイト文字を設定すると問題が発生していた。たとえば、次のようなコードでは、

<jsp:include page="included.jsp">
<jsp:param name="title"
value="<%= java.net.URLEncoder.encode(¥"[double byte characters]¥")
%>"/>
</jsp:include>

2 バイト文字が URL エンコーディングされたコードに変換されていた。 この問題は修正された。

CR108607

アプリケーションが XSL で FOP 出力メソッドを使用してアーカイブ ファイルから画像を取得すると、WebLogic Server がエラーを生成していた。 この問題は、展開形式でデプロイされたアプリケーションでは発生していなかった。 この問題は、コードを修正することで解決した。

CR108350

Administration Console は、フォーマットを共通ログ フォーマット (CLF) と拡張ログ フォーマット (ELF) の間で動的に変更できると不適切に表示した。実際には、そのような変更の場合にはサーバの再起動が必要である。 このコンフィグレーション パラメータを変更するときはサーバの再起動が必要であることを正しく表示するように、コードを変更した。

CR109958

プロキシ サーブレットを使用してリクエストを処理する場合に、WebLogic Server は HTTPS を使用する受信リクエストでのみ SecureProxy 設定を尊重していた。 受信リクエストが HTTP を使用する場合、プロキシ サーブレットで SecureProxy が有効になっていても WebLogic Server は HTTPS 接続を使用しなかった。 この問題は、コードを修正することで解決した。

CR110798

JSP で weblogic.servlet.security.ServletAuthentication.killCookie(req) を呼び出すと、セッションはクリーンアップされずに WebLogic Server に保持された。 killCookie(req) が完了する直前にセッションが無効になるようにコードを修正した。

CR110914

TrackingEnabled が false に設定されていると要求ごとに新しいセッションが作成されるが、それらのセッションが無効にされていなかった。

コードを修正したことで、TrackingEnabled が false に設定されているとセッションが即座に無効になるようになった。 これが正しい動作である。

CR111752

特定の状況では、 useByteStream パラメータが true に設定されている状態で CGIServlet を使用するときに WebLogic Server は NullPointerException を送出していた。 この問題は、1 つのフレームに静的 URL リンクが含まれ、別のフレームで CGIServlet が使用されているフレームセットの使用時に発生していた。 もう一方のフレームがページのダウンロードを完了する前に静的リンクの含まれているフレームをユーザが選択すると、IO 例外が捕捉され、次のように表示されていた。

java.lang.NullPointerException
at
weblogic.utils.Executable$Drainer.run(Executable.java:366)

この問題は、コードを修正することで解決した。

CR112799

IOException が発生した後にも、WebLogic Server が出力ストリームに書き込みをしようとしていた。 このため、IOException を処理しない Web アプリケーションで予期せぬソケットの切断が発生すると、CPU 使用率が 100% になるおそれがあった。

org.apache.xml.serialize.XMLSerializer は、そのプロセスが終了するまで IOException を無視する。 このため、HTTP 応答の一部として XML ドキュメントを返している最中に IOException が送出されると、この問題が発生していた。

コードを修正したことで、IOException が発生した後は WebLogic Server が出力ストリームへの書き込みを停止するようになった。

CR120440

シングル サインオン コンフィグレーションに複数の Web アプリケーションがデプロイされていて、あるアプリケーションが weblogic.servlet.security.ServletAuthentication.invalidateAll(request) を呼び出した場合、他のアプリケーションの HttpSessionListeners は、セッション タイムアウトが発生するまで呼び出されなかった。 これは、最初の Web アプリケーションに関連付けられたセッションのみが無効化の対象として登録されていたために発生した。ユーザが認証された後、以降のセッションは登録されなかった。

すべての Web アプリケーションのセッション ID とコンテキスト パスの両方を、invalidateAll(request) の必要に応じて無効化の対象として登録するように、コードを修正した。

CR122177

サービス パック 3 の CR060023 の修正が原因で、FileServlet は、ファイルが見つからない場合に応答コード 404 ではなく 200 を返した。 ファイルが見つからない場合に 404 を返すようにコードを修正した。

CR121846

WebLogic Server サービス パック 3 で、サーバは、拡張ログ フォーマット ヘッダを書き込む前に、標準のログ エントリをログ ファイルに書き込むことはできなかった。 この状況は、ログ ローテーション中に、複数のスレッドが同時に新しいログ ファイルに書き込もうとする場合に発生する可能性があった。

ログ ローテーションを処理するスレッドが、ログ ヘッダが書き込まれるまで、新しいログ ファイルへ排他的にアクセスするようにコードを修正した。

CR125718

WebLogic Server サービス パック 5 は、Apache および Netegrity の SiteMinder と一緒に使用すると、NullPointerException を送出する可能性があった。 Apache から SiteMinder に転送されて、SiteMinder によって認証された最初のリクエストは、WebLogic Server でも正常に認証される。 ただし、ユーザがブラウザの [戻る] ボタンを使用してログイン ページに戻り、別のユーザ名とパスワードを使用して再度認証を受けると、WebLogic Server は NullPointerException を送出する。

java.lang.NullPointerException
at
weblogic.servlet.security.internal.SecurityModule.logoutSession(SecurityModule.java:386)
at
weblogic.servlet.security.internal.SecurityModule.checkAuthenticate(SecurityModule.java:292)
at
weblogic.servlet.security.ServletAuthentication.weak(ServletAuthentication.java:353)
at com.uprr.security.weblogic.SiteMinderAuthFilter.doPreAuth(Unknown
Source)
at weblogic.servlet.security.AuthFilter.service(AuthFilter.java:51)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:262)
at
weblogic.servlet.internal.ServletStubImpl.invokeServlet(ServletStubImpl.java:198)
at
weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:530)
at
weblogic.servlet.internal.RequestDispatcherImpl.include(RequestDispatcherImpl.java:350)
at
weblogic.servlet.security.internal.ServletSecurityManager.checkAccess
(ServletSecurityManager.java:144)
[...]

この問題は、コードを修正することで解決した。

SNMP

変更要求番号

説明

CR088000

WebLogic Server 6.1 SP04 で、SNMP 停止トラップが受信されなかった。

8-Oct-02 15:57:24 FAILURE mytest!0[41]!oam/systest/snmp/oam_snmp!2[69]!if!3[86]!weblogic.qa.tests.oam.systest.snmp.trap.SNMPTrapTest.testServerShutdownTrap() wlsServerShutdownTrap wasn't received. PARAMETERS: managedServerName = oamserver1 adminServerName = adminServer

分析の結果、リスン アドレスまたはリスン ポートがコマンドライン オプションでオーバーライドされている場合、SNMP トラップが管理対象サーバに対して生成されないことがわかった。

この問題は、URL のリスン ポート値ではなく ServerMBean のリスン ポート値を使用するようにロジックを変更することで解決された。

Web サービス

変更要求番号

説明

CR099255

双方向 SSL を使用して Web サービスを呼び出す場合に、クライアント コードが Web サービスの WSDL を呼び出しで使用するとき、クライアント API は、WSDL のルックアップを行うときと、操作を呼び出すときの両方で証明書を正しく送信するようになった。 以前は、証明書は WSDL ルックアップでのみ送信され、操作を実際に呼び出すときには送信されなかった。

この問題は、コードを修正することで解決した。

CR099534

wsgen Ant タスクを最適化して、1 つの build.xml ファイルからアセンブルする Web サービスごとに、新しいクラス ローダを使用するようにした。

以前は、build.xml ファイルに複数の Web サービスが示されている場合でも、wsgen は実行全体で 1 つのクラスローダを使用していた。また、以降の各 Web サービスのすべての補助クラスは、1 つのクラスローダから取得した後にコピーされており、それが必要なすべてのクラス ファイルを生成する次善の方法だった。 build.xml ファイルに示された、アセンブルの必要がある Web サービスの数によっては、wsgen を完全に実行するのに 30 分以上かかることがあった。

この問題は、コードを修正することで解決した。

CR101383

WebLogic Web サービスは、SOAP 応答で null の xsd:dateTime 値を xsi:nil='true' と正しく表現するようになった。

以前は、WebLogic Web サービスが null の xsd:dateTime 値を返す場合、SOAP 応答では xsi:null='1' と不適切に表現されていた。これは 1999 年に策定された XML スキーマでの null 値の定義である。 WebLogic Web サービスは 2001 年に勧告された XML スキーマをサポートしており、null 値は xsi:nil='true' と定義されている。

この問題は、コードを修正することで解決した。

CR102677

外部エンティティの解決に XML レジストリを使用する場合、WebLogic Server はパブリック ID を使用して DTD を解決するときにエラーを返さなくなった。

この問題は、コードを修正することで解決した。

CR106892

生成された WebLogic Web サービス クライアント スタブは、XML ドキュメントを org.w3c.dom.Element オブジェクトとして Web サービスに送信するときに、XML ファイルの要素の本文にある改行文字を正しく保持するようになった。 以前、クライアント スタブはこれらの改行文字を誤ってスペースに変換していた。

この問題は、コードを修正することで解決した。

CR111151

WebLogic Web サービスは、Web サービスの呼び出しで例外の結果として生成される SOAP Fault 応答で、utf-8 エンコーディング ヘッダを正しく送信するようになった。 完全な正しいヘッダは次のようになる。

<?xml version="1.0" encoding="utf-8"?>

以前、WebLogic Web サービスはこのヘッダを SOAP Fault 応答に含めていなかった。

この問題は、コードを修正することで解決した。

WTC-ATMI

変更要求番号

説明

CR107323

Tuxedo 8.1 を使用するようにコンフィグレーションされた WebLogic Server 6.1 SP03 では、コミットされていない Tuxedo トランザクションがあるときに WebLogic Server が異常終了 (〔CTRL〕+〔C〕) すると、再起動時に WebLogic Server インスタンスがハングした。 問題は次のシナリオで発生した。

  1. Tuxedo でまだコミットされていないトランザクションがあるときに WebLogic が強制終了した。

  2. WTC は「ON_DEMAND」で起動するようにコンフィグレーションされている。

  3. WebLogic を起動する。

  4. WebLogic は報告された問題によりハングする。

問題は次の場合には発生しなかった。

  1. Tuxedo でまだコミットされていないトランザクションがあるときに WebLogic が強制終了した。

  2. WTC は「ON_DEMAND」で起動するようにコンフィグレーションされている。

  3. WebLogic の tlog ファイル「*.tlog」を削除する。

  4. WebLogic を起動する。

  5. WebLogic は問題なく起動する。

または

  1. Tuxedo でまだコミットされていないトランザクションがあるときに WebLogic が強制終了した。

  2. WTC は「ON_STARTUP」で起動するようにコンフィグレーションされている。

  3. WebLogic を起動する。

  4. WebLogic は問題なく起動する。

再起動後にハングが起きる場合、デフォルト グループ内のすべてのスレッドは以下のスタック トレースによりハングする。

at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:415)
at weblogic.wtc.jatmi.TuxXidRply.get_specific_reply (TuxXidRply.java:203)at weblogic.wtc.gwt.TuxedoXA.internalCommit(TuxedoXA.java:259)
at weblogic.wtc.gwt.TuxedoXA.commit(TuxedoXA.java:328)
at weblogic.wtc.gwt.OatmialCommitter.execute(WTCStartup.java:2767)at...

この問題は、weblogic.wtc.gwt.WTCStartup メソッドが各 Kernel.execute(myCommitter) の後に 1 秒間スリープするように修正することで解決された。

CR120681

WebLogic Server 6.1 SP02 で、WebLogic Tuxedo Connector はローカル リソース名をリモート サービス名に正しく変換していなかった。

トランザクションの修正で問題は解決された。

XML

変更要求番号

説明

CR102397

Xerces パーサが常に System.getProperty() を呼び出そうとしていた。 このため、プロパティを取得するパーミッションのないアプレット内で例外が送出されていた。 JMS を呼び出したアプレット内で、次のような例外が送出された。

----------- Linked Exception -----------
java.rmi.MarshalException: failed to marshal
connectionCreate(Lweblogic.jms.dispatcher.DispatcherWrapper;); nested
exception is:
java.rmi.UnexpectedException: Failed to parse descriptor file; nested
exception is:
java.security.AccessControlException: access denied
(java.util.PropertyPermission weblogic.apache.xerces.maxentityrefs read)
[...]

コードを修正したことで、パーサがアプレット クライアントを使用してシステム プロパティを読み込むことはなくなった。

 


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

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

クラスタ

変更要求番号

説明

CR082443

同じマルチキャスト アドレスを使用する複数のクラスタが存在する環境では、大きなログ ファイルが作成され、ファイルのロールオーバが過度に頻繁に発生していた。

デバッグ メッセージは次のようなものであった。

####<Jul 23, 2002 4:06:26 PM EDT> <Debug> <Cluster> <ustrntda01> <wts-cluster_test> <ExecuteThread: '9' for queue: 'default'> <> <> <000000> <dropped fragment from foreign domain/cluster domainhash=95475927 clusterhash=-1674453961>

この問題は、weblogic.cluster.ClusterDebug.java において、デバッグ メッセージをログに記録するか否かを制御するフラグが true に設定されていたために発生していた。コードを修正し、この問題を解決した。

CR087240

セッションをホストする管理対象サーバをシャットダウンすると、HTTP セッションのフェイルオーバで ClassCastException が発生していた。エラー メッセージを無視すると、フェイルオーバは成功した。

この問題は、次のコンフィグレーションにおいて確実に再現した。

1) 6.1 SP02 を実行するクラスタ化された 2 つのサーバ インスタンス

2) WLP 4.0 SP002 ポータル アプリケーションをホストするクラスタ

3) 2 ノードのクラスタを指す WebLogic Server プラグインを含む IPlanet Web サーバ

他のコンフィグレーションでは、この問題が再現しない場合があった。

この問題は、WebLogic Server のシャットダウン シーケンスの問題と関係がある。

RMIServerService をシャットダウンするための新しいサービスにより、この問題を解決した。

CR092146

クラスタのステートフル セッション Bean に対してフェイルオーバが機能しなかった。リクエスト URL に、クラスタの DNS 名ではなくローカル サーバの名前が含まれていた。

次の例外が発生した。

java.rmi.NoSuchObjectException: Unable to locate EJBHome: 'statefullCluster' on server: 't3://172.23.135.83:7600 at weblogic.ejb20.internal.HomeHandleImpl.getEJBHome(HomeHandleImpl.java:80) at weblogic.ejb20.internal.HandleImpl.getEJBObject(HandleImpl.java:204) at com.bea.cluster.testClusterEJBServlet.doGet(testClusterEJBServlet.java:137) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) 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)

weblogic.ejb20.internal.BaseEJBHome.javagetURL() メソッドを修正し、URL のホスト部分としてクラスタ アドレスを渡すことで、この問題を解決した。

CR093809

セッションのルックアップに関するエラーが原因で、スタック トレースが発生した。セカンダリ サーバ インスタンスが、シャットダウンしていた。処理しているリクエストに対するログ エントリを作成する際に、HTTP サーバはセッションからユーザの情報を取得しようとする。そのため、シャットダウン中であってもセカンダリ サーバに対するルックアップを試み、結果として次のスタック トレースが発生した。

<Dec 26, 2002 7:17:55 PM EST> <Error> <HTTP Session> <Error looking up session for id:2LcR6Ool2IC5qNtFZhThJClYVYEXt9KWG2ciXmAXZ4XiBAHPiHx4!-1379505194!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 からユーザ情報を取得するようになった。

CR94561

WebLogic Server 6.1 SP02 では、アプリケーションがインメモリ セッション レプリケーションまたはレプリケートされたステートフル セッション Bean を使うと、2 人のユーザの間でセッション データを共有できてしまうという、潜在的なセキュリティの弱点が発見された。この障害の原因は、競合状況の結果として 2 つのセッションに同じ ROID (レプリカ可能オブジェクト ID と呼ばれる内部 ID) が割り当てられるためであった。たとえば、セッション A に ROID が割り当てられた後、セッション B に同じ ROID が割り当てられる。すると、それ以降のセッション B のリクエストはすべて、A の HTTP セッション/SFSB にマップされる。HTTP セッションが混じり合うと、セッション B のユーザがセッション A のコンテンツを見ることができた。この問題が発生する可能性は非常に低く、意図的に利用することはできなかった。

ROID.create() の同期を取るようにコードを修正し、重複する ROID が複数のセッションに割り当てられないようにすることで、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-26.01.jsp の「SECURITY ADVISORY (BEA03-26.01)」を参照すること。

CR101609

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>

コードを修正し、この問題を解決した。シリアライズ不可能なオブジェクトに遭遇すると、メソッドは他のセカンダリを試みずに返る。

CR102655

CR101609 と同じ。前記を参照。

コネクタ

変更要求番号

説明

CR086251

WebLogic Server 6.1 SP03 では、シャットダウンの間に unregisterResource においてメッセージング ブリッジ アダプタが NullPointerException を送出した。この問題は、メッセージが送信されたが、消費される前にサーバのシャットダウンが開始された場合に発生した。メッセージング ブリッジがデプロイされていず、アダプタがデプロイされている場合には、問題は発生しなかった。

コンフィグレーションは、jms-xa-adp.rar メッセージング ブリッジ アダプタと、MQSeries 5.2 と JMS の間のメッセージング ブリッジであった。

登録解除を試みる前に wrappedXARes をチェックするようにコードを修正することで、この問題を解決した。

CR090002

WebLogic Server 6.1 SP03 では、JCA-Connection.closeResourceException ではなく java.lang.reflect.UndeclaredThrowableException を送出した。

リソース アダプタの本来の例外を渡すように、コードを修正した。

CR090792

WebLogic Server 6.1 SP03 と SP04 では、Console で RAR の記述子パラメータのいずれかを変更すると、RAR のデプロイメントが失敗した。

分析の結果、プール パラメータがデフォルト値から変更されていない場合、Console で記述子を変更すると、プール パラメータがリセットされることがわかった。プール パラメータの定義が不適切であった。

<pool-params>

<initial-capacity>0</initial-capacity>

<max-capacity>0</max-capacity>

<capacity-increment>0</capacity-increment>

<shrinking-enabled>false</shrinking-enabled>

<shrink-period-minutes>0</shrink-period-minutes>

</pool-params>

この結果、最大容量が 0 という許されない値になるためデプロイメントが失敗した。その後は、RA に対していかなる処理も実行できなかった。

6.1 では、記述子の値を取得するときは ResourceAdapterComponentMBean が使用される。しかし、ResourceAdapterComponentMBean のコンストラクタはデフォルトを自動的には設定せず (ConnectorComponentMBean が行っている方法)、デフォルトを手動でも設定していなかった。手動で設定するようにして、問題を解決した。

コンソール

変更要求番号

説明

CR062102

6.1 SP01 から大きなアプリケーション (40 MB) を移行すると、起動時にアプリケーションを管理対象サーバにコピーするため、ネットワークが過負荷になり、WebLogic Server の起動が遅くなった。

コードを修正し、この問題を解決した。変更されていないアプリケーションは、起動時に管理対象サーバにコピーされなくなった。

変更の有無にかかわらず起動時にアプリケーションを管理対象サーバにコピーするには、forceApplicationCopy パラメータを使用する。 アプリケーションを強制的に更新するための新しいパラメータを参照すること。

CR069284

ドメインの [コンフィグレーション|アプリケーション] ページの [自動デプロイを有効化] 属性がオフになっていても、アプリケーション ファイルがアプリケーション ディレクトリにコピーされると、アプリケーションのコンポーネントがまだ自動的にデプロイされた。

調査の結果、WebLogic Server が [自動デプロイを有効化] 属性を使用していないことがわかった。代わりに、自動デプロイメントは DomainMBean.setProductionModeEnabled プロパティによって制御されている。このプロパティは、起動時にコマンドラインで設定する。

Administration Console から AutoDeployedEnabled 属性を削除した。

CR084607

WebLogic Server 6.1 SP03 では、実行時にクラスタで JMS トピックを作成すると、InstanceNotFoundException が発生した。トピックは、クラスタ内の管理対象サーバを対象として、起動クラスの JMSHelper.createPermanentTopicAsync で作成されていた。トピックが作成された後、Administration Console で JMS サーバに対する送り先リンクをクリックすると、次のようなメッセージが表示された。

java.lang.reflect.UndeclaredThrowableException: javax.management.InstanceNotFoundException: mydomain:Name=testTopic12,Type=JMSTopic at com.sun.management.jmx.MBeanServerImpl.getMBean(MBeanServerImpl.java:1680) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.java:1152) at weblogic.management.internal.MBeanProxy.getAttribute(MBeanProxy.java:254) at weblogic.management.internal.MBeanProxy.invoke(MBeanProxy.java:187)

CR088842

WebLogic Server 6.1 SP02 では、1 つの管理サーバと 3 つの管理対象サーバというコンフィグレーションにおいて、管理対象サーバの 1 つを再起動するとデッドロックが発生した。

分析の結果、管理対象サーバの lookupServerRuntime() が、管理サーバに対する不要な getMBean() の呼び出しを行っていた。

コードを修正し、この問題を解決した。

CR089747

Solaris Sparc 2.8 上の WebLogic Server 6.1 SP03 において、ドメイン ログ ファイルが時間でローテーションされなかった。Windows 2000 では、ログ ファイルが 3 つ作成された後、ローテーションが停止していた。古いログ ファイルを削除すると、ローテーションが再開した。Windows 2000 の場合、SP01 から SP03 へのアップグレードの後ではログ ローテーションが機能したが、SP03 を新規インストールすると機能しなかった。ドメイン ログのコンフィグレーションは、次のとおりであった。

<Log FileName="config/mydomain/logs/wl-domain.log" FileTimeSpan="1" Name="mydomain" RotationType="byTime" RotationTime=10:00/>

コードを修正し、この問題を解決した。

CR091359

WebLogic Server 6.1 SP03 および SP04 では、.ear ファイル内の Web アプリケーションに対して、Administration Console のオプション [Web アプリケーション|webapp1|モニタ|すべてのアクティブな Web アプリケーションのモニタ...] が機能しなかった。

コードを修正し、この問題を解決した。

CR093409

WebLogic Server 6.1 SP02、Solaris 2.8、JDK1.3.1_04 という環境では、1 つの管理サーバと 5 つの管理対象サーバというコンフィグレーションにした場合、異なるマシンから weblogic.deploy ユーティリティを使って、3 つの EJB コンポーネントを含む EAR をデプロイしようとすると、管理サーバがハングした。スレッド ダンプはデッドロックを示していた。スタック トレースは次のような内容であった。

Execute thread 4(admin_rmi queue) holds lock of the com.sun.management.jmx.MBeanServerImpl and waiting to acquire lock on weblogic.logging.LogManager. Execute thread 8(default queue) holds lock of the weblogic.logging.LogManager and waiting to acquire lock on com.sun.management.jmx.MBeanServerImpl.

分析の結果、LogManagerFileStreamLogger でデッドロックが発生していた。

コードを修正し、この問題を解決した。

CR096726

WebLogic Server 6.1 SP02 では、MBeanHome.deleteMBean() を呼び出すと Null ポインタ例外が発生した。

コンフィグレーションは、4 つの管理対象サーバがそれぞれ異なる物理マシン上で稼働し、それぞれに対して JMX クライアントが動作する (1 対 1 で) というものであった。JMX クライアントが MBeanHome.deleteMBean を行うと、NullPointerException が発生した。

分析の結果、複数の管理対象サーバの非同期削除に関する問題であった。ある管理対象サーバが、MBean 自体を削除する前に他の MBean における参照を削除し、別の管理対象サーバが同時に同じことを行うと、Null ポインタ例外 (NPE) が発生した。

MBean に対するメタデータを取得するコード (つまり mbean.getMBeanInfo()) に対して try/except ブロックを実装することで、この問題を解決した。MBean を削除するときは、最初に MBeanServer にある現在の MBean のリストを取得した後、削除する Bean に対する参照を削除する。問題は、他の削除スレッドが同じことを行おうとして (静的な) リストから Bean を削除することがあり、そのような場合は、更新するために Bean のメタデータを取得しようとすると、NPE が発生する。このパッチでは、NPE を無視し、リストにある次の Bean を移るようにした。

CR096950

FileDistributionServletdoGet() メソッドを使うと、管理サーバ上のファイルをダウンロードできた。コードを修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-28.jsp の「SECURITY ADVISORY (BEA03-28.00)」を参照すること。

CR098623

<beahome>\wlportal4.0\applications\portal などのポータル アプリケーションを EAR ファイルとしてデプロイすると、Administration Console で application-config.xml のパラメータを変更できなかった。コードを修正し、この問題を解決した。

CR098739

WebLogic Server 6.1 SP02 では、管理サーバにおいて Java のデッドロックが検出された。スレッド ダンプには、次のような Java レベルのデッドロックが示されていた。つまり、スレッド 8 が RemoteMBeanServerImpl をロックし、さらに LogManager をロックしようとしたが、LogManager はスレッド 6 がロックしており、スレッド 6 は RemoteMBeanServerImpl を待っていた。

「ExecuteThread: '8' for queue: '__weblogic_admin_rmi_queue'」に対する Java スタック:

at weblogic.logging.LogManager.addSubsystem(LogManager.java:
58) - waiting to lock <f55b6358> (a weblogic.logging.Log
Manager) at weblogic.logging.LogOutputStream.getLogManager
(LogOutputStream.java:32) at weblogic.logging.LogOutput
Stream.error(LogOutputStream.java:63) at weblogic.management.
internal.Helper.error(Helper.java:1391) at weblogic.
management.internal.Helper.error(Helper.java:1404) at weblogic.management.internal.ConfigurationMBeanImpl.
postDeregister(ConfigurationMBeanImpl.java:900) at com.sun.
management.jmx.MBeanServerImpl.postDeregisterInvoker
(MBeanServerImpl.java:2314) at com.sun.management.jmx.MBean
ServerImpl.unregisterMBean(MBeanServerImpl.java:967) - locked <f550eec8> (a weblogic.management.internal.RemoteMBean
ServerImpl) at weblogic.management.internal.RemoteMBeanServer
Impl.unregisterMBean(RemoteMBeanServerImpl.java:213) at ..

「ExecuteThread: '6' for queue: 'default'」に対する Java スタック:

at com.sun.management.jmx.MBeanServerImpl.getMBean(MBean
ServerImpl.java:1672) at com.sun.management.jmx.MBeanServer
Impl.getAttribute(MBeanServerImpl.java:1150) at weblogic.
management.internal.MBeanProxy.getAttribute(MBeanProxy.java:254) at weblogic.management.internal.MBeanProxy.invoke
(MBeanProxy.java:187) at $Proxy7.isStdoutEnabled(Unknown Source) at weblogic.logging.ConsoleLogger.isLog(Console
Logger.java:81) at weblogic.logging.ConsoleLogger.log
(ConsoleLogger.java:70) at weblogic.logging.LogManager.log(Log
Manager.java:260) - locked <f55b6358> (a weblogic.logging.LogManager) at weblogic.logging.MessageLogger.log(MessageLogger.java:17) at weblogic.t3.srvr.T3SrvrLogger.logRemovingClientContextSoftDisconnect(T3SrvrLogger.java:1204) at weblogic.t3.srvr.ClientContext.dieIfTimedOut(ClientContext.java:512) at ...

LogManager における不必要なロックを削除するようコードを修正することで、この問題を解決した。

コア

変更要求番号

説明

CR036602

ClusterMBean.setClusterAddress() メソッドが不正な値を受け入れて、IllegalArgumentException を送出していなかった。

サーバ起動時にクラスタ アドレスが正しいことをチェックするようにして、この問題を解決した。

CR036603

ClusterMBean.setMultiCustAddress() メソッドが不正な値を受け入れて、IllegalArgumentException を送出していなかった。

コードを修正し、この問題を解決した。

CR077170

WebLogic Server 6.1 SP03 では、管理サーバをシャットダウンした後で管理対象サーバを停止すると、例外が発生した。この問題は、以下のアクションのシーケンスで発生した。

  1. 管理サーバと管理対象サーバを起動する。

  2. 管理サーバをシャットダウンする。

  3. 管理対象サーバの 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 からのシャットダウン コマンドは成功していた。

管理サーバが停止しているときに管理対象サーバをシャットダウンすると発生する例外を捕捉することで、この問題を解決した。

CR079354

WebLogic Server 6.1 SP02 では、Apache プラグインを通して DataSource にアクセスする Java クライアントが、TunnelDeadResponse を受け取っていた。

WebLogic Server は、Windows 2000 の下で稼働し、パッチ CR061847 を適用していた。プラグインは、Solaris の下で動作していた。

例外は、次のようなものであった。

<May 31, 2002 4:16:35 PM PDT> <Error> <HTTPClientJVMConnection> <java.net.ProtocolException: Tunneling result not OK, result: 'DEAD', id: '2' at weblogic.rjvm.http.HTTPClientJVMConnection.receiveAndDispatch (HTTPClientJVMConnection.java:413) at weblogic.rjvm.http.HTTPClientJVMConnection.execute (HTTPClientJVMConnection.java:296) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)>

プラグインを削除すると、例外は発生しなかった。

分析の結果、ホスト/ポートの組み合わせに対する RJVM が存在しているにもかかわらず、WebLogic Server がそれを発見できなかった。rjvm マネージャのシノニム キャッシュが、ポートの情報を保持していなかった。WebLogic Server は、ブートストラップのときキャッシュ内に一致するものが見つからないと、新しい RJVM を作成した。

ブートストラップの後、WebLogic Server は新しい RJVM が重複していることを識別し、それを閉じようとした。メッセージがキューに格納されている場合、サーバにメッセージが送付されないことがあった。その結果、サーバは RJVM でタイムアウトし、DEAD 応答を送信していた。

シノニム キャッシュがポート情報を保持するようコードを修正することで、この問題を解決した。

CR089470

WebLogic Server 6.1 SP03 では、クライアント ソケットが接続を開いて閉じると、ノード マネージャが NumberFormatException を送出した。

<Oct 28, 2002 3:38:18 PM CST> <Info> <NodeManager@localhost:5555>

<SecureSocketListener: listening on localhost:5555>

java.lang.NumberFormatException: null

at java.lang.Integer.parseInt(Integer.java:382)

at java.lang.Integer.parseInt(Integer.java:463)

at

weblogic.nodemanager.SocketInputHandler.run(SocketInputHandler.java:109)

認識できる副次的影響はなかった。エラーが発生した後でも、ノード マネージャは管理対象サーバを起動および停止できた。

データ転送を行わないで接続を開いて閉じるソケットにおいて例外を処理するよう、コードの修正を実装した。

CR070887

WebLogic Server 6.1 に SP02 を適用してもしなくても、setInstanceFollowRedirects() が機能しなかった。

JDK1.3.1 では、java.net.HttpURLConnection にメソッド getInstanceFollowRedirects()setInstanceFollowRedirects() が追加された。

これらのメソッドを使うと、特定の HttpURLConnection に対する URL のリダイレクトを無効にすることができる。HttpURLConnection が、setInstanceFollowRedirects() で設定されたフラグを無視していた。

InstanceFollowRedirects の設定に従ってリダイレクトを処理するように HttpURLConnection のリダイレクト ロジックのコードを修正することで、この問題を解決した。

CR077108

35 以上のノードで構成されるクラスタの負荷テストの際に、weblogic.utils.collections.NumericValueHashtable.
containsKey(NumericValueHashtable.java:138)
で null ポインタ例外が発生した。

<May 9, 2002 5:08:22 PM BST> <Error> <Management> <InvocationTargetException getting attribute SecondaryDistributionNames on MBean bluemartini:Location
=WebConnectaw01,Name=WebConnectaw01,ServerRuntime=WebConnectaw01,Type=ClusterRuntime. Method: public java.lang.String[] weblogic.cluster.ClusterRuntime.getSecondaryDistributionNames() java.lang.NullPointerException at weblogic.utils.
collections.NumericValueHashtable.containsKey(NumericValueHashtable.java:138) at weblogic.cluster.replication.
ReplicationManager.getSecondaryDistributionNames(ReplicationManager.java:1245) at weblogic.cluster.ClusterRuntime.

getSecondaryDistributionNames(ClusterRuntime.java:100) at java.lang.reflect.Method.invoke(Native Method) at weblogic.management.internal.DynamicMBeanImpl.getAttribute(DynamicMBeanImpl.java:511) at weblogic.management.internal.
DynamicMBeanImpl.getAttribute(DynamicMBeanImpl.java:477) at com.sun.management.jmx.MBeanServerImpl.getAttribute(MBeanServerImpl.java:1181) at com.sun.management.jmx.MBeanServer
Impl.getAttribute(MBeanServerImpl.java:1151) at weblogic.management.internal.RemoteMBeanServerImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServer
Ref.invoke(BasicServerRef.java:298) at weblogic.rmi.
internal.BasicServerRef.handleRequest(BasicServerRef.java:267) at weblogic.rmi.internal.BasicExecuteRequest.execute
(BasicExecuteRequest.java:22) at weblogic.kernel.Execute
Thread.execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)

分析の結果、getSecondaryDistributedNames() メソッドは getOtherHost() から返る null 値に備えなければならないことがわかった。この問題を解決した。

CR079354

SP02 とパッチ CR061847 を適用した WebLogic Server 6.1 では、Java Swing クライアントがコンテキストを取得して JDBC データ ソースにアクセスすると、TunnelDeadResponse を受け取った。クライアントは、初期コンテキストを取得し、データソースを通して接続を取得し、初期コンテキストを閉じて、接続を閉じる。その後は、この処理シーケンスを繰り返す。このエラーは、以下のような結果になる。

サーバでは、次のような例外が送出された。

####<Nov 21, 2002 12:24:20 PM CST> <Debug> <HTTPServerJVMConnection> <hpwlinc03> <admin> <ExecuteThread: '14' for queue: 'default'> <> <> <000000> <Closing JVM socket: 'weblogic.rjvm.http.HTTPServerJVMConnection@4cfbd8 - id: '0', closed: 'true', lastRecv: '1037903025816''> java.lang.
Throwable: Stack trace at weblogic.rjvm.http.HTTPServer
JVMConnection.close(HTTPServerJVMConnection.java:383) at weblogic.rjvm.ConnectionManager.removeConnection(ConnectionManager.java:879) at weblogic.rjvm.ConnectionManager.
shutdown(ConnectionManager.java:508) at weblogic.rjvm.
ConnectionManagerServer.shutdown(ConnectionManagerServer.java:443) at weblogic.rjvm.RJVMImpl.peerGone(RJVMImpl.java:804) at weblogic.rjvm.RJVMImpl.gotExceptionReceiving
(RJVMImpl.java:533) at weblogic.rjvm.ConnectionManager.got
ExceptionReceiving(ConnectionManager.java:736) at weblogic.rjvm.http.HTTPServerJVMConnection.checkIsDead(HTTPServerJVMConnection.java:238) at weblogic.rjvm.http.HTTPServer
JVMConnection$TunnelScavenger.trigger(HTTPServerJVMConnection.java:405) at weblogic.time.common.internal.
ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.
execute(ScheduledTrigger.java:229) at weblogic.kernel.Execute
Thread.execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)

クライアントでは、次のような例外が送出された。

<Nov 21, 2002 12:24:18 PM CST> <Error> <HTTPClientJVM
Connection> < java.net.Protocol Exception: Tunneling
result not OK, result: 'DEAD', id: '0' at weblogic.rjvm.
http.HTTPClientJVMConnection.receiveAndDispatch(HTTPCli entJVMConnection.java:413) at weblogic.rjvm.http.HTTPClient
JVMConnection.execute(HTTPClientJVMConne ction.java:296) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.
java:120)

分析の結果、ホスト/ポートの組み合わせに対する RJVM が存在するにもかかわらず、WLS が RJVM の検索に失敗してタイムアウトが発生していることがわかった。RJVM の同義語キャッシュが、ポートの情報を保持していなかった。RJVM の同義語キャッシュにポート情報を保持するようにコードを修正することで、問題を解決した。

CR080822

パフォーマンス パックを適用した Solaris 配布キットでは、ログ メッセージで表示されるファイル記述子ソフト リミットの値が正しくなかった。ファイル記述子ハード リミットの値が、ソフト リミットとハード リミットの両方に示されていた。

次に示すのは、weblogic.log に記録されるエラーである。

####<Mar 5, 2002 5:07:27 PM PST> <Info> <Posix Performance Pack> <bolinas> <myserver> <ListenThread> <system> <> <000000> <System has file descriptor limits of- soft: '1024', hard: '1024'>

####<Mar 5, 2002 5:07:27 PM PST> <Info> <Posix Performance Pack> <bolinas> <myserver> <ListenThread> <system> <> <000000> <Using effective file descriptor limit of: '1024' open sockets/files.>

このエラーは、Solaris 2.6 および Solaris 2.8 で発生した。

関連するスクリプト テンプレートの構文を修正することで、この問題を解決した。

正しくない構文:

[ !$? -a "$maxfiles" != 1024 ];

修正後の正しい構文:

[ ! $? -a "$maxfiles" != 1024 ];

CR085259

同じドメインでホストされる 2 つの独立した WebLogic クラスタがセッション クッキーに対して同じ名前を使用すると、クラスタ間でセッション データが複製されていた。

セカンダリ ホスト/ポートがセッションのプライマリ ホストと同じクラスタ内にあるかどうかの検査を実装することで、この問題を解決した。

CR086425

CR085259 と同じ。前記参照。

CR086758

多層型の実装では、負荷テストを 10 時間続けると、Web 層がハングした。Web 層 (サーブレット、JSP、およびカスタム キャッシュを実装するカスタム クラスで構成される) が EJB 層 (すべてステートレス セッション Bean) と通信している最中に、RJVM ハートビートが消えたために EJB 層が Connection Manager をクローズすると、この問題が発生した。

Web 層がハングする前に、EJB 層で次の例外が送出された。

<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 weblogic.rjvm.ConnectionManager.createHeartbeatMsg(ConnectionManager.java:1306) at weblogic.rjvm.ConnectionManager.sendHeartbeatMsg(ConnectionManager.java:497) at weblogic.rjvm.RJVMImpl$HeartbeatChecker.trigger(RJVMImpl.java:1032) at weblogic.time.common.internal.ScheduledTrigger.executeLocally(ScheduledTrigger.java:238) at weblogic.time.common.internal.ScheduledTrigger.execute(ScheduledTrigger.java:229) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

保留中の応答にピア消失イベントを通知するロジックを追加することで、この問題を解決した。

CR087808

Sunblade 100 シングル CUP Solaris マシンで稼働する WebLogic Server 6.1 SP03 では、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 は閉じたものとしてマークされていた。

重複する接続が検出され、CMD_REQUEST_CLOSE がサーバに到着していない場合は、RJVM をシャットダウンしないようにコードを修正し、この問題を解決した。

CR087944

Windows XP で稼働すると、「java.lang.UnsatisfiedLinkError: no muxer in java.library.path」のエラーが発生した。

原因は、WebLogic Server がホスト オペレーティング システムとして Windows XP を正しく通知しなかったためである。JDK 1.3.1_03 では、os.name は「Windows 2000」を返す。

SocketMuxer のメソッドを修正することで、この問題を解決した。

CR088022

ノード マネージャで管理対象サーバを起動した後、Administration Console の左ペインでサーバ名を右クリックして [接続を見る] を選択しても、管理サーバと管理対象サーバの間の通信に関する情報 (使用されているネットワーク チャンネルや JVMID など) が表示されなかった。

分析の結果、ConnectionManagerServer のバグが元で、ServerRuntimeMBeangetConnections() メソッドが接続オブジェクトのインスタンスを返していないことがわかった。

RJVM が null である接続についても接続マネージャが報告するようコードを修正することで、問題を解決した。

CR088056

WebLogic Server の muxer (マルチプレクサ) ライブラリにビルド日時の情報がないため、使用されているライブラリのバージョンを特定するのが困難であった。NTSocketMuxer にはビルド日時が含まれていたが、PosixSocketMuxer には含まれていなかった。

PosixSocketMuxer にビルド日時を追加することで、この問題を解決した。muxer の初期化時に、次のようなメッセージが表示されるようになった。

<Oct 15, 2002 3:44:04 PM PDT> <Info> <socket> <000406> <PosixSocketMuxer was built on Oct 15 2002 15:05:11>

CR089060

OS/390 Linux (SuSE Linux Kernel 2.2) では、libmuxer.so が次のエラーを送出した。

java.lang.UnsatisfiedLinkError: /opt/weblogic6/lib/linux/s390/libmuxer.so: /opt/weblogic6/lib/linux/s390/libmuxer.so: ELF file machine architecture not s390 at java.lang.ClassLoader$NativeLibrary.
load(Native Method) at java.lang.ClassLoader.loadLibrary0
(ClassLoader.java:1799)

Linux Kernel 2.2 用のバイナリを提供することで、この問題を解決した。

CR089144

jar にカスタム呼び出しルータが含まれている EJB のデプロイメントが、IllegalArgumentException で失敗した。ReplicaAwareInfo クラスの classForName() メソッドが現在のスレッドの ContextClassLoader ではなくシステム クラスローダでクラスを探していたため、クラスがロードされなかった。

スタック トレース:

java.lang.reflect.InvocationTargetException: java.lang.
IllegalArgumentException: Class weblogic.qa.tests.cluster.
ejb.callrouter.BaseCallRouterImpl not found at weblogic.rmi.
cluster.ReplicaAwareInfo.classForName(ReplicaAwareInfo.java:172) at weblogic.rmi.cluster.ReplicaAwareInfo.getCallRouter
(ReplicaAwareInfo.java:132) at weblogic.rmi.cluster.Basic
ReplicaHandler.newReplicaList(BasicReplicaHandler.java:78) at weblogic.rmi.cluster.BasicReplicaHandler.<init>(Basic
ReplicaHandler.java:72) at java.lang.reflect.Constructor.
newInstance(Native Method) at weblogic.rmi.cluster.Replica
AwareInfo.instantiate(ReplicaAwareInfo.java:186) at weblogic.rmi.cluster.ReplicaAwareInfo.getReplicaHandler(ReplicaAwareInfo.java:117) at weblogic.rmi.cluster.ReplicaAware
RemoteRef.initialize(ReplicaAwareRemoteRef.java:79) at weblogic.rmi.cluster.ClusterableRemoteRef.initialize(ClusterableRemoteRef.java:28) at weblogic.rmi.cluster.Clusterable
RemoteObject.initializeRef(ClusterableRemoteObject.java:275) at weblogic.rmi.cluster.ClusterableRemoteObject.onBind
(ClusterableRemoteObject.java:150) at weblogic.jndi.
internal.BasicNamingNode.bindHere(BasicNamingNode.java:346) at weblogic.jndi.internal.ServerNamingNode.bindHere(Server
NamingNode.java:105) at weblogic.jndi.internal.BasicNaming
Node.bind(BasicNamingNode.java:281) at ...

ClientDrivenBeanInfoImpldeploy() を呼び出すときはコンテキスト クラスローダをアプリケーション クラスローダに設定し、呼び出しルータ クラスをロードすることをコンテキスト クラスローダでチェックすることで、この問題を解決した。

CR089454

実行キューの最大長をコンフィグレーションすることで受信するリクエストのトラフィックを抑制する新しい機能が追加された。実行キューの最大長は、weblogic.kernel.allowQueueThrottling の新しい -D フラグで設定できる。

この機能は、カスタム キューにおいて「低速で移動し、リソースを大量に使用する」リクエストを抑制できるように設けられた。このキュー スロットリング機能は、カスタム アプリケーション キューに対してだけサポートされており、デフォルト キューまたは WebLogic Server の内部キューに対してはサポートされていない。

コンフィグレーションされているキューの長さを超えると、Kernel.execute() の呼び出しの結果として、クライアントは回復可能なリモート例外と、503 番の応答を受け取る。

CR090071

PosixSocketMuxer.cleanup() でアサーション失敗エラーが大量に発生すると共に、CLOSE_WAIT 状態のソケットの数が増え続けた。最終的に ulimit に達し、サーバ インスタンスの再起動が必要であった。

クリーンアップにおいてアサーション エラーを送出する前に fdr.sock が null かどうかをチェックするロジックを実装することで、この問題を解決した。

CR090341

logListenFailed() を呼び出した t3.srvr.ListenThread で、誤った障害時間が表示されていた。IOException が原因でサーバがリスンに失敗したときに生成されるメッセージの値に誤りがあった。メッセージの例を次に示す。

<Jun 11, 2002 2:37:33 PM PDT> <Critical> <WebLogicServer> <Failed to listen on port 7772, failure count: 3, failing for 1,023,831,450 seconds, java.net.SocketException: File table overflow>

t3.srvr.ListenThread にあった綴りの間違いを修正することで、この問題を解決した。

CR090823

e2e サンプルで、JSP の不要な再コンパイルが行われていた。b2c および b2b のサンプルを実行すると、e2e ドメインの JSP が必ず再コンパイルされた。ただし、これらの JSP のタイム スタンプは、正しく元に戻されていた。

原因は JspStub.getClassLoader メソッドのバグであった。バグを修正して問題を解決した。

CR091420

WebLogic Server 6.1 SP04 は、Unix Machine に対して [Post-Bind UID を有効化] オプションが指定されていると起動に失敗した。この属性は、Administration Console の [マシン] ノードでコンフィグレーションできる。この属性の目的は、UNIX マシンを実行するサーバ インスタンスが特権付きのすべての起動アクションを実行した後にその下で稼働する、Unix UID を返すことである。

コードを修正し、この問題を解決した。

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 を使用するスレッド ダンプが可能になった。

CR093416

Controller サーブレットがデプロイされていると、管理対象サーバが EmptyStackException を送出した。

Controller サーブレットのデプロイ中に、管理対象サーバが次のエラーを送出した。

[WebAppServletContext(35527,btn,/btn)] Servlet failed with Exception> java.util.EmptyStackException at weblogic.utils.
collections.Stack.pop()Ljava.lang.Object;(Unknown Source) at weblogic.kernel.ResettableThreadLocalStack.pop()Ljava.lang.Object;(Unknown Source) at weblogic.jndi.internal.
ThreadEnvironment.pop()Lweblogic.jndi.Environment;(Unknown Source) at weblogic.jndi.internal.WLContextImpl.close()V
(Unknown Source) at weblogic.jndi.factories.java.ReadOnly
ContextWrapper.close()V(Unknown Source) at be.btn.util.
JndiUtil.getEnv(Ljava.lang.String;)Ljava.lang.Object;(Unknown Source) at be.btn.web.HttpControllerServlet.init()V(Unknown Source) at javax.servlet.GenericServlet.init(Ljavax.servlet.
ServletConfig;)V(Unknown Source) at weblogic.servlet.
internal.ServletStubImpl.createServlet()Ljavax.servlet.Serv let;(Unknown Source) at weblogic.servlet.internal.
ServletStubImpl.createInstances()V(Unknown Source) at...

問題は btn.utils.JndiUtils.getEnv() メソッドに関係しており、ルックアップで取得したコンテキスト java:com/env を閉じていたため、javaURLContextFactory が環境をプッシュしていなかった。

この問題を解決した。

CR094101

WebLogic Server 6.1 SP02 と WebLogic Server 7.0 SP01 の相互運用に問題があった。WebLogic Server 6.1 の MDB が、WebLogic Server 7.0 の EJB を呼び出していた。EJB はタイムアウトすると weblogic.transaction.TimedOutException を送出していたが、この例外は WebLogic Server 7.0 で新しく追加されたものであり、WebLogic Server 6.1 では利用できなかった。WebLogic Server 6.1 の MDB の onMessage() メソッドが例外をキャッチし、Exception.printStackTrace() のコードを実行するときに ClassNotFoundException を送出していた。

weblogic.transaction.TimedOutException クラスを追加し、WebLogic Server 7.0 サーバと相互運用する際に ClassNotFoundException が発生しないようにすることで、この問題を解決した。

CR094724

WebLogic Server 6.1 SP03 以降では、HP-UX での WebLogic Server ネイティブ ライブラリが、aCC ではなく、cfront を使ってコンパイルされていた。aCC は、1998 年から cfront の代わりに使われるようになった ANSI C コンパイラである。

その結果、互換性のないランタイム ライブラリがロードされていた (cfront のコンパイルでは libC.2、また aCC でコンパイルされた SUN の Java では libCsup.2)。互換性のないランタイム ライブラリを使用するとクラッシュする場合がある。

HP-UX 11 に対しては aCC を使用するように WebLogic Server のビルドを変更することで、この問題を解決した。

CR095267

CR094561」と同じ。

CR095487

CR087808」と同じ。

CR095949

WebLogic Server 6.1 SP04 では、起動クラスの FailureIsFatal オプションを true に設定してあっても、起動クラスで障害が発生したときに、意図したように WebLogic Server がシャットダウンしなかった。

StartupClassRunner は、アプリケーションがデプロイされる前と後に呼び出される。分析の結果、アプリケーションがデプロイされる前に起動クラスで障害が発生し、起動クラスに failureIsFatal が設定された場合、fatalException が失われていた。

fatalException が失われず、サーバ インスタンスが正しくシャットダウンされるようにコードを修正することで、この問題を解決した。

CR096114

CR092933」に関する変更 (Sun JDK の 1.3.1_x バージョンでスレッド ダンプのリダイレクションを有効にするというもの) が、stdio のハンドルが無効であったために、NT サービスでは機能しなかった。

beasvcstdio のハンドルを作成するようにコードを変更することで、この問題を解決した。

CR101322

クライアントが、RMI の発信呼び出しを行うカスタム レルムを使用していた。これは、リーダー スレッドの RJVM レイヤ内の BootServicesImpl.invoke() から発生した。このような呼び出しが多く行われると、リーダー スレッドは発信呼び出しをブロックされて、応答を読み取るためのスレッドが残らなかった。

BootServices を RMI レイヤに移動し、デフォルトの実行キューにディスパッチできるようにすることで、この問題を解決した。

CR102021

WebLogic Server 6.1 SP04 では、負荷テストにおいて、PosixMuxer が以下の例外を送出した。

<Nov 21, 2002 9:38:29 AM EST> <Error> <socket> <000421> <Uncaught Throwable in processSockets java.io.IOException: unexpected exception in poll: (4) Interrupted system call java.io.IOException: unexpected exception in poll: (4) Interrupted system call at weblogic.socket.PosixSocketMuxer.poll(Native Method) at ...

中断した場合はポーリングを再び開始するようコードを修正し、この問題を解決した。

CR102058

クライアントでのリモート メソッド呼び出しで URLClassLoader を使用すると、NoClassDefFoundError が発生した。

c:¥java¥java131_07¥bin¥java -classpath “.;client.jar;C:¥home¥ravia¥weblogic¥dev¥src700¥3rdparty¥weblogicaux.jar” URLTest qa146 9901 ejb20-statefulSession- TraderHome installadministrator installadministrator java.lang.NoClassDefFoundError: weblogic/rmi/extensions/server/Stub at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:488) at...

分析の結果、AugmentableSystemClassLoader を作成するときに、それを常に SystemClassLoader に設定していることがわかった。このため、クライアントがシステム クラスローダを使用し、NoClassDefFoundError が発生した。

AugmentableSystemClassLoader に対する親として ThreadContextClassLoader を設定することで、この問題を解決した。

デプロイメント

変更要求番号

説明

CR089031

cr058358_61sp2.jar を適用した 6.1 SP02 を SP03 にアップグレードすると、管理対象サーバにおけるデプロイメントのパフォーマンスが低下していた。管理サーバでは低下しなかった。

CR058358 に対して実装された weblogic.j2ee.Component.getModuleMBean() メソッドに関して問題があった。ApplicationDescriptorMBean は管理サーバだけに登録されているので、管理対象サーバがこの MBean を要求すると、必ず管理サーバに対する RMI 呼び出しが行われる。

管理対象サーバにローカル キャッシュの MBean (ApplicaitonDescriptorMBeanImpl_Cached) を作成することで、この問題を解決した。メソッドに対する最初のリクエストは管理サーバに送られて、取得された情報はローカルに保存される。それ以降のリクエストはローカルに処理され、アプリケーションがアンデプロイされるとキャッシュは無効になる。

CR089765

Windows 2000 で weblogic.refresh を実行して、Linux 上で稼働する WebLogic Server の管理サーバおよび管理対象サーバに対するファイル (JSP または HTML) を更新すると、java.util.zip.ZipException が発生した。

この ZIP 例外が発生するのは、WebLogic Server が管理サーバまたは管理対象サーバとしてコンフィグレーションされていて、weblogic.refresh を実行する Web アプリケーションの対象が管理対象サーバになっている場合である。

管理対象サーバが更新されたファイルを管理サーバから取得しようとすると、両方のサーバ インスタンスが例外を送出する。

次のコンフィグレーションで発生した。

  • Linux (Redhat、JDK1.3.1) 上の WebLogic Server 6.1 SP03 (管理サーバが 1 つ、管理対象サーバが 1 つ)

  • Windows 2000 で weblogic.refresh を呼び出す (WebLogic Server 6.1 SP3、JDK1.3.1)

問題を診断した結果、管理対象サーバが管理サーバに対して示す更新されたファイルの位置のパスにエラーがあることがわかった。FileDistributionServlet.doGetMultipleJspRefreshRequest を修正することで問題を解決した。

CR091897

WebLogic Server 6.1 SP04 では、ab.wari.war のような短い名前の Web アプリケーションのデプロイメントが失敗した。次のエラーが発生した。

java.lang.IllegalArgumentException: Prefix string too short at java.io.File.createTempFile(File.java:1232 at weblogic.j2ee.Component.retrieveComponent(Component.java:296 at weblogic.j2ee.Component.<init>(Component.java:188)at weblogic.j2ee.WebAppComponent.<init>(WebAppComponent.java:45at weblogic.j2ee.Application.addComponent(Application.java:149)at weblogic.j2ee.J2EEService.addDeployment(J2EEService.java:117)...

このバグを修正した。

CR097560

WebLogic Server 6.1 SP04 では、カスタム InitialContextFactoryweblogic.jndi.Environment に設定しても、getInitialContext() は代わりに DEFAULT_INITIAL_CONTEXT_FACTORY を使用した。

InitialContextFactory が指定された場合は weblogic.jndi.Environment オブジェクトがそれを考慮するようコードを修正することで、この問題を解決した。

EJB

変更要求番号

説明

CR063275

WebLogic Server の EJB では、byte [] フィールドにファインダ メソッドを書き込むことができなかった。これは、「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 [] フィールドに対するファインダ メソッドをサポートするようになった。

CR063837

WebLogic Server 6.1 SP02 では、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.verifyTableExistsAndCreateMaybe(Ta bleVerifier.java:391)

コードを修正し、この問題を解決した。

CR076272

EJB をホット デプロイするときのコンパイル エラー情報が不親切だった。たとえば、次のようなものであった。

<30 avr. 02 11:03:14 BST> <Error> <Management> <Error deploying application.¥config¥mydomain¥applications¥ldapprofile.jar:java.lang.reflect.UndeclaredThrowableException>

ホット デプロイされる EJB に対するエラー レポートを改善した。実行時の例外とエラーを、スタンドアロンの ejbc で使われているのと同様の方法で報告するようにした。サーバのログと標準出力で、障害の理解に役立つ情報が提供される。次に例を示す。

<Oct 1, 2002 4:37:18 PM PDT> <Error> <J2EE> <Error deploying application ldapprofile: Unable to deploy EJB: ldapprofile.jar from ldapprofile.jar: java.lang.NoClassDefFoundError: com/bea/p13n/property/EntityPropertyManager at java.lang.ClassLoader.defineClass0(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:486) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:111) at weblogic.utils.classloaders.GenericClass
Loader.findLocalClass(GenericClassLoader.java:394) at weblogic.utils.classloaders.GenericClassLoader.findClass(GenericClassLoader.java:157) at java.lang.ClassLoader.loadClass(ClassLoader.java:297) at java.lang.ClassLoader.loadClass(ClassLoader.java:253) at............

CR076386

6.1 SP03 では、cmr-field のみと共に cmp-ejb を使用すると、正しくない SQL insert 文が生成された。この問題は、MS-SQL Server 2000 で Automatic-Primary-Key-Generation-TPYE : SQL_SERVER を指定すると発生した。コンテナによって生成される SQL 文は次のようなものであった。

Insert into tblLicence(, 5 , 7) values (,licCompID,licOrgID)

compIDorgID は、このエンティティ Bean に対応するテーブルの外部キーである。cmp-field を追加した後では、変更されていない (空の) ejbCreate-Method は正しい SQL を生成する。

Insert into tblLicence(licArchivNR,licCompID,licOrgID)values (null , 5 , 7)

この問題を解決した。Bean に (pk) フィールドと cmr フィールドだけがある場合でも、コンテナは不正な SQL Insert 文を生成しなくなった。

CR080331

6.1 SP03 では、Administration Console を使ってバージョン 5.1 の EJB jar をデプロイすると、ProcessorFactoryException が発生した。

Unable to deploy EJB: TxRolledbackExceptionBean.jar from TxRolledbackExceptionBean.jar:

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 Server examples to ensure the format is correct. The error was:

weblogic.xml.process.ProcessorFactoryException: The public id, "-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN ", specified in the XML document is invalid. Use one of the following valid public ids:

"-//BEA Systems, Inc.//DTD WebLogic 5.1.0 EJB//EN"

"-//BEA Systems, Inc.//DTD WebLogic 6.0.0 EJB//EN"

この問題は、デプロイメント記述子に対する DTD 宣言中のホワイト スペースを WebLogic Server 5.1 がサポートしているために発生していた。

キーを使ってハッシュ テーブル中のパーサを検索する前にこのキー文字列から余分なスペースを取り除くようにコードを変更することで、この問題を解決した。

CR083239

EJB QL NOT MEMBER 句で無限ループが発生しなくなった。

CR083240

EJB QL NOT MEMBER 句と WHERE を併用しても、不正なクエリが作成されなくなった。

CR084978

Administration Console に [EJBC オプション] フィールドを追加し、Console を使って ejbc にヒープ サイズや他のオプションを渡すことができるようにした。

CR087151

ステートレス セッション Bean に関して、以下の問題があった。

<stateless-bean-is-clusterable>False</stateless-bean-is-clusterable>

weblogic-ejb-jar.xml で上のように指定されていて、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 バインドはレプリケートしないようコードを修正することで、この問題を解決した。

CR088526

WebLogic Server 6.1 SP03 では、EJB コンテナが EJB 2.0 の仕様「BMT 使用中に例外が送出されたときに、ロールバックするよう設定されていないトランザクション」に違反していた。

BMT を使用する MDB で onMessage メソッドが例外を送出したときに問題があった。コンテナが、EJB 2.0 仕様 (18.3.2 節の表 18) に従って例外を処理していなかった。コンテナは、例外を記録し (行われていた)、Bean インスタンスを削除し (行われていた)、トランザクションをロールバックするようにマークしなければならなかった (行われていなかった)。結果として、トランザクションがスレッドと関連付けられたままになっていた。

コードを修正して、この問題を解決した。

CR089759

WebLogic Server 6.1:SP03: [EJB] : 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(Account
Bean.java:99)atAccountBean_t4qrab_Impl.ejbStore
(AccountBean_t4qrab_Impl.java:131)at weblogic.ejb20.manager.
DBManager.storeBean(DBManager.java:266) at weblogic.ejb20.
manager.DBManager.beforeCompletion(DBManager.java:397) at weblogic.ejb20.internal.TxManager$TxListener.beforeCompletion(TxManager.java:494) at weblogic.transaction.internal.
ServerSCInfo.callBeforeCompletions(ServerSCInfo.java:551) at weblogic.transaction.internal.ServerSCInfo.startPrePrepareAndChain(ServerSCInfo.java:88)at weblogic.transaction.
internal.ServerTransactionImpl.localPrePrepareAndChain(ServerTransactionImpl.java:979)at weblogic.transaction.
internal.ServerTransactionImpl.globalPrePrepare(ServerTransactionImpl.java:1503) at weblogic.transaction.internal.
ServerTransactionImpl.internalCommit(ServerTransactionImpl.java:215) at weblogic.transaction.internal.Server
TransactionImpl.commit(ServerTransactionImpl.java:189)at weblogic.transaction.internal.CoordinatorImpl.commit(CoordinatorImpl.java:68) at weblogic.transaction.internal.
CoordinatorImpl_WLSkel.invoke(Unknown Source)at weblogic.rmi.
internal.BasicServerRef.invoke(BasicServerRef.java:305)at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:274) at weblogic.rmi.internal.BasicExecute
Request.execute(BasicExecuteRequest.java:22) atweblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(Execute
Thread.java:120)><Oct 24, 2002 5:54:53 AM PDT> <Info> <Management> <Configuration changes for domain saved to the repository.>

この問題は、EJB 仕様の 21.2.5.1 節に準拠するために SP03 で行われた変更が原因であった。この問題を解決した。

CR089953

SP03 では、ejb20.locks.ExclusiveLockManager のテストでメモリ リークが発見されていた。メモリ リークは、デプロイとアンデプロイの結果として発生した。分析の結果、EJB がアンデプロイされたときに DiskSwap のタイマ/トリガがキャンセルされず、TimeGenerator に参照が残り、ExclusiveLockManager バケットのガベージ コレクションが行われていなかった。

タイマ/トリガを正しくキャンセルし、適切にガベージ コレクションが行われるようにコードを修正することで、この問題を解決した。

CR090143

MDB に対するデフォルトのプール サイズがスレッドのプール サイズのデフォルトより大きいため、MDB インスタンスがデフォルトのスレッド プールと、非 MDB 作業の完了を待つブロッキングをすべて使用してしまい、非ブロッキング作業を行うためのスレッドが残らなかった。

メイン スレッド プールに MDB を割り当てるときは MDB プール サイズを ((スレッド プール サイズ) - (ソケット リーダ スレッド)) の割合に制限することで、この問題を解決した。

CR090515

Administration Console で、エンティティ Bean に対する待機数の値が正しく表示されなかった。クライアントがタイムアウトした後でも、待機している EJB があるように Console では表示されていた。

待機が終わったときには ExclusiveLockManagerwaiterTotalCount をデクリメントするように修正することで、この問題を解決した。

CR091436

SP03 では、JMSConnectionPoller が初期コンテキストを閉じていなかった。MDB がルックアップに外部の InitialContextFactory を使用し、JMS プロバイダがアクセス不能であると、接続および他のリソースが急速に蓄積していた。

アクティブなメモリのクリーンアップが済んだときにはコンテキストを閉じるようにコードを修正することで、この問題を解決した。

CR091722

SP03 では、大きな負荷がかかっている場合、ビジネス メソッドを呼び出した後でトランザクションを再開すると、MDB が IllegalStateException を送出し、トランザクションの再開中に JVM がクラッシュした。

この問題は、次のようなアプリケーションにおいて発生した。クライアントがキューにメッセージ送信し、MDB がキューをリスンする。この MDB に対する tx.attribute は「Required」である。MDB の作成メソッドが BMT SLSB を作成するために home.create を行っていて、onMessage メソッドがこの SLSB に対するビジネス メソッドを呼び出している。そして、この SLSB のビジネス メソッドが、2 つの異なるキューにメッセージを送信している。

この場合、次のようなエラーが発生した。

<EJB Exception during invocation from home: com.gfs.corp.batch.cost.costupdate.ejb.NextOrderCostUpdateProcessorEJB_xtvwzj_LocalHomeImpl@54b120 threw exception: java.lang.StackOverflowError> java.lang.StackOverflowError <<no stack trace available>>

ローカル インタフェースが、例外を正しく処理していなかった。

例外が発生したときはコンテナがトランザクションを正しくロールバックするようエラー処理のコードを修正することで、この問題を解決した。

CR093850

SP04 では、エンティティ Bean の実行時モニタが、現在キャッシュされている Bean のカウントの値を誤って報告していた。値が、デプロイメント記述子で指定されているキャッシュ内の最大 Bean 数だけでなく、現在キャッシュされている Bean のカウントを超えていた。

報告される値が正しくなく、新しい Bean が不適切に作成されていた。

Bean をキャッシュから削除した後で、Bean を解放してプールに戻すよう、コードを修正した。

CR095173

weblogic-ejb-jar.xmlidle-timeout-seconds 要素は、ステートフル セッション Bean をパッシベーションするまでに EJB コンテナが待機する時間の長さを決定する。つまり、この時間が過ぎると、EJB はキャッシュから削除されて、ディスクに書き込まれる。また、EJB コンテナは、パッシベーションされた EJB をディスクから削除するまでの待機時間の長さを決めるためにも、この要素を使用していた。しかし、場合によっては、idle-timeout-seconds より長くステートフル セッション Bean をディスクに残しておきたいことがあった。つまり、ステートフル セッション Bean がキャッシュ内でアイドル状態になっている長さと、ディスク上でアイドル状態になっている長さを、異なる 2 つの要素で指定したいことがあった。

新しい要素 session-timeout-seconds を追加した。この要素は、アイドル状態のステートフル セッション Bean をディスクから削除するまでに EJB コンテナが待機する長さを指定する。

CR094524

WebLogic Server 6.1 SP03 および SP04 では、多対一のコンテナ管理関係 (CMR) の読み取り専用 EJB で LockTimedOutException が発生した。

avant getCustomerVO.getCountryVO() [ExclusiveLockManager$Lock
Bucket] : ** LOCK ACQUIRE --> WAITING -- ejb-name: Country primary key: 002 lockClient: Name=[EJB charu.ejbrelations
final.CountryBean.getCountryVO()],Xid=11:1d0d46b2(3053175),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=0,seconds left=30,activeThread=Thread
[ExecuteThread: '2' for queue: 'default',5,Thread Group for Queue: 'default'],SCInfo[mydomain+myserver]=(state=
active),properties=({weblogic.transaction.name=[EJB charu.ejbrelationsfinal.CountryBean.getCountryVO()], LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+172.23.135.56:7011+mydomain+, Resources={})]) wait (MS): 30000 [ExclusiveLockManager$LockBucket] : ** LOCK TIME OUT AFTER WAITING -- ejb-name: Country primary key: 002 lockClient: Name=[EJB charu.ejbrelationsfinal.CountryBean.get
CountryVO()],Xid=11:1d0d46b2(3053175),Status=Marked rollback. [Reason=weblogic.transaction.internal.TimedOut
Exception: Transaction timed out after 29 seconds Name=[EJB charu.ejbrelationsfinal.CountryBean.getCountryVO()],Xid=11:1d0d46b2(3053175),Status=Active,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=29,seconds left=30,active
Thread=Thread[ExecuteThread: '2' for queue:'default',5,Thread Group for Queue: 'default'],SCInfo[mydomain+myserver]=
(state=active),properties=({weblogic.transaction.name=[EJB charu.ejbrelationsfinal.CountryBean.getCountryVO()], LOCAL_ENTITY_TX=true}),OwnerTransactionManager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+172.23.135.56:7011+mydomain+, Resources={})])],numRepliesOwedMe=0,
numRepliesOwedOthers=0,seconds since begin=30,seconds left=10,activeThread=Thread[ExecuteThread: '2' for queue: 'default',5,Thread Group for Queue:'default'],SCInfo [mydomain+ myserver]=(state=active),properties=({weblogic. transaction.name=[EJB charu.ejbrelationsfinal.CountryBean. getCountryVO()], LOCAL_ENTITY_TX=true}),OwnerTransaction Manager=ServerTM[ServerCoordinatorDescriptor=(CoordinatorURL=myserver+172.23.135.56:7011+mydomain+, Resources={})]) wait (MS): 30000

if condition チェックを rbd.isReadOnly() から READONLY_EXCLUSIVE_CONCURRENCY のチェックに変更することで、この問題を解決した。

CR095545

同じ Weblogic Server インスタンス上に、ejb-name は同じだが JNDI マッピングが異なる 2 つのメッセージ駆動型 Bean をデプロイしようとすると、最初の Bean は正常にデプロイされたが、2 番目の Bean のデプロイメントは次の例外で失敗した。

weblogic.management.ManagementException: - with nested exception:

[javax.management.InstanceAlreadyExistsException:

jpdomain:Location=jpserver,Name=MessageQueueHandlerBean,ServerRuntime=jpserver,Type=EJBMessageDrivenRuntime] at

weblogic.management.runtime.RuntimeMBeanDelegate.register(RuntimeMBeanDelegate.java:96) at

weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:83) at

weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:53) at

weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:63) at

weblogic.ejb20.deployer.MessageDrivenRuntimeMBean.<init>(MessageDrivenRuntimeMBean.java:18) at

weblogic.ejb20.deployer.MessageDrivenBeanInfoImpl.deploy(MessageDrivenBeanInfoImpl.java:450) at

weblogic.ejb20.deployer.Deployer.deployDescriptor(Deployer.java:1299) at

weblogic.ejb20.deployer.Deployer.deploy(Deployer.java:1005)

この問題は、MessageDrivenRuntimeMBean 名がユニークでないことが原因であった。ユニークな名前を作成するようコードを修正し、この問題を解決した。

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> 機能を実装することで、この問題を解決した。

CR099420

引数として 2 次元配列を指定すると、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.

渡される配列の次元に基づいて適切なメソッド パラメータ シグネチャを生成するように、eblogic.ejb20.deployer.mbimpl.MethodDescriptorImpl クラスの makeMethodParameter() メソッドを修正することで、この問題を解決した。

CR101384

MDListenerUserTransaction.commit が失敗すると、それ以降に JMS から呼び出される MDB は、スレッドに既にトランザクションが存在するため、UserTransaction.begin で失敗した。次の一連のイベントが発生した。

  1. MDB が別のサーバにある JMS キューからメッセージを取得している。

  2. JMS サーバが停止する。

  3. weblogic.ejb20.internal.MDListener の内部で、UserTransaction.commit が例外を送出する。

  4. MDListener は存続時間の最後まで存在する。

  5. それ以降に JMS から呼び出された MDB は、UserTransaction.begin で失敗する。

コードを修正し、この問題を解決した。予期しない例外によってトランザクションを完了できない場合、MDListener は、新しいトランザクションを開始する前に現在のトランザクションをサスペンドする。

CR101315

jsp:setProperty パラメータの変換の失敗が報告された。

jsp:setProperty のアクションが Bean 内のプロパティの値を設定するときに、ターゲットの型を決定するためのターゲット プロパティを使用し、JSP.2.13.2.1 に従って、パラメータが変換されていた。jsp:setProperty アクションを含む JSP ファイルは、次のエラー メッセージでコンパイルに失敗していた。

... setCount(int) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setBool(boolean) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setmyDouble(double) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setFloat(float) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String) ... setmyLong(long) in weblogic.qa.xmlbasedtests.webapp_jsp_tests.FooBean cannot be applied to (java.lang.String)

この動作は、「CR098402」に関連する変更の結果であった。この CR では jsp:setProperty に関する問題が解決され、プロパティ値の中にある要求時の式が String に変換された。要求時属性として渡される値から割り当てるときは、型の変換は適用されない。

調査の結果、仕様では次のよう規定されていることがわかった。

「要求時属性として渡された値から代入するときは、JSP.2.13.2.3 節で示されているように、型の変換を適用しない。」

コードは仕様に従って機能しているものと判断され、この CR を解決済みにするためにコードの修正は不要であった。

インストーラ

変更要求番号

説明

CR092156

WebLogic Server 6.1 SP04 アップグレード インストーラのビルドに、最新の beasvc.exe が含まれていなかった。関連する CR については、 CR091420 および 091420 を参照すること。

SP05 のアップグレード インストーラでは、この問題は発生していない。

JDBC

変更要求番号

説明

CR085559

Oracle データベースがダウンしているためにユーザ トランザクションがロールバックに失敗すると、トランザクションで使用されている JDBC 接続が解放されず、接続プールに空きがなくなっていた。

この問題は、WebLogic Server 6.1 SP02、Oracle 8.1.6 または 8.1.7 の jDriver for Oracle、および Oracle シン ドライバにおいて発生した。

分析の結果、JTS 接続の internalrollback メソッドが internalclose() メソッドを呼び出していないため、ロールバックが失敗すると接続がリークすることがわかった。

コードを修正してこの問題を解決した。

CR089713

WebLogic Server 6.1 SP03 では、weblogic.Admin RESET_POOL が接続を非予約状態に再初期化していなかった。

weblogic.Admin RESET_POOL を使用した後、ログはすべての接続が更新されたことを示していたが、リセットの前に予約されていた接続は、リセットの後でもまだ予約されていた。

予約されたリソースを resourcesFree リストに戻して関連するフラグをクリアするようにコードを修正し、この問題を解決した。

CR090379

WebLogic Server の以前のリリースでは、アプリケーション コードが、閉じられないまま破棄される JDBC オブジェクトを作成した場合、オブジェクトは失われるが、ガベージ コレクションされた後でもメモリまたはオープン カーソルが保持されていた。 そのようなオブジェクトが多数作成されると、最終的にサーバはメモリ不足になり、データベースではカーソルが不足する。

WebLogic Server 6.1SP5 では、破棄された JDBC オブジェクトがガベージ コレクションの前に閉じられるようにコードを変更した。

注意: 破棄されたオブジェクトと同一の JDBC オブジェクトを直ちに作成すると、WebLogic Server は元の JDBC オブジェクトの複製を作成する。 ただし、リークされた元のオブジェクトを閉じると、複製も影響を受ける。

『WebLogic JDBC プログラミング ガイド』の「JDBC オブジェクトを閉じる」で説明されたベスト プラクティスに従うと、JDBC オブジェクトの破棄を回避できる。

CR090761

OCI ドライバで StringIndexOutOfBoundsException が発生した。この問題は、CMP エンティティ Bean を実行するときには、複数のクエリにおいてときどき発生した。また、weblogic.jdbc.pool.ResultSet.getLong(ResultSet.java:107) の箇所またはその近くの積分 (データベース内の数値の精度によって異なる) を扱うときは、常に発生した。

例外の全文は次のとおりである。
java.sql.SQLException: java.lang.
StringIndexOutOfBoundsException - String index out of range: 0

分析の結果、weblogic.db.oci.OciCurser.getValue
(OciColumn,int,int,boolean,boolean)
において、適切なチェックを行わないで new Long(string) メソッドと new BigInteger(string) メソッドを呼び出していたため、StringIndexOutOfBoundsException が発生していた。

コードを修正してこの問題を解決した。

CR091577

WebLogic Server 6.1 SP03 では、接続プール リセット メソッドについて不要な同期を取っていた。ResourceAllocatorresetThisOne() メソッドの同期が取られていた。その結果、すべての実行スレッドが testConnOnReserve を実行して応答のない接続を置き換える際に、並行して接続を確立するのではなく、キューに入れていた。

コードを修正してこの問題を解決した。

CR092453

WebLogic Server 6.1 SP04 では、Oracle 9.2 に付属する CLASSES12.zip の Oracle Thin XA により、EJB を呼び出すステートレス セッション Bean において、「コンフィグレーションの変更がリポジトリに保存された」というメッセージの後で、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 (すべての SP) では、Oracle Thin Driver に基づく接続プールを通して、Oracle の特定のオブジェクト (ArrayStruct など) を使うことができなかった。Oracle Thin Driver が返すオブジェクトは シリアライズ可能でもリモートでもなく、そのため RMI を介して渡すことができなかった。

新しいパッケージ weblogic.jdbc.vendor.oracle を導入した。パッケージにはこのようなオブジェクトのための「プロキシ」が含まれており、接続プールを通して渡すことができる。

CR093245

JDBCConnectionPoolRuntimeMBean.resetStatementProfile を呼び出した後、SQL トレースを表示できなかった。resetStatementProfile() を呼び出すとトレース ファイルはクリアされたが、JdbcSqlTraceAdmin ツールでトレースを有効にしても、トレースを行うことができなかった。トレースを再度有効にするには、サーバ インスタンスを再起動する必要があった。

コードを修正してこの問題を解決した。

CR093563

「ファイナライザ」と weblogic/jdbc/jta/Statement.java の間で、デッドロックが発生した。

このエラーは、Solaris 5.8 - WebLogic Server 6.1 SP3 - java v1.3.1_03 (ビルド 1.3.1_03-b03)、Java HotSpot(TM) Client VM (ビルド 1.3.1_03-b03、混合モード) において明らかになった。次のようなエラーが発生した。

"ExecuteThread: '5' for queue: 'default'": waiting to lock monitor 0xe1ba8 (object 0xf1327fb0, a java.util.HashSet), which is locked by "Finalizer" "Finalizer": waiting to lock monitor 0xe1b70 (object 0xf1327fe8, a weblogic.jdbc.jta.
ResultSet), which is locked by "ExecuteThread: '5' for queue: 'default'"

この問題は、Oracle データベースに対するクエリと更新を行う Web アプリケーションを実行するサーバ インスタンスにおいて発生した。デッドロックが発生するコードは、ユーザのログイン時にユーザ情報を収集する共通のユーザ管理インタフェースの一部であった。このコードでは、WebLogic Server でコンフィグレーションされている接続プールの oracle.jdbc.xa.client.OracleXADataSource を使用していた。

解析の結果、接続テストが同期を取っているため、利用できるロックがない場合でも、ロックを取得するために待っていた。

コードを修正してこの問題を解決した。

CR093734

WebLogic Server 6.1 では、クライアントが Oracle シン ドライバを使って利用できないデータベースに接続しようとしたときに、正しいエラー コードが返されなかった。

  • Driver.connect() を使って接続を直接取得すると、SQLExcetpion.getErrorCode() は 17002 を返した。

  • Oracle シン ドライバがコンフィグレーションされていて、TestConnectionsOnReserve の設定が true である接続プールから、データ ソースを使って接続を取得すると、SQLExcetpion.getErrorCode() は 0 を返した。

分析の結果、weblogic.jdbc.common.internal.ConnectionEnvFactory がエラー コードを取り込んでいた。

コードを修正してこの問題を解決した。

CR094645

0 以外の開始インデックスを getStatementProfiles() メソッドに渡すと、トレースは、指定した開始インデックスではなく、.tsf ファイルの先頭からデータを返した。

コードを修正してこの問題を解決した。

CR095059

WebLogic Server 6.1 SP04 では、JDBCStatementProfile インタフェースの JDBCStatementProfile.getTimeTaken() メソッドが常に 0 を返した。

weblogic/jdbc/common/internal/ProfileStorage.java のコードを修正して、この問題を解決した。

CR095994

weblogic.jdbc.rmi.internal.ConnectionImpl に、接続リーク プロファイリングと接続リーク検出のロジックがなかった。

接続が解放されてプールに戻される可能性があるのは、次の 3 つのイベントの場合である。

  1. クライアントからの peerGone

  2. DGC の間に BasicServerRef から参照されない呼び出し

  3. リモート クライアントのコードによる接続の適切なクローズ

最初の 2 つのイベントでは、接続リークの可能性があることの警告が、ユーザに対して示されなければならない。

SerialConnection.javaConnectionImpl.java にこのロジックを追加した。

CR096710

Weblogic Server 6.1 SP04 では、データベースに十分な数のプロセス (max_processes) がないために、指定された初期容量で接続プールを作成できない場合、ログに対して ORA-00020 メッセージが送出されていなかった。

メッセージをログに記録するようコードを修正し、この問題を解決した。

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.destroyweblogic.common.internal.ResourceAllocator.release はどちらも、同期が取られたメソッドである。

weblogic/jdbc/common/internal/ConnectionEnv.javaのコードを修正し、この問題を解決した。

CR099363

WebLogic Server 6.1 SP04 では、負荷テストにおいて、接続プールの更新間隔を 15 分に設定し、TestConnsOnReserveTestConnsOnRelease を false に設定すると、次の例外が送出された。

weblogic.common.ResourceException: No available connections in pool ODSConnectionPool

この問題は、プール内の接続の一部だけが使用されていると、その他の接続はすべて、更新テスト間隔が経過した時点でのテスト用に予約されてしまうために発生した。このような状態で、クライアントが接続を要求すると、例外が送出された。

次の 2 つの動作を実装するようにコードを修正し、この問題を解決した。

  • 他に何も変更せず、まったく同じ条件で使用すると、更新テストは一度にただ 1 つの接続を予約してテストし、直ちに接続を解放する。これにより、すべての接続がロックされる問題は解決される。

  • プールの定義に対してドライバ プロパティ secondsToTrustAnIdlePoolConnection を追加し、このプロパティに 1、2、30 のような正の整数を設定した場合には、プールは、その更新間隔中に DBMS に対して正常に接続されたことがわかっているプール接続については、テストを行わない。これにより、更新と testConnsOnReserve の処理が速くなる。

CR101093

WebLogic Server 6.1 SP04 では、接続プールのプロパティに誤ったパスワードが設定されていると、以下の例外が送出された。

<Mar 13, 2003 10:35:45 AM IST> <Info> <JDBC> <Sleeping in createResource()> <Mar 13, 2003 10:35:46 AM IST> <Info> <JDBC Pool DemPool> <Pool DemPool is created with initial capacity 0> In the earlier versions of WLS. The exception was more descriptive. The following exception is thrown when the incorrect password is specified in sp 3. <Mar 12, 2003 9:41:38 AM IST> <Error> <JDBC> <Cannot startup connection pool "Dpool" weblogic.common.ResourceException: Could not create pool connection. The DBMS driver exception was: java.sql.SQLException: ORA-01017: invalid username/password; logon denied

weblogic/common/internal/ResourceAllocator.java を修正し、この問題を解決した。

jDriver

変更要求番号

説明

CR083694

weblogic.db.oci.OciCursorgetTimeStamp()getTime()getDate()getJavaDate() のいずれかのメソッドを Calendar オブジェクトを null にして呼び出すと、新しいカレンダが作成されていた。

パフォーマンス向上のため、カレンダを 1 つだけ作成し、これらのメソッドのいずれかが初めて呼び出された時点で、カーソルに格納するようにした。

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_LANGAMERICAN_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 のコードを修正することで、この問題を解決した。

CR091151

WebLogic Server 6.1 SP03 および SP04 では、jDriver for Oracle の ResultSet#getBigDecimal() メソッドが正しい値を返さなかった。たとえば、9999999999.999999 という値は 9999999999.999998 に丸められていた。

コードを修正してこの問題を解決した。

CR093795

WebLogic jDriver for MSSQL Server 2000 で statement.getString() を使用すると、ユーロ通貨記号として「?」が取得された。

新しい String コンストラクタを使用して文字セットを正しく処理するようコードを修正し、この問題を解決した。

CR098071

WebLogic Server の旧リリースにバンドルされているバージョンの Oracle Thin driver 9.2.0 には、データ エラーが発生することのあるエラーが含まれていた。ドライバを、Oracle 製の新しいバージョンに置き換えた。

CR101517

Oracle の SQL DATE 型は 4712 B.C. から 4712 A.D. の間の日付をサポートするが、jDriver for Oracle は「1899-12-31」以前の日付を処理できなかった。jDriver によって格納された日付を、Oracle Thin Driver や SQL*Plus のような他のツールでクエリできなかった。この問題は、prepared statement を使用し、setDate() メソッドを使ってこのような日付を DATE カラムにバインドした場合にだけ発生した。

weblogic/db/oci/OciColumn.java のコードを修正し、この問題を解決した。

CR102060

WebLogic Server 6.1 SP02 では、jDriver for Oracle と Oracle 8.1.7 を使うと、CallableStatement を使用した後で、同じ接続に対して SQL の UPDATE に対する PreparedStatement が機能しなかった。この問題は、「CR080931」の再発であった。

getUpdateCount() からは 0 が返り、データベースでは何も変更されなかった。この問題は、JDBC 接続に対して weblogic.oci.min_bind_size プロパティを設定すると発生した。

props.put(“weblogic.oci.min_bind_size”, “660”)

分析の結果、jDriver が文に対して min_bind_size=33000 を使用していることがわかった。

weblogic.jdbc.oci.Connection#prepareCall は、内部的に min_bind_size に 33000 を設定していた。

db\oci\OciConnection.java のコードを修正し、この問題を解決した。

JMS

変更要求番号

説明

CR080296

WebLogic Server 6.1 SP02 では、UserPassword が null のときにメッセージング ブリッジが正しく機能しなかった。null ではない UserName と null の UserPassword でブリッジをコンフィグレーションすると、明確なエラー メッセージが表示されずにブリッジの起動が失敗した。

コードを修正してこの問題を解決した。

CR083933

WebLogic Server 6.1 SP03 では、大きな負荷がかかると JMS サーバが NullPointerException を送出した。

<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <XA resource [JMS_JMSServer1JDBCStore] has not responded in the last 120 second(s).>

<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >

<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >

<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >

<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >

<Aug 2, 2002 65438 PM EDT> <Warning> <JTA> <Resource JMS_JMSServer1JDBCStore was not assigned to any of these servers JMSServer1 >

<Aug 2, 2002 65438 PM EDT> <Alert> <JMS> <JMSServer "JMSServer1",unhandled exception during rollback, java.lang.NullPointerException.java.lang.NullPointerException at weblogic.jms.backend.BEDurableTopicMessageInfo.rollbackReceiveTran(BEDurableTopicMessageInfo.java352) atweblogic.jms.backend.BEXATranEntrySubscribe.startRollback(BEXATranEntrySubscribe.java145)at weblogic.jms.backend.BEXATranEntry.execute(BEXATranEntry.java127) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java120)

この問題は、400 の実行スレッド、200 の JMS スレッド、および接続プールに対する 100 の接続というコンフィグレーションで発見された。例外は、負荷テストにおいて、恒久サブスクライバに対する毎秒約 10 個のメッセージ (約 2K) を JMS サーバに対して発行すると発生した。分散トランザクションはなかった。JDBCStore に対する接続プールには Sybase ドライバが使用されていた。

rollbackReceiveTran() を呼び出す前に prepareStoreRequest を検査するようコードを修正することで、この問題を解決した。

CR086976

WebLogic Server 6.1 SP02 では、DB2 を使用する AS400 マシンに JMS JDBS ストアを作成できなかった。

コードを修正することでこの問題を解決した。

CR089114

JMS セレクタのパフォーマンス強化が実装された。対象となるのは、それぞれがユニークな識別子を持つ 20,000 件のサブスクライバの小さなサブセットにメッセージをパブリッシュするような場合である。すべてのサブスクライバのセレクタを評価して一致するサブセットを決定する必要があるため、これは CPU に大きな負荷のかかる処理であった。

このような状況でのパフォーマンスを向上させるため、限定的なサブスクライバ インデックス機能を JMS に追加した。この拡張機能では、各サブスクライバは、サブスクライバにインデックスを付けることができることを JMS がわかるような方法で、それぞれの「ユニークさ」を JMS に通知する。このユニークさは、次の形式の JMS セレクタを使って指定する。

xxxxx IS NOT NULL

xxxxx は JMS で既に使われているメッセージ属性とは異なる任意の識別子であり、複数のサブスクライバが同じ「xxxxx」を指定してもよい。これは、JMS の標準構文である。WebLogic JMS は、このセレクタを、サブスクライバにインデックスを付けることで最適化できることを示しているものと見なす。

インデックス付けされたサブスクライバを含むトピックに対してメッセージがパブリッシュされると、JMS は、メッセージの各ユーザ プロパティに対して反復処理を行い、ユーザ プロパティの名前と一致するインデックス付きサブスクライバにメッセージを渡す。JMS は、メッセージがパブリッシュされたときの従来の動作も引き続きサポートしており、インデックス付けされていないサブスクライバに対する反復処理を行う (上記の特殊なパターンと一致しないセレクタが指定されたサブスクライバ)。

CR089583

WebLogic Server 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) at weblogic.jms.backend.BEManager.invoke(BEManager.java:216) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510) at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync (DispatcherImpl.java:149) at weblogic.jms.dispatcher.Request.dispatchAsync(Request.java:734) at weblogic.jms.frontend.FEManager.removeSubscription(FEManager.java:288) at weblogic.jms.frontend.FEManager.invoke(FEManager.java:320) at weblogic.jms.dispatcher.Request.wrappedFiniteStateMachine(Request.java:510) at weblogic.jms.dispatcher.DispatcherImpl.dispatchAsync (DispatcherImpl.java:149) at weblogic.jms.dispatcher.DispatcherImpl.dispatchSyncFuture

(DispatcherImpl.java:300) at weblogic.jms.dispatcher.DispatcherImpl_WLSkel.invoke(Unknown Source) at weblogic.rmi.internal.BasicServerRef.invoke(BasicServerRef.java:298) at weblogic.rmi.internal.BasicServerRef.handleRequest(BasicServerRef.java:267) at weblogic.rmi.internal.BasicExecuteRequest.execute (BasicExecuteRequest.java:22) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)

分析の結果、確認応答未送信メッセージのカウントをメッセージごとに 2 回インクリメントし、1 回だけデクリメントしていることがわかった。そのため、確認応答未送信メッセージ カウントは常に 0 より大きくなり、恒久サブスクライバのサブスクライブを取り消そうとすると例外が送出された。

コードを修正することでこの問題を解決した。

CR089682

WebLogic Server SP03 では、再試行の値 (下限、上限、増分) が MessagingBridge に対して正しく機能しなかった。この問題は、WebLogic Server の JMS サーバからそれ以外に対してメッセージを送信するようにコンフィグレーションされた MessagingBridge で発生した。すべて同じ WebLogic Server インスタンスで動作していた。JMS の 1 つを対象から外すと、次のエラーが発生した。

<30-Oct-02 15:13:34 GMT> <Error> <Connector> <Error granting connection request.>

再試行の試みは、接続再試行パラメータによって制御された間隔で行われなければならない。しかし、起動時のデフォルト値 (下限 = 15、上限 = 60、増分 = 5) では、次のような動作になった。

  1. 接続を試みて失敗する - OK

  2. 15 秒後に 2 回目の接続を試みる - OK

  3. それ以降は、5 秒間隔で接続を試みる - NOT OK

<30-Oct-02 15:13:09 GMT> <Error> <Connector> <Error granting connection request.>

<30-Oct-02 15:13:14 GMT> <Error> <Connector> <Error granting connection request.>

<30-Oct-02 15:13:19 GMT> <Error> <Connector> <Error granting connection request.>

<30-Oct-02 15:13:24 GMT> <Error> <Connector> <Error granting connection request.>

<30-Oct-02 15:13:29 GMT> <Error> <Connector> <Error granting connection request.>

デフォルト パラメータのいずれかを変更すると、増分は正しくなる。しかし、上限値には達しなかった。デフォルト値の場合、55 までしか達しなかった。

再試行の値に対するロジックを修正することで、この問題を解決した。

CR091195

WebLogic Server SP04 では、MDB が受信した永続キュー メッセージに対して適切に確認応答が行われず、Administration Console のモニタ機能では「BYTES PENDING」と表示された。MDB が受信したメッセージは、WebLogic Server をシャットダウンして再起動すると解放された。

EJB のトランザクション記述子が NotSupported の時の MDB の確認応答に関するコードを修正することで、この問題を解決した。

CR091827

WebLogic Server SP02 では、OracleThinDriver for XA、Windows NT、JDK 1.3.1、および Oracle 9011 という環境で、JDBC のログ機能が「java.sql.SQLException: Connection has already been closed」を送出した。このエラー メッセージの後、JDBC のログ ファイルには何も記録されなかった。

JDBC ログ機能のエラーが発生しないようにコードを修正することで、この問題を解決した。

CR092464

WebLogic Server SP02 および SP04 では、恒久トピック サブスクライバが JMS サーバに接続し、トピックに対して送信されたメッセージがあると、メッセージが受信されて、受信側によってコミットされた場合でも、WebLogic Server は「現在のバイト数」の値にメッセージ サイズを加えていた。対応する「現在のメッセージ数」の値は、変更されなかった。恒久トピック サブスクライバが JMS サーバに接続していず、トピックに対して送信されたメッセージがある場合は、「現在のメッセージ数」と「現在のバイト数」が両方とも加算されていた。恒久トピック サブスクライバが再び JMS サーバに接続すると、「現在のメッセージ数」と対応する「現在のバイト数」が両方とも減算されていた。このような不整合の結果として、恒久トピック サブスクライバに対して未処理のメッセージがなくなっても、「現在のバイト数」の値が 0 にならなかった。

分析の結果、backend/BEConsumer.javaaddMessages() において、bytesCurrentCount が不適切に更新されており、結果として Administration Console における統計情報の表示が正しくなかった。

コードを修正し、この問題を解決した。

CR093712

WebLogic Server SP04 では、メッセージング ブリッジに対する最大アイドル タイム アウトが過ぎると、以下に示すメッセージがサーバのログ ファイルに書き込まれる。多数のメッセージング ブリッジがコンフィグレーションされている場合、ログ ファイのサイズが急速に大きくなる。

####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200027> <Bridge "DWSBackend Inbound Bridge" works in asynchronous mode and has not received messages for the predefined maximum idle time. The connections to the adapters will be interrupted and re-established.>

####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessaginBgridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200020> <Bridge "DWSBackend Inbound Bridge" is stopped.> ####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200033> <Bridge "DWSBackend Inbound Bridge" is getting the connections to the two adapters.> ####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200032> <Bridge "DWSBackend Inbound Bridge" is configured not to allow degradation of its quality of service in cases where the configured quality of service is not reachable.>

####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200030> <Bridge "DWSBackend Inbound Bridge" is configured to work in "Exactly-once" mode and it is actually working in "Exactly-once" mode.> ####<Dec 19, 2002 12:44:42 PM EST> <Info> <MessagingBridge> <dws-stage> <DwsStageServer> <ExecuteThread: '3' for queue: 'MessagingBridge'> <> <> <200028> <Bridge "DWSBackend Inbound Bridge" starts transferring messages.>

DebugMessagingBridgeruntime デバッグ フラグを使ってログ メッセージの書き込みを禁止できるようにすることで、この問題を解決した。

CR099455

競合状態が原因で、JMS メッセージが失われていた。

コードを修正し、この問題を解決した。

CR101374

JMS メッセージが失われていた。JMS サーバには着信キューと発信キューがある。別のサーバにある MDB は、着信キューからメッセージを取り出し、1 対 1 の関係で発信キューにメッセージを格納する。この処理は、MDB が開始するトランザクションの中で行われる。トランザクションの終わりは、MDB が発信キューにメッセージをエンキューしたときであった。JMS サーバを停止して再起動すると、メッセージが失われた。10,000 メッセージの負荷に対して、失われるメッセージは少数であった。

トランザクション処理される XAConnection を強制的に CLIENT_ACK にするようコードを修正し、この問題を解決した。

CR101670

weblogic.jms.client.JMSSession$UnackedMessage テストの際に、コミットまたは確認応答を行わない JMS クライアント セッションが、メモリをリークしていた。テストでは、キューとトピックの両方に対して非同期レシーバとして機能する起動クラスを使用していた。レシーバは、トランザクション処理を行うセッションと AUTO-ACKNOWLEDGE モードを使って作成された。メッセージを受信する、レシーバはセッションに対して Rollback を行った。診断の結果、weblogic.jms.client.JMSSession$UnackedMessage でメモリ リークが発生していることがわかった。

weblogic/jms/client/JMSSession.java のコードを修正し、この問題を解決した。

JNDI

変更要求番号

説明

CR087237

WebLogic Server 6.1 SP03 では、Solaris で稼働する 2 ノードのクラスタにおいて、ステートレス セッション Bean のフェイルオーバが 5 分程度かかっていた。サーバはフリーズし、クライアントはハングした。

複数のコードとコンフィグレーションを変更することで、フェイルオーバを 45 秒に短縮した。

  • RJVMFinderPeerGoneListener とすることにより、利用できないサーバを憶えておき、レプリカ リストが空になるまではサーバを試さないようにした。

  • BasicReplicaHandler を修正し、レプリカ リストにまだサーバがあるときには、フェイルオーバの間に refreshReplicalist を呼び出さないようにした。

  • T3JVMConnection に、ワーカ スレッドにソケットを作成するための新しい機能を追加した。さらに、so_timeout に対して同じタイムアウトを使うようにし、Solaris 8 クライアントにおいて読み取りが 1 分間ブロックしないようにした。新しいフラグは -Dweblogic.client.SocketConnectTimeoutInSecs=15 である。

  • サーバとクライアントでのハートビート間隔を、既存の -D の値を使って制御するようにした。サーバにおけるデフォルトの実行キューを増やし、増大したハートビートの負荷に対応するようにした。クライアントのハートビート時間は、-Dweblogic.PeriodLength=10000 フラグによって制御される。サーバのハートビートは、config.xmlServerMBeanPeriodLength="10000" フラグによって制御される。

CR093700

JNDI ツリーに対するクラスタ対応 RMI オブジェクトのバインド/リバインドおよびアンバインドの際に、アンバインド操作が、オブジェクトを null にしてガベージ コレクション用にセットアップしたにもかかわらず、オブジェクトがサーバ上でローカルにホストされているときは、null オブジェクトに対する参照を保持したままになることがあった。

クラスタ内に他に利用できるこのようなオブジェクトのレプリカがないときにだけガベージ コレクション用にオブジェクトを設定するよう、コードを修正した。

CR093799

複合名に対して Context.lookup を行うとき、名前の全体または一部が解決できないと、NameNotFoundException が発生した。

名前 remainingName = nnfe.getRemainingName(); は、名前から解決されないコンポーネントを取得しなければならない。このようなコンポーネントは、JNDI ツリー内に作成する必要のあるサブコンテキストである。

そのため、列挙 e = remainingName.getAll() を呼び出したなら、取得される列挙には未解決のコンポーネントが文字列として含まれていなければならない (「Unresolved1」、「Unresolved2」、「Unresolved3」など)。しかし、列挙にはただ 1 つの文字列「Unresolved1.Unresolved2.Unresolved3」が含まれているだけであった。

区切り文字「/」を使って CompositeName を作成するよう BasicNamingNode.java を変更することで、この問題を解決した。

CR096838

WebLogic Server 6.1 SP03 および SP04 では、weblogic.jndi.Environment オブジェクトが適切なタイミングで解放されず、InitialContextejb-ref-name をルックアップする際に OutOfMemoryError エラーが発生していた。

コードを修正し、コンテキストを正しく閉じるようにした。

JSP

変更要求番号

説明

CR092039

WebLogic Server 6.1 SP03 では、次のように JSP タグの charset の値に余分な引用符があると、JspParserUnsupportedEncodingException を送出した。

<%@ 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 属性値に対する引用符の付いた文字列やコメントのサポートを追加することで、この問題を解決した。

CR088019

WebLogic Server 6.1 SP03 では、仮想ホストを使用する HP-UX 11 の場合、生成される Java ファイルをコンパイルできなかった。仮想ホストが対象でないときは、.ear ファイルは正しくデプロイされた。アクセスすると、login.jsp が Java ファイルを生成してコンパイルした。

仮想ホストをコンフィグレーションし、.ear の Web アプリケーション部分の対象を仮想ホストにした後、サーバを再起動すると、アクセスしたときに、login.jsp は Java ファイルを生成するが、クラス ファイルにコンパイルすることができなかった。

コードを修正してこの問題を解決した。WebServer コンポーネントを識別する要素を一時ディレクトリに格納し、仮想ホストとデフォルトの Web サーバを区別するようにした。これにより、Web アプリケーションがデプロイされて一時ディレクトリが空になっても、デプロイメント ファイルがクラッシュしなくなった。

CR092089

名前にマルチバイト文字を含む JSP ファイルがコンパイルされず、ディレクトリがその内容を返していた。

分析の結果、ファイル名にマルチバイト文字が含まれると、JSP ファイルのパスが正しく検出されなかった。WebLogic Server が VM のデフォルトでパスをデコードした後、パスは「input-charset」を使って再びデコードされていた。

ブラウザのデコード方法の実装の問題が関係していた。Internet Explorer は、UTF-8 に基づいて URLencode を行っていた。Netscape は、プラットフォームのデフォルトに基づいて行っていた。

UTF-8 に基づいて ContextPathServletPath、および PathInfo をデコードするようにコードを修正することで、この問題を解決した。

デコード方式は、weblogic.http.URIDecodeEncoding でコンフィグレーションできる。

CR092366

javax.servlet.jsp.PageContext.out 属性が、本体コンテンツ タグに対して正しくクリーンアップされていなかった。

コードを修正してこの問題を解決した。

CR093014

あるスクリプトレットで開始した Java コメントが次のスクリプトレットで終了すると、エラーが発生していた。

<22.07.2002 14:12:24 CEST> <Error> <HTTP>

<[WebAppServletContext(7422744,DefaultWebApp,/DefaultWebApp)] Servlet failed with Exception weblogic.servlet.jsp.JspException: (line 12): scriptlet close brace '}' unbalanced at line 12 which breaks scope '_base_service_scope_' at ....

WebLogic Server 7.0 から文法を逆移植することで問題を解決した。ScriptletScopeLexer が Java コメント全体をスキップするようになった。

CR093291

サーバによる JSP のコンパイルに、システム クラスパスが含まれていなかった。サーバ起動時に、CLASSPATH の jar を参照する JSP がコンパイルされなかった。

次のようなメッセージが発生した。

package com.bea.p13n.util.debug does not exist probably occurred due to an error in /devtools/debug.jsp line 1:<%@ page import="com.bea.p13n.util.debug.Debug" %>

分析の結果、システム クラスパスの jar が「../..」で始まっていると問題が発生することがわかった。

クラスパスを整理するときに ./ と ../ の場合も考慮するようコードを修正することで、この問題を解決した。

CR093625

WebLogic Server 6.1 SP03 および SP04 では、JSP ページにおける JSP include に対する出力をサーバが誤って示していた。include、forward、 wrapped-response、および JSP BodyTag の処理を統一するようサーブレット エンジンを変更することで、この問題を解決した。

CR094190

JVM の仕様によると、メソッドのサイズに対する制限は 64K である。WebLogic Server 6.1 SP03 では、生成される Java コードが __jspService メソッドに対する 64K の制限を超えるような本体付きタグを多く含む JSP があった。

コードを修正し、この問題を解決した。<my:tag ... /> の形式の空の BodyTag があると、普通であれば本体に対してスコープを設定するように生成されるコードが、StandardTagLib.java の静的メソッドに対する単一の呼び出しに置き換えられる。これにより、BodyTag は、通常どおり JSP ソースから呼び出されているものと考える。

CR098402

WebLogic Server 6.1 SP04 では、jsp:setProperty が、プロパティ値に含まれる要求時の式を、String に変換していた。コードを修正し、この問題を解決した。要求時属性として指定される値から割り当てるときは、タイプ変換が適用されなくなった。

JTA

変更要求番号

説明

CR088171

WebLogic Server 6.1 SP02 では、トランザクションが unknown 状態であると、トランザクションが失われた。

次のようなクラスタ コンフィグレーションについて考える。

MS-1

  • Queue1 - MDB1 TX Required

  • Queue2 - MDB2 TX Required

  • SLSB

MS-2

  • Queue3 - MDB3 TX required

  • SLSB - send() - TX required

  • sendImmediate() - TX RequiresNew

キューは DB に保持され、MDB はトランザクションとしてメッセージをキューから取り出す。以下の操作を行う。

  1. MDB3 の SLSB.send() を呼び出した後、SLSB.sendImmediate() を呼び出す。

  2. SLSB.send は、SLSB.send() ...>MDB2-> MDB1 -> SLSB.sendImmediate() を 2 回呼び出す。

  3. Queue3 に 100 メッセージを送信し、処理の開始を許可する。すべてのメッセージがエンキューされた後、Queue3 からすべてのメッセージが取り出される前に、MS-1 を停止する。

  4. MS-1 を再起動する。

MS-2 を停止すると、MS-1 は peergone 例外を受け取り、ステータスをコミットする準備ができているトランザクションは、prepared から unknown になる。2 番目のサーバを再起動すると、トランザクションが UNKNOWN 状態であるために、コミットとロールバックのどちらを行えばよいのかわからないので、トランザクションは失われる。

コミット中に unknown 例外を受け取ったときはトランザクションをロールバックするようコードを修正することで、この問題を解決した。

CR088844

WebLogic Server 6.1 SP02 では、サーバの起動時に LogManager と JTA の間でデッドロックが発生した。スレッド ダンプを分析した結果、次のことがわかった。

実行スレッド 7: このスレッドはリソースを取得しようとする。ResourceDescriptor.startResourceUse を呼び出す。このメソッドの同期ブロックの内部は、トレース文である。

実行スレッド 6: Audit Bean が LogBroadcaster を呼び出そうとする。これによって行われる RMI 呼び出しにより、トランザクションはサスペンドしてリソースを解放する。解放では ResourceDescriptor.startResourceUse の呼び出しも行われる。

スレッド 7 のstartResourceUse 内のトレース文はスレッド 6 での LogBroadcast を待ってブロックしており、スレッド 7 の取得はスレッド 6 での解放を待っている。

startResourceUse のトレース文を同期ブロックの外に移動することで、この問題を解決した。

CR091628

javax.transaction.xa.XAResource インタフェースで定義されている setTransactionTimeout() メソッドを使うと、トランザクション マネージャは、XAResource インスタンスに関する操作のために、リソース マネージャにトランザクション タイムアウトを設定できる。アプリケーションがグローバル トランザクションでリソース マネージャにアクセスするとき、WebLogic Server のトランザクション マネージャはこのメソッドを呼び出していなかった。

XASetTransactionTimeout が「true」のときに使用される XATransactionTimeout プロパティを追加することで、この問題を解決した。これは、JTA トランザクションのタイムアウト値が使用されていてその値が大きい場合、トランザクションの途中で WebLogic Server がクラッシュすると、Oracle が行をロックしてしまい、Oracle が再起動するまで行にアクセスできなくなるためである。

CR091882

WebLogic Server 6.1 SP03 では、6.1 SP03 のリモート クラスタでステートレス EJB を呼び出すと、トランザクション タイムアウトが発生した。

transaction/internal/TransactionImpl.java のコードを修正することで、この問題を解決した。

CR092301

WebLogic Server 6.1 SP04 では、weblogic.transaction.internal.ServerResourceInfo.isAccessibleAtAndAssignableTo が Null ポインタ例外を送出した。この問題は、サーバがアイドル状態の時にも散発的に発生し、確実に再現させることはできなかった。

weblogic/transaction/internal/ServerResourceInfo.java のコードを修正することで、この問題を解決した。

CR093045

WebLogic Server 6.1 SP02 以降では、WebLogic Server に負荷がかかっている状態でデータベースを停止して再起動した後、Oracle 8.1.7.4 Thin Driver XA 接続プールが使用できなくなった。

テスト アプリケーションは、XA 接続プールを使用し、MDB を通して、Oracle 8.1.7.4 のカラムを更新していた。WebLogic Server が MDB メッセージを処理しているときに、Oracle データベースを停止して再起動すると、XA 接続が更新されず、Oracle の分散ロックが回復されなかった (ORA-01591)。WebLogic Server は周期的な「ハング」状態になり、XA 接続を更新しようとした。XA 接続の更新と使用を「循環している」とき、WebLogic Server のログ ファイルには次の情報が記録された。

... ####<13.12.2002 12:09:54 CET> <Info> <JDBC Pool FoundationThinXAPool> <A4PMA9ALX> <myserver> <ExecuteThread: '9' for queue: 'default'> <guest> <484:6c709abb7f28edb9> <000000> <javax.transaction.SystemException: start() failed on resource 'weblogic.jdbc.jta.VendorXAResource' null at weblogic.transaction.internal.ServerResourceInfo.xaStart(ServerResourceInfo.java:1010) at ...

WebLogic Server は、この状態 (サイクル) から回復しなかった。サーバのすべてのスレッドはブロックされているように見え、サーバを停止しなければならなかった (weblogic.Admin SHUTDOWN は機能しなかった)。WebLogic Server を再起動した場合にだけ、JTA の回復が行われた直後に、Oracle の分散ロックが解決された。回復が行われる前は、MDB が未処理のメッセージを再送信しようとして、ORA-01591 例外が大量に送出された。状態不明の分散トランザクションを JTA が回復した後は、未処理の JMS メッセージの処理は正常に行われた。

weblogic\jdbc\oci\xa\XADataSource.java のコードを修正し、この問題を解決した。

CR100357

トランザクションに参加するサーバを停止して再起動すると、回復が遅かったり、デッドロックが発生したりした。コンフィグレーションには、ピン固定された接続ファクトリおよび分散された着信キューと発信キューを備えた 4 つの JMS Server と、4 つの MDB Server (それぞれに 4 つの MDB がデプロイされ、プール内の 5 つの Bean が着信キューの各分散メンバをリスンしている) が含まれ、着信キューにはサイズが 2K のメッセージが 40,000 件あった。

JMS サーバと MDB サーバを再起動すると、JMS サーバがすべてのデフォルト キュー スレッドを使ってしまい、実行キューが増え続けた。

ServerTransactionImpl.java を修正し、この問題を解決した。

CR100898

トランザクションがロールバックした場合、トランザクションに参加するリソースを持たないサーバがトランザクションに参加していると、トランザクションが完了しない場合があった。トランザクションは調整を行っているサーバ上に存在し続け、ロールバックするリソースがないことをサーバに通知する再試行を続けていた。最終的に、トランザクションは破棄された。すべての参加リソースはロールバックの通知を受けたが、完了した後で、調整を行っているサーバ上でコールバックが処理されない場合があった。

リソースを持たないサーバにも対応し、すべてのサーバ/リソースが通知を受けたら直ちに状態をロールバック済みに設定するよう、ロールバック非同期応答処理のロジックを変更することで、この問題を解決した。

その他

変更要求番号

説明

CR094764

WebLogic Server 6.1 SP04 では、Windows NT を再起動したとき、beasvc.exe が正常にシャットダウンしなかった。この問題は、以下の手順で発生した。

  1. NT サービスとして動作するように WebLogic Server をコンフィグレーションする。

  2. Windows のコントロール パネルから WebLogic Server を開始する。

  3. Windows の [スタート] メニューから、Windows NT を再起動する。

サーバ ログは空で、イベント ビューアには次のメッセージが記録されていた。

The myserver service terminated unexpectedly. It has done this 1 time(s).

The following corrective action will be taken in 0 milliseconds: No action.

分析の結果、Windows Service Control Manager (SCM) は、システム シャットダウンの際に beasvc.exeSERVICE_CONTROL_SHUTDOWN を通知できるよう、SERVICE_ACCEPT_SHUTDOWN の通知を受けなければならないことがわかった。

必要な処理を行うようコードを修正し、問題を解決した。

CR099590

WebLogic Server 6.1 SP02 では、JMX クライアントを使用して管理対象サーバを削除すると、weblogic.management.internal.MBeanHomeImpl.getInterface(MBeanHomeImpl.java:431) で Null ポインタ例外が発生した。

MBean の削除に関する修正により、この問題を解決した。

プラグイン

問題が解決されたプラグインは、「説明」カラムにおいてかっこで囲んで示してあります。

変更要求番号

説明

CR091740

(HttpClusterServlet) ベンチマーク テストの際に、HttpClusterServlet を実行するプロキシ サーバが 503 番と 500 番の HTTP エラーを返した。このエラーは、ときどき不規則に発生した。コンフィグレーションは、JRockit 7.0 SP2 Load 2 と Sun JDK 1.3.1_06 であった。AcceptBacklog とスレッド カウントは、それぞれ 1000 および 50 まで増加した。ベンチマークは、100 〜 200 のクライアント スレッドで実行された。

この問題は、サーブレットの動的サーバ リストにエントリが含まれない場合に発生した。

動的サーバ リストの配列を作成する前にリストのサイズをチェックするようコードを修正することで、この問題を解決した。

CR084625

(NSAPI) iPlanet プラグインのすべてのバージョンで、/_wl_proxy/_post がハードコーディングされていた。

#else /* UNIX */

sprintf(name,"/tmp/_wl_proxy/_post__%d_%d", pid, postCounter);

fsep = '/';

#endif

このため、複数のサーバが異なるユーザ ID とグループを使用している場合に問題が発生した。

たとえば、クライアントからアップロードされたファイルは、WebLogic Server に対してプロキシを行う Web サーバの /tmp/_wl_proxy に一時的に保存される。_wl_proxy ディレクトリは、Web サーバが再起動されるたびに削除される。ユーザ プロセスはデフォルトの umask を使ってパーミッションを作成するので、環境が共有されている場合 (同じ物理サーバに複数のインスタンスがある場合) には、このディレクトリを作成したユーザ プロセスが、他のユーザの書き込みをブロックする。つまり、アプリケーション A (A というユーザ ID で動作) が /tmp/_wl_proxy/<何らかの一時ファイル> を作成した後、アプリケーション B がファイルをアップロードしようとすると、エラー ファイルに次のエラーが記録される。

[27/Aug/2002082140] failure (14367) for host 172.18.5.122 trying to POST /filetransfer/TransferUtility.do, wl-proxy reports exception occurred 'READ_ERROR [os error=13, line 501 of proxy.cpp] Cannot open TEMP file '/tmp/_wl_proxy/_post__14367_5' in $TMP/_wl_proxy for POST of 2867 bytes

コンフィグレーション可能な引数 WLTempDir を追加することで、この問題を解決した。この引数は、wlproxy.log_wl_proxy の両方に対して適用される。下位互換性のため、ログ ファイル作成時に WLLogFileWLTempDir をオーバライドする。

CR085192

(NSAPI、ISAPI) 接続プールをオフにすると、パフォーマンスが低下した。

URL を作成するために多くのリソースが必要であった。

プラグインが接続を閉じる前に WebLogic が接続を閉じたため、接続が「半分開いた状態」になり、プラグインで PROTOCOL_EXCEPTIONS が発生した。

複数のコードを変更することで、この問題を解決した。

    • ISAPI と NSAPI に対して Keep-Alive をデフォルトで有効にした。

    • WebLogic Server がプラグインに対して特殊なヘッダーで keepAliveSecs の値を送信するようにした。

CR085285

(NSAPI) プラグインからの InitJVMID リクエストに対して Web アプリケーション コンテナが 404 番のメッセージを返し、ログ ファイルが次のメッセージで一杯になっていた。

####<Sep 6, 2002 4:56:43 PM EDT> <Debug> <HTTP> <petunia> <ms1petunia> <ExecuteThread: '13' for queue: 'default'> <kernel identity> <> <101147> <HttpServer(887891,null default ctx,ms1petunia) found no context for "/WLDummyInitJVMIDs".

WebLogic Server 上に常にデプロイされている内部 Web アプリケーションに対して InitJVMID リクエストを送信することで、この問題を解決した。

CR085541

(すべてのプラグイン) __WebLogicBridgeConfig が、デバッグの内部表現 (紛らわしい 10 文字のコード) を返した。

コードによって表される値を返すようコードを修正した。

CR085695

(ISAPI) KeepAlive が有効になっているときに、HEAD HTTP リクエストについて接続を閉じるまでの時間が約 30 秒であった。

この問題は、6.1 SP01、Windows 2000、IIS 5.0 という環境で発生した。

HEAD リクエストに対して接続を直ちに閉じるようコードを修正することで、この問題を解決した。

CR085921

(ISAPI) すべてのプラグインにおいて、WebLogic Server へのリクエスト/ポスト データを書き込む際に発生した WRITE_ERRORS と、__WebLogicBridgeConfig 統計でブラウザに応答ヘッダ/データを書き込む際に発生した WRITE_ERRORS を区別することができなかった。この問題により、プラグイン/クラスタの状態をモニタするために __WebLogicBridgeConfig によって表示される統計情報の使用がいっそう困難になっていた。

2 つの新しいエラー タイプ WRITE_ERROR_TO_CLIENTWRITE_ERROR_TO_SERVER を実装することで、この問題を解決した。

CR085923

(ISAPI) すべてのプラグインで、Debug=ERR と設定すると、INF メッセージもログに記録されていた。

コードを修正してこの問題を解決した。Debug=ERR と設定したときは、ERR メッセージだけがログに記録されるようになった。

CR086224

(NSAPI) プラグインが、POST データから SESSIONID を読み取らなかった。

分析の結果、getPreferredServersFromCookie() に問題があることがわかった。session.getId() が POST データとして保持されているとき、getId() に余分な文字列「|time」が含まれていた。

コードを修正してこの問題を解決した。

CR086490

(ISAPI) すべてのプラグインと HttpClusterServlet について、MaxSkips 機能が無効になっていた。これは、この機能のデフォルト値 10 では、この機能が意図したほど有効でないことが判明したためであった。この機能がないため、クラスタ内の 1 つ以上のサーバが応答できないときに、パフォーマンスが低下する可能性があった。

新しいパラメータ MaxSkipTime を設けることで、この問題を解決した。

MaxSkipTime を使用すれば、サーバを不良状態にしてから新しいサーバ リストを強制するまでの待機時間を秒単位で指定できる。

CR086518

(NSAPI) クエリ文字列とアンカーの両方を含む URL を使ってリダイレクトを行う場合、アンカーが、最後のクエリ文字列メンバの値部分の一部と誤って見なされていた。この問題は、3 層環境で Internet Explorer を使用し、HTTP サーバに対して iPlanet 6.0 を使用した場合にだけ発生した。Netscape や Mozilla を使用した場合、または2 層環境でサーバを実行した場合は、問題は発生しなかった。

複製するためには、foo.jsp を呼び出す。

foo.jsp:

<%

String redirectURL = "http://hostname/T/foo2.jsp?a=b#foo";;

response.sendRedirect(redirectURL);

%>

foo2.jsp:

<%= request.getParameter("a") %>

Administration Console では、「b」ではなく「a」に対する値が「b#foo」として、表示された。

クエリ文字列からアンカーを除去するようにコードを修正することで、この問題を解決した。Internet Explorer では、sendRedirected URL に対してこの処理が行われない。

CR088914

(NSAPI) CR088915を参照。

CR088915

CR088914

(ISAPI、NSAPI) SSL 証明書チェーン攻撃への弱さを緩和するための変更を行った。CA 証明書に対する BasicConstraints をチェックするコードを追加した。制約の検査は、プラグインのパラメータ EnforceBasicConstraints で制御される。パラメータの設定は以下のとおりである。

  • OFF - 本当に他の選択肢がないのでない限り、強制を完全に無効にすることは推奨されない。たとえば、顧客が商用 CA から証明書を購入しても、チェーンは新しい検査を渡さない。現在の商用 CA 証明書のほとんどは、デフォルトの STRONG 設定の下で動作しなければならないことに注意すること。

  • STRONG - V3 CA 証明書に対する BasicConstraints が検査されて、証明書が CA 証明書であることが検証される。デフォルトの設定である。

  • STRICT - STRONG レベルと同じ検査を行うが、さらに、IETF RFC 2459 も厳密に強制する。この RFC では、CA 証明書に対する BasicConstraints が「critical」としてマークされている必要もあると指定されている。RFC 2459 に厳密に従う場合は、このレベルに設定する。

この変更により、WebLogic Server 6.1 SP04 では発生しなかったセキュリティ例外が発生する可能性がある。たとえば、発信 SSL 呼び出しを行おうとした場合、リモート サーバ インスタンスによって提示される証明書に基本制約がないと、次のエラーが発生する。

<May 8, 2003 4:36:18 PM MDT> <Notice> <WebLogicServer> <SSLListenThread listening on port 7002> <May 8, 2003 4:36:19 PM MDT> <Notice> <Management> <Starting discovery of Managed Server... This feature is on by default, you may turn this off by passing -Dweblogic. <May 8, 2003 4:36:19 PM MDT> <Notice> <WebLogicServer> <Started WebLogic Admin Server "myserver" for domain "412253" running in Production Mode> EXCEPTION: Socket Closed java.io.IOException: Socket Closed at weblogic.security.SSL.SSLSocket.sendAlert(SSLSocket.java:1086) at...

このようなエラーは、プラグイン パラメータ EnforceBasicConstraints を false に設定することで避けることができる。コマンドラインで基本制約のチェックを無効にするには、次のコマンドを使用する。

-Dweblogic.security.SSL.enforceConstraints=false

CR089746

(NSAPI) WebLogic Server は次のようなシナリオをサポートしていた。

  • T3 を使用してアプリケーション サーバに接続するプラグイン (SSL セッション キャッシングなし、キープアライブなし)。

  • HTTPS を使用してアプリケーション サーバに接続するプラグイン (SSL セッション キャッシングなし、キープアライブなし)。ユーザは、プラグインと Weblogic Server の間の SSL セッションの再開を望んでいる。

ユーザは、T3 と HTTPS の両方について、プラグインと WebLogic Server の間の SSL セッション キャッシングとキープアライブのサポートを要求していた。

KeepAliveEnabled フラグと SSL セッション キャッシュを追加することで、この要求に応えた。

CR091635

(NSAPI) SP03 バージョンのプラグインは、次のようなリクエストの JVMID を解析できなかった。

2002 Found Encoded

Session=[JSESSIONID=9dq5Z081!805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES]

Thu Nov 21 15:16:09 2002 Parsing cookie

JSESSIONID=9dq5Z081!805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES

Thu Nov 21 15:16:09 2002 getpreferredServersFromCookie:

805492834!174332983!7001!7002?_JASPER=1000/r/1037920979629&PAGE=HOME_TEMPLATE&INTEGRATION=YES

Thu Nov 21 15:16:15 2002 parseJVMID: could not resolve hostname 'r', treating it as invalid

sessionid 全体ではなく「/」含むセッション クッキーの JVMID 部分をチェックするようコードを修正することで、この問題を解決した。

CR092756

(ISAPI) バックエンドから HTTP 503 の応答を受け取っても、ISAPI プラグインがフェイルオーバしていなかった。コードを修正し、この問題を解決した。

CR093196

(NSAPI) Web アプリケーションがクラスタにデプロイされていて、iPlanet プロキシ プラグインを通して JSP にアクセスすると、JSP の sendRedirect() が失敗した。

IE ブラウザでは「The page cannot be displayed...」というメッセージが返り、Netscape では「The document contained no data...」というメッセージが返った。

セカンダリ セッションの Null 値をチェックするようにコードを修正することで、この問題を解決した。

CR093530

(ISAPI) PathTrim の値で大文字と小文字が区別されていたため、大文字と小文字が区別されない URL を使ってクライアントがアプリケーションにアクセスできることが望ましい環境で問題が発生していた。

PathTrim の値について大文字と小文字を区別しないように変更することで、この問題を解決した。

CR093662

(NSAPI) 次のすべてに当てはまると、encodeRedirectURL() の呼び出しが失敗した。

(a) Web アプリケーションがクラスタに .war ファイルとしてデプロイされている。

(b) Web アプリケーションの JSP に、iPlanet プロキシ プラグインを通してアクセスする。

(c) JSP が、HTTP GET メソッドを使用する FORM で encodeRedirectURL() を呼び出す。

iPlanet Web サーバでコア ダンプが発生した。Internet Explorer ブラウザは「The page cannot be displayed...Cannot find server or DNS Error」を返し、Netscape は「The document contained no data... 1」を返した。

分析の結果、問題の原因は、クエリ文字列を切り捨てないで固定長バッファにプライマリまたはセカンダリの jvmid を格納していたことであった。

セッション クッキーを解析する前にクエリ文字列を切り捨てるようにコードを変更することで、この問題を解決した。

CR094109

(Apache) 応答時間が HungServerRecoverSecs で設定されている時間制限を超え、Indempotent プリミティブが オンになっていると、プライマリ サーバからのフェイルオーバが発生しなかった。

分析の結果、ap_proxy.cpp の例外処理ソース コードにおけるエラーに関する問題であることがわかった。

フェイルオーバのコードを書き直して、この問題を解決した。

CR094282

(NSAPI) WebLogicHostWebLogicPort、または WebLogicCluster にリストされているサーバが稼働していない場合、またはたとえば Solaris がシングル ユーザ モードで起動している場合、オペレーティング システムが接続をタイムアウトするまでプラグインがハングしていた。

デフォルトでは、このタイムアウトに長い時間がかかった。

新しいプラグイン パラメータ WLSocketTimeoutSecs を追加した。このパラメータを使用すると、マシンがダウンしていても長い遅延を避けることができる。デフォルト値は 2 秒である。この値は 0より大きくなければならない。

CR094663

CR095166と同じ問題および解決。

CR094768

(ISAPI) クッキーに対するポスト データの解析が、プラグインで正しく実装されていなかった。次のエラーが発生した。

"Bad request in the post data [NameField=aaaaa&ValueField=111111111111&AddValue=+Add+]"

UrlUnescape() メソッドが、正しくない戻り値の型を返し、application/x-www-form-urlencoded 以外の content-type に対するポスト データを解析していた。

コードを修正し、この問題を解決した。

CR095009

(ISAPI) プラグインが、適切なサーバ インスタンスの解決に成功していなかった。ログ ファイルに、「Primary JVMID not found in the server list, ignore preferred servers」というエラーが記録された。

分析の結果、getPreferredServersFromCookie() にエラーがあることがわかった。コードを修正し、この問題を解決した。

CR095558

(ISAPI) プラグインが、ブラウザからの読み取りの障害と、サーバに対する書き込みの障害を、正しく区別していなかった。クライアントとプラグインの間の障害の時にだけ接続アボート メッセージ (10053/10054) を処理するよう、コードを修正した。

CR095559

(Apache) プライマリ サーバがフェイルオーバした後、プラグインが、セカンダリ サーバのインスタンスを探して、プライマリ サーバで障害が発生したときに行っていたリクエストをセカンダリ サーバに送信するのではなく、引き続きプライマリ サーバのインスタンスを探していた。

フェイルオーバのコードを書き直して、この問題を解決した。

CR095166

(ISAPI) クライアントが複数のクッキーを送信すると IIS プラグインがクッキーを誤って解釈し、プラグインとプライマリ サーバ インスタンスの間の結び付きが確立されなかった。

分析の結果、文字列検査のロジックに誤りがあり、strstr() がセッション クッキー名を正しく解析していないことがわかった。

CR096625

(Apache) X_WEBLOGIC_FORCE_JVMID ヘッダーが、クラスタのサーバ インスタンスに送信されていた。

X_WEBLOGIC_FORCE_JVMID は、サーバ リストがクラスタではなく、現在のサーバがまだ jvmid を持っていないときにだけ、送信されなければならない。

コードを修正し、この問題を解決した。

CR097202

(すべてのプラグイン) 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-KeysizeWL-Proxy-Client-Secretkeysize という 2 つのヘッダーを新しく実装した。どちらのヘッダーの値も、request.getHeader() で取得できる。

CR096850

(NSAPI) 負荷テストアプリケーションがサーバに対して複数の接続を開こうとすると、Windows 2000 の下で稼働する iPlanet サーバがクラッシュした。iPlanet サーバは、サーバに対する接続を何回か試みた後でクラッシュした。

分析の結果、iPlanet サーバはアクセス違反のためにクラッシュし、MSVCRT!CxxThrowException を示していた。

例外を送出するのではなく例外を返して処理するよう sendResponse を修正することで、この問題を解決した。

CR100361

次の新しい例外タイプが追加された。

READ_ERROR_FROM_CLIENT - クライアントからのデータ読み取り時のエラー

READ_ERROR_FROM_SERVER - バックエンド サーバからのデータ読み取り時のエラー

READ_ERROR_FROM_FILE - POST データが格納されている一時ファイルからの読み取り時のエラー

WRITE_ERROR_TO_FILE - 一時ファイルへの POST データ書き込み時のエラー

CR101222

(NSAPI および Apache) プライマリ サーバ インスタンスがハングしたときのセカンダリ サーバ インスタンスへのフェイルオーバが、確実に行われなかった。プライマリ セッションとセカンダリ セッションを確立した後、request.getParameter("primary") がサーバ名と同じ場合、クライアントは、HungServerRecoverySecs の値より長くスリープしているリカバリ リクエストを送信していた。Web サーバは、プライマリ サーバがハングし、リクエストをセカンダリ サーバにフェイルオーバしていることを検出しなかった。

分析の結果、セカンダリ サーバが異常 (bad) とマークされていたため、プラグインがセカンダリ サーバをスキップし、一般サーバ リストを使用していたことがわかった。

MaxSkipTime の後でサーバを正常 (good) にリセットするようコードを修正し、この問題を解決した。

CR101428

(ISAPI) リクエストに複数のクッキーが含まれていて、名前が JSESSIONID ではないクッキーが JSESSIONID クッキーの後にあると、そのクッキーは取り除かれて、WebLogic Server に送付されなかった。

コードを修正し、この問題を解決した。

CR101596

(NSAPI) WebLogic Server 6.1 SP04 では、特定のエラー状態に対し、ssl_certchain_verify_callback() が誤って SSLNoErr を返した。

エラー状態が発生したときは X509CertChainInvalidErr を返すようにコードを修正し、この問題を解決した。

CR103126

(Apache) Linux 上で ssl128 用のプラグインを使って Apache を起動すると、次のエラーが発生した。

Cannot load /usr/local/apache/libexec/mod_wl_ssl128.so into server: /usr/local/apache/libexec/mod_wl_ssl128.so: undefined symbol: pthread_mutexattr_init

分析の結果、ビルドの問題であることがわかり、プラグインを再ビルドすることで解決した。

CR103161

CR097202」と同じ。

RMI-IIOP

変更要求番号

説明

CR090010

WebLogic Server 6.1 SP03 では、weblogic.ejbc で生成される多次元配列に対する BoxedRMI IDL ファイル seq2_seq1_octet.idl に、モジュール/パスの宣言 org.omg.boxedRMI が 2 回出現していた。

コードを修正して多次元 boxedRMI シーケンスに対する IDL 宣言を正しくすることで、この問題を解決した。

CR093988

WebLogic Server 6.1 SP04 では、ActiveX コンポーネントから IIOP を通して EJB にアクセスすると、WebLogic Server がハングした。スレッド ダンプは、Java 層におけるデッドロックを示していた。

この問題は、Red Hat Linux 7.2 および Windows 2000 での SUN JDK 1.3.1 で発生した。

分析の結果、ソケットを閉じる IIOP ソケット タイムアウト トリガがデッドロックの原因であることがわかった。

コードを修正して、このような状況の発生を防いだ。

CR100334

WebLogic Server 6.1 の旧リリースでは、引数を指定しないでメソッドをディスパッチすると、または戻り値の型が void のメソッドを呼び出すと、WebLogic Server が存在しない可能性のあるデータを読み取ろうとした。

7.0 SP2 から提供されるときはデータは存在せず、他のリリースについては、余分な (不必要な) データを提供することで 6.1 への対応を試みる。

CR100430

6.1 SP04 以前の WebLogic Server と WebLogic Server 8.1 を相互運用できなかった。6.1 と 8.1 のサーバ インスタンス間のトランザクションが、6.1 サーバ インスタンス上の ArrayIndexOutOfBoundsException でタイムアウトした。

この問題は、WebLogic Server 6.1 SP05 において解決した。

CR100334

このリリースでは、WebLogic Server 6.1 SP04 と WebLogic Server 7.0 SP02 の間の相互運用性の問題を解決した。

WebLogic Server 6.1 SP04 では、返された void のパラメータを誤って読み込もうとして UnmarshalException が発生した。 これは次の場合に発生した。

  • WebLogic Server 6.1 SP04 は WebLogic Server 7.0 SP02 サーバ インスタンスへの呼び出しの結果として、void の戻り値を受け取った。

  • 6.1 サーバ インスタンスにある引数のないメソッドが、WebLogic Server 7.0 SP02 サーバ インスタンスによって呼び出された。

この問題は他の ORB との相互運用性を妨げた。

RMI

変更要求番号

説明

CR096511

WebLogic Server 6.1 SP03 および SP04 では、InitialContext の作成とクローズを繰り返すと、メモリ不足のメッセージが発生した。

分析の結果、DGCServerHelper クラスでメモリ リークが発生していることがわかった。

記述子の dgcpolicy が「Managed」ではない場合にだけ LocalServerRef を登録するようコードを修正することで、この問題を解決した。

CR089481

WebLogic Server 6.1 SP03 では、クライアントが適切に閉じなかったクライアント JDBC 接続が、WebLogic Server によって閉じられず、ガベージ コレクションされなかった。

リモート クライアントが接続を適切に閉じなくても接続が正しく閉じられるようコードを修正することで、この問題を解決した。

注意: クライアントサイドのコードが接続を適切に閉じなければならない。WebLogic Server は閉じられていない接続を閉じるが、使用状況と分散ガベージ コレクションの動作によっては、処理に長い時間を要する場合がある。

CR100430

WebLogic Server 6.1 SP04 では、WebLogic Server 8.1 のサーバ インスタンスが WebLogic Server 6.1 SP04 サーバ インスタンスのクライアントになっていると、トランザクションがタイムアウトし、次の例外が発生した。

java.rmi.RemoteException: Exception while committing Tx: Name=[EJB weblogic.qa.tests.interop.ejb11.txcrossdomain.TravelPlannerBean.planItinerary_Required(java.lang.String,java.util.Properties)],Xid=BEA1-000147799CCFA039D1D7(2653792),Status=Committing,numRepliesOwedMe=0,numRepliesOwedOthers=0,seconds since begin=120,seconds

コードを修正し、この相互運用性に関する問題を解決した。

セキュリティ

変更要求番号

説明

CR090101

WebLogic Server は証明書チェーンの各証明書が認証局によって発行されたことを保証していなかった。 この問題は、誰かが信頼性のある認証局から個人用証明書を取得し、その証明書を使用して他の証明書を発行しても、WebLogic Server は無効な証明書を検出できないことを意味した。 このリリースでは、WebLogic Server で使用するすべての X509 V3 CA 証明書は CA として定義される基本制御拡張を備えている必要がある。このため、証明書チェーンのすべての証明書が認証局によって発行されたことが保証される。 デフォルトでは、この条件を満たしていない認証局の証明書は拒否される。 証明書検証に合格しない証明書チェーンを持つ WebLogic Server が起動された場合、クライアントでそれを拒否できることを示す情報メッセージがログに記録される。

詳細については、「S 」を参照。

CR051018

WebLogic Server の以前のリリースでは、システム パスワードが暗号化されないで保管されていた。パスワードを暗号化して password.ini に格納するようにした。

注意: password.ini は、WebLogic Server バージョン 7.0 で使用されている boot.properties ファイルにはアップグレードできない。

CR100592

IPlanet LDAP レルムがユーザを無効にした後、WebLogic Server 6.1 SP04 が使用できなくなった。この問題は、次のイベントのシーケンスで発生した。

サーバで LDAP レルムを起動する。フォーム認証を使用する Web アプリケーションをデプロイする。LDAP レルムの任意のユーザについて、ユーザ ロックアウトしきい値に達するまで不正なパスワードを使用する。クライアントは 500 番のエラーを受け取り、サーバでは次のエラーが発生する。

<Mar 9, 2003 7:17:22 PM PST> <Error> <HTTP> <[WebAppServletContext(3017390,security,/security)] Servlet failed with Exception netscape.ldap.LDAPException: error result (19); Exceed password retry limit. Please try later.; Constraint violation

このエラーの後、サーバは認証に関して使用できない状態になった。たとえば、ほかのユーザは Web アプリケーションにログインできず、Console にもアクセスできなかった。

ユーザが無効なパスワードを入力したときの LDAP 例外を検査するようコードを修正し、この問題を解決した。

サーブレット

変更要求番号

説明

CR077922

テストにおいて、セッション バインディング リスナ (HttpSessionBindingListener) の valueBound() メソッドと valueUnBound() メソッドを 1 回だけ呼び出しても、実際にはメソッドが 2 回以上呼び出されていた。

メソッドを重複して呼び出さないようコードを修正した。

CR083624

config.xmlWebServer 要素に、新しいコンフィグレーション パラメータ UseHighestCompatibleHTTPVersion を追加した。このパラメータを指定すると、WebLogic Server は、リクエストで使用されているバージョンと互換性があって最も高いバージョンの HTTP プロトコルを使って、応答を送信する。たとえば、このパラメータを true に設定すると、HTTP/1.0 のリクエストに対して HTTP/1.1 で応答する。このパラメータは、応答のバージョン文字列の部分に対してだけ影響を与える。WebLogic Server 6.1 では、デフォルトの設定は false である。

このパラメータの値は、config.xml を編集することで変更できる。Administration Console には、このパラメータの値を変更するためのインタフェースはない。

CR086579

ポート 80 でリスンする iPlanet を通して、フォーム ベースの認証で NSAPI プロキシ プラグインを使用すると、j_security_check がリダイレクトを正しく行わず、認証が失敗した。

分析の結果、デフォルトのポートを使用した場合、フォーム ベース認証モジュールが processRedirectedURL を呼び出していなかった。

CR086587

WebLogic Server 6.1 SP03 では、Web サーバ ログ (access.log) と JDBC サブシステム ログ (jdbc.log) が、RootDirectory ではなく、製品のインストール ディレクトリを基準にして作成されていた。

コードを修正し、この問題を解決した。

CR087573

WebLogic Server 6.1 SP01 では、セッションに対して JDBC 永続性を使用し、ネストされた hashMapsTreeMaps を含む複雑なオブジェクトを格納した場合、セッションが永続化される前に後続のリクエストが届くと、セッション データが失われた。

removeSession(id)FileSessionContext.javamethod sync() の最後に移動することで、この問題を解決した。

CR087647

CR055987」に関する修正で、接続が解放されない問題を解決するためのタイムアウトを導入した。この修正で追加された InterruptedIOException が処理されていなかった。例外が発生すると、不要な再試行が行われていた。

InterruptedIOException をキャッチし、例外を送出し直して再試行を防ぐようにコードを修正することで、この問題を解決した。

CR087984

WebLogic Server 6.1 SP02 では、HttpSessionListener の前に ServletContextListener が呼び出されていた。2.3 サーブレット仕様に従えば、コンテキスト リスナがアプリケーションのシャットダウンの通知を受ける前に、セッション リスナはセッション無効化の通知を受けなければならない。

仕様に準拠するようコードを修正した。

CR088166

WebLogic Server 6.1 SP03 では、Web アプリケーションが、見つからないファイルの名前を示さずに java.lang.ClassNotFoundException を生成していた。

<[WebAppServletContext(4730538,olam,/olam)] Error loading servlet: ""> java.lang.ClassNotFoundException:

分析の結果、WebLogic Server が auth-filter タグに対する Null または空の文字列値を正しく処理していないことがわかった。コードを修正し、この問題を解決した。

CR088350

HttpProxyServlet を使って KnowNow からサードパーティのイベント サーバに対するプロキシ処理を行うと、Internet Explorer 6 が応答しないまま無限に待っていた。

分析の結果、KnowNow サーバについて次のことがわかった。

  • HTTP 1.0 のリクエストに対してのみ応答する。

  • ContentLength を送信しない。

コンテンツ長がなく、データがチャンク転送されていない場合、WebLogic Server はストリームの最後まで読み取る。KnowNow サーバがデータを送信し続けると、HttpProxyServlet はデータを読み続ける。

新しいコンフィグレーション パラメータ UseKnowNow を導入することで、この問題を解決した。このパラメータを指定すると、HttpProxyServlet の動作は次のようになる。

  • バイト単位で読み書きする。

  • HTTP/1.0 を使用して KnowNow にリクエストを送信する。

このパラメータを使用するには、Web アプリケーション HttpClusterServlet に対する web.xml に次の構文を追加する。

<init-param> <param-name>UseKnowNow</param-name> <param-value>true</param-value> </init-param>

CR088384

WebLogic Server 6.1 SP02 では、HttpServletRequest からの getContextPath が不正な値を返した。例を示す。

http://localhost//webapp/foo

上のようなリクエストに対し、getContextPath は次の値を返した。

/webap

コードを修正し、この問題を解決した。

CR088478

HttpClusterServlet およびすべてのプラグインに対する MaxSkips パラメータが使われなくなり、MaxSkipTime パラメータに置き換えられた。

このパラメータを指定すると、次のような処理が行われる。

  • プラグインは、サーバを「不良 (bad)」とマークすると、その時刻を記録する。

  • 不良サーバは、MaxSkipTime に達するまでロード バランシング サイクルにおいてスキップされる。

  • その後、新しいサーバ リストが強制される。

CR088747

weblogic.xmlCookiePath を明示的に設定していない Web アプリケーションに対するリクエストの後で、WebLogic Server セッションを確立し直そうとすると、セッションが失われた。

分析の結果、ブラウザ (IE6) が、次のような異なるパスを含む 2 つのセッション クッキーを返していた。

  • パスとして /webapp の設定された JSESSIONID

  • パスとして / の設定された JSESSIONID

J2EE によれば、ヘッダー内の複数のクッキーは、Path 属性が限定的なものから一般的なものの順に並んでいなければならない。WebLogic Server は、パフォーマンスの理由で、JSESSIONID に対するクッキーの並びを逆に検索していた。そのため、より限定的ではないパスの方を検出していた。

ヘッダー内の最初のクッキーを使うようにコードを修正することで、この問題を解決した。

CR088759

WebLogic Server 6.1 SP03 では、redirect-with-absolute-url = falsej_security_check に対して機能しなかった。

これは、j_security_check が絶対パスを格納し、sendRedirect() メソッドにそれを渡していたためであった。

j_security_checkredirect-with-absolute-url を認識しなければならなかった。

redirect-with-absolute-url の設定に従って FormSecurityModule のリダイレクト リクエストを行うよう、コードを修正した。

CR089582

Solaris 8 の WebLogic Server 6.1 SP03 では、Host ヘッダー フィールドのない HTTP/1.1 リクエストを受け取ると、WebLogic Server は「Date: Thu, 01 Jan 1970 00:00:00 GMT」という値の Date ヘッダー フィールドを返していた。そのため、不正なリクエストがいつ生成されたのかを特定できなかった。

不正リクエスト エラーを送信する前にリクエスト生成時刻を設定するようにコードを修正して、この問題を解決した。

CR089868

WebLogic Server 6.1 サービス パック 3 で行われたパフォーマンスの改善 ( 083654を参照) により、マルチバイトのヘッダが壊れるようになった。対応策はあるが、SP03 と SP04 では対応策を適用するためにはパッチが必要である (詳細については 089868を参照)。

SP05 では、CR089868 のパッチを適用する必要はなくなった。

CR090033

WebLogic Server 6.1 SP03 では、WL-Proxy-SSL ヘッダーが Host ヘッダーより前にあると、リクエストの解析において Null ポインタ例外が送出された。この現象は、クライアントが HTTPS で動作し、SSL アクセラレータ、IPlanet、および WebLogic Server が HTTP で動作すると発生した。この問題は、コンフィグレーションに SSL アクセラレータが含まれているときにだけ再現した。

java.lang.NullPointerException at weblogic.servlet.internal.ServletRequestImpl.setField(ServletRequestImpl.java:1903) at weblogic.servlet.internal.RequestParser.parse(RequestParser.java:254) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch(MuxableSocketHTTP.java:390) at weblogic.socket.MuxableSocketDiscriminator.dispatch(MuxableSocketDiscriminator.java:275) at weblogic.socket.NTSocketMuxer.processSockets(NTSocketMuxer.java:633) at weblogic.socket.SocketReaderRequest.execute(SocketReaderRequest.java:23) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:152) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:133)

このエラーは、リクエストが解析中でコンテキストがまだわからず、コンテキストが Null であるために発生した。WL-Proxy-SSL が、HOST ヘッダーより前にあった。

コードを修正し、この問題を解決した。

CR090188

WebLogic Server 6.1 SP03 では、チャンク データ転送の場合、転送されるデータの前にチャンク サイズが付加され、転送されるデータに余分な文字が追加されていた。

setChunking を、ServletRequestImplmergePostParams から request.setInputStream の後の MuxableSocketHttp に移動することで、この問題を解決した。

この変更により、サーブレットと JSP はチャンク データをデコードする必要がなくなった。WebLogic Server のサーブレット エンジンが、チャンク データを自動的にマージする。

CR090225

テストの際、デバイス ドライバが HTTP を使ってリクエストを行うようにすると (request.aux.%2a.jsp または aux.*.jsp)、リクエストを処理するスレッドがハングした。

JSPServlet のコードを修正して、この問題を解決した。上で名前を挙げたデバイス ドライバはすべて、長さ 0 のファイルとして扱われるようになった。WebLogic Server は、この種のファイルを読み込まずに提供する。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-14.jsp の「SECURITY ADVISORY (BEA03-14.05)」を参照すること。

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

X_WEBLOGIC_CLUSTER_HASH をチェックした WebLogic Server が、HttpClusterServlet に対して Null ポインタ例外を送出していた。スタック トレースは、以下のような内容であった。

<Tue Nov 05 15:58:00 PST 2002>: Start connection timeout scheduler <Tue Nov 05 15:58:00 PST 2002>: GenericProxyServelt: init() <Tue Nov 05 15:58:00 PST 2002>: HttpClusterServlet:init() <Tue Nov 05 15:58:00 PST 2002>: ===New Request===GET /base;JSESSIONID=9G8ZGUTNwnNTXm8B5V5z41e hG0T3oChTPvhnXe7EHCZ1IQI5lgF4!822557425 HTTP/1.1 <Tue Nov 05 15:58:00 PST 2002>: Found cookie: 822557425 <Tue Nov 05 15:58:00 PST 2002>: Trying to get JVMID id from server: coolant!7003!443 <Tue Nov 05 15:58:00 PST 2002>: Update dynmaic hash: WakHYk8LlxQ7XrnhkSXEohfZMAw <Tue Nov 05 15:58:00 PST 2002>: java.lang.NullPointerException at weblogic.servlet.proxy.HttpClusterServlet.initDynamicServerList(HttpClusterServlet .java:761) at weblogic.servlet.proxy.HttpClusterServlet.getPreferred(HttpClusterServlet.ja va:622 ) at weblogic.servlet.proxy.HttpClusterServlet.service(HttpClusterServlet.java:21
分析の結果、応答のヘッダーがランダムな順序で HashMap に格納されていることがわかった。ハッシュを設定する前にサーバ リストを設定するよう、コードを修正した。

CR090665

WebLogic Server 6.1 SP03 では、サーブレット フィルタは、chain.doFilter() を呼び出してクライアントに応答を送信した後、応答ラッパーに対して flushBuffer() を明示的に呼び出さなければならなかった。そのため、アプリケーション サーバ別に異なるフィルタを作成する必要があった。そうしないと、応答にデータが含まれなかった。この問題は、printWriter の OutputStreamWriter オブジェクトにデータがバッファリングされていたために発生した。

ユーザ コードが flushBuffer() を明示的に呼び出す必要がないように、コードを修正した。

CR091410

HTTP ログ オプションで「拡張フォーマット」を選択し、サーバを再起動すると、次のような Null ポインタ例外が送出された。

<Oct 9, 2002 6:45:48 PM PDT> <Error> <kernel> <000802> <ExecuteRequest failed

java.lang.NullPointerException

java.lang.NullPointerException

ファイル名が Null の場合は access.log ファイルを開くようにコードを修正して、この問題を解決した。

CR091759

RequestDispatcher.forward が、URL ヘッダーの最後にあるバージョン番号を除去していた。転送されるリクエストでは、次のように記述されていなければならない。

Request URI: /RequestDispatcher/SnoopServlet/myTest.txt;37

実際には、次のような記述が転送されていた。

Request URI: /RequestDispatcher/ProxySnoopServlet/myTest.txt

forward() を行うときは setRequestURI()processPathParameters を false に設定するようにコードを修正して、この問題を解決した。

CR091878

負荷テストの間に HttpClusterServlet をアンデプロイすると、.IndexOutOfBoundsException が発生した。

<Nov 27, 2002 4:05:11 PM PST> <Error> <HTTP> <101268>

<ServletContext(id=5220998,name=proxywebapp,context-path=): Failed while destroying servlet:

java.lang.IndexOutOfBoundsException: Index: 2, Size: 2

IndexOutOfBoundsException while destroying HttpClusterServlet

分析の結果、pool.remove(i) で接続プールの最後の要素を削除するときにエラーが発生していた。

コードを修正して、この問題を解決した。

CR092255

WebLogic Server 6.1 SP04 では、クッキーの値に引用符 (") が含まれている場合、引用符が無視されていた。次に例を示す。

Cookie cookieWithQuotedValue = new Cookie("TestQuotedCookie", "¥"TestValue¥"");

このような構文では、「"TestValue"」ではなく「TestValue」がクッキー値として追加されていた。

クッキー値内の引用符を残すようにコードを修正した。

CR092428

WebLogic Server 6.1 SP04 では、Netscape のクッキーにカンマ (,) が含まれていると、「Got bad cookie header」 (クッキー ヘッダー不正) というエラー メッセージが表示された。

コードを修正して、この問題を解決した。

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 は、入力ストリームに対してだけ使用できる。

コードを修正し、この問題を解決した。

CR093167

WebLogic Server 6.1 SP03 では、HTTPClusterServlet を使ってバックエンド クラスタのセキュアな Web アプリケーションにアクセスすると、ユーザ名とパスワードを入力した後で、Internet Explorer 5.5 が 30 秒間ハングした。この問題は他のブラウザでは再現せず、プラグインを介さないでバックエンド サーバに直接アクセスすると、Internet Explorer でも発生しなかった。

この問題は、サーバから Connection: Close ヘッダーを受け取ったときに Internet Explorer が接続を閉じないために発生していた。WebLogic Server に直接アクセスしたときは、401 エラーを送出した時点で WebLogic Server が接続を閉じていた。しかし、HttpProxyServlet を介したときは、バックエンド サーバが接続を閉じても、ブラウザと ProxyServlet の接続が維持されていた。

バックエンド サーバから Connection: Close ヘッダーが返されたときはフロントエンドの接続がキープ アライブを無効にするように GenericProxyServlet のコードを修正して、この問題を解決した。これにより、Internet Explorer は、WebLogic Server で接続がタイムアウトになるまで待つのではなく、認証の詳細を直ちに返送するようになった。

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 値をチェックするロジックを追加して、この問題を解決した。

CR093634

WebLogic Server 6.1 SP03 では、HttpRequest.getRemoteAddr() メソッドが、クライアント ブラウザの IP アドレスではなく、HttpClusterServlet の IP アドレスを返した。

分析の結果、HttpClusterServlet が固有のヘッダー「WL-Proxy-Client-IP」を設定せず、代わりにソケットがリスンしている IP アドレスを返していることがわかった。

WebLogic Plugin Enabled パラメータが有効になっている場合は「WL-Proxy-Client-IP」ヘッダーを設定するように HttpClusterServlet を修正して、この問題を解決した。

CR093755

次のエラー メッセージが誤って生成されていた。

<Warning> <HTTP> <WebAppServletContext(5294080,blue,/blue) One of the getParameter family of methods called after reading from the ServletInputStream, not merging post parameters>

メッセージが誤って生成されないようコードを修正した。

CR094488

HTTP を使って開始されたセッションにおいてセッション データを失うことなく HTTPS リソースに安全にアクセスできるようにする、新しい機能を追加した。この新機能を有効にするには、config.xmlWebServer 要素に AuthCookieEnabled="true" を追加する。

<WebServer Name="myserver" AuthCookieEnabled="true"/>

この設定を追加すると、HTTPS 接続を通して認証を行った時点で、新しいセキュアなクッキーがブラウザに送信される。また、このクッキーがブラウザから送信された場合にだけ、セッションは、セキュリティ制約のある他の HTTPS リソースにアクセスできる。

注意: 普通の HTTP を通して認証が行われた場合は、セキュアなクッキーは設定されず、HTTPS リソースに対してセキュアなクッキーが要求されることはない。保護されていない HTTPS リソースへのアクセスでは、クッキーは検査されない (ブラウザから送信されていないため)。これにより、ブラウザは、ユーザがログインしていなくても、保護されていない HTTPS リソースにアクセスできる。

CR094773

CR094561」と同じ。

WebLogic Server 6.1 SP02 では、アプリケーションがインメモリ セッション レプリケーションまたはレプリケートされたステートフル セッション Bean を使うと、2 人のユーザの間でセッション データを共有できてしまうという、潜在的なセキュリティの弱点が発見された。この障害の原因は、競合状況の結果として 2 つのセッションに同じ ROID (レプリカ可能オブジェクト ID と呼ばれる内部 ID) が割り当てられるためであった。たとえば、セッション A に ROID が割り当てられた後、セッション B に同じ ROID が割り当てられる。すると、それ以降のセッション B のリクエストはすべて、A の HTTP セッション/SFSB にマップされる。HTTP セッションが混じり合うと、セッション B のユーザがセッション A のコンテンツを見ることができた。この問題が発生する可能性は非常に低く、意図的に利用することはできなかった。

ROID.create() の同期を取るようにコードを修正し、重複する ROID が複数のセッションに割り当てられないようにすることで、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-26.01.jsp の「SECURITY ADVISORY (BEA03-26.01)」を参照すること。

CR094997

WebLogic Server SP02 では、対話する 2 つの Web アプリケーションが異なるセッション クッキー名を使用すると、セッション ID が失われた。

分析の結果、Web アプリケーションで cookieName が指定されていて、別の Web アプリケーションからのリソースがインクルードされており、リクエスト中で外部リソースのインクルードより前に RemoteUser が存在していると、セッション属性が正しく更新されないことがわかった。

コードを修正して、この問題を解決した。

CR095548

テストにおいて、永続性タイプが JDBC のとき、セッション データがときどき失われた。次の例外が発生した。

weblogic.qa.tests.cluster.webapp.plugins.RequestSessionBeforeInvalidateTest.testRequestSessionBeforeInvalidationTest()

Session Was Invalidated

Sent: http://qa47-1:7771/pluginsjdbc/SessionBeforeInvalidate.jsp?count=1

Received: <html><body>PROBLEM: session is not the same as the first

request!FirstRequest sid:

2tjgF02nPIGgHGyojFubyOIjqt0ZAVK4no1Ny0afTxGKMrOj25z5!2356550501043194848402Sid

isRequestedSessionIdValid() メソッドのコードを修正し、この問題を解決した。

CR095570

WebLogic Server 6.1 SP04 では、サーブレットの HTTP ヘッダーに Null 値が設定されていると、NullPointerException が送出された。

<Jan 22, 2003 11:11:53 AM KST> <Error> <Kernel> <Execute Request failed java.lang.NullPointerException: Start server side stack trace: java.lang.NullPointerException at weblogic.servlet.internal.ResponseHeaders.writeHeaders(ResponseHeaders.java:360) at weblogic.servlet.internal. ServletResponseImpl.writeHeaders(ServletResponseImpl.java:902) at weblogic.servlet.internal.ServletOutputStreamImpl. sendHeaders(ServletOutputStreamImpl.java:239) at weblogic. servlet.internal.ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121) at weblogic.servlet.internal. ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:484) at weblogic.servlet.internal.ServletOutputStream Impl.finish(ServletOutputStreamImpl.java:531) at weblogic. servlet.internal.ServletResponseImpl.send(ServletResponseImpl.java:1091) at weblogic.servlet.internal.Servlet RequestImpl.execute(ServletRequestImpl.java:2364) at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139) at weblogic.kernel.ExecuteThread.run(ExecuteThread. java:120) End server side stack trace at weblogic.servlet. internal.ResponseHeaders.writeHeaders(ResponseHeaders.java:360) at weblogic.servlet.internal.ServletResponseImpl. writeHeaders(ServletResponseImpl.java:902) at weblogic. servlet.internal.ServletOutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:239) at weblogic.servlet.internal. ServletOutputStreamImpl.flush(ServletOutputStreamImpl.java:121) at weblogic.servlet.internal.ServletOutputStream Impl.commit(ServletOutputStreamImpl.java:484) at weblogic.servlet.internal.ServletOutputStreamImpl.finish(ServletOutputStreamImpl.java:531) at weblogic.servlet.internal. ServletResponseImpl.send(ServletResponseImpl.java:1091) at weblogic.servlet.internal.ServletRequestImpl.execute(ServletRequestImpl.java:2364) at weblogic.kernel.ExecuteThread. execute(ExecuteThread.java:139) at weblogic.kernel.Execute Thread.run(ExecuteThread.java:120)

ResponseHeaders.java の Null 値をチェックするロジックを追加することで、この問題を解決した。

CR096459

WebLogic Server 6.1 SP02 にデプロイされた Web アプリケーションに対し、flushRes=true が設定された HTTP Version 1.0 を使用するブラウザからアクセスしたときの応答時間に問題があった。この問題は、flushRes=false の場合には発生しなかった。

分析の結果、useKeepAlive が誤って再初期化されていることがわかった。閉じられなければならないソケット接続が閉じられず、クライアントはソケットのタイムアウトを待っていた。

リクエストと応答を設定するときに useKeepAlive を初期化するよう、コードを修正した。

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 ...

分析の結果、文字セットがリクエストの content-type と関連付けられていると、アプリケーションにおいて、コードがエンコーディングを使ってデータを再び読み取り、クエリのパラメータをリセットしていることがわかった。アプリケーションは既に列挙オブジェクトを持っており、それ (request.getParameterNames) に対して反復を行って、パラメータの値 (request.getParameterValues(k)) を取得しようとした。その時点で、クエリのパラメータは消去されており、getParameterValues メソッドがそれを設定しようとした結果、例外が発生した。

文字セットがリクエストの content-type と関連付けられていてもデータを再び読み取ることができるよう、消去されたクエリ パラメータを設定するようにコードを修正して、この問題を解決した。

CR098955

weblogic.httpd.logRotationBeginTime に過去の日付が設定されていると、WebLogic Server HTTP サーバ ログに対して設定されているログ ローテーション時間が正しく計算されなかった。

INT から LONG への計算で使用されるオペランドのデータ型を変更することで、この問題を解決した。

CR099984

サーブレットのコードが入力ストリームにアクセスできるようになる前に、サーブレット エンジンが入力ストリームを使用していた。内部読み取りが入力ストリームを使用しないようコードを修正し、この問題を解決した。

CR100265

受信したリクエストにクッキーがなくても、有効な資格が含まれている場合には、WebLogic Server は保護されたリソースへのアクセスを許可しなければならない。しかし、アクセスは許可されず、次の例外が発生していた。

java.lang.NullPointerException at weblogic.servlet.security.internal.SecurityModule.checkAuthCookie(SecurityModule.java:579) at weblogic.servlet.security.internal.BasicSecurityModule.checkUserPerm(BasicSecurityModule.java:157) at ...

コードを修正し、この問題を解決した。

CR100572

正しくない URI を含むリクエストをプラグインから受信すると、WebLogic Server は次のスタック トレースを送出していた。

<Mar 8, 2003 3:27:20 PM PST> <Error> <Socket> <BEA-000421> <Uncaught Throwable i n processSockets java.lang.NullPointer Exception. java.lang.NullPointerException at weblogic. servlet.internal.ServletResponseImpl.writeHeaders(ServletResponseImpl.java:968) at weblogic.servlet.internal.Servlet OutputStreamImpl.sendHeaders(ServletOutputStreamImpl.java:244) at weblogic.servlet.internal.ServletOutputStreamImpl. flush(ServletOutputStreamImpl.java:121) at weblogic.servlet. internal.ServletOutputStreamImpl.commit(ServletOutputStreamImpl.java:486) at weblogic.servlet.internal.ChunkOutput. commit(ChunkOutput.java:269) at weblogic.servlet.internal. ChunkOutputWrapper.write(ChunkOutputWrapper.java:91) at weblogic.servlet.internal.ChunkWriter.write(ChunkWriter.java:37) at java.io.Writer.write(Writer.java:150) at java.io.PrintWriter.write(PrintWriter.java:230) at java.io.PrintWriter.write(PrintWriter.java:247) at java.io.PrintWriter.print(PrintWriter.java:378) at weblogic.servlet.internal.ServletResponseImpl.sendError(ServletResponseImpl.java:420) at weblogic.servlet.internal. ServletResponseImpl.sendError(ServletResponseImpl.java:373) at weblogic.servlet.internal.MuxableSocketHTTP.dispatch (MuxableSocketHTTP.java:512) at weblogic.socket.MuxableSocket Discriminator.dispatch(MuxableSocketDiscriminator.java:281) at weblogic.socket.NTSocketMuxer.processSockets(NTSocket Muxer.java:102) at weblogic.socket.SocketReaderRequest. execute(SocketReaderRequest.java:32) at weblogic.kernel. ExecuteThread.execute(ExecuteThread.java:178) at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:151)

コードを修正し、この問題を解決した。

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 でチャンクの終わりを正しく検出するようコードを修正して、この問題を解決した。

CR100837

WebLogic Server 6.1 SP04 が、JSP ページの JSP includes に対して出力を誤って送っていた。

コードを修正し、この問題を解決した。

WLS ツアー/サンプル

変更要求番号

説明

CR087117

WebLogic Server 6.1 SP04 では、ユーザがパスワードを入力する前に管理サーバ、Pet Store サーバ、および Example サーバを起動すると、パスワード エラーが発生した。

Starting WebLogic Server ....

<Oct 1, 2002 9:22:10 AM EDT> <Notice> <Management> <Loading configuration file .\config\petstore\config.xml ...>

<Oct 1, 2002 9:22:13 AM EDT> <Emergency> <Security> <Authentication failure - reenter password to boot weblogic server:>

コードを修正し、この問題を解決した。

CR087366

WebLogic Server 6.1 SP04 では、サンプル サーバのインデックス ページ (index.jsp) の [WebLogic Server サンプル索引] リンクが機能しなかった。リンクをクリックすると、次のメッセージが表示された。

"Netscape is unable to find the file or directory named
/D:/bea61. Check filename and try again.

分析の結果、WebLogic Server のインストールで使用さ3れた BEAHOME に空白文字が含まれていた。

index.jsp の関係する href に二重引用符を追加して BEAHOME の空白文字を許容することで、この問題を解決した。

CR090776

WebLogic Server 6.1 SP04 から WebLogic Server 8.1 へのアップグレードの際に、Pet Store アプリケーションをデプロイするとエラーが発生した。

分析の結果、デプロイメント記述子に EJB の参照がないことがわかった。この参照がないことは、WebLogic Server 8.1 では捕捉されたが、WebLogic Server 6.1 では捕捉されなかった。

Pet Store のデプロイメント記述子を修正して、この問題を解決した。

CR092881

Unix AIX 上の WebLogic Server 6.1 SP04 では、ユーザが StartPetStore.sh を使って PetStore を開始しようとすると、次のエラーが発生した。

java.lang.SecurityException: Unable to locate a login configuration.

StartPetStore.sh を修正して、この問題を解決した。

CR096147

WebLogic Server のサンプル simpFML32 では、dom1config に対して dmloadcf が失敗した。

分析の結果、*DM_LOCAL_SERVICES に次の記述が含まれていた。

*DM_LOCAL_SERVICES

REVERSE_STRING RDOM="TDOM1"

これは誤りで、次が正しい記述である。

*DM_LOCAL_SERVICES

REVERSE_STRING LDOM="TDOM1"

Tuxedo のコンフィグレーション ファイル dom1config のエラーを修正し、ローカル ドメイン TDOM1 で提供されるローカル サービス REVERSE_STRING を Tuxedo がエクスポートできるようにした。

CR102138

SSL クライアント サンプルのドキュメントが正しくなかった。WL_HOME\lib\cacertsJAVA_HOME\jre\lib\security\jssecacerts にコピーするように指示されていた。

指示を修正し、sslclient サンプル ディレクトリに jssecacerts ファイルを追加し、JSSE サンプルに対する指示にサンプル出力を追加することで、この問題を解決した。

Web サービス

変更要求番号

説明

CR087529

WebLogic Server 6.1 SP03 では、samples\examples\webservices\rpc\weatherEJB のサンプル Web サービスに対するクライアントは、wsgen でビルドされ、weblogic.jar ではなく client.jar だけを使ってデプロイされていた。Java クライアントが非 SSL の Web サービスを呼び出すと、次の例外が送出された。

<< 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 にこのクラスを含める必要があることがわかった。

client.jarweblogic.net.http.HttpsURLConnection を追加して、この問題を解決した。

CR091862

WebLogic 6.1 SP04 では、XML ドキュメントの DTD 部分を使うと、XML パーサに CPU やメモリを大量に使用させることができた。

XML ドキュメントの DTD 部分を使うと、ドキュメントで名前付きのエンティティを定義できる (定義済みの &lt;、&gt; などは除く)。エンティティは、他のエンティティを使って定義できる (再帰指定は XML 1.0 では禁止されている)。エンティティは、参照されると、XML ドキュメント内で展開される。攻撃は、あるエンティティを定義して参照するという方法で行われる。このエンティティは、別のエンティティの 2 つのインスタンスを使って定義されていて、それがさらに別のエンティティの 2 つのインスタンスによって定義される、ということが繰り返される。この定義プロセスは必要な長さだけ繰り返すことができ、通常は、100 レベルのネストで十分である。100 番目のエンティティは、単に文字列として定義しなければならない。このような定義は、理論的には、最初のエンティティに 100 番目のエンティティの値を 2^99 (2 の 99 乗) 個連結したものが含まれているのと同じ影響を及ぼす。

次に例を示す (DTD は、XML 宣言の後、XML ドキュメントの root 要素の前に置く)。

<!DOCTYPE root [

<!ENTITY x100 "foobar">

<!ENTITY x99 "&x100;&x100;">

<!ENTITY x98 "&x99;&x99;">

<!ENTITY x97 "&x98;&x98;">

...

<!ENTITY x3 "&x4;&x4;">

<!ENTITY x2 "&x3;&x3;">

<!ENTITY x1 "&x2;&x2;"> ]>

アプリケーションがドキュメント内にあるこの最初のエンティティを参照すると (&x1; という構文を使って)、ドキュメントのそれ以外の部分には問題がなくても、このエンティティを展開するために XML パーサが非常に大きな CPU 負荷またはメモリ負荷を必要とするため、結果として DoS 状態が発生する。

コンフィグレーション可能なシステム プロパティ weblogic.apache.xerces.maxentityrefs を新しく追加することで、この問題に対処した。

このプロパティの使用方法は、次のとおりである。

java -Dweblogic.apache.xerces.maxentityrefs=10000

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-23.jsp の「SECURITY ADVISORY (BEA02-23.01)」を参照すること。

CR095044

Web サービスの動作が例外を送出した場合、<SOAP-ENV:Fault> 要素の内容とセマンティクスを示すために org.apache.soap.Fault が使用されるとき、Fault.getDetailEntries() メソッドの呼び出しは例外の Vector を返さなければならない。

WebLogic 6.1 SP03 では、これとは異なり、このメソッド呼び出しは Null を返し、クライアントは例外のスタック トレースを見ることができなかった。SP02 では、この問題は発生しなかった。

クライアントは、WebLogic 6.1 SP02 または WebLogic 6.1 SP03 のサーバ インスタンスにアクセスする際、同じ CLASSPATH で動作する。問題は、次のようなクライアント CLASSPATH で再現した。

CLASSPATH=.;.\soap.jar;.\xerces.jar;.\j2ee.jar

動作の違いは、SP03 では、障害の詳細の内容が <![CDATA[ ]]> の中にラップされていることである。これは、スタック トレースに次のような内容が含まれる場合のパーサでの障害を防ぐために行われている。

<<no stacktrace available>>

新しいサーブレット初期化パラメータ cdata-fault-detail を追加することで、この問題を解決した。このパラメータを false に設定すると、障害の詳細は <![CDATA[ ]]> にラップされなくなる。

<servlet> ... <servlet-class>weblogic.soap.server.servlet.StatelessBeanAdapter</servlet-class> <init-param> <param-name>cdata-fault-detail</param-name> <param-value>true</param-value> </init-param> ...

cdata-fault-detail を false に設定した場合は、スタック トレースに次のような記述が含まれると、パーサ エラーが発生する。

<<no stacktrace available>>

CR096906

WebLogic 6.1 SP04 では、WebLogic Server によって生成された Web サービスが呼び出されたとき、dateTime エントリが正しく返されなかった。タイム ゾーン オフセットが正の時 (たとえば、GMT+1 = CET (デンマークのタイム ゾーン))、dateTime エントリのタイム ゾーン オフセット部分の「+」文字が省略されていた。次に例を示す。

CET の 2003 年 2 月 3 日 9 時 12 分 4 秒は、dateTime では次のように表記されなければならない。

<date xsi:type="xsd:dateTime">2003-02-03T09:12:04.000+01:00
</date>

Weblogic では、次のように表記されていた。

<date xsi:type="xsd:dateTime">2003-02-03T09:12:04.00001:00
</date>

コードを修正し、この問題を解決した。

CR098364

WebLogic 6.1 SP03 では、Ant を使用して、次のような WebLogic タスクを使う Web サービスの .war ファイルを生成した場合、Transactions.jar ファイルに含まれる EJB が 155 個より多いと、wsgen が失敗していた。

<taskdef name="wsgen" classname="weblogic.ant.taskdefs.ejb.WSGen"/>

CompilerInvoker のコードを修正することで、この問題を解決した。

CR099255

WebLogic 6.1 SP04 では、weblogic.soap.WebServiceProxy クラスの invoke() メソッドが、クラスに証明書が設定されているかどうかをチェックしていなかった。

そのため、双方向の認証が失敗した。または、証明書が InitialContext に渡された場合は、HTTP プロトコルが機能しなかった。

コードを修正し、この問題を解決した。

WebLogic Tuxedo

変更要求番号

説明

CR084435

WebLogic 6.1 SP02 では、WTC の接続ポリシーが ON_DEMANDON_STARTUP に設定されていると、フェイルオーバおよびフェイルバックの状況において、接続ポリシーが正しく機能しなかった。接続ポリシーを ON_STARTUP に設定すると、フェイルオーバが機能しなかった。問題の再現を試みた結果、関連するエラーが明らかになった。

  1. WTC サービス リクエストが、bdmconfig ファイルのサービス セクションでリストされているセカンダリ ドメインにフェイルオーバしていた。

  2. WTC サービス リクエストは、bdmconfig ファイルのサービス セクションでリストされているプライマリ ドメインをチェックしていなかった。リクエストは、セカンダリ ドメインに移っていた。

プライマリ ノードが利用できなくなると、bdmconfig.xml のコンフィグレーションに従って、サービス リクエストは、インポートされたサービス セクションのセカンダリ サーバにフェイルオーバした。

<T_DM_IMPORT

ResourceName="TOUPPER"

LocalAccessPoint="WLSDOM"

RemoteAccessPointList="SIMPDOM,TESTDOM">

<TranTime>600</TranTime> <

/T_DM_IMPORT>

SIMPDOM が利用できなくなると、サービス リクエストは TESTDOM によって処理された。接続ポリシーが ON_DEMAND のときは、このような処理が行われてはならない。

分析の結果、接続ポリシーがチェックされていないことがわかった。 weblogic/wtc/gwt/TuxedoConnection.java のコードを修正することで、この問題を解決した。

CR095588

simpconv サンプルにおいて、Tuxedo クライアントが WebLogic Server に接続できなかった。クライアントは、WebLogic Server ではなく Tuxedo のローカル サーバにアクセスしていた。

パディングを探さないよう、Tuxedo クライアントのコードを修正した。さらに、dubb にリモート サービス セクションを追加し、bmdconfig.xml ファイルにエクスポート セクションを追加した。

CR092860

WTC を使って Tuxedo 8 Corba オブジェクトにアクセスすると、JavaIDL Reader スレッドのリークが発生した。簡単なサンプル アプリケーションを実行すると、WebLogic Server を実行する JVM で JavaIDL Reader スレッドが増加した。サーバをシャットダウンするまで、スレッドが破棄されなかった。

分析の結果、finalize() が正しいタイミングで呼び出されていなかった。ORB.destroy() の呼び出しを追加することで、この問題を解決した。

CR090137

WebLogic Server 6.1 SP02 では、WebLogic Server の Xalan エンジンが、一致しない <META> タグを含む無効な XML ファイルを生成していた。

apache/xalan のコードを修正し、この問題を解決した。

CR074963

FML テーブルを作成するとき、mkfldclass[32] は、各エントリをハッシュ テーブルにインスタンス化するためのメソッドを生成していた。大きな FML テーブル (4000 エントリ以上) の場合、このメソッド 1 つで JVM のサイズ制限を超えていた。

フィールド テーブルの動的ロード メカニズムを実装することで、この問題を解決した。

XML

変更要求番号

説明

CR091862

WebLogic 6.1 SP04 では、XML ドキュメントの DTD 部分を使うと、XML パーサに CPU やメモリを大量に使用させることができた。

XML ドキュメントの DTD 部分を使うと、ドキュメントで名前付きのエンティティを定義できる (定義済みの &lt;、&gt; などは除く)。エンティティは、他のエンティティを使って定義できる (再帰指定は XML 1.0 では禁止されている)。エンティティは、参照されると、XML ドキュメント内で展開される。攻撃は、あるエンティティを定義して参照するという方法で行われる。このエンティティは、別のエンティティの 2 つのインスタンスを使って定義されていて、それがさらに別のエンティティの 2 つのインスタンスによって定義される、ということが繰り返される。この定義プロセスは必要な長さだけ繰り返すことができ、通常は、100 レベルのネストで十分である。100 番目のエンティティは、単に文字列として定義しなければならない。このような定義は、理論的には、最初のエンティティに 100 番目のエンティティの値を 2^99 (2 の 99 乗) 個連結したものが含まれているのと同じ影響を及ぼす。

次に例を示す (DTD は、XML 宣言の後、XML ドキュメントの root 要素の前に置く)。

<!DOCTYPE root [

<!ENTITY x100 "foobar">

<!ENTITY x99 "&x100;&x100;">

<!ENTITY x98 "&x99;&x99;">

<!ENTITY x97 "&x98;&x98;">

...

<!ENTITY x3 "&x4;&x4;">

<!ENTITY x2 "&x3;&x3;">

<!ENTITY x1 "&x2;&x2;"> ]>

アプリケーションがドキュメント内にあるこの最初のエンティティを参照すると (&x1; という構文を使って)、ドキュメントのそれ以外の部分には問題がなくても、このエンティティを展開するために XML パーサが非常に大きな CPU 負荷またはメモリ負荷を必要とするため、結果として DoS 状態が発生する。

コンフィグレーション可能なシステム プロパティ weblogic.apache.xerces.maxentityrefs を新しく追加することで、この問題に対処した。

このプロパティの使用方法は、次のとおりである。

java -Dweblogic.apache.xerces.maxentityrefs=10000

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-23.jsp の「SECURITY ADVISORY (BEA02-23.01)」を参照すること。

 


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

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

クラスローダ

変更要求番号

説明

077067

config.xmlPreferWebInfClasses プロパティを設定すると、リソース ファイルに対して正しく作用するようになった。このプロパティを設定すると、ファイルはユーザの Web アプリケーションから取得される。

077344

クラス ファイルが WEB-INF\lib フォルダの JAR ファイルに入っていると、java.lang.ClassNotFoundException: org.apache.commons.logging.impl.LogFactoryImpl が送出されていた。この問題を解決した。

079738

大きなメモリ構造への静的な参照を含む Web アプリケーションをデプロイまたはアンデプロイするときに発生する可能性のあるメモリ リークを解決した。

081377

デプロイメント時にコンテキスト クラス ローダを介してクラスをロードすると発生していた問題を解決した。

083752

クラスが InitialContext の作成を試み、java コマンド ラインが -Xbootclasspath 引数を使って weblogic.jar を指定すると、weblogic.i18ntools.L10nLookup.loadProps から NullPointerException が送出されていた。この問題を解決した。

084236

サンプル samples.examples.iiop.wls2wls.package-summary.html に、正しい URL 情報が含まれるようになった。

クラスタ

変更要求番号

説明

CR043366

サーバが開発モードで開始したとき、クラスタ アドレスに対してカンマ区切りの IP アドレスを指定できるようになった。

CR078454、CR081750

WebLogic Server 6.1 SP02 および SP03 では、WebLogic Server クラスタがセッション レプリケーション中にハングした。 コンフィグレーションには、F5 ロード バランサ、Internet Information Server、および WebLogic Server ISAPI プラグインが含まれていた。

スレッド ダンプでは、RJVM サブシステムにおける今までに報告されたことのないパスが示された。

ExecuteThread: '33' for queue: 'default'" daemon prio=5 tid=0x49edf0 nid=0x2b waiting for monitor entry [0xd527f000..0xd527fc68]^M at weblogic.rjvm.RJVMManager. findOrCreateRemoteInternal(RJVMManager.java:213)^M at weblogic.rjvm.RJVMManager.findOrCreate(RJVMManager.java:188)^M at weblogic.rjvm.RJVMFinder.findOrCreateRemoteServer (RJVMFinder.java:178)^M at weblogic.rjvm.RJVMFinder. findOrCreate(RJVMFinder.java:149)^M at weblogic.rjvm. ServerURL.findOrCreateRJVM(ServerURL.java:207)^M at weblogic.jndi.WLInitialContextFactoryDelegate.getInitialContext(WLInitialContextFactoryDelegate.java:311)^M at weblogic.jndi.Environment.getContext(Environment.java:156)^M at weblogic.jndi.Environment.getInitialContext( Environment.java:139)^M at weblogic.servlet.internal. HttpServer.lookupROIDS(HttpServer.java:751)^M at...

分析の結果、ISAPI プラグインは、リクエストをプライマリまたはセカンダリ以外のサーバに転送していたことがわかった。 その後、リモートの ROIDImpl に対する呼び出しが行われた。

この問題は、WebLogic Server 6.1 SP04 でコードの修正により解決された。

CR078677

管理対象サーバの正常なシャットダウンの際に、HttpClusterServlet がフェイルオーバを実行するようになった。

CR081908

TCP レベルでセカンダリ サーバを利用できないときの HTTP セッションのレプリケーションに関する問題を解決した。これにより、明らかに TCP リクエストを受け取ることができず、クラスタ ビューから既に削除されているセカンダリ サーバにサーバが接続を試みても、長い遅延が発生しなくなった。

CR083532

サーバのシャットダウン シーケンスが途中でアボートする原因となっていた weblogic.rmi.cluster.ReplicaAwareRemoteRef.getCurrentReplica での Null ポインタ例外を解決した。

CR087870

高可用性マルチプールを使用した場合、初期容量を 0 にしてプールを作成し、ハードウェア障害が発生すると、Weblogic は正しくフェイルオーバするようになった。送出されていた ResourceException が、マルチプールがフェイルオーバする理由として解釈される種類の例外ではなかった。それが問題であった。

コンソール

変更要求番号

説明

057307

RDBMS レルムでユーザ パスワードを変更しようとすると送出されていた NullPointerException が送出されなくなった。

061975

自動キー生成を使用したときの createColumnsSql における問題を解決した。

073536

チェック ボックスをチェックすることにより、コンソールでオプションの相互 SSL を選択できるようになった。

074998

フォームベースの認証と複数のロケールを使用したときに認証エラーを受け取る問題を解決した。英語以外の言語を使用する資格は、fileRealm.prorperties ファイルには正常に追加できたが、サーブレットのフォームベースの認証を利用した認証には使用できなかった。サーブレットのフォームベースの認証を利用した認証にも、資格を使用できるようになった。

079130

管理対象サーバにデプロイされている EJB に対する JNDI ツリーをブラウズできるようになった。

079805

ソース サーバを対象とする Web アプリケーションが、複製されたサーバを対象として示されるようになった。

082578

[サーバ|コンフィグレーション|HTTP] タブに WAP 対応フラグが追加された。

083107

コンソールが、Mozilla 1.0 ブラウザをサポートするようになった。

083330

コンソールでクラスタをマルチプールの対象として設定できるようになった。

083377

WebLogicCluster で各クラスタ ノードに DNS 名を指定した場合、HttpClusterServlet は、静的なサーバ リストへの参照を使って HTTP リクエストの固定した関係を維持できるようになった。

083578

サーバのプロトコル タブの最大メッセージ サイズのテキスト フィールド サイズが増やされた。

084114

コンソールの [mydomain|サーバ|myserver|デプロイメント|Web アプリケーション] タブの [すべてのアクティブな Web アプリケーションのモニタ] リンクを使って Web アプリケーションをモニタしようとすると、例外が送出されていた。この問題を解決した。

086652

コンソールで新しいドメインを作成すると、コンソールの左ペインで [ファイル レルム] タブが機能するようになった。

EJB

変更要求番号

説明

069899

両方のテーブルに外部キーと同じカラムがある場合でも、多対多 CMR が SQL 例外を送出しなくなった。

076112

weblogic-ejb-jar.xml ファイルで <max-beans-in-free-pool> パラメータを指定してステートレス セッション Bean をデプロイした場合、ステートレス セッション Bean に対して同時呼び出しを行っても、この値が考慮されなかった。WebLogic Server は、ステートレス セッション Bean のインスタンスを、このパラメータで指定されている値より多く新たに作成していた。この問題を解決した。

076597

<max-beans-in-free-pool> を 0 にしてステートレス EJB をアンデプロイしても、ejbRemove() メソッドが呼び出されていなかった。この問題を解決した。

077049

アプリケーションが EJB メソッドのパラメータとして動的プロキシを使用した場合、パラメータ インタフェースがサーバ クラスパスに存在していても、リモート クライアントがインタフェースを使用できるようになった。

078456

一部の EJB サンプルのドキュメントに記述されているクライアントとサーバの出力が、テキストが折り返されていなかったため読みづらかった。テキストを折り返して読みやすくした。

079745

weblogic-ejb-jar.xml ファイルに別の XML ファイルが含まれていても、EJB のデプロイが失敗しなくなった。

080569

ECperf を実行した後、EJBCacheRuntime 統計情報で、1 つのステートフル セッション Bean (CartSes) の CachedBeansCurrentCount に不正な(負の)値が表示されていた。この問題を解決した。

081355

EJB 2.0 の JAR ファイルで関係を移動しても、EJB が NullPointerException を送出しなくなった。

081807

ホームを JNDI ツリーにバインドする前に、EJB デプロイヤがコンテキスト オブジェクトで replicateBindings を「True」に固定的に設定しているので、ユーザが weblogic-ejb-jar.xml ファイルで home-is-clusterable を「False」に設定していても、クラスタ内の残りのノードに対する通知が試みられて、NameAlreadyBoundException が送出されていた。この問題を解決した。

081817

weblogic-ejb-jar.xml ファイルで Bean レベルの dispatchPolicy を設定するためのオプションが提供された。

081991

キューからメッセージを取得するために「inhibited」を選択してから「allowed」を選択した後で、メッセージ駆動型 Bean が MQSeries への再接続に失敗しなくなった。

082029

接続プールに対する openString プロパティの使用時に、XA ドライバを使用するデータベースに EJB を使って接続するときの問題を解決した。

082451

WebLogic Server ではない JMS プロバイダを使用するメッセージ駆動型 Bean に対するサードパーティの JAR ファイルに対し、ClassNotFoundException が送出されなくなった。

083050

ejbRemove() から context.getCallerPrincipal() を呼び出しても、例外が送出されなくなった。

083098

キューを閉じると、MQSeries に対する接続数が増える。

083689

SQLServer を使用し自動キー生成を行う CMP エンティティ Bean で javax.ejb.NoSuchEntityException が発生しなくなった。

083896

max-beans-in-cache を 10 に設定した後、クライアントを実行し、同じ主キーで Bean に 200 回アクセスして、キャッシュに 200 個の Bean を取得した場合、concurrency-strategy が排他に設定されていると、データベース キャッシュが無視されていた。この問題を解決した。

083896

プロパティ max-beans-in-cache が無視されていた問題を解決した。

084224

Read-mostly パターンが使用されていると、コンテナが invalidate() メソッドを呼び出していなかった。

084978

Administration Console から EJBC パラメータを追加および変更できるようになった。これにより、たとえば、スタブのコンパイルに割り当てられるメモリの量を変更できる。

085320

ステートレス セッション Bean とサーバに関する問題を解決した。Administration Console に表示されるアイドル Bean カウントが誤ってインクリメントされ続けていた。

085659

マシンがネットワークから切断されたときの EJB に関する問題と遅延を解決した。

サンプル

変更要求番号

説明

053356

サンプル samples/examples/wtc/corba/simpappcns に UNIX スクリプト run.sh がなく、UNIX マシンで動作しなかった。

ubbdomaindom1configrun.sh の各ファイルを用意し、Tuxedo 側をビルドする方法についての説明を javadoc に加えることで、この問題を解決した。この解決策により、マルチプラットフォーム/マシンのサポートが提供される。古いビルド スクリプトは、単一マシン環境を想定していた。

079543

BEAHOME の名前にスペースが含まれていると、サンプル サーバが起動しなかった。この問題を解決した。

084236

サンプルの samples.examples.iiop.wls2wls.package-summary.html に正しくない URL 情報が含まれている。

084903

WTC simpappcns サンプルが、単独のマシンだけではなく、ネットワーク経由でも動作するように修正された。

JDBC および jDriver

変更要求番号

説明

077974

Oracle 8.1.7 OCI における OCI のバグが解決されたため、Solaris に対する OS 認証が追加された。

080487

DBMS のロールバックが失敗した場合でも、JTS ドライバでプール接続のリークが発生しなくなった。

CR080931

Oracle jDriver に関する問題を解決した。JDBC 接続に対して weblogic.oci.min_bind_size プロパティを設定すると、CallableStatement を使用した後に同じ接続で実行した SQL UPDATE prepared statement が失敗した。

082438

静的に定義されたプールには prepared statement のキャッシュ サイズを定義するためのプロパティが反映されているが、Console、weblogic.Admin、または API を使って動的に作成されたプールには反映できなかった。この問題を解決した。

082484

PreparedStatement で 511 より多くのパラメータが設定された場合でも、JDriver for Oracle で ArrayIndexOutOfBoundsException が発生しなくなった。

086557

Windows、HP、および Solaris 用の jDrivers for Oracle 9.2 を追加し、それに合わせて 8.1.7 と 9.0.1 のドライバを更新した。

087005

Oracle 9.2.0 用の Thin ドライバが追加された。

087803

Oracle 9.0.1 を使用する JMSServer 用にコンフィグレーションされた JDBC ストアを作成する際の問題を解決した。更新された 9.0.1 用 Thin ドライバを提供することで、この問題を解決した。

088156

EJB 永続性マネージャが原因で発生する可能性があった JDBC のデッドロック状態を解決した。

JMS

変更要求番号

説明

063743

メッセージ駆動型 Bean がオブジェクトのメッセージに応答しなくなる問題を解決した。

079547

クラスタ環境にデプロイされた JMS サーバに対する恒久サブスクライバを作成する際の問題の原因となるデッドロックを解決した。

081525

クラスタで TopicSubscriber.close() を呼び出しても、weblogic.management.NoAccessRuntimeException が送出されなくなった。

080668

JMS サーバ用のリスナを設定するクラスタ環境では、サーバのいずれかのノードが、直ちにではなく、しばらくしてから起動すると、NoSuchObjectException が送出されていた。この問題を解決した。

082298

恒久 JMS サブスクライバの数が正しくなかった。コンシューマが恒久サブスクライバに接続するたびに、余分なインクリメントが行われていた。サブスクライバが作成された時点で数がインクリメントされ、削除された時点でデクリメントされるようになった。

082438

サービス パック 4 より前は、動的に作成された JDBC 接続プールに対して STATEMENT_CACHE_SIZE パラメータが実装されていなかった。SP04 ではこの問題が解決されたので、動的接続プールは、Statement Cache を使って prepared statement と callable statement をキャッシュし、再利用できるようになった。

083290

プライマリ サーバが停止してから再起動したときの、管理対象サーバにおける JMS の回復に関する問題を解決した。

083503

管理対象サーバを起動および停止したときの、JMS とメッセージ駆動型 Bean の回復に関する問題を解決した。

084175

MessagingBridge を通してメッセージを送信し、サーバの再起動によって中断されると、メッセージが失われていた。MessagingBridge によってメッセージが処理されている最中に(MQ Queue から WebLogic JMS Queue に処理されているメッセージ)、WebLogic Server が停止して再起動すると、場合によっては、一部のメッセージが失われることがあった。失われるメッセージの数は、MessagingBridgeBatchSize に対応していた。この問題を解決した。

084182

exceptionListener を Null に設定しても、setExceptionListener メソッドは NullPointerException を送出しなくなった。

CR084374

メッセージング ブリッジは、いずれかのサーバに対する初期コンテキストの取得に失敗すると、パスワードを含むエラー メッセージを表示していた。

パスワードをクリア テキストとして表示しないよう JMSBaseConnection.java を修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-24.jsp の「SECURITY ADVISORY (BEA03-24.00)」を参照すること。

086487

83503 を参照。

CR093060

前記の「CR084374」と同じ。

その他

変更要求番号

説明

049340

ComponentMBeans に対する DeploymentOrderapplication.xml ファイルでの順序に基づいて初期設定し、初期デプロイメントと同じ順序で再デプロイメントできるようになった。

053054

サーバがトランザクション コンテキストをコピーしなかった問題を解決した。実装クラスを JNDI ツリーにバインドした後でクライアントが新しい JVM を生成すると rjvm エラーが発生し、新しい JVM はメソッドで RMI 呼び出しを行うことができなかった。

053957、071626、075394、076265、078527、079652、079655、082693、082830

このサービス パックでは、WebLogic による RJVM の処理について、以下に示すようなさまざまな改善が行われた。

WebLogic Server は、RJVM へのメッセージ送信を試みる前に、ローカルとリモートの Java 仮想マシン上で稼働するサーバ間に有効な接続が完全に確立されていることを確認するようになった。

ローカルとリモートの Java 仮想マシン上で稼働するサーバ間に有効な接続を確立するときに発生する可能性のあったデッドロックを解決した。

これまでは、RJVM が待機状態に入る前に接続成功の通知が発行されて、RJVM が接続の確立を待ちながら無限に待機状態になる場合があった。この問題を修正し、待機状態に入る前に接続成功の通知があっても、通知を検出できるようになった。

複数のスレッドが同時に RJVM への接続を確立しようとした場合、その結果は、接続の確立を実際に管理する最初のスレッドの成功または失敗に依存するようになった。

これまでは、接続に成功した最初のスレッドによって確立された接続を使うのではなく、各スレッドが、常に、個別に接続の確立を試みていた。

異なるコンピュータ上で稼働しピアを構成する複数の WebLogic Server が、それまで接続を確立していたピア サーバの停止を正しく検出し、壊れた接続を正しくクリーンアップするようになった。

OutputStream の取得に失敗すると、Remote Method Invocation (RMI) レイヤがフェイルオーバするための適切な例外を受け取るようになった。

これまでは、2 つのピア サーバが接続を確立しようとして失敗すると、RMI レイヤに対して例外が送出されず、不適切なフェイルオーバ、または適切なフェイルオーバの遅延が発生していた。

T3JVMConnection から RJVM に対する ConnectionManager への相互呼び出しの間で発生する可能性のあったデッドロックを解決した。

056403、063910、 076409、076903、 078288、078918、079599、080292、080744、081010、081116、081856、082700、083623、 086362

以下に示すように、muxer に関するいくつかの問題を解決し、改善を行った。

ソケットにマップするすべての muxer (Java とネイティブ コード)の集合が、固有のキーを持つようになった。これにより、データの破損、不正なポインタ参照、WebLogic Server のハングとクラッシュなどの、さまざまな問題が解決された。

muxer のデータ構造と状態マシンが正しく同期するようになった。これにより、ロックの順序の衝突によって発生していた一部のデッドロックが解決された。

muxer とその上のプロトコル層の間の呼び出しスタックが双方向になり、ソケットまたは接続のクローズをスタックのどのポイントからでも実行できるようになった。デッドロックを防ぐための手段が追加されている。

muxer における状態マシンの遷移が修正され、ソケットが CLOSE_WAIT 状態のままになることがなくなった。

064301

アプリケーション サーバが突然終了されると、高い確率で、未解決の分散トランザクションが発生する。WebLogic Server 6.1 SP01 では、未解決の分散トランザクションは存在し続け、DBA に手動で介入することで解決する必要があった。WebLogic Server 6.1 サービス パック 4 では、アプリケーション サーバを再起動すると、トランザクション ログ ファイルが再スキャンされて、回復処理が開始される。

071510

NodeManagerMBean から JMX を使ってサーバを起動できなかった。WebLogic Server 6.1 サービス パック 4 では、JMX クライアントを介して ManagedServers を起動および停止するための新しいメソッドが、ServerMBean に追加された。

072188

管理サーバが、NodeManager を指定して確立されたネットワーク接続を、タスクの完了後に閉じていなかった。この問題を解決した。

073023

ノード マネージャは、リモート サーバの起動を試みたときに、ランダムに OutputHandler エラーを送出しなくなった。

074844

動的プロキシを使用したときのアサーション エラーの原因となっていた問題を解決した。

075406、076002

大きな負荷がかかっている状態で NullPointer 例外と ClassCast 例外が発生する問題を解決した。また、NT muxer に対するいくつかの改善も行った。

076605

<ExecuteThread: '12' for queue: 'default'> <> <> <000000> <No IORecord present for fd>」というメッセージが表示される原因となっていた問題を解決した。

076705

送り先がリモートの場合に、メッセージ駆動型 Bean のデプロイメントが失敗し、ゲストに対して NoAccessRuntimeException が送信されることがなくなった。

076997

MBean を使ってクラスタに EAR コンポーネントをデプロイしたとき、サーバを再起動しなくてもすべての管理対象サーバで JNDI のバインドが表示されるようになった。

077248

ネイティブ IO がオフになっている場合に IIOP を介して EJB に接続するときの問題を解決した。

077831

AppletArchiver ユーティリティを使ってクライアント JAR ファイルを作成し、問題となっているアプレットが javax.swing.JApplet クラスをコードの中で使用した場合、AppletViewer でエラーが発生していた。この問題を解決した。

077919

EJBHandleObjectOutputStream.writeObject() を呼び出した後、パッチ CR064447_61sp2.jar を使うとログ ファイルでエラーが発生していた。ログでの EJBObject の出力が、LocalServerRef から LeasedRemoteRef に変わっていた。この問題を解決した。

078431

MuxableSocketHTTP と PosixSocketMuxer の間のデッドロックの原因になっていた問題を解決した。

078952

EJB のリモート メソッドからのシリアライズ可能なオブジェクトで null 値が返されても、org.omg.CORBA.MARSHAL 例外が送出されなくなった。

079220

クラスタ環境では、JMS を実行すると、クライアントが「Could not find RJVM for $Proxy68.. (IllegalArgumentException)」という例外を受け取っていた。クライアントは、管理対象サーバの 1 つにアクセスして利用していた。この問題を解決した。

079672

WarClassFinder.getSource を呼び出すと VM がクラッシュする可能性がある。Sun は、この問題への対処を JDK の 1.4.1_02 および 1.3.1_07 で行っている。Sun のバグについては、http://developer.java.sun.com/developer/bugParade/bugs/4369396.html を参照すること。

080177

同じ EJB を繰り返しデプロイおよび削除しても、weblogic.deploy でメモリ リークが発生しなくなった。

080740

Windows サービスとして動作しているサーバがシャットダウンすると削除されるファイルを Web アプリケーションが作成した場合、コマンドラインから(java weblogic.Admin SHUTDOWN コマンドを使って)、または Administration Console からサーバをシャットダウンすると、ファイルは意図したとおりに削除された。しかし、Windows の [スタート] メニューから [設定|コントロール パネル|サービス] を開き、サービスの [停止] ボタンをクリックしてサーバをシャットダウンすると、ファイルが削除されなかった。

この機能を実装した。

080895

スタンドアロンの java クライアントがステートレス セッション EJB を呼び出したとき、約 500,000 回繰り返すと、クライアント サイドで次の例外が送出されていた。
Exception in thread "main" java.lang.ClassCastException: Assigning instance of class java.io.ObjectStreamClass to field weblogic.rmi.internal.ClientMethodDescriptor#signature at java.io.ObjectInputStream.inputClassFields(ObjectInputStream.java:2271)

この問題を解決した。

080901

Windows NT におけるソケット マルチプレクサの問題のため、DoS 攻撃によるクラッシュに対して弱かった。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-19.jsp の「SECURITY ADVISORY (BEA02-19.00)」を参照すること。

080929

ワイルドカードを使用した場合でも、weblogic.refresh がファイルを更新できるようになった。

081311

DTD の SAXParseException の重要度が、<Info> ではなく <Warn> になった。

081404

WebLogic Server 6.1 サービス パック 4 には、メッセージング ブリッジ用の JMS ブリッジ リソース コネクタ (jms-xa-adp.rarjms-notran-adp.rarjms-notan-adp51.jar) が収められた。

081568

SNMP エージェントが、サーブレットの ServletRuntime をモニタできるようになった。

081732

WebLogic Server 6.1 SP03 では、Sybase データベースを使用した場合、サーバを起動しようとすると例外が送出されていた。この問題を解決した。

081765

SSL に、途中でソケットを閉じて muxer のエラーが発生する問題があった。

081853

JDK が混在する環境で特に顕著であった、RMI-IIOP および複雑なオブジェクトのマーシャリングに関するいくつかの複雑な問題を解決した。

081868

WebLogic Server 6.1 サービス パック 2 では、java weblogic.Admin SHUTDOWN を使って管理サーバをシャットダウンすると、SNMP エージェントが serverShutDown トラップを生成していなかった。サーバの起動時には、serverStart トラップを生成できた。SNMP エージェントは、管理サーバがシャットダウンすると自己シャットダウン トラップを発行するようになった。

CR081870

WebLogic Server による Xalan の配布キットでは、次のように XSLT の出力方法を HTML (必須) に設定すると、アンカー タグの HREF 属性の中のスペースが、「%20」にエンコードされていた。

<xsl:output method="html"/>

例:

<a href="javascript: var win = openWindow()">Link</a>

上のような記述に対して、下のような誤った出力が生成されていた。

<ahref="javascript:%20var%20win%20=%20openWindow()">Link</a>

Netscape は「%20」をスペースと解釈できず、リンクが壊れていた。出力タイプを「XML」に変更すると (この場合の対応策としては適切ではない)、属性は正しい結果を出力した。

vanilla Xalan の配布キット (つまり BEA 拡張バージョンではないもの) は、同じ入力に対して正しい変換を行う。

Xalan の WebLogic Server による配布キットは、HREF 属性に対して不適切な URL エンコーディングを行った。スペースが許されない通常の URL (つまり http://somehost/...) に対しては問題なく動作するが、JavaScript の URL (つまり javascript: doSomething()) も有効であり、これはエンコーディングされてはならない。XSLT トランスフォーマの場合、URL を明示的にエンコードする方法はスタイルシートに既にあるので、URL に対して何も行ってはならない。

この問題は、WebLogic Server 6.1 SP2、SP3、および SP4 で発生した。

URL をエンコードしないよう XSLT トランスフォーマを修正することで、この問題を解決した。

082004

WebLogic Server 6.1 サービス パック 2 では、新しい InitialContext() を取得する際に、CR073910_61sp2.jar パッチによってメモリ リークが発生していた。

082263

weblogic.deploy ツールが、Windows 2000 から Solaris 上で稼働するサーバに対して、Web アプリケーションの .WAR ファイルを更新できるようになった。

082533

Xerces Parser を使用したとき、デバッグ メッセージが std.out に書き込まれていた。このメッセージは削除された。

082693

WebLogic Server 6.1 サービス パック 1 および 2 では、旧世代のスタブからの呼び出しを受け取ったサーバは、クライアントに peerGone を正しく送信し、エラーをログに記録していた。サービス パック 3 では、サーバは NullPointeException を出力し、クライアントはタイムアウトするまで待機していた。サービス パック 4 では、これを以前の正しい動作に戻した。

083102

J2EE12OnlyModeEnabled="true" を指定して 2 つの EJB (EJB 2.0 仕様に準拠したもの)をデプロイすると、サーバは Bean に対して警告メッセージを 2 つ送出し、DistributedManagementException でクラッシュしていた。この問題を解決した。

083485

t3 クライアントを呼びだしても、クライアントはデフォルト プロトコルとして t3 を使用する JavaSocketMuxer でハングしなくなった。

083652

WebLogic Server 6.1 サービス パック 3 では、アプリケーションが起動時にアンデプロイされた後、2 回再デプロイされていた。この問題を解決した。

083654

Microsoft WAS ツールからリクエストが連続して発行されたときのパフォーマンスが、WebLogic Server 6.1 サービス パック 3 より改善された。英語圏以外のユーザは、 089868の関連情報を参照すること。

083721

スタートアップ クラスの FailureIsFatal オプションが、Solaris 環境での実行時例外を抑止しなくなった。

083920

再起動した管理サーバが、管理対象サーバが稼働していることを発見したときの起動トラップが抑止されて、管理サーバの再起動時に冗長なトラップが送信されなくなった。

084127

プロダクション モードでは、自動デプロイメントがオフになっていても、WebLogic Server は config.xml ファイルでコンフィグレーションされていない一部のアプリケーション ファイルの検証を行っていた。この問題を解決した。

084622

ZAC を使用しても、getInitialContext() を呼び出したときにアサーション エラーが発生しなくなった。

085463

ネットワーク プラグを抜いたときの JNDI ルックアップのフェイルオーバに、長い時間がかからなくなった。

085914

管理対象サーバが停止した後で、SNMP リクエストがタイムアウトしていた。管理対象サーバが停止しても、SNMP エージェントが getnext リクエストにしばらく応答できない状態になることはなくなった。

085979

カスタム Mbean が定義されているときに MBeanHome.getAllMBeans() が不必要な例外を送出する問題を解決した。

086108

パフォーマンスが改善された。ListenThread が消費するメモリが、サービス パック 3 より少なくなった。

086248

ボックス化された RMI シーケンスに対するコンポーネント タイプが、先行して 2 回宣言されていたが、1 回は正しく、もう 1 回は valuetype のシーケンスに対しては正しくないタイプであるインタレースであった。

086350

例外のクラス名の最後が大文字の「I」である場合に、その名前から生成される IDL が壊れる問題を解決した。

CR086362

大きな負荷がかかると SocketException: Connection timed out エラーが発生していた。スタック トレースは以下のとおりである。

####<Sep 18, 2002 9:37:07 AM EDT> <Error> <Posix Performance Pack> <lpsapp01> <LPSAPP01_C> <ExecuteThread: '34' for queue: 'default'> <> <> <000000> <IOException on socket: 'weblogic.rjvm.t3.T3JVMConnection@67cf01', fd: '1046'> java.net.SocketException: Connection timed out: Connection timed out Start server side stack trace: java.net.SocketException: Connection timed out: Connection timed out at java.net.SocketInputStream.socketRead(Native Method) at java.net.SocketInputStream.read(SocketInputStream.java:86) at weblogic.socket.PosixSocketMuxer.readBytesProblem(PosixSocketMuxer.java:824) at weblogic.socket.PosixSocketMuxer.
deliverGoodNews(PosixSocketMuxer.java:712) at weblogic.
socket.PosixSocketMuxer.processSockets(PosixSocketMuxer.java:637) at weblogic.socket.SocketReaderRequest.execute(Socket
ReaderRequest.java:24) at weblogic.kernel.ExecuteThread.
execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120) End server side stack trace

また、サーバ インスタンスが、CLOSE_WAIT 状態のソケットでハングしていた。スレッド ダンプは以下のとおりである。

"ExecuteThread: '3' for queue: 'default'" daemon prio=5 tid=0x7f79a8 nid=0x10 waiting for monitor entry [0xa6101000..0xa6101a40] at weblogic.socket.PosixSocketMuxer.
read(PosixSocketMuxer.java:542) at weblogic.socket.
JVMSocketManager.accept(JVMSocketManager.java:185) at weblogic.t3.srvr.ListenThread$RJVMListenRequest.execute(ListenThread.java:594) at weblogic.kernel.ExecuteThread.
execute(ExecuteThread.java:139) at weblogic.kernel.
ExecuteThread.run(ExecuteThread.java:120)

スレッド ダンプを分析した結果、ネイティブな AddFdToPollSet のスレッドが PollSet Loopback FD への書き込みを終了せず、POLLSET_LOCK を正しく解放していないことがわかった。

パイプに書き込んだバイト数を追跡し、パイプに書き込んでも大丈夫であることをスレッド リーダーが示すまでパイプへの以降の書き込みを待つことで (代わりに配列を使って)、この問題を解決した。

086761

Weblogic 管理ツールが正しく実行キューを作成し、サーバ起動時に機能するようになった。

087265

WebLogic のバージョン間の相互運用性を保つため、互換性のないいくつかの serialVersionUID を修正した。

088372

weblogic.security.acl.TTLCache.cleanup での ArrayIndexOutOfBoundsException などの複数の例外が発生していた負荷状況下での問題を解決した。

089044

Administration Console をロードしても、ブラウザ/OS の互換性チェックが行われなくなった。

プラグイン

変更要求番号

説明

074128

クラスタにおいて、Internet Explorer で 10053 番のソケット エラー メッセージが表示された後、プロキシ プラグインが誤ってフェイルオーバしていた。プライマリ サーバは正常に動作していた。問題は次のコンフィグレーションで発生した。

  • WebLogic Server 6.1.0 と SP02

  • IIS プラグイン

  • Windows 2000 SP2

  • IIS 5.0

10053 番のエラーは WinSock エラーであり、winsock.h では WSAECONNABORTED と定義されている。このエラーは、ISAPI 拡張機能がデータの返送を終了する前にページを再ロードすると発生する。ページを再ロードすると、ブラウザは現在の接続を閉じた後、新しい接続を作成してリクエストを再送信する。拡張機能がデータ送信を終了する前にブラウザの [中止] ボタンをクリックしたときも、同様の状況が発生する場合がある。

これは正常なイベントであり、ブラウザはそれ以上リスンしない。エラーの後、プラグインは、単にクリーンアップを行って HttpExtensionProc から戻らなければならない。

IIS プラグインを変更することで、不適切なフェイルオーバの発生を解決した。POST データの読み取りでタイムアウトが発生した場合、sendRequst フェーズの間に処理が障害になってもフェイルオーバが発生することはなくなった。

076936

ISAPI 環境下で、次のように WlForwardPath と共に PathTrim で複数レベルのパスを指定すると、ISAPI プラグインが指定されたパスをトリムできなかった。

WlForwardPath=/
PathTrim=/path/to/weblogic

この問題を解決した。

078713

iisforward.ini ファイルに新しいパラメータ セット FilterPriorityLevel が追加された。このパラメータの値は 0、1、または 2 で、それぞれ、フィルタの優先度が低、中、高であることを意味する。デフォルト値は 2 である。仮想ホストを使ってこのプロパティを設定できない場合は、iisforward.ini ファイルを使用する。

079186

HTTP 1.1 仕様に従って、すべてのプラグインが複数行にわたるヘッダ プロパティを解析するようになった。

079683

mod_wl_ssl.so を使うと、Chunked Transfer Encoding HEX の値がブラウザに表示されていた。これは、Weblogic で jsp:include を使用したときにだけ発生した。mod_wl.so は正しく機能したが、ブラウザがページを完全に表示するまでに長い遅延があった。この問題を解決した。

079973

WebLogic Server 6.1 サービス パック 4 では、Idempotent が OFF の場合はフェイルオーバが行われず、ConnectTimeoutSecs=0 の場合はコア ダンプが行われない。iPlanet のコンフィグレーションで ConnecyTimeoutSecs が 0 に設定されていると、リトライは試みられない。以前は、デフォルトの設定 (10) または 0 であるとリトライが試みられていた。さらに、Idempotent が OFF に設定されているとリトライが 2 回行われるのに対し、 ON に設定されていると 5 回行われていた。

080219

すべての WebLogic Server インスタンスをシャットダウンしても、iPlanet のコア ダンプが発生しなくなった。

080382

NSAPI プラグインを使用しても、WebLogic Server のエラー ログに予期しないエラー メッセージが記録されなくなった。

080746

ネイティブ Web サーバ プラグインでの 64 ビット プラットフォームがサポートされるようになった。

081185

ファイルのアップロードをキャンセルしても、CPU の負荷が増えなくなった。

081493

HPUX-11 の iPLanet がクラッシュする原因となっていた問題を解決した。

082093

WebLogic Server が NSAPI プラグインを使用する iPlanet プロキシを介してアクセスされていて、QALoad を使って同時に多数のクライアント接続が生成されても、高負荷下の Web サーバに対し、プロキシ プラグインによって余分な呼び出しが行われることがなくなった。

082096 および 083386

Idempotent=OFF であっても、IIS プロキシ プラグインは、HungServerRecoverSecs の後ですべての POST リクエストに対して 1 回のリトライ(2 リクエスト = 1 オリジナル + 1 リトライ)を試みなくなった。

082113

プラグインは、クライアントからのデータの読み取り中にエラーを受け取っても、バックエンドの WebLogic Server に不完全なデータ(リクエスト)を送信しなくなった。

082206

特定のページを WebLogic への転送から除外し、IPlanet のフロントエンドで処理させることができるようになった。定義した式に一致する特定のリクエストを除外するには、obj.confWLExcludePathOrMimeType を追加する(WLExcludePathOrMimeType="/test,/*.html" など)。

083174

最新の IIS プラグインを使用すると、セッションに新しい値を追加したときにフェイルオーバが機能しなかった。

083643

NSAPI のパフォーマンスの問題を解決した。netbuf_getc 関数は非常に遅く、POST データ中の「¥0」と「0」を区別できなかった。

083558

最新の Apache である Apache 2.0.42 の動作が確認された。

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

変更要求番号

説明

042655

拡張ログ フォーマットで access.log を使用した場合、HTTP リクエストの実行時刻が GMT 時刻ではなくローカル時刻で記録されることがなくなった。

053974

access.log の名前をコンフィグレーションできるだけでなく、管理しやすいようにログのローテーション規則も選択できるようになった。

058389

javax.servlet.http.HttpServletRequestWrapper に対して呼び出された getInputStream() が、null を返さなくなった。

063630

Web アプリケーションのデプロイが失敗した場合、クラスタに他のアプリケーションをデプロイできなかった。この問題を解決した。

065967

<type> が指定されていて、タイプが配列の場合でも、taglibs が失敗しなくなった。Weblogic Server は、タイプが実際には配列の時には、タイプを文字列として扱わなくなった。

068577

JSP 仕様 1.2 によれば、すべてのタグ ハンドラは DO_END_TAG によって解放されなければならないが、生成されるコードでは、<jsp:forward> に対して _releaseTags() メソッドが呼び出されていなかった。この問題を解決した。

069731

Web アプリケーションで JSP を使用すると、JSP から作成される .java ファイルは _tmp_war (Web アプリケーションのルートの下)に置かれる。_tmp_war ディレクトリがまだ存在していない場合は、Web アプリケーションのデプロイメント時に(サーバを起動した後の初期化の中で)作成される。サーバがルートとして実行されている場合は、_tmp_war ディレクトリはルートによって作成されて所有される。以前は、初期化の最後に nonPrivUser を使って特権のないユーザに切り替えたため、JSP サーブレットと WebLogic は _tmp_war ディレクトリにアクセスできなくなっていた。この問題を解決した。

071513

WebLogic Server は、Web アプリケーションの中で weblogic.xml ファイルを検証するようになった。

073780

WebLogic Server 6.1 サービス パック 2 および 3 つのパッチ CR065452A_610sp2.jarCR063457A_610sp2.jar、および CR063829_610sp2.jar を使用したときよりも、JSP タグのパフォーマンスが改善された。

073791

サーブレットのコードから ServletOutputStreamImpl.write を呼び出した後に ChunkUtils.getEnd メソッドで NullPoinerException が発生していた問題を解決した。

074265

ServerMBean に新しい属性 MaxBackoffBetweenFailures を追加した。デフォルトは 10 秒である。サーバのリスン スレッドがソケット接続の受け付けをまだ試みている場合に、「Failed to listen on port (ポートでのリスンに失敗)」を送信する間隔を変更するには、この属性を設定する。

074940

weblogic-tags.jarcache タグの size 属性を使用しても、NullPointerException が送出されなくなった。

075471

WebLogic Server サービス パック 4 では、JRun タグ ライブラリが機能するようになった。

075721

TimeExpressionbeanName を使用する jsp:useBean タグが、正しく解釈されるようになった。

076375

weblogic.log および access.log (HTTP ログ) は、ログ ファイル名のコンフィグレーションに基づいて名前が変更されるようになった。ログ ファイル名で「%」記号を使用すると、ログ ファイルがローテーションされる時の日付/時刻に基づいてログ ファイルの名前を変更するロジックが実行される。現在ログが記録されているファイルは、「%」記号(ある場合)が取り除かれたファイル名になる。次は、有効な形式の例である。

weblogic_%yyyyMMdd%_%HH%_%mm%.log foobar_%yyyy%-%MM%-%dd%_%HH%_%mm%.log

注意: SimpleDateFormat では、大文字の「Y」は何も表さない。年を表すには、小文字の「y」を使用する。無効な形式を指定すると、WebLogic Server のデフォルトのログ ファイル名が使用される。パーセント記号 (%) で囲まれた文字列は、SimpleDateFormat に基づいてデコードされる。この形式はファイル名に対して適用され、ディレクトリ名には適用されない。

077018

リクエスト/応答ラッパを使用したときの ServletAuthenticationClassCastException が送出されなくなった。

077306

一時的なパッチを使用しても、インクルードされている(コンパイル済みの) JSP クラスが再コンパイルされなくなった。

077422

CookieParser.cookieToString が、カンマ (,) を含む SimpleDateFormatexpires クッキーを作成していた。expires の日付の中にカンマがあるため、リクエストに入れて返されたクッキーが誤って解釈されていた。カンマは、クッキーの区切り文字として解釈され、expires の日付の解釈が中断していた。この問題を解決した。

077888

setCharacterEncoding は、UnsupportedEncodingException を送出するようになった。

078090

JSP 仕様によれば、リクエスト パラメータで jsp_precompile が使用されている場合には、コンテナは、JSP をコンパイルしなければならないが(コンパイルされていない場合)、JPS を表示してはならない。WebLogic Server は、クエリ文字列を解析して jsp_precompile を検出するので、ブラウザにページを表示していなかった。

078262

ServletContextgetResourcePaths(String) が追加された。

078325

文字セット値の前後に余分な引用符がある場合に UnsupportedEncodingException が送出される原因となっていた問題を解決した。

078698

access.log ファイルは、ログのサイズが 2MB を超えるとローテーションするようになった。

079582

WebLogic Server 6.1 サービス パック 3 では、データ同期の最中に SocketException が送出されていた。この問題を解決した。

079767

アプリケーションまたはコンポーネントの再デプロイメントのたびに、EAR ファイル、WAR ファイル、または JAR ファイルを WebLogic Server に再デプロイしても、管理対象サーバの .wlnotdelete ディレクトリのサイズが増えなくなった。

079892

CGI スクリプトの実行中に停止ボタンをクリックしても、CPU の使用率が 100% のままになることがなくなった。

080090

リダイレクトの際に、ロケーション ヘッダは、次のパラメータが指定されている場合は常にそれを使用するようになった。

FrontendHTTPPort
FrontEndHTTPSPort
FrontEndHost

080384

ただ 1 つの応答でステータス コード ヘッダにスクランブルがかけられている場合であっても、HttpClusterServlet はサーバを不良 (bad) とマークしていた。この問題を解決した。

080751

サーブレットの例外を拡張するカスタム例外がコンフィグレーションされている場合は、エラー ページにリダイレクトされるようになった。

080791

クラスタ/プロキシ サーブレットにおいて、複数行のヘッダが考慮されるようになった。

080837

weblogic.xml ファイルに新しい要素が追加された。

<!--
wl-dispatch-policy を使用すれば、コンフィグレーション済みの実行キューの名前を指定して、Web アプリケーションに実行キューを割り当てることができる。この Web アプリケーション レベルのパラメータは、個別のサーブレット/JSP レベルでオーバーライドできる。次に例を示す。
<servlet>
...
<init-param>
<param-name>wl-dispatch-policy</param-name>
<param-value>CriticalAppQueue</param-value>
</init-param>
</servlet>
-->
<!ELEMENT wl-dispatch-policy (#PCDATA)>

081071

weblogic.servlet.internal.ServletContextManager.trimAbsUrlNullPointerException が送出されなくなった。

081484

複製時には PersistentStoreType と共に HttpSessionListener を使用するとセッション属性が失われなくなったが、非複製時にはセッション属性を取得できる。

081521

JSP から CGI スクリプトを呼び出すことができるようになった。

082156

常に True を返すことがないように、isRequestedSessionIdValid の実装が変更された。

082238

CreateSessionServlet は、Cache-Control ヘッダが存在するかどうかをチェックし、存在する場合は有効な値をヘッダに設定し、存在しない場合はヘッダ リストに追加していた。どちらの場合も、別に不正なヘッダが追加されていた。weblogic.xmlCacheSessionCookie を True に設定することで、この問題が解決された。

082310

ページの contentType ディレクティブが指定されている JSP を、展開形式の WAR ファイルで削除または上書きできなくなった。

082580

WebLogic Server 6.1 サービス パック 3 では、URL にアクセスするときにフォームベースの認証が実行されて認証に成功すると、HTTP POST パラメータが保持されなかった。

082671

内部的な実装において HttpSession.getServletContext() がパブリックになった。

083191

Console で Servlet Average Execution Time (サーブレット平均実行時間)に対して誤った値が表示されなくなった。

083200

nonProxyHosts でフィルタ処理が正しく行われるようになった。

083487

CGIServlet が正確に一致する <url-pattern> を処理するようになった。

083517

SecureProxy が ON であっても、HttpClusterServlet が SSL に対するリクエストをプロキシ処理していなかった。この問題を解決した。

083597

WebLogic Server 6.1 サービス パック 3 では、ページ ディレクティブを使用するコンテンツ タイプが
<%@ page contentType="text/html;charset=UTF-8" %>」と設定されていると、コンテンツ タイプが正しく設定されず、意図した出力が得られなかった。この問題を解決した。

083912

Oracle Thin ドライバの使用時に、サーバがセッション データを JDBC 管理永続性に書き込もうとしても、ORA-01461 エラーが発生しなくなった。

084002

WebLogic Server は、HTTP コードの 204 を返すときに、HTML エラー ページで Content-length に 886 を設定していた。したがって、負荷をかけているクライアントでは障害が発生し、「応答コード 204 には本体があってはならないが、Content-length が 886 に設定されていた(HTML エラー ページで)」ことを示すエラーが生成されていた。この問題を解決した。

084030

展開された Web アプリケーションを 2 つのサーバで共有すると、2 番目のサーバの起動時に、生成された一時ライブラリ (tmp lib) ディレクトリが削除されていた。このディレクトリが削除されなくなった。

084058

ServletAuthentication.logout() の後で request.getUserPrincipal() メソッドがゲストを返していた。SP4 では、getRemoteuser() は null を返すようになった。

084536

CR083377 に対するパッチが原因で発生するセキュリティと SSL 接続に関する問題を解決した。

084649

CGI サーバが内部で実行されているスクリプトに対して提供すると想定されている特定の環境変数がある。Netscape の CGI サーバで使用される SERVER_URLHTTP_COOKIE、および QUERY_STRING は、同じ CGI プログラムを WebLogic の CGI サーブレットの内部で実行したときには利用できない。これらの変数のいずれかに対してリクエストが行われると、値の代わりに NULL が返されていた。この問題を解決した。

084785

GenericProxyServlet は、ラップされた応答を処理できるようになった。

084847

チャンクされた転送に対し、WebLogic Server は、他のサーブレット エンジンでは無視される 16 進数値を含めていた。この問題を解決した。

085754

リクエスト ディスパッチャと共に使用するときに、中間の JSP である BEATestCase2.jsp に改行/コメントを入れると、クライアントは空白のページを受け取っていた。サーバ サイドでは例外は送出されなかった。この問題を解決した。

086026

パラメータ CacheSessionCookie のデフォルトとして False が使用されていた。このデフォルトが True に変更された。

086052

WebLogic Server から外向きの HTTPS 接続が、URL の最後にスラッシュ「/」がないと動作しなかった。この問題を解決した。

086280

キープ アライブ接続を通してサーブレットにアクセスしても、NullPointerException が送出されなくなった。

086481

Web アプリケーションが比較的大きなファイルをダウンロードし、マルチパートのフォーム データの読み取り中にバッファ オーバーフローが発生したときの、いくつかの問題を解決した。

088301

JSP の BodyTag タグの内部で Forward ディスパッチされた別のリソースからディスパッチされたとき、インクルードされているリソースがサーブレットの出力ストリームに送信されない問題を解決した。

注意: リクエストが Forward ディスパッチされるとタグが終了するため、ネストされた BodyTag タグの出力ストリームはフラッシュされていなかった。しかし、WebLogic は、まだ出力をタグのネストされた出力ストリームに送る必要があるものと考えていた。Forward リクエストがディスパッチされたときに BodyTag タグのネストされた出力ストリームに対する参照をクリアすることで、この問題を解決した。

CR089803

CR090225」と同じ。

テストの際、デバイス ドライバが HTTP を使ってリクエストを行うようにすると (request.aux.%2a.jsp または aux.*.jsp)、リクエストを処理するスレッドがハングした。

JSPServlet のコードを修正して、この問題を解決した。上で名前を挙げたデバイス ドライバはすべて、長さ 0 のファイルとして扱われるようになった。WebLogic Server は、この種のファイルを読み込まずに提供する。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA03-14.jsp の「SECURITY ADVISORY (BEA03-14.05)」を参照すること。

セキュリティ

変更要求番号

説明

058355

ユーザが LoginContextlogin() を呼び出すと、この呼び出しは LoginModule の login() に直接マップされたが、logout() メソッドが実装されていなかった。したがって、このメソッドに対する呼び出しを、LoginModule の logout() にマップできなかった。WebLogic Server 6.1 サービス パック 4 では、LoginModule.logout() が実装された。

057950

セキュリティのため、Certificate Request Generator サーブレットから [Random String] フィールドを削除した。

068729

weblogic.security.SSL.SSLCertificate クラスのドキュメントが作成された。

075109

LDAPRealV2 がメンバシップをキャッシュするようになった。

075451

WebLogic Server の中からリモート WebLogic Server に対する InitialContext を取得しようとすると、weblogic.net.http.HttpsURLConnection で SSL 接続を行った後で、例外が送出されていた。この問題を解決した。

076783

RDBMS レルムを使用すると、余分な呼び出しが行われていた。キャッシング レルムが修正されて、余分な呼び出しが行われなくなった。

077233

SSL 証明書の絶対パスが提供されるようになった。

077288

WebLogic Server 6.1 SP02 では、グループ内のユーザに対する CN を解析するときに、ユーザ名に「=」が含められていた。

LDAPRealmv2 の字句解析コードを修正することで、この問題を解決した。

077425

キャッシング レルムとともにカスタム レルムが使用されていて、大文字と小文字が区別されないキャッシュのデフォルトが true に設定されていると、キャッシング レルムはエラー メッセージ「Server cannot check in a case-insensitive way」を送出していた。この問題を解決した。

078893

weblogic.management.password が空白でない場合は、カスタム ログイン モジュールが呼び出されなかった。j_security_check が JAAS ログイン モジュールを使用するには、JAAS ログイン モジュールと共にプログラムによる認証 (servletauthentication.weak()) を使用する必要がある。

079183

weblogic.security.acl.ManageableRealm.setName を呼び出した後で、weblogic.security.acl.ManageableRealm.getAcl が null に戻らなくなった。

079364

deleteAcl は、getACLOwner プリンシパルと共に使用したときにだけ動作した。この問題を解決した。

079637

プライベート キーのパスワードを含むファイルの名前を指定するための pkpassfiile プロパティが追加された。

082003、087419

Microsoft Active Directory Server 用にコンフィグレーションされた LDAP レルムを使うと、フォームベースの認証は正しく機能したが、基本認証は失敗していた。この問題を解決した。

082098

資格がリモート サーバ レルムに対して使用および検証されるようになった。

083478

証明書フォームでは電子メールは必要ないが、証明書に EMAIL= が含まれていた。この問題を解決した。

084166

ネストされたグループに対するサーバのパフォーマンスが向上するよう、委託グループのキャッシングが修正された。

087485

WebLogic Server 6.1 SP03 では、LDAP はグループのすべてのメンバに対して Group.isMember() を呼び出していた。このサービス パックでは、LDAP レルムの本来の動作が回復されている。groupmembershipcache の値に 0 を設定すると、WebLogic はグループ メンバシップに対して LDAP レルムをチェックするので、グループに複数のメンバが含まれている場合でも、すべての members() がロードされることはない。

システム管理

変更要求番号

説明

059779

データ ソースを、異なるサーバの同じ JNDI 名にバインドできるようになった。

062102

起動時に管理対象サーバにコピーする必要のないアプリケーションがコピーされなくなり、ディスクの空き領域が増えた。

063630

デプロイメントが失敗したときに、残っているアプリケーションを管理対象サーバにデプロイできるようになった。

072833

Administration Console で listenAddress フィールドを空白にして管理対象サーバをコンフィグレーションした場合、異なる複数のマシンからこの管理対象サーバの複数のインスタンスを同じ名前で実行することができた。このような動作は不可能になった。

074370

WebLogic Server 6.1 サービス パック 2 では、Administration Console で EJB 記述子エディタを使用すると、javax.management.AttributeNotFoundException が送出された。この問題を解決した。

074653

Administration Console のデプロイメント記述子エディタは、メモリまたはディスクに書き込むときに、「&」を「&amp;」に置き換えるようになった。これは、XML ファイルでは「&」は特殊文字であり、「&amp;」としてエスケープする必要があるためである。

075949

weblogic.deploy が JAR ファイルをデプロイメントの直後にアンデプロイする問題を解決した。

076539

load-on-startup を指定された Web アプリケーションが、DeploymentOrder に従って正しい順序でロードされるようになった。

078257

管理サーバの JNDI が管理対象サーバの MBeanHome を示さず、NameNotFoundExceptions が送出されていた。この問題を解決した。

079270

対象となる管理対象サーバの中に停止しているものがあると、アプリケーションの再デプロイメント(削除とデプロイ)操作が成功しないことがあった。たとえば、EJB に対する JNDI エントリが稼働しているサーバに登録されなかったり、警告メッセージのために config.xml ファイルの「Targets」属性が失われたりした。この問題を解決した。

079455

デプロイメントが失敗しても ConfigurationError が送出されなくなった。

079819

多数のアプリケーションがデプロイされている管理対象サーバの起動に要する時間が短くなった。

080016

アプリケーションが仮想ホスト(管理対象サーバが対象になっている)および管理サーバを対象にした場合、管理サーバの起動の際にアプリケーションのデプロイでエラーが発生しなくなった。

080324

パブリック API に setParent メソッドが公開された。

080690

管理サーバは、バウンスして再起動した場合には、管理対象サーバへの接続を再確立するが、JNDI ツリーに管理対象サーバが示されなかった。その結果、アプリケーションは NameNotFoundExceptions を受け取っていた。管理対象サーバは、再起動した後に管理 JNDI ツリーに表示された。この問題を解決した。

080778

セッションのモニタリングをオンにしても、新しいセッションが作成されるたびに管理サーバへのトラフィックが発生することがなくなった。

081736

weblogic.Admin -help がゲストに対してパスワードを要求した後、パスワードを無視しなくなった。

082765

シャットダウンを呼び出して管理対象サーバをシャットダウンすると、removeManagedHome も呼び出されてキャッシュから管理対象サーバが削除される。そうしないと、他の管理対象サーバが起動したときに不要な RMI 呼び出しが行われて、起動に時間がかかる。

082910

EAR ファイル内からカスタム MBean を登録するときに、MBean を使用する JDBC 接続プールを削除できるようになった。

083400

管理対象サーバがデフォルト プロトコルとして T3s を使用して起動する際に、StackOverflow が発生しなくなった。

084484

ドメイン ディレクトリ以外のディレクトリからサーバを起動するときには、-Dweblogic.RootDirectory=<root directory> オプションを指定できる。起動スクリプトがルート ディレクトリに移動するように変更された場合、起動スクリプトはアプリケーションを検索したが、config.xml のパスは、RootDirectory を付加されて絶対パスに変更されていた。config.xml のパスは絶対パスに変更されなくなった。

084740

weblogic.deploy を使ってクラスタにアプリケーションをデプロイすると、サーバを再起動するまでデプロイメントは有効にならなかった。

086235

ServerRuntimeMBean.getWeblogicVersion メソッドからサーバのバージョンを取得しようとすると、クラスパスで最初にあるパッチのバージョン情報だけが返されていた。WebLogic Server 6.1 サービス パック 4 では、すべてのバージョン情報が weblogic.Admin コマンドから返される。

Web サービス

変更要求番号

説明

076510

Web サービスのメソッドが、実際には CDATA セクションを含む XML ドキュメントである String をパラメータとして受け取ると、メソッドを呼び出した後で、次の応答が送信されていた。

weblogic.soap.SoapFault: Connector - Bad request to the server

この問題を解決した。

082661

wsgen が余分なクラスパスを処理するようになった。

084960

URLConnection メソッドを使って Web サービスへの HTTP 接続を確立するときの問題を解決した。Weblogic は、java.net.HttpURLConnection を独自のバージョンでオーバーライドした。このバージョンは、ステータス コードが 400 より大きい場合は、getInputStream メソッドから例外を送出する。例外が送出されたとき、Web サービスのクライアントが入力ストリームを取得する方法はなく、HTTP SOAP バインドは壊れている。この問題が発生する場合は、新しいコマンドライン オプション -Dweblogic.net.http.ignore500status に true を設定する必要がある。

085214

Web サービスがパラメータとして日付を渡すときに発生する問題を解決した。java.lang.IllegalArgumentException は送出されなくなった。

WebLogic Tuxedo

変更要求番号

説明

077553

Tuxedo から WebLogic Server に整数配列オブジェクトを値で渡すと、weblogic.utils.AssertionError が送出された。

コードを修正し、この問題を解決した。

XML

変更要求番号

説明

080756

組み込みの XSLT プロセッサを使って日本語の文字を変換すると、意図しないコードに変更されていた。この問題を解決した。

080961

org.xml.sax.helpers.AttributesImpl.removeAttribute() にあった Xerces 1.3.1 のバグを解決した。

081372

入力エンコードが「Unicode」のときの DocumentBuilder.parse() がマルチスレッド セーフになった。

081870

XSLT 出力方法を HTML (必須)に設定すると (<xsl:output method="html"/>)、アンカー タグの HREF 属性内のスペースは、「%20」にエンコードされた。Netscape は「%20」をスペースとして解釈できず、リンクが壊れていた。この問題を解決した。

 


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

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

クラスローダ

変更要求番号

説明

063742

エンティティ Bean のリモート インタフェースに対するスケルトン生成の際に、java.lang.VerifyError が送出されていた。この問題を解決した。

064273

クラスローダ weblogic.utils.classloaders.GenericClassLoader で、definePackage() メソッドがマニフェストに従ってパッケージ情報を設定するようになった。

069506

EJB のマニフェスト ファイルの Class-Path: エントリ内にある XML ファイルにアクセスを試みると、 ClassLoader.getResources が動作するようになった。

075553

不必要なコア クラスローダが保存されていたために発生していたメモリ リークが解決された。

クラスタ

変更要求番号

説明

072281

WAPEnabled=true の場合に、HttpClusterServlet が正しく動作するようになった。

072464

サーバ内で作成された SFSB ハンドラを使用してフェイルオーバを行っても、NullPointerException が発生しなくなった。

073917

クラスタ内の SFSB のハンドラから、フェイルオーバ時に NoSuchObjectException が送出されていた。この問題を解決した。

073920

実行キューの長さはコンソールに表示されない。この機能は、WebLogic Server 6.1 では実装されていない。

074058

WebLogicCluster パラメータに対して DNS の代わりに IP 名を使用すると、一次サーバがダウンした場合に二次サーバが NONE に設定されていた。この問題を解決した。

074236

ClusterMBean に属性 MemberWarmupTimeoutSeconds を追加した。デフォルト値の 0 は、クラスタのウォームアップを行わないことを意味する。デフォルトでは、クラスタの起動シーケンスは変更されない。0 より大きい値を設定すると、クラスタのメンバは、起動の際に、指定された時間だけ待ってから他のメンバとの同期を取る。すべての MessageDriven Beans は、ウォームアップ時間が経過した後でデプロイされる。その後ではじめて、クライアント リクエストの受け付けが開始する。延期された MessageDriven Bean のデプロイメントに対する特別なプロパティはない。

コンソール

変更要求番号

説明

051136

コンソールから壊れたモニタ機能のリンクが取り除かされた。

055821

編集時にパブリック ID に対しては非 null が強制される。

056161

コンソールの EJB 実行時モニタのカスタマイズを使うと、EJB がデプロイされているマシンを見ることができるようになった。

058271

コンソールを使ってデプロイメント記述子を変更しても、Bean のマニフェスト ファイルが変更されなくなった。

059784

DefaultWebApp として wls_management_internal{1,2} を選択できなくなった。

059963

コンソールの [サーバ|コンフィグレーション] 画面に [最大オープン ソケット数] が追加された。

060116

WebLogic Server をプロダクション モードで起動すると、管理コンソールに [自動デプロイを有効化] チェックボックスが表示されなくなった。

061664

Netscape ブラウザを使用しても、サーバのシャットダウン メッセージが正しく表示されるようになった。

061686

デプロイメント記述子のヘルプの壊れたリンクが修正された。

061838

管理サーバを再起動しなくても、管理対象サーバを起動できるようになった。

062020

コンソールの XML エディタが <validate-db-schema-with> を認識するようになった。

062788

更新ボタンに対する Netscape のデフォルト値が修正されて、[OK] ボタンをクリックするたびにセキュリティ コンソールのページが再表示されなくなった。

062991

ノード マネージャを使って管理対象サーバをリモートで起動するための 5 つのフィールドをセットアップする方法を説明した情報が、コンソールのヘルプ ファイルに追加された。

063543

コンソールでのサーブレットのモニタに対する ConsoleMainAttribute が有効になった。

064849

weblogic.xml の記述子エディタが PersistentStoreTable パラメータを処理するように修正された。

067101 & 073625

コンソールを通してローカル JNDI ツリーを表示するリモート コンテキストが可能になった。

067362

コンソールが誤ったログイン タイムアウト属性を参照しなくなった。

070018

デフォルト ブラウザが Netscape 6.2 であっても、[Start Default Console] で異常が発生しなくなった。

072909

正しい JMS プール名が実行時テーブルに表示されるようになった。

073536

オプションの相互認証に対するチェック ボックスが Console に追加された。

074693

レルムの実装の変更を保存するために使われるリンクが、いっそう明確になった。

075338

Web アプリケーションのモニタ中に Console に表示される情報が正しくなった。

コア

変更要求番号

説明

CR073529

クラスタを構成する 2 サーバのコンフィグレーションの負荷 (Web ベース) テストにおいて、サーバのロックが発生した。

チャンク処理に対するコードを修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-20.jsp の「SECURITY ADVISORY (BEA02-20.00)」を参照すること。

EJB

変更要求番号

説明

047305

Console における TxCommits の値の誤りが訂正された。

054789

メッセージ駆動型 Bean が NoSuchElementException を送出しなくなり、メッセージ リスナが処理を終了する前にリスナがリストから削除されなくなった。

056081

EAR のデプロイメントは、コンポーネント ターゲット設定の前で停止する。

057608

4K より多くのデータを CMP Bean に保存できるようになった。

059045

ejbCreate()run-as が動作するようになった。

059250

WLDD に永続性要素がなくても、ejbc で NullPointerException が発生しなくなった。

060720

6.1 サービス パック 2 では、Blob/Clob を使用する場合は、<isolation-level>TRANSACTION_READ_COMMITTED_FOR_UPDATE に設定する必要がある。設定しないと、次の例外が発生する。
java.io.IOException: ORA-22920: row containing the LOB value is not locked
この場合、Blob/Clob を使用すると、コンテナがトランザクション内のすべてのテーブルをロックする。6.1 サービス パック 3 では、<isolation-level>TRANSACTION_READ_COMMITTED_FOR_UPDATE に設定する必要はない。コンテナは、Blob/Clob を含むテーブルだけをロックし、トランザクション内の他のテーブルはロックしない。これにより、Blob/Clob が格段に使いやすくなる。

060738

再起動した JMS サーバに JMS クライアントが再接続した後で対応する新しいセッションがリストに追加されず、実体のない複数のメッセージ駆動型 Bean 接続が作成されなくなった。

060867

RemoteMethod の名前が「find」で始まっていても、EJB2.0 のデプロイヤは AssertionError を送出しなくなった。

061700

生成される SQL クエリの一部の識別子に引用される識別子のエスケープがないため、生成される EJB CMP SQL で引用符で囲まれた識別子がエスケープされなかった。この問題を解決した。

062256

DDConverter で -c フラグを指定すると、入力の JAR ファイルが ejb20 に変換されて、複数の JAR ファイルが結合されるようになった。「java weblogic.ejb20.utils.DDConverter *****-c new.jar***** -d . convert.jar」のように指定された送り先 JAR ファイルでは、DDConverter が動作しなかった。

062481

EJB を Web 層と同じ場所に配置するかどうかを指定する属性が、weblogic-ejb-jar.xml に追加された。

062518

DDConverter は、findAll ファインダ クエリに遭遇しても例外を送出しなくなった。

062626

空の ejb-ql タグが許されるようになった。

062676

クラスタにおけるステートレス EJB のロード バランシングが、ランダムなロード アルゴリズムでも失敗しなくなった。weblogic-ejb-jar.xml で、デプロイメント要素 home-is-clusterable をステートレス セッション Bean に対して定義できる。

062916

6.1 サービス パック 2 では、サーバで開始したトランザクションが完了した後で、呼び出し側のトランザクションが再開していなかった。この状態になると、呼び出し側のトランザクションが永久に完了しなかった。この問題は、クライアントのトランザクションを一時停止させるトランザクション属性を持つ削除メソッドがトランザクション内の EntityBean で呼び出されて、呼び出しの処理を行うためにサーバで新しいトランザクションが開始されたときにだけ発生した。このような動作の原因となるトランザクション属性は、NotSupportedRequiresNew である。6.1 サービス パック 3 では、サーバで開始したトランザクションが完了した後で、呼び出し側のトランザクションが再開するようになった。

062974

1 桁のファインダが CMP 1.1 の Bean で定義されていると、クエリから複数の結果が返されても FinderException が送出されていなかった。この問題を解決した。

063077

weblogic-ejb-jar.xml のトランザクション タイムアウト 属性が機能するようになった。

063146

BMP EJB の同時方式が Exclusive に設定されていて、トランザクション属性が NonSupported に設定されている場合、トランザクション タイムアウトのしきい値に達すると、異なるインスタンスが割り当てられていた。この問題を解決した。さらに、ローカルなトランザクションがロールバックしても、リモート例外が送出されなくなった。

063387

デッドロック状況の後で、WebLogic Server がエンティティ Bean に対するロックのクリアに失敗しなくなった。LockManager の待機者がクリアされるようになった。

063469

CMP EJB の関係を作成している際に、NullPointerException が送出されなくなった。

064293

待機者が TimedOut になった場合でも、ExclusiveLockManager はリストから待機者を削除するようになった。

064425

ejbHomeMethod の個々の呼び出しでは、プールされている Bean インスタンスを利用するのではなく、新しい Bean インスタンスを作成していた。この問題を解決した。

064447

クッキーから EJB オブジェクト ハンドルをデコードしても、InvalidClassException が送出されなくなった。

064561

<finders-load-bean>=false の場合、プールされているインスタンスを無視して、新しい Bean インスタンスが作成されていた。この問題を解決した。

064625

受け取るべきではないときに、JDBC から「local interface must not include java.rmi.RemoteException in its throws clause」を受け取ることがなくなった。

064967

環境変数が空の文字列であっても、ejbc で異常が発生しなくなった。

064969

DDConverter が正しいアセンブリ記述子を生成するようになった。

065092

6.1 サービス パック 2 における EJB1.1 Bean では、単一のトランザクションにおいて、Bean の永続フィールドを変更した後で同じ Bean を返すファインダを呼び出した場合、永続フィールドの新しい値は、データベースから取り出された値で上書きされる。6.1 サービス パック 3 では、EntityBean に対する変更がトランザクションの途中で失われることはなくなった。

065290

クラスタリング可能な Bean に対しても、EJBC/RMIC は clusterable=true にした XML 記述子を生成する。

065321

エンティティ Bean に関するロックの問題を解決した。

065571

エンティティ Bean に create メソッドがないと、DDinit が Descriptor ファイルを生成しなかった。この問題を解決した。

066245

ctx.getCallerPrincipal が run-as プリンシパルを返さなくなった。

066644

永続的ファイル ストアを備えた JMS のメッセージ駆動型 Bean と Queue が、onMessage のトランザクション コンテキストを持ち越していた。この問題を解決した。

067018

ホーム メソッドから EntityContext.getEJBLocalHome を呼び出すと、IllegalStateException が送出されていた。この問題を解決した。

067515

5.1/6.1 の相互運用性テストの際に JSP を呼び出すと、最初は成功するが、2 回目にはエラーが発生していた。この問題を解決した。

068262

EJB1.1 Bean では、setBytes を使って LONG カラムに値を挿入していた。データが 4K より大きいと、この処理は失敗した。setBinaryStream を使うようにしたので、次の例外は発生しなくなった。
ejbCreate(): java.sql.SQLException: ORA-01461

068569

サーバサイド ejbc を使っていなくても、tmp_ejb ディレクトリが作成されていた。この問題を解決した。

068971

ejbc は、CMP EJB に対して非推奨のメソッドを含む JDBC コードを生成しなくなった。

069280

エンティティ Bean に対するクライアントの並行呼び出しの際に、Illegal Reentrant Error が誤って送出されなくなった。

069391

CMP パートナに対して壊れていた CMP マネージャ cascadeDeleteRemove を解決した。

070099

method-permission タグを生成するように DDConverter が修正された。

070565

EJB が Web 層と同じ場所に存在することを示すために、clients-on-same-server という名前のプロパティが weblogic-ejb-jar.xml に追加された。これは、マルチキャスト トラフィックを減らすために行われた、パフォーマンスに関する修正である。プロパティのデフォルト値は false である。

070754

6.1 サービス パック 2 では、ステートレス セッション Bean のメソッドがまだ処理を行っている間に、Bean で afterCompletion が呼び出されていた。この動作は、EJB 2.0 の仕様に違反している。6.1 サービス パック 3 では、ビジネス メソッドと EJB コールバックのシリアライズが行われており、ステートフル セッション Bean のメソッドが処理を完了するまで、Bean で afterCompletion が呼び出されることはない。

071027

これまで、コンテナは、SQL クエリ (select * from tableName where 1=0) を発行して CMP テーブルをチェックしていた。DB2 の場合、クエリによりテーブル全体のスキャンが行われて、テーブルのデータが多いと非常に時間がかかるため、このチェック方法では効率が悪い。そのため、DatabaseMetadata を使ってテーブルをチェックするオプションが、コンテナに用意された。この方法は、通常は SQL クエリを使うチェックより処理が遅いが、DB2 に関しては SQL クエリより効率がよい。詳細については、weblogic-rdbms-jar.xml ファイルの <validate-db-schema-with> タグを参照。

071296

エンティティ Bean (EJB 2.0) で ejbCreate() を実行すると、java.lang.IllegalStateException が送出されていた。この問題を解決した。

071377

EJB QL 拡張機能「? IS [NOT] NULL」を生成する機能がサポートされるようになった。

074710

クラスタでステートフル セッション Bean を実行しても、エラーが発生しなくなった。ステートフル セッション Bean に対してパッシベーションを行うとリモート エントリが削除され、Bean がアクティブ化されるとリモート エントリが返らなかったため、NullPointerException が発生していた。

075867

WebLogic Sever 上にデプロイされたメッセージ駆動型 Bean には、MQSeries JMS サーバに対する接続の再確立に関して問題があった。スケジューリングされるトリガの数のため、余分な接続が作成されていた。この問題を解決した。

076167

6.1 サービス パック 2 では、読み取り専用 Bean の ejbLoadSQLException が送出されると、呼び出し側の(グローバル)トランザクションが再開しなかった。6.1 サービス パック 3 では、再開されるようになった。

078147

EJB11/ CMP11 Bean の使用時に発生していた次の例外の原因である問題を解決した。

Exception in ejbCreate(): java.sql.SQLException: ORA-01461: can bind a LONG value only for insert into a LONG column

サンプル

変更要求番号

説明

048185

ACL サンプルが、クライアント サンプルでドキュメント化されるようになった。

053467

i18n.logging.message ディレクトリの 2 回目のコンパイルでエラーが発生しなくなった。

056884

サンプルに対する説明の誤りを訂正した。

057904

接続プールの変更が、petstore.html に記述されるようになった。

062545

Solaris simpappcns を実行する WebLogic Server ドメインが、NT で動作する Tuxedo Corba Server ドメインを呼び出すことができなかった。

simpappcns は、Solaris で稼働する Tuxedo と Windows NT で稼働する WebLogic Server のようなマルチプラットフォーム環境に対して動作するようになった。

062962

JAAS サンプルのユーザ名/パスワード認証が、CertLoginModule を使って UNIX 環境でも動作するようになった。

062999

WebLogic Server と Tuxedo の間の WLEC 接続を確立するときに発生していた問題を解決した。WLEC の simpapp サンプルが、Tuxedo サービスに接続できるようになった。

063229

examples/iiop/ejb/stateless/server/tux を改善した。

071478

固有のウィンドウによって JMS Draw デモ サンプルが壊れなくなった。

077055

Petstore サーバでエラーが発生して Petstore をデプロイできなくなる原因となっていた問題を解決した。

JDBC

変更要求番号

説明

052393

StringBuffer オブジェクトを配置する際に JDBC セッションの永続性でエラーが発生しないよう、シン ドライバを更新した。

054864

6.1 サービス パック 2 では、高負荷の状況において複数のデータベースで MultiPool を使用すると、サーバがハングしていた。データベースが応答しないために MultiPool リクエストがハングし、それによって、weblogic.jdbc.common.internal.MultiPool.searchHighAvail(MultiPool.java:200) においてサーバ全体がロックしていた。原因はコードにおいて過剰な同期を行っていたためであり、この問題は6.1 サービス パック 3 で解決された。

057340

接続プールが空の場合は、「No available connections in pool」というメッセージが表示されるようになった。

057977

JTS 接続のクリーンアップにおいて、接続プールがロールバックしなくなった。

059020

接続プールが別のユーザに使われているときに weblogic.jdbc.common.pool.shutdownSoft() を呼び出しても、デッドロックが発生しなくなった。

061786

DESTROY_POOL の直後に CREATE_POOL が接続プールを起動するようになった。

064198

一部のクラスは、サーバ サイド コードの中で、オプションの Oracle クラスを直接参照していた。このようなことは行われなくなった。

066001

データベースのパスワードを暗号化するためのプロパティが、JDBCConnectionPool XAPassword に追加された。

066964

JDBC 接続プール用に WebLogic jDriver for Oracle/XA を使用している場合、DBMS の障害と復元の後で接続プールをリフレッシュすると、コア ダンプが発生する場合があった。この問題を解決した。

066966

テスト テーブルに対する JDBC 呼び出しを行っている間、ResourceAllocator モニタが保持されなくなった。

068490

Java レベルで xa_open に対する呼び出しの同期が取られた。

068952

jDrivers に対する自動化されたビルド スクリプトが提供された。

070209

Oracle 9.0.1 シン ドライバを使って Oracle データベースに接続できるようになった。ドライバを使用するには、CLASSPATH において、ドライバのクラス ファイル (classes12.zip) に対するパスを、weblogic.jar に対するエントリの前に追加する。

071974

PreparedStatement キャッシュ サイズがデフォルトで 0 に設定されるようになった。

073640

JDBC 接続プールに対する新しい属性 Open String Password(config.xml ファイルの XAPassword)が追加された。この新しい属性を使うと、オープン文字列を必要とする XA JDBC ドライバを使用する接続プールに対するオープン文字列中のデータベース パスワードを暗号化できる。詳細については、『管理者ガイド』の「接続プールのコンフィグレーションにおけるデータベース パスワード」を参照。

076090

JDBC 接続プールの Properties 属性に含まれるデータベース パスワードの動作が改善された。接続プロパティまたはオープン文字列の一部としてデータベースのパスワードを指定した場合、WebLogic Server はその値を解析して、それぞれ Password 属性と Open String Password 属性に移す。これらの値は、config.xml ファイルに格納される際に暗号化される。詳細については、『管理者ガイド』の「接続プールのコンフィグレーションにおけるデータベース パスワード」を参照。

jDriver

変更要求番号

説明

056531

jDriver におけるパフォーマンスの低下がなくなった。

061643

データベースの回復の後で、weblogic.AdminRESET_POOL で障害が発生しなくなった。

063872

ストアド プロシージャの出力パラメータから文字列値が返る場合、末尾のスペースが取り除かれなくなった。

063874

JDBC の getDate() メソッド使用時に、SQL DATE の時間コンポーネントが除去されるようになった。この動作は、java.sql.Date に対する JDBC 2.0 の仕様に準拠していなかった。「SQL DATE の定義に準拠するには、java.sql.Date インスタンスによってラップされるミリ秒の値は、そのインスタンスが関係する特定のタイム ゾーンにおいて時、分、秒、およびミリ秒をゼロに設定することにより、「正規化」されなければならない」。

WebLogic jDriver for Oracle を修正した。JDBC getDate() メソッドの戻り値から、時、分、秒、およびミリ秒を除去するようにした。

069109

JDBC のテスト スクリプトが変更されて、Oracle 8.1.7 がデフォルトになった。

069676

WebLogic jDriver for Oracle が、we8iso8859p15 文字セットをサポートするようになった。

070878

WebLogic jDriver for Oracle を使用して作成された DBMS 接続で、不正な位置インデックス「0」を指定して PreparedStatement.setString を使用すると、JVM がクラッシュしていた。jDriver は、コーディング エラーを適切に処理し、例外を送出するようになった。

078936

WebLogic Server 6.1 Service Pack 2 では、HP-UX UNIX パッチ (PHSS_24627) のアプリケーションが原因で、WebLogic Server 6 が起動時に Oracle にアクセスすると、HP サーバ バス エラーが発生した。より新しいバージョン A.03.33 の aCC ライブラリでは、-AA CXXFlag を使用すると、WebLogic Server 起動時の Oracle へのアクセスにおいて、java.lang.UnsatisfiedLinkError が発生した。

この問題を解決した。

JMS

変更要求番号

説明

044976

MapMessage の get メソッドからの戻り値と例外が、JMS の仕様に準拠するようになった。

058876

Administration Console から JMS サーバを無効または有効にすると、登録されている恒久サブスクライバに対して例外が送出されていた。この問題を解決した。

061094

クラスタ環境において、クラスタの WebLogic Server ノードの 1 つがシャットダウン後に直ちに再起動しない場合でも、JMS サーバでリスンしている JMS クライアントに対して NoSuchObjectException が送出されなくなった。

061552

サーバが 3 時間アイドル状態になっていても、JDBC 接続がリセットされなくなった。

062669

JMS が Unicode 文字列のセレクタをサポートするようになった。特に、表現パーサが StringReader を使うようになり、charVocabulary の範囲が増やされた。

062744

JMS の仕様に準拠するよう、JMS の MapMessage プロパティに対して NULL 値が受け付けられるようになった。

064727

アプレット内の JMS に対する ObjectMessage の作成に関する問題を解決した。

067134

weblogic/management/configuration/JMSConstants.STORE_ENABLED_XXX が追加された。

067286

JMS ページングが、サーバの再起動中にページングを失敗しなくなった。

068667

起動時に、JMS の非永続的メッセージ ページング ファイル ストアが、すべてのディスク ブロックを再利用可能にできなかった。この問題を解決した。

069757

SSL を使用する JMS が weblogic.jms.common.LostServerException を送出しなくなった。

070454

恒久サブスクリプションと共にメッセージ駆動型 Bean を使用している場合、サーバのクラッシュに対してメッセージの回復が失敗または遅延しなくなった。

072556

addReader() で JMS キューがデッドロックしなくなった。

073403

異なる種類で同じ JNDI 名を持つ JNDI オブジェクトによる問題を解決した。

JTA

変更要求番号

説明

062681

JDBC コードにおいて接続オブジェクトがクローズされない場合でも、プールに対する JDBC 接続リクエストで障害が発生することがなくなった。

063053

XA 接続で openString プロパティを指定できるようになった。

064232

javax.transaction.HeuristicMixedException がコミット時に送出されなくなった。

064403

XA ドライバとステートレス セッション Bean を使用するトランザクションがタイムアウトした後は、WebLogic Server を再起動するまで XAConnection が利用できなかった。この問題を解決した。

064825

SubCoordinatorImpl に対するメソッド記述子が、実行時に解析されるようになった。

065495

コーディネータの参照を取得するまでの待機時間を設定できるシステム プロパティが追加された。待機時間を設定するには、クライアントまたはサーバの起動時に -Dweblogic.JTA.ContactCoordinatorWaitSeconds=<seconds> を指定する。

066420

メンバ サーバの peerGone イベントに対して JTA のサーバ リソース キャッシュが正しく更新されていなかった。この問題を解決した。

068447

TestConnectionsOnReserve="true" を指定された XA トランザクションが失敗しなくなった。

070855

負荷のある状態で延期された JTA サーバ リソース キャッシュの更新によってトランザクションが中止されなくなった。

076439

Illegal State (Expected: preparing)」メッセージと共にランダムな XA トランザクションがロールバックする原因となっていた問題を解決した。

その他

変更要求番号

説明

042372

WebLogic で提供されている API URL() が正しく機能するようになった。以前は、一部の URL に対して例外エラーが発生していた。

050388

Jolt 接続プールに対する統計情報が Console に表示されるようになった。

052478

Solaris にはタイミングに関する JVM のバグがあり、サーバ起動時の管理オブジェクトのデシリアライズ中に VM が終了する原因となっている。この JVM のバグが発生した場合は、次の方法で対処する。

  • サーバを再起動する。

  • 仮想マシンを JDK バージョン 1.3.1_04 にアップグレードする。

053029

RA コンポーネントが削除中に除去されるようになった。

054080

Solaris マシンの 6.1 サービス パック 2 では、SSL を使って(クライアントおよびサーバとして)通信している WebLogic Server が NativeIOEnabled="true" を使用すると、JVM インスタンスが消費するメモリが増え続け、最終的にヒープ サイズの限度に達していた。このバグは、取引パートナ間の SSL 通信に依存する WebLogic Integration のインストール環境で発生していた。この問題は、6.1 サービス パック 3 で解決された。

055007

許される接続の数を決定するコンフィグレーション可能なパラメータ weblogic.system.openSockCount が作成された。

056622

新しいシステム プロパティ weblogic.net.http.URLStreamHandlerFactory が追加された。

056698

顧客プロトコル ハンドラをインストールするときの問題を解決した。

057313

AbbrevMap を反復処理する際の ConcurrentModificationException を解決した。

057357

エラー ページ 401 を定義するときに発生していた問題を解決した。

057743 & 060981

WebLogic Server の verboseToZip ユーティリティと logToZip ユーティリティによって、バージョン情報に関する問題を修正した。WebLogic のクラスがバージョン情報に関して依存するマニフェストのエントリが、weblogic.jar から抽出されるようになった。verboseToZip の出力ファイルには、動的なプロキシ クラスのエントリが含まれなくなった。メッセージ ログに i18n メッセージのインスタンスが含まれている場合、logToZip は、i18n 関連のすべてのファイルを weblogic.jar からクライアントの jar に抽出する。

058327

アプレットから DataSource へのルックアップを試みるとき、 ClassCastException を取得するようにした。

058358

application.xml ファイル中の <alt-dd> タグが認識されるようになった。

059054

クッキーの区切り文字として「,」が追加された。

059104

管理対象サーバの起動に使用される JVM を指定するプロパティ javaHome がノード マネージャに追加された。

060062

接続プール モニタ画面の [最大接続数] カラムに、WebLogic Server によって更新される接続が含まれなくなった。

060079

t3s 経由で JMS を使用すると、メッセージ サイズが 50K を超えていなくても、MaxMessageSizeExceededException が送出されることがあった。

060211

Console の [リモート スタート] タブからノード マネージャに渡される起動引数の配置と引用が修正された。

060739

負荷があっても UserTransaction が正しく動作するようになった。ユーザがトランザクションを開始した場合と同様に、EJB がトランザクションを開始した場合も、トランザクション管理による EJB がアイソレーション レベルを自動的に制御する。

061059

データベースから削除されてしまったレコードは発見できなくなった。

061458

WebLogic Server は、ネイティブ ライブラリを使わなくても Solaris および HP-UX で NodeManager の起動をサポートするようになった。

061512

Windows NT および Windows 2000 のサービスとして WebLogic Server を起動するときの問題を解決した。

061847

examples.io.FileBrowser で HTTP を使用しても、エラー メッセージが発生しなくなった。

062086

DDConverter を使って CMP 1.1 から CMP 2.0 に変換しても、複数の EJB を含む JAR ファイルに対する例外が送出されなくなった。

062177

クラスタ化されたノード間でピア ツー ピア接続が使われなくなった。

062375

クラスタ環境においてトランザクションの伝播コンテキストをマーシャリングしても、PeerInfoable.getPeerInfo が null を返さなくなった。

062439

Windows のネイティブ レイヤにエラー処理コードが追加された。

062565

1.2 JVM クライアントによってソケット接続リークが発生しなくなった。

062752

100 行以上が選択される外部結合操作において、jDriver から ORA-24347 エラーが発生していた。この問題を解決した。

062926

Solaris または HP において、JSP ページのタグが MS932 固有の文字を処理できるようになった。

062989

低速のモデム接続を使用する JMS が、2 つの WebLogic Server で構成されるクラスタと JMS の topicConnection を確立しようとしても、ClassCastException が発生しなくなった。

062997

ソース ファイルが削除された場合、サーブレット エンジンが生成される JSP ファイルのサーブレット スタブを削除するようになった。

063103

生成されたスレッド内でコンテキスト ルックアップが失敗していた。この問題を解決した。

063147

JDK 1.3.1_01 プラグインでホーム インタフェース スタブをダウンロードしている最中にアプレットで異常が発生しなくなった。

063310

負荷のある状況でファイル記述子のリークのために CGIServlet で異常が発生することがなくなった。

063354

サーブレットからセッション Bean をルックアップする際に、rjvm.MsgAbbrevInputStream.readClassDescriptor() から ClassCastException を受け取らなくなった。

063671

HTTPS トンネリングを使用するクライアント サイドで、get の java.net.ProtocolException が発生していた。トンネリングの結果は OK ではなく、「DEAD(応答なし)」であった。

063830

キャッシュが一杯でも javax.transaction.TransactionRolledbackException が送出されなくなった。

064117

サーバが接続を中止して java.net.SocketException を送出する原因となっていた問題を解決した。

064125

ノード マネージャでサーバを起動すると、起動コマンドにパスワードが表示されていた。コードを修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-15.jsp の「SECURITY ADVISORY (BEA02-15.00)」を参照すること。

064130

IIOP 下で複数のルックアップを実行できるよう、ReplicaLists がシリアライズ可能になった。

064391

不正な MANIFEST.MF エントリを含むアプリケーションをデプロイしても、例外が送出されなくなった。

064404

IE の同じインスタンスを使って、Console を使用する webApp をコンフィグレーションした後、同じ webApp(たとえばフランス語の文字を含む)にアクセスすると、アクセント記号の付いた文字が正しく表示されないことがあった。この問題を解決した。

064434

サーブレットが RequestDispatcher.include() を使って JSP の出力を取り込んでいると、後処理フィルタが応答にヘッダを追加できなかった。この問題を解決した。

064860

ページ バッファリングを使用する JSP と共に CGI スクリプトを実行しても、異常が発生しなくなった。

065697

SetUID が有効になっていると、サーバが起動しなかった。この問題を解決した。

066130

準拠チェックの際に ejbc が送出していたエラー メッセージを修正した。

066158

ログ フィルタが定義されていて、管理対象サーバが対象になっている場合、NonCatalogLogger を使用するとトラップが生成されるようになった。

066252

特定の Factory/Trader パターンを使用すると、クライアント サイドで ReplicaAwareRemoteRef の警告ログが表示されていた。このログは表示されなくなった。

066504

Solaris および Windows 用の JDK 131_02 の SP インストーラが更新された。

067508

AppletArchiver でシン クライアントを生成すると、一般的なクラスローディング例外が送出されていた。この問題を解決した。

067516

appletArchiver が、i18n とマニフェストのファイルをシン クライアントの jar にスプールするようになった。

067517

クライアントの jar を作成するときに、AppletArchiverL10n タイプの例外を生成しなくなった。

067648

PosixSocketMuxer のコードのために WebLogic Server が ハングする原因となっていた問題を解決した。

068570

エージェントが DoS 攻撃の影響を受けないよう SNMP キットがアップグレードされた。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-16.jsp の「SECURITY ADVISORY (BEA02-16.01)」を参照すること。

069043

フィルタと共に HttpProxyServlet を使用しても、NTSocketMuxerSocketResetException が発生しなくなった。

069675

BEASVC のコマンド ラインで @file オプションを指定してファイルから読み込む際の 4K の制限がなくなった。

069991

サーブレットからセッション Bean をルックアップしても、rjvm.MsgAbbrevInputStream.readClassDescriptor() から ClassCastException を受け取らなくなった。

070575

サーバが約 2 日間稼働すると、最終的に JNDI ツリーと JNDI オブジェクトが同期しなくなり、別の JVM で動作するクライアントが Bean をルックアップできなくなっていた。この問題を解決した。

071580

WebLogic の Time サービスが、Context Class Loader を設定するようになった。

071822

jCOM が WebLogic のライセンス ファイルを正しく発見できるためには、beahomelist ファイルが C:¥bea に存在していなければならない。

072010

WLEC 接続プールのコンフィグレーションが、コマンド ラインのプロパティと競合していた。この問題を解決した。

072061

ノード マネージャの -Dweblogic.nodemanager.sslHostNameVerificationEnabled=true オプションでホスト名の検証が実行されるようになった。

072211

エラー状態の処理についてノード マネージャの Solaris ネイティブの実装が改善された。

072228

管理サーバで JDBCConnectionPoolRuntime に対するトラップが生成されていなかった。この問題を解決した。

072278

エラー状態の処理についてノード マネージャの HP-UX ネイティブの実装が改善された。

072327

LONG 型の属性を SNMP でモニタできるようになった。

072495

Timer サービスが原因で発生していたメモリ リークを解決した。

072904

CallRouter を使用すると、ReplicaList が壊れていた。この問題を解決した。

073116

weblogic.AdminSERVERLOG コマンド ライン ユーティリティを修正した。

073201

モデム接続を通して複数の HTTP トンネリング クライアントを実行すると、サーバが最終的にハングしていた。この問題を解決した。

073400

出力ファイルから javax クラスを除外してクライアント JAR のサイズを小さくするよう、verboseToZip を変更した。

073529

クラスタ化されたサーバが厳しい負荷テストにおいてロックする原因となっていた問題を解決した。

073569

ファイルの領域を節約するため、weblogic.log ファイルから <DGCserver> 情報メッセージが除かれた。

073578

JAVA_HOME として JRE ディレクトリを指定して Windows NT サービスをインストールすると、サービスの起動時にエラーが発生していた。この問題を解決した。

073788

HP のインストーラがビルドに失敗していた。この問題を解決した。

074991

高負荷においてパフォーマンス パックで WebLogic Server がクラッシュする原因となっていた問題を解決した。

075271

weblogic.utils.BubblingAbbrever.getValue (BubblingAbbrever.jaava:163)NullPointerException が送出されなくなった。Abbrev ツリーが壊れなくなった。

075700

WebLogic Server のインスタンスが Windows サービスとして実行される場合、サービスを実行するために Windows の Administrator 特権が必要なくなった。

076395

WebLogic Server のインスタンスが Windows サービスとして実行される場合、Administration Console または weblogic.Admin ユーティリティを使ってサーバをシャットダウンしても、Windows サービスでエラー状態が報告されなくなった。

076705

送り先がリモートの場合でも、guest に対する NoAccessRuntimeException によって MessageDriven Bean のデプロイが失敗することがなくなった。

077238

起動スクリプトが、正しい値の Oracle jDriver パスを指定するようになった。このサービス パックより前の起動スクリプトでは LD_LIBRARY_PATH=oci816_8 と指定されていたが、このパスはサポートされなくなっている。現在は、oci817_8 が指定されている。

077278

WebLogic Server 6.1 サービス パック 3 のインストールから、Oracle 816/806 ドライバが削除された。

077919

EJBHandleObjectOutputStream.writeObject() を呼び出すと「Closing:'weblogic.rjvm.t3.T3JVMConnection@49c89f' because of: 'Server received a message over an uninitialized connection」というエラーが送出される原因になっていた、以前のバグ修正に関する問題を解決した。

078523

WebLogic Server 6.1 サービス パック 3 のインストーラには、次のバージョンの Java がバンドルされている。

  • Windows 2000 および Solaris のインストーラには、Java バージョン 1.3.1-03 がバンドルされている。

  • HP のインストーラには、Java バージョン 1.3.1.05 がバンドルされている。

プラグイン

変更要求番号

説明

054344

WebLogic Server は、一部の MIME タイプを除くすべてのリクエストをプロキシできるようになった。

057448、059142

高負荷の下で SSL を使用すると発生していたメモリの問題を解決した。

058886

SSL を使用する IIS Proxy でのメモリ リークを解決した。

060325

GET リクエストと POST リクエストが同時に発生すると、Apache プラグイン内でハングしていた。

060863

NSAPI と ISAPI のプラグインの問題を解決した。2 回目のリトライが成功し、この HTML の内容がブラウザに出力された後であっても、POST タイムアウト エラーがブラウザに出力されていた。

061229

ハンドラが明示的に weblogic_handler に設定されていない場合、リクエストは拒否されるようになった。

061379

RequireSSLHostMatch=true が NSAPI で機能するようになった。

061386

新しいコンフィグレーション属性 WeblogicPluginEnabled が追加された。 この属性はサーバ レベルまたはクラスタ レベルでコンフィグレーションできる。

プロキシ プラグイン (または HttpClusterServlet) からリクエストを受信するサーバ (またはクラスタ) でこの属性が true になっている場合、getRemoteAddr を呼び出すと、Web サーバの代わりに、独自の WL-Proxy-Client-IP ヘッダからブラウザ クライアントのアドレスが返される。

プロキシされるリクエストを受信する、クラスタ化されていないサーバの場合は、[サーバ|コンフィグレーション|一般] タブで、この属性をサーバ レベルで設定できる。

WeblogicPluginEnabledClusterMBeanServerMBean で重複する。 ClusterMBeanServerMBean をオーバーライドする。 デフォルト値は false。

061561

ハングしたサーバからのフェイルオーバにおいて、リクエストがタイムアウトしなくなった。

061881、 065980、076503

NSAPI プロキシ プラグインが 2k より大きい POST リクエストを処理しても、問題が発生しなくなった。

062607

プラグインの IIS で KeepAlive が有効になっている場合、HEAD HTTP リクエストで接続が直ちに閉じるようになった。

062641

IPlanet プラグインで、JSSE を使用する Java クライアントからのサーブレット アクセスが機能するようになった。

062778

プラグインは、一次/二次サーバが現在のサーバ リストにあるかどうかをチェックしないで、これらのサーバへのリクエストをプロキシできるようになった。

062808

Apache 2.0 の最新のベータ版に対するサポートが追加された。

063004

Apache プロキシ プラグインが、高負荷の下で不正な URL を生成しなくなった。

064153

Solaris 用 (libproxy.so) および Win32 用 (proxy36.dll) の NSAPI プラグインが、プロキシ中に、URL の %20 をスペースに置き換えなくなった。

064268

応答ヘッダのステータス「HTTP/1.1 200 OK」で、文字列「OK」が iisproxy.dll によって取り除かれなくなった。

064472

mod_wl_ssl.so を使用する Solaris 2.8 の Apache 1.3.12 EAPI で、ポート ベースの仮想ホストを使うと「Segmentation Fault - core dumped」が生成されていた。この問題を解決した。

064890

Apache で PathTrim を使用しても、クッキーのパスが壊れなくなった。

065188

静的ページに対して 404 エラーの WRITE_ERROR を生成しないよう、iPlanet プラグインが修正された。

065443

NSAPI プラグインで 5.1 と 6.1 のバックエンドに対してプロキシを実行できるようになった。

065660

最後の ISAPI プラグインで HTTP ヘッダが壊れる。

067100

プラグインのビルド情報にバージョン番号が含まれるようになった。

068243

Web アプリケーションに対してフォーム認証を使用しても、ISAPI プラグインの PathPrepend パスが 2 回付加されることがなくなった。

068517

プロキシ プラグインが、ECC 暗号モジュールをロードしなくなった。

068562

複数のサイトに対してプロキシを行うように IIS をセットアップするとき、IIS サーバの前面にファイアウォールまたはロード バランサを置くと、プラグインが動作しなかった。この問題を解決した。

068634

Content Length がプラグインのパラメータ MaxPostSize を超えると、413 エラーが返るようになった。

068790

Apache2.0.32 をサポートするようになった。

068985

WebLogic Server で特定のリクエストをプロキシから除外する機能が追加された。

070358

サーバが利用できないとき、Apache プラグインは応答コード 500 を返さなくなった。

072895

二次サーバが削除されているとき、リクエストが同じサーバ(一次)に送信されていなかった。現在は送信されるようになった。

073838

iPlanet を使用している場合、CookiesEnabled が false に設定されていても、HTTP セッション ID が失われなくなった。

073936

Apache プラグインが、OpenVMS 7.3 プラットフォームに移植された。

074137

x-forwarded-for ヘッダと client-proxy-ip ヘッダが送信または設定されていない場合、NSAPI プラグインが「unknown」を返していた。この問題を解決した。

074286

Apache プラグインで 5.1 と 6.1 のバックエンドに対してプロキシを実行できるようになった。

074393

最新の iPlanet プラグインでは URL パラメータが削除されたので、正しい requesturi 変数に URL パラメータが追加された。

074656

WebLogic Server を起動するパスワードがコマンド ラインで提供された場合、プロパティ weblogic.security.jaas.Configuration が初期化されなかった。この問題を解決した。

076457

高負荷(800 ユーザ以上)の下でも、NSAPI プラグインが安定するようになった。

076578

NSAPI プラグインが、応答不能のサーバへの接続の試みを続けなくなった。

076701

Content-Length が 0 の場合はサーバがポスト データを読み取らないよう要求することで、POST リクエストの Content-Length が 0 の場合でも、Apache サーバがクラッシュしなくなった。

076722

POST リクエストの Content-Length が 0 の場合でも、Apache サーバがクラッシュしなくなった。

076731

特に指定されている場合は、一次サーバと二次サーバがロックされていると、NSAPI プラグインはアクティブなサーバにフェイルオーバするようになった。

076996

SSL のメモリ リークの問題を解決した。

077440

プロキシの IP アドレスが HTTP リクエスト ヘッダに設定されるようになった。

077794

このリリースでは、Apache 2.0 に対するキープアライブ機能が無効になった。

078265

DynamicServerList=OFF の場合は MaxSkips が使われるようになった。

078883

長い URL で URL の書き換えを使用しても、NSAPI プラグインでコア ダンプが発生しなくなった。

RMI over IIOP

変更要求番号

説明

047057

IIOP の実装において、複雑なオブジェクトに対するサポートが修正された。

062082

IIOP URL の解析が改善された。

067013

デバッグが有効になっている場合にだけ、リースの更新が失敗したときに常に onMessages が出力されるようになった。

072179

プール ドライバまたは DataSource から取得された JDBC 接続に関するクローズされないときの動作の違いを解決した。

073028

カプセル化本体の前のチャンクの継続が許されるようになった。

073889

MuxableSocketIIOP がチャンクで複数のメッセージを受信し、超過量がメッセージ ヘッダの長さより短い場合、メッセージ長を読み取るための以降の試みが誤っていた。この問題を解決した。

074100

Muxer の境界条件が原因でメッセージが壊れることがなくなった。

セキュリティ

変更要求番号

説明

061659

WebLogic Server が、コンフィグレーションされている NTrealms で起動するようになった。

061694

SSLClient サンプルを実行すると、weblogic.security.provider.MD2.<init>(MD2.java:24)NullPointerException が送出されていた。この問題を解決した。

062172

ブラウザでクッキーが無効になっている場合、フォーム ベースの認証がセキュアな JSP/サーブレットにリダイレクトされるようになった。

062261

EJB の SessionContext.getCallerPrincipal() におけるセキュリティの問題を解決した。

062988

NT レルムと複数の PDC に関する問題を解決した。

063349

AuthFilter クラスを実装すると、doFailAuth() メソッドと doSuccessAuth() メソッドが呼び出されるようになった。

063763

双方向 SSL の Java クライアント接続が、暗号化されたプライベート キーで動作するようになった。

064250

Web サーバが、セッション ID の強制に対して無防備ではなくなった。これは、フォーム ベースの認証で保護されている Web アプリケーションに適用される。

064263

322122 より大きいロックアウト遅延で、ユーザがロックアウトされるようになった。

064285

ssl.proxyHost/ssl.proxyPort で SSLClient を実行すると、SSLHostnameVerifier が意図したとおりに動作するようになった。

064342

password.ini を使用しないで、または -Dweblogic.management.password=$password プロパティを指定しないで、echo $password コマンドの出力を Java インタープリタにリダイレクトして WebLogic Server を起動できるようになった。

065046

システム パスワードが変更されたとき、ManageableRealm.newAcl() が NULL を返さなくなった。

065314

LDAP Version 2 では自然言語を含むユーザ名に関する問題が発生しなくなった。

066232

RMI/IIOP の PingClient サンプルにおける双方向 SSL が動作するようになった。

066264

日本語版 Windows 2000 を使用するロックアウト メカニズムに関する問題を解決した。500 エラーが発生していた。

066491

ブラウザがドメイン ディレクトリのファイルにアクセスできた。

コードを修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-17.jsp の「SECURITY ADVISORY (BEA02-17.00)」を参照すること。

067726

フォーム ベースの認証に関する問題を解決した。

068524

RMI/IIOP での双方向 SSL および EJB アクセスと認証が、SimpleCertAuthenticator サンプルで動作するようになった。

069083

周辺認証に関する問題を解決した。

069160

クラスタ化されていないサーバに対して ClientCertProxyEnabled を設定する手段が提供された。

070870

LDAPRealmv2 が完全に実装されるようになった。

071167

iPlanet プロキシ サーバを経由して HTTPS をトンネリングしたときに、ProtocolException が発生しなくなった。

072096

SSL と DebugRC4="true" を使って管理対象サーバを起動できるようになった。

072916

Serializable を実装するように weblogic.security.X500Name クラスが変更された。

075109

LDAPRealmv2 がメンバーシップをキャッシュするようになった。

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

変更要求番号

説明

044528

特定の状況では、isUserInRole が、true を返すべきときに false を返していた。この問題を解決した。

051065

JSP ページの XML ビューの XML フラグメントが、出力に渡されていなかった。標準タグでもカスタム タグ(タグ ライブラリ)でもない非標準フラグメントが、出力の現在値にそのまま送信されるようになった。

054694

RequestDispatcher がインクルード/転送に対して適切にフィルタを呼び出すようになった。

055333

JSP の途中で contentType ディレクティブを検出すると、JSP コンパイラで異常が発生していた。

056153

ファイル サーブレットが、コンテキスト パラメータだけでなく初期化パラメータをサポートするようになった。

058352

「i.war」や「j.war」のように名前が 1 文字の Web アプリケーションにアクセスできるようになった。

059026

サーブレットを含む Web アプリケーションにおいて、このサーブレットに対して定義されたマッピングが「*.aBc」のような形式であっても、サーブレットへのアクセスが失敗しなくなった。

059102

RequestDispatcher で圧縮フィルタが正しく動作するようになった。転送によってフィルタが呼び出されていたが、サーブレット エンジンが空の応答をクライアントに返送していた。この問題を解決した。

059219

Host ヘッダがない場合、WebLogic Server はデフォルトのポート番号を返さなくなった。

060023

ソース ファイル名を算出するときに、FileServletSERVLET_PATH を含むようになった。つまり、FileServlet を「/dir/*」などにマッピングすることで、特定のディレクトリからファイルを明示的に提供することだけができる。

060184

PathInfo がデコードされて、元の URI の文字を保持するようになった。

060351

必要な URL が見つからないときに、PageContext.include(String relativeUrlPath) メソッドが例外を送出していなかった。コンテキスト ログ ファイルに記録され、親リソースおよび取り込むことのできないリソースを示すログ メッセージが追加された。ログ メッセージは mycontext.log ファイルに記録される。mycontext は Web アプリケーションのコンテキスト パスである。

060825

BodyTagSupportgetBodyContent() メソッドが、本体付きタグが空のときに誤って null を返していた。

061377

jspc は、EVAL_BODY_AGAIN の代わりに EVAL_BODY_TAG を生成しなくなった。

061782

ServletResponseImpl.setContentType() は、マルチパート タイプのプロパティを処理できるようになった。

061784

管理対象サーバからログを取得するとき、管理サーバの Java プロセスが 90% に固定されていた。この問題を解決した。

061864

セキュアなクッキーが表示されなくなった。

061948

タグと、「tagdependent」または「jsp」に設定されている本体の内容を区別するために、新しい意味論的な属性が追加された。lexer の既存の開始タグ ルールの前に新しいルールが追加された。tagdependent ルールが呼び出されると、普通の開始タグルールと同じように動作するが、対応する終了タグが見つかるまで先読みして、JSP の内容を突き合わせる処理も行う。見つかったものはすべて、¥n、¥r、および ¥ に対してエスケープされ、「出力」に書き出される。その後、親の lexer ルールに戻り、終了タグを直ちに発見しなければならない。

061968

HEAD メソッドが、jsp:include を使用してリクエスト本体を返さなくなった。

062109

JSP スクリプト変数の同期に関する問題を解決した。

062160

プリコンパイルにおいて、<compileFlags><encoding>、および <compilerSupportsEncoding> の各パラメータが無視されなくなった。

062289

URL 内のスペースがデコードされるようになった。

062395

web.xmlload-on-startup が省略可能になった。

062536

HttpServletResponseWrapper でフィルタ処理を行ったときに、日本語を含む JSP 応答が壊れなくなった。

062538

contentType の場所に関係なく、ページが正しく解析されるようになった。

062542

Windows で稼働する WebLogic Server の aux.jsp / AUX.jsp / PRN.jsp / prn.jsp に対するリクエストが、不明の状態のままになるのではなく、成功または失敗するようになった。

062579

CGIServlet がデフォルト サーブレットとして登録されていても、CGI スクリプトが正しく解決されるようになった。

062896 & 063009

Web アプリケーション (WAR) の weblogic.xml で JSP パラメータ precompile が true に設定されていると、サーバが再起動するたびに、ドキュメント ルート レベルの JSP だけが再コンパイルされていた。サブディレクトリの JSP は再コンパイルされていなかった。プリコンパイルの際にも、JSP が変更されている場合にだけ再コンパイルされるようになった。

062920

Web アプリケーションをデプロイするときに Web アプリケーションの web.xml<exception-type> を指定する(例外クラスは WEB-INF/classes にある)、WebLogic Server は例外クラスを発見できず、ClassNotFoundException を送出していた。この問題を解決した。

063007

JDBC 永続性に対するセッション テーブル名がコンフィグレーション可能になった。

063127

セッションが新しい場合、ServletInputStream がデータを返すようになった。

063169

アクセント付き文字と Charset=UTF-8 がある場合、weblogic.utils.ParsingException およびネストされた TokenStreamException が生成されなくなった。

063288

CookiesEnabled が true の場合は、クッキーの中で SessionCookie だけが検索されるようになった。

063414

アプリケーションを WebLogic Server 5.1 から 6.1 SP1 に移行する際に、CPU の使用量が大きくならなくなった。

063524

nativeIO をオンにして FileServlet を使用しても、NullPointerException が送出されなくなった。

063563

weblogic.jspc が、ページ タグから javac に -encoding JAVAENCODING の値を渡していなかった。この問題を解決した。

063904

JSP に各ページ ディレクティブを含めると、生成される HTML 出力に余分な改行文字が挿入されていた。HTML が画像で構成されていると、画像の書式設定が失われていた。この問題を解決した。

063925

Web アプリケーションに対して言語固有の文字エンコーディングが指定されている場合でも、応答の出力ストリームに書き込まれるバイナリ データが壊れなくなった。

064294

仮想ホストを使用する WebLogic Server の SessionID の再利用に関する問題を解決した。

064383

アプレットからの HEAD リクエストによって、ClasspathServlet から ClassCastException が発行されなくなった。

064446

2 レベルのプロキシを使用すると、getRemoteUser の呼び出しが常に NULL を返していた。この問題を解決した。

064449

Web アプリケーションのデプロイメントが失敗して StringIndexOutOfBoundsException が発生していた。この問題を解決した。

064650

名前の中にピリオドのあるクラスを JAR ファイルからロードできるようになった。

064880

フォーム ベースの認証で、ユーザがログイン ページに直接移動すると、WebLogic Server はユーザをウェルカム ページに転送していた。この問題を解決した。

064988

-k フラグが設定されていても、コンパイル エラーの後で JSP のプリコンパイルがアボートしなくなった。

065104

064650 および 065213 により解決された。

065194

SSL プロセスにおけるマルチパート リクエストが、遅い接続のために失敗していた。この問題を解決した。

065213

xalan.jarxerxes.jar の両方が lib ディレクトリにある場合、NoClassDefFound が発生していた。この問題を解決した。

065924

新しいオプションの replicated_if_clustered を使うことで、クラスタ固有のプロパティを含む Web アプリケーションを、非クラスタ環境にデプロイできるようになった。

066395

誤って挿入された null 文字で、response.addHeader が失敗していた。この問題を解決した。

066500

転送された JSP ページにより、現在のページの実行が中止されるようになった。

066569

request.getParameter() が、Javaclient によるポスト リクエストのパラメータを返すようになった。

066708

request.setCharacterEncoding が、JSP のインクルードに対して動作しなかった。この問題を解決した。

067001

Http Proxy/Cluster サーブレットを使うと、リクエストがステータス 100 で戻ってきた場合、リクエストはいずれかのバックエンド サーバに送信されて、応答の本体がクライアントに返されなかった。この問題を解決した。

067072

JSP に contentType 文字セットの指定なしで pageEncoding があると、生成される .java ファイルは VM デフォルトのエンコーディングになり、コンパイルが失敗していた。この問題を解決した。

067073

contentTypepageEncoding の両方が存在すると、生成される .java と javac に対する -encoding が一致していなかった。この問題を解決した。

067077

pageEncoding のある JSP ファイルで weblogic.xmljsp-param にエンコーディングの設定があると、pageEncoding が使用されていなかった。この問題を解決した。

067292

ある JSP から別の JSP へのリダイレクトの際に、リクエスト パラメータの Latin 1 文字が失われていた。この問題を解決した。

067505

HTTP リダイレクトに対する Location ヘッダ内のポートに関する問題を解決した。

067748

サーブレットの出力ストリームを圧縮できるようになった。

067948

インクルードされている JSP ページ内にあるページ バッファ ディレクティブが無視されなくなった。

068024

HttpServer または HttpClusterServlet で sync ブロックを使用する必要がなくなった。変わらないことが保証されている Set の参照が必要なたびに、新しい列挙値が作成される。

068560

特定の JSP ページのソース コードがブラウザに表示されていた。この問題を解決した。

068648

最大 POST サイズの制限が正しく機能するようになった。

068674

フィルタと共に HttpProxyServlet を使用しても、ClassCastException が送出されなくなった。

068809

デフォルトとは異なるエンコーディングを使用すると、書き込みシグネチャが優先されるようになった。

068821

Request オブジェクトからの getRequestURI が、URI の全体を返すようになった。

069304

HttpClusterServlet が、宣言されているコンテンツ長まで、入力ストリームからポスト データを読み込み直すようになった。

069511

エラー ページの属性が、JSP エラー ディレクティブに対するリクエストで設定されるようになった。

069630

JSP 内のカスタム タグのプロパティにエスケープ シーケンス (¥") が含まれていると、JSP がコンパイルを行わなかった。この問題を解決した。

069652

クライアントにページを提供するとき、応答ヘッダ (ContentType) と JSPWriter が同じ文字セットを使用するようになった。

069809

パブリック ルートにある jsp ファイル、jws (cajun) ファイル、その他のサーバが解析するファイルを見ることができた。コードを修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-03.jsp の「SECURITY ADVISORY (BEA02-03.03)」を参照すること。

069956

複製されたセッションに対し、オープン セッションのカウントが 1 回だけインクリメントされるようになった。

070090

クライアントに対する応答でセッション クッキーを送信するとき、キャッシング プロキシがクッキーをキャッシングしないようキャッシュ制御の指定が正しく行われていなかった。この問題を解決した。

070132

中国語のファイル名を要求できるようになった。

070151

<load-on-startup> に空の値が含まれていても、weblogic.jspc が黙って終了しなくなった。

070470

コンテナにまだデプロイされている古いコードによって、以降の再ロードや更新が実行されることがあった。JSP が解析に失敗した場合は古いクラスを再ロードすることで、この種の問題を防止するようになった。

070755

リクエストが wlsproxy 経由でない場合は、wlsproxy 固有のヘッダを送信しないようになった。

070823

WAR コンポーネントと EAR コンポーネントの間にあったインデックス ディレクトリ パラメータの動作の不整合が解決された。

071076

child1 と child2 が同じクラスローダを使用しているにもかかわらず別のクラスローダが作成されて破棄される原因となっていた、クラスローディングの動作に関する問題を解決した。

071082

壊れていた URLEncoding を修正した。

071634

WebLogic Server 6.1 が WebLogic Server 5.1 と通信すると発生していたチャンク転送のエンコーディングに関する問題を解決した。

072557

response.addCookie(name) が、ブラウザにクッキーが送信された順序を考慮するようになった。

073203

<url-pattern> で「+」の文字を使用できるようになった。

073380

CGIServlet に対するエラー メッセージが改善された。

073516

CGI の NonParsedHeader に関する問題を解決した。

073792

アクティブなセッションが無効にならなくなった。

073797

JSP の useBean タグが正しく解析されるようになった。

074015

リクエストの 1 行目に PROTOCOL がないと、NegativeArraySizeException が発生していた。この問題を解決した。

075201

URL パターンが 2 文字のディレクトリを参照していても、セキュリティ制約が機能するようになった。

075607

PrintWriter で破棄されたソケット例外が、サーブレットおよび JSP における実行スレッドを拘束することがあった。この問題を解決した。

075628

文字セットを含むように設定された Content-Type を使用してプログラムがサーブレットにデータを送信すると、getParameterValues("...") が送信されたすべての値を 2 回返していた。この問題を解決した。

076056

JAR ファイルの MANIFEST.MF が別のディレクトリにある JAR ファイルを含んでいると、StringIndexOutOfBoundsException が送出されて、Web アプリケーションがデプロイされなかった。この問題を解決した。

076476

複数のフレームを使用すると、1 つのフレームによって設定された最後の accesstime を、他のフレームが考慮しなかった。この問題を解決した。

076742

<env-entry-value> 要素に対するチェックが追加された。

077329

セッションが複製に設定されていると、HttpSessionListener が正しく動作しなかった。この問題を解決した。

078930

http://host:port/webApp/aux%20.jsp を要求しても、リクエストを処理するスレッドがハングしなくなった。

システム管理

変更要求番号

説明

050136

コマンド ラインから MBean に対するプロパティ値の設定を解除できるようになった。

052774

実際には存在していない config.xml ファイル内のアプリケーションが、デプロイされなくなった。

054836

サーバのクラスタを WebLogic Server 4.5 または 5.1 から WebLogic Server 6.0 または 6.1 に移行すると、InstanceNotFoundException が送出されていた。この問題を解決した。

056158

デフォルト Web アプリケーションを含むエンタープライズ アプリケーションをアンデプロイすると、アンデプロイメント時に例外が発生していた。この問題を解決した。

056832

クラスタでは、WLEC 接続プールが起動を試みていなかった。この問題を解決した。

058946

管理サーバでプリコンパイルされた JSP は、管理対象サーバでコンパイルされなくなった。

061426

起動クラスの実行前ではなく後に、サーブレットの起動時ロード (load-on-startup) が行われるようになった。

061676

コンバータ ユーティリティが、すべてのログ ファイルを SERVER/DOMAIN/logs ディレクトリに格納するようになった。

061703

アプリケーションが .wlstaging 以外のパスを使って(つまり、config.xml を手動で編集して)もともとデプロイされていた場合でも、weblogic.deploy は常にデフォルトの .wlstaging ディレクトリを使用していた。そのため、weblogic.deploy 以外の方法でインストールされたアプリケーションに対して更新が行われなかった。この問題を解決した。

062135

展開された Web アプリケーションに Web アプリケーションと同じ名前のサブディレクトリがあると、再デプロイの際にエラーが発生していた。この問題を解決した。

062151

リモート マシン上の管理対象サーバが、Web アプリケーションの名前とタイムスタンプを保持するようになった。

062749

Web アプリケーションを削除し、デプロイし、更新し、再び更新した場合、Web アプリケーションを更新できるようになった。

064101

管理サーバの JNDI が、管理対象サーバの MBeanHome を表示するようになった。

064280

weblogic.refresh ユーティリティを使用して管理対象サーバの JSP を更新すると発生していたパフォーマンスの低下を解決した。

064575

weblogic.refresh が、Solaris で稼働しているサーバに対し、Windows 2000 から JSP および静的ファイルを更新しなかった。この問題を解決した。

064722

デプロイされるコンポーネントが起動時に存在していない場合でも、weblogic.deploy を使って EJB をデプロイできるようになった。

066480

名前が null のオブジェクトを含むカスタム MBean を登録すると、サーバが例外を送出していた。この問題を解決した。

066704

WebLogic Server 5.x から WebLogic Server 6.x への移行において、FailuresFatal プロパティが自動的に生成されていなかった。この問題を解決した。

067917

Console アプリケーションの [<ドメイン>|コンフィグレーション|一般] ページにある Console コンテキスト パス プロパティを使えば、Console 以外のコンテキスト パスでドメインにアクセスできるようになった。

068231

context-root を変更した後で weblogic.deploy を使って管理対象サーバにエンタープライズ アプリケーションを再デプロイすると、サーバが再起動するまでの間も、新しい context-root が有効になるようになった。

068579

仮想ホストに対して再デプロイメントを行うと、javax.management.InstanceNotFoundException が返っていた。この問題を解決した。

068745

100 ノードのクラスタにおける Console の動作速度が向上した。

069145

アプリケーション ディレクトリにおける自動デプロイでは、管理サーバが空ではない場合には、管理サーバがターゲットに追加されていた。

069407

複数のセンダを MBeanServerNotificationListener のリストに保存できるようになった。

069686

Web アプリケーションをデプロイした後、MBeans を使って weblogic.xml のクッキー名を変更できるようになった。

071633

MBean インタフェースに対する svuid を修正した。

072676

起動クラス用に Console に LoadBeforeAppDeployments が追加された。

072964

Console で EJB 記述子エディタを使用すると javax.management.AttributeNotFoundException が発生する原因となっていた問題を解決した。

073674

Web アプリケーションをデプロイした後でも、weblogic.xml のセッション永続性タイプを変更できるようになった。

075139

weblogic.deploy を使ってクラスタにアプリケーションをデプロイできない原因であった問題を解決した。

075667

管理サーバを再起動すると、管理サーバが管理対象サーバを発見できなかった。この問題を解決した。

077750

JNDI 名が既に使用されている状態で EJB をデプロイするときの問題を解決した。

Web サービス

変更要求番号

説明

046215

wsgen Ant タスクのプロトコル属性を使って、WebLogic Web サービスの起動時に、デフォルトの HTTP ではなく HTTPS を使用するよう指定できるようになった。

ただし、HTTPS を使用する場合は、以下の追加手順を実行する必要がある。

  • クライアント アプリケーションにおける URL 作成の直前に、次の Java コードを追加する。

    System.setProperty( "java.protocol.handler.pkgs",
    "weblogic.net" );

  • WebLogic Server に付属する SSL 証明書を使ってサンプル サーバを実行している場合は、クライアント アプリケーションを実行するときに、コマンド ラインで以下を指定する必要がある。

    -Dweblogic.security.SSL.ignoreHostnameVerification=true

062976

AuthUser および AuthPassword に対する MSSoapClient.ConnectorProperty が、EJB の InitialContext に渡されるようになった。

065205

Web サービスの FaultHandler が呼び出されていなかった。この問題を解決した。

065669

WSDL URL でセキュリティ ACL を使用できるようになった。

066226

WebLogic Web サービスは、クライアント アプリケーションと RPC スタイルの Web サービスの間の双方向 SSL 認証をサポートするようになった。

双方向 SSL 認証を使用するには、クライアント アプリケーションで Web サービスのルックアップを使用するコンテキストを取得する前に、次の Java コードを追加する必要がある。

InputStream certs[] = new InputStream[3];

certs[0]=new PEMInputStream(new
FileInputStream("sample_key.pem"));
certs[1]=new PEMInputStream(new
FileInputStream("sample_cert.pem"));
certs[2]=new PEMInputStream(new
FileInputStream("sample_ca.pem"));

h.put(SoapContext.SSL_CLIENT_CERTIFICATE, certs);

066703

SOAP クライアントで過剰なエラー メッセージが生成されていた。この問題を解決した。

072788

複合型に対する属性の代わりに要素を使って WSDL が生成されるようになった。

073897

SOAP 障害が CDATA を使用するようになった。

WebLogic Tuxedo Connector

変更要求番号

説明

052022

WebLogic Server の weblogic.wtc.encoding property を使って、WebLogic Tuxedo ドメインと Tuxedo ドメインの間のコードセット変換が提供されるようになった。詳細については、「非 ASCII コードセットに対する WebLogic Tuxedo Connector のコンフィグレーション」を参照。

055170

WTC パッケージの TypedFML(32) クラスの Fchg メソッドに関する問題を解決した。

056230

tbridge が、wlsErrorDestination JMS キューの初期化に失敗しなくなった。

062843

WTC パッケージの TypedFML(32) クラスの Fdel メソッドに関する問題を解決した。

063290

Tuxedo から WebLogic Server に大きなコード テーブルをロードするときのサービス呼び出し (tpcall) の時間が、Jolt より WTC の方が極端に長いということがなくなった。

066489

FML32 バッファを使用している場合、Tuxedo からクライアントに EJB を呼び出すことができるようになった。

XML

変更要求番号

説明

061660

JAXP API を使って XML ドキュメントを解析しても、エラー メッセージ「Failed to open XML document」が発生しなくなった。

062297

Administration Console を使って、外部エンティティ キャッシュに対するキャッシュ メモリ サイズ、キャッシュ ディスク サイズ、およびキャッシュ タイムアウト間隔を設定できるようになった。以前は、これらのフィールドはいかなる値も受け付けていなかった。

063433

WebLogic Server 6.0 に埋め込まれた XSLT プロセッサに関する問題を解決した。String と、Literal または WebLogic Server 6.0 Filler フィールドに埋め込まれた XSLT プロセッサを含むグループが MFL ファイルに含まれていると、変換がハングしていた。

067966

WebLogic Server クラスローダの改善により、任意のバージョンの Xerces XML パーサをプラグインできるようになった。

065345

CharReader.fillCurrentChunkjava.lang.ArrayIndexOutOfBoundsException を送出する原因となっていた問題を解決した。

067022

WebLogic Server 6.1 に付属するトランスフォーマが、XML ドキュメントを意図したとおりに変換するようになった(指定された XSL を使って)。

068656

weblogic.xml.jaxp.ChainingEntityResolver.pushEntityResolver における NullPointerException の原因となっていた問題を解決した。

073311

weblogic.apache.xalan.xslt を使って大量のデータを変換すると、javax.xml.transform.TransformerException (文字列インデックスが範囲外)が発生していた。この問題を解決した。

075800

外部エンティティの参照を使って元の XML ファイルに外部の XML を取り込んでいる XML ファイルを、組み込みの XML パーサが正しく解析するようになった。

WebLogic Server 6.1 サービス パック 3 に付属するサードパーティの JAR ファイル

JAR ファイル

説明

J2EE、javax とサブディレクトリ

JTA 1.0.1


JCA 1.0


JMX 1.0


EJB 2.0


Servlet 2.3


JSP 1.2


JMS 1.0.2

XML

org.apache.xalan 2.0.1


org.apache.xerces 1.3.1


Xerces 1.2.0 - DOM と SAX のパーサ


org.w3c.dom のインタフェース


org.xml.sax のインタフェース

LIBRARIES

antlr 2.7.0 - antlr コンパイラ構築ツールキットの実行時クラス


bsh 1.2b3 - Bean シェル


certicom - SSLPlus/Java 3.1.12B (ノード マネージャが使用)


netscape - Netscape Directory SDK 4.1 for Java


Oracle 8.1.6


Oracle 8.1.7


Apache Jakart Ant - 1.3 Apache ビルド システム


Apache Jakart Oro 2.0 - 正規表現マッチング ライブラリ

 


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

以降の節では、サービス パック 2 を適用した WebLogic Server 6.1 で解決された問題について説明します。

EJB

変更要求番号

説明

044294

複数のエンティティ Bean を作成するときに発生する可能性があったメモリ リークが修正された。ガベージ コレクタが、使用したすべてのメモリを再使用していなかった。

049590

ejbc コンパイラは、プリミティブ値型が先で非プリミティブ値型が後という、正しい順序で IDL ファイルを生成するようになる。

049709、
055644、
059540


これまでは、クラスタに EJB をデプロイした後で再デプロイまたはアンデプロイを試みると、タイミングの問題によって例外/エラーが送出されていた。

ローカルなアンデプロイが行われた後で JNDI アンデプロイのメッセージが到着する可能性がある。EJB のローカルなアンデプロイが行われると、EJB に対するクラスローダは破棄されるので、これによりアンマーシャリング エラーが発生する。このアンマーシャルの問題によりログ ファイルには DistributedManagement 例外が記録され、EJB はクラスタからアンデプロイされない。

同様に、ローカルなデプロイメントが成功する前に JNDI バインディングの通知が到着し、同じアンマーシャリング/デシリアライゼーション エラーが発生する可能性がある(アンマーシャルする必要のある EJB クラスがまだ存在しないため)。

6.1 サービス パック 2 での解決策はこの両方の問題に対処し、ローカルなデプロイ/アンデプロイと JNDI 通知におけるタイミングの依存性を取り除いている。クラスタの EJB のデプロイ/アンデプロイ/再デプロイを正常に実行でき、競合状態による例外と問題は発生しなくなっている。

051454

idle-timeout-secs の値より長く EJB がアイドルになっている場合、EJB はキャッシュから削除されて、ejbremove() が呼び出される。

055113

examples\ejb\basic\statelessSession\build.xml ファイルで、EJB jarファイルの名前に誤りがあった。これを修正した。

055163

クラスタ内でインメモリ レプリケーションを行うようにコンフィグレーションされたステートフル セッション Bean の問題を解決した。EJBException が送出されると Bean はフェイルオーバしていたが、Bean が削除されるとフェイルオーバしていなかった。

055502

アプリケーションが例外を送出した後、メッセージ駆動型 Bean がメッセージを回復するようになった。

055510、056543

コンテナ管理による永続性 1.1 EJB が再デプロイされた後でデプロイメント記述子を読み込み直さない問題を解決した。

057119、054806

EJB を何回も再デプロイしたときに発生するメモリ不足の問題を解決した。<max-beans-in-free-pool> 記述子が無視されて、この値を超過していた。

058210

ejbRemove() メソッドは、ステートフルとステートレスの両方のセッション Bean の、ホーム インタフェースとリモート インタフェースの両方について、アンデプロイメント時に呼び出されるようになっている。

058857

ホームに create() メソッドがない場合にエンティティ Bean が認識されない問題を解決した。

059043

RemoteException を送出しない例外句を EJBLocalObject() メソッドが送出しても、ejbc はそれを報告しなくなった。

059046

クラスタ内でステートレス セッション Bean からステートフル セッション Bean にアクセスしても失敗しなくなった。

060018

コンテナ管理による関係で ReadOnly EJB にアクセスしても、LockTimedOut 例外が発生しなくなった。

055842

クライアントが認証を受けられないためにメッセージ駆動型 Bean が別の物理マシン上にあるリモート キューにアクセスできない問題を解決した。

058074

ステートフル セッション Bean のインスタンス フィールドに EJB ローカル インタフェースへの参照を格納しても、パッシベーションの際にアサーション エラーが発生しなくなった。

053523、060032

プロトコルが t3s および HTTPS の場合に weblogic.ejb20.internal.BaseEjbHomegetURL() メソッドが非セキュア ポートを使用する問題を解決した。

054335

ReadWrite エンティティ Bean を削除すると対応する ReadOnly エンティティが無効になるようになった。これまでは、ReadOnly エンティティがキャッシュに残っていた。

059674

Bean 管理による永続性を使用する読み取り専用エンティティ Bean を使用しても、ファインダを介して Bean を読み込んだときに ejbLoad() が 2 回呼び出されることがなくなった。

060142

getEJBHandle() メソッドの問題を解決し、2 ノードのクラスタでもフェイルオーバが動作するようにした。

060416

階層環境において EJB ルックアップを実行した場合に EJB Home オブジェクトを固有の型にキャストすると ClassCastException が送出される問題を解決した。

061883

読み取り専用 Bean に対する再入可能呼び出しがロック タイムアウトのために失敗する問題を解決した。

062515

コンテナ管理による永続性の EJB ホームに対して findByChar(char c) メソッドが失敗しなくなった。

サンプル

変更要求番号

説明

055155

次のサンプル ファイルにおける問題を解決した。

ejb20\cascadeDelete\one2many\table.ddl

この問題により、「SQL not properly ended」というエラー メッセージ(エラー番号 933) が表示されていた。

055370

wlserver6.1\samples\examples\jsp\ の次のサンプルにあった切れたリンクが解決された。

SimpleSession.jsp

URLEncode.jsp

SimpleSession では「セッション タイムアウト」のリンクが切れていた。

URLEncode では「Web アプリケーションのデプロイメント記述子の記述」のリンクが切れていた。

056711

wtc/simpFML32 サンプルのビルドにおいてコンテナ トランザクションに関する警告が生成されなくなった。

057237、056063

RMI-IIOP C++ のサンプルが UNIX プラットフォームで動作するように修正された。これらのサンプルは、以下のサブディレクトリにある。

/samples/examples/iiop/ejb/entity/tuxclient
/samples/examples/iiop/ejb/stateless/server/tux
/samples/examples/iiop/ejb/stateless/tuxclient /samples/examples/iiop/rmi/server/tux
/samples/examples/iiop/rmi/tuxclient

JDBC

変更要求番号

説明

055044

動的に作成された接続プールが、config.xml の中で永続的として扱われなくなった。

055435

JDriver for Oracle は、データベースをクエリしてデータベースが 500 行より多い場合、正しい数の null 値を取得するようになった。

056268

言語をロシア語に設定して SQL クエリの実行を試みたとき、タイムスタンプで使用されるハイフンにエラーの原因となるハイフンが含まれなくなっている。

jDriver

変更要求番号

説明

046149

CLOB または NCLOB のカラムに WebLogic Server がマルチバイト文字列を書き込む際に不正な長さの文字列が書き込まれる問題を解決した。

JMS

変更要求番号

変更要求番号

055293

JMS のデフォルト接続ファクトリが、config.xml ファイルの JMSDefaultConnectionFactoriesEnabled プロパティの機能として正しくバインドされるようになった。これまでは、他の JMS オブジェクト (JMSConnectionFactoryJMSServer) が特定の WebLogic Server で定義されていないと、デフォルトの接続ファクトリが JNDI にバインドされなかった。

056320

Topic を使って ObjectMessage として文字列を送信した後で別の ObjectMessage として RemoteObject stub を送信した場合の、オブジェクトのデシリアライズのエラーに関する JMS の問題を解決した。

061783

同じ JMS トピックをサブスクライブする異なるメッセージ駆動型 Bean のインスタンスを同時にデプロイしようとしたときに発生する問題を解決した。

これまでは、一方または両方の Bean の動作が停止していた。

その他

変更要求番号

説明

036679

Solaris で Netscape ブラウザのフレームのサイズを変更した場合でも、Administration Console が正しく機能するようになった。

041873

-Djava.security.manager でサーバを起動したときの weblogic.policy ファイルに関する問題を解決した。ユーザが正しいパーミッションを持っていても、java.security.AccessControlException: access denied 例外が発生していた。

041991

RemoteMBeanServer から MBeanHome を取得しようとしても、アプリケーションが null を受け取ることはなくなった。

043010

WebLogic を Windows サービスとして実行している場合、サーバを実行している Windows セッションからユーザがログアウトしても、WebLogic が終了することはなくなった。

050437

WebLogic Express の下で動作していても、WebLogic は
<Error> <JMS> <JMSServer "null", JMS license validation failed, com.bea.utils.misc.NoSuchProcessException: No such license: WebLogic Server 6.1, JMS.> というメッセージを出力しなくなった。このメッセージは、誤解を招く無害なものであった。

053732、054781

beasvc.exe ユーティリティに -delay オプションが導入されて、管理サーバが既に動作している場合にだけ、管理対象サーバが起動することが保証される。新しい -delay オプションを使えば、管理対象サーバの JVM スレッドの実行を、指定したミリ秒数だけ遅らせることができる。

これまでは、管理対象サーバは、稼働している管理サーバに依存するために起動に失敗していた。

注意: WebLogic Server 6.1 SP04 での関連する変更については、 beasvc.exe に対する -delay 引数の動作の変更を参照すること。

053990

ノード マネージャは、名前にホワイトスペースを含むサーバをロードするようになった。

055007

WebLogic Server にスロットリング メカニズムが実装されて、一定の限度を超えた未処理のリクエストは拒否されるようになった。これまでは、サーバの能力を超える可能性のある新しい接続の数を制限する上で acceptBacklog 値は役に立たなかった。

055442

HTTP 経由での XML の送信に関係する問題を解決した。WebLogic Server が getInputStream() メソッドを誤って呼び出していたのが問題であった。

056332

RPC スタイルの Web サービスを呼び出すと IllegalStateException が発生する問題を解決した。

057091

Internet Explorer でのアプレットに関する問題を解決した。誤った時点でコンテンツの長さのチェックが実行され、「didn't meet stated Content-Length」エラーが送出されていた。

058832

プライマリ サーバが停止した直後にクライアントがセッションにアクセスすると HttpSession フェイルオーバ サービスが失敗してセッションが失われる問題を解決した。この問題は、2 サーバのクラスタでのみ発生していた。

059119

Weblogic クラスタと対話する Java クライアントの実行が 3 サーバ クラスタでは 2 サーバ クラスタより遅くなる問題を解決した。さらに、この問題では、クラスタのサーバの数と少なくとも同じ数のソケット リーダー スレッドをクライアントが確保するまで、サーバの数を増やしてもクライアントのパフォーマンスの低下が続いていた。これには、実行スレッド数 (Execute Thread count) とソケット リーダーの割合 (Percent Socket readers) というクライアント側プロパティのコンフィグレーションが関係していた。

この解決策では、サーバの数を動的に増やしたり減らしたりできるよう、このようなコンフィグレーションの依存性を取り除いた。修正後の WebLogic Server では、動作中にソケット読み取り用のスレッドが新しく作成されて、クライアントからの送信ソケットごとに 1 つのスレッドが存在することが保証される。つまり、WebLogic クライアントが WebLogic クラスタと対話する場合に、ユーザはパフォーマンスを最適化するためにクライアントに対するこれらのプロパティを調節する必要はない。

059219

WebLogic が正しくない情報が存在する可能性のある場所からポート番号を取得するという、ワイヤレス アプリケーションで発生していた問題を解決した。

060557

FileT3 属性でファイルを作成する場合に、パスが管理対象サーバに対するものであっても正しいパスでファイルが作成されるようになった。

061060

getTimeout() メソッドと setTimeout() メソッドが、HttpURLConnection クラスに存在するようになった。

056911

これまでは、.war ファイルに対するマニフェスト クラスパスにエントリを追加した場合、Web アプリケーションのクラスローダがそれをロードしていた。今回の修正で、アプリケーションのクラスローダがそれをロードするようになった。実質的な影響として、すべての Web アプリケーションは、クラスの独自のコピーを取得する前であっても、マニフェスト クラスパスからロードされたクラスのインスタンスを共有するようになった。

051220

WebLogic Server のログまたはコンソールでマルチバイトのシステム メッセージが壊れて読めなくなる問題を解決した。

054871

Administration Console で JNDI ツリーが正しく表示されるようになった。以前は、デプロイメントが誤ったコンテキストの下に表示されていた。

057466

日本語ロケール (LANG=ja_JP.PCK) の Solaris で動作するサーバに対して weblogic.Admin PING コマンドを実行するとサーバで java.net.SocketException が表示される問題を解決した。

058786

Netscape Enterprise Server プラグイン(NSAPI プラグイン)を使うと、Netscape Enterprise Server(NES、iPlanet とも呼ばれる)から WebLogic Server へのリクエストをプロキシできるようになった。プラグインは、WebLogic Server の動的な機能を必要とするリクエストを WebLogic Server が処理できるようにすることで、NES のインストールを拡張する。

以前は、NSAPI プラグインで HTTP ヘッダを読み取ると、予期しない EOF (PROTOCOL_ERROR [line linenumber of filename]: unexpected EOF reading HTTP headers at line linenumber) が発生していた。

大きなクッキーの解析に関する問題であることが判明した。

この問題を解決した。

061460

クライアント接続の数を制限するよう Weblogic 6.1 をコンフィグレーションできるようになった。2 つの方法がある。

1. config.xml ファイルを編集して weblogic.system.openSockCount パラメータを設定する。このパラメータは、許される接続の数を制限する。

<Server ListenPort="7001" Name="myserver" NativeIOEnabled="true" TransactionLogFilePrefix="config/mydomain/logs/" MaxOpenSockCount=1000>

2. weblogic.Admin を使ってソケット数を設定するか、または JMX Java クライアントを記述してソケット数を設定し、次のコードで示すように weblogic.management.configuration.ServerMBean の API を利用する。

/**
* ある時点においてサーバで開くことのできるソケットの最大数を返す。
* 最大しきい値に達すると、サーバは、ソケットの数がしきい値より少なくなるまで、
* それ以上新しいリクエストを受け付けることを停止する。
*
* @default java.lang.Integer.MAX_VALUE
* @legalMin 0
* @legalMax java.lang.Integer.MAX_VALUE
*
* @configurable
*
* @oldprop weblogic.system.openSockCount
*/

int getMaxOpenSockCount();


/**
* ある時点においてサーバで開くことのできるソケットの最大数を設定する。
* 最大しきい値に達すると、サーバは、ソケットの数がしきい値より少なくなるまで、
* それ以上新しいリクエストを受け付けることを停止する。
*
* @default java.lang.Integer.MAX_VALUE
*
* @legalMin 0
* @legalMax java.lang.Integer.MAX_VALUE
*
* @configurable
*
* @oldprop weblogic.system.openSockCount
*
*/
void setMaxOpenSockCount (int sockCount);

051882

Web アプリケーションに web.xml がない場合にコンソールでデプロイメント記述子を編集または入力しようとしても、空白の画面が表示されなくなった。

プラグイン

変更要求番号

説明

053641

KeepAliveEnabled パラメータの設定にプラグインが正しく応答するようになった。HTTP 1.1 を使用すると、Connection: Keep-Alive ヘッダが WebLogic に返送されていなかった。

055276

ISAPI プラグインでキャッシングを無効にする際の問題を解決した。

055750

Apache の Stronghold バージョンで MatchExpression を使用する際の問題を解決した。

056628

Apache HTTP Server プラグインの PathTrim パラメータを設定すると発生していた問題を解決した。PathTrim パラメータに “/” を設定しても、セッション情報が失われることがなくなった。

060064

Solaris プラットフォームにおいて Apache HTTP Server プラグインを静的にリンクされたモジュールとしてインストールすると致命的エラーが発生した問題を解決した。

RMI over IIOP

変更要求番号

説明

056233

ejb11.security.HomeMethodPermissionTest.testHandleRemoveWithoutPermission() がメモリ不足エラーで失敗する問題を解決した。

セキュリティ

変更要求番号

説明

060491

Web アプリケーションの初期リソースが保護されたリソースでない場合にシングル サインオン (SSO) が機能しない問題を解決した。

CR061313

別のサーバ インスタンスのコンテキストを取得するサーバ インスタンスに関して、セキュリティ上の弱点があった。

Security.getCurrentUser() で認可されたユーザであることを確認するようにコードを修正し、この問題を解決した。

http://dev2dev.bea.com/resourcelibrary/advisoriesnotifications/BEA02-13.jsp の「SECURITY ADVISORY (BEA02-13.00)」を参照すること。

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

変更要求番号

説明

046879、057371

cgi 実行ファイルがブラウザに画像(.gif.jpg.png の各フォーマット)を正しく提供するようになった。以前は、この処理を試みると WebLogic Server ログに例外が送出されていた。

047698

IndexDirectoryEnabled プロパティが管理対象サーバに対して正しく機能するようになった。ディレクトリとファイルの両方がリストされる。

以前は、特定の Web アプリケーションに対して IndexDirectoryEnabled を true に設定した場合、管理対象サーバでその Web アプリケーションが要求されると、ファイルだけリストされて、ディレクトリはリストされなかった。また、その Web アプリケーションでファイルを追加または削除した場合、ブラウザのページを更新してもその変更が反映されなかった。

050402

Web アプリケーションを異なる名前で再デプロイすると発生していた問題を解決した。以前は、Administration Console を使って Web アプリケーションをデプロイした後、MBean を使って同じ .war アプリケーションを異なる名前でプログラム的にデプロイすると、WebLogic Server で無限ループが発生していた。

053513

HttpClusterServlet を使ってリクエストをプロキシするとブラウザでのページ表示が正しくなくなる問題を解決した。

053706

Web アプリケーションで AuthFilter を登録して ServletAuthentication.weak を呼び出すと発生する問題を解決した。このような場合は、AuthFilterdoSuccessAuth が正しく呼び出されるようになった。

053965

response.sendRedirect の対象となる URL パラメータの一部に ASCII で 128 〜 156 の間の文字がある場合、これらの文字は第 2 のサーブレットに対して正しく送信されるようになり、第 2 のサーブレットがこれらの文字を ASCII 63 として受け取ることはなくなった。

054206

HttpServletRequest の実装クラスである weblogic.servlet.internal.ServletRequestImpl において、複数行にまたがる HTTP ヘッダ行が正しく処理されるようになった。以前は、コードが正しく解析されなかった。

054211、055987

新しいクライアントサイド プロパティ http.keepAliveCache.lifeTimehttp.keepAliveCache.proxyLifeTime を使って、HTTP の永続的接続の有効期間をコンフィグレーションできるようになった。以前は、有効期間をクライアントサイドでハードコーディングしていた。この値は、サーバサイドの keepAlive の値をオーバーライドし、スケーラビリティの問題となっていた。

054852

エラー ハンドラがコンフィグレーションされた Web アプリケーションでは、JSP1 が JSP2 に転送して JSP2 が例外を送出すると、このエラー ハンドラにリダイレクトするようになった。

以前は、サーバは空白ページを返し、200 というステータス コードを表示していた。サーバは例外を記録していたが、クライアントはそれを見ることができなかった。

054898

AuthfilterdoSuccesAuth を使用する JSP ページに関する問題を解決した。最初の JSP ページは、異なる Web アプリケーションに含まれる一連の JSP ページ内にある。

055333

JSP の先頭ではなく途中で contentType タグを使用した場合の JSP のコンパイルに関する問題を解決した。

055466

EJB を呼び出すことができずに ClassCastExceptions が発生するサーブレット フィルタに関する問題を解決した。

055535

JSP 更新ツールを使用したときにファイル配布サーブレットがファイルを間違った場所にコピーする問題を解決した。

055583

JSP カスタム タグで TryCatchFinally を実装すると、コンパイル時に正しい Java コードが作成されるようになった。

055595

WebLogic Server は JSP のタグ ライブラリ URI を解決できるようになった。

055636、56265

JSP で getParameter() メソッドを使用する際に、入力された値が空であっても、null が返ることはなくなった。空の文字列が返る。これにより、クエリ文字列で等号を忘れた場合の問題が解決された。

056092

JSP コンパイラで変数宣言の重複が誤って示されることがなくなった。

056189

WebLogic Server は「Transfer-Encoding: Chunk」を使用するクライアントをサポートするようになった。つまり、クライアントは、POST リクエストの中で「Transfer-Encoding: Chunk」を使用する場合、「Content-Length」ヘッダを送信する必要はない。

056322

異なるアプリケーション内の 2 つの異なるサーブレットが同じ EJB にアクセスを試みても、断続的な RMI エラーは送出されなくなった。

056668

パラメータが空であっても、getParameter() メソッドは null ではなく空を返すようになった。

056955

Web アプリケーションの weblogic.xml<charset-params> が定義されている場合、または web.xml<context-param> が定義されている場合に、リクエストからの POST データが forward() の後で失われる(あるサーブレットが POST データを使ってリクエストを別のサーブレットに転送した場合)という問題を解決した。

057101

JSP が含まれる場合に getParameter() メソッドが複数の値の最初の値を返さないという問題を解決した。

以前は、最初ではなく 2 番目の値が返されていた。

057279

展開されたディレクトリとパッケージ化された Web アプリケーションの間にあった動作の不一致を解決した。展開ディレクトリでは、クラスがロードされる順序が正しくなく、WEB-INF/classes のクラスより前に WEB-INF/lib のクラスがロードされていた。

057620

コードセットのエンコーディングが「UTF8」の場合に、「+」や「&」などの特殊文字が正しくデコードされるようになった。

057684、057559

アプレットが EJB に対するクライアントの場合に PortableRemoteObject.narrow() を呼び出しても ClassCastException が発生しなくなった。

058125

Web サービスに対して生成される client.jar が JDK 1.2 Java クライアントと互換性を持つようになった。

058187

JSP の更新が失敗する weblogic.deploy に関する問題を解決した。展開ディレクトリ形式のアプリケーションに追加された新しいディレクトリが管理対象サーバに伝播されず、そのために更新が失敗していた。

058220

SOAP リクエストの送信を試みても、servlet.internal.ChunkOutput.clearBuffer でサーブレット エラー java.lang.NullPointerException が発生しなくなった。

058352

「i.war」のように名前が 1 文字の Web アプリケーションにアクセスできるようになった。以前は、この種のアプリケーションをデプロイすることはできても、アクセスすると 404 エラーで失敗していた。

058714

Web コンテナを介して直接ストリーミングするのではなく cgi-bin 実行ファイルを通してストリーミングすると .gif 画像が正しく表示されないという問題を解決した。

058738

HTTP 1.0 でリクエストを送信した場合に、応答ヘッダにおいて HTTP のバージョンが正しく保持されるようになった。

058931

JSP を削除すると、500 エラーではなく 404 エラーが発生するようになった。

059054

WebLogic Server がクッキーの区切り文字「,」の解析に失敗し、新しいセッションが誤って作成される問題を解決した。

059180

WebLogic Server が独自のクッキーを単純に追加するのではなく、別のエンティティによって作成された既存のクッキーを上書きしてしまう問題を解決した。

059412

session.removeAttribute() を 2 回呼び出してから session.setAttribute() を 1 回呼び出すと、両方の削除がオーバーライドされるのではなく 1 つの removeAttribute が残ってしまうという、サーブレットの問題を解決した。

060192

URL の書き換えを使ってセッションを追跡すると、リクエストがプライマリ サーバにピン固定されないでセッションが失われる問題を解決した(ブラウザでクッキーが無効になっていた)。

060536

jspc が SUCCESSFUL の終了コードで終了しない問題を解決した。

060595

HTTPServletRequest をラップするフィルタを使用するとネストされた JSP で ClassCastException が送出される問題を解決した。

060615

Web アプリケーション間でセッション ID が一致していない問題を解決した。現在では、各 Web アプリケーションは、特定のユーザのセッションに対して単一の同じ ID を認識するようになっている。

060963

Web アプリケーションがシングル サインオンに参加していない場合、WebLogic Server はセッション ID を再利用しないようになった。

061277

(JSP 1.1)

日本語プラットフォームにおいて javac コンパイラのエラー メッセージが壊れなくなった。

061387

JSESSIONID クッキーが 2 つのユーザ定義クッキーに挟まれている場合に、ページが要求されるたびに WebLogic Server が新しいセッションを作成する問題を解決した。

061488

値で「=」が使用されている場合にリクエスト パラメータが正しく解析されない問題を解決した。

066184

6.1 SP1 では、デフォルトのエンコーディングは JVM であった。6.1 SP2 からは、デフォルトのエンコーディングが ISO8859_1 に変更された。この変更は、最新のサーブレット仕様に従ったものである。サーブレット仕様 2.3 SRV 4.9 では、デフォルトのエンコーディングは ISO8859_1 でなければならないと規定されている。

システム管理

変更要求番号

説明

045780

同じ名前で複数のサーバを定義することができなくなった。サーバを起動した後、2 番目のサーバを同じ名前で起動しようとすると、サーバの起動は中止されて、次のエラー メッセージが表示される。

"Server: <yourservername> already exists, make sure that you do not have duplicate copies of this Server name in your XML config file"

055190

アプリケーションがクラスタを対象としている場合は JSP の更新が失敗する問題を解決した。以前は、稼働している Web アプリケーションから新しい JSP を追加したり既存の JSP を変更または削除したりするには、アプリケーションのアンデプロイと再デプロイを行う必要があった。

056091

管理対象サーバが動作している状態で別のマシン上の管理サーバを再起動できる新しいプロシージャが利用できるようになった。詳細については、
管理サーバのフェイルオーバに関する考慮事項」を参照。

058946

管理対象サーバ上のプリコンパイル済み JSP が、ページが変更されていない場合でも再コンパイルされる問題を解決した。この問題により、管理対象サーバの起動に時間がかかっていた。

この解決策により、管理サーバでクラスが既にコンパイルされている場合は、管理対象サーバを起動すると、そのクラスが移動されてタイムスタンプが維持されるので、管理対象サーバでは再コンパイルが行われない。

054624

-component オプションの使用時に weblogic.deploy が意図したとおりに動作するようになった。

以前は、-component オプションを使用すると weblogic.deploy が意図したとおり動作せず、コンポーネントのサーバ リストにないサーバにアプリケーションが誤ってデプロイされていた。

054573

JDBCConnectionPool、MultiPool、または (Tx)DataSource に関係するコンフィグレーション エラーが、コンソールのエラー ダイアログで報告されない問題を解決した。正しくコンフィグレーションされたように表示されていた。

058183

WebLogic Server が .jar ファイルより前に .war ファイルをデプロイする問題を解決した。サーバ起動時に EJB より前に Web アプリケーションがデプロイされたため、NameNoteFoundException が発生していた。

059702

ネットワーク カードが無効になっていると Web アプリケーションがデプロイされない問題を解決した。

以前は、WebLogic Server は http://www.bea.com/servers/wls610/dtd/weblogic-web-jar.dtd の DTD で検証を試みていた。www.bea.com にアクセスできないと失敗していた。現在は、ネットワーク アクセスがない場合は、weblogic.jarweblogic-web-jar.dtd を見つけて処理を続ける。

060244

Administration Console を使ってクラスタの対象をただ 1 つのアプリケーションにすると個別のサーバもターゲット リストに取り込まれる問題を解決した。この解決策により、クラスタはサーバのリストに展開されなくなった。

061642

5.1 の weblogic.properties ファイルから 6.1 の config.xml ファイルへの変換に関する問題を解決した。変換ユーティリティが、JDBCConnectionPool に対するパスワードを正しく変換していなかった。その結果、新しいドメインでサーバを起動しようとすると失敗した。

055067

プリコンパイルがオンになっていると EJB の .jar ファイルのクラスと依存関係のあるアプリケーションがデプロイされない原因となる問題を解決した。

060411

(EJB 1.1)

必須の EJB トランザクション メソッドに対する 2 番目の呼び出しによってトランザクションがロールバックする問題を解決した。最初の呼び出しによってエンティティがいくつか削除されてからいくつか作成されていた。2 番目の呼び出しでは、前に作成されたエンティティを削除してから新しいエンティティを作成していた。

042052

あるリリースから別のリリースへの移行で発生していた問題を解決した。weblogic.properties ファイルが正しく変換されず、Web アプリケーションの web.xml ファイルに含まれていないプロパティがあった。

061300

WebLogic Server コンソールが __weblogic_admin_html_queue(優先度の高いキュー)ではなくデフォルトのキュー(優先度の低いキュー)で実行される問題を解決した。そのために、サーバに大きな負荷がかかっているとコンソールの応答能力が低下していた。

Web サービス

変更要求番号

説明

055415

SoapWare テスト仕様と UserLand クライアントを使用するときの相互運用性の問題を解決した(参照実装)。

054749

wsgen Ant タスクを使ってステートレス セッション EJB を RPC スタイルの Web サービスにアセンブルするとき、次に示すように EJB のパッケージ レベルに 1 つのレベルしか含まれていないと wsgen が解析エラーで失敗する問題を解決した。

package mytest;

055645

WebLogic Web サービスを手動でアセンブルするために使用する Remote2WSDL クラスに、HTTPS のような HTTP 以外のプロトコルを指定するための protocol オプションが正しく含まれるようになった。

056332

以前は、WebLogic Server が SOAP リクエストを処理して WebLogic Web サービスを呼び出す間に例外が発生すると、ServletResponse.getWriter() メソッドが 2 回実行されていた。そのために別の例外が発生していた。この問題を解決した。

056382

WebLogic Web サービスが xsd:decimal データ型をサポートするようになった。

056631

WebLogic Web サービスが xsd:hexBinary データ型をサポートするようになった。

056639

WebLogic Web サービスのクライアント API を使って、ejb-jar.xml ファイルおよび weblogic-ejb-jar.xml ファイルでセキュリティ制約が定義されたステートレス セッション EJB を持つ RPC スタイルの WebLogic Web サービスを呼び出しても、エラーが発生しなくなった。

058230

WebLogic Web サービス クライアント API において、SOAP リクエストの内部でオブジェクトを受け取った後、クライアント側で複雑な Java オブジェクトを正しく作成できるようになった。この複雑なオブジェクトとは、JavaBean の配列で構成されていて、さらにその属性の 1 つ自体が別の種類の JavaBean の配列になっているようなものである。

058431

WebLogic Web サービスは、ネストされた配列データ型の値を正しく返すようになった。

059653

Remote2Wsdl を使って Web サービスをアセンブルするとき、WSDL の <soap:address> 要素の location 属性に相当する、URL の context 部と jndi_name 部を指定できるようになった。つまり、WSDL から取得した Web サービス プロキシ上でメソッドを正常に呼び出すことができる。

WebLogic Tuxedo Connector

変更要求番号

説明

055889

WebLogic Tuxedo Connector から TPESVCFAILと共に送出された TPReplyException を、Tuxedo クライアントが受信できるようになった。

057150

FldTblClass 要素を持つコンフィグレーション ファイルの有効性を検証するときに、WTCValidateCF ユーティリティがエラーを送出しなくなった。

XML

変更要求番号

説明

044211

xmlx.jar ファイルに、HTMLEntities.res リソース ファイルが正しく含まれるようになった。

046934

組み込み SAX パーサが、任意の文字セットを使って記述されているデプロイメント記述子ファイルを正しく解析するようになった。

警告: 以前は、英語のみのアプリケーションの .xml ファイルにおけるエンコーディングの問題を検出できなかった。したがって、以前は問題なく動作していた英語専用アプリケーションが、サービス パック 2 におけるこの対処によって異常を示すようになる可能性がある。非サポート エンコーディング エラーが報告される。

このエラーが通知された場合は、指定された .xml ファイルでエンコーディング名と構文が正しいことをチェックする必要がある。

055082

weblogic.jar アーカイブの XSLTInfo.properties ファイルについて、正しくない /org/apache/xalan/res/XSLTInfo.properties ではなく、/weblogic/apache/xalan/res/XSLTInfo.properties が正しく呼び出されるようになった。その結果、変換が正しく動作し、SAXException が送出されなくなった。

056839

weblogic.apache.xalan.serializer.Encodings クラスに、MS932 と Shift_JIS の間の正しいマッピングが含まれるようになった。

062320

WebLogic FastParser が、非常に大きな文字列(1MB より大)を分単位ではなく秒単位で解析するようになった。

 


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

以降の節では、サービス パック 1 を適用した WebLogic Server 6.1 で解決された問題について説明します。

デプロイメント記述子エディタ

変更要求番号

説明

041479

J2EE アプリケーションの更新(再デプロイメント)で発生していたメモリ リークが修正された。

048757

コンソールのデプロイメント記述子エディタの隣にあった黄色の警告アイコンがすべて削除された。

048804

コンソールの EJB デプロイメント記述子エディタで、Container Transaction Trans 属性に「(none)」オプションがなくなった。

049465

コンソールの EJB デプロイメント記述子エディタで、Weblogic RDBMS Jar の表示名が記述子の読み込まれたファイル名から派生する。

051858

weblogic-ejb-jar.xml ファイルで参照されるすべての RDBMS 記述子がデプロイメント記述子エディタでアクセス可能になった。

051939

Auto-acknowledgeDups-ok-acknowledge をメッセージ駆動型 Bean の有効な確認応答モード要素として受け入れるように ejb-jar.xml 解析コードが修正された。

052613

デプロイメント記述子を編集するためのリンクが、アプリケーションのコンフィグレーション時には表示されないようになった。

052665

web.xml ファイルに <run-as> という有効な要素がある場合に、それがデプロイメント記述子エディタの使用時に失われることがなくなった。

052804

<charset-params> エンティティとすべての子エンティティが、デプロイメント記述子エディタによって weblogic.xml ファイルで維持されるようになった。

052963

.war.jar、または .rar ファイルに関して、コンソールのコンポーネント テーブルでデプロイメント記述子エディタにアクセスできなくなった。

053089

デプロイメント記述子エディタにおいて、自動キー生成機能で使用する主キーが Java の型(java.lang.Integer)でなければならないことが示されるようになった。

053098

MessageDrivenDestinationMBeanSubscriptionDurability 属性で有効な値のリストが追加された。MessageDrivenMBean から SubscriptionDurability 属性が削除され、MessageDriven.jsp から SubscriptionDurability プロパティが削除された。

053282

EJB 2.0 デプロイメント記述子エディタに exclude-list タグが追加された。

053375

デプロイメント記述子エディタが、コンソールのチェック ボックスを使用して修正された Bean が再デプロイされた後に空白にならなくなった。

054682

デプロイメント記述子エディタから EJB デプロイメント記述子の設定を維持するときに、すべての description 要素の内容が解析エラーを防ぐために CDATA セクションで囲まれるようになった。

EJB

変更要求番号

説明

031350

EJB コンパイラで、エンティティ Bean の主キー クラスにすべてのパブリック フィールドがあることが正確に検証されるようになった。以前も検証機能はあったが正確に機能しなかった。

044294

エンティティ Bean を繰り返し作成するときに発生していたメモリ リークが修正された。

047050

メッセージ駆動型 Bean の onMessage で非検査例外が送出された場合に、setRollbackOnly の代わりにトランザクションのロールバックが呼び出されるようになった。

048506

複数の Bean が作成されて、削除されなかった場合のメモリ リークが修正された。

048716

EJB 準拠エラーのメッセージで、どの Bean に問題があるのかが示されるようになった。

049180

Bean の解放を要求されたときに、EntityPoolunsetEntityContext() が呼び出されなかった。この問題は修正済み。

049658

ejb-ql の入力パラメータで算術演算子を使用する場合の問題が修正された。+、-、/ という 3 つの記号のための機能が追加された。

050134

weblogic.ejbc デバッグ フラグが機能するようになった。デバッグ機能を利用してコンパイルするには、-debug の代わりに -g を使用する。次に例を示す。
java weblogic.ejbc -g foo.jar bar.jar

050860

DDConverter で、cmp20 Bean の更新された構文で ejb-ql が生成されるようになった。

051528

weblogic-rdbms20-persistence-600.dtd<weblogic-query> タグでオプションの <description> タグ要素が追加されたので、クエリを記述できるようになった。

051653

主キー フィールドが外部キーの一部である多対 1 の関係における SQL クエリ生成の問題が修正された。

051670

別の EJB のハンドルを参照する EJB でパッシベーションが行われたときに、ClassCastException が送出された。この問題は修正済み。

051735

EJB コンパイラは、sj として指定されたときに -j オプションを認識せず、したがってコマンドを実行できなかった。この問題は修正済み。

051803

準拠チェッカーで、local または local home をリモート インタフェースのパラメータの型または戻り値の型として渡すことが許可されなくなった。詳細については、EJB 仕様のセクション 10.3.10.1 を参照。

051807

準拠チェッカーにおいて、リモート コンポーネントとローカル コンポーネントが同じ CMR マッピングを共有することが認められなくなった。

051875

XML ジェネレータで、明示的に設定された値が無視されなくなった。値がデフォルト値と同じでも生成される。

051941

remove というビジネス メソッドの不正な処理が発生する EJB コンテナの問題が修正された。

052075

ejbSelect でフィールドの集合が返される場合に SELECT DISTINCT が機能するようになった。

052502

コンソールの [デプロイ] チェックボックスで EJB をデプロイすると、EJB のデプロイメント記述子に対する変更が取得されるようになった。

053093

テーブルの自動作成機能が有効な場合に、シーケンス テーブルが生成されるようになった。

053096

ejbSelect メソッドで、Bean インスタンスのセットではなくローカル Bean のセットが返されるようになった。

053101

準拠チェッカーで、<acknowledge-mode> の値が不正ではなくなった。

053287

ejb-jar.xml ファイルの次のエントリで、ファイル全体がロードされないということがなくなった。

<message-driven-destination>
<destination-type>javax.jms.Topic</destination-type>
<subscription-durability>Durable</subscription-durability>
</message-driven-destination>

053596

アクティブな StatelessSessionBeans の数が、max-beans-in-free-pool 設定を超えられなくなった。

053599

Bean クラスを判別する EJB DDInit ツールの機能が改良された。

053643

ローカル インタフェースのない EJB から SessionContext.getEJBLocalObject() が呼び出された場合に、IllegalStateException が送出されるようになった。