プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle WebLogic Serverリリース・ノート
12c (12.2.1.3.0)
E90282-03
目次へ移動
目次

前

2 既知の問題と回避策

この章では、Oracle WebLogic Server 12.2.1.3.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()

強力なパスワードの適用がWLSTオフライン・スクリプトの問題を引き起こすことがある

問題

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

このリリースのWebLogic Serverでの強力なパスワードの適用(8文字以上で、1つの数値または特殊文字を含む)の実装により、既存のスクリプトで問題が発生する可能性があります。

回避策

次のいずれかの回避策を使用して、新しいパスワード制限をバイパスします。

  • BACKWARD_COMPAT_PW_CHECK環境変数をtrueに設定します。

  • WLSTを呼び出す際に-Dbackward.compat.pw.check=trueオプションを含めます。

この変数とオプションはWebLogic Serverの将来のリリースで削除されるため、新しいパスワード要件を満たすようにパスワードを変更することをお薦めします。

トルコ語ロケールでMDSの初期化に失敗する

問題

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

idという名前の属性にnull値が返されるため、MDSリポジトリを使用するアプリケーションは、WebLogic ServerにバンドルされているJAXBバージョンでデプロイまたは実行できません

回避策

サーバーを英語ロケールで起動します。

管理サーバーが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とともに使用する場合のインストール要件

問題

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

WebLogic Serverに依存しておらず、Mavenを使用するCoherenceユーザーは、独立型のCoherenceインストーラを使用する必要があります。

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

回避策

なし

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

問題

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

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

回避策

なし

ユーティリティ・パッケージが正しくパブリッシュされない

ユーティリティApacheパッケージcom.bea.util.jamおよびcom.bea.util.jam.visitorがオープンソースとしてJava APIリファレンス・ドキュメントで正しくパブリッシュされません。

これらのパッケージは一般使用を対象としていません。

問題

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

ユーティリティApacheパッケージcom.bea.util.jamおよびcom.bea.util.jam.visitorがオープンソースとしてJava APIリファレンス・ドキュメントで正しくパブリッシュされません。

これらのパッケージは一般使用を対象としていません。

回避策

なし

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

問題

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

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

回避策

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

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

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

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

問題

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

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

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

回避策

変更がキャンセルされるか完了した後は、アシスタントに戻るためにブラウザの「戻る」ボタンを使用しないことをお薦めします。また、アシスタント内の前の手順に戻らないこともお薦めします。かわりに、WebLogic Server管理コンソールのナビゲーション・リンクおよびボタンを使用してください。

サポートされないワーク・マネージャ構成を作成できる

問題

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

WebLogic Server管理コンソールでは、サポート対象外で想定どおりに機能しないワーク・マネージャの構成を作成できます。不適切なワーク・マネージャ構成があるとサーバー・ログに多数の例外が記録されます。最も多いのは、デプロイメント記述子の解析中に発生する「Validation problems were found」例外です。

回避策

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

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

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

問題

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

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

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

回避策

なし

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

-Djava.net.preferIPv4Stack=true

java.lang.NoClassDefFoundErrorが表示される

問題

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

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

回避策

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

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

問題

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

新しく作成したCoherenceクラスタ・サービスまたはキャッシュのセキュリティ・ロール構成時に、WebLogic Server管理コンソールで、予想していないエラー状態が示されました。これは、WebLogic Server管理コンソールでは一般的なパターンであり、新しく作成されたアーティファクト上のセキュリティ・ロールおよびポリシーを構成するためにそれらにアクセスするには、アーティファクトを保存してアクティブ化する必要があります。多くのコンソール・ページはこれを確認し、次のことを示すメッセージを表示します: 「必要なセキュリティ・プロバイダが構成されていないか、構成の変更が保留中でアクティブ化されていないため、このページは使用できません。このページを使用するには変更をアクティブ化して、(必要に応じて)管理サーバーを再起動してください」。このチェックは、Coherenceセキュリティ・ページでは行われません。

回避策

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

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

問題

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

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

回避策

なし

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

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

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

回避策

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

Apache Beehiveサポートの問題と回避策

このリリースのWebLogic Serverには、Apache Beehiveサポートの既知の問題はありません。

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

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

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

問題

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

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

回避策

なし

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

問題

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

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

  • MinDynamicClusterSize(デフォルト=1)

  • MaxDynamicClusterSize(デフォルト=8)

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

回避策

なし

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

問題

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

