2 既知の問題と回避策

この章では、Oracle WebLogic Server 12.2.1.4.0に関連する問題について説明します

この章の内容は次のとおりです。

一般的な問題と回避策

この項では、次の問題と回避策について説明します。

Safariを使用している場合にファイル名にマルチバイト文字が正しく表示されない

問題

影響を受けるプラットフォーム: すべて

Safariブラウザを使用してコンテンツをダウンロードする場合、ファイル名にマルチバイト文字が含まれていると、ファイル名の文字が"------"として表示されます。

回避策

管理対象サーバーでUseHeaderEncodingtrueに設定します。この操作を行うには、次のWLSTコマンドを使用します。

connect("admin_name", "admin_password", "t3://localhost:port")
edit()
startEdit()
cd("Servers/server_name/WebServer/server_name")
set("UseHeaderEncoding", "true")
save()
activate()
exit()

管理サーバーがEMコンソールで「開いているファイルが多すぎます」のメッセージをレポートする

問題

影響を受けるプラットフォーム: Linux

管理サーバーに対して構成されているファイル記述子の最大数が65535未満の場合、WebLogic Server管理サーバーは、Enterprise Manager (EM)コンソールで「開いているファイルが多すぎます」のメッセージをレポートします。

回避策

次のコマンドを実行して、現在構成されているファイル記述子の最大数を確認します。

cat /proc/sys/fs/file-max

値が65535未満の場合は、次のステップを実行します。

  1. ルート権限でファイル/etc/security/limits.confを編集します。
    > sudo vi /etc/security/limits.conf
    
  2. 65535以上の値を使用して、次の2行を追加します。
    *                soft    nofile          65535
    *                hard    nofile          65535
    
  3. 新しいターミナル・セッションを開始します。
  4. limit descriptorsコマンドを実行して、記述子が指定した値(65535以上)に増やされたことを確認します。
    > limit descriptors
    descriptors  65535

CoherenceをMavenとともに使用する場合のインストール要件

問題

影響を受けるプラットフォーム: なし

Oracle WebLogic Serverに依存せず、Mavenを使用するCoherenceユーザーは、スタンドアロンのCoherenceインストーラを使用する必要があります。

Oracle WebLogic Serverに依存し、Mavenを使用するCoherenceユーザーは、「WebLogic Server」または「完全および例」インストール・オプションを選択する必要があります。「Coherenceインストール」オプションは選択しないでください。

回避策

なし

デフォルトWebLogic Serverメッセージ接頭辞の変更

問題

影響を受けるプラットフォーム: すべて

デフォルトのWebLogic Serverメッセージの接頭辞は、WebLogic Serverの今後のリリースでBEAからWLに変更されます。

回避策

なし

日本語名が付いたパーティションをFusion Middleware Controlから作成できない

問題

影響を受けるプラットフォーム: すべて

Fusion Middleware Controlでは、日本語名が付いたパーティションは、ライフサイクル例外のため作成できません。

回避策

英語名を使用したパーティションを作成するか、日本語名のパーティションをWebLogic Server管理コンソールから作成します。

管理コンソールの問題と回避策

この項では、次の問題と回避策について説明します。

ブラウザの「戻る」ボタンをクリックするとコンテキストが破棄される

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server管理コンソールでページ・フローが完了すると、別のページ(通常は表)に進みます。

この時点でブラウザの「戻る」ボタンをクリックすると、完了したアシスタント内の最後のJSPファイルのロードが試行されます。この時点で、このアシスタントのコンテキストはすべて破棄されます。

回避策

変更の取消し後または完了後にブラウザの「戻る」ボタンを使用してアシスタントに戻ることはお薦めしません。また、アシスタント内の前のステップに戻ることもお薦めしません。かわりに、Oracle WebLogic Server管理コンソールのナビゲーション・リンクおよびボタンを使用してください。

サポート対象外のワーク・マネージャ構成の作成

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server管理コンソールでは、サポート対象外で想定どおりに機能しないワーク・マネージャの構成を作成できます。不適切なワーク・マネージャ構成があると、サーバー・ログに複数の例外が記録される可能性があります(最も一般的なものは、デプロイメント・ディスクリプタの解析中の「検証の問題が見つかりました」という例外です)。

回避策

ワーク・マネージャ構成に関するオンライン・ヘルプのガイドラインに従ってください。特に、特定のワーク・マネージャに割り当てられるリクエスト・クラスは1つだけです。リクエスト・クラスのスコープはワーク・マネージャと同じかそれより広くする必要があります。アプリケーション・スコープのリクエスト・クラスをグローバルなワーク・マネージャに割り当てないでください。また、アプリケーション・スコープのワーク・マネージャに対して複数のアプリケーション・スコープのリクエスト・クラスを作成しないでください。

ワーク・マネージャの構成を記載されている制約に従って修正すれば、これらの問題は解決します。

サーバー・ステータス表が一貫性のない情報を反映する

問題

影響を受けるプラットフォーム: すべて

「クラスタ: 監視: サマリー」ページの「サーバー・ステータス」表には、「プライマリ」「セカンダリ分散名」の2つのデフォルトの列があります。レプリケーションのシナリオによっては、これらのフィールドに、「クラスタ:モニター:フェイルオーバー」ページで修正および表示されたすべてのレプリケーション統計が反映されない場合があります。

詳細は、「クラスタ: 監視: フェイルオーバー」ページを参照してください。

回避策

なし

EJBのセキュリティ・ポリシーを定義する際の例外

問題

影響を受けるプラットフォーム: すべて

別のライブラリ・デプロイメントで定義された型を参照しているEJBデプロイメントに対して、Oracle WebLogic Server管理コンソールでセキュリティ・ポリシーを定義するとき、そのライブラリ・デプロイメントをコンソールから使用できないと、例外が発生する可能性があります。

回避策

すべてのライブラリ・デプロイメントで、Oracle WebLogic Server管理サーバーと、アプリケーションの参照をサポートするために必要な管理対象サーバーをターゲットとして指定します。この設定により、ポリシーの定義時に、コンソールからそれらのライブラリ・デプロイメントにアクセスできるようになるため、参照される型を必要に応じてクラスロードできます。

管理コンソールに、デプロイメント・プランに加えれらた外部の変更が反映されない場合がある

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server管理コンソールに、デプロイメント・プランで加えられた外部変更が反映されているとはかぎりません。コンソール・ユーザーがデプロイメント・プランを表示しているときに、コンソール外でデプロイメント・プランに変更が加えられた場合、それらの変更はコンソール・ユーザーに表示されません。変更には、ワークショップの使用、プラン・テキスト・ファイルの直接編集、WLSTまたはwebLogic.Deployerを使用した新しいプランによるデプロイメントの更新などがあります。

回避策

別のデプロイメントの構成ページに移動してから、元のデプロイメントに戻ってください。

アプリケーション・テスト・リンクが管理コンソールでの解決に失敗する

問題

影響を受けるプラットフォーム: すべて

一部の構成では、Oracle WebLogic Server管理コンソールに含まれているアプリケーション・テスト・ページは、テスト・リンクでIPv6アドレスを使用します。これらのアドレスは、Oracle WebLogic Serverインスタンスで有効です。ただし、IPv4とIPv6が混在する一部の環境においては、ブラウザからこれらのアドレスを使用してアプリケーションと対話することができず、テスト・リンクが解決されません。

回避策

このシナリオは、一般に、管理者が構成でサーバーのためのリスニング・アドレスを指定せず、サーバーが、Javaおよびオペレーティング・システムがIPv4よりもIPv6を使用するよう構成されているデュアル・スタック(IPv6/IPv4)マシン上で実行されている場合に起こります。IPv4スタックがIPv6と通信できないこれらの混合環境では、IPv4のみを使用するためにすべてのサーバーがダウングレードされるよう、次のコマンドを使用してすべてのサーバー・インスタンスを開始することをお薦めします。

-Djava.net.preferIPv4Stack=true

java.lang.NoClassDefFoundErrorが表示される

問題

影響を受けるプラットフォーム: すべて

管理対象サーバーにデプロイされたアプリケーションやEJBをOracle WebLogic Server管理コンソールで操作する際、それらがデプロイされたライブラリに依存しているとjava.lang.NoClassDefFoundErrorが発生することがあります。

回避策

Oracle WebLogic Server管理コンソールでは、Javaデータ型およびアノテーションを処理できるように、共有ライブラリ・デプロイメントにアクセスする必要があります。したがって、すべての共有ライブラリ・デプロイメントは、管理対象サーバーやクラスタのみでなく、常にOracle WebLogic Server管理サーバーもターゲットにする必要があります。

新しく作成したCoherenceクラスタ・サービスまたはキャッシュのセキュリティ・ロール構成時のエラー

問題

影響を受けるプラットフォーム: すべて

新しく作成したCoherenceクラスタ・サービスまたはキャッシュのセキュリティ・ロールの構成時に、Oracle WebLogic Server管理コンソールで、予期しないエラーが確認されました。これは、Oracle WebLogic Server管理コンソールではよくあるパターンで、新しく作成したアーティファクトにアクセスしてそのアーティファクト上のセキュリティ・ロールおよびポリシーを構成する前に、そのアーティファクトを保存してアクティブ化する必要があります。多くのコンソール・ページでこれが確認され、次のことを示すメッセージが表示されます:
This page is not available because the necessary security providers have not been configured, or those configuration changes are pending and not yet activated. Please activate the changes and (if necessary) restart the Administration Server to make this page available.

このチェックは、Coherenceセキュリティ・ページでは行われません。

回避策

新しいCoherenceクラスタを作成したら、構成の変更をアクティブ化し、再起動変更リストで示されている任意のサーバーを再起動します。このステップにより、Coherenceクラスタのリソースを、ロールおよびポリシー構成のために使用できるようになります。

管理コンソール拡張の非推奨化

問題

影響を受けるプラットフォーム: すべて

WebLogic Server 12.1.3からコンソール拡張が非推奨になりました。関連ドキュメントの『Oracle WebLogic Server管理コンソールの拡張』およびOracle WebLogic Server管理コンソールJava APIリファレンスは、ドキュメント・セットから削除されています。

回避策

なし

パーティションの作成時にコンソール間で動作が異なる

プラットフォーム: すべて

WebLogic Server管理コンソールで作成された、仮想ターゲットおよびリソース・グループを含まないパーティションは、Fusion Middleware Control (FMWC)のパーティション・モニタリング・ページに表示されません。これらのパーティションはFMWCパーティション表に不明ステータスで表示されます。

回避策

回避策として、FMWCパーティション表でパーティションを選択し、仮想ターゲットとリソース・グループを追加します。

コンソール・モニタリング・ダッシュボードにInternet Explorer 11ブラウザとの互換性がない

問題

Internet Explorer (IE) -11を使用してWebLogicコンソールにアクセスする場合、「モニタリング・ダッシュボード」リンクをクリックしても、コンソールに情報が表示されません(空のスペース)。

回避策

Microsoft EdgeまたはWindowマシンで使用可能な他のブラウザを使用してください。

クラスタリングの問題と回避策

この項では、次の問題と回避策について説明します。

ユニキャスト・モードのクラスタ・メッセージングでスレッドがブロックされる

問題

影響を受けるプラットフォーム: Linux

クラスタ通信にユニキャスト・モードを使用している場合、クラスタ・メッセージングで多くのスレッドがブロックされ、クラスタ・メンバーによるハートビート・メッセージの送信が難しくなることがあります。この状況では、一部のクラスタ・メンバーがクラスタからドロップアウトし、クラスタへの再参加に時間がかかることがあります。

回避策

なし

最小および最大動的クラスタ・サイズ制約の影響

問題

影響を受けるプラットフォーム: すべて

拡張性をサポートするために、Oracle WebLogic Server 12.2.1では動的クラスタの最小および最大サイズに関する次の構成可能な制約が導入されました:

  • MinDynamicClusterSize (デフォルト=1)
  • MaxDynamicClusterSize (デフォルト=8)

また、MaximumDynamicServerCount属性は非推奨となり、DynamicClusterSize属性に置き換えられました。この属性の値は、先に説明した最小および最大の制約に対して検証されます。その結果、一部の既存のユーザー構成/スクリプトが失敗することがあります。これが発生した場合、DynamicClusterSize値が限度内に収まるようにMaxDynamicClusterSize設定を適切に更新する必要があります。

回避策

なし

クラスタのスケール・ダウン中またはフェイルオーバー中のHTTP POSTリクエストでのHTTP 503エラー

問題

影響を受けるプラットフォーム: すべて

Oracle HTTP Server、Oracle WebLogic Serverプロキシ・プラグインを使用するWebサーバー、またはOracle Traffic Directorなどのロード・バランサで構成されている、クラスタ化されたOracle WebLogic ServerアプリケーションによってHTTP POSTリクエストが処理される場合、HTTP 503エラーが発生します。停止中のクラスタ化されたOracle WebLogic Server管理対象サーバーにPOSTリクエストが送信された場合に、そのサーバーがそのリクエストを完了できないかそのリクエストの結果が不明な場合、ロード・バランサはHTTP 503エラーを返す必要があります。Oracle Traffic Directorを動的クラスタとともに使用しており、そのクラスタがスケール・ダウンされている場合、Oracle WebLogic Serverは、間もなく起こるサーバー正常停止をOracle Traffic Directorに通知し、リクエストをクラスタ内の残りのサーバーにルーティングしようとします。ただし、一部のHTTPリクエストが503エラーを受信する可能性があるときは、正常停止操作の合間の、Oracle Traffic DirectorがHTTPトラフィックをリダイレクトする前に、短い停止時間がある場合があります。

回避策

なし

構成の問題と回避策

この項では、次の問題と回避策について説明します。

WebLogicドメインの作成時にASProvWorkflowExceptionが発生する

問題

影響を受けるプラットフォーム: すべて

Fusion Middleware製品のインストールを開始する前に既存のJAVA_OPTIONSがインストール環境に含まれている場合、ASProvWorkflowExceptionが原因でドメインが作成されないことがまれにあります。

回避策

Fusion Middleware製品のインストールを開始する前に、既存のJAVA_OPTIONSをクリアします。これらのJAVA_OPTIONSを使用するアプリケーションが環境内にある場合、アプリケーションはオプションをクリアした後で動作しなくなることがあります。この場合は、既存のJAVA_OPTIONSをテキスト・ファイルに保存し、他のアプリケーションを実行するための代替方法を調べます。

英語以外のロケールでWLSTを実行している場合は-Dfile.encodingプロパティを使用する

問題

影響を受けるプラットフォーム: MS Windows

WLSTは、目的のロケールを設定することでローカライズされたメッセージで実行できます。英語以外のロケールでWLSTを実行する場合は、次の問題があることを認識してください。

Windowsオペレーティング・システムで、DOSコマンド・ウィンドウのアクティブ・コード・ページがシステムのローカル(ANSI)コード・ページと異なる場合は、DOSコマンド・ウィンドウを介してWLSTを起動する際に、-Dfile.encoding=<DOS window's active code page>プロパティをWLSTプロセスに追加する必要があります。このプロパティにより、Javaプロセスのデフォルトの文字セットが変更されます。たとえば:

  • DOSウィンドウのアクティブ・コード・ページは850です。この値は、WLSTコマンド・ウィンドウでchcpコマンドを発行することで設定できます。

  • システムのローカル(ANSI)コード・ページは1250です。システムのローカル・コード・ページは、WindowsレジストリでHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NLS\CodePage\ACPキーの値を表示することで確認できます。標準のWindows編集ツール(メモ帳やワードパッドなど)で作成されたファイルは、この方法でエンコードされます。

回避策

この状況では、WLSTを次のように起動できます。

set WLST_PROPERTIES="-Dfile.encoding=cp850"

$WL_HOME%\common\bin\wlst.cmd

Oracle WebLogic Serverのインストール・パスに空白が含まれていると構成ツールが失敗することがある

問題

影響を受けるプラットフォーム: MS Windows

一部のMicrosoft Windowsプラットフォームでは、Oracle WebLogic Serverのインストール・パスに空白が含まれている場合、Oracle WebLogic Server構成ツール・コマンド(wlstconfigpackおよびunpackを含む)が失敗することがあります。この場合、コマンドは、クラスがインストール・パスの空白の後の部分から導出されるjava.lang.ClassNotFoundExceptionエラーで失敗することがあります。Windowsレジストリで短いファイル名の生成が無効になっている場合、コマンドは失敗します。

回避策

構成ツールで空白が正しく処理されるように、Windowsレジストリで短い名前の生成を有効にする必要があります。短い名前の生成を有効にするには:

  1. regeditを実行します。
  2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemフォルダに移動します。
  3. NtfsDisable8dot3NameCreationをダブルクリックし、その値を0に設定します。
  4. 変更を反映するには再起動します。

存在しないサーバー名のディレクトリが作成される

問題

影響を受けるプラットフォーム: すべて

存在しないサーバー名でWebLogic Server管理サーバーに接続しようとすると、存在しないサーバー名のディレクトリがdomain_name/serversディレクトリの下に作成されます。

回避策

管理対象サーバーの起動時に、有効なサーバー名を指定します。

WebLogicパスワードの入力後のターミナル・ウィンドウの異常な動作

問題

影響を受けるプラットフォーム: Linux

WebLogicパスワードの入力直後に[Ctrl]+[C]を押してstartManagedWebLogic.shプロセスを終了した後で、ターミナル・ウィンドウで異常な動作が発生することがあります。たとえば、[Return]を押すと、プロンプトが次の行に移動するかわりにタブ移動し、プロンプトに入力した文字がターミナルに表示されません。

回避策

現在のxtermを終了して新規に開始するか、xtermにstty echoと入力します。

