Everything is wrong » JBoss

JBoss – Tracer les requêtes HTTP

Yan — Tue, 22 Jul 2014 19:09:15 +0000

En travaillant sur un test Graphene 2, je me suis rendu compte qu’il pouvait être très intéressant de tracer le contenu des requêtes HTTP attaquant une application web. Lorsque cette application est déployée sur un serveur JBoss, il suffit d’ajouter une ligne dans le fichier jboss-web.xml :



   
      org.apache.catalina.valves.RequestDumperValve

Remarque, je n’ai pas essayé sur WildFly, mais la technique devrait fonctionner de la même façon. Ce fichier doit être dans le répertoire WEB-INF de l’archive web.

JSF2.2 – Hello world

Yan — Fri, 14 Mar 2014 21:11:04 +0000

Voici un exemple d’une application JSF2.2 minimaliste. Une vue xhtml un bean Java contenant le message “Hello world !”. Une configuration minimaliste aussi pour pouvoir déployer l’application dans le serveur wildfly.

Vue d’ensemble et configurations

Pour cette application il est suffisant d’avoir un fichier Java porteur des données (le model), un fichier xhtml décrivant la vue et un quelques fichiers de configuration :

beans.xml : ce fichier est vide dans cet exemple. Il permet à l’application de bénéficier du CDI
faces-config.xml : ce fichier est vide dans cet exemple. Il permet de configurer tout ce qui est en lien avec JSF
web.xml : ce fichier est facultatif je l’ai ajouté pour avoir un exemple de namespace XML pour la bonne version du serveur wildfly

Pour rappel, JSF est une technologie qui se base sur le modèle MVC-2. Le rôle du contrôleur est joué par la servlet JSF qui centralise les demandes provenant de la vue et qui redirige vers les bons traitements Java (avec JSF on parle en général d’actions).

Le model (Bean Java)

L’objet Java qui va contenir les données, c’est à dire le message “Hello world !” est un String. Cet objet va être créé par un producer en scope Request. A chaque nouvel appel à la vue, une nouvelle requête sera nécessaire et l’objet sera recréé de toute pièce.

package org.eiw.data;

import javax.annotation.PostConstruct;
import javax.enterprise.context.RequestScoped;
import javax.enterprise.inject.Produces;
import javax.inject.Named;

/***
 * Le producer est dans le scope Request,
 * il sera recréé à chaque nouvelle requête HTTP.
 */
@RequestScoped
public class HelloWorldProducer {
	private String message;

	/**
	 * La méthode qui produit l'objet de données vis à vis de la page XHTML.
	 */
	@Named
	@Produces
	public String getMessage() {
		return message;
	}

	/**
	 * La méthode qui initialise l'objet,
	 * à chaque nouvelle requête HTTP.
	 */
	@PostConstruct
	public void initMessage() {
		message = "Hello world !";
	}
}

La vue (XHTML)

Dans ce fichier, nous allons utiliser le conteneur CDI pour récupérer l’objet Java des données vu ci-dessus. Nous allons ensuite l’associer à un tag JSF pour formater son affichage :

Pour récupérer l’objet, il faut utiliser son nom qui est égal par défaut au nom de l’instance avec le langage EL : #{maVariable}.

Le déploiement

Pour déployer cette application, il suffit d’utiliser le plugin wildfly avec la commande suivante : mvn wildfly:run. Ensuite de se rendre sur l’adresse http://localhost:8080/hello-world/index.jsf et de visualiser le résultat :

Remarque : s’il s’agit de la première fois que vous utilisez le plugin wildfly, il vous faudra un peu de temps pour démarrer l’application car il est nécessaire de télécharger, dans le repository maven local, le serveur complet avant de le démarrer.

Ce tutoriel est disponible sur GitHub à l’adresse suivante : https://github.com/yanLanglois/jsf-2.2-tutoriel/tree/master/hello-world.

Maven – Wildfly plugin

Yan — Sat, 08 Mar 2014 21:03:57 +0000

J’ai découvert qu’il existait un plugin maven pour le serveur d’application Wildfly qui se comporte exactement comme le plugin maven pour tomcat. Pour l’utiliser, il faut ajouter ces quelques lignes dans le fichier pom.xml.


    ...
    
        ...
        
            ...
            
                org.wildfly.plugins
                wildfly-maven-plugin
                1.0.1.Final
            
            ...
        
        ...
    
...

Le goal wildfly:run compile et package le projet, puis le déploie dans une instance du serveur. Deux possibilités, soit la variable d’environnement wildfly.home existe et le serveur installé à cet emplacement est utilisé, soit elle n’existe pas et le serveur wildfly est téléchargé puis déployé dans le répertoire target du projet.

Le plugin permet beaucoup plus de choses que le simple démarrage de l’application dans un conteneur piloté par Maven. Pour plus d’information, son adresse est la suivante : https://docs.jboss.org/wildfly/plugins/maven/latest/.

PicketLink : Activer les traces dans le fichier de log

Yan — Thu, 30 Jan 2014 21:09:52 +0000

Pour débuger l’authentification faite grâce à picketLink avec JBoss Wildfly, il est nécessaire d’ajouter le logger ci-dessous puis de modifier la priorité par défaut de la console.

org.picketlink.idm

Pour cela, il faut se connecter à la console du serveur d’application puis se rendre sur la gestion des logger dans l’onglet “LOG CATEGORIES”.

Ajouter la catégorie associée au package picketLink avec le niveau DEBUG.

Enfin dans la catégorie “HANDLER”, modifier le niveau de log du handler console.

Pour information, les modifications sont prises en compte à chaud. Pas besoin de redémarrer le serveur.

JBoss 7 : Plusieurs instances standalone sur un même serveur

Yan — Thu, 13 Jun 2013 22:06:08 +0000

Pour démarrer une instance JBoss en mode standalone avec les configurations par défaut, il faut exécuter la commande suivante : $JBOSS_HOME/bin/standalone.sh

Pour créer sa propre instance, il est uniquement nécessaire de copier les fichiers de configuration originaux du serveur standalone dans un répertoire quelconque du système de fichier puis d’exécuter la commande précédente avec l’option -Djboss.server.base.dir=XX. Par exemple :

xxxx@xxxx:~/tmp/testsJboss1$ tree
.
├── configuration
│   ├── application-roles.properties
│   ├── application-users.properties
│   ├── logging.properties
│   ├── mgmt-users.properties
│   └── standalone.xml
└── deployments
xxxx@xxxx:~/$ $JBOSS_HOME/bin/standalone.sh -Djboss.server.base.dir=~/tmp/testsJboss1/

Remarque : L’option jboss.socket.binding.port-offset associée à un entier (-Djboss.socket.binding.port-offset=1), vous permet de démarrer une instance en décalant tous les ports du serveur et ainsi éviter toute interférence avec un autre serveur.

JBoss 7 : Datasources dans un WAR

Yan — Fri, 28 Sep 2012 19:17:57 +0000

Avec JBoss 7, il est possible de déclarer une datasource JNDI dans une archive WAR. Pour cela, il faut déposer un fichier ma-datasource-ds.xml dans le répertoire WEB-INF avec la déclaration de la source de données. Par exemple :




   
   
      jdbc:mysql://localhost:3306/activiti?useUnicode=true&characterEncoding=UTF-8
      mysql
      
         root
         123456

La valeur de l’élément driver, est le nom du driver installé sur le serveur. Pour l’installer, il est possible de copier le jar dans le répertoire de déploiement du serveur (cp mysql.jar /standalone/deployments).

Sources : https://community.jboss.org/thread/204245, https://community.jboss.org/wiki/DataSourceConfigurationInAS7, https://github.com/abstractj/as-quickstarts/blob/40f8cae2ce9388151e1a07f743df74e59c7848bc/kitchensink-html5-mobile/src/test/resources/arquillian-ds.xml

Appliation J2EE6 avec JBoss 7 et Maven

Yan — Wed, 03 Aug 2011 18:57:10 +0000

JBoss propose un certain nombre d’archetypes dont un qui génère une application J2EE6 pour JBoss 7 : org.jboss.spec.archetypes:jboss-javaee6-webapp. Or, par défaut, maven ne connait pas cet archetype. Voici comment réussir à l’utiliser dans Eclipse.

Avant toute chose, il faut vérifier que maven est configuré pour aller chercher des librairies sur le repository JBoss : le fichier settings.xml (~/.m2/settings.xml ou $MAVEN_HOME/conf/settings.xml) doit contenir le code XML suivant :


 ...
  
    ...
    
      jboss-public-repository
      
        
          jboss-public-repository-group
          JBoss Public Maven Repository Group
          https://repository.jboss.org/nexus/content/groups/public-jboss/
          default
          
            true
            never
          
          
            true
            never
          
        
      
      
        
          jboss-public-repository-group
          JBoss Public Maven Repository Group
          https://repository.jboss.org/nexus/content/groups/public-jboss/
          default
          
            true
            never
          
          
            true
            never
          
        
      
    

  

  
    jboss-public-repository
  
  ...

Ensuite, pour créer le projet dans Eclipse, il faut commencer par installer le catalogue JBoss : Windows -> Preferences… puis dans la fenêtre Maven -> Achetypes cliquer sur le bouton Add Remote Catalog… Saisir https://repository.jboss.org/nexus/content/groups/public/archetype-catalog.xml dans l’intitulé Catalogue File et JBoss dans Description. Après l’opération, il ne reste plus qu’à accéder au wizard de création d’un projet Maven (File -> New -> Project… puis Maven project) et de sélectionner l’archetype jboss-javaee6-webapp.

Le squelette de l’application est celui-ci :

Ce qui équivaut à une application de départ avec un exemple JSF2 s’appuyant sur une base de données embarquée avec quelques classes constituant un modèle MVC, un exemple de service web REST, et un exemple de test unitaire avec Arquillian. A noter aussi, l’utilisation d’un EJB3 archivé dans un WAR et non un EAR comme il aurait fallu le faire avec J2EE5.

Pour déployer l’application il faut la packager et utiliser le plugin JBoss de déploiement déjà configuré par l’archetype (maven package jboss-as:deploy). Attention, pour que tout se déroule correctement, il faudra avoir démarré votre serveur JBoss7 au préalable.

Maven et SeamTest

Yan — Tue, 22 Mar 2011 22:10:46 +0000

L’intégration des tests unitaires SeamTest dans un projet Maven est assez compliquée. Voici un exemple concret :

Présentation du projet

Avant de rentrer dans des détails techniques, je préfère vous parler de l’application qui va me servir de base pour intégrer mon test SeamTest.

Vision fonctionnelle

J’ai choisi de me baser sur l’exemple “hello world” du livre Seam Framework: Experience the Evolution of Java EE 2nd edition. Vous pouvez retrouver les sources des exemples du livre à l’adresse suivante : http://solutionsfit.com/blog/books/. Malheureusement, l’auteur utilise Ant et non Maven pour gérer la compilation de ses projets.

J’ai rajouté l’utilisation d’un service EJB Stateless pour démontrer la possibilité d’utiliser SeamTest dans un contexte technique hétérogène. Voici le diagramme des cas d’utilisation de l’application :

Vision maven

Le projet est composé d’un module père ayant trois modules fils :

seamtest-parent
|– seamtest-ear
|– seamtest-ejb
`– seamtest-webapp

Vous pouvez checkouter les sources à l’adresse suivante : https://subversion.assembla.com/svn/everythingiswrong/seamtest-parent/.

Dans le reste de l’article, je vais me focaliser sur le module seamtest-ejb car c’est lui qui contient le composant Seam, la persistance et l’EJB Stateless à tester.

Composant Seam à tester

Nous allons tester le composant qui va :

Enregistrer une nouvelle personne dans la base de données
Rechercher toutes les personnes de la base de données

@Stateful
@Name("manager")
public class ManagerAction extends Manager {
  @In
  private Person person;

  @Out
  private List fans;

  @EJB
  private CalculService calculService;

  @PersistenceContext
  private EntityManager em;

  //Méthode à tester.
  public void sayHello () {
    em.persist (person);
    fans = em.createQuery("select p from Person p").getResultList();
  }

  // Méthode pour vérifier l'injection de l'EJB Stateless dans le composant Seam
  public int additionner(int a, int b) {
    return (int) calculService.addition(a, b);
  }

  @Remove
  @Destroy
  public void destroy() {
  }
}

Installation et configuration

Pour information, SeamTest utilise le serveur JBoss embedded.

Installation de JBoss Embedded

Cette installation se résume à la copie du répertoire booststrap qui est dans la distribution de Seam (par exemple ici) dans le répertoire src/test.

Le fichier “pom.xml”

Ce fichier doit contenir l’ensemble des librairies qui vont permettre de démarrer et d’exécuter le serveur JBoss embedded. Il doit aussi prendre en compte le répertoire de bootstrap ajouté précédemment dans les ressources des tests.


  ...
  
  
  
    org.jboss.seam.embedded
    jboss-embedded-all
    beta3.SP12
    test
    
      
        org.jboss.microcontainer
        jboss-deployers-client-spi
      
      
        org.jboss.microcontainer
        jboss-deployers-core-spi
      
    
  
  
    org.jboss.seam.embedded
    hibernate-all
    beta3.SP12
    test
  
  
    org.jboss.seam.embedded
    thirdparty-all
    beta3.SP12
    test
  

  
  
  
    javax.faces
    jsf-api
    1.2_09
    test
  

  
  
    org.jboss.el
    jboss-el
    1.0_02.CR4    
    test
  

  
  
    org.testng
    testng
    5.8
    jdk15
    test
  


  
    
      src/test/resources
      true
    
    
      src/test/bootstrap
      false
    
    
      src/test/bootstrap
      true
      
        **/*.xml
      
    
  
  ...

Remarque : à l’heure actuelle la version la plus récente du conteneur est la beta3.SP12.

Fichiers de tests

Dans la pratique, on ajoute toujours un fichier seam.properties vide dans le classpath des jar contenant des composants Seam. Dans le cas du test, ce fichier doit contenenir au minimum l’information sur le nom JNDI des EJB :

org.jboss.seam.core.init.jndiPattern = #{ejbName}/local

La classe de test doit étendre SeamTest. Elle peut ensuite utiliser l’EL pour référencer les composants Seam :

public class ManagerActionTest extends SeamTest {
  private static Logger LOGGER = Logger.getLogger(ManagerActionTest.class);

  @Test
  public void testSayHello() {
    try {
      new ComponentTest() {
        @Override
        protected void testComponents() throws Exception {
          setValue("#{person.name}", "Yan");
          invokeMethod("#{manager.sayHello}");
          List fans = (List) getValue("#{fans}");
          assertNotNull(fans);
          assertEquals(1, fans.size());
          assertEquals("Yan", fans.get(0).getName());
          // Test le service EJB
          assertEquals(3, invokeMethod("#{manager.additionner(1, 2)}"));
        }
      }.run();
    } catch (Exception e) {
      LOGGER.error("TEST KO : " + e.getMessage());
      fail("TEST KO : " + e.getMessage());
    }
  }
}

En utilisant Hibernate, vous pouvez exécuter des scripts SQL au déploiement de votre test en ajoutant un fichier import.sql dans le classpath de test (src/test/resources). Cela dit, dans ce cas, je conseillerai plutôt d’utiliser l’intégration avec DBUnit.

Exécution

Pour exécuter les tests il faut lancer la commande mvn clean test.

Variantes

Intégration avec DBUnit

L’intégration est possible entre seamTest et DBUnit. La classe de test doit étendre DBunitSeamTest et implémenter la méthode prepareDBUnitOperations(). Il faut aussi donner à TestNg la nom JNDI de la source de données vers la base de données ainsi que le type de la base de données (HSQL ou MYSQL). Pour cela, il faut configurer le plugin surefire comme cela :


  ...
  
    org.apache.maven.plugins
    maven-surefire-plugin
    2.4.3
    
      
        
          datasourceJndiName
          java:/DefaultDS
        
        
          database
          HSQL
        
      
      -Dsun.lang.ClassLoader.allowArraySyntax=true
    
 ...

Remarque : deux propriétés pour déclarer le type de la source de données et son nom JNDI ainsi qu’un argument pour permettre au serveur JBoss Embedded de s’éxécuter avec une JDK 1.6 (par défaut ce serveur n’est compatible qu’avec une JDK1.5).

Pour information, DBUnit propose deux implémentations différentes pour décrire les données d’une base : le FlatXmlDataSet et le XmlDataSet (http://dbunit.sourceforge.net/components.html). SeamTest ne support que le FlatXmlDataSet.

Dépendances sur des projets ou modules de type EJB

Dans le cas où votre module dépende d’un autre module EJB, il faut arriver à déployer la dépendance de type EJB dans le conteneur JBoss embedded. Il est possible de faire cette opération avec le plugin maven maven-dependency-plugin comme cela :


  ...
  
    org.apache.maven.plugins
    maven-dependency-plugin
    
      
        copy
        process-test-resources
        
          copy
        
        
          
            
              ...
              ...
              ...
              ...
              ...
              false
              ${project.build.directory}/test-classes/deploy
            
          
        
      
    
  
  ...

Remarque : la copie de la dépendance se déroule avant la phase d’exécution des tests.

Profiler une application J2EE avec JBoss et TPTP

Yan — Thu, 10 Mar 2011 19:00:06 +0000

Cet article va vous expliquer comment utiliser Eclipse pour vérifier les performances d’une application sous JBoss. Je vous laisserai découvrir les écrans de reporting par vous même car ils dépendent de votre code source.

Installation

Il est nécessaire d’installer les plugins suivant dans eclipse :

TPTP qui est dispoinble à partir du site d’update : http://download.eclipse.org/tptp/updates/galileo/
JBoss Tools (notamment Test and Performances -> TPTP Profile On JBoss Server) qui est disponible à partir du site d’update : http://download.jboss.org/jbosstools/updates/development/

Puis il faut créer un serveur JBoss depuis la vue Server.

TPTP

JBoss TPTP

Exécution

Pour exécuter le profilage, il faut démarrer votre serveur JBoss avec le bouton Profile. Eclipse vous demande de choisir le type d’informations à mesurer. Une seule possibilité à la fois (je n’ai pas encore compris pourquoi je ne peux pas avoir plusieurs data collector en même temps…) :

Avant de cliquer sur le bouton Finish, n’hésitez pas à ajouter ou modifier les filtres par défaut en double-cliquant sur Java Profiling. Cela va vous permettre de focaliser votre attention sur votre code et non celui des librairies tierces que vous utilisez :

Après le démarrage de votre serveur en mode profile, le collecteur de données se synchronise à intervalle de temps régulier. Pour éviter d’enregistrer des informations inutiles, vous pouvez le mettre en pause par exemple.

Problèmes rencontrés et astuces

JRebel

Il faut savoir que JRebel ne fonctionne pas lorsqu’on utilise TPTP. Donc si vous utilisez cet outil, il faudra le désactiver (démarrer votre serveur JBoss sans les paramètres JRebel) pour pouvoir profiler votre application.

Profiles indisponibles

Si lorsque vous essayez de démarrer votre serveur en mode profile vous avez une exception vous parlant de collecteur de données, vérifier que vos plugins soient bien à jour.

Performances

TPTP est très gourmand en mémoire donc ne vous étonnez pas de voire les performances de votre application chuter rapidement. J’ai aussi remarqué que les performances d’éclipse s’effondrent rapidement lors de l’analyse des données quand celles-ci sont très volumineuses.

Utiliser l’annuaire JNDI d’un JBoss embedded

Yan — Sun, 12 Dec 2010 12:54:17 +0000

Il est toujours difficile de paramétrer les conteneurs embarqués. Encore plus lorsque ces derniers ne sont plus très récents et donc pas très bien documentés. C’est pourquoi je vous propose cet article qui va vous apprendre à enregistrer une chaine de caractère (java.lang.String) dans l’annulaire JNDI de JBoss embedded. Pour cela, il faut ajouter ce code XML dans le fichier embedded-jboss-beans.xml de votre classpath :


    La valeur de la variable
    variableName
    true

Voici un exemple concret : https://subversion.assembla.com/svn/everythingiswrong/embedded-jboss-jndi-exemple.

Pour plus d’information sur le conteneur embarqué de JBoss que j’utilise dans l’exemple : http://docs.jboss.org/ejb3/embedded/embedded.html.