2 既知の問題と回避策

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

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

一般的な問題と回避策

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

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

問題

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

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

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

回避策

なし

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

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

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

問題

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

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

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

回避策

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

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

問題

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

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

回避策

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

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

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

問題

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

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

回避策

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

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

問題

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

一部の構成では、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.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フレームワークの初期化

問題

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フレームワークを初期化します。

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

問題

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

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

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

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

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

回避策

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

set WLST_PROPERTIES="-Dfile.encoding=cp850"

$WL_HOME%\common\bin\wlst.cmd

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

問題

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

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

回避策

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

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

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

問題

影響を受けるプラットフォーム: 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へのアクティブ化されていない変更をロールバックします。

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を指定しないと、セキュリティ・ディレクトリ内に正しいファイル・セットがないため、管理対象サーバーの起動に失敗します。

回避策

なし

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

問題

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

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

state(server,'Server')

回避策

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

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

構成後のピュア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形式のアドレスの使用

問題

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

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操作は正常に完了しました」というメッセージが表示される場合があります。

回避策

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

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

問題

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

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

回避策

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

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

問題

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

サーバー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システム・プロパティを使用して設定できます。

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

問題

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

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

回避策

なし

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

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

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

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

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

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

回避策

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

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

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

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

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

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に条件付き判断を追加します。

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

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

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();

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

問題

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

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

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

回避策

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

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

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

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

問題

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

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

回避策

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

EJBに関する問題と回避策

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

Oracle表の主キーがCHARになる

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

問題

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

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

回避策

なし。

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

問題

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

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

回避策

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

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

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

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

問題

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

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

回避策

なし

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

問題

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

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

回避策

なし。

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

問題

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

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

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

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

回避策

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

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

問題

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

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

回避策

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

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

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

回避策

なし

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

問題

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

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

回避策

なし

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

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

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

問題

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

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

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

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

回避策

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

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

問題

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

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

回避策

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

Java EEの問題と回避策

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

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

問題

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

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

回避策

なし

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

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

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

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

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

問題

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

記述子の検証が有効になっていると、デプロイメント記述子の検証に失敗し、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インスタンスを作成し、デフォルト・ストア構成にそのパス名を使用します。マルチバイト文字は使用しないでください。

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

問題

回避策

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

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メッセージング・ブリッジの外部プロバイダとしてJBoss 5を使用すると問題が発生する

問題

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

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

回避策

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

JTAの問題および回避方法

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

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

問題

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

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

回避策

なし

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

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

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

問題

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

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

回避策

なし

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ホーム・ディレクトリ・パスを反映します。

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

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

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状態で開始する

問題

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

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

回避策

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

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 WebLogic Serverプロキシ・プラグインに関する次の問題および回避策について説明します:

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プロキシ・プラグインを使用する場合、増分0WINDOW_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

回避策

なし

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

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

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

問題

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

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

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

回避策

なし

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>

互換性レルム・ドメインは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メソッドを参照してください。

回避策

なし

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

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

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ページに進むことができます。

デプロイメント・プランを使用して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要素を削除します。

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

問題

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

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

回避策

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

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

問題

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

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

回避策

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

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

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

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

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

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に変換します。次の例では、host1host2の先頭に'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を参照してください。

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

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

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

問題

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

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

回避策

なし

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

問題

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

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

回避策

なし

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

問題

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

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

回避策

コールバックで使用されるカスタム例外が、親Webサービスのターゲット・ネームスペースと一致するパッケージに含まれていることを確認してください。

プロキシ・サーバーも使用している環境ではJMSトランスポートを使用できない

問題

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

プロキシ・サーバーを使用している環境では、JMS転送を使用できません。その理由は、JMSトランスポートの場合、Webサービス・クライアントは常にT3プロトコルを使用してWebサービスに接続し、プロキシ・サーバーはHTTP/HTTPSのみを受け入れるためです。

回避策

なし

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

問題

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

複合タイプhttp://www.w3.org/2001/XMLSchema{schema}をWebサービス・パラメータとして使用するWSDLを処理しているときに、clientgenが失敗します。

回避策

なし

JWSコールバックで2次元XMLオブジェクトを使用している場合のIllegalArgumentException

問題

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

JWSコールバックで2次元のXmlObjectパラメータ(XmlObject[][])を使用すると、IllegalArgumentExceptionエラーが発生します。

回避策

回避策はありません。

SoapElement[]を使用すると空の配列になる

