Je ne vais pas m’étendre sur la première partie présentée par Erwan Alliaume et Cyrille Le Clerc de Xebia ainsi que Jean-Michel Bea de FastConnect, le touilleur a encore une fois fait un bon résumé. La session était dense mais très intéressante.

Javarebel

Je vais m’attarder un peu plus sur la deuxième partie (qui n’a duré qu’une demi heure) dont le sujet me correspond plus : la productivité des développements avec JavaRebel. C’est Toomas Römer de ZeroTurnaround qui nous présente l’outil.

La démo de l’outil est toujours aussi bluffante (dispo ici et là), d’autant que pressé par le temps, Toomas l’a déroulé assez vite, ajoutant du punch à la démo :

• Modification d’une jsp => rafraichissement instantané de la page web
• Modification d’un validator => rafraichissement instantané de la page web
• Ajout de méthode, de paramètres => rafraichissement instantané de la page web
• Ajout d’un bean spring et d’une jsp => rafraichissement instantané de la page web

Aucun repackaging, aucun redéploiement, aucune perte de temps ! C’est l’objectif de Javarebel : éviter de devoir recompiler, retester, repackager et surtout redéployer l’application à chaque modification du code.

La démo nous laisse à penser : « mais comment j’arrive à supporter mes builds Maven de plusieurs minutes ? » Probablement parce qu’on n’a pas goûté à ce plaisir…

A la fin de la session, on a le droit à une question intéressante qui est de savoir s’il (Toomas ndlr) n’avait pas peur que les développeurs ne prennent plus le temps de réfléchir à leur code (modélisation, archi…) mais se contentent de coder / tester / coder… pour se rendre compte au bout de plusieurs heures que leur code n’est pas bon. Ce à quoi Toomas a répondu que l’outil était là pour éviter de perdre du temps au redéploiement (10 minutes par ci, 10 minutes par là) et ne devait pas changer la manière dont travaillent les développeurs. Et Antonio d’ajouter qu’on ne pourrait plus prendre autant de pauses cafés !

A l’issue de la présentation, en discutant avec Erwan (qui avait blogué sur le sujet), il s’avère que l’outil n’est pas tout à fait aussi magique, tou au mions pas tout le temps. Notamment sur un gros projet, Javarebel rame et finit même par planter. Je présume qu’il doit bien s’appliquer sur des appli webs relativement simples.

En tout cas je suis persuadé que la démo plus quelques chiffres pourraient convaincre quelques managers de l’intérêt de l’outil.
Pensez donc : 10 développeurs qui redéploiement environ 10 fois par jours au prix de 5 minutes à chaque fois (maven + serveur d’app) : 500 minutes (8h), soit 1j.h perdu par jour ! Au regard du prix de la license (150 $ pour une entreprise), ca donne à réfléchir !

Le besoin est simple : avoir une application java client lourd avec un système d’authentification Single Sign On basé sur Kerberos et Active Directory. On se base donc sur l’infrastructure Microsoft (AD, Windows qui utilise Kerberos pour l’authentification depuis la version 2000) et la sécurité java (JAAS).

Présentation des intervenants

Kerberos

Kerberos vient du grec et signifie « Cerbère », le chien à trois têtes gardien de la porte des enfers (mythologie grecque), joliment trouvé pour un protocole d’authentification ! Je ne rentrerai pas dans les détails du protocol, wikipedia le décrivant mieux que moi. Sachez simplement que le protocole est basé sur une notion de tickets et qu’une fois authentifié sur votre poste via l’AD, vous disposez d’un ticket que nous allons pouvoir réutiliser pour vous authentifier sur d’autres applications / serveurs…

JAAS

Java Authentication and Authorization Service (JAAS pour les intimes) est l’API sécurité de java. Elle fournit comme son nom l’indique des mécanismes d’authentification et d’habilitation. Nous allons nous concentrer sur la partie authentification. Je vous recommande vivement ce pdf si vous souhaitez une description claire et complète sur l’authent (en tout 10 documents expliquent en long en large et en travers l’API JAAS : très enrichissant).

Mise en place