ドメインの作成と更新に長時間かかる

問題

影響を受けるプラットフォーム: Linux

次の場合には、Oracle WebLogic Serverドメインの作成または更新に長時間かかることがあります:

  • 構成ウィザードやWLSTなど、規定されたドメインの作成または更新方法を使用する場合。新しいLinuxホストでこの方法を使用すると、ハングアップしたり、通常よりも大幅に時間がかかることがあります。この問題は、Javaセキュリティを初期化するためのホスト上のエントロピが不足しているために発生します。
  • Oracle WebLogic Server構成ウィザードを使用してドメインを作成または変更する場合。
  • WLSTを使用してドメインを作成または変更する場合。

回避策

CONFIG_JVM_ARGS環境変数を次の値に設定します:

-Djava.security.egd=file:/dev/./urandom

新規ドメインの構成時に「パスワード」フィールドを編集できない

問題

影響を受けるプラットフォーム: Linux

Linuxシステムで、Oracle Fusion Middleware構成ウィザードを使用して新規ドメインを作成する際に、「パスワード」および「パスワードの確認」フィールドを編集できず、ドメインを作成するためのパスワードを入力できないことがあります。

回避策

この問題を回避するには2つの方法があります。

  • 問題が発生するたびに回避するには、構成ウィザードの右上にある「ウィンドウを閉じる」(X)ボタンをクリックします。確認ダイアログで、「いいえ」をクリックして構成ウィザードに戻ります。その後で、ドメインのパスワードを入力および確認できます。

  • この問題を永続的に解決するには:

    1. すべてのscimプロセスを強制終了します。たとえば:

      kill `pgrep scim`

    2. ~/.scim/configファイルを変更(または作成)して、次の行を含めます(大文字と小文字は区別されます):

      /FrontEnd/X11/Dynamic = true

    3. VNCを実行している場合は、VNCサーバーを再起動します。

    4. 構成ウィザードをもう一度実行します。

管理サーバーのメモリー消費量およびJMX通知

問題

影響を受けるプラットフォーム: すべて

ドメイン実行時MBeanサーバーは、ドメイン内のすべての管理対象サーバー実行時MBeanサーバーと通信できる、フェデレーテッドMBeanサーバーです。フェデレーション・アーキテクチャは、問合せの際によいパフォーマンスを示します。ただし、JMX通知がMBeanに追加される場合、ドメイン実行時MBeanサーバーは、多量のメモリーを消費する可能性があります。

JMX通知が使用される場合は、管理サーバーが、ドメイン内のすべての管理対象サーバーで実行されているすべての実行時MBeanサーバーに登録されているすべてのJMXオブジェクト名のコピーを保持する原因となる、2つのケースがあります。

  • WebLogic Serverレベルで、管理対象サーバー停止時のMBean通知の登録解除をシミュレートします。

  • JDK JMXクライアント通知レイヤーにおいてです。

この問題が発生する可能性は、次の両方の条件が存在する場合に増加します。

  • EM Fusion Middleware Controlは、ドメイン実行時MBeanサーバーに通知リスナーを追加するため、大きいドメインを管理するために使用されています。

  • JMX実行時MBeanの数を大幅に増加させるFusion Middleware製品が、ドメインに含まれています。これには、ドメイン内で実行されているWebLogic Server実行時MBeanサーバー・インスタンス(つまり、管理サーバーおよび管理対象サーバー)に登録されているMBeanを持つすべての製品が含まれます。(これらの製品には、Coherence、SOA Suite、OSBなどが含まれます。)

回避策

managed-server-notifications-enabled属性を無効にします。この構成属性は、管理対象サーバー実行時MBeanサーバーに含まれる、MBean上で通知を定義する能力を無効にします(これらのMBeanは、ObjectName内にLocation=keyを含みます)。

管理対象サーバーの通知が無効になっている場合は、WebLogic ServerおよびJDKコンポーネントに含まれるMBeanのためのObjectNameの2つのセットは保持されません。通知リスナーは、MBeanServerDelegate上、およびローカルのドメイン実行時MBeanサーバーに含まれるMBean上でまだ定義できます。ただし、通知リスナーは、非ローカルMBeanには追加できません。

editCustom()MBeanへの変更をロールバックする際の問題

問題

影響を受けるプラットフォーム: すべて

editCustom()ツリーには、上位のスタックおよびシステム・コンポーネント製品のためのMBeanが含まれています。これらのMBeanに変更を行うと、その変更は、保留中のディレクトリにすぐに続きます。これは、明示的な保存が必要な、edit()ツリー内のWebLogic Server MBeanとは異なります。

stopEdit()cancelEdit()を使用するか、開いている編集セッションでWLSTを終了すると、WebLogic Server MBeanへの保存されていない変更はロールバックされます。ただし、editCustom()ツリーへの変更は持続されるため、ロールバックされません。

回避策

undo('y')コマンドを使用して、editCustom() MBeanへのアクティブ化されていない変更をロールバックします。

同一ホスト上での複数の開発サーバー起動の問題

問題

影響を受けるプラットフォーム: すべて

1つのDerbyインスタンスを共有している場合、同一ホスト上で2つの開発サーバーを起動できません。

回避策

1つのDerbyインスタンスを共有するかわりに、それぞれの開発サーバーが一意のDerbyインスタンスを使用するように構成してください。詳細は、『Oracle Service Bus開発者ガイド』独自のDerbyインスタンスによる個々のドメインの実行に関する項を参照してください。

Coherenceキャッシュのオーバーライドが機能しない

問題

影響を受けるプラットフォーム: すべて

ドメインの作成にOracle WebLogic Server構成ウィザード(config.sh)を使用し、WebLogic Coherenceクラスタの拡張テンプレートを指定する場合は、Coherenceクラスタが定義されます。Coherenceクラスタは、任意の管理対象サーバーまたは同様に構成ウィザードで作成したOracle WebLogic Serverクラスタに関連付けられます。管理対象サーバーまたはOracle WebLogic Serverクラスタが作成されていない場合、Coherenceクラスタは管理サーバーに関連付けられます。このCoherenceクラスタとサーバーの関連付けは、Oracle WebLogic Server構成ツールを使用して完全に定義されていないため、Coherenceキャッシュ構成オーバーライド・ファイルがCoherenceクラスタによって検出されません。この問題は、キャッシュ・オーバーライド機能を使用している場合にのみ発生します。

回避策

次の回避策を使用します。

  1. 構成ウィザードで作成したドメインを起動し、WebLogic Server管理コンソールを使用して接続します。
  2. WebLogic Server管理コンソールの左側のペインで「環境」を展開して、「Coherenceクラスタ」を選択します。
  3. 使用するCoherenceクラスタを選択します。そのCoherenceクラスタの設定ページが表示されます。
  4. 「メンバー」タブを選択すると、このCoherenceクラスタのすべてのメンバーが表示されます。
  5. このCoherenceクラスタのメンバーであるサーバーおよびクラスタを選択解除して、「保存」をクリックします。
  6. このCoherenceクラスタのサーバーおよびクラスタとして望ましいメンバーを再選択して、「保存」をクリックします。

この手順によって、Coherenceクラスタとターゲット・サーバー間の完全な関連付けが行われますが、これは指定されたCoherenceクラスタ・キャッシュ構成オーバーライド・ファイルの検索および使用のために必要です。

管理対象サーバーのドメインをテンプレートから作成するとエラーが発生する

問題

影響を受けるプラットフォーム: すべて

管理対象サーバーのドメイン・ディレクトリをテンプレートから作成する際に-managed=trueを指定します。-managed=trueを指定しないと、セキュリティ・ディレクトリ内に正しいファイル・セットがないため、管理対象サーバーの起動に失敗します。

回避策

なし

ドメインを開発モードから本番モードに切り替えても起動スクリプトが変更されない

問題

影響を受けるプラットフォーム: すべて

ドメインを開発モードから本番モードに切り替えると、次のようになります。

  • ドメインの起動スクリプト(および-Xverifyフラグの値)が変更されない。

  • boot.propertiesファイルが引き続き使用される。

回避策

本番モードのドメインで、次のようにします。

  1. 起動スクリプトで-Xverifyフラグの値をnoneからallに変更します。
  2. boot.propetiesファイルを削除します。詳細は、『Oracle WebLogic Serverドメイン構成の理解』開発モードと本番モードに関する項を参照してください。

WLSTスクリプトまたはコマンドの実行時にエラーが発生する

問題

影響を受けるプラットフォーム: すべて

WLSTスクリプトまたはコマンドの実行中に、TypeError: 第1引数はStringに強制変換できませんというエラーが発生します。このエラーは、WLSTクラス名serverがWLSTコマンドで変数名として使用されているために発生します。たとえば、次のコマンドでは、変数serverがクラスロード時にクラス名に置換されるため、このエラーが発生します。

state(server,'Server')

回避策

次のいずれかの回避策を使用します。

  • WLSTの起動時に-Dpython.cachedir.skip=trueパラメータを含めます。
  • 予約済文字列名を別の文字列に変更します。たとえば、文字列名serversrvrに変更すると問題を回避できます。

パーティション・リスナーがMBeanの登録解除通知を受信しないことがある

問題

影響を受けるプラットフォーム: なし

パーティションが通知を受信するよう設定されている場合でも、MBeanがMBeanサーバーから登録解除されたときにパーティション・リスナーが通知を受信しないことがあります。これは、WebLogic Server 12.2.1の現在の実装の制限によるものです。

回避策

現在、この問題に対する既知の回避策はありません。

WL MTパーティション・スコープの構成の変更が無視される

問題

影響を受けるプラットフォーム: なし

既存のRGおよびRGTスコープの非モジュール構成への変更が、パーティションの再起動後も無視される場合があります。リソース・グループ・オーバーライドの変更も無視される場合があります。ただし、データ・ソース・チューニング、JMS宛先、接続ファクトリなどのモジュール・スコープの構成への変更は、この問題の影響を受けません。

WLSTを介した問合せでは変更が正しく表示されますが、サーバー・インスタンス内では古い値の使用が続けられます。

回避策

新しい値が有効になるようサーバーを再起動します。

再ターゲット後リソース・グループが変更を反映しないことがある

問題

影響を受けるプラットフォーム: なし

同じタイプのリソースを含み、同じ名前を持つ2つのリソース・グループ・テンプレートがある場合にこの問題は発生します。

リソース・グループが初め1つのリソース・グループ・テンプレートをターゲットとし、次に2つ目のリソース・グループ・テンプレートをターゲットとして、2つ目のリソース・グループ・テンプレートの共有の名前を持つリソースに変更を加えると、それらの変更が反映されないことがあります。リソース・グループが1つ目のリソース・グループ・テンプレートのリソースの値を使用し続ける場合があります。

回避策

この問題を回避するには、次のいずれかの回避策を使用します。

  • 複数のリソース・グループ・テンプレートで同じ名前のリソースを使用しないようにします。
  • 2つ目のリソース・グループ・テンプレートのリソースに変更を加えた後、新しい値が有効になるようサーバーを再起動します。

明示的なポートおよびポート・オフセットはグローバル仮想ターゲットに対してサポートされない

問題

影響を受けるプラットフォーム: なし

Oracle WebLogic Serverは、仮想ターゲットの明示的なポートおよびポート・オフセットの設定のサポートを提供します。ただし、明示的なポートおよびポート・オフセットの設定は、現在パーティションに割り当てられている仮想ターゲットに対してのみ有効です。グローバル仮想ターゲット(パーティションに割り当てられていない仮想ターゲット)に対しては、明示的なポートおよびポート・オフセットの設定は有効ではありません。

回避策

なし

JMXシン・クライアントの使用に関する制限

問題

影響を受けるプラットフォーム: なし

JDKの最近の変更により、WebLogic ServerでJMXはwlclient.jarファイルのみではサポートされなくなりました。JMXを使用するには、WebLogicフル・クライアント(weblogic.jar)またはwljmxclient.jarファイルを使用する必要があります。

回避策

なし

構成後のピュアIPv6デプロイメントでBI Cluster1が停止している

問題

影響を受けるプラットフォーム: なし

これはピュアIPv6環境で発生します。WLSをインストールしBIを構成した後に、bi_clusterが停止しています。構成ウィザードによるレポートはありません。

回避策

この問題を解決するには:
  1. Oracle WebLogic Server管理コンソールにログインします。
  2. bi_server1を停止します。
  3. bi_cluster1を起動します。
  4. bi_server1を起動します。

ODAクラスタ構成で実行する場合、Oracle WebLogic Serverのデフォルト構成の使用を回避

問題

影響を受けるプラットフォーム: Linux

OracleクラスタがOracle WebLogic Serverと同じサブネットを共有している場合、現在のデフォルトのマルチキャスト・アドレスを使用するとOracle Clusterwareがブロックされます。

回避策

Oracle WebLogic Serverの現在のデフォルト構成設定を使用しないことをお薦めします。この構成では、同じサブネットにあるOracle Clusterwareがブロックされることがあるためです。

SSL経由でOracle Internet DirectoryにアクセスするOracle WebLogic Serverの構成

SSL経由でOracle Internet Directory (OID)にアクセスするOracle WebLogic Serverを構成する場合、OIDサーバー証明書を取得してWebLogicドメインに追加する必要があります。OID証明書は、SSLハンドシェイクを成功させてOracle WebLogic ServerからOracle Internet Directoryへの接続を正常に確立するために必要です。

必要な証明書の取得およびWebLogic Serverストアへの追加の詳細は、『Oracle SOA Suiteエンタープライズ・デプロイメント・ガイド』中間層とハードウェア・ロード・バランサ間のSSL通信の有効化に関する項を参照してください

WLSTオフライン・デフォルトを使用して作成された管理者グループへの未割当てユーザー

問題

影響を受けるプラットフォーム: すべて

WLSTオフラインを使用してドメインを作成し、グループに割り当てられていない複数のユーザーを作成した場合、これらのユーザーはデフォルトで管理者グループに割り当てられます。

回避策

ドメインを作成するときは、1つの管理ユーザーを作成する必要があります。追加のユーザーを作成し、管理者グループに割り当てられないようにする場合は、必ずそれらのユーザーを適切なグループに明示的に割り当てるようにしてください。

コア・サーバーおよびコア・ワーク・マネージャの問題と回避策

この項では、次の問題と回避策について説明します。

IPv6形式のアドレスの使用

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic ServerにIPv6形式のアドレスを使用する場合、URLのホスト・アドレス部分に大カッコ('['および']')を含める必要があります。そうしないと、WLSTは実行中のサーバーに接続できません。

回避策

ホスト・アドレスに大カッコを追加してください。たとえば:

t3://[fe80:0:0:0:203:baff:fe2f:59e5]:9991

サーバー全体を移行した後でサーバーを起動できない

問題

影響を受けるプラットフォーム: すべて

クラスタ・サーバーのサーバー全体がそれまで一度も実行されていないマシンに移行されるときに、Oracle WebLogic Server管理サーバーが停止していると、新しいマシンでサーバーを起動できません。

回避策

この問題には次のいずれかの回避策を使用してください。

  • サーバーの移行の実行中は必ず管理サーバーを稼働させておきます。

  • クラスタ内のすべての移行可能サーバーで共有のディスク/NFSを使用します。

フィールド名を変更した後でオブジェクト状態が保持されない

問題

影響を受けるプラットフォーム: すべて

J2EEアプリケーションでFastSwapを有効にしている場合、デプロイメント中にJavaクラスに対して特定の変更を行うと、再デプロイせずにその変更を確認することができますが、その際、Javaオブジェクトのすべてのインスタンスの状態は保持されます。

オブジェクトの状態が保持されない変更のタイプの1つに、フィールド名の変更があります。フィールド名の変更は次のように処理されます:

  • 古い名前のフィールドが削除されます。

  • 新しい名前のフィールドが追加されます。

この場合、古いフィールドの状態は名前変更されたフィールドに継承されません。

WorkshopまたはFastSwap Antタスクを使用している場合、インスタンス・フィールド名の変更により値がリセットされても、「FastSwap操作は正常に完了しました」というメッセージが表示される場合があります。

回避策

インスタンスの値がリセットされることを踏まえた上でフィールド名を変更してください。

あるホスト名でリスニングするように構成されたサーバーが、起動後に別のホスト名でリスニングする

問題

影響を受けるプラットフォーム: すべて

ホスト名を使用してWebLogic Server管理サーバーまたは管理対象サーバーのリスニング・アドレスの構成を指定する場合、複数のイーサネット・カードで構成されたマシンは、起動後に別のホスト名でリスニングすることがあります。たとえば:

  • マシンに3つのイーサネット・カードがあります。

  • カード1はhostname1-s (DNS登録ホスト名)にマップされています。

  • カード2はhostname1-i (DNS登録ホスト名)にマップされています。

  • カード3はhostname1(実際のノードのホスト名)にマップされています。

  • hostname1でリスニングするようにサーバーを構成します。

  • Windowsは実際のノードのホスト名を最初に有効になったイーサネット・カード・アドレスに解決するため、サーバーは起動後にhostname1-sでリスニングします。

回避策

この問題には次の3つの回避策のいずれかを使用します。

  1. WebLogic Server管理サーバーのリスニング・アドレスとして、ホスト名ではなくIPアドレスを使用します。管理対象サーバーで、IPアドレスをリスニング・アドレスとして使用するか、実際の物理ホスト名をマシンの最初のイーサネット・カードに構成します。
  2. マシンのC:\Windows\system32\drivers\etc\hostsファイルに次のエントリを追加します。

    <ip_address> <hostname>

  3. マシンのネットワーク・カードの順序を変更して、実際のノードのホスト名を持つカードがカード1になるようにします。

