2 既知の問題と回避策

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

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

• 一般的な問題と回避策
  
• 管理コンソールの問題と回避策
  
• クラスタリングの問題と回避策
  
• 構成の問題と回避策
  
• コア・サーバーおよびコア・ワーク・マネージャの問題と回避策
  
• リソース消費マネージャ(RCM)が同じ値を使用してトリガーする異なるアクションによって予期される動作
  
• データ・ソースの問題と回避策
  
• 依存関係インジェクションの問題と回避策
  
• デプロイメントの問題と回避策
  
• 開発者の操作性の問題と回避策
  
• EJBに関する問題と回避策
  
• HTTP Publish/Subscribeサーバーの問題と回避策
  
• インストールおよびパッチの適用の問題と回避策
  
• Java EEの問題と回避策
  
• JDKの問題および回避策
  
• JMSの問題および回避方法
  
• JTAの問題および回避方法
  
• Java仮想マシン(JVM)の問題と回避策
  
• ライフサイクル管理の問題と回避策
  
• モニタリングの問題と回避策
  
• ノード・マネージャの問題と回避策
  
• 操作および管理の問題と回避策
  
• Oracle Kodoの問題と回避策
  
• Oracle WebLogic Serverプロキシ・プラグインの問題と回避策
  
• RMI-IIOPの問題および回避策
  
• セキュリティの問題と回避策
  
• WebLogic Server上のSpringフレームワークの問題と回避策
  
• アップグレードの問題と回避策
  
• Webアプリケーションの問題と回避策
  
• WebLogic Server Scripting Tool (WLST)の問題と回避策
  
• Webサーバー・プラグインの問題と回避策
  
• WebサービスおよびXMLの問題と回避策
  
• WebLogic Tuxedo Connectorの問題と回避策
  
• ドキュメントの変更
  

一般的な問題と回避策

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

• Safariを使用している場合にファイル名にマルチバイト文字が正しく表示されない
  
• トルコ語ロケールでMDSの初期化に失敗する
  
• 管理サーバーがEMコンソールで「開いているファイルが多すぎます」のメッセージをレポートする
  
• CoherenceをMavenとともに使用する場合のインストール要件
  

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

問題

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

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

回避策

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

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

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

問題

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

idという名前の属性にnull値が返されるため、MDSリポジトリを使用するアプリケーションは、Oracle 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とともに使用する場合のインストール要件

問題

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

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

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

回避策

なし

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

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

• ブラウザの「戻る」ボタンをクリックするとコンテキストが破棄される
  
• サポート対象外のワーク・マネージャ構成の作成
  
• サーバー・ステータス表が一貫性のない情報を反映する
  
• EJBのセキュリティ・ポリシーを定義する際の例外
  
• 管理コンソールに、デプロイメント・プランに加えれらた外部の変更が反映されない場合がある
  
• アプリケーション・テスト・リンクが管理コンソールでの解決に失敗する
  
• java.lang.NoClassDefFoundErrorが表示される
  
• 新しく作成したCoherenceクラスタ・サービスまたはキャッシュのセキュリティ・ロール構成時のエラー
  
• 管理コンソール拡張の非推奨化
  

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

問題

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

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クラスタのリソースを、ロールおよびポリシー構成のために使用できるようになります。

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

問題

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

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

回避策

なし

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

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

• ユニキャスト・モードのクラスタ・メッセージングでスレッドがブロックされる
  
• 最小および最大動的クラスタ・サイズ制約の影響
  
• クラスタのスケール・ダウン中またはフェイルオーバー中のHTTP POSTリクエストでのHTTP 503エラー
  

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

問題

影響を受けるプラットフォーム: 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トラフィックをリダイレクトする前に、短い停止時間がある場合があります。

回避策

なし

構成の問題と回避策

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

• slf4jフレームワークの初期化
  
• WebLogicドメインの作成時にASProvWorkflowExceptionが発生する
  
• 英語以外のロケールでWLSTを実行している場合は-Dfile.encodingプロパティを使用する
  
• Oracle WebLogic Serverのインストール・パスに空白が含まれていると構成ツールが失敗することがある
  
• 存在しないサーバー名のディレクトリが作成される
  
• WebLogicパスワードの入力後のターミナル・ウィンドウの異常な動作
  
• ドメインの作成と更新に長時間かかる
  
• 新規ドメインの構成時に「パスワード」フィールドを編集できない
  
• 管理サーバーのメモリー消費量およびJMX通知
  
• editCustom()MBeanへの変更をロールバックする際の問題
  
• 同一ホスト上での複数の開発サーバー起動の問題
  
• Coherenceキャッシュのオーバーライドが機能しない
  
• 管理対象サーバーのドメインをテンプレートから作成するとエラーが発生する
  
• ドメインを開発モードから本番モードに切り替えても起動スクリプトが変更されない
  
• WLSTスクリプトまたはコマンドの実行時にエラーが発生する
  
• 構成後のピュアIPv6デプロイメントでBI Cluster1が停止している
  
