Spring Boot

Introduction

Depuis quelques années, de nombreux investissements ont été faits dans Spring Boot pour apporter une grande facilitation vis-à-vis de l’utilisation de l’écosystème basé sur le framework Spring.

Spring boot est principalement une classe SpringApplication qui fournit un moyen pratique d’amorcer une application Spring démarrée à partir d’une méthode main(). Dans de nombreuses situations, nous pouvons déléguer à la méthode statique SpringApplication.run() le soin de démarrer l’application. C’est aussi une mécanique d’auto-configuration en fonction des dépendances qui sont liées à l’application. Cette application peut être standalone, un serveur, un Batch...

Spring Boot est une application générique qui permet de faire facilement des applications standards. Nous pouvons concevoir rapidement des applications web, batch ou microservices, en nous appuyant sur des implémentations par défaut que l’on peut personnaliser. Pour les applications web/web services, Spring permet par exemple de créer des applications autonomes pouvant embarquer un conteneur Tomcat et il est possible de choisir Jetty ou Undertow ou une des autres implémentations disponibles comme substitut pour le conteneur de servlet interne ou de choisir d’utiliser...

Configuration des exemples

Nous allons décrire quelques exemples d’utilisation.

<parent>  
 <groupId>org.springframework.boot</groupId>  
 <artifactId>spring-boot-starter-parent</artifactId>  
 <version>1.5.22.RELEASE</version>  
</parent>  
<dependencies>  
 <dependency>  
 <groupId>org.springframework.boot</groupId>  
 <artifactId>spring-boot-starter-web</artifactId>  
 </dependency>  
</dependencies> 

<parent>  
 <groupId>org.springframework.boot</groupId>  
 <artifactId>spring-boot-starter-parent</artifactId>  
 <version>2.6.6.RELEASE</version>  
</parent>  
<dependencies>  
 <dependency>  
 <groupId>org.springframework.boot</groupId>  
 <artifactId>spring-boot-starter-web</artifactId>  
 </dependency>  
</dependencies>  
[...]  
 
<build>  
  <plugins>  
    <plugin>  
      <groupId>org.springframework.boot</groupId>  
      <artifactId>spring-boot-maven-plugin</artifactId>...

L’auto-configuration Spring Boot

L’annotation @EnableAutoConfiguration est une composition des annotations @Configuration, d’un jeu d’annotations @Conditional qui configure en fonction des annotations @ConditionalOnClass et @ConditionalOnMissing et qui tient compte des classes trouvées dans le classpath.

Le service discovery permet de charger au runtime des implémentations d’un service en utilisant les factories. Ces dernières sont chargées via la classe SpringFactoryLoader qui récupère une liste de factories par le nom ou le type de la classe.

Spring Boot détecte la présence du fichier META-INF/spring.factories qui contient la clé :

org.springframework.boot.autoconfigure.EnableAutoConfiguration=  
fr.eni.spring5.autoconfigure.LibXAutoConfiguration,  
fr.eni.spring5.autoconfigure.LibXWebAutoConfiguration 

Ce fichier a sa correspondance dans Spring qui contient plus d’une centaine de lignes d’auto-configuration : spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/resources/META-INF/spring.factories. La factory a plus de cent lignes qui contiennent les mêmes types de clé que celle mentionnée ci-dessus.

La configuration automatique des Beans Spring

L’auto-configuration de Spring Boot essaie de configurer d’elle-même l’application à partir des dépendances des jars ajoutés....

Les starters

Les starters sont des dépendances qui ajoutent de l’auto-configuration à l’application basée sur Spring Boot. L’utilisation d’un starter permet d’indiquer que l’on veut ajouter une fonctionnalité à l’application et qu’on laisse au framework le soin de compléter notre configuration. Pour choisir la version du conteneur, il suffit de choisir le bon starter.

Voici une liste de starters. Certains starters sont décrits plus en détail dans les sections suivantes. La liste est plutôt longue :

Événements d’applications

Spring notifie, via des événements, certaines choses, comme par exemple le rafraîchissement du contexte via l’événement ContextRefreshedEvent :

@Component  
public class MyListener {  
 @EventListener  
 public void handleContextRefresh(ContextRefreshedEvent event) {  
 ...  
 }  
} 

Ceci permet à la classe MyListener d’être averti lorsque le contexte a été actualisé et on peut l’utiliser pour exécuter du code arbitraire lorsque le contexte de l’application a complètement démarré. Les événements sont importants pour déterminer le readiness (l’application peut recevoir des requêtes) et le liveness (l’application est démarrée).

Une application Spring Boot met à disposition les événements suivants :

La récupération des arguments de la ligne de commande

Il y a deux interfaces Spring Boot permettant d’exécuter du code juste avant que l’application finisse son démarrage via deux interfaces : CommandLineRunner et ApplicationRunner. Ces interfaces sont appelées juste avant la méthode run() une fois que SpringApplication a terminé. Ceci peut aussi faire partie de la phase de configuration de l’application.

@SpringBootApplication  
public class SpringBootWebApplication implements CommandLineRunner { 
 public static void main(String[] args) throws Exception {  
   SpringApplication.run(SpringBootWebApplication.class, args);  
 }  
 @Override  
 public void run(String... args) throws Exception {  
   logger.info("Application Started !!");  
 }  
} 

@Slf4j  
public class SpringBootApplicationRunner...

La configuration des logs

