1
サーブレットの概要

Oracle Application Server Containers for J2EE（OC4J）を使用すると、標準J2EE準拠のアプリケーションを開発およびデプロイできます。アプリケーションは、標準Enterprise Archive（EAR）デプロイメント・ファイルにパッケージされており、Webモジュールをデプロイするための標準Web Archive（WAR）ファイルと、アプリケーション内のEnterprise JavaBeans（EJB）およびアプリケーション・クライアント・モジュール用のJava archive（JAR）ファイルが含まれます。

Oracle Application Server 10gリリース2（10.1.2）では、OC4Jは、Java 2 Platform Enterprise Editionバージョン1.3に準拠し、OC4Jコンテナ内ではSun社のJavaサーブレット仕様、バージョン2.3に完全に準拠しています。（特に記載のないかぎり、このマニュアルではサーブレット仕様はこのバージョンを指します）。

Webアプリケーションの構築およびデプロイ方法はOC4Jにおけるサーブレット開発を理解する上で、最も重要な概念です。サーブレットを初めて使用する場合は、第2章「サーブレットの開発」を参照してください。OC4Jの開発環境を初めて使用する場合は、第5章「デプロイおよび構成の概要」を参照して、OC4Jにおけるアプリケーションのデプロイ方法を理解してください。

この章では、Javaサーブレットの概要を説明し、基本サーブレットの例を示します。また、サーバー・サイドのプログラミングに関する様々な課題に対処するためにJ2EEアプリケーションでサーブレットを使用する方法を、簡単に説明します。

この章には、次の項が含まれます。

• サーブレットの概要

• 初めてのサーブレット作成の例

  注意 サンプルのサーブレット・アプリケーションはOC4Jのデモに含まれています。デモは、Oracle Technology Networkの次のサイトから入手可能です（OTNのメンバーシップ登録が必要ですが、登録は無料です）。 http://www.oracle.com/technology/tech/java/oc4j/demos/

サーブレットの概要

次の項では、サーブレット・テクノロジの概要を説明します。

• サーブレット・テクノロジのレビュー

• サーブレットの利点

• サーブレット・インタフェースとリクエスト・オブジェクトおよびレスポンス・オブジェクト

• サーブレットおよびサーブレット・コンテナ

• サーブレット・セッションの概要

• サーブレット・コンテキストの概要

• サーブレット構成オブジェクトの概要

• サーブレット・フィルタの概要

• イベント・リスナーの概要

• JSPページおよびその他のJ2EEコンポーネント・タイプ

  注意 「Webモジュール」、「Webアプリケーション」という用語はほとんどの場合が同義で、両方ともこのマニュアル全体を通して使用されています。区別されている場合、通常「Webモジュール」は独立したアプリケーションを構成するかしないかに関係なく単一のコンポーネントを示し、「Webアプリケーション」は複数のモジュールまたはコンポーネントから構成されている可能性のある動作中のアプリケーションを示します。

サーブレット・テクノロジのレビュー

近年、サーブレット・テクノロジは、動的Webページを使用してWebサーバー機能を拡張する強力な手段として登場しました。サーブレットは、Webサーバーで稼働するJavaプログラムです。一方、アプレットはクライアント・ブラウザで稼働します。通常、サーブレットは、ブラウザからHTTPリクエストを取得し、データベース問合せなどによって動的コンテンツを生成し、HTTPレスポンスをブラウザに返します。または、直接別のアプリケーション・コンポーネントからアクセスされるか、または別のコンポーネントに出力を送信する場合もあります。ほとんどのサーブレットはHTMLテキストを生成しますが、かわりにXMLを生成してデータをカプセル化するサーブレットもあります。

具体的には、サーブレットは、OC4JなどのJ2EEアプリケーション・サーバーで稼働します。サーブレットは、JavaServer Pages（JSP）およびEJBと同様、J2EEアプリケーションの主要なアプリケーション・コンポーネント・タイプの1つです。JSPやEJBも、サーバー・サイドJ2EEコンポーネント・タイプです。サーブレットは、アプレット（Java 2 Platform, Standard Edition仕様の一部）などのクライアント・サイド・コンポーネントやアプリケーションのクライアント・プログラムとともに使用されます。アプリケーションは、任意の数のコンポーネントで構成できます。

