Oracle® Fusion Middleware Oracle WebLogic Server Web アプリケーション、サーブレット、JSP の開発 11g リリース 1 (10.3.1) B55521-01 |
|
戻る |
次へ |
以下の節では、Web アプリケーション リソースを作成およびコンフィグレーションする方法について説明します。
Java Platform, Enterprise Edition (Java EE) バージョン 5.0 プログラミング モデルの重要な点は、メタデータ アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション コンポーネントの動作、依存性注入の要求方法などを Java クラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ アプリケーションの以前のバージョン (J2EE 1.4 以前) で必要だったデプロイメント記述子に代わるものです。詳細については、http://java.sun.com/javaee/reference/
を参照してください。
Java EE アノテーションの使用により、標準の application.xml
および web.xml
デプロイメント記述子は省略可能になりました。Java EE プログラミング モデルでは、EJB、サーブレット、Web アプリケーション、JSP などの Web コンテナに対して JDK 5.0 アノテーション機能を採用しています。「Web コンポーネント用の WebLogic アノテーション」および http://java.sun.com/javaee/5/docs/api/
を参照してください。
ただし、WebLogic Server にデプロイされる Web アプリケーションは、標準の Java EE デプロイメント記述子ファイルと WebLogic 固有のデプロイメント記述子ファイルを引き続き使用して、それらのリソースと操作属性を定義できます。
Web アプリケーションは、Java EE 仕様で定義されている標準ディレクトリ構造を採用しています。Web アプリケーションは、このディレクトリ構造を使用するファイルの集合としてデプロイする (展開ディレクトリ形式) か、WAR ファイルと呼ばれるアーカイブ ファイルとしてデプロイできます。展開された Web アプリケーションは、エンタープライズ アプリケーションの一部としてパッケージ化およびデプロイすることをお勧めします。これは、アプリケーションの移行、追加、および変更を容易に行うことができるベスト プラクティスです。また、Web アプリケーションをエンタープライズ アプリケーションの一部としてパッケージ化することにより、分割開発ディレクトリ構造を活用できます。この構造には、従来の単一ディレクトリ構造に比べて多くの利点があります。
WEB-INF
ディレクトリには、Web アプリケーションのデプロイメント記述子 (web.xml
および weblogic.xml
) と、コンパイル済み Java クラスおよびライブラリ JAR ファイルを格納するための 2 つのサブディレクトリが格納されます。サブディレクトリの名前は classes
と lib
です。JSP taglib は、ステージング ディレクトリの最上位の WEB-INF
ディレクトリに格納されます。Java クラスには、サーブレット、ヘルパー クラス、およびコンパイル済みの JSP (必要に応じて) などがあります。
Web アプリケーションに属するすべてのサーブレット、クラス、静的ファイル、およびその他のリソースは、ディレクトリ階層に基づいて配置されます。
ステージングが終了したら、jar
コマンドを使用してディレクトリ全体を WAR ファイルにまとめます。WAR ファイルは、それだけでデプロイすることも、他の Web アプリケーション、EJB コンポーネント、WebLogic Server コンポーネントといった他のアプリケーション コンポーネントと一緒にエンタープライズ アプリケーションの一部としてデプロイする (推奨) こともできます。
JSP ページと HTTP サーブレットは、WebLogic Server で使用可能なすべてのサービスと API にアクセスできます。これらのサービスには、EJB、Java Database Connectivity (JDBC) を介したデータベース接続、JavaMessaging Service (JMS)、XML などがあります。
このディレクトリ (Web アプリケーションのドキュメント ルート) には、HTML ファイルなどの静的ファイルと JSP ファイルを配置します。WebLogic Server のデフォルトでは、このディレクトリの名前は DefaultWebApp
で user_domains/mydomain/applications
の下に置かれます。
(Web アプリケーションをデフォルトの Web アプリケーションにするには、weblogic.xml
デプロイメント記述子ファイルで context-root
を "/
" に設定する必要があります。)
DefaultWebApp/WEB-INF/web.xml
ファイルは、Web アプリケーションをコンフィグレーションする Web アプリケーション デプロイメント記述子です。
DefaultWebApp/WEB-INF/weblogic.xml
ファイルは、web.xml
ファイルで指定されたリソースが WebLogic Server のどのリソースにどのようにマップされるのかを定義する WebLogic 固有のデプロイメント記述子ファイルです。またこのファイルは、JSP および HTTP セッション属性を定義するために使用されます。
DefaultWebApp/WEB-INF/classes
ディレクトリには、HTTP サーブレット クラスやユーティリティ クラスなどのサーバサイドのクラスが格納されます。
DefaultWebApp/WEB-INF/lib
ディレクトリには、JSP タグ ライブラリに加え、Web アプリケーションで使用される JAR ファイルが格納されます。
WEB-INF
ディレクトリは、アプリケーションのパブリック ドキュメント ツリーの一部ではありません。WEB-INF
ディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INF
ディレクトリのコンテンツは、ServletContext
に対する getResource
および getResourceAsStream()
メソッド呼び出しを使用するサーブレット コードや、RequestDispatcher での include/forward から認識できます。したがって、サーブレット コードから、Web クライアントに直接エクスポーズされるべきでないアプリケーション固有のコンフィグレーション情報へのアクセスを必要とする場合、アプリケーション開発者はこれをこのディレクトリの下に置くことができます。
要求は、大文字と小文字を区別してリソース マッピングと照合されるので、たとえば「/WEB-INF/foo
」、「/WEb-iNf/foo
」に対するクライアント要求の結果として、/WEB-INF
の下に置かれた Web アプリケーションのコンテンツや、何らかの形のそのディレクトリ リストが返されることはありません。
ここでは、分割開発ディレクトリ構造を使用し、エンタープライズ アプリケーションの一部として Web アプリケーションを作成する際の手順を示します。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「分割開発ディレクトリ環境の作成」、「分割開発ディレクトリでのアプリケーションのビルド」、および「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
WebLogic Server に付属の開発者向けツールを使用して Web アプリケーションを作成およびコンフィグレーションできます。「Web アプリケーション開発者向けツール」を参照してください。
ルート EAR ファイルのディレクトリを作成します。
\src\myEAR\
次のように環境を設定します。
Windows の場合は、server\bin\
ディレクトリにある setWLSEnv.cmd
コマンドを実行します。server は WebLogic Server がインストールされている最上位ディレクトリです。
UNIX の場合は、server/bin/
ディレクトリにある setWLSEnv.sh
コマンドを実行します。server は WebLogic Server がインストールされている最上位ディレクトリで、domain はドメインの名前です。
次のように、\src\myEAR\
ディレクトリにエンタープライズ アプリケーションをパッケージ化します。
エンタープライズ アプリケーション記述子 (application.xml
および weblogic-application.xml
) を META-INF\
ディレクトリに入れます。『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
必要に応じてデプロイメント記述子を編集し、エンタープライズ アプリケーションの動作を微調整します。「Web アプリケーション開発者向けツール」を参照してください。
次の場所にエンタープライズ アプリケーションの .jar
ファイルを置きます。
\src\myEAR\APP-INF\lib\
EAR ファイルのルートに Web アプリケーションのディレクトリを作成します。
\src\myEAR\myWebApp
次のように、\src\myEAR\myWebApp\
ディレクトリに Web アプリケーションをパッケージ化します。
Web アプリケーション記述子 (web.xml
および weblogic.xml
) を \src\myEAR\myWebApp\WEB-INF\
ディレクトリに入れます。「weblogic.xml デプロイメント記述子の要素」を参照してください。
必要に応じてデプロイメント記述子を編集し、エンタープライズ アプリケーションの動作を微調整します。「Web アプリケーション開発者向けツール」を参照してください。
すべての HTML ファイル、JSP、イメージ、その他 Web アプリケーションによって参照されるあらゆるファイルを、Web アプリケーションのルートに置きます。
\src\myEAR\myWebApp\images\myimage.jpg \src\myEAR\myWebApp\login.jsp \src\myEAR\myWebApp\index.html
次の場所に、Web アプリケーションの Java ソース ファイル (サーブレット、タグ ライブラリ、サーブレットまたはタグ ライブラリによって参照されるその他のクラス) を置きます。
\src\myEAR\myWebApp\WEB-INF\src\
ディレクトリ構造を設定したら、weblogic.BuildXMLGen
ユーティリティを使用して build.xml
ファイルを作成します。
wlcompile
Ant タスクを実行して javac
コンパイラを呼び出します。これにより、Web アプリケーションの Java コンポーネントが出力ディレクトリ /build/myEAR/WEB-INF/classes
にコンパイルされます。
wlappc
Ant タスクを実行して appc
コンパイラを起動します。これにより、デプロイメントのための JSP およびコンテナ固有の EJB クラスがすべてコンパイルされます。
wldeploy
Ant タスクを実行して、Web アプリケーションをアーカイブされた、または展開された EAR の一部として、WebLogic Server にデプロイします。
プロダクション環境 (開発環境でなく) の場合は、wlpackage
Ant タスクを実行して Web アプリケーションをアーカイブされた、または展開された EAR の一部としてパッケージ化します。
注意 : wlpackage Ant タスクは、Java ソース ファイルのコンパイルされたバージョンをビルド ディレクトリ (たとえば /build/myEAR/myWebApp/classes ) に格納します。 |
クライアントが Web アプリケーションにアクセスするために使用する URL は、次のパターンで作成します。
http://hoststring/ContextPath/servletPath/pathInfo
各値の説明は次のとおりです。
hoststring
は、hostname:portNumber
または仮想ホストにマップされるホスト名。
ContextPath
は、Web アプリケーションの名前。
servletPath
は、servletPath
にマップされるサーブレット。
pathInfo
は、URL の残りの部分 (通常はファイル名)。
仮想ホスティングを使用している場合、URL の hoststring の部分を仮想ホスト名に置き換えることができます。
WebLogic Server では、Web アプリケーション用の仮想ホストをコンフィグレーションする 2 つの方法をサポートしています。
以下は、チャネル ベースの仮想ホストのコンフィグレーション方法のサンプルです。
<VirtualHost Name="channel1vh" NetworkAccessPoint="Channel1" Targets="myserver"/> <VirtualHost Name="channel2vh" NetworkAccessPoint="Channel2" Targets="myserver"/>
Channel1
および Channel2
は、config.xml
ファイル内でコンフィグレーションされる NetworkAccessPoint
の名前です。NetworkAccessPoint
は、仮想ホストが HTTP リクエストを処理する専用のサーバ チャネル名を表します。特定の HTTP リクエストの NetworkAccessPoint
がどの仮想ホストの NetworkAccessPoint
とも一致しない場合は、正しい仮想ホストを解決するため、受信 HOST ヘッダは VirtualHostNames
と比較されます。受信した HTTP リクエストが仮想ホストと一致しない場合、それはデフォルトの Web サーバによって処理されます。
以下は、ホスト ベースの仮想ホストのコンフィグレーション方法のサンプルです。
<VirtualHost Name="cokevh"
Targets="myserver" VirtualHostNames="coke"/>
<VirtualHost Name="pepsivh" Targets="myserver" VirtualHostNames="pepsi"/>
Web アプリケーション コンポーネントは、WebLogic Administration Console を使用してサーバおよび仮想ホストに割り当てることができます。
以前のバージョンの WebLogic Server から移行している場合は、config.xml
ファイルの targets 属性で、すべての Web アプリケーションの対象を指定する必要があります。targets 属性は、仮想ホスト属性に取って代わっており、仮想ホストは同一ドメイン内でサーバまたはクラスタと同じ名前を持つことはできません。以下は、Web アプリケーションを仮想ホストに割り当てる方法の例です。
<AppDeployment name=
"test-app" Sourcepath="/myapps/test-app.ear">
<SubDeployment Name="test-webapp1.war" Targets="virutalhost-1"/>
<SubDeployment Name="test-webapp2.war" Targets="virtualhost-2"/>
...
</AppDeployment>
サーブレット、コンテキスト リスナ、およびフィルタは、次の順序でロードおよび破棄されます。
ロードの順序 :
コンテキスト リスナ
フィルタ
サーブレット
破棄の順序 :
サーブレット
フィルタ
コンテキスト リスナ
サーブレットおよびフィルタは、web.xml
ファイルでの定義順と同じ順序でロードされ、その逆の順序でアンロードされます。コンテキスト リスナは、次の順序でロードされます。
web.xml
ファイル内のすべてのコンテキスト リスナ (ファイルでの指定順)
タグ ライブラリ記述子が含まれるパッケージ化された JAR ファイル
WEB-INF
ディレクトリ内のタグ ライブラリ記述子
Java EE Web アプリケーション ライブラリは、デプロイメント時に Java EE アプリケーション コンテナに登録されるスタンドアロン Web アプリケーション モジュールです。WebLogic Server を使用すると、複数の Web アプリケーションで簡単に単一の Web アプリケーション モジュールまたはモジュールの集合を共有できます。
Web アプリケーションは、1 つ以上の Web アプリケーション ライブラリを参照できますが、その他の種類のライブラリ (EJB、EAR ファイル、プレーン JAR ファイル) は参照できません。Web アプリケーション ライブラリは、ライブラリとしてデプロイされる Web アプリケーション モジュールです。これらは、weblogic-application.xml
ファイル内のアプリケーション ライブラリの参照に使用されるものと同じ構文を用いて weblogic.xml
ファイルから参照されます。ただし、<context-root>
要素は無視されます。
デプロイメント時に、参照された各ライブラリのクラスパスが、Web アプリケーションのクラスパスに付加されます。したがって、すべてのリソースおよびクラスに対する検索は、まず元の Web アプリケーション内で行われ、次に参照されたライブラリ内で行われます。
デプロイメント ツール appc、wlcompile、および BuildXMLGen は、アプリケーション レベルでライブラリをサポートするのと同じように、Web アプリケーション レベルでライブラリをサポートします。共有 Java EE ライブラリとそれらのデプロイメントの詳細については、『Oracle Fusion Middleware Oracle WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの作成」を参照してください。