| Oracle® Fusion Middleware Oracle WebLogic Serverリリース・ノート 12cリリース1 (12.1.1) B65962-02 |
|
 前 |
この章では、Oracle WebLogic Serverに関連する問題について説明します。この節は、以下のトピックで構成されています。
この項で示される問題は、WebLogic Server 12.1.1のJDK 7認証テスト中に見つかったものです。この問題は、WebLogic Server 12.1.1を2012年3月15日以降にダウンロードした場合は、該当しません。
プラットフォーム: すべて
WebLogic Server 12.1.1では、(!)をワイルドカードとともにweblogic.vsee.verbose.subcomponentsで使用すると、フィルタリングが必要なSOAPメッセージがデバッグ・ログにダンプされる原因になります。たとえば、次のフィルタを使用している場合:
weblogic.wsee.connection.soap.*,!weblogic.wsee.connection.soap.SoapConnectionMessage*
SoapConnectionMessagesがデバッグ・ログにダンプされていると、ビジネス・ロジックによる処理にSOAPメッセージ・コンテンツを使用できなくなります。
回避策
この問題が発生した場合は、パッチ13641115をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、WebLogic ServerをJDK 7u2とともに使用すると、様々なSSLエラーが発生する場合があります。このエラーにはタイムアウト、SSLHandshakeExceptions、InvalidKeyExceptionsおよびEOFExceptionsがあります。
回避策
パッチ13391585をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、展開したEARのサブモジュールをJMSサーバーにデプロイした後、サブモジュールをデプロイ解除しようとすると、デプロイ解除が失敗します。
回避策
パッチ13424251をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
JDK 7をWebLogic Server 12.1.1とともに使用すると、次のSSLExceptionがnodemanger.logファイルに記録される場合があります。
Uncaught exception in server handlerjavax.net.ssl.SSLException: Error generating DH server key exchange
これは、512バイトの公開鍵を持つWebLogic Serverデモンストレーション証明書または別の証明書を使用している場合のみ、発生します。JDK 7には1024バイトの公開鍵を持つ証明書が必要です。
回避策
次のいずれかの回避策を使用します。
パッチ13421471をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
1024バイトの公開鍵を持つ証明書を使用します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、アプリケーションのデプロイ中にバグが見つかると、不要なIllegalStateExceptionが記録される場合があります。
回避策
パッチ13603813をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、ターゲット・モジュールの再デプロイが以前行われているエンタープライズ・アプリケーションをデプロイ解除すると、NullPointerExceptionが発生します。
回避策
次のいずれかの回避策を使用します。
パッチ13603813をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
ターゲット・モジュール操作を使用するのではなく、アプリケーション全体を再デプロイします。
プラットフォーム: すべて
WebLogic Server 12.1.1で、EAR共有ライブラリを参照するEARをデプロイする際、EARライブラリ内のJava/JARモジュールがEARライブラリのルート内を除くいずれかの場所に存在すると、ModuleExceptionが発生します。
回避策
次のいずれかの回避策を使用します。
パッチ13516712をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
library-refタグを使用するかわりに、共有ライブラリをアプリケーション・アーカイブに追加します。
EARライブラリのJava/JARモジュールをEARライブラリのルートに再配置します。
プラットフォーム: すべて
WebLogic Server 12.1.1でJAX-WS Webサービスを作成する際、EJBとして実装されている@WebServiceProviderサービス・プロバイダを使用すると、jwsc構築プロセスは成功しますが、サービスは標準サーブレット・サービスとして生成されます。
回避策
パッチ13361720をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、UNCパスを使用してアプリケーションをデプロイするとFileNotFoundExceptionが発生します。
回避策
パッチ13019800をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1管理コンソールを使用してデータ・ソースを作成する際、「その他」が「データベースのタイプ」として選択されている場合、「次」をクリックするとエラーを修正する必要があります。というメッセージが生成され、データ・ソースは作成できません。
回避策
管理コンソールで、その他のドライバ・タイプを選択して、データ・ソースを作成するプロセスを完了します。「接続のテスト」ページで、ドライバ名とURLの形式を、対象のドライバに該当するものに変更します。
この項のCDIの問題は、WebLogic Server 12.1.1を2012年3月15日以降にダウンロードした場合は、該当しません。
プラットフォーム: すべて
Contexts and Dependency Injection (CDI)をWebLogic Server 12.1.1で使用する際、管理コンソールからアプリケーションを起動および停止した後は、BeanマネージャがJNDIツリーに存在しなくなります。
回避策
パッチ13603813をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、トランザクション・フィルタを適用してイベントを観察するEJBアプリケーションをデプロイおよび実行する際、WELD-000401エラーが発生してオブザーバにもイベント・エラーが通知されます。
回避策
パッチ13603813をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、Contexts and Dependency Injection (CDI)アプリケーションでは分割ディレクトリ・アプリケーションに指定されているディレクトリのすべてが選択されるわけではないため、WELD-001408エラーが発生します。
回避策
パッチ13603813をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
プラットフォーム: すべて
WebLogic Server 12.1.1で、weblogic-application.xml内に次のエントリがあるアプリケーションをデプロイすると、アプリケーションのデプロイはValidationError: Unable to find a default providerによって失敗します。
<prefer-application-resources>
<resource-name>META-INF/services/*</resource-name>
</prefer-application-resources>
回避策
パッチ13603813をダウンロードしてインストールします。この値をMy Oracle Supportの「パッチと更新版」タブで、パッチ番号の検索フィールドに入力します。
この項のデプロイメント・パフォーマンスの問題は、WebLogic Server 12.1.1を2012年3月15日以降にダウンロードした場合は、該当しません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
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()
プラットフォーム: すべて
Oracle ojdbc14.jarファイルは、JDK 5または6で使用するため、ojdbc6.jarに変更されました。この結果、ojdbc14.jarへの明示的な参照はすべて、ojdbc6.jarへ変更する必要があります。
プラットフォーム: すべて
このリリースのWebLogic Serverでの強力なパスワードの適用(8文字以上で、1つの数値または特殊文字を含む)の実装により、既存のスクリプトで問題が発生する可能性があります。
回避策
次のいずれかの回避策を使用して、新しいパスワード制限をバイパスします。
BACKWARD_COMPAT_PW_CHECK環境変数をtrueに設定します。
WLSTを呼び出す際に-Dbackward.compat.pw.check=trueオプションを含めます。
この変数とオプションはWebLogic Serverの将来のリリースで削除されるため、新しいパスワード要件を満たすようにパスワードを変更することをお薦めします。
プラットフォーム: すべて
idという名前の属性にnull値が返されるため、MDSリポジトリを使用するアプリケーションは、WebLogic ServerにバンドルされているJAXBバージョンでデプロイまたは実行できません。
回避策
サーバーを英語ロケールで起動します。
プラットフォーム: Linux
管理サーバーに対して構成されているファイル記述子の最大数が65535未満の場合、WebLogic Server管理サーバーは、Enterprise Manager (EM)コンソールで「開いているファイルが多すぎます」のメッセージをレポートします。
回避策
次のコマンドを実行して、現在構成されているファイル記述子の最大数を確認します。
cat /proc/sys/fs/file-max
値が65535未満の場合は、次の手順を実行します。
ルート権限でファイル/etc/security/limits.confを編集します。
> sudo vi /etc/security/limits.conf
65535以上の値を使用して、次の2行を追加します。
* soft nofile 65535 * hard nofile 65535
新しいターミナル・セッションを開始します。
limit descriptorsコマンドを実行して、記述子が指定した値(65535以上)に増やされたことを確認します。
> limit descriptors descriptors 65535
プラットフォーム: AIX
weblogic.aspects.AspectJClassLoaderは、IBM Java 6を使用しているAIXではサポートされません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
WebLogic Server管理コンソールを使用してデプロイメントの特定の記述子値をオーバーライドする場合、これらの値はデプロイメントのデプロイメント・プラン・ファイルで変数のオーバーライドとして表現されます。設定後に、管理コンソールを使用してこれらの変数の値を変更できますが、管理コンソールを使用して削除することはできません。
回避策
デプロイメント・プランXMLファイルを直接編集します。管理コンソールを介してオーバーライドを作成する前の記述子設定に戻す必要がある場合は、変数および変数割当て句を削除します。
プラットフォーム: すべて
キャッシュされたJDBC文に関する情報が、JDBCの「モニター」ページに表示されません。
プラットフォーム: すべて
管理コンソールでページ・フローが完了すると、別のページ(通常は表)に進みます。
この時点でブラウザの「戻る」ボタンをクリックすると、完了したアシスタント内の最後のJSPファイルのロードが試行されます。この時点で、このアシスタントのコンテキストはすべて破棄されます。
回避策
変更がキャンセルされるか完了した後は、アシスタントに戻るためにブラウザの「戻る」ボタンを使用しないことをお薦めします。また、アシスタント内の前の手順に戻らないこともお薦めします。代わりに、管理コンソールのナビゲーション・リンクおよびボタンを使用してください。
プラットフォーム: すべて
管理コンソールでは、サポートされておらず想定どおりに機能しないワーク・マネージャの構成を作成することができます。不適切なワーク・マネージャ構成があるとサーバー・ログに多数の例外が記録されます。最も多いのは、デプロイメント記述子の解析中に発生する「Validation problems were found」例外です。
回避策
ワーク・マネージャ構成に関するオンライン・ヘルプのガイドラインに従ってください。特に、特定のワーク・マネージャに割り当てられるリクエスト・クラスは1つだけです。リクエスト・クラスのスコープはワーク・マネージャと同じかそれより広くする必要があります。アプリケーション・スコープのリクエスト・クラスをグローバルなワーク・マネージャに割り当てないでください。また、アプリケーション・スコープのワーク・マネージャに対して複数のアプリケーション・スコープのリクエスト・クラスを作成しないでください。
ワーク・マネージャの構成を記載されている制約に従って修正すれば、これらの問題は解決します。
プラットフォーム: すべて
「クラスタ: 監視: サマリー」ページの「サーバー・ステータス」表には、「プライマリ」と「セカンダリ分散名」の2つのデフォルトの列があります。レプリケーションのシナリオによっては、これらのフィールドに、「クラスタ:モニター:フェイルオーバー」ページで修正および表示されたすべてのレプリケーション統計が反映されない場合があります。
詳細情報については、「クラスタ: 監視: フェイルオーバー」ページを参照してください。
プラットフォーム: すべて
別のライブラリ・デプロイメントで定義された型を参照しているEJBデプロイメントに対して、管理コンソールでセキュリティ・ポリシーを定義するとき、そのライブラリ・デプロイメントをConsoleから使用できない場合に、例外が発生する可能性があります。
回避策
すべてのライブラリ・デプロイメントは、WebLogic Server管理サーバーと、アプリケーションの参照をサポートするために必要な任意の管理対象サーバーをターゲットにする必要があります。こうすると、ポリシーを定義するときに、必要に応じて参照された型をクラス・ローディングするために、Consoleがそれらのライブラリ・デプロイメントにアクセスできるようになります。
プラットフォーム: すべて
管理コンソールに、デプロイメント・プランに加えられた外部の変更が反映されない場合があります。ユーザーがコンソールでデプロイメント・プランを表示しているときに、コンソールの外部でデプロイメント・プランに変更が加えられた場合(たとえば、Workshopを使用する、プランのテキスト・ファイルを直接編集する、WLSTやWebLogic.Deployerを使用して新しいプランでデプロイメントを更新する場合など)、その変更はコンソールに表示されません。
回避策
別のデプロイメントの構成ページに移動してから、元のデプロイメントに再び戻ってください。
プラットフォーム: すべて
Oracle OCIドライバは、管理コンソールに事前構成済ドライバ・タイプとして明示的にリストされなくなりました。
回避策
Oracle OCIドライバは、アプリケーション・データ接続用にサポートされるドライバとして残り、以前のリリースのOracle WebLogic Serverと一貫性があります。ただし、ユーザーは、データベース・ユーザー名など、すべての必要な構成プロパティを手動で指定する必要があります。
プラットフォーム: すべて
Internet Explorer 7(IE 7)を使用して「監視ダッシュボード」の「メトリック・ブラウザ」タブにデータを表示する場合、データの表示に異常に長い時間がかかり、この間、ページが応答しなくなります。このタブでのデータの表示にかかる時間は、ドメインのサイズによって決まります。
回避策
「監視ダッシュボード」→「メトリック・ブラウザ」タブにデータを表示する必要がある場合は、Internet Explorer 8以上、Firefox 3以上、Safari 4以上など、IE 7以外のサポートされるWebブラウザで管理コンソールを開きます。
このリリースのWebLogic Serverには、Apache Beehiveサポートの既知の問題はありません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
Fusion Middleware製品のインストールを開始する前に既存のJAVA_OPTIONSがインストール環境に含まれている場合、ASProvWorkflowExceptionが原因でドメインが作成されないことがまれにあります。
回避策
Fusion Middleware製品のインストールを開始する前に、既存のJAVA_OPTIONSをクリアします。これらのJAVA_OPTIONSを使用するアプリケーションが環境内にある場合、アプリケーションはオプションをクリアした後で動作しなくなることがあります。この場合は、既存のJAVA_OPTIONSをテキスト・ファイルに保存し、他のアプリケーションを実行するための代替方法を調べます。
プラットフォーム: 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%\wlserver_10.3\common\bin\wlst.cmd
プラットフォーム: MS Windows
一部のMicrosoft Windowsプラットフォームでは、WebLogic構成ツール・コマンド(wlst、config、pack、unpackなど)は、WebLogicインストール・パスに空白が含まれている場合に失敗することがあります。この場合、コマンドは、クラスが空白の後のインストール・パスの部分から導出されるjava.lang.ClassNotFoundExceptionで失敗することがあります。コマンドは、Windowsレジストリで短いファイル名の生成が無効になっている場合に失敗します。
回避策
構成ツールで空白が正しく処理されるようにするには、Windowsレジストリで短い名前の生成を有効にする必要があります。短い名前の生成を有効にするには、次のようにします。
regeditを実行します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemフォルダに移動します。
NtfsDisable8dot3NameCreationをダブルクリックし、その値を0に設定します。
変更を反映するには再起動します。
プラットフォーム: Linux
存在しないサーバー名でWebLogic Server管理サーバーに接続しようとすると、存在しないサーバー名のディレクトリがdomain_name/serversディレクトリの下に作成されます。
回避策
管理サーバーに接続する際に有効な名前を指定します。
プラットフォーム: Linux
WebLogicパスワードの入力直後に[Ctrl]+[C]を押してstartManagedWebLogic.shプロセスを終了した後で、ターミナル・ウィンドウで異常な動作が発生することがあります。たとえば、[Return]を押すと、プロンプトが次の行に移動するかわりにタブ移動し、プロンプトに入力した文字がターミナルに表示されません。
回避策
現在のxtermを終了して新規に開始するか、xtermにstty echoと入力します。
プラットフォーム: Linux
次の場合には、WebLogic Serverドメインの作成または更新に長時間かかることがあります。
インストールにサーバー例が含まれている場合にUNIXまたはLinuxオペレーティング・システムにWebLogic Serverをインストールする場合。
WebLogic Server構成ウィザードを使用してドメインを作成または変更する場合。
WLSTを使用してドメインを作成または変更する場合。
回避策
CONFIG_JVM_ARGS環境変数を次の値に設定します。
-Djava.security.egd=file:/dev/./urandom
プラットフォーム: Linux
Linuxシステムでは、Oracle Fusion Middleware構成ウィザードで新規ドメインを作成する際に、「パスワード」および「パスワードの確認」フィールドが編集不能になることがあり、ドメインを作成するためのパスワードを入力できません。
回避策
この問題を回避するには2つの方法があります。
問題が発生するたびに回避するには、構成ウィザードの右上にある「ウィンドウを閉じる」(X)ボタンをクリックします。表示される確認ダイアログで、「いいえ」をクリックして構成ウィザードに戻ります。その後で、ドメインのパスワードを入力および確認できます。
この問題を永続的に解決するには、次のようにします。
すべてのscimプロセスを強制終了します。次に例を示します。
kill `pgrep scim`
ファイル~/.scim/configを変更(または作成)して、次の行を含めます(大文字と小文字は区別されます)。
/FrontEnd/X11/Dynamic = true
VNCを実行している場合は、VNCサーバーを再起動します。
構成ウィザードをもう一度実行します。
このリリースのWebLogic Serverには、拡張の既知の問題はありません。
この項では、次の問題と回避策について説明します。
プラットフォーム: AIX、Solaris X64、SPARC
オープン・ファイル記述子の数に対するオペレーティング・システムのulimit値がunlimitedに設定されている場合、ドメイン内のノード・マネージャ、管理サーバーまたは管理対象サーバーで起動が失敗、あるいは実行が停止する場合があります。
回避策
WebLogic Serverの起動に使用されているユーザー・アカウントに対して、オペレーティング・システムのulimit値をunlimited以外に設定します。次に例を示します。
ulimit -n 1024
プラットフォーム: すべて
管理対象サーバーの1つをホストするマシンが突然停止される、ネットワーク・カードが取り外される、またはネットワーク・インタフェース・カードに問題がある場合に、サーバーがその管理対象サーバーと通信しようとすると、スレッドが接続の確立を待機したままスタックします。
回避策
現在は、この問題を解決するには、次のプライベート・フラグを使用し、
-Dweblogic.client.SocketConnectTimeoutInSecs
適切なタイムアウト値を設定します。接続を確立しようとしているスレッドが解放され、リクエストがすぐに失敗するようになります。
プラットフォーム: すべて
WebLogic ServerでIPv6フォーマットのアドレスを使用する場合は、URLのホスト・アドレス部分に大カッコ([および])を含める必要があります。そうしないと、WLSTは実行中のサーバーに接続できません。
回避策
ホスト・アドレスに大カッコを追加してください。次に例を示します。
t3://[fe80:0:0:0:203:baff:fe2f:59e5]:9991
プラットフォーム: すべて
クラスタ・サーバーのサーバー全体の移行が行われるときにWebLogic Server管理サーバーが停止していて、サーバーがそれまでに一度も実行されていないマシンに移行される場合、サーバーを新しいマシンで起動できません。
回避策
この問題には次のいずれかの回避策を使用してください。
サーバーの移行の実行中は必ず管理サーバーを稼働させておきます。
クラスタ内のすべての移行可能サーバーで共有のディスク/NFSを使用します。
プラットフォーム: すべて
J2EEアプリケーションでFastSwapを有効にしている場合、デプロイメント中にJavaクラスに対して特定の変更を行うと、再デプロイせずにその変更を確認することができますが、その際、Javaオブジェクトのすべてのインスタンスの状態は保持されます。
オブジェクトの状態が保持されないケースとして、フィールド名の変更があります。これは次のように処理されます。
古い名前のフィールドが削除される
新しい名前のフィールドが追加される
したがって、この場合、古いフィールドの状態はすべて、名前変更後のフィールドに持ち越されません。
WorkshopまたはFastSwap antタスクを使用すると、インスタンス・フィールド名の変更により値がリセットされた場合でも、「FastSwap操作は正常に完了しました」というメッセージが表示される場合があります。
回避策
インスタンスの値がリセットされることを踏まえた上でフィールド名を変更してください。
プラットフォーム: すべて
次の条件は、JNDIが非常に頻繁に更新される原因となることがあり、JMSサブスクライバはjava.naming.NameNotFoundExceptionを検出することがあります。
クラスタ通信にユニキャスト・メッセージングが使用されている。
JMSトピック接続がsetReconnectPolicy("all")で設定されている。
トピックのJMS恒久サブスクライバが非常に頻繁に作成および削除される。
回避策
この問題を解決するために、新しいプロパティMessageOrderingEnabledがClusterMBeanに追加されています。このプロパティは、ユニキャスト・メッセージを強制的に厳密な順序で処理するようにします。デフォルトでは、このプロパティは有効化されていません。プロパティを有効化するには、次の行をconfig.xmlの<cluster>要素に手動で追加します。
<message-ordering-enabled>true</message-ordering-enabled>
プラットフォーム: すべて
ホスト名を使用してWebLogic Server管理サーバーまたは管理対象サーバーのリスニング・アドレスの構成を指定する場合、複数のイーサネット・カードで構成されたマシンは、起動後に別のホスト名でリスニングすることがあります。次に例を示します。
マシンに3つのイーサネット・カードがあります。
カード1はhostname1-s(DNS登録ホスト名)にマップされています。
カード2はhostname1-i(DNS登録ホスト名)にマップされています。
カード3はhostname1(実際のノードのホスト名)にマップされています。
hostname1でリスニングするようにサーバーを構成します。
Windowsは実際のノードのホスト名を最初に有効になったイーサネット・カード・アドレスに解決するため、サーバーは起動後にhostname1-sでリスニングします。
回避策
この問題には次の3つの回避策のいずれかを使用します。
WebLogic Server管理サーバーのリスニング・アドレスとして、ホスト名ではなくIPアドレスを使用します。管理対象サーバーで、IPアドレスをリスニング・アドレスとして使用するか、実際の物理ホスト名をマシンの最初のイーサネット・カードに構成します。
マシンのC:\Windows\system32\drivers\etc\hostsファイルに次のエントリを追加します。
<ip_address> <hostname>
マシンのネットワーク・カードの順序を変更して、実際のノードのホスト名を持つカードがカード1になるようにします。
プラットフォーム: Linux
コマンド・ラインから正しくないWebLogic Server管理サーバーURLを指定して管理対象サーバーを起動した場合(つまり、管理サーバーが指定されたURLに到達できない場合)、管理対象サーバーは管理対象サーバー独立(MSI)モードで起動します。
この場合、管理サーバーとノード・マネージャは管理対象サーバーのステータスを追跡できません。管理コンソールには、管理対象サーバーのステータスがUNKNOWN(不明)と表示されますが、サーバーは実際にはMSIモードでRUNNING(実行中)です。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
MS SQLServerにJDBCドライバを使用している場合、getTransactionIsolation()が最初に呼び出されると、setTransactionIsolation()がトランザクション・コンテキストで失敗することがあります。
プラットフォーム: すべて
新しいシステム・プロパティ-Dweblogic.jdbc.remoteEnabledが、Oracle WebLogic Server 10.3.2のJDBCに追加されています。以前のリリースのWebLogic Serverとの互換性を保つために、このプロパティのデフォルト設定はtrueになっています。このプロパティがfalseに設定されている場合、リモートJDBCアクセスはオフになり、このようなアクセスによって例外が発生します。
リモート・アクセスは、アプリケーションで明示的に行われる場合と、LLR、1PCまたはEmulate XAグローバル・トランザクション・オプションで構成された非XAデータ・ソースが参加しているグローバル(XA/JTA)トランザクション中に暗黙的に行われる場合があります。例外がスローされるケースと、各ケースの回避策(存在する場合)を次に示します。
次のケースでは例外が発生します。特定のケースの回避策(存在する場合)を示します。
スタンドアロン・クライアント・アプリケーションで任意のタイプのデータ・ソースを使用している場合。
WebLogic Serverにホストされているアプリケーションが任意のタイプのデータ・ソースを使用し、データ・ソースがローカルに構成(ターゲット指定)されていない場合。可能な回避策は、データ・ソースをローカルにターゲット指定することです。
同じグローバル・トランザクションの複数のWebLogic Serverインスタンスで、LLR、1PCまたはEmulate XAのトランザクション・オプションを使用して同じ名前の非XAデータ・ソースにアクセスしている場合。この場合は、可能な回避策が2つあります。
XAを使用するようにデータ・ソースを変更します(これによりパフォーマンスが低下することがあります)。
1PC/emulateXAタイプの場合は、データ・ソースが単一のサーバーからアクセスされるようにアプリケーションを変更します。
トランザクション・コーディネータとは異なるサーバー上でLLRトランザクション・オプションを使用して非XAデータ・ソースにアクセスしている場合。サーバーが開始したトランザクションの場合、コーディネータの場所はトランザクションに最初に参加しているリソースに基づいて選択されます。この場合は、可能な回避策が2つあります。(a) XAを使用するようにデータ・ソースを変更します(これによりパフォーマンスが低下することがあります)。(b)『Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング』のLLRでのパフォーマンスの最適化に関する項の説明に従って、データ・ソースがトランザクション・コーディネータでアクセスされるようにアプリケーションを変更します。後者の方法は使用できない場合があります。たとえば、MDBアプリケーションがリモートWebLogic JMSサーバーからメッセージを受信する場合、トランザクション・コーディネータは常にJMSサーバーをホストしているWebLogicサーバーになりますが、MDBアプリケーションを同じWebLogicサーバーに移動できないことがあります。
XAを使用するようにデータ・ソースを変更します(これによりパフォーマンスが低下することがあります)。
『Oracle WebLogic Server JTAのプログラミング』のLLRでのパフォーマンスの最適化に関する項の説明に従って、データ・ソースがトランザクション・コーディネータでアクセスされるようにアプリケーションを変更します。この回避策は、場合によっては使用できないことがあります。たとえば、MDBアプリケーションがリモートWebLogic JMSサーバーからメッセージを受信する場合、トランザクション・コーディネータが常にJMSサーバーをホストしているWebLogicサーバー・インスタンスになりますが、MDBアプリケーションを同じWebLogicサーバー・インスタンスに移動できないことがあります。
詳細は、『Oracle WebLogic Server JDBCのプログラミング』のWebLogic RMIドライバのセキュリティの考慮事項に関する項を参照してください。
プラットフォーム: Linux
複数のOracle RACデータベース・ノードを使用しているSOAサーバーでは、XAおよびロード・バランシングにWebLogic Serverの複数データ・ソースが構成されている場合に、ORA-10591エラーが発生することがあります。
回避策
Linux x86、Oracleリリース11.1.0.7.0用のOracle RACデータベース・パッチ7675269をダウンロードして適用します。このパッチはMy Oracle Supportからダウンロードできます。または、パッチ7675269を含むLinux x86、Oracleリリース11.1.0.7.0用のパッチ・セット9007079をダウンロードして適用することもできます。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
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という名前のファイル仕様をアクティブにしようとします。
プラットフォーム: すべて
管理対象サーバーにデプロイされたアプリケーションやEJBをWebLogic Server管理コンソールで操作する際、それらがデプロイされたライブラリに依存しているとjava.lang.NoClassDefFoundErrorが発生することがあります。
回避策
WebLogic Server管理コンソールでは、Javaデータ型およびアノテーションを処理するために、共有ライブラリ・デプロイメントにアクセスする必要があります。したがって、すべての共有ライブラリ・デプロイメントは、管理対象サーバーまたはクラスタだけでなく、WebLogic Server管理サーバーにもターゲット指定されている必要があります。
プラットフォーム: すべて
restoreメソッドは、DConfig Beanをプラン・オーバーライドで正しく更新しません。たとえば、次のステップを実行するとします。
DeployableObject dObject =
WebLogicDeployableObject.createDeployableObject(new File(appName));
DeploymentConfiguration dConfig =
WebLogicDeploymentManager.createConfiguration(dObject);
dConfig.restore(new FileInputStream(new File(plan)));
この場合、プランはDConfig Beanを正しくオーバーライドしません。
回避策
アプリケーションの構成を初期化する際にプランを指定します。次に例を示します。
helper = SessionHelper.getInstance(
SessionHelper.getDisconnectedDeploymentManager());
helper.setApplication(app);
helper.setPlan(new File(plan));
helper.initializeConfiguration();
プラットフォーム: すべて
uploadオプションを使用して大きなアプリケーション・ファイルがデプロイされる場合、デプロイメント・タスクは次のエラーで失敗します。
java.lang.OutOfMemoryError: Java heap space
この問題を解決するために、新しいシステム・プロパティweblogic.deploy.UploadLargeFileが追加されました。この問題が発生する場合は、このフラグを、デプロイメント・クライアントの起動に使用するjavaコマンドに含めます。
WebLogic Serverパッチ・リリース9.2 MP2、9.2 MP3、10.0 MP1、10.0 M2、10.3、10.3.1、10.3.2または10.3.3を使用する場合、このフラグは必要ありません。
プラットフォーム: Linux
管理対象サーバーの起動時にWebLogic Server管理サーバーが使用可能でない場合、管理対象サーバーはMSIモードで起動します。後で管理サーバーを起動すると、管理対象サーバーは管理サーバーに接続します。ただし、管理対象サーバーにデプロイされている各アプリケーションの状態は、管理対象サーバー上のアプリケーションの状態を反映するようには更新されません。各アプリケーションの状態は、WebLogic Server管理コンソールでNEWまたはPREPAREDとして表示されます。
回避策
この問題には、2つの回避策があります。
管理対象サーバーを起動する前に管理サーバーを起動します。
管理サーバーの起動後に、アプリケーションを再デプロイします。
プラットフォーム: Linux
最初にあるソース・ファイルの場所を使用してアプリケーションをデプロイし、ソース・ファイルの新しい場所を使用してアプリケーションを再デプロイしようとした場合、デプロイメントは次の例外で失敗します。
New source location <new_source_file_path> cannot be configured deployed to
configured application, <application_name>. The application source is at
original_source_file_path. Changing the source location is not allowed for a
previously attempted deployment. Try deploying without specifying the source.
これは、WebLogic Serverのデプロイメント制限が原因です。デプロイメントのソース・ファイルを指定した後、それを再デプロイメントで変更することはできません。
回避策
新しいソース・ファイルの場所を使用して再デプロイを試行する前に、アプリケーションをアンデプロイします。
この項では、次の問題と回避策について説明します。
プラットフォーム: Windows 64ビット、Linux 64ビット
開発者用のWebLogic Server 12.1.1 ZIP配布をWindows 64ビットおよびLinux 64ビットのシステムで使用する際、64ビット・プラットフォーム固有の環境設定が設定されていません。このため、空のサーバーの作成および起動ができません。
回避策
次の環境変数を手動で設定します。
WL_USE_AMD64DLL=true (Windows only) WL_USE_X86DLL=false (Windows only) JAVA_USE_64BIT=true SUN_ARCH_DATA_MODEL=64
LD_LIBRARY_PATHが正しいネイティブ・ライブラリ・ディレクトリを示すことも確認してください。
プラットフォーム: すべて
FastSwapが開発モードで有効になっているとき、EJBがビジネス・メソッドを基底クラスから継承し、そのビジネス・メソッドでトランザクション・コンテキストが必要とされる場合は、次のエラーが発生します。
javax.persistence.TransactionRequiredException: The method public abstract void javax.persistence.EntityManager.persist(java.lang.Object) must be called in the context of a transaction.
この問題は今後のリリースで修正される予定です。
回避策
次のいずれかの回避策を使用します。
FastSwapを無効にします。
継承を使用しません。
トランザクション・コンテキストを自分でビジネス・メソッド内で確立します。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
Oracle表の主キーはCHARですが、SQL表の問合せフィールドはVARCHAR2です。
回避策
データベース・スキーマをCHARからVARCHAR2に変更してください。Oracleデータベースで、主キーとしてCHARを使用することはお薦めできません。
プラットフォーム: すべて
EJB3 BeanおよびEjbgenに、クラスタ化可能なタイマーを作成するためのアノテーションがありません。
回避策
weblogic-ejb-jar.xmlファイルを作成し、これに<timer-implementation>要素および対応する値を記入してください。
プラットフォーム: すべて
Kodoの MappingTool は、主キーでBLOBを使用しているクラスのスキーマを生成することができません。BLOBを主キーに使用することはできますが、スキーマは手動で定義する必要があります。ただし、JDOおよびJPA仕様では、主キーでBLOB列をサポートすることは必須ではありません。
プラットフォーム: すべて
JPAメタデータ・モデルの拡張は、アノテーションでしか指定できず、仕様に定義されている orm.xml のような構造体では指定できません。
回避策
オブジェクト・モデルにKodo固有のメタデータを指定する方法としては以下があります。
Kodo固有のアノテーションを使用するか、または
XMLベースのメタデータをJDOメタデータ形式に変換します(拡張のXML仕様はサポートされません)。
プラットフォーム: すべて
WebLogic Spring注入拡張モデルでは、ルック・アップ・メソッドの注入をサポートしていません。
プラットフォーム: すべて
管理対象の環境でJDO PersistenceManagerFactoryをデシリアライズするとエラーが発生する可能性があります。例外にはjavax.jdo.PersistenceManagerFactoryClassプロパティがないことが示されています。管理対象の環境では通常、PersistenceManagerFactoryをシリアライズする必要はありません。
プラットフォーム: すべて
クラス・レベルで宣言された索引は、スキーマの作成時に作成されないことがあります。
回避策
スキーマ生成ツールの実行後に、索引を手動で作成します。
プラットフォーム: すべて
一部のデータベースで@Idフィールドに@Uniqueアノテーションも付いている場合、OpenJPAが例外をスローします。データベースの主キーは本質的にユニークです。一部のデータベースでは、列に対してユニークな索引を作成することで、この性質を実装しています。
回避策
1つのフィールドに対して@Idと@Uniqueの両方を指定しないでください。
プラットフォーム: すべて
バージョン・データのないエンティティを操作すると、キャッシュのヒットとミスの数が予想外に増えることがあります。EntityManagerが終了し、含まれているすべてのエンティティがデタッチされるときに、余分なキャッシュ・アクセスが行われます。バージョン・フィールドのないエンティティは、システムからはバージョン・データがないように見え、システムはデタッチ前にそれらのバージョンをキャッシュでチェックすることで応答します。
回避策
バージョン・フィールドまたはその他のバージョン方式があるエンティティは、余分なキャッシュ・アクセスの原因になりません。
プラットフォーム: すべて
MySQLデータベースを使用していて、OpenJPAが実行時にマッピング・ツールを自動的に実行するように構成され、デフォルト・スキーマに次のような表を作成する場合:
<property name='openjpa.jdbc.SynchronizeMappings' value='buildSchema'/>
<property name='openjpa.jdbc.Schema' value='MySQL database name' />
OpenJPAは、表がデータベースにすでに存在する場合でも表を作成しようとします。表がすでに存在することを示すPersistenceException例外がスローされて、表作成文が失敗します。
回避策
この問題を回避するには、MySQLデータベースを使用する場合、実行時にマッピング・ツールを自動的に実行するようにOpenJPAを構成しないでください。また、デフォルト・スキーマを指定してください。
プラットフォーム: すべて
エンティティが(Externalizableではなく)Serializableであり、writeObject()メソッドを宣言していない場合、IIOPを使用し、JPAエンティティをサーバーからクライアントに送信するEJBアプリケーションで、シリアライゼーション中にエラーが発生します。
回避策
そのようなエンティティ・クラスにはwriteObject()メソッドを追加してください。書込みオブジェクトは次のようになります。
private void
writeObject(java.io.ObjectOutputStream out)
throws IOException {
out.defaultWriteObject();
}
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
SAMPLES_HOME/server/medrec/setup/build.xmlにあるmedrec.wls.configターゲットには、セキュリティ構成に関する既知の問題があります。
プラットフォーム: すべて
../xml/staxサンプルには、同じルートで異なる拡張子を持つ2つのファイル(StreamParser.javaとStreamParser.jsp)があります。しかし、サンプル・ビューアのビルドでは、タイプごとの2つのファイルではなく、対応するHTMLファイルが1つだけ作成されます。この場合、StreamParser.jspファイルには対応するHTMLファイルがありますが、StreamParser.javaファイルにはありません。
この問題は、ドキュメントのファイルを生成するためのjava2htmlの動作を制御するbuild.xmlファイルの設定が原因で発生します。
java2htmlを使用する場合、useShortFileName="true"パラメータを指定すると、HTML出力ファイルのファイル名を作成するために、ソース・ファイルのファイル拡張子が削除されます。2つのファイルが同じ名前で異なる拡張子を持つ場合は、後から生成されたHTMLファイルが前に生成されたファイルを上書きします。
回避策
useShortFileNameパラメータを"false"に設定します。この設定では、ファイル拡張子を名前に含めてHTMLファイルが生成されます。この解決策の欠点は、対象のファイルがこのバグの影響を受けるかどうかに関係なく、HTML出力ファイルを指すすべてのリンクを修正する必要があることです。
プラットフォーム: すべて
medrecまたはsamplesドメインを起動すると、次のような警告メッセージが表示されることがあります。
<Warning> <WorkManager> <BEA-002919> <Unable to find a WorkManager with name weblogic.wsee.mdb.DispatchPolicy. Dispatch policy weblogic.wsee.mdb.DispatchPolicy will map to the default WorkManager for the application bea_wls_async_response>
この警告メッセージは、非同期のWebサービスがデプロイされたWebLogic Serverサンプル・アプリケーションの起動中に、コンソールの標準出力に出力されます。
回避策
この警告は無害ですので無視して構いません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
HTTP Publish/Subscribeサーバーはローカル・クライアントの認証と認可をサポートしていません。ローカル・クライアントにはHTTP Publish/Subscribeサーバーのチャネルを操作する完全な権限があります。つまり、ローカル・クライアントは、チャネルの作成と削除、チャネルからのイベントのパブリッシュとサブスクライブを行えます。
プラットフォーム: すべて
クラスタ化環境では、あるサーバー上のローカル・クライアントがパブリッシュしたイベント・メッセージは、同じサーバーに接続しているサブスクライブ済クライアントのみが受信できます。クラスタ内の他のサーバーに接続しているサブスクライブ済クライアントはこれらのメッセージを受信できません。
プラットフォーム: すべて
ローカル・クライアントがチャネルにパブリッシュしたイベント・メッセージが、そのチャネルに構成されているメッセージ・フィルタで処理されません。
この項では、次の問題と回避策について説明します。
IBM JDKトランスフォーマ・ファクトリとAIXおよびzLinuxのSecurity SAMLの非互換性に対するパッチ
GUIモードでのHP-UX PA-RISC 11.31へのOracle WebLogic Server 12.1.1のインストールが失敗する
プラットフォーム: すべて
WebLogic Serverインストーラは、ファイル・システムまたはディスクに使用可能ディスク領域が大量にある場合でも、ディスク領域不足エラーで失敗することがあります。
回避策
インストール・コマンドの-Dspace.detectionプロパティを使用して、使用可能領域チェックを無効にします。次に例を示します。
java -Xmx1024M -Dspace.detection=false -jar installer_file_name -mode=silent -silent_xml=silent.xml
または
wls1211_linux.bin -Dspace.detection=false
プラットフォーム: MS Windows
ミドルウェア・ホーム・ディレクトリをWebLogic Serverホーム・ディレクトリとして使用することはできません。たとえば、ミドルウェア・ホーム・ディレクトリがC:\Oracle\Middlewareの場合、C:\Oracle\MiddlewareをWebLogic Serverのホーム・ディレクトリとして指定することはできません。指定すると、構成ウィザード、テンプレート・ビルダー、および場合によって他のWebLogic Serverツールで重大な問題が発生することがあります。
回避策
ミドルウェア・ホーム・ディレクトリ以外のディレクトリにWebLogic Serverをインストールします。たとえば、ミドルウェア・ホーム・ディレクトリがC:\Oracle\Middlewareの場合は、WebLogic ServerをC:\Oracle\Middleware\wlserverまたはC:\Oracle\wlserverにインストールできます。
プラットフォーム: すべてのUNIX
インストーラでは、インストールの完了前にマシンに十分なディスク領域があるかどうかは確認されません。そのため、領域不足によりインストールを完了できない場合、次のエラー・メッセージが表示され、インストーラが終了します。
Fatal error encountered during file installation. The installer will now cleanup and exit!
回避策
この問題が発生した場合、次のコマンドを使用してインストーラを再起動します。
server103_linux32.bin -log=log.out -log_priority=debug
このコマンドによりインストール手順のログが生成され、正確な失敗の原因が詳細に示されます。領域不足が原因であれば、ログ・ファイルにそれが明示的に示されています。
プラットフォーム: AIX、zLinux
JACC (Java Authorization Contract for Containers)が有効になっている場合、Sun固有のPrincipalComparatorを使用してWebLogic Serverを実行することは、IBM JDKではサポートされていません。NoClassDefFoundErrorが発生します。
回避策
Oracle Smart Updateツールを使用して、My Oracle Supportから次のパッチをダウンロードしてインストールします。
パッチID: V5GA パスコード: NPC1WPQ5
Oracle Smart Updateツールの詳細は、次のURLにあるOracle WebLogic Serverへのパッチの適用を参照してください:
http://download.oracle.com/docs/cd/E14759_01/index.htm
プラットフォーム: AIX、zLinux
IBM JDKトランスフォーマ・ファクトリとSAML 2.0モジュールには互換性がないため、次の例外が発生します。
FATAL ERROR: 'org.apache.xml.serializer.utils.WrappedRuntimeException: org.apache.xml.serializer.ToXMLSAXHandler incompatible with org.apache.xml.serializer.SerializationHandler': org.apache.xml.serializer.ToXMLSAXHandler incompatible with org.apache.xml.serializer.SerializationHandler org.opensaml.xml.ConfigurationException: Configuration file does not validate against schema at org.opensaml.xml.XMLConfigurator.validateConfiguration(XMLConfigurator.java:33.1)
回避策
Oracle Smart Updateツールを使用して、My Oracle Supportから次のパッチをダウンロードしてインストールします。
パッチID: V5GA パスコード: NPC1WPQ5
Oracle Smart Updateツールの詳細は、次のURLにあるOracle WebLogic Serverへのパッチの適用を参照してください:
http://download.oracle.com/docs/cd/E14759_01/index.htm
プラットフォーム: HPUX
Oracle WebLogic Server 12.1.2のインストーラが、32ビットJDKでGUIモードのjava -jar wls1211_generic.jarコマンドを使用して開始された場合、インストール・プロセスの最後にインストールが失敗します。この問題は、HP-UX PA-RISC 11.31でのみ発生します。
インストーラは次のエラーを表示します。
# A fatal error has been detected by the Java Runtime Environment: # SIGSEGV (11) at pc=ca19ffa8, pid=20644, tid=21 # JRE version: 6.0 # Java VM: Java HotSpot(TM) Server VM (17.1-b03-jre1.6.0.09-rc1 PA2.0 (aCC_AP) mixed mode hp-ux-pa-risc ) # Problematic frame: # V [libjvm.sl+0x521b7848] # Please report this error to HP customer support.
回避策
次のいずれかの回避策を使用します。
java -Dspace.detection=false -jar wls1211_generic.jarコマンドを使用して、Oracle WebLogic Server 12.1.1をGUIモードでインストールします。
java -jar wls1211_generic.jar -mode=consoleコマンドを使用して、Oracle WebLogic Server 12.1.1をコンソール・モードでインストールします。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
FastSwapによってフィールドとメソッドのアクセス修飾子が緩和される可能性があります。privateとprotectedのメンバーは実行時にpublicになる可能性があります。そのためにリフレクションの動作が変わり、Strutsのようなリフレクションに基づくフレームワークが影響を受ける可能性があります。
プラットフォーム: すべて
FastSwapは、エンティティBeanとejbClass(セッション/MDB)の再定義をサポートしません。したがって、エンティティ・クラスを更新すると、再定義エラーが発生します。
回避策
エンティティ・クラスの更新後に、アプリケーションを再デプロイします。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
記述子の検証が有効になっていると、デプロイメント記述子の検証に失敗し、EARファイルにJMSモジュールのみが格納されます。
回避策
EARに、J2EE仕様に準拠したモジュールが少なくとも1つ含まれていることを確認してください。
プラットフォーム: すべて
複数のJMSプロデューサが単一のJVM内で同じJMSクライアントSAFインスタンスを使用している場合、JMS SAFクライアントが作成されるタイミングによっては、次の例外がスローされることがあります。
Error getting GXA resource [Root exception is weblogic.jms.common.JMSException: weblogic.messaging.kernel.KernelException: Error getting GXA resource]
回避策
複数のJMS SAFクライアント・プロデューサを使用する場合は、各クライアントの新規作成のタイミングを少しずらすようにしてください。
プラットフォーム: すべて
WebLogicストアのファイルおよびディレクトリの名前には、マルチ・バイト文字を使用することはできません。たとえば、WebLogic Server名にマルチ・バイト文字を使用すると、デフォルト・ストアを作成できず、WebLogic Serverを起動できません。
回避策
パス名にマルチ・バイト文字を使用せずにWebLogic Serverインスタンスを作成し、デフォルト・ストア構成にそのパス名を使用します。WebLogic Server名にマルチ・バイト文字を使用しないようにしてください。
プラットフォーム: すべて
NFS搭載のディレクトリにJMSメッセージとトランザクション・ログが格納されている場合、マシンが不意に障害したら、サーバーの再起動の動作を検証することをお薦めします。NFS実装に応じて、フェイルオーバー/再起動後、様々な問題が発生する可能性があります。詳細は、6.3項「NFSでファイル・ストアを使用している場合にWebLogic Serverのテストが突然失敗する」を参照してください。
プラットフォーム: すべて
アプリケーションのWLConnection.getReconnectPolicy()属性がallに設定されていると、サービスの移行後にJMSメッセージ・コンシューマを再接続できないことがあります。コンシューマが移行されていないと、例外がスローされるか、コンシューマが有効でなくなったことをアプリケーションに通知するonExceptionが発生します。
回避策
アプリケーションで、例外ハンドラまたはonExceptionを使用してコンシューマを更新できます。
プラットフォーム: すべて
特定の条件は、JNDIが非常に頻繁に更新される原因となることがあり、JMSサブスクライバはjava.naming.NameNotFoundExceptionを検出することがあります。詳細は、「ユニキャスト・メッセージの処理順序の強制」を参照してください。
このリリースのWebLogic Serverには、JNDIの既知の問題はありません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
WebアプリケーションまたはWebモジュールのデプロイメント時に、デプロイメント・プランを使用して2つのデプロイメント記述子WEB-INF/classes/META-INF/persistence.xmlおよびWEB-INF/classes/META-INF/persistence-configuration.xmlをオーバーライドすることはできません。それ以外の場合は、デプロイメント・プランを使用して記述子をオーバーライドできます。
回避策
WEB-INF/classes/META-INF/persistence.xmlおよびWEB-INF/classes/META-INF/persistence-configuration.xml(存在する場合)を関連するクラス・ファイルと一緒にjarファイルにパッケージ化してください。JARファイルはWebアプリケーションまたはWebモジュールのWEB-INF/libディレクトリに配置する必要があります。このようなJARファイルであれば、デプロイメント・プランを使用して2つの記述子をオーバーライドできます。
プラットフォーム: すべて
Spring拡張モデルが有効になっている場合、WebLogic Server 10.3以降はパフォーマンス上の理由から、JSPタグ・ハンドラではSpringの依存関係インジェクション(DI)をサポートしていません。
現在、WebLogic Serverは、サーブレット、フィルタ、リスナーなどのほとんどのWebコンポーネントでSpring DIをサポートしています。ただし、パフォーマンス上の理由から、現在、Spring DIはJSPタグ・ハンドラではサポートされていません。
プラットフォーム: すべて
セッションが永続化され、サーブレット・コンテキストの古いバージョンがリタイアされる場合に、有効なsessionidでアプリケーションにアクセスすると、503エラーが発生します。
たとえば、バージョン管理されているWebアプリケーションのセッション永続性のタイプは「ファイル」です。ユーザーはアプリケーションに正常にアクセスできます。その後、そのアプリケーションのバージョン2がデプロイされて、バージョン1がリタイアされます。ここで、同じユーザーがアプリケーションにアクセスすると、503エラーが発生します。
このリリースのWebLogic Serverには、JTAの既知の問題はありません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
Sun Microsystems VMの既知のバグ(513552)により、1.4シン・クライアント・アプレットはWebLogic Server 9.0以降と通信できません。これは、クライアントとサーバーの接続間でVMが正しく区別されないことが原因です。VMは、サーバー・タイプ接続を作成し、それをキャッシュします。次に、クライアント・タイプ接続の確立を試行し、キャッシュされた接続を探してそれを使用しようとしますが、クライアントはサーバー接続の使用を許可されないため、エラーが発生します。
プラットフォーム: RedHat Linux
Intel G5プロセッサ上のRedHat (RH) Linux上で実行され、直接的または間接的にシステム時間の呼出しを使用するアプリケーションにおいて、ClockSourceがtsc(デフォルト)に設定されている場合に、時間の問題が断続的に発生する可能性があります。標準のPOSIX C gettimeofday()を呼び出した結果、Java System.currentTimeMillis()とjava.util.Date()も呼び出されると、シングル・スレッド・アプリケーションの場合でも、将来に約4400秒の値が断続的に返される可能性があります。
この問題はWebLogicやJavaに固有の問題ではなく、Intel G5プロセッサ上のRH Linux上で実行されるどのアプリケーションにも当てはまります。この問題が発生するのは、標準Java、または時間ベースのアプリケーション・サーバー・サービスを使用して、時間の呼出しを明示的に行うアプリケーションです。
考えられる症状としては、トランザクションの早過ぎるタイムアウト、JMSメッセージの予期しない期限切れ、タイマーの不適切なスケジューリングなどが挙げられますが、これだけに限りません。
この問題の個別の再現に関心がある場合は、Oracleに問い合せてOracle Bug#8160147を参照してください。
回避策
Linuxの正式なパッチはまだありません。代わりに、クロックのソースをtscからhpetに変更してください。テスト・システムでこの変更を行った後は、System.currentTimeMillis()/gettimeofday()の無効な戻り値が原因の例外は発生しなくなります。試験的にシステム・クロックをtscからhpetに変更するには、rootとして以下の手順を実行します。
ntpdを無効にします(実行されている場合)
Echo 'hpet' > /sys/devices/system/clocksource/clocksource0/current_clocksource
ntpdを有効にします
この変更は再起動後に失われることに注意してください。詳細は、http://www.gossamer-threads.com/lists/linux/kernel/813344を参照してください。
プラットフォーム: Linux
無制限のフォワード・ローリングの一部として長い配列のコピーを実行しているときに、JRockit JVMがフリーズしたように見えます。この状況は、Out Of Memory条件により複数のサーバーが再起動した場合に発生することがあります。
回避策
サーバーの起動時に、次のJRockit JVMフラグを指定します。
-XXrollforwardretrylimit:-1
プラットフォーム: Linux
シリアル・バージョンUIDの不一致の問題は、最新のJVMにアプリケーションをデプロイし、以前のサービス・リリースのIBM Java 6 JDKでコンパイルした場合に発生します。
回避策
以前にコンパイルしたアプリケーションのシリアライゼーションと互換にするには、BEA_HOME/wlserver_10.3/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を持つようにする必要があります。
プラットフォーム: Linux
WebLogic Serverの実行中に、JVMスタックのオーバーフロー・エラーまたは例外が発生することがあります。この問題は、AMD64および64ビットXeonプラットフォーム上のOracle Enterprise Linux 4、5、5.1で発生します。
回避策
スタック・サイズをデフォルトの128kから256kに増やします。
プラットフォーム: Linux x86
AWTやjavax.swing(多くの場合、AWTに委任されます)などのGUIライブラリを使用している場合に、JVMクラッシュが発生することがあります。
回避策
次のフラグを使用してサーバーを起動します。
-Djava.awt.headless=true
プラットフォーム: AIX
JVMへの依存性により、IIOPシン・クライアントはAIXでサポートされません。シン・クライアント・アプリケーションだけがこの問題の影響を受けます。
回避策
WebLogic ServerをAIXで実行し、シン・クライアントを別のオペレーティング・システムで実行します。
プラットフォーム: AIXおよびzLinux
XMLスキーマ・ファクトリの検証エラーは、事前構成済のプロパティ・ファイル形式が原因でIBM JDKがプラットフォームのデフォルト・スキーマ・ファクトリを返せない場合に発生します。
回避策
WL_HOME/wlserver_version/common/bin/commEnv.shファイルを変更して次の行を含めます。
JAVA_OPTIONS="$JAVA_OPTIONS -Djavax.xml.validation.SchemaFactory:http://www.w3.org/2001/XMLSchema=org.apache.xerces.jaxp.validation.XMLSchemaFactory"
プラットフォーム: Linux、AIX
シリアル・バージョンUIDの不一致の問題は、最新のJVMにアプリケーションをデプロイし、以前のサービス・リリースのIBM Java 6 JDKでコンパイルした場合に発生します。
回避策
以前にコンパイルしたアプリケーションのシリアライゼーションと互換にするには、WL_HOME/wlserver_10.3/common/bin/commEnv.shファイルを変更して、次のコマンドを含めます。
JAVA_OPTIONS="$JAVA_OPTIONS -Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"
または、適切なLinuxまたはAIXコマンド・ライン・オプションを使用できます。
AIX:
export IBM_JAVA_OPTIONS="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"
Linux:
export JAVA_OPTIONS="-Dcom.sun.xml.namespace.QName.useCompatibleSerialVersionUID=1.0"
以前にコンパイルしたアプリケーションとともに新しいアプリケーションをデプロイする場合は、必要に応じて再コンパイルし、同じシリアル・バージョンUIDを持つようにする必要があります。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
@unharvestableタグはインタフェース・レベルで適用されません。MBean属性が明示的に@unharvestableとマークされていない場合は収集可能と見なされ、WebLogic管理コンソールにも収集可能と表示されます。
回避策
MBean属性を明示的に@unharvestableとマークできます。
プラットフォーム: すべて
WebLogic Server 10.3.3では、デフォルトのWLDF診断ボリューム設定は「オフ」です。WebLogic Server 10.3.4の時点では、デフォルトの診断ボリューム設定は低ボリュームですが、WebLogic Server 10.3.4では、JVMレベルで生成されるイベントは低ボリューム設定では生成されません(WebLogic Server 10.3.3では、JVMレベル・イベントは低ボリューム設定で生成されました)。JVMレベル・イベントは、WebLogic Server 10.3.4では高ボリュームおよび中ボリューム設定で生成されます。
回避策
次のいずれかの回避策を使用すると、JVMレベル・イベントが生成されます。
WLDF診断ボリュームを「中」または「高」レベルに上げます。
JRMC、JRCMDまたはJRockitコマンド・ライン設定を使用して、WebLogic Serverインスタンスで別のフライト記録をアクティブにします。これにより、JVMでは、JVMイベントがすべてのWLDF診断ボリューム設定(「オフ」、「低」、「中」および「高」)に存在します。
プラットフォーム: すべて
JVMイベントが有効になっている場合、次の状況でWLDFのパフォーマンスの問題が発生することがあります。
他のJRockitフライト記録が有効になっていない場合、WLDF診断ボリュームが「中」または「高」レベルに設定されていると、パフォーマンスが低下することがあります。
他のJRockitフライト記録が有効になっている場合は、すべてのWLDF診断ボリューム・レベル(オフ」、「低」、「中」または「高」)でパフォーマンスが低下することがあります。
このリリースのWebLogic Serverには、ノード・マネージャの既知の問題はありません。
このリリースのWebLogic Serverには、操作および管理の既知の問題はありません。
この項では、Oracle Kodoの次の問題と回避策について説明します。
プラットフォーム: MS Windows 2000
エンティティ内の空のバイト配列フィールドをSybaseまたはOracleデータベースに永続化しようとすると、値がバイトではなくNULLとして格納されます。その結果、値を取得したときにNULLが返されます。
これはSybaseおよびOracleドライバの制限であり、データベースに格納するときに空のバイト配列がNULLに変換されます。この問題はWebLogic JDBCドライバとSybaseおよびOracle独自のドライバで発生します。
この項では、様々なWebLogic Serverプラグインの次の問題について説明します。
プラットフォーム: すべて
次の状況では、IISプラグインが動作しないことがあり、apr_socket_connectionエラーが発生します。
IISとWebLogic Serverの両方のインスタンスが同じマシンにある場合。
マシンでIPv6が有効になっていて、マシンがIPv6環境にない場合(つまり、IPv6インタフェースが有効になっているが動作していない場合)。
WebLogic Serverインスタンスのリスニング・アドレスが単純なホスト名に設定されている場合。
ディレクティブWebLogicHostまたはWebLogicClusterがIISインスタンスに対して単純なホスト名に設定されている場合。
このリリースのWebLogic Serverには、プロトコルの既知の問題はありません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
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}"
この項では、次の問題と回避策について説明します。
プラットフォーム: AIX、zLinux
WebLogic Server 12.1.1のJava Authorization Contract for Containers (JACC)はPrincipalComparatorを使用しますが、これはIBM JDKでサポートされていません。したがって、JACCを有効にしてWebLogic Serverインスタンスを実行し、IBM JDKを使用すると、NoClassDefFoundErrorが発生します。
回避策
Oracle Automated Release Updates (ARU)を使用してリクエスト番号14420904を入力するか、パッチ13495681をMy Oracle Supportからダウンロードしてインストールします。
プラットフォーム: すべて
JDKバージョンがJRockit 1.60_24、1.60_28または1.60_29の場合、サービス側Kerberos認証はHTTP/1.1 Error 401 Unauthorizedで失敗します。
回避策
次のいずれかの回避策を使用します。
ktab.exeを使用してキータブ・ファイルを生成するかわりに、kadminなどの別のツールを使用して生成します。
ktab.exeを使用して適切なkvnoを手動で指定します。
プラットフォーム: すべて
WebLogic ServerがJSSEベースのSSLプロバイダを使用するように構成されている場合、SSL接続を作成しようとすると、BAD_MAC_ERRORメッセージで失敗することがあります。
回避策
JDK 7u2以上をインストールし、WebLogic Serverを再起動します。
プラットフォーム: すべて
-Dweblogic.system.StoreBootIdentityオプションは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能します。このディレクトリは通常、構成ウィザードまたはアップグレード・ツールによって作成されます。
ただし、ソース・コントロール・システムにチェック・インしているドメインでは、この適切なサーバー・セキュリティ・ディレクトリがない場合があります。
プラットフォーム: すべて
WebLogic Server提供のDB2ドライバを使用してDB2データベース用のRDBMSセキュリティ・データ・ストアが構成されている場合、WebLogic ServerインスタンスでSecurityServiceExceptionにより起動時エラーが発生することがあります。
回避策
RDBMSセキュリティ・データ・ストアでDB2データベース用にAlternateId接続プロパティを使用している場合は、WebLogic Server提供のDB2ドライバを使用するときに、追加のプロパティBatchPerformanceWorkaroundをtrueに設定する必要もあります。
プラットフォーム: すべて
ドメインをWLS 6.1からアップグレードした後で、認証エラーが原因でWebLogic Serverインスタンスが起動しません。
回避策
WebLogic Serverインスタンスを適切に起動するには、アップグレード・プロセスの前か後に、WLS 6.1ドメインでシステム・ユーザー・パスワードを設定する必要があります。
プラットフォーム: すべて
SAML 2.0のIDプロバイダまたはサービス・プロバイダを構成した後で、SAML 2.0サービス・メタデータ・ファイルを公開しようとすると、InvalidParameterExceptionメッセージが生成されて管理コンソールに表示される可能性があります。
回避策
WebLogic ServerインスタンスでSAML 2.0フェデレーション・サービスを構成する場合は、構成するSAMLロールで使用可能なすべてのバインディング・タイプを有効にしてください。たとえば、SAML 2.0 IDプロバイダ・サービスを構成する場合は、POST、リダイレクト、およびアーティファクト・バインディングを有効にする必要があります。SAML 2.0サービス・プロバイダ・サービスを構成する場合は、POSTおよびアーティファクト・バインディングを有効にする必要があります。また、優先バインディングを選択することもできます。
プラットフォーム: すべて
SAML 2.0サービス・プロバイダ・サービスを構成する場合、強制認証とパッシブ属性の両方を有効にすると、WebLogic Serverが検出できない無効な構成となります。これらの属性がどちらも有効な場合に非認証ユーザーがサービス・プロバイダ・サイトでホストされるリソースにアクセスしようとすると、例外が生成され、シングル・サインオン・セッションが失敗します。
WebLogic ServerではSAMLログアウトがサポートされないため、「強制認証」属性の効果がない点に注意してください。ユーザーがIDプロバイダ・サイトですでに認証され、「強制認証」が有効な場合でも、そのユーザーは、IDプロバイダ・サイトで再認証が強制されることはありません。
これらの両方の属性を有効にすることは避けてください。
プラットフォーム: すべて
fork=true属性が設定されていないAntスクリプトから起動した<java>タスクを使用するなど、WebLogicフル・クライアントが非フォーク対象VMで実行されている場合、次のエラーが発生する可能性があります。
java.lang.SecurityException: The provider self-integrity check failed.
このエラーは、RSA Crypto-Jライブラリの読込み時に自動的に実行される自己整合性チェックによって発生します。(Crypto-Jライブラリとcryptoj.jarは、wlfullclient.jarマニフェスト・クラスパスにあります。)
この自己整合性チェック・エラーは、次に示す状況のような、クライアントが非フォーク対象VMで起動され、Crypto-J APIを直接または間接的に使用する場合に発生します。
クライアントがCrypto-Jライブラリを直接起動します。
クライアントが、基盤となるクライアントSSL実装をトリガーしてCrypto-J APIを起動するT3S接続を試行する場合。
自己整合性チェックが失敗した場合、Crypto-J APIの以降の呼び出しが失敗します。
回避策
Antスクリプトから呼び出された<java>タスクでフル・クライアントを実行している場合は、fork属性を常にtrueに設定します。
自己整合性チェックの詳細は、次のURLにある『Java(tm) Cryptography Architectureでのプロバイダの実装方法』のプロバイダによる自己整合性チェックの実行方法に関する項を参照してください:
プラットフォーム: 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を追加します。この回避策は、純粋な乱数ではなく擬似乱数を使用するため、本番環境では使用しないでください。
プラットフォーム: AIX
WebLogic Serverのインストール時に、AIX上でOracleセキュリティの更新を妨害する問題があります。
回避策
次の手順を実行します。
wlsversion_generic.jarからarchives/com.oracle.ocm_1.0.0.0.jarを抽出します
jar xvf wls1031_generic.jar archives/com.oracle.ocm_1.0.0.0.jar
-Xbootclasspathを指定してwlsversion_generic.jarをインストールします
java ${JAVA_OPTION} -jar -Xbootclasspath/p:archives/com.oracle.ocm_1.0.0.0.jar wlsversion_generic.jar
プラットフォーム: AIX、zLinux
IBM JVMを使用したWebLogic Serverへの接続にECDHアルゴリズムが使用されると、SSLHandshakeExceptionが発生します。
回避策
次の行を$JAVA_HOME/jre/lib/security/java.securityファイルに追加します。
jdk.tls.disabledAlgorithms=AES, DESede, DES, SHA1, SHA
プラットフォーム: AIX、zLinux
WebLogic ServerはJavaセキュリティ・マネージャを使用して、信頼性のないコードがJavaセキュリティ・ポリシー・ファイルによって制限されているアクションを実行しないようにできます。IBM JDK 7 SR1を使用する際、あるJavaの許可を使用できない結果としてjava.security.AccessControlExceptionが発生する可能性があります。
回避策
java.security.AllPermissionをパッチJARへ次のように付与します。
grant codeBase "file:<WL_HOME>/patch_wls1211/patch_jars/-" {
permission java.security.AllPermission;
};
このリリースのWebLogic Serverには、SNMPの既知の問題はありません。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
OpenJPA ClassFileTranformerは、JRockitでWebLogic Serverを実行している場合に動作しません。
回避策
回避策として、OpenJPAエンハンサ・コンパイラを使用して、ビルド時に拡張を適用してください。LoadTimeWeaverは使用しないでください。
プラットフォーム: すべて
SpringSourceのpetclinicサンプルで、petclinic.warは問題なくデプロイされます。petclinic.earは正しくパッケージ化されていないため、WebLogic Serverにデプロイされません。SpringSourceに対してpetclinic.earのパッケージ化を修正するようにリクエストを送信済です。
このリリースのWebLogic Serverには、SCAの既知の問題はありません。
この項では、次の問題について説明します。
プラットフォーム: すべて
WebLogic Server 10.3.1を使用してドメインを作成し、WebLogic Server 10.3にロールバックした場合、そのドメインで作成したサーバーを起動できません。config.xmlファイルにはWebLogic Server 10.3に存在しない新しいスキーマ定義(xmlns.oracle.com)への参照が含まれているため、これは既知の制限です。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
<servlet-class>要素を定義しない<servlet>宣言があるweb.xmlデプロイメント記述子が含まれるWebアプリケーションをデプロイしようとすると、アプリケーションのデプロイは失敗します。たとえば、次の<servlet>宣言がデプロイ時に失敗します。
<servlet>
<display-name>MyServlet</display-name>
<servlet-name>MyServlet</servlet-name>
<load-on-startup>1</load-on-startup>
</servlet>
回避策
デプロイの失敗を避けるには、Webアプリケーションとパッケージ化されているweb.xmlファイルで、<servlet-class>サブ要素を<servlet>宣言の要素として必ず定義します。
RESTful Webサービス・アプリケーションの場合、web.xmlファイルを使用せずにアプリケーションをデプロイするか、3.0以前のサーブレットのパッケージ化形式を使用することが可能で、これには<servlet-class要素の定義が必要です。RESTful Webサービスのパッケージ化とデプロイの詳細は、『RESTful Webサービスの開発』のRESTful Webサービスのパッケージ化とデプロイに関する項を参照してください。
プラットフォーム: すべて
session-timeoutがweb.xmlファイルで構成されている場合、管理コンソールを使用してsession-timeoutに対して行った変更は反映されません。
回避策
デプロイメント・プランを使用して、session-timeout設定をオーバーライドします。
プラットフォーム: すべて
JDBCセッションを使用している場合、接続プールの「接続予約タイムアウト」の値は次のいずれかに変更されます。
セッション記述子(weblogic.xmlまたはweblogic-application.xml)で定義されているJDBC接続タイムアウト秒
120秒のデフォルト値
回避策
セッション記述子でjdbc-connection-timeout-secsを構成します。
プラットフォーム: すべて
JDBC永続性セッション中にPoolLimitSQLExceptionが発生した場合、データベースへの接続が不安定になり、リカバリあり、またはリカバリなしで失敗することがあります。これにより、セッション・データが失われます。古いセッションまたはnullが返されます。
プラットフォーム: すべて
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で次の手順を実行します。
「ツール」→「オプション」→「詳細」→「暗号化」タブ→「証明書を表示」に移動します。
「サーバー証明書」タブで、証明書を削除します。
「認証局証明書」タブで、問題の原因となったセキュリティ・デバイスの認証局(CA)を探し、削除します。
Internet Explorerまたはその他のWebブラウザを使用している場合は、表示される警告ページを無視し、Webページに進むことができます。
プラットフォーム: MS Windows
JSPXページがデプロイされ、一部のバージョンのInternet Explorerを使用してアクセスされる場合、ページ・コンテンツのかわりにXHTMLソースが表示されます。この状況は、標準モードとosjp.nextモードの両方で発生します。
回避策
アプリケーション・ユーザーに、FirefoxまたはSafariを使用してアプリケーションにアクセスするよう指示する必要があります。
プラットフォーム: 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/.
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
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ドキュメントを参照してください。
プラットフォーム: すべて
Jython 2.2によって作成されたデフォルトのcachedirは有効なディレクトリではありません。weblogic.jarからJythonを直接使用している場合、WLSTはエラーを出力します。
回避策
この問題には、2つの回避策があります。
WLSTを呼び出す場合は、-Dpython.cachedir=<valid_directory>パラメータを指定します。
weblogic.jarに含まれている部分的なJythonを使用するかわりにJython 2.2.1を別途インストールします。
プラットフォーム: Linux
WLST returnType='a'オプションは、指定したディレクトリからのみ属性を返す必要があります。しかし、子管理オブジェクトも返します。次に例を示します。
ls('Server')
drw- AdminServer
drw- worker01
ls('Server', returnMap='true', returnType='a')
drw- AdminServer
drw- worker01
ls('Server', returnMap='true',returnType='c')
drw- AdminServer
drw- worker01
returnType='a'を指定したlsは、子管理オブジェクトをリストしてはなりませんが、AdminServerとworker01は子です。
回避策
ls(returnType='a')からの出力を処理するときに、返されたエントリがディレクトリかどうかを確認します。
この項では、次の問題について説明します。
プラットフォーム: すべて
現在、mod_wlとmod_wl_ohsは、コンテナ・レベルのフェイルオーバーのみサポートし、アプリケーション・レベルのフェイルオーバーはサポートしません。mod_wl_ohsは、管理対象サーバーが起動し、実行されているかぎり、ダウンしているアプリケーションにリクエストをルーティングし続けます。クラスタ化されている場合、リクエストは、アプリケーションが停止している場合でも元のセッションが開始したコンテナに送信されるため、通常はhttpエラー404が発生します。
この項では、次の問題と回避策について説明します。
クラスタ環境で非同期MakeConnectionを使用すると、次のいずれかの例外が発生します。
McPollingTimeoutException
IllegalStateException
この問題の回避策はありません。
プラットフォーム: すべて
状況によっては、weblogic.wsee.jaxws.mdb.DispatchPolicy WorkManagerがドメイン内の管理対象サーバーの1つ以上にターゲット指定されている場合でも、このWorkManagerが見つからないことを示す警告メッセージがログに記録されます。
回避策
この問題を解決するには次のいずれかの回避策を使用します。
これらの警告メッセージを回避するには、-Dweblogic.wsee.skip.async.response=trueフラグを指定してWebLogic Serverインスタンスを開始します。このフラグの詳細は、『Oracle WebLogic Server JAX-RPC Webサービスの高度な機能のプログラミング』を参照してください。
weblogic.wsee.jaxws.mdb.DispatchPolicy WorkManagerを手動で管理サーバーにターゲット指定します。
プラットフォーム: すべて
WebLogic Server 10.3.4から10.3.5にアップグレードした後で、WebLogic Advanced Web Services for JAX-WS拡張テンプレート(wls_webservices_jaxws.jar)を使用してドメインを作成または拡張するときに、final.pyスクリプトの実行中に例外が発生する場合があります。詳細と回避策は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』の、JAX-WS拡張テンプレートにWebLogicの高度なサービスを適用する場合の問題のトラブルシューティングに関する項を参照してください。
プラットフォーム: すべて
WebLogic Serverでは、JAX-RPC 1.1仕様で要求されているスパース配列と部分転送配列がサポートされません。
プラットフォーム: すべて
Webサービス記述言語(WSDL)のコンパイラでシリアライズ可能なデータ型が生成されないため、データがリモートのEJBに渡されない、またはJMS宛先に格納されません。
プラットフォーム: すべて
WebLogic Serverでは、親Webサービスのターゲット・ネームスペースに適合しないパッケージを持つカスタム例外を、コールバックで使用することはできません。
回避策
コールバックで使用されるカスタム例外は、親Webサービスのターゲット・ネームスペースに適合するパッケージに入れるようにしてください。
プラットフォーム: すべて
プロキシ・サーバーを使用している環境では、JMS転送を使用できません。これは、JMS転送の場合はWebサービス・クライアントが常に t3 プロトコルを使用してWebサービスに接続するのに対し、プロキシ・サーバーではHTTP/HTTPSしか受け付けられないためです。
プラットフォーム: すべて
Webサービス・パラメータとして複合型http://www.w3.org/2001/XMLSchema{schema}を使用するWSDLの処理中にclientgenが失敗します。
プラットフォーム: すべて
WebLogic Server 9.2以降では、コールバックWebサービスでのJAX RPCハンドラはサポートされません。
回避策
WebLogic Workshop 8.1で作成されたWebサービスでJAX RPCハンドラが使用されていた場合、そのアプリケーションは、コールバック・ハンドラ機能を使用しないように再設計する必要があります。
プラットフォーム: すべて
WebLogic Server 9.2以降では、コールバックWebサービスでのメッセージ・レベルのセキュリティはサポートされません。
回避策
WebLogic Workshop 8.1で作成されたWebサービスでWS-Securityを使用している場合は、コールバックでメッセージ・レベルのセキュリティを使用しないようにWebサービスを再設計する必要があります。
プラットフォーム: すべて
WebLogic Serverでは、Javaメソッドの引数または戻り値のパラメータがXmlBeanプロパティを含むJAX-RPC形式のJavaBeanである場合、その処理をサポートしていません。たとえば、アプリケーションでは次のようなシグネチャを持つメソッドを使用できません。
void myMethod(myJavaBean bean);
myJavaBeanクラスは次のとおりです。
public class MyJavaBean {
private String stringProperty;
private XmlObject xmlObjectProperty;
public MyJavaBean() {}
String getStringProperty() {
return stringProperty;
}
void setStringProperty(String s) {
stringProperty = s;
}
XmlObject getXmlObjectProperty() {
return xmlObjectProperty;
}
void getXmlObjectProperty(XmlObject x) {
xmlObjectProperty = x;
}
}
回避策
現在、この問題に対する既知の回避策はありません。
プラットフォーム: すべて
JWSコールバックで2次元のXmlObjectパラメータ(XmlObject[][])を使用すると、IllegalArgumentExceptionが発生します。
回避策
現在、この問題に対する既知の回避策はありません。
プラットフォーム: すべて
@WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE)のようにWebサービス・パラメータとしてSoapElement[]を使用すると、クライアントでは常に空の配列が生成されます。
回避策
SOAPElement[]のデフォルト・バインディングをWildcardParticle.ANYTYPEに変更する際に、@WildcardBindingアノテーションを使用しないようにしてください。SOAPElement[]のデフォルト・バインディングがWildcardParticle.ANYに設定されます。
プラットフォーム: すべて
WebサービスAからWebサービスBを呼び出す場合には、WebサービスAで@ServiceClientアノテーションを使用して呼び出す必要があります。WebサービスBにおいてWebサービスBのWSDLに添付されていないカスタム・ポリシー・ファイルが必要になる場合、WebサービスAの実行は失敗します。WebサービスAはポリシー・ファイルを/Web-Inf/classes/policies/filename.xmlで検索します。しかし、その場所にはポリシー・ファイルが存在しないため、ファイルが見つからないことを示す例外がスローされます。
回避策
WebサービスBにカスタム・ポリシー・ファイルを添付してください。次に例を示します。
@Policy(uri="CustomPolicy.xml",
attachToWsdl=true)
public class B {
...
}
プラットフォーム: すべて
セキュリティ・ポリシーに以下のいずれかのトークン・アサーションが含まれている場合、クライアント側でサーバーのレスポンス・メッセージの署名の検証に失敗する可能性があります。
<sp:WssX509PkiPathV1Token11/> <sp:WssX509Pkcs7Token11/> <sp:WssX509PkiPathV1Token10/> <sp:WssX509Pkcs7Token10/>
また、<sp:WssX509Pkcs7Token11/>または<sp:WssX509Pkcs7Token10/>トークン・アサーションの場合に、X509のチェーン内に3つ以上の証明書があると、サーバー側で受信するメッセージの署名の検証に失敗する可能性があります。
証明書チェーン全体がクライアント側に保持されない限り、次のようなポリシーはサポートされません。
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token
sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
<wsp:Policy>
<sp:WssX509Pkcs7Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken='. . ./IncludeToken/Never'>
<wsp:Policy>
<sp:WssX509Pkcs7Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
. . .
</wsp:Policy>
</sp:AsymmetricBinding>
回避策
以下の2つの解決策のいずれかを使用してください。
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>
WssX509PkiPathV1Token11/>トークン・アサーションを使用してレスポンスを構成しますが、それをメッセージ内に含めます。ポリシーは次のようになります。
<sp:AsymmetricBinding>
<wsp:Policy>
<sp:InitiatorToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToRecipient'>
<wsp:Policy>
WssX509PkiPathV1Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:InitiatorToken>
<sp:RecipientToken>
<wsp:Policy>
<sp:X509Token sp:IncludeToken='. . ./IncludeToken/AlwaysToInitiator'>
<wsp:Policy>
WssX509PkiPathV1Token11/>
</wsp:Policy>
</sp:X509Token>
</wsp:Policy>
</sp:RecipientToken>
. . .
</wsp:Policy>
</sp:AsymmetricBinding>
X509証明書チェーンに複数の証明書がある場合は、<sp:WssX509Pkcs7Token11/>または<sp:WssX509Pkcs7Token10/>のかわりに、WssX509PkiPathV1Token11/>または<sp:WssX509PkiPathV1Token10/>を使用する必要があります。
プラットフォーム: すべて
build.xmlのxmlcatalog要素では、エンティティの場所はローカル・ファイル・システム上のファイルでなければなりません。リモート・ファイル(http:など)やアーカイブ内のファイル(jar:など)は使用できません。
回避策
必要な場合は、代わりに、カタログ・ファイル内のエンティティとしてリモート要素を定義してください。
プラットフォーム: すべて
XMLカタログ機能を使用する場合、カタログ・ファイルではpublic要素がサポートされません。JAX-WS EntityResolver実装との整合性を保つためにサポートされていません。WebLogic Serverはカタログ・ファイルでsystem要素の定義のみをサポートしています。
プラットフォーム: すべて
ローカルのxmlcatalog要素がAntの制限のために正しく機能しません。
回避策
Ant build.xmlファイルで、同じターゲット内の場合はclientgen(wsdlc)タスクより上にローカルの要素を定義する必要があります。または、その要素を別のターゲットで定義してください。
プラットフォーム: すべて
WebLogic Server WebサービスJAXRPCクライアントはマルチ・バイト文字を含むHTTP SOAPActionヘッダーをエンコードしません。WebLogic ServerはHTTPヘッダーでASCIIのみをサポートします。
回避策
WSDLでSOAPアクションをASCIIに変更します。
プラットフォーム: すべて
clientgenタスクのxmlcatalog要素で外部カタログ・ファイルを使用できません。たとえば、次のようなAntビルド・ファイルのスニペットは機能しません:
<clientgen ...
<xmlcatalog>
<catalogpath>
<pathelement location='wsdlcatalog.xml'/>
</catalogpath>
</xmlcatalog>
これはAnt XMLカタログの制限です。
回避策
リソースの場所は、インラインか外部カタログ・ファイルで、または両方で指定できます。外部カタログ・ファイルを使用するには、xml-commonsリゾルバ・ライブラリ(resolver.jar)をクラスパスに含める必要があります。外部カタログ・ファイルの形式はプレーン・テキストまたはXMLです。xml-commonsリゾルバ・ライブラリがクラスパスで見つからない場合、<catalogpath>パスで指定された外部カタログ・ファイルは無視されて、警告がログに記録されます。ただし、この場合でも、インライン・エントリの処理は正常に続行されます。
現在、インラインで指定できるのは<dtd>要素と<entity>要素のみです。これらの要素はそれぞれ、OASISカタログ・エントリ・タイプのPUBLICとURIに対応します。
プラットフォーム: すべて
Direct-Write同期書込みポリシーが設定されたファイル・ベース・ストレージで、高負荷状態の場合にWebサービスの信頼性のあるメッセージング・シナリオを実行している場合、WebLogic Serverログに次のようなIO例外が検出されることがあります。
weblogic.store.PersistentStoreRuntimeException: [Store:280029]The persistent store record <number> could not be found
または
Could not load conversation with id uuid:<some ID> -> Conversation read
failed:
...
weblogic.wsee.jws.conversation.StoreException:
Conversation read failed: id=uuid:<some ID>
weblogic.store.PersistentStoreException: [Store:280052]The
persistent store was not able to read a record.
java.io.OptionalDataException
これらの例外は、Webサービスの信頼性のあるメッセージングを使用している場合にのみ発生することがわかっています。これらは、ファイル・ストアからレコードの読取りに失敗したことを示し、「致命的な」データ・アクセス・エラーとみなされます。
これらのエラーの原因となった基になる問題は、将来のリリースで対処されます。
回避策
この問題には、次の回避策を使用できます。
ファイル・ストア同期書込みポリシーをDirect-Write-With-Cacheに変更します。
または
ファイル・ストア同期書込みポリシーをCache-Flushに変更します。
または
直接書込み同期書込みポリシーを保持し、次のJavaシステム・プロパティをWebLogicサーバーの起動スクリプトに追加します。
-Dweblogic.store.AvoidDirectIO=true
|
注意:
|
Direct-Write-With-Cacheオプションによってパフォーマンスが向上することがあります。オペレーティング・システムの一時ディレクトリに追加ファイルをデフォルトで作成します。
Cache-FlushおよびAvoidDirectIOの回避策は、パフォーマンスが低下することがあります。ファイル・ストアに別のブロック・サイズを構成することで、パフォーマンス低下を低減または排除できる可能性があります。
これらの設定および追加オプションの重要情報は、『Oracle WebLogic Serverパフォーマンスおよびチューニング』のファイル・ストアのチューニングに関する項を参照してください。
プラットフォーム: すべて
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がある場合にのみ動作します。
この項では、次の問題と回避策について説明します。
プラットフォーム: すべて
VIEWクラスは接続ごとには設定されません。
2つのアプリケーションが、定義は異なるが同じVIEW名を持つVIEWクラスをそれぞれ指定した場合、WebLogic Tuxedo Connectorの共有ハッシュ表は、サーバーで予期しない動作を引き起こすことがあります。Resourceセクション用のハッシュ表に加えて、その接続におけるVIEWクラス用のハッシュ表を用意する必要があります。
回避策
すべてのWebLogic Workshopアプリケーションで定義されている全VIEWクラスに一貫性を持たせます。つまり、同じVIEWクラスを表す場合にのみ同じVIEW名を用いるようにします。
この項では、ドキュメントの訂正箇所を示します。
プラットフォーム: すべて
Windowsの「スタート」メニューから「Oracle WebLogic」→「WebLogic Server」→「Examples」→「Documentation」を選択してExamplesドキュメントにアクセスすると、サンプル・ビューアの「検索」機能が動作しません。
回避策
サンプル・アプリケーションおよびサンプル・コードを検索するには、Examplesサーバーを起動して、http://localhost:7001/examplesWebApp/docs/core/index.htmlに移動する必要があります。「手順説明」をクリックし、「検索」をクリックします。
プラットフォーム: すべて
サンプル・ビューアの「検索」機能を使用すると、Avitek Medical Recordの一部のトピックの日本語版と英語版が同時に表示されるトピックが返されることがあります。
プラットフォーム: すべて
http://www.oracle.com/technetwork/middleware/weblogic/documentation/index.htmlから入手可能なWebLogic Serverドキュメント・ライブラリZIPファイルを抽出した後で、次のライブラリの一部でHTMLページが正しく表示されないことがあります。
E12840_01(WebLogic Server 10.3.0ドキュメント・ライブラリ)
E12839_01(WebLogic Server 10.3.1ドキュメント・ライブラリ)
E14571_01(WebLogic Server 10.3.3ドキュメント・ライブラリ)
回避策
ライブラリE12840-01の場合、E12840_01.zipライブラリ・ファイルを抽出した後で、HTMLページが正しく書式設定されない場合は、次の手順を実行します。
Zipファイルを抽出したディレクトリに移動します。
ディレクトリ構造で/global_resourcesディレクトリを探します。
/global_resourcesディレクトリを同じドライブのルート・ディレクトリにコピーします。
ライブラリE12839-01およびE14571-01の場合、この問題はWindowsオペレーティング・システムでのみ発生します。抽出したライブラリのHTMLページが正しく書式設定されない場合は、解凍ユーティリティで別の抽出オプションを使用してZIPファイルを抽出してみます。たとえば、7-Zipを使用してファイルを抽出している場合は、フル・パス名オプションを選択します。Windows解凍ユーティリティではライブラリZIPファイルを抽出できません。
プラットフォーム: すべて
『Oracle WebLogic Serverインストレーション・ガイド』の表5-1に、次の2つのコンポーネント・パスが有効なコンポーネント・パスとして示されています。このいずれかのコンポーネント・パスを使用するとサイレント・インストールが失敗します。
WebLogic Server/WebLogic Web Server Plugins - Web Server PluginsコンポーネントはWebLogic Server 12.1.1でサポートされていません。
WebLogic Server/Xquery Support - Xqueryサポートをインストールするには、WebLogic Server/UDDI and Xqueryサポートとしてパスを入力します。UDDIはWebLogic Server 12.1.1に含まれないため、インストールにも含まれません。
