Tomcat コアコンポーネントとアプリケーションアーキテクチャの詳細な説明

Web コンテナとは何ですか?

まず、Web コンテナの起源を理解するのに役立つ、Web テクノロジの開発の歴史を簡単に振り返ってみましょう。

初期の Web アプリケーションは、主にニュースなどの静的なページを閲覧するために使用されていました。HTTP サーバー (Apache や Nginx など) は、静的 HTML をブラウザーに返し、ブラウザーは HTML を解析して結果をユーザーに提示する役割を担っていました。

インターネットの発展に伴い、静的なページを閲覧するだけでは満足できなくなりました。インタラクティブな操作を通じて動的な結果を得ることも望まれています。そのため、HTTP サーバーがサーバー プログラムを呼び出すことを可能にする拡張メカニズムが必要です。

そこで Sun は Servlet テクノロジを発表しました。 Servlet はサーバー上で実行される Java アプレットとして簡単に考えることができますが、Servlet にはメイン メソッドがなく、独立して実行できないため、Servlet をインスタンス化して呼び出す Servlet コンテナーにデプロイする必要があります。

Tomcat はサーブレット コンテナです。使いやすさのために、HTTP サーバーの機能も備えているため、Tomcat は「HTTP サーバー + サーブレット コンテナー」であり、Web コンテナーとも呼ばれます。

HTTP の性質

HTTP プロトコルは、ブラウザとサーバー間のデータ転送プロトコルです。アプリケーション層プロトコルである HTTP は、TCP/IP プロトコルに基づいてデータ (HTML ファイル、画像、クエリ結果など) を送信します。HTTP プロトコルはパケット送信を伴わず、主にクライアントとサーバー間の通信形式を指定します。

ブラウザがリモート HTTP サーバーから HTML テキストを取得する必要がある場合、このプロセス中にブラウザは実際に 2 つのことを行う必要があります。

• サーバーとのソケット接続を確立します。
• リクエストデータを生成し、ソケット経由で送信します。

HTTP リクエスト応答の例

ユーザーはログイン ページでユーザー名とパスワードを入力し、[ログイン] をクリックします。ブラウザは次の HTTP 要求を送信します。

HTTP リクエスト データは、リクエスト ライン、リクエスト ヘッダー、リクエスト ボディの 3 つの部分で構成されます。 HTTP 要求データが Tomcat に到達すると、Tomcat は HTTP 要求データ バイト ストリームを解析して Request オブジェクトに変換し、すべての HTTP 要求情報をカプセル化します。次に、Tomcat は Request オブジェクトを Web アプリケーションに渡して処理し、処理後に Response オブジェクトを取得します。Tomcat は Response オブジェクトを HTTP 形式の応答データに変換して、ブラウザーに送信します。

HTTP 応答も、ステータス行、応答ヘッダー、メッセージ本文の3 つの部分で構成されます。同様に、GeekTime ログイン リクエストの応答も例として使用します。

クッキーとセッション

HTTP プロトコルの特徴の 1 つは、ステートレスであり、リクエスト間に関係がないことです。これにより、Web アプリケーションがユーザーを認識しないという厄介な問題が発生します。そのため、HTTP プロトコルにはリクエスト間の接続を確立する技術が必要となり、サーバーはリクエストがどのユーザーから来たのかを知る必要があり、そこで Cookie 技術が登場しました。

Cookie は HTTP メッセージのリクエスト ヘッダーです。Web アプリケーションは、ユーザー識別情報やその他の情報 (ユーザー名など) を Cookie に保存できます。ユーザーが認証されると、各 HTTP 要求メッセージに Cookie が含まれるようになり、サーバーは Cookie 要求ヘッダーを読み取ってユーザーが誰であるかを認識できるようになります。クッキーは基本的に、ユーザーのコンピューターにローカルに保存されるファイルであり、各リクエストで渡す必要がある情報が含まれています。

Cookie はプレーンテキストでローカルに保存され、多くの場合ユーザー情報が含まれているため、セキュリティ上の大きなリスクが生じます。この問題は、 Session の登場によって解決されます。 Session は、ユーザーの状態を保存するためにサーバー側に設けられたストレージスペースと理解できます。 ユーザー情報は、 Session の形式でサーバー側に保存されます。ユーザーからのリクエストが届くと、サーバーはユーザーのリクエストをユーザーのセッションと照合できます。では、セッションはリクエストにどのように対応するのでしょうか?答えは Cookie です。ブラウザは Cookie 内のセッション ID などのフィールドに入力して、リクエストを識別します。

