Web アプリケーションコンポーネントをリクエストの URL にマッピングする方法によって、ユーザーのエントリポイントが定義されます。マッピングをどのように設定するかによって、ユーザーのブラウザのアドレスバーの表示や JRun によるリクエストの処理方法が変わります。このセクションでは、暗黙の JRun マッピングを説明し、サーブレットや JSP などの Web アプリケーションや Web コンポーネントに独自のマッピングを確立する方法を説明します。
Web アプリケーションのマッピングを確立するには、そのアプリケーションのアセンブルとデプロイの方法を理解する必要があります。運用環境では、モジュールを適切なアーカイブファイルにパッケージしてデプロイすることをお勧めします。詳細については、『JRun アセンブルとデプロイガイド』を参照してください。
クライアントは、他の Web リソースと同様に、URL をリクエストすることによってサーブレットを呼び出します。次の図で示すように、URL はプロトコル、ホスト、ポート (オプション)、リクエスト URI で構成されています。
リクエスト URL を分解するサンプルサーブレットを表示するには、Samples JRun サーバを起動し、ブラウザで http://localhost:8200/techniques を開きます。
JRun 4.0 は、サーブレット API バージョン 2.3 の仕様書に記述されている Web アプリケーションアーキテクチャを完全に実装しています。この実装には、仕様に準拠したサーブレットへのリクエストのマッピングが含まれています。
アプリケーションマッピングとサーブレットマッピングは、リクエスト URI をいくつかのコンポーネントに分割し、その URI の異なる部分を使用して、呼び出すリソースを決定します。次の表でこれらのコンポーネントを説明します。
JRun では、リクエストに応えてサービスするファイルを決定するときに、次のタイプのマッピングを使用します。
/servlet
などの接頭辞、または *.jsp
などの接尾辞に関連付けます。JRun サーバで実行される各 Web アプリケーションは、1 つのアプリケーションマッピングと複数のサーブレットマッピングを定義できます。Web アプリケーションを最適な方法で使用するには、HTML ファイル、JSP、およびサーブレットに対するリクエストを処理するために、JRun がどのようにアプリケーションマッピングとサーブレットマッピングを使用するかを理解する必要があります。
次の表は、JRun 設定ファイルが定義するマッピングをリストします。
アプリケーションマッピングは、コンテキストパスを Web アプリケーションの名前とディレクトリパスに関連付けます。これらのマッピングは、JRun 管理コンソール (JMC) を使用して管理します。JRun は、アプリケーションマッピングを META-INF/application.xml ファイルで維持します。
このマッピングは、Web サーバのファイルシステム内の Web アプリケーションの物理的位置と一致する必要はありません。たとえば、myapp
が Web アプリケーションのドキュメントルートディレクトリの場合に、Web アプリケーションをサーバのディレクトリ c:/apps/myapp
に配置しているものとします。Web アプリケーションのディレクトリ構造は、myapp
の下です。
この場合、Web アプリケーションが http://www.mycomp.com/myapp の形式で URL に応答するように、/myapp
に対してアプリケーションの URL マッピングを作成できます。このマッピングを設定すると、/myapp
コンテキストパスを含むすべての URL が Web アプリケーションにマッピングされます。
アプリケーションアセンブル担当者は、すべての Web モジュールのコンテキストルートを定義します。アプリケーションアセンブル担当者は、このコンテキストルートがアプリケーション内の他のどのモジュールのコンテキストルートとも重複しないようにします。
リクエストが到着すると、JRun はそのリクエストをできるだけ最長のマッピングにマッピングしようと試みます。つまり、リクエスト URI に /foo/bar が含まれている場合は、JRun は最初に /foo/bar のマッピングを見つけようとします。これに失敗すると、JRun は /foo のマッピングを見つけようとします。一致するものを見つけられない場合、JRun は、このリクエストを / にマッピングします。サーブレットが / にマッピングされると、JRun は サーブレットパス情報として foo/bar を割り当てます。
JRun サーバでルートにマッピングできる Web モジュールは 1 つだけであり、すべての Web モジュールに固有のマッピングが必要です。JRun サーバに到着したリクエストに明示的なマッピングがない場合、リクエストはルートにマッピングされた Web アプリケーションに送信されます。
Web アプリケーションに application.xml ファイルがない場合は、このアプリケーションを EAR ファイルとしてパッケージし、このファイルを定義する必要があります。詳細については、『JRun アセンブルとデプロイガイド』を参照してください。
Web アプリケーションのルートへのすべてのリクエストを 1 つのサーブレットでキャッチする場合は、このサーブレットが / に一致するように URL パターンを設定する必要があります。これは、モデル - ビュー - コントローラなどのデザインパターンを実装するときの一般的なタスクであり、この場合は、1 つのサーブレットがコントローラまたはディスパッチャとして機能する必要があります。
たとえば、techniques-ear ファイルには Web モジュール techniques-war が含まれています。このモジュールのコンテキストルートは /techniques です。JRun が http://www.yourhost.com/techniques などのリクエストを受け取った場合、このリクエストは techniques-war モジュールにマッピングされます。次に JRun は、サーブレットマッピングについて techniques モジュールの web.xml ファイルをチェックします。
アプリケーションアセンブル担当者が、コンテキストルートにルート (/) マッピングを与えておらず、リクエストが他のマッピングと一致しない場合は、JRun は、リクエストしているユーザーに Web サーバのルートディレクトリからインデックスファイルを返します。利用可能なインデックスファイルがない場合、JRun はディレクトリリストを返します。ディレクトリリストがオフになっている場合、JRun はエラーをユーザーに返します。
デプロイするアプリケーションのタイプによっても異なりますが、Web アプリケーションのコンテキストルートを定義する方法は複数あります。このセクションでは、EAR ファイルと WAR ファイルのためにコンテキストルートを定義する方法を説明します。
EAR ファイルをデプロイする場合は、次のシンタックスを使用して、/META-INF/application.xml ファイルで各 Web モジュール用にコンテキストルートを定義します。
<module><web>
<web-uri>module-name</web-uri> <context-root>mapping</context-root> </web></module>
次の例では、techniques-war Web モジュールを /techniques にマッピングします。
<module><web>
<web-uri>techniques-war</web-uri> <context-root>/techniques</context-root> </web></module>
application.xml ファイル内で各 Web モジュール用に context-root 要素を設定する必要があります。コンテキストルートを指定しないと、Web モジュールはエンタープライズアプリケーションからアクセスできません。
Web モジュールを WAR ファイルとしてホットデプロイする場合は、jrun-web.xml ファイルでコンテキストルートを定義するか、JRun に定義させることができます。
次の表で、サーブレットをリクエスト URI にマッピングするためのいくつかのテクニックを説明します。
サーブレットマッピングは、サーブレットを URL パターンに関連付けます。URL パターンには、/MyServlet
などの接頭辞、または *.jsp
などの接尾辞を使用できます。指定された URL パターンに一致するサーブレットパスがリクエスト URI に含まれる場合、JRun は関連付けられたサーブレットを呼び出します。サーブレットを明示的に定義しない場合は、/servlet 暗黙マッピングを使用して WEB-INF/classes ディレクトリに保管してあるサーブレットをリクエストできます。詳細については、 「暗黙のサーブレットマッピング」 を参照してください。
default-web.xml ファイルの次の行で、*.jsp のパターンを JSPServlet にマッピングし、AxisServlet を /services にマッピングします。
<servlet-mapping>
<servlet-name>AxisServlet</servlet-name> <url-pattern>/services</url-pattern> </servlet-mapping> <servlet-mapping> <servlet-name>JSPServlet</servlet-name> <url-pattern>*.jsp</url-pattern> </servlet-mapping>
Web サーバがページやサーブレットに対するリクエストを受信すると、JRun は、まずリクエスト URI のコンテキストパスを、JRun に定義されているアプリケーション URL マッピングと比較して、Web アプリケーションを検索します。Web アプリケーションが見つかると、JRun はその Web アプリケーションのサーブレットマッピングを使用して、指定されたリソースを検索します。コンテキストパスに一致するアプリケーションマッピングが見つからないと、JRun はその Web サーバのデフォルトのアプリケーションのサーブレットマッピングを使用してリソースを検索します。
明示的サーブレットマッピングは、web.xml ファイルで定義および管理できます。セキュリティを最大にするには、運用アプリケーションで、Web アプリケーションの各サーブレットごとに明示的サーブレットマッピングを定義する必要があります。
サーブレットマッピングの url-pattern
には、先頭のスラッシュは必要ありません。
web.xml ファイルでの明示的サーブレットマッピングだけでなく、JRun は各 JRun サーバの default-web.xml ファイルでの一連の暗黙のサーブレットマッピングを維持します。これらのマッピングは JRun サーバ内のすべてのアプリケーションによって共有されます。次の表で、これらのマッピングについて説明します。
Web アプリケーションの web.xml ファイルで新しいマッピングを定義することにより、その Web アプリケーションの暗黙のサーブレットマッピングをオーバーライドできます。つまり、default-web.xml ファイルのすべてのアプリケーションのマッピングを変更できます。たとえば、/servlet を LoginServlet または 404Servlet に関連付けることで、ServletInvoker サーブレットのデフォルトサーブレットマッピングを変更できます。
JRun には、/servlet を ServletInvoker サーブレットに関連付けるサーブレットマッピングが含まれています。このサーブレットマッピングにより、サーブレットパス /servlet を含むリクエスト URI は、ServletInvoker サーブレットによって処理されるようになります。ServletInvoker サーブレットには、web.xml ファイルや default-web.xml ファイルでは明示的に定義されていないサーブレットのための汎用呼び出しメカニズムが用意されています。
次の部分では、default-web.xml ファイルの ServletInvoker のマッピングを示しています。
<servlet-mapping>
<servlet-name>ServletInvoker</servlet-name> <url-pattern>/servlet/</url-pattern> </servlet-mapping>
このマッピングは、開発フェーズやテストフェーズで役立ちます。これにより、サーブレットマッピングを明示的に定義する必要がなくなります。ServletInvoker サーブレットが、クラス名を使用して仮のサーブレット登録を自動的に作成するからです。
セキュリティとパフォーマンス上の理由から、すべてのサーブレットに対して明示的マッピングを定義して、運用システムのデフォルトの ServletInvoker マッピングをオーバーライドする必要があります。運用アプリケーションでは、カスタマイズしたサーブレットが常にエラーを返す場合に、たとえば次のように、そのサーブレットに /servlet のマッピングを関連付ける方法も考えられます。
/servlet = 404servlet
JRun は次の方法で ServletInvoker サーブレットを使用します。
/app1/servlet/SnoopServlet
)。
/app1
)。
/servlet
)。
/SnoopServlet
)。
ServletContext.getNamedDispatcher(
servletname)
を呼び出して、サーブレットを呼び出します。JRun は最初に Web アプリケーションの web.xml ファイルと default-web.xml ファイルを調べて、このサーブレットが定義されているかどうかを判断します。一致するサーブレットが見つからない場合、JRun は アプリケーションのクラスパスにリストされたディレクトリ内でサーブレットを検索し、サーブレットのクラス名を使用してインスタンスを作成します。
JRun では、サーブレット仕様に従って web.xml で指定されるウェルカムファイルをサポートしています。次の例に示すように、web.xml ファイルでウェルカムファイルを定義します。
<welcome-file-list>
<welcome-file>index.html</welcome-file> <welcome-file>welcome.html</welcome-file> </welcome-file-list>
welcome-file は、前後のスラッシュがない URI の一部分です。クライアントがディレクトリへのリクエストを行ったときに、JRun は welcome-file エントリをリクエストされたディレクトリに追加し、一致するものが見つかった場合は、そのリクエストを転送します。一致する welcome-file が見つからない場合やサービスできない場合は、リスト内の次の welcome-file を使用しようとします。また、welcome-file エントリがないと、JRun はクライアントにディレクトリリストを返します。ディレクトリリストがオフになっていると、JRun はエラーを返します。
ディレクトリ表示をオフにする方法については、『JRun 管理者ガイド』を参照してください。
JRun は、アプリケーションマッピングとサーブレットマッピングに従って、URL の URI 部分をコンテキストパス、サーブレットパス、追加パス情報に分割します。
たとえば、/hrapp
のアプリケーションマッピングが application.xml ファイルにあり、/
NewEmpServlet
のサーブレットマッピングが web.xml ファイルにあり、リクエスト URI が /hrapp/NewEmpServlet/login?empid=61355
の場合、JRun は次のように判断します。
URI コンポーネント |
定義 |
---|---|
/hrapp |
コンテキストパス |
/NewAppServlet |
サーブレットパス |
/login |
パス情報 |
empid=61355 |
クエリ文字列パラメータ |
アプリケーションマッピングがなく URI が同じ場合、結果は次のようになります。
URL コンポーネント |
定義 |
---|---|
(空) |
コンテキストパス |
/hrapp/NewEmpServlet |
サーブレットパス |
/login |
パス情報 |
empid=6139 |
クエリ文字列パラメータ |
メモ: リクエスト URI とパス部分の URL エンコードが異なる場合を除き、次のステートメントは常に true になります。RequestURI
= contextpath
+ servletpath
+ pathinfo
サーブレット内からコンテキストとパス情報にアクセスできます。次の例は、リクエストから ServletContext 情報を取得するメソッドの使用方法を示しています。
...
ServletContext context = getServletContext(); out.println("コンテキストパス:" + req.getContextPath()); out.println("<BR>サーブレットパス:" + req.getServletPath()); out.println("<BR>パス情報:" + req.getPathInfo()); out.println("<BR>実際のパス:" + context.getRealPath(req.getServletPath())); ...
次の例では、Referer
HTTP ヘッダーも使用して、「Back」リンクを構築します。
String referer = req.getHeader("Referer");
out.println("<BR><A HREF=¥"" + referer + "¥">Back</A>");
サンプルサーブレットを表示するには、samples JRun サーバを起動し、ブラウザで http://localhost:8200/techniques を開きます。