Einführung in Spring Boot

Einführung in Spring Boot

0:00 Spring Boot ist heute für viele Java-Teams der Standardweg, und trotzdem lohnt sich die Frage, was dieses Werkzeug eigentlich tut. Denn die ehrliche Antwort lautet: erstaunlich wenig Neues. Spring Boot erfindet kein neues Programmiermodell und ersetzt auch nicht das Spring Framework. Es nimmt Ihnen Entscheidungen ab, die Sie sonst jedes Mal von Hand treffen müssten.

0:21 In diesem Modul bauen wir ein leeres Projekt auf, lassen es laufen und schauen uns genau an, wer dabei welche Arbeit übernommen hat. Am Ende sollten Sie zwei Begriffe sicher trennen können: Starter und Autokonfiguration. Auf denen ruht alles Weitere.

Einführung in Spring Boot

0:36 Der erste Tag beginnt beim Fundament. Wir klären, was Spring Boot dem Spring Framework voraushat, richten die Beispielanwendung ein und lassen sie zum ersten Mal laufen. Danach schauen wir hinter die Kulissen: in die Projektdatei, in die Startklasse, in den Mechanismus, der beim Hochfahren alles verdrahtet. Das klingt nach Grundlagen, und das ist es auch.

0:56 Aber es ist die Sorte Grundlage, die später den Unterschied macht zwischen jemandem, der Spring Boot bedient, und jemandem, der versteht, warum es sich so verhält.

Was Spring Boot abnimmt

1:06 Fangen wir mit dem Schmerz an, nicht mit der Funktionsliste. Wer schon einmal eine Spring-Anwendung von Grund auf aufgesetzt hat, kennt das Gefühl: Man ist einen halben Tag beschäftigt und hat noch keine einzige fachliche Zeile geschrieben. Genau dort setzt Spring Boot an. Stellen Sie sich einen sehr gut sortierten Werkzeugkasten vor. Alles ist da, in hoher Qualität, für jeden denkbaren Zweck. Genau das ist das Spring Framework.

1:32 Der Haken: Ein Werkzeugkasten ist noch kein eingerichteter Arbeitsplatz. Sie müssen wissen, welches Werkzeug Sie brauchen, es herausholen, einstellen und mit den anderen zusammenbringen. Spring Boot legt über diesen Kasten eine Schicht, die genau das übernimmt — Abhängigkeiten verwalten und Komponenten automatisch konfigurieren.

1:52 Der Unterschied ist keiner der Fähigkeiten, sondern einer des Startpunkts. Sie beginnen bei der Fachlichkeit statt beim Gerüst. Das klingt bescheiden, verändert im Alltag aber sehr viel. Was hier steht, klingt nach Bequemlichkeit, ist aber vor allem eine Frage der Fehleranfälligkeit. Eine handverlesene Bibliotheksliste mit passenden Versionsnummern zu pflegen, ist keine intellektuelle Leistung, sondern eine Quelle für Konflikte, die erst zur Laufzeit auffallen.

2:18 Dasselbe gilt für Datenquelle und Transaktionsmanager: Der Code dafür sieht in jedem Projekt fast gleich aus, und genau deshalb liest ihn irgendwann niemand mehr aufmerksam. Wenn Sie nach wenigen Minuten ein laufendes Programm haben statt nach einem halben Tag, ist der eigentliche Gewinn nicht die gesparte Zeit. Es ist, dass Sie früher etwas Lauffähiges vor sich haben, an dem Sie Annahmen prüfen können.

2:41 Die Logik dieser Tabelle ist eine Kette, kein Nebeneinander. Ganz unten liegen die Bausteine des Spring Framework — mächtig, aber ohne Meinung dazu, welche davon Sie nehmen sollen. Darüber trifft Spring Boot genau diese Vorauswahl. Der Starter ist dabei die Einheit, in der Sie Ihren Bedarf ausdrücken: Ich brauche eine Webanwendung, ich brauche Datenbankzugriff.

