WebLogic Tuxedo Connector では、インポートされたサービスについて、リソース名、ローカル ドメイン名、およびリモート ドメイン名の組み合わせがユニークでなければなりません。しかし、Administration Console ではインポートされた複数のサービスを同じリソース名で定義することができませんでした。

現在の Administration Console では、リソース名、ローカル ドメイン名、およびリモート ドメイン名の組み合わせに基づいてユニークなネーミングがなされるようになっています。

適切なパーミッションを持たないユーザが特定のディレクトリ内のファイルを読み込むと、コンソールで NullPointerException が発生していました。ユーザに適切なパーミッションがないため、空の配列が返されていました。

この問題は、適切なチェックを追加することで解決しました。適切なパーミッションを持たないユーザに対してファイルが表示されることはありません。

WebLogic Server を大きなヒープ サイズ (たとえば「-Xms3069m -Xmx3069m」や「-Xms2500m -Xmx2500m」) で開始すると、Administration Console の [サーバ｜モニタ｜パフォーマンス] に誤った値が表示されていました。最大メモリは常に 1 で、現在のヒープ サイズは負の値になっていました。

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

UNIX システムで Administration Console を使用して Web アプリケーションのロード順を変更した場合に、 config.xml が正しく更新されていませんでした。アプリケーションのパスの先頭にある「/」文字が消失していました。

コードを修正したことで、関連する Console ページからロード順を変更した場合でも絶対値が更新され、パス属性は更新されなくなりました。

カスタム JDBC ドライバを使用する接続プールが作成された場合に、その JDBC ドライバがシステム クラスパスにないと、そのドライバの詳細プロパティ タブを編集することができず、サーバ インスタンスが Java.lang.ClassNotFoundException を送出していました。

システム クラスパスになくても JDBC ドライバがロードされるように、コードが修正されました。コンソールでは、XA 属性のない [接続｜詳細オプション] ページが表示されます。

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

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

WebLogic Server 8.1 サーバが Calendar オブジェクトを WebLogic Server 6.1 または 7.0 クライアントに返した場合、そのクライアントでは ClassNotFoundException が送出されていました。この問題の原因は、JDK 1.4 での Calendar クラスの変更にありました。 MsgAbbrevInputStream の readClassDescriptor() でクラスを解決しようとすると、 ClassNotFoundException が発生していました。Java シリアライゼーションでは、対応するデータが読み込まれていないと、この ClassNotFoundException がスキップされていました。

MsgAbbreveInputStream readClassDescriptor() ではクラスが解決されないようにし、 MsgAbbrevInputStream に resolveClass() を実装しました。

EAR ファイルで、WAR ファイルに実在するクラスに対して「NoClassDefFoundError」および「IllegalStateException: zip file closed」メッセージが発生していました。

複数のスレッドが EAR ファイル内の WAR ファイルから 1 つのクラスをロードしようとすると、WEB-INF/lib ディレクトリ内のいくつかの JAR ファイルがロックされない可能性があったため、NoClassDefFoundError や IllegalStateException が発生していました。

この問題は、ファインダ内の zip 構造が破損しないようにするための同期をコードに追加することで解決しました。

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

タイムアウト値 IdlePeriodsUntilTimeout は現在は調整可能です。この値は、config.xml の <Server IdlePeriodsUntilTimeout="3"> タグで設定します。通常、この値は調整する必要はなく、デフォルトの 3 のままにしておくようにしてください。ただし、負荷、アーキテクチャのリダンダンシ、および特定のアプリケーションの問題に依存する特定のケース、または特定のプロダクション シナリオでは、この値を慎重に調整すると、根本の原因が特定および修正されるまで問題を一時的に緩和できる場合があります。

この値を変更するときには特に慎重を期し、期待通りの動作になるようにピーク負荷時のアプリケーションのテストを十分に行ってください。あらゆる場面に当てはまるような推奨事項はないので、この値を変更する必要があるときには負荷とストレスのテストを必ず行ってください。

重みベースのロード バランシングがコンフィグレーションされたクラスタにデプロイされている Bean に対して、ステートフル セッション Bean のクライアントがアクセスした場合に、最大および 2 番目に大きな重みを与えられている管理対象サーバがその順序で強制終了すると、クライアントから以下のメッセージが送出されていました。

<Jul 22, 2003 1:32:56 AM IST> <Warning> <Kernel> <No replica in list has the expected weight.Reverting to round-robin>

管理対象サーバが再起動されると、ロードバランシング アルゴリズムがラウンドロビンに切り替わっていました。分析の結果、管理対象サーバがダウンしたときにレプリカ リストが更新されていましたが、競合状態が原因で、RichReplicaList の最大の重みが正しくリセットされていなかったことが判明しました。

レプリカ リストのサイズが変更されたときには必ず最大の重みが再計算されるコード修正で、この問題は解決しました。

クラスタ サービスがマルチキャスト ポートへのバインド後にプロセスの本当の uid または gid をセットしていたため、サーバをリスン ポートにバインドするとエラーが発生していました。

サーバをリスン ポートにバインドする際に、特権のある uid または gid のみが使用されるようにコードを修正しました。それ以降のサーバ開始プロセスでは、特権のない uid または gid が使用されます。

重みベースのロード バランシング アルゴリズムを使用する単一ノード クラスタ内で、外部クライアントが EJB のリモート メソッドを呼び出すと ArrayIndexOutOfBoundsException が発生していました。

単一ノード クラスタが存在する場合は、WebLogic Server がフェイルオーバやロード バランシングを要求するレプリカを持たないようにしました。このチェックを追加したことで問題は解決しました。

クラスタ アフィニティが設定されていると、70 から 81 への相互運用において BasicReplicaHandler で NullPointerException が発生する場合がありました。

すべてのアフィニティ ハンドラに null チェックが追加されました。

セッション レプリケーションによって、クラスタ内のサーバ ノードがハングしていました。これは、セッションの lastAccessedtime がバッチ更新され、そのすべてが全セッションのハッシュテーブルに格納されていたことが原因です。バッチ更新の実行時には、すべての更新 (更新はすべてリモート呼び出し) が完了するまでこのハッシュテーブルがロックされていたため、他のスレッドがハッシュテーブルを更新できずパフォーマンスが低下していました。

コードを修正することで、 BatchedLATUpdater のトリガ メソッド内に、元のハッシュテーブルの複製である新しいハッシュテーブル (ローカル変数) が作成されるようになりました。新しいハッシュテーブルをセッションの lastAccesstime へのアクセスに使用し、古いハッシュテーブルは複製されている間のみ同期されます。これにより、リモート呼び出しの実行中でも、他のスレッドがハッシュテーブルを使用することが可能になりました。

クラスタの負荷が高いとき、またはセッションの固定が維持されなかったときに NPE が送出されていました。クラスタ ノードで負荷が大きい場合には、プラグインがそのノードから拒否された接続を取得し、リクエストをクラスタ内の他のノードにフェイルオーバしていました。どちらの状況でも、セッションはクラスタ内のいずれかのノードでランダムに変更または作成され、ある特定の場合には、プライマリが削除され、同じノードでそのセッション用にセカンダリが作成される可能性もありました。セカンダリ情報の取得にはプライマリが必要なので、セカンダリ情報を取得しようとするスレッドはすべて NPE で失敗していました。セカンダリの作成前にプライマリが削除される場合は、secondaryURL が null と算出されていました。

コードの修正により、WebLogic Server が null の secondaryURL をチェックするようになりました。さらに、この問題を通知するように警告メッセージがログに記録されるようになったので、予期される負荷に合わせてクラスタをコンフィグレーションすることができます。これにより、ロード バランサのコンフィグレーションまたはプラグインでセッションの固定が壊された場合に問題を解決できるようにもなります。

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

既知の IDL 予約語にアンダースコア ( _ ) を追加するコード変更により、この問題は解決しました。

ドメイン コンフィグレーション ウィザードをサイレント モードで使用してドメイン コンフィグレーションを作成すると、Administration Console でユーザが複数回同じグループに割り当てられていました。

対応する割り当てがすでに行われている場合はエントリを追加しないようにコードが修正されました。

WebLogic Server 8.1 のサービス パック 1 が動作し、Posix Performance Pack を使用している AIX 5.1 プラットフォームで、IBM JVM から SIGSEGV 11 (*) セグメンテーション違反が発生していました。

このエラーは次のようにして再現できます。

1. コンフィグレーション ウィザードで新しい WebLogic ドメインを作成します。

2. シェルでファイル ディスクリプタの制限を無制限 ( ulimit -n ) に設定します。

3. startWebLogic.sh スクリプトを実行します。

この問題は、無制限の設定を 1025 に自動的にリセットする resetFd() メソッドが commEnv.sh script で呼び出されるようにコードを修正することで解決しました。

Solaris 2.9 で WebLogic Server Template Builder を使用してドメインを作成しようとすると、MySQL JDBC 接続プールの作成時に JDBC URL でエラーが発生していました。

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

サイレント モードでコンフィグレーション ウィザードを実行すると、Oracle OCI ドライバの JDBC 接続プールの URL (jdbc:oracle:oci:@<DBName>) が Oracle Thin ドライバの URL (jdbc:oracle:thin:@<DBHost:port:DBName>) に間違って変換されていました。これが原因で、サーバの起動時に Oracle OCI ドライバを使用する JDBC 接続プールのデプロイメントが妨げられていました。

コンフィグレーション ウィザードは、どちらの Oracle JDBC ドライバの URL も受け入れるようになりました。

接続プロキシ テストに失敗したアダプタでは、weblogic-ra.xml で inactive-connection-timeout-seconds が指定されている場合でも接続のアイドル状態の検出を無効にするべきでした。以前のリリースでは、サーバがそのようなアダプタを使用してアイドル クリーンアップを実行しようとして、NullPointerException が送出されていました。

現在は、プロキシ テストに失敗したアダプタでは idle-detection が適切に無効になります。その結果として、NullPointerException が発生しなくなりました。

一部のリソース アダプタで、コネクタ コンテナが誤って接続リークを報告することがありました。 この問題は、連続する呼び出しで同じハンドルを返すように ManagedConnection.getConnection() メソッドが実装されたアダプタで発生していました。

この問題が発生したのは、接続ハンドルの周囲にプロキシが作成されてしまうことが原因でした。プロキシが完全に作成され、同じ hashCode 値を開いたままのハンドルがあると、リークがあるかのようにコンテナが動作していました。

同じ hashCode を持つハンドルに関連付けられたカウントを、接続コンテナが追跡できるようになりました。このカウントは、開いたときに増分され、プロキシが完全に作成されたときに減分されます。これにより、ハンドルに関連付けられたすべてのプロキシが完全に作成された場合にのみコンテナがリークを報告することになり、誤ったリークが報告されることはなくなりました。

メッセージング ブリッジをホストしている WebLogic Server インスタンスは、MQSeries 5.3 Queue Manager が停止して再起動したときに再起動する必要がありました。その理由は、メッセージング ブリッジが XASession オブジェクトを閉じようとしたときに MQSeries に対する呼び出しが失敗していたからです。その結果として、MQSeries Queue Manager が停止された後にそれに関連してリソースがクリーンアップされていませんでした。また、WebLogic Server のプロセスで使用されているオブジェクトがまだ存在することを検出して、Queue Manager が再起動していませんでした。

IBM のアップグレード CSD06 を MQSeries 5.3 に適用することで、この問題は解決します。その結果として、エラーが発生したり、WLS サーバ プロセスを停止したりする必要なく、Queue Manager を停止および再起動できるようになりました。

接続をプールから永久に削除したときに、内部的にキャッシュされたオブジェクトの一部が適切にクリーンアップされていませんでした。このため、キャッシュが無制限に大きくなるおそれがありました。

コードを修正したことで、接続をプールから永久に削除すると、キャッシュされていたオブジェクトがクリーンアップされるようになりました。

jRockit JVM に大きな負荷がかかると、WebLogic コネクタの ConnectionRuntimeMBeanImpl() API によって InstanceAlreadyExists 例外が送出されることがありました。これは、さまざまなオブジェクトに対して ConnectionInfo#hashCode() メソッドがユニークでないことがあったために発生していました。

以前のサービス パックでは、接続のハッシュコードを使用して MBean 名が生成されていました。 コードを改善したことで、同期化されたカウンタを使用して MBean 名が生成されるようになりました。これにより、リソース アダプタ接続のモニタに使用するすべての実行時 MBean はユニークな名前で生成されるようになっています。

クラスタ内の複数のサーバにアダプタをデプロイすると、各サーバで作成された接続は XAResource を取得し、サーバはリソース登録に同じ名前を使用していました。このことが原因で、トランザクション マネージャは一部の処理に関して間違った XAResource で呼び出しを行おうとしていました。

リソース登録で使用される名前はサーバとドメインの名前で限定されるようになり、クラスタ内の複数のサーバにデプロイされたアダプタがリソース登録に異なる名前を使用するようになりました。

アプリケーション A がアプリケーション B を使用している場合、アプリケーション B をルックアップする間に、アプリケーション A の J2EE コンテナがアプリケーション B の ClassFinder をアタッチして DependencyClassLoader を作成します。アプリケーション B を再デプロイすると、アプリケーション B が新しい ClassFinder を検出し、それ以降は古い ClassFinder が無効になります。クライアント リクエストが発生すると、サーバが古い DependencyClassLoader を使用しようとして例外を送出していました。

この例外の原因となる動作が変更され、 ReplicaAwareRemoteObject.getPrimaryRepresentative() からの impl クラスのロードには DependencyClassLoader を使用しないことになりました。

IIOP 接続プールが初期化される前に WLECService.getConnectionPoolCount を呼び出すと、Null ポインタ例外 (NPE) が発生していました。

IIOP 接続プールが null の場合には 0 を返すためのコードを追加しました。

-Dweblogic.Stdout および -Dweblogic.Stderr コマンドライン オプションの使用時に、ログ ファイルのパスが指定されているがディレクトリが存在しない場合、サーバが FileNotFound Exception を送出していました。

コマンドライン オプションで指定されたディレクトリ構造が存在しない場合にその構造を作成するようにコードを拡張することで、この問題は解決しました。

<Sep 9, 2003 5:29:28 PM PDT> <Info> <Socket> <BEA-000406> <DevPollSocketMuxer was built on Sep 8 2003 15:34:11>

/dev/poll デバイスが使用できない場合はロードに失敗します。現時点では、以下の環境で使用できます。

• パッチを当てた Solaris 7 および Solaris 8 以降

• HP-UX 11.0 (PHKL_24064 パッチが必要)

• HP-UX 11i (PHKL_2546 パッチが必要)

別のサーバをトランザクション コーディネータとして使用するサーバで開始されたトランザクションは、2 つのサーバがそれ以前にトランザクション コンテキストを交換していない場合にコミット時に失敗していました。この問題の原因は、JTA インターセプタに渡されるチャネルにリモート ピアではなくローカル サーバ上の情報が含まれていたことです。

適切なチャネルを JTA インターセプタに渡すようにコードが修正されました。

特定の条件のもとでは、 InitialContext をルックアップする単純な Java クライアントで誤って「No version information」エラーが発生していました。

これは、ヘッダ バッファ内の改行が line.separator プロパティではなく「\n」になっていたことが原因でした。コードを修正して問題は修正されました。

特定の Factory/Trader パターンを使用すると、 ReplicaAwareRemoteRef 警告ログが出力され、クライアント サイドに次のように表示されていました。

[ReplicaAwareRemoteRef] : WARNING: client-side RA stub didn't find environment on thread

不適切なログがクライアントに出力されないようにコードを修正しました。

WebLogic Server 6.1 SP4 では、Admin ツールを使用して WLECConnectionPoolRuntime で INVOKE を発行したときに、WLECConnectionRuntime MBean が更新されていませんでした。

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

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

WebLogic シン クライアントとアプレットを使用している場合に、concurrentModificationExceptions と JMSExceptions が送出されていました。調査の結果、以下の 2 つの問題があることがわかりました。

• Sun ORB の実装に問題がありました。アプレットの仮想マシンがブラウザの更新で AppletContext を解放し、アプレット コンテキストのスレッド グループのすべてのスレッドを停止させていました。アプレット コンテキストの一部として ORB が初期化されると、リーダー スレッドがアプレット コンテキストのスレッド グループで作成されていました。ブラウザが更新されると、ORB のリーダー スレッドも停止されていました。

• WebLogic シン クライアントは、アプレット コンテキスト グループで 2 つのスレッド (HeartbeatMonitor スレッドと RequestTimer スレッド) を作成していました。ブラウザが更新されると、それらのスレッドはアプレット コンテキスト グループの他のスレッドと一緒に停止されていました。

これらの問題は、以下の変更で解決しました。

• アプレットのコンテキスト スレッド グループではなく、システム スレッド グループの子スレッド グループでリーダー スレッドが作成されるように、JDK 1.4.2_04 で Sun ORB の実装が変更されました。この変更により、orb が有効であるか、アプレットの JVM が有効である限りリーダー スレッドが有効であり続けるようになります。

• WebLogic シン クライアントの TunnelResponse スレッドと HeartbeatMonitor スレッドが、アプレットのコンテキスト スレッド グループではなくシステム スレッド グループの子スレッドで作成されるようになりました。この変更により、アプレットの JVM が有効である限りそれらのスレッドが有効であり続けるようになります。この修正は、署名付きアプレットでのみ提供されます。

使用中のリソースが原因で、サーバの停止が失敗していました。これは、アプリケーションの問題が原因で。JDBC 接続や JMS セッションなどのプールされたリソースをアプリケーションがリークしたか、サーバの停止が開始された後に、プールされたリソースへの参照をアプリケーションが保持していたかのいずれかです。

リソースが使用中でも、デフォルトでプールが停止されるようになりました。

JDBC 接続について、前の動作に戻すには、JDBCConnectionPoolMBean で ignoreInUseConnections="false" を設定します。

<Aug 29, 2003 12:31:25 AM EDT> <Info> <Configuration Audit> <159909> <Configuration Auditing is enabled>

