はじめに

月5日 快晴、今日も驚くほどの晴天が続きます。

今日でJavaWebの勉強は3日目。

tomcatの 使い方はとても簡単で、解凍してビンに移動し、 startup.batをクリックすると実行されます！

サーブレットは 単純で、.javaを作成し、HttpServletを継承し、メソッドを書き換えて、web.xmlを設定すれば完了です！

簡単

10％オフ？90パーセントオフ？

数日前にサーブレットに出会ってからというもの、私の頭の中には100,000もの疑問がつきまといます。

Servletを使用することは非常に簡単かもしれません、そのコードは私が理解することができますが、私はどのように、私はいつも、Servletは、それが実際に何であるか、それが実際に何を行うのだろうか...不思議に思っていません。

コードはすべてノックアウトされていますが、雲の上を歩いているような、柔らかくて不安定な感じです。

この記事は、綿密かつ高尚なtomcat、サーブレットのソースコードではありませんが、私にとって、この鶏は現実的ではありません、この記事は、唯一の個人的な研究ノートとして、櫛の唯一のtomcat、サーブレットの性質です！

フロントロウからのヒント：この記事は長いので、読んで得るものがあれば幸いです：

本体

ウェブサーバ、ウェブミドルウェア、ウェブコンテナ

サーブレットを探求するには、ウェブ・コンテナの概念とウェブ・サーバーとの関係を理解する必要があると思います。

• ウェブサーバー：広義には、ウェブサービスソフトウェアまたはホストを提供するウェブサーバー、つまりウェブサーバーソフトウェアまたはウェブサーバーソフトウェアを搭載したコンピュータ。

  例：IIS、apache、nginxなど。

  ウェブサーバーは、HTTPプロトコルを処理したり、静的ページやイメージのリクエストに応答したり、ページジャンプを実行したり、動的リクエストを他のプログラムに委譲したりすることができます。

  つまり、IIS、Apache、Nginx、TomcatなどをWebサーバーと呼ぶことができます。

• ミドルウェア：システムソフトウェアとアプリケーションソフトウェアの接続を提供し、ソフトウェアコンポーネント間の通信を容易にするソフトウェア

  ミドルウェアは、オペレーティング・システムと上位アプリケーションの間に位置します。

  アプリケーション環境をオペレーティング・システムから切り離すことで、アプリケーション開発者はシステムの追加問題を心配する必要がなく、むしろアプリケーションの問題解決能力に直接集中することができます。

  要するに、オペレーティングシステムとアプリケーションの間には、アプリケーション自体のビジネスロジックにもっと注意を払い、オペレーティングシステムやその基礎となるものとのやり取りにはあまり注意を払わないようにする中間媒体が必要なのです。APIの優先順位

• コンテナ：オペレーティング・システムとアプリケーションの橋渡しをするミドルウェアの一種

  コンテナ内のアプリケーション・コンポーネントに環境を提供し、アプリケーションが他のシステム問題を気にすることなく、コンテナ内の環境変数と直接やり取りできるようにします。

• Webコンテナ: JavaEEの仕様標準に準拠したWebサーバを、JavaEEではWebコンテナと呼びます。Webサービスを扱うコンテナ

  例：tomcat（サーブレットコンテナ）

  Webコンテナは、その中のアプリケーション・コンポーネントに環境を提供するために使われ、動的言語の解析を可能にするミドルウェアのコンポーネントです。例えば、TomcatがJSPを解析できるのは、内部に サーブレットコンテナが あるからです。

簡単に：

ウェブサーバー：外部へのサービス提供が可能

ミドルウェア：アプリケーションとシステムの相互作用を支援するソフトウェア

ウェブコンテナ：JavaEE仕様の標準に準拠し、アプリケーションとシステムのやり取りを可能にするミドルウェア。

3つの関係：ウェブサーバー＞ウェブミドルウェア＞ウェブコンテナ

Tomcat

