2 サーブレットのデプロイおよび起動

サーブレットをデプロイし、クライアントからサーブレットにリクエストが届くと、OC4Jによりサーブレットが起動されます。クライアント・リクエストは、WebブラウザまたはJavaクライアント・アプリケーションから、リクエスト転送メカニズムまたはリクエスト・インクルード・メカニズムを使用してアプリケーションの別のサーブレットから、あるいはサーバーのリモート・オブジェクトから送信されます。

サーブレットは、サーブレットの構成およびデプロイ方法に基づくURLマッピングを通じてリクエストされます。その際には、標準web.xmlファイルで指定されるURLの一部（サーブレット・パス）と、デプロイ時に決定されるか標準application.xmlファイルに基づく（デプロイ方法によって異なります）URLの別の部分（コンテキスト・パス）が使用されます。

次の各項で、サーブレットのデプロイと起動について説明します。

初期の注意事項およびOC4Jの使用例

OC4Jでのサーブレットのデプロイおよび起動について説明する前に、いくつかの初期注意事項と使用例をまとめます。

OC4J管理の概要

OC4Jは、J2EE環境におけるアプリケーションのデプロイおよび管理についての次の標準をサポートしています。

Java Management Extensions（JMX）1.2仕様は、J2EE環境でサービスやアプリケーションなどのリソースを管理する標準インタフェースの作成を可能にします。JMXのOC4J実装は、OC4Jサーバーやそこで動作するアプリケーションの完全な管理のために使用できるユーザー・インタフェースを提供します。
Java 2 Platform, Enterprise Edition Management Specification（JSR-77）は、J2EE環境のアプリケーションの実行時管理のためにMBean（Managed Bean）と呼ばれるオブジェクトを作成することを可能にします。OC4Jでは、Oracle Enterprise Manager 10gのシステムMBeanブラウザを使用してMBeanに直接アクセスできますが、そのプロパティの多くは、Enterprise Managerの他の機能によってユーザーによりわかりやすい方法で公開されます。
Java 2 Enterprise Edition Deployment API Specification（JSR-88）は、J2EE互換環境でJ2EEアプリケーションとモジュールを構成およびデプロイするための標準APIを定義します。OC4J実装には、コンポーネントをOC4Jにデプロイするために必要なOC4J固有の構成データを含むデプロイ・プランを作成または編集する機能が含まれています。

デプロイ・プランは、アーカイブをOC4Jにデプロイするために必要なすべての構成データのクライアント・サイドの集約です。デプロイ・プラン・エディタを使用すると、デプロイ・プランをデプロイ中に編集できます。

OC4Jデプロイ・プラン・エディタおよびシステムMBeanブラウザは、Application Server Controlと呼ばれるOracle Enterprise Manager 10g Application Server Controlを通じて公開されます。このためのユーザー・インタフェースは、Application Server Controlコンソールです。さらに、Application Server Controlコンソールの他のページを通じて公開されている、MBeanプロパティ（Webモジュール関連の主要プロパティを含む）に対応する多くのパラメータが役立ちます。

一般に、可能であれば、OC4J MBeanまたはOC4J固有のXML構成ファイルを直接操作しないでください。XMLファイルは、Application Server Controlコンソールを使用すると、OC4Jによって自動的に更新されます。このため、付録B「Webモジュールの構成ファイル」に参照情報がありますが、OC4J固有のXML構成については、このマニュアルには比較的少数の例しか含まれていません。ただし、デプロイの状況によっては、Application Server Controlコンソールを通じてorion-web.xmlプロパティが公開されない可能性もあります。このような状況では、XMLファイルを直接操作する以外に手段がない場合があります。

OC4Jのデプロイ、構成および管理に関する一般的な情報については、『Oracle Containers for J2EEデプロイメント・ガイド』および『Oracle Containers for J2EE構成および管理ガイド』を参照してください。Application Server Controlの詳細は、『Oracle Application Server管理者ガイド』で示されている管理ツールの概要を参照することもできます。

スタンドアロンのOC4JとOracle Application Server環境のOC4J

開発時は、一般に、Oracle Application Server環境の外でOC4Jを単独で使用します。これをスタンドアロンOC4Jと呼びます（管理されないOC4Jと呼ぶこともあります）。この使用例では、OC4Jは、独自のWebリスナーを使用することができ、どの外部Oracle Application Serverプロセスによっても管理されません。

一方、完全なOracle Application Server環境（管理されたOC4Jと呼ばれることもあります）では、WebリスナーとしてOracle HTTP Serverが使用され、環境を管理するためにOracle Process Manager and Notification Server（OPMN）が使用されます。

Oracle Application Server環境とスタンドアロン環境に関する追加情報やOC4JによるOracle HTTP ServerおよびOPMNの使用に関する追加情報は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。

Oracle HTTP Serverおよび関連mod_oc4jモジュールに関する一般的な情報は、『Oracle HTTP Server管理者ガイド』を参照してください。（Oracle HTTP ServerからOC4Jサーブレット・コンテナへの接続にはこのモジュールが使用されます。） OPMNに関する一般的な情報は、『Oracle Process Manager and Notification Server管理者ガイド』を参照してください。