具体的な動作プロセスは次のとおりです。サーバーがセッションを作成すると、セッションに固有のセッション ID が生成されます。ブラウザが再度リクエストを送信すると、このセッション ID が保持されます。リクエストを受信すると、サーバーはセッション ID に基づいて対応するセッションを見つけます。セッションが見つかったら、セッション内のコンテンツを取得または追加できます。これらのコンテンツはサーバーにのみ保存され、セッション ID のみがクライアントに送信されます。大量のユーザー情報を Cookie に保存する必要がないため、比較的安全で、ネットワーク トラフィックを節約できます。

では、セッションはいつ、どこで作成されるのでしょうか?もちろん、サーバー側プログラムの実行中に作成されます。異なる言語で実装されたアプリケーションでは、セッションを作成する方法が異なります。 Java では、Web アプリケーションが HttpServletRequest の getSession メソッドを呼び出すときに、Web コンテナー (Tomcat など) によって作成されます。

Tomcat のセッション マネージャーは、セッションを保存するためのさまざまな永続化ソリューションを提供します。通常は、Redis などの高性能なストレージ メソッドを使用し、クラスターの展開によって単一障害点を防ぎ、高可用性を向上させます。同時に、セッションには有効期限があるため、Tomcat はバックグラウンド スレッドを開始して定期的にポーリングし、セッションの有効期限が切れると無効になります。

サーブレット仕様

HTTP サーバーは、どの Java クラスのどのメソッドを呼び出すかをどのように認識するのでしょうか?最も直接的なアプローチは、HTTP サーバー コードに多くの if-else ロジックを記述することです。つまり、リクエスト A の場合はクラス X の M1 メソッドを呼び出し、リクエスト B の場合はクラス Y の M2 メソッドを呼び出します。しかし、HTTP サーバー コードがビジネス ロジックと結合されているため、これには明らかな問題があります。新しいビジネス メソッドが追加された場合、HTTP サーバー コードを変更する必要があります。

では、この問題をどう解決すればよいのでしょうか?インターフェース指向プログラミングが結合問題を解決する魔法の武器であることは周知の事実です。そのため、あるグループがインターフェースを定義し、さまざまなビジネス クラスがこのインターフェースを実装する必要があります。このインターフェースは Servlet インターフェースと呼ばれます。Servlet インターフェースを実装するビジネス クラスを Servlet と呼ぶこともあります。

しかし、ここでまだ問題が残っています。特定のリクエストに対して、HTTP サーバーはどのサーブレットがそれを処理するかをどのように知るのでしょうか?サーブレットをインスタンス化するのは誰ですか?明らかに、HTTP サーバーはこのタスクには適していません。そうでない場合は、ビジネス クラスと結合されます。

そこで、同じグループが、ビジネス クラスの読み込みと管理に使用される Servlet コンテナーを発明しました。 HTTP サーバーはビジネス クラスを直接処理するのではなく、リクエストをサーブレット コンテナーに渡して処理します。サーブレット コンテナーはリクエストを特定のサーブレットに転送します。サーブレットが作成されていない場合は、サーブレットをロードしてインスタンス化し、サーブレットのインターフェイス メソッドを呼び出します。したがって、サーブレット インターフェースは、実際にはサーブレット コンテナーと特定のビジネス クラス間のインターフェースです。写真を使って理解を深めましょう。

サーブレット インターフェイスとサーブレット コンテナーの仕様全体をサーブレット仕様と呼びます。 Tomcat と Jetty はどちらも、サーブレット仕様の要件に従ってサーブレット コンテナを実装しており、HTTP サーバーの機能も備えています。 Java プログラマーとして、新しいビジネス機能を実装したい場合、サーブレットを実装して Tomcat (サーブレット コンテナー) に登録するだけで、残りの作業は Tomcat が処理します。

Servlet インターフェースは次の 5 つのメソッドを定義します。

パブリックインターフェースサーブレット{
    void init(ServletConfig config) は ServletException をスローします。
    
    ServletConfig を取得します。
    
    void service(ServletRequest req, ServletResponse res) は ServletException、IOException をスローします。
    
    文字列 getServletInfo();
    
    void を破棄します。
}

