Deux Outils Indispensables Pour Les Développeurs Jakarta EE

J'adore les nouveaux jouets. J'aime vraiment les nouveaux jouets dans des piles technologiques qui ont fait leurs preuves. J'aime beaucoup les nouveaux jouets qui me permettent de jouer avec les nouvelles technologies anticipées dans les produits qui ont fait leurs preuves. Les jouets qui sont des outils sont les meilleurs de tous.

Dans cet article, je vais discuter de deux nouveaux jouets qui, lorsqu'ils sont utilisés ensemble, peuvent très bien devenir une flèche incontournable pour votre carquois de développement logiciel. Ces outils sont le wildfly-jar-maven-plugin et le tout nouveau wildfly-datasources-preview-galleon-pack du projet WildFly.

WildFly, un projet upstream pour le serveur d'applications JBoss de RedHat, est une excellente solution pour de nombreux projets. Le serveur d'applications est compatible avec Jakarta EE 8 et les nouvelles versions "preview" du serveur d'applications WildFly sont compatibles avec Jakarta EE version 9.1.

Le plan de release de WildFly comprend la préparation de la sortie prochaine de Jakarta 10 avec une futur "preview" de leur serveur d'applications afin que les développeurs puissent tester la prochaine version du standard. Passionnant.

Pour l'instant, nous allons nous concentrer sur WildFly 26.0.1 Preview – sorti la dernière semaine de janvier – et Jakarta EE 9.1.

Premier nouveau jouet