Oracle HTTP Server、WebLogic Serverプロキシ・プラグインを使用するWebサーバー、またはOracle Traffic Directorなどのロード・バランサで構成されている、クラスタ化されたWebLogic ServerアプリケーションによってHTTP POSTリクエストが処理される場合、HTTP 503エラーが発生します。停止中のクラスタ化されたWebLogic Server管理対象サーバーにPOSTリクエストが送信された場合に、そのサーバーがそのリクエストを完了できないかそのリクエストの結果が不明な場合、ロード・バランサはHTTP 503エラーを返す必要があります。Oracle Traffic Directorを動的クラスタとともに使用しており、そのクラスタがスケール・ダウンされている場合、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

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

問題

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

一部のMicrosoft Windowsプラットフォームでは、WebLogic構成ツール・コマンド(wlstconfigpackunpackなど)は、WebLogicインストール・パスに空白が含まれている場合に失敗することがあります。この場合、コマンドは、クラスが空白の後のインストール・パスの部分から導出される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

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

  • インストールにサーバー例が含まれている場合にUNIXまたはLinuxオペレーティング・システムにWebLogic Serverをインストールする場合。

  • 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キャッシュのオーバーライドが機能しない

問題

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

ドメインの作成にWebLogic Server構成ウィザード(config.sh)を使用し、WebLogic Coherenceクラスタの拡張テンプレートを指定する場合は、Coherenceクラスタが定義されます。Coherenceクラスタは、同様に構成ウィザードで作成した任意の管理対象サーバーまたはWebLogic Serverクラスタに関連付けることができます。管理対象サーバーまたはWebLogic Serverクラスタを作成しない場合は、Coherenceクラスタは管理サーバーに関連付けられます。Coherenceクラスタとサーバー間のこの関連付けは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ドメイン構成の理解』の開発モードと本番モードに関する項を参照してください。

第1引数はStringに強制変換できませんというエラーが発生する

問題

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

WLSTスクリプトまたはWLSTコマンドを実行すると、TypeError: state(): 第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つ目のリソース・グループ・テンプレートのリソースに変更を加えた後、新しい値が有効になるようサーバーを再起動します。

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

問題

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

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

回避策

なし

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

問題

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

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

回避策

なし

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

問題

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

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

回避策

WLSコンソールにログインしてbi_server1を停止し、bi_cluster1を起動します。この手順の後、bi_server1を起動して問題を解決します。

WebLogicサーバー管理コンソールを使用して動的クラスタのSAML 2.0メタデータを公開できない

問題

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

動的クラスタを含むドメインでSAML 2.0サービスを構成するときに、「メタ・データの公開」ボタンがWebLogicサーバー管理コンソールに表示されません。静的ドメインでSAML 2.0を構成する場合、「環境」→「サーバー」→「ServerName」→「構成」→「フェデレーション・サービス」→「SAML 2.0全般」ページから「メタ・データの公開」ボタンにアクセスします。

回避策

動的クラスタのサーバー・テンプレートを使用してSAML 2.0を構成し、WLSTコマンドを使用してメタデータ・ファイルを公開します。

  1. 動的クラスタのSAML 2.0構成を実行するには、「環境」→「クラスタ」→「サーバー・テンプレート」→「server_template_name」→「構成」→「フェデレーション・サービス」から「フェデレーション・サービス」タブにアクセスします。
  2. 次の例に示すように、WLSTコマンドを使用してメタデータを公開します。この例は、dynamic_cluster_metadata.xmlというファイルにメタデータを公開します。
    connect('adminUser','adminPwd','adminURL')
    domainRuntime()
    cd('ServerRuntimes') 
    cd('dynamic_server_name')
    cd('SingleSignOnServicesRuntime') 
    cd('dynamic_server_name')
    cmo.publish('/tmp/dynamic_cluster_metadata.xml')
    dynamic_server_nameは、WebLogicサーバー管理コンソールの「環境」→「サーバー」→「ServerName」ページにあります。
    SAML 2.0サービスの構成とメタデータ・ファイルの公開の詳細は、『Oracle WebLogic Serverセキュリティの管理』の「SAML 2.0サービスの構成」を参照してください。

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

問題

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

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

回避策

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

コネクタ(リソース・アダプタ)の問題と回避策

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

コンソール拡張の問題と回避策

このリリースのWebLogic Serverには、拡張の既知の問題はありません。

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

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

IPv6形式のアドレスの使用

問題

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

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

回避策

ホスト・アドレスに大カッコを追加してください。次に例を示します。

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

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

問題

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

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

回避策

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

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

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

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

問題

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

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

オブジェクトの状態が保持されないケースとして、フィールド名の変更があります。これは次のように処理されます。

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

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