Tomcatサーバーは、オープンソースの軽量Webアプリケーションサーバーであり、中小規模のシステムと小さな機会の並行処理が一般的に使用され、選択したサーブレット、JSPプログラムの開発とデバッグです。

トムキャットに関するほとんどのネット記事の最初の一文はこれだと思います。

私もコピーしました。

サーバーの役割は、乾物、Tomcatのアーキテクチャに直接、ここでは繰り返されません

Tomcat

• Servlet アーキテクチャ

• Servlet サーブレットとは何ですか？

Tomcatの構造図を見るときは、Tomcatのディレクトリを開き、confの下にあるserver.xml設定ファイルを見つけることをお勧めします！

• server.xml 設定ファイルを以下に示します：

Tomcatの主なコンポーネント：サーバー サーバー、サービス サービス、コネクタ コネクタ

コネクタとコンテナはTomcatの中核です。

コンテナコンテナと一緒に1つまたは複数のコネクタに加えて、一緒にいくつかの他のサポートコンポーネントは、サービスサービスを形成するために、サービスサービスは、外部機能を提供することができますが、 サービスサービスの生存は、環境を必要とし、この環境は、サーバーですサービスサービスの通常の使用のためのサーバーコンポーネントは 、サーバーコンポーネントの生存のための環境を提供 すると同時に、1つまたは複数のサービス サービスを管理することができます。Serverコンポーネントは、Serviceサービスの通常の使用のための環境を提供し、Serverコンポーネントは、同時に1つ以上のServiceサービスを管理することができます。

Tomcat 2つのコンポーネント

• コネクタ

  コネクタは 指定されたポートでクライアント要求をリッスンし、ブラウザから TCP 接続要求を受信し、要求側とのデータ交換に使用される 要求 および応答オブジェクトを作成します。

  その後、リクエストを処理するスレッドが生成され、 Request オブジェクトと Response オブジェクトを処理する Engineに 渡します 。

  Tomcatには2つの古典的なコネクタがあります：

  一方はブラウザからのHTTPリクエストを直接リッスンし、もう一方は他のウェブサーバからのリクエストをリッスンします。

  Connector の最も重要な機能は、接続要求を受信し、要求を処理するためにコンテナにスレッドを割り当てることです。

• コンテナ

コンテナは 、コンテナの親インターフェイスは、コンテナの設計は、それぞれ**エンジン、ホスト、コンテキスト、ラッパー、4つのサブコンテナコンポーネントで構成される責任設計パターンの典型的なチェーンです。

コンテキストは 親コンテナの Hostで 定義できますが、Hostは 必要ありません、しかし、戦争プログラムを実行するには、 Hostが必要です、戦争は web.xml ファイルを持っている必要があるため、このファイルの解像度は、 Hostが 必要になります、複数のHostがある場合は、トップコンテナで定義する必要があります Engineは 、親コンテナを持たないので、Engineは、完全なServletエンジンを表します。 Engineは 親コンテナを持たないため、 Engineは 完全な Servletエンジンを表します。

• エンジンコンテナ

  Engineコンテナは比較的シンプルで、いくつかの基本的な関連付けを定義するだけです。

• ホストコンテナ

  HostはEngineのサブコンテナです。 HostはEngine内の仮想ホストを表し、この仮想ホストの役割は複数のアプリケーションを実行することで、これらのアプリケーションのインストールとデプロイ、およびアプリケーションを識別できるようにすることです。そのサブコンテナは通常 Context で、サブコンテナの関連付けに加えて、Host が持つべき情報を保持します。

• コンテナ

  コンテキストの最も重要な機能は、その中のサーブレットインスタンスを管理することです、サーブレットインスタンスはラッパーとしてコンテキストに表示されます。単純なTomcatはエンジンとホストを持つことができません。コンテキストの最も重要な機能は、その中にServletインスタンスを管理することであり、Servletインスタンスはラッパーとしてコンテキストに表示され、もう一つのポイントは、コンテキストはどのようにそれを実行するために正しいServletを見つけることができますか？ Tomcat5以前はマッパクラスを介して管理することですが、Tomcat5は、この機能は、リクエストに移動された後、前のタイミング図では、サブコンテナの取得で見つけることができますリクエストを介して割り当てられています。

