1. Oracle WebLogic Server Webアプリケーション、サーブレット、JSPの開発
  2. Webアプリケーションの作成と構成

2 Webアプリケーションの作成と構成

WebLogic 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/7/api/を参照してください。Java EE 7 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アプリケーションのディレクトリ構造の例を示します。ここでは、myWebApp/がステージング・ディレクトリです。

例2-1 Webアプリケーションのディレクトリ構造

myWebApp/
  WEB-INF/
    web.xml
    weblogic.xml
    lib/
      MyLib.jar
    classes/
      MyPackage/
        MyServlet.class
  index.html
  index.jsp

Webアプリケーションの作成と構成の主なステップ

分割開発ディレクトリ構造を使用し、エンタープライズ・アプリケーションの一部としてWebアプリケーションを作成する方法を学習します。

『Oracle WebLogic Serverアプリケーションの開発』の分割開発ディレクトリ環境の作成に関する項,、分割開発ディレクトリでのアプリケーションのビルドに関する項、および分割開発ディレクトリからのデプロイメントとパッケージ化に関する項を参照してください。

WebLogic Serverに付属の開発者向けツールを使用してWebアプリケーションを作成および構成できます。「Webアプリケーション開発者向けツール」を参照してください

ステップ1: エンタープライズ・アプリケーション・ラッパーの作成

  1. ルートEARファイルのディレクトリを作成します。

    \src\myEAR\

  2. 次のように環境を設定します。

    • 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シェルを使用してこのコマンドを実行することをお薦めします。

  3. 次のように、\src\myEAR\ディレクトリにエンタープライズ・アプリケーションをパッケージ化します。

    1. エンタープライズ・アプリケーション記述子(application.xmlおよびweblogic-application.xml)をMETA-INF\ディレクトリに入れます。詳細は、『Oracle WebLogic Serverアプリケーションの開発』のエンタープライズ・アプリケーションのデプロイメント記述子に関する項を参照してください。

    2. 必要に応じてデプロイメント記述子を編集し、エンタープライズ・アプリケーションの動作を微調整します。「Webアプリケーション開発者向けツール」を参照してください。

    3. 次の場所にエンタープライズ・アプリケーションの.jarファイルを置きます。 

      \src\myEAR\APP-INF\lib\

ステップ2: Webアプリケーションの作成

  1. EARファイルのルートにWebアプリケーションのディレクトリを作成します。

    \src\myEAR\myWebApp

  2. 次のように、\src\myEAR\myWebApp\ディレクトリにWebアプリケーションをパッケージ化します。

    1. Webアプリケーション記述子(web.xmlおよびweblogic.xml)を\src\myEAR\myWebApp\WEB-INF\ディレクトリに入れます。「weblogic.xmlデプロイメント記述子の要素」を参照してください。

    2. 必要に応じてデプロイメント記述子を編集し、エンタープライズ・アプリケーションの動作を微調整します。「Webアプリケーション開発者向けツール」を参照してください。

    3. すべてのHTMLファイル、JSP、イメージ、その他Webアプリケーションによって参照されるすべてのファイルを、Webアプリケーションのルートに置きます。 

      \src\myEAR\myWebApp\images\myimage.jpg
\src\myEAR\myWebApp\login.jsp
\src\myEAR\myWebApp\index.html

    4. 次の場所に、WebアプリケーションのJavaソース・ファイル(サーブレット、タグ・ライブラリ、サーブレットまたはタグ・ライブラリによって参照されるその他のクラス)を置きます。

      \src\myEAR\myWebApp\WEB-INF\src\

ステップ3: build.xmlファイルの作成

ディレクトリ構造を設定したら、weblogic.BuildXMLGenユーティリティを使用してbuild.xmlファイルを作成します。

ステップ4: 分割開発ディレクトリ構造におけるAntタスクの実行

  1. wlcompile Antタスクを実行してjavacコンパイラを呼び出します。これにより、WebアプリケーションのJavaコンポーネントが出力ディレクトリ/build/myEAR/WEB-INF/classesにコンパイルされます。
  2. wlappc Antタスクを実行してappcコンパイラを起動します。これにより、デプロイメントのためのJSPおよびコンテナ固有のEJBクラスがすべてコンパイルされます。
  3. wldeploy Antタスクを実行して、Webアプリケーションをアーカイブされた、または展開されたEARの一部として、WebLogic Serverにデプロイします。
  4. 本番環境(開発環境でなく)の場合は、wlpackage Antタスクを実行してWebアプリケーションをアーカイブされた、または展開されたEARの一部としてパッケージ化します。

    ノート:

    wlpackage Antタスクは、構築ディレクトリにコンパイルされたバージョンのJavaソース・ファイルを配置します。たとえば: /build/myEAR/myWebApp/classes

クライアントによる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サーバーによって処理されます。

ホスト・ベースの仮想ホストの構成

以下は、ホスト・ベースの仮想ホストの構成方法のサンプルです。

<VirtualHost Name="cokevh" Targets="myserver" VirtualHostNames="coke"/> 
<VirtualHost Name="pepsivh" Targets="myserver" VirtualHostNames="pepsi"/>

仮想ホストへの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>

サーブレット、コンテキスト・リスナー、およびフィルタのロード

サーブレット、コンテキスト・リスナーおよびフィルタは、特定の順序でロードおよび破棄されます。

ロードの順序:

  1. コンテキスト・リスナー

  2. フィルタ

  3. サーブレット

破棄の順序:

  1. サーブレット

  2. フィルタ

  3. コンテキスト・リスナー

サーブレットおよびフィルタは、web.xmlファイルでの定義順と同じ順序でロードされ、その逆の順序でアンロードされます。コンテキスト・リスナーは、次の順序でロードされます。

  1. web.xmlファイル内のすべてのコンテキスト・リスナー(ファイルでの指定順)

  2. タグ・ライブラリ記述子が含まれるパッケージ化されたJARファイル

  3. 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圧縮属性

属性 説明 デフォルト値

GzipCompressionEnabled

ドメイン内のすべてのWebアプリケーションに対してGZIP圧縮を有効にします。

false

GzipCompressionMinCompressionContentLength

Webアプリケーションで圧縮をトリガーする最小ファイル・サイズを指定します。

この属性により、圧縮しても効果が小さく、不要なCPUを消費するサイズの小さいリソースを無視できます。

2048

GzipCompressionContentType

圧縮に含めるコンテンツのタイプを指定します。

"text/html、text/xml、text/plain"

特定の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を設定します。