したがって、この場合、古いフィールドの状態はすべて、名前変更後のフィールドに持ち越されません。

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リース・スクリプトまたはサポートがない

問題

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

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に対するデータ・ソース検証が失敗する

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から削除する必要があります。

ポート番号を指定する場合、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処理の変更

問題

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

WebLogic ServerのCDI 1.0では、META-INFディレクトリにbeans.xmlファイルがあり、埋込みライブラリJARクラスがBeanアーカイブの一部として含まれている場合、RARアーカイブはCDI Beanアーカイブとして処理されます。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();

大きなアプリケーション・ファイルがデプロイされるときにデプロイメント・タスクが失敗する

問題

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

uploadオプションを使用して大きなアプリケーション・ファイルがデプロイされる場合、デプロイメント・タスクは次のエラーで失敗します。

java.lang.OutOfMemoryError: Java heap space

この問題を解決するために、新しいシステム・プロパティweblogic.deploy.UploadLargeFileが追加されました。この問題が発生する場合は、このフラグを、デプロイメント・クライアントの起動に使用するjavaコマンドに含めます。

WebLogic Serverパッチ・リリース9.2 MP2、9.2 MP3、10.0 MP1、10.0 M2、10.3、10.3.1、10.3.2または10.3.3を使用する場合、このフラグは必要ありません。

回避策

なし

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

問題

影響を受けるプラットフォーム: 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.

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

回避策

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

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

問題

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

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

回避策

なし

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

問題

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

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

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

回避策

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

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

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

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

問題

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

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

回避策

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

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

この項では、ドメインからパーティションへの変換ツール(D-PCT)の既知の問題と考えられる回避策について説明します。

同一クラスタを指す移行可能ターゲットを対象とした場合に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が例外をスローする

問題

Oracle Bug#: 8196335

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

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

一部のデータベースで@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' />

OpenJPAは、表がデータベースにすでに存在する場合でも表を作成しようとします。表がすでに存在することを示す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でも、このハンドルを安定したストレージからシリアル化解除することや、リモート・ホーム・インタフェースへの参照を取得するために使用することができます。

ただし、WebLogic Server 12.2.1 (およびそれ以降)でホストされるサーブレットで、IIOPプロトコルを使用して、Oracle WebLogic Server 11gでホストされるEJBのリモート・ホーム・インタフェースを検索し、ハンドルをファイルにシリアル化した後、そのファイルからハンドルをシリアル化解除する場合、シリアル化解除がClassNotFoundExceptionで失敗する可能性があります。

この状況は、WebLogic Server 12.2.1 (およびそれ以降)でホストされるEJBをIIOPを使用して呼び出そうとする、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のリモート・ホーム・インタフェースを作成します。

例の問題と回避策

このリリースのWebLogic Serverには、例に関する既知の問題はありません。

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

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

JDBCドライバの修正がMAC OS X用インストーラに含まれていない

問題

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

Oracle WebLogic Server 12.2.1をMac OS X開発システムにインストールする場合、インストールに含まれるOracle JDBC Thinドライバには本番環境向けに推奨される一部のJDBCドライバの修正は含まれていません。

回避策

これらの修正を開発環境に実装する必要のある開発者向けにパッチがMy Oracle Supportから入手可能になる予定です。

サーバーの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または管理コンソールを使用する場合に発生します。

回避策

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

WebLogic Server 12.2.1.1に含まれるONS jarにパッチが必要

問題

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

WebLogic Server 12.2.1.1に含まれるONS (Oracle Notification Services) jarとUCP (Universal Connection Pool) jarの互換性の問題から、一部のデータ・ソースがデータベースFANイベントの受信を停止するため、アクティブなGridLinkデータ・ソース・デプロイメントが影響を受けます。

回避策

WebLogic Server 12.2.1.1に含まれるONS jarにパッチが必要です。My Oracle Supportにアクセスしてパッチを入手します。

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つ以上に同じ名前のクラスがある場合、WebLogic ServerがどのJARファイルからクラスをインスタンス化するかは予測できません。これは、クラスが同じ場合には問題になりませんが、異なる実装がある場合には結果を予想できません。

回避策

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

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

問題

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

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

回避策

なし

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

問題

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

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

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

<library-directory></library-directory>

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スキャニングを無効にする

問題

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

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

回避策

以前のバージョンのJava EEで開発されたアプリケーションのデプロイメントのパフォーマンスを向上させるには、次の方法でimplicit-bean-discovery-enabledfalseに設定し、Java EE 7での暗黙的CDIスキャニングを無効にします。

  • 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の問題と回避策

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