一方、監査を無効にしたメッセージには USER ID が記録されていました。

<Aug 29, 2003 12:31:31 AM EDT> <Info> <Configuration Audit> <159910> <USER system, Configuration Auditing is disabled>

コードを修正したことで、どちらの監査メッセージにも USER ID が記録されるようになりました。

別のクラスタの EJB を呼び出すクラスタにクラスタ化された Web アプリケーションをデプロイすると、 AssertionError が送出されていました。分析の結果、インタフェース内のメソッドの計算時に、生成されたコードが正しいメソッドを使用していなかったことが判明しました。これが原因で、生成されたスタブからの誤ったクラスローダを使用していました。

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

PreferWebInfClasses が有効になっている場合に、複数のスレッドが Web アプリケーション内の同じクラスをロードしようとすると、java.lang.LinkageError: duplicate class definition: エラーが発生することがありました。この問題は、クラスを初めてロードする際に発生していました。

この問題は、ChangeAwareClassloader の loadClass メソッドが同期するようにコードを修正することで解決しました。

WebLogic Server は、iiop リクエストの接続キーに基づいてエンドポイントをキャッシュしていました。接続キーは、接続確立時のホスト、ポート、およびタイプ情報に基づいていました。接続キーの確率方法が原因で、トンネリング リクエストは間違った Connection オブジェクトを使用していました。同じホストの複数のクライアントは、エンドポイントが違っていたので負荷テスト時に応答を受け取ることがありませんでした。

トンネリング リクエストが適切な Connection オブジェクトを使用するように、Connection オブジェクトでユニークな ID が作成されるようになりました。

MDB の onMessage がスレッドで呼び出されたときに、そのスレッドと以前に関連付けられたトランザクションが適切にクリーンアップされなかったことが原因で次の例外が送出されていました。

weblogic.utils.AssertionError: ***** ASSERTION FAILED *****[ Left-over JTA transaction found on MDB listener thread ]

スレッドを使用して MDB の onMessage メソッドを呼び出す前にスレッドで古いトランザクションがクリーンアップされるようになりました。

weblogic.jar を Ant タスク内の ClassPathElement として追加すると、weblogic.jar からのクラスのロードに AntClassLoader が使用されます。このプロセスは機能しますが、コンテキスト クラスローダがスレッドに正しくセットされていませんでした。スレッド上のコンテキスト クラスローダは、システム クラスローダのままになっていました。このため、スタブの生成時にクラスロードで問題が発生していました。

この問題は、WebLogic Server が作成する WLDeploy Ant タスクで修正されました。WLDeploy タスクを実装することで、コンテキスト クラスローダが正しくセットされます。

管理サーバは、トリガを使用して各管理対象サーバにハートビートを送信することで、管理対象サーバが実行されていることを確認します。管理対象サーバが再起動したときには、古い管理対象サーバ用のトリガをキャンセルする必要があります。しかし、状況によっては、古い管理対象サーバ用のトリガが適切にキャンセルされない場合がありました。

コードを修正したことで、トリガが正しくキャンセルされるようになりました。

サーバが TCP_NODELAY オプションを設定できるようにクライアントがソケットのリセットを行ったときに、サーバ側のソケットが IDLE 状態のままになることがありました。このため、それらの IDLE ソケットは適切にクリーンアップされていませんでした。

コードの変更により、ソケットで TCP_NODELAY オプションを設定するときに例外が発生した場合にサーバ側ソケットが確実にクリーンアップされるようになりました。

weblogic.Admin コマンドライン ユーティリティを使用してサーバ インスタンスが起動されるたびに、 ServerStartMbean のユーザ名とパスワードが設定されていました。 ユーザが weblogic.Admin を使用してサーバを起動しようとすると、WRITE 属性へのパーミッションがないために起動が失敗していました。

コードを修正したことで、 ServerStart に WRITE 属性が設定されなくなりました。

WebLogic Server 6.1 SP5 ドメインと 8.1 SP1 ドメインを相互運用しようとすると、InvalidClassException が発生していました。これは、6.1 SP5 が EJB 2.0 より前の仕様でリリースされていたのに対し、7.0 以降では EJB 2.0 仕様の最終仕様でリリースされており、この最終仕様で class javax.ejb.TransactionRolledbackLocalException が変更されていたことが原因です。このため、リリース 6.1 SP5 ドメインがこの例外を 8.1 ドメインに送信すると、ローカル クラスと着信した応答クラスの SVUID が異なるため、8.1 ドメインがこの例外オブジェクトをデシリアライズする際に InvalidClassException が発生し、例外を読み込むことができませんでした。

コードを修正したことで、一方のピアがリリース 6.1 ドメインの場合にはローカル クラスがロードされ、着信クラスに SVUID がスタンプされるようになりました。

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

beasvc はファイルが正しく終了しているかどうかを確認し、適切にファイルを読み込むようになりました。

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

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

サーブレットの Init メソッドから MBean.forceShutdown を使用し、かつ load-on-startup を使用している場合、サーバを正常にシャットダウンできず、[コントロール] タブの [このサーバを開始] ボタンも淡色表示のままになっていました。このリンクは、数分後に有効になりました。

この問題は、コードを修正することで解決しました。forceShutdown を呼び出すと、サーバのライフサイクル スレッドがハングすることなくサーバがシャットダウンされるようになりました。サーバの状態が正しく変更されるようになったため、サーバがシャットダウンししだいリンクが有効になります。

Sun プラグインのバグが原因で、EJB のルックアップが失敗していました。しかし、このバグが原因で、WebLogic Server のバグも発生していました。 クラスタ内にサーバが 1 つしかなく、レプリカ リストが空であるにもかかわらず、別のサーバへのフェイルオーバが試行されていました。

この問題は、コードを修正することで解決しました。フェイルオーバは、レプリカ リストが空でない場合にのみ発生します。

WebLogic Server インスタンス内のアプリケーションが同じサーバ インスタンス内の別のアプリケーションに対して RMI 呼び出しを行う際に、Call By Value (CBV) ラッパーの実装が使用されていました。CBV ラッパーの実装は、プリミティブ データ型と Date インスタンスを除くすべてのオブジェクト インスタンスの値を複製していました。 アプリケーション固有のコードが Date を派生し、Date クラスの独自の実装を提供した場合に、そのユーザ定義クラスを複製することで、オブジェクト インスタンスが別のサーバのクラスローダで作成されていました。別のサーバがそのインスタンスを呼び出し元のアプリケーションに割り当てた場合、 ClassCastException が発生します。

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

リクエストがネットワーク チャネル経由で届いた場合、サーバは JVMID の一部としてデフォルトのチャネル情報を書き込む代わりに、ネットワーク チャネルのアドレス情報を書き込みます。ストリームからのこの情報は、リクエストがデフォルトのチャネルまたはネットワーク チャネル経由で届いたかどうかを検知するために使用します。しかし、この方法ではサーバがデフォルト チャネルとネットワーク チャネルを識別できなかったため、ChunkedObjectOutputStream に EndPointStream インタフェースが実装されていませんでした。

この問題が原因で、パフォーマンスが低下していました。

ChunkedObjectOutputStream に EndPointStream インタフェースが実装されるようにコードを修正したことで、リクエストがどのチャネル経由で届いたかを JVMID クラスが識別できるようになりました。

サーバは、ネットワーク チャネル情報ではなくデフォルト チャネルのアドレス情報を JVMID の一部として書き込んでいました。これが原因で、デフォルト チャネルがクライアントから認識できないためにクライアントが java.rmi.ConnectException を送出していました。

コードの修正により、サーバはアドレス情報を正しく書き込むようになりました。

EJB ネットワーク チャネルでビジネス チャネルに接続することができませんでした。ネットワーク チャネルで接続リクエストを受信すると、サーバはその中にネットワーク チャネル情報を書き込むことで JVMID を正しく変換していました。しかし、サーバは rawAddress を変換してネットワーク チャネルのアドレスに基づいて計算していました。JVMID の同等性を維持するには、rawAddress を defaultChannel アドレスに基づいて計算しなければなりません。

コードを修正したことで、リクエストをネットワーク チャネルで受信した場合にも、rawAddress が常に defaultChannel アドレスに基づいて書き込まれるようになりました。

プロキシ認証のためリクエストが再試行されたときに、HttpURLConnection が元のヘッダと Post データを送信していませんでした。その結果として、プロキシ認証が失敗していました。

コードの修正により、オリジナル リクエストのヘッダとデータが再試行時に再送信されるようになりました。

サーバに接続しようとしたときに、クライアントが java.net.UnknownHostException 例外を送出していました。この例外は、そのクライアントがプライベート ネットワーク チャネルを持つサーバに接続したことがあるために送出されていました。新しい接続を開こうとする前に接続が存在するかどうかを判別できないときに、クライアントはこの例外を送出していました。

この問題を修正するコード修正が行われました。

クライアントがアプレットであるかどうかを判別しようとするときに、WebLogic Server はシステム プロパティを読み取ろうとし、セキュリティ例外が送出された場合、そのクライアントはアプレットであると見なされていました。署名付きアプレットの場合はセキュリティ例外が送出されることはなく、実際にはアプレットである場合に誤って Java クライアントと見なされていました。このため、WebLogic Server は Java クライアントと署名付きアプレットを見分けることができませんでした。

コードの変更により、クライアントが署名付きアプレットであるかどうかを判断するだけでなく、WebLogic Server はアプレットのみで設定される追加プロパティを読み取るようになりました。

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

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

beasvc サービスは、SERVICE_CONTROL_INTERROGATE コントロール コードを受信したときにスレッド ダンプを生成していました。これが原因で、 beasvc が他のツールから紹介されたときに無用なスレッド ダンプが生じる恐れがありました。

コードの修正により、カスタム コントロール コードを受信したときのみスレッド ダンプが生成されるようになりました。

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

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

この問題により、以下のメモリ リークが確認されていました。

• アプリケーションをアンデプロイしても、EO オブジェクトの ClientRuntimeDescriptor がヒープに残る。

• アプリケーションをアンデプロイしても、EJBCache オブジェクトがクリーンアップされない。

• アプリケーションをアンデプロイしても、WebAppServletContext 固有の実行時 MBean が登録解除されない。

• KeepAliveCache のタイマー オブジェクトにアプリケーション固有のクラスローダが保持される。

• アプリケーションをアンデプロイしても、記述子オブジェクトが登録解除されない。

• struts を使用するアプリケーションをアンデプロイしても、アプリケーション固有のクラスが Introspector キャッシュに保持されたままになる。

これらの問題は、コードを追加することで解決しました。

<Error> <Deployer> <lcaix17.bea.com> <myserver> <ExecuteThread: '0' for queue: 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-149014> <Target myserver is not defined - error null>

デプロイヤ オプションで指定されていない場合のみデフォルトのタイムアウトを使用するようにコードが修正されました。このようにして、タイムアウトが指定される場合にはデプロイメントがデフォルトの 60 分で失敗しないようになります。代わりに、タイムアウトが切れるのを待つことになります。

weblogic.Deployer コマンドがラッパー クラスから使用されると、複数のドメインへのデプロイメントでエラーが発生するおそれがありました。これは、スレッド上に正しく認証されたサブジェクトがないのに、RMI 呼び出しが実行されることが原因でした。

コードを修正したことで、正しく認証されたサブジェクトが、デプロイメント アクティビティが完了するまで保持されるようになりました。

管理対象サーバ独立 (MSI) モードの管理対象サーバでは、J2EE モジュールのタイプを識別するためのロジックでローカルまたはステ－ジングされたアプリケーションが使用されていませんでした。この問題は、サーバが J2EE モジュール タイプを識別できない結果として MSI モードで現れていました。

管理対象サーバの config.xml ファイルにオリジナル パスが存在しない場合は、 stagingLocation を使用して J2EE モジュールのタイプを識別するようになりました。

EJB モジュールは、キー化された実装クラスから派生した実装クラスを持つすべての EJB 名のリストに実装クラスをマッピングするためのマップを保持しています。このマップは、再デプロイメントの際に使用します。

この実装に以下の 2 つのバグがありました。

• 不必要なマップが EJB モジュールに保持されていた。

• マップ内のリストに同じ EJB 名が繰り返し追加されていた。

これらのバグにより、EJB コンテナがより多くのメモリを消費し、サーバのメモリが枯渇する原因となっていました。

不必要なマップは削除され、まだリストに追加されていない EJB 名のみが追加されるようになりました。

アプリケーションは展開 ear として正常にデプロイされ、META-INF ディレクトリにはリスナ クラスが定義されている weblogic-application.xml ファイルが格納され、リスナ クラスは APP-INF ディレクトリに配置されていました。拡張テンプレートが config_builder.cmd を使用して作成された後、作成された .jar ファイルから META-INF ディレクトリと APP-INF ディレクトリが失われて、アプリケーションをデプロイすることができませんでした。

この問題を修正するコード修正が行われました。

[デプロイ] タブの [停止] をクリックした後に、クラスタにデプロイされた Web アプリケーションの現在の状態が Administration Console に正しく表示されていませんでした。

この問題を修正するコード修正が行われました。

アプリケーションのアンデプロイ時にクラスローダの問題が発生していました。J2EE コンテナにはアプリケーション固有のクラスローダとクラスローダ ツリーが保持されており、これを使用してアプリケーション クラスとモジュール固有のクラスをロードします。アプリケーションに対してアンデプロイ コマンドが発行されると、クラスローダ内のモジュールをロールバックする前にクラスローダとクラスローダ ツリーを閉じていたため、サーブレットの destroy() メソッドから参照されているクラスで NoClassDefFoundError エラー が初めて発生していました。これは、サーブレットの destroy() がその特定のモジュールの rollback() から呼び出されていたためです。

クラスローダ内のモジュールをロールバックする前にクラスローダが閉じられないようにコードを修正しました。

仮想ホストを対象とする Web アプリケーションを含んだアプリケーションは、デフォルト Web サーバを対象にしていないにもかかわらず、デプロイメントの実行中にデフォルト Web サーバ上の既存のアプリケーションを検索していました。このため、他のアプリケーションが同じコンテキスト パスでデフォルト Web サーバにデプロイされていると、仮想ホストのコンポーネントのデプロイに失敗していました。

デフォルト Web サーバを対象にしていないアプリケーションが、デフォルト Web サーバ上の既存のアプリケーションを検索しないようにコードを修正しました。

サーバの起動時に、すべてのアプリケーションがステージングされていました。これには、現在のサーバで必要とされていないアプリケーションも含まれていました。この問題は config.xml ファイルの Application スタンザの StagedTargets プロパティのエントリから確認され、ステージ ディレクトリでは利用可能なすべてのアプリケーションがステージングされていました。

この問題を修正するコード修正が行われました。現在のサーバで必要なアプリケーションのみステージングされます。

WebLogic Server では、新たに java.net.URL リソース接続ファクトリがサポートされました。これにより、EJB が java.net.URL リソース接続ファクトリを使用して、WebLogic Server 環境の外にある Web サーバへの HTTP 接続を取得できるようになりました。

この機能は、以下の方法でサポートされます。

Bean プロバイダで res-type java.net.URL の直接 URL が指定される場合は、指定された jndi-name で URL オブジェクトが作成され、 java:comp/env にバインドされます。Bean プロバイダは、次のように (この場合は weblogic-ejb-jar.xml で) jndi-name を宣言します。

<resource-description>

<res-ref-name>url/MyURL</res-ref-name>

<jndi-name>http://www.rediff.com/<;;/jndi-name>

</resource-description>

Bean プロバイダは、有効な URL ではない文字列を提供します。Weblogic Server では、この文字列を、URL にマッピングされていて JNDI ツリーにもバインド済みのオブジェクトとして処理します。この場合、 LinkRef がその jndi-name にバインドされます。

<resource-description>

<res-ref-name>url/MyURL1</res-ref-name>

<jndi-name>firstName</jndi-name>

</resource-description>

この URL には、Bean コード内の次のようなコードでアクセスできます。

URL url = (URL) context.lookup("java:comp/env/url/MyURL");

connection = (HttpURLConnection)url.openConnection();

weblogic-ejb-jar.xml の <allow-remove-during-transaction> 要素が「False」に設定されていて、アプリケーションがトランザクションに参加しているステートフル セッション Bean を削除しようとした場合に、不適切な例外が送出されていました。

weblogic.ejb20.locks.LockTimedOutException は EJB 2.0 仕様では適切な例外ではなく、必要な例外 javax.ejb.RemoveException で置き換えられました。

結合された (アプリケーション レベルの) キャッシュのエンティティ キャッシュ タイムアウトでは、いずれかの Bean の idle-timeout-seconds が 0 に設定されていると、 idle-timeout-seconds> 0 に設定されている他の Bean もタイムアウト後にキャッシュから削除されていませんでした。

この問題は、 idle-timeout-seconds の登録に関係するコードを修正することで解決しました。

ステートレス セッション Bean が、BMP ejbRemove から呼び出された場合にはフリー プールに返されていませんでした。このため、プールのサイズが最大値に達し、インスタンスの取得を待機している間にタイムアウトしていました。

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

クライアントで EJB を削除して同じ主キーを持つ新しい EJB を作成した場合に、状況により WebLogic Server から Illegal Reentrant call error が送出されることがありました。

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

EJB を作成する際、キャッシュに Bean を挿入する前に、それがキャッシュ内に存在しているかどうかをチェックするように変更しました。これにより、バックグラウンドでのデータベース更新が原因で、キャッシュの状態が同期しなくなるおそれがなくなりました。

バックグラウンドでデータベースを更新しても、キャッシュの一貫性が維持されるようになりました。

ActivatableServerRef は、deactivate を呼び出した Bean メソッドを呼び出した後、activate を呼び出して Bean インスタンスを取得していました。deactivate では、Bean をプールにリリースしていました。しかし、状況によっては activate しか呼び出されない場合もありました。その場合、deactivate が呼び出されないため、Bean はリリースされていませんでした。

activate および deactivate の呼び出しは使用しないことになりました。ActivatableServerRef は、notifyRemoteCallBegin および notifyRemoteCallEnd を明示的に呼び出すように変更されました。

