アプリケーションに関する変更点

Enterprise Server v3 と Enterprise Server v2 との間にはアプリケーション関連の相違点があります。この節では、これらの相違点について説明します。

force オプション

Enterprise Server v3 では配備用の force オプションのデフォルト値は false です。Enterprise Server v2 では、このデフォルト値は true でした。Enterprise Server v3 では、再配備のためにオプションを明示的に true に設定する必要があります。このオプションは、アップグレード処理中に自動設定されません。この変更の目的は、既存アプリケーションのコンテンツが誤って上書きされないようにすることです。変更は管理コンソールとコマンド行ユーティリティーの両方に適用されます。

Enterprise Server v3 では asadmin redeploy コマンドも新しくなり、--force=true と同等の機能を提供します。force オプションは deploy コマンド (コマンド行インタフェースの場合) と deploy 画面 (コンソールの場合) にのみ適用できます。redeploy コマンドおよび redeploy 画面には適用できません。

アプリケーションおよび生成ディレクトリのレイアウト

Enterprise Server v2 にはアプリケーションリポジトリ用にapplications/j2ee-apps と applications/j2ee-modules という 2 つのサブディレクトリがありました。Enterprise Server v3 にはこのようなサブディレクトリはありません (j2ee-apps や j2ee-modules というレベルが存在しません)。Enterprise Server v2 で applications/j2ee-modules/foo 内にあった foo.war などのスタンドアロンモジュールの配備は、Enterprise Server v3 では applications/foo に格納されています。エンタープライズアプリケーションとスタンドアロンモジュールは基本的に同じ名前空間を共有するので、中間的なディレクトリ層は必要なくなりました。

domain.xml の application 要素

Enterprise Server v3 では web-module や ejb-module などの旧要素は廃止されて、新しい application 要素に置き換えられました。application 要素の詳細については、『Sun GlassFish Enterprise Server v3 Domain File Format Reference』の「application」を参照してください。

アップグレードの際、Enterprise Server v2 アプリケーションは新しい applications/ に再配備され、domain.xml に新しい application 要素が追加されます。Enterprise Server v3 に配備される新しいアプリケーションは、いずれも新しいディレクトリ構造と要素を持ちます。

JAR 可視性規則の厳格化

Java EE 6 では Java EE 5 のときよりも厳格な JAR 可視性規則が課されます。この結果として、古いアプリケーションの一部に障害が発生する可能性があります。

Java EE 6 仕様 では、どの JAR ファイルをエンタープライズアーカイブ (EAR) ファイルから見えるようにするかということに関して、厳格な規則が課されています。特に、EE.8.3.3 の節を参照してください。具体的には、アプリケーションクライアント JAR ファイルのマニフェスト Class-Path に EJB JAR ファイルが明示されていない限り、アプリケーションクライアントモジュールはいかなる EJB JAR ファイルに対してもアクセス権を持つことができません。

これは Enterprise Server v2 からの変更点です。Enterprise Server v2 では、EAR ファイルに含まれるすべての EJB JAR ファイル、および EAR ファイルの最上位にあるすべての JAR ファイルへのアクセス権がアプリケーションクライアントに自動的に付与されていました。より厳格な仕様言語に従うため、ProductName; v3 ではアプリケーションクライアントに JAR ファイルへのアクセス権を自動的に付与することはできません。

Java EE 6 によって課されたこの新しい厳格な動作に対処する方法は、次のとおりです。

• アプリケーションが Enterprise Server v2 ドメインに配備されている場合、アップグレードツールはそのドメイン内のアプリケーションに対して Enterprise Server v2 の動作を保持します。アップグレードの詳細については、『Sun GlassFish Enterprise Server v3 Upgrade Guide』を参照してください。

• 依存する JAR ファイルが明示されるように、クライアントのマニフェスト Class-Path を変更します。Class-Path に EAR ファイルのライブラリディレクトリ内の JAR ファイルを記述しないでください。仕様によって定められているように、このディレクトリ内のすべての JAR ファイルは EAR ファイル内のすべてのモジュールから利用できます。このディレクトリはデフォルトでは /lib です。また、application.xml 記述子で library-directory を使用してその他のディレクトリに設定することもできます。

• オプションの --property compatibility=v2 設定によって EAR ファイルを配備します。これにより、該当のアプリケーションが Enterprise Server v3 に配備される場合でも Enterprise Server v2 の動作を保持できます。

この動作の変更については、『Sun GlassFish Enterprise Server v3 Upgrade Guide』の第 1 章「Application Server Compatibility Issues」も参照してください。

アプリケーションクライアントの deploy --retrieve および get-client-stubs コマンド

Sun GlassFish Enterprise Server v3 で deploy --retrieve コマンドおよび get-client-stubs コマンドを実行した場合、Enterprise Server v2 の場合のように 1 つの JAR ファイルをローカルディレクトリにダウンロードするだけではなくなりました。Enterprise Server v3 でも localdir/myAppClient.jar が作成されて appclient コマンド内でターゲットとして使用できますが、もう 1 つのディレクトリ (localdir/myAppClient ) も作成されて、ここにその他のファイルが格納されます。

いつも Enterprise Server v2 でダウンロードされた 1 つの JAR ファイルをコピーすることによってアプリケーションクライアントのコンポーネントを別の場所に移動させていた場合、この操作は Enterprise Server v3 では無効になります。このような場合には asadmin get-client-stubs コマンドを使用する方法がサポートされています。このコマンドの詳細については、get-client-stubs(1) を参照してください。

それでもコピーを選択する場合は (Enterprise Server v2 の場合のように) localdir/myAppClient.jar ファイルのみをコピーするのではなく、 localdir/myAppClient ディレクトリの内容すべてをコピーしてください。