Spring Boot

Moderne Softwareentwicklung im Spring Ökosystem.

Spring Boot basiert vollständig auf dem Spring-Framework. Es wurde mit dem Ziel erschaffen, die Entwicklung eigenständig lauffähiger Anwendungen mit dem Spring-Framework drastisch zu erleichtern. Convention over configuration sowie wenige, bekannte Annotationen reichen aus, um Artefakte zu erzeugen, die alle benötigten Abhängigkeiten mitbringen und extern konfigurierbar sind. Die Schwelle, mehr als eines dieser Artefakte zu erzeugen und zu verteilen ist erheblich geringer und Grundlage erfolgreicher Verteilung von Microservices.

Mit sogenannten "Startern" ist es möglich, die Konfiguration des Builds erheblich zu vereinfachen. Durch Deklaration einer einzigen Abhängigkeit wird zum Beispiel die Unterstützung einer Template-Sprache bereitgestellt, inklusive benötigter Abhängigkeiten und Konfiguration.

Spring Boot bietet herausragende Möglichkeiten, die technischen Schichten einer Anwendung, zum Bespiel Persistenz- und Webschicht, getrennt voneinander zu testen und die Ergebnisse dieser Tests anschließend zu Dokumentationszwecken zu nutzen. Ein nicht unerheblicher Gewinn, um sauberen Code zu schreiben.

Darüber hinaus hat sich um Spring Boot, insbesondere durch die Firma Netflix, ein weiteres Ökosystem an Komponenten aufgetan, das insbesondere auf die Entwicklung verteilter, widerstandsfähiger ("resilient") Microservices zielt.

Warum dieses Buch?

Die Referenzdokumentation von Spring Boot ist ebenso wie die des Spring Frameworks selber ausgesprochen gut und es gibt eine Vielzahl Einführungen für unterschiedliche Themen. Warum also noch ein Buch?

Dieses Buch soll interessierte Entwickler aus dem Java EE Bereich ebenso wie Spring Entwickler ansprechen und ihnen ein "Rezept" an die Hand geben, immer wiederkehrende Aufgaben aus dem fachlichen Alltag elegant und ohne Ablenkung mit Spring Boot zu nutzen.

Spring Boot bringt eine Menge automatischer Konfiguration für fast alle Aspekte des Spring Frameworks. Das Buch erklärt diese Magie und hilft dabei, sie für die eigenen Zwecke zu nutzen.

Warum legt das Spring-Boot-Team soviel Wert auf externe Konfiguration? Welchen Vorteil bietet ein Fat-Jar? Wie funktionieren die Spring-Boot-Starter? Auch diese Fragen werden beantwortet.

Das Spring-Boot-Buch bestellen

Das Spring-Boot-Buch ist kurz nach Spring Boot 2 im April 2018 erschienen und greift alle aktuellen Spring Boot 2 Themen auf. Dazu gehören neben dem reaktiven Programmiermodell mit Spring 5 auch die neue Actuator-Infrastruktur, der Support von Micrometer.io und vieles mehr.

Sie können Ihr Exemplar von "Spring Boot 2: Moderne Softwareentwicklung mit Spring 5" entweder mit diesem Amazon-Partnerlink bestellen oder direkt über den dpunkt-Verlag beziehen.

Blog

Auf dem Blog des Autors finden sich die "Werkstattberichte" aus der Arbeit an und mit dem Spring-Boot-Buch:

Spring-Boot-Buch-Blog

Beispiele und Errata

Sie finden alle Beispiele des Buches im GitHub-Repository des Spring-Boot-Buches:

github.com/springbootbuch

Die Beispiele werden von Travis CI kontinuierlich gebaut, so dass sicher gestellt ist, dass Sie mit validem Code arbeiten. Die Beispiele werden im Buch ausführlich besprochen.

Errata

Ganz besonderen Dank geht an Herrn Matthias S., der mit enormer Sorgfalt mein Buch gelesen hat und sich die Mühe gemacht, mir Seitenzahlen, Kapitel und Screenshots mit Korrekturen zu schicken.

3.1.2, letzter Abschnitt