3:02 Und die Autokonfiguration ist das, was daraus tatsächlich laufende Komponenten macht. Lesen Sie die rechte Spalte besonders aufmerksam. Sie beschreibt, was Ihnen bleibt — und das ist bemerkenswert konstant: Es sind immer die fachlichen Entscheidungen. Die nimmt Ihnen keine Ebene ab. Diese drei Missverständnisse haben eine gemeinsame Wurzel: Man hält Spring Boot für etwas anderes, als es ist.

3:26 Wer es für einen Ersatz des Spring Framework hält, sucht Konzepte an der falschen Stelle und wundert sich, warum die Dokumentation ständig auf das Framework verweist. Wer erwartet, dass die Autokonfiguration fachliche Entscheidungen mitträgt, wird enttäuscht — sie richtet Technik ein, mehr nicht. Und der dritte Punkt ist der häufigste im Alltag: Man schreibt aus Gewohnheit Gerüstcode, den längst ein Starter mitbringt. Der Code funktioniert, er ist nur überflüssig.

3:53 Solche Stellen fallen erst auf, wenn jemand sie testweise entfernt.

Werkzeuge und Beispielanwendung

3:57 Bevor es losgeht, kurz das Praktische: was auf Ihrem Rechner liegen sollte und welche Anwendung uns die nächsten zwei Tage begleitet. Beides ist schnell erzählt, aber die Beispielanwendung verdient Aufmerksamkeit — sie ist der rote Faden durch alle sieben Module. Unsere Beispielanwendung heißt Radwerk und verwaltet die Aufträge einer Fahrradwerkstatt.

4:18 Sie nimmt Reparaturaufträge an, führt sie durch ihre Zustände und gibt Auskunft über den Betrieb. Warum eine Werkstatt? Weil die Domäne alles mitbringt, was wir brauchen, ohne dass Sie sie erklärt bekommen müssen: Es gibt Termine, es gibt buchbare Leistungen, es gibt Anmeldungen, und es gibt Daten, die man unterschiedlich speichern möchte.

4:37 Wichtig ist noch eine Abgrenzung: Wir bauen ausschließlich das Backend als REST-Schnittstelle. Eine Oberfläche gehört bewusst nicht dazu — in der Praxis säße dort ein Frontend, das genau diese Schnittstelle aufruft. Die Versuchung bei Seminaren ist groß, für jedes Thema ein frisches Miniaturbeispiel zu bauen. Das wirkt aufgeräumt, hat aber einen Preis: Jedes Mal beginnt das Verstehen von vorn.

5:00 Mit einem durchgehenden Beispiel ist es umgekehrt. Wenn in Modul vier die Datenbank dazukommt, passiert das an einer Stelle, die Sie schon kennen — Sie können sich ganz auf das Neue konzentrieren. Und noch etwas spricht dafür: Fehler bleiben nachvollziehbar. Wenn etwas nicht läuft, ist der Kontext derselbe wie gestern. Am Ende der zwei Tage steht ein Programm, das tatsächlich läuft, und kein Ordner voller Fragmente.

5:25 Statt diese Liste vorzulesen, zwei Hinweise dazu. Der erste betrifft Java: Spring Boot 4 verlangt mindestens Version 17, wir arbeiten hier durchgehend mit Java 25. Wenn Sie eine ältere Version haben, klären Sie das jetzt und nicht in Modul sieben. Der zweite betrifft Docker. Es steht hier unten, wirkt dadurch optional, ist es aber für die Module fünf bis sieben nicht wirklich.

5:48 Falls Sie auf einem verwalteten Firmenrechner arbeiten, auf dem Sie nichts installieren dürfen: Klären Sie das früh. Erfahrungsgemäß dauert so eine Freigabe länger als das Seminar. Der erste Punkt ist der ernsteste, auch wenn er wie eine Floskel klingt. Zuschauen fühlt sich beim Lernen gut an, weil alles einleuchtet. Beim eigenen Tippen merkt man dann, dass man an einer Stelle etwas anderes verstanden hat als gemeint. Genau diese Reibung ist der Lerneffekt.