オプティミスティックな同時実行性を使用する EJB の enable-batch-operation が true に設定されていると、java.sql.BatchUpdateException: ORA-01006 または java.lang.ArrayIndexOutOfBoundsException が送出され、述句に null のパラメータがあるクエリと述句に null でないパラメータがあるクエリがバッチとして届いていました。

クエリがバッチ処理に適合しているかどうかをチェックするようにコードを修正しました。クエリが適合していない場合はバッチ処理がオフになり、クエリは複数の UPDATE 文を使用して実行されます。次のような警告メッセージがサーバ ログに送信されます。

<Apr 27, 2004 11:25:12 AM PDT> <Warning> <EJB> <BEA-011078> <The CMP EJB UserSession has enable-batch-operations set to true, however the update queries are not suitable for batching.Batched operations are turned off for this batch and the queries shall be executed with mutliple update statements.>

8.1 SP3

JNDI 名が同じ 2 つの JMS ターゲットがドメインにある場合に、MDB のデプロイメントは同じ名前で 2 つの MDB プールを作成しようとしていました。その結果、同じ名前の 2 つの MessageDrivenEJBRuntimeMBeanImpl オブジェクトを作成しようとして、Instance Already Exists 例外が送出されていました。

この問題は、MDB 記述子で <provider-url> スタンザを指定したときに、それが外部 JMS プロバイダとして扱われるようにコードを修正することで解決しました。また、分散送り先または移行可能な送り先の最適化を実行するときに、現在のサーバまたは現在のクラスタと関連する JMS ターゲットのみが考慮されます。 他のクラスタの JMS ターゲットは考慮の対象になりません。

このようにして、ドメイン内の異なるクラスタの異なる JMS 送り先で JNDI 名が再利用されても MDB のデプロイメントは失敗しません。 また、『WebLogic エンタープライズ JavaBeans (EJB) プログラマーズ ガイド』の「MDB のデプロイメント オプション」で説明されているように、分散送り先や移行可能な送り先の最適化を行うには、MDB の記述子で < provider-url> スタンザを指定しないようにしてください。

MDB で同期式のメッセージ ポーリングが使用される場合、TIBCO JMS サーバが使用されると問題がありました。具体的には、受信されるメッセージの遅延の結果として、MDB コンテナのポーリングが最適化される恐れがありました。

最適化されたポーラーが使用されないようにコードが修正されました。TIBCO のメッセージ配信方式はこの方式ではうまく機能しないので、MDB では TIBCO JMS サーバを連続的にポーリングするポーラーが使用されるようになっています。また、そのようなポーラーは排他的なスレッドを必要とするので、MDB でディスパッチ ポリシーが指定されている場合は、この修正によりポーリングのための十分なスレッドが確保されます。あるいは、MDB の記述子で Bean の最大数を調整することもできます。

注意 : この修正は TIBCO JMS にのみ適用されるので、他の外部 JMS サーバは従来のメカニズムを継続して使用します。したがって、TIBCO 以外の外部 JMS サーバを使用する MDB の動作に変更はありません

CMP20 Bean が MS SQL Server データベースと自動キー生成を使用している場合で、 delay-db-insert-until 要素が ejbPostCreate に設定されている場合、正確な ID セットを持たないエンティティ ローカル オブジェクトが関係セットにキャッシュされていました。この識別不能なエンティティ ローカル オブジェクトは、CMR フィールドでゲッター メソッドが呼び出されたときに返され、それが原因で ClassCast 例外が送出されていました。

この問題は、Bean で create を呼び出す前に dummyPK をエンティティ オブジェクト/エンティティ ローカル オブジェクトと関連付け、PK がわかった場合にそれを正確な ID に置き換えることで解決しました。

WebLogic Server では、オプティミスティックな同時実行性 Bean を別のトランザクションにロードしていました。その際、現在のトランザクションをサスペンドして新しいトランザクションを開始し、オプティミスティックな同時実行性 Bean をロードして Oracle 以外のすべてのデータベースの古いトランザクションを再開していました。この動作は、SELECT の間にロックを取得するのを避けるためでした。しかし、Sybase のデフォルト動作では SELECT の間に共有ロックを取得しますが、文が完了する前でもリリースする必要があるため、上記のロード動作を変更しました。同時実行性 Bean がオプティミスティックである場合は、アイソレーション レベルが Read-Uncommitted または Read-Committed より高いときにのみ、Oracle 以外のデータベースのトランザクションをサスペンドおよび再開します。

cache-between-transactions 要素が true に設定されている場合、Bean は生成された多対多セットと一緒にキャッシュされ、それが原因で新しいトランザクションがキャッシュされた Bean、つまりキャッシュされたセットを使用していました。 セット内の以前にキャッシュされた値はクリアされず、したがってトランザクションの最後で M2NJoinTable の挿入が実行されるときに、 ORA-00001: unique constraint violated error で失敗していました。 つまり、重複したキーを使用してレコードが挿入されようとしていたのです。

多対多セットはトランザクションごとに保持されるので、キャッシュされている多対多セットを新しいトランザクションでクリアすることでこの問題は解決しました。

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

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

BMP bean.java.rmi.RemoteException: EJB の「cache-between-transaction」が true に設定されていると、実行時に ClassCastException が送出されていました。

BMP および CMP20 Bean のチェックを追加したことで、 ClassCastException は送出されなくなりました。

WebLogic Server では、XAConnection を使用する場合に、SonicMQ バージョン 4.* 用の特別な処理コードを使用していました。このコードは Sonic 5.* バージョンでは必要なく、使用すると接続リークが生じていました。

コードの修正で、接続リークは解消されました。

weblogic-application.xml DTD での max-beans-in-cache 要素の説明に誤りがありました。説明では、0 を指定すると max-beans-in-cache は無制限になるとされています。しかし、 max-beans-in-cache を 0 に設定した場合、実際にはキャッシュ サイズも 0 に設定されるため、 CacheFullException が発生していました。

上記の説明は DTD から削除されました。また、適合性チェックを追加することで、 weblogic-application.xml の max-beans-in-cache が 0 に設定されないようにしました。キャッシュ サイズを大きく (無制限に) する必要がある場合は、デプロイメント記述子内の max-beans-in-cache の値を java.lang.Long.MAX_VALUE に設定します。これにより、 weblogic-ejb-jar.xml 内の同じ要素の動作に適合します。

セッション Bean (ステートフル、ステートレス共) およびメッセージ駆動型 Bean の Marathon General Panel に trans-timeout-seconds プロパティが含まれていませんでした。

このプロパティを、すべての EJB の General Panel に追加し、エンティティ Bean の Persistence Panel から削除しました。

Bean をルックアップして初めてビジネス メソッドを呼び出す場合、ejbStore からの EntityContext.getCallerPrincipal() への呼び出しではユーザが「anonymous」として返されていました。その後、ejbStore を再度呼び出すと、正しいユーザ名が返されました。これは ejbStore 固有の問題であり、他のメソッドでは発生しません。

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

cache-between-transaction 要素が true に設定されている場合、トランザクションがロールバックされると、Bean は無効になりますがそのままキャッシュに残っていました。また、 cache-between-transaction が true の場合は、Bean がキャッシュ内にあるかどうかを findByPrimaryKey 実装がチェックしていました。したがって、無効な状態にある場合でも、Bean はキャッシュから再利用することができました。また、リモート メソッドが呼び出されたときにこれを返してロードすることも可能でした。 データベースから Bean をロードすると、トランザクションがすでにロールバックされていてデータベース内に行が存在しないことが原因で NoSuchObjectException が送出されていました。このため、無効な Bean が有効になってキャッシュから返されていました。

現在は、findByPrimaryKey で Bean がすでにキャッシュにあるかどうかを確認するときに、準備のできている Bean と有効な Bean のみがチェックされ、キャッシュ チェックで無効な Bean が返されないようになっています。キャッシュで Bean が見つからないと、findByPrimaryKey はデータベースに対してクエリを実行します。データベースで Bean が見つからない場合は、 FinderException が送出されます。

beasvc に追加された「-log:C:/temp/xxx.log」オプションに問題がありました。 このオプションを使用すると、すべての stdout/stderr がログ ファイルにリダイレクトされます。プロダクションでは、このファイルがすぐにかなりのサイズまで大きくなっていました。 Windows では、このファイルをコピーしたり、ファイル名を変更したりすることはできませんでした。

Windows サービスでこのログ ファイルをローテーションするためのコードを追加しました。

詳細については、http://edocs.beasys.co.jp/e-docs/wls/docs81/adminguide/winservice.html を参照してください。

プロキシで Smart Update を使用することには問題がありました。Smart Update のプロセスにおいて、ハードコード化されたプロキシ設定が引き継がれないか、認識されていませんでした。

現在は、appBoot から Smart Update ユーティリティに以下のコマンドライン システム プロパティを自動的に渡すことでプロキシがサポートされています。

• http.proxyHost

• http.proxyPort

• http.proxySet

• https.proxyHost

• https.proxyPort

• https.proxySet

ログの優先順位の設定も、Smart Update に渡されるようになっています。

config_builder.sh スクリプトが実行されたときに、Configuration Template Builder が起動せず、「Unable to instantiate GUI, defaulting to console mode」というメッセージが生成されていました。しかし、コンソール モードで起動することはなく、コマンド プロンプトに戻っていました。

これは、正しい動作です。ただし、現在では、コンソールが「The Configuration Template Builder is not supported in console mode」というメッセージを示すようになっています。

Configuration Template Builder は、グラフィカル モードでのみ起動できます。したがって、Configuration Template Builder を実行するマシンにアタッチされたコンソールは、Java ベースの GUI をサポートしている必要があります。Windows ベースのコンソールはすべて Java ベースの GUI をサポートしています。UNIX ベースのコンソールで Java ベースの GUI をサポートしているのは一部のものだけです。詳細については、『コンフィグレーション ウィザードの使い方』の「WebLogic Configuration Template Builder の開始」を参照してください。

アプリケーション パスが相対パスで、JVM user.dir が WebLogic ルート ディレクトリと同じでない場合、デプロイメントでアプリケーション パスが正しく解決されていませんでした。

現在は、weblogic.RootDirectory パスを使用して相対パスを解決するようになっています。

すべてのリスナでたった 1 つのクラス ファインダが使用されていたので、それは各呼び出しでリセットされていました。 そのクラス ファイルでは、最後のリスナの URI しか使用できませんでした。

URI のエントリごとに新しいクラス ファインダが作成され、それをアプリケーション クラスローダで利用できるようにコードが修正されました。

HighestNumUnavailable がデフォルトで 0 に設定され、そのことが原因で、一度にすべてをテストおよび解放するためにアイドル状態のすべての接続がロックされていました。この状態では接続が必要以上に長く保持され、適切にサイズ設定されていると思われるプールから予期しない ResourceException が送出されていました。

新しいコードにより、HighestNumUnavailable が接続を一度に 1 つずつテストおよび解放するようになりました。secondsToTrustIdleConnection という新しいコンフィグレーション可能属性も追加されました。この属性を使用すると、設定された秒数内で使用されている場合は接続のテストをスキップすることができます。

WebLogic Server のマルチプールで、時間ベースのフェイルオーバを定義するオプションが提供されていませんでした。セカンダリ接続プールへのフェイルオーバがトリガされる正確な状況があいまいになっていました。有効な接続がないと判断するまでに、プールのすべての接続を確認していました。プライマリ データベースがダウンした場合は、接続がセカンダリ データベースにフェイルオーバされるまで不明の時間待つ必要がありました。

接続をプライマリ データベースに返す前に時間のチェックを実行するオプションが提供されるように、コードが追加されました。「 JDBC マルチプールのフェイルオーバ機能の拡張 」を参照してください。

アプレットがデータソースを介して接続を行い、そのアプレットが強制終了された場合に、WebLogic Server はリーク検出メッセージを出力していました。そのメッセージは誤って送信されることがあり、JDBC/WLS のログ用に正しくフォーマットされていませんでした。

現在は、接続リークが検出されると JDBCLogger を使用してメッセージがフォーマットされます。

JDBC ログの名前が「.log」をサフィックスとして指定された場合に、JDBC のロギングが期待通りにローテーションされていませんでした。WebLogic Server が再起動されたときに、前のログ ファイルが新しい JDBC ログで上書きされていました。

問題を修正するために、JDBCService.initLog() が修正されました。

idle-connection-timeout をコンフィグレーションすると、意図しないスレッドのブロックまたはデッドロックが生じることがありました。その理由は、idle-timeout の期間に変更がないが、DBMS の応答を依然として待っている接続を JDBC プールが再利用しようとする場合があるからです。

JDBC プールがアイドル状態の接続を正しく認識するようにコードが修正されました。

注意 : idle-connection-timeout のコンフィグレーションの目的は、常軌を逸したトランザクションやデッドロックのトランザクションを停止することではありません。

それぞれに 1 つのアプリケーション スコープのデータソースを持つ 2 つのアプリケーションが同じサーバにデプロイされており、それらのデータソースの名前が同じ場合は、 InstanceAlreadyExistsException が送出されていました。

必要に応じてプール名がアプリケーション固有になるようにコンフィグレーションするためのコードが追加されました。

コストベースのオプティマイザで Oracle STATS パッケージを実行するなどして DB 側のカーソルが破棄された場合に、WLS 側の JDBC 接続のキャッシュされている PreparedStatement が無効になっていました。

このシナリオが原因で例外が送出された場合に備えて、PreparedStatement のキャッシュを WebLogic Server で透過的にクリアする手段はありませんでした。WebLogic Server が再起動されるか、WebLogic Server Administration Console または JMX の呼び出しによってキャッシュがクリアされるまで、WebLogic Server のキャッシュにある PreparedStatement は無効なままでした。

現在は、エラーが発生したときに PreparedStatement のキャッシュがクリアされるようになっています。

直接的にどの接続も参照していない一方で、ステートメントのマップは含まれた状態の「ConnectionEnv」オブジェクトが、接続プールに保持されたままになっていました。結果として、それらのステートメントに保持される、ステートメントを作成した接続への参照とデータベース オブジェクトの階層構造も解放されていなかったため、メモリ リークが発生していました。

このような ConnectionEnv オブジェクトを適宜解放するコードを追加して、メモリ リークを解消しました。

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

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

複数の名前で JNDI ツリーにバインドされるようにデータ ソースをコンフィグレーションできるようになりました。1 つの JDBC 接続プールを指し示す複数のデータ ソースをコンフィグレーションする代わりに、複数名のデータ ソースを使用できます。

詳細については、Administration Console オンライン ヘルプの「 複数の名前を持つデータ ソースの JNDI ツリーへのバインディング 」を参照してください。

プール内の JDBC 接続を置換するコードが置換されたオブジェクトのすべての参照を完全に削除しなかったので、接続の置換のたびにメモリが大きくなっていました。この問題は、 getVendorConnection() メソッドの使用時に確認されていました。

現在は WebLogic Server がプール内の接続を置換したときに、その置換は他のオブジェクトから参照されないようになっています。これで、置換された接続がガベージ コレクションできるようになります。

Informix で、テーブル名に大文字が含まれている場合に、RowSet のバッチ更新が失敗していました。Informix では、すべてのメタデータ名で小文字が使用されます。WebLogic Server の RowSet の実装は、メタデータに依存してバッチ更新を行います。

WebLogic Server の RowSet の実装は、Informix JDBC ドライバを使用するときにメタデータ名を小文字に変換するようになりました。

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

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

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

この警告を送信するリーク検出コードは、現在は廃止されています。

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

特定トランザクション内のすべての非 XA 接続に対する isClosed() メソッドで、いずれかの接続に対する Connection.close() 呼び出しの後に true が返されていました。

トランザクションに参加しているすべてのユーザに同じ基底の接続の独立したラッパーを提供するようにコードが修正されました。

test-connections-on-reserve が有効で、アイソレーション レベルが TransactionReadCommitted の場合、顧客が Ingres ドライバを使用しているときに SQLException が発生します。EJB のトランザクション アイソレーション レベルは、TRANSACTION_READ_COMMITTED です。この EJB を呼び出すと、「SQLState(25000) vendor code(5932) ca.edbc.util.EdbcEx: SET TRANSACTION: This statement is not allowed.」という SQLException でデータベース接続が失敗します。

DBMS ロックをすでに保持している接続で失敗していた呼び出しが成功するようになったことを除いて、変更はありません。

ResourcePoolMaintanenceTask がアクティブではないすべてのリソースをタイムアウトにするときに、同期の問題 (デッドロックではない) が発生していました。ResourcePoolMaintanenceTask は接続プールのロックを取得して、それからすべての接続を確認していました。 しかし、その時点で接続がアクティブであり、別のオブジェクトでロックされている場合、ResourcePoolMaintanenceTask はそのロックを取得するのに待たなければなりませんでした。その結果として、速度が低下し、エンド ユーザにとってはサーバが「フリーズ」したようになっていました。タスクは完了しますが、時間が非常に長くかかっていました。

コードの修正により、接続プール全体がロックされることがないようになりました。 この問題は、タイムアウト値をゼロに設定して再利用プロセスをオフにすることでも回避できます。

WebLogic Server が予期せずに JTS 接続の自動コミット モードを変更していました。この問題は、WebLogic Server が予約時の接続テストに失敗したときに発生していました。JTS 接続はグローバル トランザクションを受け入れ、接続はユーザ トランザクション内にあるので、ユーザ トランザクションの境界が尊重されなければなりません。さらに、接続テストはユーザにとって暗黙の動作でなければなりません。以前のリリースでは、そうではありませんでした。

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

JDBC 接続プールの接続作成の再試行頻度が接続の再試行を有効にするように設定されている (つまり 0 以外に設定されている) 場合、接続作成の再試行ロジックはアプリケーションが接続を予約しようとしたときに呼び出されていました。データベースが利用できない場合は、待機と再試行のサイクルの過程でスレッドがハングしていました。

接続予約要求は以前のリリースのように成功するか、すぐに失敗するようになっています。