LoginContext, LoginModule, CallBackHandler…

Si vous avez lu les documents que je citais ci-dessus, passez à la partie suivante. Sinon, voilà un petit résumé des classes dont nous allons avoir besoin :

• LoginContext : cette classe est la classe principale permettant d’authentifier un utilisateur (méthode login). Elle est indépendante du mécanisme d’authentification car elle s’appuie sur des LoginModule qui, eux, varient en fonction de la technologie sous-jacente.
• LoginModule : Il s’agit d’une interface que les différents mécanismes d’authentification (Ldap, Kerberos, …) doivent implémenter pour authentifier un utilisateur (méthode login également).
• CallBackHandler : Le CallbackHandler est une interface dont votre propre implémentation doit être passée au LoginModule utilisé. Il permet d’interagir avec l’application pour récupérer les crédentials de l’utilisateur (par exemple récupérer le login/password au travers d’une interface graphique ou d’un prompt…).

Typiquement vous aurez :

LoginContext lc = new LoginContext("MyLoginModuleName", new MyCallbackHandler(...));
try {
   lc.login();
} catch (LoginException le) {
  // do what you want
}

Lorsque le LoginContext est instancié, il va récupérer le(s) LoginModule(s) (classe d’implémentation + paramètres) correspondant au nom « MyLoginModuleName » dans un fichier de configuration. Il l’initialise.
Lorsque le login est fait, le context parcours tous les modules associés et effectue un login dans chacun d’eux. Si le module en a besoin, il fera appel au CallbackHandler associé pour récupérer les credentials et faire l’authentification.

Je vais entrer dans les détails dans la partie suivante.

Dans le vif du sujet

Configuration de JAAS

On commence par créer un fichier jaas.conf dont on référence le chemin avec la propriété java.security.auth.login.config (par exemple en lançant l’application avec java -Djava.security.auth.login.config=path/to/config ou System.setProperty(java.security.auth.login.config, "path/to/config")).

Voilà le contenu de ce fichier :

KerberosSecurityAuthSSO {
  com.sun.security.auth.module.Krb5LoginModule required useTicketCache="true" debug="false";
};

KerberosSecurityAuth {
  com.sun.security.auth.module.Krb5LoginModule required useTicketCache="false" debug="false";
};

KerberosSecurityAuth[SSO] étant les noms des modules que l’on utilisera lorsqu’on déclarera notre LoginContext.

Krb5LoginModule étant l’implémentation choisie (dans notre cas Kerberos 5). Il est possible de mettre plusieurs implémentations pour un même module, par exemple en plus du Kerberos, on aurait pu mettre du Ldap (avec LdapLoginModule)

Suivent ensuite les options :

• required permet de préciser que le module est requis pour l’authentification.
• useTicketCache permet de préciser qu’on souhaite réutiliser le TGT kerberos, donc lorsqu’on le set à true, on peut espérer avoir du SSO.
• debug permet comme son nom l’indique de fournir des traces de l’authentification.
• … de nombreuses autres options sont dispo et documentées ici.

Configuration de kerberos

De même que jaas, on a besoin d’un fichier de configuration pour kerberos. On créé donc un fichier krb5.conf dont on référence le chemin avec la propriété java.security.krb5.conf. Si cette propriété n’est pas mise, il ira dans java-home/lib/security puis dans divers répertoires du système s’il ne trouve pas.

Ce fichier contient :

[libdefaults] default_realm = MYDOMAIN.FR dns_fallback dns_lookup_kdc dns_lookup_realm [realms] MYDOMAIN.FR = { kdc = mydomain.fr }

C’est donc là que vous référencez votre domaine AD (ou plusieurs) et le(s) kdc associé(s).

Authentification SSO

On va maintenant arrêter de jouer avec les fichiers de configuration et coder un peu.

// cas SSO : utilisation du module KerberosSecurityAuthSSO
LoginContext lc = new LoginContext(“KerberosSecurityAuthSSO”, new SiouxCallbackHandler());
// cas non SSO : utilisation du module KerberosSecurityAuth
// LoginContext lc = new LoginContext(“KerberosSecurityAuth”, new SiouxCallbackHandler());