• ラッパーコンテナ

  Wrapperは、Servletを表し、Servletのロード（読み込み）、初期化、実行、リソース・リカバリーを含むServletの管理責任を負います。

その他のコンポーネント

Tomcat には、セキュリティ、ロガー、セッション、Mbeans、ネーミングなどの他の重要なコンポーネントがあります。これらのコンポーネントはコネクタとコンテナに必要なサービスを提供します。

Tomcatサーバの設定.xml

前回の記事で、Tomcatのアーキテクチャを大まかに理解しましたが、server.xmlによると、以下のようにTomcatの分割構造を感じることができます。

xmlファイルの構成構造は 、Tomcatのアーキテクチャに対応しています。

• ルート・ディレクトリは で、これがサーバを表し、 その下にサービスがあります。

  サービスは、エクゼキュータ、コネクタ、エンジンをラップして完全なサービスを形成します。

• 2つの があります。

  Connector は Tomcat がリクエストを受信するためのエントリポイントであり、各 Connector には専用のリスニングポートがあります。

  • HTTP/1.1 コネクタは、クライアントブラウザからの HTTP リクエストをポート 8080 で待ち受けます。

• 同じレベルにコネクターがあります。

  エンジンは、サービス内のすべてのリクエストの処理に責任を負います。

  Connector からリクエストを受信し、どの Host にリクエストを渡すかを決定します。 Host がリクエストを処理した後、Engine に結果を返し、Engine は Connector に結果を返します。

• エンジンがあります。 それはホストです。

  ホストは、1つまたは複数のウェブプロジェクトの管理を担当します。

• ホスト

server.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
 Server.xmlこのファイルの構成構造は、Tomcatのアーキテクチャに対応している。
 ルート・ディレクトリは<Server>サーブレットとはどのようなもので、どのように動作するのか？