81SP1 から 81SP2 へのアップグレードにおける weblogic.jdbc.vendor.oracle.OracleStatement の変更で、Oracle 9 ドライバの互換性が失われました。インタフェース weblogic.jdbc.vendor.oracle.OracleStatement のメソッド getDBDescription() の戻り値の型が、81SP1 の DBColumn[] から 81SP2 の Object[] に変更されました。この変更により、顧客が java.sql.Statement オブジェクトを動的プロキシでラップしたいときに 81SP2 が Oracle 9 ドライバと互換性がなくなるようになってしまいました。

この問題は、コードを修正することで解決しました。OracleStatement.java において、getDBDescription および getBinds の 2 つの非サポート メソッドについてそのリファレンスが削除されました。

JDBC 接続プールの「パージ ポリシー」を求める要求に対応して、StatementTimeout 属性と TestStatementTimeout 属性が JDBC 接続プールに追加され、JDBC 接続プールからのデータベース接続で文を実行できる時間を制限できるようになりました。

詳細については、『WebLogic JDBC プログラマーズ ガイド』の「 JDBC 接続プールのテスト機能の拡張 」を 参照してください 。

複数の異なる Prepared Statement を 1 つのトランザクションで使用すると、XA 対応の Statement キャッシュでバグが発生し、閉じられていない JDBC 文のハンドルが失われていました。このことが原因で、Oracle のすべての利用可能なカーソルがすぐに消費およびリークされていました。

XA 対応の Statement キャッシュを実装するために使用されるコレクション オブジェクトが修正されました。

配列のインデックスがスレッドセーフでない状態でインクリメントされることが原因で、負荷が大きいときに IndexOutOfBoundsException を発して JDBC マルチプールが失敗していました。

スレッドセーフになるように、コードが修正されました。

WebLogic のデータソースを使用している Java クライアントで「PeerGone」例外が発生したときに、接続に関連するトランザクション コンテキストが正しくクリーンアップされていませんでした。

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

サイレント スクリプト モードで JDBC 接続プールを作成する際に MaxCapacity パラメータが 1 に設定されている場合、Administration Console で誤ってこのパラメータの値が 15 と表示されていました。

この問題は解決されています。

デフォルトの WebLogic jDriver for Oracle/XA データ ソースは、 oracleXATrace パラメータの値を false ではなく true に設定します。 このため、 config.xml で oracleXATrace="false" を設定してトレース ファイルを明示的に無効にしない限り、時間とともに大きくなる xa_poolname*.trc 形式のトレース ファイルがドライバによって作成されていました。

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

デフォルトの WebLogic jDriver for Oracle/XA データ ソースは、 oracleXATrace パラメータの値を false ではなく true に設定します。 このため、 config.xml で oracleXATrace="false" を設定してトレース ファイルを明示的に無効にしない限り、時間とともに大きくなる xa_poolname*.trc 形式のトレース ファイルがドライバによって作成されていました。

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

weblogic.db.oci.OciLob クラスでは、データベースから返された BLOB データまたは CLOB データの byteArray を保持する 2 つのクラス レベルの変数が定義されていました。このバイト配列はかなり大きくなる場合があるので、OciLob の各インスタンスはガベージ コレクションが行われるまですぐにヒープを一杯にしていました。テストを追加して、クラス レベルの変数 retBArray[] と retCArray[] をメソッドに移動する OciLob を修正したことにより、変数がスタックに割り当てられるようになり、OciLob オブジェクト インスタンスのサイズが削減されて、全体的なヒープの使用量が減少しました。

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

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

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

長いデータベースの停止の後、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 は、失敗した接続作成の試行をクリーンアップするようになっています。

サーバの起動時に、JMS のコードが DestinationRuntimeMBean を作成し、それらを MBeanServer に登録していませんでした。それらの destinationMBean が登録される前に、FileStore に保存されているサブスクライバ用の DurableSubscriberRuntimeMBean (DestinationMBean の子) が作成および登録されていました。サブスクライバはその名前に親コンポーネントを持たず、コンソールでそれらを調べるときに親のスコープから抜け落ちます。

送り先の恒久サブスクライバの登録は、送り先が登録された後で、かつ送り先が通知される前に行われるようになりました。恒久サブスクライバは、JMS 送り先をモニタするときにコンソールから抜け落ちることはありません。

同じマシン上で動作し、同じドメインの 2 つの管理対象サーバで動作している 2 つの JMS トピックの間でメッセージング ブリッジが機能しているときに、問題が発生していました。WebLogic Server の起動時にメッセージング ブリッジが起動されたときに、次の警告メッセージが送出されていました。メッセージは転送できませんでした。

####<Aug 20, 2003 12:49:11 PM MST> <Warning> <MessagingBridge> <slsol4.bea.com> <server2> <ExecuteThread: '10' for queue: 'de fault'> <kernel identity> <> <200026> <Bridge "Test Messaging Bridge" encountered some problems to one of its adapters or underlying systems.It stopped transferring messages and will try to reconnect to the adapters shortly. (Exception caught was ja va.lang.Exception: javax.resource.spi.IllegalStateException: Managed connection is closed at weblogic.jms.adapter.JMSManagedConnection.checkIfDestroyed(JMSManagedConnection.java:263) at weblogic.jms.adapter.JMSManagedConnection.sendEvent(JMSManagedConnection.java:231) at weblogic.jms.adapter.JMSBaseConnection.throwResourceException(JMSBaseConnection.java:1266) at ...

分析の結果、恒久トピック用にコンフィグレーションされており、利用可能な JMS ストアがないためにブリッジがメッセージ リスナを作成できなかったことが判明しました。 ブリッジはリソース例外をログに記録しようとして内部エラーに遭遇していたので、顧客はブリッジのエラーの理由を知ることができませんでした。

ブリッジで適切なリソース例外を送出できるようにコードを修正することで、この問題は解決しました。現在は、ブリッジによって適切な例外がログに記録されます。

MBean を使用して MQ-WLS ブリッジを停止するときに、一貫性を欠く動作が行われていました。この例外は、トランザクション セッションで Recover() が有効なオペレーションでないために起こっていました。

コード変更により、 recover() を呼び出す前にセッションが非トランザクションであることが確認されるようになりました。

WebLogic Server のメッセージング ブリッジを使用して WebMethods 6.0 JMS を WebLogic Server と統合した場合に、 InvalidDestinationException が送出されていました。メッセージを WebLogic Server に送信するときに、WebMethods 6.0 は ack を要求します。ブリッジは、WebMethods が com.wm.broker.jms.Destination 型を期待しているときに weblogic.jms.DestinationImpl 型の ack を送信します。結果として例外が送出されました。

WebLogic Server が 2 つの JMS 実装間でブリッジ機能を提供しているとき、要求されるのは、メッセージの確認応答を適切な型に変換することです。通常のメッセージでは、その仕事が正しく行われているように思われます。

分析の結果、標準の WebLogic JMS クライアントが、送信する WebMethods メッセージを渡され、WebLogic 送り先を使用してその WebMethods メッセージで setJMSDestination を呼び出そうとしていたことが判明しました。WebMethods は、このときに InvalidDestinationException を送出します。

InvalidDestinationException を捕捉して無視するコード変更で、この問題は解決しました。

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

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

MQSeries の停止が原因で MDB が MQSeries との接続を失った場合、リソースは登録を解除されず、MQSeries は WebLogic Server が再起動されるまで解決されない準備されたトランザクションと一緒に放置されていました。

JMSConnectionPoller は、接続エラーが原因で JMS との接続が切断された場合に unregisterResource を呼び出すように変更されました。アンデプロイメント、移行、シャットダウンなどの他の理由で接続が切断される場合、registeredResource は null に設定されていました。

MQSeries に接続された MDB が WLS を再起動する必要なくメッセージを処理していれば、MQSeries が停止されて再起動された場合にトランザクションの回復は正しく行われるようになりました。

<Oct 16, 2003 3:12:49 PM PDT> <Notice> <WebLogicServer> <BEA-000360>
<Server started in RUNNING mode>
<Oct 16, 2003 3:23:17 PM PDT> <Error> <JMS> <BEA-040368> <The following exception has occurred: java.lang.NullPointerException at weblogic.jms.bridge.internal.MessagingBridge.startInternal(MessagingBridge.java:519) at
weblogic.jms.bridge.internal.MessagingBridge.execute(MessagingBridge.java:956) at
weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197) at
weblogic.kernel.Kernel.execute(Kernel.java:336) at
weblogic.kernel.Kernel.execute(Kernel.java:321) at
...

管理対象サーバの Started 属性が「 false 」から「 true 」に変更され、アダプタがデプロイされていないクラスタ化されたコンフィグレーションで、ブリッジが正しく開始されるようにコードが修正されました。

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

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

java weblogic.Admin -url t3://127.0.0.1:7001 -username weblogic -password weblogic INVOKE -type MessagingBridgeRuntime -method stop

MessagingBridge の開始メソッドと停止メソッドは、実行時に MessagingBridge を開始および停止する方法について情報提供の例外を送出するようになりました。

7.0 SP2 クラスタから 8.1 SP2 クラスタへ分散送り先を使用してメッセージング ブリッジ経由でメッセージが送信されるときに、8.1 SP2 クラスタのサーバの 1 つがバウンスされる場合に、メッセージ フローが止まってしまうことがありました。

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

同じ WebLogic Server インスタンス上にある分散トピック メンバーについて、Administration Console の保留メッセージ数のカウンタが正しくありませんでした。リモートの分散トピック メンバーでは、カウンタは正しく示されていました。

他の非リモート分散トピック メンバーに転送するときに、分散トピックの参照カウントを適切に管理するようにコードが修正されました。

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

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

トピック セッションからの JMS メッセージが、受信側がトランザクション セッションを使用して作成され、AUTO-ACKNOWLEDGE が使用され、メッセージがロールバックされた場合にメモリ リークを生じさせていました。

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

IIOP を使用する一部の JMS シン クライアントは、登録を実行するとき、およびハートビート障害によるコールバックの通知のときにサーバが同じロックを使用することが原因でハングしていました。

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

Tibco サーバを再起動すると、ラップされた JMS オブジェクト (ForeignJMSConnectionFactory) がそれ以降にメッセージングを送信できず、次のセキュリティ例外が送出されていました。

weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: ForeignJMSConnectionFactoryConfig Action: read, Target: Password weblogic.management.NoAccessRuntimeException: Access not allowed for subject: principals=[], on ResourceType: ForeignJMS ConnectionFactoryConfig Action: read, Target: Password

再接続時に ForeignJMSConnectionFactory が必要とするユーザ名とパスワードにアクセスするための KERNEL_ID が認識されるように JMSConnectionHelper API がコード修正されて、この問題は解決しました。

この修正の前は、曖昧な状態にあるトランザクションのメッセージはすべてロールバックされ、メッセージがメモリにあるために再配信されていました。しかし、ストア内のレコード (ある場合) はそのレコードのストアのハンドルが無効であるために正しく更新されず、レコード (ある場合) はストアに残されていました。したがって、JMS サーバが再起動されたときに、メッセージは再配信されてメッセージの重複が生じていました。

現在は、曖昧な状態にあるトランザクションのメッセージは、JMS サーバが再起動しないと回復できないようになりました。JMS サーバの再起動なしにメッセージを回復しようとすると、RMERR が生じます。

NamingException の内容をクライアントがデシリアライズできないときに、NestedException の一部としてサーバから NamingException が送出されていました。NamingException には WLContextImpl オブジェクトが含まれており、このオブジェクトをデシリアライズするためには、WebLogic Server はロードバランシングのための環境をスレッド上に必要としていました。

この問題は、スレッド上に環境がない場合にデフォルト環境を初期化することで修正されました。

JSP が更新されて手動で再コンパイルされ、更新された JSP クラス ファイルが jspWorkingDir にコピーされた場合に、WebLogic Server は再コンパイルが必要かどうかを確認せずに、更新された JSP ページを再コンパイルしていました。

新しいパラメータ -Dweblogic.jsp.alwaysCheckDisk を true に設定すると、WebLogic Server はディスク上の JSP クラスをチェックして JSP の再コンパイルが必要かどうか確認します。このパラメータはデフォルトで false であり、デフォルトの動作は変わりません。

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

この問題は、jar 形式と zip 形式で使用されるタイムスタンプの丸め方式の違いが原因で発生していました。丸め方式が違うことで、(1 秒だけ) 古いタイムスタンプが WAR ファイル内のクラス ファイルに記録されていまい、それが原因でサーバがクラスを再コンパイルしていました。

コンパイルされた JSP クラスのタイムスタンプを 1 秒だけ進めるようにコードが修正され、JSP が再コンパイルされないようになりました。

以前は、日本語の文字が含まれている JSP で JavaServer Pages Standard Tag Library (JSTL) タグを使用することはできませんでした。 このような JSP を実行すると、次のエラーが発生していました。

java.io.IOException: javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException: An invalid XML character (Unicode: 0x82) was found in the CDATA section."

ページ ディレクティブで pageEncoding 属性が指定されていない場合、バイト ストリーム (タブライブラリの検証に使用) はデフォルトのエンコーディングを使用して作成されていました。

pageEncoding が指定されていない場合は contentType 属性で定義されている文字エンコーディングが使用されるようにコードを修正して、この問題は解決されました。

コンパイル済みクラスが WAR ファイルに格納されている JSP が、再コンパイルの必要がないときに再コンパイルされていました。最大 1.75 秒のタイムスタンプの差違が示されていました。

新しいタイム バッファ ロジックが適用され、タイム バッファが 1 秒から 2 秒に変更されました。クラスがプリコンパイルされている WAR ファイル内の JSP は再コンパイルされなくなりました。

jspc コードで、WebLogic Server はユーザから提供された JSP 記述子のオプションを解析していました。そのようなオプションの 1 つは、どのタイプのコンパイラを使用するのかを提案する compileFlags 属性でした。

このフラグは、weblogic.xml で文字列 compileFlags によって示されます。WebLogic Server では文字列 compilerFlag をチェックしていたため、この記述子要素が無視されていました。

jspc コードで compilerFlags から compileFlags に文字列の比較を変更するコードが追加されました。compileFlags オプションでコンパイラ フラグを指定すると、それは jspc によって尊重されます。

wlpackage Ant タスクを使用して展開 EAR アプリケーションをビルドするときに、JSP ファイルのタイムスタンプが保持されていませんでした。このことが原因で、すでにコンパイルされている場合でも、JSP が不要に再コンパイルされることがありました。

この問題は、 wlpackage がコピーしたファイルのタイムスタンプを保持するようにコードを修正して解決されました。

sample.jsp :
<%@ page contentType="text/xml" %>
<?xml version="1.0" encoding="iso-8859-1" ?>
<%@ taglib uri="http://java.sun.com/jstl/core"; prefix="c"%>

<ablock>
<![CDATA[
This is a cdata block
]]>
</ablock>

weblogic.jspc コンパイラを使用してこの JSP をコンパイルすると、次のように出力されます。

"sample.jsp": Translation of /sample.jsp failed:
javax.servlet.jsp.JspException: The taglib validator rejected the page: "org.xml.sax.SAXParseException:
The element type "jsp:text" must be terminated by the matching end-tag "</jsp:text>"., "

コードの修正により、XML 構文の内容を JSP ドキュメントに変換しながら CDATA の存在が確認されるようになりました。

<Error> <Deployer> <149205> <The Slave Deployer failed to initialize the application dos due to error weblogic.management.ManagementException: 149233 - with nested exception: [java.lang.ExceptionInInitializerError]. java.lang.ExceptionInInitializerError: java.lang.NullPointerException

コードの修正によりこの問題は解決され、すべての JSP をプリコンパイルする前にスレッド クラス ローダが ServletClassLoader() メソッドに設定されるようになりました。これで、struts クラスと、後で struts ライブラリがロードしようとする他のクラスのロードで同じクラスローダが使用されるようになります。

Usertransaction でタイムアウト例外が発生すると、そのトランザクションはロールバックのマークが付けられていました。実際のロールバックはタイマーでスケジューリングされ、非同期で行われていました。

この状況において、顧客がトランザクションで明示的に rollback() を呼び出した場合、その呼び出しはロールバックを直に行うことも、タイマーがロールバックを実行するのを待つこともしませんでした。再び直接 begin() を呼び出すと、タイマーによってロールバックされるトランザクションとスレッドがまだ関連付けられているので IllegaStateException が送出されます。

rollback() の呼び出しは、ロールバックが実行されたときのみ復帰します。このシナリオでは、トランザクションはタイマーによってロールバックされることが内部でマーキングされているので、rollback() は直ちに復帰し、手動のロールバック処理は開始されませんでした。

他の例外条件が原因で rollback() メソッドが呼び出された場合に、トランザクションがすぐにスレッドから削除され、begin() をすぐに再び呼び出すことができるように、コードが追加されました。

古いリソースと同じ名前で新しいリソースを登録した場合に、それ以降の XA トランザクション操作が新しいリソースを利用することができませんでした。トランザクション操作は、継続してオリジナルのリソースを利用しようとしていました。

同じ名前を持った 2 つ目のリソースの代用が可能なように、コードが追加されました。

WebLogic Server はトランザクションそれ自体ではなくトランザクション マネージャで同期化されていたので、呼び出されるべきメソッドは setRollbackOnlyUnsync ではなく setRollbackOnly でした。

setRollbackOnly が同期化されるようにコードが追加されました。

WebLogic JMS と Oracle XA をリソース マネージャとして XA トランザクションを実行した場合、 Xa.prepare が実行されているときに Oracle との接続を切断すると、XAER_RMFAIL が返される場合があります。つまり、WebLogic Server により Oracle 側でトランザクションが曖昧なまま放置されることになります。この状況において、Oracle には準備状態で作成されたグローバル トランザクションがありますが、そのトランザクションが WebLogic Server によってロールバックされることはなく、結果としてテーブルはロックされ、それ以降の呼び出しは ORA-1591 エラーで返されます。

コードの修正により、RMERR または RMFAIL が Xa.prepare で受信された場合は、リソースでロールバックを呼び出すことができるようになりました。

