2 Webアプリケーションの作成と構成
この章の内容は以下のとおりです。
WebLogic WebアプリケーションとJava EE
Java EEプログラミング・モデルでは、メタデータ・アノテーションを採用しています。これにより、コンテナ内でのアプリケーション・コンポーネントの動作や依存関係インジェクションのリクエスト方法などをJavaクラス自体の中で指定でき、アプリケーションの開発プロセスを簡略化できます。アノテーションは、エンタープライズ・アプリケーションの以前のバージョン(Java EE 1.4以前)で必要とされたデプロイメント記述子に代わるものです。
Java EEアノテーションの使用により、標準のapplication.xml
およびweb.xml
デプロイメント記述子は省略可能になりました。Java EEプログラミング・モデルでは、EJB、サーブレット、Webアプリケーション、JSPなどのWebコンテナに対してJDKアノテーション機能を採用しています。「Webコンポーネント用のWebLogicアノテーション」およびhttp://docs.oracle.com/javaee/8/api/
を参照してください。Java EE Webアプリケーション・テクノロジの詳細は、http://www.oracle.com/technetwork/java/javaee/tech/index.html
を参照してください。
ただし、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
ディレクトリ内には、コンテナによってクライアントへ直接提供されるファイルはありません。ただし、WEB-INF
ディレクトリのコンテンツは、ServletContext
に対するgetResource
およびgetResourceAsStream()
メソッド呼出しを使用するサーブレット・コードや、RequestDispatcherでのinclude/forwardから認識できます。したがって、サーブレット・コードから、Webクライアントに直接公開されるべきでないアプリケーション固有の構成情報へのアクセスを必要とする場合、アプリケーション開発者はこれをこのディレクトリの下に置くことができます。
リクエストは、大文字と小文字を区別してリソース・マッピングと照合されるので、たとえば「/WEB-INF/foo」
、「/WEb-iNf/foo」
に対するクライアント・リクエストの結果として、/WEB-INF
の下に置かれたWebアプリケーションのコンテンツや、なんらかの形のそのディレクトリ・リストが返されることはありません。
Webアプリケーションの作成と構成の主なステップ
分割開発ディレクトリ構造を使用し、エンタープライズ・アプリケーションの一部としてWebアプリケーションを作成する方法を学習します。
『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の作成に関する項,、分割開発ディレクトリでのアプリケーションのビルドに関する項、および分割開発ディレクトリからのデプロイメントとパッケージ化に関する項を参照してください。
WebLogic Serverに付属の開発者向けツールを使用してWebアプリケーションを作成および構成できます。「Webアプリケーション開発者向けツール」を参照してください
ステップ1: エンタープライズ・アプリケーション・ラッパーの作成
-
ルートEARファイルのディレクトリを作成します。
\src\myEAR\
-
次のように環境を設定します。
-
Windowsでは、
WL_HOME
\server\bin\
ディレクトリにあるsetWLSEnv.cmd
コマンドを実行します。WL_HOME
は、WebLogic Serverがインストールされている最上位ディレクトリです。 -
UNIXでは、
WL_HOME
/server/bin/
ディレクトリにあるsetWLSEnv.sh
コマンドを実行します。WL_HOME
は、WebLogic Serverがインストールされている最上位ディレクトリです。
ノート:
UNIXオペレーティング・システムでは、
setWLSEnv.sh
コマンドはすべてのコマンド・シェルで環境変数を設定しません。Kornシェルまたはbashシェルを使用してこのコマンドを実行することをお薦めします。 -
-
次のように、
\src\myEAR\
ディレクトリにエンタープライズ・アプリケーションをパッケージ化します。-
エンタープライズ・アプリケーション記述子(
application.xml
およびweblogic-application.xml
)をMETA-INF\
ディレクトリに入れます。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子に関する項を参照してください。 -
必要に応じてデプロイメント記述子を編集し、エンタープライズ・アプリケーションの動作を微調整します。「Webアプリケーション開発者向けツール」を参照してください。
-
次の場所にエンタープライズ・アプリケーションの
.jar
ファイルを置きます。\src\myEAR\APP-INF\lib\
-
ステップ2: Webアプリケーションの作成
-
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\
-
クライアントによるWebアプリケーションへのアクセス方法の構成
特定のパターンを使用して、クライアントがWebアプリケーションにアクセスするために使用するURLを作成します。
http://hoststring/ContextPath/servletPath/pathInfo
ここで
-
hoststring
は、hostname:portNumber
または仮想ホストにマップされるホスト名。 -
ContextPath
は、Webアプリケーションの名前。 -
servletPath
は、servletPath
にマップされるサーブレット。 -
pathInfo
は、URLの残りの部分(通常はファイル名)。
仮想ホスティングを使用している場合、URLのhoststringの部分を仮想ホスト名に置き換えることができます。
Webアプリケーション用の仮想ホストの構成
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サーバーによって処理されます。
仮想ホストへのWebアプリケーションの割当て
Webアプリケーション・コンポーネントは、WebLogic Server管理コンソールを使用してサーバーおよび仮想ホストに割り当てることができます。
以前のバージョンの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アプリケーション・ライブラリは、デプロイメント時に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 WebLogic Serverアプリケーションの開発』の「共有Java EEライブラリおよびオプション・パッケージの作成」を参照してください。
WebアプリケーションのGZIP圧縮の有効化
WebLogic Server Webコンテナは、HTTP/1.1の一部であるHTTP Content-Encoding GZIP圧縮をサポートします。GZIP圧縮では、Webブラウザがダウンロードする必要のあるデータのサイズを減らし、ネットワーク帯域幅を改善します。
Content-EncodingおよびGZIP圧縮の全般的な情報は、Hypertext Transfer Protocol HTTP/1.1仕様を参照してください。
Content-Encoding GZIP圧縮はドメイン・レベルまたはWebアプリケーション・レベルで有効化および構成できます。
GZIP圧縮サポートのドメイン全体の値を設定するには、WLSTを使用して、WebAppContainerMBean
にあるGzipCompressionMBean
の次の属性を構成します。
表2-1 ドメイン・レベルGZIP圧縮属性
属性 | 説明 | デフォルト値 |
---|---|---|
|
ドメイン内のすべてのWebアプリケーションに対してGZIP圧縮を有効にします。 |
|
|
Webアプリケーションで圧縮をトリガーする最小ファイル・サイズを指定します。 この属性により、圧縮しても効果が小さく、不要なCPUを消費するサイズの小さいリソースを無視できます。 |
|
|
圧縮に含めるコンテンツのタイプを指定します。 |
|
特定のWebアプリケーションでGZIP圧縮を構成するには、weblogic.xmlデプロイメント記述子のcontainer-descriptor要素にあるgzip-compression要素を使用します。「gzip-compression」を参照してください。
アプリケーション・レベルの値はドメイン・レベルの値をオーバーライドします。そのため、weblogic.xml
に設定されるすべてのgzip-compression
値は、GzipCompressionMBean
に設定されているドメイン全体に渡る値またはデフォルト値よりも優先します。
WebLogic Serverは、次のオーバーライド階層に基づいて、使用するGZIP圧縮属性値を決定します。
-
個々のWebアプリケーションの
weblogic.xml
ファイルまたはドメイン全体のGzipCompressionMBean
でGZIP圧縮を構成しない場合には、ドメインのデフォルト値が使用されます。 -
ドメイン全体の
GzipCompressionMBean
でGZIP圧縮を構成する場合には、MBean値がデフォルト値をオーバーライドします。GzipCompressionMBeanvalue
が使用されます。 -
個々のWebアプリケーションの
weblogic.xml
ファイルでGZIP圧縮を構成した場合、weblogic.xml
ファイルはGzipCompressionMBean
値およびデフォルト値をオーバーライドします。Webアプリケーションのweblogic.xml
値が使用されます。
HTTPDebugLoggerdebug
フラグを有効にすることで、使用されているCPU、元のコンテンツ長、GZIPコンテンツ長および圧縮率などの圧縮統計を追跡できます。これにより、既存のサーバー・ログ・ファイルでこれらの統計に関する情報を追跡できます。HTTPDebugLogger
が有効になっていない場合、これらの統計は追跡されません。enableHTTPDebugLogger
を使用するには、サーバー起動スクリプトのJAVA_OPTIONS
で-Dweblogic.debug.DebugHttp=true
を設定します。