問題

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

@WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE)でWebサービス・パラメータとしてSoapElement[]を使用すると、クライアントで常に空の配列が生成されます。

回避策

SOAPElement[]のデフォルト・バインディングをWildcardParticle.ANYTYPEに変更する際に、@WildcardBindingアノテーションを使用しないようにしてください。SOAPElement[]のデフォルト・バインディングがWildcardParticle.ANYに設定されます。

Webサービスが別のWebサービスを呼び出す場合のFileNotFound例外

問題

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

Webサービス'A'からWebサービス'B'を呼び出す場合には、Webサービス'A'で@ServiceClientアノテーションを使用する必要があります。Webサービス'B'がWebサービス'B'のWSDLにアタッチされていないカスタム・ポリシー・ファイルを必要とする場合、Webサービス'A'は実行に失敗します。Webサービス'A'はこのポリシー・ファイルを/Web-Inf/classes/policies/filename.xmlで検索します。ポリシー・ファイルがその場所に存在しないため、Oracle WebLogic Serverではファイルが見つからないという例外がスローされます。

回避策

WebサービスBにカスタム・ポリシー・ファイルを添付してください。次に例を示します。

@Policy(uri="CustomPolicy.xml",
        attachToWsdl=true)
public class B {
  ...
}

クライアント側がサーバー・レスポンス・メッセージのシグネチャの検証に失敗する

問題

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

セキュリティ・ポリシーに以下のいずれかのトークン・アサーションが含まれている場合、クライアント側でサーバーのレスポンス・メッセージの署名の検証に失敗する可能性があります。

  <sp:WssX509PkiPathV1Token11/>
  <sp:WssX509Pkcs7Token11/>
  <sp:WssX509PkiPathV1Token10/>
  <sp:WssX509Pkcs7Token10/>

また、<sp:WssX509Pkcs7Token11/>または<sp:WssX509Pkcs7Token10/>トークン・アサーションのX509証明書のチェーンに3つ以上の証明書が存在する場合、サーバー側で受信メッセージの署名の検証に失敗する可能性があります。

証明書チェーン全体がクライアント側に残っていなければ、次のようなポリシーはサポートされません。

<sp:AsymmetricBinding>
   <wsp:Policy>
      <sp:InitiatorToken>
         <wsp:Policy>
            <sp:X509Token
               sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>

            <wsp:Policy>
               <sp:WssX509Pkcs7Token11/>
            </wsp:Policy>
         </sp:X509Token>
      </wsp:Policy>
      </sp:InitiatorToken>
      <sp:RecipientToken>
      <wsp:Policy>
      <sp:X509Token sp:IncludeToken='. . ./IncludeToken/Never'>
            <wsp:Policy>
               <sp:WssX509Pkcs7Token11/>
            </wsp:Policy>
         </sp:X509Token>
      </wsp:Policy>
      </sp:RecipientToken>
   . . .
      </wsp:Policy>
   </sp:AsymmetricBinding>

回避策

次のいずれかの解決策を使用します:

  1. WssX509PkiPathV1Token11/>のかわりに<sp:WssX509V3Token10/>トークン・アサーションを使用してレスポンスを構成します。ポリシーは次のようになります。
    <sp:AsymmetricBinding>
       <wsp:Policy>
         <sp:InitiatorToken>
            <wsp:Policy>
            <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
               <wsp:Policy>
                  WssX509PkiPathV1Token11/> 
               </wsp:Policy>
            </sp:X509Token>
            </wsp:Policy>
         </sp:InitiatorToken>
         <sp:RecipientToken>
            <wsp:Policy> sp:IncludeToken='. . ./IncludeToken/Never'>
            <sp:X509Token
               <wsp:Policy>
                  <sp:WssX509V3Token10/>
               </wsp:Policy>
            </sp:X509Token>
            </wsp:Policy>
         </sp:RecipientToken>
    . . .
         </wsp:Policy>
       </sp:AsymmetricBinding>
    
  2. WssX509PkiPathV1Token11/>トークン・アサーションを使用してレスポンスを構成しますが、それをメッセージ内に含めます。ポリシーは次のようになります。
     <sp:AsymmetricBinding>
       <wsp:Policy>
         <sp:InitiatorToken>
            <wsp:Policy>
            <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
            <wsp:Policy>
               WssX509PkiPathV1Token11/> 
            </wsp:Policy>
            </sp:X509Token>
         </wsp:Policy>
         </sp:InitiatorToken>
         <sp:RecipientToken>
            <wsp:Policy>
            <sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToInitiator'>
               <wsp:Policy>
                  WssX509PkiPathV1Token11/>
                </wsp:Policy>
            </sp:X509Token>
            </wsp:Policy>
         </sp:RecipientToken>
     . . .
       </wsp:Policy>
     </sp:AsymmetricBinding>
    