java.io.IOException: \\UNC path: The file name, directory name, or volume label syntax is incorrect.

このエラーは、DeployerRuntimeMBean を使用して、アプリケーションのソース ファイルのパスが記述子ファイルで URL としてリストされている (file://localhost/D:/myfolder/myapp.ear または file:/localhost//D|/myfolder/myapp.ear など) EAR ファイルをデプロイしたときに発生していました。

バージョン 1.4.2_04 では、JRockit は適切に UNC パスを処理します。

JDK 1.4.1_05 の場合、クラス ファイルが格納されていないソース フォルダが指定されると、WebLogicMBeanMaker はそのエラーを何の通知もなく無視し、MBean の JAR ファイルを作成していました。

JDK 1.4.2_03 の場合、WebLogicMBeanMaker はソース パスにクラス ファイルがない場合は失敗します。

現在、WebLogicMBeanMaker の動作は JDK 1.4.1 と JDK 1.4.2 で同じになっています。

JDK 1.4.2_03 および JDK 1.4.2 の問題が原因で、ロケールが日本の場合に Administration Console でサーバ ログを表示できませんでした。

WebLogic Server 8.1SP3 には JDK 1.4.2_04 が含まれており、このバージョンは日本語ロケールでのサーバ ログの表示を妨げていた問題が修正されています。

UnixProcessControl | NodeManager.c は、 JavaProcessControl と同じように SIGKILL を送信しなければならないときに SIGTERM をオフラインで送信していました。

コード変更の後、 UnixProcessControl はオフラインで SIGKILL を返すようになりました。

ノード マネージャが停止されて再起動されると、再起動の後に、ノード マネージャはそのノード マネージャが管理対象サーバをモニタしていることを検出することがありました。 ノード マネージャは管理対象サーバのコンタクトを 180 秒間待ち、その後に管理対象サーバを再起動しようとしていました。管理対象サーバには、ノード マネージャに繰り返しコンタクトしようとするタイマーがあります。そのタイマーの間隔は指数的に拡大し、管理対象サーバは 2、4、8、16... 秒後にコンタクトを試行していました。ノード マネージャが長い時間経った後に起動されると、管理対象サーバのタイマーの間隔は 180 秒を超える可能性があり、そうなるとノード マネージャは管理対象サーバがダウンしているかのように振る舞うようになります。また、管理対象サーバはノード マネージャで障害が発生した後にタイマーを開始していませんでした。その理由は、NumberFormatException を受信し、スレッドが終了していたからです。

以下の 2 つの変更が実装されました。

1) 管理対象サーバのタイマーの間隔が、ノード マネージャが再起動を試行する間隔 180 秒より小さい最大 128 秒に制限されます。

2) ノード マネージャで障害が発生すると、管理対象サーバは例外を受信していました。 その例外は NodeManagerCommandListener で捕捉され、ノード マネージャに定期的に接続を試行するためにタイマー スレッドが開始されます。

wlconfig Ant タスクを使用して、実行中のサーバ インスタンスに対し JMS サーバと 2 つの JMS キューを作成すると、Administration Console では、JMS サーバと 2 つの JMS キューが正しく作成されて表示されました。ただし、wlconfig では誤って 2 つ目の JMS キューを </JMSServer> 終了タグの外に配置したため、config.xml ファイルが適切に更新されませんでした。

この問題はコードの修正によって解決されました。

管理サーバを再起動してから、2 つの管理対象サーバを同時に起動すると、CPU の消費が大きくなっていました。1 つの管理対象サーバは初期化を完了し、もう 1 つは初期化を開始した後に停止していました。

kill -QUIT pid を使用して、次のようにメイン スレッドが HashMap.rehash でスタックしていたことが判明しました。

"main" prio=5 tid=0x29240 nid=0x1 runnable
[0xffbec000..0xffbedbd4] at
java.util.HashMap.rehash(HashMap.java:292) at
java.util.HashMap.put(HashMap.java:344) at
weblogic.management.internal.DynamicMBeanImpl$XInfo.get(DynamicMBeanImpl.java:2270) at
weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:195) at
weblogic.management.internal.DynamicMBeanImpl.<init>(DynamicMBeanImpl.java:167) at
weblogic.management.runtime.RuntimeMBeanDelegate.<init>(RuntimeMBeanDelegate.java:70) at
weblogic.jms.frontend.FEConsumer.<init>(FEConsumer.java:100)
at weblogic.jms.frontend.FESession$3.run(FESession.java:952)
at ....

コードの修正により、サイズ変更なしでもすべての MBean 属性を収容できるようにデフォルト HashMap のサイズが拡張され、HashMap へのスレッド アクセスが同期化されました。

weblogic.Admin コマンドは、メイン クラスに復帰します。メイン クラスは、例外が送出されたかどうかによって判断される終了コードを返します。 コマンドが成功したときに、不要な例外が送出されていました。

WebLogic Server は、コマンドが成功したときに例外を送出しなくなりました。

weblogic.common.internal.AdminProxy のコードが、呼び出し側が管理ユーザでない場合に例外を送出していました。 オペレータ ユーザのリクエストは、デフォルト キューにディスパッチされていました。 サーバは、保留中のリクエストがデフォルト キューにあるかのように振る舞って停止時にハングしていました。管理ユーザのリクエストは、デフォルトとは違うキューにディスパッチされていました。

ユーザがオペレータかどうかを確認し、オペレータである場合は、そのユーザにサーバの停止を許可するように、コードが追加されました。また、オペレータ ユーザのリクエストがデフォルト以外のキューにディスパッチされるようにするコードも追加されました。これで、この問題は解決されます。

管理ポートまたは admin チャネルが使用されている場合に url で間違ったポートが指定されていたので、管理対象サーバへのリモート接続を試みようとしたときに管理対象サーバのログを表示することができませんでした。

適切なポートを使用し、QOS_ADMIN を設定して操作を実行するように WebLogic Server が更新されました。

カスタム認証プロバイダの MBean は、WebLogic のディレクトリ ツリーの WL_HOME \server\lib\mbeantypes ディレクトリに配置する必要がなくなりました。

MBean タイプをインストールするデフォルトのディレクトリは、 WL_HOME \server\lib\mbeantypes です。ただし、サーバを起動するときに -Dweblogic.alternateTypesDirectory= <dir> コマンドライン フラグを使用すれば、追加ディレクトリで MBean タイプが検索されます。 <dir> は、ディレクトリ名のカンマ区切りのリストです。このフラグを使用する場合、WebLogic Server は常に最初に WL_HOME \server\lib\mbeantypes から MBean タイプをロードし、続いて追加ディレクトリ内を検索してその中の有効なアーカイブを (例外に関係なく) すべてロードします。たとえば、 -Dweblogic.alternateTypesDirectory = dirX,dirY の場合、最初に WL_HOME \server\lib\mbeantypes から MBean タイプがロードされてから、 dirX および dirY にある有効なアーカイブがロードされます。

このオプションは引き続き使用する必要があり、使用しない場合はサーバを起動できなくなります (たとえば、このオプションを使用し、ユーザを作成した後に alternateTypesDirectory オプションを使用しないことを決めた場合)。

詳細については、『WebLogic Security サービスの開発』の「 WebLogic Server 環境に MBean タイプをインストールする 」を参照してください。

• 起動時に、次のローテーション時刻が設定されていませんでした。

• 起動時に複数のログ ファイルが作成されていました。

• ログ ファイルが閉じられるときに WebLogic Server が例外をログ ファイルに記録しようとしていたので、ログ ファイルは 2 度ローテーションされていました。ローテーション時に、WebLogic Server は閉じられたファイルに書き込もうとして例外が送出されていました。

• ログ ファイルが制限を受けていても、WebLogic Server はログ ファイルが指定されたファイル数を超えることを許していました。古いログ ファイルを削除するコードが用意されていませんでした。

現在は、適切なローテーション時刻が起動時に設定されるようになっています。

ローテーション時に例外が送出されても、WebLogic Server はファイルにログを記録しなくなりました。ただし、代わりに標準出力に出力されます。

各ローテーションの後、WebLogic Server はファイル数が制限を超えているかどうか確認するようになりました (制限されている場合)。古いログ ファイルは削除されるようになっています。

カスタム COMMO Bean のある管理対象サーバが管理サーバを再起動することなく再起動された場合、その管理対象サーバは COMMO Bean のインスタンスを作成することができませんでした。次の例外が発生していました。

javax.Management.InstanceAlreadyExistsException is thrown, and the Detailed message in the exception is, The Object name specified 'wlidomain:Name=t,Server=managed1,Type=AppViewRuntime' is not unique across the domain.Please choose an unique Object Name

分析の結果、ダウンしたときに管理サーバの MBeanServer で Mbean が登録解除されていなかったことが判明しました。このため、再起動時に管理対象サーバは Bean を再作成することができませんでした。管理サーバでは、その Bean の名前を持つ Bean インスタンスがインスタンス化された Bean のリストにまだ存在していたのです。Mbean の名前は、ドメインの中でユニークでなければなりません。

この問題は、管理対象サーバのサーバ固有のすべての Bean がサーバのダウン時に登録解除されるようにコードを修正して解決されました。 管理対象サーバがダウンしたときに、管理サーバは PeerGoneEvent を受信し、その管理対象サーバと関連付けられているすべての MBean を登録解除します。

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

この問題は、コードを追加することで解決しました。

weblogic.management.commo.WebLogicMBeanLoader security.xml Exception in thread "main" weblogic.management.ManagementError: [Management:141113] The management subsystem was accessed prior to its initialization.

weblogicMBeanLoader/weblogicMBeanDumper の初期化コードを修正して、この問題を解決しました。

WebLogic Server が文字列ではなくブール値であることを想定していたため、-Dweblogic.ProductionModeEnabled=true が正しく処理されていませんでした。

この問題は、ant タスクで WebLogic Server がこれを文字列として処理するようにコードを追加することで解決されました。

ログ ローテーションは、時間だけでなく、ログ ファイルへの出力アクティビティでも引き起こされていました。つまり、ローテーション時にメッセージがない場合、WebLogic Server は更新があるまでログをローテーションしていませんでした。

この問題は、サーバ起動後の最初のログ アクティビティに基づいて最初にローテーションを行った後、WebLogic Server がスケジュールに則ってログをローテーションするように強制することで解決されました。

Deployers グループのユーザは、コンソールから、あるいはコマンドライン ツール weblogic.Deployer を使用してアプリケーションをデプロイできませんでした。アプリケーションのデプロイメントには、特定の属性の書き込みパーミッションと他のアクションの実行パーミッションが必要でした。

クラスタ、サーバ、仮想ホストなどのさまざまな対象にアプリケーションをデプロイできるように、Deployers グループのユーザにパーミッションが追加されました。

Administration Console を使用して新しい管理対象サーバ ノードをコンフィグレーションする際に、管理サーバが再起動されるまでコンソールで新しいサーバ インスタンスの実行キューをコンフィグレーションすることができませんでした。

管理サーバが起動した後に作成された新しいサーバ ノードが編集可能なデフォルトの実行キューを持つようなりました。

StdoutEnabled フラグが false に設定されている weblogic.logging.NonCatalogLogger が、クライアント サイドのロギング用にログ出力を Administration Console に表示し、この値を無視していました。

consoleHandler ロガーが stdoutEnabled フラグを認識するようになりました。

バージョン 8.1 の以前のサービスパックでは、 weblogic.Admin が「commotype」構文を正しく処理していませんでした。このことが原因で、サンプルのセキュリティ プロバイダに障害が発生していました。 サンプルをビルドし、サーバを起動して、ドメインを設定しようとしたときに、 javax.management.MBeanException エラーが何度も受信されていました。

コードの修正により、 weblogic.Admin が「commotype」構文を正しく処理できるようになりました。その結果、サンプル セキュリティ プロバイダはこのサービスパックで適切に動作します。

デフォルト URL で、 weblogic.Admin が正しく機能していませんでした。たとえば、 java weblogic.Admin -username ss -password ss VERSION では結果が返されないが、 -url t3://localhost:7001 を追加すると正しい結果が返されていました。

コードの変更後は、デフォルト URL がすでに内部にあるようになったので weblogic.Admin は入力 URL で null をチェックするようになりました。

クラスタにデプロイされている Web アプリケーションで、Administration Console に表示される Web アプリケーションのサーブレット数が、java.lang.ClassCastException により間違っていました。

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

weblogic.properties MBean 変換ツールは、内部サーバ オペレーションで使用されるものとは違う別個の MBeanServer を使用します。したがって、変換対象の MBean が MBeanServer で見つからずに変換が失敗する場合には、 invalidAttributeValueException が送出されていました。

MBean プロパティの変換の進行中において、例外を送出する前に weblogic.properties コンバータの使用する MBean が MBeanServer に存在するかどうかをチェックするようにコードが修正されました。

拡張子に関係なくプラグイン メカニズムによってあらゆるファイルがロードされ、サーバの開始時エラーが発生します。lib/mbeantypes の .jar ファイルのみセキュリティ プロバイダと見なし、他のサフィックスのファイルは無視する必要があります。

以前は、.../lib/mbeantypes ディレクトリにあるファイルがすべてセキュリティ プロバイダとして扱われ、サーバの起動時にロードされていました。このような処理は、ファイルの拡張子に関係なく行われていました。現在は、.jar または .zip が拡張子のファイルだけがセキュリティ プロバイダとして扱われます。ファイルの拡張子が .jar または .zip ではないセキュリティ プロバイダがロードされることを当てにしている場合、そのセキュリティ プロバイダはロードされなくなっているのでドメインが開始されることはありません。 そのようなセキュリティ プロバイダ ファイルは、サーバの起動前に名前を変更しないと正しく機能しません。

ドメイン ログをローテーションするときに LogRotationException が送出されました。この問題は、ロガーがログ インデックス (0001) を生成し、新しいログ ディレクトリが同じ名前のファイルを格納している現在のログ ディレクトリにローテーションされたときに発生しました。

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

起動クラスで JDK1.4 ロギング API の LogManager.getLogManager().readConfiguration() を使用すると、stdout が停止されて、それ以降ログ メッセージを使用できなくなりました。

この問題を解決するために、WebLogic Server は匿名ロガーを使用するようになりました。

クラスタ化されたサーバのノードが停止されたときに、それが移行マネージャのアクティブなサーバのリストから削除されていませんでした。このため、移行可能サーバが削除されて再作成された場合に、InstanceNotFoundException (INFE) が送出されていました。

現在は、移行可能サーバを停止する場合に、移行マネージャのアクティブ サーバ リストをひとつひとつ調べていくときに INFE は無視されます。

サーバを停止するときに、管理対象サーバの再検出プロセスに関連するメソッドが不適切に呼び出されていました。また、デプロイメントのコールバック ハンドラでは古いコンフィグレーション MBean 参照を使用しました。

この問題は解決され、管理対象サーバの再検出メソッドはサーバの停止時に呼び出されなくなりました。また、古いコンフィグレーション MBean の参照を回避するため、コールバック ハンドラは管理 MBean の参照を使用するようになりました。

Web アプリケーション モジュールのコードを変更してパフォーマンスを改善しました。

• Web アプリケーション モジュールでは、モジュール全体を変更する場合に、モジュールの更新間隔を考慮するようになりました。

• 大きなアプリケーション デプロイメントの起動時間を減らすため、コンフィグレーション済みアプリケーションのステージング対象属性を永続化するように、デプロイメントが変更されました。

• アプリケーション デプロイメント時の、管理サーバと管理対象サーバ間のリモート呼び出しのトラフィックを減らしました。

ロギング ハンドラ ( WLErrorManager.error ) で、致命的なエラーを報告するときにロギング コードが繰り返されていたため、別のロギング スレッドでロギング デッドロックが発生しました。

コードを変更して、ロギング ハンドラが致命的なエラーを報告するときのロギング デッドロックを防止しました。

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

DELETE

OPTIONS

*COPY

MKCOL

PROPFIND

PROPPATCH

SEARCH

UNLOCK

(ISAPI) iisforward.dll が使用されていない場合に DefaultFileName が機能しませんでした。この問題は次のような場合に見られました。

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

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

• iisproxy.ini に DefaultFileName が追加された。

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

(NSAPI) クライアント側で、応答がクライアントに送信されるのを止めた場合に (応答を完全に受信する前にブラウザを閉じるなど)、Web サーバ ログに 500 [WRITE TOCLIENT ERROR] が記録されました。

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

リクエストと応答のパスは次のようになります。

クライアント -> プロキシ Web サーバ -> プラグイン -> wls

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

クライアント <- プロキシ Web サーバ <- プラグイン <- wls

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

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

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

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

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

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

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

