Einführung
Es war einmal, dass Java seine Position dadurch stärkte, dass es Webanwendungen als Priorität wählte. Java hatte seit seinen Anfängen Schwierigkeiten, sich zurechtzufinden. Zuerst habe ich Applets vorgeschlagen. Dies hat Entwicklern viele Möglichkeiten geboten, dynamische Inhalte auf statischen HTML-Seiten zu erstellen. Allerdings entsprachen Applets aus vielen Gründen nicht den Erwartungen: Sicherheit, Overhead und andere. Dann schlugen die Entwickler der Java-Sprache eine Alternative vor –
die Servlet-API . Und es stellte sich heraus, dass es die richtige Entscheidung war.
Die Servlet-API ist die Spezifikation, auf der jede Java-Webanwendung basiert, sei es eine webbasierte Anwendung oder ein Webdienst, der Informationen wie angefordert zurückgibt. Daher beginnt der Weg zum Verständnis der Funktionsweise von Java-Webanwendungen mit dem Verständnis der Servlet-API.
Servlet-API
Die Servlet-API ist also das, was die Sprachentwickler den Java-Entwicklern angeboten haben. Die Servlet-API ist eine Spezifikation, die unsere Hauptfragen beantworten sollte. Sie finden es hier: „
JSR-000340 JavaTM Servlet 3.1 Final Release for Evaluation “. Im Kapitel „
1.1 Was ist ein Servlet? “ heißt es, dass
ein Servlet eine auf Java-Technologie basierende Webkomponente ist , die dynamische Inhalte (also Inhalte) erstellt. „Java-basiert“ bedeutet, dass
ein Servlet eine in Bytecode kompilierte Java-Klasse ist . Servlets werden von einem Servlet-Container verwaltet, der manchmal auch Servlet Engine genannt wird.
Ein Servlet-Container ist eine Webserver-Erweiterung , die Servlet-Funktionalität bereitstellt. Servlets wiederum ermöglichen die Interaktion mit dem Client im Anforderungs-/Antwort-Paradigma, das vom Servlet-Container implementiert wird. Im Kapitel „
1.2 Was ist ein Servlet-Container? “ heißt es, dass
ein Servlet-Container Teil eines Webservers oder Anwendungsservers ist, der Netzwerkdienste bereitstellt, über die Anfragen und Antworten gesendet, MIME-basierte Anfragen und Antworten generiert und verarbeitet werden . Darüber hinaus verwalten Servlet-Container den Lebenszyklus von Servlets (d. h. entscheiden, wann sie erstellt, gelöscht werden usw.). Alle Servlet-Container müssen das HTTP-Protokoll unterstützen, um Anfragen zu empfangen und Antworten zu senden. An dieser Stelle möchte ich hinzufügen, dass MIME ein Standard ist, eine Spezifikation, die angibt, wie Informationen kodiert und Nachrichten formatiert werden sollen, damit sie über das Internet gesendet werden können.
Webserver
Ein Webserver ist ein Server, der HTTP-Anfragen von Clients akzeptiert und ihnen HTTP-Antworten bereitstellt (normalerweise zusammen mit einer HTML-Seite, einem Bild, einer Datei oder anderen Daten). Angeforderte Ressourcen werden durch URLs identifiziert. Einer der beliebtesten Webserver mit Servlet-API-Unterstützung ist
Apache Tomcat . Die meisten Webserver sind komplexe Maschinen, die aus verschiedenen Komponenten bestehen, von denen jede spezifische Funktionen ausführt. Zum Beispiel:
Anschlüsse
— Am Eingang haben wir Connectors (also Konnektoren), die eingehende Anfragen von Clients entgegennehmen. Der HTTP-Connector in Tomcat wird mithilfe der Komponente „Coyote“ implementiert. Connectors empfangen Daten vom Client und geben diese an die Tomcat Engine weiter.
Servlet-Container – Tomcat Engine wiederum verarbeitet die vom Client empfangene Anfrage mithilfe der „Catalina“-Komponente, bei der es sich um einen Servlet-Container handelt. Weitere Einzelheiten finden Sie in der Tomcat-Dokumentation: „
Architekturübersicht “. Es gibt andere Webserver, die die Servlet-API-Spezifikation unterstützen. Zum Beispiel „
Jetty “ oder „
Undtow “. Ihre Architektur ist ähnlich. Wenn Sie also das Prinzip der Arbeit mit einem Servlet-Container verstehen, können Sie zur Arbeit mit einem anderen wechseln.
Internetanwendung
Damit wir also eine Webanwendung ausführen können, benötigen wir einen Webserver, der die Servlet-API unterstützt (d. h. einen, der über eine Erweiterungskomponente verfügt, die die Servlet-API-Unterstützung für den Webserver implementiert). Bußgeld.
Was ist überhaupt eine Webanwendung? Gemäß dem Kapitel „
10 Webanwendungen “ der Servlet-API-Spezifikation ist
eine Webanwendung eine Sammlung von Servlets, HTML-Seiten, Klassen und anderen Ressourcen, die eine endgültige Anwendung auf einem Webserver bilden. Gemäß Kapitel „
10.6 Web Application Archive File “ kann eine Webanwendung in Web ARchive (ein Archiv mit einer WAR-Erweiterung) gepackt werden.
Wie auf der Seite „ Glossar-219 “ angegeben :
Das heißt, WAR wird anstelle von JAR erstellt, um zu zeigen, dass es sich um eine Webanwendung handelt. Die nächste wichtige Tatsache: Wir müssen eine bestimmte Verzeichnisstruktur in unserem WAR-Archiv haben. In der Servlet-API-Spezifikation im Kapitel „
10.5 Verzeichnisstruktur “. In diesem Kapitel heißt es, dass es ein spezielles Verzeichnis namens „WEB-INF“ gibt. Das Besondere an diesem Verzeichnis ist, dass es für den Client nicht sichtbar ist und ihm nicht direkt angezeigt wird, aber für den Servlet-Code zugänglich ist. Außerdem steht dort, was das WEB-INF-Verzeichnis enthalten kann:
Aus dieser gesamten Liste kennen wir den Punkt über eine web.xml- Datei mit dem Namen
Deployment Descriptor nicht und verstehen ihn nicht . Was ist es? Das Kapitel „
14. Deployment Descriptor “ ist dem Deployment Deskriptor gewidmet. Kurz gesagt ist
ein Bereitstellungsdeskriptor eine XML-Datei, die beschreibt, wie unsere Webanwendung auf einem Webserver bereitgestellt (d. h. ausgeführt) wird. Der Bereitstellungsdeskriptor gibt beispielsweise an, über welche URLs auf unsere Anwendung zugegriffen werden soll, Sicherheitseinstellungen, die sich auf unsere Anwendung beziehen usw. werden angegeben. Im Kapitel „
14.2 Regeln für die Verarbeitung der Bereitstellung “ heißt es, dass web.xml einer Schemavalidierung unterzogen wird, bevor unsere Anwendung konfiguriert und gestartet wird (d. h. es wird überprüft, ob der Inhalt von web.xml gemäß dem Schema korrekt geschrieben ist). . Und im Kapitel „
14.3 Deployment Descriptor “ wird darauf hingewiesen, dass sich das Diagramm hier befindet:
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd Wenn wir uns den Inhalt der Datei ansehen, sehen wir:
Welches Schema wird für XML-Dateien verwendet? Die Schemata geben an, wie ein XML-Dokument korrekt ausgefüllt wird: Welche Elemente können verwendet werden, welche Art von Daten können in den Elementen angegeben werden, in welcher Reihenfolge sollten die Elemente angeordnet sein, welche Elemente sind erforderlich usw. Sie können das Schema eines XML-Dokuments mit einer Schnittstelle in Java vergleichen, da das Schema in Java auch angibt, wie Klassen geschrieben werden sollen, die eine bestimmte Schnittstelle erfüllen (d. h. eine bestimmte Schnittstelle implementieren). Wir verfügen also über geheimes Wissen und sind bereit, unsere erste Webanwendung zu erstellen!
Erstellen einer Webanwendung
Die Arbeit mit einer modernen Java-Anwendung ohne den Einsatz automatischer Projekterstellungssysteme ist kaum vorstellbar. Zu den beliebtesten Systemen gehören
Maven und Gradle . Für diese Überprüfung verwenden wir Gradle.
Die Installation von Gradle wird auf der offiziellen Website beschrieben . Um eine neue Anwendung zu erstellen, benötigen wir ein in Gradle integriertes Plugin: „
Build Init Plugin “. Um eine Java-Anwendung zu erstellen, müssen Sie den folgenden Befehl ausführen:
gradle init --type java-application
Nachdem wir das Projekt erstellt haben, müssen wir die Datei
build.gradle bearbeiten . Dabei handelt es sich um das sogenannte Build-Skript (weitere Einzelheiten finden Sie in der Gradle-Dokumentation: „
Schreiben von Build-Skripten “). In dieser Datei werden die Zusammenstellung des Projekts und andere Aspekte der Arbeit mit einem Java-Projekt beschrieben. Der Plugins-Block beschreibt, welche „
Gradle-Plugins “ für das aktuelle Gradle-Projekt verwendet werden sollen. Plugins erweitern die Möglichkeiten unseres Projekts. Das Standard-Plugin ist beispielsweise „
java “. Dieses Plugin wird immer dann verwendet, wenn wir Java-Unterstützung benötigen. Aber wir brauchen das Plugin „
Anwendung “ nicht , weil... In der Beschreibung heißt es, dass damit eine „ausführbare JVM-Anwendung“ erstellt wird, d. h. Ausführen von JVM-Anwendungen. Wir müssen eine Webanwendung in Form eines WAR-Archivs erstellen. Und wenn wir in der Gradle-Dokumentation nach dem Wort WAR suchen, finden wir „
War Plugin “. Daher werden wir die folgenden Plugins angeben:
plugins {
id 'java'
id 'war'
}
Auch in den „
War Plugin Default Settings “ heißt es, dass das Verzeichnis mit allen Inhalten der Webanwendung „src/main/webapp“ sein soll, es soll das gleiche WEB-INF-Verzeichnis geben, in dem sich auch die web.xml befinden soll gelegen. Lassen Sie uns eine solche Datei erstellen. Wir werden es etwas später ausfüllen, weil... hierzu liegen uns noch nicht genügend Informationen vor. Im Block „Abhängigkeiten“ geben wir die Abhängigkeiten unseres Projekts an, also jene Bibliotheken/Frameworks, ohne die unsere Anwendung nicht funktionieren kann. In diesem Fall schreiben wir eine Webanwendung, was bedeutet, dass wir ohne die Servlet-API nicht arbeiten können:
dependencies {
providedCompile 'javax.servlet:javax.servlet-api:3.1.0'
testCompile 'junit:junit:4.12'
}
ProvideCompile bedeutet, dass die Abhängigkeit nicht in unser WAR-Archiv der Webanwendung aufgenommen werden muss: Sie wird nur für die Kompilierung benötigt. Und wenn diese Abhängigkeit ausgeführt wird, wird sie von einer anderen Person (d. h. dem Webserver) bereitgestellt. Nun, wir hinterlassen im Build-Skript Informationen darüber, welches Abhängigkeits-Repository wir verwenden möchten – alle angegebenen Abhängigkeiten werden daraus heruntergeladen:
repositories {
jcenter()
}
Wir entfernen alles andere aus der Build-Skriptdatei. Bearbeiten wir nun die Klasse src\main\java\App.java. Machen wir daraus ein Servlet. In der Servlet-API-Spezifikation im Kapitel „
KAPITEL 2. Die Servlet-Schnittstelle “ heißt es, dass die Servlet-Schnittstelle über eine Basisimplementierung
von HttpServlet verfügt , die in den meisten Fällen ausreichen sollte und Entwickler nur davon erben müssen. Und im Kapitel „
2.1.1 HTTP-spezifische Methoden zur Anforderungsverarbeitung “ werden die wichtigsten Methoden angegeben, die eingehende Anforderungen verarbeiten. Schreiben wir also die App.java-Klasse neu:
import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.PrintWriter;
import java.io.IOException;
public class App extends HttpServlet {
public String getGreeting() {
return "Hello world.";
}
public void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException {
PrintWriter out = resp.getWriter();
out.println(this.getGreeting());
out.close();
}
}
Wir scheinen also alles bereit zu haben. Es bleibt nur noch, den Deployment-Deskriptor korrekt zu schreiben. Kopieren Sie aus dem Diagramm den folgenden Text in web.xml:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="..."
version="3.1">
...
</web-app>
Und auch der darin angegebene Pfad zum Schema:
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd Schauen wir uns nun ein Beispiel an, wie web.xml in der Servlet-API-Spezifikation aussehen sollte. Dieses Beispiel finden Sie im Kapitel „
14.5.1 Ein einfaches Beispiel “. Kombinieren wir die Angaben im Diagramm mit dem in der Spezifikation angegebenen Beispiel. Wir erhalten Folgendes:
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee
http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
version="3.1">
<display-name>A Simple Web Application</display-name>
<servlet>
<servlet-name>app</servlet-name>
<servlet-class>App</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/app</url-pattern>
</servlet-mapping>
</web-app>
Wie Sie sehen können, haben wir das Schema und die SchemaLocation verwendet, die zuvor angegeben wurden. Und die Beschreibung der Elemente selbst wurde dem Beispiel aus Kapitel 14.5.1 entnommen. Wenn wir alles richtig gemacht haben, werden wir die Gradle-War-Aufgabe fehlerfrei ausführen:
Starten einer Webanwendung
Wie startet eine Webanwendung? Befassen wir uns zunächst mit der komplexeren Option. Wir haben bereits erwähnt, dass es einen Apache Tomcat-Webserver gibt, der die Servlet-API unterstützt. Das bedeutet, dass wir unser gesammeltes Kriegsarchiv (man sagt auch „deploy“) auf diesem Server bereitstellen können. Laden Sie auf der Seite „
Tomcat herunterladen “ im Abschnitt „Binärdistributionen“ den Liefertyp „Core“ im ZIP-Format herunter. Und entpacken Sie das heruntergeladene Archiv in ein Verzeichnis, zum Beispiel in C:\Apache-Tomcat-9.0.14. Bevor wir den Server starten, öffnen wir die Datei zum Bearbeiten
conf\tomcat-users.xmlund fügen die folgende Zeile hinzu:
<user username="tomcat" password="tomcat" roles="tomcat,manager-gui,admin-gui"/> Gehen Sie nun in der Befehlszeile in das Verzeichnis bin und führen Sie aus
catalina.bat start. Standardmäßig ist die Serverkonsole unter verfügbar
http://localhost:8080/manager. Der Benutzername und das Passwort sind dieselben, die wir in tomcat-users.xml angegeben haben. Tomcat verfügt über ein „webapps“-Verzeichnis, das Webanwendungen enthält. Wenn wir unsere eigenen einsetzen wollen, müssen wir unser Kriegsarchiv dorthin kopieren. Als wir zuvor den Befehl gradle war ausgeführt haben,
\build\libs\wurde im Verzeichnis ein Kriegsarchiv erstellt. Das ist es, was wir kopieren müssen. Aktualisieren Sie nach dem Kopieren die Seite
http://localhost:8080/managerund sehen Sie:
Nachdem wir fertig sind
http://localhost:8080/javaweb/app, wenden wir uns unserem Servlet zu, denn Wir haben zuvor die /app-Anfrage dem App-Servlet „zugeordnet“ (d. h. zugeordnet). Es gibt eine schnellere Möglichkeit, die Funktionsweise der Anwendung zu überprüfen. Und dabei hilft uns wieder das Montagesystem. Im Build-Skript unseres Gradle-Projekts können wir dem Plugin-Bereich ein neues Plugin „
Grettyid "org.gretty" version "2.3.1" “ hinzufügen: Und jetzt können wir eine Gradle-Aufgabe ausführen, um unsere Anwendung auszuführen:
gradle appRun
Weitere Informationen finden Sie unter „
Gretty-Plugin hinzufügen und App ausführen “.
Spring- und Servlet-API
Servlets sind die Basis von allem. Und selbst das mittlerweile beliebte Spring Framework ist nichts anderes als ein Add-on zur Servlet-API. Zunächst einmal ist
das Spring Framework eine neue Abhängigkeit für unser Projekt. Fügen wir es daher dem Build-Skript im Abhängigkeitsblock hinzu:
compile 'org.springframework:spring-webmvc:5.1.3.RELEASE' In der Spring Framework-Dokumentation gibt es ein Kapitel „
1.1. DispatcherServlet “. Darin heißt es, dass das Spring Framework auf dem „Front-Controller“-Muster basiert – das heißt, es gibt ein zentrales Servlet namens „
DispatcherServlet “. Alle Anfragen kommen an dieses Servlet und es delegiert Aufrufe an die erforderlichen Komponenten. Sehen Sie, auch hier gibt es Servlets. Sie müssen dem Bereitstellungsdeskriptor einen Listener hinzufügen:
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
Dies ist ein Servlet-Kontextereignis-Listener. Das heißt, wenn der Servlet-Kontext startet, wird auch der Spring-Kontext (WebApplicationContext) gestartet.
Was ist Servlet-Kontext? Es wird in der Servle-API-Spezifikation im Kapitel „
KAPITEL 4. Servlet-Kontext “ beschrieben. Ein Servlet-Kontext ist die „Ansicht“ eines Servlets auf die Webanwendung, in der die Servlets ausgeführt werden. Jede Webanwendung verfügt über einen eigenen Servlet-Kontext. Als nächstes müssen Sie zum Aktivieren des Spring Frameworks context-param angeben – den Initialisierungsparameter für den Servlet-Kontext.
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/app-context.xml</param-value>
</context-param>
Und
die DispatcherServlet- Definition vervollständigt die Konfiguration :
<servlet>
<servlet-name>app</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value></param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>app</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
Und jetzt müssen wir nur noch die in contextConfigLocation angegebene Datei ausfüllen. Wie das geht, ist in der Spring Framework-Dokumentation im Kapitel „1.3.1. Deklaration“ beschrieben:
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:p="http://www.springframework.org/schema/p"
xmlns:mvc="http://www.springframework.org/schema/mvc"
xmlns:context="http://www.springframework.org/schema/context"
xsi:schemaLocation="
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-context.xsd
http://www.springframework.org/schema/mvc
http://www.springframework.org/schema/mvc/spring-mvc.xsd">
<context:component-scan base-package="ru.javarush.javaweb"/>
<mvc:annotation-driven/>
</beans>
Hier ist es wichtig, nicht nur anzugeben, welches Paket gescannt werden soll, sondern auch, dass wir annotationsgesteuert sein wollen, das heißt, die Annotationen steuern, wie Spring funktionieren wird. Jetzt müssen Sie nur noch das Paket ru.javarush.javaweb erstellen und die Spring-Controller-Klasse darin platzieren:
package ru.javarush.javaweb;
import org.springframework.stereotype.Controller;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.ResponseBody;
@Controller
public class SpringController {
@GetMapping("/app")
@ResponseBody
public String getGreeting() {
return "Hello world.";
}
}
Wenn wir nun gradle appRun ausführen und zur Adresse gehen,
http://127.0.0.1:8080/javaweb/apperhalten wir das gleiche Hello World. Wie Sie sehen, ist das Spring Framework eng mit der Servlet-API verknüpft und nutzt diese, um darauf zu arbeiten.
Anmerkungen
Wie wir gesehen haben, sind Anmerkungen praktisch. Und wir waren nicht die Einzigen, die das dachten. Daher erschien in der Servlet-API-Spezifikation ab Version 3.0 das Kapitel „
KAPITEL 8 Annotationen und Pluggability “, das angibt, dass Servlet-Container die Fähigkeit unterstützen müssen, durch Annotationen anzugeben, was zuvor im Deployment Descriptor angegeben wurde. Somit kann web.xml vollständig aus dem Projekt entfernt werden, und über der Servlet-Klasse können Sie die Annotation
@WebServlet angeben und angeben, welchem Pfad das Servlet zugeordnet werden soll. Hier scheint alles klar zu sein. Aber was wäre, wenn wir Spring mit dem Projekt verbinden würden, was komplexere Einstellungen erfordert? Hier ist alles etwas komplizierter. Erstens heißt es in der Spring-Dokumentation, dass Sie zum Konfigurieren von Spring ohne web.xml Ihre eigene Klasse verwenden müssen, die WebApplicationInitializer implementiert. Weitere Einzelheiten finden Sie im Kapitel „
1.1. DispatcherServlet “. Es stellt sich heraus, dass dies ein Frühlingskurs ist. Wie wird hier dann die Servlet-API verwendet? Tatsächlich wurde
der ServletContainerInitializer zur Servlet-API 3.0 hinzugefügt . Mithilfe eines speziellen Mechanismus in Java (
SPI genannt ) spezifiziert Spring seinen Servlet-Container-Initialisierer namens
SpringServletContainerInitializer. Im Gegenzug sucht es bereits nach Implementierungen von WebApplicationInitializer, ruft die erforderlichen Methoden auf und nimmt die erforderlichen Einstellungen vor. Weitere Einzelheiten finden Sie unter „
Wie der Servlet-Container WebApplicationInitializer-Implementierungen findet “. Die oben genannten Einstellungen können wie folgt vorgenommen werden:
package ru.javarush.javaweb.config;
import org.springframework.web.WebApplicationInitializer;
import org.springframework.web.context.ContextLoaderListener;
import org.springframework.web.context.support.AnnotationConfigWebApplicationContext;
import org.springframework.web.servlet.DispatcherServlet;
import javax.servlet.ServletContext;
import javax.servlet.ServletException;
import javax.servlet.ServletRegistration;
public class AppInitializer implements WebApplicationInitializer {
@Override
public void onStartup(ServletContext servletContext) throws ServletException {
AnnotationConfigWebApplicationContext ctx = new AnnotationConfigWebApplicationContext();
ctx.register(AppConfig.class);
servletContext.addListener(new ContextLoaderListener(ctx));
ctx.setServletContext(servletContext);
ServletRegistration.Dynamic servlet =
servletContext.addServlet("dispatcher", new DispatcherServlet(ctx));
servlet.addMapping("/");
servlet.setLoadOnStartup(1);
}
}
Mithilfe der „
Java-basierten Konfiguration “ geben wir nun an, welches Paket gescannt werden soll, und aktivieren Anmerkungen:
package ru.javarush.javaweb.config;
import org.springframework.context.annotation.ComponentScan;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.EnableWebMvc;
@Configuration
@EnableWebMvc
@ComponentScan(basePackages = "ru.javarush.javaweb.controllers")
public class AppConfig {
}
Und der SpringController selbst wurde nach verschoben
ru.javarush.javaweb.controllers, sodass sich die Konfiguration beim Scannen nicht selbst findet, sondern nur nach Controllern sucht.
Zusammenfassend
Ich hoffe, dieser Überblick hat etwas Aufschluss darüber gegeben, wie Webanwendungen in Java funktionieren. Dies ist nur die Spitze des Eisbergs, aber ohne die Grundlagen zu verstehen, ist es schwierig zu verstehen, wie Technologien, die auf dieser Grundlage basieren, funktionieren. Die Servlet-API ist der zentrale Teil jeder Java-Webanwendung, und wir haben untersucht, wie andere Frameworks darin passen. Um fortzufahren, können Sie die folgenden Materialien anzeigen:
#Wjatscheslaw
GO TO FULL VERSION