-->
<Server port="8005" shutdown="SHUTDOWN">
 <!-- Listener すなわち、特定のイベントをリスンする役割を持つリスナーである。>
 <Listener className="org.apache.catalina.startup.VersionLoggerListener"/>
 <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on"/>
 <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"/>
 <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener"/>
 <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener"/>
 <!-- GlobalNamingResources JNDIを構成するには--。>
 <GlobalNamingResources>
 <Resource name="UserDatabase"
 auth="Container"
 type="org.apache.catalina.UserDatabase"
 description="User database that can be updated and saved"
 factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
 pathname="conf/tomcat-users.xml"/>
 </GlobalNamingResources>
 <!--
 <Server>次のうち1つだけある。<Service>サーブレットとはどのようなもので、どのように動作するのか？
 Serviceエクゼキュータ、コネクタ、エンジンをラップして完全なサービスを形成する
 -->
 <Service name="Catalina">
 <!--
 Executor サービス内のコンポーネントが使用するためにサービスが提供するスレッドプール。
 -->
 <!--<Executor name="SuperTomcat
 namePrefix="superTomcat/>-->
 <!--
 Connectorサーブレットは、Tomcatがリクエストを受け取るためのエントリー・ポイントであり、各コネクタには専用のリスニング・ポートが用意されている。
 ConnectorHTTPコネクタとAJPコネクタの2種類がある。
 Tomcatデフォルトでは、2つのポートが設定されている。:
 HTTP/1.1プロトコル=== サーブレットはHTTPリクエストの処理に特化している。
 AJP/1.3 === 他のWebサーバーのサーブレットをリッスンする/JSP 
 Connector ポートのリッスンを担当し、リクエストはエンジンに転送される
 -->
 <!-- HTTPリクエストの処理に特化した--。>
 <Connector port="8080"
 protocol="HTTP/1.1"
 connectionTimeout="20000"
 redirectPort="8443"/>
 <!-- 他のWebサーバーのサーブレットをリッスンする/JSPリクエストする>
 <Connector port="8009"
 protocol="AJP/1.3"
 redirectPort="8443"/>
 <!--
 Engine サービス内のすべてのリクエストを処理する。
 サーブレットはコネクタから要求を受け取り、どのホストに要求を渡すかを決定する。
 Host リクエストを処理し、結果をエンジンに返した後、サーブレットはどのような性質を持つのか？
 Engine そして結果をコネクタに返す.
 -->
 <Engine name="Catalina" defaultHost="localhost">
 <Realm className="org.apache.catalina.realm.LockOutRealm">
 <Realm className="org.apache.catalina.realm.UserDatabaseRealm"
 resourceName="UserDatabase"/>
 </Realm>
 <!-- Host 1つまたは複数のWebプロジェクトの管理を担当する--。>
 <Host name="localhost"
 appBase="webapps"
 unpackWARs="true"
 autoDeploy="true">
 <Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
 prefix="localhost_access_log" suffix=".txt" pattern="%h %l %u %t &quot;%r&quot; %s %b"/>
 <!--
 Context ホスト上で動作するWebプロジェクトを表現する
 仮想ディレクトリの設定
 pathURIの名前は何でもよいが、その前に必ず/
 docBaseリソースのあるディスクの物理アドレス
 以下をconfに追加することを推奨する。\Catalina\localhost ディレクトリ配下のxmlファイルとして仮想ディレクトリを構成する
 仮想ディレクトリの設定を削除したい場合、tomcatルート・コンフィギュレーション・ファイルはあまり邪魔にならないので、コンフィギュレーション・ファイルを削除することができる。
 -->
 <!--<Context path="/ttt" docBase="test"/>-->
 </Host>
 <!-- バーチャルホスティングの設定>
 <!--<Host name="www.myweb"
 appBase="f:/myweb"
 unpackWARs="true"
 autoDeploy="true">
 <Context path="/" docBase="web"/>
 </Host>-->
 </Engine>
 </Service>
</Server>

Httpリクエストの流れ

TomcatサーバーのHTTPリクエスト処理

• サーブレットのマッピング：

Tomcat 静的リソースの扱い

Tomcatの静的リソースの扱いは、1つの文章にまとめることができます：

Tomcatのリクエストはサーブレットによって処理され、静的リソースも例外ではありません。

基本的に、Tomcatはすべての静的リソースに対して同じことを行います。つまり、URLマッチングが設定されていないすべての場所で、Tomcatのグローバルな同一処理設定が引き継がれます。

この同じ処理のグローバル設定についてですが、Tomcatのconfディレクトリの中にweb.xmlがあり、それを開いてグローバルにDefaultServletを検索すると、以下のように1つだけグローバルがあります：

また、listingsという初期化パラメータがあり、デフォルトはfalseです。

このパラメータの主な目的は、ウェルカムファイルがないときにアプリケーションディレクトリ内のファイルをリストアップすることを許可するかどうかを制御することです。trueに設定すると、一般的なFTPサーバーのように、以下のようにアプリケーションディレクトリのすべてのファイルをリストアップします。もちろん、このスタイルを定義することもできます。

もっと下を見てください：

デフォルトのサーブレットは / という url でマップされています。

url-patternが/に設定されているのだから、すべてのリクエストに応答するはずでは？

そうです。上の説明で述べたように、 Servlet-mapping を定義していないすべてのリクエストにマッチします。

Servletの独自の定義を優先することができる理由は、TomcatのServletの構成は、厳密に初期化の宣言の順序に従っているためであり、この順序で要求に応答するために、層ごとに、この比較によると、要求に応答することができます、それはそれに対処するために使用されます。

Servlet

さて、ここからが今回の主役です。

Servlet

最近、メインのメソッドが長い間書かれていないことにお気づきですか？

私が書いたこのプログラムを実際に誰が呼んだのか、もはや気にも留めていないし、まったく知らないのですが、とにかく私はクラスを書きました。