X509証明書チェーンに複数の証明書が存在する場合は、<sp:WssX509Pkcs7Token11/>または<sp:WssX509Pkcs7Token10/>のかわりに、<sp:WssX509PkiPathV1Token11/>または<sp:WssX509PkiPathV1Token10/>を使用する必要があります。

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

問題

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

build.xmlファイルのxmlcatalog要素では、エンティティの場所がローカル・ファイル・システム上のファイルである必要があります。リモート・ファイル(http:など)やアーカイブ内のファイル(jar:など)は使用できません。

回避策

必要であれば、リモート要素をカタログ・ファイル内のエンティティとして定義します。

ローカルxmlcatalog要素が正常に動作しない

問題

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

ローカルのxmlcatalog要素がAntの制限のために正しく機能しません。

回避策

Antのbuild.xmlファイルで、ローカル要素をclientgen(wsdlc)タスクより上に定義するか(同じターゲットの場合)、要素をターゲットの外部に定義する必要があります。

clientgenのxmlcatalog要素で外部カタログ・ファイルを使用できない

問題

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

clientgenタスクのxmlcatalog要素で外部カタログ・ファイルを使用できません。たとえば、次のAntビルド・ファイルのスニペットは機能しません:

<clientgen ...
  <xmlcatalog>
    <catalogpath>
      <pathelement location='wsdlcatalog.xml'/>
    </catalogpath>
  </xmlcatalog>

これはAnt XMLカタログの制限です。

回避策

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

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

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

問題

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

JAX-RSアプリケーションが実行されているOracle WebLogic Serverインスタンスを停止すると、サーバー・ログに次のエラー・メッセージが記録されていることがあります:

<Error>
<org.glassfish.jersey.server.internal.monitoring.MonitoringStatisticsProcessor
> <BEA-000000> <Exception thrown when provider class 
org.glassfish.jersey.server.internal.monitoring.MonitoringFeature$StatisticsLi
stener was processing MonitoringStatistics. Removing provider from further
processing. ...

回避策

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

WebLogic Tuxedo Connectorの問題と回避策

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

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

問題

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

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

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

回避策

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

ドキュメントの変更

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

java.netリンクの変更

問題

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

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

回避策

なし

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

問題

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

Windowsの「スタート」メニューからサンプル・ドキュメントにアクセス(「Oracle WebLogic」を選択し、「WebLogic Server」をクリックして「例」を選択し、「ドキュメント」をクリック)すると、サンプル・ビューアの「検索」機能が動作しません。

回避策

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

Avitek Medical Recordsの検索結果に日本語と英語のテキストが表示される

問題

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

サンプル・ビューアの「検索」機能では、Avitek Medical Recordsトピックの日本語バージョンと英語バージョンが両方表示された結果が返されることがあります。

回避策

なし

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

問題

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

http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.htmlから入手可能なOracle WebLogic Serverドキュメント・ライブラリのZIPファイルを解凍した後、場合によっては次のライブラリのHTMLページが正しく表示されないことがあります:

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

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

  • E14571_01 (Oracle WebLogic Server 10.3.3ドキュメント・ライブラリ)

回避策

ライブラリE12840-01の場合、E12840_01.zipライブラリ・ファイルを抽出した後で、HTMLページが正しく書式設定されない場合は、次のステップを実行します。

  1. Zipファイルを抽出したディレクトリに移動します。
  2. ディレクトリ構造で/global_resourcesディレクトリを探します。
  3. /global_resourcesディレクトリを同じドライブのルート・ディレクトリにコピーします。

ライブラリE12839-01およびE14571-01の場合、この問題はWindowsオペレーティング・システムでのみ発生します。抽出したライブラリのHTMLページが正しく書式設定されない場合は、解凍ユーティリティで別の抽出オプションを使用してZIPファイルを抽出します。たとえば、7-Zipを使用してファイルを抽出している場合は、フル・パス名オプションを選択します。Windows解凍ユーティリティではライブラリZIPファイルを抽出できません。

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になります。

回避策

なし