管理サーバーまたはノード・マネージャが、管理対象サーバーのステータスを追跡できない

問題

影響を受けるプラットフォーム: Linux

コマンド行から正しくないWebLogic Server管理サーバーURLを指定して管理対象サーバーを起動した場合(つまり、管理サーバーが指定されたURLに到達できない場合)、管理対象サーバーは管理対象サーバー独立(MSI)モードで起動します。

この場合、管理サーバーとノード・マネージャは管理対象サーバーのステータスを追跡できません。WebLogic Server管理コンソールには、管理対象サーバーのステータスがUNKNOWN(不明)と表示されますが、サーバーは実際にはMSIモードでRUNNING(実行中)です。

回避策

なし

ネットワークの分割中またはその後でマルチキャスト・トラフィックの信頼性がなくなる

問題

影響を受けるプラットフォーム: Linux

サーバー移行が行われる原因となったネットワークの分割中またはその後で、マルチキャスト・トラフィックの信頼性がなくなります。たとえば、あるノードはマルチキャスト・トラフィックを受信できますが、このノードから発信されたトラフィックはネットワークの他のノードで受信されません。その結果、移行されたサーバーは、ハートビートが受信されなかったためクラスタに追加されません。

回避策

現在わかっている回避策は、ユニキャスト・クラスタ・メッセージングを使用することだけです。

Java DBリース・スクリプトまたはサポートがない

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Serverでは、移行のためのJava DBをサポートしていません。Java DBのためのWL_HOME/server/dbディレクトリには、使用可能なリース・スクリプトはありません。

回避策

この問題に対する回避策はありません。

外部ロード・バランサでt3プロトコルを使用すると初期接続がオープンしたままになることがある

問題

影響を受けるプラットフォーム: すべて

外部ロード・バランサでt3プロトコルを使用すると、クラスタへのブートストラップで使用されたロード・バランサのIPアドレスに初期接続が関連付けられたままになることがあります。そのため、初期接続後にごく一部のリクエストがロード・バランサを通過する可能性があります。この動作を任意の時点で変更する権限はOracleが保有しているため、この動作が認められる場合は、使用できない実装を使用したことにより悪影響が生じています。

回避策

なし

管理対象サーバーをマルチキャスト・クラスタに追加するとその管理対象サーバーの起動に失敗する

プラットフォーム: すべて

2つ以上の管理対象サーバーを含むクラスタがあり、そのクラスタのメッセージング・モードをマルチキャストに設定すると、クラスタ内の管理対象サーバーの起動に失敗します。

問題

影響を受けるプラットフォーム: すべて

2つ以上の管理対象サーバーを含むクラスタがあり、そのクラスタのメッセージング・モードをマルチキャストに設定すると、クラスタ内の管理対象サーバーの起動に失敗します。

回避策

この問題を回避するには、起動スクリプトstartWebLogic.shJAVA_OPTIONSに次のプロパティを追加します。たとえば:

export JAVA_OPTIONS="${JAVA_OPTIONS} –Djava.net.preferIPv4Stack=true"

アプリケーション・スレッドの数が多いとサーバーがストールすることがある

問題

影響を受けるプラットフォーム: すべて

サーバーJVMがストールし、このJVMのスレッド・ダンプに、ほぼすべてのweblogic.kernel.Defaultスレッドがwait-for-dataまたはwait-for-prepare-acksなどの呼出しでストールしていることが示される場合があります。

回避策

  • サーバーのコマンドラインで-Dweblogic.UseEnhancedIncrementAdvisor=falseシステム・プロパティを指定して、ワーク・マネージャの拡張増分アドバイザを無効にします。
  • 前述の回避策でうまくいかない場合は、次に示された別の回避策を実行してください:
    • FEJmsDispatcherおよびBEJmsDispatcherの最小制約を1、最大制約を6に設定し、Dweblogic.UseEnhancedIncrementAdvisor=falseは保持します。
    • それぞれ使用するスレッドの数が少なくなるようアプリケーションをチューニングします。 たとえば、メッセージドリブンBean(MDB)のスレッド管理関連の例は、Oracle WebLogic ServerのパフォーマンスのチューニングメッセージドリブンBeanのチューニングに関する項を参照してください
    • クラスタ内のすべてのサーバーJVMで-Dweblogic.threadpool.MinPoolSize=NNNプロパティをスレッド・ダンプ内のweblogic.kernel.Defaultスレッドの現在の値より20%高い値に設定します。NNNの回数がわからない場合、100を試して、それでも機能しない場合は150を試す、などしてください。minpoolスレッドをあまりに大きく構成すると、パフォーマンスが非常に低下したり、メモリ不足をも引き起こす可能性があります。
    • 関係するすべてのクラスタ内のすべてのサーバーで、JTACoordinatorWMワーク・マネージャのJTA min-threads-constraintを20または30に設定します。これは、-Dweblogic.transaction.jta.coordinator.wm.min.constraint=YYYシステム・プロパティを使用して設定できます。

@Localアノテーションが付いている場合にリモート・クライアントによってエンタープライズBeanがアクセスされる

問題

影響を受けるプラットフォーム: なし

想定される動作では、Beanクラスに@Localのアノテーションが付いており(または@Local@Remoteも付いていない)、実装されているインタフェースの1つがjava.rmi.Remoteインタフェースを拡張している場合、インタフェースはローカル・クライアントによってのみアクセスされ、リモート・クライアントではアクセスできません。

ただし、12.2.1では@Localのアノテーションが付いている場合に、インタフェースがリモート・クライアントによってアクセスされることがあります。

回避策

EJBへのアクセスをローカル・クライアントのみに制限する場合、EJBの実装で次の両方を避ける必要があります。

  • @Localアノテーションの使用

  • java.rmi.Remoteインタフェースの拡張

リソース消費マネージャ(RCM)が同じ値を使用してトリガーする異なるアクションによって予期される動作

問題

影響を受けるプラットフォーム: なし

低速トリガーと停止トリガーを同じ値に対して作成することができます。同様に、停止値と通知値も作成できます。RCMトリガーの構成時には、WebLogicシステム管理者がこれを手動で検証または回避する必要があります。

回避策

なし

データ・ソースの問題と回避策

この項では、次の問題と回避策について説明します。

ポート番号を指定するとSQL Serverに対するデータ・ソース検証が失敗する

Oracle WebLogic Server 12.2.1以降、ポート番号が接続URLで指定されたSQL Serverの名前付きインスタンスに接続する場合、SQL ServerのDataDirect JDBCドライバが次のエラーを返します:

[FMWGEN][SQLServer JDBC Driver]Conflicting connection information. When the instance name is specified, it is invalid to specify the port number.

データ・ソースがデプロイに失敗します。

回避策

JDBCディスクリプタ・ファイルを更新して、allowPortWithNamedInstanceプロパティをtrueに設定するか、URLからポート番号を削除します。

ポート番号を指定する場合、Oracle WebLogic Server管理コンソールで自動的にURLにallowPortWithNamedInstance=trueプロパティが付加されます。管理者がWLSTスクリプトを更新し、このプロパティをtrueに設定する必要があります。次のURLの例は有効です。

jdbc:weblogic:sqlserver://host\\INSTANCE:1433;DatabaseName=db;allowPortWithNamedInstance=true"
jdbc:weblogic:sqlserver://host:1433;DatabaseName=db"
jdbc:weblogic:sqlserver://host\\INSTANCE;DatabaseName=db"

依存関係インジェクションの問題と回避策

この項では、次の問題と回避策について説明します。

BeanManagerでライフサイクル・イベントにValidatorFactory Beanが含まれない

問題

影響を受けるプラットフォーム: なし

CDI拡張でライフサイクル・イベントAfterBeanDiscoveryまたはAfterDeploymentValidationを監視している場合、javax.validation.ValidatoryFactory Beanインスタンスの取得が失敗します。たとえば:

public class MyExtension implements Extension {
     void checkValidatorFactoryBean(@Observes AfterBeanDiscovery abd, BeanManager bm) {
          Set<Bean<?>> validatorFactoryBeans
          = bm.getBeans(ValidatorFactory.class,
          new AnnotationLiteral<Default>() {});
     if (validatorFactoryBeans.isEmpty()) {
          throw new RuntimeException("Container provided BeanManager doesn't contain a bean of javax.validation.ValidationFactory");
          }
     }
}

前述のサンプル・コードでは、BeanManagerがValidatorFactory Beanインスタンスを取得できないため、RuntimeExceptionが発生します。これは、ValidatorFactoryおよびValidator BeanタイプがCDI 1.1より組込みBeanから削除されたために起こります。CDI 1.1以降、ValidatorFactoryおよびValidator Beanは、org.hibernate.validator.internal.cdi.ValidationExtension拡張によって定義されています。

AfterBeanDiscoveryイベント・オブザーバの起動時に呼び出された場合、このメソッドは、AfterBeanDiscoveryイベントの起動前にコンテナによって検出されたBeanのみ返します。

回避策

なし

CDIが有効なEARとCDIが有効でないWARの組合せは正しく機能しない

問題

影響を受けるプラットフォーム: なし

アプリケーションにCDIが有効なEJBモジュールとCDIが有効でないWebモジュールの両方が含まれている場合、次の修飾子で定義されたイベントは送信されません。

@Initialized(ApplicationScoped.class) and @Destroyed(ApplicationScoped.class)

回避策

WARファイルのWEB-INFディレクトリに空のbeans.xmlファイルを含めます。

12.2.1でのRARのCDI処理の変更

問題

影響を受けるプラットフォーム: なし

Oracle WebLogic ServerのCDI 1.0では、META-INFディレクトリにbeans.xmlファイルがあり、埋込みライブラリJARクラスがそのBeanアーカイブの一部として含まれている場合、RARアーカイブはCDI Beanアーカイブとして処理されます。Oracle WebLogic Server 12.2.1より、各アーカイブ(埋込みライブラリJARを含む)はMETA-inf/beans.xmlファイルまたはBean定義アノテーションを含む1つ以上のクラスの有無に基づいてそれぞれ候補Beanアーカイブと見なされます。

したがって、以前の動作を再現するには、埋込みライブラリJARにMETA-INF/beans.xmlエントリまたはBean定義アノテーションを含む1つ以上のクラスが必要です。

回避策

なし

デプロイメントの問題と回避策

この項では、次の問題と回避策について説明します。

weblogic-application.xmlでsecurity-permission要素を使用できない

問題

影響を受けるプラットフォーム: すべて

security-permission要素は、weblogic.xmlおよびweblogic-ejb-jar.xmlデプロイメント・ディスクリプタで使用できますが、weblogic-application.xmlディスクリプタでは使用できません。したがって、エンタープライズ・アプリケーションでは、EJBまたはWebアプリケーションであるJARファイルにのみセキュリティ・ポリシーを適用できます。

回避策

なし

無関係な文字列値がファイル仕様として解釈される

問題

影響を受けるプラットフォーム: すべて

weblogic.Deployerツールでは、コマンドライン引数間の無意味な文字列値がファイル指定として解釈されます。たとえば、次のコマンドを考えます:

java weblogic.Deployer -activate -nostage true -name myname -source c:\myapp\mymodule

この場合、-nostageオプションは引数をとらないため、trueは無関係な文字列値です。ツールは、trueという名前のファイル仕様をアクティブにしようとします。

回避策

なし

restoreメソッドがプラン・オーバーライドでDConfig Beanを更新しない

問題

影響を受けるプラットフォーム: すべて

restoreメソッドは、DConfig Beanをプラン・オーバーライドで正しく更新しません。たとえば、次のステップを考えてみます:

  DeployableObject dObject =
     WebLogicDeployableObject.createDeployableObject(new File(appName));
  DeploymentConfiguration dConfig =
     WebLogicDeploymentManager.createConfiguration(dObject);
  dConfig.restore(new FileInputStream(new File(plan)));

この場合、プランはDConfig Beanを正しくオーバーライドしません。

回避策

アプリケーションの構成を初期化する際にプランを指定します。たとえば:

    helper = SessionHelper.getInstance(
        SessionHelper.getDisconnectedDeploymentManager());
    helper.setApplication(app);
    helper.setPlan(new File(plan));
    helper.initializeConfiguration();

アプリケーションが別のソース・ファイルの場所を使用してデプロイされている場合、アプリケーションの再デプロイの試行に失敗する

問題

影響を受けるプラットフォーム: Linux

最初にあるソース・ファイルの場所を使用してアプリケーションをデプロイし、ソース・ファイルの新しい場所を使用してアプリケーションを再デプロイしようとした場合、デプロイメントは次の例外で失敗します。

New source location <new_source_file_path> cannot be configured deployed to 
configured application, <application_name>. The application source is at 
original_source_file_path. Changing the source location is not allowed for a 
previously attempted deployment. Try deploying without specifying the source.

これは、Oracle WebLogic Serverのデプロイメント制限が原因です。デプロイメントのソース・ファイルを指定した後、それを再デプロイメントで変更することはできません。

回避策

新しいソース・ファイルの場所を使用して再デプロイを試行する前に、アプリケーションをアンデプロイします。

該当する出力メッセージが表示されない

問題

影響を受けるプラットフォーム: すべて

アプリケーションを作成してターゲットにデプロイし、その後、同じアプリケーションを同じターゲットにデプロイしようとしても、そのターゲットに同じアプリケーションがすでにデプロイされていることを通知する出力メッセージは表示されません。これは、2度目のアプリケーションのデプロイが再デプロイと同等と見なされるために発生します。

回避策

なし

アプリケーション名はドメイン内で一意である必要がある

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server 12.2.1より、指定されたアプリケーション名でドメインにアプリケーションをデプロイする際、そのアプリケーション名が現在のドメインですでに使用されている場合、アプリケーションのデプロイメントは失敗します。

これは以前のOracle WebLogic Serverバージョンから変更された動作で、以前は、同じアプリケーション名を指定すると、指定した名前に基づいてOracle WebLogic Serverが一意の名前を自動的に作成していました。

回避策

アプリケーションのデプロイメントが失敗しないようにするには、ドメイン内のすべてのアプリケーションに一意の名前を指定します。

開発者の操作性の問題と回避策

この項では、次の問題と回避策について説明します。

ユーザーはPub-SubモジュールのためのAppcの使用時にBEA_HOMEシステム・プロパティを設定する必要がある

問題

影響を受けるプラットフォーム: すべて

Maven同期プラグインを使用してOracle WebLogic Server Mavenアーティファクトをローカル・リポジトリにインストールした後、appc Mavenプラグインを使用するとエラーが発生します。

回避策

Oracle WebLogic Serverのpub-subライブラリは、コンパイラ問題の解決をBEA_HOMEシステム・プロパティに依存しています。コンパイルのためにpub-subアプリケーションでappcを実行する際に、BEA_HOMEシステム・プロパティを設定し、これらの依存関係を解決します。

ドメインからドメイン・パーティションへの移行の問題と回避策

この項では、次の問題と回避策について説明します。

同一クラスタを指す移行可能ターゲットを対象とした場合にJDBCストアが統合されない

問題

影響を受けるプラットフォーム: すべて

ドメインのインポート時には、移行可能ターゲットを対象とする、同じクラスタを指しているすべての永続ストアは、配布ポリシーを分散済に設定して単一のエンティティに統合し、仮想ターゲットを介してクラスタをターゲット指定する必要があります。ただし、12.2.1.2.0では、この統合はJDBCストアのために失敗します。

この結果、一部のJDBCストアは、インポート後にどのJMSサーバー、SAFエージェントまたはパス・サービスによっても参照されません。これにより、リソース使用量が増加する可能性があります。

回避策

ドメインのインポート後に、どのJMSサーバー、SAFエージェントおよびパス・サービスにも参照されないJDBCストアを削除します。

MBean名にスラッシュまたはピリオドが含まれる場合にD-PCTエクスポートが失敗する

問題

影響を受けるプラットフォーム: すべて

MBean名に次のいずれかの文字が含まれる場合は、D-PCTを使用してドメインをエクスポートするためにオフラインでWLSTを使用している間に、例外によってソース・ドメインのエクスポートが失敗します。

  • ピリオド(.)

  • スラッシュ( / )

  • バックスラッシュ( \ )

回避策

この問題は、次のいずれかの方法で回避できます。
  1. ソース・ドメインからリソースを削除し、ドメイン・アーカイブをインポートした後にそれを再作成します。

  2. WLSTオフライン・モードで許可されていない文字を削除することで、リソースの名前を変更します。これは、config.xmlおよびその他の構成ファイルを適切に編集することで実行できます。MBean名を変更した後、ソース・ドメインを再起動し、ソース・ドメインをエクスポートする前に構成の変更によって他の問題が起こっていないことを確認します。

EJBに関する問題と回避策

この項では、次の問題と回避策について説明します。

Oracle表の主キーがCHARになる

問題

影響を受けるプラットフォーム: すべて

Oracle表の主キーはCHARですが、SQL表の問合せフィールドはVARCHAR2です。

回避策

データベース・スキーマをCHARからVARCHAR2に変更してください。Oracleデータベースで、主キーとしてCHARを使用することはお薦めできません。

クラスタ化可能なタイマーの作成を有効にするアノテーションがない

問題

影響を受けるプラットフォーム: すべて

EJB3 BeanおよびEjbgenに、クラスタ化可能なタイマーを作成するためのアノテーションがありません。

回避策

weblogic-ejb-jar.xmlファイルを作成し、このファイルに<timer-implementation>要素および対応する値を追加します。

KodoのMappingToolでスキーマを生成できない

問題

影響を受けるプラットフォーム: すべて

