Oracle ADF 10.1.3 SRDemoサンプルのOracle JDeveloper/ADF 11gへの移行

ホーム
コンテンツにスキップ
検索にスキップ

サインインアカウント

Oracleアカウント

サインアウト

Oracleアカウント

アカウントを管理して、パーソナライズされたコンテンツにアクセスできます。
サインインアカウントを作成

クラウド・アカウント

クラウド・ダッシュボードへのアクセス、ご注文の管理など、さまざまな操作を行えます。
サインイン国を選択
- アカウント
- ヘルプ
国を選択
電話

著者：Steve Muench、Oracle ADF開発チーム
日付：2008年10月7日
改訂版1.3（改訂履歴）

概要

この文書では、Oracle ADF Facesコンポーネントを使用するOracle Application Development Framework（Oracle ADF）10.1.3 JSFアプリケーションをOracle JDeveloper 11gに移行する手順について説明します。実践例としてSRDemoサンプル・アプリケーションを使用して、自動移行サポートについて説明するとともに、既知の問題のためにこの製品リリースで必要となる一時的な移行後の手順を段階的に示します。

         1 はじめに
         2 自動移行サポートの概要
                 2.1 サポートされている移行パス
                 2.2 移行中のすべてのOracle ADFアプリケーションへの変更
                 2.3 Webアプリケーションへの追加変更
                 2.4 Oracle ADF Faces 10.1.3コンポーネントを使用したJSFアプリケーションへの追加変更
         3 SRDemoサンプルにおける自動移行の実行
         4 移行後のデータソースを使用したOracle ADF BC構成に必要な手動の変更
         5 移行後のOracle ADF Facesコードに必要な手動の変更
         6 Trinidad表キーをOracle ADF行キーにマップするヘルパー・コードの追加
         7 移行後のJSFページに必要な手動の変更
         8 移行後のページ定義に必要な手動の変更
         9 adfFacesContextリファレンスとTrinidad requestContextの置換
         10 必要に応じたSRDEMOスキーマのインストール
         11 必要に応じたアプリケーション接続プロパティの調整
         12 セキュリティの移行
         13 アーティファクトがコンパイルされたアプリケーションのクリーンアップ
         14 8文字の新規パスワードを反映させるためのテストおよびヘルプ・テキストの更新
         15 JUnitリグレッション・テストの実行
         16 アプリケーションの実行
         関連資料

1 はじめに

ここでは、手動による変更を最小限に抑えながらOracle JDeveloper/ADF 10.1.3アプリケーションのJDeveloper 11gリリースへの移行をサポートすることを目標としています。 JDeveloper 11gリリースにおける移行はほとんど自動化されていますが、リリース・ノートには、Oracle ADF Facesベースの10.1.3アプリケーションの移行に関する既知の問題がいくつか挙げられています。こうした問題についての理解を助けるため、この文書では、よく使用されている10.1.3 SRDemoサンプル・アプリケーションのOracle ADF Business Components（Oracle ADF BC）バージョンを取り上げて、その移行手順を段階的に説明していきます。オラクルでは、この情報によって個々のユーザーの10.1.3 Oracle ADF Facesアプリケーション移行処理が簡単になり、その結果、JDeveloper 11g製品リリース前に修正の必要がある移行についての新たな問題の特定が可能となるものと考えています。

2 自動移行サポートの概要

JDeveloper 11gでは、10.1.2.xから10.1.3.xリリースへの作業領域の自動的な移行がサポートされています。この項では、サポート対象の移行パスについて説明するとともに、SRDemoサンプルのようにOracle ADF Facesコンポーネントを使用している10.1.3 JSFアプリケーションの自動移行について取り上げ、その詳細を具体的に示していきます。

2.1 サポートされている移行パス

既存のJDeveloper 10.1.2.xまたは10.1.3.xの作業領域のバックアップ・コピーを作成した後、JDeveloper 11.1.1.0.0リリースで作業領域を開けいてください。この時点で必要なすべてのファイルが移行されますが、場合によっては、移行ウィザードでいくつかの選択を確認してから移行されるファイルもあります。通常、アプリケーションの移行にはデフォルトの設定を選択します。また、何らかの理由でJDeveloper 10.1.2作業領域の直接的な移行に失敗した場合、まず10.1.2作業領域から10.1.3.3へ移行してから、次に10.1.3.3作業領域を11gに移行し、移行が成功しているかどうかを確認します。

2.2 移行中のすべてのOracle ADFアプリケーションへの変更

すべてのOracle ADFアプリケーションでは、自動的な移行により以下の変更がおこなわれます。

adf-config.xml、 connections.xml、および credential-jazn-data.xml構成ファイルが含まれた新しい .adf/META-INFディレクトリが作成される
10.1.3プロジェクトのオフライン・データベース・スキーマを保存するための DATABASE1という名前のオフライン・データベースが作成される
Oracle ADFメタデータ・ファイルが適切に更新される
JDK 1.8スタイルのCollections APIを参照する import文が変更され、それと互換性のある java.util Collections APIを使用するようになる

2.3 Webアプリケーションへの追加変更

移行アプリケーションがWebアプリケーションの場合、移行で次の追加変更が実行されます。

