Detaillierte Erläuterung der Tomcat-Kernkomponenten und der Anwendungsarchitektur

Was ist ein Webcontainer?

Lassen Sie uns zunächst kurz die Entwicklungsgeschichte der Web-Technologie Revue passieren lassen, um den Ursprung von Web-Containern zu verstehen.

Frühe Webanwendungen wurden hauptsächlich zum Durchsuchen statischer Seiten wie Nachrichten verwendet. HTTP-Server (wie Apache und Nginx) gaben statisches HTML an den Browser zurück, der für die Analyse des HTML und die Präsentation der Ergebnisse für den Benutzer verantwortlich war.

Mit der Entwicklung des Internets geben wir uns nicht mehr damit zufrieden, nur statische Seiten zu durchsuchen. Wir hoffen auch, durch einige interaktive Vorgänge dynamische Ergebnisse zu erzielen. Daher benötigen wir einige Erweiterungsmechanismen, damit der HTTP-Server das Serverprogramm aufrufen kann.

Deshalb hat Sun die Servlet-Technologie eingeführt. Sie können sich Servlet einfach als ein Java-Applet vorstellen, das auf dem Server ausgeführt wird. Allerdings verfügt Servlet über keine Hauptmethode und kann nicht unabhängig ausgeführt werden. Daher muss es in einem Servlet-Container bereitgestellt werden, der das Servlet instanziiert und aufruft.

Und Tomcat ist ein Servlet-Container. Zur einfacheren Verwendung verfügen sie auch über die Funktion eines HTTP-Servers, sodass Tomcat ein „HTTP-Server + Servlet-Container“ ist. Wir nennen sie auch Webcontainer.

Die Natur von HTTP

Das HTTP-Protokoll ist das Datenübertragungsprotokoll zwischen Browsern und Servern. Als Protokoll der Anwendungsschicht basiert HTTP auf dem TCP/IP-Protokoll zur Datenübertragung (HTML-Dateien, Bilder, Abfrageergebnisse usw.). Das HTTP-Protokoll beinhaltet keine Paketübertragung und gibt hauptsächlich das Kommunikationsformat zwischen Client und Server an.

Wenn ein Browser einen HTML-Text von einem Remote-HTTP-Server abrufen muss, muss der Browser während dieses Vorgangs eigentlich zwei Dinge tun.

• Stellen Sie eine Socket-Verbindung mit dem Server her.
• Generieren Sie Anforderungsdaten und senden Sie sie über Socket.

Beispiel für eine HTTP-Anforderungsantwort

Der Benutzer gibt auf der Anmeldeseite seinen Benutzernamen und sein Passwort ein und klickt auf Anmelden. Der Browser sendet die folgende HTTP-Anfrage:

HTTP-Anforderungsdaten bestehen aus drei Teilen: Anforderungszeile, Anforderungsheader und Anforderungstext . Wenn die HTTP-Anforderungsdaten Tomcat erreichen, analysiert Tomcat den Bytestream der HTTP-Anforderungsdaten in ein Anforderungsobjekt, das alle HTTP-Anforderungsinformationen kapselt. Tomcat übergibt das Anforderungsobjekt dann zur Verarbeitung an die Webanwendung und erhält nach der Verarbeitung ein Antwortobjekt. Tomcat konvertiert das Antwortobjekt in Antwortdaten im HTTP-Format und sendet sie an den Browser.

Die HTTP-Antwort besteht ebenfalls aus drei Teilen: Statuszeile, Antwortheader und Nachrichtentext . In ähnlicher Weise verwende ich auch die Antwort der GeekTime-Anmeldeanforderung als Beispiel.

Cookies und Sitzungen

Wir wissen, dass eines der Merkmale des HTTP-Protokolls darin besteht, dass es zustandslos ist und keine Beziehung zwischen Anforderungen besteht. Dies führt zu einem peinlichen Problem: Die Webanwendung weiß nicht, wer Sie sind. Daher benötigt das HTTP-Protokoll eine Technologie zum Herstellen einer Verbindung zwischen Anforderungen und der Server muss wissen, von welchem ​​Benutzer die Anforderung stammt. Daher entstand die Cookie-Technologie.