WebLogic Server 12.1.2以降のサーバー・アプリケーションの実行ではOracle JRockitはサポートされていない

問題

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

Oracle WebLogic Server 12.1.2は、サーバー・アプリケーションの実行のためにJDK 7を、およびWebLogic Server 12.1.2サーバーに接続するWebLogic Server 12.1.2クライアントのためにJDK 6およびJDK 7をサポートしています。Oracle JRockitは、WebLogic Server 12.1.2以降のサーバー・アプリケーションの実行ではサポートされていません。詳細は、『Oracle WebLogic Server 12.2.1.3.0の新機能』のサポート対象の構成に関する項を参照してください。

回避策

なし

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モジュールのみが格納されます。

回避策

Java EE仕様に準拠したモジュールがEARに少なくとも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クライアント・プロデューサを使用する場合は、各クライアントの新規作成のタイミングを少しずらすようにしてください。

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

問題

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

WebLogicストアのファイルおよびディレクトリの名前には、マルチ・バイト文字を使用することはできません。たとえば、WebLogic Server名にマルチ・バイト文字を使用すると、デフォルト・ストアを作成できず、WebLogic Serverを起動できません。

回避策

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

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

問題

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

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

回避策

なし。

カスタム・ドメイン・テンプレートのアップグレードは、トピック・メッセージの損失またはサーバー・メモリーの枯渇をもたらす可能性がある

問題

回避策

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

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

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

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

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

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

  • 『Oracle WebLogic Serverのアップグレード』の指示に従い、再構成ウィザードを使用して12.1.2より前の既存のドメインを再構成する場合、構成および永続トピック・サブスクリプションは変更されないままとなります。

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

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

  • 再構成ウィザードを使用して、適切な位置にドメインをアップグレードします。

  • ドメイン構成をアップグレードまたは再生成する前に、メッセージを排出します。アップグレードしたら、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 7にアップグレードすることをお薦めします。

JNDIの問題と回避策

このリリースのWebLogic Serverには、JNDIの既知の問題はありません。

JTAの問題と回避策

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

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

問題

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

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

回避策

なし

JDBCストアを有効化したときに警告メッセージが繰り返しログ記録される

問題

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

JDBC TLogストアをクロスサイト回復機能を有効にせずに使用すると、次の警告メッセージが複数回ログ記録されます。
<Warning> <JTA> <BEA-111020> <An issue occurred during cross-site recovery processing: PeerSiteRecoveryLeaseMaintenance: Unable to create either connection or prepared statements for cross-site recovery..>

回避策

ドメイン・ロギング・フィルタを使用することで、この問題を回避できます。

1つのトランザクション・ポイントで複数のDB2リソースが同じDBの場合にコミットのリカバリが失敗する

問題

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

1つのトランザクション・ポイントで複数のDB2リソースが同じDBの場合にコミットのリカバリが失敗します。

回避策

なし

Java仮想マシン(JVM)の問題と回避策

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

1.4シン・クライアント・アプレットがWebLogic Serverと通信できない

問題

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

Sun Microsystems VMの既知のバグ(513552)により、1.4シン・クライアント・アプレットはWebLogic Server 9.0以降と通信できません。これは、クライアントとサーバーの接続間でVMが正しく区別されないことが原因です。VMは、サーバー・タイプ接続を作成し、それをキャッシュします。次に、クライアント・タイプ接続の確立を試行し、キャッシュされた接続を探してそれを使用しようとしますが、クライアントはサーバー接続の使用を許可されないため、エラーが発生します。

回避策

なし

一部のプロセッサで実行されているアプリケーションで時間の問題が断続的に発生することがある

問題

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

RedHat (RH) Linux上で実行され、直接的または間接的にシステム時間の呼出しを使用するアプリケーションにおいて、ClockSourcetsc (デフォルト)に設定されている場合に、時間の問題が断続的に発生する可能性があります。標準のPOSIX C gettimeofday()を呼び出した結果、Java System.currentTimeMillis()java.util.Date()も呼び出されると、シングル・スレッド・アプリケーションの場合でも、将来に約4400秒の値が断続的に返される可能性があります。

この問題はWebLogicやJavaに固有の問題ではなく、RH Linux上で実行されるどのアプリケーションにも当てはまります。この問題が発生するのは、標準Java、または時間ベースのアプリケーション・サーバー・サービスを使用して、時間の呼出しを明示的に行うアプリケーションです。

考えられる症状としては、トランザクションの早過ぎるタイムアウト、JMSメッセージの予期しない期限切れ、タイマーの不適切なスケジューリングなどが挙げられますが、これだけに限りません。

この問題はRedHat 5.3で修正されました。