サーブレット以前は、動的コンテンツの作成に、Common Gateway Interface（CGI）が使用されていました。CGIプログラムは、Perlなどの言語で記述され、WebアプリケーションによってWebサーバーを介してコールされます。しかし、CGIはアーキテクチャやスケーラビリティに制限があるため、理想的なプログラムでないことが実証されました。

サーブレットの利点

Javaレルムでは、サーブレット・テクノロジは、データベースにアクセスするアプリケーションなどのサーバー集中型アプリケーションの場合、アプレット・テクノロジより利点があります。サーバーで実行することの利点の1つは、サーバーが通常多くのリソースを持つ堅牢なマシンであるため、プログラムがよりスケーラブルになることです。サーバーで実行すると、より直接的にデータにアクセスすることもできます。サーブレットが稼働中のWebサーバーは、アクセス対象データと同様に、ネットワーク・ファイアウォールの内側にあります。

サーブレットのプログラミングには、サーバー・サイドのWebアプリケーション開発における初期のモデルと比べると、次のような多くの利点もあります。

• サーブレットは、サーバー・サイド・インクルードやCGIスクリプトなど、動的HTML生成を行うための初期のテクノロジより優れています。一度メモリーにロードされたサーブレットは、軽量なシングル・スレッド上で実行できます。CGIスクリプトは、リクエストごとに別のプロセスにロードする必要があります。

• サーブレット・テクノロジには、スケーラビリティの向上に加えて、セキュリティ、堅牢さ、オフジェクト指向およびプラットフォームへの非依存など、よく知られたJavaの利点が備わっています。

• サーブレットは、Java Database Connectivity（JDBC）などのJava言語およびJavaの標準APIと完全に統合されています。

• サーブレットは、完全にJ2EEフレームワークに統合されています。J2EEフレームワークには、作成するWebアプリケーションに使用可能なサービスの拡張セットが用意されています。たとえば、コンポーネントのネーミングおよびルックアップに使用するJava Naming and Directory Interface（JNDI）、トランザクションの管理に使用するJava Transaction API（JTA）、セキュリティに使用するJava Authentication and Authorization Service（JAAS）、分散アプリケーションに使用するRemote Method Invocation（RMI）およびJava Message Service（JMS）などです。次のWebサイトには、J2EEフレームワークおよびサービスに関する情報が記載されています。

  http://java.sun.com/j2ee/docs.html
  
  

• サーブレットでは、スレッド・モデルに基づき、単一のサーブレット・インスタンスまたは複数のサーブレット・インスタンスを使用して同時リクエストを処理します。各サーブレットには明確に定義されたライフ・サイクルが存在します。また、オプションで、OC4Jを起動するときにサーブレットをロードできます。そのため、初回のユーザー・リクエストに応じるのではなく、事前にすべての初期化が行われます。「サーブレットの事前ロード」を参照してください。

• サーブレットのリクエストおよびレスポンス・オブジェクトを使用すると、HTTPリクエストの処理や、テキストとデータのクライアントへの返信が容易に行えます。

サーブレットは、Javaプログラミング言語で記述されているため、Java Virtual Machine（JVM）を持つすべてのプラットフォーム、およびサーブレットをサポートしているすべてのWebサーバーでサポートされます。サーブレットは、再コンパイルせずに別のプラットフォーム上で使用できます。サーブレットをグラフィックス、サウンドおよび他のデータなどの関連するファイルとともにパッケージングして、完全なWebアプリケーションを作成することができます。パッケージングによって、アプリケーションの開発とデプロイが簡素化されます。

さらに、サーブレット・ベースのアプリケーションを他のWebサーバーからOC4Jに簡単に移植できます。J2EE準拠のWebブラウザ用に開発されたアプリケーションの場合、移植の手間は最小限ですみます。

サーブレット・インタフェースとリクエスト・オブジェクトおよびレスポンス・オブジェクト

