Neuigkeiten, Beispiele und Errata vom deutschsprachigen Spring-Boot-Buch
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.
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 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.
Auf dem Blog des Autors finden sich die "Werkstattberichte" aus der Arbeit an und mit dem Spring-Boot-Buch:
Sie finden alle Beispiele des Buches im GitHub-Repository des Spring-Boot-Buches:
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.
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.
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.
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 mitjava -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.
Mitspring.config.locationkann der Suchpfad geändert und mittelsspring.config.additional-locationkö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 vonspring.config.additional-locationhaben eine niedrigere Priorität, falls Eigenschaften mehrfach definiert sind.
Kasten Beispielprojekt, Thymeleaf wird erst in Kapital 8 behandelt.
Tippfehler, richtig lautet es: "[…] findet dieser Import auch nur bei vollständig erfüllten Bedingungen statt."
Die Annotationen @AutoConfigureBefore und @AutoConfigureAfter setzen Ihre Autokonfiguration in Relation zu anderen und erlauben eine exakte Reihenfolge.
Tippfehler, richtig lautet es "[…] und den Bedürfnissen moderner Anwendungen entspricht."
Grammatikfehler, richtig lautet es "Spring Boot nutzt diesen Mechanismus, […]"
Tippfehler, richtig lautet es "[…] und ein expliziter Dateiname konfiguriert wird."
Es lautet natürlich ResponseBody statt @ResponseBodoy
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.
Grammatikfehler, richtig lautet es "[…] interessante Funktionen zur Verarbeitung statischer Ressourcen […]"
Überflüssiger Whitespace vor @ApplicationScope
Tippfehler, richtig lautet es "[…] eine Kombination davon."
Tippfehler, richtig lautet es "OAuth bietet einige verschiedene Authentifizierungsabläufe an: authentication flow, authorization code, implicit, resource owner password credentials und client credentials."
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.
Tippfehler, richtig lautet es "[…] vielleicht lieber ein Logging-Framework schreiben."
Richtig lautet es JSR-107 statt JSR 107
Tippfehler, richtig lautet es "Alternativ können Sie auch […]"
Tippfehler, das Wort 'aber' war gedoppelt, richtig lautet es: "Wesentliche Konfiguration des Konverters findet aber in den Zeilen […]"
"Das WebFlux Modul ist sowohl in einem klassischen Servlet-Container als […]"
"[…], welche Request-Methode auf welchem Pfad genutzt wurde […]"
Tippfehler, "Sprint-Test" statt "Spring-Test".
Tippfehler, "Packet" statt "Paket"
"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.
Satzzeichen (Punkt) vergessen: "[…] eine Instanz der Klasse SomeService. Das Besondere […]".
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 {
}
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.
Tippfehler, zu viele Whitespaces: "[…] unter dem Schlüssel org.springframework.boot.actuate.autoconfigure.ManagementContextConfigurstion aufgelistet werden;[…]"
Tippfehler im Kasten, dort wird dreimal das Projekt helloword_war genannt, u.a. im Verweis auf Github. Gemeint ist aber stets helloworld_war
Tippfehler, es muss "lesend und schreibend" statt "schreiben" lauten.
Tippfehler im Kasten, statt @ EnableEurekaClient sollte es @EnableEurekaClient lauten.
Tippfehler im Kasten, statt "Spring Cloud Hystric" sollte es "Spring Cloud Hystrix" lauten.
Tippfehler, statt "Der To-do-Service regiert […]" sollte es "Der To-do-Service reagiert […]" lauten.
Die @Bean-Annotation im Fließtext sollte eigentlich in Monospace formatiert sein.
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.
Tippfehler, einmal wurde provideragnostisch und kurz darauf provider-agnostisch geschrieben.