最も重要なのは、特定のビジネス クラスが処理ロジックを実装するサービス メソッドです。このメソッドは、ServletRequest と ServletResponse の 2 つのパラメータを取ります。 ServletRequest はリクエスト情報をカプセル化するために使用され、ServletResponse はレスポンス情報をカプセル化するために使用されるため、これら 2 つのクラスは基本的に通信プロトコルのカプセル化です。

HTTP プロトコルのリクエストとレスポンスは、HttpServletRequest と HttpServletResponse の 2 つのクラスに対応します。 HttpServletRequest を使用すると、リクエスト パス、Cookie、HTTP ヘッダー、リクエスト パラメータなど、リクエストに関連するすべての情報を取得できます。さらに、HttpServletRequest を通じてセッションを作成および取得することもできます。 HttpServletResponse は HTTP 応答をカプセル化するために使用されます。

インターフェースには、ライフサイクルに関連する init と destroy という 2 つのメソッドがあることがわかります。これはよく考えられた設計です。サーブレット コンテナーは、サーブレット クラスをロードするときに init メソッドを呼び出し、アンロードするときに destroy メソッドを呼び出します。 init メソッドで一部のリソースを初期化し、destroy メソッドでこれらのリソースを解放する場合があります。たとえば、Spring MVC の DispatcherServlet は、init メソッドで独自の Spring コンテナを作成します。

ServletConfig クラスにも注目してください。ServletConfig の役割は、サーブレットの初期化パラメータをカプセル化することです。 web.xml でサーブレットのパラメータを設定し、プログラムの getServletConfig メソッドを通じてこれらのパラメータを取得できます。

インターフェースがあるところには、通常、インターフェースを実装し、共通ロジックをカプセル化するために使用される抽象クラスがあることはご存じのとおりです。したがって、サーブレット仕様では、GenericServlet 抽象クラスが提供されており、これを拡張することで実装できます。 Servlet 仕様では通信プロトコルは考慮されませんが、ほとんどの Servlet は HTTP 環境で処理されます。そのため、Servet 仕様では GenericServlet を継承し、HTTP 機能を追加するために HttpServlet も提供されています。このように、HttpServlet クラスを継承して独自のサーブレットを実装します。doGet と doPost の 2 つのメソッドを書き直すだけです。

サーブレットコンテナ

クライアントがリソースを要求すると、HTTP サーバーはクライアントの要求情報を ServletRequest オブジェクトにカプセル化し、サーブレット コンテナのサービス メソッドを呼び出します。サーブレット コンテナは要求を受信すると、要求された URL とサーブレットのマッピング関係に基づいて対応するサーブレットを見つけます。サーブレットがロードされていない場合は、リフレクション メカニズムを使用してサーブレットを作成し、サーブレットの init メソッドを呼び出して初期化を完了します。次に、サーブレットのサービス メソッドを呼び出して要求を処理し、ServletResponse オブジェクトを HTTP サーバーに返します。HTTP サーバーは応答をクライアントに送信します。

ウェブアプリケーション

サーブレット コンテナはサーブレットをインスタンス化して呼び出しますが、サーブレットはどのようにしてサーブレット コンテナに登録されるのでしょうか?一般的に、サーブレットは Web アプリケーションとしてデプロイされます。サーブレット仕様によると、Web アプリケーションには特定のディレクトリ構造があり、その中にサーブレット クラス ファイル、構成ファイル、および静的リソースが配置されます。サーブレット コンテナーは、構成ファイルを読み取ることでサーブレットを見つけて読み込むことができます。 Web アプリケーションのディレクトリ構造はおそらく次のようになります。

|-MyWebApp
      | - WEB-INF/web.xml -- サーブレットなどの設定に使用される設定ファイル | - WEB-INF/lib/ -- Web アプリケーションに必要なさまざまな JAR パッケージを格納します | - WEB-INF/classes/ -- サーブレット クラスなどのアプリケーション クラスを格納します | - META-INF/ -- プロジェクト情報を格納するディレクトリ

Servlet 仕様では、Web アプリケーションに対応するServletContextインターフェイスが定義されています。 Web アプリケーションがデプロイされた後、サーブレット コンテナーは起動時に Web アプリケーションをロードし、各 Web アプリケーションに対して一意の ServletContext オブジェクトを作成します。 ServletContext はグローバル オブジェクトと考えることができます。Web アプリケーションには複数のサーブレットが存在する場合があり、グローバル ServletContext を通じてデータを共有できます。これらのデータには、Web アプリケーションの初期化パラメータ、Web アプリケーション ディレクトリの下のファイル リソースなどが含まれます。 ServletContext はすべての Servlet インスタンスを保持しているため、これを使用して Servlet リクエストを転送することもできます。