(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 バイトが失われ、その結果コア ダンプになりました。この問題は、コードを修正することで解決しました。

(NSAPI) NSAPI が HP11.00 上で動作し、2 つの Solaris マシン (それぞれに WebLogic Server インスタンスが 3 つずつ) 上にある 6 ノード クラスタにプロキシしている場合、負荷テスト中にメモリ消費量が徐々に増加して、約 50 分後に ns-httpd プロセスがクラッシュしました。HP11.00 または Solaris では同じ負荷テストがクラッシュしませんでした。proxy.cpp のコードではネイティブ システム コールである strdup() が使用されていて、これによってシステム メモリがプログラムのヒープ領域に割り当てられていました。WebLogic Server は Iplanet の FREE マクロを使用して、以前に割り当てられた領域を不要になった時点で解放しました。FREE は strdup() によって割り当てられた領域を解放しなかったため、メモリ リークが発生しました。

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

最後に %0A のある POST リクエストが NSAPI プラグイン経由で WebLogic Server に送信されたところ、本文のストリームに余分なデータが追加されて、ヘッダが本文の最後に現れました。リクエストは WebLogic Server に直接送信されて正しく処理されました。

HTTP/0.9 応答を適切に検出および処理するようにプラグインのコードを変更することで、この問題は解決されました。

(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 サーバがリクエストの処理を続行しなければなりません。

この問題は、コードを変更することで解決しました。

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

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

ある接続がプールから取得されたものの、サーバ インスタンスがその接続をすでに閉じていた場合、 HALF_OPEN_SOCKET_RETRY 例外が送出されました。その結果、以前の接続オブジェクトが削除されて、同じサーバへの新しい接続オブジェクトが作成されました。

HALF_OPEN_SOCKET_RETRY 例外を適切に処理するコードを追加して、問題を解決しました。

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

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

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

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

Netscape 4.0 を使用している場合、WebLogic プラグインは http://hostname:port/ を http://hostname:port/index.html に変換しませんでした。

コードの修正により、この問題は解決されました。

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

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

ERROR: SSLWrite failed

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

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

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

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

コードを変更して、SSL 接続を開始する必要があるかどうかを決定する新しいパラメータを提供することで、この問題を解決しました。

ブラウザと Apache の間で SSL を使用するように Apache がコンフィグレーションされている場合、WebLogic プラグインはリクエストをパスに基づいてルーティングできませんでした。

コードの修正により、この問題は解決されました。

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

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

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

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

8.1 SP3

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

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

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

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

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

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

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

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

リリース 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) 追加されるようにコードを変更しました。

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

このエラーは、WebLogic Server インスタンスに送信するときにプラグインが WL-Proxy-Client-Cert ヘッダを切り詰めていたために発生していました。

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

この機能と制限の詳細については、『WebLogic RMI over IIOP プログラマーズ ガイド』の「 ハードウェア ロード バランサと RMI over IIOP の併用 」を参照してください。

注意 : この機能は、WebLogic Server 8.1 SP3 には部分的にしか実装されていません。詳細については「 RMI/IIOP に関する確認済みの問題 」を参照してください。

Exception in thread ;ExecuteThread: '23' for queue: 'weblogic.kernel.Default'; org.omg.CORBA.MARSHAL: stream corrupted: reading past end of chunk at: 186504 vmcid: 0x0 minor code: 0 completed: No

これは、応答における GIOP バージョンの不一致が原因でした。この不一致は、応答の断片と帯域外のハートビート メッセージを交互に配置することにより引き起こされたものです。応答に正しい GIOP バージョンを配置するようにコードを修正して、この問題を解決しました。

IIOP クライアントがトランザクションを開始し、WLS 8.1 ORB 内にホストされた CORBA オブジェクトのメソッドを実行した場合、トランザクションがあるスレッドで開始され、別のスレッドで終了したために、ロールバック例外が発生しました。

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

コンテナが RMI スタブを不適切にキャッシュしたため、RMI オブジェクトをキャストする際に ClassCastException の問題が発生しました。 ある Web アプリケーションの RMI スタブが作成された後に、別の Web アプリケーションが前者と同じ RMI インタフェースを使用してルックアップを行うと、前者の Web アプリケーションのスタブが返されます。したがって ClassCastException が発生します。これは Web アプリケーション同士でクラスローダに互換性がないことが原因です。この問題は、ルックアップが T3 および HTTP 上で行われる場合にのみ発生します。IIOP には適切なキャッシングの実装がなかったため、ClassCastException の原因にはなりません。

この問題は、コードを修正することで解決しました。JNDI ツリー内の同じ RMI オブジェクトをルックアップする 2 つの Web アプリケーションは、どちらかの Web アプリケーションが以前の呼び出しでロードしたスタブを使用する代わりに、個別のスタブを持つようになりました。これが正しい動作です。

サーバで PeerGone の処理をする場合、マルチプレクサが接続を閉じるよう要求すると、サーバはクライアントを ping します。この ping がハングすると、マルチプレクサはソケットを停止しなくなります。

この問題を修正するため、現在 WebLogic Server では、ハングがエラーと見なされるように、クライアントを ping する前にエラーのフラグを設定します。

wlclient.jar および wljmsclient.jar シン クライアントを使用して、スタンドアロン JMS クライアントにおける ExceptionListener の機能をテストしているときに、接続が停止すると以下のエラーが発生しました。

Error: CORBA COMM_FAILURE 1398079696 Maybe; nested exception is: org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 208 completed: Maybe

スレッド上の現在のユーザが null の場合は、代わりに匿名ユーザを使用するように、シン クライアントのコードを変更しました。

32k より大きな SSL ポートを使用する ORB に、WebLogic Server からアクセスできませんでした。そのようなポートは unsigned short ではなく signed short として解釈されるため、32k より大きなポートは負の数に変換されていました。

ポートを unsigned short として扱うようにコードを変更しました。

外部 IOR の string_to_object() メソッドを呼び出して確立された IIOP 接続に対して、SSL が実施されませんでした。この問題は、SSL タグに SSL ポートがあり、ブートストラップが SSL 上で行われる場合、またはプレーン ポートがない場合にのみ SSL が使用されるために発生しました。

ORB の関数を使用してブートストラップを行う場合はプロトコルを確認するようにコードを修正しました。それに伴い、 weblogic.corba.orb.ORBProtocol プロパティを iiops に設定することで、 string_to_object() メソッドを使用して SSL を実施できるようになりました。

IIOP プロトコルを使用する場合 (たとえば、WebLogic Server シン クライアントを使用する場合や、外部のアプリケーション サーバと相互運用する場合)、null のパスワードを使用してログインしようとすると、null ポインタ例外が発生しました。この障害は T3 プロトコルを使用する場合には発生しませんでした。

IIOP を使用する場合に null のパスワードが許可されるようにコードを変更しました。

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

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

以前は、サーバの再起動時に WebLogic Server を正常に停止するために使用する、UNIX マシンの init.d スクリプトでは、 weblogic.Admin を呼び出す際にコマンドラインでユーザ名とパスワードを指定する必要がありました。

起動 ID ファイルを使用するとこのセキュリティ ホールは解消されます。新しいコマンドの StoreUserConfig が、 weblogic.Admin ユーティリティと weblogic.Deployer ユーティリティに追加されました。

このコマンドを使用すると、事前に作成された起動 ID (および SerializedSystemIni.dat ) ファイルの場所を指定できます。

セキュリティ デバッグ フラグ <ServerDebug DebugSecurityAtn="true" DebugSecurityAtz="true" ...> を StdoutDebugEnabled="true" StdoutSeverityLevel="64" と一緒に設定した場合、サーバはユーザ パスワードをクリア テキストで stdout にロギングしました。

ログ ファイルに書き込まれる文からパスワード文字列を削除することにより、この問題を解決しました。

CR107359 では、ノード マネージャがコンフィグレーション済みのプライベート キー パスワードをパスワードとして使用し、暗号化サービスをインスタンス化する問題が報告されました。これは、暗号化サービスをインスタンス化できないために、ノード マネージャのコンフィグレーションが変更されて、新しいプライベート キー パスワードがコンフィグレーションされる場合の問題でした。

内部的な文字列をパスワードとして使用して暗号化サービスをインスタンス化するように、ノード マネージャが変更されました。ただし、暗号化された既存のプロパティを、新しい暗号化サービスで複合化することはできません。したがって、既存のプロパティは、古いサービスで複合化してから新しいサービスで暗号化し直す必要があります。

ノード マネージャは、サービス パックのインストール後 (またはパッチの適用後) に最初に再起動されるときに、この変換を行います。以降の再起動では、新しい暗号化サービスがインスタンス化されます。

パフォーマンス チューニングの機能が強化され、LDAP ディレクトリでのグループ メンバシップ検索の深さを制限できる新しい属性が追加されました。メンバシップの階層に従って検索を調整し、グループ メンバシップが見つからないことがわかっている検索を排除することができます。

追加された新しい属性は、 GroupMembershipSearching と MaxGroupMembershipSearchLevel です。

weblogic.security.SSL.TrustManagerJSSE インタフェースで、カスタムの TrustManager には certificateCallback() の動作を制御する設定が含まれていました。この設定は validateErr の変数によってオーバーライドされました。

コードを修正して問題は解決されました。現在、WebLogic Server の SSL は、カスタム トラスト マネージャによって返される結果を評価します。

WebLogic Server 6.1 SP05 で、weblogic.net.http.HttpsURLConnection が https.nonProxyHosts 環境変数を受け取りませんでした。この問題は次の状況で見られました。

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

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

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

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

ID アサーションに使用される X509 トークンが、リクエスト ヘッダではなく証明書から取得されていました。X509 ID アサーションがコンフィグレーションされていない場合にもこの問題が発生しました。

セキュリティ レルムの ID アサーション プロバイダが X509 トークンを使用するようにコンフィグレーションされているかどうかを判別するために、テストを追加しました。X509 がコンフィグレーションされていない場合、ID アサーションに使用されるトークンを決定する際に、X509 トークン タイプは無視されます。

パフォーマンス チューニングの機能が強化され、グループ メンバシップ検索の深さを制限できる新しい属性が追加されました。メンバシップの階層に従って検索を調整し、グループ メンバシップが見つからないことがわかっている検索を排除することができます。

新しい属性は GroupMembershipSearching および MaxGroupMembershipSearchLevel です。その場合は、『WebLogic Security の管理』の「WebLogic 認証プロバイダおよび LDAP 認証プロバイダのパフォーマンスの向上」を参照してください。

ドメインで監査 MBean (または同様のサーバ以外の MBean) がコンフィグレーションされている場合、管理対象サーバは起動時にその MBean に通知リスナを追加しようとしました。管理対象サーバは次に NotificationRelay リスナをキャストしようとしましたが、例外が発生しました。

WebLogic Server は NotificationRelay リスナをキャストしなくなりました。

WebLogic Security フレームワークは、 weblogic-ra.xml デプロイメント記述子ファイルにコンフィグレーションされているセキュリティ ポリシーを無視していました。

Java セキュリティ ポリシーと WebLogic セキュリティ ポリシーを組み合わせることで、この問題を解決しました。 weblogic-ra.xml デプロイメント記述子ファイルで指定されたセキュリティ ポリシーが尊重されるようになりました。

iPlanetAuthenticator MBean によって使用される listGroupMembers 実装を介してユーザのリストを取得する際に問題がありました。具体的には、 listGroupMembers() メソッドが空のカーソルを返しました。

StaticMemberDNAttribute のデフォルト値を「uniquemember」に変更して、この問題を解決しました。

他の LDAP 認証プロバイダが静的グループを使用するのに対し、WebLogic 認証プロバイダは動的グループを使用してグループ メンバシップを表現していました。GroupReader MBean の isMember() メソッドで使用される再帰的検索では静的グループを想定していたため、WebLogic 認証プロバイダでグループ メンバシップの検索が適切に動作しませんでした。

コードを追加して、動的グループを扱うように再帰的検索を更新しました。GroupReader MBean の isMember() メソッドの動作は、LDAP ベースのすべての認証プロバイダで一貫性を持つようになりました。

「Deployer」グローバル ロールのユーザが以下のタスクを実行できませんでした。

• JDBC 接続プールを作成後にテストする (Administration Console または weblogic.Admin TEST_POOL から)

• JDBC 接続プールの Statement キャッシュをクリアする

• JDBC 接続プールをサスペンド、強制サスペンド、破棄、強制破棄、または停止する

• JDBC 接続プールを再開するまたは有効にする

• J2EE アプリケーションまたはアプリケーション コンポーネントをクラスタにデプロイまたはアンデプロイする

Deployer はこれらのタスクの実行を許可されるようになりました。

WebLogic Server ドメインに 2 つの Active Directory 認証プロバイダがあり、同じ Active Directory LDAP サーバを使用するようにコンフィグレーションされている場合、両方のプロバイダが LDAP サーバに同時にアクセスしようとすると、LDAP サーバへの接続が失敗しました。WebLogic Server は無効な接続をクリアするために再起動する必要がありました。

Active Directory 認証プロバイダに [接続再試行制限] 属性が追加されました。この属性を指定すると、最初の接続が失敗した場合、LDAP サーバへの接続が再試行されます。

<<WLS Kernel>> <> <BEA-000430> <isMessageComplete javax.net.ssl.SSLProtocolException: FATAL Alert:UNEXPECTED_MESSAGE - A message out of sequence was received.

Verisign SGC/Stepup 証明書のサポートを追加することで、この問題を解決しました。

カスタム キーストアを含むドメインで、Operator セキュリティ ロールを持つユーザが、ノード マネージャを使用して管理対象サーバを起動できませんでした。このエラーは、Operator セキュリティ ロールが、管理対象サーバの起動に必要となる、保護された属性へアクセスするパーミッションを持っていないために発生しました。

コードの修正により、Operator セキュリティ ロールを割り当てられたユーザは、ノード マネージャを使用して、Administration Console から管理対象サーバを起動できるようになりました。

ProxyAuthenticator のコンストラクタが呼び出されず、 SSLLayeredSocket を使用しなかったため、 java.net.ConnectException が発生しました。

プロキシ認証されたソケットを使用するように T3SJvmConnection.newSocket メソッドを変更しました。

ユーザ名およびパスワードと -upload フラグを指定して STOREUSERCONFIG を使用すると、weblogic.Deployer ユーティリティが java.io.FileNotFoundException を送出しました。

いかなる場合でも Deployer が userconfig を使用するように、コードを追加しました。

File.canWrite() における JVM のバグが原因で、 setUID スクリプトを使用する場合にコンフィグレーション ファイル ( config.xml ) を変更できませんでした。

コードの変更による回避策を WebLogic Server に実装しました。 File.canWrite() の問題の詳細については、http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4993360 を参照してください。

以前は、セキュリティ プロバイダのディレクトリにあるファイルはどれもセキュリティ プロバイダとして扱われ、ファイル拡張子に関係なくサーバの起動時にロードされていました。現在は、拡張子が .jar または .zip のファイルだけがセキュリティ プロバイダとして扱われます。

他の拡張子を使用するセキュリティ プロバイダはロードされなくなります。ドメインでセキュリティ プロバイダに他のファイル拡張子を使用している場合は、サービス パック 3 に合わせて変更してください。

アプレットで setIgnoreTrustValidation(true) メソッドを使用すると java.lang.ExceptionInInitializerError が発生しました。

アプレットのセキュリティ マネージャが SSL ハンドシェークを許可するように、コード修正を実装しました。

認証の際に、セキュリティ レルムのデフォルト認証プロバイダは、LDAP に格納されているのと同じ大文字/小文字を使用して、サブジェクトにユーザ プリンシパル名を設定する必要があります。サブジェクトはクライアントがログインの際に使用した大文字/小文字で設定されました (LDAP ではユーザ名の大文字/小文字は区別されます)。

Administration Console で WebLogic LDAP 認証プロバイダの [詳細] タブに UseRetrievedUserNameAsPrincipal 属性を追加することで、この問題を解決しました。この属性が有効な場合は、入力されたユーザ名ではなく、LDAP からユーザ名を取得して認証用のプリンシパル名として使用します。

デフォルト ドメイン ディレクトリにある DefaultAuditRecorder.log ファイルのサイズが非常に大きくなり、使用可能なディスク スペースを使い果たす可能性があります。

監査ログ ファイルが書き込まれるディレクトリを指定するためのコマンドライン引数を提供することで、この問題を解決しました。

-Dweblogic.security.audit.auditLogDir

詳細については、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」を参照してください。

デフォルト ドメイン ディレクトリにある DefaultAuditRecorder.log ファイルのサイズが非常に大きくなり、使用可能なディスク スペースを使い果たす可能性があります。

[★Ｏローテーション時間 (分)Ｏ★] 属性を導入することでこの問題を解決しました。この属性では、新しい DefaultAuditRecorder.log ファイルを作成するまでに待機する分数を指定できます。指定された時間が経過すると、監査ファイルが閉じられて新しいバックアップ ファイルが作成されます。

詳細については、『WebLogic Security の管理』の「セキュリティ プロバイダのコンフィグレーション」を参照してください。

Administration Console を使用すると、特殊な文字 (ドイツ語のウムラウトなど) を含むパスワードで新しいユーザを作成できました。 ただし、新しいユーザがそのパスワードでログインしようとしても、パスワードが受け入れられませんでした。

LDAP エントリからパスワードのバイトを UTF-8 で取得するコードによって、この問題を解決しました。

WebLogic Server 8.1 の以前のサービス パックに付属していたデモ用証明書と信頼性のある CA 証明書は、2004 年 5 月 14 日で期限が切れ、基本制御機能で動作しなくなります。今回のサービス パックには、基本制御機能で動作する、信頼性のある CA 証明書の更新版が含まれています。証明書 (democert.pem、democert1024.pem、ca.pem、ca1024.pem, trusted.crt、demo.crt) がファイルとして提供されています。

WebLogic Server 8.1 の以前のサービス パックを使用している場合は、http://dev2dev.bea.com/products/wlserver81/wls_demo_cas.jsp の指示に従って、更新されたデモ用証明書と信頼された CA 証明書にアップグレードできます。

サーバの起動時に、LDAP コードで静的なアプリケーション デプロイメントがフリーズしました。この状況は、EJB などのコンポーネントに対するセキュリティ ロールをデプロイするときに発生しました。LDAP コードで通知がなかったためにフリーズが発生しました。

組み込み LDAP のコードを修正してこの問題を解決しました。

CSIv2 (Common Secure Interoperability Version 2) および GSS (Generic Security Service) トークンに基づく ID アサーションを使用する場合、特定の長さのプリンシパル名が適切にデコードされませんでした。その結果、 IdentityAssertionProvider が呼び出されなかったり、切り詰められたプリンシパル名で呼び出されたりしました。

コードの修正により、GSS トークンが適切にエンコードおよびデコードされるようになりました。

障害の発生したセカンダリ ノードへのセッション レプリケーションによって、プライマリ ノードがハングしました。プライマリ ノードはセカンダリ ノードに接続しようとし、他のスレッドが待機しなければならないロックを保持しているようでした。

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

シングル サインオン コンフィグレーションに複数の Web アプリケーションがデプロイされていて、あるアプリケーションが weblogic.servlet.security.ServletAuthentication.invalidateAll(request) を呼び出した場合、それ以外のアプリケーションの HttpSessionListeners はセッション タイムアウトが発生するまで呼び出されませんでした。これは、最初の Web アプリケーションに関連付けられたセッションのみが無効化の対象として登録されていたことが原因で発生しました。ユーザが認証された後、以降のセッションは登録されませんでした。

コードを修正したことで、必要に応じて invalidateAll(request) によって、すべての Web アプリケーションのセッション ID とコンテキスト パスの両方が無効化の対象として登録されるようになりました。

HTTPClusterServlet は、セッション クッキーの JVMID によって識別されるプライマリ インスタンスとは異なるサーバ インスタンスへリクエストをルーティングしました。

HTTPClusterServlet は、リクエストを複数のクラスタ化されていない管理対象サーバにプロキシしていました。バックエンドのサーバ インスタンス上の Web アプリケーションは、 index.jsp および frameset.jsp で構成されていました。Web アプリケーションの開始点は index.jsp であり、そこでセッションが作成されます。 index.jsp は <jsp:forward> を使用してリクエストを、フレームセットを含む frameset.jsp に転送します。

index.jsp が初めてプロキシ サーバ ( HTTPClusterServlet ) によってアクセスされると、応答してセッションが作成され、クッキーが設定されました。 index.jsp が frameset.jsp に転送すると、(フレームセット内の各 JSP に対する) 新しいリクエストがクッキーと共に送信されました。断続的にクッキーはリクエスト内に見つかりましたが、リクエストがサーバ リスト内のサーバ (プライマリ サーバ以外) に送信され、セッションは消失しました。プロキシ ログには次のようなエントリがありました。

<Thu Aug 21 15:41:15 PDT 2003>: Found cookie: -1339390245
<Thu Aug 21 15:41:15 PDT 2003>: In-bound headers:
<Thu Aug 21 15:41:15 PDT 2003>: Content-Length: 117
<Thu Aug 21 15:41:15 PDT 2003>: #### Trying to connect with server -1189081773!172.17.26.74!7201!443

この問題は、サーバ リストを更新するロジックを変更することで解決しました。リスト内のサーバの JVMID を更新すると、サーバがリストから削除され、更新されてから再びリストに追加されるようになりました。オブジェクトを更新するだけではリストのソートは行われませんでした。

サーバは、拡張ログ フォーマット ヘッダを書き込む前に、標準のログ エントリをログ ファイルに書き込むことができました。この状況は、ログ ローテーション中に、複数のスレッドが同時に新しいログ ファイルに書き込もうとすると発生する場合がありました。

コードを修正したことで、ログ ローテーションを処理するスレッドが、ログ ヘッダの書き込みが終了するまで新しいログ ファイルに排他的にアクセスするようになりました。

WebLogic Server は、ELF ロギング サービスの初期段階で高い負荷がかかると ELF ヘッダの読み込みに失敗することがありました。この状況は、複数のスレッドが ELF ロギングの初期段階を同時に呼び出した場合に発生しました。

コードを修正して、初期のメソッドをゆるやかに (lazily) 呼び出さずに、コンストラクタに移動しました。

サーブレット仕様に従って、正確に一致するパターンはワイルドカード パターンより優先されなければなりませんが、これが正しく機能していませんでした。たとえば、"/TestPath/*" が "WildcardServlet" に対応し、"/TestPath" が "ExactMatchServlet" に対応するときに、受信する相対 URI が '/TestPath' である場合、 WildcardServlet ではなく、 ExactMatchServlet が提供される必要がありました。

この問題は、パターン マッチング機能に適切な変更を行うことで解決しました。

javax.servlet.http.HttpSessionActivationListener および javax.servlet.http.HttpSessionBindingListener は使用可能なリスナ インタフェースですが、APPC 用の WebAppDescriptorComplianceChecker で欠落していたので、wlappc を使用したコンパイル時にエラーが発生します。

欠落していたインタフェースが追加されました。

"Warning: One of the getParameter family of methods called after reading from the ServletInputStream(), can't mix these two!".

転送されたリクエストはポスト パラメータが解析された後にのみ、クエリ パラメータの取得を試みるようにコードが修正されました。その結果、警告メッセージは表示されなくなりました。

CR121053 によって作成されたパッチでは、SessionListener の sessionDestroyed() メソッドからセッション ID にアクセスし、ネットワーク チャネル名が null の場合に、NPE が発生しました。

ネットワーク チャネルの null 値をチェックするようにコードを変更しました。

関連付けられたリクエストがなく、したがってネットワーク チャネル名が返されないために、NPE が発生しました。これはユーザ エラーにより発生したものですが、NPE の送出は適切な応答ではありません。最適な解決策はデフォルトのネットワーク チャネル名を返すことです。ただし、この方法はネットワーク チャネルが使用されている場合は適していません。

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

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

この問題は、インデックス ファイルを提供する前に、ファイルが存在するかどうかのチェックが行われたために発生しました。分割ディレクトリ アプリケーションの docroot ( src ディレクトリと想定されるが、WebLogic Workshop アプリケーションでは outdir ディレクトリになる) にファイルが存在しなかったため、ファイルが検出されませんでした。

src ディレクトリと outdir ディレクトリの両方でインデックス ファイルを検索するようにコードを変更しました。

アプリケーションが http://localhost:7001/WebApp/target.jsp#section4 のような HTML アンカー タグが含まれている URL をエンコードしようとすると、結果の URL は http://localhost:7001/WebApp/target.jsp#section4;jsessionid= 16OXDN2vax5g2lbGucG4uspB9h6vzhaZw8KtDLl5urAhK96dqvfo!-1835542719 のように不正なものになりました。

アンカー タグは URL の末尾になければならないので、無視されます。正しい URL は、http://localhost:7001/WebApp/target.jsp;jsessionid= 16OXDN2vax5g2lbGucG4uspB9h6vzhaZw8KtDLl5urAhK96dqvfo!-1835542719#section4 のようになります。

元の URL にクエリ文字列がない場合にはアンカーを探し、そのアンカーをエンコードされた URL の末尾に追加するように、コードを追加しました。

save-sessions が有効になっている Web アプリケーションでは、アンデプロイメント時にメモリ リークが発生し、 Object.hashCode がユニークであることについて間違った想定が行われていました。

コードの修正により、Web アプリケーションのコンテキスト パスが必ずセッション データのキーとして使用されるようになり、アンデプロイメント時にはセッション データが削除されるようになりました。

サーブレット コンテキスト リスナは、アプリケーション (Web アプリケーション) のアンデプロイメント時には web.xml ファイルでの宣言に対する逆の順序で呼び出されませんでした。

コードの修正により、サーブレット コンテキスト リスナがアンデプロイメント時に逆の順序で呼び出されるようになりました。そのため、コンテキスト リスナ順の間違った動作を前提としているすべてのアプリケーションはサーブレット仕様の要件に従い、この変更による影響を受けます。

<Warning> <HTTP Session> <BEA-100061> <Web application: ServletContext(id=13577225,name=SessionServlet,context-path=/SessionServlet) tried to place a non-serializable attribute: simplesession.time into the session: 1PNw8xxxxx.This attribute will be lost upon redeployment.This message is logged only once per session.>

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

• この警告メッセージはサーバが開発モードで実行されている場合にのみログに記録されます。

• メモリ セッション データに対しては、この警告メッセージは save-sessions-enabled フラグが true に設定されている場合にのみログに記録されます。

サーブレットとフィルタが属性を使用し、かつ、フィルタがクラスローダの変更の有無をチェックした後にサーブレット クラスが更新された場合、サーブレットとフィルタのクラスローダ間の相違が原因となって ClassCastException が発生することがありました。

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

旧バージョンの WebLogic Server の JSP クラスがバージョン 8.1 のサーバ インスタンスにデプロイされていることが原因で、webauction テストの実行中に次のエラー メッセージが表示されました。

java.lang.NoSuchMethodError: weblogic.servlet.jsp.StaleChecker.isResourceStale

これは、バージョン 8.1 向けに stalechecker インタフェースが変更されたためです。この問題は、コードを修正することで解決しました。そのため、 isStale() メソッドが例外を送出すると、例外は捕捉され JSP が再生成されます。

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

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

開発モードでは、ファイルのタイムスタンプが最後のデプロイメントから変更されると、servlet-init が 2 回呼び出されていました (1 回目はデプロイメント サブシステム、2 回目は App-Poller による呼び出し)。

コードの修正により、WebLogic Server が実行状態でなくなるまで GenericPoller がデプロイされないようになりました。

"Internet Explorer Cannot download a .txt from localhost Internet Explorer was not able to open this internet site.The requested site is either unavailable and cannot be found.Please try again later."

このエラーは、ブラウザが Content-Disposition ヘッダと Cache-Control ヘッダの両方が設定されている状況に対応できなかったために発生しました。

Content-Disposition ヘッダと Cache-Control ヘッダの両方が設定されているかどうかをチェックするコードを追加しました。両方のヘッダがある場合は、ユーザにその状況を通知してコードのデバッグに役立てるための、以下の警告メッセージがログに記録されます。

####<May 4, 2004 7:13:40 PM PDT> <Warning> <HTTP> <mint> <myserver> <ExecuteThread: '13' for queue: 'weblogic.kernel.Default'> <<anonymous>> <> <BEA-1 01324> <Some Browsers may fail when both "Content-Disposition" and "Cache-Control" are set.>

セッション データの参照回数は、リクエストをロギングしている間にカスタム ロガーが HttpAccountingInfo.getRemoteUser()、getRemoteUse()、getRequestedSessionId()、getUserPrincipal()、または isRequestedSessionIdValid() を呼び出すと増加する場合があります。これは、これらのメソッドが SessionInternal オブジェクトを取得しようとするためです。しかし参照回数は減少しません。

この問題は、コードを修正することで解決しました。コードの変更によって、ServletRequestImpl の getRemoteUse()、getRequestedSessionId()、getUserPrincipal()、および isRequestedSessionIdValid() から返される値は、リクエストのロギング前に HttpAccountingInfoImpl オブジェクトにキャッシュされ、カスタム ロガーが HttpAccountingInfo のメソッドを呼び出すとキャッシュされた値が使用されるようになりました。これにより、参照回数が増加しなくなります。

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

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

JavaServer Faces v1.0 参照実装の最終バージョンの一部のサンプルは、起動時の事前のロードに失敗します。次の ServletException が表示されます。

<Mar 16, 2004 10:31:09 AM MST> <Error> <HTTP> <BEA-101216> <Servlet: "Faces Servlet" failed to preload on startup in Web application: "jsf-guessNumber". javax.servlet.ServletException

この問題は、サーブレット リスナを登録するためのロジックを Web アプリケーションの起動時に追加することで解決しました。これは、アプリケーションの lib フォルダにある .tld ファイルで定義されます。

GenericProxyServlet.readStatus が時おり失敗することがありました。この問題は、バックエンド サーバによってすでに閉じられた接続を GenericProxyServlet が再利用する場合に発生しました。

ハーフオープン状態のソケットの例外が発生し、接続ヘッダをフィルタが除外する場合には、同じリクエストを再試行するようにコードを修正して、この問題を解決しました。

GenericProxyServlet が ResponseWrapper に含まれていて、コンテンツ長がゼロである場合、 GenericProxyServlet は java.io.DataInputStream.read() メソッドからの戻り値を長時間待機していました。

そのような場合は DataInputStream が読み込まれないようにコードを変更しました。

ClassPathServlet は Web アプリケーションの WEB-INF\classes ディレクトリからクラスをロードできませんでした。これは、(application.xml におけるこのモジュールの context_root の記述に基づいて) プレフィックスとして余分なフォワード スラッシュ「/」を使用して Web アプリケーション モジュールが作成されたことが原因です。そのため、J2EE アプリケーション コンテナはこのモジュールの適切なクラスを見つけることができませんでした。

Web アプリケーション モジュール名の余分なフォワード スラッシュを考慮するように、 ClassPathServlet にロジックを追加することで、この問題を解決しました。 また、J2EE コンテナを変更して、「/」プレフィックスを使用せずに新しいデプロイメントの Web アプリケーション モジュール名を作成するようにしました。

java.util.MissingResourceException: Can't find bundle for base name weblogic.i18n.J2EELogLocalizer, locale en_US

コードの修正により、システム クラスパスに weblogic.jar ファイルがない場合には Ant で正しいクラスローダを実装できるようになりました。

注意 : Ant バージョン 1.6 は、weblogic.jar ファイルに付属しているバージョンと互換性がありません。外部の Ant ファイルを実行する場合は、システム クラスパスから weblogic.jar ファイルを削除する必要があります。

WLServer Ant タスクでは、指定されたプロパティがないコンフィグレーション ファイル (config.xml) が作成される場合がありました。分析の結果、MBean の変更を config.xml に書き込む saveDomain を WLServer が明示的に呼び出していなかったことが判明しました。代わりに、WLServer は saveDomain を呼び出すトリガに依存していました。問題は、WLServer によるサーバの起動と停止があまりに高速で、トリガの発生が遅れてしまう場合があることでした。

この問題は、saveDomain の呼び出しを WLServer Ant タスク内に置き、サーバが停止される前に config.xml が強制的に書き出されるようにすることで解決しました。

tld ファイルにマルチバイト文字が含まれている場合、ヘッダがファイル エンコーディングに一致しませんでした。Builder を使用してタグ ライブラリを編集する場合、 tld ファイルはデフォルト エンコーディングで保存されます。たとえば、日本語の Windows では Shift_JIS になります。ただし、ヘッダのエンコーディングはファイルのエンコーディングに関係なく ISO-8859-1 でした。

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

WebLogic Server clientgen Ant タスクで、WSDL ファイル内に不正にハイフンを残せるようになっていました。これにより、生成される Java コードに、ハイフンが含まれるクラス名およびメソッド名が存在することになりました。これは、java では無効です。

NameUtils に対する修正により、clientgen でハイフンを削除できるようになりました。さらに、JAXRPC メソッドおよびクラスに対しては、結果の文字列が Java キーワードでもある場合には、WebLogic Server は JAXRPC 仕様 1.0 および 1.1 により、それに _ を追加します。

UDDI 処理が失敗すると、「dispositionReport」が返されました。 SAAJ クラスを使用することで、dispositionReport XML が作成されました。

ネームスペースがまだ定義されていない場合には、SOAPElement.addChildElement(Name name) が「name」のネームスペースを宣言するようになりました。

startWebLogic.cmd スクリプトの「 Setting javax.xml.soap.MessageFactory 」にプロパティを設定した場合、JSP や Servlet の org.xml.sax.driver 、 org.xml.sax.parser 、 javax.xml.soap.MessageFactory 、および javax.xml.rpc.ServiceFactory に対して適切に機能しませんでした。

コードの修正により、WebLogic Server はプロパティの設定前にそれがすでに設定済みであるかどうかをチェックし、設定されていない場合はそのプロパティにデフォルト値を設定するようになりました。

WebLogic Server clientgen Ant タスクで、WSDL ファイル内に誤ってハイフンを残せるようになっていました。これにより、生成される Java コードに、ハイフンが含まれるクラス名およびメソッド名が存在することになりました。これは、java では無効です。

NameUtils に対する修正により、 clientgen でハイフンを削除できるようになりました。さらに、JAXRPC メソッドおよびクラスに対しては、結果の文字列が Java キーワードでもある場合には、WebLogic Server は JAXRPC 仕様 1.0 および 1.1 により、それに _ を追加します。

複数のサービス エントリがある状態で useServerTypes=True と設定すると、正しいタグが解析されず、web-services.xml の複数のタグが解析されませんでした。結果として、web-services.xml の最初のタグだけが正しく処理されていました。

この問題は、web-services.xml で正しいタグを検索し、すべてを処理するコードを追加することで解決しました。

useServerTypes=True が設定されているクライアントに対して、複数のサービス エントリが処理されるようになりました。

servicegen のセキュリティ セクションに encryptKeyName 属性と encryptKeyPass 属性が指定されていない場合、生成される web-services.xml ファイルの EncryptionSpec 属性において EncryptBody 設定が「true」になっていました。その結果 SOAP メッセージが暗号化されました。

web-services.xml ファイルが正しく生成されるようにコードを修正して、この問題を解決しました。

信頼性のあるメッセージングが有効になっていない場合、WSDL ファイルで <wsr:reliability persistDuration="60000"> エントリが生成されました。

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

Web サービスに添付されている画像が正しく機能しませんでした。この問題は、ユーザが Web サービスに java.awt.Image を添付し、その画像が不適切にシリアライズまたはデシリアライズされた場合に発生しました。

シリアライゼーションおよびデシリアライゼーションを修正するコードが追加されました。

信頼性のある SOAP メッセージングを使用して、送信側の WebLogic Server インスタンスから受信側の WebLogic Server インスタンスに Web サービスを呼び出す場合、送信側はコンフィグレーションされている再試行の制限を超えて呼び出しの再試行を続けました。再試行は、受信側が再起動されるか、またはトランザクションのタイムアウト値を超過したために送信側のコンテナがクライアントを強制停止するまで続きました。指定されている再試行の制限を遵守できないことにより、トランザクションが長時間実行され、クライアントがハングしました。

送信側がコンフィグレーションされている再試行の制限を超えて再試行を行わないようにするコードが追加されました。

simpleType に final 属性が含まれる場合、autotype が weblogic.xml.schema.model.parser.XSDParseException: invalid attribute "final" in element "xsd:simpleType" というメッセージで失敗します。

simpleType で final 属性を使用できるようにコードを修正しました。

SOAPElement にマップされる他の型に依存する型 (anyType など) は、SOAPElement 自体にマップされる必要があります。以前は 'hasA' 依存関係のみが考慮されていました。

anyType から派生する型を SOAPElement にマップするコードが追加されました。

機能の拡張により、WebLogic XML デジタル署名 API が提供されました。この API には、SOAP メッセージに対してデジタル署名および検証を行うクラスが含まれています。

詳細については、「 WebLogic XML デジタル署名 API の使い方 」を参照してください。

Apache AXIS クライアントは、Message 要素と ErrorCode 要素に同じネームスペース プレフィックスがなかったため、SOAP 応答メッセージを拒否していました。この問題は、WebLogic Server が最上位要素のみを修飾していたために発生しました。

コードを修正して、最上位レベルの要素が修飾されているかどうかを判別するシステム プロパティ -Dweblogic.xml.schema.binding.qualifytoplevelelementonly を導入しました。有効な値は次のとおりです。

• true - 最上位要素を修飾します。デフォルト値です。

• false - 最上位要素を修飾しません。

Apache AXIX クライアントのユーザはこの値を false に設定してください。

SOAP メッセージにインターレースの SOAP 添付ファイルがあり、MIME ヘッダの start パラメータが content ID ヘッダに一致していない場合、例外が送出されました。

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

SOAP HTTP バインディングでは、Web サービス内で例外が発生すると、サーバはその例外を表す SOAP Fault 応答と共に HTTP 500「Internal Server Error」を送出しなければならないことになっています。

多くの Web サービス クライアントでは、Web サービスに HTTP 接続を行うために URL 接続が使用されます。WebLogic Server は java.net.HttpURLConnection を異なるバージョンでオーバーライドしました。WebLogic のバージョンは、ステータス コードが 400 以上の場合に getInputStream メソッドからの例外を送出しました。

例外が送出されたので、Web サービス クライアントには入力ストリームを取得する方法がありませんでした。このため、HTTP SOAP バインディング仕様に違反していました。

WebLogic Server は、500 エラーで入力ストリームを取得できるようになりました。

ブラウザが使用されている場合は、デバッグ メッセージはサーバに送信されました。Java クライアントが使用されている場合は、メッセージはクライアントで表示されなければなりませんでした。

クライアント デバッグとサーバ デバッグの両方が表示されるようになりました。

WSDL が JPD から生成され、java クライアントがメソッドの呼び出しに使用された場合、クライアントからの入力リクエスト xml は無効であり、NullPointerException が発生しました。

この問題は、コードを追加することで解決しました。

source2wsdd タスクの mergeWithExistingWS 属性を使用して、既存の web-services.xml ファイルを新しいファイルと結合できませんでした。

mergeWithExistingWS="True" を設定する場合の source2wsdd タスクを修正し、source2wsdd に新しい targetNameSpace 属性を追加して、この問題を解決しました。

この変更の結果、web-services.xml に 2 つのサービスがある場合は WSDL ファイルを生成できません。つまり、source2wsdd タスクで wsdlFile 属性を指定できません。WSDL は 1 つの web-services.xml につき 1 つのサービスに対してのみ生成されるためです。

.Net クライアント (暗号化に 512 ビットのキーを使用) がセキュアな WebLogic Web サービス (暗号化に 1024 ビットのキーを使用) を呼び出す場合、以下の例外が発生しました。

Unhandled Exception: System.Web.Services.Protocols.SoapException: Exception during processing: java.lang.AssertionError: weblogic.xml.stream.XMLStreamException: Unable to decrypt EncryptedKey - with nested exception: [weblogic.xml.security.encryption.EncryptionException: Invalid input length for decryption.Length should be multiple of 128 - Block Size.- with nested exception: [com.rsa.jsafe.JSAFE_InputException: Invalid input length for decryption.Length should be multiple of 128 - Block Size.]](see Fault Detail for stacktrace)

変更を行って、暗号化/複合化キーの不一致を説明するわかりやすいエラー メッセージを用意しました。

Unable to decrypt EncryptedKey: key size of encryption/decryption mismatched

Client FAIL Exception during Service Create javax.xml.rpc.JAXRPCException: unable to find port:SubmitStatusRequest This may be because the WSDL file and the generated stub is out sync. Doing clientgen again may fix this problem.

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

<message name="WSException">
<part name="WSException" type="cio:WSExceptionType" /> </message>

コードを変更して、「part」で「element」が使用される場合に wsdl2service が適切に例外を生成するようにしました。

[clientgen] Finished Schema2Java parameter validation [clientgen] schemaURL file:/C:/edrive/462245/AaisTransactionManagerService.WSDL [clientgen] java.io.FileNotFoundException: C:\edrive\462245\Ont.xsd (The system cannot find the file specified) [clientgen] at java.io.FileInputStream.open(Native Method) [clientgen] at java.io.FileInputStream.<init>(FileInputStream.java:103) [clientgen] at java.io.FileInputStream.<init>(FileInputStream.java:66) [clientgen] at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:69) [clientgen] at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.fetchSchemaLocation(SimpleSchemaResolver.java:120) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.doExternalLookup(SimpleSchemaResolver.java:90) [clientgen] at weblogic.xml.schema.model.SimpleSchemaResolver.resolveSchemaLocation(SimpleSchemaResolver.java:68) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclusion(XSDSchema.java:533) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclusion(XSDSchema.java:524) [clientgen] at weblogic.xml.schema.model.XSDSchema.resolveInclude(XSDSchema.java:489)

