| Oracle® Fusion Middleware Oracle Fusion Middlewareリリース・ノート 11g リリース1 (11.1.1) for HP-UX Itanium B55937-06 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Fusion Middlewareリリース・ノート 11g リリース1 (11.1.1) for HP-UX Itanium B55937-06 |
|
前 |
次 |
この章では、Oracle WebLogic Serverに関連する問題について説明します。次のトピックが含まれます:
|
注意: WebLogic Server 11gリリース1 (10.3.6)で修正された不具合のリストを参照するには、「ナレッジ・ベースの検索」フィールドに次のドキュメントIDを入力してください。このドキュメントIDをそのまま入力する必要があります。 1302753.1 |
この項では、次の問題および回避策について説明します。
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 Fusion Middleware 11gには、Oracle WebLogic Server 11gが含まれます。Oracle WebLogic Serverのリリース番号は、10.3.6です。
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)コンソールにレポートされます。
回避策
シェル内のファイル記述子の数を増やして、そのシェル内のWLS管理サーバーを再起動します。ファイル記述子の数(nofiles)を増やすコマンドはオペレーティング・システムおよびシェル間で異なりますが、UNIXプラットフォームでは通常ulimitコマンドで実行します。そのため、manページでulimitについて参照してください。
次に例を示します。
$ ulimit -n 65535
Linux x86-64、Microsoft Windows x64 (64-Bit)およびOracle SolarisプラットフォームへのOracle WebLogic Server 10.3.5.0 (PS4)の汎用インストールには、Sun JDK 1.6.0.U35-B52バージョンが必要です。
記載されたバージョンのJDKはOracle Webサイトからダウンロードできません。
http://www.oracle.com/technetwork/indexes/downloads/index.html
次の手順を完了して、必要なJDKバージョンをダウンロードします。
My Oracle Supportにアクセスします。
https://support.oracle.com
「パッチと更新版」タブをクリックします。
パッチ12346791を「パッチ検索」の下の「パッチ名または番号」」フィールドに入力します。
「検索」をクリックします。
このパッチに含まれているREADMEの説明に従って、対象のプラットフォーム用のパッチを選択してダウンロードします。
この項では、次の問題および回避策について説明します。
キャッシュされた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サポートに関する既知の問題は存在しません。
この項では、次の問題および回避策について説明します。
まれに、Fusion Middlware製品のインストールを開始する前にインストール環境にJAVA_OPTIONSがすでに存在する場合、ASProvWorkflowExceptionの原因になってドメインの作成を妨げることがあります。
回避策
Fusion Middleware製品のインストールを開始する前に、既存のJAVA_OPTIONSをクリアします。これらのJAVA_OPTIONSを使用するアプリケーションが環境にある場合、オプションをクリアすると機能しなくなる可能性があります。その場合は、既存のJAVA_OPTIONSをテキスト・ファイルに保存して、他のアプリケーションを実行する別の方法を調査してください。
存在しないサーバー名を使用してWebLogic Server管理サーバーに接続しようとすると、その存在しないサーバー名に対応するディレクトリがdomain_name/serversディレクトリ内に作成されます。
回避策
管理サーバーに接続する際は、有効なサーバー名を指定します。
WebLogicパスワードを入力した直後に[Ctrl]を押しながら[C]を押してstartManagedWebLogic.shプロセスを終了すると、ターミナル・ウィンドウで異常な動作が発生することがあります。たとえば、[Enter]を押すと、プロンプトは次の行に移動するかわりに[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)モードで起動されます。
この場合、管理サーバーとノード・マネージャのどちらも管理対象サーバーのステータスを追跡できません。管理コンソールには、管理対象サーバーのステータスは「Unknown」と表示されますが、サーバーは実際にはMSIモードで実行されています。
この項では、次の問題および回避策について説明します。
11.8.1項「weblogic-application.xmlでsecurity-permission要素が使用できない問題」
11.8.5項「プランの適用時に「"config-root" <directory>が見つかりませんでした」という警告が表示される問題」
11.8.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または10.3.4を使用している場合、このフラグは必要ありません。
管理対象サーバーの起動時にWebLogic Server管理サーバーが使用できない場合、管理対象サーバーはMSIモードで起動されます。後で管理サーバーを起動すると、管理対象サーバーはその管理サーバーに接続されます。ただし、管理対象サーバーにデプロイされた各アプリケーションの状態は、管理対象サーバー上のアプリケーションの状態を反映するために更新されません。各アプリケーションの状態は、WebLogic Server管理コンソールに「NEW」または「PREPARED」として表示されます。
回避策
この問題には、次の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のデプロイメントの制限が原因です。いったんデプロイメントのソース・ファイルを指定すると、再デプロイメントに際してこれを変更することはできません。
回避策
新しいソース・ファイルの場所を使用して再デプロイを試みる前に、アプリケーションをアンデプロイします。
この項では、次の問題および回避策について説明します。
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権限があります。つまり、ローカル・クライアントは、チャネルを作成または削除したり、チャネルからイベントをパブリッシュまたはサブスクライブできます。
クラスタ環境では、あるサーバーのローカル・クライアントによりパブリッシュされたイベント・メッセージは、同じサーバーに接続されたサブスクライブ済クライアントによってのみ受信されます。これらのメッセージは、クラスタ内の別のサーバーに接続されたサブスクライブ済クライアントでは受信されません。
ローカル・クライアントにより任意のチャネルにパブリッシュされたイベント・メッセージには、そのチャネルに対して構成されたメッセージ・フィルタが適用されません。
この項では、次の問題および回避策について説明します。
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にアップグレードする場合、完了前にアップグレードを中断すると、通常、インストール環境は自動的に前のインストール環境にロールバックされます。この正常な操作は行われないことがあり、結果として使用できないインストール環境が生成されます。
ファイル・システムまたはディスク上に使用可能なディスク領域が大量にあっても、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)の再定義はサポートされません。そのため、エンティティ・クラスを更新すると、再定義エラーが発生します。
回避策
エンティティ・クラスの更新後に、アプリケーションを再デプロイします。
この項では、次の問題および回避策について説明します。
11.14.1項「MS SQLServerにJDBCドライバを使用している場合、setTransactionIsolation()へのコールが失敗することがある問題」
11.14.3項「複数のOracle RACノードを使用するよう構成されたSOAサーバーでORA-01591エラーが発生する問題」
MS SQLServerにJDBCドライバを使用している場合、getTransactionIsolation()が最初にコールされると、setTransactionIsolation()へのコールがトランザクション・コンテキストで失敗することがあります。
新規システム・プロパティの-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インスタンスに移動できない可能性があります。
複数の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が発生する可能性があります。詳細は、11.7.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では、サーバー・タイプの接続を作成してキャッシュします。その後、VMではクライアント・タイプの接続を作成する際に、キャッシュされた接続を検出してその使用を試みますが、クライアントではサーバー接続の使用が許可されないため、エラーが発生します。
この項では、次の問題および回避策について説明します。
@unharvestableタグは、インタフェース・レベルでは評価されません。明示的に@unharvestableとマークされていないMBean属性は、収集可能とみなされ、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レベルのイベントは低ボリューム設定で生成されていました)。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の今回のリリースでは、プロトコルに関する既知の問題は存在しません。
この項では、次の問題および回避策について説明します。
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}"
この項では、次の問題および回避策について説明します。
11.27.1項「適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能するStoreBootIdentity」
11.27.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のプロバイダの実装方法」の「プロバイダが自己整合性チェックを行う方法」を参照してください。
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ページに進むことができます。
この項では、次の問題および回避策について説明します。
異なるファイルシステム・ユーザーによって所有され、同時WLSTオフライン操作を実行するプロセスが複数ある場合、FileNotFoundException、Permission Deniedエラーが発生する可能性があります。
回避策
ログ・ファイル名の衝突を回避するには、wlst.sh script_nameを起動する前に次のプロパティを環境に設定します。
export WLST_PROPERTIES="-Dwlst.offline.log=./logs/filename.log"
filenameを一意の名前で置き換えます。各ログ・ファイルに一意の名前を使用して、ログ・ファイル名の衝突がないようにする必要があります。
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が発生します。
この項では、次の問題および回避策について説明します。
11.35.1項「weblogic.wsee.jaxws.mdb.DispatchPolicy WorkManagerが見つからない問題」
11.35.3項「WebLogic Advanced Web Services for JAX-WS Extensionテンプレートの適用時の問題のトラブルシューティング」
11.35.11項「JAX-RPCスタイルのJavaBeansに相当するJavaメソッド引数またはリターン・パラメータの処理」
11.35.12項「JWSコールバックで2次元のXMLオブジェクトを使用する場合に発生するIllegalArgumentException」
11.35.16項「xmlcatalog要素のエンティティにリモート・ファイルやアーカイブ内のファイルを指定できない問題」
11.35.19項「JAXRPCクライアントでマルチバイト・キャラクタを含むHTTP SOAPActionヘッダーがエンコードされない問題」
一部の状況下で、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
|
注意:
|
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クライアント・アプリケーションの記述方法の詳細は、http://jax-ws.java.net/2.2.6/docs/ch03.htmlにあるJAX-WS 2.1参照実装Webサイトの『JAX-WS Users Guide』を参照してください。
構成ウィザードを使用して、新規作成されたSOAドメインにWebLogic Server拡張Webサービス・コンポーネントを追加すると、構成が不完全になる可能性があります。デフォルトの即時利用可能なsoa_server1サーバー定義のみを含むクラスタを作成すると、生成されるクラスタには、そのクラスタでWebLogic Server Webサービスを実行するのに必要なリソースが含まれません。
回避策
この問題には次のいずれかの回避策を使用します。
構成ウィザードの実行時に、クラスタ内に第2のサーバーを作成します。
「オプションの構成を選択」画面で、「管理対象サーバー、クラスタ、およびマシン」を選択します。
「管理対象サーバーの構成」画面で、管理対象サーバーを追加します。
「サーバーのクラスタへの割当」画面で、デフォルトのsoa_server1サーバーが存在するクラスタにこのサーバーを追加します。
構成ウィザードの「サービスのクラスタまたはサーバーへのターゲット設定」画面で、Webサービス・リソース(WseeJmsServerやWseeJmsModuleなど)をクラスタにターゲット設定します。
これらの回避策のいずれかによって、構成ウィザードで、WebLogic Server拡張Webサービス・コンポーネントのリソースがクラスタに適用されます。
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を使用する場合にのみ動作します。
この項では、次の問題および回避策について説明します。
ビュー・クラスは、接続単位ベースでは設定できません。
2つのアプリケーションが異なる定義を持つ同じビュー名を参照していると、WebLogic Tuxedo Connectorの共有ハッシュ表により、サーバーで予期しない動作が発生する可能性があります。リソース・セクションと同様に、接続のビュー・クラスに対するハッシュ表が存在する必要があります。
回避策
すべてのWebLogic Workshopアプリケーション全体で定義されたすべてのビュー・クラスが一貫性を持つことを確認します。つまり、同じビュー名で同じビュー・クラスを表していることを確認します。
この項では、ドキュメントの訂正箇所を示します。
サンプル・ビューアの「検索」機能では、一部の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に含める必要があります。
「JAXWS Webサービス用のセキュアで信頼性のあるSOAPメッセージングの構成」の例に関する説明は、「JAX-WS Webサービスへの接続および信頼できるメッセージングの使用」の例に関する説明のコピーです。
「JAXWS Webサービス用のセキュアで信頼性のあるSOAPメッセージングの構成」の例に関する正しい説明は、次のとおりです。
この例は、JAX-WS Webサービス用にセキュアで信頼性のあるメッセージングを構成する方法を示しています。この例には、次のWebLogic Webサービスが含まれています。
信頼性のあるセキュアなSOAPメッセージングを使用して操作を呼び出せるWebサービス(宛先エンドポイント)。
信頼性のあるセキュアな方法で最初のWebサービスの操作を呼び出すクライアントWebサービス(送信元エンドポイント)。
セキュアで信頼性のあるSOAPメッセージングの概要
Webサービスの信頼性のあるメッセージングとは、あるアプリケーション・サーバーで実行中のアプリケーションが、別のアプリケーション・サーバーで実行中のWebサービスを確実に呼び出せるフレームワークです。ここでは、双方のサーバーでWS-RelicableMessaging仕様が実装されていることが前提となっています。信頼性のあるとは、ソフトウェア・コンポーネント、システムまたはネットワークで障害が発生した場合に、2つのエンドポイント(Webサービスとクライアント)間でのメッセージの配信を保証できるということです。
WebLogic Webサービスは、WS-ReliableMessaging 1.2仕様 (2009年2月)に準拠しており、バージョン1.1をサポートしています。この仕様では、異なるアプリケーション・サーバー上の2つのエンドポイント(Webサービスとクライアント)が確実に通信できる方法について記述されています。仕様では、特に、送信元エンドポイント(クライアントWebサービス)から宛先エンドポイント(操作を確実に呼び出せるWebサービス)に送信されるメッセージが、1つ以上の配信保証によって確実に配信されるか、そうでなければ必ずエラーが発生する、相互運用性プロトコルについて説明されています。
WebLogic Webサービスでは、宛先Webサービスが信頼性のあるSOAPメッセージング機能と要件を記述および公表できるように、WS-Policyファイルを使用します。WS-Policyファイルは、サポートされているWS-ReliableMessaging仕様のバージョン、送信元Webサービスの再送信間隔、宛先Webサービスの承認間隔などの特性を記述するXMLファイルです。
例の概要
この例では、JWSアノテーションを使用してWebサービスの形式と動作を指定しています。宛先Webサービスで信頼性のあるセキュアなSOAPメッセージングを有効にし、送信元Webサービスからセキュアな方法で操作を確実に呼び出すための追加JWSアノテーションを記述しています。
ReliableEchoService宛先Webサービスには、信頼性のあるセキュアな方法で呼び出せる2つの操作、echoとechoOnewayがあります。このWebサービスを実装するJWSファイルでは、@Policiesおよび@Policy JWSアノテーションを使用して、信頼性のあるセキュアなSOAPメッセージング・アサーションが含まれるWS-Policyファイルを指定します。
ClientService送信元Webサービスには、1つの会話内でReliableEchoService Web サービスのecho操作をセキュアな方法で確実に呼び出す1つの操作、runTestEchoWithResがあります。ClientService Webサービスを実装するJWSファイルでは、@WebServiceRef JWSアノテーションを使用して、呼び出される信頼性のあるWebサービスのサービス名を指定します。
Webサービスを生成するには、build.xmlファイルで示すように、jwsc WebLogic WebサービスAntタスクを使用します。jwscターゲットは信頼性のあるセキュアなWebサービスを生成し、jwsc-client-appターゲットは、ReliableEchoService Webサービスのecho操作を呼び出す送信元Webサービスを作成します。jwsc Antタスクは、JWSファイルをコンパイルして、Webサービスのデプロイメント・ディスクリプタ、WSDLファイル、データ・バインディング・コンポーネントなどの標準のJ2EE Enterprise Webサービスの実装に必要な追加ファイルを生成します。Antタスクは、WebLogic Serverにデプロイできるエンタープライズ・アプリケーション・ディレクトリ構造にすべてのコンポーネントを自動生成します。この例では、wldeploy WebLogic Antタスクを使用してWebサービスをデプロイしています。
また、jwsc-client-appターゲットは、最初にclientgen Antタスクを実行してReliableEchoService宛先Webサービス用のJAX-WSスタブを生成し、生成されたJavaソース・ファイルをコンパイルした後、jwscのclasspath属性を使用して、ClientServiceImpl.javaクラスが検出できるように、これらのクラスが格納されているディレクトリを指定する方法を示しています。
WsrmJaxwsExampleRequest.javaクラスは、送信元Webサービスのecho操作を呼び出すスタンドアロンJavaアプリケーションです。build.xmlファイルのクライアント・ターゲットは、clientgenを実行して生成された全JavaファイルおよびWsrmJaxwsExampleRequest.javaアプリケーションをコンパイルする方法を示しています。
ディレクトリの場所: MW_HOME/wlserver_10.3/samples/server/examples/src/examples/webservices/wsrm_jaxws/wsrm_jaxws_security
MW_HOMEは、Oracle Fusion Middlewareホーム・ディレクトリを表します。
| ファイル | 説明 |
|---|---|
|
ClientServiceImpl.java |
|
|
ReliableEchoServiceImpl.java |
信頼性のある宛先Webサービスを実装するJWSファイル。このJWSファイルでは、 |
|
client/WsrmJaxwsExampleRequest.java |
送信元WebLogic Webサービスを呼び出すスタンドアロンJavaクライアント・アプリケーション。呼び出されたWebサービスが |
|
ws_rm_configuration.py |
信頼性のあるSOAPメッセージングに必要なコンポーネントを構成するWLSTスクリプト。信頼性のある宛先WebサービスをホストするWebLogic Serverインスタンスに対してこのスクリプトを実行します。初期状態のExamplesサーバーは、確実に操作を呼び出す送信元Webサービスに必要なリソースを使用してすでに構成されています。 |
|
configWss.py |
セキュアなSOAPメッセージングに必要なコンポーネントを構成するWLSTスクリプト。送信元WebサービスをホストするWebLogic Serverインスタンスに対してこのスクリプトを実行します。このスクリプトの実行後に、送信元WebLogic Serverを再起動してください。 |
|
configWss_Service.py |
セキュアなSOAPメッセージングに必要なコンポーネントを構成するWLSTスクリプト。宛先WebサービスをホストするWebLogic Serverインスタンスに対してこのスクリプトを実行します。このスクリプトの実行後に、宛先WebLogic Serverを再起動してください。 |
|
certs/serverKeyStore.jks |
サーバー側 |
|
certs/clientKeyStore.jks |
クライアント側 |
|
jaxws-binding.xml |
生成されたコードのパッケージ名を記述するXMLファイルで、クライアント側コードに非同期呼出しインタフェースを含める必要があることを指定します。 |
|
build.xml |
この例のビルドおよび実行対象のターゲットが含まれるAntのビルド・ファイル。 |
この項では、例の準備方法について説明します。
前提条件
この例で作業する前に、次の手順を実行します。
Oracle WebLogic Serverのインストールを行います(例を含む)。
Examplesサーバーを起動します。
環境を設定します。
宛先WebLogic Serverインスタンスを構成します(省略可)
この例のデフォルト構成では、送信元と宛先の両方のWebサービスがExamplesサーバーにデプロイされます。このデフォルト構成を使用して、例がどのように動作するかを確認できますが、信頼性のあるセキュアなSOAPメッセージングの実際の使用例(宛先Webサービスをホストするものとは異なるWebLogic Serverに送信元Webサービスがデプロイされる)を示しているわけではありません。この項では、実際の例の設定方法について説明します。
例には、次の構成に使用されるWebLogic Server Scripting Language (WLST)スクリプトが含まれます。
Store-and-forward (SAF)サービス・エージェント
ファイル・ストア
JMSサーバー
JMSモジュール
JMSサブデプロイメント
JMSキュー
論理ストア
セキュリティ・コンテキスト・トークン用の資格証明プロバイダ
導出キー用の資格証明プロバイダ
x.509用の資格証明プロバイダ
機密保護および整合性のためのキーストア
PKI CreditMapper
セキュアで信頼性のある宛先Webサービスを異なるWebLogic Serverインスタンスにデプロイする場合は、次の手順を実行します。
信頼性のあるJAX-WS Webサービスをデプロイする管理対象WebLogic Serverが存在しない場合は、作成します。
SAMPLES_HOME\server\examples\src\examples\webservices\wsrm_jaxws\wsrm_jaxws_securityディレクトリに変更します。SAMPLES_HOMEは、WebLogic Server例のメイン・ディレクトリ(c:\Oracle\Middleware\wlserver_10.3\samplesなど)を指します。
build.xmlファイルを編集し、信頼性のあるJAX-WS Webサービスが宛先WebLogic Serverに必ずデプロイされるように、次のプロパティ定義を更新します。
<property name="wls.service.server" value="destinationServerName" /> <property name="wls.service.hostname" value="destinationHost" /> <property name="wls.service.port" value="destinationPort" /> <property name="wls.service.username" value="destinationUser" /> <property name="wls.service.password" value="destinationPassword" />
前述のプロパティのイタリック体の部分を、宛先WebLogic Serverの実際の値に置き換えます。デフォルトの初期状態のbuild.xmlでは、これらのプロパティがExamplesサーバーに設定されています。
例のビルドとデプロイ
例をビルドおよびデプロイするには:
SAMPLES_HOME\server\examples\src\examples\webservices\wsrm_jaxws\wsrm_jaxws_securityディレクトリに変更します。SAMPLES_HOMEは、WebLogic Server例のメイン・ディレクトリ(c:\Oracle\Middleware\wlserver_10.3\samplesなど)を指します。
環境を設定したシェルから、build.xmlファイルのconfig.ws.reliable.serviceターゲットを実行して宛先WebLogic Serverを構成するWLSTスクリプトを実行します。
prompt> ant config.ws.reliable.service
環境を設定したシェルから次のコマンドを実行して、JAX-WS Webサービス・セキュリティを構成します。
prompt> ant config.wss
異なる宛先WebLogic Serverを構成した(つまり、宛先サーバーがExamplesサーバーではない)場合は、certs\serverKeyStore.jksファイルを宛先サーバーのdomainディレクトリにコピーします。
クライアントと宛先の両方のWebLogic Serverを再起動してMBeanの変更をアクティブにします。
環境を設定したシェルから次のコマンドを実行します。
prompt> ant build
このコマンドは、例のコンパイルおよびステージングを行います。具体的には、送信元と宛先の両方のWebサービスがコンパイルされます。また、送信元Webサービスを呼び出すスタンドアロンのWsrmJaxwsExampleRequestアプリケーションもコンパイルします。呼び出されたWebサービスが信頼性のある宛先Webサービスを呼び出します。
環境を設定したシェルから次のコマンドを実行します。
prompt> ant deploy
このコマンドは、デフォルトで、送信元と宛先の両方のWebサービスを、WebLogic Serverのwl_serverドメインにデプロイします。異なる宛先WebLogic Serverを構成し、それに応じてbuild.xmlファイルを更新した場合は、信頼性のあるJAX-WS Webサービスは構成された宛先サーバーにデプロイされます。
この例を実行する手順は次のとおりです。
「例の準備」の手順を完了します。
デプロイメント・シェルで、例のメイン・ディレクトリ(SAMPLES_HOME\server\examples\src\examples\webservices\wsrm_jaxws\wsrm_jaxws_security)から次のコマンドを使用してWsrmJaxwsExampleRequest Javaアプリケーションを実行します。
prompt> ant run
このコマンドは、送信元Webサービスを呼び出すスタンドアロンのWsrmJaxwsExampleRequestアプリケーションを実行します。呼び出されたWebサービスが信頼性のある宛先JAX-WS Webサービスを呼び出します。
Webサービスの信頼性をテストするには、宛先WebLogic Serverを停止した後、WsrmJaxwsExampleRequestアプリケーションを再実行します。宛先WebLogic Serverを再起動して信頼性のあるWeb serviceがデプロイされると、操作も自動的に呼び出されることを確認してください。
出力の確認
例が正常に実行されると、次のメッセージが、WsrmJaxwsExampleRequestアプリケーションを実行したコマンド・シェルに表示されます。
Trying to override old definition of task clientgen
run:
[java]
[java]
[java] ###########################################
[java] In testEcho_AsyncOnServerClient_ServiceBuffered...
[java] On-Server / Async / Buffered case
[java] 2011/06/160 03:30:29.938
[java] ###########################################
[java]
[java]
[java] Client addr:http://localhost:9001/wsrm_jaxws_sc_example_client/Clien
tService
[java] ---[HTTP request - http://localhost:9001/wsrm_jaxws_sc_example_clien
t/ClientService]---
[java] Content-type: text/xml;charset=utf-8
[java] Soapaction: ""
[java] Accept: text/xml, multipart/related, text/html, image/gif, image/jpe
g, *; q=.2, */*; q=.2
[java] <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://sc
hemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:runTestEchoWithRes xmlns:ns2="htt
p://example.wsrm_jaxws/"><arg0>Foo bar</arg0><arg1>localhost</arg1>
<arg2>8001</arg2><arg3>C:\Oracle\Middleware\wlserver_10.3\samples\server\
examples\src\examples\webservices\wsrm_jaxws_security/certs</arg3>
</ns2:runTestEchoWithRes></S:Body></S:Envelope>--------------------
[java]
[java] ---[HTTP response - http://localhost:9001/wsrm_jaxws_sc_example_clie
nt/ClientService - 200]---
[java] Transfer-encoding: chunked
[java] null: HTTP/1.1 200 OK
[java] Content-type: text/xml;charset=utf-8
[java] X-powered-by: Servlet/2.5 JSP/2.1
[java] Date: Thu, 09 Jun 2011 07:30:33 GMT
[java] <?xml version='1.0' encoding='UTF-8'?><S:Envelope xmlns:S="http://sc
hemas.xmlsoap.org/soap/envelope/"><S:Body><ns2:runTestEchoWithResResponse xmlns:
ns2="http://example.wsrm_jaxws/"><return>[2011/06/160 03:30:33.953] ## Making Ec
ho Requests (ASYNC/BUFFERED) ##
[java] [2011/06/160 03:30:42.703] *** On first good invoke ***
[java] [2011/06/160 03:30:42.703] echo returned: Foo bar expected: Foo bar
[java] [2011/06/160 03:30:42.922] echo returned: foo bar 2 expected: foo ba
r 2
[java] [2011/06/160 03:30:43.031] echo returned: foo bar 3 expected: foo ba
r 3
[java] [2011/06/160 03:30:43.031] ## Done Making Echo Requests (ASYNC/BUFFE
RED) ##
[java] </return></ns2:runTestEchoWithResResponse></S:Body>
</S:Envelope>--------------------
[java]
[java] [2011/06/160 03:30:33.953] ## Making Echo Requests (ASYNC/BUFFERED)
##
[java] [2011/06/160 03:30:42.703] *** On first good invoke ***
[java] [2011/06/160 03:30:42.703] echo returned: Foo bar expected: Foo bar
[java] [2011/06/160 03:30:42.922] echo returned: foo bar 2 expected: foo ba
r 2
[java] [2011/06/160 03:30:43.031] echo returned: foo bar 3 expected: foo ba
r 3
[java] [2011/06/160 03:30:43.031] ## Done Making Echo Requests (ASYNC/BUFFE
RED) ##
[java]
BUILD SUCCESSFUL
Total time: 2 minutes 33 seconds
次のメッセージが、(信頼性のある送信元Webサービスをホストする)クライアントWebLogic Serverとして起動したコマンド・ウィンドウに表示されます。
Service addr:http://localhost:7001/wsrm_jaxws_sc_example/ReliableEchoService
[2011/06/180 01:33:40.906] ## Making Echo Requests (ASYNC/BUFFERED) ##
[2011/06/180 01:33:40.906] In invokeEchoAsync, invoking echo with request: Foo bar
[2011/06/180 01:33:40.906] In invokeEchoAsync, waiting for response to request: Foo bar ...
SignInfo mismatch Algo mismatch http://www.w3.org/2000/09/xmldsig#rsa-sha1 VS.
http://www.w3.org/2000/09/xmldsig#hmac-sha1 Refs: Msg size =1#Signature_prfr5thF
y2vRPbpC, Policy size =3 #unt_w7HSTtcGcebXFWEr, #Timestamp_XIXttwj9Yq2XO7Tj, #Bo
dy_81D2x3V7iTNyy1I5,
STR type mismatch Actual KeyInfo:{http://docs.oasis-open.org/wss/2004/01/oasis-2
00401-wss-wssecurity-secext-1.0.xsd}KeyIdentifier|http://docs.oasis-open.org/wss
/oasis-wss-soap-message-security-1.1#ThumbprintSHA1, StrTypes size=1 :{http://d
ocs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Refere
nce||http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk,
Security Token mismatch, token type =http://docs.oasis-open.org/ws-sx/ws-securec
onversation/200512/dk and actual ishttp://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-x509-token-profile-1.0#X509v3
<WSEE:15>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
testing...................
[2011/06/180 01:33:41.718] In ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fb8)
[2011/06/180 01:33:41.718] Done with ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fb8): Foo bar
[2011/06/180 01:33:41.718] *** On first good invoke ***
[2011/06/180 01:33:41.734] echo returned: Foo bar expected: Foo bar
[2011/06/180 01:33:41.734] In invokeEchoAsync, invoking echo with request: foo bar 2
[2011/06/180 01:33:41.750] In invokeEchoAsync, waiting for response to request: foo bar 2 ...
<WSEE:15>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
testing...................
[2011/06/180 01:33:41.984] In ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fae)
[2011/06/180 01:33:41.984] Done with ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fae): foo bar 2
[2011/06/180 01:33:41.984] echo returned: foo bar 2 expected: foo bar 2
[2011/06/180 01:33:42.000] In invokeEchoAsync, invoking echo with request: foo bar 3
[2011/06/180 01:33:42.015] In invokeEchoAsync, waiting for response to request: foo bar 3 ...
<WSEE:31>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
testing...................
[2011/06/180 01:33:42.187] In ClientServiceImpl.onEchoResponse(request:
examplesServer:4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fab)
[2011/06/180 01:33:42.328] Done with ClientServiceImpl.onEchoResponse(request:
examplesServer:4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fab): foo bar 3
[2011/06/180 01:33:42.328] echo returned: foo bar 3 expected: foo bar 3
[2011/06/180 01:33:42.328] ## Done Making Echo Requests (ASYNC/BUFFERED) ##
<WSEE:46>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
次のメッセージが、(信頼性のある宛先Webサービスをホストする)宛先WebLogic Serverを起動したコマンド・ウィンドウに表示されます。
%% Echoing: Foo bar %%
%% Echoing: foo bar 2 %%
%% Echoing: foo bar 3 %%
送信元と宛先の両方のWebサービスを同じサーバーにデプロイした場合は、次のメッセージが、クライアントと宛先のWebLogic Serverを起動したコマンド・ウィンドウに表示されます。
Service addr:http://localhost:7001/wsrm_jaxws_sc_example/ReliableEchoService
[2011/06/180 01:33:40.906] ## Making Echo Requests (ASYNC/BUFFERED) ##
[2011/06/180 01:33:40.906] In invokeEchoAsync, invoking echo with request: Foo bar
[2011/06/180 01:33:40.906] In invokeEchoAsync, waiting for response to request: Foo bar ...
SignInfo mismatch Algo mismatch http://www.w3.org/2000/09/xmldsig#rsa-sha1 VS.
http://www.w3.org/2000/09/xmldsig#hmac-sha1 Refs: Msg size =1#Signature_prfr5thF
y2vRPbpC, Policy size =3 #unt_w7HSTtcGcebXFWEr, #Timestamp_XIXttwj9Yq2XO7Tj, #Bo
dy_81D2x3V7iTNyy1I5,
STR type mismatch Actual KeyInfo:{http://docs.oasis-open.org/wss/2004/01/oasis-2
00401-wss-wssecurity-secext-1.0.xsd}KeyIdentifier|http://docs.oasis-open.org/wss
/oasis-wss-soap-message-security-1.1#ThumbprintSHA1, StrTypes size=1 :{http://d
ocs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd}Refere
nce||http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/dk,
Security Token mismatch, token type =http://docs.oasis-open.org/ws-sx/ws-securec
onversation/200512/dk and actual ishttp://docs.oasis-open.org/wss/2004/01/oasis-
200401-wss-x509-token-profile-1.0#X509v3
%% Echoing: Foo bar %%
<WSEE:15>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
testing...................
[2011/06/180 01:33:41.718] In ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fb8)
[2011/06/180 01:33:41.718] Done with ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fb8): Foo bar
[2011/06/180 01:33:41.718] *** On first good invoke ***
[2011/06/180 01:33:41.734] echo returned: Foo bar expected: Foo bar
[2011/06/180 01:33:41.734] In invokeEchoAsync, invoking echo with request: foo bar 2
[2011/06/180 01:33:41.750] In invokeEchoAsync, waiting for response to request: foo bar 2 ...
%% Echoing: foo bar 2 %%
<WSEE:15>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
testing...................
[2011/06/180 01:33:41.984] In ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fae)
[2011/06/180 01:33:41.984] Done with ClientServiceImpl.onEchoResponse(request:
examplesServer: 4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fae): foo bar 2
[2011/06/180 01:33:41.984] echo returned: foo bar 2 expected: foo bar 2
[2011/06/180 01:33:42.000] In invokeEchoAsync, invoking echo with request: foo bar 3
[2011/06/180 01:33:42.015] In invokeEchoAsync, waiting for response to request: foo bar 3 ...
%% Echoing: foo bar 3 %%
<WSEE:31>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
testing...................
[2011/06/180 01:33:42.187] In ClientServiceImpl.onEchoResponse(request:
examplesServer:4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fab)
[2011/06/180 01:33:42.328] Done with ClientServiceImpl.onEchoResponse(request:
examplesServer:4b1c0f3e575dfa8c:7291c50f:130d9cbaace:-7fab): foo bar 3
[2011/06/180 01:33:42.328] echo returned: foo bar 3 expected: foo bar 3
[2011/06/180 01:33:42.328] ## Done Making Echo Requests (ASYNC/BUFFERED) ##
<WSEE:46>There is no information on the incoming SOAP message.
<SmartPolicySelect or.getSmartPolicyBlueprint:501>