Ein Cookie ist ein Anforderungsheader einer HTTP-Nachricht . Webanwendungen können Benutzeridentifikationsinformationen oder andere Informationen (Benutzername usw.) im Cookie speichern. Nachdem der Benutzer authentifiziert wurde, enthält jede HTTP-Anforderungsnachricht ein Cookie, sodass der Server den Cookie-Anforderungsheader lesen kann, um zu erkennen, wer der Benutzer ist. Ein Cookie ist im Wesentlichen eine lokal auf dem Computer des Benutzers gespeicherte Datei, die Informationen enthält, die bei jeder Anfrage weitergegeben werden müssen.

Da Cookies lokal im Klartext gespeichert werden und oft Benutzerinformationen enthalten, stellt dies ein großes Sicherheitsrisiko dar. Das Aufkommen von Session löst dieses Problem. Session kann als ein auf der Serverseite geöffneter Speicherplatz verstanden werden, der den Status des Benutzers speichert. Benutzerinformationen werden auf der Serverseite in Form von Session gespeichert . Wenn eine Benutzeranforderung eingeht, kann der Server die Benutzeranforderung der Sitzung des Benutzers zuordnen. Wie entspricht also die Sitzung der Anfrage? Die Antwort lautet: Cookies. Der Browser füllt ein Feld wie die Sitzungs-ID im Cookie aus, um die Anfrage zu identifizieren.

Der konkrete Arbeitsablauf ist wie folgt: Wenn der Server eine Sitzung erstellt, generiert er eine eindeutige Sitzungs-ID für die Sitzung. Wenn der Browser erneut eine Anfrage sendet, enthält er diese Sitzungs-ID. Nach Erhalt der Anfrage findet der Server die entsprechende Sitzung anhand der Sitzungs-ID. Nachdem Sie die Sitzung gefunden haben, können Sie Inhalte in der Sitzung abrufen oder hinzufügen. Diese Inhalte werden nur auf dem Server gespeichert und nur die Sitzungs-ID wird an den Client gesendet. Dies ist relativ sicher und spart Netzwerkverkehr, da keine große Menge an Benutzerinformationen im Cookie gespeichert werden muss.

Also, wann und wo wird die Sitzung erstellt? Natürlich wird es während der Ausführung des serverseitigen Programms erstellt. In verschiedenen Sprachen implementierte Anwendungen haben unterschiedliche Methoden zum Erstellen von Sitzungen. In Java wird es vom Web-Container (z. B. Tomcat) erstellt, wenn die Web-Anwendung die Methode getSession von HttpServletRequest aufruft.

Der Session Manager von Tomcat bietet eine Vielzahl von Persistenzlösungen zum Speichern von Sitzungen. Dabei werden normalerweise Hochleistungsspeichermethoden wie Redis verwendet und einzelne Fehlerpunkte durch Clusterbereitstellung verhindert, wodurch die Hochverfügbarkeit verbessert wird. Gleichzeitig verfügt die Sitzung über eine Ablaufzeit, sodass Tomcat einen Hintergrundthread zur regelmäßigen Abfrage startet. Wenn die Sitzung abläuft, wird sie ungültig.

Servlet-Spezifikation

Woher weiß der HTTP-Server, welche Methode welcher Java-Klasse aufgerufen werden soll? Der direkteste Ansatz besteht darin, viel if-else-Logik in den HTTP-Servercode zu schreiben: Wenn es sich um Anforderung A handelt, rufen Sie die Methode M1 der Klasse X auf; wenn es sich um Anforderung B handelt, rufen Sie die Methode M2 ​​der Klasse Y auf. Dies bringt jedoch offensichtliche Probleme mit sich, da der HTTP-Servercode mit der Geschäftslogik gekoppelt ist. Wenn eine neue Geschäftsmethode hinzugefügt wird, muss der HTTP-Servercode geändert werden.

Wie lösen wir also dieses Problem? Wir wissen, dass schnittstellenorientierte Programmierung die Wunderwaffe zur Lösung des Kopplungsproblems ist. Daher definiert eine Gruppe von Personen eine Schnittstelle, und verschiedene Geschäftsklassen müssen diese Schnittstelle implementieren. Diese Schnittstelle wird als Servlet-Schnittstelle bezeichnet. Manchmal nennen wir die Geschäftsklasse, die die Servlet-Schnittstelle implementiert, auch Servlet.

Allerdings besteht hier immer noch ein Problem: Woher weiß der HTTP-Server bei einer bestimmten Anfrage, welches Servlet sie verarbeiten soll? Wer instanziiert das Servlet? Offensichtlich ist der HTTP-Server für diese Aufgabe nicht geeignet, da er sonst mit der Business-Klasse gekoppelt wird.