6:16 Der zweite Punkt ist erfahrungsgemäß der teuerste: Wer Docker erst installiert, wenn es gebraucht wird, verliert Zeit an einer Stelle, an der es inhaltlich gerade spannend wird. Und der dritte: Wenn Ihnen der Begriff Bean unscharf ist, holen Sie das jetzt nach. Sonst wirkt später vieles wie Magie, was schlicht Spring ist.

Ein Projekt mit dem Spring Initializr

6:35 Jetzt wird es praktisch. Wir legen das Projekt an, bauen es und lassen es laufen. Achten Sie dabei weniger auf die Klickfolge als auf das, was am Ende in der Projektdatei steht — das ist die eigentliche Erkenntnis dieses Kapitels. Der Initializr ist im Grunde ein Konfigurator, so wie Sie ihn vom Autokauf kennen: Sie wählen Ausstattung, und am Ende kommt ein fertig zusammengestelltes Paket heraus.

6:59 Sie legen Aufbauwerkzeug, Sprache, Version und die Maven-Koordinaten fest, haken ein paar Abhängigkeiten an und laden ein Archiv herunter. Und jetzt kommt der Punkt, auf den es ankommt: Was der Initializr dabei tut, ist völlig unspektakulär. Er trägt die passenden Starter in die Projektdatei ein. Mehr nicht. Das ist wichtig zu wissen, weil es den Initializr entzaubert — Sie könnten dasselbe von Hand tun, es wäre nur mühsamer.

7:25 Der rote Faden dieser Schritte ist: möglichst wenig entscheiden. Wir nehmen Maven und Java, tragen unsere eigenen Koordinaten ein — Gruppe de.radwerk, Artefakt werkstatt — und wählen als Verpackung ein Jar. Bei den Abhängigkeiten bleiben wir bewusst bei einer einzigen, nämlich Spring Web. Das ist das Minimum für REST-Dienste, und es reicht, um zu sehen, wie viel daraus schon entsteht.

7:49 Ein Wort zur Version: Nehmen Sie die aktuelle stabile. Es gibt auch Vorabversionen, und die sind zum Ausprobieren interessant — aber nichts, worauf man eine Anwendung baut, die in Produktion gehen soll. Zwei Dinge sind hier bemerkenswert. Erstens der Maven-Wrapper: Das Skript liegt im Projekt, lädt sich Maven selbst herunter und macht damit eine globale Installation überflüssig.

8:12 Jeder, der das Projekt auscheckt, baut mit derselben Maven-Version — ein unterschätzter Vorteil. Zweitens das Ergebnis: eine einzelne Jar-Datei, die Sie mit java und der Option jar starten. Kein Anwendungsserver, kein Verzeichnis mit Bibliotheken daneben. Beim ersten Lauf lädt Maven allerdings sehr viel herunter. Das sieht beunruhigend aus, ist aber einmalig — beim nächsten Bau liegt alles im lokalen Verzeichnis.

8:38 Bei dieser Aufgabe geht es weniger ums Tippen als ums Lesen. Starten Sie die Anwendung und schauen Sie sich an, was beim Hochfahren im Protokoll erscheint. Es sind nur wenige Zeilen, und die meisten überfliegt man normalerweise. Genau das sollen Sie diesmal nicht tun. Suchen Sie die Zeile, die belegt, dass ein Tomcat gestartet wurde und auf welchem Port er lauscht.

8:59 Diese Zeile ist Ihr Beweis dafür, dass die Autokonfiguration gearbeitet hat — und Sie haben dafür keine einzige Konfigurationsdatei angefasst. Wer schneller fertig ist, baut dasselbe Projekt als War und vergleicht das Ergebnis. Der erste Punkt begegnet einem oft bei erfahrenen Java-Leuten: Man hat Maven ohnehin installiert und ignoriert den Wrapper.

