Oracle JDeveloper for Windows NT and Windows 2000

リリース・ノート

リリース3.2.3

2001年4月

部品番号: J03328-01

原典情報: JDeveloper 3.2.3 Release Notes (A82929-03)

目次

Oracle JDeveloperは、インターネット・アプリケーションを作成、デバッグおよび配布するためのオラクル社のJava開発ツールです。このリリースには、Oracle Business Components for Javaも含まれています。これは、XMLで強化された100% Javaのアプリケーション・コンポーネント・フレームワークで、インターネット用の複数層Javaアプリケーションの開発、配布およびカスタマイズが大幅に簡略化されます。

JDeveloper 3.2のオンライン・ヘルプ・システムには、次の2つの形式があります。

• HTML Help

  HTML Help形式のオンライン・ヘルプを使用する場合、マシンにMicrosoft Internet Explorer 4.0以降がインストールされている必要があります。このドキュメントは、圧縮形式の*.chmファイルで提供されています。全文検索機能が使用可能です。

• WebHelp

  WebHelp形式を使用する場合、Netscape Navigator 4.0またはMicrosoft Internet Explorer 4.0以降のいずれでも使用できます。このドキュメントは、非圧縮の*.htmlファイルで提供されています。ドキュメントはサイズの小さい多数のファイルで構成されているため、（NTFSではなく）FATファイル・システムにインストールする場合には、大量のディスク容量が必要になります。実際の必要ディスク容量は、ハード・ディスクおよびセクターのサイズにより異なります。

Javadoc形式のリファレンスは、JDeveloper内部から直接使用できます。Javadocを表示するには、まずソース・ファイルを開きます（ナビゲータでファイルを指定して開く、または、ソース・エディタ内に記述されているクラス名の上で右クリックして「このシンボルを参照」を選択する）。次に、「Javadocビューア」タブをクリックします。クラスにJavadocがない場合は、エラー・メッセージが表示されます。

標準インストールを選択した場合は、Oracle JDeveloperのインストーラにより、コンピュータにどのブラウザがインストールされているかが検出され、適切な形式のヘルプがインストールされます。

• Microsoft Internet Explorer 4.0以降がインストールされている場合、自動的にHTML Helpがインストールされます。

• Microsoft Internet Explorerが検出されない場合、WebHelpがインストールされます。

• いずれの場合でも、JDeveloper内のJavadocシステムは常に使用可能です。

適切なブラウザをインストールしていない状態で任意のヘルプ・システムを強制インストールするには、Oracle JDeveloperインストーラの「カスタム」インストール・オプションを使用します。希望のオンライン・ヘルプ・オプションを選択してください。

• Microsoft Internet Explorer 4.0以降をインストールしていない状態でHTML Helpを強制インストールした場合、Oracle JDeveloperのインストール後にMicrosoft Internet Explorerをインストールするよう警告されます。HTML Helpシステムは、Microsoft Internet Explorerをインストールせずに起動することはできません。

• Netscape Navigator 4.0以降またはMicrosoft Internet Explorer 4.0以降をインストールしていない状態でWebHelpを強制インストールした場合、Oracle JDeveloperのインストール後にどちらかをインストールするよう警告されます。WebHelpシステムは、いずれかのブラウザをインストールせずに起動することはできません。

HTML Helpをインストールしても、マシン上で適切なバージョンのMicrosoft Internet Explorerが使用できない場合、ヘルプ・システムの起動時に次のようなエラーが発生します。

• 「shlwapi.dllが指定されたパスに見つかりません。」

• JDeveloperが予期せずに終了したことを示す「Windows NTワトソン博士エラー」

• 「序数 <番号> がダイナミック リンク ライブラリCOMCTK32.dllから見つかりません。」

Oracle Technology Network（OTN）は、インターネット・プラットフォームでの開発に関するOracle技術情報について、最も信頼のおける無償のソースです。ユーザーはオンライン・コミュニティの一員となり、無償提供のソフトウェアや、OTNが開催しているインターネット開発者会議および最新のOracleテクノロジについて議論するグループにアクセスできます。

OTNの登録ページ
日本語サイト:  http://otn.oracle.co.jp/membership/index.html
USサイト:  http://otn.oracle.com/free/

ホワイトペーパー、FAQ、リリース・ノートの更新など、JDeveloperに関する最新情報は、Oracle Technology Networkの次のサイトを参照してください。
日本語サイト:  http://otn.oracle.co.jp/products/itools/jdev/jdev.html
USサイト:  http://otn.oracle.com/products/jdev/

ライセンス情報

VisiBroker for JavaおよびVisiBroker for C++のバージョンは、Oracle JDeveloper 3.2に統合されました。CORBAサーバー・オブジェクトの構築など、このVisiBroker for JavaおよびVisiBroker for C++を使用するすべての開発は、Oracleツールの使用を介した場合に限定されます。スタンドアロン開発でVisiBroker for JavaおよびVisiBroker for C++を使用することは許可されていません。またオラクル社は、VisiBroker for JavaおよびVisiBroker for C++の開発バージョンとランタイム・バージョンのいずれについても、スタンドアロンCORBAサーバー・オブジェクトのサポートを含め、Oracleのツールおよび製品の外部での使用をサポートしていません。

VisiBroker for JavaおよびVisiBroker for C++をスタンドアロン・ベースで使用するライセンスは、Borland Software Corporationから入手できます。

インストール、システム要件およびサポートされる配布環境の詳細は、「Oracle JDeveloper for Windows NT and Windows 2000 インストレーション・ガイド リリース3.2.3」を参照してください。インストレーション・ガイドには、JDeveloperソース・コントロールで使用するOracle Repositoryのインストールについての情報も記載されています。インストレーション・ガイド（install.htm）は、次の両方の場所にあります。

• <JDeveloper_Home>\Install.htm（インストール後にここに置かれます）

• JDeveloperインストールCDのルート・ディレクトリ

Oracle JDeveloper 3.2は、Oracle8i 8.1.7を完全にサポートしています。次の表は、Oracle JDeveloper 3.1および3.2と、Oracle8i 8.1.6および8.1.7の互換性を示したものです。

1 Javaストアド・プロシージャのみ。

2 Solaris上のOracle8i 8.1.7にJDeveloper 3.2からEJBを配布することはできません。この問題は、Windows NT上のOracle8i 8.1.7では発生しません。この問題に関する詳細は、OTN-Jを参照してください。

注意:　 この表は、Oracle JDeveloperの全機能ではなく、Oracle8i 関連の機能のみを対象としたものです。

この項には、ドキュメントには記載されていないBusiness Components for Javaの機能に関する最新情報が記載されています。

次の機能は、リリース3.2でのBusiness Components for Java（BC4J）の新機能です。詳細は、オンライン・ドキュメントを参照してください。

• アプリケーション・モジュール・プーリングおよび状態管理の改良

  高スループットWebアプリケーション用のアプリケーション・モジュール・プーリングのインプリメンテーションが、大幅に改良されました。新しいプール・インプリメンテーションを使用すると、アプリケーション・モジュールを1回のリクエストが継続している間使用し、その後で解放できます。オプションで、保留中のアプリケーション・モジュールの状態のスマート管理機能も使用できます。これにより、Webアプリケーションへのステートフル・アプローチに通常伴うボトルネックを発生させずに、論理作業単位の実行に複数ページを必要とするWebアプリケーションの開発が大幅に簡略化されます。

• ビジネス・コンポーネントへのアクセスを簡略化する新規JSP 1.1 Business Components for Javaデータ・タグ・ライブラリ

  データ・タグ・ライブラリを使用し、余分なJava Beanメソッド・コールやカスタムJavaコーディングを行わずに、ビジネス・コンポーネントJSPアプリケーション全体をHTMLタグとJSPタグで開発できます。Business Components for Javaデータ・タグ・ライブラリは、JSP 1.1に完全に準拠したJSPタグのセットです。このライブラリを使用し、Business Components for Javaデータの表示または変更、あるいはその両方を簡単かつ強力に制御できます。

• ビュー・オブジェクトのツリーの双方向XMLメッセージ・サポート

  どのビュー・オブジェクトも、ビュー・リンクでリンクされたディテール・ビューと連携し、ViewObjectインタフェースで新しいwriteXML()メソッドを使用して、階層型XMLメッセージを自動的に発行できます。XMLエレメント名とその他オプションは、カスタム・ビュー・オブジェクトおよびビュー・オブジェクト属性プロパティを使用して制御できます。XMLメッセージを代替XML形式に変換するオプションのXSLTスタイルシートを提供できます。

  XMLの生成に加えて、ビュー・オブジェクトはXMLメッセージを読み込み、それらの内容を自動的に処理することもできます。新しいreadXML()メソッドをViewObjectインタフェースで使用することにより、マスター/ディテール・ビューのビュー・リンク・ツリーのルート・ビュー・オブジェクトにXMLメッセージを渡すことができます。また、エンティティ・オブジェクト・レベルのすべてのビジネス・ロジックの施行やデフォルトの設定など、適切な挿入、更新、削除を（任意のレベルで）いくつでも実行できます。処理するXMLメッセージが、ビュー・オブジェクトで読み込める標準形式でない場合は、オプションのXSLTスタイルシートを提供して、処理する前に標準形式に変換できます。

• Oracle XSQLページとのBC4Jの統合

  このリリースには、定義済ビュー・オブジェクトとOracle XSQLページのXML/XSLT公開フレームワークを組み合せた使用を容易にする2つのXSQLアクション・ハンドラが用意されています。oracle.jbo.xsql.ViewObjectハンドラを使用するとXSQLページにXMLを描画でき、oracle.jbo.xsql.UpdateViewObjectを使用するとXSQLページはXMLの内容をインバウンド処理のためにビュー・オブジェクトにポストできます。IDEが新たにサポートする新規XSQLページの作成、XSQLページのデバッグおよびXSQLアクション・エレメントの構築により、作業がさらに簡略化されます。

• 構成を使用するすべての層の接続管理の簡略化

  各BC4Jパッケージは、そのパッケージ内のアプリケーション・モジュールの名前付き構成を記録するXMLベースのbc4j.xcfgファイルに関連付けることができます。パッケージには、すべての必要な接続パラメータやカスタム・ランタイム・パラメータの事前定義値を含め、BC4Jがサポートする任意の接続モード用の任意のアプリケーション・モジュールの構成をいくつでも事前定義できます。実行時に、some.packageという名前のパッケージ用のbc4j.xcfgファイルは、クラスパス上の.\some\package\commonディレクトリにあります。

• アプリケーション・モジュールのデバッグ

  Business Component Testerをデバッグ・モードで非常に手軽に実行できます。つまり、Business Component Testerを使用してアプリケーション・モジュールを試すことができ、カスタム・クライアント・コードを作成せずにビジネス・コンポーネント・コードにブレークポイントを設定できます。Business Component Testerを使用してアプリケーション・モジュールをデバッグするには、次の手順を実行します。

  1. デバッグするアプリケーション・モジュールのノードをナビゲータで展開し、JavaファイルとXMLファイルを表示します。

  2. インプリメンテーション・ファイル AppModuleImpl.javaを選択します。

  3. 右クリックで表示されるメニューから「デバッグ...」を選択します。

  最初に"MyAppModuleLocal"構成を編集し、構成エディタの「プロパティ」タブにアクセスすることにより、セッションのデバッグに影響する可能性のある追加のBC4Jランタイム・プロパティを設定することもできます。

• Oracle8i リリース8.1.7のEJB 1.1 CMPサポート

  新機能とウィザードにより、BC4Jを、Oracle8i リリース8.1.7でのEJB 1.1エンティティBeanサポート用のコンテナ管理の永続性（CMP）プロバイダとして使用できます。