Daher hat dieselbe Gruppe den Servlet-Container erfunden, der zum Laden und Verwalten von Business-Klassen verwendet wird. Der HTTP-Server befasst sich nicht direkt mit der Business-Klasse, sondern übergibt die Anforderung zur Verarbeitung an den Servlet-Container. Der Servlet-Container leitet die Anforderung an ein bestimmtes Servlet weiter. Wenn das Servlet nicht erstellt wurde, lädt und instanziiert er das Servlet und ruft dann die Schnittstellenmethode des Servlets auf. Daher ist die Servlet-Schnittstelle tatsächlich die Schnittstelle zwischen dem Servlet-Container und der spezifischen Business-Klasse. Lassen Sie uns zur Vertiefung unseres Verständnisses ein Bild verwenden.

Der gesamte Satz an Spezifikationen für die Servlet-Schnittstelle und den Servlet-Container wird als Servlet-Spezifikation bezeichnet. Sowohl Tomcat als auch Jetty implementieren Servlet-Container gemäß den Anforderungen der Servlet-Spezifikation und verfügen auch über die Funktionen von HTTP-Servern. Wenn wir als Java-Programmierer neue Geschäftsfunktionen implementieren möchten, müssen wir nur ein Servlet implementieren und es in Tomcat registrieren (Servlet-Container). Den Rest erledigt Tomcat für uns.

Die Servlet-Schnittstelle definiert die folgenden fünf Methoden:

öffentliche Schnittstelle Servlet {
    void init(ServletConfig config) löst ServletException aus;
    
    ServletConfig getServletConfig();
    
    void service(ServletRequest req, ServletResponse res) löst ServletException, IOException aus;
    
    String getServletInfo();
    
    ungültig zerstören();
}

Die wichtigste ist die Servicemethode, bei der die spezifische Geschäftsklasse die Verarbeitungslogik implementiert. Diese Methode verwendet zwei Parameter: ServletRequest und ServletResponse. ServletRequest wird zum Kapseln von Anforderungsinformationen verwendet und ServletResponse zum Kapseln von Antwortinformationen. Diese beiden Klassen sind also im Wesentlichen Kapselungen von Kommunikationsprotokollen.

Die Anfragen und Antworten im HTTP-Protokoll entsprechen den beiden Klassen HttpServletRequest und HttpServletResponse. Sie können HttpServletRequest verwenden, um alle anforderungsbezogenen Informationen abzurufen, einschließlich Anforderungspfad, Cookies, HTTP-Header, Anforderungsparameter usw. Darüber hinaus können wir Sitzungen auch über HttpServletRequest erstellen und abrufen. Die HttpServletResponse wird zum Kapseln von HTTP-Antworten verwendet.

Sie können sehen, dass es in der Schnittstelle zwei Methoden gibt, die sich auf den Lebenszyklus beziehen: init und destroy. Dies ist ein durchdachtes Design. Der Servlet-Container ruft die init-Methode beim Laden der Servlet-Klasse auf und ruft die destroy-Methode beim Entladen auf. Wir können einige Ressourcen in der Init-Methode initialisieren und diese Ressourcen in der Destroy-Methode freigeben. Beispielsweise erstellt das DispatcherServlet in Spring MVC seinen eigenen Spring-Container in der Init-Methode.

Ihnen wird auch die Klasse ServletConfig auffallen. Die Rolle von ServletConfig besteht darin, die Initialisierungsparameter des Servlets zu kapseln. Sie können Parameter für das Servlet in web.xml konfigurieren und diese Parameter über die Methode getServletConfig im Programm abrufen.

Wir wissen, dass es dort, wo es eine Schnittstelle gibt, im Allgemeinen eine abstrakte Klasse gibt, die zur Implementierung der Schnittstelle und zur Kapselung gemeinsamer Logik verwendet wird. Daher stellt die Servlet-Spezifikation die abstrakte Klasse GenericServlet bereit, die wir durch Erweiterung implementieren können. Obwohl sich die Servlet-Spezifikation nicht um das Kommunikationsprotokoll kümmert, werden die meisten Servlets in der HTTP-Umgebung verarbeitet. Daher bietet die Servet-Spezifikation auch HttpServlet, um GenericServlet zu erben und HTTP-Funktionen hinzuzufügen. Auf diese Weise implementieren wir unser eigenes Servlet, indem wir die Klasse HttpServlet erben. Wir müssen nur zwei Methoden neu schreiben: doGet und doPost.

Servlet-Container

