Spring Boot 2: quoi de neuf?

De la part d'un traducteur: malgré le fait qu'un an se soit déjà écoulé, les questions sur les nouveautés de 2nd Boot ne s'arrêtent pas là. Écrire un tel contenu à partir de zéro n'est pas l'idée la plus intelligente. Nous avons donc décidé de traduire un article qui nous semble le plus concis et en même temps assez complet.

La sortie de Spring Boot 2 a eu lieu au début de 2018, et tout le monde est impatient de le regarder bientôt en action. Cette publication a été l'aboutissement de 17 mois de travail et de plus de 6 800 engagements de 215 personnes différentes. Il existe de nombreuses fonctionnalités intéressantes à discuter, alors parlons des nouveautés de Spring Boot 2.

Dans cet article, nous considérerons:

• L'histoire de Spring Boot
• Nouveautés de Spring Boot
• Guide de mise à niveau de Spring Boot 2

Histoire de Spring Boot

Avant de me plonger dans les innovations, je voudrais saisir cette opportunité et raconter un peu l'histoire de Spring Boot. Dans un article publié en août 2013, Phil Webb a annoncé la première sortie historique d'un projet appelé Spring Boot sur son blog.

Spring Boot a été créé pour simplifier la création d'applications et de services prêts à l'emploi sur Spring, sans effort excessif. Spring Boot est un regard subjectif sur la plate-forme Spring, qui permet aux débutants et aux utilisateurs expérimentés de Spring de trouver tout ce dont ils ont besoin. À l'aide de Boot, vous pouvez créer des applications autonomes qui s'exécutent en tant que «java-jar» ou sont distribuées dans un format WAR plus traditionnel.

Après environ 9 mois, en avril 2014, Spring Boot 1.0 est sorti. Depuis lors, il y a eu de nombreuses versions mineures et de nouvelles fonctionnalités utiles.

Spring Boot 1.1 (juin 2014)

• test de démarrage à ressort
• Paramètres et paramètres de santé
• Elastic Search, Apache Solr, Spring Social et Spring Auto-configuration
• Prise en charge des modèles (Freemaker, Groovy et Velocity)

Spring Boot 1.2 (mars 2015)

• Servlet 3.1, Tomcat 8 et Jetty 9
• Printemps 4.1
• @SpringBootApplication annotation
• Assistance par e-mail

Spring Boot 1.3 (décembre 2016)

• Mise à niveau de Spring Framework vers la version 4.2
• Mise à niveau de Spring Security vers la version 4.0
• Outils développeur
• Mise en cache de la configuration automatique
• JAR et support de service entièrement exécutables

Spring Boot 1.4 (janvier 2017)

• Printemps 4.3
• Hibernate 5
• Améliorations des tests
• Démarreur d'intégration
• Prise en charge de Couchbase et Neo4J

Spring Boot 1.5 (février 2017)

• Point de terminaison des enregistreurs
• Prise en charge d'Apache Kafka
• Mécanismes avancés pour Cloud Foundry
• Prise en charge LDAP
• Tester les mises à jour

Quoi de neuf au printemps

Alors quoi de neuf dans Spring Boot 2? Si nous parlons de la plus grande innovation, il s'agit d'une mise à jour du Spring Framework vers la 5ème version. Depuis la sortie de Spring Framework 5 en septembre 2017, la plupart des développeurs (comme moi) attendaient la sortie de Spring Boot 2. Spring Framework 5 a une liste considérable de nouvelles fonctionnalités, mais je ne voudrais parler que de quelques-unes des plus importantes.

Nouveautés de Spring Framework 5

Prise en charge de la version Java 8+

Si vous souhaitez continuer à créer des applications sur Spring Framework, vous devez travailler avec Java version 8+. Vous pensiez probablement que c'est un changement très important pour nous tous, mais pour l'équipe Spring, c'est encore plus important. Cela a permis de mettre à jour la base de code source vers Java 8 avec toutes ses nouvelles fonctionnalités comme les expressions lambda ou les flux. Cela rend non seulement le code plus lisible, mais améliore également les performances du noyau de la plate-forme.

Prise en charge de Java 9

Si vous souhaitez utiliser Java 9, vous devez passer à Spring Framework 5 et également à Spring Boot 2. Je sais que beaucoup n'utilisent toujours pas les dernières versions de Java en production, et c'est une excellente occasion d'expérimenter avec de nouveaux "jouets" sympas. Tout devrait fonctionner sans problème lors de l'utilisation du chemin de classe standard, mais j'ai lu quelques difficultés lors du passage aux modules Java 9.

Spring mvc

