TOC

Quoi de neuf dans Spring Boot 2?

Quoi de neuf dans Spring Boot 2?

1. Vue d'ensemble

Spring Boot apporte une approche éclairée à l'écosystème Spring. D'abord publié à la mi-2014. Spring Boot a connu beaucoup de développement et d'amélioration. Sa version 2.0 est aujourd'hui prête à être publiée début 2018.

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

  • Gestion des dépendances. Via des démarreurs et diverses intégrations de gestionnaires de paquets

  • Autoconfiguration. Essayer de minimiser la quantité de configuration qu'une application Spring nécessite de se préparer et de privilégier la convention par rapport à la configuration

  • Fonctionnalités prêtes à la production. Tels queActuator, meilleure journalisation, surveillance, métriques 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 utilisantspring-boot-devtools

Dans cet article, nous allons explorer 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. Les dépendances

2.1. Ligne de base Java

Spring Boot 2.x will no longer support Java 7 and below, étant Java 8 la configuration minimale requise.

C'est également 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 signifieif you want to use the latest Java release and take advantage of this framework, Spring Boot 2.x is your only option.

2.2. Nomenclature

À chaque nouvelle version de Spring Boot, les versions de diverses dépendances de l'écosystème Java sont mises à niveau. Ceci est défini dans Bootbill of materials aka BOM.

Dans la version 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 minimum prise en charge de Tomcat est 8.5

  • La version minimum prise en charge par Hibernate est 5.2

  • La version minimum 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.

To create fat jars, bootRepackage Gradle’s task gets replaced with bootJar and bootWar pour construire respectivement des bocaux et des guerres.

Si nous voulions exécuter nos applications avec le plugin Gradle, dans 1.x, nous pourrions exécutergradle bootRun.In 2.x bootRun extends Gradle’s JavaExec. 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 tâches classiques deJavaExec.

Parfois, nous souhaitons tirer parti de la nomenclature Spring Boot. 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 queSpring Boot 2.x will no longer apply the dependency management plugin by default.

Si nous voulons une gestion des dépendances avec Spring Boot, nous devrions 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 la version 2.x, la configuration de la sécurité est considérablement simplifiée. By default, everything is secured, including static resources and Actuator endpoints.

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

Cela nous évitera de nous battre avec les problèmes de commande deWebSecurityConfigurerAdapter. Ces problèmes se produisaient généralement lors de la configuration personnalisée des règles de sécurité de l'actionneur et des applications.

Jetons un coup d'œil à un simple extrait de code de sécurité qui combine 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 tirer parti de@WebFluxTest. Cela se comporte de la même manière que les@WebMvcTest plus anciens initialement introduits dans le cadre des divers testsslices dans 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 choses, nous pouvons tirer parti de Spring Boot Actuator.

Actionneur contient divers outils permettant de simplifier la surveillance, le traçage et l'introspection générale des applications. Vous trouverez plus de détails sur l'actionneur dans nosprevious article.

With its 2 version actuator has been through major improvements. Cette itération se concentre sur la simplification de la personnalisation. Il prend également en charge d’autres technologies Web, notamment le nouveau module réactif.

4.1. Support technologique

Le démarrage Spring deIn Spring Boot 1.x only Spring-MVC was supported for actuator endpoints. In 2.x, however, it became independent and pluggable. apporte désormais un support prêt à l'emploi pour WebFlux, Jersey et Spring-MVC.

Comme auparavant, JMX reste une option et peut être activé ou désactivé via la configuration.

4.2. Création de points de terminaison personnalisés

La nouvelle infrastructure d'actionneurs est indépendante de la technologie. Pour cette raison, le modèle de développement a été entièrement repensé.

Le nouveau modèle apporte également plus de flexibilité et d’expressivité.

Voyons comment créer un point de terminaisonFruits pour l'actionneur: 

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

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

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

Une fois que nous enregistronsFruitsEndpoint dans notreApplicationContext,, il peut être exposé en tant que point de terminaison Web en utilisant la technologie choisie. Nous pourrions également l'exposer via JMX en fonction de notre configuration.

En traduisant notre point de terminaison en points de terminaison Web, cela se traduirait par:

  • GET sur/application/fruits renvoyant des fruits

  • POST sur/applications/fruits/{a-fruit} manipulant ce fruit qui devrait être inclus dans la charge utile

Il y a beaucoup plus de possibilités. Nous pourrions récupérer des données plus granulaires. Nous pourrions également définir des implémentations spécifiques par technologie sous-jacente (par exemple, JMX vs. Web). Pour les besoins de l'article, nous le garderons comme une simple introduction sans entrer dans trop de détails.

4.3. Sécurité dans l'actionneur

Au printemps, Boot 1.x Actuator définit son propre modèle de sécurité. Ce modèle de sécurité est différent de celui utilisé par notre application.

C’était la racine de nombreux problèmes lorsque les utilisateurs essayaient d’affiner la sécurité.

Dans 2.x, la configuration de sécurité doit être configurée en utilisant la même configuration que le reste de l'application utilise.

Par défaut, la plupart des points d'extrémité de l'actionneur sont désactivés. Cela est indépendant du fait que Spring Security soit dans le classpath ou non. Au-delà destatus etinfo,, tous les autres points de terminaison doivent être activés par l'utilisateur.

4.4. Autres changements importants

  • La plupart des propriétés de configuration sont maintenant sousmanagement.xxx, par exemple:management.endpoints.jmx

  • Certains terminaux ont un nouveau format. e.g.: env, flyway or liquibase

  • Les chemins de points finaux prédéfinis ne sont plus configurables

5. Expérience de développement améliorée

5.1. Meilleure rétroaction

Spring boot a introduitdevtools dans la version 1.3.

Il s’occupe de résoudre les problèmes de développement typiques. Par exemple, la mise en cache de technologies d'affichage. Il effectue également des redémarrages automatiques et un rechargement en direct du navigateur. En outre, cela nous permet de déboguer des applications à distance.

In 2.x when our application gets restarted by devtools a ‘delta' report will be printed out. Ce rapport indiquera ce qui a changé et l'impact que cela pourrait avoir sur notre application.

Supposons que nous définissions une source de données JDBC remplaçant celle configurée par Spring Boot.

Devtools indiquera que celui configuré automatiquement n'est plus créé. Il indiquera également la cause, une correspondance défavorable en@ConditionalOnMissingBean pour le typejavax.sql.DataSource. Devtools imprimera ce rapport une fois qu'il aura redémarré.

5.2. Changements de rupture

En raison de problèmes liés à JDK 9, devtools supprime la prise en charge du débogage distant via HTTP.

6. Sommaire

Dans cet article, nous avons présenté certaines des modifications apportées par Spring Boot 2.

Nous avons discuté des dépendances et de la façon dont Java 8 devient la version minimale prise en charge.

Ensuite, nous avons parlé de la configuration automatique. Nous nous sommes concentrés sur la sécurité parmi d'autres. Nous avons également parlé d'actionneur et des nombreuses améliorations qu'il a reçues.

Enfin, nous avons parlé de quelques modifications mineures apportées aux outils de développement fournis.

Related