Wenn ein Client eine Ressource anfordert, kapselt der HTTP-Server die Anforderungsinformationen des Clients in ein ServletRequest-Objekt und ruft dann die Servicemethode des Servlet-Containers auf. Nachdem der Servlet-Container die Anforderung empfangen hat, findet er das entsprechende Servlet basierend auf der Zuordnungsbeziehung zwischen der angeforderten URL und dem Servlet. Wenn das Servlet nicht geladen wurde, verwendet er den Reflexionsmechanismus, um das Servlet zu erstellen, und ruft die Init-Methode des Servlets auf, um die Initialisierung abzuschließen. Anschließend ruft er die Servicemethode des Servlets auf, um die Anforderung zu verarbeiten und das ServletResponse-Objekt an den HTTP-Server zurückzugeben. Der HTTP-Server sendet die Antwort an den Client.

Webanwendung

Der Servlet-Container wird das Servlet instanziieren und aufrufen. Wie wird also das Servlet im Servlet-Container registriert? Im Allgemeinen stellen wir Servlets als Webanwendungen bereit. Gemäß der Servlet-Spezifikation haben Webanwendungen eine bestimmte Verzeichnisstruktur, in der die Servlet-Klassendateien, Konfigurationsdateien und statischen Ressourcen abgelegt werden. Der Servlet-Container kann das Servlet finden und laden, indem er die Konfigurationsdatei liest. Die Verzeichnisstruktur einer Webanwendung sieht wahrscheinlich wie folgt aus:

|-MeineWebApp
      | - WEB-INF/web.xml – Konfigurationsdatei, die zum Konfigurieren von Servlets usw. verwendet wird. | - WEB-INF/lib/ – speichert verschiedene JAR-Pakete, die für Webanwendungen erforderlich sind. | - WEB-INF/classes/ – speichert Ihre Anwendungsklassen, z. B. Servlet-Klassen. | - META-INF/ – Verzeichnis speichert einige Projektinformationen.

Die Servlet-Spezifikation definiert die ServletContext- Schnittstelle so, dass sie einer Webanwendung entspricht. Nachdem die Webanwendung bereitgestellt wurde, lädt der Servlet-Container die Webanwendung beim Start und erstellt für jede Webanwendung ein eindeutiges ServletContext-Objekt. Sie können sich ServletContext als globales Objekt vorstellen. Eine Webanwendung kann mehrere Servlets haben, die Daten über den globalen ServletContext gemeinsam nutzen können. Zu diesen Daten gehören die Initialisierungsparameter der Webanwendung, Dateiressourcen im Verzeichnis der Webanwendung usw. Da ServletContext alle Servlet-Instanzen enthält, können Sie ihn auch zum Weiterleiten von Servlet-Anfragen verwenden.

Erweiterungsmechanismus

Nach der Einführung der Servlet-Spezifikation müssen Sie sich keine Gedanken mehr über die Socket-Netzwerkkommunikation, das HTTP-Protokoll oder darüber machen, wie Ihre Geschäftsklassen instanziiert und aufgerufen werden, da diese durch die Servlet-Spezifikation standardisiert sind. Sie müssen sich nur noch darum kümmern, wie Sie Ihre Geschäftslogik implementieren. Für Programmierer ist das eine gute Sache, es hat aber auch eine unbequeme Seite. Der sogenannte Standard bedeutet, dass sich jeder daran halten muss und es wird immer dasselbe sein. Wenn dieser Standard jedoch nicht die individuellen Anforderungen Ihres Unternehmens erfüllen kann, gibt es ein Problem. Daher müssen Sie beim Entwerfen eines Standards oder einer Middleware die Skalierbarkeit vollständig berücksichtigen. Die Servlet-Spezifikation bietet zwei Erweiterungsmechanismen: Filter und Listener .

Filter ist ein Filter. Diese Schnittstelle ermöglicht Ihnen eine einheitliche, benutzerdefinierte Verarbeitung von Anfragen und Antworten. Sie können beispielsweise den Zugriff basierend auf der Häufigkeit von Anfragen beschränken oder den Antwortinhalt basierend auf verschiedenen Ländern und Regionen ändern. Das Funktionsprinzip des Filters ist wie folgt: Nachdem die Webanwendung bereitgestellt wurde, muss der Servlet-Container den Filter instanziieren und den Filter in eine Filterkette einbinden. Wenn eine Anforderung eingeht, holen Sie sich den ersten Filter und rufen Sie die Methode doFilter auf, die für den Aufruf des nächsten Filters in dieser Filterkette verantwortlich ist.

