|
|
|
|
|
|
| | | |
この章では、Web アプリケーションをデプロイする方法について説明します。
Web アプリケーションのデプロイメントは最後の手順です。これによって WebLogic Server は Web アプリケーションのコンポーネントをクライアントに提供します。Web アプリケーションは、ユーザの環境と Web アプリケーションがプロダクション環境に置かれるかどうかに基づいて、複数の手順のうちの 1 つでデプロイできます。WebLogic Server Administration Console や weblogic.deploy ユーティリティを使うことも、自動デプロイメントを使うことも可能です。
Web アプリケーションをデプロイする手順では、正しいディレクトリ構造を使用し、web.xml デプロイメント記述子を含み、必要であれば weblogic.xml デプロイメント記述子も含む、正常に作動する Web アプリケーションを作成していることを前提としています。Web アプリケーションの作成に必要な手順の概要については、「Webアプリケーション作成の主な手順」を参照してください。
WebLogic Server を実行するには、開発モードとプロダクション モードの 2 つのモードが利用できます。開発モードを有効にするには、-Dweblogic.ProductionModeEnabled=false フラグを指定して WebLogic Server を起動します（これはデフォルトの動作です）。プロダクション モードを有効にするには、-Dweblogic.ProductionModeEnabled=true フラグを指定して WebLogic Server を起動します。これらのモードの設定の詳細については、「WebLogic Server の起動と停止」を参照してください。
開発モードを指定すると、自動デプロイ機能を使用できます。自動デプロイ機能では、管理サーバの applications ディレクトリに Web アプリケーションをコピーすることによって、Web アプリケーションを短時間でデプロイできます。このディレクトリは、WebLogic Server インストール環境の config\mydomain ディレクトリ（mydomain は WebLogic Server ドメインの名前）にあります。WebLogic Server は applications ディレクトリにコピーされるすべてのアプリケーションを自動的にデプロイします。.war 形式の Web アプリケーションが変更された場合、WebLogic Server はその Web アプリケーションを自動的に再デプロイします。Web アプリケーションが展開形式の場合は、
展開ディレクトリ形式でデプロイされた Web アプリケーションの再デプロイを参照してください。アプリケーションを config/mydomain/applications ディレクトリに格納しておくことはお勧めできません。このディレクトリにアプリケーションが既に存在していると、プロダクション モードであっても自動的にデプロイされます。
Web アプリケーションは、ファイル システムから、展開ディレクトリ形式、またはアーカイブされた .war 形式にデプロイできます。展開ディレクトリ形式とは、Web アプリケーション コンポーネントが Web アプリケーション用の標準ディレクトリ構造を使ってファイル システム上に整理されていることを意味しています。.war アーカイブは、Web アプリケーションの内容を展開ディレクトリ形式でアーカイブするために、Java jar ユーティリティを使って作成したものです。
管理対象の WebLogic Server のクラスタを使用している場合、1 つまたは複数の「対象となった」管理対象サーバに Web アプリケーションをデプロイするように指定することができます。管理サーバは、Web アプリケーションの対象になっているドメインにある管理対象サーバに Web アプリケーションを自動的にコピーします。
自動デプロイメントを使用した Web アプリケーションのデプロイメント
自動デプロイメントは Web アプリケーションの開発のために設計された便利な機能であり、プロダクション アプリケーションでの使用には適しません。アプリケーションをプロダクション環境に移動するには、 プロダクション モードを有効にした Web アプリケーションのデプロイで説明している手動のデプロイメント手順を使用してください。管理サーバに Web アプリケーションをデプロイする方法は自動デプロイメントだけです。自動デプロイされた Web アプリケーションが管理対象サーバを対象としている場合、Web アプリケーションも管理対象サーバにデプロイされます。
自動デプロイメントを使用する前に、正しいディレクトリ構造を使用し、web.xml デプロイメント記述子を含み、必要であれば weblogic.xml デプロイメント記述子も含む、正常に作動する Web アプリケーションを作成する必要があります。Web アプリケーションは、アーカイブされた .war ファイルとして、または展開ディレクトリ形式でデプロイできます（
ディレクトリ構造を参照）。
自動デプロイメントを使用した Web アプリケーションのデプロイ方法
自動デプロイメントを使用して Web アプリケーションをデプロイするには、次の手順に従います。
-DProductionModeEnabled=false フラグを指定して WebLogic 管理サーバを起動します。詳細については、「WebLogic Server の起動と停止」を参照してください。
.war アーカイブ ファイルまたは Web アプリケーションを含むディレクトリを、ドメインの applications ディレクトリにコピーします。applications ディレクトリは WebLogic Server インストール環境の config\mydomain ディレクトリ（mydomain は WebLogic Server ドメイン）にあります。Web アプリケーションは管理サーバによって自動的にデプロイされます。
applications ディレクトリにコピーしたばかりの Web アプリケーションも入っています。
http://
myServer:myPort/myWebApp/resource
各要素の説明は次のとおりです。
Web アプリケーションの applications ディレクトリへのアップロード
Administration Console は、Web アプリケーションの applications ディレクトリへのアップロードにも使用できます。この手順は、WebLogic Server がリモート マシンにある場合に便利です。
Web アプリケーションをアップロードするには、次の手順に従います。
-DProductionModeEnabled=false フラグを指定して WebLogic 管理サーバを起動します。詳細については、「WebLogic Server の起動と停止」を参照してください。
.war ファイルの格納場所に移動します。
applications ディレクトリにコピーされ、デプロイされます。
自動デプロイメントを使用した Web アプリケーションの再デプロイ
自動デプロイメントを使用している場合は、applications ディレクトリにデプロイされている Web アプリケーションの静的コンポーネント（JSP や HTML ページなど）を変更したなら、変更を反映するために、Web アプリケーションを再デプロイする必要があります。その手順は、.war アーカイブ ファイルでデプロイされた Web アプリケーションと、展開ディレクトリ形式でデプロイされた Web アプリケーションとでは異なります。
.war アーカイブでの Web アプリケーションの再デプロイ
アーカイブ ファイルを変更すると、Web アプリケーションの再デプロイメントが自動的に開始されます。自動デプロイされた Web アプリケーションが管理対象サーバを対象としている場合、Web アプリケーションもその管理対象サーバに再デプロイされます。
展開ディレクトリ形式でデプロイされた Web アプリケーションの再デプロイ
自動デプロイメントを使用している場合、展開ディレクトリ形式でデプロイした Web アプリケーションの再デプロイは、REDEPLOY と呼ばれる特殊ファイルを変更して、または Administration Console を使用して行うことができます。または、新しいバージョンのクラス ファイルを WEB-INF/classes ディレクトリにある古いファイルの上にコピーすることで、部分的な再デプロイを行うこともできます。
REDEPLOY ファイルの変更
REDEPLOY ファイルを変更して Web アプリケーションを再デプロイするには、次の手順に従います。
REDEPLOY という空のファイルを作成して、Web アプリケーションの WEB-INF ディレクトリに格納します（ディレクトリが存在しない場合は作成します）。
REDEPLOY ファイルを変更します。まずファイルを開き、内容を変更して（スペースを挿入するのが最も簡単な方法）、ファイルを保存します。また UNIX マシンでは、REDEPLOY ファイルに対して touch コマンドを使用することもできます。次に例を示します。
touch user_domains/mydomain/applications/DefaultWebApp/WEB-INF/REDEPLOY
REDEPLOY ファイルが変更されると、Web アプリケーションはすぐに再デプロイされます。
Administration Console を使った再デプロイ
Administration Console を使用して Web アプリケーションを再デプロイするには、次の手順に従います。
ホット デプロイメント
WEB-INF/classes ディレクトリにあるファイルの再デプロイは、次の方法で行います。クラスが WEB-INF/classes にデプロイされている場合は、古いファイルより後のタイム スタンプを持つ新しいバージョンのファイルをコピーするだけで、Web アプリケーションは、WEB-INF/classes フォルダ内のすべてを新しいクラスローダで再ロードします。
WLS がファイル システムを調べる頻度はコンソールで制御します。[デプロイメント｜Web アプリケーション] で Web アプリケーションを選択します。[コンフィグレーション] タブの [ファイル] サブタブに移動し、[再ロード間隔（秒）] に秒数を入力します。
プロダクション モードを有効にした Web アプリケーションのデプロイ
プロダクション モードを有効にして Web アプリケーションをデプロイするには、-DProductionModeEnabled=true フラグを指定して WebLogic 管理サーバを起動する必要があります。この機能は WebLogic 管理サーバでは使用できますが、管理対象サーバでは使用できません。詳細については、「WebLogic Server の起動と停止」を参照してください。
Web アプリケーションは、Administration Console または weblogic.deploy ユーティリティを使用してデプロイできます。Web アプリケーションは、デプロイすると、ドメイン内で対象とした管理対象サーバすべてに自動的にデプロイされます（管理対象サーバの管理の詳細については、「WebLogic Server とクラスタのコンフィグレーション」を参照してください）。
config/mydomain/applications ディレクトリにはアプリケーションを格納しておかないことをお勧めします。プロダクション モードでは、WebLogic Server は config/mydomain/applications ディレクトリに新しく置かれたアプリケーションは検出しませんが、プロダクション モードに切り替わる前にこのディレクトリで検出していたアプリケーションは、引き続き自動的にデプロイします。
これらのデプロイメント手順の実行には、正しいディレクトリ構造を使用し、web.xml デプロイメント記述子を含み、必要であれば weblogic.xml デプロイメント記述子も含む、正常に作動する Web アプリケーションを作成していることを前提としています。Web アプリケーションは、アーカイブされた .war ファイルとして、または展開ディレクトリ形式でデプロイできます。詳細については、
ディレクトリ構造を参照してください。
Administration Console を使用した Web アプリケーションのデプロイ
Administration Console を使用して Web アプリケーションをデプロイするには、次の手順に従います。
.war ファイルへのパスを入力します。次に例を示します。
（展開ディレクトリ形式） c:\myApps\myWebApp
（アーカイブ形式） c:\myApps\myWebApp.war
http://
myServer:myPort/myWebApp/resource
各要素の説明は次のとおりです。
weblogic.deploy ユーティリティを使った Web アプリケーションのデプロイ
weblogic.deploy ユーティリティを使って Web アプリケーションをデプロイするには、次の手順に従います。
CLASSPATH に入り、JDK が利用できるようにローカル環境を設定します。CLASSPATH の設定には、config\mydomain ディレクトリにある setEnv スクリプトを使用できます。
% java weblogic.deploy -port
port_number-hosthost_name-componentapplication:targetdeploypasswordapplicationsource
各要素の説明は次のとおりです。
host_name は、WebLogic Server のホスト マシンの名前。
port_number は、WebLogic Server がリクエストをリスンしているポート番号。
application は、この Web アプリケーションに割り当てる名前。
target は、この Web アプリケーションの対象となるサーバ、クラスタ、仮想ホストのいずれかの名前。対象はカンマで区切ると複数指定できます。
password はシステム管理用パスワード。
source はデプロイする .war ファイルのフル パス名、または展開ディレクトリ形式の Web アプリケーションを含むディレクトリのフル パス名。
次に例を示します。
java weblogic.deploy -port 7001 -host myhost -component
myWebApp:myserver deploy pswd1234 myWebApp d:\myWebApp.war
プロダクション モードを有効にした Web アプリケーションの再デプロイ
プロダクション モードを有効にして Web アプリケーションを再デプロイするには、-DProductionModeEnabled=true フラグを指定して WebLogic 管理サーバを起動する必要があります。この機能は WebLogic 管理サーバでは使用できますが、管理対象サーバでは使用できません。詳細については、「WebLogic Server の起動と停止」を参照してください。
管理サーバ上の Web アプリケーションのコンポーネント（サーブレット、JSP、HTML ページなど）を変更するときは、対象になっている管理対象サーバに変更したコンポーネントもデプロイされるように、変更したコンポーネントを更新する追加の手順を実行する必要があります。コンポーネントを更新する 1 つの方法は、Web アプリケーション全体を再デプロイすることです。Web アプリケーションを再デプロイすることは、Web アプリケーションの対象になっている管理対象サーバすべてに、変更したコンポーネントだけではなく Web アプリケーション全体をネットワーク経由で再送信することを意味します。
Web アプリケーションの再デプロイメントでは、次の点に注意してください。
JSP、HTML ファイル、画像ファイルなどの静的ファイルを更新する必要がある場合、weblogic.deploy ユーティリティの更新オプションを使って静的ファイルを更新できます。詳細については、
アプリケーションの再デプロイを利用しない静的コンポーネントの更新を参照してください。
Administration Console を使用した Web アプリケーションの再デプロイ
Administration Console で Web アプリケーションを再デプロイするには、次の手順に従います。
注意: Web アプリケーションを再デプロイすると、アクティブな HTTP セッションは失われます。
weblogic.deploy ユーティリティを使った Web アプリケーションの再デプロイ
次のコマンドを入力します。
% java weblogic.deploy -port
port_number-hosthost_nameupdatepasswordapplicationsource
各要素の説明は次のとおりです。
注意: Web アプリケーションを再デプロイすると、アクティブな HTTP セッションは失われます。
アプリケーションの対象になっているサーバ インスタンスの 1 つでそのアプリケーションを更新すると、対象になっているすべてのサーバでアプリケーションが更新されます。たとえば、アプリケーションの対象がクラスタの場合、クラスタ化されたサーバ インスタンスの 1 つでアプリケーションを更新すると、アプリケーションはクラスタの全メンバで更新されます。同様に、クラスタとスタンドアロン サーバ インスタンスがアプリケーションの対象になっている場合は、スタンドアロン サーバのインスタンスでアプリケーションを更新すると、クラスタでもアプリケーションが更新されます。また、逆の場合も同様の処理が行われます。
部分的な再デプロイメント
アプリケーションの再デプロイを利用しない静的コンポーネントの更新
アプリケーション全体を再デプロイしないでアプリケーションの静的コンポーネントを更新するには、weblogic.refresh ツールを使用します。
管理サーバ上で Web アプリケーションの静的ファイルを更新する場合、ファイルは管理対象サーバ上の Web アプリケーションに自動的にはコピーされません。しかし、weblogic.refresh を使えば、次のような静的ファイルの更新、追加、または削除を行うことができます。
各 JSP はそれ自体のクラスローダによってロードされるので、JSP を更新するために Web アプリケーションを再デプロイする必要はありません。Web アプリケーションのクラスローダは、JSP 個別のクラスローダの親です。
このユーティリティには以下の制限があることに注意してください。
.ear ファイルに収められている場合は、.ear ファイルも展開形式でなければなりません。このユーティリティは、.war ファイルでアーカイブされたコンポーネントには機能しません。
静的ファイルを更新するには、次の手順に従います。
CLASSPATH に入り、JDK が利用できるように開発環境を設定します。環境の設定には、config\mydomain ディレクトリにある setEnv スクリプトを使用できます。
% java weblogic.refresh -url
-username-password -application -component -files -delete -root
各要素の説明は次のとおりです。
url は、WebLogic 管理サーバの URL。
username は、システム管理用ユーザ名。
password はシステム管理用パスワード。
application は、更新する Web アプリケーションを含むエンタープライズ アプリケーションの名前。Web アプリケーションがエンタープライズ アプリケーションの一部ではない場合は、Web アプリケーションの名前を入力します。
component は、更新する Web アプリケーションの名前。
files は、更新されるファイルのカンマで区切ったリスト。*.jsp や *.gif などのワイルドカードを使って、ファイルを指定できます。ただし、複数のファイルを指定する場合、ワイルドカードとカンマ区切りの複数ファイル指定の両方を一緒に使うことはできないことに注意してください。ファイル名は、Web アプリケーションのルートを基準とする相対ファイル名でなければなりません。したがって、ファイルが ball.gif で、Web アプリケーションのルート ディレクトリの \foo サブディレクトリにある場合は、ファイル名は foo\ball.gif になります。サーバ上にファイルがない場合は、指定したサブディレクトリと共にファイルが作成されます。
delete を設定すると、指定したファイルが削除されます。
root は、更新用に使用するファイルが格納されているディレクトリ。デフォルトはカレント ディレクトリです。
たとえば、次のコマンドは myWebApp Web アプリケーションの HelloWorld.jsp ファイルと foo\ball.gif ファイルを更新します。
java weblogic.refresh -url t3://localhost:7001 -username
myUsername -password myPassword -application myApplication
-component myWebApp -root c:\stagedir\myWebApp
HelloWorld.jsp,foo\ball.gif
Web アプリケーションをアンデプロイすると、コンフィグレーションには何ら影響はありませんが、Web アプリケーションはクライアントからのリクエストに応答できなくなります。Web アプリケーションは、Administration Console または weblogic.deploy ユーティリティを使用してアンデプロイできます。
Administration Console を使用した Web アプリケーションのアンデプロイ
Administration Console を使用して Web アプリケーションをアンデプロイするには、次の手順に従います。
weblogic.deploy ユーティリティを使った Web アプリケーションのアンデプロイ
weblogic.deploy ユーティリティを使って Web アプリケーションをアンデプロイするには、次の手順に従います。
CLASSPATH に入り、JDK が利用できるように開発環境を設定します。CLASSPATH の設定には、config\mydomain ディレクトリにある setEnv スクリプトを使用できます。
% java weblogic.deploy -port
port_number-hosthost_nameundeploypasswordapplicationsource
各要素の説明は次のとおりです。
Web アプリケーションの削除とは、ドメイン コンフィグレーションから Web アプリケーションのコンフィグレーション情報すべてを削除し、Web アプリケーションをクライアントからのリクエストに応答できなくすることです。Web アプリケーションは、Administration Console または weblogic.deploy ユーティリティを使用して削除できます。
Web アプリケーションを削除しても、ファイル システムから Web アプリケーションが削除されるわけではありません。
Web アプリケーションの applications ディレクトリからの削除
（WebLogic Server を -DProductionModeEnabled=false フラグで起動した）開発モードで WebLogic Server を稼働している場合、applications ディレクトリの Web アプリケーションを削除するには、applications ディレクトリから Web アプリケーションを含むディレクトリまたはアーカイブを物理的に削除する必要があります。
Administration Console を使用した Web アプリケーションの削除
Administration Console を使用して Web アプリケーションを削除するには、次の手順に従います。
weblogic.deploy ユーティリティを使った Web アプリケーションの削除
weblogic.deploy ユーティリティを使って Web アプリケーションを削除するには、次の手順に従います。
CLASSPATH に入り、JDK が利用できるように開発環境を設定します。CLASSPATH の設定には、config\mydomain ディレクトリにある setEnv スクリプトを使用できます。
% java weblogic.deploy -port
port_number-hosthost_namedeletepasswordapplication
各要素の説明は次のとおりです。
エンタープライズ アプリケーションの一部としての Web アプリケーションのデプロイ
エンタープライズ アプリケーションは、Web アプリケーション、EJB、およびリソース アダプタを単一のデプロイ可能なユニットにバンドルする J2EE デプロイメント ユニットです。詳細については、「WebLogic Server J2EE アプリケーションのパッケージ化」を参照してください。エンタープライズ アプリケーションの一部として Web アプリケーションをデプロイすると、WebLogic Server が Web アプリケーション用のリクエストを解決するときに、Web アプリケーションの実際の名前の代わりに使う文字列を指定することができます。エンタープライズ アプリケーション用の application.xml デプロイメント記述子の <context-root> 要素に新しい名前を指定します。詳細については、「application.xml デプロイメント記述子の要素」を参照してください。
たとえば、oranges という Web アプリケーションでは、多くの場合、次のような URL で oranges Web アプリケーションのリソースを要求します。
http://host:port/oranges/catalog.jsp
oranges Web アプリケーションがエンタープライズ アプリケーションにパッケージ化された場合、次の例で示す <context-root> に値を指定できます。
<module>
<web>
<web-uri>oranges.war</web-uri>
<context-root>fruit</context-root>
</web>
</module>
その結果、次の URL を使用して、oranges Web アプリケーションの同じリソースにアクセスできます。
http://host:port/fruit/catalog.jsp
注意: 1 つのエンタープライズ アプリケーションでは、複数の名前で 1 つの Web アプリケーションをデプロイすることはできません。ただし、それぞれの Web アプリケーションが異なるエンタープライズ アプリケーションにパッケージ化されている場合には、複数の名前で同一の Web アプリケーションをデプロイできます。
Web アプリケーションがスタンドアロンである場合は、weblogic.xml ファイルの context-root 要素を使って、Web アプリケーションのコンテキスト ルートを指定できます。Web アプリケーションが EAR の一部である場合は、EAR の application.xml ファイルでコンテキスト ルートを指定します。application.xml ファイルにおける context-root の設定の方が、weblogic.xml での context-root の設定より優先されます。 context-root 要素を参照してください。
|
|
|