Le wildfly-jar-maven-plugin permet aux développeurs de provisionner (déterminer les parties, dépendances ou capacités dont votre application a besoin à partir du serveur d'applications et effectuer toute configuration requise) un serveur WildFly et générer un Uber JAR qui contient votre application et le conteneur WildFly à l'aide de Maven. C'est vrai. L'ensemble du serveur d'applications et votre application sont regroupés dans un fichier JAR bien rangé. Utilisez la commande :

java -jar nameOfYourApplication-bootable.jar

et le serveur démarre et votre application est prête à fonctionner. Déposez ce JAR bootable sur un serveur de votre réseau local, déployez-le sur votre appareil périphérique, déployez-le dans un environnement conteneurisé et, bien sûr, dans votre répertoire cible. Vous trouverez toujours votre fichier WAR standard qui maintient votre application prête à être déployée dans le conteneur Jakarta EE exécuté sur un bare metal ou dans une machine virtuelle.

C'est beaucoup d'options et tout un tas de travail de configuration, mais ce plugin le fait en un clin d'œil. Ce plugin semble avoir été poussé vers le référentiel Maven en 2020 et la version la plus récente, 7.0.0.Final, a été poussée il y a quelques mois. Au vu de la fréquence des versions dans le référentiel Maven, le plugin est clairement maintenu activement.

Comme ci-dessus, avec le serveur d'applications et votre application étroitement liés, vous êtes à quelques pas d'un fichier Docker trivial en préparation pour un déploiement sur Kubernetes. L'ajout du plugin à votre pom.xml de Maven peut ressembler à ceci :

<plugin>
  <groupId>org.wildfly.plugins</groupId>
  <artifactId>**wildfly-jar-maven-plugin**</artifactId>
  <version>${version.wildfly.jar.maven.plugin}</version>
  <configuration>
    <log-time>true</log-time>
    <cloud>
      <type>kubernetes</type>
    </cloud>
    <context-root>false</context-root>
    <feature-packs>
      <feature-pack>
        <location>wildfly@maven(org.jboss.universe:community-universe)#${version.wildfly}
        </location>
      </feature-pack>
      <feature-pack>
        <groupId>org.wildfly</groupId>
        <artifactId>wildfly-datasources-galleon-pack</artifactId>
        <version>${version.wildfly.datasources.galleon-pack}</version>
      </feature-pack>
    </feature-packs>
    <hollow-jar>false</hollow-jar>
    <plugin-options>
      <jboss-fork-embedded>true</jboss-fork-embedded>
    </plugin-options>
    <!-- Listen on all ports -->
    <arguments>
      <argument>-b=0.0.0.0</argument>
    </arguments>
    <!-- Make sure we can debug -->
    <jvmArguments>
      <arg>-agentlib:jdwp=transport=dt_socket,address=8787,server=y,suspend=n</arg>
    </jvmArguments>
    <cli-sessions>
      <cli-session>
        <!-- Feed WildFly Some Properties -->
        <properties-file>package_properties.properties</properties-file>
        <!-- Run some jboss-cli.sh commands against WildFly -->
        <script-files>
          <script>package_script.cli</script>
        </script-files>
      </cli-session>
    </cli-sessions>
    <excluded-layers>
      <!-- Just here to demonstrate one can take layers OUT of the Container -->
      <layer>core-management</layer>
      <layer>deployment-scanner</layer>
      <layer>jmx-remoting</layer>
      <layer>request-controller</layer>
      <layer>security-manager</layer>
    </excluded-layers>
    <layers>
      <!-- Some of these layers are redundant as Galleon dependencies take's care of most things -->
      <layer>cloud-server</layer>
      <layer>ejb-dist-cache</layer>
      <layer>web-clustering</layer>
      <layer>ee</layer>
      <layer>ejb-lite</layer>
      <layer>jaxrs</layer>
      <layer>jpa</layer>
      <layer>jsf</layer>
      <layer>jsonb</layer>
      <layer>jsonp</layer>
      <!-- These go along with **wildfly-datasources-preview-galleon-pack** -->
      <layer>datasources-web-server</layer>
      <layer>postgresql-datasource</layer> <!-- Yes, there are other drivers available -->
    </layers>
  </configuration>
  <executions>
    <execution>
      <goals>
        <goal>package</goal>
      </goals>
    </execution>
  </executions>
</plugin>

La documentation complète pour la création de fichiers JAR amorçables est disponible ici. Pour vous aider à démarrer rapidement, j'ai publié un exemple de code sur GitHub. Clonez ce dépôt et lancez la commande :

mvn clean
mvn wildfly-jar:dev-watch

Second nouveau jouet

Maintenant que nous avons exploré le premier nouveau jouet, prenons la version "preview" de WildFly pour un tour. Tout d'abord, nous mettrons à jour l'emplacement du "feature pack" à partir de :

<location>wildfly@maven(org.jboss.universe:community-universe)#${version.wildfly}</location>

pour

<location>wildfly-preview@maven(org.jboss.universe:community-universe)#${version.wildfly}</location>

Nous devrons également changer l'artifactId pour le tout nouveau wildfly-datasources-preview-galleon-pack afin que nous puissions connecter notre application à une base de données. Après tout, qu'est-ce qu'une application sans données ?

Ensuite, mettez à jour :

<artifactId>wildfly-datasources-galleon-pack</artifactId>

pour

<artifactId>wildfly-datasources-preview-galleon-pack</artifactId>

Les mainteneurs des WildFly extras, le référentiel parent des extras de la communauté Java pour WildFly, méritent beaucoup de crédit pour l'avoir mis à disposition ! C'était vraiment un ajout intéressant et nécessaire pour expérimenter une application basée sur une base de données utilisant la version "preview" de WildFly. Il a été poussé vers Maven la première semaine de février 2022.

Utilisez la commande :

mvn wildfly-jar:dev-watch

et vous êtes opérationnel. Votre code est surveillé et déployé pendant que vous enregistrez vos fichiers par le wildfly-jar-maven-plugin. Et, avec le wildfly-datasources-preview-galleon-pack, la connexion à votre base de données est triviale. Pas mal.

La plupart des IDE vous permettront d'utiliser "mvn maven wildfly-jar:dev-watch" via leurs contrôles graphique de Maven. Ci-dessous, une capture d'écran d'IntelliJ IDEA montrant leurs contrôles Maven qui incluent le wildfly-jar-maven-plugin tel que configuré dans notre pom.xml.

Tout comme sur la ligne de commande, "mvn maven wildfly-jar:dev-watch", l'IDE affichera la sortie de la construction, du lancement et de la configuration de l'exemple d'application :

Dans la configuration de l'unité de persistance de l'application d'exemple, il existe une propriété jakarta.persistence.sql-load-script-source qui référence le fichier my_jpa_data_table.sql situé dans le répertoire META-INF de l'application. Ce fichier SQL est utilisé pour insérer quelques enregistrements dans la table de base de données utilisée par l'application d'exemple. Après avoir lancé l'application d'exemple, exécutez une commande SELECT simple sur la table my_jpa_data_table dans PostgreSQL. Dans la capture d'écran ci-dessous, voici ce que vous trouverez après avoir pointé l'exemple d'application sur votre serveur de base de données et lancé à l'aide des outils de cet article :

Et, juste pour démontrer que l'exemple d'application fait des allers-retours complets, vous pouvez ouvrir un navigateur pour afficher les données dans l'application :

Si vous souhaitez voir comment ces outils accéléreront le temps de développement de votre application, laissez la commande "mvn maven wildfly-jar:dev-watch" en cours d'exécution, modifiez le index.xhtml dans l'application d'exemple et enregistrez le fichier. Vous verrez l'application se redéployer rapidement et vos modifications seront reflétées dans le navigateur Web. Vous pouvez vous attendre au même comportement, non seulement au niveau de l'interface utilisateur de l'application, mais à tous les niveaux ; base de données démarrée.

Des jouets cool.

Quelques conseils si vous prenez wildfly-preview avec le wildfly-datasources-preview-galleon-pack pour essayer d'utiliser wildfly-jar-maven-plugin :

• La configuration des "couches" gère toutes les dépendances dont vous pourriez avoir besoin de WildFly. Si vous savez que vous allez conteneuriser, vous pouvez simplement commencer par ajouter la couche "cloud-server" et la "postgresql-datasource" ou la couche de source de données qui correspond à votre base de données.
• S'il y a des "couches" dont vous n'avez pas besoin, vous pouvez les exclure afin d'affiner votre Uber JAR. J'en ai exclu quelques-uns dans la configuration de mon plugin juste pour démontrer cette capacité du wildfly-jar-maven-plugin. Consultez les couches disponibles et déterminez celles qui sont facultatives ou non nécessaires à vos besoins.
• Vous souhaiterez mettre à jour l'espace de noms javax dans votre application vers jakarta. La version standard de WildFly vous permettra d'utiliser soit l'ancien espace de noms javax, soit le nouvel espace de noms jakarta, mais la version preview est axée sur Jakarta EE, vous aurez donc besoin d'utiliser systématiquement les packages import jakarta.* dans votre code source Java. La même chose devrait s'appliquer à votre fichier web.xml si cela s'applique à votre projet.
• Gardez à l'esprit qu'il s'agit d'une preview, il est donc préférable d'utiliser la version standard en production.

Un conseil essentiel !

• Vous remarquerez que nulle part nous n'avons défini les paramètres de l'application pour trouver notre serveur de base de données et la base de données au sein de ce serveur. Le wildfly-datasources-preview-galleon-pack lira ces informations à partir des variables d'environnement. Maintenant, vous pouvez également définir des propriétés dans WildFly, mais en pratique, je recommanderais des variables d'environnement. Cela se prête à la conteneurisation du serveur d'application / de l'application en Uber JAR.

Exemple de variables d'environnement de base de données sous Linux :

export POSTGRESQL_HOST=server.withyourdatabase.com
export POSTGRESQL_PORT=5432
export POSTGRESQL_DATABASE=quickDb
export POSTGRESQL_USER=yourUsername
export POSTGRESQL_PASSWORD=yourSecretPassword

Alternativement, un exemple de variables d'environnement de base de données dans un IDE :

Après avoir découvert le plugin et obtenu l'aide de la communauté WildFly pour m'assurer que je pouvais me connecter à une base de données à l'aide de la version en preview, cette combinaison d'outils a rapidement atteint le statut "ne peut pas vivre sans". J'ai dû me réprimander avec "Comment ai-je raté ça ?" En combinaison, ces "feature packs" Galleon et le wildfly-jar-maven-plugin est une expérience vraiment agréable pour le développeur qui peut être apprécié. C'est particulièrement vrai avec mvn wildfly-jar:dev-watch !

Pourtant, aussi utile que "mvn wildfly-jar:dev-watch" est en cours de développement actif, l'objectif est d'obtenir un seul JAR compatible avec la base de données qui possède toutes les capacités inhérentes à WildFly prêt pour déploiement. C'est assez simple avec ce plugin. Lancez simplement la commande :

mvn clean package wildfly-jar:package

Des jouets cool. En effet!

Les éléments de configuration à prendre en compte

Les problèmes de configuration de base de votre application peuvent être résolus en utilisant le wildfly-jar-maven-plugin. Vous verrez cela dans l'exemple de code dans lequel il y a quelques fichiers (presque) vides qui peuvent être utilisés pour ajouter des variables d'environnement d'application et émettre des commandes de configuration supplémentaires pour terminer votre configuration de WildFly.

Vous verrez que dans le fichier package_script.cli, j'ajoute la ligne :

/system-property=somePropertyName:add(value=somePropertyValue)

qui définit la propriété "somePropertyName" sur "somePropertyValue. L'ajout de cette ligne revient essentiellement à utiliser

${JBOSS_HOME}/bin/jboss-cli.sh /system-property=somePropertyName:add(value=somePropertyValue)

sur la ligne de commande. Les fichiers package_script.cli et package_properties.properties référencés par le plug-in dans l'exemple de code semblent suffisants pour la plupart des configurations de serveur d'applications dont vous pourriez avoir besoin.

Pourtant, même avec cette flexibilité, je n'ai pas encore déterminé la best practice pour certaines tâches de configuration. Non pas qu'il n'y ait pas de moyens de résoudre ces problèmes de configuration, mais vous aurez toujours besoin d'un plan.

Prenons, par exemple, un scénario dans lequel vous devez conserver les informations d'identification en toute sécurité. Si votre application va dans un environnement Kubernetes, vous utiliserez probablement quelque chose comme Sealed Secrets de Bitnami ou HashiCorp's Vault donc ce n'est pas un défi. Sur votre poste de travail, ou votre serveur où vous avez le contrôle de l'environnement d'exploitation, votre application peut référencer cet environnement.

Mais que se passe-t-il si le mieux pour votre application était de stocker ces informations d'identification dans le conteneur WildFly ? WildFly inclut un excellent sous-système de sécurité, Elytron, il serait donc naturel d'utiliser l'outil. La possibilité de stocker vos informations d'identification dans WildFly avec Elytron doit être envisagée.

Sur votre poste de travail ou votre serveur, vous ajouteriez un « secret-key-credential-store » à l'aide de la commande ${JBOSS_HOME}/bin/jboss-cli.sh. Cette série de commandes pourrait ressembler à :

history --disable
/subsystem=elytron/secret-key-credential-store=secret-key-credential-store:add(relative-to=jboss.server.config.dir, path=secretKeyCredentialStore.cs)
/subsystem=elytron/secret-key-credential-store=secret-key-credential-store:export-secret-key(alias=key)
/subsystem=elytron/expression=encryption:add(resolvers=[{name=secret-key-resolver, credential-store=secret-key-credential-store, secret-key=key}])

Jusqu'ici tout va bien. Mais, le premier obstacle dans cette tâche de configuration "sécuriser les informations d'identification à l'intérieur de WildFly" se présente maintenant. Les deux commandes suivantes que vous auriez besoin d'utiliser, la création d'une expression pour votre mot de passe en texte clair (l'entrée) à la première commande et l'ajout de la sortie de cette commande à un "credential-store" sont dépendantes :