Listener ist ein weiterer Erweiterungsmechanismus. Wenn eine Webanwendung in einem Servlet-Container ausgeführt wird, treten innerhalb des Servlet-Containers weiterhin verschiedene Ereignisse auf, z. B. das Starten und Stoppen der Webanwendung, das Eintreffen von Benutzeranforderungen usw. Der Servlet-Container stellt einige Standardlistener bereit, um diese Ereignisse abzuhören. Wenn ein Ereignis eintritt, ist der Servlet-Container für den Aufruf der Listener-Methode verantwortlich. Natürlich können Sie Ihre eigenen Listener definieren, um die Ereignisse abzuhören, die Sie interessieren, und die Listener in web.xml konfigurieren. Beispielsweise implementiert Spring einen eigenen Listener, um auf das Startereignis von ServletContext zu hören. Der Zweck besteht darin, den globalen Spring-Container zu erstellen und zu initialisieren, wenn der Servlet-Container gestartet wird.

Tomcat-Download-Adresse: https://tomcat.apache.org/download-80.cgi

/bin: Speichert Skriptdateien zum Starten und Herunterfahren von Tomcat auf Windows- oder Linux-Plattformen.
/conf: Speichert verschiedene globale Konfigurationsdateien von Tomcat, von denen server.xml die wichtigste ist.
/lib: Speichert JAR-Dateien, auf die Tomcat und alle Webanwendungen zugreifen können.
/logs: speichert Protokolldateien, die bei der Ausführung von Tomcat generiert werden.
/work: speichert die nach der JSP-Kompilierung generierten Klassendateien.
/webapps: Tomcats Web-Anwendungsverzeichnis. Standardmäßig werden Web-Anwendungen in diesem Verzeichnis abgelegt.

Öffnen Sie das Tomcat-Protokollverzeichnis. Dabei handelt es sich um das Protokollverzeichnis unter dem Tomcat-Installationsverzeichnis. Die Protokollinformationen von Tomcat sind in zwei Kategorien unterteilt: Eine ist das Betriebsprotokoll, das hauptsächlich einige Informationen während des Betriebs aufzeichnet, insbesondere einige Protokollinformationen zu abnormalen Fehlern; die andere ist das Zugriffsprotokoll, das Zugriffszeit, IP-Adresse, Zugriffspfad und andere zugehörige Informationen aufzeichnet.

• catalina.***.log zeichnet hauptsächlich Informationen zum Tomcat-Startvorgang auf. In dieser Datei können Sie die JVM-Startparameter und die Protokollinformationen des Betriebssystems sehen.
• catalina.out ist Tomcats Standardausgabe (stdout) und Standardfehler (stderr), die im Startskript von Tomcat angegeben sind. Wenn es nicht geändert wird, werden stdout und stderr hierher umgeleitet. In dieser Datei können Sie also die Informationen sehen, die wir im Programm MyServlet.java ausgedruckt haben.
• localhost.**.log zeichnet hauptsächlich nicht behandelte Ausnahmen auf, die während des Initialisierungsprozesses der Webanwendung auftreten. Diese werden von Tomcat erfasst und in diese Protokolldatei ausgegeben.
• localhost_access_log.**.txt speichert das Anforderungsprotokoll für den Zugriff auf Tomcat, einschließlich IP-Adresse, Anforderungspfad, Zeit, Anforderungsprotokoll, Statuscode und anderen Informationen.
• manager.***.log/host-manager.***.log speichert die Protokollinformationen des in Tomcat integrierten Manager-Projekts.

Zusammenfassung:

1. Die Kernkomponenten von Tomcat verstehen
2. Detaillierte Erklärung der server.xml-Konfiguration

1. Tomcat-Komponenten verstehen

Wissenspunkte:

1. Beschreibung der Tomcat-Architektur
2. Detaillierte Einführung in Tomcat-Komponenten und -Beziehungen
3. Beschreibung der Tomcat-Startparameter
4. Beschreibung der Tomcat-Architektur

Tomcat ist ein JAVA-basierter Webcontainer, der die Servlet- und JSP-Spezifikationen in JAVA EE implementiert. Im Gegensatz zum Nginx-Apache-Server wird er im Allgemeinen für die dynamische Anforderungsverarbeitung verwendet. Die Architektur ist komponentenorientiert aufgebaut. Das heißt, die Gesamtfunktion wird durch die Montage von Komponenten vervollständigt. Darüber hinaus ist jede Komponente austauschbar, um Flexibilität zu gewährleisten.