回避策

なし

長い配列のコピーを実行しているときに、JRockit JVMがフリーズしたように見える

問題

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

無制限のフォワード・ローリングの一部として長い配列のコピーを実行しているときに、JRockit JVMがフリーズしたように見えます。この状況は、Out Of Memory条件により複数のサーバーが再起動した場合に発生することがあります。

回避策

サーバーの起動時に、次のJRockit JVMフラグを指定します。

 -XXrollforwardretrylimit:-1

シリアル・バージョンUIDの不一致

問題

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

シリアル・バージョンUIDの不一致の問題は、最新のJVMにアプリケーションをデプロイし、以前のサービス・リリースのIBM Java 6 JDKでコンパイルした場合に発生します。

回避策

以前にコンパイルしたアプリケーションのシリアライゼーションと互換にするには、WL_HOME/common/bin/commEnv.shファイルを変更して、次のコマンドを含めます。

JAVA_OPTIONS="$JAVA_OPTIONS 
-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"

または、次のコマンド行オプションを使用できます。

export IBM_JAVA_OPTIONS=
"-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"

以前にコンパイルしたアプリケーションとともに新しいアプリケーションをデプロイする場合は、必要に応じて再コンパイルし、同じシリアル・バージョンUIDを持つようにする必要があります。

JVMスタックのオーバーフロー

問題

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

WebLogic Serverの実行中に、JVMスタックのオーバーフロー・エラーまたは例外が発生することがあります。この問題は、AMD64および64ビットXeonプラットフォーム上のOracle Enterprise Linux 4、5、5.1で発生します。

回避策

スタック・サイズをデフォルトの128kから256kに増やします。

AWTライブラリを使用するとJVMがクラッシュすることがある

問題

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

AWTやjavax.swing(多くの場合、AWTに委任されます)などのGUIライブラリを使用している場合に、JVMクラッシュが発生することがあります。

回避策

次のフラグを使用してサーバーを起動します。

-Djava.awt.headless=true

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

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

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

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

明示的に@unharvestableとマークされていないMBean属性が収集可能として表示される

問題

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

@unharvestableタグはインタフェース・レベルで適用されません。MBean属性が明示的に@unharvestableとマークされていない場合は収集可能と見なされ、WebLogic Server管理コンソールにも収集可能と表示されます。

回避策

MBean属性を明示的に@unharvestableとマークできます。

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

問題

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

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

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

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

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

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

回避策

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

CreateSystemResourceControlの動作変更

問題

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

この問題は、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'というモジュール名を含める必要があります。

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

