Création de WAR traditionnels pour déploiement sur serveur d'applications externe

Pourquoi choisir le format WAR pour Spring Boot ?

Spring Boot privilégie par défaut la création de fichiers JAR exécutables autonomes, embarquant le serveur (comme Tomcat) et toutes les dépendances nécessaires. C'est une approche moderne et pratique pour de nombreux cas d'usage, notamment dans les environnements de microservices et de conteneurisation. Cependant, il existe des situations où la création d'un fichier WAR (Web Application Archive) traditionnel reste nécessaire ou préférable.

Les principales raisons pour générer un WAR incluent :

• Infrastructure existante : Votre entreprise ou votre client utilise peut-être déjà une infrastructure basée sur des serveurs d'applications Java EE / Jakarta EE (Tomcat, JBoss/WildFly, WebSphere, WebLogic, etc.) et les processus de déploiement sont établis autour du format WAR.
• Politiques d'entreprise : Certaines organisations imposent l'utilisation de serveurs d'applications centralisés et gérés pour des raisons de sécurité, de standardisation ou de mutualisation des ressources.
• Fonctionnalités du serveur : Vous pourriez avoir besoin de fonctionnalités spécifiques fournies par le serveur d'applications externe (gestion avancée des pools de connexions, intégration JTA, services de sécurité spécifiques, etc.) qui ne sont pas directement gérées par Spring Boot ou qui sont plus faciles à configurer au niveau du serveur.
• Déploiements multiples : Un serveur d'applications peut héberger plusieurs applications WAR, ce qui peut être pertinent dans certains contextes de consolidation.

Spring Boot est suffisamment flexible pour supporter nativement la création de fichiers WAR, vous permettant de bénéficier de sa simplicité de développement tout en vous adaptant à ces contraintes de déploiement.

Configurer le projet pour la génération d'un WAR

Passer d'un JAR exécutable à un WAR traditionnel nécessite quelques ajustements dans la configuration de votre projet Maven ou Gradle.

1. Changer le type de packaging :

Dans votre fichier `pom.xml` (Maven), modifiez la balise `` de `jar` à `war` :

war

Dans votre fichier `build.gradle` (Gradle), appliquez le plugin `war` (il remplace ou complète souvent le plugin `java` ou `org.springframework.boot`) :

// build.gradle
plugins {
    id 'java'
    id 'war' // Ajoute le plugin WAR
    id 'org.springframework.boot' version '3.x.x' // Remplacez par votre version
    id 'io.spring.dependency-management' version '1.x.x'
}

2. Marquer le serveur embarqué comme "provided" :

Puisque le WAR sera déployé sur un serveur externe qui fournit déjà les bibliothèques de servlet, vous devez exclure le serveur embarqué (Tomcat par défaut) du WAR final. Pour cela, déclarez la dépendance `spring-boot-starter-tomcat` avec la portée `provided`.

Avec Maven :

    
        org.springframework.boot
        spring-boot-starter-web
        
    

    
        org.springframework.boot
        spring-boot-starter-tomcat
        provided 
    
    

Avec Gradle :

// build.gradle
dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web'
    // implementation ('org.springframework.boot:spring-boot-starter-web') {
    //    exclude group: 'org.springframework.boot', module: 'spring-boot-starter-tomcat'
    // }
    providedRuntime 'org.springframework.boot:spring-boot-starter-tomcat' // ICI : Marquer comme fourni
    // implementation 'org.springframework.boot:spring-boot-starter-jetty' // Si serveur externe = Jetty
    // implementation 'org.springframework.boot:spring-boot-starter-undertow' // Si serveur externe = Undertow
    // Autres dépendances
}

Notez que la dépendance `spring-boot-starter-web` est toujours nécessaire car elle apporte Spring MVC et d'autres composants web essentiels.

Initialiser l'application avec `SpringBootServletInitializer`

Lorsqu'une application Spring Boot démarre en tant que JAR exécutable, la méthode `main` de la classe annotée avec `@SpringBootApplication` lance le processus. Cependant, lorsqu'elle est déployée en tant que WAR dans un conteneur de servlets externe (comme Tomcat), le cycle de vie est géré par le conteneur. Le conteneur recherche un point d'entrée spécifique conforme à l'API Servlet pour initialiser l'application.