Webアプリケーション・ディスクリプタおよびライブラリのWeb（サーブレット）バージョン2.5仕様への更新
WebLogic-application.xmlデプロイメント・ディスクリプタの追加
使用しているJSTL 1.0タグおよびライブラリをJSTL 1.2へアップグレード
使用しているJSF 1.1タグおよびライブラリをJSF 1.2へアップグレード

2.4 Oracle ADF Faces 10.1.3コンポーネントを使用したJSFアプリケーションへの追加変更

移行するWebアプリケーションでJavaServer Faces（JSF）とOracle ADF Facesコンポーネント・ライブラリを使用している場合、11gで Apache Trinidad ^{[ 1]}コンポーネントを使用するためにWebアプリケーションを移行する必要が生じます。 JDeveloper 11gでは、10.1.3 Oracle ADF Facesコンポーネント・ライブラリを操作するWYSIWYGサポートが提供されていないため、Webアプリケーションを移行することで、ページ設計の視覚的なWYSIWYG設計時サポートを引き続き利用できるようになります。 Apache Trinidadコンポーネントは、Oracle ADF Faces 10.1.3コンポーネントに基づくオープン・ソースのJSFコンポーネント・ライブラリです。このため、オリジナルのOracle ADF Facesコンポーネントに非常によく似ています。ただし、これらのコンポーネントは名前空間が個別に識別される単独のコンポーネント・ライブラリであるため、UIコンポーネントに別の名前が使用される場合もあります。

JDeveloper 11gでは、自動移行中に、10.1.3 Oracle ADF Facesのアプリケーション・ページが対応するApache Trinidadコンポーネントを使用するように更新されます。具体的には、移行で次の追加変更が実行されます。

使用しているOracle ADF Faces 10.1.3タグおよびライブラリを、対応するApache Trinidadのコンポーネントへ更新
Oracle ADF Faces 10.1.3 web.xml構成情報を、Apache Trinidadに対応した適切なバージョンへ更新
Oracle ADF Faces 10.1.3 APIを参照するカスタムJavaコード内の import文を、Apache Trinidadライブラリの対応するクラスへ更新

注：	Oracle ADFからTrinidadへの移行のWikiページ ^{[ 2]}で、移行ウィザードによって実装されるOracle ADF FacesからTrinidadへの移行パスの詳細を確認できます。

3 SRDemoサンプルにおける自動移行の実行

ここでは、JSFおよびOracle ADF Facesを使用したOracle ADF 10.1.3 Webアプリケーションの移行を実際に体験するため、一般的によく使用されているSRDemoサンプル・アプリケーション（Oracle ADF BCバージョン）を使用します。以下の手順を実行して、移行します。

JDeveloper 11g Studio Editionのダウンロードおよびインストール

OTNのJDeveloper Product Center ^{[ 3]}からJDeveloper 11gの Studio Editionをダウンロードして、残りの手順を実行してください。

注：	この移行チュートリアルについての検証は、JDeveloper 11g Studio Editionバージョン11.1.1.0.0のビルド `JDEVADF_MAIN.BOXER_GENERIC_081002.2127.5156`で実施しました。

移行前のJUnit拡張機能インストール確認

SRDemoサンプル（Oracle ADF BCバージョン）では、ユニット・テストにJUnitを使用します。そのため、移行をおこなう前にJUnit拡張機能がインストールされていることを確認する必要があります。これを実行するには、「 Help 」→「 Check for Updates... 」を使用して、JDeveloper 11gリリース用の適切なJUnit拡張機能をインストールします。拡張機能の名前は、 JUnit Integration 11.1.1.0.XX.YY.ZZ です。
オリジナルの10.1.3 SRDemoサンプル（Oracle ADF BCバージョン）のダウンロードおよび展開

これらの手順を正確に実行するため、移行の起点として使用するオリジナルの10.1.3 SRDemoサンプル（Oracle ADF BCバージョン） ^{[ 4]}をダウンロードすることをお勧めします。ダウンロードしたあと、jar、unzip、WinZipなどのzipファイル・ユーティリティを使用して、適切なディレクトリに SRDemoSampleADFBC.zipファイルを展開します。デモのすべてのファイルを含む最上位レベルの SRDemoSampleADFBCディレクトリが作成されます。
JDeveloper 11gの起動およびSRDemoSampleADFBC作業領域のオープン

JDeveloper 11gを起動し、「 File 」→「 Open... 」を選択します。上記で抽出した SRDemoSampleADFBCディレクトリの SRDemoSampleADFBC.jwsファイルを選択します。

移行ウィザード が自動的に表示されます。
移行ウィザード・ダイアログを使用したアプリケーションの移行

移行プロセスを開始するには、 Migration Wizard ダイアログで以下の手順を実行します。
1. Welcome ページで、「 (Next) 」をクリックします。
2. Confirmation ページの Do you want to migrate these files? ラジオ・グループで、デフォルトの「 Yes 」をそのまま受け入れて、「 (Next) 」をクリックします。
3. Webapp 2.5 Migration ページの「 Migrate to Webapp 2.5 」チェック・ボックスを選択したままにします。この選択により、「 Convert JSF 1.0/1.1 to 1.2 」チェック・ボックスも選択されることになります。また、「 Convert JSTL 1.0 to 1.2 」チェック・ボックスも選択したままの状態で「 (Next) 」をクリックします。
4. UserInterface.jpr ページで、「 Migrate to Trinidad 」チェック・ボックスを選択したままにして、「 (Next) 」をクリックします。
5. Finish ページの「 (Finish) 」をクリックします。
  
  実際の移行には、数分かかる場合があります。 Migration Progress ダイアログに、実行中の処理のフィードバックが表示されます。