Tomcatにはこれを前提としたmianメソッドがあります：

いずれにせよ、一般的な考え方としては、作成したサーブレット・クラスがtomcatによって呼び出され、必要なロジックが実行されます。

これを読めば、サーブレットとは何か、知らず知らずのうちに理解できるはずです。

Tomcat Tomcatにはサーブレットがたくさんあります。

既知：Tomcatのリクエストはサーブレットによって処理されます。

• 静的リソースはDefaultServletによって処理されます。
• JspはJspServletによって処理されます。
• サーブレットのマッピング

サーブレットは大まかに以下のように分けられます：

Servlet サーブレットとは何ですか？

Servlet サーブレットの役割と位置

JavaWebを開発する場合、開発環境でも本番環境でも、デプロイされたプロジェクトにWebサーバーを使用する必要性が常にあります。

軽量の tomcat "サーバー "の場合、実際には

tomcat サーバー = ウェブサーバー + ウェブコンテナー

tomcat は次のようなリクエストを受け取ります：

Connector コンポーネントは必要なポートでリッスンし、リクエストが取得されると、Connector コンポーネントは2つのオブジェクトを作成します：

• request: リクエストに含まれる様々な情報をインターセプトし、オブジェクトにカプセル化します。
• Jsp JspServletで処理します。

次に、この2つのオブジェクトは、 tomcatのもう1つのコア・コンポーネントであるContainerコンポーネントに渡されます。

コンテナは、「エンジン」＞「ホスト」＞「コンテキスト」＞「ラッパー（サーブレット）」に分かれています。

コンテナはリクエストを受け取り、2つのオブジェクトをレイヤーごとに渡し、最終的にサーブレットに到達し、サーブレットはリクエストの処理を完了します。

サーブレットが処理を終えると、結果をレスポンスに入れ、最終的にコネクタに到達してクライアントに返すために階層を渡します。

以上のことから明らかなように

• サーブレットはTomcatアーキテクチャの最後の層にあります。
• サーブレットはリクエストを処理し、処理結果を返すために使用されます。

では、サーブレットとは一体何なのでしょうか？

これはまた、JavaEEから話をしなければならない、JavaEEは、実際にJAVA技術に基づく一連の標準です。

1990年代、池の向こうのSUNという会社がJavaというまったく新しい言語を作りました。

わずか数年で、市場で最もホットな言語に躍り出ました。

これに続いたのが、JavaEE仕様としても知られる「Java13トリック」です：

JDBC、JNDI、EJB、RMI、JSP、サーブレット、XML、JMS、Java IDL、JTS、JTA、JavaMail、JAF。

サーブレットはJavaEEの仕様です。

こう答えることができます：

SerlvetはJavaEEが仕様を定義しているJavaの技術ですが、あくまで仕様です。

仕様の目的は何ですか、機能を達成するためではないので、他の人の製品を使用するために、製品を生成するために、この仕様に従って人々がいる、我々は製品の役割を果たすことができるようにするために、仕様に従って動作する必要があります。

そしてこの製品の役割は、リクエストを処理して結果を返すことです

製品」は実際にはサーブレットコンテナです。

ServletコンテナはTomcatで利用できますが、もちろんServletコンテナが存在する場所は他にもあります。

サーブレットとは何か

• responseサーブレットとは何ですか？
• 仕様があるだけでは不十分で、具体的な実装、つまりサーブレット製品が必要です。
• Servlet製品は、使い慣れたServlet仕様で使用できます。
• Servlet JavaEEの仕様です。
• サーブレット製品は、各ウェブ・サーバーにおけるいわゆるウェブ・コンテナです。

サーブレットの使い方

さて、パッドの全文の後、最終的にサーブレットを見たいと思い、ここまで書きましたが、もしあなたが読み通すことができれば、首尾一貫することができ、私はあなたを伝えることができる、サーブレットはです。

サーブレットからラップを外しましょう。

interface Servlet

コードの中のサーブレットは、実は インターフェイスです。