Spring Boot fournit une classe d'aide, `SpringBootServletInitializer`, pour faire le pont entre le mécanisme de démarrage de Spring Boot et l'API Servlet standard. Pour l'utiliser, vous devez modifier votre classe principale (celle annotée avec `@SpringBootApplication`) pour qu'elle hérite de `SpringBootServletInitializer` et surcharge la méthode `configure`.

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.builder.SpringApplicationBuilder;
import org.springframework.boot.web.servlet.support.SpringBootServletInitializer;

@SpringBootApplication
public class MonApplicationWar extends SpringBootServletInitializer { // Hérite de SpringBootServletInitializer

    @Override
    protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
        // Pointe vers la classe de configuration principale (@SpringBootApplication)
        return application.sources(MonApplicationWar.class);
    }

    public static void main(String[] args) {
        // La méthode main est toujours utile pour lancer en mode JAR embarqué (pendant le dev)
        SpringApplication.run(MonApplicationWar.class, args);
    }

}

Le rôle de la méthode `configure` est d'indiquer à Spring Boot quelle est la source principale de configuration (votre classe `@SpringBootApplication`) lorsqu'il est démarré par le conteneur externe. La présence de la méthode `main` reste utile car elle vous permet toujours de lancer l'application avec un serveur embarqué pendant le développement et les tests, sans avoir besoin de déployer systématiquement sur un serveur externe.

Générer et déployer le fichier WAR

Une fois ces modifications effectuées, la génération du fichier WAR se fait via les commandes de build standard de Maven ou Gradle.

Avec Maven, exécutez :

mvn clean package

Le fichier WAR sera généré dans le répertoire `target/` (par exemple, `target/mon-application-0.0.1-SNAPSHOT.war`).

Avec Gradle, exécutez :

gradle clean build

Le fichier WAR se trouvera généralement dans le répertoire `build/libs/`.

Le déploiement du fichier WAR dépend ensuite du serveur d'applications externe que vous utilisez. Généralement, il suffit de copier le fichier WAR généré dans un répertoire de déploiement spécifique surveillé par le serveur (par exemple, le répertoire `webapps/` pour Tomcat, ou `deployments/` pour JBoss/WildFly). Consultez la documentation de votre serveur d'applications pour les instructions précises.

Il est important de noter que le nom du fichier WAR déployé détermine souvent le contexte racine de l'application sur le serveur. Par exemple, un fichier `monapp.war` sera généralement accessible à l'adresse `http://serveur:port/monapp`.

Considérations importantes

Lorsque vous passez d'un JAR exécutable à un déploiement WAR, gardez à l'esprit quelques points :

• Gestion des dépendances : Assurez-vous qu'il n'y a pas de conflits entre les bibliothèques fournies par votre WAR et celles déjà présentes sur le serveur d'applications. La portée `provided` aide à éviter d'embarquer les API Servlet et le serveur lui-même, mais d'autres conflits peuvent survenir (versions de Logback, Jackson, etc.).
• Configuration : Les sources de configuration externalisées de Spring Boot (application.properties, variables d'environnement, etc.) fonctionnent généralement de la même manière. Cependant, le serveur d'applications peut offrir ses propres mécanismes de configuration (JNDI, modules) qui pourraient interagir ou être préférés dans certains environnements.
• Cycle de vie : Le démarrage et l'arrêt de l'application sont désormais gérés par le serveur externe, et non plus directement par la méthode `main`.
• Développement et tests : La possibilité de conserver la méthode `main` et de lancer en mode embarqué est un grand avantage pour le développement et les tests unitaires/d'intégration rapides, même si la cible finale est un WAR.

En résumé, créer un WAR avec Spring Boot est une fonctionnalité bien supportée qui permet d'intégrer la puissance et la simplicité de Spring Boot dans des environnements de déploiement plus traditionnels basés sur des serveurs d'applications externes.