序文
Filter機能の1つは顧客の要求を前処理することであり、TomcatバルブはCatalinaコンテナーHTTPが受け取った要求を前処理することです。
フィルターは実際にServlet仕様で提案されているため、すべてのServletコンテナーに適し、TomcatバルブはTomcatサーカムフレックスであり、Tomcat他のServletコンテナーには使用できません。
はじめに
バルブは、<Engine>/ <Host>およびの3種類のコンテナに追加できます<Context>。
すべてのバルブが実装されorg.apache.catalina.Valveており、次のメソッドがあります。
public Valve getNext();
public void setNext(Valve valve);
public void backgroundProcess();
public void invoke(Request request, Response response)
throws IOException, ServletException;
public boolean isAsyncSupported();
これらの中で最も重要なのはinvoke()、その公式のJavaDoc説明が次のとおりであることです。
バルブの要求に応じてリクエスト処理を行ってください。
単一のバルブは、指定された順序で次の操作を実行できます。
指定された要求と応答の属性を確認または変更します。
指定された
Request属性を確認し、対応する属性を完全に生成して、Response制御を呼び出し元に返します。指定された要求と応答の属性を確認し、これらの2つのオブジェクトの一方または両方をラップして、それらの機能を補足してから、それを渡します。
対応するものが生成されない
Response（そしてコントロールが返されない）場合は、に進んでくださいgetNext()。invoke()パイプラインの次のものを呼び出すにはValve（存在する場合）：getNext().invoke(request, response);最終応答のプロパティを確認しますが、変更はしません（応答は後で呼び出される
ValveかContainer作成されます）。バルブは次のことを決して行ってはなりません。
- この要求の処理制御フローをガイドするために使用された要求属性を変更します（たとえば、標準実装のホストまたはコンテキストに接続されたパイプから要求を送信する必要がある仮想ホストを変更しようとする）。
- 完了した応答を作成し、リクエストと応答をパイプラインの次のバルブに渡します。
- リクエストに完全に関連付けられていない限り、リクエストを渡す前にレスポンスを完全に生成またはラップしていない限り、リクエストに関連付けられた入力ストリームのバイトを消費してください。
- で
getNext()。invoke()メソッドが戻ったら、Response含まれているHTTPヘッダーを変更します。- で
getNext()。invoke()メソッドが返された後、指定されたにResponse関連付けられている出力ストリームに対して任意の操作を実行します。
の属性
<Valve>の基本的な表現は次のとおりです。
<Valve className="实现了Valve接口的类" ...其他属性.../>
ここのリストは其他属性、特定のValve実装クラスによって異なります。これは、ここで対応して設定できるメンバー変数を定義しますが、それらはすべて文字列や数値などの単純な型です。
内蔵バルブ
内蔵バルブはたくさんありますが、よく使われるバルブがいくつかあります。詳しくは公式サイトをご確認ください。9.0バージョンリンクはこちらで、バージョンURLを入れ替えることができます。
一般的に使用される組み込みバルブ：
- カスタマーアクセスログバルブ。これはデフォルトでオンになっており、
server.xml/<Server><Context>その中にアクセスログが生成され$CATALINA_HOME/logsます。場所はフォルダーの下です。 - リモートアドレスフィルター。アクセスできるアドレスと禁止するアドレスを定義します。
- アクセスできるホストと禁止されるホストを定義するリモートホストフィルター
- カスタマーリクエストレコーダー
場所
バルブを効果的にするには、バルブを適切な位置に配置する必要があります。位置が異なると、スコープも異なります。アクションの範囲は、大きいものから小さいものまで、
- 要素の下
server.xmlに配置Engine - 要素の下
server.xmlに配置<Host> - 配置
contextに関して、contextここで推奨場合だけでなく、の位置$project_base_dir/src/main/META-INF/context.xml、特定の理由が表示さJavaWeb-Tomcat_Contextを
最も一般的なのは3番目のケースで、プロジェクトのニーズに応じてカスタマイズできます。
2つ目は2つ目のケースで、デフォルトでオンになっているカスタマーアクセスログバルブ（ `` AccessLogValve`）がこの位置に定義されています。
最初のものはあまり一般的ではありませんが、状況によって異なります。
カスタム
カスタムバルブは、いくつかの条件を満たす必要があります。
- 実装クラスのパッケージ名は
org.apache.catalina.valves - カスタムバルブはどこでなければならない
jar上、袋$CATALINA_HOME/lib2で構成されている下のパス、TomcatのClassLoader決断。それ以外の場合はエラーになりますClassNotFoundException。 org.apache.catalina.Valveインターフェイスを実装するには、通常、org.apache.catalina.valves.ValveBaseクラスを継承してinvokeメソッドをオーバーライドする必要があります。
問題ログ
-
デフォルトでは、アクセスログバルブはオンになっていますが、対応するログファイルが表示されないのはなぜですか？
ただの始め方
Valve、見てserver.xml実際に顧客のアクセスログバルブを開いて、常に見logs、私が使用しているため、研究は、問題を発見した後のディレクトリに対応するログファイルが表示されますが、コマンドが呼び出されたIDEA統合を開始するための方法およびデプロイにwarプロジェクトにTomcat、これは、コールへの道であるcatalina.sh runコマンド、ログにこのモデルの結果がコンソールにリダイレクトされますので、展開する必要が自分自身を呼び出すcatalina.sh startか、startup.shその上に。