Quoi de neuf dans Spring Boot 2?

1. Vue d'ensemble

Spring Boot apporte une approche avisée à l'écosystème Spring. Première sortie mi-2014. Spring Boot a subi de nombreux développements et améliorations. Sa version 2.0 s'apprête aujourd'hui à sortir début 2018.

Cette bibliothèque populaire essaie de nous aider dans différents domaines:

  • Gestion des dépendances. Grâce aux démarreurs et à diverses intégrations de gestionnaire de packages
  • Autoconfiguration. Essayer de minimiser la quantité de configuration requise par une application Spring pour être prêt à partir et privilégier la convention par rapport à la configuration
  • Fonctionnalités prêtes pour la production. Tels que l' actionneur , une meilleure journalisation, une surveillance, des mesures ou diverses intégration PAAS
  • Expérience de développement améliorée. Avec plusieurs utilitaires de test ou une meilleure boucle de rétroaction à l'aide de spring-boot-devtools

Dans cet article, nous explorerons quelques modifications et fonctionnalités prévues pour Spring Boot 2.0. Nous décrirons également comment ces changements pourraient nous aider à devenir plus productifs.

2. Dépendances

2.1. Ligne de base Java

Spring Boot 2.x ne prendra plus en charge Java 7 et les versions antérieures , étant Java 8 la configuration minimale requise.

C'est aussi la première version à prendre en charge Java 9. Il n'est pas prévu de prendre en charge Java 9 sur la branche 1.x. Cela signifie que si vous souhaitez utiliser la dernière version de Java et profiter de ce framework, Spring Boot 2.x est votre seule option .

2.2. Nomenclature

Avec chaque nouvelle version de Spring Boot, les versions de diverses dépendances de l'écosystème Java sont mises à niveau. Il est défini dans Boot nomenclature aka nomenclature .

En 2.x, cela ne fait pas exception. Cela n'a aucun sens de les lister, mais nous pouvons jeter un œil à spring-boot-dependencies.pom pour voir quelles versions sont utilisées à un moment donné.

Quelques points forts concernant les versions minimales requises:

  • La version minimale prise en charge par Tomcat est 8.5
  • La version minimale prise en charge d'Hibernate est 5.2
  • La version minimale prise en charge par Gradle est 3.4

2.3. Plugin Gradle

Le plugin Gradle a subi des améliorations majeures et des changements de rupture.

Pour créer de gros jars, la tâche de bootRepackage Gradle est remplacée par bootJar et bootWar pour créer respectivement des jars et des wars.

Si nous voulions exécuter nos applications avec le plugin Gradle, en 1.x, nous pourrions exécuter gradle bootRun. Dans 2.x, bootRun étend JavaExec de Gradle . Cela implique qu'il est plus facile pour nous de le configurer en appliquant la même configuration que nous utiliserions généralement dans les tâches JavaExec classiques .

Parfois, nous voulons profiter de Spring Boot BOM. Mais parfois, nous ne voulons pas créer une application de démarrage complète ou la reconditionner.

À cet égard, il est intéressant de savoir que Spring Boot 2.x n'appliquera plus le plugin de gestion des dépendances par défaut .

Si nous voulons une gestion des dépendances Spring Boot, nous devons ajouter:

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

Cela nous donne une plus grande flexibilité avec moins de configuration dans le scénario mentionné ci-dessus.

3. Autoconfiguration

3.1. Sécurité

Dans 2.x, la configuration de la sécurité est considérablement simplifiée. Par défaut, tout est sécurisé, y compris les ressources statiques et les points de terminaison de l'actionneur.

Une fois que l'utilisateur a configuré explicitement la sécurité, les valeurs par défaut de Spring Boot cesseront d'affecter. L'utilisateur peut alors configurer toutes les règles d'accès en un seul endroit.

Cela nous évitera de lutter contre les problèmes de commande de WebSecurityConfigurerAdapter . Ces problèmes se produisaient généralement lors de la configuration personnalisée des règles de sécurité de l'actionneur et de l'application.

Jetons un coup d'œil à un simple extrait de code de sécurité qui mélange les règles d'actionneur et d'application:

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. Support réactif