/subsystem=elytron/expression=encryption:create-expression(resolver=secret-key-resolver, clear-text=passwordThatNoOneWillEverGuess)

/subsystem=elytron/credential-store=credential-store:add(relative-to=jboss.server.config.dir, path=credentialStoreCandela.cs, credential-reference={clear-text= OUTPUT_OF_PREVIOUS_COMMAND_AS_INPUT_HERE }, create=true)

Enchaîner les sorties d'une commande à une autre tout en travaillant dans une fenêtre de terminal est assez simple. Ou, au pire, il s'agit d'une tâche d'administration système ponctuelle dans laquelle vous devez simplement copier-coller l'expression de la première commande dans la seconde. Continuer à terminer la tâche est également assez simple lorsque vous utilisez :

/subsystem=elytron/credential-store=credential-store:generate-secret-key(alias=key)
/subsystem=elytron/expression=encryption:list-add(name=resolvers, value={name=resolver, credential-store=credential-store, secret-key=key})
reload
/subsystem=elytron/expression=encryption:write-attribute(name=default-resolver, value=resolver)
reload
/subsystem=elytron/expression=encryption:create-expression(clear-text=passwordThatNoOneWillEverGuess)
history --enable
/subsystem=elytron/credential-store=credential-store:add-alias(alias=MyFirstCredential, secret-value=doNotShareThis)
/subsystem=elytron/credential-store=credential-store:add-alias(alias=MySecondCredential, secret-value=AlsoDoNotShareThis)
/subsystem=elytron/secret-key-credential-store=secret-key-credential-store:read-aliases
/subsystem=elytron/credential-store=credential-store:read-aliases