OC4JおよびOracle Application Server管理ツール

Oracle Application Server環境またはスタンドアロン環境のいずれでも、Application Server Control（概要は、「OC4J管理の概要」を参照）を使用してOC4JでJ2EEアプリケーションをバインド、構成および管理できます。これは、一般に、アプリケーションを管理するための推奨される方法ですので、このマニュアルでもこの方法を重視しています。アプリケーションは、OC4Jホームページからアクセスできる「アプリケーション」タブにあるApplication Server Controlコンソールの「デプロイ」機能を使用してデプロイすることができます。Webモジュールを構成するためのApplication Server Controlコンソールのページについては、付録A「Webモジュールの管理」で説明します。

スタンドアロンOC4Jでは、OC4Jのadmin_client.jarコマンドライン・ツールを使用してJ2EEアプリケーションをデプロイおよびバインドすることができます。

また、Oracle JDeveloperツールを使用してアプリケーションを開発する場合は、このツールを使用してアプリケーションをデプロイおよびバインドすることもできます。

場合により、特に開発時に、OC4J固有のXMLファイルを直接操作してOC4Jアプリケーションの各部を構成する必要があることもあります。このため、OC4Jのドキュメント・セットにはこれらのファイルに関する参照ドキュメントが含まれています。OC4J固有Webモジュール構成ファイルのglobal-web-application.xml（グローバル）およびorion-web.xml（アプリケーション・レベル）の要素と属性については、付録B「Webモジュールの構成ファイル」で説明します。

Application Server Controlコンソールまたはadmin_client.jarツールによるアプリケーションのデプロイおよび管理に関する一般的な情報は、『Oracle Containers for J2EEデプロイメント・ガイド』および『Oracle Containers for J2EE構成および管理ガイド』を参照してください。Application Server Controlコンソールの詳細なオンライン・ヘルプもあります。

URL構成要素のサマリー

サーブレットのデプロイと起動について説明する前に、URLの構成要素とその値を決定するもののサマリーを示します。次に、一般的な構成を示します（ただし、通常はpathinfoは空です）。

protocol://host:port/contextpath/servletpath/pathinfo

また、デリミタの後に情報を追加することも可能です。たとえば、疑問符（?）デリミタの後にリクエスト・パラメータ設定を使用できます。

protocol://host:port/contextpath/servletpath/pathinfo?param1=value1...

表2-1に、一般的な構成要素を示します。

表2-1 URLの構成要素

