![]() ![]() ![]() ![]() |
以下の節では、Web アプリケーション リソースを作成およびコンフィグレーションする方法について説明します。
Java Platform, Enterprise Edition (Java EE) バージョン 5.0 プログラミング モデルの重要な点は、メタデータ アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション コンポーネントの動作、依存性注入の要求方法などを Java クラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ アプリケーションの以前のバージョン (J2EE 1.4 以前) で必要だったデプロイメント記述子に代わるものです。
Java EE アノテーションの使用により、標準の application.xml
および web.xml
デプロイメント記述子は省略可能になりました。Java EE プログラミング モデルでは、EJB、サーブレット、Web アプリケーション、JSP などの Web コンテナに対して JDK 5.0 アノテーション機能を採用しています。「Web コンポーネント用の WebLogic アノテーション」を参照してください。
ただし、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 アプリケーションに属するすべてのサーブレット、クラス、静的ファイル、およびその他のリソースは、ディレクトリ階層に基づいて配置されます。
DefaultWebApp/
DefaultWebApp
で、user_domains/mydomain/applications の下に置かれます。
web.xml
ファイルで指定されたリソースが WebLogic Server のどのリソースにどのようにマップされるのかを定義します。またこのファイルは、JSP および HTTP セッション属性を定義するために使用されます。
ステージングが終了したら、jar コマンドを使用してディレクトリ全体を WAR ファイルにまとめます。WAR ファイルは、それだけでデプロイすることも、他の Web アプリケーション、EJB コンポーネント、WebLogic Server コンポーネントといった他のアプリケーション コンポーネントと一緒にエンタープライズ アプリケーションの一部としてデプロイする (推奨) こともできます。
JSP ページと HTTP サーブレットは、WebLogic Server で使用可能なすべてのサービスと API にアクセスできます。これらのサービスには、EJB、Java Database Connectivity (JDBC) を介したデータベース接続、JavaMessaging Service (JMS)、XML などがあります。
WEB-INF
ディレクトリは、アプリケーションのパブリック ドキュメント ツリーの一部ではありません。WEB-INF
ディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INF
ディレクトリのコンテンツは、ServletContext に対する getResource および getResourceAsStream() メソッド呼び出しを使用するサーブレット コードから認識できる、あるいは RequestDispatcher を使用してインクルード/転送を行います。したがって、サーブレット コードから、Web クライアントに直接エクスポーズされるべきでないアプリケーション固有のコンフィグレーション情報へのアクセスを必要とする場合、アプリケーション開発者はこれをこのディレクトリの下に置くことができます。
要求は、大文字と小文字を区別してリソース マッピングと照合されるので、たとえば「/WEB-INF/foo」、「/WEb-iNf/foo」に対するクライアント要求の結果として、/WEB-INF の下に置かれた Web アプリケーションのコンテンツや、何らかの形のそのディレクトリ リストが返されることはありません。
次に Web アプリケーションのディレクトリ構造の例を示します。ここでは、myWebApp/ がステージング ディレクトリです。
myWebApp/
WEB-INF/
web.xml
weblogic.xml
lib/
MyLib.jar
classes/
MyPackage/
MyServlet.class
index.html
index.jsp
ここでは、分割開発ディレクトリ構造を使用し、エンタープライズ アプリケーションの一部として Web アプリケーションを作成する際の手順を示します。『WebLogic Server アプリケーションの開発』の「分割開発ディレクトリ環境の作成」、「分割開発ディレクトリでのアプリケーションのビルド」、および「分割開発ディレクトリからのデプロイメントとパッケージ化」を参照してください。
WebLogic Server に付属の開発者向けツールを使用して Web アプリケーションを作成およびコンフィグレーションできます。「Web アプリケーション開発者向けツール」を参照してください。
application.xml
および weblogic-application.xml
) を META-INF\ ディレクトリに入れます。『WebLogic Server アプリケーションの開発』の「エンタープライズ アプリケーションのデプロイメント記述子の要素」を参照してください。
\src\myEAR\myWebApp\images\myimage.jpg
\src\myEAR\myWebApp\index.html
ディレクトリ構造を設定したら、weblogic.BuildXMLGen ユーティリティを使用して build.xml ファイルを作成します。
注意 : | wlpackage Ant タスクは、Java ソース ファイルのコンパイルされたバージョンをビルド ディレクトリ (たとえば /build/myEAR/myWebApp/classes) に格納します。 |
クライアントが Web アプリケーションにアクセスするために使用する URL は、次のパターンで作成します。
http://hoststring
/ContextPath
/servletPath
/pathInfo
hoststring
ContextPath
servletPath
pathInfo
仮想ホスティングを使用している場合、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
ファイルでの定義順と同じ順序でロードされ、その逆の順序でアンロードされます。コンテキスト リスナは、次の順序でロードされます。
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 ライブラリとそのデプロイメントの詳細については、『WebLogic Server アプリケーションの開発』の「共有 Java EE ライブラリおよびオプション パッケージの作成」を参照してください。
![]() ![]() ![]() |