問題

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

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

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

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

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

  • アップグレードの実行中に、稼動中のサーバーがある場合(スキーマを複数の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ノード・マネージャの管理』のノード・マネージャのプロパティに関する項を参照してください。

操作および管理の問題と回避策

このリリースのWebLogic Serverには、操作および管理の既知の問題はありません。

Oracle Kodoの問題と回避策

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

問題

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

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

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

回避策

なし

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

この項では、様々なWebLogic Serverプラグインの次の問題について説明します。

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

問題

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

次の状況では、IISプラグインが動作しないことがあり、apr_socket_connectionエラーが発生します。

  1. IISとWebLogic Serverの両方のインスタンスが同じマシンにある場合。

  2. マシンでIPv6が有効になっていて、マシンがIPv6環境にない場合(つまり、IPv6インタフェースが有効になっているが動作していない場合)。

  3. WebLogic Serverインスタンスのリスニング・アドレスが単純なホスト名に設定されている場合。

  4. ディレクティブWebLogicHostまたはWebLogicClusterがIISインスタンスに対して単純なホスト名に設定されている場合。

回避策

なし

管理対象サーバーによる書込み保護されたドメインの調査に失敗する

問題

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

イントロスペクションは失敗し、ユーザーは、書込みできないドメインを調査しようとしているときにエラーを受け取ります。

回避策

調査を実行するユーザーを許可するよう、ドメイン・ルート・ディレクトリの権限を変更します。

SYSPROPによりOVAB StudioでHTTPプロキシ処理を有効にする

問題

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

Oracle Virtual Assembly Builder (OVAB) Studioでは、HTTPプロキシ処理は無効化されています。システム・プロパティを使用してHTTPプロキシ検出を有効にできます。

回避策

このシステム・プロパティは、Studioの起動を実行するごとに設定することも、abstudio.shファイルを変更して永続的に設定することもできます。

OVAB Studioの実行1回ごとにこのプロパティを設定するには、次の手順を実行します。

  1. OVAB Studioを停止します。

  2. 構成ディレクトリを削除します。

    $AB_INSTANCE/state/gui/$USER/system.12.1.2.0.0 (または相当するもの)

  3. プロパティになんらかの値(たとえば1)を設定してGUIを再起動します。

    ./abstudio.sh -J-Dovab.studio.enableHttpProxy=1

注意:

その後GUIを起動するごとにこのプロパティを定義する必要があり、そうしなければabstudio.shのプロパティ設定によって、プロキシ処理はfalseに戻されます。

HTTPプロキシ処理が常に有効になるようにプロパティを設定するには、次の手順を実行します。

  1. インスタンスのbinディレクトリのabstudio.shファイルを編集します。
  2. プロパティ設定を次のようにSYSPROPSに追加します。

    SYSPROPS="${SYSPROPS} -J-Dovab.studio.enableHttpProxy=1

enableHTTPProxy=1を設定した後で、標準Javaプロパティhttp.proxyHosthttp.proxyPortおよびhttp.nonProxyHostsを使用して、プロキシ・ホスト、ポートおよび例外を設定できます。Linuxで非標準のデスクトップ環境を使用している場合は、valuehost:porthttp_proxyプロパティの設定が必要な場合があります。

プロトコルの問題と回避策

このリリースのWebLogic Serverには、プロトコルの既知の問題はありません。

RMI-IIOPの問題と回避策

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

Ant 1.7 rmicタスクの非互換性

問題

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

Antバージョン1.7 rmicタスクを呼び出すと、-vcompat flagが自動的に追加されますが、これはOracle WebLogic Serverのrmicと互換性がありません。

回避策

rmic呼出しが次の形式の場合は、次のいずれかの回避策を使用します。

rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
   base="${module_location}/core-legacy-ra/classes"
   classpath="${core.classes}" compiler="weblogic" />
  • stubversionを追加します

    <rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
       base="${module_location}/core-legacy-ra/classes"
       classpath="${core.classes}" compiler="weblogic"
       stubversion="1.2"/>
    
  • compilerフラグを削除します

    <rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
       base="${module_location}/core-legacy-ra/classes"
       classpath="${core.classes}"

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

問題

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

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

回避策

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

-Dweblogic.PrintStackTraceInProduction=true

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

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

サービス側Kerberos認証がエラー401で失敗する

問題

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

JDKバージョンがJRockit 1.60_24、1.60_28または1.60_29の場合、サービス側Kerberos認証はHTTP/1.1 Error 401 Unauthorizedで失敗します。

回避策

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

  • ktab.exeを使用してキータブ・ファイルを生成するかわりに、kadminなどの別のツールを使用して生成します。

  • ktab.exeを使用して適切なkvnoを手動で指定します。

JSSEベースのSSL Providerを使用している場合にBAD_MAC_RECORDエラーが発生する

問題

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

WebLogic ServerがJSSEベースのSSLプロバイダを使用するように構成されている場合、SSL接続を作成しようとすると、BAD_MAC_ERRORメッセージで失敗することがあります。

回避策

JDK 7u2以上をインストールし、WebLogic Serverを再起動します。

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

問題

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

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

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

回避策

なし

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

問題

Oracle Bug#:

影響を受けるリリース:

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

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

回避策

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

ドメインをWLS 6.1からアップグレードした後で認証に失敗する

問題

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

ドメインをWLS 6.1からアップグレードした後で、認証エラーが原因でWebLogic Serverインスタンスが起動しません。

回避策

WebLogic Serverインスタンスを適切に起動するには、アップグレード・プロセスの前か後に、WLS 6.1ドメインでシステム・ユーザー・パスワードを設定する必要があります。

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を追加します。

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

問題

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

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

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

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

回避策

なし

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

WebLogic Server LDAP認証プロバイダのログ・メッセージに、getConnectionメソッドで返されたLDAP接続のURLが表示されますが、そのURLは正しくありません。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ファイルを削除して、管理対象サーバーを再起動します。

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

問題

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

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

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

回避策

なし

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

問題

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

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

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 12.2.1.3.0の新機能』の削除された機能とコンポーネントに関する項を参照してください。

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

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

回避策

なし

JDK8u161以上を使用したutils.CertGenでの証明書の生成が失敗する

問題

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

JDK 8 u161以上を使用してutils.CertGenで証明書を生成すると、java.security.InvalidKeyException: exponent is larger than modulusのエラー・メッセージで失敗します。

回避策

utils.CertGenの実行時に-noskidパラメータを指定します。

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

問題

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

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

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

回避策

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

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

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

SNMPの問題と回避策

このリリースのWebLogic Serverには、SNMPの既知の問題はありません。

WebLogic Server上のSpringフレームワークの問題と回避策

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

JRockitで実行している場合にOpenJPA ClassFileTranformerが動作しない

問題

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

OpenJPA ClassFileTranformerは、JRockitでWebLogic Serverを実行している場合に動作しません。

回避策

回避策として、OpenJPAエンハンサ・コンパイラを使用して、ビルド時に拡張を適用してください。LoadTimeWeaverは使用しないでください。

WebLogic Serverにpetclinic.earがデプロイされない

問題

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

SpringSourceのpetclinicサンプルで、petclinic.warは問題なくデプロイされます。petclinic.earは正しくパッケージ化されていないため、WebLogic Serverにデプロイされません。SpringSourceに対してpetclinic.earのパッケージ化を修正するようにリクエストを送信済です。

回避策

なし

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

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

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

問題

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

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

回避策

なし

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

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

アップグレード時にSQLIntegrityConstraintViolationExceptionが発生する場合がある

問題

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

再構成ウィザードでlog_priority=ALLを指定してOracle WebLogic Serverをアップグレードすると、次の例外が発生します。

Internal Exception: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (NM_OPSS.IDX_JPS_RDN_PDN) violated

回避策

なし

再構成時にSAXParseExceptionが発生する場合がある

問題

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

log_priority=ALLを指定してreconfig.shを起動すると、reconfig.logに次の例外が出力されます。

[org.xml.sax.SAXParseException; lineNumber: 3; columnNumber: 77; cvc-elt.1: Cannot find the declaration of element 'stringSubsInfo'.]

回避策

なし

ドメインのアップグレード時DefaultIdentityAsserterを手動で構成する

問題

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

ライフサイクル・マネージャ、RESTful管理サービス、WebLogic Server管理コンソール、Fusion Middleware ControlなどのWebLogic Serverソフトウェアの一部の機能は、アップグレードしたドメイン構成には存在しない可能性のあるWebLogic Serverのセキュリティ機能に依存しています。

回避策

ドメインのアップグレード時、次のセキュリティ機能を手動で構成する必要があります。

  • LCMUserサービス・アカウントがない場合は作成します。このサービス・アカウントは管理グループに存在する必要があり、セキュアなパスワードが必要です。

  • weblogic-jwt-tokenがない場合、DefaultIdentityAsserter構成を更新してアクティブなタイプとして含めます。

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. 「ツール」「オプション」「詳細」「暗号化」タブ「証明書を表示」に移動します。
  2. 「サーバー証明書」タブで、証明書を削除します。
  3. 「認証局証明書」タブで、問題の原因となったセキュリティ・デバイスの認証局(CA)を探し、削除します。

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

Internet ExplorerでJSPXページの出力を表示できない

問題

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

JSPXページがデプロイされ、一部のバージョンのInternet Explorerを使用してアクセスされる場合、ページ・コンテンツのかわりにXHTMLソースが表示されます。この状況は、標準モードとosjp.nextモードの両方で発生します。

回避策

アプリケーション・ユーザーに、FirefoxまたはSafariを使用してアプリケーションにアクセスするよう指示する必要があります。

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モジュールのデプロイメント時に、デプロイメント・プランを使用して2つのデプロイメント記述子WEB-INF/classes/META-INF/persistence.xmlおよびWEB-INF/classes/META-INF/persistence-configuration.xmlをオーバーライドすることはできません。それ以外の場合は、デプロイメント・プランを使用して記述子をオーバーライドできます。

回避策

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

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

回避策

回避策はありません。

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

問題

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

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

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

回避策

回避策はありません。

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

問題

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

WebLogic Server 12.1.2以降は、weblogic.xmlデプロイメント記述子内のjdbc-connection-timeout-secs要素はなくなりました。jdbc-connection-timeout-secsを構成するアプリケーションは、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に変更された

問題

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

WebLogic Server 12.1.3より、JSPページに対するweblogic.xml内のjsp-descriptor要素のencoding要素のデフォルト値は、UTF-8です。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より、WebLogic Serverは、Webアプリケーションのデプロイメント記述子web.xmlのバージョンが2.5以前に設定されたJSFベースのWebアプリケーションに対してアノテーション付きカスタム・タグはサポートしません。

回避策

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

たとえば、既存のWebアプリケーションのバージョンが2.3に設定されているとします。次の例に示すように3.0にアップグレードします。

<?xml version = '1.0' encoding = 'windows-1252'?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
         version="3.0">
   ...
</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の問題と回避策

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

スパース配列と部分転送配列はサポートされない

問題

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

WebLogic Serverでは、JAX-RPC 1.1仕様で要求されているスパース配列と部分転送配列がサポートされません。

回避策

なし

WSDLコンパイラはシリアライズ可能なデータ型を生成しない

問題

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

Webサービス記述言語(WSDL)のコンパイラでシリアライズ可能なデータ型が生成されないため、データがリモートのEJBに渡されない、またはJMS宛先に格納されません。

回避策

なし

コールバックでのカスタム例外の使用

問題

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

WebLogic Serverでは、親Webサービスのターゲット・ネームスペースに適合しないパッケージを持つカスタム例外を、コールバックで使用することはできません。

回避策

コールバックで使用されるカスタム例外は、親Webサービスのターゲット・ネームスペースに適合するパッケージに入れるようにしてください。

プロキシ・サーバーも使用している環境ではJMS転送を使用できない

問題

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

プロキシ・サーバーを使用している環境では、JMS転送を使用できません。これは、JMS転送の場合はWebサービス・クライアントが常に t3 プロトコルを使用してWebサービスに接続するのに対し、プロキシ・サーバーではHTTP/HTTPSしか受け付けられないためです。

回避策

なし

WSDLの処理中にclientgenに失敗する

問題

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

Webサービス・パラメータとして複合型http://www.w3.org/2001/XMLSchema{schema}を使用する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で検索します。しかし、その場所にはポリシー・ファイルが存在しないため、ファイルが見つからないことを示す例外がスローされます。

回避策

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>

回避策

以下の2つの解決策のいずれかを使用してください。

  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/>のかわりに、WssX509PkiPathV1Token11/>または<sp:WssX509PkiPathV1Token10/>を使用する必要があります。

xmlcatalog要素エンティティをリモート・ファイルまたはアーカイブ内のファイルにできない

問題

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

build.xmlxmlcatalog要素では、エンティティの場所はローカル・ファイル・システム上のファイルでなければなりません。リモート・ファイル(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カタログの制限です。

回避策

リソースの場所は、インラインか外部カタログ・ファイルで、または両方で指定できます。外部カタログ・ファイルを使用するには、xml-commonsリゾルバ・ライブラリ(resolver.jar)をクラスパスに含める必要があります。外部カタログ・ファイルの形式はプレーン・テキストまたはXMLです。xml-commonsリゾルバ・ライブラリがクラスパスで見つからない場合、<catalogpath>パスで指定された外部カタログ・ファイルは無視されて、警告がログに記録されます。ただし、この場合でも、インライン・エントリの処理は正常に続行されます。

現在、インラインで指定できるのは<dtd>要素と<entity>要素のみです。これらの要素はそれぞれ、OASISカタログ・エントリ・タイプのPUBLICとURIに対応します。

WebSphereおよびWebLogic ServerとのWS-AT相互運用性の問題

問題

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

WebSphereをクライアントとし、WebLogic ServerまたはJRFをサービスとして使用したWeb Services Atomic Transactions (WS-AT) 1.1の相互運用は動作しません。

WS-AT 1.1の相互運用は、WebSphereがサービスで、WebLogic ServerまたはJRFがクライアントの場合に動作します。この場合、相互運用はFix/Feature Pack 7を適用したWebSphere 7がある場合にのみ動作します。

回避策

なし

サーバー・ログにJAX-RSエラー・メッセージが記録されている場合がある

問題

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

JAX-RSアプリケーションが実行されている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 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」→「Documentation」を選択してExamplesドキュメントにアクセスすると、サンプル・ビューアの「検索」機能が動作しません。

回避策

サンプル・アプリケーションおよびサンプル・コードを検索するには、Examplesサーバーを起動して、http://localhost:7001/examplesWebApp/docs/core/index.htmlに移動する必要があります。「手順説明」をクリックし、「検索」をクリックします。

Avitek Medical Recordsの一部の検索結果トピックで日本語のテキストが表示される

問題

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

サンプル・ビューアの「検索」機能を使用すると、Avitek Medical Recordの一部のトピックの日本語版と英語版が同時に表示されるトピックが返されることがあります。

回避策

なし

ダウンロードしたライブラリのHTMLページが正しく表示されない

問題

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

http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.htmlから入手可能なWebLogic Serverドキュメント・ライブラリZIPファイルを抽出した後で、次のライブラリの一部でHTMLページが正しく表示されないことがあります。

  • E12840_01 (WebLogic Server 10.3.0ドキュメント・ライブラリ)

  • E12839_01 (WebLogic Server 10.3.1ドキュメント・ライブラリ)

  • E14571_01 (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で解決されています

回避策

なし