9:20 Das geht meistens gut und genau deshalb fällt es nicht auf, wenn die Versionen auseinanderlaufen. Der zweite Punkt ist eine reine Nervensache — der erste Bau lädt so viel herunter, dass man einen Fehler vermutet und abbricht. Lassen Sie ihn durchlaufen. Der dritte hat es in sich: War zu wählen fühlt sich vertraut an, wenn man aus der Java-EE-Welt kommt.

9:40 Nur braucht ein War einen Servlet-Container, der es entgegennimmt — und den betreibt heute kaum noch jemand.

Das Deployment-Modell

9:47 Jetzt kommt der Teil, bei dem erfahrene Java-Entwickler am häufigsten kurz innehalten. Es geht um eine Umkehrung, die so grundlegend ist, dass sie beim ersten Hören fast wie ein Trick klingt — und die erklärt, warum Spring Boot so gut in die Cloud passt. Klassisch war es so: Der Server stand, und Sie lieferten Ihre Anwendung dorthin.

10:06 Ein Servlet-Container oder ein großer Anwendungsserver lief im Rechenzentrum, und Sie gaben ein War- oder Ear-Archiv ab, das dort eingespielt wurde. Die Anwendung war Gast, der Server war Gastgeber. Spring Boot dreht dieses Verhältnis um. Die Anwendung wird zu einem eigenständigen Jar, und der Tomcat läuft darin mit — als Bibliothek, die beim Start hochgefahren wird. Aus dem Gast wird der Gastgeber.

10:29 Diese Umkehrung klingt nach einem technischen Detail, hat aber weitreichende Folgen für den Betrieb. Wenn Sie diese Tabelle von oben nach unten lesen, sehen Sie eigentlich zwei verschiedene Betriebsmodelle. Links steht ein Modell aus einer Zeit, in der Rechenleistung teuer und Server groß waren: Man stellte eine mächtige Maschine hin und ließ viele Anwendungen darauf laufen.

10:52 Die Konfiguration lag beim Betrieb, im Voraus, für alle gemeinsam. Rechts steht das Gegenteil: viele kleine Einheiten, jede für sich, jede bringt mit, was sie braucht. Interessant ist die vorletzte Zeile — eine Anwendung je Container. Das wirkt verschwenderisch, ist aber der Grund, warum sich einzelne Teile unabhängig skalieren und ersetzen lassen.

11:13 Ein Container soll klein sein und schnell starten, weil er im Zweifel hundertmal am Tag neu entsteht. Das verträgt sich nicht mit einem Anwendungsserver, der Minuten zum Hochfahren braucht und mehrere Anwendungen verwaltet. Das eigenständige Jar dagegen passt genau: Alles Nötige ist darin, es startet in Sekunden, und es macht genau eine Sache. Beachten Sie den letzten Punkt auf der Folie besonders.

11:36 Dass kein vorinstallierter Anwendungsserver mehr gebraucht wird, ist keine Kleinigkeit — es bedeutet, dass Entwicklung und Betrieb dieselbe Artefaktform sehen. Was auf Ihrem Rechner läuft, läuft auch im Rechenzentrum. Alle drei Punkte sind Gewohnheitsfehler, und Gewohnheiten sind zäh. Ein War zu bauen, weil man das immer so gemacht hat, funktioniert technisch weiterhin — nur nimmt es niemand mehr entgegen.

11:59 Den eingebetteten Tomcat für eine Notlösung zu halten, ist ein Denkfehler aus derselben Ecke: Er ist nicht der kleine Bruder des richtigen Servers, er ist der Regelfall. Und der dritte Punkt kommt oft aus Vorsicht: Man legt Bibliotheken neben das Jar, weil man sichergehen will. Sie stecken bereits darin, und im schlimmsten Fall haben Sie damit zwei Versionen derselben Bibliothek im Spiel.

Das Projekt von innen