Les commandes « reload » présentées ci-dessus sont nécessaires pour terminer la tâche et ne posent pas de problème sur un poste de travail ou un serveur. L'exécution de cette tâche à la volée via les commandes "mvn wildfly-jar:watch-dev" et "mvn clean package wildfly-jar:package" fournit le processus qui semble « aller de l'avant ». Cela signifie que la configuration à la volée effectuée par ces outils ne permet pas de demander au serveur d'application de relire et de recharger son fichier de configuration maître qui, dans cette tâche de configuration spécifique, est une étape obligatoire.

Existe-t-il des moyens possibles d'aborder une configuration légèrement complexe comme celle-ci ? Bien sûr. Peut-être simplement copier dans un fichier de configuration et les fichiers de support appropriés dans une phase Maven choisie. Voyez peut-être jusqu'où vous pouvez aller en remplissant package_script.cli et package_properties.properties avec vos données.

Quel serait l'idéal ? Je ne suis pas encore certain compte tenu de mon expérience relativement courte avec le wildfly-jar-maven-plugin. Mes premières pensées sont que le wildfly-preview-datasources-galleon-pack est si lisse que peut-être un "wildfly-credential-store-galleon-pack" ou un nouvel artefact d'outillage pourrait être créé dans l'ordre pour faire face à ce scénario spécifique. Peut-être ajouter le pack galleon à la configuration du plug-in et le laisser lire un nombre de variables d'environnement (peut-être avec une convention de dénomination prédéfinie ?) Ou lire à partir d'un fichier de propriétés stocké en toute sécurité en dehors de votre référentiel d'applications sur votre poste de travail de développement. Cela vous permettra de charger ces informations d'identification en toute sécurité dans Elytron à la volée, tout comme le wildfly-preview-datasources-galleon-pack traite de la connectivité de la base de données à la volée.