Kodoの MappingTool は、主キーでBLOBを使用しているクラスのスキーマを生成することができません。BLOBを主キーに使用することはできますが、スキーマは手動で定義する必要があります。ただし、JDOおよびJPA仕様では、主キーでBLOB列をサポートすることは必須ではありません。

回避策

なし。

JPAメタデータ・モデルに対する拡張はアノテーションを介してのみ指定できる

問題

影響を受けるプラットフォーム: すべて

JPAメタデータ・モデルの拡張は、アノテーションを介してのみ指定可能であり、仕様で定義されているorm.xmlファイルのような構造を使用して指定することはできません。

回避策

オブジェクト・モデルにKodo固有のメタデータを指定するには、次のいずれかを実行します:

  • Kodo固有のアノテーションを使用します。

  • XMLベースのメタデータをJDOメタデータ形式に変換します(拡張のXML仕様はサポートされません)。

ルックアップ・メソッドの注入がSpringでサポートされない

問題

影響を受けるプラットフォーム: すべて

WebLogic Spring注入拡張モデルでは、ルック・アップ・メソッドの注入をサポートしていません。

回避策

なし

管理対象の環境でJDO PersistenceManagerFactoryをデシリアライズするとエラーが発生することがある

問題

影響を受けるプラットフォーム: すべて

管理対象の環境でJDO PersistenceManagerFactoryをデシリアライズするとエラーが発生する可能性があります。例外にはjavax.jdo.PersistenceManagerFactoryClassプロパティがないことが示されています。管理対象の環境では通常、PersistenceManagerFactoryをシリアライズする必要はありません。

回避策

なし。

スキーマの作成時に索引が作成されないことがある

問題

影響を受けるプラットフォーム: すべて

クラス・レベルで宣言された索引は、スキーマの作成時に作成されないことがあります。

回避策

スキーマ生成ツールの実行後に、索引を手動で作成します。

@Idフィールドに@Uniqueアノテーションも付いている場合にOpenJPAが例外をスローする

問題

影響を受けるプラットフォーム: すべて

一部のデータベースで@Idフィールドに@Uniqueアノテーションも付いている場合、OpenJPAが例外をスローします。データベースの主キーは、定義上一意です。一部のデータベースでは、列に対してユニークな索引を作成することで、この性質を実装しています。

回避策

1つのフィールドに対して@Id@Uniqueの両方を指定しないでください。

キャッシュのヒットとミスの数が予想外に増える

問題

影響を受けるプラットフォーム: すべて

バージョン・データのないエンティティを操作すると、キャッシュのヒットとミスの数が予想外に増えることがあります。EntityManagerが閉じられて、含まれているすべてのエントリがデタッチされると、余分なキャッシュ・アクセスが発生します。バージョン・フィールドのないエンティティは、システムからはバージョン・データがないように見え、システムはデタッチ前にそれらのバージョンをキャッシュでチェックすることで応答します。

回避策

バージョン・フィールドまたはその他のバージョン戦略があるエンティティは、余分なキャッシュ・アクセスの原因になりません。

Open JPAは表が存在する場合でも表を作成しようとする

問題

影響を受けるプラットフォーム: すべて

MySQLデータベースを使用している場合、OpenJPAが実行時にマッピング・ツールを自動的に実行してデフォルト・スキーマ内に表を作成するように構成されていると、その表がデータベースに存在していても、表の作成が試行されます。たとえば:

<property name='openjpa.jdbc.SynchronizeMappings' value='buildSchema'/>
<property name='openjpa.jdbc.Schema' value='MySQL database name' />

PersistenceExceptionがスローされ、表がすでに存在し、表の作成文が失敗したことが示されます。

回避策

この問題を回避するには、MySQLデータベースを使用する際に、実行時に自動的にマッピング・ツールを実行して同時にデフォルト・スキーマを指定するようOpenJPAを構成しないでください。

シリアライゼーション中にEJBアプリケーションが失敗する

問題

影響を受けるプラットフォーム: すべて

エンティティが(Externalizableではなく)Serializableであり、writeObject()メソッドを宣言していない場合、IIOPを使用し、JPAエンティティをサーバーからクライアントに送信するEJBアプリケーションで、シリアライゼーション中にエラーが発生します。

回避策

そのようなエンティティ・クラスにはwriteObject()メソッドを追加してください。書込みオブジェクトは次のようになります。

private void
writeObject(java.io.ObjectOutputStream out)
   throws IOException {
  out.defaultWriteObject();
}

IIOPを使用した11g EJBの呼出し時にEJBハンドルのシリアライゼーションが失敗する

問題

影響を受けるプラットフォーム: すべて

Enterprise JavaBeans仕様で説明されているように、リモート・ホーム・インタフェースにより、クライアントは、そのリモート・ホーム・インタフェースのハンドルを取得できます。このハンドルは、シリアル化することや、安定したストレージに書き込むことができます。後で、場合によっては異なるJVMでも、このハンドルを安定したストレージからシリアル化解除することや、リモート・ホーム・インタフェースへの参照を取得するために使用することができます。

ただし、Oracle WebLogic Server 12.2.1(以降)でホストされているサーブレットがIIOPプロトコルを使用して、Oracle WebLogic Server 11gでホストされているEJBのリモート・ホーム・インタフェースを検索し、そのハンドルをファイルにシリアライズしてから、ファイルからハンドルをデシリアライズすると、デシリアライズがClassNotFoundExceptionで失敗することがあります。

この状況は、Oracle WebLogic Server 12.2.1(およびそれ以降)でホストされるEJBをIIOPを使用して呼び出そうとする、Oracle WebLogic Server 11gでホストされるEJBにも当てはまります。

回避策

IIOPのかわりにT3プロトコルを使用します。

リモート・アノテーションで指定したEJB 3.xをWebLogicクライアントでIIOPを使用して検索できない

問題

影響を受けるプラットフォーム: すべて

WebLogic標準クライアント(wlclient.jar)を使用するアプリケーションで、IIOPプロトコルを使用して、@Remoteアノテーションで修飾されたEJB 3.x Beanのリモート・ホーム・インタフェースを検索する場合、検索がClassNotFoundExceptionメッセージで失敗する可能性があります。

回避策

次のいずれかを実行できます。

  • クライアント・クラスパスで、WebLogic標準クライアントwlclient.jarのかわりにWebLogicインストール・クライアントweblogic.jarを使用します。

  • @Remoteアノテーションを使用するかわりにjava.rmi.Remoteインタフェースを拡張することで、EJBのリモート・ホーム・インタフェースを作成します。

HTTP Publish/Subscribeサーバーの問題と回避策

この項では、次の問題と回避策について説明します。

ローカル・クライアントの認証と認可がサポートされない

問題

影響を受けるプラットフォーム: すべて

HTTP Publish/Subscribeサーバーはローカル・クライアントの認証と認可をサポートしていません。ローカル・クライアントにはHTTP Publish/Subscribeサーバーのチャネルを操作する完全な権限があります。つまり、ローカル・クライアントは、チャネルの作成と削除、チャネルからのイベントのパブリッシュとサブスクライブを行えます。

回避策

なし

ローカル・クライアントによってパブリッシュされたイベント・メッセージにフィルタが適用されない

問題

影響を受けるプラットフォーム: すべて

ローカル・クライアントがチャネルにパブリッシュしたイベント・メッセージが、そのチャネルに構成されているメッセージ・フィルタで処理されません。

回避策

なし

インストールおよびパッチの適用の問題と回避策

この項では、次の問題と回避策について説明します。

インストールが致命的なエラーで失敗する

問題

影響を受けるプラットフォーム: すべてのUNIX

インストーラでは、インストールの完了前にマシンに十分なディスク領域があるかどうかは確認されません。そのため、領域不足によりインストールを完了できない場合、次のエラー・メッセージが表示され、インストーラが終了します。

Fatal error encountered during file installation. The installer will now
cleanup and exit!

回避策

この問題が発生した場合、次のコマンドを使用してインストーラを再起動します。

server103_linux32.bin -log=log.out -log_priority=debug

このコマンドによりインストール手順のログが生成され、正確な失敗の原因が詳細に示されます。領域不足が原因であれば、ログ・ファイルにそれが明示的に示されています。

サーバーのFAILED状態によって停止操作時ZDTロールアウトが中止される

問題

影響を受けるプラットフォーム: すべて

ロールアウトの実行時にサーバーを停止中、サーバーがFAILED状態になると、次のエラーが表示されることがあります:

Workflow wf0008 failed and the revert process was not initiated. The failure was: Failure performing execute of wf0008-3-1-0 (ShutdownServerResumeOnRevertCommand), caused by Failed to shut down server server1: java.lang.Exception: The process for the server server1 has not completely shut down. This problem should be reported and you may have to kill the process manually.

このエラーは、WLSTまたは管理コンソールを使用する場合に発生します。

回避策

サーバー・ログを慎重に確認し、停止の失敗につながったサーバーの障害の原因を特定する必要があります。問題を解決し、サーバーを手動で停止した後、ロールアウトを続行できます。

JMSサービスのフェイルバック中にJMS T3スタンドアロン・クライアントが待機する時間が長い

問題

影響を受けるプラットフォーム: なし

ゼロ・ダウンタイム(ZDT)パッチ適用のシナリオでは、進行中のロールアウトにフェイルバック・ケースを含むJMSサービス移行が含まれている場合、JMS T3スタンドアロン・クライアントでJMSサーバーの接続ファクトリおよび宛先オブジェクトに対するJNDIルックアップを実行することができません。

回避策

移行サービスが元のサーバーにフェイルバックする場合、JMSスタンドアロン・クライアントは、JNDIルックアップが正常に行われるまで、予測不能な時間を待機する必要があります。

Java EEの問題と回避策

この項では、次の問題と回避策について説明します。

FastSwapによってフィールドとメソッドのアクセス修飾子が緩和される可能性がある

問題

影響を受けるプラットフォーム: すべて

FastSwapによってフィールドとメソッドのアクセス修飾子が緩和される可能性があります。privateとprotectedのメンバーは実行時にpublicになる可能性があります。この変更によってリフレクションの動作が変わり、Strutsのようなリフレクションに基づくフレームワークが影響を受ける可能性があります。

回避策

なし

FastSwapでエンティティBeanとejbClassの再定義がサポートされない

問題

影響を受けるプラットフォーム: すべて

FastSwapは、エンティティBeanとejbClass(セッション/MDB)の再定義をサポートしません。したがって、エンティティ・クラスを更新すると、再定義エラーが発生します。

回避策

エンティティ・クラスの更新後に、アプリケーションを再デプロイします。

EARファイルに複数のJARがある場合にクラスパス順序が保証されない

問題

影響を受けるプラットフォーム: すべて

個別のJARファイルを含むEARファイルがあり、そのJARファイルの2つ以上に同じ名前のクラスがある場合、Oracle WebLogic ServerがどのJARファイルからクラスをインスタンス化するかは予測できません。これは、クラスが同じ場合には問題になりませんが、異なる実装がある場合には結果を予想できません。

回避策

現在、この問題に対する既知の回避策はありません。

CDIの使用時にFastSwapがサポートされない

問題

影響を受けるプラットフォーム: すべて

CDIの使用時にFastSwapはサポートされません。FastSwapを有効にして展開形式でアプリケーションをデプロイすると、デプロイに失敗し、CDIに関連するエラーが発生します。

回避策

なし

library-directory要素が空の場合ライブラリがロードされない

問題

影響を受けるプラットフォーム: すべて