• ODAクラスタ構成で実行する場合、Oracle WebLogic Serverのデフォルト構成の使用を回避
  
• WLSTオフライン・デフォルトを使用して作成された管理者グループへの未割当てユーザー
  

slf4jフレームワークの初期化

問題

Oracle WebLogic Serverを14c (14.1.1.0)にアップグレードした後、slf4jフレームワークが初期化されません。

回避策

Oracle WebLogic Server 14c (14.1.1.0)では、slf4jフレームワークは$ORACLE_HOME\oracle_common\modules\thirdparty\apache-maven_bundle\3.6.1.0.0\apache-maven-3.6.1\libにあります。この場所からslf4jフレームワークを初期化します。

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構成ツール・コマンド(wlst、config、packおよび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つのケースがあります。

• Oracle WebLogic Serverレベルで、管理対象サーバーが停止したときの登録解除済MBean通知をシミュレートする場合。
• JDK JMXクライアント通知レイヤーにおいてです。

回避策

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

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

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

問題

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

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

編集セッションを開いている状態でstopEdit()またはcancelEdit()を使用するか、WLSTを終了すると、Oracle 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パラメータを含めます。
• 予約済文字列名を別の文字列に変更します。たとえば、文字列名serverをsrvrに変更すると問題を回避できます。

構成後のピュア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がブロックされることがあるためです。

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

問題

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

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

回避策

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

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

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

• IPv6形式のアドレスの使用
  
• サーバー全体を移行した後でサーバーを起動できない
  
• フィールド名を変更した後でオブジェクト状態が保持されない
  
• あるホスト名でリスニングするように構成されたサーバーが、起動後に別のホスト名でリスニングする
  
• 管理サーバーまたはノード・マネージャが、管理対象サーバーのステータスを追跡できない
  
• ネットワークの分割中またはその後でマルチキャスト・トラフィックの信頼性がなくなる
  
• Java DBリース・スクリプトまたはサポートがない
  
• 管理対象サーバーをマルチキャスト・クラスタに追加するとその管理対象サーバーの起動に失敗する
  
• アプリケーション・スレッドの数が多いとサーバーがストールすることがある
  
• @Localアノテーションが付いている場合にリモート・クライアントによってエンタープライズBeanがアクセスされる
  

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ディレクトリには、使用可能なリース・スクリプトはありません。

回避策

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

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

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

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

問題

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

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

回避策

この問題を回避するには、起動スクリプトstartWebLogic.shのJAVA_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に対するデータ・ソース検証が失敗する
  

ポート番号を指定すると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"

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

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

• AroundInvokeインターセプタ・メソッドがコンテナにより呼び出されたMDBメソッドに適用される
  
• BeanManagerでライフサイクル・イベントにValidatorFactory Beanが含まれない
  
• CDIが有効なEARとCDIが有効でないWARの組合せは正しく機能しない
  
• 12.2.1でのRARのCDI処理の変更
  

AroundInvokeインターセプタ・メソッドがコンテナにより呼び出されたMDBメソッドに適用される

問題

インターセプタ・バインディングを使用して宣言されたインターセプタの場合、通常、AroundInvokeインターセプタ・メソッドは、コンテナによって呼び出されるMDBメソッド(setMessageDrivenContext()、ejbRemove()など)には適用されません。このリリースのOracle Weblogic Server 14.1.1.0.0から、AroundInvokeインターセプタ・メソッドはこれらのメソッドにも適用されます。この動作変更は、CDIのOracle WebLogic Server 14.1.1.0.0に統合されているWeld 3.0.x (x>1)に起因しています。

回避策

methodsというコンテナをスキップするには、AroundInvokeに条件付き判断を追加します。

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要素を使用できない
  
• 無関係な文字列値がファイル仕様として解釈される
  
• restoreメソッドがプラン・オーバーライドでDConfig Beanを更新しない
  
• 大きなアプリケーション・ファイルがデプロイされるときにデプロイメント・タスクが失敗する
  
• アプリケーションが別のソース・ファイルの場所を使用してデプロイされている場合、アプリケーションの再デプロイの試行に失敗する
  
• 該当する出力メッセージが表示されない
  
• アプリケーション名はドメイン内で一意である必要がある
  

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コマンドに含めます。

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

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

回避策

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

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

問題

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

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

回避策

なし

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

問題

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

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

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

回避策

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

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

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

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

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

問題

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

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

回避策

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

EJBに関する問題と回避策

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

• Oracle表の主キーがCHARになる
  
• クラスタ化可能なタイマーの作成を有効にするアノテーションがない
  
• KodoのMappingToolでスキーマを生成できない
  
• JPAメタデータ・モデルに対する拡張はアノテーションを介してのみ指定できる
  
• ルックアップ・メソッドの注入がSpringでサポートされない
  
• 管理対象の環境でJDO PersistenceManagerFactoryをデシリアライズするとエラーが発生することがある
  
• スキーマの作成時に索引が作成されないことがある
  
• @Idフィールドに@Uniqueアノテーションも付いている場合にOpenJPAが例外をスローする
  
• キャッシュのヒットとミスの数が予想外に増える
  
• Open JPAは表が存在する場合でも表を作成しようとする
  
• シリアライゼーション中にEJBアプリケーションが失敗する
  
• IIOPを使用した11g EJBの呼出し時にEJBハンドルのシリアライゼーションが失敗する
  
• リモート・アノテーションで指定したEJB 3.xをWebLogicクライアントでIIOPを使用して検索できない
  

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サーバーのチャネルを操作する完全な権限があります。つまり、ローカル・クライアントは、チャネルの作成と削除、チャネルからのイベントのパブリッシュとサブスクライブを行えます。

回避策

なし

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

問題

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

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

回避策

なし

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

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

• インストールが致命的なエラーで失敗する
  
• JDBCドライバの修正がMAC OS X用インストーラに含まれていない
  
• サーバーのFAILED状態によって停止操作時ZDTロールアウトが中止される
  
• WebLogic Server 12.2.1.1に含まれるONS jarにパッチが必要
  
• JMSサービスのフェイルバック中にJMS T3スタンドアロン・クライアントが待機する時間が長い
  

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

問題

影響を受けるプラットフォーム: すべての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でエンティティBeanとejbClassの再定義がサポートされない
  
• EARファイルに複数のJARがある場合にクラスパス順序が保証されない
  
• CDIの使用時にFastSwapがサポートされない
  
• Java EE 6アプリケーションをJava EE 7に移行する場合暗黙的CDIスキャニングを無効にする
  

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に関連するエラーが発生します。

回避策

なし

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の問題および回避策

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

• WebLogic Server 12.1.2以降のサーバー・アプリケーションの実行ではOracle JRockitはサポートされていない
  
• RSA 6.2.4プロバイダおよびJDK 11でのFIPS 140-2サポート
  
• JDK8u301およびJDK 11.0.12以降を使用した非FIPS準拠のキーストアの変換時のKeytoolエラー
  

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の新機能』のサポート対象の構成に関する項を参照してください。

回避策

なし

RSA 6.2.4プロバイダおよびJDK 11でのFIPS 140-2サポート

問題

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

WebLogic Server 14.1.1には、現在RSA 6.2.4プロバイダが付属しています。RSA 6.2.4プロバイダによるJDK 11のJavaオプションを使用してFIPSモードを有効化する場合、java.securityファイルで指定されたRSAプロバイダの順序は、JDK 8で使用されている順序とは異なります。

回避策

JDK 11については、java.securityファイルにリストされている最初の2つのJavaセキュリティ・プロバイダとしてRSA JCEプロバイダとRSA JSSEプロバイダの順序を変更します(『Oracle WebLogic Serverセキュリティの管理』のJavaオプションのFIPS 140-2モードの有効化に関する項を参照)。

JDK 8:

security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider

JDK 11:

security.provider.1=com.rsa.jsse.JsseProvider 
security.provider.2=com.rsa.jsafe.provider.JsafeJCE

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

問題

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

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

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

回避策

RSA JCEプロバイダを使用して非FIPS準拠のJKSおよびPKCS12キーストアを変換する手順の詳細は、『Oracle WebLogic Serverセキュリティの管理』のFIPS 140-2準拠のキーストアの作成に関する項を参照してください。JDK 8u301またはJDK 11.0.12以降を使用している場合は、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の問題および回避方法

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

• マップされていない接続ファクトリ・リソースの動作の変更
  
• デプロイメント記述子の検証に失敗する
  
• 複数のプロデューサが同じクライアントSAFインスタンスを使用する場合の例外
  
• ストアのファイル名とディレクトリ名でマルチバイト文字がサポートされない
  
• NFSでファイル・ストアを使用している場合にWebLogic Serverのテストが突然失敗する
  
• カスタム・ドメイン・テンプレートをアップグレードすると、トピック・メッセージが失われたりサーバー・メモリーが枯渇することがある
  
• 既存のJMS .NETクライアントと相互運用するためのシステム・プロパティの設定
  
• JMS分散宛先がドメインを拡張した後に存在しない
  
• JMSメッセージング・ブリッジの外部プロバイダとしてJBoss 5を使用すると問題が発生する
  

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

問題

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

この問題は、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 foundやDispatcher 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の問題および回避方法

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

• トランザクション・プロトコルの変更によってトランザクション結果が矛盾する
  
• JDBCストアを有効化したときに警告メッセージが繰り返しログ記録される
  
• 1つのトランザクション・ポイントで複数のDB2リソースが同じDBを指し示している場合、コミットのリカバリが失敗する
  

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

問題

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

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

回避策

なし

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シン・クライアント・アプレットがOracle WebLogic Serverと通信できない
  
• 一部のプロセッサで実行されているアプリケーションで時間の問題が断続的に発生することがある
  
• 長い配列のコピーを実行しているときに、JRockit JVMがフリーズしたように見える
  
• シリアル・バージョンUIDの不一致
  
• JVMスタックのオーバーフロー
  
• AWTライブラリを使用するとJVMがクラッシュすることがある
  
• Java SE 8上で実行されている14.1.1.0.0にアップグレードする場合にOracle WebLogic Server用のJava推奨ディレクトリの場所を手動で設定する
  

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

問題

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

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

回避策

なし

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

問題

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

RedHat (RH) Linux上で実行され、直接的または間接的にシステム時間の呼出しを使用するアプリケーションにおいて、ClockSourceがtsc (デフォルト)に設定されている場合に、時間の問題が断続的に発生する可能性があります。標準の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

Java SE 8上で実行されている14.1.1.0.0にアップグレードする場合にOracle WebLogic Server用のJava推奨ディレクトリの場所を手動で設定する

問題

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

Oracle WebLogic Server 10.3.xドメインをJava SE 8で動作するドメインにアップグレードする際に、Oracle WebLogic ServerのJava推奨ディレクトリ(または複数のディレクトリ)の場所を手動で設定することが必要な場合があります。

回避策

次の場合は、管理対象サーバーの起動に使用するコマンドでOracle WebLogic Server用のJava推奨ディレクトリの場所を手動で設定する必要があります:

• カスタム起動スクリプト、つまりOracleで提供されていない起動スクリプトを使用中の場合。
• java.weblogic.Serverを使用して空のドメインを作成しようとしている場合。

このいずれのケースでも、管理対象サーバーの起動コマンドにjava.endorsed.dirsパラメータを含めてください。

startWeblogic.sh -Djava.endorsed.dirs=ORACLE_HOME/oracle_common/modules/endorsed

ノート:

この項に記述されているオプションではすべて、ORACLE_HOMEを自分のOracle WebLogic Serverインストールの絶対パスに置き換える必要があります。

次のように、startServerを呼び出すときに値をjvmArgsとして渡すか、nmstartを呼び出すときに値をプロパティとして渡すことで、この値を指定することもできます:

wls:/nm/mydomain> prps =
          makePropertiesObject("Arguments=-
Djava.endorsed.dirs=ORACLE_HOME/oracle_common/modules/endorsed")wls:/nm/mydomain> nmStart("AdminServer",props=prps)

管理対象サーバーの起動にノード・マネージャを使用している場合は、WLSTまたはOracle WebLogic Server管理コンソールを使用して、-Djava.endorsed.dirs=ORACLE_HOME/oracle_common/modules/endorsedパラメータをServerStartMBeanのarguments属性に含めることができます。Oracle WebLogic Server管理コンソールを使用している場合は、サーバーの「構成」ページに移動し、「サーバーの起動」タブをクリックして、「引数」フィールドにこのパラメータを入力します。管理サーバーに接続されているWLSTクライアントからstart(server_name 'Server')を呼び出す際、またはOracle WebLogic Server管理コンソールでサーバーの「起動」をクリックした際にこの属性は適用されます。

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

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

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

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

問題

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

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

回避策

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

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

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

• 明示的に@unharvestableとマークされていないMBean属性が収集可能として表示される
  
• 曖昧な監視ルールのObjectNameパターンに関する問題
  
• CreateSystemResourceControlの動作変更
  
• アップグレード・アシスタントを使用してWLDFスキーマのEBRアップグレードを行うと、WLDFアーカイブへの書込みでエラーが発生する可能性がある
  

明示的に@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の動作変更

問題

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

この問題は、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ドメインを停止しておきます。

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

この項では、ノード・マネージャに関する次の問題と回避策について説明します。

• プライマリ・インタフェースの削除がサーバーの移行時にエラーを引き起こす
  
• Oracle HTTP ServerのインスタンスがUNKNOWN状態で開始する
  
• 新しいノード・マネージャのプロパティ名がWLSTオフラインから使用できない
  
• Oracle WebLogic Sever 12.2.1.3.0から14.1.1.0.0にアップグレードすると、nmStartがパーティション・ドメインの管理サーバーの起動に失敗する
  

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

問題

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

プライマリ(リスト内の最初のインタフェース)を削除すると、他の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

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

問題

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

まれに、Oracle WebLogic Serverによって管理されているOracle HTTP Server (OHS)インスタンスが、UNKNOWN状態で開始される場合があります。この状況は、管理サーバーがOHSインスタンスの状態を初期化できない場合に発生することがあります。たとえば、OHSインスタンスの作成時にノード・マネージャが実行されておらず、初回の状態のチェック時に管理サーバーをバイパスして直接ノード・マネージャに接続する場合です。

回避策

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

新しいノード・マネージャのプロパティ名が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 WebLogic Sever 12.2.1.3.0から14.1.1.0.0にアップグレードすると、nmStartがパーティション・ドメインの管理サーバーの起動に失敗する

問題

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

Oracle WebLogic Server 14.1.1.0.0ではパーティションがサポートされないため、Oracle WebLogic Sever 12.2.1.3.0から14.1.1.0.0.にアップグレードされると、nmStartは、パーティション・ドメインの管理サーバーの起動に失敗します。パーティションなしで、通常のクラスタ・ドメインのアップグレードまたはロールバックは、再構成ウィザードの実行後に正常に機能します。

回避策

なし

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

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

Oracle Kodoの問題と回避策

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

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

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

問題

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

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

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

回避策

なし

Oracle WebLogic Serverプロキシ・プラグインの問題と回避策

この項では、様々なOracle WebLogic Serverプロキシ・プラグインに関する次の問題および回避策について説明します:

• HTTP/2プロトコルがバックエンド接続用に構成されている場合、GZIP圧縮は機能しない
  
• HTTP/2のアップグレード中に複数のHTTP2-Settingsヘッダー・フィールドが送信された場合、エラーにならない
  
• 実装されていないメソッドに対して矛盾したHTTPエラー・コードが返される
  
• HTMLリンク事前ロード・オプションが使用されている場合、サーバー・プッシュ機能はサポートされない
  
• WINDOW_UPDATEサイズが0でストリーム・エラーのかわりに接続エラーが報告される
  
• Oracleウォレットを使用したRSASSA-PSSキー・アルゴリズムはサポートされない
  
• IIS用プロキシ・プラグインを使用している場合にapr_socket_connection例外が発生する
  
• 管理対象サーバーによる書込み保護されたドメインの調査に失敗する
  
• SYSPROPによりOVAB StudioでHTTPプロキシ処理を有効にする
  

HTTP/2プロトコルがバックエンド接続用に構成されている場合、GZIP圧縮は機能しない

問題

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

Oracle WebLogic Serverでは、HTTP/2接続でのGZIP圧縮はサポートされていません。リクエストを処理するためにGZIP圧縮を使用するアプリケーションで、次の場合、リクエストは失敗します:

• フロントエンド接続とバックエンド接続の両方でHTTP/2プロトコルが使用される場合。
• フロントエンド接続でHTTP/1.1プロトコルが使用され、バックエンド接続でHTTP/2プロトコルが使用される場合。

回避策

なし

HTTP/2のアップグレード中に複数のHTTP2-Settingsヘッダー・フィールドが送信された場合、エラーにならない

問題

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

この問題は、Apache HTTP Server用Oracle WebLogic Server 14.1.1.0.0プロキシ・プラグインを使用する場合に発生します。

HTTP/1.1からHTTP/2にアップグレードするリクエストには、HTTP2-Settingsヘッダー・フィールドを1つ含める必要があります。このヘッダー・フィールドが存在しない場合、または複数存在する場合、サーバーは接続をHTTP/2にアップグレードできません。また、サーバーはこのヘッダー・フィールドを送信できません。これは予想された動作です。ただし、クライアントがHTTP/1.1からHTTP/2に接続をアップグレードしようとしたときに、複数のHTTP2-Settingsヘッダー・フィールドをApache HTTP Serverに送信すると、Apache HTTP Serverは最初のHTTP2-Settingsフレームを考慮し、残りを無視します。HTTP/2へのアップグレード・リクエストは、エラーなしで成功します。

回避策

なし

実装されていないメソッドに対して矛盾したHTTPエラー・コードが返される

問題

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

この問題は、Apache HTTP Server用Oracle WebLogic Server 14.1.1.0.0プロキシ・プラグインを使用する場合に発生します。

HTTP/1.1以外のプロトコルを使用する場合、Oracle WebLogic Server 14.1.1.0.0で使用されるJavaサーブレット4.0実装は、実装されていないリクエスト・メソッドに対して405 (Method Not Allowed)エラーを返すのではなく、400 (Bad Request)レスポンス・ステータス・コードを返します。そのため、実装されていないメソッドに対するHTTP/2リクエストは、400レスポンス・ステータス・コードになります。

回避策

なし

HTMLリンク事前ロード・オプションが使用されている場合、サーバー・プッシュ機能はサポートされない

問題

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

この問題は、Apache HTTP Server用Oracle WebLogic Server 14.1.1.0.0プロキシ・プラグインを使用する場合に発生します。

次の例に示すように、HTMLリンク・ヘッダーの事前ロード・オプションが使用されている場合、サーバー・プッシュ機能はサポートされません:

<head>
  <meta charset="utf-8">
  <title>JS and CSS preload example</title>

  <link rel="preload" href="style.css" as="style">
  <link rel="preload" href="main.js" as="script">

  <link rel="stylesheet" href="style.css">
  <script type="text/javascript" src="main.js"></script>
</head>

回避策

次のオプションのいずれかを使用します。

• オプション1: アプリケーション・サーバー側のサーブレットまたはJSP Javaコードでレスポンス・ヘッダーを設定します:

  response.setHeader("Link","style.css>; rel=preload; as=style,<main.js>;
  rel=preload; as=script");

• オプション2: httpd.confファイルで必要なリソースを構成します:

  <Location />
    Header add Link "<style.css>;rel=preload"
    Header add Link "<main.js>;rel=preload"
  </Location>

WINDOW_UPDATEサイズが0でストリーム・エラーのかわりに接続エラーが報告される

問題

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

この問題は、Apache HTTP Server用Oracle WebLogic Server 14.1.1.0.0プロキシ・プラグインを使用する場合に発生します。

HTTP/2仕様に従って、受信者は、フロー制御ウィンドウの増分が0 (ゼロ)のWINDOW_UPDATEフレームの受信をPROTOCOL_ERRORタイプのストリーム・エラーとして処理する必要があります。接続フロー制御ウィンドウのエラーは、接続エラーとして処理する必要があります。ただし、Apache HTTP Server用Oracle WebLogic Server 14.1.1.0.0プロキシ・プラグインを使用する場合、増分0のWINDOW_UPDATEフレームがストリーム(0以外のストリームID)に送信されると、Apache HTTP ServerがRST_STREAMフレームではなくGOAWAYフレームを送信し、ストリーム・エラーではなく接続エラーが発生します。

回避策

NA

Oracleウォレットを使用したRSASSA-PSSキー・アルゴリズムはサポートされない

問題

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

Oracleウォレットでは、キー・アルゴリズムとしてのRSASSA-PSSの使用はサポートされません。Oracleウォレットでは、署名アルゴリズムとしてのみRSASSA-PSSがサポートされます。

.jksファイルにRSASSA-PSSアルゴリズムを使用して生成されたキーが含まれている場合、次のコマンドではファイルをウォレットにインポートできません:

<PLUGIN_HOME>/bin/orapki wallet jks_to_pkcs12 -wallet <wallet location>  -keystore <keystore path>  -jkspwd <password>

次のエラー・メッセージが表示されます。

Exception : java.lang.IllegalArgumentException: PublicKey must be one of RSAPublicKey, ECPublicKey, DSAPublicKey or DHPublicKey

回避策

なし

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インスタンスに対して単純なホスト名に設定されている場合。

回避策

なし

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

問題

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

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

回避策

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

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.proxyHost、http.proxyPortおよびhttp.nonProxyHostsを使用して、プロキシ・ホスト、ポートおよび例外を設定できます。Linuxで非標準のデスクトップ環境を使用している場合は、valuehost:portでhttp_proxyプロパティの設定が必要な場合があります。

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

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

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

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

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

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

• StoreBootIdentityは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ動作する
  
• SecurityServiceExceptionでブート時のエラーが発生する
  
• InvalidParameterExceptionメッセージが生成および表示される
  
• SAML 2.0サービス・プロバイダ・サービスで認証とパッシブ属性の両方を有効にするのは無効な構成である
  
• 不十分なエントロピのマシンで乱数ジェネレータが低速になることがある
  
• BEA-090402メッセージの追加情報
  
• LDAPオーセンティケータのログ・メッセージに誤ったURLが表示される
  
• ODI管理対象サーバーの起動時にセキュリティ・エラーが発生する
  
• 互換性レルム・ドメインはOracle WebLogic Server 12.2.1.1クライアントでサポートされない
  
• IPv6プロトコルをサポートするためのweblogic.security.net.ConnectionFilterImplのメソッドの戻りタイプの変更
  

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

問題

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

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

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

回避策

なし

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

問題

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

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

回避策

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

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プロバイダ・サイトで再認証が強制されることはありません。

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

回避策

なし

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

問題

影響を受けるプラットフォーム: 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ファイルを削除しないでください。

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

問題

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

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

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

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

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

回避策

なし

IPv6プロトコルをサポートするためのweblogic.security.net.ConnectionFilterImplのメソッドの戻りタイプの変更

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

問題

14.1.1.0.0では、ConnectionFilterImplメソッドの解析関連メソッドは、int値ではなくBigIntegerを返します。『Oracle WebLogic Server Java APIリファレンス』のクラスConnectionFilterImplメソッドを参照してください。

回避策

なし

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

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

• JRockitで実行している場合にOpenJPA ClassFileTranformerが動作しない
  
• WebLogic Serverにpetclinic.earがデプロイされない
  

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のパッケージ化を修正するようにリクエストを送信済です。

回避策

なし

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

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

• アップグレード時にSQLIntegrityConstraintViolationExceptionが発生する場合がある
  
• ドメインのアップグレード時DefaultIdentityAsserterを手動で構成する
  

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

問題

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

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

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

回避策

なし

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

問題

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

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

回避策

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

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

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

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

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

• WebブラウザでMaxPostSizeExceededExceptionが報告される
  
• 管理コンソールはセッション・タイムアウトの変更を実装できない
  
• PoolLimitSQLExceptionエラーが発生するとデータベース接続が不安定になる
  
• SSLポートを使用してアクセスした場合にWebページを開けない
  
• Internet ExplorerでJSPXページの出力を表示できない
  
• Internet Explorer 7でSVGファイルの出力を表示できない
  
• デプロイメント・プランを使用して2つのディスクリプタをオーバーライドできない
  
• Springの依存関係インジェクションはJSPタグ・ハンドラでサポートされない
  
• 有効なセッションIDでアプリケーションにアクセスしたときに503エラーが発生する
  
• jdbc-connection-timeout-secsを構成するアプリケーションがデプロイに失敗する
  
• WebSocket: 4MB以上のメッセージをサーバーで受信できない
  
• デフォルトJSPエンコーディングがUTF-8に変更された
  
• バージョン2.5より前のJSFベースの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で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モジュールのデプロイメント時に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要素を削除します。

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-1をjsp-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)の問題と回避策

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

• Jythonバージョン2.7.1での動作の変更
  
• 特定の文字を含むプロパティ名はloadPropertiesでサポートされない
  
• Jythonによって作成された無効なcachedirはWLSTがエラーを出力する原因となる
  

Jythonバージョン2.7.1での動作の変更

WLSTスクリプト環境は、Javaのスクリプト・インタプリタである、Jythonに基づいています。Oracle WebLogic Server 14.1.1.0.0では、Jythonバージョンがバージョン2.2.1からバージョン2.7.1にアップグレードされています。Jython 2.7.1では、WLSTスクリプトの誤動作を引き起こす可能性のある新しい動作が導入されています。

次の点に注意してください。

JythonのUnicode文字列が文字列配列の各メンバーの先頭に追加されます

Jython 2.7.1では、デフォルトの文字列タイプのUnicodeを使用します。既存の文字列がu'string'として返されるために、エラーが発生します。文字列値にUnicodeが含まれている場合は、str(x)をコールしてUnicodeをASCIIに変換します。次の例では、host1とhost2の先頭に'u' stringが追加され、str(host)の値がhost1になっています。

java weblogic.WLST
connect('username', 'password', 't3://host:port')
cd('Servers/sysadmin/SingleSignOnServices/sysadmin')
ls()
wls:/domain/serverConfig/Servers/sysadmin/SingleSignOnService
s/sysadmin> cmo.getAllowedTargetHosts()

array(java.lang.String, [u'host1', u'host2'])

wls:/domain/serverConfig/Servers/sysadmin/SingleSignOnService
s/sysadmin> host = cmo.getAllowedTargetHosts()[1]

WebLogic Deploy Toolingのサポートの問題

Oracle WebLogic Server 14.1.1.0.0でのJythonバージョンのアップグレードにより、WebLogic Deploy Tooling 1.4.x以前でOracle WebLogic Server 14.1.1.0.0がサポートされなくなりました。

Jythonスクリプトのアップグレードの失敗

最新のJythonアップグレード・スクリプトを使用している場合、空のZIPファイル(zipfile.py)を作成するとエラーが発生します。いったん閉じてから、追加のために再度開きます。ZIPファイルを開けず、IllegalArgumentExceptionエラーが表示されます。

osに置き換えられたJavaos

Python Libモジュールjavaosは、osモジュールに置き換えられました。

変更前:

import javaos as os

変更後:

import os

main値の使用の変更

mainを入力するための一般的なPEP (Python Enhancement Proposal)標準(Pythonファイルがスクリプトとして実行される場合)では、名前フィールドがスクリプトとして入力されるかどうかを確認してから、main関数をコールします。

Jython 2.2では、__name__フィールドに値mainが含まれています。最新バージョンでは、__name__フィールドに値'__main__'が含まれています。

変更前:

if __name__ == 'main':
	main(sys.argv)

変更後:

if __name__ == '__main__' or __name__ == 'main':
       main(sys.argv)

変更されたJythonスクリプト機能

機能の変更やバグ修正のため、Jythonスクリプト(*.py)に対して次の変更が必要です。

• raiseは、入力として文字列を受け入れなくなりました。このため、次の例に示すように、独自のエラー・タイプを作成する必要があります。

  raise Exception("my exception text")

• ex.printStackTrace()は機能しません。かわりに、次のコマンドを使用します。

  import traceback
  traceback.print_exc()

• 一部の形式のimport関数は、Oracle WebLogic Server 14.1.1.0.0でサポートされているJDK11で常に機能するとはかぎりません。次の形式のimport関数が適切に機能します。

  from some.package import *
  import some.package.*
  
  from some.package import SomeClass
  import some.package.SomeClass

  明示的なfrom形式は、次の例のように最も一貫性があります。

  from weblogic.coherence.descriptor.wl import 
  CoherenceClusterParamsBean

Jython 2.7.0起動時のパフォーマンス低下

Jythonの課題2605を参照してください。

import *は、java.*、jdk.*ネームスペースのJDK9では機能しません

Jythonの課題2362を参照してください。

特定の文字を含むプロパティ名は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=9iがmyapp.db.defaultパッケージに含まれていることを示しますが、そのようなパッケージは存在しないためエラーになります。このパッケージは存在しません。

回避策

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

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

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

この方法は、1レベルのネームスペース(myapp.var1、myapp.var2)であれば機能します。同じ名前をネームスペースとして共有する最上位の変数(myapp=oracleやmyapp.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を別途インストールします。

Webサーバー・プラグインの問題と回避策

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

• MOD_WLS_OHSがフェイル・オーバーしない
  

MOD_WLS_OHSがフェイル・オーバーしない

問題

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

現在、mod_wlとmod_wl_ohsは、コンテナ・レベルのフェイルオーバーのみサポートし、アプリケーション・レベルのフェイルオーバーはサポートしません。mod_wl_ohsは、管理対象サーバーが起動し、実行されているかぎり、ダウンしているアプリケーションにリクエストをルーティングし続けます。クラスタ化されている場合、リクエストは、アプリケーションが停止している場合でも元のセッションが開始したコンテナに送信されるため、通常はhttpエラー404が発生します。

回避策

なし

WebサービスおよびXMLの問題と回避策

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

• スパース配列と部分転送配列はサポートされない
  
• WSDLコンパイラはシリアライズ可能なデータ型を生成しない
  
• コールバックでのカスタム例外の使用
  
• プロキシ・サーバーも使用している環境ではJMSトランスポートを使用できない
  
• WSDLの処理中にclientgenに失敗する
  
• JWSコールバックで2次元XMLオブジェクトを使用している場合のIllegalArgumentException
  
• SoapElement[]を使用すると空の配列になる
  
• Webサービスが別のWebサービスを呼び出す場合のFileNotFound例外
  
• クライアント側がサーバー・レスポンス・メッセージのシグネチャの検証に失敗する
  
• xmlcatalog要素エンティティをリモート・ファイルやアーカイブ内のファイルにできない
  
• ローカルxmlcatalog要素が正常に動作しない
  
• clientgenのxmlcatalog要素で外部カタログ・ファイルを使用できない
  
• WebSphereおよびWebLogic ServerとのWS-AT相互運用性の問題
  
• サーバー・ログにJAX-RSエラー・メッセージが記録されている場合がある
  

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

問題

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

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に対応しています。

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アプリケーションが実行されている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. ...

回避策

このエラー・メッセージは無視してかまいません。

WebLogic Tuxedo Connectorの問題と回避策

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

• VIEWクラスは接続ごとには設定されない
  

VIEWクラスは接続ごとには設定されない

問題

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

VIEWクラスは接続ごとには設定されません。

2つのアプリケーションが、定義は異なるが同じVIEW名を持つVIEWクラスをそれぞれ指定した場合、WebLogic Tuxedo Connectorの共有ハッシュ表は、サーバーで予期しない動作を引き起こすことがあります。Resourceセクション用のハッシュ表に加えて、その接続におけるVIEWクラス用のハッシュ表を用意する必要があります。

回避策

すべてのWebLogic Workshopアプリケーションで定義されている全VIEWクラスに一貫性を持たせます。つまり、同じVIEWクラスを表す場合にのみ同じVIEW名を用いるようにします。

ドキュメントの変更

この項では、次のドキュメントの訂正箇所について説明します:

• java.netリンクの変更
  
• サンプル・ビューアの「検索」機能に関する問題
  
• Avitek Medical Recordsの検索結果に日本語と英語のテキストが表示される
  
• ダウンロードしたライブラリのHTMLページが正しく表示されない
  
• File T3サービスの非推奨情報がWebLogic Server Administration Consoleオンライン・ヘルプにない
  
• 管理コンソール・オンライン・ヘルプにデフォルトのJPA永続性プロバイダの構成ページが誤って表示される
  
• 『継続的統合によるアプリケーションの開発』ガイドのMavenのバージョン番号が正しくない
  

java.netリンクの変更

問題

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

java.netサイトはクローズしました。java.netにこれまでホストされていたほとんどのオープン・ソース・プロジェクトは移転しました。https://javaee.github.ioを参照してください。その他の質問または問題点については、[e-mail]にご連絡ください。

回避策

なし

サンプル・ビューアの「検索」機能に関する問題

問題

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

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ファイルを抽出できません。

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オンライン・ヘルプから削除されます。

回避策

なし

管理コンソール・オンライン・ヘルプにデフォルトのJPA永続性プロバイダの構成ページが誤って表示される

問題

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

Oracle WebLogic Server 12 c (12.2.1.4.0)以降のバージョンでは、管理コンソールのドメインの「構成」→「一般」オプションの下に「JPA」タブはありません。Oracle WebLogic Server管理コンソール・オンライン・ヘルプに、デフォルトのJPA永続性プロバイダの構成ヘルプ・ページが誤って表示されます。

このページは、Oracle WebLogic Serverの将来のリリースでOracle WebLogic Server管理コンソール・オンライン・ヘルプから削除されます。

回避策

なし

『継続的統合によるアプリケーションの開発』ガイドのMavenのバージョン番号が正しくない

問題

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

『継続的統合によるアプリケーションの開発』のMavenを使用したWebLogic ServerのJava EEプロジェクトのビルドの章に、Oracle WebLogic Server 14.1.1.0.0 Maven座標の誤ったプラグイン・バージョン番号が含まれています。プラグインのバージョン番号は12.2.1-0-0ではなく14.1.1-0-0になります。

回避策

なし