Was ist neu in Spring Boot 2?

Was ist neu in Spring Boot 2?

1. Überblick

Spring Boot bietet einen fundierten Ansatz für das Spring-Ökosystem. Erstveröffentlichung Mitte 2014. Spring Boot wurde viel weiterentwickelt und verbessert. Seine Version 2.0 wird heute für die Veröffentlichung Anfang 2018 fertig.

Es gibt verschiedene Bereiche, in denen diese beliebte Bibliothek versucht, uns zu helfen:

  • Abhängigkeitsmanagement. Durch Starter und verschiedene Paketmanager-Integrationen

  • Autokonfiguration. Wenn Sie versuchen, den Konfigurationsaufwand für eine Spring-App zu minimieren, müssen Sie bereit sein und die Konvention der Konfiguration vorziehen

  • Produktionsbereite Funktionen. WieActuator, bessere Protokollierung, Überwachung, Metriken oder verschiedene PAAS-Integrationen

  • Verbesserte Entwicklungserfahrung. Mit mehreren Testprogrammen oder einer besseren Rückkopplungsschleife mitspring-boot-devtools

In diesem Artikel werden einige Änderungen und Funktionen erläutert, die für Spring Boot 2.0 geplant sind. Wir werden auch beschreiben, wie diese Änderungen uns helfen können, produktiver zu werden.

2. Abhängigkeiten

2.1. Java Baseline

Spring Boot 2.x will no longer support Java 7 and below, wobei Java 8 die Mindestanforderung ist.

Es ist auch die erste Version, die Java 9 unterstützt. Es ist nicht geplant, Java 9 in der 1.x-Verzweigung zu unterstützen. Dies bedeutetif you want to use the latest Java release and take advantage of this framework, Spring Boot 2.x is your only option.

2.2. Stückliste

Mit jeder neuen Version von Spring Boot werden Versionen verschiedener Abhängigkeiten des Java-Ökosystems aktualisiert. Dies ist in Bootbill of materials aka BOM definiert.

In 2.x ist dies keine Ausnahme. Es macht keinen Sinn, sie aufzulisten, aber wir können unsspring-boot-dependencies.pom ansehen, um zu sehen, welche Versionen zu einem bestimmten Zeitpunkt verwendet werden.

Einige Highlights zu den Mindestversionen:

  • Die unterstützte Mindestversion von Tomcat ist 8.5

  • Die unterstützte Mindestversion für den Ruhezustand ist 5.2

  • Die unterstützte Mindestversion von Gradle ist 3.4

2.3. Gradle Plugin

Das Gradle-Plugin wurde erheblich verbessert und es wurden einige wichtige Änderungen vorgenommen.

To create fat jars, bootRepackage Gradle’s task gets replaced with bootJar and bootWar, um Gläser bzw. Kriege zu bauen.

Wenn wir unsere Apps mit dem Gradle-Plugin in 1.x ausführen möchten, können wirgradle bootRun.In 2.x bootRun extends Gradle’s JavaExec. ausführen. Dies bedeutet, dass es für uns einfacher ist, sie mit derselben Konfiguration zu konfigurieren, die wir normalerweise verwenden klassischeJavaExecAufgaben.

Manchmal möchten wir Spring Boot BOM nutzen. Manchmal möchten wir jedoch keine vollständige Boot-App erstellen oder neu packen.

In dieser Hinsicht ist es interessant zu wissen, dassSpring Boot 2.x will no longer apply the dependency management plugin by default.

Wenn wir das Spring Boot-Abhängigkeitsmanagement wollen, sollten wir hinzufügen:

apply plugin: 'io.spring.dependency-management'

Dies gibt uns mehr Flexibilität mit weniger Konfiguration im oben genannten Szenario.

3. Autokonfiguration

3.1. Sicherheit

In 2.x wird die Sicherheitskonfiguration drastisch vereinfacht. By default, everything is secured, including static resources and Actuator endpoints.

Sobald der Benutzer die Sicherheit explizit konfiguriert hat, wirken sich die Standardeinstellungen für Spring Boot nicht mehr aus. Der Benutzer kann dann alle Zugriffsregeln an einem einzigen Ort konfigurieren.

Dies verhindert, dass wir mit den Bestellproblemen vonWebSecurityConfigurerAdapterzu kämpfen haben. Diese Probleme traten normalerweise auf, wenn Actuator- und App-Sicherheitsregeln auf benutzerdefinierte Weise konfiguriert wurden.

Schauen wir uns ein einfaches Sicherheits-Snippet an, das Aktor- und Anwendungsregeln kombiniert:

http.authorizeRequests()
  .requestMatchers(EndpointRequest.to("health"))
    .permitAll() // Actuator rules per endpoint
  .requestMatchers(EndpointRequest.toAnyEndpoint())
    .hasRole("admin") // Actuator general rules
  .requestMatchers(PathRequest.toStaticResources().atCommonLocations())
    .permitAll() // Static resource security
  .antMatchers("/**")
    .hasRole("user") // Application security rules
  // ...

3.2. Reaktive Unterstützung

Spring Boot 2 bringt eine Reihe neuer Starter für verschiedene reaktive Module. Einige Beispiele sind WebFlux und die reaktiven Gegenstücke für MongoDB, Cassandra oder Redis.

Es gibt auch Testprogramme für WebFlux. Insbesondere können wir@WebFluxTest. nutzen. Dies verhält sich ähnlich wie die älteren@WebMvcTest, die ursprünglich als Teil der verschiedenen Testsslices in 1.4.0 eingeführt wurden.