Java EE 7仕様(https://jcp.org/en/jsr/detail?id=342)に、空のlibrary-directory要素を使用してライブラリ・ディレクトリがないことを示すことができると記されています。

以前のリリースのOracle WebLogic Serverでは、application.xmlファイルに次に示すような空のlibrary-directory要素があると、EARファイルのルート・ディレクトリ内のライブラリJARファイルがライブラリとしてロードされていました:

<library-directory></library-directory>

Oracle WebLogic Server 12c (12.2.1.1)より、この動作は変更され、Java EE 7仕様に準拠するようになりました。現在は、空のlibrary-directory要素がapplication.xmlファイルにある場合、アプリケーションのルート、libディレクトリまたは共有ライブラリからライブラリはロードされません。

ノート:

アプリケーションで空のディレクトリを作成し、library-directory要素でそのディレクトリを指し示すと、libディレクトリからライブラリを削除することなく共有ライブラリからライブラリをロードできます(libディレクトリからはできません)。

回避策

なし

Java EE 6アプリケーションをJava EE 7に移行する場合暗黙的CDIスキャニングを無効にする

問題

影響を受けるプラットフォーム: すべて

既存のアプリケーションをOracle WebLogic Server 12.2.1.1に移行する場合、Java EE 6 (またはそれ以前のJava EEのバージョン)を使用して開発されたアプリケーションのパフォーマンスが、Java EE 7によって必要とされるデフォルトCDIスキャニングの変更によって悪影響を受ける可能性があります。

回避策

以前のバージョンのJava EEで開発されたアプリケーションのパフォーマンスを向上させるには、implicit-bean-discovery-enabledの値をfalseに設定して、Java EE 7での暗黙的CDIスキャニングを無効にします。この値は、次のいずれかの方法で設定できます:

  • Oracle WebLogic Server管理コンソールの使用。「ドメイン一般構成」ページに移動し、「拡張設定」セクションで「暗黙的Bean検出の有効化」を選択解除します。

  • WLSTオンラインまたはオフラインの使用。

    • WLSTオンラインを使用してこの設定を変更するには、次のコマンドを入力します。

      connect('user','password','url')
      domainConfig()
      edit()
      cd('CdiContainer/mydomain')
      startEdit()
      set('ImplicitBeanDiscoveryEnabled',0)  // 1 to enable 0 to disable
      validate()
      save()
      activate(block="true")
      
    • WLSTオフラインを使用してこの設定を変更するには、次のコマンドを入力します。

      readDomain(domain)
      create('mydomain','CdiContainer')
      cd('CdiContainer/mydomain')
      set('ImplicitBeanDiscoveryEnabled',0)
      // 1 to enable 0 to disable
      updateDomain()
      closeDomain()

JDKの問題および回避策

この項では、次の問題と回避策について説明します。

JDK8u301以降を使用した非FIPS準拠のキーストアの変換時のKeytoolエラー

問題

影響を受けるプラットフォーム: すべて

JDKに含まれる、CA証明書を使用したデフォルトのJKSキーストアであるcacertsは、WebLogic Server 12.2.1.3以下ではFIPSに準拠していません。FIPS 140-2には、PKCS12 PBES2キーストアが必要です。Sun JSSEプロバイダ(デフォルト)を使用してキーツールで作成されたJKSキーストアおよびPKCS12キーストアはサポートされていないため、FIPS準拠のキーストアに変換する必要があります。

JDK 8u301以降の変更により、keytoolコマンドを使用して非FIPS準拠のJKSまたはPKCS12キーストアをFIPS準拠のキーストアに変換すると、keytoolは例外をスローし、キーストアは作成されません。このエラーは、-srcprovidernameプロパティをJsafeJCEに設定すると発生します。

回避策

『Oracle WebLogic Serverセキュリティの管理』FIPS 140-2準拠のキーストアの作成に関するトピックには、RSA JCEプロバイダを使用して非FIPS準拠のJKSおよびPKCS12キーストアを変換する手順が示されています。JDK 8u301以降を使用している場合は、keytoolコマンドの-srcprovidername JsafeJCEパラメータを省略します。たとえば:

例2-1 Keytoolコマンド

keytool -importkeystore -srckeystore /u01/jdk/jre/lib/security/cacerts.p12   
-srcstoretype PKCS12
-destkeystore /u01/jdk/jre/lib/security/cacerts.rsa
-deststoretype PKCS12 -destprovidername JsafeJCE
-providerclass com.rsa.jsafe.provider.JsafeJCE 
-providerpath $CLASSPATH

JMSの問題および回避方法

この項では、次の問題と回避策について説明します。

マップされていない接続ファクトリ・リソースの動作の変更

問題

影響を受けるプラットフォーム: すべて

この問題は、JMS接続ファクトリへのリソース参照を含むEJBまたはサーブレットを使用する場合に発生することがあります。つまり、@ResourceアノテーションまたはアプリケーションのXMLディスクリプタに定義されたリソースのコンテキスト・ルックアップを使用して接続ファクトリを取得する場合、およびこのリソース参照がディスクリプタ・ファイルでlookup属性、mappedName属性またはjndi-nameを介して明示的にJNDI名を指定していない場合です。

WebLogic Server 12.2.1以上のリリースでは、Java EE 7 Platform仕様の変更によって、そのようなリソース参照がリソース名と一致するJNDI名の接続ファクトリをJNDIから返すか、javax.naming.NameNotFoundExceptionを返すのではなく、プラットォームのデフォルト接続ファクトリを予期せず返す可能性があります。マップされていない接続ファクトリ・リソースのこの動作の変更によって起こる可能性のある現象の一部を次に示します。

  • アプリケーションはカスタム接続ファクトリを必要としていた可能性があるが、デフォルト接続ファクトリが付与されたことを示すINFOレベルのログ・メッセージ。たとえば、

    BEA-169827> <The resource reference "jms/my_cf" of type JMS Connection Factory in application "my_module" does not specify a JNDI name. As of Java EE 7 and WebLogic version 12.2.1.1, such references return a "java:comp/DefaultJMSConnectionFactory" by default when no Connection Factory with a JNDI name that matches the resource name is found.>
    
  • アプリケーションが、デフォルトのメッセージの有効期限など、カスタム構成されているWL JMS接続ファクトリからの想定されているカスタマイズされた動作の実施を停止します。

  • Illegal Destination typeなどのエラー。これは、AQ JMS宛先をWebLogic JMS接続ファクトリと組み合せて使用しようとすると発生することがあります。

  • Destination not foundDispatcher not foundなどの例外。

  • 意図された接続ファクトリと同じクラスタ内でホストされるJMSサーバーではなく、ローカルJMSサーバーに一時宛先が作成されます。

回避策

アプリケーションが予期したとおりに動作するようにするには、次のいずれかの回避策をとることをお薦めします。

  • WebLogic ServerのJMSConnectionFactoryUnmappedResRefMode構成可能属性をFailSafeモードに設定し、古い動作を強制的に行うようシステムを明示的に構成します。この設定は、Java EE 7ではFailSafeモードにデフォルト設定できないと規定されていますが、Java EE 7仕様に準拠していることに注意してください。詳細は、『Oracle WebLogic Server JMSリソースの管理』接続ファクトリのマップされないリソース参照モードの指定に関する項を参照してください。

  • すべてのサーブレットおよびEJBアプリケーション内のすべてのマップされていないリソース参照を確認し、目的の接続ファクトリを明示的に指定するよう修整します。目的の接続ファクトリがJava EE 7デフォルト接続ファクトリの場合、java:comp/DefaultJMSConnectionFactoryをJNDI名として指定できます。

デプロイメント記述子の検証に失敗する

問題

影響を受けるプラットフォーム: すべて

記述子の検証が有効になっていると、デプロイメント記述子の検証に失敗し、EARファイルにJMSモジュールのみが格納されます。

回避策

EARファイル内にJava EE仕様に準拠したモジュールが少なくとも1つ存在することを確認します。

複数のプロデューサが同じクライアントSAFインスタンスを使用する場合の例外

問題

影響を受けるプラットフォーム: すべて

複数のJMSプロデューサが単一のJVM内で同じJMSクライアントSAFインスタンスを使用している場合、JMS SAFクライアントが作成されるタイミングによっては、次の例外がスローされることがあります。

Error getting GXA resource [Root exception is weblogic.jms.common.JMSException:
weblogic.messaging.kernel.KernelException: Error getting GXA resource]

回避策

複数のJMS SAFクライアント・プロデューサを使用している場合は、各クライアントの新規作成のタイミングを少しずらします。

ストアのファイル名とディレクトリ名でマルチバイト文字がサポートされない

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Serverストアのファイルおよびディレクトリの名前でマルチ・バイト文字はサポートされていません。たとえば、Oracle WebLogic Server名にマルチ・バイト文字が含まれていると、デフォルト・ストアが作成されず、Oracle WebLogic Serverの起動に失敗します。

回避策

パス名にマルチ・バイト文字を含めずにOracle WebLogic Serverインスタンスを作成し、デフォルト・ストア構成にそのパス名を使用します。マルチバイト文字は使用しないでください。

NFSでファイル・ストアを使用している場合にWebLogic Serverのテストが突然失敗する

問題

影響を受けるプラットフォーム: すべて

NFS搭載のディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンが不意に障害したら、サーバーの再起動の動作を検証することをお薦めします。NFS実装に応じて、フェイルオーバー/再起動後、様々な問題が発生する可能性があります。

回避策

なし。

カスタム・ドメイン・テンプレートをアップグレードすると、トピック・メッセージが失われたりサーバー・メモリーが枯渇することがある

問題

回避策

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server 12.1.2以降は、構成ウィザードでのJMSサーバーおよびWebLogicストア・ターゲット指定が変更されています。

12.1.2では、構成ウィザードは、これらのオブジェクトがドメイン・テンプレート内の管理対象サーバーまたはクラスタを明示的に対象にしない場合に、移行可能なターゲットへのJMSサーバーおよびWebLogicストアを自動的に対象とします。移行可能なターゲットの使用は、JMSシステムのための高可用性を可能にするベスト・プラクティスです。

カスタム・ドメイン・テンプレートを使用してOracle WebLogic Server 12.1.2でドメインを作成し、そのテンプレートに、管理対象サーバーまたはクラスタを明示的にターゲット指定していないJMSサーバーおよびWebLogicストアが含まれる場合、ターゲット指定の結果が前のリリースとは異なります。

動作のこの変更により、generate-unique-client-id拡張を可能にするメッセージドリブンbean (MDB)のための永続トピック・サブスクリプションへの変更も生じます。Oracle WebLogic Serverは、このようなMDBに永続トピック・サブスクリプションを作成する際に、移行可能ターゲット名が含まれるようにサブスクリプション名を変更します。元のサブスクリプション名の下に格納されるメッセージは、MDBには配信されません。また、元のサブスクリプションは、新しいメッセージの累積を継続します。

アップグレードの計画時は、次の重要な変化に注意してください。

  • 再構成ウィザードを使用して、構成および永続トピック・サブスクリプションをそのまま維持するように12.1.2より前の既存ドメインを再構成します。手順は、『Oracle WebLogic Serverのアップグレード』WebLogicドメインの再構成に関する項を参照してください。

  • 前述のようにカスタム・テンプレートを使用してドメインを再生成する場合、結果となる構成は前のリリースとは異なり、システムの起動時に新しい永続トピック・サブスクリプションが作成されます。ただし、古い永続トピック・サブスクリプションは残ります。それらのサブスクリプションには、メッセージの累積を継続し、サーバー・メモリーを枯渇させる、未処理のメッセージが含まれます。

次のいずれかの推奨回避策を選択してください。

  • 再構成ウィザードを使用して、ドメインのインプレース・アップグレードを実行します。

  • ドメイン構成をアップグレードまたは再生成する前に、メッセージを排出します。アップグレード後、Oracle WebLogic Server管理コンソールを使用して、古いJMSサブスクリプションを検索して削除します。

  • JMSファイル・ストア・ファイルまたはJMS JDBCストア表を削除します。ファイルまたは表に保持されているすべてのメッセージが削除されます。

既存のJMS .NETクライアントと相互運用するためのシステム・プロパティの設定

問題

影響を受けるプラットフォーム: すべて

12.1.3より前のWebLogic Serverで開発されたJMS .NETクライアントをWebLogic Server 12.1.3と相互運用できるようにするには、WebLogic Server 12.1.3インスタンスで次のシステム・プロパティを設定します。

-Dweblogic.protocol.t3.login.replyWithRel10Content=true

12.1.3より前のWebLogic Serverで開発された既存のJMS .NETクライアントとの相互運用性のデフォルト値はfalseです。

回避策

なし。

JMS分散宛先がドメインを拡張した後に存在しない

プラットフォーム: すべて

問題

影響を受けるプラットフォーム: すべて

JMS分散宛先を含むドメインから生成された拡張テンプレートを使用してドメインを拡張した後、分散宛先がドメインに存在しなくなります。これは次の分散宛先に影響を与えます。

  • distributed-queue

  • distributed-topic

  • uniform-distributed-queue

  • uniform-distributed-topic

これらの要素のいずれかがソース・テンプレートにあるJMS XMLファイルに含まれている場合、これらは処理されず、宛先ドメインでは構成されません。

回避策

これを解決するには、WLSTコマンドの次のシーケンスを対話的にまたはスクリプトで使用します。

readDomain('domain_path')

addTemplate('extension_template_file') 

unassign('JmsSystemResource','resource_name','Target','destination_name') 
For example: unassign('JmsSystemResource','JMSModule','Target','C1')

assign('JmsSystemResource','resource_name','Target','destination_name')
For example: assign('JmsSystemResource','testModule','Target','Server-1')

unassign('JmsSystemResource','resource_name','Target','destination_name')
For example: unassign('JmsSystemResource','testModule','Target','Server-1')

assign('JmsSystemResource','resource_name','Target','destination_name')For example: assign('JmsSystemResource','testModule','Target','C1')

updateDomain()

closeDomain()

JMSメッセージング・ブリッジの外部プロバイダとしてJBoss 5を使用すると問題が発生する

問題

影響を受けるプラットフォーム: すべて

JBoss 5を外部プロバイダとして使用してJMSメッセージング・ブリッジを作成すると、同じクラスの競合するバージョンがロードされます。これによって起動時にブリッジが失敗します。

回避策

この問題を回避するには、JBoss 7にアップグレードすることをお薦めします。

JTAの問題および回避方法

この項では、次の問題と回避策について説明します。

トランザクション・プロトコルの変更によってトランザクション結果が矛盾する

問題

影響を受けるプラットフォーム: すべて

データ・ソースのトランザクション・プロトコルが変更された場合、トランザクションの結果が矛盾しないようすべてのターゲット・サーバーを再起動する必要があります。

回避策

なし

ライフサイクル管理の問題と回避策

この項では、次の問題と回避策について説明します。

ドメインのアンパック後ライフサイクル構成プラグイン・パスが更新されない場合がある

問題

影響を受けるプラットフォーム: すべて

ある環境でライフサイクル・マネージャを使用するよう構成されたドメインをpackコマンドを使用してパックし、別の環境でアンパックした場合、<Domain>/config/lifecycle-config.xmlファイルに含まれているプラグインのパスがソース環境のOracleホーム・ディレクトリのパスを参照したままになることがあります。

回避策

lifecycle-config.xmlファイル内のファイル・パスを修正して、ターゲット環境のOracleホーム・ディレクトリ・パスを反映します。

リソース・グループの変更でOracle Traffic Directorが更新されない

問題

影響を受けるプラットフォーム: すべて

Oracle Weblogic Server、Oracle Traffic Director (OTD)およびライフサイクル・マネージャを含む統合環境で、ライフサイクル・マネージャのアウト・オブ・バンド機能が有効な場合、想定では、ドメイン・パーティションにターゲットを絞った変更を含むリソース・グループ内の変更は、ライフサイクル・マネージャを使用してOTDに送信されるはずです。しかし、12.2.1よりこの動作は変更され、リソース・グループの追加または削除を含むリソース・グループに対する更新はOTDに送信されません。

回避策

対象の構成の変更後ドメイン・パーティションを再起動する必要があります。このステップにより、リソース・グループで最新の構成の変更によってOTDが更新されます。

ライフサイクル例外が発生しパーティションを作成できない

問題

影響を受けるプラットフォーム: Windows

ライフサイクル例外が発生するため、日本語の名前の仮想ターゲットを使用するパーティションは作成できません。これはWindowsプラットフォームでのみ発生します。

回避策

仮想ターゲットとして英語の名前を使用するパーティションは正常に作成されます。

モニタリングの問題と回避策

この項では、次の問題と回避策について説明します。

曖昧な監視ルールのObjectNameパターンに関する問題

問題

影響を受けるプラットフォーム: すべて

カスタムMBean ObjectNameパターンと一致する、監視ルール式のための変数でワイルドカード・パターンを指定する場合は、パターンが十分に明示的であることを確認してください。MBeanタイプ名を除外して、曖昧なインスタンス・パターンを使用する場合は、次のことが起こる可能性があります。

  • WebLogic Server実行時MBeanインスタンスのみがパターンに一致します。

  • 必要なカスタムMBeanインスタンスが無視されます。

たとえば、次のObjectNameパターンは、タイプを明示的に宣言せず、WebLogic Server実行時MBeanインスタンスと一致する可能性がある曖昧なObjectNameパターンを使用します。

${ServerRuntime//com.b*:Type=Server*,*}

回避策

混乱を避けるため、十分に明示的なObjectNameパターンを使用するか、変数式でMBeanタイプを宣言します。

CreateSystemResourceControlの動作変更

問題

影響を受けるプラットフォーム: すべて

この問題は、WebLogic診断フレームワーク(WLDF)でのハーベスタ・レコードおよびウォッチ・ルール通知に対するモジュール名の使用方法が変更されたことに関連しています。内部ディスクリプタ名はオーバーライドされ、外部WLDFディスクリプタがランタイム・コントロールAPIまたはWLSTの機能を通じて登録されるときに付けられる名前を使用するようになりました。これは、外部WLDFシステム・リソースをデプロイしてハーベスタ・メトリックを収集したり、デプロイ済のモジュールに基づいてウォッチ・ルール通知をリスニングしたりする際に、ランタイム・コントロール機能を使用している場合に発生します。

たとえば、デプロイ済のディスクリプタのハーベスタ要素とウォッチ要素が次のようであるとします:

<harvester>
   <name>MyExternalResource</name>
...
<watch-notification>
   <name>MyExternalResource></name>
...

また、このディスクリプタをcreateSystemControl("resource1", ...)としてランタイム・コントロールに登録したとします。この場合、以前のハーベスタ・レコードは、このリソースのアーカイブに含まれるハーベスタ・レコードのWLDFMODULE列値にMyExternalResourceを使用して記録されていました。また、これはウォッチ通知ペイロードのモジュール名にも使用されていました。今後は、ハーベスタ・レコードおよびウォッチと通知のペイロードのWLDFMODULE名にresource1が使用されるようになります。

回避策

WLSTコマンドcreateSystemResourceControl()を使用する際に、外部WLDFリソースを登録した名前を使用します。また、外部リソースからのウォッチ通知に使用する通知リスナーが通知ペイロードのWLDFモジュール名に依存している場合は、コントロールを登録したときの名前で検索する必要があります。

たとえば、コントロールをcreateSystemResourceControl("resource1", ...),のように登録した場合は、このリソースのWLDF Accessor問合せの問合せ文字列にWLDFMODULE='resource1'というモジュール名を含める必要があります。

アップグレード・アシスタントを使用してWLDFスキーマのEBRアップグレードを行うと、WLDFアーカイブへの書込みでエラーが発生する可能性がある

問題

影響を受けるプラットフォーム: すべて

Oracle EBRのエディション・スキーマを使用するようにサーバーのWLDFアーカイブをドメインで構成してから、アップグレード・アシスタントを使用してそのスキーマをアップグレードしようとすると、アップグレードの実行中にまだそのスキーマで実行しているサーバーでエラーが発生する可能性があります。

該当する条件は次のとおりです。

  • 12.1.2のリポジトリ作成ユーティリティ(RCU)を使用してWLDFスキーマがOracle EBRデータベースにインストールされている場合、または以前のバージョンのOracle WebLogic Serverから手動で作成されたWLDFスキーマがある場合。

  • アップグレード・アシスタントを使用する際に、既存のスキーマをアップグレードしてOracle EBRのエディション表を使用するように選択した場合

  • アップグレードの実行中に、稼動中のサーバーがある場合(スキーマを複数のOracle WebLogic Serverドメインで共有している場合など)。

アップグレード時に、WLDFの表は名前変更され、名前変更されたインスタンスを指すようにエディションベースのビューが作成されます。この操作で失われるデータはありません。ただしこの場合、ごく短い時間ではありますが、エラーが起り得る時間があります。それは、アップグレードの実行中に稼動中のサーバーでWLDFのハーベスタ・データやインストゥルメンテーション・データが記録されるときです。

これらのエラーはクリティカルではなく、サーバーのパフォーマンスに影響するものではありませんが、それらのサーバーで少量のモニタリング・データが失われる可能性があります。

回避策

このようなエラーの可能性を回避するには、Oracle Databaseのアップグレード・プロセスの間、該当するWebLogic Serverドメインを停止しておきます。

ノード・マネージャの問題と回避策

この項では、次の問題と回避策について説明します。

プライマリ・インタフェースの削除がサーバーの移行時にエラーを引き起こす

問題

影響を受けるプラットフォーム: Linux

一部の特定のLinuxプラットフォームおよびバージョンでは、仮想インタフェース/エイリアスを動的に削除する問題があります。インタフェースのプライマリ・アドレスである仮想インタフェースの削除は、同時に他のセカンダリ仮想IPアドレスの削除をもたらす可能性があります。これは、サーバーの移行時にノード・マネージャでのランダムな例外を引き起こす可能性があります。この問題が発生した場合は、移行後にサーバーを停止する際に、ノード・マネージャのログ・ファイルで例外が検出されることがあります。たとえば、次のようなエラーを受け取る場合があります。

java.io.IOException: コマンド '/<PATH to DOMAIN>/bin/server_migration/wlsifconfig.sh -removeif -IPv4 eth0 X.X.X.Xが失敗出口コード'1'を返しました

ここに問題の例を示します。

最初に、3つの仮想インタフェースを追加します(最初の1つがプライマリになります)。

$ sudo /sbin/ifconfig eth0:4 X.X.X.178 netmask 255.255.248.0
$ sudo /sbin/ifconfig eth0:5 X.X.X.179 netmask 255.255.248.0
$ sudo /sbin/ifconfig eth0:6 X.X.X.180 netmask 255.255.248.0
$ sudo /sbin/ifconfig eth0:4 down

プライマリ(リスト内の最初の1つ)を削除すると、他の2つは、同時に自動的に削除されます。

回避策

この問題を一時的に修正するには、次のコマンドを使用して、ネットワーク・インタフェース上でpromote_secondariesフラグを有効にします。eth0を実際のインタフェース名に置き換えます。

$ sudo /sbin/sysctl net.ipv4.conf.eth0.promote_secondaries=1

また、次のコマンドを使用して、すべてのインタフェースのデフォルト設定を更新することもできます。

$ sudo /sbin/sysctl net.ipv4.conf.all.promote_secondaries=1

これが有効になっており、インタフェースのプライマリ・アドレスが削除される場合は、セカンダリ・インタフェースが、プライマリ・インタフェースになるようアップグレードされます。デフォルトでは、プライマリ・インタフェースの削除時にはすべてのセカンダリ・インタフェースがパージされます。

サーバーの再起動後にこの問題を永久的に処置するには、sysctl.confファイルを更新します。たとえば:

$ echo "net.ipv4.conf.eth0.promote_secondaries=1" >> /etc/sysctl.conf

Javaコマンドを使用してサーバーを起動する際にノード・マネージャが-D64を示さない

問題

影響を受けるプラットフォーム: HPUX IA64

起動スクリプトを使用してサーバーを起動するノード・マネージャとJavaコマンドを使用してサーバーを起動するノード・マネージャの間には基本的な違いがあります。起動スクリプトを使用する場合は、プラットフォームを検出する一部のスクリプト言語に基づいて-d64フラグが追加されます。Javaコマンドを使用してサーバーを起動する場合、ノード・マネージャはこのフラグを追加しません。

回避策

ノード・マネージャを使用してJavaコマンドを介してサーバーを起動する場合は、ServerStart引数フィールドで-d64などの引数を指定します。

Oracle HTTP ServerのインスタンスがUNKNOWN状態で開始する

問題

影響を受けるプラットフォーム: すべて

まれなケースでは、WebLogic Serverによって管理されるOracle HTTP Server (OHS)インスタンスが、状態UNKNOWNで開始される場合があります。これは、管理サーバーがOHSインスタンスの状態を初期化できない場合に起こる可能性があります。たとえば、OHSインスタンスの作成時にノード・マネージャが実行されていない場合や、ノード・マネージャに直接接続しており、最初に状態を確認する際に管理サーバーをバイパスする場合などです。

回避策

管理サーバーの使用を続行します。OHSインスタンスの状態が正しく初期化される必要があります。

installNodeMgrSrv.cmdでOPSSのテンプレート情報が欠落している

問題

影響を受けるプラットフォーム: MS Windows

installNodeMgrSvc.cmdを使用してノード・マネージャを起動する際に必要なOPSSのテンプレート情報が欠落しています。そのため、JRF/OPSS環境でinstallNodeMgrSvc.cmdを正しく使用できません。ノード・マネージャは、KSSをロードするための正しいクラスが指定された情報を使用せずに起動し、デフォルト・キーストアとしてJKSを使用します。この問題は、環境を設定して最初にstartNodeManager.cmd (KSSをロードします)を実行するときに発生します。

回避策

installNodeMgrSvc.cmdコマンドを使用する前に、startNodeManager.cmdからセクションをコピーして編集します。たとえば:

set JAVA_OPTIONS=%JAVA_OPTIONS%
-Doracle.security.jps.config=C:\OracleHome11g\user_projects\domains\mydomain\config\fmwconfig\jps-config-jse.xml
-Dcommon.components.home=C:\OracleHome1213\Oracle_Home\oracle_common -Dopss.version=12.1.3
if NOT "%POST_CLASSPATH%"=="" (set POST_CLASSPATH=C:\OracleHome1213\Oracle_Home\oracle_common\modules\oracle.jps_12.1.3\jps-manifest.jar;%POST_CLASSPATH%)
else (set POST_CLASSPATH=C:\OracleHome1213\Oracle_Home\oracle_common\modules\oracle.jps_12.1.3\jps-manifest.jar)

新しいノード・マネージャのプロパティ名がWLSTオフラインから使用できない

問題

影響を受けるプラットフォーム: すべて

WLSTオフライン、およびpackおよびunpackコマンドは、WebLogicサーバー12.1.3で導入された次の新しいノード・マネージャの置換プロパティの設定をサポートしていません。

非推奨になったプロパティ 置換プロパティ

CipherSuite

CipherSuites

CoherenceStartScriptEnabled

coherence.StartScriptEnabled

CoherenceStartScriptName

coherence.StartScriptName

IfConfigDir

weblogic.IfConfigDir

JavaHome

WebLogic Serverプロセスの場合はweblogic.startup.JavaHome、Coherenceプロセスの場合はcoherence.startup.JavaHomeを使用してください。

StartScriptEnabled

weblogic.StartScriptEnabled

StartScriptName

weblogic.StartScriptName

StopScriptEnabled

weblogic.StopScriptEnabled

StopScriptName

weblogic.StopScriptName

UseMACBroadcast

weblogic.UseMACBroadcast

回避策

WLSTオフライン、またはpackおよびunpackコマンドを使用してノード・マネージャのプロパティを構成した場合、前述の非推奨のプロパティを使用し続ける必要があります。これらは、WebLogicサーバーでまだ完全にサポートされています。詳細は、『Oracle WebLogic Serverノード・マネージャの管理』ノード・マネージャのプロパティに関する項を参照してください。

Oracle Kodoの問題と回避策

この項では、Oracle Kodoの次の問題と回避策について説明します。

空のバイト配列フィールドに対して取得した値がNULLになる

問題

影響を受けるプラットフォーム: MS Windows 2000

エンティティ内の空のバイト配列フィールドをSybaseまたはOracleデータベースに永続化しようとすると、値がバイトではなくNULLとして格納されます。その結果、値を取得したときにNULLが返されます。

これはSybaseおよびOracleドライバの制限であり、データベースに格納するときに空のバイト配列がNULLに変換されます。この問題はWebLogic JDBCドライバとSybaseおよびOracle独自のドライバで発生します。

回避策

なし

プラグインの問題と回避策

この項では、次の問題と回避策について説明します。

IIS用プロキシ・プラグインを使用している場合にapr_socket_connection例外が発生する

問題

影響を受けるプラットフォーム: すべて

IIS用プロキシ・プラグインは次の状況では動作せず、apr_socket_connectionエラーが発生します:

  1. IISとOracle WebLogic Serverの両方のインスタンスが同じマシンにある場合。
  2. マシンでIPv6が有効になっていて、マシンがIPv6環境にない場合(つまり、IPv6インタフェースが有効になっているが動作していない場合)。
  3. Oracle WebLogic Serverインスタンスのリスニング・アドレスが単純なホスト名に設定されている場合。
  4. ディレクティブWebLogicHostまたはWebLogicClusterがIISインスタンスに対して単純なホスト名に設定されている場合。

回避策

なし

RMI-IIOPの問題および回避策

この項では、次の問題と回避策について説明します。

EJBの起動に失敗した場合、切り捨てられたJava例外スタック・トレースがクライアントに返される

問題

影響を受けるプラットフォーム: すべて

本番モードで実行するように構成されたWebLogic 12.1.2ドメインでホストされるEJBをクライアントで起動すると、起動エラーが発生した場合に、切り捨てられたJava例外スタック・トレースがクライアントに返されます。

回避策

WebLogic Serverを起動するJavaコマンドで、次のオプションを指定します。

-Dweblogic.PrintStackTraceInProduction=true

セキュリティの問題と回避策

この項では、次の問題と回避策について説明します。

StoreBootIdentityは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ動作する

問題

影響を受けるプラットフォーム: すべて

-Dweblogic.system.StoreBootIdentityオプションは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能します。このディレクトリは通常、構成ウィザードまたはアップグレード・ツールによって作成されます。

ただし、ソース・コントロール・システムにチェック・インしているドメインでは、この適切なサーバー・セキュリティ・ディレクトリがない場合があります。

回避策

なし

SecurityServiceExceptionでブート時のエラーが発生する

問題

影響を受けるプラットフォーム: すべて

WebLogic Server提供のDB2ドライバを使用してDB2データベース用のRDBMSセキュリティ・データ・ストアが構成されている場合、WebLogic ServerインスタンスでSecurityServiceExceptionにより起動時エラーが発生することがあります。

回避策

RDBMSセキュリティ・データ・ストアでDB2データベース用にAlternateId接続プロパティを使用している場合は、WebLogic Server提供のDB2ドライバを使用するときに、追加のプロパティBatchPerformanceWorkaroundtrueに設定する必要もあります。

InvalidParameterExceptionメッセージが生成および表示される

問題

影響を受けるプラットフォーム: すべて

SAML 2.0のIDプロバイダまたはサービス・プロバイダを構成した後で、SAML 2.0サービス・メタデータ・ファイルを公開しようとすると、InvalidParameterExceptionメッセージが生成されてWebLogic Server管理コンソールに表示される可能性があります。

回避策

WebLogic ServerインスタンスでSAML 2.0フェデレーション・サービスを構成する場合は、構成するSAMLロールで使用可能なすべてのバインディング・タイプを有効にしてください。たとえば、SAML 2.0 IDプロバイダ・サービスを構成する場合は、POST、リダイレクト、およびアーティファクト・バインディングを有効にする必要があります。SAML 2.0サービス・プロバイダ・サービスを構成する場合は、POSTおよびアーティファクト・バインディングを有効にする必要があります。また、優先バインディングを選択することもできます。

SAML 2.0サービス・プロバイダ・サービスで認証とパッシブ属性の両方を有効にするのは無効な構成である

問題

影響を受けるプラットフォーム: すべて

SAML 2.0サービス・プロバイダ・サービスを構成する場合、強制認証とパッシブ属性の両方を有効にすると、WebLogic Serverが検出できない無効な構成となります。これらの属性がどちらも有効な場合に非認証ユーザーがサービス・プロバイダ・サイトでホストされるリソースにアクセスしようとすると、例外が生成され、シングル・サインオン・セッションが失敗します。

WebLogic ServerではSAMLログアウトがサポートされないため、「強制認証」属性の効果がない点に注意してください。ユーザーがIDプロバイダ・サイトですでに認証され、「強制認証」が有効な場合でも、そのユーザーは、IDプロバイダ・サイトで再認証が強制されることはありません。

これらの両方の属性を有効にすることは避けてください。

回避策

なし

非フォーク対象VMでのWebLogicフル・クライアントの実行

問題

影響を受けるプラットフォーム: すべて

fork=true属性が設定されていないAntスクリプトから起動した<java>タスクを使用するなど、WebLogicフル・クライアントが非フォーク対象VMで実行されている場合、次のエラーが発生する可能性があります。

java.lang.SecurityException: The provider self-integrity check failed.

このエラーは、RSA Crypto-Jライブラリの読込み時に自動的に実行される自己整合性チェックによって発生します。(Crypto-Jライブラリとcryptoj.jarは、wlfullclient.jarマニフェスト・クラスパスにあります。)

この自己整合性チェック・エラーは、次に示す状況のような、クライアントが非フォーク対象VMで起動され、Crypto-J APIを直接または間接的に使用する場合に発生します。

  • クライアントがCrypto-Jライブラリを直接起動します。

  • クライアントが、基盤となるクライアントSSL実装をトリガーしてCrypto-J APIを起動するT3S接続を試行する場合。

自己整合性チェックが失敗した場合、Crypto-J APIの以降の呼び出しが失敗します。

回避策

Antスクリプトから呼び出された<java>タスクでフル・クライアントを実行している場合は、fork属性を常にtrueに設定します。

自己整合性チェックの詳細は、次のURLにある『Java(tm) Cryptography Architectureでのプロバイダの実装方法』のプロバイダによる自己整合性チェックの実行方法に関する項を参照してください:

http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#integritycheck

不十分なエントロピのマシンで乱数ジェネレータが低速になることがある

問題

影響を受けるプラットフォーム: Linux

予測不能な乱数を生成するために、SSLセキュリティ・コードはマシンの「エントロピ」に依存します。エントロピは、マウスの移動、ディスクIO、ネットワーク・トラフィックなどのアクティビティです。エントロピが最小であるか存在しない場合、乱数ジェネレータは低速になり、セキュリティ操作がタイムアウトになることがあります。これにより、セキュアな管理者チャネルを使用したドメインでの管理対象サーバーの起動などのアクティビティが混乱することがあります。この問題は、一般に起動後の一定期間に発生します。JVMで十分なエントロピが実現された後は、乱数ジェネレータがマシンの存続期間を通して十分に動作します。

詳細は、次の場所でSunバグ6202721および6521844を参照してください。

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6202721

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6521844

回避策

低エントロピ・システムで、非ブロック乱数ジェネレータを使用できます。そのためには、Javaプロセスを起動するコマンドに-Djava.security.egd=file:///dev/urandomスイッチまたはfile://dev/./urandomを追加します。

オプションで、次のようにLinuxシステムのエントロピ・レベルを上げることができます。
  • 最初に、現在のレベルを決定します
    cat/proc/sys/kernel/random/entropy_avail 
  • 値が500未満の場合は、より多くのエントロピが存在するようにシステムを構成する必要があります。
    rngd -r /dev/urandom -o /dev/random -b -W 2048 
    これによりサイズが2048に達するまでエントロピ・プールにビットが追加されます。

BEA-090402メッセージの追加情報

問題

影響を受けるプラットフォーム: すべて

BEA-090402メッセージは、サーバー・インスタンスがboot.propertiesファイルの問題で起動に失敗した場合の対処法を示すカタログ・メッセージです。

しかし、問題の本質は認証の問題にあります。BEA-090402は、最も可能性の高い根本原因を示します: 顧客がboot.propertiesファイルまたはブート・ユーザー・パスワードを変更しました。このため、認証は失敗します。

このエラーは、ごくまれに別の原因でも発生します。たとえば、LDAPの破損やディスクの故障が発生した場合や、管理対象サーバーが管理サーバーへの接続に失敗し、期限切れのローカルLDAPの認証にフォールバックする場合などです。これらの原因はBEA-090402では触れられていません。資格証明に問題のないことが明らかな場合は、これらの頻度の低い原因のいずれかをBEA-090402が示している可能性があります。

回避策

なし

LDAPオーセンティケータのログ・メッセージに誤ったURLが表示される

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server LDAP認証プロバイダのログ・メッセージに、getConnectionメソッドで返されたLDAP接続のURLが表示されますが、そのURLは正しくありません。Oracle WebLogic Serverプロバイダの構成でSSLを指定していない場合でも、getConnectionのメッセージはSSLが使用されていることを示します。

回避策

ログ・ファイルの「Connecting to host」メッセージは、SSLが使用されているかどうかを正しく示します。たとえば、

  • <Connecting to host=somehost, port=3060>

  • <Connecting to host=somehost, ssl port=3060>

ODI管理対象サーバーの起動時にセキュリティ・エラーが発生する

問題

影響を受けるプラットフォーム: すべて

ODI管理対象サーバーの起動時に、その管理対象サーバーの起動に使用したアイデンティティがWebLogic Sever管理者ロールに正しくマップされず、セキュリティ・エラーが発生します。管理対象サーバーの起動時にこの警告が発生すると、管理対象サーバーの組込みLDAPファイルによって管理サーバーのポリシーの再同期化が行われます。

回避策

管理対象サーバーのフォルダ<domain>/…/data/ldap/ldapfilesにある組込みLDAPファイルを削除して、管理対象サーバーを再起動します。

ノート:

管理サーバーのLDAPファイルにはセキュリティ・プロバイダのプライマリ・データが含まれているため、管理サーバーから組込みLDAPファイルを削除しないでください。

SSOに対するWebLogic SAMLサポートはセキュリティ・レルム再起動を使用する場合サポートされない

問題

影響を受けるプラットフォーム: すべて

WebブラウザおよびHTTPクライアントを使用したシングル・サインオンに対するSAMLの使用は、自動レルム再起動の場合サポートされていません。

ただし、Webサービスを使用した場合のSAMLの使用は、これらの機能に対して完全にサポートされています。

回避策

なし

互換性レルム・ドメインはWebLogic 12.2.1.1クライアントでサポートされない

問題

影響を受けるプラットフォーム: すべて

WebLogic Serverバージョン12.2.1.1で、互換性レルムを含む互換性セキュリティのサポートは削除されました。互換性セキュリティおよび互換性レルムの詳細は、『Oracle WebLogic Serverセキュリティの管理』互換性セキュリティとはに関する項を参照してください。

6.xレルムはWebLogic Serverバージョン9.0 (2006年11月)で非推奨になりました。レルム・アダプタ・セキュリティ・プロバイダおよび6.xレルム構成要素を使用して構成されたWebLogicドメインは、WebLogic Server 12.2.1.1でサポートされなくなりました。WebLogic Server 12.2.1.1で削除され、サポートされなくなった特定の互換性セキュリティおよび6.xレルム・コンポーネントについては、『Oracle WebLogic Serverの新機能』削除された機能に関する項を参照してください。

さらに、WebLogic Server 12.2.1.1クライアントまたはクライアントとして機能するサーバーは、ターゲット・ドメインが互換性レルムを使用して構成されている場合サーバーで起動できなくなりました。そのような起動でClassNotFoundException (RealmAdapterUser)が発生し、起動が失敗します。

WebLogic Server 12.2.1.1と以前のリリースのサーバー間の相互運用性は、互換性レルムが構成されていない場合サポートされます。『Oracle WebLogic Serverの理解』プロトコルの互換性に関する項を参照してください。

回避策

なし

ドメインのアップグレード後にパーティションの作成が失敗する

問題

影響を受けるプラットフォーム: すべて

WebLogic Server 12.2.1.1で、デフォルトの認可およびデフォルトのロール・マッピングが変更されました。ロール・マッピングはアイデンティティ・ドメインを含むよう変更されました。たとえば、WebLogic Sever管理者ロールのデフォルト・ロール・マッピングは、アイデンティティ・ドメインをサポートするためにグループ(管理者)からAdminIDDGroup(管理者)に変更されました。

ドメインのアップグレード後にドメインにパーティションを作成しようとすると、パーティションの作成が失敗します。これは、ドメインが検証され、各セキュリティ・レルムに新しいポリシーおよび述部が含まれているかチェックされるためです。アップグレードしたドメインには12.2.1より前のリリースで作成されたセキュリティ・レルムが含まれており、新しいポリシーは含まれていません。したがって、検証が失敗し、パーティションの作成が失敗します。

回避策

ドメインのアップグレード後、次のタスクを実行する必要があります。

  1. 新しいセキュリティ・レルムを作成し、新しいレルムをデフォルト・レルムに設定します。
  2. 古いセキュリティ・レルムを削除します。

新規セキュリティ・レルムの作成または既存のセキュリティ・レルムの削除の詳細は、Oracle Fusion Middleware Oracle WebLogic Server管理コンソール・オンライン・ヘルプセキュリティ・レルムの管理に関する項を参照してください。

システム・コンポーネント・アーキテクチャ(SCA)の問題と回避策

この項では、次の問題と回避策について説明します。

ドメイン・パーティションでSCAはサポートされない

問題

影響を受けるプラットフォーム: すべて

SCAコンテナは、ドメイン・パーティションで使用するよう更新されていません。パーティションでSCAを使用した場合、動作は不定です。SCAアプリケーションを実行する必要がある場合、ドメインにドメイン・パーティションを追加しないでください。

回避策

なし

アップグレードの問題と回避策

この項では、次の問題と回避策について説明します。

12.2.1.4.0へのローリング・アップグレード中にクラスタ・メッセージングを許可するようweblogic.upgradeExpirationDateを設定

問題

以前のバージョンからWebLogic Serverバージョン12.2.1.4.0へのローリング・アップグレードに失敗しました。

回避策

12.2.1.4.0では、WebLogic Serverクラスタのメッセージングが強化されました。クラスタ内のすべてのサーバーで同じインストール・バージョンのWebLogic Serverが実行されている場合は、変更は必要ありません。12.2.1.3.0から12.2.1.4.0へのローリング・アップグレードを実行するには、古いプロトコルを一時的に許可するように、新しい12.2.1.4.0サーバーを明示的に設定する必要があります。システム・プロパティweblogic.upgradeExpirationDateに有効期限を設定することで、12.2.1.4.0サーバーは、その有効期限日が切れるまでクラスタでの通信を許可します。たとえば、-Dweblogic.upgradeExpirationDate=2020-01-05T08:47です。長期間にわたってバージョンが異なるクラスタ間で通信していると予想される場合、値を将来のアップグレード日付に設定する必要があります。

再構成ウィザードでドメイン・バージョンが12.2.1.4.0ではなく12.2.1.3.0と表示される

問題

影響を受けるプラットフォーム: すべて

再構成ウィザードを実行してWebLogic Server 10.3.6ドメインを12.2.1.4.0にアップグレードする際、「再構成サマリー」ページで、テンプレートはドメイン・バージョンを12.2.1.4.0ではなく12.2.1.3.0と表示します。

回避策

これはGUIのエラーであり、無視しても問題ありません。

Webアプリケーションの問題と回避策

この項では、次の問題と回避策について説明します。

WebブラウザでMaxPostSizeExceededExceptionが報告される

問題

影響を受けるプラットフォーム: すべて

12.1.2より前のWebLogic Serverバージョンからアプリケーションをアップグレードした後に、WebブラウザでMaxPostSizeExceededExceptionが報告されます。

回避策

max-save-post-size session-descriptorを、FORM認証の間にコンテナによって保存またはバッファされるPOSTの最大サイズ(バイト)に設定します。

管理コンソールはセッション・タイムアウトの変更を実装できない

問題

影響を受けるプラットフォーム: すべて

web.xmlファイルでsession-timeoutが構成されている場合、WebLogic Server管理コンソールを使用してsession-timeoutに対して行った変更は反映されません。

回避策

デプロイメント・プランを使用して、session-timeout設定をオーバーライドします。

PoolLimitSQLExceptionエラーが発生するとデータベース接続が不安定になる

問題

影響を受けるプラットフォーム: すべて

JDBC永続性セッション中にPoolLimitSQLExceptionエラーが発生した場合、データベースへの接続が不安定になり、リカバリあり、またはリカバリなしで失敗することがあります。これにより、セッション・データが失われます。古いセッションまたはnullが返されます。

回避策

回避策はありません。

SSLポートを使用してアクセスした場合にWebページを開けない

問題

影響を受けるプラットフォーム: すべて

SSLポートを使用してWebページにアクセスしている場合、ページを開けず、次のエラーがレポートされます:

Secure Connection Failed 
 
An error occurred during a connection to <hostname>. 
 
You have received an invalid certificate. Please contact the server 
administrator or email correspondent and give them the following information: 
 
Your certificate contains the same serial number as another certificate 
issued by the certificate authority. Please get a new certificate containing a unique serial number.

回避策

Firefoxでは次の回避策を使用できます。

このエラーを受信し、自己署名証明書のあるWebページにアクセスしようとしている場合は、Firefoxで次のステップを実行します。

  1. 「Tools」に移動し、「Options」を選択して「Advanced」をクリックし、「Encryption」タブを選択して「View Certificates」をクリックします。
  2. 「サーバー証明書」タブで、証明書を削除します。
  3. 「Authorities」タブで、問題の原因となったセキュリティ・デバイスの認証局(CA)を探して削除します。

Internet Explorerまたはその他のWebブラウザを使用している場合は、表示される警告ページを無視し、Webページに進むことができます。

Internet Explorer 7でSVGファイルの出力を表示できない

問題

影響を受けるプラットフォーム: MS Windows

ページがScalar Vector Graphicsを使用してデプロイされ、Internet Explorer 7 (IE7)を使用してアクセスされる場合、ページのグラフィック・コンテンツのかわりにソースが表示されます。この状況は、標準モードとosjp.nextモードの両方で発生します。

回避策

SVGグラフィックはIE7でネイティブにサポートされないため、アプリケーション開発者は、アプリケーションでSVGグラフィックを使用しないようにする必要があります。使用している場合は、次のような警告を追加する必要があります。

All current browsers, with the exception of Internet Explorer, support SVG 
files. Internet Explorer requires a plug-in to display SVG files. The plug-ins 
are available for free, for example, the Adobe SVG Viewer at 
http://www.adobe.com/svg/viewer/install/.

デプロイメント・プランを使用して2つのディスクリプタをオーバーライドできない

問題

影響を受けるプラットフォーム: すべて

デプロイメント・プランを使用して、WebアプリケーションまたはWebモジュールのデプロイメント時にWEB-INF/classes/META-INF/persistence.xmlおよびWEB-INF/classes/META-INF/persistence-configuration.xmlの2つのディスクリプタをオーバーライドすることはできません。それ以外の場合は、デプロイメント・プランを使用して記述子をオーバーライドできます。

回避策

WEB-INF/classes/META-INF/persistence.xmlおよびWEB-INF/classes/META-INF/persistence-configuration.xml (存在する場合)を、関連するクラス・ファイルとともに単一のJARファイルにパッケージします。このJARファイルは、WebアプリケーションまたはWebモジュールのWEB-INF/libディレクトリに配置してください。このようなJARファイルであれば、デプロイメント・プランを使用して2つの記述子をオーバーライドできます。

Springの依存関係インジェクションはJSPタグ・ハンドラでサポートされない

問題

影響を受けるプラットフォーム: すべて

Spring拡張モデルが有効になっている場合、Oracle WebLogic Server 10.3以降では、パフォーマンス上の理由から、JSPタグ・ハンドラでSpring依存関係インジェクション(DI)がサポートされません。

現在、Oracle WebLogic Serverでは、ほとんどのWebコンポーネントでSpring DIがサポートされています。たとえば、サーブレット、フィルタ、リスナーなどです。ただし、パフォーマンス上の理由から、現在、Spring DIはJSPタグ・ハンドラではサポートされていません。

回避策

回避策はありません。

有効なセッションIDでアプリケーションにアクセスしたときに503エラーが発生する

問題

影響を受けるプラットフォーム: すべて

セッションが永続化され、サーブレット・コンテキストの古いバージョンがリタイアされる場合に、有効なsessionidでアプリケーションにアクセスすると、503エラーが発生します。

たとえば、バージョン管理されているWebアプリケーションのセッション永続タイプが'file'であると、ユーザーはアプリケーションに正常にアクセスできます。その後、このアプリケーションのバージョン2が再デプロイされ、バージョン1はリタイアされます。同じユーザーがアプリケーションにアクセスすると、503エラーが発生します。

回避策

回避策はありません。

jdbc-connection-timeout-secsを構成するアプリケーションがデプロイに失敗する

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server 12.1.2以降は、weblogic.xmlデプロイメント・ディスクリプタ内のjdbc-connection-timeout-secs要素はなくなりました。jdbc-connection-timeout-secsを構成するアプリケーションは、Oracle WebLogic Server 12.1.2サーバー・インスタンスでデプロイに失敗し、サーバー・ログで次のエラーになります:

Unable to load descriptor /.../WEB-INF/weblogic.xml of module myweb. The error is weblogic.descriptor.DescriptorException: VALIDATION PROBLEMS WERE FOUND 
  <6:7> problem: cvc-complex-type.2.4a: Expected elements 'timeout-secs@http://xmlns.oracle.com/weblogic/weblogic-web-app ...' instead of 'jdbc-connection-timeout-secs@http://xmlns.oracle.com/weblogic/weblogic-web-app' here in element session-descriptor@http://xmlns.oracle.com/weblogic/weblogic-web-app

回避策

weblogic.xmlデプロイメント記述子からjdbc-connection-timeout-secs要素を削除します。

HttpServletRequest getLocaleメソッドおよびgetLocalesメソッドの変更点

問題

影響を受けるプラットフォーム: すべて

HttpServletRequest getLocaleメソッドとgetLocalesメソッドでWebLogic Serverの言語タグを取得する際のデフォルトの動作が変更されました。12.1.3より前は、getLocaleメソッドとgetLocalesメソッドは、RFC3066に従って言語タグを返していました。12.1.3からは、これらのメソッドはRFC5646に従って言語コードを返します。

回避策

RFC3066に従って言語コードを取得する場合は、weblogic.xmlファイルのcontainer-descriptorlangtag-revision要素を3066に設定する必要があります。たとえば:

<container-descriptor>
	  <langtag-revision>3066</langtag-revision>
</container-descriptor>

システム・プロパティ-Dweblogic.servlet.langtagRevisionでもロケール解析メカニズムを指定できます。ただし、langtag-revisionに値を設定すると、その値で-Dweblogic.servlet.langtagRevisionの設定がオーバーライドされます。詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』langtag-revisionに関する項を参照してください。

WebSocket: 4MB以上のメッセージをサーバーで受信できない

問題

影響を受けるプラットフォーム: すべて

Tyrusのメッセージ・フレーム・サイズには、大容量の受信メッセージを回避するための制限があります。デフォルト値は4MBです。

回避策

この値はサーブレット・コンテキスト・パラメータで構成できます。WebLogic Serverでは、weblogic.websocket.tyrus.incoming-buffer-sizeパラメータに該当し、次のように編集できます。

<context-param>
   <param-name>weblogic.websocket.tyrus.incoming-buffer-size</param-name>
   <param-value>value_to_tune</param-value>
</context-param>

デフォルトJSPエンコーディングがUTF-8に変更された

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server 12.1.3より、JSPページに対するweblogic.xml内のjsp-descriptor要素のencoding要素のデフォルト値は、UTF-8です。Oracle WebLogic Server 12.1.3より前は、JSPエンコーディングのデフォルト値はISO-8859-1でした。

回避策

ISO-8859-1jsp-descriptor要素のエンコーディング値として指定するには、input-charset要素のjava-charset-name要素をISO-8859-1に構成します。これらの要素の詳細は、『Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発』weblogic.xmlデプロイメント・ディスクリプタの要素に関する項を参照してください。

バージョン2.5より前のJSFベースのWebアプリケーションに対してアノテーションはサポートされない

問題

影響を受けるプラットフォーム: すべて

12.2.1.1より、Oracle WebLogic Serverは、Webアプリケーションのデプロイメント・ディスクリプタweb.xmlのバージョンが2.5以降に設定されたJSFベースのWebアプリケーションに対してアノテーション付きカスタム・タグをサポートしません。

回避策

バージョンが2.5以前に設定されたWebアプリケーションとの互換性のために、Webアプリケーションのデプロイメント・ディスクリプタweb.xmlのバージョンを3.2にアップグレードすることをお薦めします。

たとえば、既存のWebアプリケーションでバージョンが2.3に設定されている場合、次の例に示すように3.2にアップグレードする必要があります:

<?xml version = '1.0' encoding = 'windows-1252'?>
<web-app xmlns="xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="xmlns.jcp.org/xml/ns/javaee
xmlns.jcp.org/xml/ns/javaee/web-app_3_2.xsd"
         version="3.2">
   ...
</web-app> 

WebLogic Server Scripting Tool (WLST)の問題と回避策

この項では、次の問題と回避策について説明します。

特定の文字を含むプロパティ名はloadPropertiesでサポートされない

問題

影響を受けるプラットフォーム: すべて

WLSTのloadPropertiesコマンドで、名前に「.」(ピリオド)が含まれているプロパティのロードがサポートされていません。たとえば、プロパティ・ファイル内にmyapp.db.defaultという名前のプロパティが存在すると、WLSTから次のような名前例外がスローされます。

  Problem invoking WLST - Traceback (innermost last):
    File "<iostream>", line 7, in ?
    File "<iostream>", line 4, in readCustomProperty
  NameError: myapp

これは、PythonおよびloadPropertiesコマンドのシステム制限です。WLSTでは、変数の名前と値を読み込み、それらをPythonインタプリタの変数として設定します。Pythonインタプリタでは、ネームスペース、パッケージ、またはその両方の命名において、モジュールのスコープ指定を示すデリミタとして「.」が使用されています。したがって、前述のプロパティ・ファイルの場合、myapp.db.default.version=9imyapp.db.defaultパッケージに含まれていることを示しますが、そのようなパッケージは存在しないためエラーになります。このパッケージは存在しません。

回避策

変数名にピリオドを使用しないようにしてください。これにより、プロパティ・ファイルから変数をロードし、WLSTスクリプトでそれらを参照できるようになります。ネームスペースの区切り文字としては、「_」(アンダースコア)や英字の大文字/小文字などを使用できます。

別の方法としては、プロパティ・ファイルから変数を設定することも可能です。スクリプト内で変数を使用すると、それらの変数はプロパティ・ファイルからの実際の値に置き換えられます。たとえば:

myapp.py
var1=10
var2=20
import myapp
print myapp.var1
10
print myapp.var2
20

この方法は、1レベルのネームスペース(myapp.var1myapp.var2)であれば機能します。同じ名前をネームスペースとして共有する最上位の変数(myapp=oraclemyapp.var1=10など)では機能しません。myapp変数を設定すると、myappネームスペースはオーバーライドされます。

複数のレベルが必要な場合は、ディレクトリを使用してパッケージ・ネームスペースを定義できます。vars.pyファイルで、次のようにmyapp/db/defaultディレクトリを作成します。

var1=10
var2=20

そして、次のようにインポートします。

import myapp.db.default.vars
print myapp.db.default.vars.var1
10

サブディレクトリに__init__.pyファイルを追加する必要がある場合もあります。パッケージの詳細については、次のPythonドキュメントを参照してください。

https://docs.python.org/3/tutorial/index.html

Jythonによって作成された無効なcachedirはWLSTがエラーを出力する原因となる

問題

影響を受けるプラットフォーム: すべて

Jython 2.2によって作成されたデフォルトのcachedirは有効なディレクトリではありません。weblogic.jarからJythonを直接使用している場合、WLSTはエラーを出力します。

回避策

この問題には、2つの回避策があります。

  • WLSTを呼び出す場合は、-Dpython.cachedir=<valid_directory>パラメータを指定します。

  • weblogic.jarに含まれている部分的なJythonを使用するかわりにJython 2.2.1を別途インストールします。

WLSTエラー・メッセージをヨーロッパ言語ロケールで表示できない

問題

影響を受けるプラットフォーム: すべて

ヨーロッパ言語ロケールでは、WLSTを使用したときに、メッセージに一重引用符が含まれていると構文エラーが発生します。

回避策

なし

Webサーバー・プラグインの問題と回避策

この項では、次の問題について説明します。

MOD_WLS_OHSがフェイル・オーバーしない

問題

影響を受けるプラットフォーム: すべて

現在、mod_wlmod_wl_ohsは、コンテナ・レベルのフェイルオーバーのみサポートし、アプリケーション・レベルのフェイルオーバーはサポートしません。mod_wl_ohsは、管理対象サーバーが起動し、実行されているかぎり、ダウンしているアプリケーションにリクエストをルーティングし続けます。クラスタ化されている場合、リクエストは、アプリケーションが停止している場合でも元のセッションが開始したコンテナに送信されるため、通常はhttpエラー404が発生します。

回避策

なし

WebサービスおよびXMLの問題と回避策

この項では、次の問題と回避策について説明します。

スパース配列と部分転送配列はサポートされない

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Serverでは、JAX-RPC 1.1仕様で要求されているスパース配列と部分転送配列がサポートされません。

回避策

なし

WSDLコンパイラはシリアライズ可能なデータ型を生成しない

問題

影響を受けるプラットフォーム: すべて

Webサービス記述言語(WSDL)のコンパイラでシリアライズ可能なデータ型が生成されないため、データがリモートのEJBに渡されない、またはJMS宛先に格納されません。

回避策

なし

コールバックでのカスタム例外の使用

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Serverでは、親Webサービスのターゲット・ネームスペースと一致しないパッケージを持つカスタム例外を、コールバックで使用することはできません。

回避策

コールバックで使用されるカスタム例外が、親Webサービスのターゲット・ネームスペースと一致するパッケージに含まれていることを確認してください。

プロキシ・サーバーも使用している環境ではJMSトランスポートを使用できない

問題

影響を受けるプラットフォーム: すべて

プロキシ・サーバーを使用している環境では、JMS転送を使用できません。その理由は、JMSトランスポートの場合、Webサービス・クライアントは常にT3プロトコルを使用してWebサービスに接続し、プロキシ・サーバーはHTTP/HTTPSのみを受け入れるためです。

回避策

なし

WSDLの処理中にclientgenに失敗する

問題

影響を受けるプラットフォーム: すべて

複合タイプhttp://www.w3.org/2001/XMLSchema{schema}をWebサービス・パラメータとして使用するWSDLを処理しているときに、clientgenが失敗します。

回避策

なし

JWSコールバックで2次元XMLオブジェクトを使用している場合のIllegalArgumentException

問題

影響を受けるプラットフォーム: すべて

JWSコールバックで2次元のXmlObjectパラメータ(XmlObject[][])を使用すると、IllegalArgumentExceptionエラーが発生します。

回避策

回避策はありません。

SoapElement[]を使用すると空の配列になる

問題

影響を受けるプラットフォーム: すべて

@WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE)でWebサービス・パラメータとしてSoapElement[]を使用すると、クライアントで常に空の配列が生成されます。

回避策

SOAPElement[]のデフォルト・バインディングをWildcardParticle.ANYTYPEに変更する際に、@WildcardBindingアノテーションを使用しないようにしてください。SOAPElement[]のデフォルト・バインディングがWildcardParticle.ANYに設定されます。

Webサービスが別のWebサービスを呼び出す場合のFileNotFound例外

問題

影響を受けるプラットフォーム: すべて

Webサービス'A'からWebサービス'B'を呼び出す場合には、Webサービス'A'で@ServiceClientアノテーションを使用する必要があります。Webサービス'B'がWebサービス'B'のWSDLにアタッチされていないカスタム・ポリシー・ファイルを必要とする場合、Webサービス'A'は実行に失敗します。Webサービス'A'はこのポリシー・ファイルを/Web-Inf/classes/policies/filename.xmlで検索します。ポリシー・ファイルがその場所に存在しないため、Oracle WebLogic Serverではファイルが見つからないという例外がスローされます。

回避策

WebサービスBにカスタム・ポリシー・ファイルを添付してください。次に例を示します。

@Policy(uri="CustomPolicy.xml",
        attachToWsdl=true)
public class B {
  ...
}

クライアント側がサーバー・レスポンス・メッセージのシグネチャの検証に失敗する

問題

影響を受けるプラットフォーム: すべて

セキュリティ・ポリシーに以下のいずれかのトークン・アサーションが含まれている場合、クライアント側でサーバーのレスポンス・メッセージの署名の検証に失敗する可能性があります。

  <sp:WssX509PkiPathV1Token11/>
  <sp:WssX509Pkcs7Token11/>
  <sp:WssX509PkiPathV1Token10/>
  <sp:WssX509Pkcs7Token10/>

また、<sp:WssX509Pkcs7Token11/>または<sp:WssX509Pkcs7Token10/>トークン・アサーションのX509証明書のチェーンに3つ以上の証明書が存在する場合、サーバー側で受信メッセージの署名の検証に失敗する可能性があります。

証明書チェーン全体がクライアント側に残っていなければ、次のようなポリシーはサポートされません。

<sp:AsymmetricBinding>
   <wsp:Policy>
      <sp:InitiatorToken>
         <wsp:Policy>
            <sp:X509Token
               sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>

            <wsp:Policy>
               <sp:WssX509Pkcs7Token11/>
            </wsp:Policy>
         </sp:X509Token>
      </wsp:Policy>
      </sp:InitiatorToken>
      <sp:RecipientToken>
      <wsp:Policy>
      <sp:X509Token sp:IncludeToken='. . ./IncludeToken/Never'>
            <wsp:Policy>
               <sp:WssX509Pkcs7Token11/>
            </wsp:Policy>
         </sp:X509Token>
      </wsp:Policy>
      </sp:RecipientToken>
   . . .
      </wsp:Policy>
   </sp:AsymmetricBinding>

回避策

次のいずれかの解決策を使用します:

  1. WssX509PkiPathV1Token11/>のかわりに<sp:WssX509V3Token10/>トークン・アサーションを使用してレスポンスを構成します。ポリシーは次のようになります。
    <sp:AsymmetricBinding>
       <wsp:Policy>
         <sp:InitiatorToken>
            <wsp:Policy>
            <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
               <wsp:Policy>
                  WssX509PkiPathV1Token11/> 
               </wsp:Policy>
            </sp:X509Token>
            </wsp:Policy>
         </sp:InitiatorToken>
         <sp:RecipientToken>
            <wsp:Policy> sp:IncludeToken='. . ./IncludeToken/Never'>
            <sp:X509Token
               <wsp:Policy>
                  <sp:WssX509V3Token10/>
               </wsp:Policy>
            </sp:X509Token>
            </wsp:Policy>
         </sp:RecipientToken>
    . . .
         </wsp:Policy>
       </sp:AsymmetricBinding>
    
  2. WssX509PkiPathV1Token11/>トークン・アサーションを使用してレスポンスを構成しますが、それをメッセージ内に含めます。ポリシーは次のようになります。
     <sp:AsymmetricBinding>
       <wsp:Policy>
         <sp:InitiatorToken>
            <wsp:Policy>
            <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
            <wsp:Policy>
               WssX509PkiPathV1Token11/> 
            </wsp:Policy>
            </sp:X509Token>
         </wsp:Policy>
         </sp:InitiatorToken>
         <sp:RecipientToken>
            <wsp:Policy>
            <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToInitiator'>
               <wsp:Policy>
                  WssX509PkiPathV1Token11/>
                </wsp:Policy>
            </sp:X509Token>
            </wsp:Policy>
         </sp:RecipientToken>
     . . .
       </wsp:Policy>
     </sp:AsymmetricBinding>
    

X509証明書チェーンに複数の証明書が存在する場合は、<sp:WssX509Pkcs7Token11/>または<sp:WssX509Pkcs7Token10/>のかわりに、<sp:WssX509PkiPathV1Token11/>または<sp:WssX509PkiPathV1Token10/>を使用する必要があります。

xmlcatalog要素エンティティをリモート・ファイルやアーカイブ内のファイルにできない

問題

影響を受けるプラットフォーム: すべて

build.xmlファイルのxmlcatalog要素では、エンティティの場所がローカル・ファイル・システム上のファイルである必要があります。リモート・ファイル(http:など)やアーカイブ内のファイル(jar:など)は使用できません。

回避策

必要であれば、リモート要素をカタログ・ファイル内のエンティティとして定義します。

ローカルxmlcatalog要素が正常に動作しない

問題

影響を受けるプラットフォーム: すべて

ローカルのxmlcatalog要素がAntの制限のために正しく機能しません。

回避策

Antのbuild.xmlファイルで、ローカル要素をclientgen(wsdlc)タスクより上に定義するか(同じターゲットの場合)、要素をターゲットの外部に定義する必要があります。

clientgenのxmlcatalog要素で外部カタログ・ファイルを使用できない

問題

影響を受けるプラットフォーム: すべて

clientgenタスクのxmlcatalog要素で外部カタログ・ファイルを使用できません。たとえば、次のAntビルド・ファイルのスニペットは機能しません:

<clientgen ...
  <xmlcatalog>
    <catalogpath>
      <pathelement location='wsdlcatalog.xml'/>
    </catalogpath>
  </xmlcatalog>

これはAnt XMLカタログの制限です。

回避策

リソースの場所は、インラインで、または1つ以上の外部カタログ・ファイルに(あるいはその両方で)指定できます。外部カタログ・ファイルを使用するには、xml-commonsリゾルバ・ライブラリ(resolver.jar)がクラスパスに存在している必要があります。外部カタログ・ファイルの形式はプレーン・テキストまたはXMLです。xml-commonsリゾルバ・ライブラリがクラスパスで見つからない場合、<catalogpath>パスで指定された外部カタログ・ファイルは無視されて、警告がログに記録されます。ただし、この場合、インライン・エントリの処理は正常に行われます。

現在、インラインで指定できるのは<dtd>要素と<entity>要素のみです。これらはそれぞれ、OASISカタログ・エントリ・タイプのPUBLICとURIに対応しています。

サーバー・ログにJAX-RSエラー・メッセージが記録されている場合がある

問題

影響を受けるプラットフォーム: すべて

JAX-RSアプリケーションが実行されているOracle WebLogic Serverインスタンスを停止すると、サーバー・ログに次のエラー・メッセージが記録されていることがあります:

<Error>
<org.glassfish.jersey.server.internal.monitoring.MonitoringStatisticsProcessor
> <BEA-000000> <Exception thrown when provider class 
org.glassfish.jersey.server.internal.monitoring.MonitoringFeature$StatisticsLi
stener was processing MonitoringStatistics. Removing provider from further
processing. ...

回避策

このエラー・メッセージは無視してかまいません。

JAX-RPC拡張テンプレートを使用した場合、複数ターゲット用のSAFエージェントのクローニングがサポートされない

問題

影響を受けるプラットフォーム: すべて

複数のターゲットを持つドメインをJAX-RPC拡張テンプレートを使用して拡張する場合、CIE処理で複数のターゲット用のSAFエージェントのクローニングはサポートされません。SAFエージェントの各インスタンスは、単一ターゲットに割り当てられます。

回避策

複数のターゲットに追加のSAFエージェントを作成するには、WLSTを使用する必要があります。ただし、SAFエージェントの各インスタンスは、1つのターゲットにのみターゲット指定できます。次の例では、ドメインdomain1用にSAFエージェントを作成し、2つのターゲット・クラスタを含めます。

readDomain('domain1')
cd('/')
create('ReliableWseeSAFAgent1','SAFAgent')
create('ReliableWseeSAFAgent2','SAFAgent')
assign('SAFAgent','ReliableWseeSAFAgent1','Target','SenderCluster')
assign('SAFAgent','ReliableWseeSAFAgent2','Target','ReceiverCluster')
wlsuOfflineUpdateWLSDomain() 

weblogic.wsee.jaxws.spi.ClientIdentityRegistryでスレッド・デッドロックが検出されたため、サーバーが警告状態になる

問題

影響を受けるプラットフォーム: すべて

weblogic.wsee.jaxws.spi.ClientIdentityRegistryのスタック・スレッドのため、管理対象サーバーは次のエラーでWarning状態になります:

Deadlock detected:
Thread 23:
wait to aquire: weblogic.wsee.jaxws.spi.ClientInstancePool.dispose: _poolLock.writeLock().lock();
aquired: weblogic.wsee.jaxws.spi.ClientIdentityRegistry.unregisterClientIdentity: _clientRegistryInternalLock.writeLock().lock();
Thread 28:
wait to aquire: weblogic.wsee.jaxws.spi.ClientIdentityRegistry.getClientInfo: _clientRegistryInternalLock.readLock().lock();
aquired: weblogic.wsee.jaxws.spi.ClientInstancePool.release: _poolLock.writeLock().lock();

回避策

パッチ30965440: HOGGING THREADS CAUSE MANAGED SERVER WARNING AND USERS NOT ABLE TO LOG INTO APPをダウンロードして適用します。このパッチはMy Oracle Support (https://support.oracle.com/)からダウンロードできます。

WebLogic Tuxedo Connectorの問題と回避策

この項では、次の問題と回避策について説明します。

VIEWクラスは接続ごとには設定されない

問題

影響を受けるプラットフォーム: すべて

VIEWクラスは接続ごとには設定されません。

2つのアプリケーションが、定義は異なるが同じVIEW名を持つVIEWクラスをそれぞれ指定した場合、WebLogic Tuxedo Connectorの共有ハッシュ表は、サーバーで予期しない動作を引き起こすことがあります。Resourceセクション用のハッシュ表に加えて、その接続におけるVIEWクラス用のハッシュ表を用意する必要があります。

回避策

すべてのWebLogic Workshopアプリケーションで定義されている全VIEWクラスに一貫性を持たせます。つまり、同じVIEWクラスを表す場合にのみ同じVIEW名を用いるようにします。

ドキュメントの変更

この項では、次のドキュメントの訂正箇所について説明します:

java.netリンクの変更

問題

影響を受けるプラットフォーム: すべて

java.netサイトはクローズしました。java.netにこれまでホストされていたほとんどのオープン・ソース・プロジェクトは移転しました。https://javaee.github.ioを参照してください。その他の質問または問題点については、java_administrator_grp@oracle.comにご連絡ください。

回避策

なし

サンプル・ビューアの「検索」機能に関する問題

問題

影響を受けるプラットフォーム: すべて

Windowsの「スタート」メニューからサンプル・ドキュメントにアクセス(「Oracle WebLogic」を選択し、「WebLogic Server」をクリックして「例」を選択し、「ドキュメント」をクリック)すると、サンプル・ビューアの「検索」機能が動作しません。

回避策

サンプル・アプリケーションおよびサンプル・コードを検索するには、Examplesサーバーを起動して、http://localhost:7001/examplesWebApp/docs/core/index.htmlに移動する必要があります。「手順説明」,をクリックし、「検索」をクリックします。

Avitek Medical Recordsの検索結果に日本語と英語のテキストが表示される

問題

影響を受けるプラットフォーム: すべて

サンプル・ビューアの「検索」機能では、Avitek Medical Recordsトピックの日本語バージョンと英語バージョンが両方表示された結果が返されることがあります。

回避策

なし

ダウンロードしたライブラリのHTMLページが正しく表示されない

問題

影響を受けるプラットフォーム: すべて

http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.htmlから入手可能なOracle WebLogic Serverドキュメント・ライブラリのZIPファイルを解凍した後、場合によっては次のライブラリのHTMLページが正しく表示されないことがあります:

  • E12840_01 (Oracle WebLogic Server 10.3.0ドキュメント・ライブラリ)

  • E12839_01 (Oracle WebLogic Server 10.3.1ドキュメント・ライブラリ)

  • E14571_01 (Oracle WebLogic Server 10.3.3ドキュメント・ライブラリ)

回避策

ライブラリE12840-01の場合、E12840_01.zipライブラリ・ファイルを抽出した後で、HTMLページが正しく書式設定されない場合は、次のステップを実行します。

  1. Zipファイルを抽出したディレクトリに移動します。
  2. ディレクトリ構造で/global_resourcesディレクトリを探します。
  3. /global_resourcesディレクトリを同じドライブのルート・ディレクトリにコピーします。

ライブラリE12839-01およびE14571-01の場合、この問題はWindowsオペレーティング・システムでのみ発生します。抽出したライブラリのHTMLページが正しく書式設定されない場合は、解凍ユーティリティで別の抽出オプションを使用してZIPファイルを抽出します。たとえば、7-Zipを使用してファイルを抽出している場合は、フル・パス名オプションを選択します。Windows解凍ユーティリティではライブラリZIPファイルを抽出できません。

以前のリリースでクラス・バージョンの不一致のエラーを引き起こしていた問題が修整された

問題

影響を受けるプラットフォーム: すべて

以前のバージョンのWebLogic Serverで、リモート・クライアント(コンテナ外からの呼出し)がIIOPおよびwlclient.jarファイルを使用してEJBを呼び出し、そのEJBがクライアントとEJBとの間でのクラス・バージョンの不一致を引き起こす値オブジェクト返す場合、次のエラーが発生していました。

org.omg.CORBA.BAD_PARAM: Could not find FVD class

この問題は、WebLogic Serverインスタンス間でも発生しました。

この問題は、WebLogic Server 12.2.1.1で解決されています

回避策

なし

JMSInteropModuleおよびJMSInteropModuleMBeanの非推奨情報がWebLogic Serverのドキュメントにない

問題

影響を受けるプラットフォーム: すべて

JMS相互運用モジュールおよび関連するMBean JMSInteropModuleMBeanはWebLogic Server 12.2.1で非推奨になり、将来のWebLogic Serverリリースで削除される予定です。ただし、この非推奨ステータスはWebLogic Serverのドキュメントに反映されていません。JMS相互運用モジュールおよび関連するMBeanへのすべての参照は、将来のWebLogic Serverリリースでドキュメントから削除されます。

回避策

config.xmlinterop-jms.xmlという名前のモジュールがある場合は、標準のシステム・モジュールに変換してください。「JMSシステム・モジュールの構成」を参照してください

File T3サービスの非推奨情報がWebLogic Server Administration Consoleオンライン・ヘルプにない

問題

影響を受けるプラットフォーム: すべて

WebLogic File T3サービスのサポートは非推奨であり、将来のWebLogic Serverリリースで削除されます。ただし、この非推奨ステータスは、Oracle WebLogic Server Administration Consoleオンライン・ヘルプ・ドキュメントの一部のページに反映されていません。将来のWebLogic Serverリリースでは、File T3の参照はすべてOracle WebLogic Server Administration Consoleオンライン・ヘルプから削除されます。

回避策

なし

WebLogic Server Administration Consoleオンライン・ヘルプでNonBufferedDestinationとNonBufferedSourceのデフォルト値が間違っている

問題

Oracle WebLogic Server Administration Consoleオンライン・ヘルプとMBeanリファレンス・ドキュメントで、MBeansのNonBufferedDestinationNonBufferedSourceのデフォルト値の説明に記載されている値falseは間違っています。正しいデフォルト値はtrueです。

回避策

なし

管理コンソール・オンライン・ヘルプにデフォルトのJPA永続性プロバイダの構成ページが誤って表示される

問題

影響を受けるプラットフォーム: すべて

Oracle WebLogic Server 12 c (12.2.1.4.0)以降のバージョンでは、管理コンソールのドメインの「構成」→「一般」オプションの下に「JPA」タブはありません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプに、デフォルトのJPA永続性プロバイダの構成ヘルプ・ページが誤って表示されます。

このページは、Oracle WebLogic Serverの将来のリリースでOracle WebLogic Server管理コンソール・オンライン・ヘルプから削除されます。

回避策

なし