|
| Sun ONE Application Server 7, Update 1 開発者ガイド |
J2EE アプリケーションのアセンブルと配備moduleSun ONE Application Server モジュールと、これらのモジュールをアプリケーション内に個別に、または一括してアセンブルする方法について説明します。アセンブリに影響を与える設計上の考慮事項については、「アプリケーションのモジュール化」を参照してください。
Sun ONE Application Server のモジュールおよびアプリケーションには、J2EE 標準の要素と Sun ONE Application Server 固有の要素が組み込まれています。moduleSun ONE Application Server 固有の要素についてのみ詳細に説明します。
このmoduleには次の節があります。
アセンブリと配備の概要
アプリケーションアセンブリ (パッケージ化とも呼ばれる) は、アプリケーションの個別のコンポーネントを、J2EE に準拠するアプリケーションサーバーに配備できる単位に結合するプロセスです。パッケージは、モジュールまたは独立したアプリケーションとして利用できます。この節には次の項目があります。
- モジュール
- アプリケーション
- J2EE 標準記述子
- Sun ONE Application Server 記述子
- ネーミングルール
- JNDI ネーミングサービス
- ディレクトリ構造
- 実行時環境
- クラスローダー
- サンプルアプリケーション
モジュール
J2EE モジュールは、J2EE コンポーネントの集合で、同一コンテナタイプ (たとえば Web、EJB など) の 2 つの配備記述子を持ちます。一方の配備記述子は J2EE 標準で、もう一方の記述子は Sun ONE Application Server 固有です。J2EE モジュールの種類は次のとおりです。
- Web アプリケーションアーカイブ (WAR) : Web アプリケーションは、Servlet、HTML ページ、クラスなどのリソースの集合で、いくつかの J2EE アプリケーションサーバーにバンドルして配備することができます。WAR ファイルは次のアイテムから構成されます。Servlet、JSP、JSP タグライブラリ、ユーティリティクラス、静的ページ、クライアントサイドアプレット、Beans、Bean クラス、および配備記述子 (web.xml およびオプションで sun-web.xml) から構成されます。
- EJB JAR ファイル : EJB JAR ファイルは、Enterprise JavaBean をアセンブルするときに使われる標準フォーマットです。このファイルには、Bean クラス (ホーム、リモート、ローカル、および実装)、すべてのユーティリティクラス、および配備記述子 (ejb-jar.xml および sun-ejb-jar.xml) が格納される。EJB コンポーネントがコンテナ管理による持続性を使用するエンティティ Bean である場合、.dbschema ファイルと CMP マッピング記述子ファイル (sun-cmp-mapping.xml) ファイルも同様に含まれる場合がある
- アプリケーションクライアントコンテナ JAR ファイル: ACC クライアントは、Sun ONE Application Server 固有の J2EE クライアントである。ACC クライアントでは、J2EE 標準のアプリケーションクライアント仕様がサポートされているだけでなく、Sun ONE Application Server に直接アクセスすることができる。このクライアントの配備記述子は、application-client.xml と sun-application-client.xml である
- リソース RAR ファイル : RAR ファイルは、J2EE CA コネクタに適用されます。コネクタモジュールは、デバイスドライバのような働きをします。この移植性のある方法を使用すると、EJB コンポーネントは外部の企業システムにアクセスできるようになる。Sun ONE Application Server の各コネクタには、J2EE XML ファイルである ra.xml がある。また、Sun ONE Application Server 配備記述子である sun-ra.xml も必要となる
モジュールを配備した後にクラスローダーが正しいクラスを検索できるように、すべてのモジュールのソースコードでパッケージ定義を使う必要があります。
配備記述子内の情報は宣言型であるため、ソースコードを変更しなくても変更できます。J2EE サーバーは、実行時に読み込んだ配備記述子内の情報に従って動作します。
Sun ONE Application Server は、ライフサイクルモジュールもサポートしています。詳細は、「ライフサイクルリスナーの開発」を参照してください。
次の図に示すように、EJB JAR モジュールと Web モジュールは JAR ファイルまたは WAR ファイルとして個別にアセンブルされ、アプリケーションの外部に個別に配備することもできます。
モジュールのアセンブリと配備
アプリケーション
J2EE アプリケーションは、1 つまたは複数の J2EE モジュールの論理集合で、アプリケーション配備記述子によって関連付けられています。コンポーネントは、モジュールレベルまたはアプリケーションレベルでアセンブルできます。また、モジュールレベルまたはアプリケーションレベルで配備することもできます。
次の図は、配備する準備として、モジュールにコンポーネントをアセンブルしてから、Sun ONE Application Server アプリケーションの EAR ファイルにアセンブルする方法を示しています。
アプリケーションのアセンブリと配備
各モジュールには、Sun ONE Application Server 配備記述子および J2EE 配備記述子が定義されています。Sun ONE Application Server 管理インタフェースは、配備記述子を使って、アプリケーションコンポーネントを配備し、Sun ONE Application Server にリソースを登録します。
アプリケーションは、1 つまたは複数のモジュール、オプションの Sun ONE Application Server 配備記述子、および必要な J2EE アプリケーション配備記述子で構成されています。これらのすべてのアイテムが、Java ARchive (.jar) ファイル形式で、拡張子 .ear を持つ 1 つのファイルにアセンブルされます。
J2EE 標準記述子
J2EE プラットフォームでは、アセンブリおよび配備機能が提供されます。これらの機能では、コンポーネントおよびアプリケーションの標準パッケージとして WAR、JAR、EAR ファイルが使われ、パラメータのカスタマイズには XML ベースの配備記述子が使われます。
J2EE の標準配備記述子の詳細は、次のサイトでバージョン 1.3 の J2EE 仕様書を参照してください。
配備前に配備記述子の正しさを確認する方法については、「配備記述子ベリファイア」を参照してください。
次の表は、J2EE 標準配備記述子に関する詳細情報の参照先を示しています。左の列は配備記述子、右の列はそれらの記述子に関する詳細情報の参照先を示しています。
Sun ONE Application Server 記述子
Sun ONE Application Server では、Sun ONE Application Server 固有の機能を設定するために追加の配備記述子を使用します。sun-application.xml ファイルと sun-web.xml ファイルはオプションで、それ以外のすべての配備記述子は必須です。
すべての Sun ONE Application Server 配備記述子用の DTD スキーマファイルは、install_dir/lib/dtds ディレクトリにあります。
配備前に配備記述子の正しさを確認する方法については、「配備記述子ベリファイア」を参照してください。
次の表は、Sun ONE Application Server 配備記述子についての詳細情報の参照先を示しています。左の列は配備記述子、右の列はそれらの記述子に関する詳細情報の参照先を示しています。
注 Sun ONE Application Server 配備記述子は、UNIX システム上で 600 のアクセス権限を持っている必要があります。
ネーミングルール
アプリケーション名および個別に配備された EJB、JAR、WAR、およびコネクタ RAR モジュールの名前 (server.xml ファイル内の name 属性によって指定される) は、Sun ONE Application Server 内で一意である必要があります。名前を指定しない場合、ファイル名の最初の部分がデフォルト名となります (.war または .jar 拡張子は含まない)。server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
さまざまなタイプのモジュールが、1 つのアプリケーション内で同じ名前を持つ可能性があります。なぜなら、アプリケーションが配備されると、それぞれのモジュールを持つディレクトリ名には、_jar、_war、_rar などのサフィックスが付けられるためです。1 つのアプリケーション内にある同じタイプのモジュールには、一意の名前を付ける必要があります。また、CMP を使用するエンティティ Beans では、同じアプリケーション内で .dbschema ファイルに一意の名前を付ける必要があります。
パッケージとファイル名に、スペースやお使いのオペレーティングシステムで不正となる文字が含まれていないことを確認してください。
JNDI ネーミングサービス
クライアントまたは Web アプリケーションが EJB コンポーネントと通信する場合、または Web アプリケーションまたは EJB コンポーネントが JDBC や別のリソースからのサービスを必要とする場合は、ネーミングサービスによって相互のコンポーネントが特定され、対話が行われます。ネーミングサービスは、名前とオブジェクトを関連付けるバインドのセットを維持します。J2EE のネーミングサービスは JNDI (Java Naming and Directory Interface) です。
Sun ONE Application Server では、コンテナがコンポーネントに命名環境 (コンテキスト) を提供しています。これにより、コンポーネントは分散しているその他のコンポーネントやリソースを検索できます。Context オブジェクトは、名前とオブジェクトのバインド、名前とオブジェクトのバインド解除、オブジェクト名の変更、バインドリストの表示を実行するメソッドを提供します。
JNDI はサブコンテキスト機能にも対応しています。ファイルシステムのディレクトリのように、サブコンテキストはコンテキストに含まれるコンテキストです。この階層構造により、情報を効率的に組織化できます。サブコンテキストをサポートするネーミングサービスでは、Context クラスはサブコンテキストの生成と削除を実行するメソッドも提供します。
EJB コンポーネントの JNDI 名は一意である必要があります。たとえば、EJB 名にアプリケーション名とモジュール名を追加すると、確実に一意な名前になります。この場合、モジュール pkgingEJB.jar 内の EJB の JNDI 名は、アプリケーション pkging.ear にパッケージ化されているため、mycompany.pkging.pkgingEJB.MyEJB になります。
注 JNDI 内のその他のエンタープライズリソース名との衝突や移植性の問題を回避するため、Sun ONE Application Server アプリケーション内のすべての名前を、文字列 java:comp/env で始める必要があります。
次の表は、Sun ONE Application Server の接続ファクトリの JNDI サブコンテキストを示しています。左の列にリソースマネージャのタイプ、中央の列に接続ファクトリのタイプ、右の列に JNDI サブコンテキストを示します。
ディレクトリ構造
アプリケーションを配備すると、アプリケーションは空のディレクトリ構造に展開され、個別のモジュールを持つディレクトリ名には、_jar、_war、_rar などのサフィックスが付けられます。EAR ファイルの代わりに、asadmin deploydir コマンドを使用してディレクトリを構成した場合、ディレクトリ構造はこの規則に従っています。
モジュールおよびアプリケーションのディレクトリ構造は、J2EE 仕様書に示されている構造に準拠します。次に、Web モジュール、EJB モジュール、クライアントモジュールを含む簡単なアプリケーションのディレクトリ構造の一例を示します。
+ converter_1/
|--- converterClient.jar
|--+ META-INF/
| |--- MANIFEST.MF
| |--- application.xml
| '--- sun-application.xml
|--+ war-ic_war/
| |--- index.jsp
| |--+ META-INF/
| | |--- MANIFEST.MF
| '--+ WEB-INF/
| |--- web.xml
| '--- sun-web.xml
|--+ ejb-jar-ic_jar/
| |--- Converter.class
| |--- ConverterBean.class
| |--- ConverterHome.class
| '--+ META-INF/
| |--- MANIFEST.MF
| |--- ejb-jar.xml
| '--- sun-ejb-jar.xml
'--+ app-client-ic_jar/
|--- ConverterClient.class
'--+ META-INF/
|--- MANIFEST.MF
|--- application-client.xml
'--- sun-application-client.xml
次に、個別に配備したコネクタモジュールのディレクトリ構造の例を示します。
+ MyConnector/
|--- readme.html
|--- ra.jar
|--- client.jar
|--- win.dll
|--- solaris.so
'--+ META-INF/
|--- MANIFEST.MF
|--- ra.xml
'--- sun-ra.xml
実行時環境
個々のモジュールまたはアプリケーションを配備すると、ファイルシステムとサーバー設定の両方が配備の影響を受けます。次に示す図「モジュールの実行時環境」と「アプリケーションの実行時環境」を参照してください。
モジュールの実行時環境
次の図は、モジュールベースで個別に配備した場合の実行時環境です。
モジュールの実行時環境
ファイルシステムのエントリとして、モジュールは次のように抽出されます。
instance_dir/applications/j2ee-modules/module_name
instance_dir/generated/ejb/j2ee-modules/module_name
instance_dir/generated/jsp/j2ee-modules/module_nameapplications ディレクトリには、「ディレクトリ構造」で説明したディレクトリ構造が含まれます。generated/ejb ディレクトリには、ACC クライアントがモジュールにアクセスするときに必要となるスタブとタイが保存され、generated/jsp ディレクトリにはコンパイルされた JSP が保存されます。
ライフサイクルモジュール (「ライフサイクルリスナーの開発」を参照) は、次の手順で抽出されます。
instance_dir/applications/lifecycle-modules/module_name
設定エントリは、server.xml 内に次のように追加されます。
<server>
<applications>
<type-module>
...module configuration...
</type-module>
</applications>
</server>server.xml 内のモジュールの type は、lifecycle、ejb、web、または connector のいずれかになります。server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
アプリケーションの実行時環境
次の図は、アプリケーションベースで配備した場合の実行時環境を示しています。
アプリケーションの実行時環境
ファイルシステムのエントリとして、アプリケーションは次のように抽出されます。
instance_dir/applications/j2ee-apps/app_name
instance_dir/generated/ejb/j2ee-apps/app_name
instance_dir/generated/jsp/j2ee-apps/app_nameapplications ディレクトリには、「ディレクトリ構造」で説明したディレクトリ構造が含まれます。generated/ejb ディレクトリには、ACC クライアントがモジュールにアクセスするときに必要となるスタブとタイが保存され、generated/jsp ディレクトリにはコンパイルされた JSP が保存されます。
設定エントリは、server.xml 内に次のように追加されます。
<server>
<applications>
<j2ee-application>
...application configuration...
</j2ee-application>
</applications>
</server>server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
クラスローダー
Sun ONE Application Server クラスローダーについて理解すると、サポートしている JAR ファイルとリソースファイルをモジュールおよびアプリケーションのどこに配備するかや、その方法を決定しやすくなります。
Java 仮想マシン (JVM) のクラスローダーは、依存関係の解決に必要な Java クラスファイルを動的に読み込みます。たとえば、java.util.Enumeration のインスタンスを作成する場合は、クラスローダーの 1 つが関連するクラスを実行時環境に読み込みます。この節には次の項目があります。
クラスローダーの階層
Sun ONE Application Server 実行時環境のクラスローダーは、次に示す階層に構成されています。
クラスローダーの実行時階層
これは、Java 継承階層ではなく、委譲階層です。委譲方式のクラスローダーは、自分でクラスを読み込まずに、親へクラスの読み込み作業を委託します。クラスローダーの親は、システムクラスローダーか、または別のカスタムクラスローダーのいずれかです。親クラスローダーがクラスを読み込めない場合、クラスローダーサブクラスで、findClass() メソッドが呼び出されます。つまり、クラスローダーは、親が読み込めないクラスだけを読み込みます。
Web クラスローダーは例外で、サーブレット仕様の委譲モデルに従います。Web クラスローダーは、親に委譲する前にローカルクラスローダーを調べます。Web クラスローダーが最初に親に委譲するようにするには、sun-web.xml ファイルの class-loader 要素を delegate="true" に設定します。詳細は、『Web アプリケーション開発者ガイド』を参照してください。
注 Web サービスの Web コンポーネントで使われる Web クラスローダーは、親クラスローダーに委譲する必要があります。この場合は、sun-web.xml ファイルの class-loader 要素を delegate="true" に設定します。
次の表は、Sun ONE Application Server のクラスローダーを示しています。左の列はクラスローダー、右の列はそのクラスローダーの説明と参照するファイルを示しています。
クラスローダー領域
サーバー上にインストールしたアプリケーションやモジュール内のコンポーネントへのアクセスは、分離されたクラスローダー領域のコンテキスト内で発生し、各領域は、専用の EJB、Web、および JSP エンジンクラスローダーを持ちます。
- アプリケーション領域 : 各 J2EE アプリケーションは、アプリケーションのすべてのモジュール内にあるクラスを読み込む、専用のクラスローダー領域を持っている
- 個別に配備されたモジュール領域 : 個別に配備された各 EJB JAR、web WAR、またはライフサイクルモジュールは、モジュール内のクラスを読み込む、専用のクラスローダー領域を持っている
注 iPlanet Application Server 6.x では、個別に配備されたモジュールは同じクラスローダーを共有していました。Sun ONE Application Server 7 では、個別に配備されたモジュールは、それぞれ専用のクラスローダー領域を持っています。
クラスローダー分離の回避
各アプリケーションまたは個別に配備されたモジュールのクラスローダー領域は分離されているため、アプリケーション (またはモジュール) は、別のアプリケーション (またはモジュール) からクラスを読み込むことができません。このため、異なるアプリケーションに同じ名前の 2 つのクラスがあったとしても、互いに問題になることはありません。
複数のアプリケーションによってアクセスされるライブラリ、ユーティリティクラス、または個別に配備されたモジュールに対して、この制限が適用されないようにするには、次のいずれかの方法で、必要なクラスへの相対パスを追加します。
システムクラスローダーの使用
システムクラスローダーを使用するには、次のいずれかを実行した後、サーバーを再起動します。
- 管理インタフェースからサーバーインスタンスページを表示し、「JVM 設定」タブを選択し、「パス設定」オプションを選択してから、「クラスパスのサフィックス」フィールドを編集し、「保存」を選択する
- server.xml ファイル内の java-config 要素の classpath-sufix 属性を編集する。server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
システムクラスローダーを使用すると、アプリケーションまたはモジュールが、サーバーインスタンス内のほかのアプリケーションまたはモジュールにアクセスできるようになります。
共通クラスローダーの使用
共通クラスローダーを使用するには、JAR および ZIP ファイルを instance_dir/lib ディレクトリにコピーするか、または .class ファイルを instance_dir/lib/classes ディレクトリにコピーした後、サーバーを再起動します。
共通クラスローダーを使用すると、アプリケーションまたはモジュールが、サーバーインスタンス内のほかのアプリケーションまたはモジュールにアクセスできるようになります。
アプリケーション内の別アプリケーション用クライアント JAR のパッケージ化
アプリケーション A に含まれるアプリケーション B 用にクライアント JAR をパッケージ化することで、アプリケーション B の EJB コンポーネントまたは Web コンポーネントが、アプリケーション A (従属アプリケーション) の EJB コンポーネントを呼び出せるようになります。このとき、どちらのアプリケーションのコンポーネントも、別のアプリケーションやモジュールにアクセスできるようにする必要はありません。
アプリケーションに含まれる別アプリケーション用にクライアント JAR をパッケージ化することには、短所もあります。-nolocalstubs オプションを有効化すると、他のアプリケーションのクライアント JAR を含む複数のアプリケーションを、サーバーを再起動せずに配備できるようになります。ただし、-nolocalstubs オプションの使用はサーバーのパフォーマンスを低下させることがあります。
その代わりに、「共通クラスローダーの使用」で説明する方法で共通クラスローダーに従属アプリケーションのクライアント JAR をロードさせることができます。サーバーのパフォーマンスは良くなりますが、従属アプリケーションにアクセスするにはサーバーの再起動が必要です。またサーバーインスタンス内でのアクセスが可能になります。本稼動環境ではこの方法をお勧めします。
アプリケーション内の別アプリケーション用にクライアント JAR をパッケージ化するには、次の手順に従います。
- 次のいずれかの方法でサーバーインスタンスの rmic オプションに -nolocalstubs オプションを追加し、サーバーを再起動します。
管理インタフェースでサーバーインスタンスページを表示し、「JVM 設定」タブを選択し、「一般」オプションを選択してから、「rmic オプション」フィールドに -nolocalstubs を追加し、「保存」を選択する
server.xml ファイル内の java-config 要素の rmic-options 属性に -nolocalstubs を追加する。server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
この変更を加えると、それ以後に配備するすべての EJB コンポーネントには、リモートアクセスだけが可能となります。
注 -nolocalstubs オプションの使用はサーバーのパフォーマンスを低下させることがあります。
- 従属アプリケーションを配備します。
- 従属アプリケーションのクライアント JAR ファイルを呼び出し側アプリケーションに追加します。
EJB コンポーネントの呼び出しでは、EJB コンポーネントと同じレベルにクライアント JAR ファイルを追加する。次に、呼び出し側 EJB コンポーネントの MANIFEST.MF ファイルに Class-Path エントリを追加する。Class-Path エントリの構文は、次のとおりです。
Class-Path:filepath1.jar filepath2.jar ...
それぞれの filepath は、MANIFEST.MF ファイルを含むディレクトリまたは JAR ファイルに対して相対的なものです。詳細は、J2EE 仕様書の第 8.1.1.2 項「Dependencies」を参照してください。
呼び出し側の Web コンポーネントでは、WEB-INF/lib ディレクトリの下にクライアント JAR ファイルを追加する
- ほとんどのアプリケーションでは、クライアント JAR ファイルと呼び出し側 EJB コンポーネントをパッケージ化するだけで十分です。Web コンポーネントが従属アプリケーションの EJB コンポーネントを直接呼び出す場合を除き、EJB コンポーネントと Web コンポーネントの両方をクライアント JAR ファイルとパッケージ化する必要はありません。EJB コンポーネントと Web コンポーネントの両方をクライアント JAR とパッケージ化するときは、sun-web.xml ファイルの class-loader 要素に delegate="true" を設定します。この設定により、クラスローダーの標準の委譲モデルが適用され、Web クラスローダーはクラス自体をロードする前に親に委譲します。
- 呼び出し側アプリケーションを配備します。
注 呼び出し側の EJB コンポーネントまたは Web コンポーネントは、従属アプリケーション側の EJB コンポーネントと同じ JNDI 名を使う必要があります。ejb-ref マッピングは機能しません。
サンプルアプリケーション
Sun ONE Application Server には、参照したり配備したりできるサンプルアプリケーションがあり、install_dir/samples ディレクトリに含まれています。サンプルアプリケーションは、ejb、jdbc、connectors、i18n などのカテゴリに分かれています。サンプルアプリケーションの各カテゴリは、さらにサブカテゴリに分かれています。たとえば ejb カテゴリには、 stateless、stateful、security、mdb、bmp、cmp のサブカテゴリがあります。
Sun ONE Application Server のほとんどのサンプルアプリケーションは、次のディレクトリ構造を持ちます。
- docs ディレクトリには、サンプルアプリケーションの使用方法に関するドキュメントが保存されている
- src ディレクトリには、次の内容が保存されている
サンプルの asant ターゲットを定義した build.xml ファイル (「Apache Ant のアセンブリツールおよび配備ツール」を参照)
配備記述子
- build ディレクトリ、assemble ディレクトリ、および javadocs ディレクトリは、build.xml ファイルに指定されているターゲットの結果として生成される
install_dir/samples/common.xml ファイルには、すべてのサンプルアプリケーションに共通するプロパティが定義されており、サンプルアプリケーションのコンパイル、アセンブル、配備、配備取消しに必要なターゲットを実装します。ほとんどのサンプルアプリケーションでは、build.xml ファイルが common.xml ファイルを含みます。
注 install_dir/samples/webservices の下にあるサンプルアプリケーションを使用する前に、jre/lib/endorsed ディレクトリに Java XML Pack JAR ファイルをコピーし、JDK に付属する JAR ファイルを上書きします。
次の図は、helloworld というサンプルアプリケーションの構造を示しています。
サンプルアプリケーション helloworld
Sun ONE Application Server に配備したサンプルアプリケーションは、次の URL を使って起動できます。
http://server:port/helloworld
サンプルアプリケーションの詳細、および配備と実行の方法については、次のディレクトリにある関連ドキュメントを参照してください。
install_dir/samples/ejb/stateless/simple/docs/index.html
モジュールとアプリケーションのアセンブル
Sun ONE Application Server 内でモジュールおよびアプリケーションをアセンブリ
(パッケージ化) するときは、従来のすべての J2EE 仕様書に準拠する必要があります。ただし、Sun ONE Application Server 内でアセンブルするときは、Sun ONE Application Server 固有の配備記述子 (sun-web.xml、sun-ejb-jar.xml など) を含めて、アプリケーションサーバーの機能を拡張する必要があります。この節には次の項目があります。
- アセンブリ用ツール
- WAR モジュールのアセンブル
- EJB JAR モジュールのアセンブル
- ライフサイクルモジュールのアセンブル
- アプリケーションのアセンブル
- ACC クライアントのアセンブル
- J2EE CA リソースアダプタのアセンブル
アセンブリ用ツール
Sun ONE Application Server では、モジュールまたはアプリケーションのアセンブルを次の方法で行うことができます。
Apache Ant
Ant は、モジュールとアプリケーションのアセンブルおよび配備に役立ちます。詳細については、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
Sun ONE Studio
J2EE アプリケーションとモジュールのアセンブルには Sun ONE Studio 4 を利用できます。Sun ONE Studio に関する詳細は、『Sun ONE Studio 4, Enterprise Edition のチュートリアル』を参照してください。
配備記述子ベリファイア
ベリファイアツールは、J2EE 配備記述子と Sun ONE Application Server 固有の配備記述子の両方を、対応する DTD ファイルと比較し、モジュールまたはアプリケーションが J2EE および Sun ONE Application Server に準拠していない場合にエラーや警告を返します。EAR、WAR、RAR、JAR ファイルの配備記述子を検証できます。
ベリファイアツールは、単なる XML 構文ベリファイアではありません。配備記述子に含まれるさまざまな要素間で、ルールと相互依存関係が検証されます。必要に応じて、ユーザーアプリケーションクラスを調べて検証ルールを適用します。
ベリファイアは、sun-appserv-deploy Ant タスクにも統合されています。
ヒント ベリファイアツールを使うことで、デバッグが難しい実行時エラーを回避できます。
この節には次の項目があります。
コマンド行ユーティリティ
ベリファイアツールの構文は次のとおりです。
verifier [options] file
file には、EAR、WAR、RAR、または JAR ファイルを指定できます。
次の表は、verifier コマンドの options (省略可能) を示しています。左の列はオプション、右の列は各オプションの説明です。
たとえば、次のコマンドを実行するとベリファイアが詳細モードで実行され、ejb.jar ファイルの静的検証のすべての結果が ResultsDir ディレクトリに書き出されます。
verifier -v -ra -d ResultsDir ejb.jar
結果ファイルは、ejb.jar_verifier.txt と ejb.jar_verifier.xml になります。
ベリファイアが問題なく実行されると、結果コード 0 が返されます。これは、検証エラーがなかったことを意味するわけではありません。ベリファイアの実行に失敗した場合は、ゼロ以外の値が返されます。
Ant の統合
Ant の build ファイルにターゲットとしてベリファイアを統合すると、アプリケーションまたはモジュールをアセンブルするたびに、Ant の呼び出し機能を使ってターゲットを呼び出せます。これは、com.sun.enterprise.tools.verifier.Verifier の main メソッドをユーザー Ant スクリプトから呼び出せるためです。main メソッドは、「verifier コマンドのオプション」の表で説明した引数を受け入れます。
次に、Ant の verify ターゲットのコード例を示します。
<target name="verify">
<echo message="Verification Process for ${testfile}"/>
<java classname="com.sun.enterprise.tools.verifier.Verifier"
fork="yes">
<sysproperty key="com.sunone.enterprise.home"
value="${appserv.home}"/>
<sysproperty key="verifier.xsl"
value="${appserv.home}/verifier/config" />
<!-- uncomment the following for verbose output -->
<!--<arg value="-v"/>-->
<arg value="${assemble}/${ejbjar}" />
<classpath path="${appserv.cpath}:${java.class.path}"/>
</java>
</target>結果ファイルの例
次に、結果ファイル (XML ファイル) の例を示します。
<static-verification>
<ejb>
<failed>
<test>
<test-name>
tests.ejb.session.TransactionTypeNullForContainerTX
</test-name>
<test-assertion>
Session bean with bean managed transaction demarcation test
</test-assertion>
<test-description>
For [ TheGreeter ] Error:Session Beans [ TheGreeter ] with [ Bean ] managed transaction demarcation should not have container transactions defined.
</test-description>
</test>
</failed>
</ejb>
...
</static-verification>次に、結果ファイル (TXT ファイル) の例を示します。
---------------------------
STATIC VERIFICATION RESULTS
---------------------------
----------------------------------
NUMBER OF FAILURES/WARNINGS/ERRORS
----------------------------------
# of Failures : 3
# of Warnings : 6
# of Errors : 0
-----------------------------
RESULTS FOR EJB-RELATED TESTS
-----------------------------
--------------
FAILED TESTS :
--------------
Test Name :tests.ejb.session.TransactionTypeNullForContainerTX
Test Assertion :Session bean with bean managed transaction demarcation test
Test Description :For [ TheGreeter ]
Error:Session Beans [ TheGreeter ] with [ Bean ] managed transaction demarcation should not have container transactions defined.
...
---------------
PASSED TESTS :
---------------
Test Name :tests.ejb.session.ejbcreatemethod.EjbCreateMethodStatic
Test Assertion :Each session Bean must have at least one non-static ejbCreate method test
Test Description :For [ TheGreeter ] For EJB Class [ samples.helloworld.ejb.GreeterEJB ] method [ ejbCreate ] [ samples.helloworld.ejb.GreeterEJB ] properly declares non-static ejbCreate(...) method.
...
-----------
WARNINGS :
-----------
Test Name :tests.ejb.businessmethod.BusinessMethodException
Test Assertion :Enterprise bean business method throws RemoteException test
Test Description :
Test Name :tests.ejb.ias.beanpool.IASEjbBeanPool
Test Assertion :
Test Description :WARNING [IAS-EJB ejb] :bean-pool should be defined for Stateless Session and Message Driven Beans
...
---------------------
NOTAPPLICABLE TESTS :
---------------------
Test Name :tests.ejb.entity.pkmultiplefield.PrimaryKeyClassFieldsCmp
Test Assertion :Ejb primary key class properly declares all class fields within subset of the names of the container-managed fields test.
Test Description :For [ TheGreeter ] class com.sun.enterprise.tools.verifier.tests.ejb.entity.pkmultiplefield. PrimaryKeyClassFieldsCmp expected Entity bean, but called with Session.
Test Name :tests.ejb.entity.ejbcreatemethod.EjbCreateMethodReturn
Test Assertion :Each entity Bean may have zero or more ejbCreate methods which return primary key type test
Test Description :For [ TheGreeter ] class com.sun.enterprise.tools.verifier.tests.ejb.entity.ejbcreatemethod. EjbCreateMethodReturn expected Entity bean, but called with Session bean.
...
-----------------------------------
RESULTS FOR OTHER XML-RELATED TESTS
-----------------------------------
---------------
PASSED TESTS :
---------------
Test Name :tests.dd.ParseDD
Test Assertion :Test parses the deployment descriptor using a SAX parser to avoid the dependency on the DOL
Test Description :PASSED [EJB] :[ remote ] and [ home ] tags present.
PASSED [EJB]:session-type is Stateless.
PASSED [EJB]:trans-attribute is NotSupported.
PASSED [EJB]:transaction-type is Bean.
...WAR モジュールのアセンブル
WAR モジュールをアセンブルするには、次の手順で行います。
- 作業ディレクトリを作成し、Web モジュールのコンテンツをその中にコピーします。ディレクトリの構造については、『Sun ONE Application Server Web アプリケーション開発者ガイド』の説明を確認してください。
- web.xml (必須)および sun-web.xml (省略可能) という名前の 2 つの配備記述子ファイルを作成します。これらのファイルの詳細は、『Sun ONE Application Server Web アプリケーション開発者ガイド』を参照してください。
ヒント 最初は、WAR モジュールのアセンブルと配備記述子の作成に Sun ONE Studio を使えます。生成された WAR ファイルから配備記述子を抽出することもできます。
- 次のコマンドを実行して、WAR ファイルを作成します。
jar -cvf module_name.war *
ヒント アセンブルプロセスは、Ant ツールを使って自動化できます。詳細は、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
EJB JAR モジュールのアセンブル
EJB JAR モジュールをアセンブルするには、次の手順で行います。
- 作業ディレクトリを作成し、モジュールの内容をコピーします。ディレクトリの構造については、『Sun ONE Application Server Enterprise JavaBeans 開発者ガイド』の説明を確認してください。
- ejb-jar.xml および sun-ejb-jar.xml という名前の 2 つの配備記述子ファイル (どちらも必須) を作成します。これらのファイルの詳細は、『Sun ONE Application Server Enterprise JavaBeans 開発者ガイド』を参照してください。EJB コンポーネントがコンテナ管理による持続性を使用するエンティティ Bean である場合、.dbschema ファイルおよび sun-cmp-mapping.xml ファイルも作成する必要があります。
ヒント 最初は、EJB WAR モジュールのアセンブルと配備記述子の作成に Sun ONE Studio を使えます。生成された EJB JAR ファイルから配備記述子を抽出することもできます。
- 次のコマンドを実行して、JAR ファイルを作成します。
jar -cvf module_name.jar *
ヒント アセンブルプロセスは、Ant ツールを使って自動化できます。詳細は、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
注 J2EE 仕様の第 8.1.1.2 項「Dependencies」には、個別に配備した EJB モジュールのユーティリティクラスをパッケージ化できないことが規定されています。その代わりに、JAR Extension Mechanism Architecture を使ってアプリケーション内の EJB モジュールとユーティリティ JAR をパッケージ化します。それ以外の方法については、「クラスローダー分離の回避」を参照してください。
ライフサイクルモジュールのアセンブル
ライフサイクルモジュールをアセンブルするには、次の手順で行います。
- 作業ディレクトリを作成し、モジュールの内容をコピーします。
- 次のコマンドを実行して、JAR ファイルを作成します。
jar -cvf module_name.jar *
ヒント アセンブルプロセスは、Ant ツールを使って自動化できます。詳細は、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
ライフサイクルモジュールの全般的な情報については、「ライフサイクルリスナーの開発」を参照してください。
アプリケーションのアセンブル
アプリケーションをアセンブルするには、次の手順で行います。
- 作業ディレクトリを作成し、すべてのモジュールを含むアプリケーションのコンテンツをその中にコピーします。ディレクトリの構造については、『Sun ONE Application Server Enterprise JavaBeans 開発者ガイド』の説明を確認してください。
- application.xml (必須) および sun-application.xml (省略可能) という名前の 2 つの配備記述子ファイルを作成します。これらのファイルの詳細は、「サンプルアプリケーション XML ファイル」を参照してください。
ヒント 最初は、アプリケーションのアセンブルと配備記述子の作成に Sun ONE Studio を使えます。生成された EAR ファイルから配備記述子を抽出することもできます。
- 次のコマンドを実行して、J2EE アプリケーションの EAR ファイルを作成します。
jar -cvf app_name.ear *
ヒント アセンブルプロセスは、Ant ツールを使って自動化できます。詳細は、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
ACC クライアントのアセンブル
この節では、ACC クライアントのアセンブルについて簡単に説明します。ただし、『Sun ONE Application Server Developer's Guide to Clients』の内容を理解していることを前提としています。
ACC クライアントの JAR モジュールをアセンブルするには、次の手順で行います。
- 作業ディレクトリを作成し、モジュールの内容をコピーします。ディレクトリの構造については、『Sun ONE Application Server Developer's Guide to Clients』の説明を確認してください。
- application-client.xml および sun-application-client.xml という名前の 2 つの配備記述子ファイル (どちらも必須) を作成します。これらのファイルの詳細は、『Sun ONE Application Server Developer's Guide to Clients』を参照してください。
ヒント 最初は、クライアント JAR モジュールのアセンブルと配備記述子の作成に Sun ONE Studio を使えます。生成されたクライアント JAR ファイルから配備記述子を抽出することもできます。
- 次のコマンドを実行して、クライアント JAR ファイルを作成します。
jar -cvfm module_name.jar META-INF/MANIFEST.MF *
ヒント アセンブルプロセスは、Ant ツールを使って自動化できます。詳細は、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
ACC クライアントの配備とクライアントマシンの準備については、「ACC クライアントの配備」で簡単に説明しています。
J2EE CA リソースアダプタのアセンブル
この節では、J2EE CA リソースアダプタのアセンブルについて簡単に説明します。ただし、『Sun ONE J2EE CA Service Provider Implementation 管理者ガイド』の内容を理解していることを前提としています。
次の XML コネクタファイルは、コネクタをアプリケーションサーバーに配備するのに必要です。
- ra.xml
- sun-ra.xml (セキュリティマップを含む)
ra.xml ファイルは J2EE CA 仕様に基づいており、コネクタにパッケージ化されています。sun-ra.xml ファイルは Sun ONE Application Server 固有の情報を含んでいます。
RAR モジュールをアセンブルするには、次の手順で行います。
- 作業ディレクトリを作成し、モジュールの内容をコピーします。ディレクトリの構造については、『Sun ONE J2EE CA Service Provider Implementation 管理者ガイド』の説明を確認してください。
- ra.xml および sun-ra.xml という名前の 2 つの配備記述子を作成します。これらのファイルに関する詳細は、『Sun ONE J2EE CA Service Provider Implementation 管理者ガイド』を参照してください。
ヒント 最初は、RAR モジュールのアセンブルと配備記述子の作成に Sun ONE Studio を使えます。生成された RAR ファイルから配備記述子を抽出することもできます。
- 次のコマンドを実行して、RAR ファイルを作成します。
jar -cvf module_name.rar *
ヒント アセンブルプロセスは、Ant ツールを使って自動化できます。詳細は、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
モジュールおよびアプリケーションの配備
この節では、J2EE のアプリケーションおよびモジュールを Sun ONE Application Server に配備する方法について説明します。この節には、次の項目があります。
- 配備名とエラー
- 配備のライフサイクル
- 配備ツール
- モジュールまたはアプリケーションベースでの配備
- WAR モジュールの配備
- EJB JAR モジュールの配備
- ライフサイクルモジュールの配備
- ACC クライアントの配備
- J2EE CA リソースアダプタの配備
- 共有フレームワークへのアクセス
配備名とエラー
アプリケーションまたはモジュールを配備すると、Sun ONE Application Server の配備記述子ファイルに一意の名前が生成されます。アプリケーションを再配備すると、この名前は変更されます。この名前を手作業で変更しないでください。配備時に、サーバーは名前の重複を検出し、一意の名前を持たないアプリケーションまたはモジュールをロードしません。この場合、サーバーログにメッセージが送信されます。詳細は、「ネーミングルール」を参照してください。
配備中にエラーが発生すると、アプリケーションまたはモジュールは配備されません。アプリケーション内のモジュールにエラーが含まれる場合、そのアプリケーション全体が配備されません。これは、部分的な配備によってサーバーの状態に整合性がなくなることを避けるためです。
配備のライフサイクル
アプリケーションははじめに配備されて、修正および再読み込み、再配備、無効化、再有効化され、最後に配備の取消しが行われてサーバーから削除されます。この節には、配備のライフサイクルに関連する次の項目があります。
動的配備
サーバーを再起動せずにアプリケーションまたはモジュールを配備、再配備、および配備の取消しをすることができます。これを動的配備と呼びます。
動的な配備は、主にサーバーを再起動せずに新しいアプリケーションおよびモジュールを運用環境でオンラインにするために使用されます。ただし、再配備を行うと、再配備中に実行されていたセッションが無効になります。クライアントはセッションを実行し直す必要があります。
注 asadmin deploy に --force オプションを指定するか、配備時に管理インタフェースの適切なチェックボックスにチェックマークをつけることで、以前に配備したアプリケーションを上書きすることができます。ただし、設定済みのリソースを更新するときは、事前にそのリソースを削除しておく必要があります。
アプリケーションを再配備すると、自動的に生成された名前が変更されます。
配備されたアプリケーションまたはモジュールの無効化
配備されたアプリケーションまたはモジュールをサーバーから削除しないで無効にすることができます。無効化したアプリケーションからクライアントにアクセスすることはできません。
アプリケーションまたはモジュールを無効化するには、次のいずれかの手順を実行します。
- server.xml ファイルで、アプリケーションまたはモジュールを enabled="false" に設定する。server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
- 管理インタフェースを使用する :
動的再読み込み
動的再読み込みを有効にすると、コードまたは配備記述子を変更したときにアプリケーションまたはモジュールを再配備する必要がありません。変更した JSP ファイルまたはクラスファイルをアプリケーションまたはモジュールの配備ディレクトリにコピーするだけで再配備が完了します。サーバーは、定期的に変更を確認して、アプリケーションを変更に合わせて自動的かつ動的に再配備します。
この機能は、変更したコードをすぐにテストできるため、開発環境で役に立ちます。動的な再読み込みは、パフォーマンスが低下することがあるので運用環境にはお勧めしません。また、再読み込みを行うと、再読み込み中に実行されていたセッションが無効になります。クライアントはセッションを実行し直す必要があります。
動的再読み込みを有効にするには、次のいずれかを行います。
- 管理インタフェースを使用する :
サーバーインスタンスの下にある「アプリケーション」コンポーネントを開きます。
「再読み込みを有効」ボックスをオンにして動的再読み込みを有効にします。
「再読込のポーリング間隔」フィールドに秒数を入力して、アプリケーションとモジュールにコードの変更がないか確認して動的に再読み込みする間隔を設定します。
サーバーインスタンスのページを表示し、「変更の適用」ボタンを選択します。
詳細については、『Sun ONE Application Server 管理者ガイド』を参照してください。
- server.xml ファイルの applications 要素の次の属性を編集します。
dynamic-reload-enabled="true" に設定して、動的再読み込みを有効にします。
dynamic-reload-poll-interval-in-seconds で、アプリケーションとモジュールにコードの変更がないか確認して動的に再読み込みする間隔を設定します。
server.xml の詳細については、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
さらに、新しいサーブレットファイルの読み込み、変更に関連する EJB の再読み込み、または配備記述子の変更の再読み込みを行うには、次の操作を行う必要があります。
- 配備されたアプリケーションのルートに .reload という名前の空のファイルを作成します。
instance_dir/applications/j2ee-apps/app_name/.reload
または個別に配備されたモジュールに作成します。
instance_dir/applications/j2ee-modules/module_name/.reload
- 上記の変更を行うたびに、.reload ファイルのタイムスタンプ (UNIX では touch.reload) を明示的に更新します。
JSP では、sun-web.xml ファイルの jsp-config 要素にある reload-interval プロパティで設定した頻度で、変更が自動的に再読み込みされます。JSP の動的再読み込みを無効にするには、reload-interval プロパティの値を -1 に設定します。
配備ツール
ここでは、モジュールとアプリケーションを配備するときに使用するツールについて説明します。次の配備ツールがあります。
Apache Ant
Ant は、モジュールとアプリケーションのアセンブルおよび配備に役立ちます。詳細については、「Apache Ant のアセンブリツールおよび配備ツール」を参照してください。
Sun ONE Studio
J2EE アプリケーションとモジュールの配備には Sun ONE Studio 4 を利用できます。Sun ONE Studio に関する詳細は、『Sun ONE Studio 4, Enterprise Edition のチュートリアル』を参照してください。
注 Sun ONE Studio では、モジュールまたはアプリケーションの配備を「実行」と呼びます。「実行」には、サーバーが稼動していることの確認、およびモジュールまたはアプリケーションをアクティブにする正しい URL の表示も含まれます。
asadmin コマンド
asadmin コマンドを使用すると、アプリケーションおよび個別に配備されたモジュールをローカルサーバー上に配備および配備の取消しができます。複数マシンまたは複数インスタンスへの同時配備はサポートされていません。この節では、asadmin コマンドについて簡単に解説します。詳細は、『Sun ONE Application Server 管理者ガイド』を参照してください。
ライフサイクルモジュールを配備する場合は、「ライフサイクルモジュールの配備」を参照してください。
asadmin deploy
asadmin deploy コマンドを使用すると、WAR、JAR、RAR、または EAR ファイルを配備できます。アプリケーションを配備するには、コマンドに --typeapplication を指定します。個別のモジュールを配備するには、--typeejb、web、connector、または client を指定します。構文は次のとおりです。オプションパラメータにデフォルト値がある場合は、その値を表示しています。
asadmin deploy --user admin_user [--password admin_password] [--passwordfile password_file] [--host localhost] [--port 4848] [--secure | -s] [--virtualservers virtual_servers] [--type application|ejb|web|connector] [--contextroot contextroot] [--force=true] [--precompilejsp=false] [--verify=false] [--name component_name] [--upload=true] [--retrieve local_dirpath] [--instance instance_name] filepath
たとえば、次のコマンドは、個別の EJB モジュールを配備します。
asadmin deploy --user jadams --password secret --host localhost --port 4848 --type ejb --instance server1 packagingEJB.jar
upload が false に設定されている場合、filepath はサーバーマシン上の絶対パスで指定します。
asadmin deploydir
asadmin deploydir コマンドを使用すると、オープンディレクトリ構造内のアプリケーションまたはモジュールを配備できます。ディレクトリ構造は、「ディレクトリ構造」に指定されているとおりにする必要があります。dirpath の場所が instance_dir/applications/j2ee-apps の下または instance_dir/applications/j2ee-modules の下のどちらにあるかによって、それがアプリケーションか個別に配備されたモジュールかが決まります。構文は次のとおりです。オプションパラメータにデフォルト値がある場合は、その値を表示しています。
asadmin deploydir --user admin_user [--password admin_password] [--passwordfile password_file] [--host localhost] [--port 4848] [--secure | -s] [--virtualservers virtual_servers] [--type application|ejb|web|connector] [--contextroot contextroot] [--force=true] [--precompilejsp=false] [--verify=false] [--name component_name] [--instance instance_name] dirpath
たとえば、次のコマンドは、個別の EJB モジュールを配備します。
asadmin deploydir --user jadams --password secret --host localhost --port 4848 --type ejb --instance server1 packagingEJB
upload が false に設定されている場合、filepath はサーバーマシン上の絶対パスで指定します。
注 Windows 環境でマッピングされたドライブにディレクトリを配備するときは、マッピングされたドライブが割り当てられているユーザーとして Sun ONE Application Server を実行する必要があります。それ以外のユーザーとして実行していると、Sun ONE Application Server はそのディレクトリを認識できません。
asadmin undeploy
asadmin undeploy コマンドを使用すると、アプリケーションまたはモジュールの配備取消しができます。アプリケーションの配備を取消すには、コマンド内に --typeapp を指定します。個別のモジュールの配備を取消すには、--typeejb、web、connector、または client を指定します。構文は次のとおりです。オプションパラメータにデフォルト値がある場合は、その値を表示しています。
asadmin undeploy --user admin_user [--password admin_password] [--passwordfile password_file] [--host localhost] [--port 4848] [--secure | -s] [--type application|ejb|web|connector] [--instance instance_name] component_name
たとえば、次のコマンドは、個別の EJB モジュールの配備を取消します。
asadmin undeploy --user jadams --password secret --host localhost --port 4848 --type ejb --instance server1 packagingEJB
管理インタフェース
管理インタフェースを使用すると、モジュールとアプリケーションをローカルおよびリモートの Sun ONE Application Server サイトに配備できます。このツールを使うには、次の手順で行います。
- サーバーインスタンスの下にある「アプリケーション」コンポーネントを開きます。
- 「エンタープライズアプリケーション」、「Web アプリケーション」、「コネクタモジュール」、「EJB モジュール」のいずれかのページに移動します。
- 「配備」ボタンをクリックします。このページでは、アプリケーションまたはモジュールの配備取消しと無効化も実行できます。
- モジュールまたはアプリケーションのディレクトリまたはアーカイブファイルの完全パスを入力し (または「ブラウズ」をクリックして指定)、「了解」ボタンをクリックします。
- モジュールまたはアプリケーションの名前を入力します。
- Web モジュールでは、コンテキストルートを入力します。
- 仮想サーバー名の隣のボックスにチェックマークをつけて、1 つまたは複数の仮想サーバーにアプリケーションまたは Web モジュールを割り当てます。
- モジュールまたはアプリケーションがすでに配備されていれば、適切なボックスをチェックして、それを再配備することもできます (これを強制配備と呼びます)。これはオプションです。
- ベリファイアを実行して配備記述子ファイルを検証します。これはオプションです。ベリファイアの詳細は、「配備記述子ベリファイア」を参照してください。
- モジュールのタイプによっては、その他のフィールドが表示されます。適切なボックスをチェックし、適切な値を入力してください。必須フィールドはアスタリスク (*) で示されます。
- 「了解」ボタンをクリックします。
ライフサイクルモジュールを配備する場合は、「ライフサイクルモジュールの配備」を参照してください。
モジュールまたはアプリケーションベースでの配備
アプリケーションまたはアプリケーションから独立した個別のモジュールを配備することができます。アプリケーションベースまたは個別のモジュールベースで配備したときの実行時環境およびファイルシステムについては、「実行時環境」を参照してください。
次のものがコンポーネントにアクセスする場合は、個別のモジュールベースで配備することをお勧めします。
- ほかのモジュール
- J2EE アプリケーション
- ACC クライアント (モジュールベースで配備すると、ACC クライアント、サーブレット、または EJB コンポーネントから Bean に共有アクセスできる)
複数のモジュールを 1 つの EAR ファイルに結合すると、1 つのモジュールとして配備できるようになります。これは、EAR のモジュールを個別に配備するのと似ています。
WAR モジュールの配備
「配備ツール」で説明されているとおりに、WAR モジュールを配備します。
配備時に管理インタフェースの適切なチェックボックスにチェックマークをつけるか、asadmin deploy コマンドまたは asadmin deploydir コマンドに --precompilejsp オプションを指定して、JSP を事前コンパイルすることができます。Ant タスク sun-appserv-deploy および sun-appserv-jspc を使って JSP を事前コンパイルすることもできます。
JSP 用の生成されたソースは、-keepgenerated フラグを sun-web.xml 内の jsp-config 要素に追加することによって保持できます。WAR モジュールを配備するときにこのプロパティを追加すると、生成されたソースが保存されます。保存先は、アプリケーションの場合は instance_dir/generated/jsp/j2ee-apps/app_name/module_name、個別に配備された Web モジュールの場合は instance_dir/generated/jsp/j2ee-modules/module_name です。
JSP の事前コンパイルと -keepgenerated プロパティの詳細については、『Sun ONE Application Server Web アプリケーション開発者ガイド』を参照してください。
EJB JAR モジュールの配備
「配備ツール」で説明されているとおりに、EJB JAR モジュールを配備します。
スタブとタイ用の生成されたソースは、-keepgenerated フラグを server.xml 内の java-config 要素の rmic-options 属性に追加することによって保持できます。EJB JAR モジュールを配備するときにこのフラグを追加すると、生成されたソースが保存されます。保存先は、アプリケーションの場合は instance_dir/generated/ejb/j2ee-apps/app_name/module_name、個別に配備された EJB JAR モジュールの場合は instance_dir/generated/ejb/j2ee-modules/module_name です。-keepgenerated フラグの詳細は、『Sun ONE Application Server 管理者用設定ファイルリファレンス』を参照してください。
ライフサイクルモジュールの配備
ライフサイクルモジュールの全般的な情報については、「ライフサイクルリスナーの開発」を参照してください。
ライフサイクルモジュールを配備するには、次のツールを使います。
asadmin コマンド
ライフサイクルモジュールを配備するには、asadmin create-lifecycle-module コマンドを使います。構文は次のとおりです。オプションパラメータにデフォルト値がある場合は、その値を表示しています。
asadmin create-lifecycle-module --user admin_user [--password admin_password] [--passwordfile password_file] [--host localhost] [--port 4848] [--secure | -s] [--instance instance_name] --classname classname [--classpath classpath] [--loadorder load_order_number] [--failurefatal=false] [--enabled=true] [--description text_description] [--property (name=value)[:name=value]*] modulename
次に例を示します。
asadmin create-lifecycle-module --user jadams --password secret --host localhost --port 4848 --instance server1 --classname RMIServer MyRMIServer
ライフサイクルモジュールの配備を取消すには、asadmin delete-lifecycle-module コマンドを使います。構文は次のとおりです。オプションパラメータにデフォルト値がある場合は、その値を表示しています。
asadmin delete-lifecycle-module --user admin_user [--password admin_password] [--passwordfile password_file] [--host localhost] [--port 4848] [--secure | -s] [--instance instance_name] module_name
次に例を示します。
asadmin delete-lifecycle-module --user jadams --password secret --host localhost --port 4848 --instance server1 MyRMIServer
サーバーインスタンス上に配備されたライフサイクルモジュールをリスト表示するときは、asadmin list-lifecycle-modules コマンドを使います。構文は次のとおりです。オプションパラメータにデフォルト値がある場合は、その値を表示しています。
asadmin list-lifecycle-modules --user admin_user [--password admin_password] [--passwordfile password_file] [--host localhost] [--port 4848] instance_name
次に例を示します。
asadmin list-lifecycle-module --user jadams --password secret --host localhost --port 4848 server1
管理インタフェース
管理インタフェースを使ってライフサイクルモジュールを配備することもできます。次の手順に従います。
- サーバーインスタンスの下にある「アプリケーション」コンポーネントを開きます。
- 「ライフサイクルモジュール」ページに移動します。
- 「配備」ボタンをクリックします。
- 次の情報を入力します。
「クラス名」 (必須) - ライフサイクルモジュールのクラスファイルの完全修飾された名前
「クラスパス」 (省略可能) - ライフサイクルモジュールのクラスパス。モジュールの場所を指定する。デフォルトの場所は、アプリケーションのルートディレクトリの下
「読み込み順序」(省略可能) - 起動時にライフサイクルモジュールが読み込まれる順序を決定する。モジュールに指定された数値が小さいほど、早く読み込まれる。値の範囲は、101 からオペレーティングシステムの MAXINT まで。1 〜 100 までの値は予約されている
「致命的な障害」 (省略可能) - ライフサイクルモジュールが失敗した場合にサーバーをシャットダウンするかどうかを決定する。デフォルトは false
「ライフサイクルを有効」 (省略可能) - ライフサイクルモジュールを有効にするかどうかを決定する。デフォルトは true
- 「了解」ボタンをクリックします。
ACC クライアントの配備
クライアントがEJB コンポーネントとデータをやり取りする場合にだけ配備が必要です。ACC クライアントを配備するには、次の手順に従います。
- 必要なクライアントファイルをアセンブルします (「ACC クライアントのアセンブル」を参照)。
- クライアントがアクセスする EJB コンポーネントをアセンブルします。
- クライアントと EJB コンポーネントをアプリケーションにパッケージ化します。
- アプリケーションを配備します。
- 配備が完了すると、クライアント JAR ファイルは次の場所に作成されます。
instance_dir/applications/j2ee-apps/app_name/app_nameClient.jar
クライアント JAR には、ACC クライアント用のタイおよび必要なクラスが含まれています。このファイルをクライアントマシンにコピーし、クライアント上の APPCPATH 環境変数がこの JAR を示すように設定します。
Sun ONE Application Server マシンでクライアントを実行テストするときは、install_dir/bin ディレクトリにある appclient スクリプトを使用できます。デフォルトのサーバーインスタンスを使っている場合に必要なオプションは、-client だけです。次に例を示します。
appclient -client converterClient.jar
デフォルトインスタンスを使っていない場合は、sun-acc.xml ファイルの場所を指定する -xml パラメータも指定する必要があります。
別のマシンで ACC クライアントを実行するには、事前にクライアントマシンを準備する必要があります。
- install_dir/bin ディレクトリにある package-appclient スクリプトを使って ACC パッケージ JAR ファイルを作成します。JAR ファイルは install_dir/lib/appclient ディレクトリに作成されます。
- ACC パッケージ JAR ファイルをクライアントマシンにコピーし、unjar を実行してファイルを展開するこれにより、appclient ディレクトリの下にディレクトリ構造が作成されます。
- appclient/appserv/lib/appclient ディレクトリにある sun-acc.xml ファイルを設定します。
- appclient/appserv/bin ディレクトリにある asenv.conf ファイル (Windows 環境では asenv.bat ファイル) を設定します。
- クライアント JAR ファイルをクライアントマシンにコピーする
これで、クライアントを実行する準備ができました。詳細は、『Sun ONE Application Server Developer's Guide to Clients』を参照してください。
J2EE CA リソースアダプタの配備
「配備ツール」で説明されているとおりに、コネクタモジュールを配備します。
共有フレームワークへのアクセス
J2EE のアプリケーションとモジュールで共有フレームワーククラス (ユーティリティクラス、ライブラリなど) を使用する場合、それらのクラスはアプリケーションやモジュールではなくシステムクラスローダーまたは共有クラスローダーのパスに配備できます。サイズが大きい共有ライブラリを、そのライブラリを使用するすべてのモジュールにアセンブルする場合、サーバーへの登録に多くの時間がかかります。また、同一クラスの複数のインスタンスが独自のクラスローダを使用すると、リソースの浪費になります。
詳細は、「クラスローダー分離の回避」を参照してください。
Apache Ant のアセンブリツールおよび配備ツール
Ant の自動アセンブリ機能を使用することができます。Ant は、次の Apache Software Foundation のサイトから入手できる Java ベースのビルドツールです。
http://jakarta.apache.org/ant/
Ant は、Java クラスを使って拡張した Java ベースのビルドツールです。シェルコマンドを使う代わりに、XML ドキュメントを使ってアセンブリ手順を宣言します。各タスクは、特定のタスクインタフェースを実装したオブジェクトによって実行されます。
Sun ONE Application Server (Solaris 9 にバンドルされている場合もバンドルされていない場合も) には Apache Ant 1.4.1 が付属しています。Sun ONE Application Server に付属するサンプルアプリケーションには、Ant の build.xml ファイルが用意されています。詳しくは、「サンプルアプリケーション」を参照してください。
Ant を使用する前に、次の操作を実行してください。
- PATH 環境変数に install_dir/bin を含める (Solaris 9 のバンドル製品では /usr/sfw/bin)。Sun ONE Application Server に付属する Ant スクリプト asant は、このディレクトリにある。asant の詳細な使用方法は、install_dir/samples/docs/ant.html ファイル内のサンプルアプリケーションマニュアルを参照
- exec タスクや cvs タスクのようなプラットフォームに固有のアプリケーションを実行している場合は、ANT_HOME 環境変数を Ant のインストールディレクトリに設定する必要がある
この節には Ant に関連する次の項目があります。
標準の Ant タスクに関する詳細は、Ant のマニュアルを参照してください。
http://jakarta.apache.org/ant/manual/index.html
Sun ONE Application Server 7 の Ant タスク
Sun ONE Application Server の Ant タスクを使って、モジュールとアプリケーションをアセンブル、配備、および配備を取消したり、サーバーインスタンスを構成したりすることができます。タスクには、次のものがあります。
- sun-appserv-deploy
- sun-appserv-undeploy
- sun-appserv-instance
- sun-appserv-component
- sun-appserv-admin
- sun-appserv-jspc
sun-appserv-deploy
次のいずれかをローカルまたはリモートの Sun ONE Application Server インスタンスに配備します。
- エンタープライズアプリケーション (EAR ファイル)
- Web アプリケーション (WAR ファイル)
- Enterprise Java Beans (EJB-JAR ファイル)
- エンタープライズコネクタ (RAR ファイル)
- アプリケーションクライアント
サブ要素
次の表は、sun-appserv-deploy タスクのサブ要素について説明しています。これは、タスクの実行対象となるオブジェクトです。左側の列にはサブ要素名、右側の列には要素の説明を示しています。
sun-appserv-deploy のサブ要素
要素
説明
Sun ONE Application Server インスタンス。
配備するコンポーネント
指定したパラメータと一致するコンポーネントファイルのセット
属性
次の表は、sun-appserv-deploy タスクの属性を説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
例
多くの属性が指定されていない簡単なアプリケーション配備スクリプトを示します。
<sun-appserv-deploy
file="${assemble}/simpleapp.ear"
password="${password}" />属性がすべて指定された同等のスクリプトを示します。
<sun-appserv-deploy
file="${assemble}/simpleapp.ear"
name="simpleapp"
type="application"
force="true"
precompilejsp="false"
verify="false"
upload="true"
user="admin"
password="${password}"
host="localhost"
port="4848"
instance="${default-instance-name}"
sunonehome="${sunone.home}" />次の例では、リモートサーバーで実行している 1 つの Sun ONE Application Server インスタンスに複数のコンポーネントを配備します。
<sun-appserv-deploy password="${password}" host="greg.sun.com"
sunonehome="/opt/sunone" >
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"
contextroot="test"/>
<component file="${assemble}/simplebean.jar"/>
</sun-appserv-deploy>次の例では、リモートサーバーで実行している 2 つの Sun ONE Application Server インスタンスに複数のコンポーネントを配備します。この例では、どちらのサーバーも同じ admin パスワードを使っています。同じパスワードを使わない場合は、各パスワードをサーバー要素に指定することができます。
<sun-appserv-deploy password="${password}" sunonehome="/opt/sunone" >
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"
contextroot="test"/>
<component file="${assemble}/simplebean.jar"/>
</sun-appserv-deploy>次の例では、3 つのコンポーネントが fileset 条件と一致します。前の例と同じコンポーネントを配備しますが、コンポーネント固有の属性をいくつか設定できないことに注意してください。コンポーネント固有のすべての属性 (name、type、および contextroot) はデフォルト値を使います。
<sun-appserv-deploy password="${password}" host="greg.sun.com"
sunonehome="/opt/sunone" >
<fileset dir="${assemble}" includes="**/*.?ar" />
</sun-appserv-deploy>sun-appserv-undeploy
次のいずれかをローカルまたはリモートの Sun ONE Application Server インスタンスから配備を取消します。
- エンタープライズアプリケーション (EAR ファイル)
- Web アプリケーション (WAR ファイル)
- Enterprise Java Beans (EJB-JAR ファイル)
- エンタープライズコネクタ (RAR ファイル)
- アプリケーションクライアント
サブ要素
次の表は、sun-appserv-undeploy タスクのサブ要素について説明しています。これは、タスクの実行対象となるオブジェクトです。左側の列にはサブ要素名、右側の列には要素の説明を示しています。
sun-appserv-undeploy のサブ要素
要素
説明
Sun ONE Application Server インスタンス。
配備するコンポーネント
指定したパラメータと一致するコンポーネントファイルのセット
属性
次の表は、sun-appserv-undeploy タスクの属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
例
多くの属性が指定されていない簡単なアプリケーションの配備を取消すスクリプトを示します。
<sun-appserv-undeploy name="simpleapp" password="${password}" />
属性がすべて指定された同等のスクリプトを示します。
<sun-appserv-undeploy
name="simpleapp"
type="application"
user="admin"
password="${password}"
host="localhost"
port="4848"
instance="${default-instance-name}"
sunonehome="${sunone.home}" />次の例は、アーカイブファイル (この場合は EAR および WAR) を使用した配備の取消し、コンポーネントの名前とタイプ (この例では EJB コンポーネントの配備の取消し) の使用、および複数のコンポーネントの配備の取消しを示しています。
<sun-appserv-undeploy password="${password}">
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-undeploy>配備プロセスと同様に、1 つのコマンドで複数のサーバーからコンポーネントの配備を取消すことができます。次の例では、Sun ONE Application Server 7 の 2 つの異なるインスタンスから 3 つの同じコンポーネントが削除されています。この例では、どちらのインスタンスも同じパスワードを使っています。
<sun-appserv-undeploy password="${password}">
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-undeploy>sun-appserv-instance
1 つまたは複数のアプリケーションサーバーインスタンスの起動、停止、再起動、作成、または削除を行います。
サブ要素
次の表は、sun-appserv-instance タスクのサブ要素について説明しています。これは、タスクの実行対象となるオブジェクトです。左側の列にはサブ要素名、右側の列には要素の説明を示しています。
sun-appserv-instance のサブ要素
要素
説明
Sun ONE Application Server インスタンス。
属性
次の表は、sun-appserv-instance タスクの属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
例
次の例では、local Sun ONE Application Server 7 インスタンスを起動します。
<sun-appserv-instance action="start" password="${password}"
instance="${default-instance-name}"/>属性がすべて指定された同等のスクリプトを示します。
<sun-appserv-instance
action="start"
user="admin"
password="${password}"
host="localhost"
port="4848"
instance="${default-instance-name}"
sunonehome="${sunone.home}" />単一のコマンドで複数のサーバーを制御することができます。次の例では、2 つのサーバーを再起動します。この場合、サーバーはそれぞれ別のパスワードを使用します。
<sun-appserv-instance action="restart"
instance="${default-instance-name}"/>
<server host="greg.sun.com" password="${password.greg}"/>
<server host="joe.sun.com" password="${password.joe}"/>
</sun-appserv-instance>次の例では、Sun ONE Application Server 7 の新しいインスタンスを作成します。
<sun-appserv-instance
action="create" instanceport="8080"
password="${password}"
instance="development" />属性がすべて指定された同等のスクリプトを示します。
<sun-appserv-instance
action="create"
instanceport="8080"
user="admin"
password="${password}"
host="localhost"
port="4848"
instance="development"
sunonehome="${sunone.home}" />単一のコマンドで複数のサーバー上にインスタンスを作成できます。次の例では、2 つの異なるサーバー上に qa という名前の新しいインスタンスを作成しています。この場合は、両方のサーバーが同じパスワードを使用しています。
<sun-appserv-instance
action="create"
instanceport="8080"
instance="qa"
password="${password}>
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
</sun-appserv-instance>次のように、各サーバーからこれらのインスタンスを削除することもできます。
<sun-appserv-instance
action="delete"
instance="qa"
password="${password}>
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
</sun-appserv-instance>次のように、server サブ要素の属性を使って異なるインスタンス名およびインスタンスポートを指定することもできます。
<sun-appserv-instance action="create" password="${password}>
<server host="greg.sun.com" instanceport="8080" instance="qa"/>
<server host="joe.sun.com" instanceport="9090"
instance="integration-test"/>
</sun-appserv-instance>sun-appserv-component
Sun ONE Application Server 7 に配備されている 次の J2EE コンポーネントタイプを有効または無効にします。
- エンタープライズアプリケーション (EAR ファイル)
- Web アプリケーション (WAR ファイル)
- Enterprise Java Beans (EJB-JAR ファイル)
- エンタープライズコネクタ (RAR ファイル)
- アプリケーションクライアント
コンポーネントを有効または無効にするのにアーカイブを指定する必要はありません。必要となるのはコンポーネント名だけです。ただし、コンポーネントアーカイブは、コンポーネント名を示しているため、使用することもできます。
サブ要素
次の表は、sun-appserv-component タスクのサブ要素について説明しています。これは、タスクの実行対象となるオブジェクトです。左側の列にはサブ要素名、右側の列には要素の説明を示しています。
sun-appserv-component のサブ要素
要素
説明
Sun ONE Application Server インスタンス。
配備するコンポーネント
指定したパラメータと一致するコンポーネントファイルのセット
属性
次の表は、sun-appserv-component タスクの属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
例
コンポーネントを無効にする簡単な例を示します。
<sun-appserv-component
action="disable"
name="simpleapp"
password="${password}" />コンポーネントを有効にする簡単な例を示します。
<sun-appserv-component
action="enable"
name="simpleapp"
password="${password}" />属性がすべて指定された同等のスクリプトを示します。
<sun-appserv-component
action="enable"
name="simpleapp"
type="application"
user="admin"
password="${password}"
host="localhost"
port="4848"
instance="${default-instance-name}"
sunonehome="${sunone.home}" />次の例は、アーカイブファイル (この例では EAR および WAR) またはコンポーネント名およびタイプ (この例では、EJB コンポーネント) を使って複数のコンポーネントを無効にする方法を示しています。
<sun-appserv-component action="disable" password="${password}">
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-component>複数のサーバー上にあるコンポーネントを、単一のタスクで有効または無効にすることができます。次の例は、Sun ONE Application Server 7 の 2 つの異なるインスタンス上で 3 つの同じコンポーネントを有効にする方法を示しています。この例では、両インスタンスのパスワードは同じです。
<sun-appserv-component action="enable" password="${password}">
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-component>sun-appserv-admin
Sun ONE Application Server 7 上で実行される任意の管理コマンドおよびスクリプトを有効にします。これは、特定の Ant タスクが開発されていないか、または関連コマンド一式が単一のスクリプト内にある場合に有効です。
サブ要素
次の表は、sun-appserv-admin タスクのサブ要素について説明しています。これは、タスクの実行対象となるオブジェクトです。左側の列にはサブ要素名、右側の列には要素の説明を示しています。
sun-appserv-admin のサブ要素
要素
説明
Sun ONE Application Server インスタンス。
属性
次の表は、sun-appserv-admin タスクの属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
sun-appserv-jspc
Sun ONE Application Server による初回の呼び出し用に、JSP ソースコードを Sun ONE Application Server 互換の Java コードに事前コンパイルします。このタスクを使うことで、JSP ページへのアクセスや、JSP ソースコードの構文チェックを迅速に行えます。生成される Java コードを javac タスクに送り、JSP のクラスファイルを生成することもできます。
サブ要素
なし
属性
次の表は、sun-appserv-jspc タスクの属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
例
次の例では、webapp 属性を使って JSP ファイルから Java ソースファイルを生成します。sun-appserv-jspc タスクが終了すると、生成された Java ファイルをクラスファイルにコンパイルする javac タスクが直ちに実行されます。javac タスクの classpath の値は、空白文字を挿入せずにすべてを 1 行で記述する必要があります。
<sun-appserv-jspc
destdir="${assemble.war}/generated"
webapp="${assemble.war}"
classpath="${assemble.war}/WEB-INF/classes"
sunonehome="${sunone.home}" />
<javac
srcdir="${assemble.war}/WEB-INF/generated"
destdir="${assemble.war}/WEB-INF/generated"
debug="on"
classpath="${assemble.war}/WEB-INF/classes:${sunone.home}/lib/appse rv-rt.jar:${sunone.home}/lib/appserv-ext.jar">
<include name="**/*.java"/>
</javac>再利用可能なサブ要素
Sun ONE Application Server 7 の Ant タスクの再利用可能なサブ要素は次のとおりです。これは、タスクの実行対象となるオブジェクトです。
server
Sun ONE Application Server インスタンスを指定します。1 つのタスクが複数のサーバーインスタンスで動作できます。server 属性は、親タスクの対応属性をオーバーライドするため、親タスクの属性にはデフォルト値が適用されます。
サブ要素
なし
属性
次の表は、server 要素の属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
server の属性
属性
デフォルト値
説明
user
admin
(省略可能) アプリケーションサーバーの管理インスタンスにログインするときに使用するユーザー名
password
なし
(親タスクで指定されている場合は省略可能) アプリケーションサーバーの管理インスタンスにログインするときに使用するパスワード
host
localhost
(省略可能) ターゲットサーバー。リモートサーバーをターゲット指定するときは、完全修飾されたホスト名を使う
port
4848
(省略可能) ターゲットサーバーの管理ポート
instance
デフォルトインスタンスの名前
(省略可能) ターゲットアプリケーションサーバーインスタンス
domain
(local="true" と設定し、複数のローカルドメインが存在する場合を除いて sun-appserv-instance にだけ適用される) ローカルな action のターゲットドメイン。local="false" の場合は、この属性は無視される
instanceport
なし
(action が create である場合を除いて sun-appserv-instance に適用される) 新しいインスタンスが作成される場合にポート番号を指定する。それ以外の場合、この属性は無視される。
debug
false
(省略可能。sun-appserv-instance だけに適用される) action に start を設定すると、サーバーがデバッグモードで起動するかどうかを指定できる。action にその他の値を指定した場合は、この属性は無視される。true の場合、そのインスタンスのライフタイムを通じて追加のデバッグ出力が生成される。
local
false
(省略可能。sun-appserv-instance だけに適用される) true の場合、action のターゲットはローカルマシン上のインスタンス (localhost) となるため、管理サーバーが稼動している必要はなく、host、port、user、および password 属性は無視される。false の場合は管理サーバーが稼動している必要があり、host、port、user、および password 属性にも適切な値を設定する必要がある
upload
true
(省略可能。sun-appserv-deploy だけに適用される) true の場合、コンポーネントが配備先のサーバーに転送される。コンポーネントをローカルマシンに配備する場合、upload を false に設定すると、配備にかかる時間を短縮できる
virtualservers
デフォルトの仮想サーバーのみ
(省略可能。sun-appserv-deploy だけに適用される) 配備の対象となる仮想サーバーをコンマで区切ったリスト。アプリケーションコンポーネント (.ear) または Web コンポーネント (.war) だけに適用され、その他のコンポーネントタイプでは無視される
例
1 つのタスクで複数のサーバーを制御できます。この例では、異なるパスワードを使って 2 つのサーバーを起動します。一方のサーバーだけをデバッグモードで起動します。
<sun-appserv-instance action="start">
<server host="greg.sun.com" password="${password.greg}"/>
<server host="joe.sun.com" password="${password.joe}"
debug="true"/>
</sun-appserv-instance>1 つのタスクで複数のサーバーにインスタンスを作成できます。次の例では、2 つの異なるサーバー上に qa という名前の新しいインスタンスを作成しています。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-instance action="create" instanceport="8080"
instance="qa" password="${password}>
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
</sun-appserv-instance>次のように、各サーバーからこれらのインスタンスを削除することもできます。
<sun-appserv-instance action="delete" instance="qa"
password="${password}>
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
</sun-appserv-instance>入れ子の server 要素の属性を使って、別のインスタンス名とポート番号を指定することもできます。
<sun-appserv-instance action="create" password="${password}>
<server host="greg.sun.com" instanceport="8080" instance="qa"/>
<server host="joe.sun.com" instanceport="9090"
instance="integration-test"/>
</sun-appserv-instance>複数のサーバーに複数のコンポーネントを配備できます (入れ子の component 要素を参照)。次の例では、リモートサーバーで実行している 2 つの Sun ONE Application Server インスタンスにコンポーネントを 1 つずつ配備します。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-deploy password="${password}" sunonehome="/opt/s1as7" >
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"
contextroot="test"/>
<component file="${assemble}/simplebean.jar"/>
</sun-appserv-deploy>複数のサーバーの複数のコンポーネントの配備を取消すこともできます。次の例では、2 つの異なるインスタンスから 3 つの同じコンポーネントを削除します。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-undeploy password="${password}">
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-undeploy>複数のサーバーにあるコンポーネントを有効化または無効化することができます。次の例では、2 つの異なるインスタンスで 3 つの同じコンポーネントを有効化します。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-component action="enable" password="${password}">
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-component>component
J2EE コンポーネントを指定します。1 つのタスクが複数のコンポーネントで動作するようになります。component 属性は、親タスクの対応属性をオーバーライドするため、親タスクの属性にはデフォルト値が適用されます。
サブ要素
なし
属性
次の表は、component 要素の属性について説明しています。左側の列には属性名、中央の列にはデフォルト値、右側の列には属性の説明を示しています。
component の属性
属性
デフォルト値
説明
file
なし
(親タスクが sun-appserv-undeploy または sun-appserv-component の場合は省略可能) ターゲットコンポーネント。この属性がファイルを参照する場合、そのファイルは有効なアーカイブである必要がある。この属性がディレクトリを参照する場合、そのディレクトリはすべてのコンポーネントが展開された有効なアーカイブを含んでいる必要がある。upload を false に設定するときは、サーバーマシンの絶対パスを指定する必要がある
name
拡張子を含まないファイル名
(省略可能) コンポーネントの表示名。
type
ファイル名またはディレクトリ名の拡張子で決定される
(省略可能) コンポーネントのタイプ。有効なタイプは、application、ejb、web、connector。指定しない場合、コンポーネントタイプの決定にはファイル (またはディレクトリ) の拡張子が適用される。application は .ear、ejb は .jar、web は .war、connector は .rar がそれぞれ該当する。ファイル拡張子でコンポーネントを決定できない場合、デフォルト値は application となる
force
true
(省略可能。sun-appserv-deploy だけに適用される) true の場合、コンポーネントがすでにサーバー上にあるときは上書きされる。コンポーネントが存在する状態で false に設定すると、含んでいる要素の処理は失敗する
precompilejsp
false
(省略可能。sun-appserv-deploy だけに適用される) true の場合、エンタープライズアプリケーション (.ear) または Web アプリケーション (.war) に含まれるすべての JSP が事前コンパイルされる。その他のコンポーネントタイプでは、この属性は無視される
retrievestubs
クライアントスタブは保存されない
(省略可能。sun-appserv-deploy だけに適用される) クライアントスタブを保存するディレクトリ
contextroot
拡張子を含まないファイル名
(省略可能。sun-appserv-deploy だけに適用される) Web モジュール (WAR ファイル) のコンテキストルート。コンポーネントが WAR ファイルでない場合、この属性は無視される
verify
false
(省略可能。sun-appserv-deploy だけに適用される) true の場合、すべての配備記述子の構文とセマンティックの正確さが自動的に検証される。
例
1 つのタスクで複数のコンポーネントを配備できます。次の例では、リモートサーバーで実行している 1 つの Sun ONE Application Server インスタンスに各コンポーネントを配備します。
<sun-appserv-deploy password="${password}" host="greg.sun.com"
sunonehome="/opt/s1as7" >
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"
contextroot="test"/>
<component file="${assemble}/simplebean.jar"/>
</sun-appserv-deploy>1 つのタスクで複数のコンポーネントの配備を取消すこともできます。次の例では、アーカイブファイル (この例では EAR と WAR) および EJB コンポーネントの名前とタイプを使っています。
<sun-appserv-undeploy password="${password}">
<component file="${assemble}/simpleapp.ear"/
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-undeploy>複数のサーバーに複数のコンポーネントを配備できます。次の例では、リモートサーバーで稼動している 2 つのインスタンスにコンポーネントを 1 つずつ配備します。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-deploy password="${password}" sunonehome="/opt/s1as7" >
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"
contextroot="test"/>
<component file="${assemble}/simplebean.jar"/>
</sun-appserv-deploy>複数のサーバーの複数のコンポーネントの配備を取消すこともできます。次の例では、2 つの異なるインスタンスから 3 つの同じコンポーネントを削除します。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-undeploy password="${password}">
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-undeploy>複数のコンポーネントを有効化または無効化することができます。次の例では、アーカイブファイル (この例では EAR と WAR) および EJB コンポーネントの名前とタイプを使って複数のコンポーネントを無効化しています。
<sun-appserv-component action="disable" password="${password}">
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-component>複数のサーバーにある複数のコンポーネントを有効化または無効化することもできます。次の例では、2 つの異なるインスタンスで 3 つの同じコンポーネントを有効化します。どちらのサーバーでも同じパスワードを使用します。
<sun-appserv-component action="enable" password="${password}">
<server host="greg.sun.com"/>
<server host="joe.sun.com"/>
<component file="${assemble}/simpleapp.ear"/>
<component file="${assemble}/simpleservlet.war"/>
<component name="simplebean" type="ejb"/>
</sun-appserv-component>fileset
指定したパラメータと一致するコンポーネントファイルを選択します。fileset がサブ要素として含まれている場合、fileset の各ファイルに対して、含んでいる要素の name および contextroot 属性にデフォルト値を使う必要があります。詳細は、次のサイトを参照してください。
http://jakarta.apache.org/ant/manual/CoreTypes/fileset.html
アプリケーション配備記述子ファイル
Sun ONE Application Server アプリケーションには、次の 2 種類の配備記述子ファイルがあります。
- 『Java Servlet Specification, v2.3』の第 13 章「Deployment Descriptors」で説明している J2EE 標準ファイル (application.xml)
- この節で説明しているオプションの Sun ONE Application Server 固有のファイル (sun-application.xml)
この節には次の項目があります。
sun-application_1_3-0.dtd ファイル
sun-application_1_3-0.dtd ファイルでは、sun-application.xml ファイルの構造、および記述できる要素とそのサブ要素および属性が定義されています。sun-application_1_3-0.dtd ファイルは、install_dir/lib/dtds ディレクトリにあります。
注 sun-application_1_3-0.dtd ファイルを編集しないでください。このファイルの内容は、Sun ONE Application Server の新しいバージョンだけで変更されます。
DTD ファイルおよび XML の全般的な情報については、次のサイトにある XML 仕様を参照してください。
DTD ファイルに定義された各要素 (対応する XML ファイル内に置かれている場合もある) には、次の要素が含まれています。
サブ要素
要素にはサブ要素を含めることができます。たとえば、次のコードは、sun-application の要素を定義しています。
<!ELEMENT sun-application (web*, pass-by-reference?, unique-id?, security-role-mapping*)>
この ELEMENT タグは、sun-application 要素に web、pass-by-reference、unique-id、および security-role-mapping 要素を含めることができることを示しています。
次の表に、サブ要素のサフィックス文字 (省略可能) によって決まる必要指定数、つまり指定可能なサブ要素の数を示します。左の列にサブ要素の末尾文字、右の列に対応する必要指定数を示します。
必要指定数とサブ要素のサフィックス
サブ要素のサフィックス
必要指定数
element*
このサブ要素を含まないか、1 個以上含めることができる
element?
このサブ要素を含まないか、1 個含めることができる
element+
このサブ要素を 1 個以上含まなければならない
element (サフィックスなし)
このサブ要素を 1 個だけ含まなければならない
要素にほかの要素を含めることができない場合は、カッコで囲まれた要素名のリストの代わりに、EMPTY または (#PCDATA) が表示されます。
データ
要素の中には、サブ要素の代わりに文字データを含むものもあります。これらの要素は、次の形式で定義されます。
<!ELEMENT element-name (#PCDATA)>
次に例を示します。
<!ELEMENT role-name (#PCDATA)>
sun-application.xml ファイル内では、データ要素内の空白スペースはデータの一部として扱われます。そのため、データ要素で区切られたデータの前後には余分な空白がないようにする必要があります。次に例を示します。
<role-name>manager</role-name>
属性
ATTLIST タグを持つ要素には属性が含まれています。sun-application.xml ファイル内の要素には、属性は含まれていません。
sun-application.xml ファイル内の要素
この節では、sun-application.xml ファイルの次の要素について説明します。
- sun-application
- web
- web-uri
- context-root
- pass-by-reference
- unique-id
- security-role-mapping
- role-name
- principal-name
- group-name
sun-application
アプリケーション用の Sun ONE Application Server 固有の設定を定義します。これはルート要素であり、sun-application.xml ファイル内には sun-application 要素が 1 つだけ存在します。
サブ要素
次の表では、sun-application 要素のサブ要素について説明しています。左の列にサブ要素名、中央の列に必要指定数、右の列に要素の説明を示します。
web
アプリケーションの Web 層の設定を指定します。
サブ要素
次の表では、Web 要素のサブ要素について説明しています。左の列にサブ要素名、中央の列に必要指定数、右の列に要素の説明を示します。
web のサブ要素
要素
必要指定数
説明
1 個のみ
アプリケーション用の Web URI を含みます。
1 個のみ
アプリケーション用の Web コンテキストルートを含みます。
web-uri
アプリケーション用の Web URI を含みます。application.xml ファイル内の対応する要素と一致する必要があります。
サブ要素
なし
context-root
アプリケーション用の Web コンテキストルートを含みます。application.xml ファイル内の対応する要素よりも優先されます。
サブ要素
なし
pass-by-reference
false (この要素が存在しない場合はこれがデフォルト値) の場合、このアプリケーションでは、EJB 仕様で要求される pass-by-value セマンティクスが使用されます。true の場合、このアプリケーションでは、pass-by-reference セマンティクスが使用されます。sun-application.xml ファイル内のこの要素の設定は、アプリケーション内のすべての EJB モジュールに適用されます。
個別に配備された EJB モジュール用に、sun-ejb-jar.xml ファイル内に同じ要素を設定することもできます。Bean レベルとアプリケーションレベルの両方で pass-by-reference を使用する場合は、アプリケーションレベルより Bean レベルが優先されます。詳細は、『Sun ONE Application Server Enterprise JavaBeans 開発者ガイド』を参照してください。
サブ要素
なし
unique-id
アプリケーション用の固有 ID を含みます。この値は、アプリケーションが配備または再配備されるたびに自動的に更新されます。この値を手動で変更しないでください。
サブ要素
なし
security-role-mapping
ユーザーおよびグループにロールを割り当てます。最低 1 つの主体名またはグループ名が必要ですが、必ずしも両方は必要ありません。
サブ要素
次の表は、security-role-mapping 要素のサブ要素について示します。左の列にサブ要素名、中央の列に必要指定数、右の列に要素の説明を示します。
role-name
application.xml ファイルの security-role 要素内に role-name を含みます。
サブ要素
なし
principal-name
主体 (ユーザー) 名を含みます。
サブ要素
なし
group-name
グループ名を含みます。
サブ要素
なし
サンプルアプリケーション XML ファイル
この節には次の項目があります。
サンプル application.xml ファイル
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN' 'http://java.sun.com/dtd/application_1_3.dtd'>
<application>
<display-name>app_stateless-simple</display-name>
<description>Application description</description>
<module>
<ejb>stateless-simpleEjb.jar</ejb>
</module>
<module>
<web>
<web-uri>stateless-simple.war</web-uri>
<context-root>helloworld</context-root>
</web>
</module>
</application>
サンプル sun-application.xml ファイル
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sun-application PUBLIC '-//Sun Microsystems, Inc.//DTD Sun ONE Application Server 7.0 J2EE Application 1.3//EN' 'http://www.sun.com/software/sunone/appserver/dtds/sun-application_ 1_3-0.dtd'>
<sun-application>
<unique-id>67488732739338240</unique-id>
</sun-application>