2.Tomcat-Komponenten und -Beziehungen

Server und Service
Konnektor
HTTP 1.1
SSL-Verschlüsselung
AJP (Apache JServ Protocol) privates Apache-Protokoll, wird für den Apache-Reverse-Proxy Tomcat verwendet
Container
Motor motorcatalina
Die virtuelle Hostmaschine verteilt Anfragen basierend auf dem Domänennamen
Der Kontext isoliert jede WEB-Anwendung. Der ClassLoader jedes Kontexts ist unabhängig.
Komponente
Manager
Logger
Lader
Pipeline
Ventil (Ventil in einer Leitung)

2. Detaillierte Erläuterung der Tomcat server.xml-Konfiguration

Server

Stammelement: Konfiguration des Servers auf oberster Ebene. Hauptattribute: Port: Portnummer zur Ausführung des Shutdown-Befehls. Shutdown: Shutdown-Befehl.

Demonstrieren Sie die Verwendung von shutdown#Basierend auf telent, führen Sie den Befehl SHUTDOWN aus, um herunterzufahren (muss groß geschrieben werden) telnet 127.0.0.1 8005 SHUTDOWN

Service

Service: Kombinieren Sie mehrere Konnektoren und eine Engine zu einem Service. Sie können mehrere Services konfigurieren.

Konnektor

Connector: Wird verwendet, um Verbindungen unter einem angegebenen Protokoll zu empfangen und sie einer eindeutigen Engine zur Verarbeitung zuzuweisen. Primäre Eigenschaften:

• Protokoll Das Abhörprotokoll, der Standard ist http/1.1
• port gibt die Portnummer an, die auf der Serverseite erstellt werden soll
• minSpareThreads Die Anzahl der Threads, die erstellt werden, wenn der Server mit der Bearbeitung von Anfragen beginnt
• maxThreads Die maximale Anzahl von Threads, die zur Verarbeitung von Anfragen erstellt werden können
• enableLookups Wenn wahr, können Sie den tatsächlichen Hostnamen des Remote-Clients abrufen, indem Sie request.getRemoteHost() aufrufen, um eine DNS-Abfrage durchzuführen. Wenn falsch, wird keine DNS-Abfrage durchgeführt, sondern stattdessen die IP-Adresse des Remote-Clients zurückgegeben.
• redirectPort gibt die Portnummer an, zu der der Server nach dem Empfang einer SSL-Transportanforderung bei der Verarbeitung einer HTTP-Anforderung umleitet
• acceptCount gibt die Anzahl der Anfragen an, die in die Verarbeitungswarteschlange gestellt werden können, wenn alle verfügbaren Threads zur Verarbeitung von Anfragen verwendet werden. Anfragen, die diese Zahl überschreiten, werden nicht verarbeitet.
• connectionTimeout gibt die Timeout-Dauer an (in Millisekunden)
• SSLEnabled Gibt an, ob die SSL-Verifizierung aktiviert werden soll. Sie muss beim Zugriff über HTTPS aktiviert werden. Generieren Sie ein Zertifikat: keytool -genkey -v -alias testKey -keyalg RSA -validity 3650 -keystore D:\test.keystore
• [ ] Demonstration der Konfiguration mehrerer Connectoren

<Connector-Port="8860" Protokoll="org.apache.coyote.http11.Http11NioProtocol"
                VerbindungsTimeout="20000"
                UmleitungsPort="8862"
                URIEncoding="UTF-8"
                useBodyEncodingForURI="true"
                Komprimierung="ein" KomprimierungMinSize="2048"
compressableMimeType="text/html,text/xml,text/plain,text/javascript,text/css,anwendung/x-json,anwendung/json,anwendung/x-javascript"
                maxThreads="1024" minSpareThreads="200"
                AkzeptierenAnzahl="800"
                maxVerbindungen="10000"
                enableLookups="false"
        />

Motor

Engine: Der Executor, der zur Verarbeitung der Verbindung verwendet wird. Die Standard-Engine ist Catalina. In einem Dienst kann nur eine Engine konfiguriert werden. Hauptattribute: Name Engine-Name defaultHost Standardhost

Gastgeber

Virtuelle Maschine: Stimmt mit einer angegebenen virtuellen Maschine basierend auf dem Domänennamen überein. Ähnlich wie beim Server in nginx ist die Standard-VM localhost. Haupteigenschaften:

