Oracle® Fusion Middleware Oracle WebLogic Server 10.3.6 Webアプリケーション、サーブレット、JSPの開発 11gリリース1 (10.3.6) B60993-07 |
|
![]() 前 |
![]() 次 |
この章では、WebLogic Server 10.3.6でWebアプリケーション・リソースを作成および構成する方法について説明します。
この章の内容は以下のとおりです。
Java Platform, Enterprise Edition (Java EE)バージョン5.0プログラミング・モデルの重要な点は、メタデータ・アノテーションが導入されたことです。アノテーションを使用すると、コンテナ内でのアプリケーション・コンポーネントの動作、依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。詳細は、http://www.oracle.com/technetwork/java/javaee/documentation/index.html
を参照してください。
Java EEアノテーションの使用により、標準のapplication.xml
およびweb.xml
デプロイメント記述子は省略可能になりました。Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDK 5.0アノテーション機能を採用しています。第8章「Webコンポーネント用のWebLogicアノテーション」およびhttp://download.oracle.com/javaee/5/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-INF
ディレクトリは、アプリケーションのパブリック・ドキュメント・ツリーの一部ではありません。WEB-INF
ディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INF
ディレクトリのコンテンツは、ServletContext
に対するgetResource
およびgetResourceAsStream()
メソッド呼出しを使用するサーブレット・コードや、RequestDispatcherでのinclude/forwardから認識できます。したがって、サーブレット・コードから、Webクライアントに直接公開されるべきでないアプリケーション固有の構成情報へのアクセスを必要とする場合、アプリケーション開発者はこれをこのディレクトリの下に置くことができます。
リクエストは、大文字と小文字を区別してリソース・マッピングと照合されるので、たとえば「/WEB-INF/foo」
、「/WEb-iNf/foo」
に対するクライアント・リクエストの結果として、/WEB-INF
の下に置かれたWebアプリケーションのコンテンツや、なんらかの形のそのディレクトリ・リストが返されることはありません。
分割開発ディレクトリ構造を使用し、エンタープライズ・アプリケーションの一部としてWebアプリケーションを作成する手順を次に示します。『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 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\
ディレクトリに入れます。付録B「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
と比較されます。受信したリクエストが仮想ホストと一致しない場合、それはデフォルトのWebサーバーによって処理されます。
以下は、ホスト・ベースの仮想ホストの構成方法のサンプルです。
<VirtualHost Name="cokevh"
Targets="myserver" VirtualHostNames="coke"/>
<VirtualHost Name="pepsivh" Targets="myserver" VirtualHostNames="pepsi"/>
Webアプリケーション・コンポーネントは、WebLogic 管理コンソールを使用してサーバーおよび仮想ホストに割り当てることができます。
以前のバージョンの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アプリケーション・レベルでライブラリをサポートします。共有J2EEライブラリとそのデプロイメントの詳細は、『Oracle WebLogic Serverアプリケーションの開発』の共有J2EEライブラリおよびオプション・パッケージの作成に関する項を参照してください。