WebLogic Server Web アプリケーションの開発
|
 |
 |
|
この章では、Web アプリケーションのデプロイメントについて説明します。
WebLogic Server アプリケーションのデプロイメントについては、『WebLogic Server アプリケーションのデプロイメント』でより詳しく説明しています。この章では、Web アプリケーションに固有のデプロイメント手順のみを説明します。
Web アプリケーションのデプロイメントは、コネクタ、EJB、およびエンタープライズ アプリケーションのデプロイメントとほぼ同じです。これらのデプロイメント ユニットと同様、Web アプリケーションも展開ディレクトリ形式でデプロイしたり、アーカイブ ファイルとしてデプロイしたりすることができます。
注意 : デプロイメントとプロダクションが目的の場合は、展開された (アーカイブされていない) ディレクトリ形式でアプリケーションをデプロイすることをお勧めします。これは、エンタープライズ アプリケーションの一部としてパッケージ化されたスタンドアロンの Web アプリケーション、EJB、およびコネクタにも当てはまります。この形式を使うことで、アプリケーション全体のアーカイブを展開し、編集し、再アーカイブするのではなく、展開ディレクトリの中でファイルを直接更新できます。展開されたアーカイブ ディレクトリを使うと、『WebLogic Server アプリケーションのデプロイメント』の「展開されたアーカイブ ディレクトリ」で説明するように、他にも利点があります。
Web アプリケーションをデプロイすると、WebLogic Server は Web アプリケーションのコンポーネントをクライアントに提供できるようになります。Web アプリケーションは、ユーザの環境と Web アプリケーションがプロダクション環境に置かれるかどうかに基づいて、複数の手順のうちの 1 つでデプロイできます。WebLogic Server Administration Console や weblogic.Deployer ユーティリティを使うことも、自動デプロイメントを使うことも可能です。
Web アプリケーションをデプロイする手順では、正しいディレクトリ構造を使用し、web.xml デプロイメント記述子を含み、必要であれば weblogic.xml デプロイメント記述子も含む、正常に作動する Web アプリケーションを作成していることを前提としています。Web アプリケーションのパッケージ化および作成に必要な手順の概要については、「Web アプリケーション作成の主な手順」を参照してください。
Web アプリケーションでは、2 つのデプロイメント記述子を使用して操作属性を定義します。web.xml デプロイメント記述子は、WAR ファイルの内容を記述する J2EE 標準の XML ドキュメントです。weblogic.xml デプロイメント記述子は、Web アプリケーション用の WebLogic Server 固有の要素が格納される XML ドキュメントです。
これらのデプロイメント記述子の要素の詳細については、「web.xml デプロイメント記述子の要素」および「weblogic.xml デプロイメント記述子の要素」を参照してください。
デプロイメント記述子は、以下のツールを使用して変更できます。
WebLogic Builder は、アプリケーションのデプロイメント記述子 XML ファイルを編集するためのビジュアルな環境を提供します。これらの XML ファイルは WebLogic Builder で視覚的に編集しながら表示できますが、XML ファイルをテキスト編集する必要はありません。
WebLogic Builder は以下の開発作業に使用します。
WebLogic Builder の使い方については、「WebLogic Builder のマニュアル」を参照してください。
XML デプロイメント ファイルの編集、作成時に、各デプロイメント ファイルに対して正しい DOCTYPE ヘッダを指定することが重要です。特に、DOCTYPE ヘッダ内部に不正な PUBLIC 要素を使用すると、原因究明が困難なパーサ エラーになることがあります。
このヘッダは、デプロイメント記述子の文書型定義 (DTD) ファイルの場所およびバージョンを表します。このヘッダは外部 URL の java.sun.com を参照していますが、WebLogic Server には独自の DTD ファイルが用意されているので、ホスト サーバがインターネットにアクセスする必要はありません。ただし、この <!DOCTYPE...> 要素を weblogic.xml ファイルに含めて、外部 URL を参照させる必要があります。この要素内の DTD バージョンはこのデプロイメント記述子のバージョンを識別するためのものだからです。
XML の解析ユーティリティ (appc など) でヘッダ情報が不正な XML ファイルを解析すると、次のようなエラー メッセージが表示されることがあります。
SAXException: This document may not have the identifier `identifier_name'
identifier_name には通常、PUBLIC 要素内の不正な文字列が表示されます。
weblogic.xml ファイルの DOCTYPE ヘッダは次のようになっています。
<!DOCTYPE weblogic-web-app PUBLIC
"-//BEA Systems, Inc.//DTD Web Application 8.1//EN"
"http://www.bea.com/servers/wls810/dtd/weblogic810-web-jar.dtd">
このリリースの WebLogic Server では、Administration Console デプロイメント記述子エディタが非推奨になりました。代わりに [記述子] タブが新たに Administration Console に追加されています。[記述子] タブは管理の目的に使用します。
[記述子] タブを使用すると、デプロイメント記述子の要素を表示または変更したり、Web アプリケーションの記述子ファイルに保存したりできます。また、記述子ファイルの変更を、その対象となるすべてのデプロイ済みアプリケーションに適用することもできます。
ただし、これらの変更は実行時に動的に有効になるため、Web アプリケーションを再デプロイする必要はありません。[記述子] タブに含まれる記述子要素の属性は、実行時に動的に変更できるものに限られます。これには以下が含まれます。
『WebLogic Server アプリケーションのデプロイメント』の「デプロイメント ツールのリファレンス」を参照してください。
以下の節では、Web アプリケーションのデプロイメントに固有のガイドラインについて説明します。
プロダクション目的の場合も開発目的の場合も、スタンドアロンの Web アプリケーション、EJB、およびリソース アダプタは、エンタープライズ アプリケーションの一部としてパッケージ化およびデプロイすることをお勧めします。このプラクティスにより、アプリケーションの移行、追加、および変更が容易に行えるようになります。たとえば、アプリケーションに対して複数の Web アプリケーション、EJB、またはリソース アダプタ モジュールを追加するには、モジュールをエンタープライズ アプリケーションにパッケージ化する必要があります。最初からエンタープライズ アプリケーションにスタンドアロン アプリケーションをパッケージ化してデプロイすると、大幅な時間の節約になります。またこれにより、従来の単一ディレクトリ構造に比べていくつかの利点がある分割開発ディレクトリ構造を利用できるようになります。
詳細については、『WebLogic Server アプリケーションの開発』の「WebLogic Server アプリケーションの作成」を参照してください。
WebLogic Server を開発モードで実行している場合、applications/ ディレクトリにコピーした Web アプリケーションは自動的にデプロイされます。 また、アプリケーション内のファイルの変更によって、部分的または完全な再デプロイメントを開始することができます。
applications/ ディレクトリの自動デプロイメントは、反復的な開発が行われる環境用であり (プロダクション用ではない)、単一サーバ (具体的には管理サーバ) のみに使用することを想定しています。つまり、applications/ ディレクトリを使用してデプロイしたアプリケーションは、管理サーバ以外のサーバを対象にしないでください。
展開ディレクトリ形式で Web アプリケーションをデプロイする場合、ディレクトリ構造内の特定のファイルを変更することにより、再デプロイメントが影響を受けます。自動デプロイメントを使用して Web アプリケーションをデプロイする場合は、Web アプリケーションの WEB-INF/ ディレクトリにある、REDEPLOY という特別なファイルを変更して Web アプリケーション全体を再デプロイする必要があります。
展開された Web アプリケーションの個々のファイルを変更すると、変更したファイルによっては Web アプリケーションが部分的に再デプロイされます。たとえば、WEB-INF/classes ディレクトリでサーブレットなどのクラスを変更すると、関連付けられたクラスローダが置き換えられます。その結果、アプリケーションでそのクラスの最新のバージョンが使用されます (これは、セッションに格納されるオブジェクトがシリアライズ可能でなければならない理由の 1 つです)。servlet-reload-check-secs 要素を設定することで、自動的なクラス更新のタイミングを制御できます。「weblogic.xml デプロイメント記述子の要素」を参照してください。
REDEPLOY ファイルを変更して、展開ディレクトリ形式で自動デプロイした Web アプリケーション全体を再デプロイするには、次の手順に従います。
注意 : REDEPLOY の内容変更では、ファイルのタイムスタンプを変更することに重点があります。簡単な編集を行って保存するだけでタイムスタンプは変更できます。
サーブレット コンテナは、サーブレット クラスおよびフィルタ クラスの変更を検出すると、クラスローダをリセットします。すべてのサーブレットとフィルタがまとめて再ロードされることに注意してください。1 つのサーブレットまたはフィルタを変更すると、すべてが再ロードされます。詳細については、「コマンドライン デプロイメントの使用」を参照してください。
同様に、JSP ファイルを変更すると JSP が再コンパイルされます。JSP クラス ファイルは個別に再ロードされるため、1 つの JSP の再ロードによって影響を受ける JSP クラスは 1 つだけです。
静的なコンテンツはディスクから直接使用されるため、HTML ページ、イメージ ファイルなどの再デプロイメントは必要ありません。ただし、キャッシング タグまたはフィルタを使用している場合は、コンテンツを変更したときにキャッシュをフラッシュする必要があります。
自動デプロイメントを使用する場合、REDEPLOY という特別なファイルを変更することにより、展開ディレクトリ形式でデプロイされた Web アプリケーションを再デプロイできます。 また、WEB-INF/classes ディレクトリ内に新しいクラス ファイルをコピーして古いクラス ファイルを上書きすることで、部分的に再デプロイすることもできます。
コマンドライン デプロイメントは、自動デプロイされないアプリケーションに使用します。これには、applications/ ディレクトリ以外の場所からデプロイされるすべてのアプリケーションが該当します。また、サーバがプロダクション モードで実行しているときは自動デプロイメントは無効です。このため、プロダクション モードが有効になっているときはすべてのアプリケーションでコマンドライン デプロイメントが必要です。
プロダクション モードを有効にするには、-Dweblogic.ProductionModeEnabled=true フラグを使用してドメインの管理サーバを起動します。 これで、ドメイン内のすべてのサーバ インスタンスにプロダクション モードが設定されます。
Web アプリケーションのコンポーネント (サーブレット、JSP、HTML ページなど) を変更するときは、対象になっている管理対象サーバに変更したコンポーネントもデプロイされるように、変更したコンポーネントを更新する追加の手順を実行する必要があります。コンポーネントを更新する方法の 1 つに、Web アプリケーション全体の再デプロイメントがあります。Web アプリケーションを再デプロイすることは、Web アプリケーションの対象になっている管理対象サーバすべてに、変更したコンポーネントだけではなく Web アプリケーション全体をネットワーク経由で再送信することを意味します。
Web アプリケーションの再デプロイメントでは、次の点に注意してください。
注意 : weblogic.xml デプロイメント記述子で save-sessions-enabled 要素を true に設定しておくと、セッションが復元されます。
静的コンポーネント (JSP ファイル、HTML ファイル、イメージ ファイルなど) を更新するときは、weblogic.Deployer ユーティリティを使用することをお勧めします。weblogic.Deployer ユーティリティについては、『WebLogic Server アプリケーションのデプロイメント』の「デプロイメント ツールのリファレンス」を参照してください。
複数の Web アプリケーションをデプロイするには、それぞれのコンテキスト ルートをユニークなものにする必要があります。たとえば /test-1、/test-2 などのようにユニークにします。そうすることで、Web アプリケーション モジュールの数が増加したときに Web アプリケーション モジュールのコンテキスト ルートの表示が壊れることを防げます。
|
|
|