Tout développeur rêve de travailler avec des technologies modernes et de rester à la pointe. En fait, il est presque impossible de construire une stratégie de recrutement solide autour de technologies obsolètes, souvent inefficaces, voire mort-nées.
Cependant, la vie est complexe et tout ne dépend pas toujours de nos désirs.
On pourrait vous proposer une promotion et vous transférer vers un projet où les technologies n'ont pas changé ou n'ont pas été mises à jour depuis des années. Ou bien, vous pourriez décrocher un emploi dans l'entreprise de vos rêves, où la pile technologique actuelle ne vous intéresse pas particulièrement pour le moment. Peut-être venez-vous de terminer vos études universitaires et êtes-vous impatient d'acquérir votre première expérience professionnelle, ou peut-être avez-vous été licencié de votre emploi précédent et devez-vous trouver quelque chose rapidement pour éviter des difficultés financières.
Il existe également un autre scénario : lors de l'entretien, on vous dit que vous commencerez à travailler avec la pile actuelle, mais que vous aurez de nombreuses possibilités d'apporter des modifications à l'avenir - peut-être, éventuellement, mais...
Mais soyons honnêtes, tout ceci n'est que de la philosophie. Je suis d'accord et je vous propose d'analyser un cas réel que vous pourriez rencontrer au cours de votre parcours professionnel difficile.
Pour tous les fans de la pile JVM, en particulier ceux qui aiment Spring Framework, ceci est pour vous, s'il vous plaît, lisez la suite.
Au fait, pourquoi auriez-vous besoin de déployer une application Spring Boot sur un serveur d'applications alors qu'elle peut s'exécuter de manière indépendante ? Après tout, c'est l'une des fonctionnalités les plus remarquables de Spring Boot.
Il peut donc y avoir plusieurs raisons à cela :
Java 8 est sorti le 18 mars 2014 et a apporté des fonctionnalités importantes que nous utilisons encore aujourd'hui.
Je n’ai pas besoin d’aller bien loin pour trouver des exemples, en voici quelques-uns :
Expressions Lambda
API de flux
Cours optionnel
Le package java.time (API de date et d'heure)
etc etc
Depuis lors, trois versions LTS ont été publiées à ce jour ( 19/08/2024 ) :
Selon une étude menée par New Relic , Java 8 est encore utilisé dans 28,8 % des projets actuels, ce qui, vous en conviendrez, n'est pas négligeable. Si sa part diminue progressivement d'année en année, il est certainement trop tôt pour écarter complètement cette technologie.
Selon le site Web du projet Eclipse dédié à Eclipse GlassFish :
Eclipse GlassFish® est un serveur d'applications complet qui implémente la spécification Jakarta EE. GlassFish inclut des implémentations de toutes les API Jakarta EE requises et facultatives et passe tous les TCK Jakarta EE. GlassFish inclut également une console d'administration complète, une prise en charge du clustering et d'autres outils et fonctionnalités axés sur le développement et la production.
Malheureusement, il n'est pas possible de télécharger depuis ce site web une version antérieure à la 5.1.0, mais comme nous avons décidé d'utiliser la version inférieure à la cinquième, nous devrons nous rendre sur le site web d'Oracle , où vous pourrez trouver plusieurs versions antérieures de ce produit dans la section Téléchargements. Mais soyez prudent avec la licence et n'utilisez rien de ce dossier en dehors de votre sandbox.
Placez simplement le fichier de distribution quelque part sur votre machine, accédez au dossier bin
et exécutez la commande suivante :
./asadmin start-domain --verbose
Attendez un instant et essayez d'ouvrir http://localhost:4848/ , la console d'administration devrait être disponible par défaut et ne devrait demander aucun type d'informations d'identification. Sur le panneau de gauche, vous trouverez l'onglet Applications, si vous cliquez dessus, vous aurez accès à un menu avec lequel vous pourrez déployer, annuler le déploiement, activer et désactiver des applications.
C'est tout ce que vous devez savoir sur GlassFish pour le moment pour essayer d'y déployer votre application.
Il est probablement assez difficile de trouver une personne dans le monde du développement Web qui n’a pas entendu parler de ce framework populaire au moins une fois.
Spring Boot 2 est sorti en 2021 et nécessite Java 8 comme version minimale contrairement à la version 3 qui nécessite Java 17 comme version minimale .
Pour pouvoir utiliser les dernières fonctionnalités, les correctifs de sécurité et certaines optimisations, nous devons trouver la dernière version prenant en charge Java 8.
Et le voici, 2.7.18, selon leur blog , 2.7.18 est devenu la dernière version de support Spring Boot 2.x et par conséquent Java 8 et Java 11 :
Après 5,5 ans et 121 versions, la version 2.7.18 marque la fin du support open source pour Spring Boot 2.x. Veuillez effectuer la mise à niveau vers Spring Boot 3 dès que possible. Si vous n'êtes pas encore prêt à effectuer la mise à niveau, un support commercial pour Spring Boot 2.7.x est disponible .
La communauté Spring Boot fournit des recommandations sur la façon d'exécuter l'application Spring Boot dans l'environnement EE + Documentation officielle
Le fichier pom.xml minimum et suffisant pour créer et exécuter l'application ressemblera à ce qui suit :
<?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>2.7.18</version> <relativePath/> </parent> <groupId>io.github.isharipov</groupId> <artifactId>sb2-to-gf4</artifactId> <version>1.0-SNAPSHOT</version> <packaging>war</packaging> <properties> <maven.compiler.source>8</maven.compiler.source> <maven.compiler.target>8</maven.compiler.target> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion> </exclusions> <scope>provided</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-maven-plugin</artifactId> </plugin> </plugins> </build> </project>
Ici, vous devez faire attention à deux choses :
Je conditionne l'application sous forme de fichier war pour indiquer clairement au serveur d'applications que je déploie une application Web
<packaging>war</packaging>
J'exclus Tomcat intégré en ajoutant la dépendance spring-boot-starter-tomcat en excluant deux dépendances internes et en ajoutant la portée fournie
<dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-tomcat</artifactId> <exclusions> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion> </exclusions> <scope>provided</scope> </dependency>
Cette approche vous permet d'inclure Tomcat et de le rendre disponible uniquement pour l'environnement d'exécution Spring Boot, ce qui vous permet d'exécuter l'application indépendamment du serveur d'applications. Cette séparation est importante. Spring place cette dépendance dans un dossier distinct appelé lib-provided dans l'artefact résultant. Vous disposez désormais d'au moins trois options pour exécuter l'artefact résultant :
domain-dir/autodeploy
asadmin
- commande de déploiementjava -jar
: spring-boot-maven-plugin crée deux artefacts : war
et war.original
. Le war
simple inclut lib-provided
, l' original
non.L’exclusion des dépendances suivantes nous permet de réduire la taille de l’artefact résultant :
<exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-el</artifactId> </exclusion> <exclusion> <groupId>org.apache.tomcat.embed</groupId> <artifactId>tomcat-embed-websocket</artifactId> </exclusion>
Pour exécuter une application Spring Boot sur un serveur d’applications, vous devez apporter deux modifications à la classe d’application principale.
En règle générale, pour configurer une application Web simple, vous devez créer une classe publique avec une méthode main
et l'annoter avec l'annotation @SpringBootApplication .
@SpringBootApplication public class Application { private static final Logger LOGGER = LoggerFactory.getLogger(Application.class); public static void main(String[] args) { SpringApplication.run(Application.class, args); } }
Donc, comme je l’ai mentionné plus haut, deux amendements :
@SpringBootApplication public class Application extends SpringBootServletInitializer { private static final Logger LOGGER = LoggerFactory.getLogger(Application.class); public static void main(String[] args) { LOGGER.debug("From main"); SpringApplication.run(Application.class, args); } @Override protected SpringApplicationBuilder configure(SpringApplicationBuilder application) { LOGGER.debug("From configure"); return application.sources(Application.class); } }
Et enfin, vous devez ajouter un descripteur de déploiement
Ainsi, sous le dossier principal → src → webapp → WEB-INF, vous devez placer le fichier suivant - glassfish-web.xml :
<?xml version="1.0" encoding="UTF-8" ?> <!DOCTYPE glassfish-web-app PUBLIC "-//GlassFish.org//DTD GlassFish Application Server 3.1 Servlet 3.0//EN" "http://glassfish.org/dtds/glassfish-web-app_3_0-1.dtd"> <glassfish-web-app> <class-loader delegate="false"/> <session-config> <session-manager/> </session-config> <jsp-config/> </glassfish-web-app>
En savoir plus sur le descripteur de déploiement
En savoir plus sur la délégation du chargeur de classe