拡張メカニズム

Servlet 仕様が導入された後は、ソケット ネットワーク通信、HTTP プロトコル、ビジネス クラスのインスタンス化と呼び出し方法について心配する必要はありません。これらは Servlet 仕様によって標準化されているためです。ビジネス ロジックをどのように実装するかだけに注意すれば済みます。これはプログラマーにとっては良いことですが、不便な面もあります。いわゆる標準とは、誰もがそれに従う必要があるという意味であり、同じになります。しかし、この標準がビジネスの個別のニーズを満たすことができない場合は問題が発生します。したがって、標準やミドルウェアを設計するときは、スケーラビリティを十分に考慮する必要があります。 Servlet 仕様では、 Filter と Listener という2 つの拡張メカニズムが提供されています。

フィルターはフィルターです。このインターフェースを使用すると、リクエストとレスポンスに対して統一されたカスタマイズされた処理を実行できます。たとえば、リクエストの頻度に基づいてアクセスを制限したり、国や地域に基づいてレスポンスの内容を変更したりできます。フィルターの動作原理は次のとおりです。Web アプリケーションがデプロイされた後、サーブレット コンテナーはフィルターをインスタンス化し、フィルターを FilterChain にリンクする必要があります。リクエストが到着すると、最初のフィルターを取得し、この FilterChain 内の次のフィルターを呼び出す doFilter メソッドを呼び出します。

リスナーは別の拡張メカニズムです。 Web アプリケーションが Servlet コンテナ内で実行されると、Web アプリケーションの起動と停止、ユーザー要求の到着など、さまざまなイベントが Servlet コンテナ内で継続的に発生します。サーブレット コンテナは、これらのイベントをリッスンするためのデフォルトのリスナーをいくつか提供します。イベントが発生すると、サーブレット コンテナはリスナー メソッドを呼び出す役割を担います。もちろん、関心のあるイベントをリッスンするための独自のリスナーを定義し、web.xml でリスナーを構成することもできます。たとえば、Spring は、ServletContext の起動イベントをリッスンするための独自のリスナーを実装します。その目的は、サーブレット コンテナの起動時にグローバル Spring コンテナを作成して初期化することです。

Tomcat ダウンロード アドレス: https://tomcat.apache.org/download-80.cgi

/bin: Windows または Linux プラットフォームで Tomcat を起動およびシャットダウンするためのスクリプト ファイルを保存します。
/conf: Tomcat のさまざまなグローバル構成ファイルを格納します。最も重要なのは server.xml です。
/lib: Tomcat およびすべての Web アプリケーションからアクセスできる JAR ファイルを格納します。
/logs: Tomcat の実行時に生成されたログ ファイルを保存します。
/work: JSP コンパイル後に生成されたクラス ファイルを格納します。
/webapps: Tomcat の Web アプリケーション ディレクトリ。デフォルトでは、Web アプリケーションはこのディレクトリに配置されます。

Tomcat ログ ディレクトリ (Tomcat インストール ディレクトリの下の logs ディレクトリ) を開きます。 Tomcat のログ情報は 2 つのカテゴリに分かれています。1 つは操作ログで、主に操作中のいくつかの情報、特にいくつかの異常なエラー ログ情報が記録されます。もう 1 つはアクセス ログで、アクセス時間、IP アドレス、アクセス パス、およびその他の関連情報が記録されます。

• catalina.***.log は主に Tomcat の起動プロセスの情報を記録します。このファイルでは、起動 JVM パラメータとオペレーティング システムのログ情報を確認できます。
• catalina.out は Tomcat の標準出力 (stdout) と標準エラー (stderr) であり、Tomcat の起動スクリプトで指定されます。変更されていない場合、stdout と stderr はここにリダイレクトされます。このファイルでは、MyServlet.javaプログラムで出力した情報を確認できます。
• localhost.**.log には主に、初期化プロセス中に Web アプリケーションで発生した未処理の例外が記録されます。これらの例外は Tomcat によってキャプチャされ、このログ ファイルに出力されます。
• localhost_access_log.**.txt には、IP アドレス、要求パス、時間、要求プロトコル、ステータス コードなどの情報を含む、Tomcat へのアクセスに関する要求ログが保存されます。
• manager.***.log/host-manager.***.log には、Tomcat の組み込み Manager プロジェクトのログ情報が保存されます。

