JRun によるアプリケーションの開発 戻る 上のレベルへ 進む
JRun によるサーブレットへの 要求のマッピング


JRun によるファイルの提供

既定のアプリケーションは Web ルート (/) にマッピングするため、JRun は、Web サーバーに送信されるすべての要求を調べます。JRun では、高度なコーディング テクニックを使用して、パフォーマンスを低下させることなく JRun 以外の Web サーバーのファイルを提供できるようにしています。

次のセクションでは、JRun Web サーバーの対話について説明し、2 つのファイル サービス事例を記載します。

Web サーバーの対話

Web サーバーは、着信したすべての要求を JRun に渡します。JRun は、既定および既定以外のアプリケーション用のアプリケーション マッピングと、暗黙的および明示的サーブレット マッピングを使用して、次の図で示すように各要求を処理します。

各 Web サーバーは、既定の Web アプリケーションを個々に所有します。

アプリケーション URL マッピング、サーブレット マッピング、および Web サーバーのファイルの存在に応じて、JRun は次のいずれかの操作を行います。

JRun は、既定のアプリケーションを除くすべてのクライアントにエラーを直接返します。したがって、Web サーバー用に定義された、404 エラーの処理用ページなどのカスタム エラー ページは使用されません。ただし、JRun アプリケーション用にカスタム エラー ページを定義することで、同じ機能を実装できます。

事例

次のセクションでは、2 つの事例を記載します。それぞれの事例でアクセスの例をいくつか示します。

各事例では、次の内容を説明します。

各例では、次の内容を記載します。

単一の既定の Web アプリケーション

この事例では、単一の既定の Web アプリケーションを使用します。既定の Web アプリケーションは、Web サーバーのルート (/) にマッピングします。この事例では、次の暗黙的サーブレット マッピングも使用します。

次の表は、単一の既定のアプリケーションに対してファイルを提供するアクセスの例を示します。
要求 URI
JRun の応答
実際に解決される
ドキュメント
処理順序
 
/index.html
スラッシュ (/) は既定のアプリケーションに相当しますが、既定のアプリケーションには対応するサーブレット マッピングがありません。JRun は、Web サーバーに制御を返します。
 
webroot/index.html
  1. 既定のアプリケーション
  2. Web サーバー
 
/app1
/index.html
app1 対するアプリケーションマッピングがないため、JRunは既定のアプリケーションを使用します。既定のアプリケーションには対応するサーブレット マッピングがありません。JRun は、Web サーバーに制御を返します。
 
webroot/app1/
index.html
  1. 既定のアプリケーション
  2. Web サーバー
 
/app1/foo
/bar.jsp
app1 対するアプリケーション マッピングがないため、JRun は既定のアプリケーションを使用します。既定のアプリケーションには、*.jsp に対するサーブレット マッピングがあるため、JRun は jsp サーブレットを呼び出し、jsp サーブレットは、 Web サーバーと通信してパスを解決します。
 
webroot/app1/foo/
bar.jsp
  1. 既定のアプリケーション
  2. jsp サーブレット
  3. generatedname.class
 
/app1/snoop
app1 対するアプリケーション マッピングがないため、JRun は既定のアプリケーションを使用します。既定のアプリケーションには、対応するサーブレット マッピングがないため、JRun は要求を Web サーバーに返し、Web サーバーは 404 をクライアントに返します。
 File not found (404)
  (この例を機能させるには、
/app1/snoop に対してサーブレット マッピングを定義します。)
  1. 既定のアプリケーション
  2. Web サーバー
 		 
/servlet/
SnoopServlet
/servlet 対するサーブレット マッピングがないため、JRun は制御を invoker サーブレットに渡します。
 サーブレットには適用されません。
  1. 既定のアプリケーション
  2. invoker サーブレット
  3. SnoopServlet

JRun サーバーに複数の Web アプリケーションが存在する場合

この事例では、次のアプリケーションを使用します。

両方の Web アプリケーションで、次の暗黙的サーブレット マッピングを使用します。

次の表は、複数のアプリケーションに対するファイルの提供の例を示します。
要求 URI
JRun の応答
実際に解決される
ドキュメント
処理順序
 
/index.html
スラッシュ (/) は既定のアプリケーションに相当しますが、既定のアプリケーションには一致するサーブレット マッピングがありません。JRun は、Web サーバーに制御を返します。
 
webroot/index.html
  1. 既定のアプリケーション
  2. Web サーバー
 
/app1
/index.html
JRun は App1 アプリケーションを使用して、Web アプリケーションのルートで見つかった index.html ファイルを提供します。
 
approot/index.html
  1. App1 アプリケーション
 
/app1/foo
/bar.jsp
JRun は App1 アプリケーションを使用します。App1 アプリケーションには、*.jsp に対するサーブレット マッピングがあるため、JRun は jsp サーブレットを呼び出し、jsp サーブレットはアプリケーション マッピングを使用して、パスを解決します。
 
approot/foo/bar.jsp
  1. App1 アプリケーション
  2. jsp サーブレット
  3. generatedname.class
 
/app1/snoop
JRun は App1 アプリケーションを使用します。App1 アプリケーションには、/snoop に対するマッピングがあるため、JRun は制御を関連するサーブレット (SnoopServlet) に渡します。
 サーブレットには適用されません。
  1. App1 アプリケーション
  2. SnoopServlet
 
/app1
/servlet/
SnoopServlet
JRun は App1 アプリケーションを使用します。App1 アプリケーションには、/servlet に対するマッピングがあるため、JRun は制御を
invoker サーブレットに渡します。
 サーブレットには適用されません。
  1. App1 アプリケーション
  2. invoker サーブレット
  3. SnoopServlet

Copyright © 2001, Macromedia Inc. All rights reserved. 戻る 上へ 進む