この章では、Oracle WebLogic Serverに関連する問題について説明します。内容は次のとおりです。
この項では、次の問題および回避方法について説明します。
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に置き換えます。
この項では、次の問題および回避方法について説明します。
キャッシュされた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で指定したユーザー名とパスワードを求められます。
WLSTは、希望するロケールを設定することで、ローカライズされたメッセージを使用して実行できます。WLSTツールを英語以外のロケールで実行する場合、次の問題を考慮する必要があります。
Windowsオペレーティング・システムで、DOSコマンド・ウィンドウのアクティブ・コード・ページがシステムのローカル(ANSI)・コード・ページと異なる場合、DOSコマンド・ウィンドウを通じてWLSTを起動する際に、-Dfile.encoding=<
DOS window's active code page
>
プロパティをWLSTプロセスに追加する必要があります。これにより、javaプロセスのデフォルト・キャラクタ・セットが変更されます。次に例を示します。
DOSウィンドウのアクティブ・コード・ページは850です。これは、WLSTコマンド・ウィンドウでchcp
コマンドを発行することで取得できます。
システムのローカル(ANSI)・コード・ページは1250です。システムのローカル・コード・ページは、WindowsレジストリのHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\NLS\CodePage\ACPキーの値を表示することで確認できます。標準のWindows編集ツール(メモ帳やワードパッドなど)で作成されるファイルは、この形式でエンコードされます。
この場合、次のようにWLSTを起動します。
set WLST_PROPERTIES="-Dfile.encoding=cp850"
$WL_HOME%\wlserver_10.3\common\bin\wlst.cmd
一部のMicrosoft Windowsプラットフォームでは、WebLogicのインストール・パスに空白が含まれると、WebLogic構成ツールのコマンド(wlst、config、pack、unpackなど)に障害が発生する可能性があります。この場合、コマンドは、空白の後のインストール・パス部分からクラスが導出される際に、java.lang.ClassNotFoundException
が発生して失敗する可能性があります。コマンドの失敗は、Windowsレジストリで短縮ファイル名の生成が無効化されている場合に発生します。
回避方法
空白を構成ツールで適切に処理するには、Windowsレジストリで短縮名の生成を有効化する必要があります。短縮名の生成を有効化するには、次の手順を実行します。
regedit
を実行します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystemフォルダに移動します。
NtfsDisable8dot3NameCreation
をダブルクリックし、その値を0
(ゼロ)に設定します。
再起動して変更を反映します。
WebLogic Serverの今回のリリースでは、コネクタ(リソース・アダプタ)に関する既知の問題は存在しません。
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操作は正常に完了しました
というメッセージが表示されることがあります。
回避方法
フィールド名の変更時にインスタンスの値がリセットされるのは通常の動作です。
同じマシン上の複数のサーバーを手動で同時に停止し、その後別のマシン上のサーバーを同様に停止した場合、停止したいずれかのサーバーを起動しようとすると、IPバインドが機能しない可能性があります。この問題は、netsh
によってIPアドレスが削除済であるとレポートされたにもかかわらず、元のマシンがそのIPアドレスを要求するために発生します。
回避方法
この問題を解決するには、ipconfigユーティリティまたはWindowsネットワーク構成を使用してネットワーク構成をチェックする必要があります。いずれかのツールにより、サーバーが停止したにもかかわらず、仮想または可変IPアドレスの1つがまだ構成されていることが判明する場合があります。その場合、Windowsネットワーク構成を使用してそのIPアドレスを削除できます。これを行うには、次の手順を実行します。
Windowsのコントロール パネルで、「ネットワーク接続」を選択します。
適切なネットワーク・インタフェースを選択して右クリックし、「プロパティ」を選択します。
「インターネット プロトコル(TCP/IP)」を選択し、「プロパティ」をクリックします。
「詳細設定」を選択します。
適切なIPアドレスを選択し、「削除」をクリックします。
この項では、次の問題および回避方法について説明します。
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ディレクトリを手動で作成します。
この項では、次の問題および回避方法について説明します。
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パブリッシュ/サブスクライブ・サーバーのチャネルを操作する完全な権限を持ちます。つまり、ローカル・クライアントは、チャネルを作成または削除することや、チャネルからイベントをパブリッシュまたはサブスクライブすることが可能です。
クラスタ環境では、あるサーバーのローカル・クライアントによりパブリッシュされたイベント・メッセージは、同じサーバーに接続されたサブスクライブ済クライアントによってのみ受信されます。これらのメッセージは、クラスタ内の別のサーバーに接続されたサブスクライブ済クライアントでは受信されません。
ローカル・クライアントにより任意のチャネルにパブリッシュされたイベント・メッセージには、そのチャネルに対して構成されたメッセージ・フィルタが適用されません。
この項では、次の問題および回避方法について説明します。
12.13.1項「WebLogic Serverがデフォルトの場所にインストールされていない場合に失敗するpackおよびunpackコマンド」
12.13.2項「WebLogic Serverホーム・ディレクトリをMiddlewareホーム・ディレクトリと同じにできない問題」
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
Oracle Bug#8554212に従って記載されています(ベースOracle Bug#8547939, 10.3.1, Windows)。
Middlewareホーム・ディレクトリは、WebLogic Serverホーム・ディレクトリとして使用できません。たとえば、Middlewareホーム・ディレクトリがC:\Oracle\Middlewareの場合、WebLogic Serverのホーム・ディレクトリとしてC:\Oracle\Middlewareを指定できません。指定すると、構成ウィザードやテンプレート・ビルダーなどの様々なWebLogic Serverツールが壊れる可能性があります。
回避方法
Middlewareホーム・ディレクトリ以外のディレクトリにWebLogic Serverをインストールします。たとえば、Middlewareホーム・ディレクトリがC:\Oracle\Middlewareの場合、C:\Oracle\Middleware\wlserverやC:\Oracle\wlserverにWebLogic Serverをインストールすれば安全です。この問題は、WebLogic Serverホーム・ディレクトリがMiddlewareホーム・ディレクトリと完全に同じである場合にのみ発生します。
この項では、次の問題および回避方法について説明します。
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にアップグレードします。Sun JVMのバージョン1.5以上、およびJRockit JVMのバージョンR27.6では、この問題は発生しませんが、更新されたJVMでもデタッチ処理を行うことをお薦めします。Sun JVMに関する問題の詳細は、次のURLを参照してください。
この項では、次の問題および回避方法について説明します。
デプロイメント・プランを使用して、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に関する既知の問題は存在しません。
この項では、次の問題および回避方法について説明します。
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
を参照してください。
この項では、次の問題および回避方法について説明します。
12.21.1項「@unharvestableとして明示的にマークされていないMBean属性がWLS管理コンソールで収集可能として表示される問題」
12.21.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.26.1項「適切なサーバー・セキュリティ・ディレクトリが存在する場合にのみ機能するStoreBootIdentityオプション」
12.26.2項「AllowUnencryptedNullCipherをTrueに設定しないとNULL暗号を必要とする接続が失敗する問題」
12.26.3項「SecurityServiceExceptionによりWLS Serverインスタンスで起動時に障害が発生する問題」
12.26.5項「InvalidParameterExceptionメッセージが生成されて管理コンソールに表示される問題」
12.26.6項「weblogic.xmlファイルが存在しない場合にweblogic.policyのデフォルトのWeb権限が機能しない問題」
-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およびアーティファクト・バインドを有効化します。オプションで、優先バインドを選択することもできます。
この項では、次の問題および回避方法について説明します。
JRockit上でWebLogic Serverを実行すると、OpenJPAのClassFileTranformerが機能しません。
回避方法
OpenJPAのエンハンサ・コンパイラを通じてビルド時に拡張を適用する代替方法を使用します。LoadTimeWeaverは使用しないでください。
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つのバージョンのアプリケーション間に非互換性問題が存在する場合、古いバージョンの正常なリタイアを実行します。アプリケーションおよびセッション表を監視し、古いバージョンを強制的にリタイアする適切なタイミングを見つけます。セッション表には、すべてのセッションが表示されます。表のすべてのセッションが、(タイムアウトや無効化のために)新規バージョンのアプリケーションのセッションのみになるまで減少したら、停止を強制して古いバージョンのアプリケーションを安全にリタイアできます。
session-timeout
がweb.xml
ファイルに構成されている場合、管理コンソールを使用してsession-timeout
を変更する操作は機能しません。
回避方法
デプロイメント・プランを使用してsession-timeout
設定を上書きします。
JSPXページをデプロイし、Internet Explorer 7(IE7)を使用してアクセスすると、ページ・コンテンツのかわりにXHTMLソースが表示されます。この問題は、normalモードとosjp.next
モードの両方で発生します。
回避方法
アプリケーション・ユーザーに、FirefoxまたはSafariを使用してアプリケーションにアクセスするよう指示します。
Scalar Vector Graphics(SVG)を使用してページをデプロイし、Internet Explorer 7(IE7)を使用してアクセスすると、ページのグラフィック・コンテンツのかわりにソースが表示されます。この問題は、normalモードとosjp.nextモードの両方で発生します。
回避方法
アプリケーション開発者は、各自のアプリケーションにおいてIE7でネイティブにサポートされないSVGグラフィックの使用を避ける必要があります。使用する場合は、次のような警告を追加してください。
All current browsers, with the exception of Internet Explorer, support SVG files.
Internet Explorer requires a plug-in to display SVG files. The plug-ins are available
for free, for example, the Adobe SVG Viewer at
http://www.adobe.com/svg/viewer/install/
.
この項では、次の問題および回避方法について説明します。
WLST loadProperties
コマンドでは、名前に「.」文字が含まれるプロパティのロードはサポートされません。たとえば、プロパティmyapp.db.default
がプロパティ・ファイルに存在する場合、WLSTでは次のように名前の例外がスローされます。
Problem invoking WLST - Traceback (innermost last): File "<iostream>", line 7, in ? File "<iostream>", line 4, in readCustomProperty NameError: myapp
これは、PythonおよびloadProperties
コマンドのシステム制限です。WLSTでは、変数の名前と値を読み取り、それらをPythonインタプリタの変数として設定します。Pythonインタプリタでは、ネームスペースのモジュール・スコープ、またはパッケージ名(あるいはその両方)を示すデリミタとして「.」を使用します。したがって、myapp.db.default.version=9i
はmyapp.db.default
パッケージ内にあると仮定されるため、プロパティ・ファイルで例外が発生します。そのようなパッケージは存在しません。
回避方法
ピリオドを含まない変数名を使用します。これにより、プロパティ・ファイルから変数をロードして、WLSTスクリプトで参照できます。ネームスペースを区切る場合、アンダースコア(_)や小文字/大文字などの別の文字を使用できます。
別の方法として、プロパティ・ファイルから変数を設定できます。スクリプトで変数を使用すると、それらの変数は実行時にプロパティ・ファイルの実際の値に置換されます。次に例を示します。
myapp.py var1=10 var2=20 import myapp print myapp.var1 10 print myapp.var2 20
この方法は、ネームスペースの1つのレベルで動作します(myapp.var1
、myapp.var2
)。ネームスペースと同じ名前を共有するトップレベル変数では動作しません(myapp=oracle
とmyapp.var1=10
など)。myapp
変数を設定すると、myapp
ネームスペースは上書きされます。
複数のレベルが必要な場合は、ディレクトリを使用してパッケージ・ネームスペースを定義します。次のようなvars.pyファイルを含むmyapp/db/defaultディレクトリを作成します。
var1=10 var2=20
その後、次のようにインポートします。
import myapp.db.default.vars print myapp.db.default.vars.var1 10
状況によっては、サブディレクトリに__init__.py
ファイルを追加する必要があります。パッケージの詳細は、次のPythonのドキュメントを参照してください。
Jython 2.2で作成されたデフォルトのcachedir
は、有効なディレクトリではありません。Jythonをweblogic.jar
から直接使用している場合、これによりWLSTでエラーが発生します。
回避方法
この問題には、次の2つの回避方法があります。
WLSTの起動時に、-Dpython.cachedir=<
valid_directory
>
パラメータを指定します。
weblogic.jar
に含まれる不完全なJythonを使用するかわりに、Jython 2.2.1を個別にインストールします。
この項では、次の問題について説明します。
現在のところ、mod_wl
およびmod_wl_ohs
ではコンテナ・レベルのフェイルオーバーのみがサポートされ、アプリケーション・レベルのフェイルオーバーはサポートされません。mod_wl_ohs
は、管理対象サーバーが起動されて実行されているかぎり、停止しているアプリケーションにリクエストをルーティングし続けます。クラスタ環境では、アプリケーションが停止していても、元のセッションが開始されたコンテナへのリクエスト送信が継続され、通常はHTTPエラー404が発生します。
この項では、次の問題および回避方法について説明します。
12.32.8項「JAX-RPCスタイルのJavaBeansに相当するJavaメソッド引数またはリターン・パラメータの処理」
12.32.9項「JWSコールバックで2次元のXMLオブジェクトを使用する場合に発生するIllegalArgumentException」
12.32.13項「Webサービス固有のリソースなしで作成されたドメインに対して生成されるサーバー・ログのINFOメッセージ」
12.32.14項「クライアント証明書を使用した非同期レスポンスおよび肯定応答の送信が信頼できるメッセージングでサポートされない問題」
12.32.15項「xmlcatalog要素のエンティティにリモート・ファイルやアーカイブ内のファイルを指定できない問題」
12.32.18項「JAXRPCクライアントでマルチバイト・キャラクタを含むHTTP SOAPActionヘッダーがエンコードされない問題」
12.32.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にアップグレードできます。