FormationSpringBoot 5 SpringBoot

Orange septembre
2020
de Spring à Spring Boot

le chef d'orchestre Spring Boot
le chef d'orchestre Spring Boot
sommaire
– Spring et son écosystème
– initialisation d'un projet Spring Boot
– projet Spring Boot généré
– tests
– pages statiques
– fichiers .properties/.yml et profils
– gestion des logs
– monitoring
– déploiement avec Spring Boot
de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

Spring et son écosystème

avantages
Spring apporte tout un écosystème d'outils pour faciliter le développement d'applications. Il prend en charge (au moins en partie) certaines
des problématiques les plus couramment rencontrées par les développeurs :
– l'injection de dépendances avec Spring Framework

– l'accès aux données via Spring Data
– l'exposition d'API REST avec Spring Web MVC
– la sécurité avec Spring Security
– l'écriture de batches avec Spring Batch
– ...
Bien évidemment, ces frameworks sont interopérables les uns avec les autres.
Le but recherché est de laisser Spring se charger au maximum des mécanismes techniques du développement qui sont coûteux à mettre en
place (la plomberie). Ainsi, le développeur se concentre sur les règles métier de son application.

inconvénients
Un projet qui se base sur l'écosystème Spring nécessite de :
– connaître le fonctionnement des différents frameworks Spring

– savoir les configurer (XML ou annotations) individuellement
– savoir les intégrer les uns avec les autres (quelles versions sont compatibles...).
Ces configurations peuvent s'avérer :
– volumineuses (surtout en XML)

– éparpillées
– redondantes de projets en projets (gestion des dépendances par exemple).

la solution
Spring Boot est un outil chapeau. Il a pour but de simplifier :
– la configuration : conventions et paramétrages par défaut (dépendances Maven, configuration Spring), qui assurent une bonne
intégration des différents frameworks
– l'exécution : un serveur d'applications (Tomcat, Jetty ou Undertow) est embarqué dans le jar/war exécutable de l'application
– la mise en place de microservices : support de libraires et d'une plateforme de microservices
– le déploiement dans un Cloud : aide à la configuration, outils, clients Cloud. Intégration avec Cloud Foundry
Spring Boot s'adresse à la fois :
– aux développeurs familiers de l'écosystème Spring

– aux débutants en Spring, qui l'appréhenderont avec plus de rapidité et de simplicité.
Spring Boot pousse la logique de simplification et d'intégration entamée par Spring à son maximum.
Note : Spring Boot n'apporte pas de nouvelles solutions aux problématiques déjà prises en charge par les autres frameworks
Spring.

Spring Boot
Spring Boot repose sur 3 composants principaux :
– des Spring Boot Starter : réduction des dépendances dans le fichier de build
- rassemble un groupe de dépendances liées entre elles (domaine commun) en une seule dépendance
- il existe de nombreux starters (web, data-jpa, security, test...)
- le pom.xml devient très compact et simple à lire/modifier
– Spring AutoConfigurator : réduction de la configuration Spring
- autoconfiguration des frameworks sans fichier XML
- réduction des annotations Java à mentionner explicitement
- possibilité de surcharger cette configuration dans un fichier .properties/yml
– Spring Actuator : outils de supervision d'application Spring Boot
- métriques de suivi (logs, liste des beans, thread dump...)
- création de ses propres métriques
- ajout d'endpoints REST

initialisation d'un projet Spring Boot

Plusieurs moyens (au choix) sont à disposition pour générer un squelette de projet Spring Boot. Ils s'appuient tous sur Spring Initializr, via :
– une interface web

– l'IDE Spring Tools ou IntelliJ
– Spring Boot CLI (Command Line Interface)
– cURL
En fonction des choix exprimés par l'utilisateur (Web, JPA, Security, Cloud...), le squelette du projet est créé, notamment en ajoutant les
dépendances Maven nécessaires (les starters).
Note :
– le projet généré n'est pas un projet Maven multi-modules, puisque plutôt orienté microservices
– il n'y a pas de code métier, donc le projet n'est pas testable directement, contrairement aux anciens Orange Maven
Archetypes

Spring Initializr via une interface web
Spring Initializr est une page web permettant de générer un projet Spring Boot sous forme de fichier .zip. Celui-ci peut être importé dans un
IDE une fois dézippé.