12:22 Wir haben eine laufende Anwendung, aber noch nicht hineingesehen. Das holen wir jetzt nach — und zwar in der Projektdatei. Sie ist überraschend kurz, und genau diese Kürze ist die eigentliche Aussage dieses Kapitels. Von außen ist Radwerk ein ganz gewöhnliches Maven-Projekt: eine pom.xml, ein Verzeichnis für den Quellcode, eines für die Tests.

12:44 Nichts Exotisches, jedes Java-Werkzeug versteht diese Struktur. Bemerkenswert ist erst der Blick in die pom.xml selbst. Dort stehen ein Eltern-Projekt, zwei Abhängigkeiten und ein Plugin — das war es. Wer aus Projekten kommt, in denen die Projektdatei mehrere hundert Zeilen umfasst, sollte an dieser Stelle kurz stutzen. Der Rest ist nicht verschwunden, er ist nur woandershin verlagert. Wohin genau, sehen wir gleich.

13:11 Auf das Einzige, worauf es hier ankommt, deutet die Fußzeile: Bei der Abhängigkeit steht keine Versionsnummer. Das ist kein Versehen und auch keine Nachlässigkeit. Das Eltern-Projekt legt für jede verwaltete Bibliothek fest, welche Version zum Einsatz kommt — und zwar eine, die mit allen anderen zusammen getestet wurde.

13:30 Sie erben damit eine aufeinander abgestimmte Menge von Bibliotheken. Wer schon einmal einen halben Tag damit verbracht hat, herauszufinden, welche Kombination zweier Bibliotheksversionen sich verträgt, weiß, was das wert ist. Diese Arbeit hat jemand anderes gemacht und dokumentiert sie mit jedem Spring-Boot-Release neu. Damit sind wir beim ersten der beiden Schlüsselbegriffe dieses Moduls.

13:53 Ein Starter ist im Grunde ein Bündel: eine Abhängigkeit, die alles mitbringt, was nötig ist, um eine bestimmte Fähigkeit einzuschalten. Denken Sie an ein Menü statt an eine Zutatenliste. Sie bestellen nicht Mehl, Hefe und Ofen, sondern Sie bestellen eine Webanwendung. Der Webmvc-Starter holt entsprechend Tomcat ins Projekt und macht daraus eine Webanwendung, der zugehörige Test-Starter bringt die Werkzeuge für Modul- und Integrationstests mit.

14:19 Zwei Zeilen in der Projektdatei, und damit ist der technische Unterbau vollständig beschrieben. Diese vier Punkte teilen sich sauber auf zwei Verantwortliche auf. Die ersten beiden gehen aufs Konto des Eltern-Projekts: abgestimmte Versionen und vorkonfigurierte Plugins. Die dritten und vierten gehören zu den Startern und zum Spring-Boot-Plugin.

14:39 Interessant ist der letzte Punkt, weil er leicht übersehen wird: Das Plugin ist nicht schmückendes Beiwerk, sondern es baut das ausführbare Jar überhaupt erst — jenes Archiv, das alle Abhängigkeiten enthält und mit java und der Option jar startet. Ohne das Plugin bekommen Sie ein gewöhnliches Jar, das genau so lange läuft, bis es die erste fremde Klasse braucht.

15:00 Der erste Punkt passiert fast immer aus gutem Willen: Man trägt eine Versionsnummer ein, weil man genau wissen will, was verwendet wird. Damit hebelt man aber die Abstimmung aus, die das Eltern-Projekt leistet, und handelt sich möglicherweise genau die Konflikte ein, die man vermeiden wollte. Der zweite Punkt ist verwandt — man ergänzt eine Bibliothek, die ein Starter längst mitbringt, und hat sie nun zweimal im Spiel.

15:23 Und der dritte trifft die, die das Projekt umbauen: Wer das Spring-Boot-Plugin für optional hält und entfernt, merkt es erst, wenn das gebaute Jar nicht mehr startet.

Die Hauptklasse und ihre Annotationen