Demonstration der Konfiguration mehrerer Hosts

<Hostname="www.wukong.com" appBase="/usr/www/wukong" unpackWARs="true" autoDeploy="true"> 
	<Valve-Klassenname="org.apache.catalina.valves.AccessLogValve" Verzeichnis="Protokolle" Präfix="www.wukong.com.access_log" 
			Suffix=".txt" Muster="%h %l %u %t &quot;%r&quot; %s %b" /> 
</Host>

Kontext

Anwendungskontext: Unter einem Host können mehrere Kontexte konfiguriert werden und jeder Kontext verfügt über seinen eigenen unabhängigen Klassenpfad. Isolieren Sie sie voneinander, um ClassPath-Konflikte zu vermeiden. Primäre Eigenschaften:

Demonstration der Konfiguration mehrerer Kontexte

<Kontextpfad="/testweb" docBase="testweb.war" reloadbale="true"/>

Ventil : kann verstanden werden als

Die spezifische Konfiguration des Filters basiert auf der Unterklasse der spezifischen Valve-Schnittstelle. Das Folgende ist ein Valve-Zugriffsprotokoll

<Valve-Klassenname="org.apache.catalina.valves.AccessLogValve" Verzeichnis="Protokolle"
               Präfix="www.wukong.com.access_log" Suffix=".txt"
               Muster="%h %l %u %t &quot;%r&quot; %s %b" />

3. Schreiben eines Tomcat-Bereitstellungsskripts

Beschreibung der Tomcat-Startparameter

Wie erfolgt der Startvorgang von Tomcat?

1. Kopieren Sie die WAR-Datei in das Tomcat-Webanwendungsverzeichnis.
2. Führen Sie zum Starten das Skript startut.bat aus.
3. Während des Startvorgangs wird das War-Paket automatisch dekomprimiert und geladen.

Aber wenn wir ein WEB-Projekt in Eclipse oder Idea starten, entpacken wir dann auch das War-Paket in das Webapps-Verzeichnis? Offensichtlich nicht. Die tatsächliche Praxis besteht darin, ein Bereitstellungsverzeichnis außerhalb der Tomcat-Programmdatei zu erstellen, was auch in einer allgemeinen Produktionsumgebung getan wird: Das Tomcat-Programmverzeichnis und das Bereitstellungsverzeichnis sind getrennt. Um dies zu erreichen, müssen wir beim Start nur die Parameter CATALINA_HOME und CATALINA_BASE angeben.

| Startparameter| Beschreibung | |:----|:----| | JAVA_OPTS | JVM-Startparameter, Speicherkodierung festlegen usw. -Xms100m -Xmx200m -Dfile.encoding=UTF-8 | | JAVA_HOME | Geben Sie das JDK-Verzeichnis an. Wenn nicht festgelegt, suchen Sie es über die Java-Umgebungsvariable. | | CATALINA_HOME | Stammverzeichnis des Tomcat-Programms | | CATALINA_BASE | Bereitstellungsverzeichnis der Anwendung, Standard ist $CATALINA_HOME | | CATALINA_OUT | Ausgabeverzeichnis des Anwendungsprotokolls: Standard ist $CATALINA_BASE/log | | CATALINA_TMPDIR | Temporäres Anwendungsverzeichnis: Standard: $CATALINA_BASE/temp |

Sie können ein Skript schreiben, um eine benutzerdefinierte Konfiguration zu implementieren:

ln -s /home/wukong/apache-tomcat-8.5.56 apache-tomcat

Startskripte aktualisieren

#!/bin/bash
 export JAVA_OPTS="-Xms100m -Xmx200m"
export CATALINA_HOME=/home/wukong/apache-tomcat
exportiere CATALINA_BASE="`pwd`"
 
Fall $1 in
        Start)
        $CATALINA_HOME/bin/catalina.sh starten
                Echo-Start erfolgreich!!
        ;;
        stoppen)
                $CATALINA_HOME/bin/catalina.sh stoppen
                Echo-Stopp erfolgreich!!
        ;;
        Neustart)
        $CATALINA_HOME/bin/catalina.sh stoppen
                Echo-Stopp erfolgreich!!
                Schlaf 3
        $CATALINA_HOME/bin/catalina.sh starten
        Echo-Start erfolgreich!!
        ;;
        Version)
        $CATALINA_HOME/bin/catalina.sh Version
        ;;
        Konfigurationstest)
        $CATALINA_HOME/bin/catalina.sh configtest
        ;;
        esac