• すべて一時属性を持つビュー・オブジェクト

  BC4Jウィザードを使用することにより、一時属性のみで構成されるビュー・オブジェクトを、SQL問合せを発行せずに構築できます。これらの問合せなしビュー・オブジェクトは、実行時にアプリケーション・コードによりプログラム的に移入される一時データのための値ホルダーとして使用できます。

• フェイルオーバー・サポート

  デフォルトでは、アプリケーション・モジュール・プールのステートフル・モードを使用すると、保留中のアプリケーション・モジュールの状態は、アプリケーション・モジュールがプールに解放されるたびに保持されます。これにより、異なるWebサーバーに割り当てられているブラウザ・ユーザーは、新規サーバーにルーティングされた場合でも、アプリケーション・モジュールの状態をリカバリできます。このレベルのフェイルオーバー・サポートが不要な場合は、プロパティを次のように設定できます。

  jbo.dofailover=false

  このプロパティは、コマンドラインまたはBC4J構成プロパティで設定します。

• オプションのJDBC接続プーリング

  接続プーリングは使用可能ですが、デフォルトではオフになっています。これにより、プール内の各アプリケーション・モジュールは、再利用可能なJDBC文を保持し、次のリクエストで再利用できます。接続をプールに解放しないと、多数のJDBCオブジェクトをその都度再作成することを回避できるため、この機能はアプリケーション・モジュールが各リクエストに対して多数のビュー・オブジェクトを使用する場合に、より効率的です。このモードでも、アプリケーションは、コミットされていないデータベース状態を複数のリクエストにまたがって保持する必要はありません。接続プーリングをオンにするには、次のプロパティを設定します。

  jbo.doconnectionpooling=true

  このプロパティは、コマンドラインまたはBC4J構成プロパティで設定します。

• 永続コレクション・サポート

  数千行以上から成るBC4J行セットを処理する場合は、新しい永続コレクション・サポートを使用し、行のキャッシングやスクロールに使用されるコア・メモリー量を削減できます。この機能は、データベースを、メモリーに入りきらない余剰行の外部記憶装置として使用します。

  jbo.use.pers.coll=true

  このプロパティは、コマンドラインまたはBC4J構成プロパティで設定します。

• ユーザー定義の調整式行セット・フィルタ

  デフォルトでは、ビュー・リンクは、リンク元（マスター）行の属性と、対応するリンク先（ディテール）行の属性セットの間で、等価基準を使用してマスター/ディテール行セットを調整します。ディテール行セットがAssociationの整合性モードで使用されるよう設定されている場合は、キャッシュ内のエンティティに対する保留中の変更も、適切なディテール行セットに自動的に保持されます。

  ビュー・リンク・ウィザード/エディタの最後のページで使用可能なユーザー定義ビュー・リンクの「関連付けSQL文」の句を使用すると、ユーザーは、複合SQLベースのディテール問合せ基準を使用し、基本等式を超えるビュー・リンク関係を定義できます。ただし、リリース3.1までは、これらの複雑なビュー・リンクで、メモリー内行セットの内容の一貫性を保つことはできませんでした。3.2では、ビュー・オブジェクトはカスタム行フィルタを関連付けて、この動作を任意の複合ビュー・リンクで有効にします。この新機能のインプリメント例は、後の項を参照してください。

• 大/小文字の区別なしの問合せ

  BC4J ViewCriteria機能を例による問合せ機能で使用する場合は、大/小文字の区別なしのモードでWHERE句列を生成することを要求できます。この機能を使用するには、ViewCriteriaRowのインスタンスでsetUpperColumns(true)をコールします。

  
  

  注意:　 この機能は、ビュー基準行に対して生成されたWHERE句の断片部分で<COLNAME>のかわりにUPPER(<COLNAME>)を生成することで動作します。問合せのパフォーマンスを改善するには、UPPER(<COLNAME>)式にファンクション索引を作成して索引を利用してください。

  
  

• BC4Jの配布でのOracle8i JVMセキュリティ権限の簡略化

  <JDeveloper_Home>\bin\Java2Perm.sqlスクリプトは、EJBセッションBeanまたはCORBAサーバーとして、あるいはLOCALモードでOracle8i に配布されるBC4Jアプリケーション・モジュールの配布および実行に必要な権限の付与を支援するために用意されています。

次に、アプリケーション・モジュール・プールでサポートされる3種類のモードを説明します。

ステートレス・モードを使用してアプリケーション・モジュールをプールに解放した場合は、保留中のアプリケーション・モジュールの状態がすべて解放されます。リクエストの継続中にコードでトランザクションを明示的にコミットしなかった場合、リクエスト中にアプリケーション・モジュールで行われた保留中の挿入、更新、削除はすべて取り消されます。このモードは、サーブレットまたはJSPページが実行しているタスクが現在のリクエストで完了する場合に使用します。

ジョブ完了のためにユーザーによる別のページへのアクセスが必要なタスクをインプリメントするWebアプリケーションを構築する必要がある場合は、ステートフル・モードを使用します。このモードでは、アプリケーション・モジュール・インスタンスをプールに解放しますが、プールに対して、保留中のアプリケーション・モジュールの状態を効果的に管理するよう要求します。現在のセッション中にアプリケーション・モジュールに対して行われた保留中の（コミットされていない）挿入、更新または削除は、リクエストの終了後も、アクティブなビュー・オブジェクトの現在位置として記憶されます。これにより、多くのWebページ・リクエストにまたがることの多い新規オーダーの作成や新規項目の追加が、簡単にプログラムできるようになります。前述のように、プロセスの最終ページでアプリケーション・モジュールをステートレス・モードで解放し、終了を示すことができます。

これは、現在のアプリケーション・モジュールが、現在のブラウザ・ユーザー専用であることを意味するのではなく、現在のブラウザ・ユーザーが戻った際に次のリクエストで前のリクエストと同じ保留状態のアプリケーション・モジュールを自動的に処理するだけであると理解することが非常に重要です。プールのアプリケーション・モジュール・インスタンスがまったく同じであるという保証はありませんが、スマート状態管理により、プールからどのインスタンスを取得した場合でも、現在のユーザーの前のセッションの状態と自動的に同期することが保証されます。このモードでは、Webサイトにアクセスする各ユーザーがリソースを専有するという欠点を伴うことなく、単純なステートフル・プログラミング・モデルを利用できます。この機能は、XMLに対する必要最低限のアプリケーション・モジュール状態をデータベースに透過的に保持し、必要に応じてアプリケーション・モジュール状態のスナップショットを透過的に再利用することにより実現されます。このモードでは、保留中のデータベース状態を複数のリクエストにまたがって保持すべきではありませんが、（コミット時ロックを使用した）アプリケーション・モジュールの保留中の変更は適切に処理されます。

JDeveloper 3.1との下位互換性を保つために、アプリケーション・モジュールをリザーブド・モードで解放できます。このモードは、ユーザー定義のタイムアウトが経過するまで、または後続のページがアプリケーション・モジュールをステートレス・モードで再び解放するまで、特定のアプリケーション・モジュール・インスタンスを現在のブラウザ・セッションに事実上固定します。このモードは、複数のリクエストにまたがって保留中のデータベース状態をサポートする唯一のモードです。

機能に対する次の最新の変更は、ドキュメントに記載されていない可能性があります。

• XMLメッセージを介したビュー行の削除の処理

  XMLメッセージを新規ViewObject.readXML()メソッドに渡して処理する際に、BC4Jは、ビュー・リンクでリンクされたビュー・オブジェクトのツリーに対する挿入および更新を自動的に処理します。特定の行を削除するよう指定するには、行を表すエレメントにbc4j-action="remove"属性を追加する必要があります。

  したがって、たとえばXML_ROW_ELEMENTプロパティを使用して上書きされたデフォルトのXMLエレメント名がない場合は、Employeesという名前のビュー・オブジェクトから行を削除するためのXMLメッセージは次のようになります。

  <!-- Example message to remove two employees -->
  <Employees>
    <EmployeesRow bc4j-action="remove">
      <Empno>1234</Empno>
    </EmployeesRow>
    <EmployeesRow bc4j-action="remove">
      <Empno>1288</Empno>
    </EmployeesRow>
  </Employees> 

  挿入や更新の場合と同じように、XMLは、行の主キーなど、目的の操作の実行に必要最低限のエレメントのみ提供する必要があることに注意してください。前述の例では、主キー属性Empnoに値を指定するだけで、フレームワークはこれを特定し、削除できます。

• XMLメッセージでのnullインジケータの明示的なリクエスト

  新規ViewObject.writeXML()メソッドによりデフォルトで生成されるXMLメッセージは、null値を持つ属性に対してXML内のエレメントを省略します。null属性を結果に含める場合は、目的のビュー・オブジェクトまたは個々のビュー・オブジェクト属性にXML_EXPLICIT_NULLという名前のカスタム・プロパティを提供します。プロパティの値には、空値以外の任意の値（"y"、"yes"など）を指定できます。このカスタム・プロパティの存在により、<AttrName>エレメントを省略するかわりに、<AttrName null="true"/>という名前のエレメントが作成されます。

カスタムSQLのWHERE句を使用してビュー・リンクでリンクされたBC4Jビュー・オブジェクトをプログラムで処理する場合は、等式ベースのビュー・リンクにデフォルトで提供されているものと同じ種類のマスター/ディテール行セットの一貫性を実現できます。これを実現するには、次のことが必要です。

• oracle.jbo.server.RowFilterインタフェースをインプリメントするクラスを作成します。

  行フィルタは、カスタマイズされたグループ化基準に基づいて、関連する行のグループを概念的に所有するオブジェクトです。デフォルトのインプリメンテーションでは、キー属性値の特定のセットに一致する関連行のグループ（たとえば、部門番号が10のすべての従業員）を所有するフィルタを定義します。

• マスター/ディテール・ビュー・リンク内のディテール問合せを表すViewObject実装クラス内の3つのメソッドをオーバーライドします。

  1. RowFilter buildRowFilter(Object[] paramValues)

     このメソッドは、デフォルト・インプリメンテーションoracle.jbo.server.RowFilterKeyを使用するかわりに、RowFilterのカスタム・インプリメンテーションのインスタンスを返します。

  2. RowFilter[] getQualifyingRowFilters(Object[] rowParamValues)

     このメソッドは、候補行が属する0以上の一致する行フィルタの配列を返します。

  3. RowFilter[] buildQualifyingRowFilters(Object[] rowParamValues)

     このメソッドは、既存の行フィルタを修飾しない候補行に関連付けられる新規行フィルタがある場合に、それを構築するためにコールされます。

次は、カスタム行フィルタの使用方法を示すサンプルです。この例では、部門番号別にグループ化するデフォルトの方法は使用せずに、2つのビュー・オブジェクトを使用し、データ駆動の給与帯にグループ化された従業員情報を提示します。このアプリケーションが接続するデータベース内のEMP表について理解していることと、このEMP表にEmpという名前のエンティティ・オブジェクトがマップされていることを前提とします。サンプル・コードで示すオブジェクトのパッケージ名はneqです。

最初に、ビュー・オブジェクト・ウィザードを使用してSalaryBandsビュー・オブジェクトを作成します。問合せのみ指定する必要があり、エンティティ・オブジェクトにこのエキスパート・モード問合せを関連付ける必要はありません。問合せは次のようになります。

select 'Band1' as band,
       0       as band_low,
       999    as band_high
  from dual
union all
select 'Band2' as band,
       1000   as band_low,
       1999   as band_high
  from dual
union all
select 'Band3' as band,
       2000   as band_low,
       5999   as band_high
  from dual 

これはSALARY_BANDS表に対する問合せにすることができますが、例示が目的であるため、より単純なこの問合せを使用しています。これにより、次のような3行の問合せ結果が生成されます。

BAND  BAND_LOW BAND_HIGH
----  -------- ---------
Band1 0        999
Band2 1000     1999
Band3 2000     5999 

