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<Person> 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.

<dependencies>
  ...
  <!-- dépendances des tests unitaites : http://community.jboss.org/thread/18299 -->
  <!-- dependencies related to JBoss Embedded for Seam 2.X.X -->
  <dependency>
    <groupId>org.jboss.seam.embedded</groupId>
    <artifactId>jboss-embedded-all</artifactId>
    <version>beta3.SP12</version>
    <scope>test</scope>
    <exclusions>
      <exclusion>
        <groupId>org.jboss.microcontainer</groupId>
        <artifactId>jboss-deployers-client-spi</artifactId>
      </exclusion>
      <exclusion>
        <groupId>org.jboss.microcontainer</groupId>
        <artifactId>jboss-deployers-core-spi</artifactId>
      </exclusion>
    </exclusions>
  </dependency>
  <dependency>
    <groupId>org.jboss.seam.embedded</groupId>
    <artifactId>hibernate-all</artifactId>
    <version>beta3.SP12</version>
    <scope>test</scope>
  </dependency>
  <dependency>
    <groupId>org.jboss.seam.embedded</groupId>
    <artifactId>thirdparty-all</artifactId>
    <version>beta3.SP12</version>
    <scope>test</scope>
  </dependency>

  <!-- dependencies related to JBoss MicroContainer -->
  <!-- java.lang.NoClassDefFoundError: javax/faces/application/Application -->
  <dependency>
    <groupId>javax.faces</groupId>
    <artifactId>jsf-api</artifactId>
    <version>1.2_09</version>
    <scope>test</scope>
  </dependency>

  <!-- java.lang.NoClassDefFoundError: org/jboss/el/ExpressionFactoryImpl -->
  <dependency>
    <groupId>org.jboss.el</groupId>
    <artifactId>jboss-el</artifactId>
    <version>1.0_02.CR4</version>    <!-- http://seamframework.org/Community/IllegalAccessErrorAfterUpgradingTo212CR1 -->
    <scope>test</scope>
  </dependency>

  <!-- dependencies related to TestNG -->
  <dependency>
    <groupId>org.testng</groupId>
    <artifactId>testng</artifactId>
    <version>5.8</version>
    <classifier>jdk15</classifier>
    <scope>test</scope>
  </dependency>
