|
|
|
|
|
開発者の生産性を向上させるために、Sun ONE Application Server 7 にはいくつかの動的な配備機能が用意されています。 ここでは、これらの機能について説明し、前の手順で配備したサンプルアプリケーションを使っていくつかの練習を行います。
動的配備と動的再読み込み開発サイクルの短縮のために、Sun ONE Application Server 7 には次の機能が用意されています。
動的配備と動的再配備 J2EE[tm] アプリケーションを動的に配備または再配備できるようにしたことで、対象となるアプリケーションサーバーインスタンスを再起動しなくても、アプリケーションの初回配備やその後の再配備を行うことができます。再配備時に、アプリケーションはアプリケーションサーバーによって完全に再読み込みされます。この機能は、EAR レベルの配備だけでなく、Web モジュールや EJB[tm] JAR モジュールの個別配備にも適用されます。動的配備、動的再配備の際は、サーバーの設定を変更する必要はありません。
スマート再配備 スマート再配備によって、EJB ベースのアプリケーションを迅速に再配備できます。アプリケーションを再配備すると、前回の配備以降にインタフェースが変更された EJB のスタブクラスとスケルトンクラスだけが再生成されます。配備に要する時間の多くはスタブとスケルトンの生成にあてられているため、スマート再配備によって待ち時間を大幅に短縮できます。この機能を使用するのに、サーバーの設定を変更する必要はありません。 スマート再配備は、すべての再配備作業に適用されます。 動的再読み込み 動的再読み込みは、アプリケーションの完全な再アセンブルと再配備、およびアプリケーションサーバーの再起動を行わなくても、アプリケーションサーバーが個々のクラスファイル、Web コンテンツの変更、および配備記述子の変更を読み込み直す機能です。クラスファイルと配備記述子の変更を動的に再読み込みするために、サーバーインスタンスは「.reload」という特別なファイルを監視しています。このファイルは、アプリケーションまたは個々の配備モジュールの配備領域の最上位層に格納されます。開発者による編集や make 機能の実行によって .reload ファイルに変更が加えられると、サーバーインスタンスはアプリケーションまたは個々の配備モジュールを完全に読み込み直します。この機能を利用するには、アプリケーションサーバーのインスタンスごとに明示的に有効にする必要があります。 監視によるオーバーヘッドが加わるため、この機能は開発環境だけに適しています。 動的再読み込みを有効にしなくても、アプリケーションサーバーの Web コンテナは静的なコンテンツや JavaServer Page (JSP) などの Web コンテンツを監視し、変更の有無を確認します。変更があった場合は、次回のアクセス時に Web コンテナはファイルを自動的に読み込み直します。 アプリケーションサーバーに関する説明では、「ホット配備」という用語を目にすることがあります。多くの場合、「ホット配備」は動的配備、動的再配備、および動的再読み込みを意味します。 ただし、あるアプリケーションサーバーがこれらの機能すべてに対応しているかどうかを調べるには、その製品のマニュアルをよく読む必要があります。 アプリケーションコンポーネントの変更この項では、サンプルアプリケーション「jdbc-simple」に含まれる次のコンポーネントに変更を加えます。 Web コンテンツの再配備と再読み込み
EJB の再配備と再読み込み
ここでは、サーブレットクラスファイルの変更、アプリケーションの再アセンブル、およびアプリケーションの動的再配備を実際に行うことで、アプリケーションサーバーの動的再配備機能について説明します。動的再配備では、アプリケーションの再起動は必要ありません。 1. サーブレットのソースコードディレクトリに移動します。たとえば、次のようなディレクトリです。
2. GreeterDBServlet.java ファイルを編集します。次の行を探します。
見つかったら、先頭に「MODIFIED」という文字列を追加します。 次に例を示します。
3. 変更を保存します。 4. サンプルを再コンパイルし、再アセンブルします。
5. 管理コンソールを使ってサンプルアプリケーションを再配備します。
6. サーバーのイベントログファイルを確認しながらアプリケーションを再実行します。 次の stdout メッセージの先頭には、「MODIFIED」という単語が表示されています。
この練習では、サーブレットクラスファイルが変更されたアプリケーションを再配備することで、アプリケーションサーバーインスタンスの再起動を必要としない動的再配備機能のメリットを確認しました。 1. サンプルアプリケーション「jdbc-simple」を実行し、メインページのタイトルとして表示される文字列を確認します。 2. アプリケーションサーバーインスタンスのアプリケーション配備領域に移動します。特に、次の Web モジュールの領域に移動します。
3. index.html ファイルを開き、次のように <TITLE> タグの直後に「MODIFIED 」という文字列を追加します。
4. 変更を保存します。 5. アプリケーションのメインページに再度アクセスし、ユーザー名を入力して「Process」をクリックします。 Web ページのタイトルが変更されていない場合は、Shift キーを押しながらブラウザの「更新」ボタンをクリックすると、コンテンツがアプリケーションサーバーから再読み込みされます。 1. サンプルアプリケーション「jdbc-simple」を実行し、ユーザー名を入力して「Process」ボタンをクリックします。 表示されるページの内容を確認します。このページを表示している JSP を変更します。 2. アプリケーションサーバーインスタンスのアプリケーション配備領域に移動します。特に、次の Web モジュールの領域に移動します。
3. GreeterDBView.jsp ファイルを開き、次のように <TITLE> タグの直後に「MODIFIED 」という文字列を追加します。
4. 変更を保存します。 5. アプリケーションを再実行し、ブラウザウィンドウに表示される新しいタイトルを確認します。 変更を検出した Web コンテナは JSP ファイルを再コンパイルするため、変更後のアプリケーションの最初の実行には時間がかかります。 6. アプリケーションを再実行します。JSP のコンパイルが完了しているので、今回は速やかに実行されます。
サーブレットクラスファイルを変更したのと同じ方法で、EJB 実装クラスファイルに変更を加え、アプリケーションサーバーを再起動せずに動的再配備を行なって、アプリケーションを簡単にテストしてみましょう。 1. EJB のソースコードディレクトリに移動します。たとえば、次のようなディレクトリです。
2. GreeterDBBean.java ファイルを編集します。次の行を探します。
見つかったら、先頭に「MODIFIED」という文字列を追加します。次に例を示します。
3. 変更を保存します。 4. サンプルを再コンパイルし、再アセンブルします。
5. 管理コンソールを使ってサンプルアプリケーションを再配備します。
6. サーバーのイベントログファイルを確認しながらアプリケーションを再実行します。 次の stdout メッセージの先頭には、「MODIFIED」という単語が表示されています。
この練習では、EJB 実装クラスファイルが変更されたアプリケーションを再配備することで、アプリケーションサーバーインスタンスの再起動を必要としない動的再配備機能のメリットを確認しました。 ここでは、動的再読み込み機能について説明します。 クラスを動的に読み込み直す利点は、動的な再配備による利点より複雑に考えられがちですが、開発時間の短縮という観点から言えば、動的再配備よりも動的再読み込みのほうが効果的です。 make 機能、または Java コンパイラのクラスファイル送信先設定を使って、個々のファイルをビルド領域から配備領域にコピーするプロセスを自動化することで、動的再読み込み機能のメリットを引き出すことができます。 この練習の前半では、GreeterDBBean の実装クラスに新たな変更を加えます。EJB を再コンパイルしたら、それをアプリケーションの配備領域に手動でコピーします。 次に、.reload という特別なファイルを作成し、サンプルアプリケーションを再実行します。.reload ファイルを作成することで、アプリケーションの配備領域に 1 つまたは複数のファイルが新たにコピーされたこと、およびアプリケーション全体の再読み込みが必要であることをサーバーインスタンスに認識させることができます。アプリケーションサーバーのインスタンスがアプリケーション全体を再読み込みするときに、メモリーに残されているすべてのアプリケーションコンポーネントはフラッシュされ、すべてが再読み込みされます。また、アプリケーションレベルの再読み込み時には、そのアプリケーションと関連するすべてのユーザーセッションもフラッシュされます。 変更したクラスファイルをコピーして .reload ファイルを作成するだけで、変更後のアプリケーションをただちにテストできるようになります。 動的再読み込み機能を利用すれば、アプリケーションを再アセンブルしたり、あらためて再配備したりする必要はありません。 動的再読み込みの有効化 クラスの動的再読み込みを実際に行う前に、動的再読み込み機能を有効にする必要があります。 動的再読み込み機能を有効にすると、.reload ファイルの存在や変更が頻繁に確認されるため、オーバーヘッドが増大します。運用環境でこの機能を有効にすることはお勧めできません。 1. 管理コンソールを開きます。 2. 「server1」インスタンスノードを選択します。 3. Applications フォルダを選択します。 4. 「再読み込みを有効」チェックボックスをクリックしてチェックマークをつけます。 4. 「保存」をクリックします。 5. サーバーインスタンス「server1」を選択して「変更の適用」をクリックし、サーバーインスタンスを再起動します。
次に、EJB 実装クラスを変更し、再コンパイルして手動で配備領域にコピーします。 EJB 実装クラスの変更 1. EJB のソースコードディレクトリに移動します。たとえば、次のようなディレクトリです。
2. GreeterDBBean.java ファイルを再度編集します。次の行を探します。
見つかったら、先頭に「MODIFIED AGAIN」という文字列を追加します。次に例を示します。
3. 変更を保存します。 再コンパイルと配備領域へのコピー 1. サンプルアプリケーションの src/ ディレクトリに戻ります。 2. ターゲット名に compile を指定して asant を実行し、変更した Java ソースファイルを再コンパイルします。ターゲット名に compile を指定するのは、アプリケーションが完全に再アセンブルされるのを防ぐためです。
ここで再コンパイルされるソースファイルは 1 つだけで、残りの Java ソースファイルは再コンパイルされません。 3. 新たに生成されたクラスをローカルの build/classes/ ディレクトリからターゲットアプリケーションサーバーインスタンスのアプリケーション配備領域に手動でコピーします。 新たに生成されたサーブレットクラスは、次のディレクトリに格納されています。
4. このファイルを次のディレクトリにコピーします。
.reload ファイルの作成 アプリケーションの配備ディレクトリのルートに .reload という名前の空のファイルを作成します。 Windows 環境では、メモ帳を使ってテキストファイルを新規作成し、それを次のディレクトリに保存します。
UNIX 環境では、前の手順で空のファイルを作成するために指定した配備ディレクトリ内で「touch .reload」を実行します。 アプリケーションの再実行 1. サーバーのイベントログファイルを確認しながらアプリケーションを再実行します。 次の stdout メッセージの先頭には、「MODIFIED AGAIN」という単語が表示されています。
2. println() ステートメントを変更して、EJB 実装クラスにさらに変更を加えます。EJP 実装クラスを再コンパイルしてコピーし、.reload ファイルにも新たな変更を加えてアプリケーションによる動的再読み込みを実行します。
「サーバーのその他の機能」に進みます。ここでは、一般的なタスクについて学習します。
|
||||||||||||||||||||||||||||||||
運用環境での動的再配備 : 動的再配備の主な目的は開発時間を短縮することにありますが、アプリケーションを再配備する前に次の手順を実行すれば、運用環境でもこの機能を利用できます。
メモ帳を使って .reload ファイルを作成できない場合 : メモ帳で .reload ファイルを保存する際は、「ファイルの種類」を「すべてのファイル」に設定する必要があります。通常の設定では、 .reload というファイル名に拡張子 .txt が追加されてしまいます。