Employeesビュー・オブジェクトを作成した後で、ビュー・リンクを作成します。このビュー・リンクは、各給与帯マスター行について、給与が現在の給与帯の高値と低値の間に該当する従業員のリストを表示します。ウィザードを使用してデフォルトのEmployeesビュー・オブジェクトを作成し、それをEmpエンティティ・オブジェクトに関連付けます。行セットの整合性機能を動作させるには、ディテール・ビュー・オブジェクトがエンティティ・オブジェクトにマップされる必要があります。

EmployeesWithinBandという名前のビュー・リンクをSalaryBandsビュー・オブジェクトとEmployeesビュー・オブジェクトの間に作成し、次のリンク元属性を選択します。

1. BandLow

2. BandHigh

また、一致する次のリンク先属性を選択します。

1. Sal

2. Sal

リンク先で参照する必要のある属性は1つのみであるため、Sal属性を2回選択したことに注意してください。デフォルトのAssociationアクセッサ名をオーバーライドし、よりわかりやすいEmployeesInBandという名前に変更します。これにより、SalaryBandsビューの各行でこの名前を使用して属性をプログラムで取得し、調整済のディテール・レコード・セットを取得できます。

ビュー・リンク・ウィザードの「関連付けSQL文」ページで、デフォルトのWHERE句をオーバーライドして次のようなカスタムWHERE句を作成します。

SAL BETWEEN :1 AND :2 

アプリケーション・モジュールを作成し、SalaryBandsビュー・オブジェクトをビュー・リンクでリンクされたディテールEmployeesビュー・オブジェクトとともにそのアプリケーション・モジュールに追加すれば、Business Component Testerを実行して、給与帯と、その給与帯に該当する従業員の問合せが機能することが確認できます。

ここで、RowFilterをインプリメントし、従業員の給与が該当する給与帯に基づいて、従業員行の挿入および更新が適切なディテール従業員コレクションに自動的にグループ化されるようにします。

package neq;
import oracle.jbo.domain.Number;
import oracle.jbo.server.RowFilter;
import oracle.jbo.server.ViewObjectImpl;
public class SalaryBandRowFilter implements RowFilter{
  private ViewObjectImpl _vo;
  private Object[]       _values;
  private float          _rangeLow, _rangeHi;
  // Filter to group rows into salary bands
  public SalaryBandRowFilter(ViewObjectImpl vo, Object[] values) {
    _vo       = vo;
    _values   = values;
    if (values != null && values.length <= 2) {
        _rangeLow = ((Number)values[0]).floatValue();
        _rangeHi  = ((Number)values[1]).floatValue();
    }
  }
  // Return the VOImpl we are associated with
  public ViewObjectImpl getViewObjectImpl() { return _vo; }
  // Return the number of parameters we were constructed with
  public int getParamLength() { return _values != null ? _values.length : 0; }
  // Return the source parameter values we were constructed with
  public Object[] getParamValues() { return _values; }
  // Test whether a candidate row's link attributes qualify for this filter
  public boolean paramQualifies(Object[] values) {
      if (values == null || _values == null) return false;
      if (values[0] == null) return false;
      float currentSal = ((Number)values[0]).floatValue();
      // Return true if current salary falls between _Low and _High
      return _rangeLow <= currentSal &&
                          currentSal <= _rangeHi;
  }
  public int getRowInitLength() {
    return 0;    // No Foreign Key values to initialize for new rows
  }
  public Object[] getRowInitValues() {
    return null; // No Foreign Key values to initialize for new rows
  }
  // This is not a null row filter
  public boolean isNull() { return false; }
} 

次に、Employeesビュー・オブジェクト（ディテール・ビュー・オブジェクト）のEmployeesImpl.javaファイルで、次のメソッドをオーバーライドします。（java.util.*をインポートするコードの追加が必要です。）

  // Return our custom row filter
  protected RowFilter buildRowFilter(Object[] paramValues) {
    return new SalaryBandRowFilter(this,paramValues);
  }
  // This method is called to retrieve row filters for a candiate row
  protected RowFilter[] getQualifyingRowFilters(Object[] rowParamValues) {
    Enumeration rowFilters = getRowFilters();
    Vector qualFilterVec = new java.util.Vector();
    while (rowFilters.hasMoreElements()) {
      RowFilter rowFilter = (RowFilter) rowFilters.nextElement();
      if (rowFilter.paramQualifies(rowParamValues)) {
         qualFilterVec.addElement(rowFilter);
      }
    }
    RowFilter[] retVal = new oracle.jbo.server.RowFilter[qualFilterVec.size()];
    qualFilterVec.copyInto(retVal);
    return retVal;
  }
  // This method is called when a candidate row does not
  // qualify any of the existing row filters
  protected RowFilter[] buildQualifyingRowFilters(Object[] rowParamValues) {
    // Do not create a row filter for missing bands
    return null;
  }
 

これらのオーバーライドは、カスタムRowFilterインプリメンテーションを使用することをフレームワークに通知し、候補行に一致する適切なフィルタの識別というフレームワークのニーズに応えます。最後に、次の処理を行うサンプルBC4Jクライアントを作成して、機能の動作を確認します。

1. neq.NeqModuleアプリケーション・モジュールに接続します。

2. 処理するSalaryBandsビュー・オブジェクトを検索します。

3. SalaryBandsビューの最初の行（Band1、0〜999）を取得します。

4. EmployeesInBandという名前のビュー・リンク・アクセッサ属性を要求することにより、現在の給与帯にあるディテール従業員の調整済セットを取得します。

5. 現在の給与帯である0〜999の範囲外の給与を持つ新規従業員行を、このコレクションに作成します。

6. 2番目の給与帯である1000〜2999にナビゲートします。

7. その行のEmployeesInBandという名前のビュー・リンク・アクセッサ属性を再度要求することにより、その給与帯にあるディテール従業員の調整済セットを取得します。

8. 取得するディテール行セットでsetAssociationConsistent(true)をコールし、キャッシュに整合性のある方法で内容が取得されるようにします（問い合わされた行に加えて保留中の新規/変更済の行を含む）。

9. 現在の給与帯で見つかったディテール従業員を反復し、新規に追加された従業員が、給与帯に基づいて適切なディテール行セットに自動的に移し替えられたことを確認します。

クライアント・コードは次のようになります。

import oracle.jbo.*;
import java.util.*;
import javax.naming.*;
import oracle.jbo.domain.Number;
public class TestClient {
  public static void main(String arg[]) throws Exception {
    // Modify this JDBC connection string to suit your database
    String jdbcURL        = "jdbc:oracle:thin:scott/tiger@localhost:1521:ORCL";
    String appModuleName  = "neq.NeqModule";
    // Setup the hashtable of JNDI initialization parameters
    Hashtable env = new Hashtable(2);
    env.put(Context.INITIAL_CONTEXT_FACTORY, JboContext.JBO_CONTEXT_FACTORY);
    env.put(JboContext.DEPLOY_PLATFORM, JboContext.PLATFORM_LOCAL);
    // Create an JNDI initial context
    Context ic = new InitialContext(env);
    // Lookup a home interface (factory) for the AppModule by name
    ApplicationModuleHome home =(ApplicationModuleHome)ic.lookup(appModuleName);
    // Create an instance of the AppModule using the home/factory
    ApplicationModule am = home.create();
    // Connect the application module to the database
    am.getTransaction().connect(jdbcURL);

    // Find the "SalaryBands" view object by name in the app module
    ViewObject vo_Bands = am.findViewObject("SalaryBands");

    // Get the first row of its result set, executing query if needed
    Row row_Bands = vo_Bands.first();

    RowSet details = (RowSet)row_Bands.getAttribute("EmployeesInBand");

    // Create a new employee row in this rowset
    // Since its salary falls outside of the 0-999 band,
    // it should get automatically moved to the rowset
    // for the second band 1000-1999
    Row new_Emp = details.createRow();
    new_Emp.setAttribute("Empno",new Number(1111));
    new_Emp.setAttribute("Ename","Steve");
    new_Emp.setAttribute("Sal", new Number(1475));
    details.insertRow(new_Emp);

    row_Bands = vo_Bands.next(); // Get Band 2
    details = (RowSet)row_Bands.getAttribute("EmployeesInBand");
    details.setAssociationConsistent(true);
    while (details.hasNext()) {
      Row row_Emp = details.next();
      System.out.println(row_Emp.getAttribute("Ename"));
      System.out.println(row_Emp.getAttribute("Sal"));
    }
    // Disconnect the application module
    am.getTransaction().disconnect();

  }
} 

リモートに配布されたビジネス・コンポーネント・プロジェクトのアップグレードは、次の手順で行います。

1. アプリケーション・モジュール・エディタの「リモート」タブをクリックし、すでに選択されている配布プラットフォームをハイライトしてから「完了」をクリックすることにより、トップレベルのアプリケーション・モジュールを再びリモートにします。

2. ビジネス・コンポーネント・プロジェクトを対象プラットフォームに再び配布します。

3. 必要に応じて、再生成されたクライアントJARファイルでクライアント・プロジェクトを更新します。

4. クライアント・プロジェクトを再配布します。

クライアントが、TreeControlを使用するDACアプレットまたはアプリケーションの場合は、TreeControlを正しく動作させるために、複数層起動用の-DnullString=trueスイッチも組み込む必要があります。

デフォルトでは、DACナビゲーション・バーのリフレッシュ・インプリメンテーションは、次の手順で処理されます。

1. BC4JおよびDACのトランザクション・コンテキストをロールバック

2. すべてのセッションRowSetInfoオブジェクトの問合せを再実行

3. すべてのセッションRowSetInfoオブジェクトの行の流用をリセット

ただし、大規模なDACアプリケーションでは、すべてのセッションRowSetInfoオブジェクトの問合せをロールバック・インプリメンテーションによって積極的に実行する必要はありません。かわりに、そのようなアプリケーションでは、現在表示されているコントロールをサポートするRowSetInfoオブジェクトのみを再問合せする必要があります。

大規模なアプリケーションの要件を満たすために、DACナビゲーション・バーは、トランスポータブルなリフレッシュ・インプリメンテーションをサポートしています。拒否可能なボタン・クリック・リスナーをナビゲーション・バーに追加することにより、アプリケーション開発者は、ユーザーがDACナビゲーション・バー上のリフレッシュ・ボタンをクリックしたときに実行されるカスタム・リフレッシュ・インプリメンテーションを追加できます。拒否可能なリスナーは、あらゆるロールバック・イベントをリスニングする必要があります。ロールバック・イベントが検出されると、このリスナーがカスタム・リフレッシュ・インプリメンテーションを実行します。カスタム・リフレッシュ・インプリメンテーションが実行された後、リスナーはイベントを拒否することによってデフォルトのインプリメンテーションを短絡し、それが実行されないようにします。

カスタム・リフレッシュ・インプリメンテーションでは、アプリケーションで要求される任意のリフレッシュ処理を実行できます。ただし、BC4JおよびDACのトランザクション・コンテキストをロールバックするには、ほとんどのインプリメンテーションでリフレッシュが要求される可能性があります。この要求をサポートするために、カスタム・リフレッシュ・インプリメンテーションでは次の処理を実行する必要があります。

1. DACトランザクション・コンテキストが使用済かどうかをチェック

2. DACトランザクション・コンテキストが使用済の場合には、次の処理を実行
   1. BC4Jトランザクション・コンテキストをロールバック

   2. DACトランザクション・コンテキストが未使用であることをマーク

   3. DACトランザクション・コンテキストが有効であることをマーク

3. アプリケーション固有のリフレッシュ・ロジックを実行して表示可能な行セットをリフレッシュし、行の流用をリセット、等