以前のサービス パックでは、WebLogic Web サービスは WSDL ファイルとインクルードされるスキーマが同じディレクトリに格納されることを想定していました。変更によって、Web サービスはスキーマの相対的なインクルードをサポートするようになりました。次に例を示します。

a.wsdl --- インポート ---> b/b.xsd --- インクルード ---> b/c/c.xsd

スタンドアロンの Java Web サービス クライアントからのビジネス プロセスの呼び出し中に、XMLBean からルート要素を取得しようとすると、ClassCastException が送出されました。WebLogic Server は匿名のインライン型に対して xsi:type を書き出しました。これにより、XMLBean からのルート要素の取得時に WebLogic Workshop で ClassCastException が発生しました。

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

WebLogic Server 8.1 の以前のサービス パックでは、Web サービスの「InclusiveNameSpaces」が正しく実装されていませんでした。Web サービス仕様に従って、次に示すように、ドキュメントで明白に使用されているすべてのネームスペースは InclusiveNameSpaces PrefixList に追加される必要があります。

<c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"; PrefixList="n1"></c14n:InclusiveNamespaces>

旧 8.1 のサービス パックでは、「PrefixList」の属性ではなく、「InclusiveNameSpaces」タグの値としてネームスペースを配置していました。次に例を示します。

<c14n:InclusiveNamespaces xmlns:c14n="http://www.w3.org/2001/10/xml-exc-c14n#"; >n1/c14n:InclusiveNamespaces>