移行の終了および移行されたすべてのファイルの保存

移行されたプロジェクトを要約する最後の Migration Progress ダイアログが表示されたら、「 (OK) 」をクリックします。

そのあと、「 File 」→「 Save All 」を選択して、移行された作業領域ファイルをすべて保存します。

4 移行後のデータソースを使用したOracle ADF BC構成に必要な手動の変更

SRDemoサンプルの SRServiceLocal構成と同様に、アプリケーション・モジュール構成のいずれかでJDBCデータソースを使用している場合は、そのデータソース構成を更新し、 jbo.server.internal_connectionが既存のデータソース名に設定されるようにする必要があります。デフォルトでは、JDeveloper 11gで SRDemoという名前のアプリケーション・リソース接続を作成すると、統合されたWebLogicアプリケーション・サーバーでアプリケーションを実行したりデバッグをおこなったりするたびに、作成した接続のWebLogic JDBCモジュールがIDEにより自動的に作成されます。また、JDBCモジュールについての設定の一部として、該当する接続のJNDI名が jdbc/SRDemoDSに設定されます。さらに、JDeveloper 11gにより、そのデータソースをアプリケーション・リソースとして参照するようにするためのエントリが、アプリケーションの web.xmlファイルに追加されます。つまり、アプリケーションにおいて、アプリケーション・リソースのJNDI名前空間の下にあるJNDI名を使用してデータソースの参照をおこなうことが可能となります。具体的には、 jdbc/SRDemoDSデータソース用として使用する適切なJNDI名は、 java:comp/env/jdbc/SRDemoDSとなります。このJNDI名は、このデータソース用に SRServiceLocal構成で使用されているものと同じ文字列であるため、それをそのまま使用できます。この構成で変更の必要があるプロパティは、 jbo.server.internal_connectionです。このプロパティは、すでに存在していないJNDI名 java:comp/env/jdbc/SRDemoCoreDS（名前に Coreが含まれている点に注意）を参照しているため、変更する必要があります。

そこで、この更新をおこなうため、以下の手順を実行します。

アプリケーション・ナビゲータで、 DataModelプロジェクトの「 SRService 」アプリケーション・モジュールを右クリックし、「 Configurations... 」を選択します。
Manage Configurations ダイアログが表示されたら、そのダイアログの左側の一覧で「 SRServiceLocal 」構成を選択し、「 (Edit...) 」をクリックします。
次に表示される Edit Business Components Configuration ダイアログで、「 Properties 」タブ（3番目のタブ）を選択します。
画面をスクロールして jbo.server.internal_connectionプロパティを探し、このプロパティの値を更新して java:comp/env/jdbc/SRDemoDSに設定します。
「 (OK) 」をクリックし、そのあとにもう一度「 (OK) 」をクリックして Manage Configurations ダイアログを閉じます。

5 移行後のOracle ADF Facesコードに必要な手動の変更

最初にアプリケーションを再構築して、Oracle ADF Faces APIコードの変更に必要ないくつかの場所を確認します。これらの点については、このプレビュー・リリースでは手動で解決する必要があります。アプリケーションを再構築するには、以下の手順に従います。

アプリケーション・ナビゲータで作業領域のドロップダウン・リストをクリックして、 SRDemoSampleADFBC作業領域が現在の作業領域として設定されていることを確認します。
メイン・メニューから「 Build 」→「 Clean All 」を選択します。
Cleaning SRDemoSampleADFBC.jws ダイアログを確認します。
メイン・メニューから「 Build 」→「 Make All 」を選択します。

UserInterfaceプロジェクトには、以下の4つのコンパイル・エラーがあります。これは、Oracle ADF Faces 10.1.3コア・コンポーネントでサポートされているAPIとは異なるApache Trinidadコア・コンポーネントAPIの小規模の変更点によって発生します。

oracle.srdemo.view.backing.SRMainクラス

Error(87,23): method setTip(null) not found in class org.apache.myfaces.trinidad.component.core.input.CoreSelectBooleanCheckbox Error(137,36): method getSelectionState() not found in class org.apache.myfaces.trinidad.component.core.data.CoreTable
oracle.srdemo.view.menu.MenuItemクラス

Error(19,38): identifier CoreCommandMenuItem not found
oracle.srdemo.view.menu.TrainModelAdapterクラス

Error(23,24): constructor ProcessMenuModel(Object, String, Object) not found in class org.apache.myfaces.trinidad.model.ProcessMenuModel

以下の変更を実行して、これらのコンパイル・エラーを解決します。

SRMain.javaのコンパイル・エラーの修正

SRMain.javaの87行目における変更個所は次の部分です。

getConfidential().setTip(null);

これを、以下のように変更します。

getConfidential().setShortDesc(null);

ヒント：	報告されたコンパイル・エラーの該当するクラスへ迅速に移動するには、ログ・ウィンドウのエラーをダブルクリックしてください。ソース・コード・エディタの行番号を有効にするには、左側の余白の領域を右クリックし、「 *Toggle Line Numbers* 」を選択します。特定の行番号に移動するには、「 *Navigate* 」→「 *Go to line...* 」を選択するか、[ `Ctrl`]+[ `G`]を押します。

137行目の変更個所は次の部分です。

Set keySet = getHistoryTable().getSelectionState().getKeySet();

これを、以下のように変更します。

Set keySet = getHistoryTable().getSelectedRowKeys();

MenuItem.javaのコンパイル・エラーの修正

MenuItem.javaの19行目における変更個所は次の部分です。

private String _type = CoreCommandMenuItem.TYPE_DEFAULT;

これを、以下のように変更します。

private String _type = "default";
TrainModelAdapter.javaのコンパイル・エラーの修正

TrainModelAdapter.javaの25行目における変更個所は次の部分です。

getMaxPathKey());

これを、以下のように変更します。

(String)getMaxPathKey());
アプリケーションの再構築

最後に、アプリケーションを再構築して、すべてのコンパイル・エラーが解決されていることを確認します。それには、以下の手順に従います。
1. アプリケーション・ナビゲータで作業領域のドロップダウン・リストをクリックして、 SRDemoSampleADFBC作業領域が現在の作業領域として設定されていることを確認します。
2. 「 Build 」→「 Clean All 」を選択します。
3. Cleaning SRDemoSampleADFBC.jws ダイアログを確認します。
4. メイン・メニューから「 Build 」→「 Make All 」を選択します。
アプリケーションからコンパイル・エラーがなくなります。いくつかの非推奨機能に関する警告については無視しても問題ありません。

6 Trinidad表キーをOracle ADF行キーにマップするヘルパー・コードの追加

SRDemoサンプルの SRMain.jspxページには、サービス履歴行のUI表が含まれています。この表は、複数選択ができるように構成されています。また、このページの (Delete Service History Record) ボタンは、 deleteServiceHistoryNotesというOracle ADFメソッド・アクション・バインディングを起動するように構成されています。このアクション・バインディングは、SRServiceアプリケーション・モジュールで同じ名前のメソッドを起動し、パラメータとして oracle.jbo.Keyオブジェクトの java.util.Setを渡します。 deleteServiceHistoryNotesアクション・バインディングの rowKeyパラメータには、表で現在選択しているキーのセットを渡す ${backing_SRMain.historyTable.selectionState.keySet}EL式が含まれます。

10.1.3のOracle ADF Faces CoreTableクラスの selectionState.keySetプロパティは、選択した行キーの Setを返します。 Apache Trinidadでは、対応する CoreTableクラスの selectedRowKeysプロパティも、行キーの Setを返します。ただし、Oracle ADF Facesの実装では Setまたは oracle.jbo.Keyオブジェクトが返され、一方のTrinidadの実装では Stringキーの Setが返されるという点で、この2つの実装方法は異なっています。

SRDemoサンプルでは、Oracle ADF Faces CoreTableにより oracle.jbo.Keyオブジェクトの Setが返され、それがアプリケーション・モジュール・メソッドに直接渡されるという実装の詳細が誤って使用されています。このため、Trinidadへの移行時に、ヘルパー・メソッドを追加して、CoreTable行キーの Setを oracle.jbo.Keyオブジェクトの Setにマップする必要があります。この処理を実行するには、 UserInterfaceプロジェクトの OnPageLoadBackingBeanBaseクラスを検索して、以下のヘルパー・コードを追加します。このヘルパー・コードを使用すると、マップ・キーとして CoreTableのインスタンスが渡された場合に、 Set<Key>を返す selectedAdfRowKeysという Map値プロパティを参照できます。この文書のあとの手順で、 SRMain.jspxページのページ定義に対応する変更をおこなって、この新しい構文に合うように調整します。

ヒント：

名前を使用してクラスに迅速に移動するには、「 Navigate 」→「 Go to Java Class... 」を選択するか、[ Ctrl]+[ -] （マイナス）を押します。次に、クラス名を入力してリストをサブセット化し、任意のクラスを選択します（格納されているパッケージを覚える必要はありません）。それぞれのライブラリ・リストおよびプロジェクト依存性によって決定された現時点でのアクティブ・プロジェクトのクラスパスにより、このメカニズムを使用して検索することができる、クラス名のセットに対するコンテキストが提供されます。探しているクラスが見つからない場合は、アプリケーション・ナビゲータのプロジェクトを選択して、検索用の適切なコンテキストを設定してから、もう一度試行します。

次のように、 OnPageLoadBackingBeanBaseクラスに、以下の2つのコメントの間に記載されているコード行を追加します。