手順1から2のcは、トランザクション・コンテキストをロールバックする際にデフォルトのリフレッシュ・インプリメンテーションが実行する手順と同じです。

次のサンプル・クラスでは、カスタム・リフレッシュ・インプリメンテーションを追加するために使用されるナビゲーション・バー・ボタンのリスナーのインプリメンテーションを示しています。サンプル・コードとしての目的上、アプリケーション要件については多くの前提条件があります。たとえば、次のような点です。

1. NavigationBarは、グリッド・コントロールによっても表示されるEmpViewデータ項目に静的にバインドされます。

2. リフレッシュ・インプリメンテーションは、ディテールEmpViewのRowSetInfoの問合せを再実行するためにのみ必要とされます。行の流用をリセットするためのリフレッシュ、マスターDeptViewのRowSetInfoの問合せを再実行するためのリフレッシュ、あるいは現在表示されている他のコントロール（すなわちDACのTreeControl）をリフレッシュするためのリフレッシュは不要です。

      public class MyNavigationBarListener implements NavigationBarButtonClickListener 
      { 
        public void navigationBarButtonClicked(NavigationBarButtonClickEvent event) 
        throws NavigationBarButtonClickVetoException
        { 
          if (NavigationBar.BUTTON_ROLLBACK == event.getButtonClicked())
          { 
            doRollback();
            throw new NavigationBarButtonClickVetoException("X");
          } 
        }
        private void doRollback()
        { 
          try
          {
            Frame1.getInstance().masterNavBar.showBusyCursor();
            SessionInfo sessionInfo = Frame1.getInstance().sessionInfo;
            // Only if the sessionInfo has been instantiated and has been opened
            if (sessionInfo != null && sessionInfo.isOpen())
            { 
              // If pending changes exist 
              if (sessionInfo.isDirty())
              {
                // Rollback the BC4J transaction
                sessionInfo.getApplicationModule().getTransaction().rollback();
                // Reset the state of the DAC session. 
                sessionInfo.clearDirty();
                sessionInfo.forceValid();
                } 
                // Execute the application specific refresh logic 
              doRefresh();
            } 
          }
          finally
          { 
            Frame1.getInstance().masterNavBar.restoreDefaultCursor();
          }
        }
        private void doRefresh()
        {
          // Perform application specific refresh logic 
          // For instance, re-execute the queries for the RowSetInfos that are 
          // bound to the currently visible controls 
          Frame1.getInstance().EmpViewDetailIter.executeQuery(); 
        }
      } 

ここでFrame1.getInstance()は、アプリケーションのエントリ・ポイントでインスタンス化される単一フレームのインスタンスを返すstaticメソッドです。

MyNavigationBarListenerをインスタンス化および登録するためには、ナビゲーション・バーを使用する前に次のようなインプリメンテーションが必要です。

    masterNavBar.addVetoableNavigationBarButtonClickListener(new MyNavigationBarListener());

ここでmasterNavBarは、EmpViewDetailIterにより生成されるデータ項目に静的にバインドされるNavigationBarのインスタンスです。

注意: 上のソリューションは、ユーザーがDACナビゲーション・バー上のリフレッシュ・ボタンをクリックする場合にのみ適用されるものです。アプリケーション開発者が、SessionInfo.getDbAccess().rollbackTransaction()を使用してコード中でロールバックを強制した場合には、そのコードを移植してカスタム・インプリメンテーションを使用するか、または問合せを再実行せずにBC4JおよびDACのトランザクション・コンテキストをロールバックする別のカスタム・インプリメンテーションを使用する必要があります。

JDeveloper 3.2では、Data Web Beanは、デフォルトのリクエスト・スコープ設定で使用した場合に最適に機能します。JSPエレメント・ウィザードでは、アプリケーション、セッション、ページおよびリクエストのスコープ設定を使用できますが、デフォルトのスコープ・オプションであるリクエストを常に使用することをお薦めします。スコープを変更すると、複数のユーザーがページにアクセスする際に信頼性のない結果が生成されることがあります。

JDeveloper 3.2では、JSPアプリケーション・モジュール・リソースを管理するためのモードとしてステートフル・モードが新規に追加されます。これに伴い、JDeveloper 3.1でステートフル・モードと呼ばれていたモードはリザーブド・モードに置き換わります。JDeveloper 3.2のリザーブド・モードは、HTTPセッションの継続時間全体にわたってアプリケーション・モジュールの制御を維持しますが、新しいステートフル・モードは、JSPページがアプリケーション・モジュールを解放するとき（ReleasePageResourceデータ・タグまたはreleasePageResource()メソッドをData Web Beanについて検出したとき）に、アプリケーション・モジュールの状態をデータベースにキャッシュします。リザーブド・モードでのみ、セッション中にユーザーが変更したデータが、別のユーザーにより変更されないことが保証されます。ステートフル・モードはデータを保持し、後続のセッションでそのデータを復元できますが、格納されたデータに対して行われた変更は、新規アプリケーション・モジュール・インスタンスがデータベースから状態を復元する際に反映されます。

「プロジェクト・プロパティ」ダイアログの「コンパイラ」タブでプロジェクトのエンコーディングを設定することにより特殊なキャラクタ・セット・エンコーディングをJSPアプリケーションで使用する場合は、Oracle JSPサーバーのzone.propertiesファイルでtranslate_paramsオプションをtrueに設定する必要もあります。

JDeveloperのビジネス・コンポーネント・プロジェクト用にJSPクライアント・プロジェクトを作成する場合は、JSPプロジェクトがビジネス・コンポーネントの出力ルート・ディレクトリにアクセスできることを確認する必要があります。アクセスできない場合は、クライアントがビジネス・コンポーネントのクラス・ファイルの位置を特定できないため、ランタイム・エラーが発生します。出力ルート・ディレクトリが両方のプロジェクトで同じでない場合は、「プロジェクト・プロパティ」ダイアログを使用し、ビジネス・コンポーネントのクラスパスを定義するJSPプロジェクト用の新規ライブラリを作成します。「ライブラリ」タブを選択して「ライブラリ」、「追加」、「新規」の順にクリックし、JSPクライアント・ライブラリの名前を指定し、ビジネス・コンポーネント・クラスを含むディレクトリ（たとえば、C:\JDeveloper3.2.3\myclasses\OnlineOrdersなど）を入力します。または、「プロジェクト・プロパティ」ダイアログの「パス」タブで、両方のプロジェクトに対して同じ出力ルート・ディレクトリを設定します。

サーブレットの初期化パラメータは、構成ファイルで設定可能です。これはwebtogo.oraという名前のファイルで、<JDeveloper_Home>\libにあります。

このファイルの[SERVLET_PARAMETERS]という領域に、サーブレット・パラメータを追加できます。たとえば、 （webtogo.oraファイルで）次のようにします。

[SERVLET_PARAMETERS]
My_Init_Parameter=My_Value
 .
 .
 .
 

この値を取得するには、サーブレットで次のようなコードを使用します。

// Global String to retrieve value
String my_init_val;

// Overidden Init method with getInitParameter call.
 public void init(ServletConfig config) throws ServletException {
    super.init(config);
     my_init_val = getInitParameter("My_Init_Parameter");
  }

 

注意:　 これらのパラメータは、システム共通です。また、この機能はJDeveloperの3.2以降のリリースで変更される場合があります。

JDeveloper 3.2には、JDKの切換え機能があります。この機能により、Java Development Kitの新しいバージョンをIDEに追加することが可能です。JDeveloperリリース3.2には、JDK 1.2.2（デフォルト）およびJDK 1.1.8が含まれています。現在JavaSoftではJDK 1.3がリリースされています。JDK 1.3は、JDeveloper 3.2には含まれませんが、http://java.sun.com/products/jdk/1.3/ja/から無償でダウンロード可能です。

注意:　 JDK 1.3は、Javadocに含まれていません。これらのドキュメントは、http://java.sun.com/j2se/1.3/ja/docs.htmlから無償でダウンロードできます。Javadocは、JDK 1.3ホーム・ディレクトリに解凍することをお薦めします。Java2 SDKドキュメントの詳細は、JDK 1.3のリリース・ノートを参照してください。

1. JDeveloperをC:\Program Files\Oracle\JDeveloper 3.2.3\にインストールしてある場合は、JDK 1.3をディレクトリC:\Program Files\Oracle\JDeveloper 3.2.3\jdk1.3にインストールします。

2. C:\Program Files\Oracle\JDeveloper 3.2.3\java1.2\jre\binディレクトリから、ovjmディレクトリと、fdebug.exeおよびfdebug_g.exeの2ファイルを、C:\Program Files\Oracle\JDeveloper 3.2.3\jdk1.3\jre\binにコピーします。

3. C:\Program Files\Oracle\JDeveloper 3.2.3\jdk1.3\jre\lib\jvm.cfgのファイルを編集します。このファイルには、このリリースでサポートされるJava仮想マシン（JVM）がリストされています。JDK 1.3でOracle JVM（Oracleによる拡張されたJVM、OJVM）を実行させるには、次の行を追加します。

   -ojvm 

注意:　 jvm.cfgファイルでの各JVMの順序は重要です。リストの1番目のJVMがデフォルトのJVMになります。

手順2および3を自動的に実行するために、InstallOJVM.batというバッチ・ファイルが用意されています。これは、<JDeveloper_Home>\binディレクトリ内にあります。

1. JDeveloperを起動し、「ツール」メニューから「デフォルトのプロジェクト・プロパティ」を選択します。「ターゲットのJDKバージョン」プルダウン・メニュー・ボックスの隣にある「定義」ボタンをクリックします。

2. 「使用可能なJDKのバージョン」ダイアログが表示されます。「新規」ボタンをクリックし、次に「...」ボタンをクリックして、JDK 1.3のjava.exeを検索するか、またはJDK 1.3のディレクトリ内のjava.exeまでのパスを入力します。

3. java.exeへのパスを選択すると、「クラスパス」および「ソースパス」テキストボックスのパスは自動的に決定されます。Javadocもダウンロードしインストールした場合は、ドキュメント・パスも挿入されます。「使用可能なJDKのバージョン」リストにJDK 1.3が追加されます。

4. 「OK」をクリックし、ダイアログを閉じます。

5. 「ターゲットのJDKバージョン」プルダウン・メニュー・ボックスからJDK 1.3を選択して「OK」をクリックし、変更した「デフォルトのプロジェクト・プロパティ」を確定します。

これで、JDeveloper 3.2を使用してJavaアプリケーションを開発する際にJDK 1.3を使用できるようになります。新規プロジェクトにデフォルトとしてJDK 1.3を使用する場合は、「デフォルトのプロジェクト・プロパティ」ダイアログの「ターゲットのJDKバージョン」プルダウン・メニュー・ボックスで、JDK 1.3が選択されていることを確認してください。既存プロジェクトに対しては、JDK 1.3を使用する際に「ターゲットのJDKバージョン」を変更する必要があります。

JDeveloper 3.2の一部はJavaでプログラムされているため、それ自体に新しいJDK 1.3を利用することも可能です。これには次の3つの方法があります。

• Windows NTのコマンド・プロンプトを使用し、次のコマンドでJDeveloper 3.2を起動します。

  <JDeveloper_Home>\bin\jdeveloper -jdk=1.3.0 

• スタート・メニューに、jdeveloper.exeへの新規ショートカットを作成します。ショートカットを右クリックし、「プロパティ」ダイアログの「ショートカット」タブで、「リンク先:」テキストボックスに前述のコマンドを入力します。

• JDeveloperの初期化ファイルを、次のようにして変更します。

  1. JDeveloper 3.2を終了します。

  2. <JDeveloper_Home>\bin\jdeveloper.iniファイルを開きます。

  3. [Java_2]のセクションまでスクロールします。パラメータを、次のように置き換えます。
         変更前:　JDK=java version "JDK1.2.2_JDeveloper"
         変更後:　JDK=java version "1.3.0"
     

  4. ファイルを保存します。

  5. JDeveloperの次の起動時には、JavaプラットフォームとしてJDK 1.3が使用されるようになります。

