Page d'accueil>Lié à la programmation>Code source JAVA
Télécharger

Exemples Java EE 7

Cet espace de travail comprend des exemples Java EE 7 et des tests unitaires. Ils sont classés dans différents répertoires, un pour chaque technologie/JSR.

Certains échantillons/tests ont une documentation, sinon lisez le code. Le livre Java EE 7 Essentials fait référence à la plupart de ces exemples et fournit une explication. N'hésitez pas à ajouter des documents et à envoyer une pull request.

Comment courir ?

Les échantillons sont testés sur Payara, GlassFish, Wildfly et plus encore en utilisant l'écosystème Arquillian.

Une brève instruction sur la façon de cloner, créer, importer et exécuter les exemples sur votre ordinateur local que @radcortez fournit dans cet exemple de vidéo https://www.youtube.com/watch?v=BB4b-Yz9cF0

Un seul profil de conteneur peut être actif à un moment donné, sinon il y aura des conflits de dépendances.

Il existe 16 profils de conteneurs disponibles, pour 6 serveurs différents :

  • Payara et GlassFish

    • payara-ci-managed

      Ce profil installera un serveur Payara et démarrera le serveur par exemple. Utile pour les serveurs CI. La version Payara utilisée peut être définie via la propriété payara.version . Il s'agit du profil par défaut et il n'est pas nécessaire de le spécifier explicitement.

    • payara-embedded

      Ce profil utilise le serveur intégré Payara et s'exécute dans la même JVM que TestClass. Utile pour le développement, mais présente l'inconvénient du démarrage du serveur par échantillon.

    • payara-remote

      Ce profil nécessite que vous démarriez un serveur Payara en dehors de la build. Chaque échantillon réutilisera ensuite cette instance pour exécuter les tests. Utile pour le développement afin d'éviter le coût de démarrage du serveur par échantillon.

      Ce profil prend en charge certains tests pour définir l'emplacement où Payara est installé via la propriété système glassfishRemote_gfHome . Par exemple

      -DglassfishRemote_gfHome=/opt/payara171

      Ceci est utilisé pour envoyer des commandes asadmin pour créer des ressources de conteneur, telles que des utilisateurs dans un magasin d'identités.

    • glassfish-embedded

      Ce profil utilise le serveur intégré GlassFish et s'exécute dans la même JVM que TestClass. Utile pour le développement, mais présente l'inconvénient du démarrage du serveur par échantillon.

    • glassfish-remote

      Ce profil nécessite que vous démarriez un serveur GlassFish en dehors de la build. Chaque échantillon réutilisera ensuite cette instance pour exécuter les tests. Utile pour le développement afin d'éviter le coût de démarrage du serveur par échantillon.

      Ce profil prend en charge certains tests pour définir l'emplacement où GlassFish est installé via la propriété système glassfishRemote_gfHome . Par exemple

      -DglassfishRemote_gfHome=/opt/glassfish41

      Ceci est utilisé pour envoyer des commandes asadmin pour créer des ressources de conteneur, telles que des utilisateurs dans un magasin d'identités.

  • Mouche sauvage

    • wildfly-ci-managed

      Ce profil installera un serveur Wildfly et démarrera le serveur par exemple. Utile pour les serveurs CI. La version de WildFly utilisée peut être définie via la propriété wildfly.version .

    • wildfly-embedded

      Ce profil est presque identique à celui de wildfly-ci-managed. Il installera le même serveur Wildfly et redémarrera ce serveur par exemple, mais utilisera à la place le connecteur intégré Arquillian pour l'exécuter dans la même JVM. Utile pour les serveurs CI. La version de WildFly utilisée peut être définie via la propriété wildfly.version .

    • wildfly-remote

      Ce profil nécessite que vous démarriez un serveur Wildfly en dehors de la build. Chaque échantillon réutilisera ensuite cette instance pour exécuter les tests. Utile pour le développement afin d'éviter le coût de démarrage du serveur par échantillon.

    • wildfly-swarm

      Ce profil utilise WildFly Swarm, qui permet de créer des uberjars contenant juste assez du serveur d'applications WildFly. Ici, les parties de WildFly incluses sont sélectionnées en fonction de l'inspection de l'application et de la recherche des API Java EE réellement utilisées. La version de WildFly Swarm utilisée peut être définie via la propriété wildfly.swarm.version .

  • TomEE

    • tomee-ci-managed

      Ce profil installera un serveur TomEE et démarrera ce serveur par exemple. Utile pour les serveurs CI. Ce profil ne peut pas se connecter à un serveur en cours d'exécution.

      Notez que la version de TomEE à utiliser doit être présente dans un référentiel maven disponible. Les valeurs par défaut de ce profil supposent que l'adaptateur arquillian et le serveur TomEE ont la même version. Par exemple, les deux 7.0.0.

      Pour utiliser un serveur TomEE qui n'est pas disponible dans maven central, une façon de l'utiliser pour les exemples consiste à l'installer dans un .m2 local comme suit :

      Cloner le dépôt TomEE :

      git clone https://github.com/apache/tomee cd tomee

      Basculez vers la version souhaitée si nécessaire, puis compilez et installez en .m2 :

      mvn clean install -pl tomee/apache-tomee -am -Dmaven.test.skip=true

      mvn clean install -pl arquillian -amd -Dmaven.test.skip=true

      Assurez-vous que la version installée (voir pom.xml dans le projet TomEE) correspond à tomee.version dans la section propriétés de la racine pom.xml du projet d'exemples.

    • tomee-embedded

      Ce profil utilise le serveur intégré TomEE et s'exécute dans la même JVM que TestClass.

  • Liberté

    • liberty-managed

      Ce profil démarrera le serveur Liberty par exemple et se connectera éventuellement à un serveur en cours d'exécution que vous pourrez démarrer en dehors de la build (avec la restriction que ce serveur doit s'exécuter sur l'hôte où les tests sont exécutés en utilisant le même utilisateur ).

      Pour vous connecter à un serveur en cours d'exécution, la propriété système org.jboss.arquillian.container.was.wlp_managed_8_5.allowConnectingToRunningServer doit être définie sur true. Par exemple

      -Dorg.jboss.arquillian.container.was.wlp_managed_8_5.allowConnectingToRunningServer=true

      Ce profil nécessite que vous définissiez l'emplacement où Liberty est installé via la propriété système libertyManagedArquillian_wlpHome . Par exemple

      -DlibertyManagedArquillian_wlpHome=/opt/wlp

      Ce profil nécessite également que la fonctionnalité localConnector soit configurée dans server.xml, et si tous les tests doivent être exécutés, la fonctionnalité javaee-7.0, par exemple 

      < featureManager >
    < feature >javaee-7.0</ feature >
    < feature >localConnector-1.0</ feature >
</ featureManager >

      Pour les anciennes versions de Liberty (avant 16.0.0.0), afin que les tests JASPIC puissent même être tentés d'être exécutés, une triche est nécessaire pour créer un groupe dans le registre d'utilisateurs interne de Liberty : 

      < basicRegistry id = " basic " >
    < group name = " architect " />
</ basicRegistry >

      Cette astuce n'est pas nécessaire pour les dernières versions de Liberty (16.0.0.0/2016.7 et versions ultérieures)

    • liberty-ci-managed

      Ce profil téléchargera et installera un serveur Liberty et démarrera le serveur par exemple. Utile pour les serveurs CI. Notez qu'il ne s'agit pas d'un véritable serveur embarqué, mais d'un serveur classique. Il est désormais appelé « intégré » car aucune installation distincte n’est nécessaire car il est téléchargé automatiquement.

  • Logique Web

    • weblogic-remote

      Ce profil nécessite que vous démarriez un serveur WebLogic en dehors de la build. Chaque échantillon réutilisera ensuite cette instance pour exécuter les tests.

      Ce profil nécessite que vous définissiez l'emplacement où WebLogic est installé via la propriété système weblogicRemoteArquillian_wlHome . Par exemple

      -DweblogicRemoteArquillian_wlHome=/opt/wls12210

      Le nom d'utilisateur et le mot de passe par défaut sont respectivement « admin » et « admin007 ». Cela peut être modifié à l’aide des propriétés système weblogicRemoteArquillian_adminUserName et weblogicRemoteArquillian_adminPassword . Par exemple

      -DweblogicRemoteArquillian_adminUserName=myuser -DweblogicRemoteArquillian_adminPassword=mypassword

  • Matou

    • tomcat-remote

      Ce profil nécessite que vous démarriez un serveur Tomcat simple (8.5 ou 9) en dehors de la build. Chaque échantillon réutilisera ensuite cette instance pour exécuter les tests.

      Tomcat prend en charge les exemples qui utilisent Servlet, JSP, Expression Language (EL), WebSocket et JASPIC.

      Ce profil nécessite que vous activiez JMX dans Tomcat. Cela peut être fait en ajoutant ce qui suit à [tomcat home]/bin/catalina.sh : 

       JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.port=8089 -Dcom.sun.management.jmxremote=true "
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.ssl=false "
JAVA_OPTS="$JAVA_OPTS -Dcom.sun.management.jmxremote.authenticate=false"
JAVA_OPTS="$JAVA_OPTS -Djava.rmi.server.hostname=localhost "

      Ce profil vous oblige également à définir un nom d'utilisateur ( tomcat ) et un mot de passe ( manager ) pour l'application de gestion dans tomcat-users.xml . Voir le fichier test-utils/src/main/resources/tomcat-users.xml dans ce référentiel pour un exemple complet.

      Sachez que cela ne doit être fait que pour une instance Tomcat utilisée exclusivement à des fins de test, car ce qui précède rendra l'installation de Tomcat totalement non sécurisée !

    • tomcat-ci-managed

      Ce profil installera un serveur Tomcat et démarrera le serveur par exemple. Utile pour les serveurs CI. La version de Tomcat utilisée peut être définie via la propriété tomcat.version .

Les conteneurs qui téléchargent et installent un serveur (les profils gérés *-ci-ci) permettent de remplacer la version utilisée, par exemple :

  • -Dpayara.version=4.1.1.163

    Cela changera la version de la version actuelle (par exemple 4.1.1.171.1) à 4.1.1.163 à des fins de test Payara.

  • -Dglassfish.version=4.1

    Cela changera la version de la version actuelle (par exemple 4.1.1) à 4.1 à des fins de test GlassFish.

  • -Dwildfly.version=8.1.0.Final

    Cela changera la version de la version actuelle (par exemple 10.1.0.Final) à 8.1.0.Final pour WildFly.

Pour les exécuter dans la console, faites :

  1. Dans le terminal, mvn test -fae dans le répertoire de niveau supérieur pour démarrer les tests du profil par défaut.

Lorsque vous les développez et les exécutez à partir de l'IDE, n'oubliez pas d'activer le profil avant d'exécuter le test.

Pour en savoir plus sur Arquillian, veuillez vous référer aux guides Arquillian.

Pour exécuter uniquement un sous-ensemble des tests, effectuez-le dans le répertoire de niveau supérieur :

  1. Installer les dépendances de niveau supérieur : mvn clean install -pl "test-utils,util" -am
  2. cd dans le module souhaité, par exemple : cd jaspic
  3. Exécutez les tests sur le serveur souhaité, par exemple : mvn clean test -P liberty-ci-managed

Comment contribuer

Avec votre aide, nous pouvons améliorer cet ensemble d'échantillons, apprendre les uns des autres et développer une communauté remplie de personnes passionnées et soucieuses de la technologie, de l'innovation et de la qualité du code. Chaque contribution compte !

Il y a juste un tas de choses que vous devez garder à l'esprit avant d'envoyer une pull request, afin que nous puissions facilement incorporer toutes les nouvelles choses dans la branche master.

Les tests standard sont basés sur jUnit - par exemple ce commit. La dénomination des classes de test doit être conforme aux normes de dénomination infaillibles **/*Test.java , **/*Test*.java ou **/*TestCase.java .

Par souci de clarté et de cohérence, et pour minimiser la complexité initiale, nous préférons les tests jUnit standards utilisant Java, avec comme aides supplémentaires HtmlUnit, Hamcrest et bien sûr Arquillian. Veuillez ne pas utiliser d'alternatives à ces technologies. Si une nouvelle dépendance doit être introduite dans ce projet, elle doit fournir quelque chose qui n'est pas couvert par ces dépendances existantes.

Quelques principes de codage

  • Lors de la création d'un nouveau fichier source, ne mettez (ni ne copiez) aucun en-tête de licence, car nous utilisons une licence de niveau supérieur (MIT) pour chaque fichier de ce référentiel.
  • Veuillez suivre le profil de formatage du code de la communauté JBoss tel que défini dans le référentiel jboss/ide-config. Les détails y sont expliqués, ainsi que les configurations pour Eclipse, IntelliJ et NetBeans.

Petits conseils Git

  • Assurez-vous que votre fork est toujours à jour. Exécutez simplement git pull upstream master et vous êtes prêt à pirater.
  • Lors du développement de nouvelles fonctionnalités, veuillez créer une branche de fonctionnalités afin que nous puissions intégrer vos modifications en douceur. C'est également pratique pour vous car vous pouvez travailler sur quelques choses en parallèle ;) Afin de créer une branche de fonctionnalités et d'y accéder d'un seul coup, vous pouvez utiliser git checkout -b my_new_cool_feature

C'est ça! Bienvenue dans la communauté !

Emploi CI

Les tâches CI sont exécutées par Travis. Notez qu'en raison de la nature même des échantillons fournis ici, il est tout à fait normal que tous les tests ne réussissent pas. Cela indiquerait normalement un bug sur le serveur sur lequel les échantillons sont exécutés. Si vous pensez que c'est vraiment le test qui est défectueux, veuillez soumettre un problème ou fournir un correctif à un PR.

Exécutez chaque échantillon dans Docker

  • Installez le client Docker depuis http://boot2docker.io

  • Créez l'exemple que vous souhaitez exécuter sous

    mvn clean package -DskipTests

    Par exemple:

    mvn -f jaxrs/jaxrs-client/pom.xml clean package -DskipTests

  • Modifiez la deuxième ligne dans Dockerfile pour spécifier l'emplacement du fichier WAR généré

  • Exécutez boot2docker et donnez la commande

    docker build -it -p 80:8080 javaee7-sample

  • Dans un autre shell, recherchez l'adresse IP du conteneur en cours d'exécution comme :

    boot2docker ip

  • Accédez à l'exemple sous http://IP_ADDRESS:80/jaxrs-client/webresources/persons. L'URL exacte diffère en fonction de l'échantillon.

Développer
Informations supplémentaires
Applications connexes
Recommandé pour vous
Actualités connexes Tout