Spring Initializr via Spring Tools ou IntelliJ
Spring Tools s'appuie sur l'IDE Eclipse, customisé pour simplifier les développements d'applications Spring.
Il inclut un ensemble de plugins en plus du noyau Eclipse de base :
– analyse des dépendances de beans Spring

– validation de projet Spring
– support des annotations ou de la configuration XML Spring
– éditeurs graphiques pour Spring Batch, Spring Integration
– supervision des beans Spring lors de l'exécution de l'application
– intégration avec les outils Pivotal : Cloud Foundry et tc Server (Tomcat optimisé pour Spring)
– Git
– Maven
– ...

Que ce soit dans Spring Tools ou IntelliJ, un wizard intègre Spring Initializr : File/New/Spring Starter Project

Il faut ensuite remplir les informations (Maven entre autres) demandées :

Enfin, il faut sélectionner les briques Spring dont on a besoin :

Spring Initializr via Spring Boot CLI
Spring Boot CLI est un outil qui permet de lancer des tâches en lignes de commande (pas besoin d'ouvrir un IDE), par exemple :
– spring help <nomCommande> : avoir les détails de la commande souhaitée

– spring init : initialiser un projet à partir de templates Spring Boot (Spring Initializr)
– spring test : compiler et lancer les tests de l'application
– spring jar : générer un jar exécutable à partir des sources du projet
– spring run : exécuter un script Groovy
– ...
Exemple de création d'un nouveau projet Maven :
– dans un répertoire MyProject

– utilisant les starters spring-boot-starter-web et spring-boot-starter-data-jpa
– dont la classe principale s'appelle MyProjectApplication
spring init --name=MyProjectApplication --dependencies=web,data-jpa MyProject

Spring Initializr via cURL
cURL est une librairie open source et un outil en ligne de commandes pour transférer des données suivant de nombreux protocoles (HTTP,
HTTPS, FTP, SMTP, LDAP...).
Les commandes sont de la forme : curl [URL] [options] ou curl [options] [URL]
On peut s'en servir pour accéder à la création d'un projet Spring Initializr, par exemple :
curl https://start.spring.io/starter.zip
-d applicationName=MyProjectApplication
-d dependencies=web,data-jpa
-o MyProject.zip
Pour avoir plus d'informations sur les paramètres et les dépendances possibles :
curl https://start.spring.io -H 'Accept: application/json'

projet Spring Boot généré

structure d'un projet Spring Boot
Le projet généré par Spring Initializr est un projet Maven (ou Gradle) contenant au moins :
– dans src/main/java : la classe principale de l'application

– dans src/main/resources :
- /static pour les fichiers statiques (html, images...)
- /templates pour les templates des moteurs de templating
(FreeMarker, Groovy, Thymeleaf et Mustache)
- application.properties pour le paramétrage (ex : url de la
base de données, messages internationalisés...)
– dans src/test/java : le squelette d'une classe de tests de
l'application
– un fichier .gitignore pour exclure certains fichiers de la gestion
dans Git
– un fichier HELP.md listant des liens utiles
– un script mvnw.cmd pour installer Maven et lancer des goals
en ligne de commande
– le pom.xml Maven avec les dépendances sélectionnées.

configuration Maven sans pom corporate
Le pom.xml de l'application hérite d'un parent (spring-boot-starter-parent) offert par Spring Boot :
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.3.3.RELEASE</version>
<relativePath/> 
</parent>
Ce parent apporte :
– un ensemble de dépendances Spring en tant que <dependencyManagement>

– une homogénéité dans les versions des dépendances Spring (et autres) embarquées
– la prise en compte de l'UTF8
– une configuration standard des plugins
– ...
Rappel : la section <dependencyManagement> du pom.xml déclare des dépendances mais ne les importe pas. Il faut spécifier
celles que l'on veut vraiment utiliser dans la section <dependencies>.

configuration Maven avec pom corporate
Si on doit hériter d'un pom corporate, il n'est plus possible d'hériter du spring-boot-starter-parent (un seul parent possible).
On contourne le problème en ajoutant spring-boot-dependencies en tant que <dependencyManagement>, avec un <scope>import</scope>

et <type>pom</type> :
<dependencyManagement>
<dependencies>
<dependency>

<artifactId>spring-boot-dependencies</artifactId>
<version>2.3.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
Note : concrètement, le spring-boot-starter-parent hérite lui-même de spring-boot-dependencies.

configuration Maven : les dépendances
On trouve ensuite des starters offerts par Spring en tant que dépendances, en fonction des choix faits dans Spring Initializr :
– spring-boot-starter-web : support du développement web (Spring MVC, Tomcat...)

– spring-boot-starter-data-jpa : support de JPA (Spring Data, Spring ORM, Hibernate...)
– spring-boot-starter-test : support des dépendances communes de test (JUnit, Mockito, Hamcrest...)
– spring-boot-starter-security : support de Spring Security
– ...
Note : il n'est pas nécessaire de spécifier la version du starter, elle est paramétrée dans la dépendance spring-boot-
dependencies.

configuration Maven : surcharge de propriétés
Par défaut, beaucoup de propriétés, notamment les versions des librairies, sont positionnées par Spring Boot.
Il est possible d'en changer dans la partie <properties> du pom.xml de l'application, en surchargeant celles déclarées dans le pom.xml de
spring-boot-dependencies :
<properties>
...
<java.version>11</java.version>
<slf4j.version>1.7.29</slf4j.version>
...
</properties>

configuration Maven : jar/war exécutable
Par défaut, un jar exécutable (fat jar) est généré, mais il est possible également d'avoir un war exécutable (fat war) :
– en spécifiant le packaging souhaité dans le pom.xml (classiquement en Maven)

– grâce au plugin spring-boot-maven-plugin
<packaging>jar</packaging> 
...
<build>
<plugins>
<plugin>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
</plugins>
</build>
Note : nous verrons plus loin dans la formation quel packaging privilégier.

code Java
La classe principale de l'application (annotée par @SpringBootApplication) a été générée dans le package de base.
Cette annotation va entre autres scanner le package courant et les sous-packages pour détecter les beans Spring (annotés @Named,
@Component, @Controller, @Service...).
Cette classe principale contient la méthode main() qui sert à exécuter l'application.
Le code métier reste évidemment à la charge du développeur.
package com.orange.todolist;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
@SpringBootApplication
public class ToDoListDemoApplication {
public static void main(String[] args) {

SpringApplication.run(ToDoListDemoApplication.class, args);
}
}

tests

tests
configuration Maven
Avec Spring Initializr, le spring-boot-starter-test est automatiquement ajouté dans le pom.xml :
<dependency>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.junit.vintage</groupId>
<artifactId>junit-vintage-engine</artifactId>
</exclusion>
</exclusions>
</dependency>
Ce starter apporte les dépendances vers (entre autres) :
– JUnit : le standard pour les tests unitaires en Java

– Spring Test et Spring Boot Test : support de test des applications Spring et Spring Boot
– Hamcrest : librairie de comparaisons d'objets (equalTo(), hasItems(), containsString()...)
– Mockito : framework de création de bouchons (mocks)

tests
tests unitaires
On peut créer les classes de tests unitaires, en utilisant JUnit :
@SpringBootTest(webEnvironment=SpringBootTest.WebEnvironment.RANDOM_PORT,
properties="classpath:test.properties")
public class ToDoList_API_Test {
...
@LocalServerPort
private int port;
@BeforeEach
public void setUp() throws Exception {...}
@Test
public void findAllToDoLists_OK() throws Exception {...}
...
}

pages statiques

pages statiques
Pour ajouter des fichiers statiques (pages HTML...) à une application Spring Boot, il faut les placer dans le répertoire
src/main/resources/static (ou src/main/resources/public).
On peut surcharger la page d'erreur par défaut de Spring Boot par des pages customisées. Elles doivent :
– être situées dans src/main/resources/static/error (ou /public/error)

– être nommées :
- soit <codeStatutHTTP>.html (exemple : 404.html)
- soit <classeStatutsHTTP>.html (exemple : 4xx.html)
Pour plus d'informations sur la surcharge de la page d'erreurs, rendez-vous sur la documentation Spring Boot.

fichiers .properties/.yml et profils

Le paramétrage d'une application et des frameworks embarqués par Spring Boot peut se faire grâce à des fichiers .properties et/ou .yml.
Le format .yml ressemble beaucoup à du .json. C'est pratique pour définir des données de configuration hiérarchiques (mais attention au
respect de l'indentation !).
Le fichier principal de configuration application.properties (ou application.yml) peut par exemple définir :
– la gestion des logs (LogBack par défaut, implémentant le standard SLF4J)

– les informations d'accès à une base de données (URL, user, password... )
– les messages fonctionnels (labels, erreurs...)
– ...
Voici une liste non exhaustive des propriétés disponibles.

Ce fichier de configuration peut être divisé en plusieurs fichiers selon la nature des informations contenues, et pour éviter qu'il soit trop
volumineux.
De plus, on peut définir plusieurs profils :
– pour donner des configurations différentes suivant les environnements cibles (développement, test, intégration, production...)
– qui viendront surcharger celles définies dans le fichier par défaut.
Ces fichiers .properties/.yml peuvent être externalisés en dehors du jar/war.

Pour créer des profils, il faut créer un fichier application-<nomProfil>.properties/.yml par profil :
– application-dev.properties ou application-dev.yml
– application-prod.properties ou application-prod.yml
#application-dev.properties
server.port: 4431
#application-prod.properties
server.port: 4432
#application-dev.yml
server:
port: 4431
#application-prod.yml
server:
port: 4432

En format yaml, on peut également tout déclarer dans le fichier principal application.yml, en séparant les profils par --- :
spring:
application:
name: demoservice
server:
port: 8080
---
spring:
profiles: dev
server:
port: 4431
---
spring:
profiles: prod
server:
port: 4432

sélection d'un profil
Pour exécuter une application avec un profil particulier, on a 2 solutions :
– en passant des paramètres au lancement de l'application :
java -jar <projectJarName>.jar -Dspring.profiles.active=<nomProfil>
– en le spécifiant dans le fichier principal de configuration :
#application.properties
spring.profiles.active=prod
Quand un profil est lancé, le fichier correspondant est lu après le fichier principal de configuration application.properties/.yml, ce qui permet
de surcharger ses propriétés.
Note : si vous déployez une application dans Cloud Foundry, le fichier application-cloud.properties/.yml sera chargé par
défaut. Il n'est donc pas nécessaire de spécifier le profil actif.

bonnes pratiques
Voici l'ordre de priorité des fichiers .properties/.yml :
– fichier de profil placé en dehors du jar/war

– fichier de profil placé dans le jar/war
– fichier principal de configuration placé en dehors du jar/war
– fichier principal de configuration placé dans le jar/war
Conseil :
– rassembler les propriétés communes (ou par défaut) à tous les environnements dans un ou plusieurs fichiers
.properties/.yml, à déployer dans le jar/war (messages...)
– externaliser la configuration dépendante de l'environnement cible dans un ou plusieurs fichiers de profils déployés en
dehors du jar/war.

gestion des logs

gestion des logs
paramétrage dans le fichier .properties/.yml
Spring Boot a un paramétrage par défaut de Logback (politique de rolling, pattern...) qu'il est possible de modifier (en partie) directement dans
le fichier application.properties/yml.
#properties
logging.level.root = WARN
logging.level.com.orange.todolist = DEBUG
logging.file = /tmp/todolistApp.log
#yml
logging:
level:
root: WARN
com.orange.todolist: DEBUG
file: /tmp/todolistApp.log
La complétion permet d'aider à l'écriture des clés.
Plus de précisions sur la gestion des logs dans Spring Boot ainsi que des profils.

gestion des logs
paramétrage dans le fichier .xml
Il est bien sûr également possible de modifier le paramétrage par défaut de Logback en utilisant son propre fichier .xml :
– logback-spring.xml (chargé par défaut)

– logback<Xxx>.xml (à préciser avec la clé logging.config).
logging.path = /tmp
logging.config = classpath:logback-custom.xml
<?xml version="1.0" encoding="UTF-8"?>

<configuration>


<property name="LOG_FILE" value="${LOG_PATH}/todolistApp.log" />
<include resource="org/springframework/boot/logging/logback/base.xml"/>
<logger name="com.orange.todolist" level="DEBUG" />

<logger name="org.springframework.boot" level="INFO" />
<logger name="org.hibernate" level="INFO" />
</configuration>

gestion des logs
externalisation et centralisation des logs
Dans le cas d'une application ou de microservices déployés sur PaaS, il faut pouvoir externaliser les logs, afin de :
– collecter les logs écrites sur la sortie standard stdout

– les stocker dans un espace dédié
– les visualiser grâce à une application web appropriée.
Cela permet de :
– consolider les logs des différents microservices d'une même application

– faire du suivi de session, pour voir l'enchainement des appels des microservices pour un même use-case.

gestion des logs
Ce système de gestion centralisée des logs est disponible directement dans les PaaS Cloud Foundry et Kermit.
Il est basé sur la suite opensource ELK :
– Elasticsearch :
- base de données NoSQL
- stockage massif des données, notamment des logs
- moteur de recherche, d'indexation et d'analyse de données
– Logstash :
- pipeline acceptant en entrée des données provenant de différentes sources
- fait des transformations, agrégations... sur ces données
- exporte les données vers d'autres outils, notamment Elasticsearch pour stockage
– Kibana :
- interface web permettant d'explorer les masses de données stockées dans Elasticsearch
- rendus graphiques très variés (nuages de points, courbes, graphes...)
Cloud Foundry utilise un service Logsearch opensource au dessus d'ELK, permettant de manager un environnement ELK dans un contexte
cloud.

gestion des logs
A ces plateformes s'ajoutent côté application :
– Spring Cloud Sleuth :

- implémente une solution de gestion des logs distribuée de façon transparente
- capture les logs sur la sortie standard
- les enrichit, notamment en ajoutant les attributs (et headers HTTP) :
- traceId : identifiant des traces liées à une même requête utilisateur (use-case)
- spanId : identifiant des différents composants/microservices appelés, en gardant le même traceId
- ces identifiants permettront de faire une recherche précise (dans ELK) du parcours d'une requête au travers des
microservices
- les envoyer si nécessaire à un service de stockage externe (par exemple ELK)
– Logstash-Logback-encoder :
- extension de Logback permettant de transformer des logs au format JSON (entre autres)
- permet de configurer la structure des logs.

gestion des logs
L'intégration avec Spring Boot est simple et transparente au niveau du code.
Au niveau du pom.xml, il faut avoir les dépendances suivantes :
<properties>
<logstash-encoder.version>6.4</logstash-encoder.version>
</properties>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency>
<groupId>net.logstash.logback</groupId>
<artifactId>logstash-logback-encoder</artifactId>
<version>${logstash-encoder.version}</version>
</dependency>
</dependencies>

gestion des logs
Il faut également ajouter la dependencyManagement suivante (la même que pour OpenFeign) :
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
Par défaut, Sleuth ne renvoie que 10% des logs vers la plateforme distante. Il est possible de modifier ce pourcentage dans le fichier
application.properties :
# entre 0 et 1
spring.sleuth.sampler.probability = 0.5

gestion des logs
Enfin, il faut utiliser la classe LogstashEncoder pour transformer les logs en JSON, grâce au fichier de configuration logback-spring.xml :
<?xml version="1.0" encoding="UTF-8"?>

<configuration>

<include resource="org/springframework/boot/logging/logback/defaults.xml"/>
<appender name="JSON" class="ch.qos.logback.core.ConsoleAppender">

<encoder class="net.logstash.logback.encoder.LogstashEncoder"></encoder>
</appender>
<root level="INFO">
<appender-ref ref="JSON" />
</root>
</configuration>

monitoring

monitoring
initialisation avec Spring Initializr
Avec Spring Initializr, il faut de sélectionner l'option Actuator dans la section Ops :
Les autres options sont disponibles pour les versions précédentes de Spring Boot. Notamment Actuator Docs qui ajoutait la
documentation d'Actuator directement dans l'application sous forme d'endpoint (URL) prédéfinie.
La génération du projet va ajouter la dépendance Maven en conséquence.

monitoring
configuration Maven
Que ce soit avec Spring Initializr ou à la main, il faut avoir la dépendance vers le spring-boot-starter-actuator :
<dependency>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

monitoring
fonctionnalités apportées
Actuator ajoute des endpoints (URLs) à votre application, afin d'interagir avec elle et la superviser :
– /beans : affiche la liste complète des beans Spring de l'application

– /health : affiche l'état de l'application (opérationnelle ou non, + d'autres informations si vous êtes authentifié : espace disque,
database...)
– /info : affiche des informations à votre convenance (vide par défaut)
– /loggers : affiche et modifie la configuration des logs
– /metrics : affiche la mémoire utilisée/disponible, nb sessions actives, nb classes chargées...
– /mappings : affiche toutes les URLs accessibles (grâce aux annotations @RequestMapping)
– /shutdown : arrêt gracieux de l'application
– /threaddump : effectue un thread dump (liste de tous les threads en cours d'exécution)
– ...
Par défaut, tous ces enpoints sont autorisés (sauf /shutdown) mais pas forcément exposés (donc pas accessibles). On peut changer leur
autorisation individuellement dans le fichier application.properties/yml :
management.endpoint.shutdown.enabled=true
management.endpoint.threaddump.enabled=false

monitoring
Ces endpoints peuvent être exposés (qu'ils soient autorisés ou non) via JMX et/ou HTTP. Il est possible de modifier leur exposition sur l'une
ou l'autre technologie :
# n'exposer que health et info via JMX

management.endpoints.jmx.exposure.include=health,info
# exposer tout sauf threaddump via HTTP
management.endpoints.web.exposure.include=*
management.endpoints.web.exposure.exclude=threaddump
Par défaut, sur HTTP :
– un préfixe (/actuator) est ajouté au endpoint (ex : http://monappli.orange.com/actuator/health)

– seuls /health et /info sont exposés (et autorisés donc accessibles).
Attention : ne pas exposer et autoriser certains endpoints sans les sécuriser, car ils peuvent donner des informations sensibles
sur l'application. Si Spring Security est présent, ils sont sécurisés par défaut (sauf /health et /info) et nécessitent une
authentification. Il est possible de modifier les droits d'accès de chaque endpoint en fonction de rôles.

monitoring
Il est possible de modifier certains paramètres par défaut (ports, URL d'endpoints...) dans le fichier application.properties/yml :
# modifier le port pour l'application (par défaut : 8080)

server.port=9000
# autoriser SSL pour l'application
server.ssl.enabled=true
# modifier le port pour les endpoints de monitoring
management.server.port=9001
# autoriser SSL pour les endpoints de monitoring
management.server.ssl.enabled=true
# modifier le préfixe par défaut (/actuator) : /manage/health, ...
management.endpoints.web.base-path=/manage
Enfin, il est possible de créer ses propres endpoints (exposés via JMX ou HTTP ou les 2).

monitoring
Pour afficher des informations pour le endpoint /info, il suffit d'ajouter ses propres clés (libres) en les préfixant par info. dans le fichier
application.properties/yml :
# informations pour '/info' : info.<nomLibre>: <valeurLibre>

info.applicationName: ToDoList Demo
info.author: Mickael Cormier
D'autres informations sur l'application, issues du fichier pom.xml (name, groupId, artifactId, date du build...), peuvent être ajoutées directement
grâce à la configuration du plugin spring-boot-maven-plugin :
<plugin>
<artifactId>spring-boot-maven-plugin</artifactId>
<executions>
<execution>
<goals>

<goal>build-info</goal>
</goals>
</execution>
</executions>
</plugin>
déploiement avec Spring Boot

fat jar ou fat war ?
Comme nous l'avons déjà évoqué, Spring Boot offre la possibilité de créer un fat jar ou un fat war, comprenant un Tomcat embarqué.
En production, en cas d'utilisation :
– d'un PaaS : l'utilisation du fat jar est conseillée, car on est sûr que le binôme Tomcat/jar est identique d'un bout à l'autre de la chaîne de
production. La supervision est à la charge du PaaS.
– d'une plateforme Platon : il vaut mieux s'appuyer sur un fat war déployé dans un Tomcat Platonisé.
A noter qu'un fat war peut aussi bien être autoexécutable que déployé dans un Tomcat classique. Le Tomcat embarqué est alors ignoré.
Du coup, il convient de distinguer 2 phases :
– en développement : sur le poste du développeur, l'utilisation du Tomcat embarqué est très pratique
– dès l'intégration continue : déployer ce même fat war mais dans un Tomcat externe aussi proche que possible de celui en production.
Ceci afin d'éviter les différences de plateforme entre les tests et la production.

déployer le jar localement en ligne de commande
Il faut d'abord builder l'application avec Maven pour obtenir le jar exécutable (avec un Tomcat embarqué).
Ensuite, il faut lancer la commande :
java -jar <projectJarName>.jar
Pour activer un profil particulier :
java -jar <projectJarName>.jar -Dspring.profiles.active=<nomProfil>

déployer le jar localement en ligne de commande
Au bout de quelques secondes, l'application est déployée et disponible à l'adresse : http://localhost:8080/<contexte>

déployer le jar localement depuis un IDE
Dans Spring Tools : clic droit sur le projet \Run As\Spring Boot App
Dans IntelliJ : clic droit sur le projet \Run SpringBootWebApplication

déployer le jar localement depuis un IDE
Dans Spring Tools (et IntelliJ ?), il existe une vue Spring Boot Dashboard.
Elle permet de :
– lancer/arrêter une application Spring Boot

– connaître le statut des applications déclarées dans le dashboard (URL, port...)
– s'intégrer avec Cloud Foundry...

déployer le war sur un serveur externe
Pour générer et déployer un war dans un conteneur externe (exemple : Tomcat), il est préférable de créer un profil Maven particulier dans le
pom.xml. Par défaut c'est le jar qui est produit, et le war seulement quand le profil est activé :
<profiles>
<profile>
<id>deploy-war</id>
<properties>
<packaging>war</packaging>
</properties>
<dependencies>
<dependency>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
...
</profile>
</profiles>

En plus de cela, il faut que la classe principale de l'application étende la classe SpringBootServletInitializer et surcharge la méthode
configure() :
@SpringBootApplication
public class ToDoListDemoApplication extends SpringBootServletInitializer {
public static void main(String[] args) {

SpringApplication.run(ToDoListDemoApplication.class, args);
}
@Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder builder) {
return builder.sources(ToDoListDemoApplication.class);
}
}
Cela permet de remplacer le traditionnel fichier de configuration web.xml, et possiblement d'ajouter de la configuration (profil par défaut,
arguments de lancement de l'application...).

Le plugin Maven Cargo permet de simplifier le déploiement du war sur la plateforme de votre choix (en local ou à distance) :
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>${cargo.version}</version>

...
</plugin>
Ce plugin serait utile dans le profil deploy-war présenté précédemment par exemple.

documentation
– Site officiel Spring Boot
– Spring Boot Reference Guide
– Documentation sur la configuration Maven de Spring Boot
– Documentation sur Spring Actuator
– Site Spring Initializr
– Site Spring Tools
– Articles sur Spring Boot Dashboard
– GitHub Spring Initializr CLI
– Site Elastic
– Site Logsearch
– Site Spring Cloud Sleuth
– Site Spring Framework GURU : de nombreux tutoriaux
– Site Baeldung : de nombreux tutoriaux
– Tutoriel Spring : beaucoup d'informations sur l'installation et l'utilisation des outils en lien avec Spring (Spring Core, Spring MVC, Spring
Security, Spring Tools, Spring Boot, Spring Boot CLI, cURL...)
– Guide de migration de SpringBoot 1.5 à SpringBoot 2.0

merci

Langue

FormationSpringBoot 5 SpringBoot

Transféré par

Informations du document

Titre original

Copyright

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

FormationSpringBoot 5 SpringBoot

Titre original :

Transféré par

Droits d'auteur :

Orange septembre

de Spring à Spring Boot

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– l'injection de dépendances avec Spring Framework

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– connaître le fonctionnement des différents frameworks Spring

Ces configurations peuvent s'avérer :

– volumineuses (surtout en XML)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

Spring Boot s'adresse à la fois :

– aux développeurs familiers de l'écosystème Spring

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– une interface web

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

Il inclut un ensemble de plugins en plus du noyau Eclipse de base :

– analyse des dépendances de beans Spring

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– spring help <nomCommande> : avoir les détails de la commande souhaitée

Exemple de création d'un nouveau projet Maven :

– dans un répertoire MyProject

spring init --name=MyProjectApplication --dependencies=web,data-jpa MyProject

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

curl https://start.spring.io -H 'Accept: application/json'

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– dans src/main/java : la classe principale de l'application

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– un ensemble de dépendances Spring en tant que <dependencyManagement>

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

On contourne le problème en ajoutant spring-boot-dependencies en tant que <dependencyManagement>, avec un <scope>import</scope>

Note : concrètement, le spring-boot-starter-parent hérite lui-même de spring-boot-dependencies.

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– spring-boot-starter-web : support du développement web (Spring MVC, Tomcat...)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– en spécifiant le packaging souhaité dans le pom.xml (classiquement en Maven)

<packaging>jar</packaging>

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

Le code métier reste évidemment à la charge du développeur.

public static void main(String[] args) {

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

Ce starter apporte les dépendances vers (entre autres) :

– JUnit : le standard pour les tests unitaires en Java

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– être situées dans src/main/resources/static/error (ou /public/error)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

– la gestion des logs (LogBack par défaut, implémentant le standard SLF4J)

Voici une liste non exhaustive des propriétés disponibles.

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

De plus, on peut définir plusieurs profils :

Ces fichiers .properties/.yml peuvent être externalisés en dehors du jar/war.

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)

de Spring à Spring Boot - le chef d'orchestre Spring Boot (Orange internal)