</dependencies>
<build>
  <testResources>
    <testResource>
      <directory>src/test/resources</directory>
      <filtering>true</filtering>
    </testResource>
    <testResource>
      <directory>src/test/bootstrap</directory>
      <filtering>false</filtering>
    </testResource>
    <testResource>
      <directory>src/test/bootstrap</directory>
      <filtering>true</filtering>
      <includes>
        <include>**/*.xml</include>
      </includes>
    </testResource>
  </testResources>
  ...
</build>

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<Person> fans = (List<Person>) 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 :

<build>
  ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.4.3</version>
    <configuration>
      <systemProperties>
        <property>
          <name>datasourceJndiName</name>
          <value>java:/DefaultDS</value>
        </property>
        <property>
          <name>database</name>
          <value>HSQL</value>
        </property>
      </systemProperties>
      <argLine>-Dsun.lang.ClassLoader.allowArraySyntax=true</argLine>
    </configuration>
 ...
</build>

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 :

<build>
  ...
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-dependency-plugin</artifactId>
    <executions>
      <execution>
        <id>copy</id>
        <phase>process-test-resources</phase>
        <goals>
          <goal>copy</goal>
        </goals>
        <configuration>
          <artifactItems>
            <artifactItem>
              <groupId>...</groupId>
              <artifactId>...</artifactId>
              <version>...</version>
              <type>...</type>
              <classifier>...</classifier>
              <overWrite>false</overWrite>
              <outputDirectory>${project.build.directory}/test-classes/deploy</outputDirectory>
            </artifactItem>
          </artifactItems>
        </configuration>
      </execution>
    </executions>
  </plugin>
  ...
</build>

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

Création de l’intercepteur : c’est un EJB standard avec une méthode public annotée avec @AroundInvoke.

public @Stateless class LoggerServiceBean implements LoggerService {
    @AroundInvoke
    public Object c(InvocationContext ctx) throws Exception {
        // Affiche le nom de la méthode
        System.out.println(ctx.getMethod().toGenericString());
        // Liste les paramètres passés à la méthode
        for (int i = 0; i < ctx.getParameters().length; i++) {
            if (i != 0) {
                System.out.print(",");
            }
            System.out.print("parameter " + i +" : " + ctx.getParameters()[i]);
        }
        System.out.println();
        return ctx.proceed(); //Exécute de la méthode
    }
}

Comme vous pouvez le voir, c’est l’objet InvocationContext qui va vous permettre de visualiser la méthode et les paramètres utilisés.

Déclaration de l’EJB en tant qu’intercepteur : ajouter ces quelques lignes dans le fichier META-INF/ejb-jar.xml :

<?xml version="1.0" encoding="UTF-8"?>
<ejb-jar xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
        http://java.sun.com/xml/ns/javaee/ejb-jar_3_0.xsd"
    version="3.0">

  <interceptors>
    <interceptor>
      <interceptor-class>org.everythingiswrong.tutorial.interceptor_openejb.interceptor.LoggerServiceBean</interceptor-class>
    </interceptor>
  </interceptors>

  <assembly-descriptor>
    <interceptor-binding>
      <ejb-name>*</ejb-name>
      <interceptor-class>org.everythingiswrong.tutorial.interceptor_openejb.interceptor.LoggerServiceBean</interceptor-class>
    </interceptor-binding>
  </assembly-descriptor>

</ejb-jar>

Voici l’adresse SVN du projet : https://subversion.assembla.com/svn/everythingiswrong/tutorial-interceptor-openejb

<bean name="" class="org.jboss.ejb3.embedded.JndiBinder">
    <property name="target">La valeur de la variable</property>
    <property name="bindTo">variableName</property>
    <property name="serializable">true</property>
</bean>

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.

Principe de fonctionnement

Lorsqu’un serveur d’application reçoit à une demande cliente (HTTP, RMI, etc.), il utilise une thread pour y répondre puis la libère à la fin du traitement. Vous pouvez vérifier ce comportement avec une requête HTTP ou bien un MBean. Pour visualiser les threads dans les log il faut paramétrer le PatternLayout Log4J avec %t. Lorsque toutes les threads sont occupées, le serveur ne peut plus répondre aux demandes clientes.

Pour information, sur un serveur d’application, le nombre de thread est limité mais configurable. Par exemple, le nombre maximum de threads sur JBoss est de 100 par défaut.

Traitements longs

Dans un serveur d’application, certaines ressources ont une durée de vie ou d’activité limitée. Par exemple, une transaction sur une base de données ne peut pas excéder 5 minutes par défaut sur une serveur JBoss sous peine de provoquer l’exception suivante :

Transaction is not active: tx=TransactionImple < ac, BasicAction: -3f57f10b:911:49fb4a4b:3e status: ActionStatus.ABORT_ONLY >; - nested throwable: (javax.resource.ResourceException: Transaction is not active: tx=TransactionImple < ac, BasicAction: -3f57f10b:911:49fb4a4b:3e status: ActionStatus.ABORT_ONLY >)

La seule solution est de découper son traitement en plusieurs traitements plus petit ou de modifier le timeout. Dans ce dernier cas, il faut faire attention car un timeout top grand peut avoir des effets néfastes sur les performances de l’application. Voici comment gérer les démarcations de transaction pour découper un traitement long en plusieurs petits traitements :

Client (sans transaction) -> EJB (transaction supportée : TransactionAttributeType.SUPPORTS) -> EJBs (nouvelle transaction pour chaque appel EJB : TransactionAttributeType.REQUIRED ou TransactionAttributeType.REQUIRES_NEW)

Dissociation entre le web et les traitements lourds

Après avoir vu le principe de fonctionnement d’un serveur d’application et comment développer un traitement long sans provoquer d’exception de timeout, il ne faut pas oublier qu’une application web peut être utilisée par un grand nombre d’utilisateurs. Si les requêtes HTTP provoquent des traitements longs cela peut rapidement provoquer une indisponibilité du serveur.

Une des solutions possibles est d’utiliser deux serveurs d’applications différents : un serveur d’application pour les traitements lourds et un pour l’IHM. Les échanges entre ces deux serveurs doivent se faire en asynchrone pour ne pas pénaliser la partie web de l’application. Ainsi une augmentation du nombre d’utilisateur n’impactera pas votre application, à moins de mal configurer le serveur s’occupant de l’IHM.

Au final, tout n’est qu’une question de paramétrage des serveurs. Il ne faut pas oublier qu’avec un serveur d’application le clustering est toujours possible, et dans ce cas, le nombre de threads disponibles pour traiter les demandes augment lui aussi.

Vous pouvez utiliser le serveur d’application pour exécuter seulement des batchs. il faut alors vous assurer que le nombre de threads disponibles sur le serveur soit assez grand et que vos traitements successifs n’engendrent pas de problèmes de mémoire ou de réservation de ressources, car votre serveur ne sera pas réinitialisé au début de chaque traitement.

Cas du conteneur embarqué

Si vous préférez avoir une JVM par traitement et donc une architecture plus proche d’un batch classique, des conteneurs embarqués sont désormais disponibles et ils fonctionnent très bien. J’ai déjà testé openEJB et JBossEmbedded, glassfish, etc. je n’ai jamais remarqué de problème sur leur utilisation. De plus, dans ce cas, comme il y a une JVM non partagée par traitement, les problèmes de disponibilités lié à l’utilisation de thread n’existe plus. J’ajouterai que l’utilisation d’un conteneur embarqué est très simple, voici un exemple avec openEJB :

Créer un project maven avec l’archetype quickstart et ajouter openEJB dans les dépendances. Voici l’allure du fichier POM :

    <dependencies>
        <dependency>
            <groupId>org.apache.openejb</groupId>
            <artifactId>openejb-core</artifactId>
            <version>3.1.2</version>
                <exclusions>
                    <exclusion>
                        <groupId>org.apache.activemq</groupId>
                        <artifactId>activeio-core</artifactId>
                    </exclusion>
                </exclusions>
        </dependency>
    </dependencies>

L’exclusion d’activeMq est nécessaire car l’artefact n’existe pas sur le repository maven. L’étape suivante est de rajouter deux fichiers de configuration : jndi.properties avec la ligne

java.naming.factory.initial = org.apache.openejb.client.LocalInitialContextFactory

et un fichier “vide” META-INF/ejb-jar.xml qui ne contient que la ligne :

<ejb-jar/>

Ce fichier XML vide indique au conteneur de rechercher les EJBs présents dans le classpath. Le serveur embarqué se démarre et déploie les  services EJB tout seul et vous n’avez plus qu’a les appeler :

    public class App {
       public static void main( String[] args ) {
          try {
             Context context = new InitialContext();
             HelloWorldService helloWorldService =
                (HelloWorldService) context.lookup("HelloWorldServiceHandlerLocal");
             System.out.println(helloWorldService.sayHello("Smith"));
          } catch (NamingException e) {
             // TODO Auto-generated catch block
             e.printStackTrace();
          }
    }
}

Pour plus de précisions, voici l’URL où vous pouvez retrouver mon exemple : https://subversion.assembla.com/svn/everythingiswrong/tutorial-embedded-openejb/

Conclusion

Pour conclure cet article, je dirais qu’utiliser un serveur d’application pour ses batchs ou traitements longs est très intéressant car cela vous permet de disposer de la stack Java J2EE. Cela peut  éventuellement vous permettre de mutualiser du code entre traitement batch et IHM, si vous avez une application qui nécessite les deux. Si l’utilisation d’un “vrai” serveur d’application vous fait peur, il est toujours possible d’utiliser un conteneur embarqué pour bénéficier, là aussi, de la stack logiciel fournie par Java J2EE.

Les traitements longs sur les serveurs d’applications J2EE ne sont donc qu’une question de paramétrage. Ils ne sont pas à proscrire, surtout si vous utilisez un conteneur embarqué.

Pour ceux qui ne sont toujours pas convaincus, voici 4 articles intéressants sur les batchs J2EE et le multithreading dans un serveur J2EE :

• http://javablog.franksalinas.net/2009/03/01/the-ejb-specification-concurrency-and-batch-processing/
• http://www.javaworld.com/javaworld/jw-07-2003/jw-0718-mdb.html?page=1
• http://java.sys-con.com/node/415321
• http://www.devx.com/java/article/20791