Javaサーブレットは、当然javax.servlet.Servletインタフェースを実装しています。このインタフェースは、サーブレットの初期化、リクエストの処理、サーブレットの構成情報や他の基本情報の取得、およびサーブレット・インスタンスの終了などを行うメソッドを指定します。

Webアプリケーションの場合は、javax.servlet.http.HttpServlet抽象クラスを拡張して、Servletインタフェースを実装できます。（一方、プロトコルに依存しないサーブレットの場合は、javax.servlet.GenericServletクラスを拡張できます。）HttpServletクラスには、次のメソッドが含まれています。

• init(...): サーブレットを初期化します。

• destroy(...): サーブレットを終了します。

• doGet(...): HTTP GETリクエストを実行します。

• doPost(...): HTTP POSTリクエストを実行します。

• doPut(...): HTTP PUTリクエストを実行します。

• doDelete(...): HTTP DELETEリクエストを実行します。

• service(...): HTTPリクエストを受信し、デフォルトで、そのリクエストを適切なdoXXX()メソッドに送信します。

• getServletInfo(...): サーブレットに関する情報を取得します。

HttpServletを拡張するサーブレット・クラスは、必要に応じてこれらのメソッドの一部またはすべてを実装し、元の実装を任意にオーバーライドしてリクエストを処理し、レスポンスを返します。たとえば、ほとんどのサーブレットは、doGet()メソッド、doPost()メソッドまたはこれらの両方をオーバーライドして、HTTP GETおよびPOSTリクエストを処理します。

各メソッドは、入力としてHttpServletRequestインスタンス（javax.servlet.http.HttpServletRequestインタフェースを実装するクラスのインスタンス）とHttpServletResponseインスタンス（javax.servlet.http.HttpServletResponseインタフェースを実装するクラスのインスタンス）を取得します。

HttpServletRequestインスタンスは、サーブレットにHTTPリクエストに関する情報を提供します。情報には、リクエスト・パラメータ名と値、リクエストを作成したリモート・ホスト名およびリクエストを受信したサーバー名などが含まれます。HttpServletResponseインスタンスは、レスポンスの送信時に、コンテンツ長とMIMEタイプの指定および出力ストリームの指定など、HTTP固有の機能を提供します。

サーブレットおよびサーブレット・コンテナ

Javaクライアント・プログラムとは異なり、サーブレットには静的なmain()メソッドがありません。したがって、サーブレットは、外部コンテナの制御下で実行する必要があります。

サーブレット・コンテナは、サーブレット・エンジンとも呼ばれ、サーブレットの実行と管理を行います。サーブレット・コンテナは、サーブレット・メソッドをコールし、サーブレットの実行中に必要なサービスを提供します。サーブレット・コンテナは通常Javaで作成し、Webサーバーに組み込むか（WebサーバーもJavaで作成されている場合）、Webサーバーに関連付けて使用します。OC4Jには、完全な標準準拠のサーブレット・コンテナが組み込まれます。

サーブレット・コンテナにより、サーブレットは、ヘッダーやパラメータなどHTTPリクエストのプロパティに容易にアクセスできます。URLによる指定などでサーブレットがコールされると、Webサーバーは、HTTPリクエストをサーブレット・コンテナに渡します。コンテナは、次に、そのリクエストをサーブレットに渡します。サーブレットの管理で、サーブレット・コンテナは、次のタスクを実行します。

• サーブレットのインスタンスを作成し、そのinit()メソッドをコールして初期化します。

• リクエスト・オブジェクトを作成して、サーブレットに渡します。リクエストには、特に次のものが含まれます。
  • クライアントからの任意のHTTPヘッダー

  • クライアントから渡されたパラメータと値（URL内の問合せ文字列の名前および値など）

  • サーブレット・リクエストの完全なURI

• サーブレットのレスポンス・オブジェクトを作成します。

• サーブレットのservice()メソッドを起動します。HTTPサーブレットの場合、汎用サービス・メソッドは、通常HttpServletクラスでオーバーライドされます。サービス・メソッドは、リクエスト内のHTTPヘッダーに応じて（GETまたはPOST）、サーブレットのdoGet()またはdoPost()メソッドにリクエストを送ります。