Spring Boot 2 apporte un ensemble de nouveaux démarreurs pour différents modules réactifs. Quelques exemples sont WebFlux et les équivalents réactifs pour MongoDB, Cassandra ou Redis.

Il existe également des utilitaires de test pour WebFlux. En particulier, nous pouvons profiter de @WebFluxTest. Cela se comporte de la même manière que l'ancien @WebMvcTest introduit à l'origine dans le cadre des différentes tranches de test de la version 1.4.0.

4. Fonctionnalités prêtes pour la production

Spring Boot apporte des outils utiles pour nous permettre de créer des applications prêtes pour la production. Entre autres, nous pouvons profiter de Spring Boot Actuator.

L'actionneur contient divers outils pour simplifier la surveillance, le traçage et l'introspection générale des applications. Vous trouverez plus de détails sur l'actionneur dans notre article précédent.

Avec sa version 2, l' actionneur a subi des améliorations majeures. Cette itération se concentre sur la simplification de la personnalisation. Il prend également en charge d'autres technologies Web, y compris le nouveau module réactif.

4.1. Support technologique

Dans Spring Boot 1.x, seul Spring-MVC était pris en charge pour les points de terminaison d'actionneur. Dans 2.x, cependant, il est devenu indépendant et enfichable. Spring Boot apporte désormais un support prêt à l'emploi pour WebFlux, Jersey et Spring-MVC.

As before, JMX remains an option and can be enabled or disabled through configuration.

4.2. Creating Custom Endpoints

The new actuator infrastructure is technology-agnostic. Because of this, the development model has been redesigned from scratch.

The new model also brings greater flexibility and expressiveness.

Let's see how to create a Fruits endpoint for actuator:

@Endpoint(id = "fruits") public class FruitsEndpoint { @ReadOperation public Map fruits() { ... } @WriteOperation public void addFruits(@Selector String name, Fruit fruit) { ... } }

Once we register FruitsEndpoint in our ApplicationContext, it can be exposed as a web endpoint using our chosen technology. We could also expose it via JMX depending on our configuration.

Translating our endpoint to web endpoints, this would result in:

  • GET on /application/fruits returning fruits
  • POST on /applications/fruits/{a-fruit} handling that fruit which should be included in the payload

There are many more possibilities. We could retrieve more granular data. Also, we could define specific implementations per underlying technology (e.g., JMX vs. Web). For the purpose of the article, we'll keep it as a simple introduction without getting into too much detail.

4.3. Security in Actuator

In Spring Boot 1.x Actuator defines its own security model. This security model is different from the one used by our application.

This was the root of many pain points when users were trying to refine security.

In 2.x the security configuration should be configured using the same config that the rest of the application uses.

By default, most actuator endpoints are disabled. This is independent of whether Spring Security is in the classpath or not. Beyond status and info, all the other endpoints need to be enabled by the user.

4.4. Other Important Changes

  • Most configuration properties are now under management.xxx e.g.: management.endpoints.jmx
  • Some endpoints have a new format. e.g.: env, flyway or liquibase
  • Predefined endpoint paths are no longer configurable

5. Enhanced Development Experience

5.1. Better Feedback

Spring boot introduced devtools in 1.3.

It takes care of smoothing out typical development issues. For example, caching of view technologies. It also performs automatic restarts and browser live-reloading. Also, it enables us to remote debug apps.

In 2.x when our application gets restarted by devtools a ‘delta' report will be printed out. This report will point out what changed and the impact it might have on our application.

Let's say we define a JDBC Datasource overriding the one configured by Spring Boot.

Devtools will indicate that the one autoconfigured is no longer created. It will also point out the cause, an adverse match in @ConditionalOnMissingBean for type javax.sql.DataSource. Devtools will print this report once it performs a restart.

5.2. Breaking Changes

Due to JDK 9 issues, devtools is dropping support for remote debugging through HTTP.

6. Summary

In this article, we covered some of the changes that Spring Boot 2 will bring.

We discussed dependencies and how Java 8 becomes the minimum supported version.

Next, we talked about autoconfiguration. We focused on security among others. We also talked about actuator and the many improvements it has received.

Lastly, we talked about some minor tweaks that happened in the development tools provided.