まとめ：

1. Tomcatのコアコンポーネントを理解する
2. server.xml 構成の詳細な説明

1. Tomcatコンポーネントの理解

知識ポイント:

1. Tomcat アーキテクチャの説明
2. Tomcat のコンポーネントと関係の詳細な紹介
3. Tomcat 起動パラメータの説明
4. Tomcat アーキテクチャの説明

Tomcat は、Java EE のサーブレットと jsp 仕様を実装する Java ベースの WEB コンテナです。Nginx Apache サーバーとは異なり、通常は動的なリクエスト処理に使用されます。アーキテクチャはコンポーネント指向で設計されています。つまり、コンポーネントを組み立てることで全体の機能が完成します。さらに、各コンポーネントは交換可能で、柔軟性を確保します。

2.Tomcatのコンポーネントと関係

サーバーとサービス
コネクタ
HTTP 1.1
SSLhttps
AJP (Apache JServ プロトコル) Apache リバース プロキシ Tomcat で使用される Apache プライベート プロトコル
容器
エンジンエンジンカタリナ
ホスト仮想マシンはドメイン名に基づいてリクエストを分散します
コンテキストは各 WEB アプリケーションを分離します。各コンテキストの ClassLoader は独立しています。
成分
マネージャー
ロガー
ローダ
パイプライン
バルブ（パイプ内のバルブ）

2. Tomcat server.xml 設定の詳細な説明

サーバ

ルート要素: サーバーの最上位構成 主な属性: port: シャットダウンコマンドを実行するポート番号 シャットダウン: シャットダウンコマンド

シャットダウンの使用方法をデモンストレーションします#telent に基づいて、SHUTDOWN コマンドを実行してシャットダウンします (大文字にする必要があります) telnet 127.0.0.1 8005 SHUTDOWN

サービス

サービス: 複数のコネクタとエンジンを 1 つのサービスに結合します。複数のサービスを構成できます。

コネクタ

コネクタ: 指定されたプロトコルで接続を受信し、処理のために一意のエンジンに割り当てるために使用されます。 主な属性:

• プロトコル リスニングプロトコル。デフォルトは http/1.1 です。
• portはサーバー側で作成されるポート番号を指定します
• minSpareThreads サーバーがリクエストの処理を開始するときに作成されるスレッドの数
• maxThreads リクエストを処理するために作成できるスレッドの最大数
• enableLookups true の場合、request.getRemoteHost() を呼び出して DNS クエリを実行することで、リモート クライアントの実際のホスト名を取得できます。false の場合、DNS クエリは実行されませんが、代わりに IP アドレスが返されます。
• redirectPort は、HTTP リクエストの処理中に SSL トランスポート リクエストを受信した後にサーバーがリダイレクトするポート番号を指定します。
• acceptCount は、リクエストの処理に使用可能なすべてのスレッドが使用された場合に、処理キューに配置できるリクエストの数を指定します。この数を超えるリクエストは処理されません。
• connectionTimeout はタイムアウト期間を指定します（ミリ秒単位）
• SSLEnabled SSL 検証を有効にするかどうか。Https 経由でアクセスする場合は有効にする必要があります。証明書を生成します: keytool -genkey -v -alias testKey -keyalg RSA -validity 3650 -keystore D:\test.keystore
• [ ] 複数のコネクタの設定のデモンストレーション

<コネクタ ポート="8860" プロトコル="org.apache.coyote.http11.Http11NioProtocol"
                接続タイムアウト = "20000"
                リダイレクトポート="8862"
                URIエンコーディング="UTF-8"
                URI のボディエンコードを ="true" にする
                圧縮="オン" 圧縮最小サイズ="2048"
圧縮可能なMimeType="text/html、text/xml、text/plain、text/javascript、text/css、application/x-json、application/json、application/x-javascript"
                最大スレッド数="1024" 最小スペアスレッド数="200"
                受け入れ数 = "800"
                最大接続数 = "10000"
                enableLookups="false"
        />

エンジン