Bien que Spring MVC ne soit pas au centre de l'histoire dans cet article, il convient de dire qu'il y a eu plusieurs belles mises à niveau. Je ne m'y attarderai pas; pour plus de détails, consultez la documentation de Spring Framework 5 .

Webflux de printemps

Les flux de données asynchrones sont au cœur de l'histoire de Spring Framework 5. Il s'agit d'un type de pensée complètement différent, mais, heureusement pour nous, il n'est pas nécessaire de réapprendre à écrire des applications d'une manière complètement nouvelle. Spring WebFlux est un framework absolument asynchrone et non bloquant, construit à partir de zéro, qui vous permet de gérer un grand nombre de connexions parallèles. Bien qu'il s'agisse d'une révolution dans le paradigme, il ne sera pas si difficile de commencer.

Assistance Kotlin

La prise en charge de Kotlin a été ajoutée dans http://start.spring.io , mais Spring Framework 5 a une prise en charge spécialisée de ce langage qui apporte des fonctionnalités utiles, vous pouvez les lire ici .

Améliorations des tests

Le plus grand changement dans le système de test est la prise en charge complète de JUnit 5 Jupiter. J'en parlerai plus tard, mais lorsque vous lancez une nouvelle application sur Spring Boot 2, vous utilisez toujours JUnit 4 par défaut, cependant, passer à JUnit 5 est une tâche triviale.

Nouveautés de Spring Boot 2

Mises à jour de la bibliothèque tierce

À chaque nouvelle version de Spring Boot, l'équipe Spring est en mesure de mettre à jour diverses dépendances.

• Feuilles de thym 3 *
• Jetée 9.4
• Tomcat 8.5
• Hibernate 5.2
• Voie de migration 5
• Gradle 4

* Le démarreur Thymeleaf a maintenant un thymeleaf-extras-java8time intégré.

Sécurité et données réactives de printemps

Avec le passage à Spring WebFlux, Spring Data a ajouté la prise en charge des applications avec des flux de données asynchrones. Cassandra, MongoDB, Couchbase et Redis prennent actuellement en charge les API asynchrones. Spring Boot a des démarreurs POM pour chacun d'eux, ce qui facilite le démarrage.

Il est également possible d'utiliser Spring Security 5.0 dans nos applications réactives.

Actionneur

Le Spring Boot Actuator n'a rien de nouveau, mais il a été réécrit à partir de zéro. Si vous n'êtes pas déjà familier avec Actuator, voici ce qu'il fait: il affiche automatiquement les points de terminaison pour obtenir des informations sur l'état de l'application. L'actuateur dans Spring Boot 1.x a été écrit au-dessus des servlets, et avec les nouvelles approches réactives, l'équipe Spring avait besoin d'une solution qui prend en charge les approches anciennes et réactives. De plus, les modifications suivantes ont été apportées à l'actionneur:

