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 Beispiel 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 Streidel, der mit enormer Sorgfalt mein Buch gelesen hat und sich nicht nur die Mühe gemacht hat, mir Seitenzahlen, Kapitel und Screenshots mit Korrekturen zu schicken, sondern auch zu dieser Seite beigetragen hat.

3.1.2, letzter Abschnitt

Hier hat sich ein inhaltlicher Dreher eingeschlichen. 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, richtig 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
  • Richtig lautet es "* @PostFilter dient dazu, Collections, die von […]"
  • Richtig lautet es "* @PreFilter Für den seltenen Fall, dass Sie vor dem Aufruf der Methode Dinge filtern wollen."
  • Richtig lautet es JSR-250 statt JSR 250
9.3.9, Seite 188

Tippfehler, richtig lautet es "OAuth bietet einige verschiedene Authentifizierungsabläufe an: authentication flow, authorization code, implicit, resource owner password credentials und client credentials."

9.3.9, Seite 189

Tippfehler in den GAV-Koordinaten, es wurde zweimal die Group-ID angegeben. Tatsächlich hat sich aber im Spring-OAuth-Projekt einiges getan und auch die Version sollte angepasst werden: Während im Beispiel-Projekt meines Buches noch eine Snapshot-Abhängigkeit von spring-security-oauth2-autoconfigure genutzt wurde, so lauten die finalen Koordinaten für aktuelle Spring-Boot-Versionen: org.springframework.security.oauth.boot:spring-security-oauth2-autoconfigure:2.3.4.RELEASE.

9.4, Seite 196

Tippfehler, richtig lautet es "[…] vielleicht lieber ein Logging-Framework schreiben."

10.2.2, Seite 204
  • Richtig lautet es JSR-338 statt JSR 338
  • Tippfehler in der Auflistung der vier Varianten der Datenbankinitialisierungsspezifikationen, statt drop-create lautet es create-drop.
11, Seite 235
  • Richtig lautet es Autor statt Author
  • Richtig lautet es "[…] Reduzierung der Anzahl der Zugriffe […]"
11.2, Seite 237

Richtig lautet es JSR-107 statt JSR 107

12.1.3, Seite 251

Tippfehler, richtig lautet es "Alternativ können Sie auch […]"

13, Seite 254

Tippfehler, das Wort 'aber' war gedoppelt, richtig lautet es: "Wesentliche Konfiguration des Konverters findet aber in den Zeilen […]"

14, Seite 268
  • Tippfehler, richtig lautet es "Anwendungsszenarien in denen es […]"
  • Tippfehler, richtig lautet es "In diesen Fällen […]"
14.2, Seite 273

"Das WebFlux Modul ist sowohl in einem klassischen Servlet-Container als […]"

14.2.3, Seite 283

"[…], welche Request-Methode auf welchem Pfad genutzt wurde […]"

15.1, Seite 297

Tippfehler, "Sprint-Test" statt "Spring-Test".

15.2, Seite 301

Tippfehler, "Packet" statt "Paket"

15.3, Seite 313

"Webanwendungen können damit ebenso getestet wie Datenbanken und anderes mehr." Gemeint ist: "Die Webschicht kann damit ebenso in Isolation getestet werden wie die Serviceschicht oder die Persistenzschicht." In Bezug auf die Schichten einer komplexen Anwendung gesehen ergeben sich Unit-Tests. Technisch sind diese allerdings oftmals dann doch wieder Integrationstests, zum Beispiel gegen Spring-MVC oder halt eine Datenbank. Vergleiche hierzu Domain- und Test-driven Development mit Spring Boot 2.

15.3, Seite 317

Satzzeichen (Punkt) vergessen: "[…] eine Instanz der Klasse SomeService. Das Besondere […]".

15.3, Seite 322

Listing 15.27 ist falsch. Der Inhalt des Service ist für den Text irrelevant, sollte aber dennoch gültiger Code sein: @Service public class SomeService { }

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.

17.6, Seite 360

Tippfehler, zu viele Whitespaces: "[…] unter dem Schlüssel org.springframework.boot.actuate.autoconfigure.ManagementContextConfigurstion aufgelistet werden;[…]"

18.3.1, Seite 376

Tippfehler im Kasten, dort wird dreimal das Projekt helloword_war genannt, u.a. im Verweis auf Github. Gemeint ist aber stets helloworld_war

18.4.1, Seite 385

Tippfehler, es muss "lesend und schreibend" statt "schreiben" lauten.

20.1, Seite 399
  • Statt "[…] stehen allen anfragenden Dateien zur Verfügung." sollte es lauten "[…] stehen allen anfragenden Anwendungen zur Verfügung."
  • Tippfehler, es sollte "dieselben" statt "diesdelben" lauten.
21, Seite 401

Tippfehler im Kasten, statt @ EnableEurekaClient sollte es @EnableEurekaClient lauten.

22.1, Seite 412

Tippfehler im Kasten, statt "Spring Cloud Hystric" sollte es "Spring Cloud Hystrix" lauten.

23, Seite 417

Tippfehler, statt "Der To-do-Service regiert […]" sollte es "Der To-do-Service reagiert […]" lauten.

A.2, Seite 422

Die @Bean-Annotation im Fließtext sollte eigentlich in Monospace formatiert sein.

C.2, Seite 434

Tippfehler, statt "Insbesondere Strukturen, die inhaltlich sowohl zur bestehenden Servlet-API als zum neuen WebFlux-Modul gehören können, […]" sollte es "Insbesondere Strukturen, die inhaltlich sowohl zur bestehenden Servlet-API als auch zum neuen WebFlux-Modul gehören können, […]" lauten.

C.2, Seite 435

Tippfehler, einmal wurde provideragnostisch und kurz darauf provider-agnostisch geschrieben.

C.2, Seite 437
  • Tippfehler, statt "Hikaru" sollt es "Hikari" lauten.
  • Tippfehler, statt "Spring-Securitys-Default" sollte es "Spring-Security-Default" lauten.