Déni, colère, marchandage, dépression… 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... Acceptation… 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 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. Spring Boot Il peut donc y avoir plusieurs raisons à cela : Vous disposez peut-être déjà de l'infrastructure configurée pour déployer des applications dans GlassFish ou un autre serveur d'applications EE. Dans ce cas, le serveur d'applications EE est installé, configuré et entièrement pris en charge. Même si l'application peut s'exécuter de manière indépendante, comme c'est le cas avec Spring Boot, vous devrez toujours préparer et maintenir l'infrastructure pour le déploiement et l'exécution. Vous savez qu'après un certain temps, vous commencerez à abandonner le serveur d'application et donc à utiliser à l'avance la technologie que vous utiliserez à l'avenir avec la possibilité de l'utiliser dans l'environnement actuel Différentes expériences et expertises au sein de l'équipe Expériences et tests d'hypothèses Java 8 Java 8 est sorti le 18 mars 2014 et a apporté que nous utilisons encore aujourd'hui. des fonctionnalités importantes 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, ont été publiées à ce jour ( ) : trois versions LTS 19/08/2024 Java SE 11(55) - 25 septembre 2018 Java SE 17(61) - 14 septembre 2021 Java SE 21(65) - 19 septembre 2023 Selon une , 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. étude menée par New Relic GlassFish 4.1.2 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 , 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. site web d'Oracle Placez simplement le fichier de distribution quelque part sur votre machine, accédez au dossier et exécutez la commande suivante : bin ./asadmin start-domain --verbose Attendez un instant et essayez d'ouvrir , 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. http://localhost:4848/ C'est tout ce que vous devez savoir sur GlassFish pour le moment pour essayer d'y déployer votre application. Botte de printemps 2 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. en 2021 et nécessite Java 8 comme version minimale contrairement à . Spring Boot 2 est sorti 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 , 2.7.18 est devenu la dernière version de support Spring Boot 2.x et par conséquent Java 8 et Java 11 : blog 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 Commencer à les utiliser ensemble Prérequis : Java 8 GlassFish 4.1.2 Spring Boot 2.7.18 Maven La communauté Spring Boot sur la façon d'exécuter l'application Spring Boot dans l'environnement EE + fournit des recommandations Documentation officielle pom.xml Le minimum et suffisant pour créer et exécuter l'application ressemblera à ce qui suit : fichier pom.xml <?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é dans l'artefact résultant. Vous disposez désormais d'au moins trois options pour exécuter l'artefact résultant : lib-provided Déployer sur GlassFish - : il existe essentiellement trois manières de déployer une application Interface d'administration de GlassFish Copiez votre fichier d'archive dans le répertoire autodeploy sous le domain-dir/autodeploy API - commande asadmin de déploiement Exécutez avec : deux artefacts : et . Le simple inclut , l' non. java -jar spring-boot-maven-plugin crée war war.original war lib-provided original Démarrez l'application dans votre IDE préféré - pour IntelliJ IDEA Community Edition, vous devez ajouter l'option suivante sous Configuration d'exécution/débogage 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> Classe d'application 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 et l'annoter avec l'annotation . main @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 : Hériter de la classe Application de SpringBootServletInitializer Remplacer la méthode SpringApplicationBuilder protégée configure(SpringApplicationBuilder builder) @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); } } Descripteur de déploiement 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 Pour conclure N'ayez pas peur d'utiliser des technologies plus anciennes Restez curieux et continuez à développer vos compétences Bonne chance GitHub LinkedIn