• Refonte pour prendre en charge les servlets et la réactivité
• Le statut et le bilan de santé détaillé deviennent séparés
• Modèle de sécurité simplifié
• Passer au micromètre (c'est comme SLF4J, uniquement pour les métriques)
• Structure de données JSON améliorée
• Un processus simplifié pour créer des points de terminaison personnalisés.
• Endpoint
• @WebEndpoint
• @JmxEndpoint

Il est probable qu'il puisse y avoir des difficultés de mise à niveau en raison de changements dans le modèle de sécurité, dont nous parlerons plus tard. Par défaut, tous les points de terminaison Web sont accessibles via le chemin /actuator avec une URL de la forme /actuator/{id} . Le chemin / actuator peut être modifié dans les paramètres management.endpoints.web.base-path .

Il existe un bloc de documentation séparé détaillé pour les points de terminaison de l'API Web Spring Boot Actuator , il convient de commencer l'introduction de cet outil.

Plugin Gradle

J'ai toujours beaucoup aimé Gradle, et je suis juste ravi que l'équipe ait décidé de réécrire le plugin pour Gradle.
Le plugin Spring Boot Gradle vous permet d'implémenter la prise en charge de Spring Boot dans Gradle et vous permet de conditionner des archives exécutables ou des archives de guerre, d'exécuter des applications sur Spring Boot et de gérer les dépendances via les dépendances de spring-boot. Le plugin Gradle dans Spring Boot nécessite Gradle version 4.0 et ultérieure.

Pour commencer

Pour commencer à travailler avec le plugin, vous devez le télécharger dans le projet.

 buildscript { repositories { maven { url 'https://repo.spring.io/libs-milestone' } } dependencies { classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.0.0.RC1' } } apply plugin: 'org.springframework.boot' 

Création de fichiers exécutables et d'archives de guerre

La tâche bootRepackage a été remplacée par bootJar et bootWar pour créer des fichiers jar et war, respectivement. Les deux tâches ont plus de fonctionnalités que la commande similaire Gradle standard, donnant accès à tous les paramètres et à la logique.

Gestion des dépendances

Le plugin Spring Boot Gradle ne tire plus automatiquement le plugin de gestion des dépendances. Au lieu de cela, le plug-in Gradle Spring Boot voit que le plug-in de gestion des dépendances est connecté et importe la version correcte de la nomenclature. Cela vous permet de mieux contrôler où et comment la gestion des dépendances est configurée. Pour la plupart des applications, l'ajout d'un plugin de gestion des dépendances suffit:

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

Le plugin Gradle possède sa propre documentation , qui contient des informations très utiles. Je recommande à tous ceux qui souhaitent commencer à travailler avec Gradle de suivre ce lien.

Sécurité simplifiée

L'un des principaux objectifs de Spring Boot 2.x était de simplifier la configuration de sécurité et de faciliter l'ajout de paramètres de sécurité personnalisés. Par défaut, toutes les données sont protégées, y compris les ressources statiques et les points de terminaison de l'actionneur. Si Spring Security se trouve dans le @EnableWebSecurity aux @EnableWebSecurity , Spring Boot ajoutera l'annotation @EnableWebSecurity , et quel mécanisme d'authentification spécifique sera utilisé déterminera le mécanisme de négociation de contenu à partir de Spring Security.

Lorsqu'un utilisateur configure ses règles de sécurité, la configuration de sécurité Spring Boot standard cesse de fonctionner. À ce stade, l'utilisateur devra énoncer toutes les règles de sécurité aussi précisément que possible. Cela signifie que tous les paramètres de sécurité sont collectés en un seul endroit et qu'il n'y a aucun problème avec l'ordre de traitement des commandes avec les WebSecurityConfigurerAdapters existants.

Exemple de paramètres de sécurité individuels:

 http .authorizeRequests() // 1 .requestMatchers(EndpointRequest.to("status", "info")) .permitAll() // 2 .requestMatchers(EndpointRequest.toAnyEndpoint()) .hasRole("ACTUATOR") // 3 .requestMatchers(StaticResourceRequest.toCommonLocations()) .permitAll() // 4 .antMatchers("/**") .hasRole("USER") .and() ... // additional configuration 

1. /status et /info ne nécessitent pas d'autorisation.
2. Tous les autres actionneurs sont protégés à l'aide du rôle ACTUATOR .
3. L'emplacement des ressources statiques partagées est accessible à tous.
4. Tous les autres points de terminaison d'application sont protégés par le rôle USER .

Sécurité de l'actionneur

Étant donné que les points de terminaison de l'actionneur sont fixes, vous devez activer ou exclure les points de terminaison, selon ceux dont vous avez besoin. Voici les paramètres qui contrôlent cela, ils ont changé depuis la version 1.x.

 # ENDPOINTS WEB CONFIGURATION (WebEndpointProperties) management.endpoints.web.exposure.include=info,health # Endpoint IDs that should be included or '*' for all. management.endpoints.web.exposure.exclude= # Endpoint IDs that should be excluded. management.endpoints.web.base-path=/actuator # Base path for Web endpoints. Relative to server.servlet.context path or management.server.servlet.context-path if management.server.port is configured. management.endpoints.web.path-mapping= # Mapping between endpoint IDs and the path that should expose them. 

Si vous ne savez pas comment configurer ces paramètres, mettez en signet la documentation pour les paramètres généraux de l'application .

Prise en charge HTTP / 2

Incroyablement, la sortie de la spécification HTTP 1.1 était déjà en 1996. Je suppose que vous n'avez pas besoin de rappeler qu'un réseau moderne diffère à tous égards. Si vous souhaitez implémenter la prise en charge HTTP / 2 dans une application sur Spring MVC ou WebFlux, utilisez le paramètre suivant.

 server.http2.enabled=true 

La prise en charge HTTP / 2 dépend du serveur Web et de l'environnement d'application sélectionnés, car ce protocole n'est pas pris en charge dans JDK8 prêt à l'emploi. En savoir plus à ce sujet dans la documentation .

Options de configuration

Dans Spring Boot 1.x, la soi-disant liaison détendue était prise en charge, en d'autres termes, vous pouviez déterminer le nom du paramètre de plusieurs façons (cas de chameau, trait de soulignement, trait d'union) et, à la fin, la valeur était affectée à la même propriété.

La liaison détendue fonctionne de la même manière et la façon dont vous lisez les variables dans votre code a changé:

24. Configuration externalisée

Spring Boot vous permet d'externaliser votre configuration afin de pouvoir travailler avec le même code d'application dans différents ... docs.spring.io

Métrique

La métrique Spring Boot personnalisée a été remplacée par Micrometer. Il est développé par l'équipe Pivotal et s'adapte rapidement aux projets Pivotal.

Spring Boot Actuator fournit la configuration automatique de Micrometer , une interface métrique d'application qui prend en charge de nombreux types de surveillance, notamment:

• Atlas
• Datadog
• Ganglia
• Graphite
• Afflux
• Jmx
• Nouvelle relique
• Prométhée
• Signalfx
• Simple (en mémoire)
• Statsd
• Front d'onde

Plus d'informations sur Micrometer sur https://micrometer.io/ .

Une mise à niveau à cause de cela peut être pénible pour ceux qui enregistrent des tonnes de métriques personnalisées.

Planificateur de quartz

Spring Boot 2 prend en charge la bibliothèque d'exécution de tâches planifiées Quartz, qui est facile à ajouter à l'aide du démarreur à quartz spring-boot-starter-quartz. Travail pris en charge sur la RAM et sur JDBC.

 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-quartz</artifactId> </dependency> 

Pool de connexions HikariCP

Le pool de connexions standard est passé de Tomcat à HikariCP. Si vous avez utilisé spring.datasource.type pour que Hikari fonctionne dans votre application Tomcat, vous pouvez le supprimer. De même, si vous souhaitez continuer à utiliser le pool Tomcat, ajoutez simplement ce qui suit à votre configuration:

 spring.datasource.type=org.apache.tomcat.jdbc.pool.DataSource 

Outils pour les développeurs

Par défaut, chaque fois que vous redémarrez l'application, un rapport est écrit sur la différence de configurations. En d'autres termes, le rapport affiche les modifications de la configuration automatique de l'application qui se produisent lorsque vous effectuez des modifications telles que la suppression / l'ajout de beans et la définition des paramètres de configuration.

Pour désactiver l'enregistrement de ce rapport, configurez le paramètre suivant:

 spring.devtools.restart.log-condition-evaluation-delta=false 

Assistance Kotlin

Plus tôt dans cet article, le soutien officiel de Kotlin a été mentionné. Il existe également un bloc de documentation spécialisé pour Kotlin .

Junit 5

Comme mentionné ci-dessus, JUnit 4 est toujours utilisé par défaut dans les applications Spring Boot. Si vous souhaitez mettre à niveau vers JUnit 5, vous devez exclure JUnit 4 de spring-boot-starter-test et ajouter les dépendances nécessaires. Vous aurez également besoin de plugins de la liste ci-dessous.

 <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions> <exclusion> <groupId>junit</groupId> <artifactId>junit</artifactId> </exclusion> </exclusions> </dependency> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-api</artifactId> <scope>test</scope> </dependency> <dependency> <groupId>org.junit.jupiter</groupId> <artifactId>junit-jupiter-engine</artifactId> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <dependencies> <dependency> <groupId>org.junit.platform</groupId> <artifactId>junit-platform-surefire-provider</artifactId> <version>${junit-platform.version}</version> </dependency> </dependencies> </plugin> </plugins> </build> 

Guide de mise à niveau de Spring Boot 2

Je pense que vous ne pouvez pas parler d'un fait aussi évident qu'avec une telle version, le simple changement du numéro de version en production n'est pas le meilleur moyen de mettre à niveau. Tout d'abord, je recommanderais de lire le Guide de migration Spring Boot 2.0 . Personnellement, j'ai trouvé une solution à la plupart de mes problèmes dans un modèle de sécurité simplifié et des changements de paramètres. Ce guide contient d'excellents conseils sur la migration des fichiers de paramètres.

Dans Spring Boot 2.0, de nombreux paramètres de configuration ont été renommés / supprimés et les développeurs doivent mettre à jour application.properties / application.yml pour refléter ces changements. Pour faciliter cette tâche, Spring Boot a fourni un nouveau module spring-boot-properties-migrator . En étant ajouté à votre projet en tant que dépendance, il analysera non seulement l'environnement d'application et affichera les résultats de diagnostic au démarrage, mais migrera également temporairement les paramètres lors de l'exécution. Il s'agit d'une étape nécessaire lors de la migration d'une application:

 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-properties-migrator</artifactId> </dependency> 

Je ne sais pas ce que vous en pensez, mais je vais certainement commencer à jouer avec Spring Boot 2 et travailler à la migration du code vers cette version, mais généralement avec n'importe quelle version majeure, j'attends la sortie de la prochaine version mineure. Cela s'applique non seulement au printemps, mais aussi à d'autres marques d'Apple à Pivotal et même Angry Birds!