try {
  // authentification
  lc.login();

  // recuperation du Subject
  Subject subject = lc.getSubject();

  // recuperation du Principal
  Iterator it = subject.getPrincipals().iterator();
  Principal pr = null;
  while (it.hasNext()) {
    pr = (Principal) it.next();
  }

  // on retourne le nom du principal (login@domaine)
  if (pr != null) {
    return pr.getName();
  }
  return null;

} catch (LoginException le) {
  // ...
}

Le CallbackHandler ne devrait pas être utilisé dans ce cas. Étant donné que l’on récupère le ticket Kerberos, le LoginModule n’en a pas besoin puisqu’il a déjà les credentials.

Authentification non SSO

Si par contre nous avions utilisé le module « KerberosSecurityAuth » (avec useTicketCache=false), le module va avoir besoin du SiouxCallbackHandler que voilà :

public class SiouxCallbackHandler implements CallbackHandler {

  public SiouxCallbackHandler (/* parametres... */) {
    /* init ... */
  }

  public void handle(Callback[] callbacks) throws IOException, UnsupportedCallbackException {
    String username;
    String domain;
    String password;

    // Affichage d'une boite de dialogue ...
    SecurityLoginDialog loginDialog = new SecurityLoginDialog();
    loginDialog.pack();
    loginDialog.setVisible(true);

    // ... pour récupérer le user, domaine et password
    username = loginDialog.getUser();
    password = loginDialog.getPassword();
    domain = loginDialog.getDomain();

    // On met à jour les callbacks avec les infos récupérées (login@domain et password)
    for (int i = 0; i < callbacks.length; i++) {
      Callback cb = callbacks[i];
      if (cb instanceof NameCallback) {
        username = username.concat("@");
        username = username.concat(domain);
        ((NameCallback) cb).setName(username);
      } else if (cb instanceof PasswordCallback) {
        // password is a char[]
        ((PasswordCallback) cb).setPassword(password.toCharArray());
      } else {
        throw new UnsupportedCallbackException(cb, "Unrecognized Callback");
      }
    }
  }
}

Ainsi le Krb5LoginModule aura les credentials dont il a besoin pour effectuer l'authentification (Aucun mot de passe ne circule en clair sur le réseau, de par l'utilisation de Kerberos et non LDAP).

Conclusion