変更が有効かどうかを確認するには、JDeveloper 3.2を起動して「ヘルプ」 -> 「バージョン情報」を選択します。アイコンの下に、次のように表示されます。

1.3.0
OJVM

OJVMがインストールされていないJDKでローカル・デバッグをする場合、特に指定がない限り、JDeveloperはデフォルトのJVM設定を使用します。SunのJDK 1.3を使用する場合、ホットスポットがデフォルトですが、ホットスポットのデバッグのインプリメンテーションには問題があります。したがって、OJVMがインストールされていないJDK 1.3でローカルにデバッグする場合は、デバッグの実行時に-classicパラメータを使用してください。

JDeveloper 3.2を入手する前にOracle9i Application Serverを入手した場合は、最新のビジネス・コンポーネント・ライブラリがない可能性があります。これらのライブラリを追加し、クラスパスにその一部を含めることにより、Oracle9i Application Serverを更新する必要があります。

Oracle9i Application Serverを更新するには

1. <JDeveloper_Home>\libから<Oracle_Home>/Apache/BC4J/libに次のファイルをコピーします。

        connectionmanager.zip
        jbo8iclient.zip
        jbocmp.zip
        jbodatum111.zip
        jbodatum12.zip
        jbodomgnrc.zip
        jbodomorcl.zip
        jbodt.zip
        jboejb.jar
        jbohtml.zip
        jboimdomains.zip
        jbojdbcpatch.zip
        jbomt.zip
        jboo8i.zip
        jboremote.zip
        jboremoteejb.zip
        jbotester.zip
        jbovb.zip
        jbovbclient.zip
        ordhttp.zip
        ordim817.zip
        ordvir817.zip  

   これらのファイルには、ターゲット・ディレクトリ内に既存のバージョンを持つものもあります。これらのファイルは新規バージョンで置換してください。

2. テキスト・エディタでjserv.propertiesファイルを編集します。このファイルは、UNIXでは<Oracle_Home>/Apache/Jserv/etc、Windows NTでは<Oracle_Home>\Apache\Jserv\confディレクトリにあります。

3. コメントで始まるブロックを検索します。

        # OJSP environment settings 

4. 次の行が存在することを確認します。

   
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/connectionmanager.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbocmp.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbodatum111.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbodatum12.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbodomgnrc.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbodomorcl.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbodt.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbohtml.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jboimdomains.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbojdbcpatch.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbomt.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jboremote.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/jbotester.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/ordhttp.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/ordim817.zip
        wrapper.classpath=<Oracle_Home>/Apache/BC4J/lib/ordvir817.zip  

この手順を完了した後で、WebアプリケーションをOracle9i Application Serverに配布する通常の手順に従うことができます。

Oracle JDeveloper 3.2は、EJB 1.1のみサポートしています。EJB 1.0アプリケーションを扱う開発者は、EJB 1.0をサポートしているOracle JDeveloper 3.1を使用する必要があります。（JDeveloper 3.1は、EJB 1.1をサポートしていません。）

JDeveloper 3.1を使用して作成したEJBの自動的な移行はサポートされていませんが、EJB 1.0クラスを参照する1.1仕様と互換性のある新規EJBを作成することは可能です。新規EJBデザイナおよび配布ツールを使用し、EJBの開発を継続できます。

JDeveloperの外部で開発したEJB 1.1準拠のクラスをすべてインポートし、EJBデザイナで開発を継続することもできます。

EJB 1.0クラスをJDeveloperに移行するには、次の手順を実行します。

1. 新規JDeveloperプロジェクトを作成するか、既存のプロジェクトを選択します。

2. EJBウィザードを起動します（「ファイル」 -> 「新規」 -> 「Enterprise JavaBean」）。

3. 既存のEJBのEJBタイプを選択します。必要に応じて、名前を変更します。

4. 3つのデフォルトEJBクラス名（Beanクラス、ホーム・インタフェースおよびリモート・インタフェース）を置換します。

5. エンティティEJBを移行する場合は、「次へ＞」をクリックした後のページで、主キー情報を入力してください。

6. 「次へ＞」をクリックし、EJBクラスのパッケージとEJBソース・ファイルへのソースパスを指定します。

7. 「次へ＞」をクリックしてEJBの情報を確認します。パス、パッケージ、名前などの選択内容を修正する必要がある場合は、「＜戻る」をクリックして変更します。

8. 「完了」をクリックします。既存のソース・ファイルのパスを指定した場合、EJBウィザードにより、既存のファイルを変更せずに受け入れるか、EJBウィザードで上書きするかの確認が求められます。一般には、変更せずに受け入れます。

   EJBウィザードは、終了時に、新規EJBの配布記述子をXML形式で作成します。自動的に開くEJBデザイナでEJBの開発を継続できます。EJBデザイナはJDeveloper 3.2の新機能であり、EJBとその配布記述子プロパティを編集する場合に使用できます。「XML」タブを選択し、XML配布記述子の現在の状態を表示できます。

9. EJB 1.1仕様に準拠するよう、EJBを変更します。EJBをOracle8i に配布する配布プロファイルを作成するには、プロジェクトに追加されたEJBフォルダを右クリックし、「EJB/8i 配布プロファイルの作成...」を選択します。

既存のEJB 1.1クラスをJDeveloper 3.2に移行するには、次の手順を実行します。

1. 前述の手順1〜8を実行します。

2. プロジェクトに追加されたEJBフォルダを右クリックし、「EJB/8i 配布プロファイルの作成...」を選択します。

3. CMPエンティティEJBを移行した場合は、最初に複数のウィザードを実行してCMPマッピング情報を指定します。その他のタイプのEJBでは、EJB/8i 配布プロファイル・ウィザードが開始されます。

4. 「出力」タブを選択し、「EJB記述子」フィールドを編集して、EJB 1.1配布記述子を編集します。Oracle固有のEJB 1.1配布記述子ファイルがある場合は、そのファイル名を「Oracle記述子」フィールドに入力します。

5. 「完了」をクリックしてプロファイルを閉じ、変更を保存します。.prfファイルは、配布記述子ファイルとともにプロジェクトの「配布」フォルダに追加されます。

6. プロファイルを開き直し、各タブにアクセスして配布記述子の詳細を確認し、IIOP接続を指定して配布します。

注意:　 JDeveloper 3.2は、EJB自体の独立した配布記述子を保持します。この配布記述子は、EJBを配布するために作成された各配布プロファイルに関連付けられている配布記述子から分離されています。この動作は意図的なものであり、ソースEJB自体には影響を与えずに、場合によっては異なるプロパティを使用して複数のターゲット・サーバーにEJBを配布できます。ソースEJBの配布記述子は、ディスク上で .ejxファイルにキャプチャされます。各EJBプロファイルの配布記述子はユーザー指定ですが、デフォルトでは .xmlファイルとして生成されます。記述子内のすべてのプロパティはEJBデザイナまたはEJB配布プロファイル・ウィザードを介して編集できるため、.ejxファイルの直接ユーザー変更はサポートされていません。

JDeveloper 3.2以降、コード・インサイト・バックグラウンド調査は、デフォルトではオンになりません。コード・インサイトを有効にする場合は、メニュー・バーの「ツール」を選択し、「環境オプション」をクリックします。「コード・インサイト」タブを選択し、「バックグラウンド調査」をクリックします。「バックグラウンド調査」をデフォルトで無効にすることにより、コード・エディタは不明なタイプを赤で表示しなくなります。メンバーとクラスの完了は使用できます。

「必要なライブラリを追加する方法」の手順5では、「Oracle Intermedia｣および「SQLJ Runtime」を追加するよう指示しています。ここではさらに、「Oracle 8.1.7 JDBC NLS Support」も追加してください。

このチュートリアル・トピックの最終手順では、次のコマンドでクライアントを実行するよう指示しています。

jre javagui.TestClient
jre javagui.TestClient2

jreはシステムの環境変数からクラスパスを使用しません。かわりに、次のコマンドを使用してください。

java BatchClient.TestClient
java BatchClient.TestClient2

3層モードでの実行は、ヘルプに記載されている手順に加えて、いくつかの追加手順が必要であることが報告されています。これに関する詳細情報は、OTN-Jにて公開される予定です。

SQL92ベースのBC4Jを作成した場合、エンティティ・オブジェクトの属性の「リフレッシュ」のプロパティは無視されます。つまり、表の列がデータベース・トリガーを介して更新された場合、BC4Jにはそれが通知されません。

ヘルプなどのドキュメントに記述されている以下の機能は、日本語環境ではサポートされません。

• Oracle8i Liteに対する接続のサポート
• ビジネス・コンポーネントの接続先としてのOracle以外のデータベースのサポート
• WebLogicへのEJBコンポーネントの配布
• 任意のVisiBroker ORBに対するCORBAオブジェクトの配布

OnlineOrdersForClients.jws内のプロジェクトを、日本語環境上のOracle8i 8.1.7に対して実行すると、次のエラーがスローされます。

Non supported character set:  oracle-character-set-832

Non supported character set:  oracle-character-set-830

回避方法として、Oracle 8.1.7 JDBC NLS Supportライブラリをプロジェクトに手動で追加し、再ビルドします。

JSPまたはHTMLファイルに含まれる一部のHTMLタグに囲まれた日本語文字は、ビューア上には正しく表示されません。これは、通常のブラウザでは正しく表示されます。

ビジネス・コンポーネントJSPアプリケーション・ウィザードを使用して作成したJSPアプリケーションを実行した際、表示されるボタン・ラベルや文字列が翻訳されていません。これは、サード・パーティのJSUIベース・コンポーネントを使用しているためです。今後のリリースではJSUIベース・コンポーネントは使用されず、この問題は修正される予定です。

Business Components for Javaアプリケーションにおけるデータのフェッチ・サイズに関する初期設定値について（1325995）

日本語版の JDeveloper 3.2 では、BC4Jアプリケーションに対するデータのフェッチ・サイズの初期設定が変更されています。これはマルチバイト・データの取り出し時に起こるJBO-27022を回避するためです。

この設定は oracle.jbo.server.jboserver.propertiesファイル（jbomt.zipにあります）のoracle.jbo.defineColumnLengthで指定されています。このフラグをfalseに設定すると、Business Components for Javaは、フェッチする列の型を定義する際にJDBCにmax-data-lengthを渡しません。これによってJDBCは、（JDeveloper 3.0および3.1と同じように）フェッチされるVARCHAR2列あたりほぼ2Kを事前に割り当てます。

シングルバイト環境で、より高いパフォーマンスを得るためにこの設定を変更することができます。jbomt.zip内のoracle.jbo.server.jboserver.propertiesファイルを編集する、または環境設定で定義するか、/Dオプションを使用してJavaVMにコマンドライン・パラメータとして渡すことで設定できます。

デフォルトのプロジェクト・プロパティのエンコーディング設定の変更について

日本語版の JDeveloper 3.2 では、デフォルトのプロジェクト・プロパティのエンコーディング設定としてMS932を採用しています。この環境下では、JSP、サーブレット、XMLなどのWebアプリケーション・ファイルを作成する際に、SHIFT_JISのエンコーディング情報が追加されます。詳しくは、リリース3.2における既知の問題の「Webアプリケーション(JSP、XML、サーブレット)に追加されるキャラクタ・セットの設定」の項も参照してください。

JDeveloperにビルトインされたサーブレット・エンジンでの日本語名ファイルの呼出しについて