Ausfahrt 0

Docker startet 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/logs -v /usr/local/tuling-project/tomcat-test/conf:/usr/local/tomcat/conf --privileged=true tomcat:8

Quellcode-Build

Download-Adresse: https://tomcat.apache.org/download-80.cgi

Konfiguration

1. Entpacken Sie den Quellcode apache-tomcat-8.5.57-src

2. Fügen Sie die POM-Datei im Verzeichnis apache-tomcat-8.5.57-src hinzu

<?xml version="1.0" encoding="UTF-8"?>
<Projekt 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">
 
    <modelVersion>4.0.0</modelVersion>
    <groupId>org.apache.tomcat</groupId>
    <artifactId>Tomcat8.0</artifactId>
    <name>Tomcat8.0</name>
    <version>8.0</version>
 
    <Bauen>
        <finalName>Tomcat8.0</finalName>
        <Quellverzeichnis>java</Quellverzeichnis>
        <testSourceDirectory>Test</testSourceDirectory>
        <Ressourcen>
            <Ressource>
                <Verzeichnis>java</Verzeichnis>
            </Ressource>
        </Ressourcen>
        <Testressourcen>
            <Testressource>
                <Verzeichnis>Test</Verzeichnis>
            </TestRessource>
        </testResources>
        <Plugins>
            <Plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>Maven-Compiler-Plugin</artifactId>
                <version>2.3</version>
                <Konfiguration>
                    <Kodierung>UTF-8</Kodierung>
                    <Quelle>1.8</Quelle>
                    <target>1,8</target>
                </Konfiguration>
            </plugin>
        </plugins>
    </bauen>
 
    <Abhängigkeiten>
        <Abhängigkeit>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>Test</scope>
        </Abhängigkeit>
        <Abhängigkeit>
            <groupId>org.easymock</groupId>
            <artifactId>einfaches Mock</artifactId>
            <version>3.4</version>
        </Abhängigkeit>
        <Abhängigkeit>
            <groupId>Ameise</groupId>
            <artifactId>Ameise</artifactId>
            <version>1.7.0</version>
        </Abhängigkeit>
        <Abhängigkeit>
            <groupId>wsdl4j</groupId>
            <artifactId>wsdl4j</artifactId>
            <version>1.6.2</version>
        </Abhängigkeit>
        <Abhängigkeit>
            <groupId>javax.xml</groupId>
            <artifactId>jaxrpc</artifactId>
            <version>1.1</version>
        </Abhängigkeit>
        <Abhängigkeit>
            <groupId>org.eclipse.jdt.core.compiler</groupId>
            <artifactId>ecj</artifactId>
            <version>4.5.1</version>
        </Abhängigkeit>
 
    </Abhängigkeiten>
</Projekt>

3. Erstellen Sie ein neues Catalina-Home-Verzeichnis im selben Verzeichnis wie Apache-Tomcat-8.5.57-src und stellen Sie sicher, dass die Dateien im Verzeichnis wie folgt lauten

Hinweis : Wenn sich im obigen Ordner ein Ordner namens apache-tomcat-8.5.57-src befindet, schneiden Sie ihn einfach aus. Wenn nicht, erstellen Sie einen neuen. Bin conf Webapps sollte aus apache-tomcat-8.5.57-src ausgeschnitten werden.

4. Bringen Sie die Idee in das Projekt ein

Datei->Öffnen Wählen Sie die entpackte Datei C:\Users\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src

Konfigurationsstart

Hauptklasse: org.apache.catalina.startup.BootstrapVmOptions: -Dcatalina.home=C:\Benutzer\wukong\Downloads\apache-tomcat-8.5.57-src\apache-tomcat-8.5.57-src\catalina-home

Startfehler

TestCookieFilter meldet einen Fehler: Diese Klasse CookieFilter kann nicht gefunden werden

Lösung:

1. Löschen: TestCookieFilter

Greifen Sie nach dem Start auf localhost:8080 zu und melden Sie org.apache.jasper.JasperException: java.lang.NullPointerException

Lösung:

org.apache.catalina.startup.Bootstrap Codeblock hinzufügen

{
        JasperInitializer-Initialisierer = neuer JasperInitializer();
         }

Oben finden Sie ausführliche Erläuterungen zu den Kernkomponenten und der Anwendungsarchitektur von Tomcat. Weitere Informationen zu den Kernkomponenten und der Anwendungsarchitektur von Tomcat finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!