Encore une fois, je viens de choisir la sécurisation des informations d'identification dans WildFly comme scénario dans lequel une planification supplémetaire est requise si vous souhaitez utiliser le plug-in. Je suis sûr que vous pouvez imaginer d'autres tâches de configuration pour votre application en fonction de vos besoins de déploiement si vous la regroupez dans un JAR amorçable.

Assez n'est jamais assez

C'est trop cool. Que pourrait-on vouloir de plus ? Je suis content que vous ayez posé la question, car quel type d'utilisateur final serais-je si je n'en voulais pas plus ?

Je souhaite utiliser les pilotes Eclipse Vert.x pour me connecter à ma base de données et j'espère qu'ils seront intégrés à wildfly-datasources-preview-galleon-pack. Ce souhait présuppose qu'une nouvelle version d'Hibernate, l'implémentation JPA et ORM dans WildFly, s'associe à Hibernate Reactive. Le site Hibernate indique qu'il s'agirait de la version 5.6. Hibernate 5.3 est la version fournie avec wildfly-preview. Peut-être que cela devient un non-problème si Hibernate ORM 6 atteint un statut stable à temps pour Jakarta EE 10. Cette bienveillance d'Hibernate Reactive se trouve dans des projets comme Quarkus, et j'aimerais voir ces fonctionnalités disponibles dans WildFly. Pour autant que ces ajouts n'enfreignent pas la conformité à la norme Jakarta EE. Cela ne devrait pas être un problème car la norme n'exclut généralement pas « plus » d'un serveur d'applications et/ou d'un fournisseur d'outils.