1. <JDeveloper_Home>\lib\webtogo.oraをテキスト・エディタで開きます。
2. [WEBTOGO]セクションにある_DISABLE_NLS_DECODINGの記述をコメントアウトします（行頭に#を付けます）。
3. [SERVLET_PARAMETERS]セクションにあるtranslate_paramsの記述をコメントアウトします(行の先頭に#を付けます)。

これらのパラメータをコメントアウトすることにより、JDeveloperにビルトインされたサーブレット・エンジン上での日本語名ファイルの呼出しが可能になりますが、逆に、サーブレットおよびXSQLアプリケーションでの日本語処理の動作が、一般的なアプリケーション・サーバー上での実行時と異なってしまうことに注意してください。したがって、これらのパラメータのコメントアウトは、日本語名のJSPファイルを使用したテストの時にのみ使用してください。なお、URL内にASCII以外の文字を使用することは推奨されていません。関連する情報として、「クラス名、JSPファイル名およびサーブレット名に対するマルチバイト文字の使用について」および「JSPアプリケーション作成に影響するビュー・オブジェクト名および属性名について」も参照してください。

JDK 1.1.Xを使用する場合、クラス名、JSPファイル名およびサーブレット名には英数文字を用いるようにしてください。マルチバイト文字はClassNotFound例外の原因となります。JDK 1.2.Xを使用する場合には、mainメソッドを含むクラス名、JSPファイル名およびサーブレット名に対してのみこの問題が発生します。

この問題は、特にビジネス・コンポーネントの作成の際には注意が必要です。ビジネス・コンポーネント・ウィザードは、デフォルトでは指定されたデータベース表および列の名前を利用した名前のエンティティ・オブジェクトおよびビュー・オブジェクトを作成します。いくつかのアプリケーション・ウィザードは、他の機能やオブジェクトを作成するために、これらの名前を利用しています。これについては「JSPアプリケーション作成に影響するビュー・オブジェクト名および属性名について」の項も参照してください。

JSPアプリケーション作成に影響するビュー・オブジェクト名および属性名について(1660019)

ビジネス・コンポーネント・ウィザードは、指定されたデータベース表および列の名前を利用して、ビュー・オブジェクトおよびその属性の初期の名前を作成します。これによって、以下のような問題が発生する可能性があります。

• JSPファイル名の問題

  ビジネス・コンポーネントJSPアプリケーション・ウィザードはビュー・オブジェクトの名前から自動的にJSPファイル名を決定します。一般に、JSPファイル名がマルチバイト文字の場合、うまくURLとして取り扱われない場合があります（FileNotFoundException）。これはURLの仕様としても推奨されていません（RFC1738も参照してください）。

• JavaScript関数名の問題

  JavaScript（JScript）ではマルチバイト文字を使った名前の関数を認めていません（これはJavaScriptの仕様です）。しかし、以下のような場合に、マルチバイト文字を使った名前の関数が作成され、その結果、JavaScriptエラーが発生します。

1. ビジネス・コンポーネントJSPアプリケーションのテンプレートとしてOracleテンプレートを用いた場合。この場合、実行時に、Date型の属性に対して、属性名を使ったJavaScript関数が動的に作成されます（これによってカレンダー表示機能を実現します）。

2. JSPエレメント・ウィザードによって挿入される一部のJSPタグ（例えばInsertSelectLOVなど）。これらによって、実行時に、指定された属性名を使ったJavaScript関数が動的に作成されます。

上記の問題を避けるため、ビュー・オブジェクトおよびその属性の名前は英数文字に変更することをお薦めします。

サンプル: JSPアプリケーション（<JDeveloper_Home>\sample以下のJSPファイル）での日本語の処理について

サンプルとして付属するJSPファイルはWINDOWS-1252のエンコーディング設定で作成されています。このため、日本語の処理に問題があります。回避方法として、JSPファイル内のキャラクタ・セットの指定をSHIFT_JISに変更してください。

日本語で登録されたカスタムJSPテーマ名が文字化けする(1710311)

カスタムJSPテーマの名前を日本語にして登録すると、ウィザードからの選択時に文字化けして表示されます。これはウィザード上の表示の問題で、機能的には問題ありません。

接続エラーメッセージが文字化けする(1711596)

Connection ManagerやBusiness Component Testerの接続エラーメッセージが文字化けします。これはJDBC Driver 8.1.7固有の問題です。

Javaストアド・プロシージャのリモート・デバッグが文字化けする(1693829)

Javaストアド・プロシージャのリモート・デバッグに対するメッセージ・ウィンドウでの表示結果が文字化けします。Javaストアド・プロシージャ以外のリモート・デバッグに対しては問題ありません。

サンプル: OnlineOrders.sqlの実行時にORA-01858が発生する(1721086)

日本語環境において、samples\Bc4j\OrderEntry\DatabaseSetup\OnlineOrders.sqlをSQL*Plusから実行するとORA-01858が発生します。これはDate型に対する書式指定が異なるためです。回避方法として、OnlineOrders.sql をテキスト・エディタで開いて、2行目に、次の1行を追加してください。

ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YY';

サンプル: インストラクション用のHTMLについて

サンプル・アプリケーション用プロジェクトの中には、その内容を解説するHTMLファイルが付属しているものがあります。これらのうち、次に示すものについては、日本語に翻訳された同等の内容をヘルプから参照できます。

• <JDeveloper_Home>\samples\BC4J\bc4jauctions\scriptimages\BC4JAuctions.html

  <ヘルプでの位置>
  「チュートリアルおよびサンプル・アプリケーション」

  ->「サンプル・アプリケーション」
  ->「Business Components for Javaを使用したAuctionsサンプルWebアプリケーション」
  
  
• <JDeveloper_Home>\samples\SampleAddins\JavaDocWizard\JavaDocWizardInstructions.html

  <ヘルプでの位置>
  「チュートリアルおよびサンプル・アプリケーション」

  ->「サンプル・アプリケーション」
  ->「アドインの例: Javadocウィザード」
  
  
• <JDeveloper_Home>\samples\stylemanager\Documentation\StyleDemo.html

  <ヘルプでの位置>
  「ビジネス・コンポーネント・データ・フォームの開発」

  ->「データ・フォーム・クライアント・ランタイムのプログラミング」
  ->「データ・フォーム用Style Managerアプリケーションの作成」
  
  ->「データ・フォーム・プロジェクトでのサンプルStyle Manager」
  
  
  
• <JDeveloper_Home>\samples\xmlsamples\Intro.html

  <ヘルプでの位置>
  「ビジネス・コンポーネントの開発」

  ->「XMLの使用」
  ->「XMLパーサーの使用方法」

「ヘルプ」メニューに含まれる「Oracle Technology Network」および「Oracle Java Education」を選択した場合に表示されるWebページの内容は、米国オラクル社によるものです。対応する日本のサイトとして、以下をご利用ください。

Oracle Technology Network Japan（OTN-J）

http://otn.oracle.co.jp

日本オラクル

http://www.oracle.co.jp/seminar

Solaris上のOracle8i 8.1.7にJDeveloper 3.2からEJBを配布することはできません。この問題は、Windows NT上のOracle8i 8.1.7では発生しません。この問題に関する詳細は、OTN-Jを参照してください。

Javaメソッドの宣言を含むJSPをデバッグする際、正常に動作しない場合があります。

BC4JをEJBとしてOracle8i 8.1.7に配布している間に、JDeveloperのメッセージ・ビューに「ORA-29552: verification warning」が表示されます。この警告は配布されたアーカイブまたはEJBには影響ありません。

Solaris上のJavaサーブレットまたはJavaServer Pagesをリモート・デバッグするためには、Solaris上でJDK 1.2.2_007のリファレンス・インプリメンテーションおよびJPDA 1.0を使用する必要があります。どちらも、http://www.javasoft.comから入手可能です。JPDAは、JDKと同じディレクトリにインストールされる必要があります。また、<JDeveloper_Home>\libからojc.jarをSolarisマシン上にコピーし、JavaサーブレットまたはJavaServer Pagesを実行しているApplication Serverのクラスパスにそれを含める必要があります。他の設定は、すべてWindows NTの設定方法と同じです。

JDeveloper 3.2.3は、デフォルトではシングル・プロセッサのみサポートしています。JDeveloperでマルチ・プロセッサを使用する場合は、<JDeveloper_Home>\bin\jdeveloper.iniで次のように設定します。

    DualProcessorDisableAlways=0

一部のシステムでは、これにより動作に不具合が発生することが確認されています。上の変更を行い、JDeveloperの動作に不具合が生じた場合は、DualProcessorDisableAlwaysの設定を1に戻し、マルチ・プロセッサのサポートを使用不可にしてください。

ソース・コントロールで、Version History Viewer/Version Event Viewerが起動不可（1719021）

Oracleホームの構成によっては、「ソース・コントロール」メニューから起動した際に、Version History ViewerおよびVersion Event Viewerが表示されない場合があります。これは、Repository 6i クライアントを新規のOracleホームにインストールする前に、それ以外のOracleクライアント製品を含むOracleホームがインストールされている場合にのみ発生します。

この問題を回避するには、PCにあるOracleホームのうち最初のものが、必ずRepository 6i クライアントとなるようにしてください。もしくは、Repository 6i のOracleホームを除くすべてのOracleホームに対して、レジストリHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\HOMEx\TNS_ADMIN（xはそれぞれのOracleホームを表す数値）を設定して、その変数で、Repository 6i のホームにあるnet80\adminディレクトリのフルパスを指すよう変更します。

たとえば、次のソフトウェアを次の順にインストールしたとします。

• c:\Dev_Homeに、Oracle Developer

• c:\Reposに、Repository 6i

• c:\8i_impexpに、Import/Export Tool（Oracle8i ）

HEKY_LOCAL_MACHINE\SOFTWARE\Oracle\の下に、Developer、RepositoryおよびImport/Exportのそれぞれに対するHOME0、HOME1およびHOME2の3つのレジストリ・キーがあるはずです。c:\Repos\net80\adminを指すように、それぞれのホームのキー、すなわちHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\HOME0\TNS_ADMINおよびHKEY_LOCAL_MACHINE\SOFTWARE\Oracle\HOME2\TNS_ADMINを設定する必要があります。

XSQLチュートリアルの更新結果の表示

更新ビュー操作の結果を表示するには、（生成されたコードの後、</page>タグの前に）次のコードをXSQLページに追加する必要があります。このコードは、（UpdateViewObjectアクション・ハンドラが起動した後で）SUPPLIER表を問い合せて新しい結果を表示します。

<xsql:action  handler="oracle.jbo.xsql.ViewObject"
               name="SupplierView"
               max-levels="0"
               max-rows="1"
               appmodule="OnlineOrders.OnlineOrdersModule"
               connname="MyJdbcConn">
   <where>
     <attribute name="Id" value="{@Id}"/>
    </where>
</xsql:action>  

エンティティBeanを複数の表にマップする際には、主キー属性がBusiness Components for Javaデータ型に適切にマップされていることを確認してください。たとえば、（後から追加された）2つ目以降の表における列とマップされているBeanの主キー属性がint型の場合、マップされるエンティティ・オブジェクトの属性は、デフォルトのNumberからIntegerに変更することが必要です。同様に、Beanの主キー属性がlong型の場合、エンティティ・オブジェクトの属性はLongに変更することが必要です。CMPに対して提案されるマッピングについては、オンライン・ヘルプの「CMPで推奨される型マッピングについて」のトピックを参照してください。

現在ビジネス・コンポーネントがOracle8i またはVisiBroker CORBAサーバーとして配布された場合に、Plug-in 1.2.2上で実行されるアプレットからアクセスすると問題が発生します。JRE 1.2.1またはJRE 1.3のPlug-inを使用してください。

最初の試行時にのみ、CodeCoachログ・ウィンドウが空白で表示されます。この状況が発生した場合は、JDeveloperを再起動してください。

ビューアでEJBフォルダにあるファイルを開いている場合、JDeveloper 3.2は、ワークスペースを閉じたとき（または完全に終了したとき）にハングします（タスク・マネージャが必要になります）。この状況は、プロジェクト・ファイル（.jpr）をダブルクリックしてWindowsエクスプローラからJDeveloperを起動した場合にのみ発生します。ワークスペース・ファイル（.jws）から起動した場合、JDeveloperはワークスペースを閉じる際にntdll.dll例外をスローします。回避方法として、ワークスペースにEJBがある場合は、常にスタート・メニューを使用してJDeveloperを起動します。

XSQLソースを参照する際に、JavadocビューアはXSQL Javadocを表示しません。XSQL Javadocを有効にするには、JDeveloperを終了し、テキスト・エディタ（メモ帳など）を使用して、次の行を<JDeveloper_Home>\bin\library.iniの[Library_1.2_XSQL Runtime]セクションと[Library_1.1_XSQL Runtime]セクションに追加します。

Docpath=[..\doc\javadoc\Oracle\xsqlref.zip] 

JDeveloperを再起動する際に、「Javadocビューア」タブを使用してXSQL Javadocを表示できます。

JDeveloper 3.1以前で作成されたJSPアプリケーションをJDeveloper 3.2環境にインポートする場合は、3.1のオリジナルの<JDeveloper_Home>\myhtml\webapp\環境の内容を3.2の<JDeveloper_Home>\myhtml\webappディレクトリに移入するか、3.2のJSPウィザードの1つを使用して\webapp\ディレクトリに新しい内容を生成する必要があります。

3.2では、\webapp\ディレクトリは最初は空で、ビジネス・コンポーネントJSPアプリケーション・ウィザードの完了時に動的にデータが移入されます。結果として、JDeveloperでのランタイム・テストにおいて、CSSファイルとイメージが見つかりません。

JDeveloper 3.2のWeb Beanは、新しいデータ型固有の描画機能を利用します。Web Beanの実装クラスは変更されたため、JDeveloper 3.2で3.1のWebアプリケーションを開いた場合は、Oracle interMediaライブラリをプロジェクトに追加し、新しい描画機能をサポートする必要があります。JDeveloper 3.2にライブラリを追加するには、Webアプリケーションの「プロジェクト・プロパティ」ダイアログを開き、「ライブラリ」タブをクリックしてから「追加」をクリックし、リストから「Oracle Intermedia」を選択して「OK」をクリックし、interMediaライブラリをプロジェクトに追加します。

3.1で作成したJSPアプリケーションのJDeveloper 3.2でのアップグレードの詳細は、オンライン・ヘルプを参照してください。アップグレードに関するトピックは、「JSPページの作成」の下の「JSPアプリケーションについて」を参照してください。

Oracle JDeveloperには、データベース内のinterMediaタイプの描画を実現するJSPページが用意されています。このJSPページは、Oracleデータベースに付属するJSPランタイム環境であるOracleサーブレット・エンジンでは現在動作しません。ただし、このJSPページは、任意の標準JSP環境とOracle9i Application Serverでは動作します。

現在、Enumeration型を返すBeanのファインダ・メソッドは、実行時にInvalidOwnerExceptionをスローして失敗します。このエラーは、ファインダが動作しないというOracleJVMのバグ（1422231）が原因です。

たとえば、パラメータとしてdoubleを受け取り、Enumerationを返すファインダ・メソッドがEJBにある場合、CMP配布エラーが発生します。 このエラーは、永続性マネージャAPIがプリミティブ型をサポートしないというOracle JVMのバグ（1471204）が原因です。回避方法として、ファインダ引数をdoubleではなくDoubleとして定義します。

booleanから、精度が定義された数値列へのマッピングには問題があります。たとえば、number(2)などの場合です。このような列に対して属性が作成された場合、スケール/精度のValidatorがその属性に対して作成されて精度が増し、boolean値の認識に失敗します。この検証をオフにするには、マップされたbc4jエンティティ属性を編集し、データベース列の型をNUMBER(xx)からNUMBERに変更します。

webtogo.oraファイルのほとんどの部分は変更しないでください。ただし、このファイルの2つの変数は、変更が必要な場合があります。どちらの変数も、Webアプリケーションの実行時にJDeveloperのデフォルトの動作を上書きします。

1. [WEBTOGO]セクションで、PORT=<port_number>という構文を使用して特定のポートを定義できます。このエントリが存在しない場合（デフォルト）、webtogoサーバーは使用可能なポートを検索します。次に例を示します。

   [WEBTOGO]
   USE_SYSTEM_CLASSPATH=YES
   DEBUG=YES
   PORT=7007 

2. [JDEV]セクションで、HOST=<fully_qualified_hostname>という構文を使用して特定のホスト名を定義できます。このエントリが存在しない場合（デフォルト）、webtogoサーバーはユーザーのローカルIPアドレスを使用します。次に例を示します。

   [JDEV]
   HOST=jdev-lap.us.oracle.com 

注意:　 このファイルの他の部分を変更すると、Webアプリケーションが正しく実行されない可能性があります。

Business Components for Javaのランタイム・ライブラリとビジネス・コンポーネントのEJBが異なるスキーマに配布された場合は、次のエラーが生成されます。

Generating Jar File...done
Loading EJB Jar file and Comm Stubs Jar file...
error: loadJava has failed to load some classes; Please check trace file!
*** Errors occurred while deploying the EJB to 8i JVM *** 

サーバーのトレース・ファイルをチェックすると、複数のORA-04043エラーが見つかります。

Error while resolving class
oracle/jbo/common/remote/ejb/RemoteApplicationModulePackage/sequence_of_wstringHelper
ORA-04043: object
oracle/jbo/common/remote/ejb/RemoteApplicationModulePackage/sequence_of_wstringHelper does not exist 

この問題は、Oracle8i リリース8.1.7に対するデータベース・パッチセットで修正される予定です。

ネットワーク・サーバー上のJDeveloperへのパスに空白が含まれる場合、スタート・メニューのショートカットが動作しません。回避方法として、追加されているJDeveloperのショートカットのプロパティを開き、そのリンク先のパスの先頭と末尾に二重引用符（"）を追加します。

jbo:SetAttribute dataitem="*"タグがオブジェクト型に対して動作しない（1426349）

オブジェクト型が含まれる表に対して、jbo:SetAttribute dataitem="*"タグが正しく動作しません。回避方法として、次のように、"*"を使用せずにそれぞれの属性を記述します。

<jbo:Row id="newRow"  datasource="ds1"  action="Create" >
<jbo:SetAttribute dataitem="Id" value="101" />
<jbo:SetAttribute dataitem="Address.Street"  value="101 Main st" />
<jbo:SetAttribute dataitem="Address.City"  value="Redwood city" />
</jbo:Row> 

注意:　 この例におけるAddressはオブジェクト属性です。オブジェクト型に含まれる属性を直接指定します。

Collectionは、Oracle8i 8.1.7ではサポートされていません。ファインダ・メソッドの戻り型がCollectionの場合は、配布時に次のエラーが発生します。

Reading Deployment Descriptor...done
Verifying Deployment Descriptor...done
Gathering users...done
Processing container managed persistence bean...done
Generating Comm Stubs.........................................done
Compiling Stubs...done
Generating Jar File...done
Loading EJB Jar file and Comm Stubs Jar file...done
Generating EJBHome and EJBObject on the server...
Compilation errors in
oracle/aurora/ejb/gen/_test_mingye_StringFind/EjbHome_StringFindHome:ORA-29535:
 source requires recompilation
oracle/aurora/ejb/gen/_test_mingye_StringFind/EjbHome_StringFindHome:148:
Incompatible type for declaration. Explicit cast needed to convert
java.util.Collection to java.util.Enumeration.
oracle/aurora/ejb/gen/_test_mingye_StringFind/EjbHome_StringFindHome:156:
Incompatible type for return. Explicit cast needed to convert
oracle.aurora.ejb.AuroraEnumeration to java.util.Collection.
Info: 2 errors  

Oracle8i JVMに配布された中間層に対してアプリケーション・プールを使用している際に、フェイルオーバー・フレームワークがアプリケーション・データの変更をコミットしないようにするには、Business Components for Javaランタイムを配布した後に次の手順を実行する必要があります。

1. jbo.serverpropertiesをjbomt.zipから抽出します。

2. jbo.serverpropertiesを編集して次の行を追加します。

   jbo.server.internal_connection=jdbc:oracle:thin:<user>/<password>@<host>:<port>:<sid>

3. jboserver.propertiesをJARファイルに追加します。JARファイルを作成している間、oracle/jbo/serverパスが保持されることを確認します。

4. JDeveloper配布ユーティリティを使用してプロパティ・ファイルを含むJARファイルをデータベースに配布します。

5. JAVASYSPRIVロールまたはconnect,resolve java.net.SocketPermissionsをJavaオブジェクトの所有者に付与します。

   EXEC DBMS_JAVA.GRANT_PERMISSION('<user>', 'SYS:java.net.SocketPermission', '*', 'connect,resolve');
    

単一のHTTPリクエストでアプリケーション・モジュールに対して複数のステートフル・チェックアウト/チェックイン操作を行うと、データベースの状態が競合する場合があります。

Webアプリケーションの開発者は、各HTTPリクエストが実行するステートフル・アプリケーション・モジュール・プールのチェックアウト/チェックインが、アプリケーション・モジュールあたり1つのみであることを確認する必要があります。追加のプール・チェックイン/チェックアウト操作を実行する可能性のあるjsp:forwardタグには特別な注意を払う必要があります。

アプリケーション・モジュール・プールのフェイルオーバー・サポート機能またはディスクへの分割機能を使用し、かつ、jbo.maxpoolsizeプロパティでJDBC接続プール・サイズを制限しようとしている場合、最大プール・サイズを見積もる際に、各ルート・アプリケーション・モジュールのためのJDBC接続の容量を（それぞれ1つずつ余計に）確保しておいてください。

この例外は、Oracle8i JVMにEJBとして配布されたアプリケーション・モジュールの非活性化（passivation）が起動した際にスローされるOracleSQLException 2089の結果です。この状況は、グローバル・トランザクション・マネージャが、DDLを起動して永続コレクション表を作成する際に、活性化/非活性化の状態管理フレームワークにより起動された暗黙的コミットを処理できないことが原因です。JDeveloper 3.2では、回避方法として、EJBトランザクション・タイプをデフォルトのグローバル・タイプではなくローカルとして宣言します。これは、次の手順で行います。

1. jboserver.propertiesをjbomt.zipから抽出します。

2. 次の行をjboserver.propertiesに追加します。jbo.ejb.txntype=local

3. jboserver.propertiesファイルをOracle8i JVMに配布します。

DBサーブレットはJDeveloper 3.2から削除されました。かわりにDataPageウイザードを使用できます。DataPageウイザードの詳細は、オンライン・ヘルプを参照してください。

Javaストアド・プロシージャを配布する場合は、Oracle JDBCライブラリがloadjavaユーティリティにより要求されるため、このライブラリをプロジェクトの一部として持つ必要があります。コードでOracle JDBCドライバを使用していない場合でも、Javaストアド・プロシージャを配布する場合はこのライブラリが含まれている必要があります。

リモート・デバッグするには、ソース・ファイルがクラス・ファイルと同じディレクトリ構造である必要があります。たとえば、パッケージCORBA.foo1.innerfooがリモートでデバッグされる場合は、ソース・ファイルがJDeveloperのソース・ディレクトリのCORBA\foo1\innerfooディレクトリに入っている必要があります。このディレクトリにない場合は、ブレークポイントが認識されません。

JDeveloper 3.1から、アプリケーションのmainメソッドをpublicかつstatic voidにする必要があるという規則が新たに設けられました。これはJavaの公式仕様です。JDeveloper 2.0ではアクセス・フラグが無視されるため、アクセス修飾子とは無関係にstatic void main(String[])メソッドを含むクラスの実行が可能でしたが、JDeveloper 3.1以降では不可能です。「実行/デバッグ」メニューは、コードが実行可能ノードであると見なされない場合は無効になります。

Webアプリケーションに関連するウィザードは、各プロジェクトのプロパティ設定にしたがって、ファイル内にキャラクタ・セットのエンコーディング情報を追加します。

プロジェクトのエンコーディング設定が「デフォルト」の場合

• ビジネス・コンポーネントJSPアプリケーション・ウィザードおよびDataPageウィザード

  ISO-8859-1のキャラクタ・セットのエンコーディング情報が追加されます。ISO-8859-1はJavaServer Pagesの仕様におけるデフォルトのエンコーディングです。ビジネス・コンポーネントJSPアプリケーションおよびDataPageのウィザード終了後、プロジェクトのエンコーディング設定は「デフォルト」から「ISO8859_1」に変更されます。

• JSPおよびHTTPサーブレット・ウィザード

  特定のエンコーディング情報は付加されません。この場合、ファイル内の文字はISO-8859-1のキャラクタ・セットとして取り扱われます。

• XML、XSQLおよびXSL

  OSの環境設定に応じて適切なキャラクタ・セットのエンコーディング情報が追加されます。日本語のWindows環境の場合、charset=SHIFT_JISが追加されます。

• JSPエレメント・ウィザード

  JSPエレメント・ウィザードによって一部のタグを挿入する場合、ウィザードはプロジェクト内に新規のCommonフォルダを追加します。プロジェクトのエンコーディング設定が「デフォルト」の場合、このCommonフォルダ内のJSPファイルには、OSの環境設定に応じて適切なキャラクタ・セットのエンコーディング情報が追加されます。また、プロジェクトのエンコーディング設定も「デフォルト」から適切なキャラクタ・セットに変更されます。日本語のWindows環境の場合、JSPファイルにはcharset=SHIFT_JISが追加され、プロジェクトのエンコーディング設定は'MS932'に変更されます。

• HTML

  特定のエンコーディング情報は付加されません。

上記のすべてにおいて、プロジェクトのエンコーディング設定が「デフォルト」でない場合（日本語版のJDeveloper 3.2のデフォルトはMS932です）には、その設定に対応した適切なエンコーディング情報が追加されます。ウィザードによるキャラクタ・セットの選択の違いを避けるためにも、プロジェクトのエンコーディング設定は「デフォルト」以外にすることをお勧めします。

Webアプリケーション以外の場合、プロジェクトのエンコーディング設定は、単にコンパイル時のエンコーディング指定にのみ使用されます。

XSQL、JSPファイルに対するヒント・メッセージが適切ではない(1671024)

ナビゲータ内のXSQL、JSPファイルのアイコン上にマウスを置いたときに出るヒント・メッセージが正しくありません。

9iASおよびApache JServ上でWeb Monitorのセッション情報が表示されない(1727311)

Oracle9i Appliacation ServerまたはApache JSev上でビジネス・コンポーネントJSPアプリケーションを実行する際にWeb Admin Utilityの「セッション情報」でエラーが発生します。これはJDeveloper開発環境上、およびTomcatでは正常に機能します。

JSPのリモート・デバッグにおける注意事項

ローカル・デバッグに使用したプロジェクトでJSPに対するリモート・デバッグを実行する場合、リモート配布用のパッケージはローカルで使用したパッケージと一致する必要があります。つまりユーザーは、JDeveloperのmyhtmlディレクトリ（デフォルトでは、MyProject4_htmlなどのディレクトリ名）にあるサブディレクトリと同名のサブディレクトリを、Webサーバーのhtmlディレクトリに作成し、JSPファイルはこのサブディレクトリにコピーする必要があります。この場合JSPのURLは、http://host/MyProject4_html/test.jspなどとなります。

ローカル・パッケージと一致しないディレクトリにJSPファイルを配布する場合は、リモート・デバッグ用に、同じディレクトリ構造で、新規プロジェクトを作成する必要があります。

JSPを（ローカルまたはリモートで）デバッグする場合、式の評価を使用するデバッグ機能はすべて使用できません。これには条件ブレークポイント、ブレークポイント発生の式のロギングおよび「実行」メニューからの「評価/変更」ダイアログも含まれます。

Business Components for Javaを実行するユーザーには、特定のJava2スタイルの権限を付与する必要があります。SCOTTなどのユーザーにこれらの権限を付与するために、SYSユーザーとして次のSQLスクリプトを実行できます。

SET VERIFY OFF
EXEC DBMS_JAVA.GRANT_PERMISSION('SCOTT', 'SYS:java.util.PropertyPermission','*', 'write');
EXEC DBMS_JAVA.GRANT_PERMISSION('SCOTT', 'SYS:java.util.PropertyPermission','*', 'read');
EXEC DBMS_JAVA.GRANT_PERMISSION('SCOTT', 'SYS:java.lang.RuntimePermission','createClassLoader', null);
EXEC DBMS_JAVA.GRANT_PERMISSION('SCOTT', 'SYS:java.lang.RuntimePermission','setContextClassLoader', null);
EXEC DBMS_JAVA.GRANT_PERMISSION('SCOTT', 'SYS:java.lang.RuntimePermission','getClassLoader', null);
COMMIT; 

注意:　 DBMS_JAVA.GRANT_PERMISSIONプロシージャの第1パラメータでユーザー名を指定する場合、必ずすべて大文字を使用してください。上記のコードは、スクリプトjava2perm.sqlとしても提供されています。このスクリプトは、<JDeveloper_Home>\binディレクトリに入っています。このスクリプトは、SQL*Plusから次のように実行します。 @<JDeveloper_Home>\bin\java2perm SCOTT USERIDはすべて大文字にする必要があります（たとえば、SCOTT）。

Business Components for Javaに影響のあるJDBCの問題点は、次のとおりです。WHERE句パラメータは、JDBCのPreparedStatementに対し（インデックスを1ずつ増分して）setObjectまたはsetNullをコールします。次のプログラム例は、Oracle JDBCドライバがバインド変数の番号の一致ではなく位置の一致によってこれらのsetObjectコールを受け取ることを示すものです。

Example program
=======================================

     import java.sql.*;
     import java.io.*;
     import oracle.sql.*;


     public class bind
     {
        Connection conn;

        public static void main(String argv[])
        {
           bind ex = new bind();

           try
           {
              DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver());

              ex.conn = DriverManager.getConnection("jdbc:oracle:thin:scott/tiger@localhost:1521:ORA815");

              ex.work();
              ex.work2();

              ex.conn.close ();
           }
           catch(Exception e)
           {
              e.printStackTrace();
           }
        }

        public void work() throws Exception
        {
           PreparedStatement stat;


           stat = conn.prepareStatement("select * from emp e where ENAME = :2 or JOB = :1");

           stat.setObject(1, "KING");
           stat.setObject(2, "PRESIDENT");

           ResultSet rslt = stat.executeQuery();

           if (rslt.next())
           {
              System.out.println("name: " + rslt.getString("ENAME"));
           }
           else
           {
              System.out.println("no row found");
           }

           rslt.close();
           stat.close();
        }

        public void work2() throws Exception
        {
           PreparedStatement stat;


           stat = conn.prepareStatement("select * from emp e where ENAME = :2 or JOB = :1");

           stat.setObject(1, "PRESIDENT");
           stat.setObject(2, "KING");

           ResultSet rslt = stat.executeQuery();

           if (rslt.next())
           {
              System.out.println("name: " + rslt.getString("ENAME"));
           }
           else
           {
              System.out.println("no row found");
           }

           rslt.close();
           stat.close();
        }
     }
 

