| Oracle Fusion Middlewareリリース・ノート 11gリリース1（11.1.1） for AIX Based Systems(64-Bit) B55935-01 |
|
 戻る |
 次へ |
この章では、Oracle WebLogic Serverに関連する問題について説明します。内容は次のとおりです。
この項では、次の問題および回避方法について説明します。
12.1.6項「管理サーバーからEnterprise Managerコンソールにレポートされる、オープン・ファイルが多すぎるというメッセージ」
12.1.7項「AIX SOA-Web層環境でトポロジ・ビューアにアクセスするとスローされる、オープン・ファイルが多すぎるというエラー・メッセージ」
Oracle Fusion Middleware 11gには、Oracle WebLogic Server 11gが含まれます。Oracle WebLogic Serverのリリース番号は、10.3.1です。
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バージョンではデプロイまたは実行できません。
回避方法
サーバーを英語ロケールで起動します。
ドイツ語、スペイン語またはポルトガル語（ブラジル）の言語設定を使用している場合、wsm-pmアプリケーションのadf-config.xmlファイルでプロパティ名のjndi-datasourceとpartition-nameが翻訳されているため、「WSM-04509: データ・ストアへの接続を初期化できません」というエラーが発生します。
回避方法
次のいずれかの回避方法を使用して、スキーマでadf-config.xmlファイルを検証できるように、翻訳されたプロパティ名を英語の名前に置き換えます。
回避方法1: デプロイされた環境で、adf-config.xmlファイルの<property name="JNDI-Datenquelle" value="jdbc/mds/owsm"/>を<property name="jndi-datasource" value="jdbc/mds/owsm"/>に置き換え、<property name="Partitionsname" value="owsm"/>を<property name="partition-name" value="owsm"/>に置き換えます。SOAサーバーを再起動します。
回避方法2: wsm-pm.earに含まれるadf-config.xmlファイルの<property name="JNDI-Datenquelle" value="jdbc/mds/owsm"/>を<property name="jndi-datasource" value="jdbc/mds/owsm"/>に置き換え、<property name="Partitionsname" value="owsm"/>を<property name="partition-name" value="owsm"/>に置き換えてから、管理コンソールを使用してファイルを再デプロイします。この場合、サーバーの再起動は不要です。
回避方法3: 構成ウィザードCIEを実行する前に、com.bea.cie.config.de_6.0.0.0.jar、com.bea.cie.config.pt.BR_6.0.0.0.jarおよびcom.bea.cie.config.es_6.0.0.0.jarファイルに含まれるconfig_de.propertiesファイルのmds.partition.name=Partitionsnameをmds.partition.name=partition-nameに置き換え、mds.jndi.ds=JNDI-Datenquelleをmds.jndi.ds=partition-nameに置き換えます。
管理サーバーに対して構成されているファイル・ディスクリプタの最大数が65535未満の場合、WLS管理サーバーからオープン・ファイルが多すぎるというメッセージがEnterprise Managerコンソールにレポートされます。
回避方法
シェル内のファイル・ディスクリプタの数を増やし、そのシェル内のWLS管理サーバーを再起動します。ファイル・ディスクリプタの数（nofiles）を増やすコマンドは、オペレーティング・システムおよびシェルごとに異なりますが、通常UNIXプラットフォームではulimitコマンドを使用します。ulimitのmanページを参照してください。
次に例を示します。
$ ulimit -n 65535
オープン・ファイルが多すぎるというエラー・メッセージAIX（RC5）SOA-WEBTIER環境でトポロジ・ビューアにアクセスしたときに、オープン・ファイルが多すぎるというエラーが表示された場合、状況に応じてファイル・ディスクリプタの制限を増やす必要があります。
この問題は、WebLogic Serverが起動するたびに、WebLogicのインストールbinディレクトリにあるcommEnv.shファイルのresetFdコマンドにより、ファイル・ディスクリプタの最大数が1024にリセットされるために発生します。
回避方法
この問題を回避するには、次の手順を実行します。
ファイル・ディスクリプタの数をAIXに対して適切な数に設定します。
WLSインストールbinディレクトリのcommEnv.shファイルを編集します。
ulimitコマンドをコメント・アウトします。
シェル・ファイルの制限を2000以上に設定します。
サーバーを再起動します。
weblogic.aspects.AspectJClassLoaderは、IBM Java 6を使用するAIXではサポートされません。
この項では、次の問題および回避方法について説明します。
キャッシュされたJDBCの文に関する情報は、JDBCの監視ページには表示されません。
管理コンソールでページ・フローが完了すると、異なるページ（通常は表）に転送されます。
この時点でブラウザの「戻る」ボタンを押すと、完了したアシスタントで最後のJSPファイルのロード操作が試行されます。これにより、このアシスタントのすべてのコンテキストは破棄されます。
回避方法
変更が取り消されるか完了した後に、ブラウザの「戻る」ボタンを使用してアシスタントに戻ることや、アシスタントの前の手順に戻ることはお薦めしません。かわりに、管理コンソールのナビゲーション・リンクおよびボタンを使用してください。
一部の環境では、管理コンソールにおいて、管理ポートの構成変更に準拠するようにリクエストURLが自動的に更新されません。
コンソール・オプションの「ロックを自動取得して変更をアクティブ化」を選択して（開発モードのデフォルト）、コンソールのアドレスを変更しても（たとえば、ドメイン全体の管理ポートの有効化、管理チャネルの作成、またはSSLリスニング・ポートの変更を行っても）、コンソールはその新規アドレスに自動的にリダイレクトされません。かわりに、ブラウザにはエラーが表示されます。
回避方法
ブラウザに、管理サーバーが現在リクエストをリスニングしているURLアドレスとプロトコルを入力します（たとえば、http://localhost:7001/consoleからhttps://localhost:9002/consoleに切り替えます）。
管理コンソールでは、サポート対象外で正常に動作しないワーク・マネージャ構成を作成できます。不適切なワーク・マネージャ構成により、サーバー・ログに多くの例外が記録される可能性があります（通常は、デプロイメント・ディスクリプタの解析中に検証問題が例外として検出されます）。
回避方法
ワーク・マネージャ構成のオンライン・ヘルプに記載されているガイドラインに従ってください。具体的には、任意のワーク・マネージャにはただ1つのリクエスト・クラスを割り当てます。また、そのリクエスト・クラスのスコープは、ワーク・マネージャと同等かそれより広範囲である必要があります。グローバル・ワーク・マネージャにアプリケーション・スコープのリクエスト・クラスを割り当てることはできません。また、アプリケーション・スコープのワーク・マネージャに複数のアプリケーション・スコープのリクエスト・クラスを作成することもできません。
ドキュメントに記載された制約に準拠するようにワーク・マネージャ構成を修正することで、これらの問題を解決できます。
「クラスタ: 監視: 概要」ページの「サーバー状態」表には、「プライマリ」および「セカンダリ分散名」という2つのデフォルト列が含まれます。レプリケーション環境によっては、これらのフィールドに、「クラスタ: 監視: フェイルオーバー」ページで収集および表示されるレプリケーション統計の一部が反映されないことがあります。
正確な情報は、「クラスタ: 監視: フェイルオーバー」ページを参照してください。
管理コンソールで、個別のライブラリ・デプロイメントで定義されたタイプを参照するEJBデプロイメントに対してセキュリティ・ポリシーを定義する場合、そのライブラリ・デプロイメントがコンソールで使用できないと、例外が発生する可能性があります。
回避方法
すべてのライブラリ・デプロイメントは、管理サーバーに加え、参照するアプリケーションをサポートするために必要な任意の管理対象サーバーをターゲットとする必要があります。これにより、ポリシーの定義時に、コンソールでそれらのライブラリ・デプロイメントにアクセスできるため、参照されるタイプが必要に応じて確実にクラス・ロードされます。
管理コンソールには、デプロイメント・プランで行われた外部変更が反映されないことがあります。コンソール・ユーザーがデプロイメント・プランを表示しているときに、コンソール外部のデプロイメント・プランで変更が行われると（Workshopの使用、プラン・テキスト・ファイルの直接編集、WLSTまたはWebLogic.Deployerを使用した新規プランによるデプロイメントの更新など）、それらの変更はコンソール・ユーザーに表示されません。
回避方法
別のデプロイメントの構成ページに移動してから、元のデプロイメントに戻ります。
一部の環境で視覚障害者のアクセシビリティ・レベルを向上するため、管理コンソールでは、その用途や対象に関してリンク・テキスト単独では実現できないより詳しい説明が必要な場合に、リンク用のタイトル属性を提供しています。この主な使用例は、リンクがシミュレート・タブ・グループの一部であり、現在そのタブが選択されている場合です。ただし、スクリーン・リーダーのユーザーは、表示されるリンク・テキストのかわりに、これらのリンク・タイトル属性が読み取られるように構成を変更する必要があります。
次の手順は、主要なスクリーン・リーダーのJAWS（Freedom Scientific社製）用です。
リンク・タイトルを読み取るようにJAWSを構成するには、次の手順を実行します。
アクティブなブラウザ・ウィンドウにWebLogic Serverを表示したまま、[Insert]、[Shift]および[V]キーを同時に押してJAWSの「Personalized Settings」ダイアログを開きます。
JAWSバージョン6.x、7.xおよび8.xの場合:
「Links With Text Only」設定に移動し、「Title」オプションを選択します（[Space]を押して値を切り替えます）。
JAWSバージョン9.xの場合:
「Links Options」ノードを開き、「Text Links」オプションに移動して、「Show Using Title」オプションを選択します（[Space]を押して値を切り替えます）。
「Close」を選択して構成変更を保存します。
WebLogic Serverの今回のリリースでは、Apache Beehiveサポートに関する既知の問題は存在しません。
WebLogic Serverの今回のリリースでは、クラスタリングに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
ConfigToScriptで生成されたconfig.pyファイルの実行時にサーバーが稼働していないと、次のエラーが発生してドメインの作成に失敗します。
com.bea.plateng.domain.script.ScriptException: The password must be at least 8 alphanumeric characters with at least one number or special character.
回避方法
手動でサーバーを起動し、ConfigToScriptで生成されたconfig.pyファイルを実行します。次の手順を使用してください。
ScriptExceptionによりconfig.pyが失敗した後、次のようにcdコマンドで空のドメイン・ディレクトリに移動します。
cd <domain_name>
サーバーを起動せずにconfig.pyを実行した場合の<domain_name>のデフォルトは、WLSTConfigToScriptDomainです。
サーバーを起動し、次のように空の初期ドメインを作成します。
java -Xmx512m -XX:MaxPermSize=128m -Dweblogic.Name=AdminServer
-Dweblogic.Domain=<domain_name> weblogic.Server
<domain_name>は、使用するドメインの適切な名前で置き換えてください。プロンプトが表示されたら、使用するユーザー名とパスワードを入力します。
ユーザー名とパスワードを要求するように、生成されたconfig.pyを変更します。これを行うには、config.pyの次の接続コマンドを変更します。
connect(userName, passWord, URL)
次のように変更します。
connect()
config.pyを再実行します。
java weblogic.WLST config.py
手順2で指定したユーザー名とパスワードを求められます。
存在しないサーバー名を使用して管理サーバーに接続しようとすると、その存在しないサーバー名に対応するディレクトリがdomain_name/serversディレクトリ内に作成されます。
回避方法
管理サーバーに接続する際は、有効なサーバー名を指定します。
WebLogicパスワードを入力した直後に[Ctrl]を押しながら[C]を押してstartManagedWebLogic.shプロセスを終了すると、ターミナル・ウィンドウで異常な動作が発生することがあります。たとえば、[Enter]を押すと、プロンプトは次の行に移動するかわりに[Tab]を押した状態になり、プロンプトに入力した任意の文字は端末に表示されません。この問題は、開発モードで発生するもので、本番環境では発生しません。
回避方法
現在のxtermを終了して新規に開始するか、xtermにstty echoと入力します。
WebLogic Serverの今回のリリースでは、コンソール拡張に関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
いずれかの管理対象サーバーをホストするマシンが異常停止した状態、ネットワーク・ケーブルが外れた状態、またはネットワーク・インタフェース・カードに問題が発生した状態で、サーバーがその管理対象サーバーと通信しようとすると、スレッドが接続の取得を待機してスタックします。
回避方法
この問題は、現在、次のプライベート・フラグを使用して解決できます。
-Dweblogic.client.SocketConnectTimeoutInSecs
このフラグに、接続を取得しようとするスレッドを解放し、リクエストの迅速な終了を可能にする適切なタイムアウト値を設定します。
WLSでIPv6形式のアドレスを使用する場合、URLでは、ホスト・アドレス用に角カッコ（[ と ]）を含める必要があります。含めない場合、WLSTは実行中のサーバーに接続できない可能性があります。
回避方法
ホスト・アドレスに角カッコを追加します。次に例を示します。
t3://[fe80:0:0:0:203:baff:fe2f:59e5]:9991
クラスタ・サーバーでサーバー全体の移行が発生したときに管理サーバーが停止しており、サーバーが以前に一度も実行されたことのないマシンに移行されると、そのサーバーは新規マシンで起動できません。
回避方法
この問題には次のいずれかの回避方法を使用します。
サーバー移行の実行時に必ず管理サーバーを起動しておきます。
クラスタ内のすべての移行可能サーバーで共有ディスクまたはNFSを使用します。
J2EEアプリケーションでFastswapが有効化されている場合、開発中にJavaクラスに対して特定のタイプの変更を行い、再デプロイすることなくその変更を参照できます。このとき、Javaオブジェクトのすべてのインスタンス状態は保持されます。
オブジェクト状態が保持されない変更タイプの1つとして、フィールド名の変更があげられます。このとき、フィールドは次のように処理されます。
古い名前を持つフィールドは削除されます。
新しい名前を持つフィールドは追加されます。
つまり、この場合、古いフィールドの状態は名前の変更されたフィールドに継承されません。
WorkshopまたはFastSwap Antタスクの使用時には、インスタンス・フィールド名の変更により値のリセットが発生しても、FastSwap操作は正常に完了しましたというメッセージが表示されることがあります。
回避方法
フィールド名の変更時にインスタンスの値がリセットされるのは通常の動作です。
コマンドラインで間違った管理サーバーURLを指定して管理対象サーバーを起動すると（つまり、指定したURLで管理サーバーに接続できない場合）、管理対象サーバーは、管理対象サーバー独立（MSI）モードで起動されます。
この場合、管理サーバーとノード・マネージャのどちらも管理対象サーバーのステータスを追跡できません。管理コンソールには、管理対象サーバーのステータスは「Unknown」と表示されますが、サーバーは実際にはMSIモードで実行されています。
この項では、次の問題および回避方法について説明します。
12.9.1項「weblogic-application.xmlでsecurity-permission要素が使用できない問題」
12.9.6項「デプロイメント・プランの適用時に「config-root <directory>が見つかりませんでした」という警告が表示される問題」
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管理コンソールを使用している場合、java.lang.NoClassDefFoundErrorが発生する可能性があります。
回避方法
WebLogic Server管理コンソールでは、Javaのデータ型とアノテーションを処理するために、共有ライブラリ・デプロイメントにアクセスする必要があります。したがって、すべての共有ライブラリ・デプロイメントは、管理対象サーバーやクラスタのみでなく、常に管理サーバーも対象とする必要があります。
編集セッションを開始して、アプリケーションをインストールし、その変更を元に戻すと、デプロイメント・タスクは適切にクリーンアップされません。このタスクは、初期化状態のまま残り、将来の変更のアクティブ化の際に問題の原因となります。
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ディレクトリを手動で作成します。
管理対象サーバーの起動時に管理サーバーが使用できない場合、管理対象サーバーはMSIモードで起動されます。後で管理サーバーを起動すると、管理対象サーバーはその管理サーバーに接続されます。ただし、管理対象サーバーにデプロイされた各アプリケーションの状態は、管理対象サーバー上のアプリケーションの状態を反映するために更新されません。各アプリケーションの状態は、WebLogic Server管理コンソールに「新規」または「準備完了」として表示されます。
回避方法
この問題には、次の2つの回避方法があります。
管理対象サーバーを起動する前に管理サーバーを起動します。
管理サーバーの起動後にアプリケーションを再デプロイします。
この項では、次の問題および回避方法について説明します。
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のシリアライズは必要ありません。
org.apache.openjpa.*パッケージのみをフィルタで除外すると（ただし、com.solarmetric.*およびkodo.*パッケージは除外しません）、アプリケーションのデプロイメントは次のような例外メッセージとともに失敗します。
java.lang.IllegalArgumentException: interface org.apache.openjpa.event.CallbackModes is not visible from class loader
例外メッセージに出現する特定のクラスまたはインタフェースは、変化する可能性があります。
回避方法
アプリケーションに付属するバージョンのOpenJPAをデプロイする場合、3つのKodo関連のパッケージは、すべて次のようにprefer-application-ライブラリ・ディレクティブを使用してフィルタする必要があります。
<weblogic-application>
<prefer-application-packages>
<package-name>org.apache.openjpa.*
</package-name>
<package-name>kodo.*</package-name>
<package-name>com.solarmetric.*
</package-name>
</prefer-application-packages>
</weblogic-application>
Kodoおよびcom.solarmetricパッケージは、すべてのKodo機能を無効化する場合（つまり、OpenJPAのみを使用する場合）でもフィルタする必要があります。
また、ユーザー独自のバージョンのopenjpa.jarを提供するが、WebLogic付属のKodo jarを使用する場合も、アプリケーションでkodo.*およびcom.solarmetric.*を除外し、WebLogicディストリビューションのKodo jarをバンドルする必要があります。
将来のある時点で新規APIや不具合の修正がコードベースに導入された場合も、状況によっては、アプリケーションでserp.*を除外し、その独自バージョンをバンドルする必要があります。ただし、serpには、org.apache.openjpa.*、kodo.*およびcom.solarmetric.*パッケージ間にあるような相互依存関係はありません。
クラス・レベルで宣言された索引が、スキーマ作成時に作成されないことがあります。
回避方法
スキーマ生成ツールの実行後に手動で索引を作成します。
一部のデータベースで@Idフィールドに@Uniqueのアノテーションも付けると、OpenJPAにより例外がスローされます。データベースの主キーは、定義上一意です。一部のデータベースでは、列に一意索引を作成することでこれを実装しています。
回避方法
単一のフィールドに@Idと@Uniqueの両方を指定しないでください。
Sybaseの提供するJDBCドライバのかわりにWebLogicに付属するSybaseドライバを使用して、IDが自動的に増加するエンティティを対象にデータベースにレコードを挿入しようとすると、失敗する可能性があります。これは、次に使用可能なID値をフェッチするデフォルトの問合せが、常に0（ゼロ）を返すためです。
|
注意: WLS 10.3.1では、Sybase JDBCドライバはWebLogic Serverに付属していません。Sybaseからドライバをダウンロードする必要があります。したがって、この問題は新規のWLSインストール環境には適用されません。 |
回避方法
次のようにkodo.propertiesファイルのlastGeneratedKeyQueryプロパティを上書きします。
openjpa.jdbc.DBDictionary: lastGeneratedKeyQuery='SELECT MAX({0}) FROM {1}'
バージョン・データのないエンティティの操作時に、キャッシュ・ヒットおよびミスの数が異常に上昇することがあります。この異常なキャッシュ・アクセスは、EntityManagerがクローズしてすべての格納エンティティがデタッチされたときに発生します。バージョン・フィールドのないエンティティは、システムでバージョン・データが欠落していると認識されます。そのため、システムではデタッチの前にキャッシュでそのバージョンをチェックして応答します。
回避方法
バージョン・フィールドや他のバージョン処理方法を持つエンティティでは、異常なキャッシュ・アクセスは発生しません。
エンティティ内の空のバイト配列フィールドをSybaseデータベースに永続化しようとすると、値がバイトではなくNULLとして格納されます。そのため、値がNULLとして取得されます。
この原因は、データベースへの格納時に空のバイト配列をNULLに変換するSybaseドライバの制限にあります。この問題は、WebLogic JDBCドライバとSybase固有のドライバの両方で発生します。
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();
}
現在のところ、EJB3仕様におけるビジネス・オブジェクトは、シリアライズする方法がありません（従来のコンポーネント・オブジェクトとは異なります）。
回避方法
ビジネス・オブジェクトをシリアライズする必要がある場合、最初にBusinessObject._WL_getBusinessObjectHandle()を起動してビジネス・ハンドル・オブジェクトを取得してから、そのビジネス・ハンドル・オブジェクトをシリアライズします。このシリアライズから復帰するには、単にビジネス・ハンドル・オブジェクトをデシリアライズして取得し、そのgetBusinessObject()を起動します。
キャッシュ・ミス率の高いエンティティBeanでは、準備完了しているBeanインスタンスの保持がパフォーマンスに悪影響を及ぼす可能性があります。
回避方法
<entity-descriptor>の<entity-cache>要素で<disable-ready-instances>フラグを設定すると、コンテナではキャッシュ内に準備完了インスタンスが保持されません。デプロイメント・ディスクリプタでこの機能を有効化すると、キャッシュではアクティブ・インスタンスのみが保持されます。関連するトランザクションがコミットまたはロールバックされた後、Beanインスタンスは即座にアクティブ・キャッシュからプールに移動されます。
EJBでジェネリクスを使用すると、次のような問題が発生します。
ビジネス・インタフェースでjava.rmi.Remoteを拡張し、スーパー・クラスの汎用メソッドを拡張する場合、デプロイメントに失敗します。
ビジネス・インタフェースでjava.rmi.Remoteを拡張しない場合、汎用ビジネス・メソッドの起動に失敗します。
回避方法
最初の例は、WLS 10.3以上の制限事項です。
2番目の例は、サーバー・サイドから必要なクラスをダウンロードすることで解決できます。ただし、ネットワーク・ダウンロードが無効な場合は、同じように起動に失敗します。ネットワーク・ダウンロードがユーザーの環境で許可されない場合、最初にappcを実行してから、生成されたクラスをクライアント・サイドのクラスパスに追加することをお薦めします。
この項では、次の問題および回避方法について説明します。
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のサンプル・アプリケーションを起動すると、コンソールの標準出力に表示されます。
回避方法
この警告は無害のため、無視して問題ありません。
この項では、次の問題および回避方法について説明します。
12.12.2項「ローカル・クライアントによりパブリッシュされたイベント・メッセージが他のサーバーに接続されたサブスクライブ済クライアントに受信されない問題」
12.12.3項「ローカル・クライアントによりパブリッシュされたイベント・メッセージにメッセージ・フィルタが適用されない問題」
HTTPパブリッシュ/サブスクライブ・サーバーでは、ローカル・クライアントの認証および認可がサポートされません。ローカル・クライアントは、HTTPパブリッシュ/サブスクライブ・サーバーのチャネルを操作する完全な権限を持ちます。つまり、ローカル・クライアントは、チャネルを作成または削除することや、チャネルからイベントをパブリッシュまたはサブスクライブすることが可能です。
クラスタ環境では、あるサーバーのローカル・クライアントによりパブリッシュされたイベント・メッセージは、同じサーバーに接続されたサブスクライブ済クライアントによってのみ受信されます。これらのメッセージは、クラスタ内の別のサーバーに接続されたサブスクライブ済クライアントでは受信されません。
ローカル・クライアントにより任意のチャネルにパブリッシュされたイベント・メッセージには、そのチャネルに対して構成されたメッセージ・フィルタが適用されません。
この項では、次の問題および回避方法について説明します。
WebLogic Server製品がデフォルト以外の場所にインストールされていると、packおよびunpackコマンドがjava.lang.ClassNotFoundExceptionとともに失敗する可能性があります。
回避方法
$WL_HOME/.product.propertiesファイルを編集します。$WL_HOMEは、WebLogic Serverのインストール先のディレクトリです。次の2つのプロパティを追加します。
weblogic.server.modules.featurejar=MWHOME/modules/features/weblogic.server.
modules_10.3.1.0.jar
WLS_PRODUCT_VERSION=10.3.1.0
適切なファイル・セパレータを使用して、MWHOMEに対応するFusion Middlewareホーム・ディレクトリへの絶対パスを置き換えます。たとえば、Microsoft Windowsプラットフォームの場合、次のようになります。
weblogic.server.modules.featurejar=D\:\\myMWhome\\modules\\features\\weblogic. server.modules_10.3.1.0.jar
インストーラでは、インストールの完了前にマシン上に十分なディスク領域が存在するかどうかが検証されません。結果として、領域不足が原因でインストールを完了できないと、次のエラー・メッセージが表示され、インストールは終了します。
Fatal error encountered during file installation. The installer will nowcleanup and exit!
回避方法
この問題が発生した場合、次のコマンドを使用してインストーラを再実行します。
$JAVA_HOME/bin/java -jar wls1031_generic.jar -log=log.out -log_priority=debug
前述のコマンドにより、インストール操作のログが生成されるため、障害の正確な原因を詳細に調査できます。原因が実際に領域不足であった場合、ログ・ファイルにそのことが明示的に示されます。
この項では、次の問題および回避方法について説明します。
FastSwapでは、フィールドやメソッドのアクセス修飾子が緩和されることがあります。privateおよびprotectedメンバーは、実行時にpublicになる可能性があります。これにより、リフレクションの動作が変更されるため、Strutsなどのリフレクションベースのフレームワークが影響を受ける可能性があります。
FastSwapでは、エンティティBeanおよびejbClass（セッション/MDB）の再定義はサポートされません。そのため、エンティティ・クラスを更新すると、再定義エラーが発生します。
回避方法
エンティティ・クラスの更新後に、アプリケーションを再デプロイします。
WebLogic Serverの今回のリリースでは、JDBCに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
デプロイメント・ディスクリプタの検証が有効化されており、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名にはマルチバイト・キャラクタを使用しないでください。
接続IDやサブスクライバID内にピリオド（ドット）またはスラッシュが含まれると、一部のJMSアプリケーションが原因でWebLogic Server上でメモリー・リークが発生する可能性があります。この問題が発生するのは、通常、（a）トピック宛先で永続サブスクリプションを継続的に作成および破棄し、かつ（b）新規永続サブスクリプションごとに接続IDまたはサブスクライバIDで最後の「.」または「/」の前に一意の文字列を指定する（過去に破棄したサブスクリプションの文字列を再利用しない）アプリケーションのみに限定されます。
回避方法
接続IDおよびサブスクライバIDへのピリオド（.）またはスラッシュ（/）の指定は、慎重に行ってください。
JMS Cクライアント・ライブラリを使用するCプログラムは、JVMの障害によりクラッシュする可能性があります。この問題は、一部のJVM製品でのみ発生することが確認されている断続的な既知の競合状態に関連しており、障害発生の可能性は、JVMのバージョンとパッチ・レベル、オペレーティング・システムおよびハードウェアに応じて変化します。具体的には、JMS Cクライアント・ライブラリがCスレッドをJVMに暗黙的にアタッチしますが、作業の完了時にそのデタッチに失敗します。
回避方法
回避方法は次のとおりです。
以前にJMS C-APIにコールされた、終了したCスレッドからJVMをデタッチするコードをクライアントに追加します。
以前にJMS C-APIにコールされたCスレッドが、プロセス全体が終了する前に終了することを禁止します。
Sun 1.5以上では、特にこの問題を処理できますが、Sun JVMでもデタッチ処理を行うことをお薦めします。詳細は、次を参照してください。
より新しいJVMにアップグレードします。
この項では、次の問題および回避方法について説明します。
デプロイメント・プランを使用して、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拡張モデルが有効化されている場合、パフォーマンス上の理由から、WLS 10.3以上ではJSPタグ・ハンドラでSpring依存関係インジェクション（DI）がサポートされません。
現在、WLSでは、サーブレット、フィルタ、リスナーなど、ほとんどのWebコンポーネントでSpring DIがサポートされます。ただし、現在のところ、パフォーマンス上の理由からJSPタグ・ハンドラではSpring DIはサポートされません。
セッションが永続的で、古いバージョンのサーブレット・コンテキストがリタイアされたときに、有効なセッションIDでアプリケーションにアクセスすると503エラーが発生します。
たとえば、バージョン付きWebアプリケーションのセッション永続タイプがfileであるとします。ユーザーは、このアプリケーションに正常にアクセスできます。その後、このアプリケーションのバージョン2が再デプロイされ、バージョン1はリタイアされます。同じユーザーがこのアプリケーションにアクセスすると、503エラーが発生します。
WebLogic Serverの今回のリリースでは、JTAに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
IIOPシン・クライアントは、JVMに対する依存性が原因でAIXではサポートされません。この問題の影響を受けるのは、シン・クライアント・アプリケーションのみです。
回避方法
WebLogic ServerはAIX上で実行し、シン・クライアントは別のオペレーティング・システム上で実行します。
最新の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を持つように状況に応じて再コンパイルする必要があります。
この項では、次の問題および回避方法について説明します。
12.22.1項「@unharvestableとして明示的にマークされていないMBean属性がWLS管理コンソールで収集可能として表示される問題」
12.22.5項「デプロイメント・プランを使用して追加したMethodInvocationStatisticsActionの使用時に発生するNullPointerException」
@unharvestableタグは、インタフェース・レベルでは評価されません。明示的に@unharvestableとマークされていないMBean属性は、収集可能とみなされ、WebLogic管理コンソールで収集可能として表示されます。
回避方法
MBean属性を明示的に@unharvestableとしてマークできます。
ハーベスタの監視ルールの変数が複数のメトリック・データ・ポイント・トリガーに解決される場合、送信通知のWatchDataフィールドが空になります。通常、このフィールドには、MBeanインスタンスのリストと、ルールの評価に使用される属性の実際の値が含まれます。
SNMPコマンドライン・ツールweblogic.diagnostics.snmp.cmdline.ManagerのSnmpTrapLoggerサブコマンドの-C prop-fileオプションは機能しません。その結果、SNMPコマンドライン・ツールのSnmpTrapLoggerサブコマンドでログ構成プロパティ・ファイルを指定できません。
回避方法
現在のところ、この問題の回避方法はありません。
サーバーの再起動後に初めてWLDFハーベスタを構成し、DomainRuntimeネームスペースのMBeanメトリックのWLDFモジュールで最初のWLDF監視を構成しようとすると、NullPointerExceptionが発生します。このエラーは、ハーベスタが初期化を完了する前に、サーバーのDomainRuntime MBeanServerで使用可能なMBeanセットのハーベスタをコンソールが問い合せようとするために発生します。このエラーは、（a）ハーベスタがまだ初期化されておらず、かつ（b）WLDFモジュールで作成された最初の監視がDomainRuntimeネームスペースのMBeanに対して構成されている場合にのみ発生します。
これは、重大なエラーではありません。
回避方法
監視の作成の試行を取り消して、再試行します。NullPointerExceptionエラーは、再度発生することはありません。
デプロイメント・プランを使用してデプロイ済アプリケーションのインスツルメンテーションに新規診断モニターを追加し、新しく追加したモニターにMethodInvocationStatisticsActionアクションをアタッチする場合、次の条件下でMethodInvocationStatisticsActionアクションを実行すると、NullPointerExceptionがスローされます。
アプリケーションがすでにデプロイされています。
デプロイメント・プランを使用して、アプリケーションのインスツルメンテーション構成にaroundの新規診断モニターを追加しました。
デプロイメント・プランを使用して、新しく追加した診断モニターにMethodInvocationStatisticsActionをアタッチします。
MethodInvocationStatisticsActionを起動するようにアプリケーションが実行されます。
この問題は、アプリケーションのデプロイ後に、新規追加された診断モニターにデプロイメント・プランを使用してMethodInvocationStatisticsActionをアタッチする場合にのみ発生します。インスツルメンテーション構成の更新後にアプリケーションを再デプロイする場合、この問題は発生しません。
回避方法
アプリケーションのインスツルメンテーション構成にMethodInvocationStatisticsActionを追加する場合、プランでアプリケーションを更新するだけでなく、プランでアプリケーションを再デプロイします。
複合タイプまたは複合タイプの配列に相当するMBean属性のエントリは、SNMPでこれらのタイプがネイティブにサポートされないため、WebLogic Server 10.3.1ではSNMP MIBから削除されています。以前のリリースのWebLogic Serverでは、複合タイプのオブジェクトに対してObject.toString()が返されましたが、現在、これは監視目的として意味がありません。
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の今回のリリースでは、プロトコルに関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
Antバージョン1.7のrmicタスクをコールすると、自動的に-vcompatフラグが追加されますが、これはOracle WebLogic Serverのrmicと互換性がありません。
回避方法
rmicコールが次の形式の場合、次のいずれかの回避方法を使用します。
rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
base="${module_location}/core-legacy-ra/classes"
classpath="${core.classes}" compiler="weblogic" />
stubversionを追加します。
<rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
base="${module_location}/core-legacy-ra/classes"
classpath="${core.classes}" compiler="weblogic"
stubversion="1.2"/>
compilerフラグを削除します。
<rmic classname="com.bea.crmsimulation.legacyra.LegacyAdapter"
base="${module_location}/core-legacy-ra/classes"
classpath="${core.classes}"
この項では、次の問題および回避方法について説明します。
12.27.1項「適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能するStoreBootIdentityオプション」
12.27.2項「AllowUnencryptedNullCipherをTrueに設定しないとNULL暗号を必要とする接続が失敗する問題」
12.27.3項「SecurityServiceExceptionによりWLS Serverインスタンスで起動時に障害が発生する問題」
12.27.5項「InvalidParameterExceptionメッセージが生成されて管理コンソールに表示される問題」
12.27.6項「weblogic.xmlファイルが存在しない場合にweblogic.policyのデフォルトのWeb権限が機能しない問題」
12.27.7項「循環グループ・メンバーシップが原因でOracleInternetAuthenticatorが多数のLDAP接続をオープンする問題」
-Dweblogic.system.StoreBootIdentityオプションは、適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能します。このディレクトリは、通常、構成ウィザードまたはアップグレード・ツールにより作成されます。
ただし、適切なサーバー・セキュリティ・ディレクトリが、ソース・コントロール・システムにチェックインされるドメインに存在しないこともあります。
WLSでは、SSL接続でのNULL暗号の使用が可能ですが、結果としてデータが暗号化されません。
WLS 10.3以上では、NULL暗号の使用はデフォルトで無効化されています。クライアントでNULL暗号を有効化するには、weblogic.ssl.AllowUnencryptedNullCipherシステム・プロパティをtrueに設定します。次に例を示します。
-Dweblogic.ssl.AllowUnencryptedNullCipher=true
WLS 10.3以上では、このシステム・プロパティでNULL暗号の使用を明示的に有効化しなければ、NULL暗号を必要とするクライアントSSL接続は失敗します。NULL暗号を使用するには、サーバー側とクライアント側の両方でNULL暗号を有効化する必要があります。両方で有効化しない場合、SSLハンドシェイクに失敗します。
WLS Serverインスタンスは、RDBMSセキュリティ・データ・ストアがWLSに付属するDB2ドライバを使用してDB2データベース用に構成されている場合、SecurityServiceExceptionにより起動時に障害が発生する可能性があります。
回避方法
RDBMSセキュリティ・データ・ストアでDB2データベース用にAlternateId接続プロパティを使用する場合、WLSに付属するDB2ドライバの使用時に追加プロパティのBatchPerformanceWorkaroundもtrueに設定する必要があります。
ドメインをWLS 6.1からアップグレードすると、認証障害によりWLS Serverインスタンスが起動しなくなります。
回避方法
WLS 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およびアーティファクト・バインドを有効化します。オプションで、優先バインドを選択することもできます。
weblogic.policyにデフォルトのWebアプリケーション権限を定義する場合に、Webアプリケーションにweblogic.xmlディスクリプタ・ファイルが存在しないと、デフォルトのWeb権限は有効化されず、AccessControlExceptionが発生する可能性があります。
回避方法
アプリケーションにweblogic.xmlディスクリプタ・ファイルを追加します。
OIDサーバーのスキーマに存在する静的グループに、その静的グループそれ自体を示すuniquememberエントリが含まれる場合、循環グループ・メンバーシップが作成されます。このような循環参照により、WebLogic ServerのOracleInternetAuthenticatorがLDAPサーバーに対する多数のLDAP接続をオープンし、最終的にすべての接続リソースを使い果たすことがあります。
回避方法
自分自身を参照する静的グループをLDAPスキーマに含めないでください。
WebLogic Serverをインストールすると、AIXでOracleセキュリティ・アップデートを実行できないという問題が発生します。
回避方法
次の手順を実行します。
wls1031_generic.jarからarchives/com.oracle.ocm_1.0.0.0.jarを抽出します。
jar xvf wls1031_generic.jar archives/com.oracle.ocm_1.0.0.0.jar
-Xbootclasspathを指定してwls1031_generic.jarをインストールします。
java ${JAVA_OPTION} -jar -Xbootclasspath/p:archives/com.oracle.ocm_1.0.0.0.jar wls1031_generic.jar
この項では、次の問題および回避方法について説明します。
SpringSourceのpetclinicサンプルでは、petclinic.warは問題なくデプロイされます。petclinic.earは、正しくパッケージされていないため、WLSにデプロイされません。petclinic.earのパッケージの修正を依頼するリクエストがSpringSource社に提出されています。
この項では、次の問題について説明します。
WebLogic Server 10.3.1を使用してドメインを作成し、WebLogic Server 10.3にロールバックすると、そのドメインで作成したサーバーを起動できません。これは、既知の制限であり、WebLogic Server 10.3に存在しない新しいスキーマ定義（xmlns.oracle.com）に対する参照がconfig.xmlファイルに含まれることが原因です。
この項では、次の問題および回避方法について説明します。
プロダクション再デプロイメント機能を使用して新規バージョンのアプリケーションをデプロイすると、通常は、既存のすべてのセッションの処理が元のバージョンのアプリケーションで継続されるように、元のアプリケーションの正常な停止操作が開始されます。ただし、jdbcまたはasync-jdbcセッション永続性を使用している場合、元のバージョンのアプリケーションはリタイアされません。
回避方法
次の2つの回避方法があります。
2つのバージョンのアプリケーション間にセッション・オブジェクトの非互換性問題が存在しない場合、正常な停止を行わないプロダクション再デプロイメントを選択します（「ただちに強制停止」）。これにより、ただ1つのアプリケーション・バージョンがアクティブとなり、リクエストを受信します。
2つのバージョンのアプリケーション間に非互換性問題が存在する場合、古いバージョンの正常なリタイアを実行します。アプリケーションおよびセッション表を監視し、古いバージョンを強制的にリタイアする適切なタイミングを見つけます。セッション表には、すべてのセッションが表示されます。表のすべてのセッションが、（タイムアウトや無効化のために）新規バージョンのアプリケーションのセッションのみになるまで減少したら、停止を強制して古いバージョンのアプリケーションを安全にリタイアできます。
この項では、次の問題および回避方法について説明します。
WLST loadPropertiesコマンドでは、名前に「.」文字が含まれるプロパティのロードはサポートされません。たとえば、プロパティmyapp.db.defaultがプロパティ・ファイルに存在する場合、WLSTでは次のように名前の例外がスローされます。
Problem invoking WLST - Traceback (innermost last):
File "<iostream>", line 7, in ?
File "<iostream>", line 4, in readCustomProperty
NameError: myapp
これは、PythonおよびloadPropertiesコマンドのシステム制限です。WLSTでは、変数の名前と値を読み取り、それらをPythonインタプリタの変数として設定します。Pythonインタプリタでは、ネームスペースのモジュール・スコープ、またはパッケージ名（あるいはその両方）を示すデリミタとして「.」を使用します。したがって、myapp.db.default.version=9iはmyapp.db.defaultパッケージ内にあると仮定されるため、プロパティ・ファイルで例外が発生します。そのようなパッケージは存在しません。
回避方法
ピリオドを含まない変数名を使用します。これにより、プロパティ・ファイルから変数をロードして、WLSTスクリプトで参照できます。ネームスペースを区切る場合、アンダースコア（_）や小文字/大文字などの別の文字を使用できます。
別の方法として、プロパティ・ファイルから変数を設定できます。スクリプトで変数を使用すると、それらの変数は実行時にプロパティ・ファイルの実際の値に置換されます。次に例を示します。
myapp.py var1=10 var2=20 import myapp print myapp.var1 10 print myapp.var2 20
この方法は、ネームスペースの1つのレベルで動作します（myapp.var1、myapp.var2）。ネームスペースと同じ名前を共有するトップレベル変数では動作しません（myapp=oracleとmyapp.var1=10など）。myapp変数を設定すると、myappネームスペースは上書きされます。
複数のレベルが必要な場合は、ディレクトリを使用してパッケージ・ネームスペースを定義します。次のようなvars.pyファイルを含むmyapp/db/defaultディレクトリを作成します。
var1=10 var2=20
その後、次のようにインポートします。
import myapp.db.default.vars print myapp.db.default.vars.var1 10
状況によっては、サブディレクトリに__init__.pyファイルを追加する必要があります。パッケージの詳細は、次のPythonのドキュメントを参照してください。
Jython 2.2で作成されたデフォルトのcachedirは、有効なディレクトリではありません。Jythonをweblogic.jarから直接使用している場合、これによりWLSTでエラーが発生します。
回避方法
この問題には、次の2つの回避方法があります。
WLSTの起動時に、-Dpython.cachedir=<valid_directory>パラメータを指定します。
weblogic.jarに含まれる不完全なJythonを使用するかわりに、Jython 2.2.1を個別にインストールします。
WLST returnType='a'オプションでは、指定したディレクトリから属性のみが返される必要があります。しかし、同時に子の管理オブジェクトも返されます。次に例を示します。
ls('Server')
drw- AdminServer
drw- worker01
ls('Server', returnMap='true', returnType='a')
drw- AdminServer
drw- worker01
ls('Server', returnMap='true',returnType='c')
drw- AdminServer
drw- worker01
returnType='a'付きのlsでは、子の管理オブジェクトはリストされないはずですが、AdminServerとworker01は子の管理オブジェクトです。
回避方法
ls(returnType='a')からの出力を処理する場合、返されたエントリがディレクトリであるかどうかをチェックしてください。
この項では、次の問題について説明します。
現在のところ、mod_wlおよびmod_wl_ohsではコンテナ・レベルのフェイルオーバーのみがサポートされ、アプリケーション・レベルのフェイルオーバーはサポートされません。mod_wl_ohsは、管理対象サーバーが起動されて実行されているかぎり、停止しているアプリケーションにリクエストをルーティングし続けます。クラスタ環境では、アプリケーションが停止していても、元のセッションが開始されたコンテナへのリクエスト送信が継続され、通常はHTTPエラー404が発生します。
この項では、次の問題および回避方法について説明します。
12.33.8項「JAX-RPCスタイルのJavaBeansに相当するJavaメソッド引数またはリターン・パラメータの処理」
12.33.9項「JWSコールバックで2次元のXMLオブジェクトを使用する場合に発生するIllegalArgumentException」
12.33.13項「Webサービス固有のリソースなしで作成されたドメインに対して生成されるサーバー・ログのINFOメッセージ」
12.33.14項「クライアント証明書を使用した非同期レスポンスおよび肯定応答の送信が信頼できるメッセージングでサポートされない問題」
12.33.15項「xmlcatalog要素のエンティティにリモート・ファイルやアーカイブ内のファイルを指定できない問題」
12.33.18項「JAXRPCクライアントでマルチバイト・キャラクタを含むHTTP SOAPActionヘッダーがエンコードされない問題」
12.33.21項「jwscが変更されたため、サービス・エンドポイント・インタフェースに含まれるようになった@WebMethodアノテーションのないメソッド」
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サーバーに突然広がることがあります。 |
信頼できるメッセージングでは、クライアント証明書を使用した非同期レスポンスおよび肯定応答の送信はサポートされません。
非同期または信頼できるメッセージングを使用するWebサービスでは、非同期レスポンスや肯定応答などを送信する目的で、（受信側のサービスから送信側のサービスへの）新規接続の確立時に自動的にサーバーのSSL証明書が使用されます。
build.xmlのxmlcatalog要素では、エンティティの場所がローカル・ファイルシステムのファイルである必要があります。リモート・ファイル（http:など）やアーカイブ内のファイル（jar:など）を指定することはできません。
回避方法
必要であれば、かわりにカタログ・ファイルにエンティティとしてリモート要素を定義します。
カタログ・ファイルのpublic要素は、XMLカタログ機能の使用時にはサポートされません。JAX-WS EntityResolver実装への準拠もサポートされません。WLSでサポートされるのは、カタログ・ファイルでのsystem要素の定義のみです。
ローカルのxmlcatalog要素は、Antの制限のために適切に機能しません。
回避方法
Antのbuild.xmlファイルで、clientgen(wsdlc)タスクの前にローカル要素を定義するか（同じターゲットの場合）、すべてのターゲットの外部に要素を定義する必要があります。
WLS WebサービスのJAXRPCクライアントでは、マルチバイト・キャラクタを含むHTTP SOAPActionヘッダーがエンコードされませんが、WLSサーバーでは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サービスの信頼できるメッセージングを使用する場合にのみ発生することがわかっています。これらの例外は、ファイル・ストアからレコードを読み取る際に障害が発生したことを示しており、致命的なデータ・アクセス・エラーであるとみなされます。
これらのエラーの原因となっている問題は、将来のリリースで対処される予定です。
回避方法
この問題には、次の回避方法を使用できます。
ファイル・ストアの同期書込みポリシーをCache-Flushに変更します。
または
Direct-Write同期書込みポリシーを維持したまま、次のJavaシステム・プロパティをWebLogic Serverの起動スクリプトに追加します。
-Dweblogic.store.AvoidDirectIO=true
どちらの回避方法でも、次のJavaシステム・プロパティを使用して、ファイル・ストアのブロック・サイズを設定できます。
-Dweblogic.store.BlockSize=block-size
ファイル・ストア設定の変更により、パフォーマンスが多少低下する可能性がありますが、負荷のかかる環境でWebサービスの信頼できるメッセージングを適切に動作させるには必要な手順です。
これらの設定と追加オプションの重要な情報は、『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のすべてのメソッドを含む必要があると規定しています。
WLS 10.3.1では、jwsc（およびWebサービス・ランタイム）が、JAX-WS 2.1仕様に準拠して暗黙的なサービス・エンドポイント・インタフェース（および対応するサービス用のWSDL）を適切に生成するように変更されています。その結果、暗黙的に導出されるサービス・エンドポイント・インタフェースには、公開されるパブリックで非静的なJWSのすべてのメソッドが含まれます。一部の環境では、@WebMethodアノテーションのないメソッドは、サービス・エンドポイント・インタフェースおよび対応するサービスのWSDLに含めないという前提で、以前のjwscに依存するJWS実装を記述していることがあります。新しいjwscの動作では、そのようなメソッドでも、サービス・エンドポイント・インタフェースおよび対応するサービスのWSDLに含まれます。
回避方法
WLS 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)
この項では、次の問題および回避方法について説明します。
ビュー・クラスは、接続単位ベースでは設定できません。
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 Expressは、Oracleで使用できなくなりました。そのため、その説明はWebLogic Serverのドキュメントから削除されています。WebLogic Expressのすべての機能は、使用可能であり、他のOracle WebLogic Server製品でサポートされます。10.0以下のWebLogic Expressアプリケーションは、WebLogic Server 10.3.xにアップグレードできます。