Il existe un WildFly MicroProfile Reactive Feature Pack mais je n'ai vu aucune référence spécifique à Hibernate Reactive comme Panache dans ce référentiel de projet spécifique.

Finalement

Ce ne sont pas seulement de nouveaux jouets, mais des outils utiles. Essayez le wildfly-jar-maven-plugin et avec lui le wildfly-datasources-preview-galleon-pack si vous regardez wildfly-preview pour votre application basée sur une base de données.

J'ai posté un petit exemple de projet sur GitHub si vous souhaitez utiliser cette combinaison de nouveaux outils pour un essai et que vous êtes pressés. Ce fichier Dockerfile trivial mentionné précédemment et, pour faire bonne mesure, un exemple de fichier Kubernetes YAML se trouvent également dans le référentiel. L'exemple de code contient un fichier SQL de référence, une unité de persistance JPA et un objet JPA configurés, ainsi qu'une page JSF pour afficher les données si vous choisissez de remplir la table. Le wildfly-datasources-preview-galleon-pack rend votre JAR amorçable compatible avec la base de données avec très peu d'effort (il suffit de définir la variable d'environnement pour qu'elle pointe vers votre base de données) et l'exemple d'application récupère certaines données et les affiche.

Ressources et remerciements

Jakarta EE est vraiment un centre de gravité dans l'écosystème Java. Il est très probable que si vous ne l'utilisez pas directement via un ou plusieurs des nombreux serveurs d'applications, comme WildFly, qui implémentent l'intégralité de la norme, vous utilisez l'une de ses bibliothèques indirectement ou telle qu'implémentée par d'autres projets Java dans l'écosystème. Les outils abordés dans cet article feront du travail avec Jakarta EE et WildFly, en particulier, une expérience agréable. Il se passe tellement de grandes choses dans l'espace Java et Jakarta EE, un espace où l'activité ne semble que s'accélérer. Il peut être difficile de ne pas manquer quelque chose qui peut vraiment augmenter votre productivité et améliorer votre expérience de travail avec cette norme essentielle. Au-delà de la Fondation Eclipse, l'organisation responsable de Jakarta EE, les Jakarta EE Ambassadors sont une excellente communauté et ressource pour les développeurs. C'est un bon moyen pour vous d'être informé sur les événements liés à Jakarta EE. Si vous n'êtes pas déjà membre, envisagez de devenir membre des Jakarta EE Ambassadors comme un moyen de vous engager professionnellement dans cette partie de l'écosystème Java !

Merci encore à l'équipe wildfly-extras. Tant de bons outils sortent du projet WildFly et les outils dont nous avons discuté ici ne sont pas la moindre de ces bonnes choses. Chacun de ces outils ajoute au plaisir de développer des applications en utilisant Jakarta EE et WildFly !