Hier hat sich ein inhaltlicher Dreher eingeschlichhen. Falls fachliche Komponenten wie Services-Klassen und ähnliches frei von Spring-Code bleiben sollen, ist natürlich die Java-basierte Konfiguration sinnvoll. Schnittstellen, wie @Controller und @RestController sind bereits so eng mit Spring-Infrastruktur verzahnt, dass sie getrost per Komponentensuche in den Kontext kommen können. Hier bieten die großen IDEs auch hinreichend gute Unterstützung. Der korrigierte Text lautet:

Von XML-Konfiguration wird mittlerweile abgeraten. Bewährt hat sich eine Mischung aus Java-basierter Konfiguration und Komponentensuche. Die Java-basierte Konfiguration eignet sich dabei hervorragend zur Konfiguration der fachlichen Komponenten einer Anwendung und die Komponentensuche zur Zusammenstellung der nicht fachlichen Beans beziehungsweise von Beans, die bereits sehr stark von Spring-Infrastruktur abhängen. Fachliche Aspekte können somit als POJO implementiert werden und sind frei von Spring-Code.

4.1.1, Seite 68

Der Absatz bzgl. Default-Konfigurationsdateien ist unvollständig. Korrekt lautet er:

Der Basisname application der Konfigurationsdateien kann durch Setzen der Eigenschaft spring.config.name geändert werden. Der Aufruf des helloworld-Projektes mit java -jar target/helloworld.jar --spring.config.name=foobar ändert den Basisnamen der Konfigurationsdateien auf foobar, es wird nun nach foobar.properties, foobar.yml und profilspezifischen Varianten davon gesucht.
Mit spring.config.location kann der Suchpfad geändert und mittels spring.config.additional-location können zusätzliche Orte angegeben werden. Für beide Eigenschaften gilt: Enthalten sie Pfade, so wird innerhalb dieser Pfade nach Konfigurationsdateien entsprechend dem Standardnamen oder dem konfigurierten Namen gesucht, andernfalls nach Dateien wie angegeben. Profilspezifische Varianten werden nicht gesucht (siehe auch Unterabschnitt 4.2.1). Pfade innerhalb von spring.config.additional-location haben eine niedrigere Priorität, falls Eigenschaften mehrfach definiert sind.

5, Seite 96

Kasten Beispielprojekt, Thymeleaf wird erst in Kapital 8 behandelt.

5.2, Seite 99

Tippfehler, richig lautet es: "[…] findet dieser Import auch nur bei vollständig erfüllten Bedingungen statt."

5.2.1, Seite 100

Die Annotationen @AutoConfigureBefore und @AutoConfigureAfter setzen Ihre Autokonfiguration in Relation zu anderen und erlauben eine exakte Reihenfolge.

6, Seite 107

Tippfehler, richtig lautet es "[…] und den Bedürfnissen moderner Anwendungen entspricht."

6.2.1, Seite 111

Grammatikfehler, richtig lautet es "Spring Boot nutzt diesen Mechanismus, […]"

6.2.1, Seite 112

Tippfehler, richtig lautet es "[…] und ein expliziter Dateiname konfiguriert wird."

8.1.2, Seite 132

Es lautet natürlich ResponseBody statt @ResponseBodoy

8.1.2, Seite 134

Der Satz "Sie können, wie in der zweiten index-Methode gezeigt, die Abbildung auch über die unterstützten Inhaltstypen einschränken" bezieht sich auf Listing 8-3 auf der nachfolgenden Seite.

8.1.5, Seite 146

Grammatikfehler, richtig lautet es "[…] interessante Funktionen zur Verarbeitung statischer Ressourcen […]"

8.1.8, Seite 153

Überflüssiger Whitespace vor @ApplicationScope

9, Seite 167

Tippfehler, richtig lautet es "[…] eine Kombination davon."

9.2.4, Seite 173
  • Korrekt lautet es "* @PostFilter dient dazu, Collections, die von […]"
  • Korrekt lautet es "* @PreFilter Für den seltenen Fall, dass Sie vor dem Aufruf der Methode Dinge filtern wollen."
  • Korrekt lautet es JSR-250 statt JSR 250
17.2.2, Seite 347

Die Basis-URL der Endpunkte wird über management.endpoints.web.base-path konfiguriert, die Pfade einzelner Endpunkte über management.endpoints.web.path-mapping.health=healthcheck.<id>, der Kontext-Pfad der Actuator-Endpunkte über management.server.servlet.context-path.