そうそう

このインターフェイスには5つのメソッドしかありません。

5つのメソッドは、最も困難な場所は、パラメータの形式ですが、Tomcatは、さらに、事前にパラメータオブジェクトの形式を渡すためにラップされる、つまり、データベースへのTCP接続を書き込まないでください、HTTPリクエストを解析する必要はありません、はるかに少ないHTTPレスポンスに結果を有効にする必要がある、要求オブジェクトと応答オブジェクトは、私がそれを成し遂げるのを助けるために！

Connectorがリクエストを取得するときに作成される2つのオブジェクト、リクエストとレスポンスを覚えていますか？

このように、サーブレット実装クラスは、実際には単なる空のシェルであり、そのメソッドを書き換えて、その中にロジックコードを書くだけで、tomcatが勝手に実行されます。

簡単

サーブレット・インターフェイスの3つのパラメータ

• ServletConfig: その名の通り「サーブレット設定」です。

  思い返してみると、サーブレットはどこで設定しましたか？web.xmlでしたか？

  実際には、このServletConfigはTomcatのweb.xmlコンフィギュレーション項目に書かれ、解析された後、Servletオブジェクトにカプセル化されます。

• リクエスト/レスポンス

  シンプルなリクエストオブジェクト/レスポンスオブジェクト

  この2つのオブジェクトの作成タイミングと作成方法については、上記で強調しましたので、ここでは繰り返しません。

GenericServlet

Servletの覆いが取り払われると、とてもシンプルになります。

しかし、これはインターフェイスであり、 インターフェイスServletを 実装して毎回Servletを作成するのであれば、毎回すべてのメソッドを書き直さなければなりません。

ですから、 インターフェイスServletを

ご心配なく。Javaは GenericServletを 継承してServletを作成する別の方法も提供しています。

以下の実装コードを見てください：

package com.itheima.servlet;
import javax.servlet.GenericServlet;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import java.io.IOException;
public class ExtendsGenericServlet extends GenericServlet {
 @Override
 public void service(ServletRequest servletRequest, ServletResponse servletResponse) throws ServletException, IOException {
 }
}

サービスメソッドを書き換えただけで、こんなにシンプルになったのでしょうか？

では、このGenericServletがどのようなものなのか見てみましょう。

Servletインタフェースを実装した抽象クラスであることがわかります：

GenericServletは少し改良されていることがわかりました：

• init メソッド内の ServletConfig オブジェクトのスコープを引き上げました。これは、もともと正式なパラメータであったため、他のメソッドで簡単に使用できるようにするためです。
• initメソッドはinit nullコンストラクトも呼び出します。 Servletの作成時に初期化を行いたい場合は、GenericServletを継承した後にinit nullコンストラクトをオーバーライドします。

このように、GenericServletは

しかし、リクエストには様々な方法があるため、実際にサービスメソッドでリクエストを処理する際には、リクエスト方法を判断しなければならないことが多々あります。

の冗長なコードの山になります。

ご心配なく。

HttpServlet

HttpServlet 抽象クラス

HttpServlet 構造体

HttpServletが GenericServletを継承していることがわかります。

ソースコードを見ると、 HttpServletは すでに service メソッドを実装しています。

要するに、HttpServletのサービスメソッドが、複雑なリクエスト判定をすでに行ってくれているのです。

HttpServletの派生クラスのdoGet/doPost/doPut...メソッドを書き換えるだけです。 メソッドをHttpServletの派生クラスに書き換えるだけです。

こんな感じです：

public class ExtendsHttpServlet extends HttpServlet {
 @Override
 protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 // ......
 }
 @Override
 protected void doPost(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
 // .....
 }
}

サーブレットは とてもシンプルです。

10％オフ？10％オフ？10％オフ？10％オフ？10％オフ？10％オフ？10％オフ？10％オフ？10％オフ？

謝辞 侵略と削除

ウェブサーバ、ウェブミドルウェア、ウェブコンテナの違い

Tomcat

Tomcat: