1.0 概要
2.0 サポートするソフトウェアと仕様
3.0 既知の問題
3.1 リフレッシュの問題
3.2 Meet-in-the-middle マッピングのヒントと制約
3.3 マッピング・エディターにおけるドラッグ・アンド・ドロップのサポート
3.4 J2EE パースペクティブのナビゲーター・ビューにおけるテーブルとスキーマの削除
3.5 1.1 CMP Entity Bean のオプティミスティック述部
3.6 継承のヒントおよび制約事項
3.7 インストール・パスに複数の連続スペースがある場合のデプロイメント・コード生成の問題
3.8 開発時にランタイム JAR ファイルを参照する
3.9 複数のテーブルに複合タイプをマップしない
3.10 CMP エンティティーを削除してもマッピング項目が除去されない
3.11 EJB QL の制限
3.12 EJB 参照の検証は自動ではない
3.13 CMP bean の継承された属性
3.14 アラビア語の名前が、Java Bean とファイルでサポートされない
3.15 照会の生成の制限
3.16 EJB 2.0 JAR ファイルに対する EJB 照会言語の妥当性検査
3.17 J2EE 階層での EJB アクション使用時の ClearCase 制約事項
3.18 local-ejb-ref リンクの編集の問題
3.19 EJB 2.0 リレーションシップのデプロイ後のタスク・リストのエラー
3.20 MANIFEST.MF ファイルにディレクトリーを追加する
3.21 非ヌルの外部キー列で特殊化された ejbCreate が欠落する
3.22 継承を使用してソース・ページの CMP フィールドを変更する場合の制限
3.23 Bean クラスを変更したときに EJB デプロイメント・コードが削除されない
3.24 不明の 1 次キーはサポートされない
3.25 リレーションシップを持つ 1.1 CMP について 1 次キー・クラスを変更するとコンパイル・エラーが発生する
3.26 CVS リポジトリーから更新を行うと、リフレクション・エラーになる
3.27 アウトライン・ビューからの FIND 照会の削除
3.28 ソース・ページと EJB の継承
3.29 継承構造では、多対多のリレーションシップに応じた EJB QL 照会が適切に生成されない
3.30 FLOAT データ型の SQL サーバー・マッピングの問題
3.31 他のプロジェクトの Enterprise Bean を使用する場合、デプロイ済みコードの生成が必要な場合がある
3.32 外部キーおよび 1 次キーへの Enterprise Bean のマッピングのサポート
3.33 継承および 2 次テーブル・マッピングの制限
3.34 EJB 1.1 から EJB 2.0 へ Bean をマイグレーションする場合の Access Bean の
クリーンアップ
3.35 WebSphere Application Server v4.0.6 でコンバーターおよびコンポーザーを使用して
EJB アプリケーションをデプロイする
3.36 バイナリー・クラスを含む EJB プロジェクトのマイグレーション
3.37 ビューに対するボトムアップ・マッピングのインプリメンテーション
EJB ツールは、Enterprise Bean の開発に使用可能な専用の環境を提供します。 EJB ツールは以下のエンティティーで構成されています。
- J2EE パースペクティブ
- Enterprise Bean の作成、インポート、およびエクスポートのためのツールとウィザード
- Access Bean 作成ウィザード
- データ・パーシスタンスを Enterprise Bean 内にビルドするツール
- デプロイメント・コード生成用ツール
この README ファイルには、EJB ツールに関連した、既知の問題、制限、回避策が記載されています。
ejbdeploy コマンド (EJB デプロイメント・ツール) の -dbvendor オプションは、以下の値 (サポートされるデータベースに対応) をサポートするようになりました。
以下の値はサポートされていません。
- DB2UDB_V72 (DB2 for Windows、V7.2) -- 以前にサポートされていた DB2UDBWIN_V72 に取って代わります。
- DB2UDB_V81 (DB2 for Windows、V8.1) -- 以前にサポートされていた DB2UDBWIN_V81 に取って代わります。
- SQL92(Generic SQL 92)
- SQL99(Generic SQL 99)
- MYSQL_V323 (MySQL、V3.23)
- DB2UDBAS400_V4 (DB2 for AS/400、V4) -- これは DB2UDBISERIES (DB2 for ISeries) に取って代わられました。
- DB2UDBAS400_V5 (DB2 for AS/400、V5) -- これは DB2UDBISERIES (DB2 for ISeries) に取って代わられました。
- INFORMIX_V92 (Informix Dynamic Server.2000 V9.2)
- SYBASE_V1192 (Sybase Adaptive Server Enterprise V11.9.2)
- DB2UDBWIN_V71 (DB2 for Windows、V7.1)
- DB2UDBWIN_V72 (DB2 for Windows、V7.2) -- これは DB2UDB_V72 に取って代わられました。
- DB2UDBWIN_V81 (DB2 for Windows、V8.1) -- これは DB2UDB_V81 に取って代わられました。
ワークベンチ内のファイルまたはリソースが同期していないように見える場合、または予期しない障害が発生する場合 (例えば、エディターやビューに現行デプロイメント記述子の設定が反映されない場合など) には、プロジェクト・メニューからプロジェクトをクローズして再オープンすることで問題が解決されることがあります。
- 名前で突き合わせ - 完全な一致のみを処理する。WebSphere Application Server バージョン 3.5 互換スイッチを使用してユーザーのスキーマを生成するか、または WebSphere Application Server バージョン 3.5 JAR をインポートすると、ユーザーのテーブル名には「tbl」 が付加され、認識されなくなります。
- 継承 - 子 Bean は、自身のフィールドがない場合にはマップされない。 これらは親テーブルに手作業でマップする必要があります。
- java.util.Date は、1.1 CMP フィールド・マッピングではサポートされない。
- マッピングで Composer を使用する場合は、マップを生成してそれを保管し、プロジェクトをクローズして再度オープンし、そのあとでデプロイしてください。
ドラッグ・アンド・ドロップはマップの「方向」でのみサポートされます。例えば、マップが「トップダウン」操作で作成された場合、Enterprise Bean のデータベースへのドラッグは許可されます。 以下のドラッグ・アンド・ドロップ操作が許可されます。
- Enterprise Bean をテーブルにドラッグすると、両者の間にマップが作成されます。
- Bean を DB にドラッグすると、対応するテーブルと列が作成され、DB が Bean と属性にマップされます。
テーブルを削除する必要がある場合は、データ・パースペクティブ、または J2EE パースペクティブの J2EE 階層ビューを使用してください。それにより、すべての従属リンクも除去されます。通常は、従属関係が更新されないため、 J2EE の削除にナビゲーターまたは J2EE ナビゲーターを使用しないでください。
WSAD 5.0 では、Bean 開発者向けに、修飾が多い更新に使用される属性を識別する機能が追加されました。 以前のリリースの WSAD を使用して作成された EJB JAR ファイルには、1.1 CMP Entity Bean に対応したこの仕様は含まれていません。 ただし、WSAD 5.1 を使用してデプロイすると、以前のセマンティクスがサポートされます。 具体的には、属性のリストがない場合、使用可能なすべての述部が使用されます。 2.0 CMP Entity Bean は異なる方法で処理されることに注意してください。述部として選択された属性がない場合は、修飾が多い更新に属性は追加されません。
- Oracle をデータベースに使用している場合は、ルート - リーフ継承構造において、BLOB タイプを使用しないでください。
- ルート - リーフ継承マッピングは、MySQL、 InstantDB、SQL92、および SQL99 データベースではサポートされません。 これらのデータベースは、ルート - リーフ・マッピングに使用される複雑な照会に必要な SQL セット演算子をサポートしていません。これらのデータベースに対してテストを行うには、単一テーブル・マッピングを使用する必要があります。
- Not-Null 列への CMP フィールドのマッピングは、継承された Bean ではサポートされていません。 オプティミスティック述部は、ルート Bean からの CMP フィールドにのみ設定できます。
プロダクトをインストールしたパス上のいずれかのディレクトリーに複数の連続スペースがある場合、デプロイメント・コードの生成は失敗します。
Websphere Application Server ランタイム (例えば、rt.jar、xerces.jar、など) に対して可視の JAR ファイルにコンパイルを実行したい場合、一般的には、事前定義されたクラスパス変数を使用してこれらの JAR ファイルを各ランタイム・インストールに追加する必要があります。例えば、WebSphere Application Server v4.0 サーバー JAR ファイルの場合は WAS_PLUGINDIR クラスパス変数を使い、WebSphere Application Server v5.0 サーバー JAR ファイルの場合は WAS_50_PLUGINDIR クラスパス変数を使用します。
マッピング・エディターを使用して、合成タイプを異なったテーブルの複数の列にマップすることができます。これは、デプロイメント・コードの生成でエラーとなります。 複合タイプのマッピング内のすべての列が同じテーブルに属するようにしてください。
CMP エンティティーが削除されるとき、この Bean が参照する、対応 するマップでは、そのマッピングが除去されません。 エンティティーの削除後にマッピング・エディターでこれらのファイルをオープンすると、マッピングが除去されます。これは予期される動作です。デプロイメント・コードの生成前にマッピング・エディターをオープンする必要があります。
- 他の Enterprise Bean とのリレーションシップから構成さ れるキーを持つ Enterprise Bean に関する EJB QL 照会は、デプロイメント 時に無効と表示され、エラーになります。 これは既知の障害です。
- IBM EJB QL サポートは、 制限を緩めたり、より多くの DB2 機能のサポートを追加するなど、EJB 2.0 仕様をさまざまな点で拡張しています。 さまざまなベンダーのデータベースまたは EJB デプロイメント・ツールの間の移植性に不安がある場合は、 すべての EJB QL 照会を、EJB 2.0 仕様の 11 章に厳密に合わせて慎重に作成するようにしてください。
EJB ローカル参照、EJB 参照、およびリソース参照の妥当性検査は、これらの参照に対する変更を行っても自動的には行われません。 これらの参照に対する検証が完了するように、EAR バリデーターを明示的に起動する必要があります。
継承された CMP を設定するとき、子は先祖チェーンのどこかに定義されたものと同じ名前の CMP 属性を持っていない可能性があります。例えば、親が CMP Bean で、int 型の属性 ID を持つ場合があります。子 が CMP Bean 作成ウィザードで作成された CMP Bean である場合に親をそのスーパー・タイプとして指定し、int 型の属性 ID を追加をする場合には、親の ID 属性を継承しているため ID 属性は追加されません。子 2 が別の無関係の CMP Bean で、java.lang.String 型の属性 ID を持つ場合にその継承構造がデプロイメント記述子エディターで親を継承するように変更されると、子 2 の java.lang.String 型の属性 ID は、親の属性 ID を継承するため型の競合が起こり、検証エラーとなって除去されます。
Java ファイル、Java Bean、または Access Bean にはアラビア語の名前を使用しないでください。 MiniBank の例で作業する際にも、アラビア語の名前は使用しないでください。
- m:n のリレーションシップの間でプリロードを行うと、誤った SQL が生成される結果になります。 これは既知の制限で、今後対処される予定です。
- 自己参照リレーションシップの間でプリロードを行うと、誤った SQL が生成される結果となります。
- 十分に定義されていない、同じ継承の階層内にある親子の Enterprise Bean のリレーションシップは避けるべきです。
EJB 照会言語の妥当性検査は、現在 EJB-RDB マッピングの妥当性検査の一部として実行されています。マッピング文書 (Map.mapxmi ファイル) がプロジェクトに存在しないときは、EJB 照会は検証されません。これは次回のリリースで、照会の検証がマッピング文書の存在と無関係に行なわれるように変更されます。
J2EE 階層から Enterprise Bean を変更する (例えば、CMP フィールドを Bean に追加する) アクションを使用する場合、最初にプロジェクト・ファイルがリポジトリーからチェックアウトされているようにしてください。
EJB デプロイメント記述子エディターの「参照」ページ内で、「ブラウズ」ボタンを使用して local-ejb-ref のリンクを編集しようとしている場合、リモート・インターフェースのないターゲット Bean を選択することはできません。 回避策は参照を削除して再作成することです。
EJB 2.0 リレーションシップを除去してデプロイメント・コードを再生成するとき、タスク・リストで無効のエラーが出される場合があります。 回避策は、最初にデプロイメント・コードを再生成する前に、Bean のデプロイメント・コードを除去することです。
EJB 2.0 リレーションシップを追加して、デプロイメント・コードを再生成した後、タスク・リストに無効なエラーがあることがあります。この場合、単にもう一度再生成を行うとエラーは除去されます。
MANIFEST.MF ファイルにディレクトリーを追加すると、次のようなエラー・メッセージを受け取ります。
IWAE0024W アーカイブ xyz.jar の Manifest クラスパスには、項目、プロパティーが含まれていますが、EAR 内のファイルまたはモジュールに解決可能ではありません: サンプル...EJB 仕様はこの問題に対して明示的ではありません。しかし、EAR 内のルーズ・ファイルは無効であると暗示しています。現在、この構成は WebSphere Application Server 内で機能しますが、今後はこの構成に依存すべきではありません。
Java プロジェクトを作成し、プロパティー・ファイルをソース・フォルダー (または、プロジェクトがソース・フォルダーの場合はプロジェクト) に追加することができます。アプリケーション・エディターではこの Java プロジェクトをエディターの「モジュール」タブ上にプロジェクト・ユーティリティー JAR として追加し、その後、WebSphere テスト環境で EAR ファイルを実行できます。EAR ファイルをエクスポートする際、 Java プロジェクトは自動的に JAR に追加されて EAR に組み込まれます。
非ヌルの列を持つ外部キーを使用してスキーマ上でボトムアップのマッピングをする場合は、署名に追加された役割のクライアント・インターフェース・タイプを使用して、特殊 ejbCreate() メソッドを作成する必要があります。 ボトムアップのマッピングではこの処理は自動的には実行されません。
EJB 1.1 および 2.0 仕様をサポートするには、EJB 継承構造内の各サブタイプ Bean について一致する CMP フィールドを作成する必要があります。 EJB デプロイメント記述子エディターを開いて、ソース・ページ上でこれらのいずれかのフィールドの名前を変更した場合、 EJB 仕様を満たすためにサブタイプ Bean 上に作成した CMP フィールドでは該当する名前が変更されません。 回避策としては、Beans ページの「編集 (Edit)」操作を使用して名前を変更してください。
同一の Java クラスを使用して複数の Enterprise Bean をサポートするには、生成されたデプロイメント・クラスに固有の名前を付ける命名技法を使用するために、生成されたデプロイメント・コードが必要になります。 名前は、既存の Bean クラス、インターフェース、およびキー・クラスから派生されます。
Bean のデプロイメント・コードを生成した場合、これらのいずれかのクラスを変更するには、最初にデプロイメント・コードを削除する必要があります。 最初にデプロイメント・コードを削除しないと、以前に生成したクラスが削除されず、コンパイル・エラーが発生することがあります。 このことは、Bean ページの「編集 (Edit)」操作を使用して「primkey」フィールドのタイプを変更した場合にも当てはまります。 これでキー・クラスが指定タイプに自動的に変更されるか、または「primkey」フィールドが無効になっている場合は新しい複合キーが作成されます。
EJB ツールでは、EJB 2.0 仕様に定義されている不明の 1 次キーは現在サポートされていません。 回避策としては、特定の 1 次キー・クラスを定義してください。
1.1 CMP リレーションシップをサポートするために Link クラスが作成されます。 Link クラスには、Bean の 1 次キー・クラスに関する知識が必要になります。 リレーションシップを持つ 1.1 CMP について 1 次キー・クラスを変更した場合、生成された Link クラスに古い 1 次キー・クラスへの参照が残っています。 回避策としては、手動で Link クラスを更新してください。 たいていの場合、変更が必要なのは 2 回です。
CVS リポジトリーから EJB プロジェクトを更新した後に、クラスまたはインターフェースが反映されないことを示すエラーが「タスク (Tasks)」に表示された場合は、EJB プロジェクトを再ビルドして、エラーを訂正してください。
エラーは次のように表示されます。"CHKJ2802E: ejb-class class test.SessionBean, or one of its supertypes, cannot be reflected. Check the classpath."
アウトライン・ビューを使用して、ローカル・インターフェースが組み込まれた 2.0 CMP Bean から FIND 照会を削除すると、ローカル・ホーム・インターフェースからメソッド宣言を削除できません。 回避策としては、EJB デプロイメント記述子エディターの照会セクションにある「除去 (Remove)」ボタンを使用してください。
継承の階層内の CMP Bean の形状を変更する場合は、ソース・ページではなく、EJB デプロイメント記述子エディターのデザイン・ページを使用してください。 例えば、CMP フィールドを追加または削除する場合、あるいは CMP Bean の「prim-key」フィールドを変更する場合、Bean を EJB 仕様に準拠させるために、すべての継承 Bean についてこれらのフィールドをツールが同期化します。 ソース・ページでソースを変更すると、このような同期化は実行されません。
このシナリオでは、ユーザーは EJB 継承構造が定義済みで (ルート/リーフまたは単一テーブル継承のいずれかで)、この構造の中の EJB Bean に対する多対多のリレーションシップがあります。この場合、これらの Bean に定義されたどの EJB QL 照会にも誤った JOIN ステートメントがあります。
以下に構造の例を示します。
Customer <---- m:m ----> Account
|
|
------inherit------
| |
Checking Savings
CMP Bean を SQL サーバー・データベースにマップする際、浮動型のフィールドは REAL 型ではなく、 FLOAT 型の列にマップする必要があります。
EJB プロジェクト内の Enterprise Bean で、他のプロジェクトにある第 2 の Enterprise Bean の ホーム・インターフェースまたはリモート・インターフェースを使用している場合 (例えば、第 2 の Enterprise Bean の リモート・インターフェースをパラメーターとして取るメソッドを使用している場合)、第 2 の Enterprise Bean の ホーム・インターフェースまたはリモート・インターフェースを変更したときは、両方のプロジェクトのデプロイ済みコードを生成する必要があります。
それによって、第 2 の Enterprise Bean 用の RMIC で生成されたクラスが、両方のプロジェクトで最新であることが保証されます。
Enterprise Bean をデータベース・テーブルにマッピングする場合、外部キーおよび 1 次キーに関連する制約がいくつかあります。
- テーブルに複数の列を含む複数の外部キーがある場合、2 つの外部キーが異なる 2 つの EJB リレーションシップへのマッピングに使用されているときは、両方の外部キーを相互にオーバーラップすることはできません。 例えば、ForeignKey1 に ColumnA と ColumnB が含まれる場合、ForeignKey2 は ColumnC と ColumnD を含むことができますが、ColumnB と ColumnC を含むことはできません。ForeignKey2 に ColumnB と ColumnC が含まれる場合、2 つの外部キーは相互にオーバーラップします。
- テーブルに複数列の 1 次キーがあり、それらの列が 1 つ以上の外部キーによって共有されている場合、外部キーは 1 次キーとまったく同じ列を含むか、または完全に 1 次キーの外部にある列を含む必要があります。 例えば、PrimaryKey1 に ColumnA と ColumnB が含まれる場合、ForeignKey1 は ColumnA と ColumnB または ColumnC と ColumnD を含むことができますが、ColumnB と ColumnC を含むことはできません。複数の外部キーがある場合、各外部キーがこの要件を満たしている必要があります。
継承のマッピングに root-leaf の方法を使用する場合、または複数のテーブルに 2 次マップを使用する場合、参照保全性の順序付けの問題 (SQL ステートメントが正しい順序で実行されない) を避けるために、データベースから外部キー制約を除去する必要があります。
Access Bean は、ローカル・クライアント・ビューのみを持つ Enterprise Bean に対して サポートされていないため、Bean を EJB 1.1 から EJB 2.0 へマイグレーションし、ローカル・クライアント・ビューを追加してリモート・クライアント・ビューを除去するときは、手動でクリーンアップを行うことが必要な場合があります。 データ・クラス Access Bean を使用する場合は、Bean に関連したファクトリー・クラスを削除する必要があります。 コピー・ヘルパー Access Bean を使用する場合は、Access Bean 自体を削除し、ファクトリーを削除して、無効な可能性がある Bean クラスのメソッドをクリーンアップする必要があります。
EJB から RDB へのマッピングでコンバーターとコンポーザーを使用し、 WebSphere Application Server v4.0.6 にデプロイする場合は、 WebSphere Application Server に緊急修正プログラムを適用する必要があります。 WAS 緊急修正プログラムは vaprt.jar ファイルを更新します。
WAS 緊急修正プログラムは PQ76109 です。
WebSphere Studio Application Developer v5.1 では、デフォルトのコンバーターおよびコンポーザーを管理する vaprt.jar ファイルが変更されています。 これらの変更により、WebSphere Application Server v4.0.6 の vaprt.jar ファイルを 更新する必要があります。WAS 緊急修正プログラムはこの vaprt.jar ファイルを同期化します。
緊急修正プログラムの代替の回避策としては、j2ee.core プラグインのランタイム・ディレクトリーから WAS ランタイム lib ディレクトリーに vaprt.jar をコピーします。 緊急修正プログラムを適用していない WAS v4.0.6 の次のコンバーターまたは コンポーザーは期限が切れています。
VapBigDecimalToBooleanConverter VapBigDecimalToDoubleConverter VapBigDecimalToFloatConverter VapBigDecimalToIntegerConverter VapBigDecimalToLongConverter VapBigDecimalToShortConverter VapTimestampToUtilDateConverter NameComposer VapUSPhoneNumberComposer
マイグレーション・ウィザードを使用して、1 つ以上のバイナリー Java クラス (.class ファイル) を含む EJB プロジェクトをマイグレーションする場合、ソース Java ファイル (.java ファイル) を含むプロジェクト・コンポーネントのマイグレーションは正常に行われますが、バイナリー・クラスはマイグレーションされません。 エラーが発生した場合は、手動で修正する必要があります。
ボトムアップ・マッピングを行う (既存のテーブルを基に Enterprise Bean を生成 する) 場合、デフォルトではウィザードでビューの基礎テーブルの Bean は生成されません。 ただし、外部キーのリレーションシップを作成する必要があるため、ウィザードでは、 外部キーを持つテーブル用の Bean、またはその他のテーブルの外部キーが 示す 1 次キーを持つテーブル用の Bean が自動的に作成されます。「ビューの基礎 テーブル用の Bean を作成しない (Do not create beans for underlying tables for views)」 チェック・ボックスのチェックを外すと、ウィザードでは、データベース・ スキーマのすべてのテーブルとビューに対する Bean が生成されます。
(C) Copyright IBM Corporation 2000, 2003. All Rights Reserved.