リリース・ノート
リリース10.1.3
部品番号: B28635-01
2006年5月
Oracle JDeveloper 10gは、標準ベースのSOAアプリケーション向けの完全な統合開発環境です。 Oracle JDeveloper 10gリリース3（10.1.3）には、多数の新機能が追加されています。 たとえば、新しいルック・アンド・フィール、豊富なリファクタ・オプションにより大幅に改善されたコーディング環境、最新のJava標準（J2SE 5.0、J2EE 1.4、EJB 3.0）のサポートおよびビジュアルJSF開発などです。 視覚的で宣言的なアプローチと改善されたOracle Application Development Framework（Oracle ADF）の連携により、アプリケーション開発が簡素化され、通常のコーディング・タスクが削減されます。 これにより、どのようなテクノロジ・スタックや配布先プラットフォームを選択した場合にも、開発者の生産性が飛躍的に向上します。
ダウンロード可能な追加機能は、「ヘルプ」→「更新の確認」を使用してオンラインで確認してください。
このドキュメントの発行時点で未入手の追加情報は、『Oracle JDeveloper 10g Release Notes Addendum』を参照してください。 JDeveloperの詳細と技術資料は、次のサイトにアクセスしてください。
Linux上でリリース9.0.3xまたは9.0.4xからリリース10.1.3に移行する場合、デバッガの接続試行の設定を20以上に増やす必要があります。 これが特に必要になるのは、XSLTデバッグが実行されるXMLプロジェクトを移行する場合です。 リリース9.0.3または9.0.4ではXSLTデバッグ機能を使用できなかったため、リリース10.1.3に移行したプロジェクトは接続試行の設定値が小さすぎて、追加のXSLTデバッグ・フレームワークが原因でデバッガはローカル・プロセスに接続できません。
XML関連の各ウィザード（「XML文書」、「XMLスキーマからXMLドキュメント」、「XMLスキーマ」、「XQuery」および「XSLスタイル・シート」）により生成されたXMLファイルは、以前のリリースではデフォルトで public_html ディレクトリに作成されていました。
このリリースではXMLファイルは、デフォルトでプロジェクトのルート・ディレクトリに作成されるように変更されています。
プロジェクトを移行すると、既存のXMLファイルは public_html ディレクトリに残りますが、新規のXMLファイルはデフォルトで新しい場所に作成されます。
コード・インサイトには、ファイルがコンパイルされるまでに #sql で宣言されていた変数についてエラーが表示されます。
SQLJトランスレータがSQLJとクラス・ファイルの間にあるため、SQLJからJavaファイルが作成されるまで、プロジェクト内の変数は認識されません。
Javaファイルの作成後は、使用される変数が予期したとおりに認識されます。
この問題が発生するのは、バージョニングされていないファイルを参照する新規プロジェクトを作成する場合です。 「CVSへのインポート」ウィザードで「モジュール・チェックアウトの実行」オプションを選択してプロジェクトをインポートする場合、JDeveloperのナビゲータに表示されるのはプロジェクトのヘッダーのみで、内容は表示されません。 回避策は、ナビゲータ・ツールバーの「リフレッシュ」ボタンをクリックすることです。 これにより、プロジェクトの内容（ファイル・ノード）がナビゲータに表示されます。
バリアント（"fr_FR_EURO"など）やJDBCではサポート対象外である一部のロケール（後述）を含んだロケールで、JDBC 10.1.0.5を介してOracle Databaseに接続しようとすると、JDBCが SQLException をスローします。
サポート対象外のロケールは、次のとおりです。
Java 5.0の「Supported Locales」（http://java.sun.com/j2se/1.5.0/docs/guide/intl/locale.doc.html
- 日本語版）にリストされていないロケール（ab_CD、fr_FR_EURO、it_IT_EUROなど）。
また、次のロケールはJava 5.0ではサポート対象ですが、JDBCではサポート対象外です。
th_TH_TH - タイ語（タイ、TH）be - ベラルーシ語be_BY - ベラルーシ語（ベラルーシ）es_AR - スペイン語（アルゼンチン）es_BO - スペイン語（ボリビア）es_DO - スペイン語（ドミニカ共和国）es_EC - スペイン語（エクアドル）es_HN - スペイン語（ホンジュラス）es_PY - スペイン語（パラグアイ）es_UY - スペイン語（ウルグアイ）mk - マケドニア語mk_MK - マケドニア語（マケドニア）no_NO_NY - ノルウェー語（ノルウェー、ニーノシク）sq - アルバニア語sq_AL - アルバニア語（アルバニア）回避策は、Javaのデフォルトのロケール設定を更新することです。 次に例を示します。
es_AR の場合は、次のように es （スペイン語）をデフォルト・ロケールに設定します。
Locale.setDefault(new Locale("Es"));fr_FR_EURO などのバリアント・コードがある場合は、バリアント・コード（EURO）を削除してデフォルトを次のように設定します。
Locale.setDefault(new Locale("fr", "FR"));Locale.setDefault(Locale.ENGLISH);ランタイムJavaのロケールは、次のように入力して確認できます。
System.out.println(Locale.getDefault().toString()) LinuxユーザーがJDeveloperでドラッグ・アンド・ドロップすると、スローされた NullPointerException がコンソールに表示されることがあります。
これは、JDKの不具合によるものであり、例外が発生しても問題はありません。
JDKの不具合の詳細: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6182905
Windowsプラットフォーム上では、特定の場合にJDeveloperで「編集」→「コピー」操作を実行した後でクリップボードが破損することがあります。
原因は、ディスク上のソース・ディレクトリと、そのソース・ディレクトリを指すJDeveloperのプロジェクト・プロパティが一致しないことです。
たとえば、ディスク上のディレクトリが Src でも、JDeveloperのプロジェクトが src を指していると、「コピー」→「貼付け」操作に問題が発生することがあります。
回避策は、JDeveloperプロジェクトのプロパティを、問題のディレクトリを指すように変更することです（「ツール」→「プロジェクト・プロパティ」→「プロジェクト・コンテンツ」）。
これにより、ディスク上の対応するディレクトリのパス名と大/小文字区別が同じになります。
または、ディスク上のディレクトリ名を、プロジェクトのプロパティにあわせて変更する方法もあります。
EARのインポート時にソース・パスを指定していれば、コンソールに NullPointerException が表示されてもインポートは成功します。
JDeveloper 10gでWebアプリケーションを実行またはデバッグする場合は、埋込みコンテナを停止せずにアプリケーションを再実行または再デバッグできます。 この場合、埋込みOC4Jはウォーム・リスタート・モードになります。 これにより、実行またはデバッグ・サイクルは迅速になりますが、アプリケーションの埋込みOC4Jサーバーに対して、このウォーム・リスタートを実行した後に、既知の問題が原因で次の例外が断続的に表示されることがあります。
05/11/23 15:59:11 java.lang.IllegalStateException: ClassLoader "SomeLibraryName:X.Y.Z"
(from <shared-library> in .../jdev/system/oracle.j2ee.10.1.3.35.74/embedded-oc4j/config/server.xml):
This loader has been closed and should not be in use.
この警告が発生するのは、JDeveloper 10gでOC4Jがウォーム・リスタート・モードになっている場合のみで、無視しても問題はありません。
JDeveloper 10.1.2から10.1.3にプロジェクトを移行する場合、ワークスペースに定義されていたデータ・ソースは保持されます。 アプリケーションを実行する前にIDEのデータベース接続を再作成する必要はありません。 ただし、IDE接続を作成するように選択した場合は、競合を回避するために、まず同じ名前の移行済データ・ソースを削除する必要があります。 そのためには、「埋込みOC4Jサーバーの設定」→「現在のワークスペース」→「データソース」の順にナビゲートして子ノードを削除します。
Oracle Application Server 10.1.2へアプリケーションをデプロイするOracle DCMクライアントでは、パスに空白を含んだEARファイルを処理できず、デプロイ・コマンドが無効として解釈されます。
JDeveloperでは、この問題に2つの回避策があります（どちらの場合も、EARファイルが名前に空白を含んでいないディレクトリに書き込まれます）。 次のいずれかを実行できます。
埋込みOC4Jサーバーを使用してセッション・フェイルオーバーをテストする場合は、orion-web.xml ディスクリプタを作成し、 persistence-path を application-deployments ディレクトリ以外の場所に変更します。
次に例を示します。
persistence-path="c:/shared/persistence/App1"
また、「ツール」→「埋込みOC4Jサーバーの設定」→「シャットダウン」を使用して、埋込みサーバーを正常にシャットダウンするようにJDeveloperを変更します。 これにより、永続データはサーバーのシャットダウン前に確実にディスクに書き出されます。
埋込みOC4Jサーバーでアプリケーションを実行する場合は、ユーザーが使用中のJDKのバージョンを認識している必要があります。 これは、JDKのバージョン間で切り替えて、異なるJDKバージョンを使用して複数のJDeveloperプロジェクトで作業する場合に特に必要です。
デフォルトでは、埋込みサーバーはJDK 1.5で起動します。 すでに埋込みOC4JサーバーをJDK 1.5で実行した後に、JDK 1.4ベースのプロジェクト（「プロジェクト・プロパティ」→「ライブラリ」→「J2SEバージョン」で構成）を実行するには、『Oracle Containers for J2EE 構成および管理ガイド』の第4章（「OC4Jランタイム構成」）に記載されている手順にユーザーが従う必要があります。
bc4j/jlib/dc-adapters.jarbc4j/jlib/adf-connections.jarj2ee/home/lib/http_client.jarwebservices/lib/wsdl.jarwebservices/lib/orajaxr.jarwebservices/lib/orawsrm.jarwebservices/lib/wsclient.jarwebservices/lib/orasaaj.jarwebservices/lib/xsdlib.jarwebservices/lib/mdds.jarjlib/osdt_core.jarjlib/osdt_cert.jarjlib/osdt_xmlsec.jarjlib/osdt_wss.jarjlib/osdt_saml.jarjlib/ojpse.jarjlib/oraclepki.jarwebservices/lib/wssecurity.jarwebservices/lib/orawsdl.jarj2ee/home/jazncore.jar次のアプリケーションは、Oracle Application Server以外のアプリケーション・サーバーへのデプロイはサポートされません。
大きいEARファイルをWebLogicにデプロイする際に SocketException が発生する場合は、JDeveloperではなくコンソールを使用してEARをデプロイします。
ドメインまたはサーバーに組み込まれている製品によっては、製品のインストール・パスが長すぎる場合や、サーバーのクラスパスに多数のエントリが追加されている場合に、 startWebLogic.cmd スクリプトから Input Line Too Long というエラーが戻されることがあります。
これは、Windowsコマンド・プロセッサの制限事項です。
名前が18文字以内のインストール・ディレクトリは、プラットフォーム・ドメインのスクリプト（WebLogic Server、WebLogic PortalおよびWebLogic IntegrationのCLASSPATHエントリ）を変更しなくても動作します。
名前が18文字以内のディレクトリにインストールします。
JARを結合するか、1つのJARファイルに Manifest Class-Path エントリを使用して、余分なサーバークラスパスのエントリ数を減らします。
<jdev_home>/BC4J/lib にコピーします。<JdevUserHome>\<Application>\<Application>-oc4j-app.xml を編集します。
import-shared-libraries タグを変更し、ADFの汎用ドメイン・ライブラリ定義を挿入します。
Oracleドメイン・ライブラリは、外部データ・ソースの使用時には不要なため、削除します。
デフォルトでグローバルな application.xml から継承されます。
<imported-shared-libraries> <import-shared-library name="adf.generic.domain"/> <remove-inherited name="adf.oracle.domain"/> </imported-shared-libraries>
<oc4j_home>/BC4J/lib にコピーします。META-INF フォルダにある orion-application.xml を編集します。
import-shared-libraries タグを変更し、次のライブラリ定義を挿入します。
adf.oracle.domain のエントリが存在する場合は、そのエントリを削除します。
<imported-shared-libraries> <import-shared-library name="adf.generic.domain"/> </imported-shared-libraries>
スタンドアロンOC4JにJDeveloperからアプリケーションをデプロイした後で、埋込みOC4Jでアプリケーションを再実行すると、次のエラー・メッセージが表示されることがあります。
JBO-29000: Unexpected exception caught:これには次の2つの回避策があります。
src\META-INF および classes\META-INF 内の orion-application.xml を削除します。または
<jazn location="./jazn-data.xml" provider="XML"/> を src\META-INF\orion-application.xml に追加し、jdev\system\oracle.j2ee.10.1.3.##.$$\embedded-oc4j\config\system-jazn-data.xml を src\META-INF\jazn-data.xml にコピーします。JDeveloper 10.1.3により生成された data-sources.xml によって定義されるデータソースを用いるアプリケーションを Oracle Application Server 10.1.2 にデプロイするとエラーが発生することがあります。
例えば、データベースに接続するEJBアプリケーションの場合は注意が必要です。
これは、Oracle Application Server 10.1.3ではOracle Application Server 10.1.2とは異なるパスワード・インダイレクションの解析法方を取っていることに起因します。
このようなアプリケーションをOracle Application Server 10.1.2にデプロイできるように、Oracle Application Server 10.1.2のパッチが提供される
Oracle Application Server 10.1.2にデプロイされているJDeveloper 10.1.3を使用して data-sources.xml を開発し、そこに定義されている接続を使用するアプリケーションをデプロイすると、デプロイ・エラーになることに注意してください。
その一例が、データベースへの接続にEJBを使用するアプリケーションです。
これは、Oracle Application Server 10.1.3とOracle Application Server 10.1.2では、パスワード・インダイレクションの解析方法に違いがあるためです。
この種のアプリケーションがデプロイできるように、Oracle Application Server 10.1.2のパッチが提供される予定です。
「サード・パーティJDBCドライバ」または「Oracle Lite」接続タイプを使用してOracle Liteへの接続を作成するには、テキスト・エディタで <jdev_home>\jdev\bin\jdev.conf を開き、Oracle10g Lite Settingsセクションを非コメント化し、Oracle Liteインストールを指すようにディレクトリを変更する必要があります。
このように変更しないと、接続に失敗します。
SQL*Plusを使用するなど、JDeveloper外部でデータベースを変更した場合、JDeveloperではデータベース・オブジェクトのキャッシュがリフレッシュされません。 接続ナビゲータで接続名のノードを選択し、「リフレッシュ」ボタンをクリックして、接続を手動でリフレッシュする必要があります。
明示的なサポート対象ではない汎用JDBCデータベースへの接続を作成すると、接続ナビゲータで参照して、表をJDeveloperにインポートし、オフライン・データベース機能を使用できます。 ただし、列を参照すると、等価のJDBC型のかわりにネイティブのデータ型が表示されます。 長さ、リビジョンおよびスケールなどのプロパティが欠落した不完全なデータ型の場合もあります。
JDeveloperチームでは、正しいSQLが生成されるように、「オフライン・データベース・オブジェクトからSQLを生成」ウィザードを使用してデータベースに生成または調整することをお薦めします。
データベースに直接生成できない場合は、変更内容の適用後にデータベース・スキーマをオフラインで再度インポートしてから、他のオフライン変更を続行する必要があります。
バージョン3.4.68より前のDataDirectドライバを使用して INTERVAL型の列を含んだ表をインポートするか、接続ナビゲータで表示すると、データ型は空となります。
3.4.68または3.5.17以上のバージョンを使用している場合、表はインポートされず、接続ナビゲータでは参照できません。
UMLアーチファクトを含むナビゲータ・パッケージの場合は、「アプリケーション・ナビゲータ」のコンテキスト・メニューから「リファクタ」サブメニューを表示できます。 ただし、パッケージをリファクタしてもUMLアーチファクトはリファクタされませんが、Java型や他の型は予期したとおりにリファクタされます。
JAWSスクリーン・リーダーを使用している場合は、現在Javaクラス図のポップアップ・コード・エディタにアクセスできません。 回避策は、ダイアグラム上のJava要素には「編集」のかわりに「ソースへ移動」を使用することです。 これにより、通常のコード・エディタが起動します。
PL/SQLオブジェクトにコロンを含む名前を付けると、正常に動作しなくなります。 引用符で囲まれていない名前はコロンが無効であるため、これは引用符で囲まれた名前にのみ該当します。
データベース・ダイアグラムでは、一部のビジュアル・プロパティが機能しません。 この種のビジュアル・プロパティ（表やビューの「列のデータ型の表示」など）は、選択または選択を解除しても無効です。
新規に作成した外部キーのカーディナリティが正しく表示されないことがあります。 ダイアグラムを閉じてから再び開くと、正しい位置に表示されます。
ユースケースがユースケース・ダイアグラムのシステム境界内に予期したとおり表示されない場合は、そのユースケースのスコープが破損していることが原因と思われます。 基礎となるユースケース文書を開き、スコープ・セクションで有効な場所を参照していることを確認してください。 その後、JDeveloperを再起動します。
本リリースのJDeveloper 10.1.3には、UIXに対する設計時サポートが存在しません。 このサポートは、UIXページをOracle ADF Facesページに変換するためのユーティリティとともに、運用開始後に拡張機能として使用可能になります。 Oracle ADF FacesはUIXの大幅な進化版であり、新しいJSF標準に準拠しています。 ほとんどのUIXコンポーネントは移行ユーティリティで処理されますが、コードを移行するには手動による作業が必要です。
以前のリリースのJDeveloperサーブレット・プロジェクトをリリース10.1.3に移行する場合は、サーブレットごとにサーブレット・マッピング・タグを web.xml に手動で追加する必要があります。
MyFaces 1.0.9のhtmlタグ・ライブラリの outputLabel では、for 属性が必須としてマークされています。
JSF仕様とリファレンス実装では、その必要はありません。
この問題を回避するには、属性を1つ指定します。
この問題は、J2EEエディションとStudioエディションの両方に該当します。
JDeveloper 10.1.3に付属するStruts（Struts 1.1）とは異なるバージョンのStruts（Struts 1.2.4など）を使用する場合、他のバージョンのダウンロードには TilesServlet が含まれていないことがあるため、デフォルトで TilesServlet を使用できないことがあります。
Strutsアプリケーション用のプロジェクトにTiles定義ファイルを追加し、アプリケーションの web.xml ファイルを調べようとすると、 org.apache.struts.tiles.TilesServlet クラスが見つからないことを示す警告が表示されます。
回避策は、クラスパスに org.apache.struts.tiles.TilesServlet を指定して新規ライブラリを作成し、この新規ライブラリをプロジェクトに追加します。
付属のStrutsとは異なるバージョンを使用する場合の詳細は、次のURLにあるOTNの「Oracle JDeveloper - How-To」を参照してください。
http://www.oracle.com/technology/products/jdev/howtos/index.html
faces-config.xml の概要エディタの「Managed Bean」ページでは、NULLに設定されていたmanaged-propertyまたはmap-entryの値を設定できません。
回避策は、まずソース・エディタまたは「ソース構造」パネルから <null-value/> タグを削除することです。
OC4JでEJB2 CMPを使用すると、 orion-ejb-jar.xml に指定されているデータ・ソースおよびログイン情報がCMPのデプロイに使用されます。
orion-ejb-jar 内の情報は、アプリケーション・ナビゲータからプロパティ・エディタを起動して編集できます。
デプロイ・データベースの接続情報はTopLinkマップで編集可能ですが、TopLinkに対して指定した情報はデプロイ時に無視されます。
TopLink POJOオブジェクト用にセッションBeanファサードを作成する場合は、リモート・インタフェースを介してSessionBeanファサードから戻されるTopLink POJOオブジェクトごとに java.io.Serializable を実装する必要があります。
通常、この作業が必要になるのは、EJBクライアントをADF Swingを使用して実装している場合、またはEJBセッションBeanがクライアントとは異なるアプリケーション・サーバーで実行している場合です。
次の例外を取得した場合に java.io.Serializable を実装する必要があるとも言えます。
com.evermind.reflect.UndeclaredExceptionTypeException:
/oracle.oc4j.rmi.OracleRemoteException/
at __Proxy1.[Your Class Name Here] (Unknown Source) 回避策は、各POJOオブジェクトを手動で編集して java.io.Serializable を実装することです。
今後のリリースでは、この手動手順は不要になる予定です。
TopLinkマップまたはTopLinkセッションの構成ファイルにダブルバイト・キャラクタが含まれている場合は、POJOを生成すると例外が発生します。
tlmap.xml ファイルと sessions.xml ファイルの名前にダブルバイト・キャラクタが含まれていないことを確認してください。
SQL Server固有の順序付けを構成できない場合は、別のデータベース・プラットフォーム（Oracle）を選択してネイティブ順序付けを有効化します。 その後、設定をSQL Serverに戻す必要があります。
デプロイメント・ディスクリプタの場所は、リリース9.0.5のTopLink ADFアプリケーションをリリース10.1.3に移行すると変更されます。
移行後のアプリケーションをリリース10.1.3で動作させるには、DeploymentDescriptorFileNameプロパティを META-INF\toplink-deployment-descriptor.xml から META-INF\package\toplink-deployment-descriptor.xml に変更する必要があります。
TopLink Mapping Editorでディスクリプタ（マップされたクラス）にアドバンスト・プロパティ「ロード後」を追加するためのオプションが用意されています。 「ロード後」のプロパティ・エディタで、TopLinkのAfter Loadメソッドのシグネチャ要件を満たすメソッドを含んだクラスを指定できます。 これらのメソッドが、「Staticメソッド」の選択に表示されないことがあります。
有効なAfter Loadメソッドを含むクラスを指定した後、指定のクラスをJavaソース・エディタで開き、空白または任意の文字を2つ入力します。 これにより、TopLinkマッピング・モデルのクラス・メタデータが更新され、そのクラスに定義されているAfter Loadメソッドが「Staticメソッド」の選択に表示されます。
リリース10.1.3のTopLinkエディタでは、TopLinkマッピングのメタデータ・モデルに必要な場合にクラス・メタデータを遅延ロードします。 これにより、「ロード後」プロパティで指定したクラスがマッピング・モデルで参照されていないと、その属性とメソッドが移入されないことがあります。 この問題の解決策は、After Loadメソッドで指定したクラスが移入されない場合、完全移入を強制的に実行させることです。
TopLink POJOまたはEJB 3.0エンティティをリモート（コンテナ外部）で使用すると、エンティティは関連エンティティからの情報にアクセスできません。
解決策は、クライアントに送信する前に、必要なエンティティ・データをすべて事前ロードしておくことです。
たとえば、Departments および Employees という2つのエンティティがある場合は、Employees のコレクションを反復してデータをロードする必要があります。
次の例は、同じコンテナにエンティティ（またはPOJO）を持つセッションBeanについてデフォルトで生成される findAllDept()メソッドのコードを示しています。
public List<Dept> findAllDept() {
Session session = getSessionFactory().acquireSession();
List<Dept> results = (List<Dept>)session.executeQuery("findAllDept", Dept.class);session.release();
return results;
}各 Department の Employees コレクション（empCollection フィールド）を事前にロードするには、このコードを次のように変更します。
public List<Dept> findAllDept() {
Session session = getSessionFactory().acquireSession();
List<Dept> results = (List<Dept>)session.executeQuery("findAllDept", Dept.class);session.release();
// Eagerly load all Emp's associated with each Dept so they can be
// accessed by a remote client.
for (Dept dept : results) {
dept.getEmpCollection().size();
}
return results;
}このコードでは、Department ごとに関連する Employees がロードされます。
さらに各 Employee に関連する Addressをロードするには、次のように変更します。
// Eagerly load all Emp's associated with each Dept so they can be
// accessed by a remote client. Also, for each Emp, eagerly load
// its associated Address
for (Dept dept : results) {
for (Emp emp: dept.getEmpCollection()) {
emp.getAddress();
}
}このリリースでは、EJB 3.0のBeanのモデリングに対するサポートはありません。
JDeveloperリリース10.1.3のEJBデータ・コントロールでは、interMediaのBLOB/CLOB型がサポートされません。 これらのデータ型を持つ列は、ベースCMP/POJOにあってもデータ・コントロール・パレットに表示されません。
EJBリレーションシップに java.util.Set を使用すると、EJBをOC4Jにデプロイできません。
回避策は、java.util.Collection または java.util.List を使用することです。
EJBデータ・コントロール・ウィザード（リリース10.1.3の新機能）を使用して、インポートしたEJB JARファイルからADFデータ・コントロールを作成すると、埋込みOC4Jサーバーに対して実行できません。 ただし、リモート・サーバーを使用してアプリケーションを実行することはできます。
Windowsでは、長い名前を持つWebサービスがJavaメソッドを公開し、そのJavaメソッドが同じく長い名前を持つJavaBeansを使用する場合、埋込みOC4Jサーバー上の結合ファイルへのパスが長すぎて認識できないことがあります。 このため、実行時にサービスからJavaBeans用のシリアライザを登録できないことがレポートされます。
回避策は次のとおりです。
D:\JDevEmbeddedServer\application_deploymentsEJB 3.0のWebサービスを外部OC4JにデプロイしてOracle Enterprise Managerからテストしようとした場合、「起動」ボタンが表示されないことがあります。 回避策はありません。
複数のポートを使用するWebサービスへのプロキシを作成すると、そのWebサービスには無効なエンドポイントを持つプロキシが生成されることがあります。 回避策は、WSDLを調べて適切なエンドポイントURLを見つけ、それを生成されたプロキシ・クラスに貼り付けることです。
1つのプロジェクトに同じマッピング・ファイルを使用するWebサービスを複数作成すると、ランタイム例外が戻されます。 回避策は次のとおりです。
serviceName 引数値を第2のWebサービスに対して指定します。EJB 3.0から作成されたWebサービスは、埋込みOC4Jサーバーでは実行できませんが、外部OC4Jにはデプロイできます。
このリリースでは、BC4Jフェイルオーバー・モードのデフォルトが false に切り替えられています。
これは、フェイルオーバーが提供するサービスの品質を必要としないデフォルトのBC4Jアプリケーションのパフォーマンスを強化するために行われた変更です。
フェイルオーバーを必要とする既存のアプリケーションの場合は、フェイルオーバーを再有効化できます。 そのためには、「プーリングおよびスケーラビリティ」タブ・ページで「アプリケーション・モジュール」構成を編集してフェイルオーバーを有効化します。
ADF 10.1.3には、アプリケーションの状態を管理するために新しいStateManager状態リポジトリが導入されています。
これにより、ADFではWebリクエストごとにブラウザのCookieとしてBC4Jの受動化IDのような状態を書き込む必要がなくなります。
ただし、この追加により、BC4Jアプリケーションについて以前の実装で提供されていたのと同じサービス品質を必要とする場合、アプリケーション開発者は特定のプロビジョンを行う必要があります。
アプリケーションで状態をディスクに保存する必要がある場合は、ある程度の構成を実行する必要がありますが、 jbo.dofailover=true の場合でも、この構成をデフォルトで実行できないことがあります。
n個のノードに障害が発生した場合でもBC4Jの状態が確実に管理されるようにするには、アプリケーション開発者はStateManagerが状態をディスクに保存するように構成されていることを確認する必要があります。 WebベースのADFアプリケーション用のデフォルトのStateManagerリポジトリは、HttpSessionです。 したがって、コンテナで永続HttpSessionがサポートされる場合、アプリケーション開発者に必要なのはこの機能を有効化することのみです。
コンテナでHttpSessionの保持がサポートされない場合や、HttpSessionの保持が実現可能でない場合、アプリケーション開発者は別のStateManagerリポジトリを使用するように選択できます。 ADFにはJavaCache* StateManagerリポジトリも用意されており、このリポジトリではデフォルトで永続的な状態管理がサポートされます。 JavaCache StateManagerリポジトリを使用するには、コマンドラインで次のJavaシステム・プロパティを定義します。
oracle.adf.share.statemanager.class_name=oracle.adf.share.statemanager.javacache.StateManagerImpl注意: JavaCacheオプションは、データ・バインディング（リリース10.1.2以降でのみ可能）を使用して生成されたアプリケーションにのみ適用されます。 それ以前のアプリケーション（9.0.xベースなど）の場合、このオプションは使用できません。 ただし、付加的な措置として、アプリケーション・モジュールごとにブラウザCookieを記述するという従来の方法も使用可能で、「アプリケーション・モジュール」の構成設定jbo.ampool.writecookietoclient=trueを使用して有効化できます。 この代替策には明らかに望ましくない副次効果（ブラウザCookieの上限に達するリスクの上昇）があり、あくまでも一時的な措置です。
この項では、ADFアプリケーションに関してチームで作業しており、1人が同じプロジェクトを変更した間に他のチーム・メンバーが変更内容をソース・コントロールにコミットしていた場合に、マージ競合が発生する可能性を最小限に抑えるためのヒントを示します。
「ツール」→「設定」の「ビジネス・コンポーネント」→「一般」パネルで、「クラスパスへのパッケージXMLファイルのコピー」というプロパティの選択を解除します。 これにより、新規のADF Business Componentsプロジェクトに使用されるデフォルトの設定値が設定されます。 このプロパティの選択を解除すると、ADFの設計時にはパッケージ内にあるコンポーネントの追跡にパッケージXMLファイルが使用されなくなるため、パッケージXMLファイルはチーム・メンバー間のマージ競合点にならなくなります。 既存のプロジェクトの場合も、「プロジェクト・プロパティ」の「ビジネス・コンポーネント」→「オプション」パネルで、このプロパティを必要に応じて編集し、選択を解除できます。
プロジェクトに新規のADF Business Componentsを追加した場合など、他のチーム・メンバーが行った変更が原因でプロジェクト・ファイルにマージ競合が発生すると、一時的にアプリケーション・ナビゲータにプロジェクト・コンテンツを表示できなくなります。
マージ競合を解決するには、「表示」→「システム・ナビゲータ」を使用してシステム・ナビゲータを表示し、プロジェクトのコンテキスト・メニューで「競合の解決」オプションを選択します。
JPRファイルの owner map部分の書式は、ソース・コントロール・システムでコンテンツを自動的にマージし、結果的に手動によるマージの解決作業を簡素化できる可能性を高めるように最適化されています。
ADF Business ComponentsのXMLメタデータ・ファイルにあるマージ競合を解決した後、メモリー内のメタデータがあらためて再読取りされるように、ADF Business Componentを含むプロジェクトを選択し、メイン・メニューから「ファイル」→「閉じる」を選択して、アプリケーション・ナビゲータでプロジェクトを開きなおすことをお薦めします。 これにより、マージされた最新メタデータが確実に表示されます。
ADF 10.1.3では、ビュー・オブジェクトに複数のビュー基準を使用できます。
この機能のサポートと、メモリー内の行のフィルタリングをさらに厳密にプログラムで制御するための関連機能のサポート導入の一環として、ブール・フラグを受け入れる ViewObjectImpl.getViewCriteriaWhereClause() について、新規のオーバーロードを導入する必要がありました。
引数を取らない以前のメソッドはコールされなくなりました。
そのため、リリース10.1.2以前に getViewCriteriaWhereClause() をオーバーライドしていた場合は、次の提案に従ってコードをリリース10.1.3に移行する必要があります。
次のコードから始めたとします。
public String getViewCriteriaClause() {
// your-code here
}VOのVCが1つのみで、VCが常にデータベース問合せに使用される（メモリー内のフィルタリングには使用されない）場合は、単に、オーバーライドした既存のメソッドを、ブール・パラメータを持つように変更できます。
これにより、新規メソッドのシグネチャのオーバーライドとなります。
ただし、複数のビュー基準機能やメモリー内フィルタリングに対するビュー基準のサポートを利用する場合は、ViewObjectImpl で次のメソッドを使用するように既存のオーバーライド・コードを拡張できます。
public ViewCriteria[] getApplyViewCriterias(int criteriaMode) データベース問合せのビュー基準を取得する場合は、oracle.jbo.ViewCriteria.CRITERIA_MODE_QUERYを使用してコールします。
メモリー内フィルタリングのビュー基準を取得するには、ViewCriteria.CRITERIA_MODE_CACHEフラグを使用してコールします。
メモリー内フィルタリングの場合、戻されるWHERE句にはデータベース列名ではなく、ビュー・オブジェクトの属性名を使用する必要があることに注意してください。 逆に、データベース問合せのWHERE句には、データベース列名を使用する必要があります。
Bug#4932766（リリース10.1.3でoracle.jbo.domain.Raw型の主キーを持つエンティティ・オブジェクトを検索する際の回帰）に対処するために、Rawドメインの動作が変更されました。
このリリースでは、Rawドメインの String コンストラクタは、文字列が行値の16進ダンプであることを期待します。
たとえば、バイト配列の長さが3で文字A、BおよびCを含む行が必要な場合は、次のようにコールする必要があります。
new Raw("414243");// 0x41 is hex ascii code for 'A', etc.
既存のコードがRawドメインの文字列コンストラクタの以前の動作に依存する場合は、そのコードを次のように変更できます。
new Raw("ABC")new Raw("ABC".getBytes());これにより、以前のセマンティックが保持されます。
再利用可能なコンポーネント・ライブラリを共有するため、ADF Business Componentsのインポート機能を使用して大型のエンタープライズ・アプリケーションをビルドした多数のユーザーの経験に基づいて、インポート済のコンポーネントはインポート対象プロジェクトのナビゲータに表示されなくなりました。 インポート済のコンポーネントは、常にADF Business Componentsのウィザードとエディタの「使用可能なコンポーネント」リストにあるものとして表示されますが、「システム・ナビゲータ」や「アプリケーション・ナビゲータ」には表示されません。 これには主に2つのメリットがあります。
これは優れた改良ですが小さなデメリットが1つあり、ADF BCコンポーネントのインポート済パッケージへの参照を完全に削除する必要が生じた場合に、コンポーネントのパッケージをアンインポートする特定の操作を追加するまでは、インポート対象プロジェクトの *.jpx ファイル内で対応するエントリを削除する必要があります。
次の手順に従います。
*.xmlコンポーネント・メタデータ・ファイル内で検索すると、そのパッケージ内のコンポーネントに依存する可能性のある候補コンポーネントを識別できます。./src）で YourProjectName.jpx ファイルを検索します。YourProjectName.jpxファイルを開き、インポート済パッケージに関連する <Containee> 要素を削除します。
_locationURL というプロパティを持つネストした <DesignTime> 要素があり、その内容は次のとおりです。
<Containee
Name="yourpackagename"
FullName="com.yourcompany.yourapp.yourpackagename.yourpackagename"
ObjectType="JboPackage">
<DesignTime>
<Attr Name="_LocationURL" Value="<SomePathHereTo>/YourLibraryName.jar" />
</DesignTime>
</Containee><Containee> および </Containee> タグとその間にあるすべてのテキストを削除する必要があります。ADF設計時には、次のいずれかのパッケージ内のコンポーネントのみが表示されます。
ビジネス・コンポーネントのパッケージをJDeveloperプロジェクトに追加（packagename というコンポーネントのパッケージの場合は packagename.xml ファイルを追加）すると、必要に応じてBC4Jウィザードを使用してあらゆる側面を編集でき、ソース・コードが表示されます。
ビジネス・コンポーネントのパッケージをライブラリからインポートすると、コンポーネントは現行プロジェクト内で編集可能なコンポーネントにより参照される各種ADF BC設計時ウィザードで使用可能になりますが、インポート済コンポーネントを変更することはできません。 つまり、Javaソース・コードがライブラリのJARファイルに存在する必要はありません（*.classおよび*Xmlファイルのみ存在）。
ADF BCコンポーネントをデプロイするには、ビジネス・コンポーネントのデプロイメント・プロファイルの作成時に「シンプルJARファイル」オプションを使用します。 このオプションには、アプリケーション・モジュール・コンポーネントの右マウス・メニューから「ビジネス・コンポーネントのデプロイメント」を選択してアクセスできます。
ADF BCコンポーネントのパッケージをインポートする手順は、次のとおりです。
*CSMT.jar ファイルと *CSCommon.jar ファイルの両方がライブラリ定義に含まれていることを確認します。packagename）の packagename.xml ファイルを選択します。インポート済コンポーネントの1つを選択すると、そのプロパティを「ビジネス・コンポーネント」エディタで検査できますが、設計上、インポート済コンポーネントはインポート対象プロジェクト内では編集できないため、すべてがグレー表示されていることがわかります。
注意: インポート対象プロジェクトで作業中に新規JARファイルを生成してインポート済プロジェクトを更新した場合、インポート対象プロジェクトを閉じてから再び開くまでは、変更内容がインポート対象プロジェクトで認識されないことに注意してください。
ADF BCアクセッサ・ベースのコレクションの場合、リクエスト間で通貨を保持するには、アクセッサ・コレクションを起動する前に、マスター・ビュー・オブジェクト上で setViewLinkAccessorRetained(true) をコールして、ビュー・リンク・アクセッサ上で通貨を保持するようにマスター・ビュー・オブジェクトをマーク付けする必要があります。
これは、複数のWebページで同じアクセッサを使用する場合も同様です。
通貨をページ間で保持する場合は、アクセッサ・コレクションを起動する前に、マスター・ビュー・オブジェクト上で setViewLinkAccessorRetained(true) をコールして、ビュー・リンク・アクセッサ上で通貨を保持するようにマスター・ビュー・オブジェクトをマーク付けする必要があります。
たとえば、DeptViewImpl 内で ViewObjectImpl からの create メソッドをオーバーライドするには、次のようにします。
protected void create() {
//for customized components to perform programmatic defaulting
setViewLinkAccessorRetained(true);
}その後、createメソッドでは、フォーカスが作成された行または選択された編集行に保持されます。
ベスト・プラクティスは、各ページまたはパネルのバインディング・コンテナで、参照する必要のある全データについてバインディングを定義することです。 これは、ADFのデータ・コントロール・パレットからコントロールをドロップしてページを作成する際などにデフォルトで発生する状況です。 このベスト・プラクティスを使用してページを開発した場合、リリース10.1.3への移行時にアプリケーションを変更する必要はありません。 ただし、現行ページのバインディング・コンテナとは異なるバインディング・コンテナからのバインディングを参照するページがアプリケーションに含まれている場合は、既存のアプリケーションをリリース10.1.3に移行する際に注意が必要な重要情報を参照してください。
Webアプリケーションの場合、ライフサイクルのprepareModelフェーズ中に、ADF Modelランタイム・フレームワークにより自動的に現行のページ・リクエストに対する適切なバインディング・コンテナが準備され、現行のバインディング・コンテナ内のバインディングにより保持されている状態はリクエストの終了時に解除されます。
これにより、セッション・レベルの不要な状態が回避され、スケーラビリティが向上します。
リリース10.1.2では、現行ページが ${data.SomeNonCurrentBindingContainer.SomeBindingName}などのEL式を使用して別のバインディング・コンテナからのバインディングに対するアクセスを試行した場合、現行リクエストのコンテキスト内でそのバインディングに関連する単一イテレータに対して、オンデマンドの prepareModel() を試行していました。
これは、状況によっては正常に機能しました。
ただし、動作に一貫性がなく、予期しない副次効果が生じて、最新でないバインディングに関連していたイテレータの種類によっては多数の開発者を驚かす結果となりました。
この非一貫性に対処し、前述のベスト・プラクティスを促進するために、現在はこのオンデマンドの事前イテレータ作成は回避されています。
実際の効果として現行ページで可能なのは、デフォルトで、バインディングを固有のバインディング・コンテナから参照することのみです。
アプリケーション・ページで ${data. の出現箇所を検索すると、アプリケーションにこの種の参照が含まれているかどうかをチェックできます。
含まれている場合は、次の方法によりシステムで置換できます。
${data.SomeNonCurrentBindingContainer.SomeBindingName} の現行の参照を ${bindings.NewBindingName} に変更します。複数のページに組み込む共有JSPページのフラグメントで ${data.SomeBindingContainer.SomeBindingName} のようなバインディングを参照する場合は、現行のページ・リクエスト中に SomeBindingContainer をプログラム的に準備できます。
そのためには、既存の DataAction クラスの prepareModel() メソッドをオーバーライドし、 super.prepareModel() の後に次の prepareBindingContainer() のようなヘルパー・メソッドをコールして、ページで参照する必要のあるバインディングを含んだ必要なバインディング・コンテナをリフレッシュします。
public void prepareBindingContainer(DataActionContext ctx, String bcName) {
ctx.getBindingContext().findBindingContainer(bcName)
.refresh(DCBindingContainer.PREPARE_MODEL);
}したがって、オーバーライドした prepareModel() メソッドは次のようになります。
// Programmatically prepare NameOfOtherPageUIModel binding container
// in this request, too
public void prepareModel(DataActionContext context) {
super.prepareModel(context);
prepareBindingContainer(context,"NameOfOtherPageUIModel");
}このコードをリリース10.1.3でDataPageに初めて追加すると、クラスはオーバーライドするのと同じ prepareModel() ライフサイクル・メソッドを持つ新規の PageController クラスのサブクラスになり、ヘルパー・メソッドは次のようになります。
public void refreshBindingContainer(LifecycleContext ctx, String bcName) {
ctx.getBindingContext().findBindingContainer(bcName);
Refresh(DCBindingContainer.PREPARE_MODEL);
}現在、ADF Business Componentsのデータ・コントロールは、この新規動作を積極的に規定するデータ・コントロールのみですが、他のデータ・コントロール実装は将来のメンテナンス・リリースでこのポリシーに従うことになります。 したがって、アプリケーションで使用中のデータ・コントロールの種類に関係なく、ベスト・プラクティスの推奨事項に即時に従うことが最善の方法です。
ページ定義ファイル内で実行可能ファイルの RefreshCondition プロパティに提供される el-expression の名前がEL領域に存在しないかNULLに評価される場合、現在は RefreshCondition が無視され、実行可能ファイルがリフレッシュされるかどうかは実行可能ファイルの Refresh プロパティによって決まります。
このデフォルト動作は、将来、El-expression 内の欠落エントリなどを false として解析するように変更される可能性があります。
このリリースでは、 RefreshCondition で提供されるエントリが実際にJavaブール値に評価されることをアプリケーションで確認する必要があります。
アプリケーション・モジュール名を変更すると、アプリケーション・モジュールのJavaクラスとデフォルト構成の名前が変更されます。
ただし、 DataBindings.cpx ファイルでは引き続き古い構成が参照され、プロジェクトの「デフォルトの実行ターゲット」では引き続き古いJavaクラス名が参照されます。
アプリケーション・モジュール名またはパッケージ名を変更した場合は、プロパティ・インスペクタを使用して必要な更新を行う必要があります。
リリース10.1.2では、Beanデータ・コントロールで検索モードがサポートされていても、Bean属性は問合せ可能として識別されませんでした。
検索フォームをリリース10.1.3に移行する場合は、プロパティ・インスペクタを使用して、検索に関与させる検索フォームの属性について Beanデータ・コントロールの属性 IsQueriable を true に設定します。
リリース10.1.3では、設計時に新規のBean属性が更新可能として定義されることに注意してください。
JDeveloperの 「式ビルダー」ダイアログでは、オブジェクト、マネージドBeanおよびプロパティのリストを指定してEL式を作成できます。 このダイアログを使用してADFバインディングのプロパティのADFデータバインド式を編集するときには、ページの各バインディング・オブジェクトで使用可能なADFバインディング変数が表示されます。 現在、このリストにはリリース10.1.3で廃止になった一部のバインディング・プロパティが含まれています。 たとえば、次のような廃止プロパティが表示されます。
actionEnabled: Actionバインディングに存在allRowsInRange: JUVariableIteratorBindingに存在application: JUFormBinding、JUIteratorBinding、JUVariableIteratorBindingに存在applicationModule: JUIteratorBindingおよびJUVariableIteratorBindingに存在attributeDef: Hierarchical（ツリー）、Rangeバインディングに存在attributeDefs: JUVariableIteratorBindingに存在autoSyncEnabled: Tree（HierNodeBinding）バインディングに存在currentRow: Tree（HierNodeBinding）バインディングに存在displayListIterator: Boolean、Listバインディングに存在error: Hierarchical（ツリー）、Rangeバインディングに存在estimatedRowCount: JUVariableIteratorBindingに存在findMode: JUVariableIteratorBindingに存在formBinding: JUVariableIteratorBindingおよびJUIteratorBindingに存在hierTypeBinding: Tree（HierNodeBinding）バインディングに存在inputValue: Hierarchical（ツリー）、Rangeバインディングに存在label: Hierarchical（ツリー）、Rangeバインディングに存在listIterBinding: Boolean、Listバインディングに存在mandatory: Hierarchical（ツリー）、Rangeバインディングに存在orderedVOUsageList: JUFormBindingに存在operationEnabled: Actionバインディングに存在operationSupported: JUVariableIteratorBindingに存在panel: JUFormBindingに存在path: Actionバインディングに存在rangeSize: Hierarchical（ツリー）バインディング、JUVariableIteratorBindingに存在rangeStart: Hierarchical（ツリー）バインディング、JUVariableIteratorBindingに存在rangeSet:Hierarchical（ツリー）に存在singleAttrList: Booleanバインディングに存在sourceName: JUVariableIteratorBindingに存在tooltip: Hierarchical（ツリー）、Rangeバインディングに存在updateable: Hierarchical（ツリー）、Rangeバインディングに存在valueAt: JUCtrlAttrsBindingに存在viewObject: JUVariableIteratorBindingに存在VOName:JUVariableIteratorBindingに存在前述のプロパティは将来のリリースで削除されるため、バインディングには使用しないでください。
EA1でアプリケーションをビルドした場合は、Facesバインディングでメソッド名が invoke から executeに変更されたことに注意してください。
例えば、先頭の行に移動する「First」ボタンは、EA1アプリケーションでは、次のようにバインドされていました。
<af:commandButton actionListener="#{bindings.First.invoke}"
action="First" text="First"
disabled="#{!bindings.First.enabled}"/>これは次のように更新する必要があります。
<AF:commandButton actionListener="#{bindings.First.execute}"
action="First" text="First"
disabled="#{!bindings.First.enabled}"/>設計上、ADF BindingContextは、リクエスト中に実行される転送の回数に関係なくリクエストごとに1度のみ作成されます。 HttpSessionを無効化してリクエスト中にBindingContextを破棄した場合は、新規のADFバインディング・コンテキストを使用する新規HTTPセッションが正常に作成されるように、HTTPリダイレクトを実行する必要があります。 JSFを使用すると、JSFナビゲーション・ケースでリダイレクト・プロパティをマーク付けして、このリダイレクトを宣言的に実行できます。
次のエラー・メッセージが戻されたとします。
SEVERE: Managedbean main_bean could not be created The scope of the referenced object:
'#{bindings}' is shorter than the referring objectADFmでバインドされているコマンド・コンポーネント用にプログラム的にメソッド・バインディングを作成する場合は、選択したマネージドBeanがリクエスト・スコープに存在する必要があることに注意してください。 コード生成時には、ADFバインディング・コンテナが管理プロパティとしてマネージドBeanにインジェクトされます。 バインディング・コンテナはリクエスト・スコープにあるため、Beanのスコープが広いとマネージドBeanで参照できません。
JSFページの検索フォームでは、デフォルトで、日付に <af:selectInputDate> コンポーネントが使用されます。
このコンポーネントで許可されるのは正確な日付のみであるため、他のコンポーネントに有効な > および < 演算子を使用すると検証エラーになります。
代替策は、ワイルドカードを使用する必要がある場合は <AF:inputText> コンポーネントを使用し <convertDateTime> タグを削除することです。
EJB 3.0では、persistEntity のアクションがハードコード化されていると重複PKの検証が表示されないことがあります。
メソッドをダブルクリックしてコードを追加するメソッドをプログラム的に実行し、ユーザーを空ページの作成に戻すエラーが発生した場合は、結果としてNULLを戻す必要があります。
アクセッサ・ベースのVOメソッドを使用してJSF JSPページを作成すると、不正なページ定義が生成されます。
このため、ページの実行時にランタイム・エラーが発生します。
回避策は、生成されたページ定義ファイルを次のように手動で変更することです（メソッド名が foo であるとします）。
foo1 のIDで生成された余分な <methodAction> 要素を削除し、生成されたJSPページ内で foo1 への参照をすべて foo に置き換えます。foo について残りの <methodAction> 要素を修正し、 InstanceName 属性を bindings.yourIterator.viewObject に設定して IsViewObjectMethod 属性を false に設定します。<attributeValues> 要素を検索し、 IterBinding 属性の値が variables であることを確認します。JSPセグメント・ファイルの場合、ADF Databindingはサポートされません。 データバインドされたコンポーネントは、JSPセグメント・ファイルにドロップできません。
ビジュアル・エディタまたはStruts ADFアプリケーションのJSPページの「ソース」ビューでUIコントロールを削除しても、ページの定義ファイルでは対応するバインディングが削除されません。 構造ウィンドウまたはソース・エディタを使用すると、手動でページ定義ファイルからバインディングを削除できます。
TopLinkのワークスペースを移行して session.xml からデータ・コントロールを再作成すると、データ・コントロール・パレットに「findAll」ノードが表示されません。
これは、このような問合せが定義されているのは新規作成されたプロジェクトのみであるためです。
回避策は、 findAll 問合せを必要なディスクリプタに追加することです。
EJBを含むワークスペースを移行し、そこからデータ・コントロールを作成すると、Beanクラスから生成される .xml ファイルは作成されません。
回避策は、構造ウィンドウのコンテキスト・メニューから「リフレッシュ」を選択してBeanクラスを手動でリフレッシュすることです。
JavaBeansやEJBのデータ・コントロールなど、Beanベースのデータ・コントロールを生成すると、フレームワークはJDK 1.5の汎用コレクション型メタデータ（Collection<SomeType>）を横断できます。
Collectionのフィールド、メソッドまたはパラメータがこの方法で型指定されていない場合は、Collectionが保持するオブジェクトの型がわかっていれば、その型をフレームワークに対して指示する必要があります。
そのためには、構造ウィンドウでCollectionアクセッサを選択し、プロパティ・インスペクタを起動して、そのアクセッサのオブジェクト型を「Beanクラス」フィールドに入力します。
データ・コントロール・パレットでこのアクセッサに関連した「Operations」フォルダに表示するCollection操作を有効化するには、CollectionBeanClassフィールドに UpdateableCollection または ReadOnlyCollection などの値を入力します。
ライブラリが変更されたため、EA1から移行したアプリケーションが正しくレンダリングまたは実行されないことがあります。 この問題を解決するには、「プロジェクト・プロパティ」に移動し、taglibセクションを削除してからADF Facesタグ・ライブラリを読み取ります。
<afc:cache> タグを <af:document> タグの親にすると、XMLソース・エディタに次のエラーが表示されることがあります。
要素af:documentの親要素が無効ですこのエラーが発生しても実行時に問題は発生しません。
このエラーを無視するか、 <afc:cache> タグを <af:document> タグ内に移動できます。
後者の方法を選択すると、キャッシュには、 <f:view>タグに含まれていたページ・コンテンツではなく、<af:document> タグに含まれていたフラグメントのコンテンツが格納されます。
この変更は、キャッシュに格納される実際のコンテンツには影響しません。
メイン・アプリケーションのページで再POST（同じページからのPOSTの結果であるリクエスト）を実行し、固有のサブページにある対象フラグメントが含まれている場合、対象フラグメントでは <afc:cache> を使用しないでください。
メイン・ページを更新するボタンやタブは、再POSTの一例です。
このタイプのフラグメントとともに <afc:cache> タグを使用すると、予期しないページ・ナビゲーションが発生することがあります。
Apple MacintoshプラットフォームでJDK 1.5を使用する場合は、JDKバージョン1.5.0_06以上を使用してください。 バージョン1.5.0_06以前のJDK 1.5には不具合があり、ADF Facesの表コンポーネントがビジュアル・エディタにレンダリングされず、他にもレンダリングに問題が発生する可能性があります。
Webサービスに関して生成されるWSDLファイルとエンドポイント情報は、標準ポート8888でスタンドアロンoc4jインスタンスに対してデプロイすることを意図しています。 データ・コントロールでは、Webサービスへの接続がこのポートで構成されます。 埋込みOC4Jはデフォルトでポート8988で実行されるため、データ・コントロールによりWebサービスが実行されるとエンドポイントに到達できません。 「Webサービス接続の編集」ダイアログを使用して、エンドポイントのポートを埋込みOC4Jのポートに変更する必要があります。
ANYデータ型として定義されている複合型を持つWSDL内のスキーマ、または型がスキーマ全体として定義されているスキーマは、サポートされません。
この種のスキーマを公開するサンプルWSDLは、次を参照してください。
http://www.jasongaylord.com/webservices/zipcodes.asmx?wsdl
埋込みoc4jインスタンスは、 <jdev_home>\j2ee\home\config\system-jazn-data.xml を embedded-oc4j\config にコピーした後、JSPを再実行する前に終了する必要があります。
終了しないと、新規にコピーした system-jazn-data.xml が埋込みOC4Jサーバーにより取得されません。
URLデータ・コントロールを使用するアプリケーションをOracle Application Server上で実行するには次の回避策が必要です。
<jdev_home>\j2ee\home\config 内の system-jazn-data.xmlを、<as_home>\j2ee\home\configにコピーします。
このファイルを上書きしないようにする場合は、このファイルにURLConnection資格証明をカット・アンド・ペーストします。<as_home>\opmn\bin\opmnctl stopall でOracle Application Serverを停止し、opmnctl startallで起動します。EJB 3.0データ・コントロールに対してビルドされたADF Swingクライアントは、Java WebStartを使用してデプロイできません。
これは、WebStartのデプロイメント・ディスクリプタの制限によるものです。
ADF SwingクライアントをEJB 3.0データ・コントロールで動作させるには、VMにコマンドライン引数 -javaagent を渡す必要があります。
ただし、Java WebStartのデプロイメント・ディスクリプタでは、 -javaagent パラメータを指定できません。
この制限は、EJB 2.1データ・コントロールには影響しません。
JClientアプリケーションでは、認証と認可を有効化するために、引き続きアプリケーション・モジュールの構成プロパティ jbo.security.enforce を使用する必要があります。
JClientの場合、リリース10.1.3の新しい adf-config.xml の authorizationEnforce プロパティはまだサポートされていません。
リリース9.0.4以前のADF Swing（JClient）アプリケーションをJDeveloper 10.1.3に移行すると、リリース10.1.3のアプリケーションで作成した新規パネルおよびフォームでは、移行したパネルを再利用できなくなります。
また、データ・コントロール・パレットからドラッグ・アンド・ドロップしても、移行したパネルを拡張することはできません。
このような制限は、JDeveloper 9.0.5以降にバインディングを定義するためのページ定義ファイルが導入されたことによるものです。
移行後のパネルを拡張する最善の方法は、コンポーネント・パレットを使用することと、パネルのソース内で Document および Model プロパティを編集することです。
このリリースでは、Oracle XSQLページで作業中にJDeveloperでプロジェクトを自動的に構成する方法が一部変更されています。
XSQLConfig.xml ファイルを、JDBCデータ・ソースを使用するように構成します。
これにより、Oracle XSQL Pagesエンジンの組込み機能が利用され、データベース接続情報が簡素化され、安全性が向上して管理が集中的に行われるようになります。
これは、XSQLページではデフォルトで、J2EE Webアプリケーション環境で構成されたデータ・ソースが使用されることを意味します。
JDeveloperでは、これらの接続が接続ナビゲータで定義した接続に基づいて自動的に構成されます。connection="scott"（XSQLConfig.xmlファイルに直接定義した名前付き接続の使用時に必要）のかわりに、connection="jdbc/scottDS"のような構文で選択したデータ・ソースのJNDI名を使用して、必要に応じてページに接続属性が追加されます。<connection-manager>/<factory>をXSQLのデフォルト（XSQLConfig.xml ベースの名前付き接続を使用）に変更する手順は、 XSQLConfig.xml ファイル内のコメントにあります。
この手順に従うと、元のメカニズムを引き続き使用できます。
リリース10.1.3.0.0のAskコンポーネントでサポートされているのは、en_US ロケールのみです。
そのため、コンテンツを表示する特定のエンド・ユーザーには、英語のみで表示されます。
以降のリリースでは、他のロケールがサポートされます。
Oracle Corporation |
Worldwide Inquiries: |
Copyright © 2006, Oracle Corporation. All Rights Reserved. |