• サーブレットのdestroy()メソッドをコールして、必要に応じてそのサーブレットをガベージ・コレクションの対象とするために破棄します。（パフォーマンス上の理由から、通常サーブレット・コンテナはサーブレット・インスタンスをメモリー内に保持して再利用します。タスクが終了するたびにインスタンスを破棄することはありません。破棄されるのは、Webサーバー・シャットダウンなどの使用頻度が低いイベントの場合のみです。）

図1-1に、サーブレットがサーブレット・コンテナおよびWebブラウザなどのクライアントとどのように関連するかを示します。WebリスナーがOracle HTTP Server（powered by Apache）の場合、OC4Jサーブレット・コンテナへの接続は、mod_oc4jモジュール経由になります。詳細は、『Oracle HTTP Server管理者ガイド』を参照してください。

図1-1    サーブレットおよびサーブレット・コンテナ

画像の説明

サーブレット・セッションの概要

サーブレットでは、HTTPセッションを使用して、各HTTPリクエストの発信元ユーザーを追跡します。そのため、単一ユーザーからの複数のリクエストは、ステートフルな方法で管理できます。サーブレットのセッション・トラッキングは、CGIなど以前のテクノロジで使用されたセッション・トラッキングと本質的に類似しています。

この項では、サーブレット・セッションの概要を説明します。詳細および例は、「サーブレットのセッション」を参照してください。

セッション・トラッキングの概要

サーブレットは、クライアント・セッションとサーバー・セッションの同期を維持する便利な方法を備えています。これにより、ステートフルなサーブレットは、クライアントによるブラウズ・セッションの間中、サーバー上のセッションの状態を維持できます。

OC4Jは次のセッション・トラッキング方法をサポートしています。詳細は、「セッション・トラッキング」を参照してください。

• Cookie

  サーブレット・コンテナは、Cookieをクライアントに送信します。クライアントはそのCookieをHTTPリクエスト時にサーバーに返します。このプロセスでは、リクエストはCookieが示すセッションIDに関連付けられます。これが最もよく使用される方法で、サーブレット仕様に準拠しているすべてのサーブレット・コンテナでサポートされます。

• URLリライティング

  Cookieを使用するかわりに、サーブレットは、レスポンス・オブジェクトのencodeURL()メソッドまたはリダイレクト用のencodeRedirectURL()メソッドをコールして、セッションIDを各リクエストのURLパスに追加することもできます。このプロセスでは、リクエストをセッションに関連付けることができます。これが、クライアントがCookieを受け入れない場合に最もよく使用される方法です。

HttpSessionインタフェースの概要

標準サーブレットAPIでは、各クライアント・セッションは、javax.servlet.http.HttpSessionインタフェースを実装するクラスのインスタンスによって表されます。サーブレットは、このHttpSessionオブジェクト内のセッションに関する情報を設定および取得できます。このオブジェクトはアプリケーション・レベルのスコープを持つ必要があります。

サーブレットは、HttpServletRequestオブジェクトのgetSession()メソッドを使用して、ユーザーのHttpSessionオブジェクトを取得または作成します。このメソッドは、ブール引数を取得して、オブジェクト・セッションがアプリケーション内に存在しない場合に、クライアントに対して新規セッション・オブジェクトを作成する必要があるかどうかを指定します。

詳細は、「HttpSessionインタフェースの機能」を参照してください。

サーブレット・コンテキストの概要

サーブレット・コンテキストは、単一JVM内のWebアプリケーションの全インスタンス（つまり、Webアプリケーションに含まれる全サーブレットとJSPページ・インスタンス）に関する情報を保持するために使用します。任意のJVM内で稼働するWebアプリケーションごとに1つのサーブレット・コンテキストがあります。これは常に1対1の設定です。サーブレット・コンテキストは、特定のアプリケーションのコンテナと考えられます。

サーブレット・コンテキストの基本

サーブレット・コンテキストは、javax.servlet.ServletContextインタフェースを実装するクラスのインスタンスです。このクラスは、サーブレットをサポートするWebサーバーに含まれています。