Il y a pas mal de documentation autour de ces sujets (cf. les divers liens de l'article) et moyen de faire beaucoup plus que ce que j'ai montré. Mon exemple est relativement simple et vous fournira les bases d'une application sécurisée avec Kerberos (SSO ou non).
Un document de sun complète mon article avec l'utilisation de GSS-Api pour faire de la délégation de credentials et donc appeler des services avec son compte sans ré-authentification.

Jakarta Commons-logging (JCL) est une couche d’abstraction permettant d’utiliser n’importe quel mécanisme de log (java.util.logging, log4j) sans utiliser directement leur implémentation. Cela permet donc de changer de framework de log sans impacter toute l’application. Seulement, change-t-on vraiment de framework de log tous les quatre matins ? On utilise généralement log4j, qui est très complet et fait très bien ce qu’il a à faire et jamais on n’en change !

Surconception
Petit aparté sur la surconception. On a souvent tendance à mettre en place des couches d’abstraction « au cas où ». JCL au cas où on changerait de framework de log, des interfaces à tout va au cas où on ajouterait une nouvelle implémentation, la séparation jar/war au cas où on ferait une nouvelle IHM…
Ne pourrait-on pas se contenter du nécessaire et abstraire le jour où on en aura vraiment besoin ?
Pour ceux qui ne connaissent pas le Test Driven Development (TDD), voilà les règles que la méthode énonce :

• On écrit le(s) test(s) qui vérifie(nt) la fonctionnalité (et qui échoue vu que la fonctionnalité n’est pas encore implémentée).
• On écrit le code le plus simple possible qui fait passer le test. Pas de superflu, juste le nécessaire !
• On itère sur les deux étapes précédentes pour ajouter d’autres fonctionnalités.
• On refactor le code lorsque cela devient nécessaire. C’est à ce moment que l’on se pose la question des interfaces, des couches d’abstractions…

L’utilisation de JCL m’a posé pas mal de problème sur WAS et aux vues des nombreuses plaintes à ce sujet, je ne pense pas être le seul. Effectivement, WAS embarque sa propre version de JCL et gère le chargement des classes (classloader) différemment des autres serveurs d’application, à savoir les classes de WAS avant celles de l’application (PARENT FIRST). Résultat : des « ClassCastException », des « NoClassDefFoundError », des « NoSuchMethodException », …
Un très bon article, même s’il est un peu ancien, décrit bien ce problème. Plusieurs solutions existent pour pallier à ça et notamment celles qui m’avaient servit à l’époque sur WAS 5.1. Je vous laisse lire ce document IBM pour les détails.

Comme je le disais plus haut, la solution la plus simple est encore de ne pas l’utiliser quand on en n’a pas besoin. Dans le cas contraire, je vous conseille de regarder du côté de SLF4J.

SLF4J

Simple Logging Facade for Java (SL4J) est comme son nom l’indique une couche d’abstraction simple, pour faire comme ce bon vieux JCL… mais sans les problèmes de classloader. Comment ?
Tout simplement parce que contrairement à JCL qui charge dynamiquement à l’exécution l’implémentation (log4j, java.util), SLF4J le fait à la compilation et manuellement, en fonction de l’implémentation choisie (jar).

Exemple : Vous fournissez une api quelconque dans laquelle vous loggez des informations. Pour ce faire, vous avez besoin du jar de SLF4J slf4j-api-x.x.x.jar, et des différents adapteurs des frameworks (log4j : slf4j-log4j12-x.x.x.jar, java.util : slf4j-jdk14-x.x.x.jar) que les projets vous utilisant manipulent :

Simple d’utilisation :

Plus de problème de classloading, vous fournissez tous les adapters disponibles (relativement légers : moins de 20 ko) et les projets utilisent leur framework de log préférés (log4j, java.util ou le plus récent logback qui apporte nativement l’adapteur SLF4J).

Conclusion

Pas sûr que les problèmes de classloading soient encore d’actualité sur les versions récentes de WAS, il n’empêche que JCL est vieillissant et quand on a degusté ces problèmes, on n’a plus envie de tenter le diable.
Au delà de sa simplicité et de la disparition du problème de classpath, SLF4J apporte un peu de fraîcheur (cf. exemple ci-dessus), alors n’hésitez plus, simplifiez vous la vie !

Depuis la nuit des temps

J’exagère un peu mais depuis qu’on développe des applications JEE, on doit gérer différents environnements :

• Le poste de travail du développeur
• Le serveur d’assemblage
• Le serveur de pré-prod
• Le serveur de prod
• … et parfois d’autres intermédiaires

La plupart du temps, on maintenait plusieurs fichiers properties et au moment de générer le package, c’était la galère : on prenait le bon fichier (« quel environnement je livre déjà ?« ), on le copiait dans le bon répertoire (« euh, quel environnement j’ai dit ?« ). Avec Ant, on s’en sortait plus ou moins automatiquement mais au prix de nombreuses lignes d’XML!

Maven est arrivé…

… sans s’presser ! Et surtout sans rien révolutionner. Du moins dans les premiers temps car on refaisait avec Maven 1 (à coup de scripts jelly) ce qu’on faisait avant avec Ant. Mais l’arrivée des profiles a changé la donne !

Profiles et ressources

Je ne vais pas refaire le chapitre 11 de l’excellent livre de sonatype ni reprendre la doc Maven à 0 mais pour résumer, il est possible d’avoir différent profils, qui comme leurs noms l’indiquent, permettent de définir plusieurs configurations et donc de gérer plusieurs environnements. Pour chaque profile, on peut définir des dépendances particulières, des plugins particuliers … mais surtout un build particulier et notamment les ressources (voir ici pour le détail du contenu de la balise profiles).

Le plus simple pour comprendre est encore de prendre un exemple :

<project>
  [...]
  <profiles>
    <profile>
      <id>dev</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
      <build>
        <resources>
          <resource>
            <directory>${basedir}/src/main/resources_dev</directory>
          <resource>
        </resources>
        [...]
      </build>
      [...]
    </profile>
    <profile>
      <id>prod</id>
      <build>
        <resources>
          <resource>
            <directory>${basedir}/src/main/resources_prod</directory>
          <resource>
        </resources>
        [...]
      </build>
      [...]
    </profile>
  </profiles>
</project>

pom.xml

Et on a donc une arborescence qui ressemble à ça :

Javasioux
|
\- src
    |
    \- main
        |
        \- resources
        |    \- common.properties
        \- resources_dev
        |    \- specific.properties
        \- resources_prod
             \- specific.properties

Ainsi, sur votre poste de travail, vous n’aurez qu’à faire : mvn package pour que Maven sélectionne (par défaut : activeByDefault) le profile de dev et donc avoir en sortie les fichiers common.properties (qui provient par convention du répertoire src/main/resources) et specific.properties provenant du répertoire src/main/resources_dev.

Ensuite, lorsque vous devrez livrer votre application, vous devrez sélectionner le profile de prod et donc exécuter mvn package -Pprod. En sortie, vous aurez toujours votre common.properties, mais par contre vous aurez le specific provenant de src/main/resources_prod.

Avantage : On peut sélectionner différents fichiers de configuration en fonction de l’environnement sur lequel on veut déployer.

Inconvénients :

• Lorsque vous aurez fait vos tests sur un environnement donné (préprod par exemple) avec votre fichier « specific » de préprod, vous devrez faire un nouveau package avec votre fichier « specific » de prod. Vous ne constatez pas un problème ? Effectivement, l’application testée et validée en préprod n’est pas la même que vous livrez en prod, et donc vous n’êtes pas sûr qu’elle fonctionnera !
• Il faut maintenir plusieurs fichiers et ne pas oublier d’ajouter les variables dans chacun d’eux.
• La configuration est faite en dur dans vos fichiers. Par conséquent vous devez connaître chacun des environnements. Hors, il est rare de connaître les paramètres de la base de donnée de production…

Profiles et filtres

Il s’agit là encore d’une nouvelle possibilité bien pratique de Maven, filtrer les différentes propriétés de vos ressources. En clair, vous avez :

• Un fichier properties, un fichier xml, peu importe tant qu’il se situe dans un répertoire de ressources référencé dans le pom (src/main/resources par défaut).
• Dans ce fichier de configuration quelconque, vous n’utilisez pas de valeurs en dur mais des variables du style ${mavariable}.
• Et dans le pom, vous définissez les différentes valeurs possibles pour ces variables en fonction des environnements.

Exemple : je reprends l’exemple fourni par sonatype dans son livre, vous pouvez l’avoir en détail ici.

Vous avez un fichier spring qui définit une datasource, et comme je le disais des variables … variables :

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

    <bean id="someDao" class="com.example.SomeDao">
        <property name="dataSource" ref="dataSource"/>
    </bean>

    <bean id="dataSource" destroy-method="close"
             class="org.apache.commons.dbcp.BasicDataSource">
        <property name="driverClassName" value="${jdbc.driverClassName}"/>
        <property name="url" value="${jdbc.url}"/>
        <property name="username" value="${jdbc.username}"/>
        <property name="password" value="${jdbc.password}"/>
    </bean>
</beans>

Pour faire simple, ce fichier se trouve dans le répertoire par défaut src/main/resources. Et donc associé à cela, vous avez évidemment le pom.xml magique :

<project>
  [...]
  <!--
     On définit ici les valeurs par défaut des propriétés
     qui apparaîtront dans le fichier spring.
   -->
  <properties>
    <jdbc.driverClassName>com.mysql.jdbc.Driver</jdbc.driverClassName>
    <jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url>
    <jdbc.username>dev_user</jdbc.username>
    <jdbc.password>s3cr3tw0rd</jdbc.password>
  </properties>
  [...]
  <!--
    On est obligé de redéfinir la ressource car on active le filtrage.
    Cet élément est indispensable puisqu'il permet de dire à Maven
    que les ressources se trouvant dans ce répertoire doivent être
    filtrées, c'est à dire parsées pour remplacer les variables par
    des valeurs.
   -->
  <build>
    <resources>
      <resource>src/main/resources</resource>
      <filtering>true</filtering>
    </resources>
  </build>
  [...]
  <!--
    On peut ensuite définir des valeurs particulières en fonction
    d'un profile, et donc d'un environnement particulier.
   -->
  <profiles>
    <profile>
      <id>production</id>
      <properties>
        <jdbc.driverClassName>oracle.jdbc.driver.OracleDriver</jdbc.driverClassName>
        <jdbc.url>jdbc:oracle:thin:@proddb01:1521:PROD</jdbc.url>
        <jdbc.username>prod_user</jdbc.username>
        <jdbc.password>s00p3rs3cr3t</jdbc.password>
      </properties>
    </profile>
  </profiles>
</project>

Avantage par rapport à la solution précédente : On ne maintient qu’un seul fichier, tout est dans le pom.xml.

Inconvénients : Par contre, on se retrouve avec les autres problèmes : un package testé avec un profile peut ne pas marcher avec un autre profile. De même, il vous faudra connaître l’environnement pour configurer correctement l’application.

Pas mal mais pas idéal !

Les profiles, c’est pratique, ca permet de simplement gérer différents environnements (simplement mais avec pas mal de XML supplémentaire dans le pom). Le problème, nous l’avons vu, c’est que cela nécessite de connaître les environnements sur lesquels sera déployée l’application, chose relativement rare dans les grandes sociétés, ou la production gère la plupart des environnements.

Remarque : Je ne comprends pas cette page de Maven où les profiles et le plugin antrun sont décrits comme étant le moyen de gérer divers environnements. Effectivement, c’en est un, je viens de le décrire mais il y a tout de même mieux… ne serait qu’en n’utilisant pas le plugin antrun !

Retour au JEE !

Et oui, depuis tout ce temps, on avait la solution sous les yeux sans vraiment s’en servir. JEE fournit une extension pour configurer correctement votre application : Java Naming and Directory Interface (JNDI). Cette extension permet de configurer votre application directement sur le serveur d’application. Je ne vais pas entrer dans les détails de JNDI, ce n’est pas l’objet de ce billet mais sachez simplement que vous pouvez configurer une url qui pointe vers un fichier et par exemple votre ficher de configuration.

Configuration JNDI de l’application

Dans le code

Soit en standard avec le lookup :

try {
   URL configURL = (URL)initialContext.lookup("java:comp/env/url/MyAppConfig");
   InputStream inputstream = configURL.openStream();
   Properties properties = new Properties();
   properties.load(inputstream);
}
catch (Exception e) {
   // ...
}

Soit si vous utilisez spring :

<bean class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
    <property name="locations">
         <list>
                    <ref bean="appConfig" />
              [...]
             </list>
    </property>
</bean>
<bean id="appConfig" class="org.springframework.core.io.UrlResource">
    <constructor-arg ref="appConfigJndiUrlResource"/>
</bean>
<bean id="appConfigJndiUrlResource" 
      class="org.springframework.jndi.JndiObjectFactoryBean">
    <property name="jndiName" value="java:comp/env/url/MyAppConfig" />
</bean>

Descripteur de déploiement

Bien entendu on référence la ressource dans le web.xml :

<resource-ref>
       <res-ref-name>myAppConfigResource</res-ref-name>
       <res-type>java.net.URL</res-type>
       <jndi-name>java:comp/env/url/MyAppConfig</jndi-name>
</resource-ref>

Sur le serveur d’application

Tout dépend du serveur dont vous disposez mais vous n’avez qu’à configurer la resource URL url/MyAppConfig vers le fichier properties qui convient (ex : file:/usr/Websphere/6.0/config/specific.properties).

Évidemment, il faut déployer le fichier au bon endroit sur le serveur et donc le livrer avec l’application mais en dehors de l’ear ou du war et c’est là que Maven entre à nouveau en jeu !

Maven assembly

Le plugin assembly de Maven permet de générer un paquetage (pour ne pas dire package) zip, targz… regroupant un ou plusieurs packages et des fichiers divers (et notamment ceux qui nous intéressent, les properties). Encore une fois, je ne saurais vous conseiller le livre de sonatype pour les détails sur la construction d’assemblies. Ici, je vais simplement construire un zip contenant l’ear et les fichiers properties externalisés. Dans un premier temps, il faut créer un projet supplémentaire :

<project>
  [...]
  <dependencies>
    <dependency>
      <groupId>fr.javasioux</groupId>
      <artifactId>project-ear</artifactId>
      <version>1.2</version>
      <type>ear</type>
    </dependency>
  </dependencies>
 <build>
    <plugins>
      <plugin>
        <artifactId>maven-assembly-plugin</artifactId>
        <version>2.2-beta-2</version>
        <executions>
          <execution>
            <id>create-zip-package</id>
            <phase>package</phase>
            <goals>
              <goal>attached</goal>
            </goals>
            <configuration>
              <descriptor>
                  src/main/assembly/dep.xml
              </descriptor>
           </configuration>
          </execution>
        </executions>
      </plugin>
    </plugins>
  </build>
</project>

Ce pom dépend de l’ear et précise qu’il a besoin du plugin assembly et d’un fichier dep.xml décrivant comment sera fait l’assemblage :

<assembly>
  <id>project-assembly</id>
  <formats>
    <format>zip</format>
  </formats>
  <fileSets>
    <fileSet>
      <directory>../project-war/src/main/resources</directory>
      <outputDirectory>configuration</outputDirectory>
      <includes>
        <include>**/*.*</include>
      </includes>
    </fileSet>
  </fileSets>
  <dependencySets>
    <dependencySet>
      <scope>runtime</scope>
      <outputDirectory>/</outputDirectory>
      <unpack>false</unpack>
    </dependencySet>
  </dependencySets>
</assembly>

Ce petit fichier dep.xml nous dit qu’il faudra prendre les fichiers properties se trouvant dans les resources du projet war pour les mettre dans le répertoire configuration : c’est le fileSets. Il nous dit également qu’il faudra prendre les dépendances (l’ear) et le mettre à la racine sans le décompresser (remarque : unpack false est la valeur par défaut) : c’est le dependencySets.

En sortie de ce projet, après avoir saisi la commande mvn assembly:assembly, vous aurez un zip contenant l’ear à la racine et les fichiers resources dans un répertoire configuration. L’ear est donc indépendant de l’environnement, et la production se chargera de configurer les spécificités de chaque plateforme (base de données, resources spécifiques… et bien sûr le jndi qui vous permettra d’aller chercher cette configuration). Bien entendu, il faudra penser à livrer un minimum de documentation pour que la production puisse faire ce travail efficacement.

Conclusion

Maven fournit de nombreux moyens de gérer plusieurs environnements (et mes exemples étaient simples). Il faudra donc choisir celui qui s’adapte le plus à votre contexte :

• Est-ce que l’équipe de production accepte/impose les properties externalisées accessibles en JNDI ?
• Est-ce que l’équipe de production ne déploie en prod que le package testé en préprod ?
• Est-ce qu’on prend le temps d’investir dans un pom un peu plus complexe/complet mais qui nous permet de gérer efficacement les environnements ou bien on continue à la main au risque de faire des erreurs ?

A défaut d’employer Maven pour générer un package avec le plugin assembly, vous pouvez toujours utiliser JNDI et fabriquer vous même le zip avec l’ensemble des binaires et de la config.

Après, si on est dans un process d’intégration continue un peu poussé (cf. mon billet sur l’intéraction avec la production), on pourra songer à utiliser Maven, relativement agréable une fois mis en place.

Et oui, on ne peut pas simplement dire qu’on utilise une datasource XA, SQL Server doit disposer de différents éléments (notamment des procédures stockées spécifiques) pour que cela fonctionne.

• Pré-requis : SQL Serveur ne doit pas être installé sur Windows XP, des problèmes ont été rencontré sur cet OS, préférer Windows Server 2003.
• Récupérer les drivers jdbc Microsoft pour SQL Server (1.2).
• Décompresser l’archive, aller dans le répertoire xa et choisir l’architecture de la machine (x86 ou 64bits).
• Copier la dll sqljdbc_xa.dll dans le répertoire Binn de l’installation de SQL Server (ex : C:\Program Files\Microsoft SQL Server\MSSQL.2\MSSQL\Binn\).
• Exécuter le script sql (xa_install.sql). Cela va créer des procédures stockées liées à XA (notamment master..xp_sqljdbc_xa_init).
• L’utilisateur qui se connecte aux bases pour effectuer des requêtes transactionnées, typiquement l’utilisateur de votre application doit disposer du rôle SqlJDBCXAUser :

      use master
      go
      EXEC sp_grantdbaccess 'username', ' username'
      go
      EXEC sp_addrolemember \[SqlJDBCXAUser\], ' username'
      go

Configurer le DTC

Ne le prenez pas mal, mais c’est comme cela qu’il s’appelle : le Distributed Transaction Coordinator (plus communément appelé MSDTC). C’est le service qui gère les transactions distribuées (transactions entre plusieurs bases). Plusieurs choses à vérifier à ce niveau :

• Vérifier que le service est démarré. Si ce n’est pas le cas, vous risquez une erreur du genre :

Caused by: javax.transaction.xa.XAException: java.sql.SQLException: Failed to create the XA control connection. Error: xp_sqljdbc_xa_init failure, status:0 msg:*** SQLJDBC_XA DTC_ERROR Context: xa_init, state=1, StatusCode:0 (0x00000000) ***.
at com.microsoft.sqlserver.jdbc.SQLServerXAResource.start(Unknown Source)

• Il faut ensuite autoriser les transactions XA (extrait de la msdn) :

1. Dans le Panneau de configuration, ouvrez Outils d’administration, puis ouvrez Services de composants.
2. Développez Services de composants, cliquez avec le bouton droit de la souris sur Poste de travail et sélectionnez Propriétés.
3. Cliquez sur l’onglet MSDTC, puis sur Configuration de la sécurité.
4. Activez la case à cocher Transactions XA, puis cliquez sur OK. Ceci entraînera le redémarrage du service MS DTC.
5. Cliquez à nouveau sur OK pour fermer la boîte de dialogue Propriétés, puis fermez Services de composants.
6. Arrêtez puis redémarrez SQL Server afin de garantir la synchronisation avec les modifications de MS DTC.

Configurer l’application

Personnellement, j’utilise Spring 2.5 et Hibernate, mais vous pouvez travailler sur des versions antérieures, ca marchera aussi. Spring 2.5 fournit surtout des raccourcis…

Datasources

Vous déclarez vos datasources comme à votre habitude. En spring 2.5, vous pouvez simplement mettre :

<jee:jndi-lookup id="dataSource1" jndi-name="java:comp/env/jdbc/db1"/>
<jee:jndi-lookup id="dataSource2" jndi-name="java:comp/env/jdbc/db2"/>

Transaction JTA

C’est là que Spring 2.5 est intéressant car vous n’avez qu’à préciser <tx:jta-transaction-manager/> dans votre configuration spring pour qu’il se débrouille : il vérifie le type de serveur d’application dont vous disposez et choisit le transaction manager approprié. Par exemple pour Websphere, il utilisera le WebSphereUowTransactionManager. Plus de détails sur les transactions spring ici.

Configurer le serveur d’application

Au niveau du serveur d’application, vous devez configurer les ressources jndi pour les datasources. Pour ce faire, utilisez la classe com.microsoft.sqlserver.jdbc.SQLServerXADataSource. Pour le reste, c’est du standard : configurez l’url, l’utilisateur, le password…

Conclusion

Alors que côté JEE, on reste dans une configuration assez standard et simple à mettre en place, niveau base de donnée, on a pas mal de choses à faire qui ne sont pas innées et qui ne s’inventent pas.