このトピックでは、EJB デプロイメントについて現在知られている制限の概要を説明します。
製品がインストールされているパスのいずれかのディレクトリーに複数の連続スペースがあると、デプロイメント・コードの生成が失敗します。
複数のエンタープライズ Bean による同じ Java™ クラスの使用をサポートするためには、生成されるデプロイメント・コードの生成は、生成されるデプロイメント・クラスの名前を固有にする命名技法を使用する必要があります。 名前は、既存 Bean クラス、インターフェース、およびキー・クラスの名前から派生します。
ある Bean のデプロイメント・コードを生成してから、 これらのクラスのいずれかの名前を変更するには、まずデプロイメント・コードを削除しなければなりません。 デプロイメント・コードを先に削除しないと、生成済みの古いクラスが除去されず、コンパイル・エラーが含まれることになります。 これは「Bean」ページで「編集」アクションを使用して primkey-field の型を変更した場合にも言えます。 この場合、キー・クラスが指定された型に自動的に変更されます。または、primkey-field が既に有効でない場合は、新しい複合キーが作成されます。
WebSphere Application Server v4.0.7 でのデプロイ
次のコンバーターまたはコンポーザーは、WebSphere Application Server v4.0.6 では欠落しているか、または既に無効です (ただし WebSphere Application Server v4.0.7 では更新されています)。
WebSphere Application Server v4.0.6 でデプロイ中に EJB から RDB へのマッピングでコンバーターおよびコンポーザーを使用する場合:
予備手段: j2ee.core プラグインのランタイム・ディレクトリーから WebSphere Application Server のランタイム lib ディレクトリーへ vaprt.jar をコピーします。
EJB 1.0 JAR ファイルを製品にマイグレーションしようとして、特定のデータベース・ベンダーを処理できるように既存の生成済みデプロイメント・コードの生成を変更した場合 (例えば、列名の文字を大/小文字混合に変更した場合)、その変更は製品を使用して JAR ファイルを再デプロイするときに保存されません。
当初 VisualAge® for Java を使用してマッピングの指定とデプロイメント・コードの生成を行っていた場合は、VisualAge for Java から EJB プロジェクトを EJB 1.1 JAR ファイルとしてエクスポートする必要があります。 これで、マッピング・メタデータと、表名および列名の大/小文字が保存されます。