エンジン: 接続を処理するために使用されるエグゼキュータ。デフォルトのエンジンは catalina です。サービス内で設定できるエンジンは 1 つだけです。 主な属性: name エンジン名 defaultHost デフォルトホスト

ホスト

仮想マシン: ドメイン名に基づいて指定された仮想マシンと一致します。 nginx のサーバーと同様に、デフォルトの仮想マシンは localhost です。主なプロパティ:

複数のホストの構成のデモンストレーション

<ホスト名="www.wukong.com" appBase="/usr/www/wukong" unpackWARs="true" autoDeploy="true"> 
	<Valve クラス名="org.apache.catalina.valves.AccessLogValve" ディレクトリ="logs" プレフィックス="www.wukong.com.access_log" 
			サフィックス=".txt" パターン="%h %l %u %t &quot;%r&quot; %s %b" /> 
</ホスト>

コンテクスト

アプリケーション コンテキスト: ホストの下に複数のコンテキストを構成でき、各コンテキストには独自の独立した classPath があります。 ClassPath の競合を避けるために、互いに分離します。 主な属性:

複数のコンテキストの設定のデモンストレーション

<コンテキスト パス="/testweb" docBase="testweb.war" reloadbale="true"/>

バルブ：次のように理解できます

フィルターの具体的な構成は、特定の Valve インターフェースのサブクラスに基づいています。以下はValveのアクセスログです

<Valve クラス名="org.apache.catalina.valves.AccessLogValve" ディレクトリ="logs"
               プレフィックス="www.wukong.com.access_log" サフィックス=".txt"
               パターン="%h %l %u %t &quot;%r&quot; %s %b" />

3. Tomcat デプロイメント スクリプトの作成

Tomcat 起動パラメータの説明

Tomcat を起動するプロセスは何ですか?

1. WAR ファイルを Tomcat Web アプリケーション ディレクトリにコピーします。
2. 起動するには、startut.bat スクリプトを実行します。
3. 起動プロセス中に、war パッケージが自動的に解凍され、ロードされます。

しかし、Eclipse または idea で WEB プロジェクトを開始するときに、War パッケージも webapps ディレクトリに解凍するのでしょうか?当然違います。実際の方法は、Tomcat プログラム ファイルの外部にデプロイメント ディレクトリを作成することです。これは、一般的な運用環境でも行われています。つまり、Tomcat プログラム ディレクトリとデプロイメント ディレクトリは分離されています。 これを実現するには、起動時に CATALINA_HOME および CATALINA_BASE パラメータを指定するだけです。

|起動パラメータ| 説明| |:----|:----| | JAVA_OPTS | JVM 起動パラメータ、メモリ エンコーディングの設定など -Xms100m -Xmx200m -Dfile.encoding=UTF-8 | | JAVA_HOME | jdk ディレクトリを指定します。設定されていない場合は、java 環境変数から見つけます。 | | CATALINA_HOME | Tomcat プログラムのルート ディレクトリ | | CATALINA_BASE | アプリケーション デプロイメント ディレクトリ。デフォルトは $CATALINA_HOME です | | CATALINA_OUT | アプリケーション ログ出力ディレクトリ。デフォルトは $CATALINA_BASE/log です | | CATALINA_TMPDIR | アプリケーションの一時ディレクトリ。デフォルトは $CATALINA_BASE/temp です |

カスタム構成を実装するためのスクリプトを作成できます。

apache-tomcat は、次のディレクトリにあります。

起動スクリプトを更新する

#!/bin/bash
 JAVA_OPTS="-Xms100m -Xmx200m" をエクスポートします。
エクスポート CATALINA_HOME=/home/wukong/apache-tomcat
エクスポート CATALINA_BASE="`pwd`"
 
ケース$1
        始める）
        $CATALINA_HOME/bin/catalina.sh 開始
                エコースタート成功！！
        ;;
        停止）
                $CATALINA_HOME/bin/catalina.sh を停止します
                エコー停止成功！！
        ;;
        再起動）
        $CATALINA_HOME/bin/catalina.sh を停止します
                エコー停止成功！！
                睡眠3
        $CATALINA_HOME/bin/catalina.sh 開始
        エコースタート成功！！
        ;;
        バージョン)
        $CATALINA_HOME/bin/catalina.sh バージョン
        ;;
        configテスト)
        $CATALINA_HOME/bin/catalina.sh 構成テスト
        ;;
        エサック
終了 0

docker で tomcat を起動する