15:33 Vom Bauwerkzeug zum Code. Wir schauen uns die Klasse an, die der Initializr erzeugt hat. Sie ist ausgesprochen kurz — und trotzdem stecken drei verschiedene Mechanismen darin, die zusammen den Start der Anwendung ausmachen. Die erzeugte Startklasse enttäuscht auf den ersten Blick. Eine main-Methode, eine einzige Zeile darin, die die Kontrolle an Spring Boot übergibt. Nichts zu erklären.

15:57 Interessant wird es eine Zeile darüber, bei der Annotation. Sie heißt SpringBootApplication und ist selbst mit drei weiteren Annotationen versehen. Java kennt dafür den Mechanismus der Meta-Annotation: Was an einer Annotation steht, wirkt auf die Klasse, als stünde es direkt dort. Eine Zeile im Code, drei aktive Mechanismen dahinter. Das ist praktisch, verschleiert aber, was tatsächlich passiert — und deshalb schauen wir gleich genauer hin.

16:24 Was Sie hier sehen, ist praktisch das gesamte handgeschriebene Startprogramm von Radwerk. Der Aufruf übergibt lediglich die Klasse selbst und die Kommandozeilenargumente. Warum die Klasse selbst? Weil sie Spring Boot als Ausgangspunkt dient — von ihrem Paket aus wird nach Komponenten gesucht. Das ist ein Detail mit Folgen, auf das wir gleich bei den Stolpersteinen zurückkommen.

16:46 Und die Kommandozeilenargumente werden mit übergeben, weil sie zu einer Konfigurationsquelle werden. Das wird in Modul zwei wichtig, wenn wir sehen, dass Argumente jede andere Einstellung übersteuern können. Diese drei Zeilen kann man gut als Ablauf lesen. Die erste erlaubt der Klasse, selbst Beans zu definieren — sie ist die unauffälligste der drei.

17:07 Die zweite ist die folgenreichste im Alltag: Die Komponentensuche durchforstet das Paket der Startklasse und alles darunter nach annotierten Klassen und registriert, was sie findet. Deshalb ist die Lage dieser Klasse im Paketbaum keine Geschmacksfrage. Die dritte schließlich startet die Autokonfiguration, also das Thema des nächsten Kapitels.

17:27 Merken Sie sich vor allem eines: Diese Annotation ist kein Etikett, das sagt „hier beginnt die Anwendung". Sie schaltet drei Maschinen an. Die ersten beiden Punkte sind zwei Gesichter desselben Problems, und es ist der häufigste Anfängerfehler mit Spring überhaupt. Die Komponentensuche beginnt beim Paket der Startklasse. Verschiebt man diese Klasse in ein Unterpaket oder legt Beans außerhalb des Baums ab, werden sie schlicht nicht gefunden.

17:53 Die Anwendung startet, aber eine Abhängigkeit fehlt — und die Fehlermeldung nennt selten die eigentliche Ursache. Der dritte Punkt ist eher eine Haltungsfrage: Wer die Annotation für einen Marker hält, wundert sich über Verhalten, das er nirgends angefordert zu haben glaubt.

Autokonfiguration

18:08 Jetzt zum zweiten Schlüsselbegriff. Autokonfiguration ist der Mechanismus, dem Spring Boot seinen Ruf verdankt — im Guten wie im Schlechten. Für die einen ist es der Grund, warum es so schnell geht. Für die anderen ist es die Stelle, an der sie nicht mehr wissen, was passiert. Der Mechanismus ist im Kern einfach: Beim Start schaut Spring Boot nach, was an Startern im Projekt liegt, und richtet daraufhin die passenden Komponenten ein.

18:34 Liegt der Webmvc-Starter vor, wird ein Tomcat konfiguriert und hochgefahren. Kommt später der Datenbank-Starter dazu, entstehen Datenquelle und Transaktionsverwaltung — Sie geben nur noch wenige Einstellungen dazu. Man kann sich das wie ein Auto vorstellen, das erkennt, welche Anhängerkupplung montiert ist, und die passende Elektrik gleich mitkonfiguriert.

