| Oracle® Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Linux x86 B55924-02 |
|
 戻る |
 次へ |
| Oracle® Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for Linux x86 B55924-02 |
|
戻る |
次へ |
この章では、Oracle WebLogic Serverに関連する問題について説明します。内容は次のとおりです。
|
注意: WebLogic Server 11gリリース1（10.3.3）で修正された不具合のリストを参照するには、「ナレッジ・ベースの検索」フィールドに次のドキュメントIDを入力してください。このドキュメントIDをそのまま入力する必要があります。1080299.1 10.3.3のリストには、WebLogic Server 10.3.1、10.3.2および10.3.3リリースで修正された不具合が含まれます。 同じリストは、WebLogic Serverインストール環境の次の場所にも保存されています。
|
この項では、次の問題および回避方法について説明します。
Oracle Fusion Middleware 11gには、Oracle WebLogic Server 11gが含まれます。Oracle WebLogic Serverのリリース番号は、10.3.3です。
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
この項では、次の問題および回避方法について説明します。
キャッシュされたJDBCの文に関する情報は、JDBCの監視ページには表示されません。
管理コンソールでページ・フローが完了すると、異なるページ（通常は表）に転送されます。
この時点でブラウザの「戻る」ボタンを押すと、完了したアシスタントで最後のJSPファイルのロード操作が試行されます。これにより、このアシスタントのすべてのコンテキストは破棄されます。
回避方法
変更が取り消されるか完了した後に、ブラウザの「戻る」ボタンを使用してアシスタントに戻ることや、アシスタントの前の手順に戻ることはお薦めしません。かわりに、管理コンソールのナビゲーション・リンクおよびボタンを使用してください。
管理コンソールでは、サポート対象外で正常に動作しないワーク・マネージャ構成を作成できます。不適切なワーク・マネージャ構成により、サーバー・ログに多くの例外が記録される可能性があります（通常は、デプロイメント・ディスクリプタの解析中に「検証の問題が見つかりました」という例外が発生します）。
回避方法
ワーク・マネージャ構成のオンライン・ヘルプに記載されているガイドラインに従ってください。具体的には、任意のワーク・マネージャにはただ1つのリクエスト・クラスを割り当てます。また、そのリクエスト・クラスのスコープは、ワーク・マネージャと同等かそれより広範囲である必要があります。グローバル・ワーク・マネージャにアプリケーション・スコープのリクエスト・クラスを割り当てることはできません。また、アプリケーション・スコープのワーク・マネージャに複数のアプリケーション・スコープのリクエスト・クラスを作成することもできません。
ドキュメントに記載された制約に準拠するようにワーク・マネージャ構成を修正することで、これらの問題を解決できます。
「クラスタ: 監視: 概要」ページの「サーバー状態」表には、「プライマリ」および「セカンダリ分散名」という2つのデフォルト列が含まれます。レプリケーション環境によっては、これらのフィールドに、「クラスタ: 監視: フェイルオーバー」ページで収集および表示されるレプリケーション統計の一部が反映されないことがあります。
正確な情報は、「クラスタ: 監視: フェイルオーバー」ページを参照してください。
管理コンソールで、個別のライブラリ・デプロイメントで定義されたタイプを参照するEJBデプロイメントに対してセキュリティ・ポリシーを定義する場合、そのライブラリ・デプロイメントがコンソールで使用できないと、例外が発生する可能性があります。
回避方法
すべてのライブラリ・デプロイメントは、WebLogic Server管理サーバーに加え、参照するアプリケーションをサポートするために必要な任意の管理対象サーバーをターゲットとする必要があります。これにより、ポリシーの定義時に、コンソールでそれらのライブラリ・デプロイメントにアクセスできるため、参照されるタイプが必要に応じて確実にクラス・ロードされます。
管理コンソールには、デプロイメント・プランで行われた外部変更が反映されないことがあります。コンソール・ユーザーがデプロイメント・プランを表示しているときに、コンソール外部のデプロイメント・プランで変更が行われると（Workshopの使用、プラン・テキスト・ファイルの直接編集、WLSTまたはwebLogic.Deployerを使用した新規プランによるデプロイメントの更新など）、それらの変更はコンソール・ユーザーに表示されません。
回避方法
別のデプロイメントの構成ページに移動してから、元のデプロイメントに戻ります。
Oracle OCIドライバは、管理コンソールに事前構成済ドライバ・タイプとして明示的にリストされなくなりました。
回避方法
Oracle OCIドライバは、現在もアプリケーション・データ接続用としてサポートされるドライバであり、Oracle WebLogic Serverの以前のリリースと互換性があります。ただし、現在は、データベース・ユーザー名を含むすべての必須構成プロパティを手動で指定する必要があります。
WebLogic Server 10.3.3より前のリリースでは、「構成」→「WSDL」タブを選択して、現在のWebサービスのWSDLを表示できました。「WSDL」タブは、WebLogic Server 10.3.3で削除されました。現在のWebサービスのWSDLを表示するには、「テスト」タブを選択し、テスト・ポイントを表示するWebサービスの名前を展開して、「WSDL」をクリックします。
Internet Explorer 7（IE 7）を使用して監視ダッシュボードの「メトリック・ブラウザ」タブにデータを表示する場合、データを表示するのに非常に時間がかかり、その間ページが反応しなくなります。このタブにデータを表示するのに要する時間は、ドメインのサイズに応じて変化します。
回避方法
監視ダッシュボードの「メトリック・ブラウザ」タブにデータを表示する必要がある場合、IE 7以外のサポートされるWebブラウザ（たとえば、Internet Explorer 8以上、Firefox 3以上またはSafari 4以上）で管理コンソールを開きます。
WebLogic Serverの今回のリリースでは、Apache Beehiveサポートに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
存在しないサーバー名を使用してWebLogic Server管理サーバーに接続しようとすると、その存在しないサーバー名に対応するディレクトリがdomain_name/serversディレクトリ内に作成されます。
回避方法
管理サーバーに接続する際は、有効なサーバー名を指定します。
この項では、次の問題および回避方法について説明します。
ホスト名にlocalhostを使用してWLSTからWebLogic Server管理サーバーに接続しようとすると、管理サーバーのlisten-address属性が特定のIPアドレスに制限されている場合に、次のメッセージが表示されることがあります。
javax.naming.CommunicationException [Root exception is java.net.ConnectException : <t3://HOST:PORT> : Destination unreachable; nested exception is: java.net.ConnectException: Connection refused; No available router to destination
回避方法
次のいずれかの回避方法を使用します。
ドメイン構成ファイルで、管理サーバーのlisten-address属性が正しく設定されていることを確認します。listen-address行を削除するか、単にコメントアウトします。後で値を把握する必要がある場合は、コメントアウトしておくことをお薦めします。たとえば、ドメイン構成ファイルは次のようになります。
<server> <name>AdminServer</name> <ssl> . . . </ssl> <machine>machine_name</machine> <!-- listen-address>machine_ip_address</listen-address --> </server>
WLSTのconnectコマンドでは、localhostのかわりに管理サーバーのホスト名を使用します。
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.9.1項「weblogic-application.xmlでsecurity-permission要素が使用できない問題」
11.9.5項「プランの適用時に「"config-root" <directory>が見つかりませんでした」という警告が表示される問題」
11.9.7項「別のソース・ファイルの場所を使用してアプリケーションがすでにデプロイされている場合、アプリケーションの再デプロイに失敗する問題」
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ディレクトリを手動で作成します。
管理対象サーバーの起動時に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度デプロイメントのソース・ファイルを指定すると、再デプロイメントに際してこれを変更することはできません。
回避方法
新しいソース・ファイルの場所を使用して再デプロイを試みる前に、アプリケーションをアンデプロイします。
この項では、次の問題および回避方法について説明します。
11.10.8項「@Idフィールドに@Uniqueのアノテーションも付けるとOpenJPAにより例外がスローされる問題」
11.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パブリッシュ/サブスクライブ・サーバーのチャネルを操作する完全な権限を持ちます。つまり、ローカル・クライアントは、チャネルを作成または削除することや、チャネルからイベントをパブリッシュまたはサブスクライブすることが可能です。
クラスタ環境では、あるサーバーのローカル・クライアントによりパブリッシュされたイベント・メッセージは、同じサーバーに接続されたサブスクライブ済クライアントによってのみ受信されます。これらのメッセージは、クラスタ内の別のサーバーに接続されたサブスクライブ済クライアントでは受信されません。
ローカル・クライアントにより任意のチャネルにパブリッシュされたイベント・メッセージには、そのチャネルに対して構成されたメッセージ・フィルタが適用されません。
この項では、次の問題および回避方法について説明します。
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.3にアップグレードする場合、完了前にアップグレードを中断すると、通常、インストール環境は自動的に前のインストール環境にロールバックされます。この正常な操作は行われないことがあり、結果として使用できないインストール環境が生成されます。
インストーラでは、インストールの完了前にマシン上に十分なディスク領域が存在するかどうかが検証されません。結果として、領域不足が原因でインストールを完了できないと、次のエラー・メッセージが表示され、インストールは終了します。
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.15.2項「WLSデータソースが1PC、エミュレートXAまたはLLRのグローバル・トランザクション・オプションで構成されている場合に10.3.2以上のリモートWLSにアクセスすると失敗する問題」
11.15.3項「Oracle DatabaseからのNClobオブジェクトの取得時に発生するSQLException」
11.15.4項「WLCachedRowSetを使用したNClobデータの更新時またはNClobオブジェクトの取得時に発生する問題」
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アクセスは無効になり、リモート・クライアントを介したそのようなアクセスがあると、例外が発生します。
システムの制限
WebLogic Server 10.3.2以上で使用可能な-Dweblogic.jdbc.remoteEnabledオプションをfalseに設定した状態で、グローバル・トランザクションの複数のWebLogic Serverインスタンスに対するLLR、1PCまたはエミュレートXAのトランザクション・オプション付きでXA以外のデータソースにアクセスしようとすると、そのアクセスは失敗します。
|
注意: トランザクション調整サーバーでローカルにホストされるグローバル・トランザクションの1PC、エミュレートXAまたはLLRの参加者は、引き続き動作します。この動作は、Oracle Fusion Middleware Oracle WebLogic Server JTAのプログラミングのLLRによるパフォーマンスの最適化に関する項に記載されているとおり、コーディネータで直接ホストされている接続インスタンスを使用するようにアプリケーションを最適化することで可能になる場合があります。コーディネータで直接ホストされている接続インスタンスを使用するようにアプリケーションを最適化することが不可能な場合もあります。たとえば、リモートのWebLogic JMSサーバーからメッセージを受信するMDBは、常にリモート・コーディネータを使用します。 |
回避方法
XAを使用するようにデータソースを変更します。この操作により、パフォーマンスが低下する可能性があります。
JdbcRowSetオブジェクトを使用してOracle Thinドライバを通じてOracle DatabaseからNClobオブジェクトを取得する場合、次のSQLExceptionが発生します。
NCLOBを作成するために使用するフォームが正しくありません
この結果、NClobオブジェクトは取得できません。
WLCachedRowSetを使用する場合、次の2つの問題が発生します。
RowsetオブジェクトのNClobデータの更新時に「オブジェクトはクローズされました。」というSQL例外が発生します。
WLCachedRowSetオブジェクトからのNClobオブジェクトの取得時に「この列をNClobに変換できません。」というSQL例外が発生します。
MSSQLを使用し、updateBlob()メソッドとupdateBinaryStream()メソッドを使用してRowSetオブジェクトのBLOBデータを更新しても、データはデータベースで更新されません。
複数のRACデータベース・ノードを使用しているSOAサーバーで、XAおよびロード・バランシングに対してWebLogic Serverのマルチ・データ・ソースが構成されている場合、ORA-10591エラーが発生します。
回避方法
RACデータベース・パッチp7675269_111070_Linux-x86.zipを適用します。このパッチは、http://aru.us.oracle.com:8080/ARU/ViewPatchRequest/process_form?aru=11860090からダウンロードできます。ps9007079_111070_Linux-x86.zipパッチは、p7675269パッチを含むスーパーセット・パッチです。
この項では、次の問題および回避方法について説明します。
デプロイメント・ディスクリプタの検証が有効化されており、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.3には、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.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では、サーバー・タイプの接続を作成してキャッシュします。その後、VMではクライアント・タイプの接続を作成する際に、キャッシュされた接続を検出してその使用を試みますが、クライアントではサーバー接続の使用が許可されないため、エラーが発生します。
回避方法
なし。この問題は、Sun社が解決する必要があります。
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の今回のリリースでは、ノード・マネージャに関する既知の問題は存在しません。
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}"
この項では、次の問題および回避方法について説明します。
11.28.1項「適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能するStoreBootIdentity」
11.28.2項「AllowUnencryptedNullCipherをTrueに設定しないとNULL暗号を必要とする接続が失敗する問題」
11.28.6項「SAML 2.0サービス・プロバイダ・サービスで「認証」属性と「パッシブ」属性の両方を有効化すると無効な構成になる問題」
-Dweblogic.system.StoreBootIdentityオプションは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能します。このディレクトリは、通常、構成ウィザードまたはアップグレード・ツールにより作成されます。
ただし、適切なサーバー・セキュリティ・ディレクトリが、ソース・コントロール・システムにチェックインされるドメインに存在しないこともあります。
WebLogic Serverでは、SSL接続でのNULL暗号の使用が可能ですが、結果としてデータが暗号化されません。
WebLogic Server 10.3以上では、NULL暗号の使用はデフォルトで無効化されています。クライアントでNULL暗号を有効化するには、weblogic.ssl.AllowUnencryptedNullCipherシステム・プロパティをtrueに設定します。次に例を示します。
-Dweblogic.ssl.AllowUnencryptedNullCipher=true
WebLogic Server 10.3以上では、このシステム・プロパティでNULL暗号の使用を明示的に有効化しなければ、NULL暗号を必要とするクライアントSSL接続は失敗します。NULL暗号を使用するには、サーバー側とクライアント側の両方でNULL暗号を有効化する必要があります。両方で有効化しない場合、SSLハンドシェイクに失敗します。
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でサポートされないため、「強制認証」属性は無効であることに注意してください。そのため、ユーザーがすでにアイデンティティ・プロバイダ・サイトで認証されている状態で「強制認証」を有効化しても、ユーザーはアイデンティティ・プロバイダ・サイトで再度認証を強制されることはありません。
これら両方の属性を有効化することは避けてください。
WebLogic Serverに付属するいずれかの認証プロバイダを構成する場合、「グループ・メンバーシップ・ルックアップの階層キャッシングを有効化」が有効になった状態で「グループ・メンバーシップ検索」を制限付きに設定すると、認証障害が発生する可能性があります。認証は、グループ・メンバーシップ・キャッシュの現在の内容に応じて成功または失敗します。
WebLogic Server管理コンソールの認証プロバイダの構成ページで、「グループ・メンバーシップ検索」属性は「プロバイダ固有」タブで、「グループ・メンバーシップ・ルックアップの階層キャッシングを有効化」属性は「パフォーマンス」タブで使用できます。
これらの属性のデフォルト設定は、次のとおりです。
「グループ・メンバーシップ検索」の設定は無制限。
「グループ・メンバーシップ・ルックアップの階層キャッシングを有効化」は有効。
回避方法
これら2つの構成設定は、同時に使用しないでください。認証プロバイダを構成する場合、次のいずれかの方法を使用してこの問題を回避します。
「グループ・メンバーシップ検索」を制限付きに設定しないようにします。
制限付き設定を使用する必要がある場合は、「グループ・メンバーシップ・ルックアップの階層キャッシングを有効化」の設定を無効化します。ただし、グループ・メンバーシップ・キャッシュを無効化すると、通常はシステム・パフォーマンスが低下します。
予測不可能な乱数を生成するために、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 10.3.3には、ユーザーがgetやgetnextなどのSNMPリクエストでMIBのノードにアクセスする場合、それらのノードを遅延ロードすることでSNMPエージェントによる初期メモリー使用量を節約するという最適化機能があります。WebLogic Serverのランタイムおよび構成MBeanに対応するノードは遅延ロードされますが、カスタムMBeanのノードは起動時に初期ロードされます。カスタムMBeanは、デフォルトでMIBに登録されません。カスタムMBeanをMIBに登録するには、SNMPAgentMBeanのSNMPAccessForUserMBeansEnabled属性をtrueに設定する必要があります。
回避方法
この問題の回避方法はありません。この問題は、SNMPAccessForUserMBeansEnabled属性が有効化されており、SNMPエージェントが実行中である場合にのみ発生します。
この項では、次の問題および回避方法について説明します。
JRockit上でWebLogic Serverを実行すると、OpenJPAのClassFileTranformerが機能しません。
回避方法
OpenJPAのエンハンサ・コンパイラを通じてビルド時に拡張を適用する代替方法を使用します。LoadTimeWeaverは使用しないでください。
SpringSourceのpetclinicサンプルでは、petclinic.warは問題なくデプロイされます。petclinic.earは、正しくパッケージされていないため、WebLogic Serverにデプロイされません。petclinic.earのパッケージの修正を依頼するリクエストがSpringSource社に提出されています。
この項では、次のSCAの問題について説明します。
System Component Architecture（SCA）Spring Bean Webサービスでは、サービスBeanがSOAP 1.2およびresponse(return value)のswaRef(@XmlAttachmentRef)を使用している場合、レスポンスSOAPメッセージの生成時にContent-Typeが間違ってtext/xmlに設定されます。間違ったContent-Typeが原因となり、SAAJ MessageFactoryではUnable to internalize messageエラーがスローされ、サービスでは障害が報告されます。
回避方法
添付ファイルには、SOAP 1.1またはメッセージ転送最適化メカニズム（MTOM）を使用します。
この項では、次の問題について説明します。
WebLogic Server 10.3.1を使用してドメインを作成し、WebLogic Server 10.3にロールバックすると、そのドメインで作成したサーバーを起動できません。これは、既知の制限であり、WebLogic Server 10.3に存在しない新しいスキーマ定義（xmlns.oracle.com）に対する参照がconfig.xmlファイルに含まれることが原因です。
WebLogicコンポーネントのWorkShopとともにWebLogic Server 10.3.0または10.3.1をインストールしており、Smart Updateを使用してWebLogic Server 10.3.2にアップグレードした場合、10.3.2から以前のリリースにロールバックするためのSmart Updateの「ダウングレードのオプション」が使用できません。
|
注意: この問題は、WebLogic Serverインストール環境にWebLogicコンポーネントのWorkshopが含まれない場合は発生しません。 |
回避方法
WebLogic Serverのアンインストーラを実行し、ロールバック・オプションを選択して元のWebLogic Server 10.3.0または10.3.1インストール環境にロールバックします。WebLogic Serverのアンインストーラを実行する方法の詳細は、Oracle WebLogic Serverのインストレーション・ガイドを参照してください。
この項では、次の問題および回避方法について説明します。
session-timeoutがweb.xmlファイルに構成されている場合、管理コンソールを使用してsession-timeoutを変更する操作は機能しません。
回避方法
デプロイメント・プランを使用してsession-timeout設定を上書きします。
JDBCセッションの使用時に、接続プールの接続予約タイムアウトの値が次のいずれかに変更されます。
セッション・ディスクリプタ（weblogic.xmlまたはweblogic-application.xml）で定義されたJDBC接続タイムアウト秒
デフォルト値の120秒
回避方法
セッション・ディスクリプタのjdbc-connection-timeout-secsを構成します。
JDBC永続性セッションでPoolLimitSQLExceptionが発生すると、データベースへの接続が不安定になり、リカバリ可能または不可能な障害が発生する可能性があります。これにより、セッション・データが失われます。古いセッションまたはnullが返されます。
この項では、次の問題および回避方法について説明します。
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.36.8項「JAX-RPCスタイルのJavaBeansに相当するJavaメソッド引数またはリターン・パラメータの処理」
11.36.9項「JWSコールバックで2次元のXMLオブジェクトを使用する場合に発生するIllegalArgumentException」
11.36.14項「xmlcatalog要素のエンティティにリモート・ファイルやアーカイブ内のファイルを指定できない問題」
11.36.17項「JAXRPCクライアントでマルチバイト・キャラクタを含むHTTP SOAPActionヘッダーがエンコードされない問題」
11.36.20項「jwscが変更されたため、サービス・エンドポイント・インタフェースに含まれるようになった@WebMethodアノテーションのないメソッド」
11.36.25項「WebLogic ServerでJRockit JDKを実行している場合にDBWSの起動に失敗する問題」
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/>を使用する必要があります。
WebLogic Webサービスでは、Webサービスをサポートするために必要な特定のリソースが各WebLogic Serverドメインに含まれているとみなされます。ただし、一部のドメインは、これらのリソースで作成されていません。
たとえば、構成ウィザードで（他のテンプレートを適用せずに）デフォルトのWebLogic Serverドメインを作成しても、必要なWebサービス・リソースは作成されません。
Webサービス・リソースを含まないドメインでも、Webサービス以外の使用例や、非同期リクエストまたはレスポンスに関連しないWebサービスの使用例では、正常に起動および動作します。ただし、非同期リソースが構成されていないことと、Webサービス用の非同期レスポンス・サービスが完全にデプロイされていないことを示すINFOメッセージがサーバー・ログに記録されます。
回避方法
非同期リクエストまたはレスポンスを使用するWebサービスは、Webサービス・リソースが構成されていないドメインでは正しく機能しません。これらのリソースを構成するには、次の2つの方法を使用します。
構成ウィザードを使用して、ドメインにwls_webservice.jarテンプレートを適用します。
Webサービスのドメイン構成に関するオンライン・ドキュメントに記載されているルールに従って、これらのリソースを手動で構成します。
|
注意: 前述の構成ウィザードによる方法は、すでにJMSサーバーが構成されており、宛先などのJMSリソースに対してJMSリソースのデフォルト・ターゲット指定が有効化されているドメインには推奨されません。ウィザードでは、自動的に追加のJMSサーバーが作成され、新規作成されたJMSサーバーにデフォルトのターゲット・リソースが自動的に出現する可能性があります。たとえば、分散宛先が生成されて、意図したよりも多くのJMSサーバーに突然広がることがあります。 |
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.3では非推奨になりました。かわりに、ストアの同期書込みポリシーをDirect-Write-With-Cacheに構成することをお薦めします。 |
Direct-Write-With-Cacheオプションでは、パフォーマンスが向上する可能性があります。このオプションでは、デフォルトでオペレーティング・システムの一時ディレクトリに追加ファイルが作成されます。
Cache-FlushおよびAvoidDirectIOによる回避方法では、パフォーマンスが低下する可能性があります。状況によっては、ファイル・ストアの異なるブロック・サイズを構成することで、このパフォーマンス低下を緩和するか、排除することが可能です。
これらの設定と追加オプションの重要な情報は、『Oracle Fusion Middleware Performance and Tuning for Oracle WebLogic Server』のファイル・ストアのチューニングに関する項を参照してください。
11gリリース1（WebLogic Serverリリース10.3.1）より前には、そのサービス・エンドポイント・インタフェースが実装から推測できる（つまり、明示的なサービス・エンドポイント・インタフェース・クラスが宣言されていない）JAX-WS JWSは、暗黙的なサービス・エンドポイント・インタフェースに、（exclude=trueを指定していない）@WebMethodアノテーションが記載されたメソッドのみを含んでいました。この動作は、JAX-WS 2.1仕様に正しく準拠していません。JAX-WS 2.1では、JWSから推測できるサービス・エンドポイント・インタフェースは、メソッドに@WebMethod(exclude=true)がアタッチされていないかぎり、パブリックで非静的なJWSのすべてのメソッドを含む必要があると規定しています。
WebLogic Server 10.3.1では、jwsc（およびWebサービス・ランタイム）が、JAX-WS 2.1仕様に準拠して暗黙的なサービス・エンドポイント・インタフェース（および対応するサービス用のWSDL）を適切に生成するように変更されています。その結果、暗黙的に導出されるサービス・エンドポイント・インタフェースには、公開されるパブリックで非静的なJWSのすべてのメソッドが含まれます。一部の環境では、@WebMethodアノテーションのないメソッドは、サービス・エンドポイント・インタフェースおよび対応するサービスのWSDLに含めないという前提で、以前のjwscに依存するJWS実装を記述していることがあります。新しいjwscの動作では、そのようなメソッドでも、サービス・エンドポイント・インタフェースおよび対応するサービスのWSDLに含まれます。
回避方法
WebLogic Server 10.3.1以上をインストールしたら、発生する可能性のある次のエラーに関して既存のサービスを評価することをお薦めします。
仕様に準拠していないWebメソッド宣言に相当するパブリックで非静的なメソッド（これらのメソッドはサービスのビルド時にjwsc失敗の原因となる可能性があります）。
仕様に準拠したWebメソッドに相当するが、サービスで公開することを意図しないパブリックで非静的なメソッド。
次に、2つの例について詳細に説明します。
例1: 以前の非公開メソッドが無効なWebメソッドである場合、一部のJWSクラスがjwscでのコンパイルに失敗する可能性があります。このようなメソッドを新しく暗黙的に含めると、jwscタスクに失敗します。jwscが新しく含まれたWebメソッドのコンパイルに失敗する理由は、数多く考えられます。最も一般的な理由は、JAXBと互換性のないパラメータ・タイプがメソッドに含まれているためです（たとえば、デフォルトのno-argコンストラクタを持つ具象クラスのかわりのインタフェースなど）。
例2: 明示的に非公開にしていないパブリックで非静的なメソッドは、今後はサービス・エンドポイント・インタフェースに含まれるようになります。これらのメソッドは、通常、仕様に完全準拠したWebメソッド宣言ですが（たとえば、jwscで正しくコンパイルされます）、サービスでの公開操作用としては意図されていない可能性があります。
既存のサービスで暗黙的に定義されているサービス・エンドポイント・インタフェース（および動的に生成されるWSDL）を調査し、意図したメソッドのみを公開することをお薦めします。
どちらの例でも、サービスのエンドポイント・インタフェースおよびWSDLからメソッドを除外するには、そのメソッドに次のアノテーションを追加します。
@WebMethod(exclude=true)
一部の環境では、wseeclient.jarを使用してスタンドアロンのJAX-WSクライアント・アプリケーションを実行すると（Oracle Fusion Middleware Oracle WebLogic Server JAX-WS Webサービスのスタート・ガイドのWebサービスの起動時におけるスタンドアロンのクライアントJARファイルの使用に関する項を参照）、アプリケーションがClassNotFound例外とともに停止することがあります。次に例を示します。
Exception in thread "Main Thread" java.lang.NoClassDefFoundError: com/oracle/xml /ws/transport/http/client/HttpTransportPipe at weblogic.wsee.jaxws.WLSTransportTubeFactory.createHttpTransport(WLSTransportTube Factory.java:30
回避方法
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または10.3.3へのアップグレード後、@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インスタンスでJRockit JDKを実行している場合、EclipseLinkまたはTopLinkに基づくデータベースWebサービス（DBWS）の起動は、失敗します。
この問題は、Sun JVM環境でアプリケーション・サーバーを実行している場合には発生しません。
TopLinkでの回避方法は、Oracle Toplinkのリリース・ノートを参照してください。
EclipseLinkでの回避方法は、http://wiki.eclipse.org/EclipseLink/Releaseを参照してください。
一部のシナリオでは、WebLogicクラスタのサーバー・インスタンスがクラッシュすると、Web Services-Atomic Transaction（WS-AT）リカバリの結果として、現在のトランザクションのコミット処理中にタイムアウトが発生するか、サーバーを警告状態に移行するスタック・スレッドが発生します。これらの場合でも、WS-ATデータ・リカバリは成功します。ただし、この場合、トランザクションのコミット確認が適切に処理されないため、ログ・ファイルに失敗状態を示すメッセージが記録されます。サーバーは警告状態で動作し続けることが可能ですが、スレッドはトランザクション破棄のタイムアウト（デフォルトで24時間）に到達するまでスタックし続けます。
回避方法
サーバーを再起動してスタック・スレッドを削除し、警告状態を解消します。
WebLogic Server 10.3.3でサポートされるSun JDK（1.6.0 U18）には、StAX 1.2 APIが含まれます。WebLogic Server 10.3.3でサポートされるJRockit JDK（1.6.0 U17）には、StAX 1.0 APIが含まれます。そのため、Sun JDKに基づいて開発された、StAX 1.2固有のAPIを使用するアプリケーションは、JRockit JDKにデプロイできません。
この項では、次の問題および回避方法について説明します。
ビュー・クラスは、接続単位ベースでは設定できません。
2つのアプリケーションが異なる定義を持つ同じビュー名を参照していると、WebLogic Tuxedo Connectorの共有ハッシュ表により、サーバーで予期しない動作が発生する可能性があります。リソース・セクションと同様に、接続のビュー・クラスに対するハッシュ表が存在する必要があります。
回避方法
すべてのWebLogic Workshopアプリケーション全体で定義されたすべてのビュー・クラスが一貫性を持つことを確認します。つまり、同じビュー名で同じビュー・クラスを表していることを確認します。
この項では、ドキュメントの訂正箇所を示します。
Windowsの「スタート」メニューから「Oracle Weblogic」→「Weblogic Server」→「Examples」→「Documentation」を選択してExamplesドキュメントにアクセスすると、サンプル・ビューアの「検索」機能が動作しません。
回避方法
サンプル・アプリケーションおよびコード例を検索するには、Examplesサーバーを起動してhttp://localhost:7001/examplesWebApp/docs/core/index.htmlに移動します。「手順説明」→「検索」をクリックします。
サンプル・ビューアの「検索」機能では、一部のAvitek Medical Recordsトピックの日本語バージョンと英語バージョンが同時に表示されたトピックが返されることがあります。
『WebLogic Server 10.3.1 MBean Reference』には、SAML 2.0 IDアサーション・プロバイダとSAML 2.0資格証明マッピング・プロバイダに対するインタフェースが記載されていません。かわりに、これらのMBeanインタフェースのJavadocが、『WebLogic Server 10.3.1 MBean API Reference Guide』に記載されています。
WebLogic Serverのコード例のWebページを表示すると、目次のWebサービスのセクション（「WebLogic Serverの例」→「例」→「API」→「Webサービス」）にWeb Services Atomic Transactionの使用方法に関するトピックがリストされません。
回避方法
このトピックを表示するには、Webブラウザに次のURLを入力します。
WL_HOME\samples\server\examples\src\examples\webservices\jaxws\wsat\
instructions.html
ここで、WL_HOMEは、WebLogic Serverのインストール・ディレクトリ（デフォルトはC:\Oracle\Middleware\wlserver_10.3）です。
Oracle Fusion Middlewareのアクティブ・キャッシュの使い方に含まれるサンプルmanifest.mfファイルの例の最後の行に誤植があります。この例は、正しくは次のようになります。
Extension-List: active-cache active-cache-Extension-Name: active-cache active-cache-Specification-Version: 1.0 active-cache-Implementation-Version: 1.0