このプログラムを実行すると、まずworkが実行され、次にwork2が実行されます。work()では、setObject によってインデックス 1 で指定された値が:2にバインドされ、setObjectによってインデックス 2 で指定された値が:1にバインドされます。work2()では、このバインド順序が逆転します。

実行の結果は次のようになります。

name: KING
no row found 

work2()で行が検出されなかったことから、このバインドは位置により実行されたことがわかります。

Business Components for JavaでBLOB列をサポートさせる場合、JDBCドライバ8.1.XおよびNet8 8.1.Xが必要です。

Connection Managerでは、ネット名/値ペアの接続方法でOracle JDBC Thinドライバを使用したOracle8i への接続を作成することが可能です。この接続によってデータベース・ブラウザを表示できますが、Oracle JDBC Thinドライバを使用する場合にはloadjavaユーティリティで"@host:port:SID"という形式のデータベース文字列が必要であるため、配布が完了しません。

この問題を回避するには2つの方法があります。

1. Connection Managerでこの接続タイプを作成する際、Net8の「ネット名/値」ペアではなく「名前付きホスト」接続を使用します。

2. Oracle JDBC Thinドライバではなく、Oracle JDBC OCI-8ドライバを使用します。JDeveloperでOracle JDBC OCI-8ドライバを使用するには、オンライン・ヘルプの「OCIおよびタイプ2 JDBCドライバの接続要件」という項を参照してください。