18:55 Die Entscheidung, was montiert ist, bleibt bei Ihnen. Alles Weitere leitet sich daraus ab. Der Begriff meinungsstark, im Englischen opinionated, wird oft wie ein Vorwurf verwendet. Er beschreibt aber nur einen Unterschied. Das Spring Framework bietet Ihnen Tomcat, Jetty und andere an und überlässt Ihnen die Wahl. Spring Boot trifft sie — Tomcat als Servlet-Container, Jackson für JSON.

19:19 Entscheidend ist der dritte Punkt auf der Folie: Diese Vorgaben gelten nur, solange Sie nichts anderes sagen. Es ist keine Bevormundung, sondern ein Standardwert. Und der vierte Punkt zeigt, wie leicht das Abweichen ist: Sie tauschen Abhängigkeiten aus, Sie schreiben keinen Code. Das ist ein wichtiger Unterschied. Was hier passiert, lässt sich in einem Satz sagen: Wir nehmen den Tomcat-Starter aus dem Webmvc-Starter heraus und legen stattdessen den Jetty-Starter dazu. Das war es.

19:48 Es gibt keine Konfigurationsklasse, keinen Schalter, keine Zeile Java. Beim nächsten Start sieht die Autokonfiguration einen anderen Servlet-Container im Projekt und richtet eben diesen ein. Genau das ist mit dem vorhin genannten aus dem Weg gehen gemeint: Der Mechanismus besteht nicht darauf, recht zu haben. Er reagiert auf das, was da ist.

20:08 Wenn Sie eine Vorgabe ändern wollen, ändern Sie also die Voraussetzungen, nicht das Ergebnis. Diese Aufgabe ist bewusst klein und trotzdem lehrreich. Tauschen Sie Tomcat gegen Jetty und starten Sie neu. Der Beweis liegt wieder im Protokoll — suchen Sie die Zeile, die den Wechsel belegt. Der Erkenntniswert liegt weniger im Ergebnis als im Aufwand: Sie werden feststellen, dass Sie für einen Austausch des Servlet-Containers keine einzige Zeile Programmcode angefasst haben.

20:36 Nehmen Sie die Änderung anschließend bitte wieder zurück. Alle weiteren Module setzen auf dem Tomcat-Stand auf, und ich möchte nicht, dass Sie morgen eine Abweichung suchen, die von hier stammt. Der erste Punkt ist der klassische Kampf gegen das Framework: Man versucht, eine Vorgabe durch Konfiguration zu übersteuern, statt den Starter zu tauschen.

20:56 Das gelingt manchmal, führt aber zu Konstruktionen, die niemand mehr versteht. Der zweite ist ein handfester Fehler — zwei Servlet-Container im Projekt, und die Anwendung startet gar nicht mehr; passiert leicht, wenn man beim Ausschluss ungenau war. Der dritte ist der wichtigste: Autokonfiguration wirkt undurchschaubar, solange man die Startmeldungen ignoriert. Dort steht ausführlich, was eingerichtet wurde.

21:19 In Modul sechs lernen wir zusätzlich einen Endpunkt kennen, der die Entscheidungen offenlegt.

Was Sie aus Modul 1 mitnehmen

21:25 Vier Sätze sollten hängen bleiben. Spring Boot ist ein Aufsatz, kein Ersatz — die Konzepte des Spring Framework gelten unverändert weiter. Starter bündeln Abhängigkeiten, die Autokonfiguration richtet daraus die Komponenten ein; das sind zwei Schritte, keiner. Die Anwendung ist ein eigenständiges Jar mit eingebettetem Tomcat, und diese Umkehrung ist der Grund für die gute Passung zur Cloud. Und Radwerk läuft, ist aber noch leer.

21:51 Im nächsten Modul geben wir ihm etwas, das jede ernsthafte Anwendung braucht: eine Konfiguration, die sich ändern lässt, ohne neu zu bauen.