4. Produktionsbereite Funktionen

Spring Boot enthält einige nützliche Tools, mit denen wir produktionsbereite Anwendungen erstellen können. Unter anderem können wir den Spring Boot Actuator nutzen.

Actuator enthält verschiedene Tools zur Vereinfachung der Überwachung, Nachverfolgung und allgemeinen Überprüfung der App. Weitere Details zum Stellantrieb finden Sie in unserenprevious article.

With its 2 version actuator has been through major improvements. Diese Iteration konzentriert sich auf die Vereinfachung der Anpassung. Es unterstützt auch andere Webtechnologien, einschließlich des neuen reaktiven Moduls.

4.1. Technischer Support

In Spring Boot 1.x only Spring-MVC was supported for actuator endpoints. In 2.x, however, it became independent and pluggable. Spring Boot bietet jetzt sofort Unterstützung für WebFlux, Jersey und Spring-MVC.

Nach wie vor bleibt JMX eine Option und kann durch Konfiguration aktiviert oder deaktiviert werden.

4.2. Benutzerdefinierte Endpunkte erstellen

Die neue Aktuatorinfrastruktur ist technologieunabhängig. Aus diesem Grund wurde das Entwicklungsmodell von Grund auf neu gestaltet.

Das neue Modell bringt auch mehr Flexibilität und Ausdruckskraft.

Mal sehen, wie man einenFruits-Endpunkt für den Aktuator erstellt:

@Endpoint(id = "fruits")
public class FruitsEndpoint {

    @ReadOperation
    public Map fruits() { ... }

    @WriteOperation
    public void addFruits(@Selector String name, Fruit fruit) { ... }
}

Sobald wirFruitsEndpoint in unserenApplicationContext, registriert haben, kann es mit der von uns gewählten Technologie als Webendpunkt verfügbar gemacht werden. Wir könnten es auch über JMX verfügbar machen, abhängig von unserer Konfiguration.

Das Übersetzen unseres Endpunkts in Web-Endpunkte würde zu folgenden Ergebnissen führen:

  • GET auf/application/fruits, die Früchte zurückgeben

  • POST auf/applications/fruits/{a-fruit} Umgang mit der Frucht, die in die Nutzlast aufgenommen werden soll

Es gibt viele weitere Möglichkeiten. Wir könnten genauere Daten abrufen. Wir könnten auch spezifische Implementierungen pro zugrunde liegender Technologie definieren (z. B. JMX vs. Netz). Für den Zweck des Artikels behalten wir ihn als einfache Einführung bei, ohne auf zu viele Details einzugehen.

4.3. Sicherheit im Stellantrieb

In Spring Boot 1.x definiert Actuator ein eigenes Sicherheitsmodell. Dieses Sicherheitsmodell unterscheidet sich von dem in unserer Anwendung verwendeten.

Dies war die Wurzel vieler Probleme, als Benutzer versuchten, die Sicherheit zu verfeinern.

In 2.x sollte die Sicherheitskonfiguration mit derselben Konfiguration konfiguriert werden, die der Rest der Anwendung verwendet.

Standardmäßig sind die meisten Aktorendpunkte deaktiviert. Dies ist unabhängig davon, ob sich Spring Security im Klassenpfad befindet oder nicht. Außerstatus undinfo, müssen alle anderen Endpunkte vom Benutzer aktiviert werden.

4.4. Andere wichtige Änderungen

  • Die meisten Konfigurationseigenschaften liegen jetzt untermanagement.xxx, z. B.:management.endpoints.jmx

  • Einige Endpunkte haben ein neues Format. e.g.: env, flyway or liquibase

  • Vordefinierte Endpunktpfade sind nicht mehr konfigurierbar

5. Verbesserte Entwicklungserfahrung

5.1. Besseres Feedback

Spring Boot führtedevtools in 1.3 ein.

Es kümmert sich um die Beseitigung typischer Entwicklungsprobleme. Zum Beispiel das Cachen von View-Technologien. Es führt auch automatische Neustarts und Browser-Live-Reloads durch. Außerdem können wir damit Apps remote debuggen.

In 2.x when our application gets restarted by devtools a ‘delta' report will be printed out. In diesem Bericht wird erläutert, was sich geändert hat und welche Auswirkungen dies auf unsere Anwendung haben könnte.

Angenommen, wir definieren eine JDBC-Datenquelle, die die von Spring Boot konfigurierte überschreibt.

Devtools zeigt an, dass die automatisch konfigurierte nicht mehr erstellt wird. Es wird auch auf die Ursache hingewiesen. Eine nachteilige Übereinstimmung in@ConditionalOnMissingBean für Typjavax.sql.DataSource. Devtools druckt diesen Bericht, sobald ein Neustart durchgeführt wird.

5.2. Änderungen brechen

Aufgrund von JDK 9-Problemen wird die Unterstützung für Remote-Debugging über HTTP von devtools eingestellt.

6. Zusammenfassung

In diesem Artikel haben wir einige der Änderungen behandelt, die Spring Boot 2 mit sich bringen wird.

Wir haben Abhängigkeiten besprochen und wie Java 8 die minimal unterstützte Version wird.

Als nächstes sprachen wir über Autokonfiguration. Wir haben uns unter anderem auf die Sicherheit konzentriert. Wir haben auch über den Antrieb und die vielen Verbesserungen gesprochen, die er erhalten hat.

Zuletzt sprachen wir über einige kleinere Änderungen, die in den bereitgestellten Entwicklungstools vorgenommen wurden.