構成要素	説明
protocol	Webアプリケーションの起動時に使用するネットワーク・プロトコル。一般には、HTTP、HTTPS、FTP、ORMI（EJBで使用）などがあります。スタンドアロン環境では、OC4Jは、通常、独自のWebリスナーを通じて直接HTTPプロトコルを使用します。Oracle Application Server環境では、Oracle HTTP ServerがWebリスナーであり、Oracle HTTP ServerはApache JServ Protocol（AJP）を使用してOC4Jと通信します。ただし、AJPはエンド・ユーザーには表示されません。 OC4J Webサイトのプロトコルは、`default-web-site.xml`（通常）などのWebサイトのXMLファイルに含まれる`<web-site>`要素の`protocol`属性に反映されます。`protocol="http"`（HTTPの場合）または`protocol="ajp13"`（AJPの場合）を使用します。（これらは、通常、デフォルトで適切に設定されています。）
host	Webアプリケーションが稼働しているサーバーのネットワーク名。Webクライアントがアプリケーション・サーバーと同じシステム上に存在する場合は、`localhost`を使用可能です。それ以外の場合は、ホスト名を使用します（たとえばUNIXシステムの場合は、`/etc/hosts`に定義されています）。次に例を示します。 www.example.com
port	Webサーバーがリスニングしているサーバー・ポート。URLによってポートを指定しないと、HTTPプロトコルの場合はポート80、HTTPSの場合はポート443が使用されます。 OC4J Webサイトのポート番号は、WebサイトのXMLファイルに含まれる`<web-site>`要素の`prot`属性に反映されます。スタンドアロンOC4Jの場合、これは、通常、`default-web-site.xml`ファイルであり、デフォルトのポートは8888です。Oracle Application Server環境の場合、これは、通常、`default-web-site.xml`ファイルですが、`port`設定により、実際のポート番号はOPMNによって決定されることがあります。各ポートについて、`<web-site>`要素の`protocol`属性に基づく1つの関連付けられたプロトコルが必要です。 OC4J Webサイト構成およびWebサイトのXMLファイルに関する一般的な情報は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。
contextpath（コンテキスト・ルートとも呼ばれる）	サーブレット・コンテキストの指定されたルート・パス。 Application Server Controlコンソールを使用してEARファイルをデプロイする場合、これは、「application.xmlファイルの作成」に示すように、EARファイル内の標準`application.xml`ファイルの`<context-root>`要素に従います。 Application Server Controlコンソールを使用してWARファイルをデプロイする場合は、デプロイ時にコンテキスト・パスを指定できます。`admin_client.jar`を使用してEARファイルをデプロイする場合は、アプリケーションに含まれるWebモジュールをバインドする際にコンテキスト・パスを指定します。（詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。） OC4Jでは、指定されたコンテキスト・パスは、WebサイトのXMLファイルに含まれる該当するWebモジュールの`<web-app>`要素（`<web-site>`のサブ要素）の`root`属性の設定に反映されます。（各コンテキストは、サーバー・ファイル・システム内のディレクトリ・パスに関連付けられています。）また、`<web-app>`要素は、`application`属性によって、デプロイ時に指定するJ2EEアプリケーション名（およびEARファイル名）を反映し、`name`属性によって、指定するWebモジュール名（およびWARファイル名）を反映します。J2EEアプリケーション名、Webモジュール名およびコンテキスト・パスは、すべてこのように一緒にマップされます。次に例を示します。 <web-app application="ojspdemos" name="ojspdemos-web" root="/ojspdemos" /> WARファイルは、単独でデプロイすると、OC4JのデフォルトJ2EEアプリケーションに関連付けられます。
servletpath	コンテキスト・パスより後で、起動するサーブレットを指定するパス。Webモジュールの`web.xml`ファイル内で標準マッピングによってサーブレット・パスを指定します。サーブレット・クラスは、`<servlet>`要素の`<servlet-class>`および`<servlet-name>`サブ要素によって、任意のサーブレット名にマップされます。サーブレット名は、`<servlet-mapping>`要素の`<servlet-name>`および`<url-pattern>`サブ要素によってサーブレット・パスにマップされます。（1つのサーブレット・クラスを複数のサーブレット名および複数のサーブレット・パスにマップできます。）次に例を示します。 <web-app> ... <servlet> <servlet-name>logout</servlet-name> <servlet-class> oracle.security.jazn.samples.http.Logout </servlet-class> </servlet> ... <servlet-mapping> <servlet-name>logout</servlet-name> <url-pattern>/logout/*</url-pattern> </servlet-mapping> ... </web-app>
pathinfo	（通常はこれは空です。）コンテキスト・パスおよびサーブレット・パスより後に、URLにHTTPリクエスト・オブジェクトを介してサーブレットに提供される追加情報を含めることが可能です。この情報は、サーブレットによって理解されるとみなされます。この情報は、疑問符などのデリミタに続くリクエスト・パラメータ設定またはその他のURLの構成要素とは異なるものです。デリミタは、パス情報の後に続きます。

注意
<servlet-name>要素で指定される名前は、サーブレットのリクエスト・ディスパッチャを使用する場合にサーブレット・コンテキストのgetNamedDispatcher()メソッドに入力する名前です。

次のURLを例にして説明します。

http://www.example.com:port/foo/bar/mypath/myservlet/info1/info2?user=Amy

クライアント・ブラウザが提供したURLに基づいてサーブレットを起動する際、サーブレット・コンテナは次のステップを実行します。

URLのポート番号の後の部分全体を検証し、コンテキスト・パスを認識するためにコンテナ自体の構成設定（WebサイトのXMLファイル内など）を検証して、URLのどの部分がコンテキスト・パスであるかを決定します。

この例では、コンテキスト・パスが/foo/barであるとします。
URLのコンテキスト・パスの後の部分全体を検証し、web.xmlファイル内のサーブレット・マッピングで認識済のサーブレット・パスを検証して、URLのどの部分がサーブレット・パスであるかを決定します。

この時点で、サーブレットは起動できます。サーブレット・コンテナは、サーブレット・パスより後ろの情報は使用しません。

この例では、サーブレット・パスが/mypath/myservletであるとします。
URLの中で、サーブレット・パスより後、URLデリミタ（この例ではリクエスト・パラメータ設定を区切る「?」）より前に残っている部分がある場合、URLのその部分は追加情報とみなされ、HTTPリクエスト・オブジェクトを介してサーブレットに渡されます。

この例では、追加パス情報が/info1/info2であるとします。

この例で示すように、コンテキスト・パス、サーブレット・パスおよびその他のいかなるパス情報でも、1つ以上のスラッシュが間にある複合構成要素である可能性があります。多くの場合、コンテキスト・パスはfooのみのように単純で、サーブレット・パスもmyservletのみのように単純であり、パス情報も単純なことがよくあります。ただし、URLを見ただけでは、どの部分がコンテキスト・パス、サーブレット・パスまたはその他のパス情報（存在する場合）であるかはわかりません。これを判断するには、WebサイトのXMLファイルおよびweb.xmlファイル内の構成を検証する必要があります。

注意

Cookieの名前は、ホスト名、ポート番号およびパス（デフォルトではコンテキスト・パスのみだが、サーブレット・パスも含めることが可能）に基づいて決定されます。

コンテキスト・パス、サーブレット・パスおよびパス情報は、HTTPリクエスト・オブジェクトのgetContextPath()、getServletPath()およびgetPathInfo()メソッドを使用して取得できます。

WebアプリケーションのOC4Jへのデプロイ

OC4Jでは、J2EE仕様に従って、J2EEアプリケーションをEARファイルとしてデプロイすることができます。EARファイルのコンテンツには、J2EEアプリケーション全体の一部であるWebアプリケーション（サーブレットとJSPページの組合せ）のWARファイルが0個以上含まれます。

Webアプリケーションのみをデプロイする場合は、J2EEラッパー・アプリケーションを効率的に定義してEARファイル内にWARファイルをパッケージするか、WARファイルを直接デプロイすることができます。

次の項では、標準アプリケーション構造を説明した後に、各アプローチの一般的な手順を示します。

ここでは、詳細ではなく、簡単な説明のみを行います。 OC4Jにデプロイするための固有の情報や手順は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。

アプリケーション構造

Javaサーブレット仕様で規定されているように、標準Webアプリケーション構造は次のようなものです。

root_directory/
   Static files (for example, index.html)
   JSP pages
   WEB-INF/
      web.xml
      classes/
         servlet classes (directory substructure according to Java package)
      lib/
         JAR files (libraries and dependency classes)

この構造は、Webアプリケーションのデプロイに使用される標準WARファイルの構造に反映されます。同様にJavaサーブレット仕様で規定されている標準web.xmlでは、（特に）サーブレットおよびJSPページを構成します。WARファイルおよびweb.xmlに関する追加情報は、この少し後にある「WARファイルをデプロイする一般的な手順のサマリー」を参照してください。

注意
OC4J固有のWebモジュール設定の場合は、orion-web.xmlを、web.xmlファイルとともに/WEB-INFに組み込むことができます。また、OC4Jでorion-web.xmlファイルを自動作成し、OC4J固有の設定にApplication Server Controlコンソールを使用することができます（この設定はorion-web.xmlに反映されます）。

Java 2 Enterprise Edition仕様で規定されているように、標準J2EEアプリケーション構造は、次のような、Webアプリケーション構造のスーパーセットです。

root_directory/
   META-INF/
      application.xml
   WebModule/
      Static files (for example, index.html)
      JSP pages
      WEB-INF/
         web.xml
         classes/
            servlet classes (directory substructure according to Java package)
         lib/
            JAR files (libraries and dependency classes)
   EJBModule/...
   ClientModule/...
   ResourceAdapterModule/...

この構造は、J2EEアプリケーションやWARおよびその中に含まれる他のアーカイブ・ファイルのデプロイに使用される標準EARファイルの構造に反映されます。同様にJava 2 Enterprise Edition仕様で規定されている標準application.xmlファイルでは、J2EEアプリケーションとそのモジュール（Webモジュールなど）を構成します。EARファイルには、任意のWARファイル、EJBのJARファイル、アプリケーション・クライアントのJARファイル、およびリソース・アダプタのRARファイル（アプリケーションのモジュールを含む）が組み込まれます。EARファイルおよびapplication.xmlに関する追加情報は、この少し後にある「EARファイルをデプロイする一般的な手順のサマリー」を参照してください。

注意
OC4J固有のJ2EEアプリケーション設定の場合は、orion-application.xmlファイルを、標準application.xmlファイルとともに/META-INFに組み込むことができます。ただし、一般的には、OC4Jでorion-application.xmlファイルを自動作成し、OC4J固有の設定にApplication Server Controlコンソールを使用することができます（この設定はorion-application.xmlに反映されます）。 orion-application.xmlファイルの詳細は、『Oracle Containers for J2EE開発者ガイド』を参照してください。

WARファイルをデプロイする一般的な手順のサマリー

WebアプリケーションをWARファイルとして直接デプロイする（WARファイルをJ2EE EARファイルに組み込まない）場合は、次の一般的な手順を実行します。

標準web.xmlファイルを作成して、Webアプリケーションを構成します。web.xmlファイルは、WARファイルに組み込まれている必要があります。トップレベルの<web-app>要素内で、<servlet>および<servlet-mapping>サブ要素を使用して、サーブレットおよびJSPページを構成します。

<servlet>要素の<servlet-name>および<servlet-class>サブ要素と<servlet-mapping>要素の<servlet-name>および<url-pattern>サブ要素を使用して、サーブレット・クラスをURLサーブレット・パスにマップします。任意の名前を使用できますが、サーブレット・クラスをサーブレット・パスにマップすることが目的のため、論理的な名前を使用してください。
```
<web-app>
...
  <servlet>
    <servlet-name>servletname</servlet-name>
    <servlet-class>package.Classname</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>servletname</servlet-name>
    <url-pattern>servletpath</url-pattern>
  </servlet-mapping>
...
</web-app>
```
WARファイルを作成し、「アプリケーション構造」に示されているWebアプリケーション構造とパラレルなディレクトリ構造を持つルート・ディレクトリから、Webアプリケーション・コンポーネントおよびweb.xmlファイルを組み込みます。
WARファイルをOC4Jにデプロイします。Application Server Controlコンソールの「デプロイ」機能（OC4Jホームページからアクセスできる「アプリケーション」タブにあります）を使用する場合は、ここで、標準JSR-88準拠デプロイ・プランを提供または作成することや、オプションで編集することができます。

Webアプリケーションをバインドします。これは、WebアプリケーションをOC4J Webサイトに関連付け、Webアプリケーションへのアクセスで使用するURLコンテキスト・パスを関連付けるプロセスです。Application Server Controlコンソールを使用してWARファイルをデプロイする場合は、バインドはデプロイ手順に含まれており、コンテキスト・パスを指定することができます。

注意
WARファイルを単独でデプロイする際は、orion-application.xmlファイルに対応するパラメータを構成することはできません。これは、WARファイルにorion-application.xmlファイルを組み込むことができないためです。これらのパラメータを構成するには、WARファイルをEARファイルにパッケージする必要があります。関連情報については、「アプリケーション構造」を参照してください。

EARファイルをデプロイする一般的な手順のサマリー

WebアプリケーションをEARファイル内のWARファイルとしてデプロイする（WARファイルを直接デプロイしない）場合は、次の手順を実行します。

前項「WARファイルをデプロイする一般的な手順のサマリー」の説明に従って、Webアプリケーションのweb.xmlファイルおよびWARファイルを作成します。
J2EEアプリケーションを構成する標準application.xmlファイルを作成します。application.xmlファイルは、EARファイルに組み込まれている必要があります。特に、デプロイするWebアプリケーションは、URLコンテキスト・パスにマップしてください。このパスで、Application Server Controlは、後でWebサイトのXMLファイルに書き込まれるコンテキスト・パス情報を取得します。

<web>要素内で、<web-uri>サブ要素を使用してWARファイル名を指定し、<context-root>サブ要素を使用してコンテキスト・パスを指定します。
```
<application>
...
   <module>
      <web>
         <web-uri>warname.war</web-uri>
         <context-root>contextpath</context-root>
      </web>
   </module>
...
</application>
```
EARファイルを作成し、「アプリケーション構造」に示されているJ2EEアプリケーション構造とパラレルなディレクトリ構造を持つルート・ディレクトリから、アプリケーション・コンポーネントおよびapplication.xmlファイルを組み込みます。
EARファイルをOC4Jにデプロイします。Application Server Controlコンソールの「デプロイ」機能（OC4Jホームページからアクセスできる「アプリケーション」タブにあります）を使用する場合は、ここで、標準JSR-88準拠デプロイ・プランを提供または作成することや、オプションで編集することができます。
起動するすべてのWebアプリケーションをバインドします。これは、WebアプリケーションをOC4J Webサイトに関連付け、Webアプリケーションへのアクセスで使用するURLコンテキスト・パスを関連付けるプロセスです。Application Server Controlコンソールを使用してEARファイルをデプロイする場合は、Webアプリケーションのバインドはデプロイ手順に含まれており、コンテキスト・パスは、前述したように、EARファイルで提供した標準application.xmlファイルに従います。

OC4Jでのサーブレットの起動

この項では、スタンドアロンOC4J環境とOracle Application Server環境におけるサーブレット起動方法を説明します。また、開発およびテスト環境でクラス名によってサーブレットを起動するためのOC4Jの特別な機能についても説明します。

スタンドアロンOC4J環境でのサーブレットの起動

スタンドアロンOC4J環境のWebサイトでは、Oracle HTTP Serverを経由せずに、OC4J Webリスナーを直接経由してHTTPプロトコルを使用します。このサイトは、default-web-site.xmlファイルの設定に従って構成されます。（これは一般的な名前ですが、WebサイトのXMLファイル名はserver.xmlファイルの設定に基づいており、変更可能です。）

サーブレットがリクエストされると、OC4Jサーブレット・コンテナはURLを解析します（この解析については、コンテキスト・パスおよびサーブレット・パスの決定方法における注意点とともに、「URL構成要素のサマリー」で説明されています）。スタンドアロンOC4Jのデフォルトでは、ポートは8888です。このポートは、このマニュアルの多くの例で使用されます（開発者向けのマニュアルであるため）。

たとえば、コンテキスト・パスが/mypath、サーブレット・パスが/myservletの場合、次のURLでサーブレットを起動します。

http://www.example.com:8888/mypath/myservlet

OC4J開発時におけるクラス名によるサーブレットの起動

スタンドアロンOC4Jの開発環境またはテスト環境には、クラス名でサーブレットを起動する簡易的なメカニズムがあります。セキュリティ上の理由から、このメカニズムはアプリケーションの開発またはテスト時にのみ使用してください。

OC4Jのシステム・プロパティhttp.webdir.enableがtrueに設定されている場合（デフォルトはfalse）、global-web-application.xmlファイルまたはorion-web.xmlファイルの<orion-web-app>要素内のservlet-webdir属性によって、クラス名によるサーブレット起動に使用される特別なURLコンポーネントが定義されます。このURLコンポーネントはURLのコンテキスト・パスに続き、このURLコンポーネントに続くものは、サーブレット・クラス名（該当するパッケージ情報も含め）とみなされます。URLには、サーブレット・パスのかわりにサーブレット・クラス名が使用されます。（サーブレット・パスはservlet-webdir値で、サーブレット自体として動作し、実行するサーブレットのクラス名がパス情報として取得されます。）

OC4Jは、/WEB-INF/classesディレクトリ（パッケージに基づくサブディレクトリ内にある）で、またはコンテキスト・パスに関連付けられているWebアプリケーションの/WEB-INF/libディレクトリにあるJARファイルで、クラスを検索します。

注意

Application Server Controlのデプロイ・プラン・エディタを使用して、servlet-webdir（servletWebdir）を設定できます。

OC4JのデフォルトWebアプリケーションでクラス名による起動のメカニズムを使用するには、クラスをj2ee/home/default-web-app/WEB-INF/classesディレクトリに保存し、URLでデフォルトWebアプリケーションのコンテキスト・パス（デフォルトでは「/」）を使用してください。

一般に、すべてのアプリケーションでは、http.webdir.enableをtrueに設定した使用例の場合、クラス名による起動に対するOC4Jの動作は、アプリケーションのorion-web.xmlファイル内のservlet-webdir設定で決まります（設定されている場合）。ただし、次の点に注意してください。

global-web-application.xmlファイル内のservlet-webdir要素の任意の設定は、デフォルト値として使用されます（これは、global-web-application.xml内の構成設定全般に当てはまります）。ただし、global-web-application.xmlにservlet-webdirが設定されていない場合、デフォルト値は""（空の引用符）です。この設定では、クラス名による起動は無効です。デフォルト値が使用されるのは、アプリケーションのデプロイにorion-web.xmlが含まれていない場合や、servlet-webdirが設定されていない場合です。
次のいずれかの方法で、クラス名によるサーブレット起動を無効にできます。
- システム・プロパティhttp.webdir.enableのデフォルト値falseを使用します。この結果、servlet-webdir設定は無視されます。（OC4Jのシステム・プロパティに関する一般的な情報は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。）
- global-web-application.xmlまたはorion-web.xmlを使用して、servlet-webdirの値を""（空の引用符）に設定。

servlet-webdir属性については、「<orion-web-app>」でも説明します。

コンテキスト・パスを/mypath、設定をservlet-webdir="/servlet/"と仮定すると、次に示すURLは、クラス名によりサーブレットfoo.bar.SessionServletを起動します。

http://www.example.com:8888/mypath/servlet/foo.bar.SessionServlet

重要
クラス名によるサーブレットの起動を許可すると、重大なセキュリティ上のリスクが発生する可能性があります。本番環境では、OC4Jをこのモードで動作するよう構成しないでください。詳細は、「セキュリティのベスト・プラクティス」を参照してください。

Oracle Application Server環境でのサーブレットの起動

Oracle Application Server環境では、OC4Jは、OC4Jとの通信にAJPプロトコルを使用するOracle HTTP Serverを通じてアクセスされます。（AJPはエンド・ユーザーには表示されません。）Webサイトは、default-web-site.xmlファイルでの設定に基づいて構成されます。（これは一般的な名前ですが、WebサイトのXMLファイル名はserver.xmlファイルの設定に基づいており、変更可能です。）

サーブレットがリクエストされると、OC4Jサーブレット・コンテナはURLを解析します（この解析については、ポート、コンテキスト・パスおよびサーブレット・パスの決定方法における注意点とともに、「URL構成要素のサマリー」で説明されています）。

たとえば、コンテキスト・パスが/mypath、サーブレット・パスが/myservletの場合、次のURL（および適切なポート番号）でサーブレットを起動します。

http://www.example.com:port/mypath/myservlet

単純なサーブレットの例のデプロイおよび起動

この項では、「単純なサーブレットの例」で示したサーブレットをデプロイして起動します。まず、サーブレットをWARファイルとして直接デプロイし、次に、EARファイルに組み込まれたWARファイルとしてデプロイします。

サーブレットの例のWARファイルとしてのデプロイ

この項では、最初に「WARファイルをデプロイする一般的な手順のサマリー」で概要が示された次の手順を実行して、単純なサーブレットの例をWARファイルとして直接デプロイします。

サーブレットの実行や、デプロイ仕様の一部がサーブレットのURLに反映された結果は、「サーブレットの例の起動」を参照してください。

web.xmlファイルの作成

次に、単純なサーブレットの例のweb.xmlファイルを示します。 <servlet-class>要素は、「サンプル・コードの作成」に示されているHelloWorld.javaで指定されているパッケージ名とクラス名を反映します。<url-pattern>要素は、サーブレットの起動で使用されるURLのサーブレット・パス部分としてmyhelloを指定します。サーブレット名は、クラス名をサーブレット・パスにマップします。

<?xml version="1.0"?>
<!DOCTYPE web-app (doctype...)> 
<web-app>
  <servlet>
    <servlet-name>hello</servlet-name>
    <servlet-class>mytest.HelloWorld</servlet-class>
  </servlet>
  <servlet-mapping>
    <servlet-name>hello</servlet-name>
    <url-pattern>myhello</url-pattern>
  </servlet-mapping>
</web-app>

WARファイルの作成

次に、標準Webアプリケーション構造に基づく、単純なサーブレットの例のディレクトリ構造を示します。

root_directory/
   WEB-INF/
      web.xml
      classes/
         mytest/
            HelloWorld.class
            HelloWorld.java

WARファイルは、この構造を反映する必要があります。WARファイルを手動で作成する場合は、カレント・ディレクトリがルート・ディレクトリのときにJARユーティリティを使用して次のコマンドを発行します（%はシステム・プロンプト）。

% jar cvf MyHelloWorld.war .

これにより、次のコンテンツと構造を持つWARファイルのMyHelloWorld.warが生成されます（ここでManifest.mfファイルおよびMETA-INFディレクトリが自動的に作成されます）。

META-INF/Manifest.mf
WEB-INF/web.xml
WEB-INF/classes/mytest/HelloWorld.class
WEB-INF/classes/mytest/HelloWorld.java

WARファイル名は、主要なWebコンポーネント名を反映している必要があります。この場合は、サーブレットの例のクラス名を反映しています。

WARファイルのデプロイおよびWebアプリケーションのバインド

WARファイルをデプロイします。これには、通常、Application Server Controlの「デプロイ」機能（OC4Jホームページからアクセスできる「アプリケーション」タブにあります）を使用します。

Application Server Controlコンソールで、次の手順を実行します。

WARファイルを指定します。
Application Server Controlで新しいデプロイ・プランを作成します。
アプリケーション（Webアプリケーション）名を指定します。この名前は、WARファイル名を反映する必要があります。
親アプリケーション（デフォルトではOC4Jのデフォルト・アプリケーション）を指定します。
WebアプリケーションをバインドするためのWebサイト（default-web-siteなど）を指定します。

コンテキスト・パスを指定します（または、WARファイル名から得られるデフォルトのコンテキスト・パスを使用します）。この例では、/mycontextを指定します。

注意
Application Server Controlコンソールのかわりにadmin_client.jarを使用する場合は、デプロイとバインドが別の手順であり、バインドする際にコンテキスト・パスを指定します。詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。

サーブレットの例のEARファイルとしてのデプロイ

この項では、最初に「EARファイルをデプロイする一般的な手順のサマリー」で概要が示された次の手順を実行して、単純なサーブレットの例をEARファイルに組み込まれたWARファイルとしてデプロイします。

サーブレットの実行や、デプロイ仕様の一部がサーブレットのURLに反映された結果は、「サーブレットの例の起動」を参照してください。

web.xmlファイルおよびWARファイルの作成

WARファイルを直接デプロイする場合と同じように、まず、web.xmlファイルとWARファイルを作成します。この手順は、「web.xmlファイルの作成」および「WARファイルの作成」で説明されています。

application.xmlファイルの作成

次に、EARファイルに組み込まれたWARファイルにサーブレットをデプロイする際に使用する、単純なサーブレットの例のapplication.xmlファイルを示します。Application Server Controlコンソールを使用してデプロイする場合は、そこでコンテキスト・パスが決定され、後でWebサイトのXMLファイルに書き込まれます。<web-uri>要素は、WARファイルの名前を示します。<context-root>要素は、WARファイルのWebアプリケーション（ここではサーブレットの例）と目的のURLコンテキスト・パスの/mycontextを結び付けます。

<?xml version = '1.0' encoding = 'UTF-8'?>
<!DOCTYPE web-app (doctype...)> 
<application>
   <module>
      <web>
         <web-uri>MyHelloWorld.war</web-uri>
         <context-root>/mycontext</context-root>
      </web>
   </module>
</application>

注意
admin_client.jarを使用して、EARファイルをデプロイし、組み込まれているWebアプリケーションをバインドする場合は、Webアプリケーションをバインドする際にコンテキスト・パスを直接指定します。

EARファイルの作成

EARファイルを作成する前に、次の手順を実行してディレクトリ構造を準備します。

目的のルート・ディレクトリから、META-INFサブディレクトリを作成します。
標準J2EEアプリケーション構造に従って、application.xmlファイルをMETA-INFに配置します。
WARファイルをルート・ディレクトリに配置します。

これにより、次のディレクトリ構造が作成されます。

root_directory/
   META-INF/
      application.xml
   MyHelloWorld.war

EARファイルを手動で作成する場合は、カレント・ディレクトリがルート・ディレクトリのときにJARユーティリティを使用して次のコマンドを発行します（%はシステム・プロンプト）。

% jar cvf MyHelloWorld.ear .

これにより、次のコンテンツと構造を持つEARファイルのMyHelloWorld.earが生成されます（ここでManifest.mfファイルが自動的に作成されます）。

MyHelloWorld.war
META-INF/application.xml
META-INF/Manifest.mf

EARファイルのデプロイおよび組み込まれているWebアプリケーションのバインド

EARファイルをデプロイします。これには、通常、Application Server Controlの「デプロイ」機能（OC4Jホームページからアクセスできる「アプリケーション」タブにあります）を使用します。

Application Server Controlコンソールで、次の手順を実行します。

EARファイルを指定します。
Application Server Controlで新しいデプロイ・プランを作成します。
J2EEアプリケーション名を指定します。この名前は、EARファイル名を反映する必要があります。
親アプリケーション（デフォルトではOC4Jのデフォルト・アプリケーション）を指定します。

WebアプリケーションをバインドするためのWebサイト（default-web-siteなど）を指定します。

注意
Application Server Controlコンソールのかわりにadmin_client.jarを使用する場合は、EARファイルのデプロイと組み込まれているWebアプリケーションのバインドは別の手順です。詳細は、『Oracle Containers for J2EEデプロイメント・ガイド』を参照してください。

サーブレットの例の起動

前述のWARファイルのデプロイまたはEARのデプロイ（どちらも同じサーブレット・パスおよびコンテキスト・パスを指定します）が完了したら、次のように、適切なホスト名を指定して、サーブレットを起動します。このURLは、OC4Jのポート番号が8888の場合です。このポート番号は、スタンドアロン環境のOC4Jのデフォルト設定です。

http://www.example.com:8888/mycontext/myhello

サーブレット・パスのmyhelloは、デプロイ時に提供したweb.xmlファイルによって決定されます。コンテキスト・パスの/mycontextは、前述のように、application.xmlファイルによって、またはWebアプリケーションのバインド時の指定によって決定されます。（コンテキスト・パスについては、「URL構成要素のサマリー」を参照してください。）

次に、サーブレットの出力を示します。

画像の説明

サーブレットの事前ロード

通常、サーブレット・コンテナは、ブラウザ経由の直接リクエストやインクルードまたは転送などによって最初にリクエストされたときに、サーブレット・クラスをインスタンス化してロードします。ただし、サーバーの起動後すぐにサーブレットを起動する場合は、server.xmlファイル、WebサイトのXMLファイル（default-web-site.xmlなど）およびweb.xmlファイルの設定を使用してサーブレットの事前ロードを設定できます。事前ロードされたサーブレットは、OC4Jサーバーの起動時またはWebアプリケーションのデプロイ時や再デプロイ時にロードされ、初期化されます。

事前ロードには、次の手順が必要です。

使用するserver.xmlファイル内の<application>要素の属性がstart="true"に設定されていることを確認します。アプリケーションをデプロイすると、デフォルトでOC4Jがこの設定を挿入します。
属性設定load-on-startup="true"を、使用するWebサイトのXMLファイルの<web-site>要素の<web-app>サブ要素に指定します。（OC4JのWebサイトのXMLファイルの詳細は、『Oracle Containers for J2EE構成および管理ガイド』を参照してください。）
事前ロードするサーブレットに対して、Webモジュールのweb.xmlファイルの<servlet>要素の下に<load-on-startup>サブ要素が存在する必要があります。

表2-2に、web.xmlの<load-on-startup>要素の動作を説明します。

表2-2 web.xmlファイルの<load-on-startup>の動作

値の範囲 動作

値の範囲	動作
0（ゼロ）未満（<0）例: <load-on-startup>-1</load-on-startup>	サーブレットは事前ロードされません。
0（ゼロ）以上（>=0）例: <load-on-startup>1</load-on-startup>	サーブレットは事前ロードされます。サーブレットのロードは、同じWebアプリケーションに事前ロードされる他のサーブレットに関してload-on-startupの値に従い、低い数値から順に行われます。（たとえば、ゼロ（0）は1の前にロードされ、1は2の前にロードされます。）
空要素例: <load-on-startup/>	load-on-startup値が`Integer.MAX_VALUE`の場合と同様に動作します。この場合、サーブレットは、load-on-startup値がゼロ（0）以上のサーブレットの後にロードされます。

0（ゼロ）未満（<0）

例:

<load-on-startup>-1</load-on-startup>

サーブレットは事前ロードされません。

0（ゼロ）以上（>=0）

例:

<load-on-startup>1</load-on-startup>

サーブレットは事前ロードされます。サーブレットのロードは、同じWebアプリケーションに事前ロードされる他のサーブレットに関してload-on-startupの値に従い、低い数値から順に行われます。（たとえば、ゼロ（0）は1の前にロードされ、1は2の前にロードされます。）

空要素

例:

<load-on-startup/>

load-on-startup値がInteger.MAX_VALUEの場合と同様に動作します。この場合、サーブレットは、load-on-startup値がゼロ（0）以上のサーブレットの後にロードされます。

注意
OC4Jでは、startupクラスおよびshutdownクラスの指定をサポートしています。詳細は、『Oracle Containers for J2EE開発者ガイド』を参照してください。startupクラスはserver.xmlファイルの<startup-classes>要素によって指定され、OC4Jの初期化直後にコールされます。shutdownクラスはserver.xmlファイルの<shutdown-classes>要素によって指定され、OC4Jの終了直前にコールされます。
startupクラスは他の事前ロードされるサーブレットより先にコールされる点に注意してください。