現在では WebLogic Web サービスは、"PrefixList" 属性を使用することで Web サービス仕様に準拠しています。そのため、リリース 8.1 サービス パック 2 以前によって署名されているドキュメントはサービス パック 3 で検証できません (この逆も同様)。

weblogic.webservice.tools.wsdlp.WSDLParseException: transport not supported:http://schemas.xmlsoap.org/soap12/http

以前のサービス パックでは、 clientgen コマンドの実行時に WSDL ファイル内の SOAP 1.1 HTTP 転送のみがチェックされました。コードの修正により、 clientgen の実行時に WSDL ファイル内の SOAP 1.1 HTTP 転送および SOAP 1.2 HTTP 転送の両方がチェックされるようになりました。

コードの修正により、wsdl2service Ant タスクは「generateImpl」が true に設定されている場合、実装クラスのインタフェースとスケルトンを生成するようになりました。

詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「Web サービス Ant タスクとコマンドライン ユーティリティ」を参照してください。

WebLogic Web サービスには現在、以下の 2004 年 4 月 6 日付の OASIS 標準 Web Services Security 1.0 (最終バージョン) 仕様が実装されています。

• Web サービス セキュリティ : SOAP メッセージ セキュリティ

• Web サービス セキュリティ : ユーザ名トークン プロファイル

• Web サービス セキュリティ : X.509 トークン プロファイル

サービス パック 2 は、その時点ではこの仕様の最新バージョンであった、草案バージョン 1.0 を実装していました。

この実装は、以前のバージョン 8.1 サービス パックと下位互換性がありません。この互換性の欠如の詳細については、「 WebLogic Server 8.1 SP3 の新機能 」を参照してください。

Web サービスのセキュリティの詳細については、『WebLogic Web サービス プログラマーズ ガイド』の「セキュリティのコンフィグレーション」を参照してください。

最初のスキーマが 2 番目のスキーマをインポートし、2 番目のスキーマが別のスキーマを含んでいた場合、WebLogic Server はこのインクルードされているスキーマを検索しませんでした。このため、autotype は失敗しました。

この問題は、コードを修正することで解決されました。WebLogic Server はインポートされたスキーマの子インクルードを検索するようになりました。

Weblogic 8.1 Web サービス サーブレットの前にフィルタを追加し、フィルタの最後でカスタマイズされた HttpServletRequestwrapper インスタンスを doFilter(req, resp) 呼び出しに渡すと、ClassCastException が発生しました。

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

web-services.xml 記述子に <xsd:documentation> の余分な要素が含まれていました。たとえば、<xsd:annotation> <xsd:documentation> <xsd:documentation> などです。

余分な <xsd:documentation> タグは削除されました。

servicegen を使用して、 javax.jms.JMSException を送出するサービス メソッドに対する Web サービスを生成すると、 weblogic.xml.schema.binding.BindingException 例外が発生しました。

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

web-services.xml ファイルから WSDL ファイルを作成すると、 web-services.xml ファイルにある処理の順序が WSDL に保持されませんでした。

この問題は、 web-services.xml の生成時に WSDL ファイルに表示される処理の順序を保持するように、コードを修正することで解決しました。

ドキュメント スタイルの Web サービスでは、サービスのエンドポイントによって不正なネームスペース プレフィックスが返されるため、クライアントはユーザ定義の例外を捕捉できませんでした。

この問題はコードの修正によって解決されました。

Web サービスのエンドポイントは、「Accept-Charset: UTF-8, UTF-16」がリクエスト ヘッダに含まれている HTTP リクエストを理解できませんでした。

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

-Dweblogic.webservice.i18n.charset=UTF-8 プロパティを設定すると、警告メッセージ <Unrecognized property: webservice.i18n.charset> が生成されます。

この問題は、このプロパティを管理 admin に追加して、この警告メッセージを削除することで解決しました。

発信プロキシ サーバ (iPlanet Web プロキシ サーバ) を介して外部 Web サービスにアクセスすると、SOAP 障害が返されました。この問題は、HTTP および HTTPS を使用した、プロキシ認証が有効になっているプロキシ サーバを介したリモートの Web サービスの呼び出しが許可されていなかったために発生しました。

Web サービス クライアントのプロキシ サーバを介した HTTP および HTTPS トンネリングが許可されるように、コードを修正しました。

weblogic.xml.schema.binding.BindingException: No default constructor was found for class java.lang.StackTraceElement loaded from file:/usr/bea/jdk141_03/jre/lib/rt.jar!/java/lang/StackTraceElement.class. All classes that will be serialized or deserialized must be non-interface, non-abstract classes that provide a public default constructor - with nested exception: [java.lang.NoSuchMethodException: java.lang.StackTraceElement]

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

Web サービス クライアントで、子要素や属性を持たない空の SOAP ヘッダ要素を送信しようとした場合に、外部の Web サービスが呼び出されませんでした。たとえば、 <env:Header/> のような場合です。

子要素および属性がない場合、空の SOAP ヘッダ要素は送信されないようにコードを修正しました。

トランザクションで DB2 用の XA WebLogic Type 4 JDBC ドライバを使用している場合、PreparedStatement の実行およびトランザクションのコミット後は PreparedStatement を再利用できませんでした。

この問題は、ドライバのコードを修正することで解決されました。

MS SQL Server および Sybase 用の WebLogic Type 4 JDBC ドライバでは、 <stored_proc_name>;<versionNumber> のような完全なストアド プロシージャ名を持つストアド プロシージャのバージョンがサポートされていませんでした。

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

DATE および TIMESTAMP データ型に以下の問題がありました。

• DB2 - Connection.setAutocommit(true) で実行されている場合に TIMESTAMP データ型を使用すると、サーバのプロトコル エラーにより失敗しました。

• Informix - TIMESTAMP データ型を認識しませんでした。

• MS SQL Server - DATE データ型から TIMESTAMP データ型へデータを暗黙的に変換できませんでした。

• Sybase - DATE データ型および TIMESTAMP データ型を認識しませんでした。

この問題は、ドライバのコードを修正することで解決されました。現在ではこれらのドライバで DATE データ型および TIMESTAMP データ型がサポートされています。

XA WebLogic Type 4 JDBC ドライバを使用しているクライアントに対しては、DBMS はクライアントの接続解除を検出できません。クライアントの接続解除によってトランザクションが破棄される場合があり、破棄されたトランザクションをタイムアウトさせる方法はありませんでした。

破棄されたトランザクションをタイムアウトさせる設定がドライバに追加されました。

MS SQL Server 用の XA WebLogic Type 4 JDBC ドライバを使用している場合は、 XASetTransactionTimeout が内部で自動的に true に設定され、ドライバでトランザクションのタイムアウト設定が利用できるように、WebLogic Server が更新されました。

XASetTransactionTimeout 属性の詳細については、「 XAResource のトランザクション タイムアウトのサポート 」を参照してください。

ドライバは NOTA (-4) ではなく RMERR (-3) というエラー コードを返しました。その結果、トランザクションは回復時に解決される代わりに、 AbandonTimoutSeconds まで再試行されました。

この問題は、ドライバのコードを修正することで解決されました。

CLASSPATH に EJBJAR ファイルが含まれていない場合には、セッション Bean のサービス メソッドの呼び出しによってオブジェクト レプリケーションのロジックがトリガされ、その結果、 TypedFML._tmpresend が呼び出されます。CARRAY フィールドが null の場合、 _tmpresend はフィールド長を (FLDID_SIZE + FLDLEN_SIZE ではなく) 0 と記録します。 最終的には、 _tmpostrecv が呼び出され、フィールド長は FLDID_SIZE + FLDLEN_SIZE と想定されます。 _tmpresend はこの情報を記録しなかったため、負の値がフィールド長として読み込まれました。現在、フィールド長に対するチェックではフィールド長が 0 であるかどうかが検査されるため、 NegativeArraySize 例外が送出されます。

フィールド長をチェックし、それが 0 以下であるかどうかを判別するコードが _tmpostrecv に追加されました。

tBridge FML または Queue のサンプルの実行中、 tBfrom2jms は tBsend2jms からの quit を認識しませんでした。その結果、タイムアウト エラーが発生しました。

この問題は、 weblogic.jms.Tux2JmsQueue からのメッセージを受信するように tBfrom2jms のコードを変更することで解決しました。現在では quit は受信されます。

受信する Java 文字列参照が null の場合、エンコーディング ルーチンの viewj コンパイラのパラメータは false に設定されます。 -modify_string オプションを使用する場合は、コンパイラは空の文字列に null を追加する必要があります。

修正により、エンコーディング ルーチンのパラメータは null 文字列に対して true に設定され、null を空の文字列に追加できるようになりました。

WLS/WTC v7.0sp4 tBridge は、CARRAY 型メッセージ (ByteMessage) または Qmessage の CorrelationID を Tuxedo から WebLogic JMS に伝播しませんでした。

CARRAY メッセージが Tuxedo キューから受信されると、CorrelationID を JMS メッセージに設定するように、コードが追加されました。

現在の WebLogic Tuxedo Connector は VIEW の文字列に対して使用されないスペースを埋め込まないので、WebLogic Tuxedo Connector FML/VIEW はサイズの大きい文字列型で失敗しました。

WebLogic Tuxedo Connector は常に VIEW ファイルで指定されている文字列の固定長を送信するようになりました。

TPNOTRAN フラグが設定されている WebLogic Tuxedo Connector の tpcall が失敗して、トランザクションが強制的にロールバックされました。 これは、 tpcall の試行が失敗した場合に、 TPNOTRAN フラグが設定されているかどうかに関係なくトランザクションがロールバックとしてマークされていたために発生します。

修正により、 tpcall に対して TPNOTRAN フラグが設定されている場合は、トランザクションがロールバックとしてマークされなくなりました。

WebLogic Tuxedo Connector ユーティリティ ルーチンは、 xdr_encode_string_length メソッドによって入力に null 文字列が検出されると、null ポインタ例外を送出する場合があります。

修正により、null 入力文字列に対するチェックが追加されました。

WebLogic Tuxedo Connector は複数の Tuxedo ドメインが存在するトランザクションを調整します。最初のドメインが 2 フェーズ コミットの第 1 フェーズで ROLLBACK を決定しても、他の Tuxedo ドメインはロールバックされませんでした。

XAException を送出する前に、すべての Tuxedo ブランチがロールバックされるようになりました。

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

• Administration Console において ConnectionPool が正しく表示されない。

• 登録解除されたエンドポイントにより COMM_FAILURES が発生する。

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

WLEC 経由で呼び出しを行うクライアントは、接続数が maxpoolsize を超えるまでは、既存の接続を再利用しないで、新しい WLEC 接続を優先的に作成していました。このしきい値に達すると、接続が再利用されました。

WLEC 接続プールを使用する場合のシステム パフォーマンスとリソース使用率を向上させるため、コードを修正しました。

XML パーサ クラス オブジェクトを JAXP プロパティで定義するには、 javax.xml.parsers.DocumentBuilderFactory=weblogic.xml.jaxp.RegistryDocumentBuilderFactory
javax.xml.parsers.SAXParserFactory=weblogic.xml.jaxp.RegistrySAXParserFactory
javax.xml.transform.TransformerFactory=weblogic.xml.jaxp.RegistrySAXTransformerFactory というエントリを $java.home/lib/jaxp.properties ファイルに追加します。

8.1 アプリケーションまたはドメインを 8.1 SP2 または SP3 にアップグレードするときに UnsupportedOperationException が発生する場合がありました。この例外で「This operation requires xqrl.jar」という誤ったエラー メッセージが表示されました。クエリが複雑すぎるため処理できないことを示すように、このエラー メッセージを変更しました。

注意 : この例外は、 wlxbean.jar ファイルがサーバの CLASSPATH に含まれていないために発生した可能性があります。したがって、アップグレード処理中にこの例外が発生した場合は、 wlxbean.jar がサーバの CLASSPATH に含まれていることを確認してください。