この章では、Oracle WebLogic Serverに関連する問題について説明します。内容は次のとおりです。
注意: WebLogic Server 11g リリース1(10.3.5)で修正された不具合のリストを参照するには、「ナレッジ・ベースの検索」フィールドに次のドキュメントIDを入力してください。このドキュメントIDをそのまま入力する必要があります。1302753.1 |
この項では、次の問題および回避方法について説明します。
Oracle Fusion Middleware 11gには、Oracle WebLogic Server 11gが含まれます。Oracle WebLogic Serverのリリース番号は、10.3.5です。
Oracle ojdbc14.jar
ファイルは、JDK 5または6で使用できるojdbc6.jar
に変更されました。そのため、ojdbc14.jar
に対する明示的な参照は、すべてojdbc6.jar
に変更する必要があります。
今回のリリースのWebLogic Serverで厳密なパスワード強制(1つ以上の数字または特殊文字を含む最低8文字のパスワード)を実装すると、既存のスクリプトに問題が発生する可能性があります。
回避方法
新しいパスワードの制限を回避するには、次のいずれかの方法を使用します。
BACKWARD_COMPAT_PW_CHECK
環境変数をtrue
に設定します。
WLSTの起動時に-Dbackward.compat.pw.check=true
オプションを含めます。
この変数とオプションは、WebLogic Serverの将来のリリースからは削除される予定のため、新しいパスワード要件に準拠するように現在のパスワードを変更することをお薦めします。
MDSリポジトリを使用する任意のアプリケーションは、id
という名前の属性に対してNULL値が返されるため、WebLogic ServerにバンドルされているJAXBバージョンではデプロイまたは実行できません。
回避方法
サーバーを英語ロケールで起動します。
管理サーバーに対して構成されているファイル・ディスクリプタの最大数が65535未満の場合、WebLogic Server管理サーバーからオープン・ファイルが多すぎる
というメッセージがEnterprise Manager(EM)コンソールにレポートされます。
回避方法
次のコマンドを実行して、現在構成されているファイル・ディスクリプタの最大数を確認します。
cat /proc/sys/fs/file-max
値が65535未満の場合、次の手順を実行します。
root権限で/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
この項では、次の問題および回避方法について説明します。
WebLogic Server管理コンソール・ヘルプが表示されても、左側のペインまたは機能検索にヘルプ・コンテンツが表示されません。
回避方法
SIPおよびWTC l10nコンソール拡張を無効にすると、この問題を解決できます。コンソールの右ペインの最上部にあるバナー・ツールバー領域で、「プリファレンス」→「拡張」を選択します。sipserver-console-ext-l10nおよびwtc-l10nの横にあるチェック・ボックスを選択し、「無効化」をクリックし、管理サーバーを再起動します。
キャッシュされたJDBCの文に関する情報は、JDBCの監視ページには表示されません。
管理コンソールでページ・フローが完了すると、異なるページ(通常は表)に転送されます。
この時点でブラウザの「戻る」ボタンを押すと、完了したアシスタントで最後のJSPファイルのロード操作が試行されます。これにより、このアシスタントのすべてのコンテキストは破棄されます。
回避方法
変更が取り消されるか完了した後に、ブラウザの「戻る」ボタンを使用してアシスタントに戻ることや、アシスタントの前の手順に戻ることはお薦めしません。かわりに、管理コンソールのナビゲーション・リンクおよびボタンを使用してください。
管理コンソールでは、サポート対象外で正常に動作しないワーク・マネージャ構成を作成できます。不適切なワーク・マネージャ構成により、サーバー・ログに多くの例外が記録される可能性があります(通常は、デプロイメント・ディスクリプタの解析中に「検証の問題が見つかりました」
という例外が発生します)。
回避方法
ワーク・マネージャ構成のオンライン・ヘルプで説明されているガイドラインに従います。具体的には、特定のワーク・マネージャに割り当てることができるリクエスト・クラスは1つのみであり、このリクエスト・クラスはワーク・マネージャと同じかそれより広いスコープである必要があります。グローバル・ワーク・マネージャにアプリケーション・スコープのリクエスト・クラスを割り当てたり、1つのアプリケーション・スコープのワーク・マネージャに複数のアプリケーション・スコープのリクエスト・クラスを作成しないようにしてください。
ドキュメントに記載された制約に準拠するようにワーク・マネージャ構成を修正することで、これらの問題を解決できます。
「クラスタ: 監視: 概要」ページの「サーバー状態」表には、「プライマリ」および「セカンダリ分散名」という2つのデフォルト列が含まれます。レプリケーション環境によっては、これらのフィールドに、「クラスタ: 監視: フェイルオーバー」ページで収集および表示されるレプリケーション統計の一部が反映されないことがあります。
正確な情報は、「クラスタ: 監視: フェイルオーバー」ページを参照してください。
管理コンソールで、個別のライブラリ・デプロイメントで定義されたタイプを参照するEJBデプロイメントに対してセキュリティ・ポリシーを定義する場合、そのライブラリ・デプロイメントがコンソールで使用できないと、例外が発生する可能性があります。
回避方法
すべてのライブラリ・デプロイメントは、WebLogic Server管理サーバーに加え、参照するアプリケーションをサポートするために必要な任意の管理対象サーバーをターゲットとする必要があります。これにより、ポリシーの定義時に、コンソールでそれらのライブラリ・デプロイメントにアクセスできるため、参照されるタイプが必要に応じて確実にクラス・ロードされます。
管理コンソールには、デプロイメント・プランで行われた外部変更が反映されないことがあります。コンソール・ユーザーがデプロイメント・プランを表示しているときに、コンソール外部のデプロイメント・プランで変更が行われると(Workshopの使用、プラン・テキスト・ファイルの直接編集、WLSTまたはwebLogic.Deployerを使用した新規プランによるデプロイメントの更新など)、それらの変更はコンソール・ユーザーに表示されません。
回避方法
別のデプロイメントの構成ページに移動してから、元のデプロイメントに戻ります。
Oracle OCIドライバは、管理コンソールに事前構成済ドライバ・タイプとして明示的にリストされなくなりました。
回避方法
Oracle OCIドライバは、現在もアプリケーション・データ接続用としてサポートされるドライバであり、Oracle WebLogic Serverの以前のリリースと互換性があります。ただし、現在は、データベース・ユーザー名を含むすべての必須構成プロパティを手動で指定する必要があります。
Internet Explorer 7(IE 7)を使用して監視ダッシュボードの「メトリック・ブラウザ」タブにデータを表示する場合、データを表示するのに非常に時間がかかり、その間ページが反応しなくなります。このタブにデータを表示するのに要する時間は、ドメインのサイズに応じて変化します。
回避方法
監視ダッシュボードの「メトリック・ブラウザ」タブにデータを表示する必要がある場合、IE 7以外のサポートされるWebブラウザ(たとえば、Internet Explorer 8以上、Firefox 3以上またはSafari 4以上)で管理コンソールを開きます。
WebLogic Serverの今回のリリースでは、Apache Beehiveサポートに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
存在しないサーバー名を使用してWebLogic Server管理サーバーに接続しようとすると、その存在しないサーバー名に対応するディレクトリがdomain_name
/servers
ディレクトリ内に作成されます。
回避方法
管理サーバーに接続する際は、有効なサーバー名を指定します。
WebLogicパスワードを入力した直後に[Ctrl]を押しながら[C]を押してstartManagedWebLogic.sh
プロセスを終了すると、ターミナル・ウィンドウで異常な動作が発生することがあります。たとえば、[Return]を押すと、プロンプトは次の行に移動するかわりに[Tab]を押した状態になり、プロンプトに入力した任意の文字は端末に表示されません。
回避方法
現在のxtermを終了して新規に開始するか、xtermにstty echo
と入力します。
次の場合、WebLogic Serverドメインの作成および更新に時間がかかる可能性があります。
インストールにServer Examplesが含まれるWebLogic ServerをUNIXまたはLinuxオペレーティング・システムにインストールする場合
WebLogic Server構成ウィザードを使用してドメインを作成または更新する場合
WLSTを使用してドメインを作成または更新する場合
回避方法
CONFIG_JVM_ARGS環境変数を次の値に設定します。
-Djava.security.egd=file:/dev/./urandom
Linuxシステムで、Oracle Fusion Middleware構成ウィザードで新規ドメインを作成する場合、「パスワード」および「パスワードの確認」フィールドを編集できないことがあり、パスワードを入力してドメインを作成できません。
回避方法
この問題を回避するには、2つの方法があります。
問題が発生するたびに回避するには、構成ウィザードの右上にある「ウィンドウを閉じる」(X)ボタンをクリックします。表示される確認ダイアログで、「いいえ」をクリックして構成ウィザードに戻ります。これにより、ドメインのパスワードを入力および確認できるようになります。
この問題を完全に修正する手順は、次のとおりです。
すべてのscimプロセスを強制終了します。次に例を示します。
kill `pgrep scim`
ファイル~/.scim/config
を変更(または作成)し、次の行(大文字と小文字は区別)を含めます。
/FrontEnd/X11/Dynamic = true
VNCを実行している場合、VNCサーバーを再起動します。
構成ウィザードを再実行します。
WebLogic Serverの今回のリリースでは、コネクタ(リソース・アダプタ)に関する既知の問題は存在しません。
WebLogic Serverの今回のリリースでは、コンソール拡張に関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
いずれかの管理対象サーバーをホストするマシンが異常停止した状態、ネットワーク・ケーブルが外れた状態、またはネットワーク・インタフェース・カードに問題が発生した状態で、サーバーがその管理対象サーバーと通信しようとすると、スレッドが接続の取得を待機してスタックします。
回避方法
この問題は、現在、次のプライベート・フラグを使用して解決できます。
-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オブジェクトのすべてのインスタンス状態は保持されます。
オブジェクト状態が保持されない変更タイプの1つとして、フィールド名の変更があげられます。このとき、フィールドは次のように処理されます。
古い名前を持つフィールドは削除されます。
新しい名前を持つフィールドは追加されます。
つまり、この場合、古いフィールドの状態は名前の変更されたフィールドに継承されません。
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
でリスニングするように構成します。
再起動したサーバーは、hostname1-s
でリスニングします。この理由は、Windowsが実際のノードのホスト名を最初に有効なイーサネット・カードのアドレスに解決するためです。
回避方法
この問題には次の3つの回避方法のいずれかを使用します。
WebLogic Server管理サーバーのリスニング・アドレスとして、ホスト名ではなくIPアドレスを使用します。管理対象サーバーでは、リスニング・アドレスとしてIPアドレスを使用するか、マシンの最初のイーサネット・カードに対して実際の物理ホスト名を構成します。
マシンのC:\Windows\system32\drivers\etc\hostsファイルに次のエントリを追加します。
<ip_address> <hostname>
実際のノードのホスト名を持つカードがカード1になるようにマシンのネットワーク・カードの順序を変更します。
コマンドラインで間違ったWebLogic Server管理サーバーURLを指定して管理対象サーバーを起動すると(つまり、指定したURLで管理サーバーに接続できない場合)、管理対象サーバーは、管理対象サーバー独立(MSI)モードで起動されます。
この場合、管理サーバーとノード・マネージャのどちらも管理対象サーバーのステータスを追跡できません。管理コンソールには、管理対象サーバーのステータスは「不明」と表示されますが、サーバーは実際にはMSIモードで実行されています。
この項では、次の問題および回避方法について説明します。
12.9.1項「weblogic-application.xmlでsecurity-permission要素が使用できない問題」
12.9.5項「プランの適用時に「"config-root" <directory>が見つかりませんでした」という警告が表示される問題」
12.9.8項「別のソース・ファイルの場所を使用してアプリケーションがすでにデプロイされている場合、アプリケーションの再デプロイに失敗する問題」
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
このとき、ツールでは、trueという名前のファイル指定をアクティブ化しようとします。-nostage
オプションは引数を取らず、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();
管理コンソールを使用してアプリケーションの構成を変更すると、デプロイメント・プランが生成されます。外部ディスクリプタがデプロイメント・プランの一部として生成されると、それらは構成ルートのplanディレクトリに配置されます。このディレクトリは、デプロイメント・プランのconfig-root属性に設定されます。
外部ディスクリプタが必要ない場合、構成ルート・ディレクトリは作成されず、デプロイメント・プランの適用時に警告が表示されます。この結果、サーバー出力に次の警告が記録されます。
<Warning <WWebLogicDescriptorWL> <BEA-2156000><"config-root" C:\deployments\plan was not found>.
回避方法
planディレクトリを手動で作成します。
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を使用している場合、このフラグは必要ありません。
管理対象サーバーの起動時にWebLogic Server管理サーバーが使用できない場合、管理対象サーバーはMSIモードで起動されます。後で管理サーバーを起動すると、管理対象サーバーはその管理サーバーに接続されます。ただし、管理対象サーバーにデプロイされた各アプリケーションの状態は、管理対象サーバー上のアプリケーションの状態を反映するために更新されません。各アプリケーションの状態は、WebLogic Server管理コンソールに「新規」または「準備完了」として表示されます。
回避方法
この問題には、次の2つの回避方法があります。
管理対象サーバーを起動する前に管理サーバーを起動します。
管理サーバーの起動後にアプリケーションを再デプロイします。
あるソース・ファイルの場所を使用して最初にアプリケーションをデプロイし、その後で新しいソース・ファイルの場所を使用してアプリケーションを再デプロイしようとすると、次の例外が発生してデプロイメントが失敗します。
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のデプロイメントの制限が原因です。1度デプロイメントのソース・ファイルを指定すると、再デプロイメントに際してこれを変更することはできません。
回避方法
新しいソース・ファイルの場所を使用して再デプロイを試みる前に、アプリケーションをアンデプロイします。
この項では、次の問題および回避方法について説明します。
12.10.8項「@Idフィールドに@Uniqueのアノテーションも付けるとOpenJPAにより例外がスローされる問題」
12.10.12項「非トランザクション・メッセージドリブンBeanのコンテナで外部トピックに対して再現可能な動作を提供できない問題」
Oracle表の主キーはCHARですが、SQL表の問合せフィールドはVARCHAR2です。
回避方法
データベース・スキーマをCHARからVARCHAR2に変更します。CHARを主キーとして使用することは、Oracle Databaseでは推奨されません。
クラスタ化可能なタイマーを作成できるEJB3 BeanまたはEjbgen
のアノテーションはありません。
回避方法
weblogic-ejb-jar.xmlファイルを作成し、<timer-implementation>
要素および対応する値をそのファイルに配置します。
Kodoのマッピング・ツールでは、主キーでBLOBを使用するクラスのスキーマを生成できません。BLOBは、主キーで使用できますが、スキーマは手動で定義する必要があります。主キーでのBLOB列のサポートは、JDOまたはJPAのどちらの仕様にも規定されていないことに注意してください。
JPAメタデータ・モデルの拡張は、アノテーションを通じてのみ指定可能であり、仕様に定義されているorm.xmlファイルなどの構造では指定できません。
回避方法
オブジェクト・モデルにKodo固有のメタデータを指定するには、次のいずれかを行います。
Kodo固有のアノテーションを使用します。
XMLベースのメタデータを、拡張のXML指定がサポートされるJDOメタデータ形式に変換します。
WebLogic Springインジェクションの拡張モデルでは、lookupメソッドのインジェクションはサポートされません。
管理環境でのJDO PersistenceManagerFactory
のデシリアライズは、失敗する可能性があります。例外により、javax.jdo.PersistenceManagerFactoryClass
プロパティが欠落していると報告されます。管理環境では、一般的に、PersistenceManagerFactory
のシリアライズは必要ありません。
クラス・レベルで宣言された索引が、スキーマ作成時に作成されないことがあります。
回避方法
スキーマ生成ツールの実行後に手動で索引を作成します。
一部のデータベースで@Id
フィールドに@Unique
のアノテーションも付けると、OpenJPAにより例外がスローされます。データベースの主キーは、定義上一意です。一部のデータベースでは、列に一意索引を作成することでこれを実装しています。
回避方法
単一のフィールドに@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を構成しないでください。
IIOPを使用してサーバーからクライアントにJPAエンティティを送信するEJBアプリケーションは、エンティティがシリアライズ可能(ただし、外部化不可能)で、writeObject()
メソッドを宣言していない場合、失敗します。
回避方法
該当するエンティティ・クラスにwriteObject()
メソッドを追加します。書込みオブジェクトは次のように簡単なものでかまいません。
private void writeObject(java.io.ObjectOutputStream out) throws IOException { out.defaultWriteObject(); }
外部トピック(WebLogic以外)のJMSを指定する非トランザクション・トピックのメッセージドリブンBean(MDB)に対してマルチスレッド処理を使用する場合、MDBコンテナで再現可能な動作を提供できないことがあります。たとえば、onmessage()
メソッドでruntimeException
がスローされても、コンテナでは引き続きメッセージに肯定応答を返す可能性があります。
回避方法
デプロイメント・ディスクリプタでmax-beans-in-free-pool
属性を1に設定します。
この項では、次の問題および回避方法について説明します。
SAMPLES_HOME/server/medrec/setup/build.xml
のmedrec.wls.config
ターゲットには、セキュリティ構成に関連する既知の問題があります。
../xml/stax
サンプルには、同じ名前で拡張子が異なるStreamParser.java
およびStreamParser.jsp
という2つのファイルが含まれます。ただし、サンプル・ビューア・ビルドでは、ファイル・タイプごとに2つではなく、ただ1つの対応するHTMLファイルが作成されます。この場合、StreamParser.jsp
ファイルのみに同等のHTMLファイルが作成され、StreamParser.java
ファイルには作成されません。
この問題の原因は、ドキュメントのファイルを生成するjava2html
の動作を制御するbuild.xmlファイルの設定にあります。
java2html
を使用すると、useShortFileName="true"
パラメータにより、ソース・ファイルのファイル拡張子が切り捨てられ、HTML出力ファイルのファイル名が作成されます。2つのファイルが同じ名前で拡張子が異なる場合、最後に生成されたHTMLファイルが常に前のファイルを上書きします。
回避方法
useShortFileName
パラメータをfalseに設定します。この設定により、名前にファイル拡張子を含むHTMLファイルが生成されます。この解決方法のデメリットは、関連するファイルがこの不具合により影響を受けていたかどうかにかかわらず、HTML出力ファイルを参照しているすべてのリンクを修正する必要があることです。
medrecまたはサンプル・ドメインを起動すると、次のような警告メッセージが表示されることがあります。
<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パブリッシュ/サブスクライブ・サーバーでは、ローカル・クライアントの認証および認可をサポートしていません。ローカル・クライアントには、HTTPパブリッシュ/サブスクライブ・サーバーのチャネルを操作するためのFULL権限があります。つまり、ローカル・クライアントは、チャネルを作成または削除したり、チャネルからイベントをパブリッシュまたはサブスクライブできます。
クラスタ環境では、あるサーバーのローカル・クライアントによりパブリッシュされたイベント・メッセージは、同じサーバーに接続されたサブスクライブ済クライアントによってのみ受信されます。これらのメッセージは、クラスタ内の別のサーバーに接続されたサブスクライブ済クライアントでは受信されません。
ローカル・クライアントにより任意のチャネルにパブリッシュされたイベント・メッセージには、そのチャネルに対して構成されたメッセージ・フィルタが適用されません。
この項では、次の問題および回避方法について説明します。
12.13.2項「アップグレード・インストールの中断後に発生することのある前のインストール環境への不適切なロールバック」
12.13.3項「Smart Updateを使用してWebLogic Server 10.3.4にアップグレードできない問題」
Oracle WebLogic Server 11g リリース1のインストーラでは、Sybase JDBCドライバがダウンロードされません。最新のインストーラを使用して既存のWebLogic Server 10.3インストール環境をアップグレードする場合、元のインストール環境からSybase JARファイルは削除されません。このインストーラでは、weblogic.jar
ファイルのみがアップグレードされます。
/server/libまたは/server/ext/jdbc/sybaseディレクトリのSybase JARファイル(jconn2.jar、jconn3.jarおよびjConnect.jar)は、アップグレードされたweblogic.jarファイルのマニフェスト・クラスパスから削除されます。そのため、WebLogic ServerアプリケーションのクラスパスにSybase JARファイルが含まれず、weblogic.jarのみが含まれる場合、アップグレード・インストール後にアプリケーションからClassNotFoundExceptionがスローされます。
この問題を回避するには、WebLogic Serverアプリケーションのクラスパスに明示的にSybase JARファイルを追加します。
アップグレード・インストーラまたはSmart Updateを使用して既存のWebLogic Server 10.3.xインストール環境をWebLogic Server 10.3.4にアップグレードする場合、完了前にアップグレードを中断すると、通常、インストール環境は自動的に前のインストール環境にロールバックされます。この正常な操作は行われないことがあり、結果として使用できないインストール環境が生成されます。
Smart Updateを使用して、WebLogic 10.3.4をダウンロードして既存のWebLogic Server 10.3.xの上にインストールすることはできません。かわりに、My Oracle Supportから適切なWebLogic Serverアップグレード・インストーラをダウンロードする必要があります。次のパッチ番号を検索して参照してください。
11060985—WebLogic Server 10.3.4汎用アップグレード・インストーラ
11060966—Linux 32ビット・システム用のWebLogic Server10.3.4アップグレード・インストーラ
11060958—Windows 32ビット・システム用のWebLogic Server10.3.4アップグレード・インストーラ
11060943—Solaris 32ビット・システム用のWebLogic Server10.3.4アップグレード・インストーラ
Smart Updateを使用して、WebLogic Server 10.3.4より前のサポート対象リリースのパッチ・セットまたはメンテナンス・パックをダウンロードしてインストールすることは可能です。また、Smart Updateを使用して、WebLogic Server 10.3.4を含む任意のサポート対象リリースの個別パッチをダウンロードすることも可能です。
QuickStartウィンドウ(「スタート」メニューからアクセス可能)でドキュメントへのオンライン・アクセスをクリックすると、Oracle Fusion Middleware 11gリリース1(11.1.1.4)ドキュメント・ライブラリに移動します。このリンクを使用して、次の場所にあるOracle Fusion Middleware 11gリリース1(11.1.1.5)ドキュメント・ライブラリにアクセスできます。
ファイル・システムまたはディスク上に使用可能なディスク領域が大量にあっても、WebLogic Serverインストーラが失敗してディスク領域の不足エラーが発生する可能性があります。
回避方法
インストール・コマンドの-Dspace.detection
プロパティを使用して、使用可能な領域チェックを無効にしてください。次に例を示します。
java -Xmx1024M -Dspace.detection=false -jar
installer_file_name
-mode=silent -silent_xml=silent.xml
または
wls1034_linux.bin -Dspace.detection=false
インストーラでは、インストールの完了前にマシン上に十分なディスク領域が存在するかどうかが検証されません。結果として、領域不足が原因でインストールを完了できないと、次のエラー・メッセージが表示され、インストールは終了します。
Fatal error encountered during file installation. The installer will now cleanup and exit!
回避方法
この問題が発生した場合、次のコマンドを使用してインストーラを再実行します。
server103_linux32.bin -log=log.out -log_priority=debug
前述のコマンドにより、インストール操作のログが生成されるため、障害の正確な原因を詳細に調査できます。原因が実際に領域不足であった場合、ログ・ファイルにそのことが明示的に示されます。
この項では、次の問題および回避方法について説明します。
FastSwapでは、フィールドやメソッドのアクセス修飾子が緩和されることがあります。privateおよびprotectedメンバーは、実行時にpublicになる可能性があります。これにより、リフレクションの動作が変更されるため、Strutsなどのリフレクションベースのフレームワークが影響を受ける可能性があります。
FastSwapでは、エンティティBeanおよびejbClass(セッション/MDB)の再定義はサポートされません。そのため、エンティティ・クラスを更新すると、再定義エラーが発生します。
回避方法
エンティティ・クラスの更新後に、アプリケーションを再デプロイします。
この項では、次の問題および回避方法について説明します。
WebLogic Serverリリース10.3.2で、OEM DataDirectドライバは4.0にアップグレードされました。SQLServerドライバで新しいDBMSデータ型をすべて処理するため、デフォルト構成で実行すると、問合せに時間がかかります。新規データ型に対するアプリケーション・アクセスをgetString()
に制限できる場合、次の構成の回避方法でパフォーマンスが回復します。
回避方法
WebLogicデータソースの接続プールにおけるドライバ・プロパティのリストに次のドライバ・プロパティを追加します。管理コンソールで、データソースの「構成」→「接続プール」タブを選択します。
XA以外の接続プールでは、次のプロパティを追加します。
ReportDateTimeTypes=false
XA接続プールでは、次のプロパティを追加します。
ExtendedOptions=ReportDateTimeTypes=false
別の方法として、データソースのXML構成ファイルにプロパティを追加して、同じ結果を得ることができます。
XA以外の場合:
<jdbc-driver-params> <properties> <property> <name>ReportDateTimeTypes</name> <value>false</value> </property>
XAの場合:
<jdbc-driver-params> <properties> <property> <name>ExtendedOptions</name> <value>ReportDateTimeTypes=false</value> </property>
新規システム・プロパティの-Dweblogic.jdbc.remoteEnabled
がOracle WebLogic Server 10.3.2のJDBCに追加されました。WebLogic Serverの以前のリリースとの互換性を確保するため、このプロパティのデフォルト設定はtrue
です。このプロパティをfalse
に設定すると、リモートJDBCアクセスは無効になり、そのようなアクセスがあると、例外が発生します。
リモート・アクセスは、アプリケーション内で明示的に行われる場合と、LLR、1PCまたはXAのエミュレートのグローバル・トランザクション・オプションを使用して構成されて参加している非XAデータソースを持つグローバル(XA/JTA)トランザクション中に暗黙的に行われる場合があります。次の一覧は、例外がスローされる事例と各事例の回避方法(存在する場合)を示します。
例外は、次のような場合に発生します。特定の事例の回避方法(存在する場合)も示します。
スタンドアロン・クライアント・アプリケーションが任意のタイプのデータソースを使用する場合。
WebLogic Serverでホストされているアプリケーションが任意のタイプのデータソースを使用し、データソースがローカルに構成(ターゲット指定)されていない場合。潜在的な回避方法としては、データソースをローカルにターゲット指定します。
同じグローバル・トランザクション内の複数のWebLogic Serverインスタンスに対するLLR、1PCまたはXAのエミュレートのトランザクション・オプションを使用した、同じ名前の非XAデータソースにアクセスする場合。この場合、潜在的な回避方法は2種類あります。
XAをかわりに使用するようデータソースを変更します(パフォーマンスが低下する可能性があります)。
1PC/エミュレートXAタイプの場合、単一サーバーからデータソースにアクセスできるようアプリケーションを変更します。
トランザクション・コーディネータとは異なるサーバーに対するLLRトランザクション・オプションを使用した非XAデータソースにアクセスする場合。サーバーが開始したトランザクションの場合、コーディネータの場所は、トランザクションに最初に参加したリソースに基づいて選択されます。この場合、潜在的な回避方法は次の2種類あります。(a) XAをかわりに使用するようデータソースを変更します(パフォーマンスが低下する可能性があります)。(b) トランザクション・コーディネータ上でデータソースにアクセスできるようアプリケーションを変更します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング』のLLRを使用したパフォーマンスの最適化に関する項を参照してください。後者の回避方法は一部の事例では使用できない可能性があります。たとえば、MDBアプリケーションがリモートWebLogic JMSサーバーからメッセージを受信する場合、トランザクション・コーディネータは常に、JMSサーバーをホストしているWebLogic Serverになりますが、MDBアプリケーションを同じWebLogic Serverに移動できない可能性があります。
XAをかわりに使用するようデータソースを変更します(パフォーマンスが低下する可能性があります)。
トランザクション・コーディネータ上でデータソースにアクセスできるようアプリケーションを変更します。詳細は、『Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミング』のLLRを使用したパフォーマンスの最適化に関する項を参照してください。この回避方法は一部の事例では使用できない可能性があります。たとえば、MDBアプリケーションがリモートWebLogic JMSサーバーからメッセージを受信する場合、トランザクション・コーディネータは常に、JMSサーバーをホストしているWebLogic Serverインスタンスになりますが、MDBアプリケーションを同じWebLogic Serverインスタンスに移動できない可能性があります。
データ・ダイレクトMSSQLドライバを使用し、updateBlob()
メソッドとupdateBinaryStream()
メソッドを使用してRowSet
オブジェクトのBLOBデータを更新しても、データはデータベースで更新されません。
複数のOracle RACデータベース・ノードを使用しているSOAサーバーで、XAおよびロード・バランシングに対してWebLogic Serverのマルチ・データソースが構成されている場合、ORA-10591エラーが発生します。
回避方法
Linux x86、Oracleリリース11.1.0.7.0用のOracle RACデータベース・パッチ7675269をダウンロードして適用します。このパッチはMy Oracle Supportからダウンロードできます。また、Linux x86、Oracleリリース11.1.0.7.0用のパッチ・セット9007079をダウンロードして適用することもできます。これには、パッチ7675269が含まれます。
この項では、次の問題および回避方法について説明します。
デプロイメント・ディスクリプタの検証が有効化されており、EARファイルにJMSモジュールのみが含まれる場合、ディスクリプタの検証は失敗します。
回避方法
J2EE仕様に準拠したモジュールがEARに少なくとも1つ存在することを確認します。
複数のJMSプロデューサで同じJMSクライアントSAFインスタンスを(単一のJVM内で)使用すると、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名にはマルチバイト・キャラクタを使用しないでください。
WebLogic Server 10.3.4には、JMSの通常の宛先、分散宛先またはテンプレートにデフォルトの順序単位(UOO)を設定する構成の修正が含まれます。この修正により、宛先のホストJMSサーバーの再起動後も、デフォルトの順序単位名が同じであることが保証されます。現在、デフォルトのUOO名は、ドメイン、JMSサーバーおよび宛先名に基づきます。
JMSメッセージおよびトランザクション・ログをNFSにマウントされたディレクトリに格納している場合、予期しないマシン障害の後にサーバーの再起動の動作を確認することを強くお薦めします。NFSの実装に応じて、フェイルオーバーおよび再起動後に異なる問題が発生する可能性があります。詳細は、6.3項「NFSでのファイル・ストアの使用時におけるWebLogic Serverの予期しない障害のテスト」を参照してください。
JMSメッセージ・コンシューマは、アプリケーションのWLConnection.getReconnectPolicy()
属性がall
に設定されている場合、サービスの移行後に再接続できないことがあります。コンシューマが移行されないと、例外がスローされるか、またはコンシューマが有効でなくなったことをアプリケーションに通知するonException
が発生します。
回避方法
アプリケーションでは、例外ハンドラまたはonException
を通じてコンシューマをリフレッシュできます。
一部の状況では、JNDIの更新頻度が非常に高くなるため、JMSサブスクライバでjava.naming.NameNotFoundException
が発生する可能性があります。詳細は、12.8.5項「ユニキャスト・メッセージの順序どおりの処理の強制」を参照してください。
WebLogic Serverの今回のリリースでは、JNDIに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
デプロイメント・プランを使用して、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拡張モデルが有効化されている場合、パフォーマンス上の理由から、WebLogic Server 10.3以上ではJSPタグ・ハンドラでSpring依存関係インジェクション(DI)がサポートされません。
現在、WebLogic Serverでは、サーブレット、フィルタ、リスナーなど、ほとんどのWebコンポーネントでSpring DIがサポートされます。ただし、現在のところ、パフォーマンス上の理由からJSPタグ・ハンドラではSpring DIはサポートされません。
セッションが永続的で、古いバージョンのサーブレット・コンテキストがリタイアされたときに、有効なsessionid
でアプリケーションにアクセスすると503エラーが発生します。
たとえば、バージョン付きWebアプリケーションのセッション永続タイプがfileであるとします。ユーザーは、このアプリケーションに正常にアクセスできます。その後、このアプリケーションのバージョン2が再デプロイされ、バージョン1はリタイアされます。同じユーザーがこのアプリケーションにアクセスすると、503エラーが発生します。
WebLogic Serverの今回のリリースでは、JTAに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
Sun Microsystems VMの既知の不具合(513552)のため、1.4シン・クライアント・アプレットではWebLogic Server 9.0以上に接続できません。これは、VMがクライアント接続とサーバー接続を正しく区別できないことが原因です。VMでは、サーバー・タイプの接続を作成してキャッシュします。その後、クライアント・タイプの接続を作成する際に、キャッシュされた接続を検出してその使用を試みますが、クライアントではサーバー接続の使用が許可されないため、エラーが発生します。
Intel G5プロセッサ上のRH Linuxで実行され、システム時間コールを直接的または間接的に使用するアプリケーションでは、ClockSource
がtsc
(デフォルト)に設定されていると、断続的に時間の問題が発生する可能性があります。標準のPOSIX C gettimeofday()
コールと、関連するJava System.currentTimeMillis()
およびjava.util.Date()
コールでは、シングル・スレッド・アプリケーションであっても、現在から約4400秒後の値を断続的に返す可能性があります。
この問題は、WebLogicやJavaに固有ではなく、Intel G5プロセッサ上のRH Linuxで稼働するすべてのアプリケーションに適用されます。この問題は、標準のJavaを使用して明示的に時間コールを行うアプリケーションで発生するか、または時間ベースの任意のアプリケーション・サーバー・サービスを明示的に使用するアプリケーションで発生する可能性があります。
問題発生の可能性となる兆候には、早すぎるトランザクション・タイムアウト、予期しないJMSメッセージの期限切れ、およびスケジュールされたタイマーの誤動作などがあげられます(ただし、これら以外の兆候も考えられます)。
この問題の単独の再現方法に興味がある場合は、オラクル社に連絡して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
を参照してください。
無制限のロールフォワードの一環として長い配列のコピーを実行すると、JRockit JVMがフリーズしたように見えます。この問題は、メモリー不足
状態により複数のサーバーで再起動が行われると、発生することがあります。
回避方法
サーバーの起動時に、次のJRockit JVMフラグを指定します。
-XXrollforwardretrylimit:-1
最新のJVMにアプリケーションをデプロイしても、IBM Java 6 JDKの以前のサービス・リリースでコンパイルした場合、シリアル・バージョンUIDの不一致の問題が発生します。
回避方法
以前にコンパイルしたアプリケーションのシリアライズとの互換性を維持するには、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を持つように状況に応じて再コンパイルする必要があります。
WebLogic Serverの実行時にJVMスタック・オーバーフロー・エラーまたは例外が発生することがあります。この問題は、AMD64および64ビットXeonプラットフォーム上のOracle Enterprise Linux 4、5および5.1が対象となります。
回避方法
スタック・サイズをデフォルトの128Kから256Kに増やします。
この項では、次の問題および回避方法について説明します。
@unharvestable
タグは、インタフェース・レベルでは評価されません。明示的に@unharvestable
とマークされていないMBean属性は、収集可能とみなされ、WebLogic管理コンソールで収集可能として表示されます。
回避方法
MBean属性を明示的に@unharvestable
としてマークできます。
WebLogic Serverの将来のリリースでは、カタログおよび非カタログのメッセージIDに対する現在のデフォルト接頭辞が、現在のBEA接頭辞からWLに変更される予定です。
回避方法
この将来の変更に備えておく必要があります。変更までの間に考慮しておく必要のあるガイドラインは、次のとおりです。
スクリプトやフィルタ式などで、メッセージIDのBEA接頭辞に依存することは避けてください。
次のようなログ・メッセージがあるとします。
<Jan 30, 2009 12:51:49 AM CST> <Notice> <WebLogicServer> <BEA-000365> <Server state changed to STARTING>
この場合、BEA接頭辞ではなく、000365
に対してフィルタを設定することをお薦めします。
ログ解析スクリプトは、BEAのみをフィルタするかわりに、BEAとWLの両方を検索するように更新する必要があります。
WebLogic Server 10.3.3では、デフォルトのWLDF診断ボリューム設定はオフでした。WebLogic Server 10.3.4ではデフォルトの診断ボリューム設定は低ボリュームで、WebLogic Server 10.3.4ではJVMレベルによって生成されるイベントは低ボリュームでは生成されません(WebLogic Server 10.3.3ではJVMレベルのイベントは低ボリューム設定で生成されていました)。WebLogic Server 10.3.4では、JVMレベルのイベントは依然として高ボリュームおよび中ボリューム設定で生成されます。
回避方法
次のいずれかの回避方法を使用すると、JVMレベルのイベントが生成されるようになります。
WLDF診断ボリュームを中または高ボリュームに上げます。
JRMC、JRCMDまたはJRockitコマンドライン設定を使用して、WebLogic Serverインスタンスで別のフライト記録をアクティブ化します。これを行うことにより、すべてのWLDF診断ボリューム設定(オフ、低、中および高)でJVMイベントが存在するようになります。
JVMイベントが有効である場合、次の状況下でWLDFパフォーマンス問題が発生する可能性があります。
他のJRockitフライト記録が有効でない場合、WLDF診断ボリュームを中または高レベルに設定すると、パフォーマンスが低下する可能性があります。
他のJRockitフライト記録が有効である場合、すべてのWLDF診断ボリューム・レベル(オフ、低、中および高)でパフォーマンスが低下する可能性があります。
WebLogic Serverの今回のリリースでは、ノード・マネージャに関する既知の問題は存在しません。
WebLogic Serverの今回のリリースでは、操作、制御および管理に関する既知の問題は存在しません。
WebLogic Serverの今回のリリースでは、Oracle Kodoに関する既知の問題は存在しません。
この項では、様々なWebLogic Serverプラグインに関する次の問題について説明します。
次の状況では、IISプラグインが動作せず、apr_socket_connection
エラーが発生する可能性があります。
IISインスタンスとWeblogic Serverインスタンスの両方が同じマシン上に存在する場合。
IPv6がマシンで有効化されているが、そのマシンがIPv6環境内に存在しない(つまり、IPv6インタフェースが有効だが機能していない)場合。
WebLogic Serverサーバー・インスタンスのリスニング・アドレスが単純なホスト名に設定されている場合。
WebLogicHostまたはWebLogicClusterディレクティブのいずれかがIISインスタンスの単純なホスト名に設定されている場合。
WebLogic Serverの今回のリリースでは、プロトコルに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
Antバージョン1.7のrmic
タスクをコールすると、自動的に-vcompat
フラグが追加されますが、これは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}"
この項では、次の問題および回避方法について説明します。
12.28.1項「適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能するStoreBootIdentity」
12.28.5項「SAML 2.0サービス・プロバイダ・サービスで「認証」属性と「パッシブ」属性の両方を有効化すると無効な構成になる問題」
-Dweblogic.system.StoreBootIdentity
オプションは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能します。このディレクトリは、通常、構成ウィザードまたはアップグレード・ツールにより作成されます。
ただし、適切なサーバー・セキュリティ・ディレクトリが、ソース・コントロール・システムにチェックインされるドメインに存在しないこともあります。
WebLogic Serverインスタンスは、RDBMSセキュリティ・データ・ストアがWebLogic Serverに付属するDB2ドライバを使用してDB2データベース用に構成されている場合、SecurityServiceException
により起動時に障害が発生する可能性があります。
回避方法
RDBMSセキュリティ・データ・ストアでDB2データベース用にAlternateId
接続プロパティを使用する場合、WebLogic Serverに付属するDB2ドライバの使用時に追加プロパティのBatchPerformanceWorkaround
もtrue
に設定する必要があります。
ドメインをWLS 6.1からアップグレードすると、認証障害によりWebLogic Serverインスタンスが起動しなくなります。
回避方法
WebLogic Serverインスタンスを正常に起動させるためには、アップグレード・プロセスの前または後にWLS 6.1ドメインでシステム・ユーザー・パスワードを設定する必要があります。
SAML 2.0のアイデンティティ・プロバイダ・サービスまたはサービス・プロバイダ・サービスを構成し、SAML 2.0サービスのメタデータ・ファイルを公開しようとすると、InvalidParameterException
メッセージが生成され、管理コンソールに表示されることがあります。
回避方法
WebLogic ServerインスタンスでSAML 2.0フェデレーション・サービスを構成する際に、構成対象のSAMLロールで使用可能なすべてのバインディング・タイプが有効化されていることを確認します。たとえば、SAML 2.0アイデンティティ・プロバイダ・サービスを構成する場合、POST、リダイレクトおよびアーティファクト・バインドを有効化する必要があります。SAML 2.0サービス・プロバイダ・サービスを構成する場合、POSTおよびアーティファクト・バインドを有効化します。オプションで、優先バインドを選択することもできます。
SAML 2.0サービス・プロバイダ・サービスを構成する場合、「強制認証」属性と「パッシブ」属性の両方を有効化すると、WebLogic Serverで検出できない無効な構成になります。これら両方の属性が有効化された状態で、認証されていないユーザーがサービス・プロバイダ・サイトでホストされるリソースにアクセスしようとすると、例外が生成されてシングル・サインオン・セッションに失敗します。
SAMLログアウトはWebLogic Serverでサポートされないため、「強制認証」属性は無効であることに注意してください。そのため、ユーザーがすでにアイデンティティ・プロバイダ・サイトで認証されている状態で「強制認証」を有効化しても、ユーザーはアイデンティティ・プロバイダ・サイトで再度認証を強制されることはありません。
これら両方の属性を有効化することは避けてください。
たとえば、fork=true
属性なしでAntスクリプトから呼び出された<java>
タスクを使用する場合など、WebLogicフル・クライアントが非分岐VMで実行されている場合、次のエラーが発生する可能性があります。
java.lang.SecurityException: プロバイダ自己整合性チェックに失敗しました。
このエラーは、RSA Crypto-Jライブラリがロードされるときに自動的に実行される自己整合性チェックが原因で発生します。(Crypto-Jライブラリcryptoj.jar
は、wlfullclient.jar
マニフェスト・クラスパスにあります。)
この自己整合性チェックの失敗が発生するのは、次の状況のように、クライアントが非分岐VMで開始されてCrypto-J APIを間接的または直接的に使用する場合です。
クライアントがCrypto-Jライブラリを直接呼び出します。
クライアントがT3S接続の確立を試行するため、基礎となるクライアントSSL実装がトリガーされ、Crypto-J APIが呼び出されます。
自己整合性チェックが失敗すると、Crypto-J APIのこれ以上の呼び出しが失敗します。
回避方法
Antスクリプトから呼び出された<java>
タスクでフル・クライアントを実行する場合、fork
属性を常にtrue
に設定してください。
自己整合性チェックの詳細は、次のURLにある「Java(tm) Cryptography Architectureのプロバイダの実装方法」の「プロバイダが自己整合性チェックを行う方法」を参照してください。
予測不可能な乱数を生成するために、SSLセキュリティ・コードはマシンのエントロピに依存します。エントロピとは、マウスの移動、ディスクI/O、ネットワーク・トラフィックなどのアクティビティです。エントロピがごくわずかであるか、存在しない場合、乱数ジェネレータの速度は遅くなり、セキュリティ操作がタイムアウトする可能性があります。これにより、様々なアクティビティ(セキュアなドメイン・チャネルを使用したドメインでの管理対象サーバーの起動など)に障害が発生する可能性があります。この問題は、通常、起動後の一定期間に発生します。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
を追加します。ただし、この回避方法は、真の乱数のかわりに擬似乱数を使用するため、本番環境では使用しないでください。
WebLogic Serverの今回のリリースでは、SNMPに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
JRockit上でWebLogic Serverを実行すると、OpenJPAのClassFileTranformer
が機能しません。
回避方法
OpenJPAのエンハンサ・コンパイラを通じてビルド時に拡張を適用する代替方法を使用します。LoadTimeWeaver
は使用しないでください。
SpringSourceのpetclinic
サンプルでは、petclinic.war
は問題なくデプロイされます。petclinic.ear
は、正しくパッケージされていないため、WebLogic Serverにデプロイされません。petclinic.ear
のパッケージの修正を依頼するリクエストがSpringSource社に提出されています。
WebLogic Serverの今回のリリースでは、SCAに関する既知の問題は存在しません。
この項では、次の問題について説明します。
WebLogic Server 10.3.1を使用してドメインを作成し、WebLogic Server 10.3にロールバックすると、そのドメインで作成したサーバーを起動できません。これは、既知の制限であり、WebLogic Server 10.3に存在しない新しいスキーマ定義(xmlns.oracle.com
)に対する参照がconfig.xml
ファイルに含まれることが原因です。
この項では、次の問題および回避方法について説明します。
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ページに進むことができます。
Scalar Vector Graphics(SVG)を使用してページをデプロイし、Internet Explorer 7(IE7)を使用してアクセスすると、ページのグラフィック・コンテンツのかわりにソースが表示されます。この問題は、normalモードとosjp.nextモードの両方で発生します。
回避方法
アプリケーション開発者は、各自のアプリケーションにおいて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
は、有効なディレクトリではありません。Jythonをweblogic.jar
から直接使用している場合、これによりWLSTでエラーが発生します。
回避方法
この問題には、次の2つの回避方法があります。
WLSTの起動時に、-Dpython.cachedir=<
valid_directory
>
パラメータを指定します。
weblogic.jar
に含まれる不完全なJythonを使用するかわりに、Jython 2.2.1を個別にインストールします。
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が発生します。
この項では、次の問題および回避方法について説明します。
12.36.1項「weblogic.wsee.jaxws.mdb.DispatchPolicy WorkManagerが見つからない問題」
12.36.3項「WebLogic Advanced Web Services for JAX-WS Extensionテンプレートの適用時の問題のトラブルシューティング」
12.36.11項「JAX-RPCスタイルのJavaBeansに相当するJavaメソッド引数またはリターン・パラメータの処理」
12.36.12項「JWSコールバックで2次元のXMLオブジェクトを使用する場合に発生するIllegalArgumentException」
12.36.16項「xmlcatalog要素のエンティティにリモート・ファイルやアーカイブ内のファイルを指定できない問題」
12.36.19項「JAXRPCクライアントでマルチバイト・キャラクタを含むHTTP SOAPActionヘッダーがエンコードされない問題」
12.36.27項「WsrmClient.getMostRecentMessageNumber()から常にゼロが戻される問題」
一部の状況下で、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を管理サーバーに手動でターゲット指定します。
送信用としてメッセージ転送最適化メカニズム(MTOM)アタッチメントが処理されるWebサービス・クライアント呼出しを実行すると、複数のバッファ・サイズ変更呼出しが発生します。
回避方法
この問題を解決できるパッチがあります。このパッチは、WebLogic Server 10.3.4に対してのみ適用できます。このパッチにはシステム・プロパティjaxws.transport.streaming
が用意されています。このプロパティは、Webサービス・クライアントに対してトランスポート層でストリーミングを有効化または無効化します。Webサービスの対話にクライアントとして参加し、サイズの大きなメッセージを送信しているWebLogic Serverインスタンス上で実行されているCPU高負荷のアプリケーションに対して、このプロパティをtrue
に設定します。
このパッチを取得するには、次のいずれかの手順を実行します。
My Oracle Supportに連絡し、Oracle Bug#9956275のパッチをリクエストします。
My Oracle Supportからこのパッチをダウンロードし、次のMy Oracle Supportドキュメントの指示に従ってSmart Updateを使用してインストールします。
1302053.1
Oracleパッチ番号9956275またはSmart Updateパッチ7Z5Hを検索します。
WebLogic Server 10.3.4から10.3.5にアップグレードした後、WebLogic Advanced Web Services for JAX-WS Extensionテンプレート(wls_webservices_jaxws.jar
)を使用してドメインを作成または拡張する場合、final.pyスクリプトの実行時に例外が発生する可能性があります。完全な詳細および回避方法は、『Oracle WebLogic Server JAX-WS Webサービス・スタート・ガイド』のWebLogic Advanced Web Services for JAX-WS Extensionテンプレートの適用時の問題のトラブルシューティングに関する項を参照してください。
WebLogic Serverでは、JAX-RPC 1.1仕様で要求されているスパース配列および部分転送配列はサポートされません。
Webサービス記述言語(WSDL)のコンパイラでは、シリアライズ可能なデータ型は生成されないため、データをリモートEJBに渡すことや、JMS宛先に格納することはできません。
WebLogic Serverでは、親のWebサービスのターゲット・ネームスペースと一致しないパッケージを含むコールバックでのカスタム例外の使用はサポートされません。
回避方法
コールバックで使用するカスタム例外が、すべて親のWebサービスのターゲット・ネームスペースと一致するパッケージ内に含まれることを確認してください。
プロキシ・サーバーも使用する環境では、JMSトランスポートは使用できません。この理由は、JMSトランスポートの場合、Webサービス・クライアントでは常にT3プロトコルを使用してWebサービスに接続しますが、プロキシ・サーバーではHTTP/HTTPSのみに対応するためです。
複合タイプhttp://www.w3.org/2001/XMLSchema{schema}
をWebサービス・パラメータとして使用するWSDLを処理すると、clientgen
が失敗します。
WebLogic Server 9.2以上では、コールバックWebサービスでJAX RPCハンドラがサポートされません。
回避方法
WebLogic Workshop 8.1で作成したWebサービスとともにJAX RPCハンドラを使用していた場合、そのようなアプリケーションは、コールバック・ハンドラ機能を使用しないように再設計する必要があります。
WebLogic Server 9.2以上では、コールバックWebサービスでメッセージ・レベル・セキュリティがサポートされません。
回避方法
WS-Securityを使用するWebLogic Workshop 8.1で作成したWebサービスは、コールバックでメッセージ・レベル・セキュリティを使用しないように再設計する必要があります。
WebLogic Serverでは、XmlBean
プロパティを含むJAX-RPCスタイルのJavaBeansに相当するJavaメソッド引数またはリターン・パラメータの処理は、サポートされません。たとえば、アプリケーションでは、次のようなシグネチャを含むメソッドを保持できません。
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
が生成されます。
回避方法
現在のところ、この問題に有効な回避方法はありません。
SoapElement[]
を@WildcardBinding(className="javax.xml.soap.SOAPElement[]", binding=WildcardParticle.ANYTYPE)
でWebサービス・パラメータとして使用すると、クライアントで常に空の配列が生成されます。
回避方法
@WildcardBinding
アノテーションを使用してSOAPElement[]
のWildcardParticle.ANYTYPE
に対するデフォルト・バインディングを変更しないでください。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
でポリシー・ファイルを検索します。この場所にポリシー・ファイルが存在しないため、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>
回避方法
次のいずれかの解決策を使用します。
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:
など)を指定することはできません。
回避方法
必要であれば、かわりにカタログ・ファイルにエンティティとしてリモート要素を定義します。
カタログ・ファイルのpublic
要素は、XMLカタログ機能の使用時にはサポートされません。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カタログの制限です。
回避方法
リソースの場所は、インラインで、または1つ以上の外部カタログ・ファイルに(あるいはその両方で)指定できます。外部カタログ・ファイルを使用するには、xml-commons
リゾルバ・ライブラリ(resolver.jar
)がクラスパスに存在している必要があります。外部カタログ・ファイルでは、プレーン・テキスト形式またはXML形式のいずれかを使用できます。xml-commons
リゾルバ・ライブラリがクラスパスに見つからない場合、<catalogpath>
パスで指定された外部カタログ・ファイルは無視され、ログに警告が記録されます。ただし、この場合、インライン・エントリの処理は正常に行われます。
現在のところ、<dtd>
および<entity>
要素のみはインラインで指定できます。これらの要素は、それぞれOASISカタログ・エントリ・タイプのPUBLICとURIに対応しています。
Direct-Write
同期書込みポリシー設定が含まれるファイルベース・ストレージにおいて、負荷の高い状態でWebサービスの信頼できるメッセージング操作を実行すると、WebLogic Serverログに次のようなI/O例外が記録されることがあります。
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
に変更します。
または
Direct-Write同期書込みポリシーを維持したまま、次のJavaシステム・プロパティをWebLogic Serverの起動スクリプトに追加します。
-Dweblogic.store.AvoidDirectIO=true
注意: -Dweblogic.store.AvoidDirectIO システム・プロパティは、WebLogic Server 10.3.4では非推奨になりました。かわりに、ストアの同期書込みポリシーをDirect-Write-With-Cache に構成することをお薦めします。 |
Direct-Write-With-Cache
オプションでは、パフォーマンスが向上する可能性があります。このオプションでは、デフォルトでオペレーティング・システムの一時ディレクトリに追加ファイルが作成されます。
Cache-Flush
およびAvoidDirectIO
による回避方法では、パフォーマンスが低下する可能性があります。状況によっては、ファイル・ストアの異なるブロック・サイズを構成することで、このパフォーマンス低下を緩和するか、排除することが可能です。
これらの設定および追加オプションの重要な情報は、『Oracle Fusion Middleware Oracle WebLogic Serverパフォーマンスおよびチューニング』のファイル・ストアのチューニングに関する項を参照してください。
このリリースでは、スタンドアロンJAX-WSクライアントはサポートされません。
回避方法
Java Standard Edition Release 6(JDK 1.6)Update 4以上と統合されたクライアント側のJAX-WS 2.1を使用します。この場合、WebLogic Server固有のAPISのかわりにJAX-WS APIを使用する必要があります。
JDK 1.6の現行リリースは、http://java.sun.com/javase/downloads/index.jsp
からダウンロードできます。スタンドアロンのJAX WS 2.1クライアント・アプリケーションの記述方法の詳細は、https://jax-ws.dev.java.net/
にあるJAX-WS 2.1参照実装WebサイトのJAX-WSのユーザーズ・ガイドを参照してください。
構成ウィザードを使用して、新規作成されたSOAドメインにWebLogic Server拡張Webサービス・コンポーネントを追加すると、構成が不完全になる可能性があります。デフォルトの即時利用可能なsoa_server1サーバー定義のみを含むクラスタを作成すると、生成されるクラスタには、そのクラスタでWebLogic Server Webサービスを実行するのに必要なリソースが含まれません。
回避方法
この問題には次のいずれかの回避方法を使用します。
構成ウィザードの実行時に、クラスタ内に第2のサーバーを作成します。
「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。
「管理対象サーバーの構成」画面で、管理対象サーバーを追加します。
「サーバーのクラスタへの割当」画面で、デフォルトのsoa_server1サーバーが存在するクラスタにこのサーバーを追加します。
構成ウィザードの「サービスのクラスタまたはサーバーへのターゲット設定」画面で、Webサービス・リソース(WseeJmsServerやWseeJmsModuleなど)をクラスタにターゲット設定します。
これらの回避方法のいずれかによって、構成ウィザードで、WebLogic Server拡張Webサービス・コンポーネントのリソースがクラスタに適用されます。
WebLogic Server 10.3.1からWebLogic Server 10.3.2以上へのアップグレード後、@WebParam(header=true)
の名前属性の値がJWSメソッドのJavaパラメータ名と異なる場合、WSDLパート名の例外が発生する可能性があります。
回避方法
サービスに対してclientgen
を実行し、クライアント・アーティファクトを再ビルドします。
WebSphereをクライアントとして使用し、WebLogic ServerまたはJRFをサービスとして使用するWeb Services Atomic Transaction(WS-AT)1.1の相互運用は、動作しません。
WS-AT 1.1の相互運用は、WebSphereがサービスでWebLogic ServerまたはJRFがクライアントである場合には動作します。この場合、相互運用は、Fix/Feature Pack 7が適用されたWebSphere 7を使用する場合にのみ動作します。
WebLogic Server SCAサービスおよび参照が同じSCAアプリケーションにパッケージ化されており、デプロイされているアプリケーションに対する最初のリクエストが多数の同時リクエストとともに到達すると、(実際のボリュームに応じて)最初のレスポンスが大幅に遅れ、場合によっては最大10分遅れることがあります。
回避方法
この問題を解決するには、次の2つの回避方法のいずれかを使用してください。
SCAサービスおよび参照が同じアプリケーションにパッケージ化されている場合、可能な場合は常にローカル・ワイヤリングを使用します。これを行うには、同じSpringコンテキスト・ファイルで宣言されたSCAサービスの名前と等しい値を使用して、default
プロパティをsca:reference
で指定します。次に例を示します。
<sca:reference name="scareference" ... default="scaservice">
注意: この回避方法を使用できるのは、サービスが参照と同じコンポジット(つまり、同じSpringコンテキスト・ファイル)内にある場合のみです。 |
サービスおよび参照を異なるアプリケーションにパッケージ化し、アプリケーション・レベルのワーク・マネージャを使用します。
weblogic.wsee.reliability2.api.WsrmClient.getMostRecentMessageNumber()
メソッドは、RM対応のクライアント・インスタンス上の最新の呼出しに関連付けられたメッセージ番号を戻すことを目的としています。この番号は最初は0、最初の呼出し後は1、続いて2、という形式になる必要があります。
weblogic.wsee.reliability2.api.WsrmClient.reset()
メソッドは、順序コンテキストをクライアント・インスタンス(ポートまたはディスパッチ)からクリアし、古い順序を参照することなくクライアント・インスタンスを再使用できるようにする必要がありますが、クライアント・インスタンスのリクエスト・コンテキストからCLIENT_CURRENT_SEQUENCE_ID_PROP_NAMEプロパティをクリアしません。
この項では、次の問題および回避方法について説明します。
ビュー・クラスは、接続単位ベースでは設定できません。
2つのアプリケーションが異なる定義を持つ同じビュー名を参照していると、WebLogic Tuxedo Connectorの共有ハッシュ表により、サーバーで予期しない動作が発生する可能性があります。リソース・セクションと同様に、接続のビュー・クラスに対するハッシュ表が存在する必要があります。
回避方法
すべてのWebLogic Workshopアプリケーション全体で定義されたすべてのビュー・クラスが一貫性を持つことを確認します。つまり、同じビュー名で同じビュー・クラスを表していることを確認します。
この項では、ドキュメントの訂正箇所を示します。
WebLogicスクリプト・ツール・コマンド参照では、nmKill
、nmServerLog
、nmServerStatus
およびnmstart
コマンドで「Coherence」がserverType
引数の有効なオプションとしてリストされます。このserverType
オプションは、これらのコマンドに対してサポートされていません。
Windowsの「スタート」メニューから「Oracle Weblogic」→「Weblogic Server」→「Examples」→「Documentation」を選択してExamplesドキュメントにアクセスすると、サンプル・ビューアの「検索」機能が動作しません。
回避方法
サンプル・アプリケーションおよびコード例を検索するには、Examplesサーバーを起動してhttp://localhost:7001/examplesWebApp/docs/core/index.html
に移動します。「手順説明」→「検索」をクリックします。
サンプル・ビューアの「検索」機能では、一部のAvitek Medical Recordsトピックの日本語バージョンと英語バージョンが同時に表示されたトピックが返されることがあります。
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を使用してファイルを解凍する場合、「Full pathnames」オプションを選択します。Windowsの解凍ユーティリティを使用してライブラリZIPファイルを解凍することはできません。
WebLogic Server 10.3.3および10.3.4用の『WebLogic Serverインストレーション・ガイド』の第5章「サイレント・モードでのインストール・プログラムの実行」の表5-1には、Evaluation Databaseがインストール可能なコンポーネントとしてリストされていません。「コンポーネント・パス」行には次のエントリが含まれる必要があります。
WebLogic Server/Evaluation Database
Server Examplesコンポーネントがsilent.xml
に含まれる場合、Evaluation Databaseコンポーネントは自動的にインストールされます。したがって、silent.xml
に明示的に含める必要はありません。ただし、Server Examplesはインストールしないが、Evaluation Databaseはインストールする場合、WebLogic Server/Evaluation Database
をsilent.xml
に含める必要があります。
WebLogic Server 10.3.5では、「クイック・スタート」メニュー、「起動」メニュー、コード例およびサンプル・アプリケーションからオンライン・ドキュメントへのリンクは、WebLogic Server 10.3.4ドキュメント・ライブラリ(http://download.oracle.com/docs/cd/E17904_01/wls.htm)に移動します。
回避方法
オンライン・ドキュメントにアクセスする場合、WebLogic Server 10.3.5ドキュメント・ライブラリのURL(http://download.oracle.com/docs/cd/E21764_01/wls.htm)を使用します。