この問題はWindows NTで発生します。この問題を改善するには、Windows NTエクスプローラ「表示」 -> 「オプション」を選択します。「ファイル タイプ」タブをクリックします。「登録されているファイル タイプ」で「Netscape Hypertext Document」（またはhtm/htmlが関連付けられているアプリケーション）を選択し、「編集...」ボタンをクリックします。「ファイル タイプの編集」ダイアログで、「アクション:」フィールドの「open」を選択し、「編集」ボタンをクリックします。「アクションの編集」ダイアログで、「DDEを使う」チェック・ボックスのチェックを外します。

すべてのダイアログで「OK」をクリックし、ダイアログを閉じます。これで問題が解決されます。

Javaフォームについて定義する接続タイプは、アプリケーションで指定するすべてのSessionInfoコンポーネントの接続タイプと同じである必要があります。たとえばアプリケーションでは、2つのインスタンスでOracle8i とVisiBrokerに別々に接続することはできません。データベース対応アプリケーションは常に、パスに最初に出現するクライアント・ライブラリを検索し、すべてのSessionInfoコンポーネントが同じライブラリを使用すると仮定するためです。複数の接続タイプをサポートするために複数のクライアント・ライブラリを導入する方法は、このリリースではサポートされません。

JPublisherウィザードでは、配布済Javaストアド・プロシージャのJavaファイルが生成されません。

パッケージ化されたJavaストアド・プロシージャに対して、JDeveloperによる配布により、AS LANGUAGE JAVA構文のあるパッケージ仕様部が作成されます。次に例を示します。

PACKAGE MYPROJECT1 AS
FUNCTION ROWCOUNT (p0 VARCHAR2) RETURN NUMBER
AS LANGUAGE JAVA
NAME 'package1.RowCounter.rowCount(java.lang.String) return int';
END MYPROJECT1; 

これは、機能的には次と同等です。

PACKAGE MYPROJECT1 AS
FUNCTION ROWCOUNT (p0 VARCHAR2) RETURN NUMBER;
END MYPROJECT1;
PACKAGE BODY MYPROJECT1 AS
FUNCTION ROWCOUNT (p0 VARCHAR2) RETURN NUMBER
AS LANGUAGE JAVA
NAME 'package1.RowCounter.rowCount(java.lang.String) return int';
END MYPROJECT1; 

「Javaの生成」オプションは2番目の例で動作しますが、最初の例では動作しません。

バインド・モード/ネーミング・モードのVisiBrokerで、DACアプレットには、稼働中のGateKeeperサービスが必要です。アプレット・ビューアを使用してJDeveloper内部から実行すると、これらのアプレットは失敗しますが、Webサーバーからの実行には問題ありません。