Spring Boot utilise le Commons Logging pour toutes les logs, mais il est possible de changer le comportement par défaut. Les configurations par défaut sont fournies pour Java Util Logging, Log4J2 et Logback. Dans chaque cas, les enregistreurs sont pré-configurés pour utiliser la sortie de la console avec la sortie de fichier facultative.

Par défaut, si vous utilisez les starters, Logback sera utilisé pour les logs. Le routage Logback approprié est également inclus pour garantir que les bibliothèques dépendantes qui utilisent Java Util Logging, Commons Logging, Log4J ou SLF4J fonctionnent correctement.

Nous avons à notre disposition les niveaux de logs classiques FATAL (sauf pour Logback), ERROR, WARN, INFO, DEBUG et TRACE.

logging.pattern.console=%d{dd-MM-yyyy HH:mm:ss.SSS} 
%magenta([%thread]) %highlight(%-5level) %logger.%M - %msg%n 

LOGGER.trace("Test des logs:trace");  
LOGGER.debug("Test des logs:debug");  
LOGGER.info("Test des logs:info");  
LOGGER.warn("Test des logs:warn");  
LOGGER.error("Test des logs:error"); 

02-03-2018 12:42:27.545 [main] TRACE 
fr.eni.spring5.logs.Ex1Logs.run - Test des logs:trace  
02-03-2018 12:42:27.545 [main] DEBUG 
fr.eni.spring5.logs.Ex1Logs.run - Test des logs:debug  
02-03-2018 12:42:27.545 [main] INFO 
fr.eni.spring5.logs.Ex1Logs.run - Test des logs:info  
02-03-2018 12:42:27.545 [main] WARN 
fr.eni.spring5.logs.Ex1Logs.run - Test des logs:warn  
02-03-2018 12:42:27.545 [main] ERROR 
fr.eni.spring5.logs.Ex1Logs.run - Test des logs:error 

La gestion des sessions

Nous essayons d’être stateless car la gestion des sessions complique la mise en cluster des serveurs à cause du partage de session. Nous « émulons » alors la session via un cache partagé.

Dans certains cas, nous n’avons pas le choix, il faut gérer des sessions. Les sessions peuvent alors être gérées dans le projet Spring Session qui a deux versions en parallèle. Ce projet a pour but d’offrir une alternative aux sessions des conteneurs Tomcat, Jetty...

Le module Spring Session gère les sessions.

Il y a des différences entre les deux implémentations.

Dans ce tableau, Spring 4 et 5 correspondent aux versions 1.5 et 2.6 de Spring Boot.

HttpSession (Spring) : remplace le HttpSession dans un conteneur (Tomcat) de façon neutre en ajoutant les fonctionnalités suivantes :

WebSocket : permet de garder la session HttpSession vivante quand nous recevons des messages WebSocket.

WebSession : permet le remplacement des WebSession d’une application conteneurisée Spring...

Le guide de migration de la version 1.5 à la version 2.x

Au niveau de la migration de Spring Boot 1.5 vers la version 2.x, la documentation Spring liste un certain nombre de points.

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

Description avancée de Spring Boot

Ce paragraphe décrit le lancement d’un programme Spring Boot. Il permet de démystifier une fois de plus la « magie » apparente du système qui est en fait le résultat d’un travail intéressant et consciencieux. Spring utilise pour son compte les mécanismes de Spring Boot qu’il met à notre disposition.

Les sources de Spring Boot sont visibles ici : https://github.com/spring-projects/spring-boot. Nous pouvons étudier le comportement de Spring Boot au démarrage à partir des sources. Une application Spring Boot se caractérise par deux éléments : l’annotation @SpringBootConfiguration et la méthode statique RUN au sein d’un programme Java standard :

@SpringBootApplication  
public class Application {  
public static void main(String[] args) {  
 SpringApplication.run(Application.class, args);  
 }  
} 

L’annotation @SpringBootApplication est une composition des annotations @SpringBootConfiguration, @EnableAutoConfiguration et @ComponentScan avec leurs attributs par défaut.

Comme nous l’avons vu, l’annotation @SpringBootConfiguration est un alias vers l’annotation @Configuration et l’annotation @EnableAutoConfiguration indique que nous avons de la configuration embarquée...

Mise en place des listeners

Spring Boot utilise l’interface SpringApplicationRunListener qui a pour implémentation EventPublishingRunListener.

C’est ce listener qui va envoyer les événements durant la phase d’initialisation :

Nous avons déjà présenté certains de ces événements.

class MonListener implements ApplicationListener<ApplicationStartingEvent> { 
 void onApplicationEvent(ApplicationStartingEvent event {...}  
} 

L’EnableAutoConfigurtation

L’annotation EnableAutoConfigurtation est de type Import.

@Target(ElementType.TYPE) 
@Retention(RetentionPolicy.RUNTIME) 
@Documented 
@Inherited 
@AutoConfigurationPackage  
@Import(AutoConfigurationImportSelector.class) 
public @interface EnableAutoConfiguration { 
 
        /** 
        * Environment property that can be used to override 
when auto-configuration is 
        * enabled. 
        */ 
        String ENABLED_OVERRIDE_PROPERTY =  
"spring.boot.enableautoconfiguration"; 
 
        /** 
        * Exclude specific auto-configuration classes such that they will never be applied. 
        * @return the classes to exclude 
        */ 
        Class<?>[] exclude() default {}; 
 
        /** 
        * Exclude specific auto-configuration class names such that they will never be 
        * applied. 
        * @return the class names to exclude 
        * @since 1.3.0 
        */ 
        String[] excludeName() default {}; ...