ServletContextオブジェクトは、サーブレット環境に関する情報（サーバー名など）を提供し、単一JVM内のグループのサーブレット間でリソースを共有できるようにします。（同時に複数のJVMをサポートしているサーブレット・コンテナの場合、リソース共有の実装は一様ではありません。）

サーブレット・コンテキストは、アプリケーションの実行インスタンスに対してスコープを設定します。このメカニズムによって、各アプリケーションは別個のクラスローダーからロードされ、その実行時オブジェクトは他のアプリケーションのオブジェクトとは明確に区別されます。特に、ServletContextオブジェクトはアプリケーションごとに異なります。これは、各HttpSessionオブジェクトがそのアプリケーションのユーザーごとに異なるのと同じです。

サーブレット仕様のバージョン2.2から、ほとんどの実装で単一ホスト内に複数のサーブレット・コンテキストを設定できます。そのため、各Webアプリケーションが独自のサーブレット・コンテキストを持つことができます（以前の実装では、任意のホストに設定できるサーブレット・コンテキストは1つのみでした）。

サーブレット・コンテキストの取得方法

サーブレットの構成オブジェクトのgetServletContext()メソッドを使用して、サーブレット・コンテキストを取得します。「サーブレット構成オブジェクトの概要」を参照してください。

サーブレット・コンテキスト・メソッド

ServletContextインタフェースは、サーブレットにそのサーブレットを実行するサーブレット・コンテナとの通信を許可するメソッドを指定します。この方法によって、サーブレットはアプリケーション・レベルの環境と状態情報を取得できます。ServletContextでは、次のようなメソッドが指定されます。詳細は、次の場所でSun社のJavadocを参照してください。

http://java.sun.com/products/servlet/2.3/javadoc/index.html

• void setAttribute(String name, Object value)

  このメソッドは、指定したオブジェクトをサーブレット・コンテキストの指定した属性名にバインドします。属性を使用すると、サーブレット・コンテナは、サーブレットに情報を提供できます。属性を使用しない場合、ServletContextインタフェースを介して情報を提供できません。

  注意 サーブレット・コンテキストの場合、setAttribute()は、ローカル操作のみです。クラスタ内の他のJVMへの配布を目的としていません。（これは、サーブレット仕様に従っています）。

• Object getAttribute(String name)

  このメソッドは、指定した名前を持つ属性を戻します。その名前の属性がない場合は、nullを戻します。属性は、java.lang.Objectインスタンスとして戻されます。

• java.util.Enumeration getAttributeNames()

  このメソッドは、サーブレット・コンテキストで使用可能な全属性の名前が含まれたjava.util.Enumerationインスタンスを戻します。

• void removeAttribute(String attrname)

  このメソッドは、指定した属性をサーブレット・コンテキストから削除します。

• String getInitParameter(String name)

  このメソッドは、指定したコンテキスト全体の初期化パラメータの値を示す文字列を戻します。その名前のパラメータがない場合は、nullを戻します。これによって、このサーブレット・コンテキストに関連付けられたWebアプリケーションに有用な構成情報にアクセスできます。

• Enumeration getInitParameterNames()

  このメソッドは、サーブレット・コンテキストの初期化パラメータ名が含まれたjava.util.Enumerationインスタンスを戻します。

• RequestDispatcher getNamedDispatcher(String name)

  このメソッドは、指定したサーブレットのラッパーとして動作するjavax.servlet.RequestDispatcherインスタンスを戻します。

• RequestDispatcher getRequestDispatcher(String path)

  このメソッドは、指定したパスにあるリソースのラッパーとして動作するjavax.servlet.RequestDispatcherインスタンスを戻します。

• String getRealPath(String path)

  このメソッドは、指定した仮想パスに対する実際のパスを文字列で戻します。

• URL getResource(String path)

  このメソッドは、指定したパスにマップされたリソースに対するURLが含まれたjava.net.URLインスタンスを戻します。

• String getServerInfo()

  このメソッドは、サーブレット・コンテナの名前とバージョンを戻します。

• String getServletContextName()

  このメソッドは、web.xmlファイルの<display-name>要素に基づいて、サーブレット・コンテキストが関連付けられているWebアプリケーションの名前を戻します。

サーブレット構成オブジェクトの概要

サーブレット構成オブジェクトには、サーブレットの初期化および起動パラメータが含まれます。このオブジェクトは、javax.servlet.ServletConfigインタフェースを実装するクラスのインスタンスです。このクラスは、任意のJ2EE準拠のWebサーバーにより提供されます。

サーブレットのgetServletConfig()メソッドをコールすることで、サーブレットのサーブレット構成オブジェクトを取得できます。このメソッドはjavax.servlet.Servletインタフェースで指定されており、javax.servlet.http.HttpServletクラスでデフォルトが実装されています。

ServletConfigインタフェースは、次のメソッドを指定します。

• ServletContext getServletContext()

  アプリケーションのサーブレット・コンテキストを取得します。「サーブレット・コンテキストの概要」を参照してください。

• String getServletName()

  サーブレットの名前を取得します。

• Enumeration getInitParameterNames()

  サーブレットの初期化パラメータの名前がある場合、その名前を取得します。名前は、Stringオブジェクトのjava.util.Enumerationインスタンスに戻されます。（初期化パラメータがない場合、Enumerationインスタンスは空です。）

• String getInitParameter(String name)

  これは、指定した初期化パラメータの値を含むStringオブジェクトを戻します。その名前のパラメータがない場合は、nullを戻します。

サーブレット・フィルタの概要

リクエスト・オブジェクト（HttpServletRequestを実装するクラスのインスタンス）とレスポンス・オブジェクト（HttpServletResponseを実装するクラスのインスタンス）は、通常、サーブレット・コンテナとサーブレットとの間で直接受渡しされます。

ただし、サーブレット仕様では、サーブレット・フィルタを使用できます。このフィルタは、サーバーで実行され、特別なリクエストやレスポンスを処理するためにサーブレット（またはサーブレット・グループ）とサーブレット・コンテナの中間に置くことができるJavaプログラムです。

サーブレットより先に起動するフィルタまたは一連のフィルタがある場合、これらのフィルタは、リクエスト・オブジェクトとレスポンス・オブジェクトをパラメータとして使用してコンテナからコールされます。フィルタは、doChain()メソッドを使用して、これらのオブジェクト（変更されている場合もある）を一連のフィルタ内の次のオブジェクトに渡します。新規オブジェクトを作成してそれを渡すこともあります。

詳細は、「サーブレット・フィルタ」を参照してください。

イベント・リスナーの概要

サーブレット仕様には、イベント・リスナーを使用してWebアプリケーションの主要イベントを追跡する機能が追加されました。この機能を使用すると、イベントの状態に基づいたリソース管理と自動処理をより効果的に実行できます。

リスナー・クラスを作成する場合、サーブレット・コンテキストのライフ・サイクル・イベント、サーブレット・コンテキスト属性の変更、HTTPセッションのライフ・サイクル・イベント、およびHTTPセッション属性の変更に対して標準インタフェースを実装できます。リスナー・クラスには、必要に応じて、これらのインタフェースの1つ、複数またはすべてを実装できます。

イベント・リスナー・クラスは、web.xmlデプロイメント・ディスクリプタで宣言され、アプリケーションの起動時に起動され、登録されます。イベントが発生すると、サーブレット・コンテナは適切なリスナー・メソッドをコールします。

詳細は、「イベント・リスナー」を参照してください。

JSPページおよびその他のJ2EEコンポーネント・タイプ

アプリケーションには、サーブレットに加えて、JSPページやEJBなどのサーバー・サイド・コンポーネントを組み込むことができます。特に、サーブレットは、WebアプリケーションのJSPページと組み合せて使用するのが一般的です。サーブレットは、OC4Jサーブレット・コンテナによって管理されます。一方、EJBはOC4J EJBコンテナ、JSPページはOC4J JSPコンテナによって管理されます。これらのコンテナはOC4Jの中核を形成します。

JSPページにもサーブレット・コンテナが含まれています。これは、JSPコンテナ自体がサーブレットであり、サーブレット・コンテナによって実行されるためです。JSPコンテナは、JSPページをページ実装クラスに変換します。このクラスはJSPコンテナによって実行され、基本的にはサーブレットでもあります。