docker run -id --name=test_tomcat -e JAVA_OPTS='-Xmx128m' -p 8888:8080 -v /usr/local/tuling-project/tomcat-test/webapps:/usr/local/tomcat/webapps -v /usr/local/tuling-project/tomcat-test/logs:/usr/local/tomcat/log -v /usr/local/tuling-project/tomcat-test/conf:/usr/local/tomcat/conf --privileged=true tomcat:8

ソースコードビルド

ダウンロードアドレス: https://tomcat.apache.org/download-80.cgi

構成

1. ソースコードapache-tomcat-8.5.57-srcを解凍します。

2. apache-tomcat-8.5.57-srcディレクトリにpomファイルを追加します。

<?xml バージョン="1.0" エンコーディング="UTF-8"?>
<プロジェクト xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
 
    <モデルバージョン>4.0.0</モデルバージョン>
    <グループ ID>org.apache.tomcat</グループ ID>
    <artifactId>Tomcat8.0</artifactId>
    <name>Tomcat8.0</name>
    <バージョン>8.0</バージョン>
 
    <ビルド>
        <finalName>Tomcat8.0</finalName>
        <ソースディレクトリ>java</ソースディレクトリ>
        <testSourceDirectory>テスト</testSourceDirectory>
        <リソース>
            <リソース>
                <ディレクトリ>java</ディレクトリ>
            </リソース>
        </リソース>
        <テストリソース>
            <テストリソース>
                <ディレクトリ>テスト</ディレクトリ>
            </テストリソース>
        </テストリソース>
        <プラグイン>
            <プラグイン>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <バージョン>2.3</バージョン>
                <構成>
                    <encoding>UTF-8</encoding>
                    <ソース>1.8</ソース>
                    <target>1.8</target>
                </構成>
            </プラグイン>
        </プラグイン>
    </ビルド>
 
    <依存関係>
        <依存関係>
            <groupId>ジュニット</groupId>
            <artifactId>junit</artifactId>
            <バージョン>4.12</バージョン>
            <scope>テスト</scope>
        </依存関係>
        <依存関係>
            <groupId>org.easymock</groupId>
            <artifactId>イージーモック</artifactId>
            <バージョン>3.4</バージョン>
        </依存関係>
        <依存関係>
            <groupId>アリ</groupId>
            <artifactId>アリ</artifactId>
            <バージョン>1.7.0</バージョン>
        </依存関係>
        <依存関係>
            <グループID>wsdl4j</グループID>
            <アーティファクトID>wsdl4j</アーティファクトID>
            <バージョン>1.6.2</バージョン>
        </依存関係>
        <依存関係>
            <グループID>javax.xml</グループID>
            <artifactId>jaxrpc</artifactId>
            <バージョン>1.1</バージョン>
        </依存関係>
        <依存関係>
            <groupId>org.eclipse.jdt.core.compiler</groupId>
            <artifactId>ecj</artifactId>
            <バージョン>4.5.1</バージョン>
        </依存関係>
 
    </依存関係>
</プロジェクト>

3. apache-tomcat-8.5.57-srcと同じディレクトリに新しいcatalina-homeディレクトリを作成し、ディレクトリ下のファイルが次のようになっていることを確認します。

注: 上記のフォルダに apache-tomcat-8.5.57-src がある場合はそれを切り取ってください。ない場合は新しいものを作成してください。bin conf webapps は apache-tomcat-8.5.57-src から切り取る必要があります。

4.プロジェクトにアイデアを導入する

ファイル->開く 解凍したC:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-srcを選択します

構成の起動

メインクラス: org.apache.catalina.startup.BootstrapVmOptions: -Dcatalina.home=C:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src\catalina-home

起動エラー

TestCookieFilter がエラーを報告しました: このクラス CookieFilter が見つかりません

解決：

1. 削除: TestCookieFilter

起動後、localhost:8080にアクセスし、org.apache.jasper.JasperException: java.lang.NullPointerExceptionを報告します。

解決：

org.apache.catalina.startup.Bootstrap コードブロックを追加

{
        JasperInitializer 初期化子 = 新しい JasperInitializer();
         }

上記はTomcatコアコンポーネントとアプリケーションアーキテクチャの詳細な説明の詳細な内容です。Tomcatコアコンポーネントとアプリケーションアーキテクチャの詳細については、123WORDPRESS.COMの他の関連記事に注目してください。