public class OnPageLoadBackingBeanBase implements PagePhaseListener { private BindingContainer bc = null; // ----------- ADD THE LINES BELOW ---------- private Map<CoreTable,Set<Key>> selectedAdfRowKeys = new HashMap(){ public Object get(Object key) { if (key instanceof CoreTable) { return getSelectedAdfRowKeys((CoreTable)key); } throw new RuntimeException("selectedAdfRowKeys[] key not a Core Table!"); } }; public Map<CoreTable,Set<Key>> getSelectedAdfRowKeys() { return selectedAdfRowKeys; } public Set<Key> getSelectedAdfRowKeys(CoreTable table) { Set<Key> retVal = new HashSet<Key>(); for (Object opaqueFacesRowKey : table.getSelectedRowKeys()) { table.setRowKey(opaqueFacesRowKey); JUCtrlValueBindingRef rowData = (JUCtrlValueBindingRef)table.getRowData(); retVal.add(rowData.getRow().getKey()); } return retVal; } // ----------- ADD THE LINES ABOVE ---------- /* * ... etc. ... Rest of existing class here */ }

この新しく追加したコードをコンパイルするには、次の import文をファイルの上部（既存のインポート文と同じセクション）に追加する必要があります。デフォルトでは、コード・エディタの importセクションは閉じた状態で表示されます。これを展開するには、左側の余白のプラス記号をクリックします。

import java.util.HashMap; import java.util.HashSet; import java.util.Map; import java.util.Set; import oracle.jbo.Key; import oracle.jbo.uicli.binding.JUCtrlValueBindingRef; import org.apache.myfaces.trinidad.component.core.data.CoreTable;

7 移行後のJSFページに必要な手動の変更

このリリースには既知の問題があるため、移行後にJSFページに対していくつかの手動の変更をおこなう必要があります。以下の手順を実行します。

3項演算を使用したEL式のコロンのあとに空白を追加することによるJSF 1.2 EL実行時エラーの回避

現時点では、JSF 1.2式言語（EL）のエバリュエータでは、直後が英字になる場合の3項演算で :（コロン）を解析しようとすると、実行時に ELExceptionがスローされます。この問題を回避するもっとも簡単な方法は、ページ内の該当する個所を検索して3項演算の :（コロン）の前後に空白を追加することです。 SRDemoでこの問題が発生するのは、1つのページだけです。 [Bug 6408848]

./app/staff/SRSearch.jspxページを開いて、エディタの下部にある「 Source 」タブを選択します。行94で、次のように :rowという文字が連続した状態となっています。

<tr:outputText value="#{row.AssignedDate eq null?res['srsearch.highlightUnassigned']:row.AssignedDate}" ...

エラーを回避するため、空白を挿入してコロンと識別子 rowとを分離する必要があります。このため、次のようにEL式を変更して、 :（コロン）のあとに空白を挿入します。

<tr:outputText value="#{row.AssignedDate eq null?res['srsearch.highlightUnassigned'] : row.AssignedDate}" ...

ヒント：	名前を使用してファイルへ迅速に移動するには、「 *Navigate* 」→「 *Go to File...* 」を選択するか、[ `Ctrl`]+[ `Alt`]+[ `-`]（マイナス）を押します。次に、ファイル名を入力してリストをサブセット化し、任意のファイルを選択します（格納されているディレクトリを覚える必要はありません）。

削除アクションにバインドされたボタンへのImmediate="true"の追加（未設定の場合）

ベスト・プラクティスとして、"Cancel"や"Rollback"ボタンなどのJSFコマンド・コンポーネントでは、 immediateプロパティを trueに設定することにより、処理が実行される前に対象フォームのユーザー・データが送信されるのを回避する必要があります。ところが、SRDemoの SRMain.jspxページにある"Add Note"パネルの (Cancel) ボタンは、このベスト・プラクティスに完全に準拠 していませんでした。

immediateプロパティにおけるこのベスト・プラクティス設定が無視されていた要因は、11gで修正されているOracle ADF Faces 10.1.3の問題[Bug 5918302]にあります。理由は次のとおりです。 Oracle ADF Facesを使用したJDeveloper 10.1.3で、クライアント側の必須属性が強制的に適用される機能が使用されていない場合、該当するフォームのフィールド・データがユーザーにより変更されていなければ、サーバー側の必須フィールドが空の値で送信されたフォームは正しく検証されません。 10.1.3 SRDemoの (Cancel) ボタンは、Oracle ADF Facesでのこの誤った動作が原因で検証が実行されなかったために、通常どおり動作していました。しかし11gでは検証が正常に実行されるようになったので、 immediate="true"プロパティをこの (Cancel) ボタンに追加して、状況を修正する必要があります。

この修正をおこなうには、以下の手順を実行します。
1. 「 SRMain.jspx 」を開き、「 Source 」タブを選択して、ページ・ソースを確認します。
2. id="addNotesPanel"の <tr:panelBox> タグを検索します。
3. このパネルで、キャンセル操作の <tr:commandButton> を検索します。次のような記述が表示されます。
  
  <tr:commandButton text="#{res['srdemo.cancel']}" action="#{backing_SRMain.onCancelAddNote}"/>
4. これに immediate="true"属性を追加して、以下のようにします。
  
  <tr:commandButton text="#{res['srdemo.cancel']}" action="#{backing_SRMain.onCancelAddNote}" immediate="true" />

8 移行後のページ定義に必要な手動の変更

以下の変更を実行します。

表のSelectionStateへの参照の調整

Oracle ADF Facesの表には、 selectionStateというプロパティがあります。このプロパティにネストされている keySetプロパティは、選択した行のキーの Setを返します。 Apache Trinidad表の場合は、 selectedRowKeysというプロパティがあり、このプロパティも同じように選択した行のキーの Setを返します。この文書では、前述の手順において、ヘルパー・コードを OnPageLoadBackingBeanBaseクラスに追加し、Trinidad表キーの Setを oracle.jbo.Keyオブジェクトの対応する Setに対して宣言的にマップできるように処理をおこないました。このため、 SRMain.jspxページのページ定義で selectionState.keySetに対する参照を変更し、このヘルパー・コードが使用されるようにする必要があります。

以下の手順を実行します。
- アプリケーション・ナビゲータの「 ./app/SRMain.jspx 」ページを右クリックし、「 Go to Page Definition 」を選択します。
- 構造ウィンドウの bindings セクションから「 deleteServiceHistoryNotes 」アクション・バインディング・ノードを開きます。
- deleteServiceHistoryNotesアクション・バインディング内の「 keySet 」パラメータ子ノードを選択します。
- プロパティ・インスペクタで、 NDValueプロパティ値式を ${backing_SRMain.historyTable.selectionState.keySet}から ${backing_SRMain.selectedAdfRowKeys[backing_SRMain.historyTable]}に変更します。

9 adfFacesContextリファレンスとTrinidad requestContextの置換

このリリースでは、移行ウィザードによって、 adfFacesContextに対する参照が、Trinidadでこれに相当するページおよびページ定義内の requestContextに自動的に置き換えられますが、Javaコードで adfFacesContextを参照している場合は、この置換を手動でおこなう必要があります。このため、JDeveloperのファイル機能で検索/置換を使用して、この置換処理を手動でおこないます。以下の手順を実行します。

アプリケーション・ナビゲータで「 UserInterface 」プロジェクトを選択します。
メイン・メニューから「 Search 」→「 Replace in Files... 」を選択します。

Replace in Files ダイアログが表示されます。
Search Text フィールドに adfFacesContextを入力します。
Replace With フィールドに requestContextを入力します。
Options が以下のとおりに設定されているかどうかを確認します。
- [ x ] Match Case
- [ x ] Recurse into Directory
- [ ] Recurse into Zip and Jar Files
- [ ] Match Whole Word Only
- [ ] Preview Change
「 (OK) 」をクリックします。

10 必要に応じたSRDEMOスキーマのインストール

SRDemoスキーマは、 SRDemoSampleADFBC/DatabaseSchema/scriptsディレクトリに格納されている一連のSQLスクリプトで定義されます。 SRDEMOスキーマおよびデモ表を作成する必要がある場合、コマンド・シェル・ウィンドウを開いて、以下の手順を実行します。

ディレクトリを ./SRDemoSampleADFBC/DatabaseSchema/scriptsに変更します。
リモート・データベースにインストールする必要がある場合は、以下のようにします。
- Windowsを使用している場合
  
  set LOCAL= tnsname_of_remote_db
- Unixを使用している場合
  
  setenv TWO_TASK tnsname_of_remote_db
SYSTEMユーザーとして、 build.sqlスクリプトを実行します。

sqlplus system/manager @build.sql

SRDEMOユーザーとして、 createContextPackage.sqlスクリプトおよび createContextPackageBody.sqlスクリプトを実行します。

sqlplus srdemo/ORACLE @createContextPackage.sql Package created. SQL> @createContextPackageBody.sql Package body created. SQL> exit

注：	Oracle 11gデータベースを使用している場合、デフォルトでパスワードの大文字と小文字が区別されるようになっています。 `build.sql`スクリプトによるパスワード作成方法は大文字を基盤としているため、 `srdemo`ユーザー・パスワードに大文字の `ORACLE`を入力する必要があります。

11 必要に応じたアプリケーション接続プロパティの調整

アプリケーションを移行すると、移行される *.jpxおよび *.xcfg構成ファイルの情報に基づいて、Oracle ADF Business Componentsプロジェクトのアプリケーション・リソース・データベース接続が自動的に作成されます。とくにSRDemoの移行の場合、 SRDemoというアプリケーション・リソース接続が作成されます。もしデモを実行している環境が、SID名が ORCLで、TNSリスナー・プロセスがデフォルト・ポート 1521をリスニングしているローカルのOracleデータベースでない場合には、この接続のプロパティを調整して、使用する SRDEMOスキーマを作成した場所を指定する必要があります。

これを実行するには、アプリケーション・ナビゲータの「 Application Resources 」ゾーンを開き、「 Connection 」フォルダとそこに含まれる「 Database 」ノードを開きます。次に、 SRDemo接続を右クリックして、表示されたメニューから「 Properties... 」を選択します。実行する SRDEMOアカウントを指定するため、接続設定を確認し、必要に応じて変更します。「 (Test Connection) 」ボタンを使用して接続が成功していることを確認してから、「 (OK) 」をクリックします。

12 セキュリティの移行

SRDemoサンプルのように、JAASセキュリティを使用するアプリケーションについては、11gへの移行時にそのセキュリティ設定を移行する必要があります。ほとんどの作業は、ウィザードを実行することで自動的におこなわれます。以下の手順を実行します。

Oracle ADF Securityウィザードの実行

アプリケーション・ナビゲータで「 UserInterface 」プロジェクトを選択します。次に、メイン・メニューから「 Tools 」→「 Configure ADF Security 」を選択します。
1. ウィザードの Enable ADF Security ページで、 Security Model ラジオ・グループから「 ADF Authentication 」アイテムを選択し、「 (Next>) 」をクリックします。
2. Select authentication type ページで、 Form-Based Authentication が自動的に選択され、 Login Page と Error Page の両方に対しては /infrastructure/SRLogin.jspxページが推測されます。
3. Select identity store ページで、「 Application XML 」オプションを選択し、「 (Finish) 」をクリックします。
最後に、「 (OK) 」をクリックして Security Infrastructure Created ダイアログの確認をおこないます。
3つのプロジェクトのソース・パスからのConfigurationDataの削除

SRDemoの3つのプロジェクトは、 ConfigurationDataという名前の別個のディレクトリのセキュリティ情報を共有しています。上記のセキュリティ移行を実行すると、このディレクトリは不要となるため、削除する必要があります。以下の手順を実行します。
- UserInterfaceプロジェクトからのConfigurationDataディレクトリの削除
  
  アプリケーション・ナビゲータで「 UserInterface 」プロジェクトをダブルクリックします。 Project Properties ダイアログの Project Source Paths ページで、 Java Source Paths: リスト・ボックスから「 ConfigurationData 」という名前のエントリを選択し、「 (Remove) 」をクリックします。次に「 (OK) 」をクリックします。
- UnitTestsプロジェクトからのConfigurationDataディレクトリの削除
  
  アプリケーション・ナビゲータで「 UnitTests 」プロジェクトをダブルクリックします。 Project Properties ダイアログの Project Source Paths ページで、 Java Source Paths: リスト・ボックスから「 ConfigurationData 」という名前のエントリを選択し、「 (Remove) 」をクリックします。次に「 (OK) 」をクリックします。
- DataModelプロジェクトからのConfigurationDataディレクトリの削除
  
  アプリケーション・ナビゲータで「 DataModel 」プロジェクトをダブルクリックします。 Project Properties ダイアログの Project Source Paths ページで、 Java Source Paths: リスト・ボックスから「 ConfigurationData 」という名前のエントリを選択し、「 (Remove) 」をクリックします。次に「 (OK) 」をクリックします。
以前のjazn-data.xmlエントリの新しい場所へのコピー

SRDemoの ConfigurationDataディレクトリで使用されている jazn-data.xmlエントリを上記のConfigure ADF Securityウィザードで作成した新規の jazn-data.xmlファイルに移行するには、以下の手順を実行します。
1. JDeveloperで新しいjazn-data.xmlファイルを開く
  
  アプリケーション・ナビゲータの「 Application Resources 」アコーディオン・パネルを展開してから、「 Descriptors 」フォルダ、「 META-INF 」フォルダの順に展開します。開いたフォルダ内にある「 jazn-data.xml 」ファイルをダブルクリックします。「 Source 」タブを選択して、このファイルのソースを確認します。
2. jazn-realm要素およびそのすべてのコンテンツを削除する
  
  <jazn-realm> 要素で始まり、それに対応する </jazn-realm> 要素で終わる（要素自体も含めて）テキストを選択し、そのテキストを削除します。
3. 以前のjazn-data.xmlエントリをクリップボードにコピーする
  
  メモ帳などのテキスト・エディタを使用して ./SRDemoSampleADFBC/ConfigurationData/src/META-INF/jazn-data.xmlファイルを開き、 <jazn-realm> 要素で始まり、対応する </jazn-realm> 要素で終わる（要素自体も含めて）ファイル内のすべての行をクリップボードにコピーします。
4. 新しいjazn-data.xmlファイルにクリップボードをペーストする
  
  JDeveloperに戻り、新しい jazn-data.xmlファイルで、 <policy-store> タグの前の <jazn-data> タグと </jazn-data> タグの間にカーソルを置き、クリップボードのコンテンツをファイルにペーストします。すべての変更を保存します。
ConfigurationDataディレクトリの削除

以前の jazn-data.xmlコンテンツをコピーするために上記で開いたエディタを閉じたあとの時点で、それ以降はセキュリティ情報がConfigurationDataディレクトリから取得されないことを明確にするために、このディレクトリを削除できます。
各ユーザーの資格証明を8文字以上にする設定

Oracle WebLogic Serverでは、 jazn-data.xmlファイルにおける各ユーザーの資格証明（パスワードなど）が8文字以上であることが求められます。 SRDemoの jazn-data.xmlファイルでは各ユーザーのパスワードとして welcomeが使用されていましたが、これは7文字しかないので、各ユーザーのパスワードを welcome1に変更し、実行時にデプロイ例外が発生しないようにする必要があります。この処理をおこなうには、以下の手順を実行します。
1. エディタで開かれたままとなっている jazn-data.xmlファイルの「 Overview 」タブを選択します。
2. エディタの Overview タブの右上にある「 (Manage Users and Roles) 」ボタンをクリックします。
3. Edit JPS Identity and Policy Store ダイアログが表示されたら、 Identity Store および jazn.com レルム名でインデントされているエディタの「 Users 」ページを選択します。
4. リスト ahunoldの最初のユーザーを選択します。
5. Credentials フィールドの既存の値とタイプ welcome1を選択します。
6. リスト内の各ユーザーに対し、ステップ4と5を繰り返します。
7. 名前が DataBase_User_*で始まる2人のユーザーについては、削除できます。
  
  ただし、削除の前に、該当するユーザーのパスワードを更新して8文字以上にしなくてはならない場合もあります。
8. 最後に、「 (OK) 」をクリックしてダイアログを閉じ、「 Save All 」を選択して変更を保存します。

13 アプリケーションのコンパイルされたアーティファクトのクリーンアップ

後述の項でJUnitテストとWebアプリケーションを実行する前に、アプリケーションをクリーンアップしてクラスパスから既存のクラスおよびXMLファイルをすべて取り除き、最新の変更だけを確認できるようにします。アプリケーションをクリーンアップするには、アプリケーション・ナビゲータの上部で作業領域リストをクリックして、「 SRDemoSampleADFBC 」作業領域を選択します。そのあと、メイン・メニューから「 Build 」→「 Clean All 」を選択します。アラートが表示されたら、それを確認します。

14 8文字の新規パスワードを反映させるためのテストおよびヘルプ・テキストの更新

まず、すべてのユーザーのパスワードを welcomeから welcome1に修正したため、ユニット・テストで使用するパスワードも変更する必要があります。また、ログイン・ページでは、デモを実行しているユーザーに対し、それぞれ使用しているパスワードが何かを思い出すためのヘルプ・テキストとしてのパスワードが表示されるようになっています。このため、ここで使用するヘルプ・テキストも更新します。

ユニット・テストの welcomeパスワードを welcome1に更新するには、以下の手順を実行します。

oracle.srdemo.tests.model.unittestsパッケージの UnitTestsプロジェクトで、 SRServiceTestAsManagerRoleクラスを特定します。
welcomeを検索します。
検出したパスワードを welcome1に変更します。
SRServiceTestAsTechnicianRoleおよび SRServiceTestAsUserRoleクラスでも同じ変更を実行します。

次に、Webアプリケーションのヘルプ・テキストを更新し、パスワードの変更を反映させます。この変更を実行するには、以下の手順を実行します。

UserInterfaceプロジェクトを選択します。
メイン・メニューから「 Navigate 」→「 Go to File... 」を選択します（または、[ Ctrl]+[ Alt]+[ -]（マイナス）を押します）。
UIResources.propertiesファイルの最初の数文字を入力しはじめると、リスト内でファイルが特定されます。[ Enter]を押して編集するファイルを開きます。
コード・エディタの上部にある検索フィールドに文字列 <b>welcomeを入力し、変換する古い welcomeパスワードが含まれた文字列を検索します。
ここで検出された welcomeを welcome1となるように変更します。
イタリア語のロケールでのデモの実行も予定している場合は、 UIResources_it.propertiesファイルで同じ変更をおこなってください。

15 JUnitリグレッション・テストの実行

すべて正しく動作しているかどうかを確認するには、JUnitリグレッション・テストを実行します。このテストを実行するには、アプリケーション・ナビゲータの UnitTestsプロジェクトで「 SRServiceAllTests.java 」クラスを右クリックし、「 Run 」を選択します。 JUnit Test Runner ログ・ウィンドウには、12個のユニット・テストが100%合格したと表示されます。

すべてのテストが 不合格の場合、前述のコンパイルされたアプリケーション・アーティファクトのクリーンアップに失敗したか、 SRDemoアプリケーション・リソース接続の接続プロパティを上記で説明したように調整する必要があるかのどちらかです。 Oracle Database 11gを使用している場合、パスワードの大文字と小文字が区別されるため、 SRDEMOユーザー・パスワードを大文字の ORACLEに変更しなくてはならない場合があります。コンパイルされた出力をクリーンアップし、接続プロパティの調整と接続テストをおこなった後、ユニット・テストを再実行して、テストに合格していることを確認してください。

16. アプリケーションの実行

これで、アプリケーションを実行できます。アプリケーション・ナビゲータの「 UserInterface 」プロジェクトを右クリックし、「 Run 」を再選択します。続けてログインし、デモを試行します。デフォルトのブラウザでログイン・ページが表示された場合、テストで試行する各ユーザー・アカウントに対して新しい welcome1パスワードを使用してください。

注：	この文書の手順に従って移行した 11g移行のSRDemoサンプル（Oracle ADF BCバージョン） ^{[ 5]}のバージョンは、ダウンロードできます。ただし、その場合も以下の3つについては、デモを実行する前に上記で説明した手順を実行する必要があります。アプリケーションのコンパイルされたアーティファクトのクリーンアップ必要に応じたアプリケーション接続プロパティの調整 JUnitリグレッション・テストの実行

Oracleアカウント

Oracleアカウント

クラウド・アカウント

お問い合わせ

日本オラクルについて

クラウド

イベント

おすすめコンテンツ

ニュース

主要トピック

Integrated Cloud Applications & Platform Services

改訂	日付	コメント
1.0	2007/09/24	OTN Technology Preview 2リリース
1.1	2007/12/21	OTN Technology Preview 3リリース
1.2	2008/05/01	OTN Technology Preview 4リリース
1.3	2008/10/06	製品リリース