注意 このマニュアルでサーブレットに適用する機能について説明している部分はすべて、特に記載がないかぎりJSPページにも同様に適用されます。

JSPページとEJBの詳細は、次のマニュアルを参照してください。

• 『Oracle Application Server Containers for J2EE JavaServer Pages開発者ガイド』

• 『Oracle Application Server Containers for J2EE Enterprise JavaBeans開発者ガイド』

初めてのサーブレット作成の例

サーブレットの作成に関する一般的なフレームワークを説明するには、基本的な例を参照するのが一番効率的です。

Hello Worldコード

このサーブレットはクライアント上に「Hi There!」を表示します。このコメントには、サーブレットの作成の基本的な側面の一部が記載されています。

// You must import at least the following packages for any servlet you write.
import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;

// Extend HttpServlet, the base servlet implementation.
public class HelloServlet extends HttpServlet {

  // Override the base implementation of doGet(), as desired.
  public void doGet (HttpServletRequest req, HttpServletResponse resp)
    throws ServletException, IOException {
    // Set the MIME type for the response content.
    resp.setContentType("text/html");

    // Get an output stream to use in sending the output to the client.
    ServletOutputStream out = resp.getOutputStream();
    // Put together the HTML code for the output.
    out.println("<html>");
    out.println("<head><title>Hello World</title></head>");
    out.println("<body>");
    out.println("<h1>Hi There!</h1>");
    out.println("</body></html>");
  }
}

サーブレットのコンパイルおよびデプロイ

サンプル・サーブレットのコードをOC4Jスタンドアロン環境で使用する場合は、OC4JのデフォルトのWebアプリケーションの/WEB-INF/classesディレクトリ内にHelloServlet.javaとして保存してください。（詳細は、「OC4JのデフォルトのアプリケーションおよびデフォルトのWebアプリケーション」を参照してください。）

次に、サーブレットをコンパイルします。最初に、OC4Jにより提供される、servlet.jarがCLASSPATH内にあることを確認してください。これには、Sun社のjavax.servletおよびjavax.servlet.httpパッケージが含まれます。

注意 開発時およびテスト時に、サーブレット・コードに対してOC4Jの自動コンパイル機能を使用すると便利です。この機能は、OC4J構成ファイル・ディレクトリにあるglobal-web-application.xmlファイルの<orion-web-app>要素の設定development="true"を使用して有効化します。source-directory属性も適切に設定する必要があります。自動コンパイルが有効な場合、変更したサーブレット・ソースを適切なディレクトリに保存すると、OC4Jサーバーは、次の起動時にサーブレットを自動的にコンパイルし、再デプロイします。 developmentおよびsource-directoryの詳細は、「global-web-application.xmlおよびorion-web.xmlの要素の説明」を参照してください。

サーブレットの実行

OC4Jサーバーが起動されていて稼働中であり、クラス名による起動が/servlet/のservlet-webdirの組込みデフォルト設定で有効になっている場合には、次のようにサーブレットを起動して、その出力をWebブラウザに表示できます。hostは、OC4Jサーバーが実行されているホストの名前、portは、Webリスナーのポートです。

http://host:port/servlet/HelloServlet

（クラス名による起動およびOC4Jのservlet-webdir属性の詳細は、「OC4J開発時におけるクラス名によるサーブレットの起動」を参照してください。）

OC4Jスタンドアロン環境では、ポート8888を使用してOC4J Webリスナーに直接アクセスします。（概要は、「開発用OC4Jスタンドアロン」を参照してください。）

この例では、「/」はWebアプリケーションのコンテキスト・パスです。OC4Jスタンドアロンでは、これがデフォルトのWebアプリケーションに対するデフォルトのコンテキスト・パスです。

重要 ここに示すサーブレットの起動方法は、クラス名によって直接起動します。これは開発環境には適していますが、重大なセキュリティ上のリスクが発生します。本番環境では、OC4Jをこのモードで動作するよう構成しないでください。詳細は、「OC4J開発時におけるクラス名によるサーブレットの起動」および「その他のセキュリティに関する考慮事項」を参照してください。