![]() ![]() ![]() ![]() |
以下の節では、サーブレットを作成およびコンフィグレーションする方法について説明します。
Java EE メタデータ アノテーションの使用により、標準の web.xml
デプロイメント記述子は省略可能になりました。Servlet 2.5 仕様では、サーブレット、フィルタ、リスナ、タグ ハンドラなどの特定の Web コンポーネントでアノテーションを定義できると規定されています。アノテーションを使用すると、外部リソースに対する依存性を宣言できます。コンテナはこれらのコンポーネントのアノテーションを検出し、コンポーネントのライフサイクル メソッドが呼び出される前に必要な依存性を注入します。「Web コンポーネント用の WebLogic アノテーション」を参照してください。
ただし、サーブレットは、標準の Web アプリケーション デプロイメント記述子 web.xml の複数のエントリで Web アプリケーションの一部としても定義できます。web.xml
ファイルは、Web アプリケーションの WEB-INF
ディレクトリにあります。
web.xml のルート servlet
要素の下の最初のエントリには、サーブレットの名前が定義され、そのサーブレットを実行するコンパイル済みクラスが指定されます。あるいは、サーブレット クラスを指定する代わりに、JSP を指定することもできます。servlet
要素には、サーブレットの初期化属性とセキュリティ ロール用の定義も含まれています。
web.xml 内の servlet-mapping
要素の下の 2 番目のエントリには、このサーブレットを呼び出す URL パターンが定義されています。
サーブレット マッピングとは、サーブレットへのアクセス方法を制御することです。次の例は、Web アプリケーションでサーブレット マッピングを使用する方法を示しています。この例には、(web.xml
デプロイメント記述子の) サーブレット コンフィグレーションとマッピングがあり、その後にこれらのサーブレットの起動に使う URL を示す表 (「url-pattern と呼び出されるサーブレット」を参照) があります。
一般的なサーブレット マッピングのルールや規約など、サーブレット マッピングの詳細については、Servlet 2.5 仕様のセクション 11 を参照してください。
<servlet>
<servlet-name>watermelon</servlet-name>
<servlet-class>myservlets.watermelon</servlet-class>
</servlet>
<servlet>
<servlet-name>garden</servlet-name>
<servlet-class>myservlets.garden</servlet-class>
</servlet>
<servlet>
<servlet-name>list</servlet-name>
<servlet-class>myservlets.list</servlet-class>
</servlet>
<servlet>
<servlet-name>kiwi</servlet-name>
<servlet-class>myservlets.kiwi</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>watermelon</servlet-name>
<url-pattern>/fruit/summer/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>garden</servlet-name>
<url-pattern>/seeds/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>list</servlet-name>
<url-pattern>/seedlist</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>kiwi</servlet-name>
<url-pattern>*.abc</url-pattern>
</servlet-mapping>
ServletServlet は、サーブレットのデフォルト マッピングの作成に使用できます。たとえば、/myservlet/* に対するすべてのサーブレットにマップするデフォルト マッピングを作成すると、http://host:port/web-app-name/myservlet/com/foo/FooServlet を使用してサーブレットを呼び出せます。このデフォルト マッピングを作成するには、web.xml ファイルに次のコードを追加します (web.xml
ファイルは、Web アプリケーションの WEB-INF
ディレクトリにあります)。
<servlet>
<servlet-name>ServletServlet</servlet-name>
<servlet-class>weblogic.servlet.ServletServlet</servlet-class>
</servlet>
<servlet-name>ServletServlet</servlet-name>
<url-pattern>/myservlet/*</url-pattern>
</servlet-mapping>
各 Web アプリケーションには、デフォルト サーブレットがあります。このデフォルト サーブレットは管理者が指定できますが、指定しない場合、WebLogic Server では FileServlet
という内部サーブレットがデフォルト サーブレットとして使用されます。
どのサーブレットでも、デフォルト サーブレットとして登録できます。独自のデフォルト サーブレットを作成すれば、独自のロジックを使用して、デフォルト サーブレットに送られる要求の処理方法を定義できます。
設定したデフォルト サーブレットは、FileServlet
に取って代わります。FileServlet
はほとんどのファイル (テキスト ファイル、HTML ファイル、イメージ ファイルなど) を提供するために使用されるので、デフォルト サーブレットの設定は注意深く行う必要があります。デフォルト サーブレットでこれらのファイルを提供するには、その機能をデフォルト サーブレットに記述する必要があります。
ユーザ定義のデフォルト サーブレットを設定するには、次の手順に従います。
<servlet-mapping>
<servlet-name>MyOwnDefaultServlet</servlet-name>
<url-pattern>/myservlet/*(</url-pattern>
</servlet-mapping>
FileServlet
で他の拡張子付きのファイルを提供する場合は、次の手順に従います。注意 : | docHome パラメータ (このリリースで非推奨になった) が指定されていない場合、ソース ファイル名決定時の FileServlet には、SERVLET_PATH が含まれています。そのため、FileServlet を /dir/* などにマップすることで、特定のディレクトリからのファイルのみを明示的に提供できます。 |
サーブレットの初期化属性は、Web アプリケーションのデプロイメント記述子 web.xml の中の servlet
要素の init-param
要素に、param-name
タグと param-value
タグを使って定義します。web.xml
ファイルは、Web アプリケーションの WEB-INF
ディレクトリにあります。次に例を示します。
<servlet>
<servlet-name>HelloWorld2</servlet-name>
<servlet-class>examples.servlets.HelloWorld2</servlet-class>
<init-param>
<param-name>greeting</param-name>
<param-value>Welcome</param-value>
</init-param>
<init-param>
<param-name>person</param-name>
<param-value>WebLogic Developer</param-value>
</init-param>
</servlet>
この節では、Hello World というメッセージを出力する単純な HTTP サーブレットを記述する手順について説明します。これらの手順を示すサンプル コード (HelloWorldServlet
) の全文がこの節の最後にあります。JDBC、RMI、JMS など各種の Java EE および WebLogic Server サービスをサーブレットで使用する方法の詳細については、このマニュアルで後述します。
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
javax.servlet.http.HttpServlet
を拡張します。次に例を示します。public class HelloWorldServlet extends HttpServlet{
service()
メソッドを実装します。
サーブレットの主要な機能は、Web ブラウザからの HTTP リクエストを受け取って、HTTP 応答を返すことです。この処理は、サーブレットの service()
メソッドによって行われます。サービス メソッドには、出力を生成する応答オブジェクトと、クライアントからのデータを受け取る要求オブジェクトがあります。
これ以外にも、doPost()
メソッドや doGet()
メソッドを実装したサーブレットのサンプルを見たことがあるかもしれません。これらのメソッドは、POST または GET 要求にのみ応答するものです。service()
メソッドを実装しておけば、1 つのメソッドですべての要求タイプを処理できます (ただし、service()
メソッドを実装した場合、このメソッドの最初で super.service()
を呼び出さない限り、doPost()
メソッドや doGet()
メソッドを実装することはできません)。HTTP サーブレットの仕様ではこれ以外に、他の要求タイプの処理に使用されるメソッドも解説していますが、全部をまとめて、サービス メソッドと総称しています。
サービス メソッドはすべて、同じパラメータ引数を取ります。HttpServletRequest
は、要求の情報を提供し、HttpServletResponse
は HTTP クライアントに応答する際にサーブレットによって使用されます。サービス メソッドは次のようになります。
public void service(HttpServletRequest req,
HttpServletResponse res) throws IOException
{
res.setContentType("text/html");
java.io.PrintWriter
オブジェクトへの参照を取得します。PrintWriter out = res.getWriter();
PrintWriter
オブジェクトに対し println()
メソッドを使用して、HTML を生成します。out.println("<html><head><title>Hello World!</title></head>");
out.println("<body><h1>Hello World!</h1></body></html>");
}
}
サーブレットの呼び出しに使用する URL は、(a) そのサーブレットが含まれる Web アプリケーション名、(b) Web アプリケーションのデプロイメント記述子にマップされるサーブレット名によって決まります。要求パラメータも、サーブレットを呼び出す URL に含まれることがあります。
一般的には、サーブレットの URL は以下のパターンに従います。
http://host:port/webApplicationName/mappedServletName?parameter
host
は、WebLogic Server が稼動しているマシンの名前。port
は、上記マシンが HTTP リクエストをリスンしているポート。webApplicationName
は、サーブレットが含まれる Web アプリケーションの名前。
たとえば、examplesWebApp
にデプロイされ、使用中のマシンで稼動している WebLogic Server から提供される HelloWorldServlet
(このマニュアルで使われているサンプル) を Web ブラウザで呼び出す場合、次のような URL を入力します。
http://localhost:7001/examplesWebApp/HelloWorldServlet
URL の host
:
port
部分は、WebLogic Sever にマップされている DNS 名に置き換えることもできます。
上記の手順で、基本的なサーブレットが作成できます。サーブレットでは、さらに高度な機能を使用することもできます。
init()
メソッドをオーバーライドできます。
この節では、前述の手順で使用したサンプル Java ソース コードの全文を示します。このサンプルは HTTP リクエストに応答する簡単なサーブレットです。このマニュアルの後半では、このサンプルを拡張することにより、HTTP パラメータ、クッキー、およびセッション トラッキングの使い方を説明します。
import javax.servlet.*;
import javax.servlet.http.*;
import java.io.*;
public class HelloWorldServlet extends HttpServlet {
public void service(HttpServletRequest req,
HttpServletResponse res)
throws IOException
{
// 先にコンテンツ タイプを設定する
res.setContentType("text/html");
// ここで HTML を挿入する PrintWriter を取得する
PrintWriter out = res.getWriter();
out.println("<html><head><title>" +
"Hello World!</title></head>");
out.println("<body><h1>Hello World!</h1></body></html>");
}
}
WebLogic Server 配布キットの samples/examples/servlets
ディレクトリに、このソース コードと、サンプルをコンパイルして実行するための手順説明があります。
以降の節では、WebLogic Server サーブレット コンテナで利用可能なデバッグ オプションについて説明します。
サーブレットのアクセスのロギングは、サーバのパフォーマンスに関してはコスト高となる場合があります。したがって、アクセス ロギングが不要な場合は、アクセス ログ ファイルへのロギングを無効化することによりパフォーマンスを向上することができます。
weblogic.xml
の container-descriptor
で指定可能な disable-access-logging
プロパティは、基底の Web アプリケーションのアクセス ロギングを無効化するかどうか指定する際に使用することができます。
注意 : | disable-access-logging プロパティは、Web アプリケーション レベルで機能します。したがって、このプロパティを 1 つの Web アプリケーションで定義しても、他の Web アプリケーションには影響しません。このプロパティは、開発モードとプロダクション モードの両方で機能します。 |
<?xml version="1.0" encoding="ISO-8859-1"?>
<weblogic-web-app xmlns="http://www.bea.com/ns/weblogic/90">
<container-descriptor>
<disable-access-logging>true</disable-access-logging>
</container-descriptor>
</weblogic-web-app>
セッション変化の追跡は、特にレプリケートされるセッションに関して、アプリケーションの開発時に大いに役立ちます。HttpSessionAttributeListener
を利用すると、セッションの変化を Web アプリケーション レベルで追跡できますが、開発者は、特定の要求時にセッション変化を追跡するため、より詳細なデバッグ オプションを指定する必要があります。
wl_debug_session
要求属性または同じ名前のセッション属性は、現在のセッションにおける属性の変化をロギングすることができます。いずれかのフラグを使用すると、基底のセッションの変更がコンテナによってサーバ ログに記録されます。
以下のいずれかの方法で特定セッションのデバッグを有効化することができます。
セッションのデバッグを停止するには、単に wl_debug_session
属性を削除します。
注意 : | この機能は開発モードでのみ使用できます。デバッグ メッセージの重大度は、debug レベルです。システム ロガーがデバッグ メッセージをサーバ ログ ファイルに出力できるように、ロガーの重大度は debug 以下に調整する必要があります。 |
要求ハンドルの処理内容の追跡は、アプリケーション開発モードの場合に大いに役立ちます。たとえば、アプリケーションのデバッグ時には多くの情報が必要になります。これには、どのような要求を受信したか、その要求がどのようにディスパッチされたか、どのセッションにバインドされたか、サーブレットがいつ関与したか、どのような応答が送信されたかなどの情報が含まれます。最後に、ServletException
が発生したら、エラーの原因を探るため、その例外を対応する要求に結び付ける方法が必要となります。
WLS サーブレット コンテナでは、より詳細なログ メッセージが要求の処理時に提供されるため、要求フロー内の各イベントがより詳細に表現されます。DebugHttp
ロガーを有効化する以外、コンフィグレーションを変更する必要はありません。
このようにすると、要求ハンドルの処理内容をサーバ ログで見つけることができます。プロダクション モードに移行したら、DebugHttp
ロガーを無効化し、サーバのパフォーマンスを最大化する必要があります。
![]() ![]() ![]() |