Cet article se propose de vous montrer comment réaliser de tels tests, avec un niveau d’isolation suffisant pour la parallélisation dans un processus multithread, tout en essayant de trouver le meilleur compromis avec le temps d’exécution de chaque test. Ces tests sont présentés dans une configuration très classique utilisant Spring et JPA/Hibernate.
L’implémentation utilise une base HSQLDB et quelques bibliothèques pour faciliter l’écriture du code, en essayant de rester aussi léger que possible. Les tests sont isolés pour que vous puissiez activer l’exécution parallèle du plugin Surefire de Maven au niveau des classes de test. Vous pourrez facilement dériver l’implémentation nécessaire à isoler vos tests au niveau des méthodes si vous le souhaitez.

Introduction

Un premier réflexe est de réaliser des tests contre une base de donnée existante. L’automatisation de ces tests mène très rapidement à des problèmes de reproductibilité et d’isolation, en particulier quand les traitements testés effectuent des opérations d’écriture dans la base de données, mais également parce que la base utilisée est souvent une base de développement que les développeurs peuvent être amenés à faire évoluer de manière incontrôlée. La solution immédiate est de créer une copie du jeu de données initial et de le recharger dans la base avant chaque test. Cette problématique, et sa conséquence, la gestion des jeux de données ont amené la création d’outils tels que DBUnit.

L’utilisation d’une base de données centralisée, même si elle est spécifique aux tests, amène son propre lot de problèmes : que se passe-t-il si plusieurs développeurs jouent leurs tests en même temps ? Les uns vont insérer leur jeu de données pendant que les autres font une écriture ; les tests ne sont pas isolés. Il faut créer une base de données par développeur.

Deux options s’offrent alors, la première consiste à créer un schéma pour chacun sur le serveur. Cela amène des problèmes de latences réseaux, de charge du serveur et rend impossible le travail en cas de coupure du réseau. Il vaut mieux pencher pour la seconde option et créer une instance sur la machine de chaque développeur. Comme ce sont souvent des machines de bureautique avec des disques lents, un SGBD complet qui n’est finalement presque pas utilisé et qui consomme de précieuses ressouces est mal venu, surtout lorsqu’il faut partager ces ressources avec un IDE, un serveur d’application, … Reste la possibilité d’utiliser une base de données embarquée comme HyperHSQL (HSQLDB), H2, Derby, etc. L’instance est créée par le processus du test et détruite lorsqu’il se termine. Il reste à y charger la structure des tables et le tour est joué.

Ces tests d’intégration joués séquentiellement peuvent encore s’avérer trop lent, surtout dans le cadre d’un build complet qui joue tous les tests. Il convient alors de les paralléliser.

Structure du projet

Partons d’un projet classique utilisant Spring et JPA/Hibernate, packagé avec maven. La structure de projet prend la forme suivante :

Dans le dossier main, on retrouve les entités du modèle de données, les DAOs avec respectivement une interface et une implémentation et le descripteur de l’unité de persistance JPA.

Dans le dossier test, les tests des deux DAOs, les fichiers de configuration XML Spring, un fichier de propriétés pour hsqldb et les deux jeux de données pour les tests au format XML.

Créer les tests avec spring & dbunit

Le code d’un test

AddressDaoTest.java

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"applicationContext-test.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class,
                         DataSetTestExecutionListener.class})
@DataSet(value = "AddressDaoTest.xml")
public class AddressDaoTest {
    @Autowired
    private AddressDao addressDao;
    @Test
    public void testFindByAddressname() {
        Address user = addressDao.findByAddress("a");
        assertNotNull(user);
    }
    @Test
    public void testFindByAbsentAddressname() {
        Address user = addressDao.findByAddress("c");
        assertNull(user);
    }
}

Ce test est exécuté avec SpringJunit4ClassRunner qui créé le contexte Spring avec les fichiers indiqués dans l’annotation @ContextConfiguration et le met en cache.

La mise en cache est un détail important pour l’exécution de plusieurs classes de tests. Si vous avez plusieurs classes de tests, déclarant exactement la même annotation @ContextConfiguration qui sont lancées dans un même processus, seule la première aura besoin d’initialiser le contexte Spring. Les suivantes pourront réutiliser le contexte économisant ainsi : le parsing de la configuration, le scan du classpath à la recherche d’annotations ainsi que les diverses phases d’initialisations des beans utilisés dans le contexte.

L’annotation @TestExecutionListener fournie par spring-test permet d’enregistrer des classes qui peuvent se brancher dans le cycle de vie d’exécution d’un test (before test class, before test method, …). L’utilité des listeners utilisés ici est précisée un peu plus bas.

La configuration

Notre contexte de test contient les éléments standards d’un contexte Spring JPA/Hibernate mais quelques points méritent d’être notés pour que nous puissions revenir dessus.

La déclaration de la datasource hsqldb

<bean id="dataSource" class="org.springframework.jdbc.datasource.DriverManagerDataSource">
    <property name="driverClassName" value="${ds.driver=org.hsqldb.jdbcDriver}"/>
    <property name="url" value="${ds.url=jdbc:hsqldb:mem:test}"/>
    <property name="username" value="${ds.username=sa}"/>
    <property name="password" value="${ds.password=}"/>
</bean>

La déclaration de la factory JPA/Hibernate

<bean id="jpaVendorAdapter" class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
    <property name="databasePlatform" value="${hibernate.dialect}<"/>
</bean>
<bean id="emf" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
    <property name="dataSource" ref="dataSource"/>
    <property name="persistenceUnitName" value="pdbunit"/>
    <property name="jpaVendorAdapter" ref="jpaVendorAdapter"/>
    <property name="jpaProperties">
        <props>
            <prop key="hibernate.dialect">${hibernate.dialect}</prop>
            <prop key="hibernate.hbm2ddl.auto">${hibernate.hbm2ddl.auto=update}</prop>
        </props>
    </property>
</bean>

Les listeners

DependencyInjectionTestExecutionListener

L’utilisation de ce listener défini par l’API spring-test permet simplement d’utiliser les annotations d’injection de dépendance (@Autowired,@Resource,…) sur des éléments de la classe de test. Ainsi, dans le test de DAO vu précédemment l’instance du DAO sera injectée avant l’exécution du test.

DataSetTestExecutionListener

Ce listener est défini dans l’API spring-dbunit et permet l’utilisation de l’annotation @Dataset sur une classe ou sur une méthode de test.

Cette annotation utilise dbunit pour charger un jeu de données avant chaque test et pour le supprimer après chaque test.

Par défaut, cette annotation cherche un fichier nommé dataSet.xml dans le même package que la classe de test qui porte l’annotation. Il est possible de changer le nom du fichier, d’en charger plusieurs, bref de choisir son jeu de données.

Un premier palier

À ce stade, nous avons donc des tests qui chargent leur jeu de données dans une base mémoire avant de s’exécuter. Isolés du monde extérieur ils ne risquent pas d’échouer à cause d’un changement involontaire par une autre personne, d’une perte de connexion réseau ou d’une autre exécution de la suite de test par un second développeur.

Parallèliser les tests dans maven

En l’état actuel, les tests ne peuvent pas être exécutés en multi-thread au sein d’un même processus, ce que sait faire le plugin surefire de maven en charge de l’exécution des tests. Unitairement rapides, la contrainte de les exécuter en séquentiel empêche de profiter pleinement des processeurs multi-cores des ordinateurs modernes. Les tests ne sont utiles que si ils sont exécutés et ils ne sont exécutés que si ils sont suffisamment rapides.

Une base de donnée par thread

Ce qui fait échouer l’exécution en mode multi-thread, ce sont les collisions entre les différents jeux de données manipulés par dbunit (deux jeux de données chargés en même temps peuvent modifier le résultat de certaines requêtes), sans compter les opérations d’écritures potentielles des traitements testés. Il faudrait que chaque test dispose de sa propre base de donnée.

ThreadUniqueDriverManagerDataSource

public class ThreadUniqueDriverManagerDataSource extends
  DriverManagerDataSource {
 @Override
 public String getUrl() {
  long tId = Thread.currentThread().getId();
  return super.getUrl() + tId;
 }
}

En utilisant cette surcharge de DriverManagerDataSource comme classe d’implémentation pour votre dataSource, chaque thread accédera à sa propre base de données mémoire.

<bean id="dataSource" class="fr.xebia.jdbc.datasource.ThreadUniqueDriverManagerDataSource">
    <property name="driverClassName" value="${ds.driver=org.hsqldb.jdbcDriver}"/>
    <property name="url" value="${ds.url=jdbc:hsqldb:mem:test}"/>
    <property name="username" value="${ds.username=sa}"/>
    <property name="password" value="${ds.password=}"/>
</bean>

Il reste un problème: le contexte Spring n’est chargé et initialisé qu’une seule fois, par conséquent Hibernate ne créé la structure des tables qu’une seule fois. Si nous tentions d’exécuter nos tests, le « premier » – celui dans lequel le contexte Spring est initialisé – réussirait. Les autres échoueraient en se plaignant que les tables nécessaires à l’insertion de leur jeu de données n’existent pas.

Il est possible de forcer le runner de Spring à réinitialiser un contexte pour chaque classe de test, mais cette initialisation est coûteuse et tout ce dont nous avons besoin est de créer les tables dans la base de données, tout le reste fonctionne très bien sans réinitialisation.

Recréer la structure de la base de données dans chaque thread.

Sachant que les listeners de test sont exécutés dans l’ordre de leur déclaration, il nous faut donc un listener qui soit exécuté après la création du contexte mais avant le chargement des données et qui se charge de recréer la structure. Nous avons déjà du code capable de recréer la structure dans Hibernate, il faut donc l’exécuter à nouveau pour chaque nouvelle base. La dernière donnée est le niveau de parallélisation, le maven-surefire-plugin est capable de paralléliser aux niveaux : « classes », « methods », « both ». Il faudra adapter le listener en fonction du niveau choisi.

Dans la suite nous allons chercher à exécuter le code parallélisé au niveau « classes », notre TestListener peut donc s’exécuter « beforeTestClass ».

JpaHibernateDbSetupTestListener

Le code du listener suivant est lié à l’utilisation JPA/Hibernate. Il ne devrait pas être très difficile de dériver un listener pour d’autres solutions de persistance, du moment que l’on sait créer la structure de la base de données.

public class JpaHibernateDbSetupTestListener extends AbstractTestExecutionListener {
    @Override
    public void beforeTestClass(TestContext testContext) throws Exception {
        super.beforeTestMethod(testContext);
        Map<String, EntityManagerFactoryInfo> emfsMap = testContext.getApplicationContext().getBeansOfType(
                EntityManagerFactoryInfo.class);
        for (Map.Entry<String, EntityManagerFactoryInfo> emfByName : emfsMap.entrySet()) {
            EntityManagerFactoryInfo entityManagerFactoryInfo = emfByName.getValue();
            String puName = entityManagerFactoryInfo.getPersistenceUnitInfo().getPersistenceUnitName();
            HibernatePersistenceCacheUnit persistenceInformation = HibernatePersistenceCache.getPersistenceInformation(puName);
            SchemaExport schemaExport = new SchemaExport(persistenceInformation.getHibernateConfiguration(),
                    persistenceInformation.getSettings());
            schemaExport.execute(false, true, false, false);
        }
    }
}

Cette implémentation nécessite des modifications supplémentaires à notre environnement de test. Elle repose sur la présence d’un cache des informations de persistance (HibernatePersistenceCache) dans lequel sont stockées les informations nécessaires à la recréation du SchemaExport.

Les informations de configuration manipulées par SchemaExport ne sont normalement pas accessibles une fois l’initialisation d’Hibernate terminée. Il faut donc les capturer lors de l’initialisation et les ajouter au cache. Pour cela nous allons devoir remplacer l’adaptateur Spring org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter par une implémentation maison.

public class HibernateJpaVendorParallelAdapter extends HibernateJpaVendorAdapter {
  private final PersistenceProvider persistenceProvider = new CachingHibernatePersistence();
  @Override
  public PersistenceProvider getPersistenceProvider() {
    return this.persistenceProvider;
  }
}

Le remplacement se fait dans le fichier de définition du contexte Spring, ce qui explique l’externalisation de la définition du jpaVendorAdapter :

<bean id="jpaVendorAdapter" class="fr.xebia.test.utils.parallel.jpa.hibernate.HibernateJpaVendorParallelAdapter">
        <property name="databasePlatform" value="org.hibernate.dialect.Oracle10gDialect"/>
</bean>

La capture des informations de configuration peut alors se faire dans CachingHibernatePersistence :

public class CachingHibernatePersistence extends HibernatePersistence {
  @Override
  public EntityManagerFactory createEntityManagerFactory(String persistenceUnitName, Map overridenProperties) {
    Ejb3Configuration cfg = new Ejb3Configuration();
    Ejb3Configuration configured = cfg.configure(persistenceUnitName, overridenProperties);
    cacheConfig(persistenceUnitName, null, overridenProperties, configured);
    return configured != null ? configured.buildEntityManagerFactory() : null;
  }
  @Override
  public EntityManagerFactory createContainerEntityManagerFactory(PersistenceUnitInfo info, Map map) {
    Ejb3Configuration cfg = new Ejb3Configuration();
    Ejb3Configuration configured = cfg.configure(info, map);
    cacheConfig(info.getPersistenceUnitName(),info, map, configured);
    return configured != null ? configured.buildEntityManagerFactory() : null;
  }
  private void cacheConfig(String name, PersistenceUnitInfo info, Map map, Ejb3Configuration configured) {
    if (configured != null) {
      HibernatePersistenceCacheUnit cachedInfo = new HibernatePersistenceCacheUnit(name);
      cachedInfo.setPersistenceUnitInfo(info);
      cachedInfo.setPropertyMap(map);
      cachedInfo.setHibernateConfiguration(configured.getHibernateConfiguration());
      cachedInfo.setSettings(configured.buildSettings());
      HibernatePersistenceCache.addPersistenceInformation(cachedInfo);
    }
  }
}

HibernatePersistenceCacheUnit est un simple conteneur pour les données qui nous intéressent :

public class HibernatePersistenceCacheUnit {
    private final String name;
    private PersistenceUnitInfo persistenceUnitInfo;
    private Map<String, Object> propertyMap;
    private Configuration hibernateConfiguration;
    private Settings settings;
    private SessionFactory sessionFactory;
    //...
}

et enfin le cache lui-même est une implémentation basique utilisant une simple HashMap :

public class HibernatePersistenceCache {
  private static final Map<String, HibernatePersistenceCacheUnit> persistenceInformationMap = new HashMap<String, HibernatePersistenceCacheUnit>();
  public static void addPersistenceInformation(HibernatePersistenceCacheUnit persistenceInformation) {
    assert(persistenceInformation != null);
    assert(persistenceInformation.getName() != null);
    persistenceInformationMap.put(persistenceInformation.getName(), persistenceInformation);
  }
  public static List<HibernatePersistenceCacheUnit> getPersistenceInformations() {
    return new ArrayList<HibernatePersistenceCacheUnit>(persistenceInformationMap.values());
  }
  public static void clearPersistenceInformations() {
    persistenceInformationMap.clear();
  }
  public static HibernatePersistenceCacheUnit getPersistenceInformation(String name) {
    return persistenceInformationMap.get(name);
  }
}

Il ne reste plus qu’à déclarer le listener au bon endroit dans le test :

@RunWith(SpringJUnit4ClassRunner.class)
@ContextConfiguration({"applicationContext-test.xml"})
@TestExecutionListeners({DependencyInjectionTestExecutionListener.class, JpaHibernateDbSetupTestListener.class, DataSetTestExecutionListener.class})
@DataSet(value = "AddressDaoTest.xml")
public class AddressDaoTest {
    @Autowired
    private AddressDao addressDao;
    @Test
    public void testFindByAddressname() {
        Address user = addressDao.findByAddress("a");
        assertNotNull(user);
    }
    @Test
    public void testFindByAbsentAddressname() {
        Address user = addressDao.findByAddress("c");
        assertNull(user);
    }
}

et à activer la parallélisation des tests lors de l’exécution du plugin surefire

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>2.11</version>
    <configuration>
        <parallel>classes</parallel>
    </configuration>
</plugin>

Vos tests sont maintenant suffisament isolés pour que surefire puisse exécuter vos classes de tests en multi-thread.

Autres pistes de listeners

Il existe plusieurs moyens de résoudre le problème du rechargement de la structure de la base de données dans les bases créées en mémoire. Si vous disposez d’un outil de migration comme flyway, ou que votre équipe garde scrupuleusement à jour un fichier avec la totalité de la structure de données de la base, vous pouvez créer votre propre listener pour charger la base à partir de cette référence. Vous pouvez également initialiser une base de données fichier plutôt que mémoire et en créer des copies qui seront utilisées par les différents Threads.

Des bases de données et des dialectes

Utiliser une base de donnée mémoire n’est pas complètement anodin. Chaque SGBD parle son propre ‘dialecte’ de SQL, souvent un sous-ensemble auquel peut s’ajouter des extensions spécifiques de l’éditeur.
L’idée dans cet article est de maximiser les gains obtenus en testant les commandes SQL qui sont partagées entre votre SGBD de production et la base mémoire utilisée. L’utilisation de moteurs ORM comme Hibernate tends à normaliser le sous-ensemble de commandes utilisées, ce qui facilite la compatibilité pour la plupart des requêtes. Il peut néanmoins être nécessaire d’utiliser des requêtes natives pour certaines optimisations ou pour certains cas d’utilisation spécifiques. Même comme ça, les cas d’incompatibilités peuvent être réduit par l’utilisation d’une base mémoire adaptée. Recherchez la base mémoire qui a un dialecte aussi proche que possible de celui de votre moteur de production pour pouvoir tester autant de requêtes que possible.

Le code qui malgré tout restera incompatible pourra être testé dans le cadre de tests d’acceptation sur un environnement complet. Respectez la loi de Pareto en dépensant 20% d’effort pour 80% des gains, et ne modifiez pas une requête optimisée pour votre moteur de production juste pour pouvoir la tester dans un moteur de test.

Code de l’article

Vous retrouverez sur github

• le projet de démo qui a servi de base au code de l’article
• un projet contenant l’implémentation du listener et du cache sous forme de librairie maven.

Actualité éditeurs / SSII

• Scala : la saga continue
• VMWare, Cisco et Google jouent aux marionnettes

Le coin de la technique

• Hibernate et ses performances anti-patterns
• Gitblit : le nouveau gestionnaire de repositories Git

Evénements de notre communauté en France et à l’étranger

• L’Apache Software Foundation et Subversion
• En vrac

Actualité éditeurs / SSII

Scala : la saga continue

Lors de notre précédente revue de presse nous vous avions parlé de l’article publié par Stephen Colbourne qui expliquait pourquoi il compare Scala aux EJB2. En réponse aux critiques qui l’accusaient de n’avoir pas assez utilisé Scala dans la vie réelle, il a publié un mail envoyé par Coda Hale (ingénieur infrastructure chez Yammer) à Donald Fischer (CEO de Typesafe) et Martin Odersky (créateur de Scala). Ce mail contient une série de critiques précises contre le langage (complexe, courbe d’apprentissage importante, forme idiomatique, outils de build immatures, incompatibilité des binaires entre versions majeures et des problèmes de performances de certaines formes fonctionnelles) qui ont amené Yammer à reconsidérer son utilisation.
Il s’avère ensuite que le mail est un échange privé dans lequel Coda Hale répondait à une demande de Typesafe sur les points d’amélioration possibles du langage, il avait été placé dans un gist de github pour relecture et s’est retrouvé partagé et repris par mégarde. Son contenu finit par être repris de façon générale.
Finalement, Yammer publie sa position officielle toujours par la plume de Coda Hale. Dans ce communiqué, il indique

• qu’ils suivent une philosophie très pragmatique, et qu’ils essayent de nombreux outils pour résoudre leurs problèmes.
• que tous les langages ont des défauts face aux types de problématiques rencontrées chez Yammer
• qu’ils ont construit plusieurs systèmes impressionnants avec Scala (gestion de centaines de milliers d’utilisateurs, de millions de recherches, etc avec des performance très élevées).
• que Scala est un langage encore jeune (il le compare à java 1.3) et qu’il est normal qu’il ait encore quelques bords à arrondir, que c’était justement le sens de la démarche de Typesafe.

En retrait de l’agitation, Martin Odersky adresse indirectement une partie des problèmes remontés lors de cette controverse dans un article publié sur le blog de Typesafe. Quelques points intéressants

• Support au développement avec l’annonce de la sortie en release candidate de scala IDE
• Courbe d’apprentissage réduite d’une part par l’IDE, par des sources gratuites dont un site de documentation collaboratif et pour le reste par des formations.
• Accélération du compilateur et soutient au travail accompli dans le compilateur incrémental de SBT.
• Community avec surtout le passage de Scala sous github

Il évoque également la performance, les frameworks (avec akka, et play2), les plans pour répondre aux problèmes de compatibilité binaire.

La bataille fait rage pour décider du langage qui remplacera Java sur la JVM, bataille qui ne manquera pas de s’amplifier avec les fonctionnalités annoncées pour Java 8 (Jigsaw, Lambda expressions, le reste du projet Coin, …) et l’arrivée de nouveaux challengers annoncés ces derniers temps (Kotlin et Ceylon)

VMWare, Cisco et Google jouent aux marionnettes

PuppetLabs, l’entreprise commerciale derrière l’outil Open source Puppet vient d’annoncer sur son blog que VMWare, Cisco et Google venaient de prendre des parts lors du dernier tour de table effectué par la société. En dehors du blabla marketing d’une telle annonce, il faut bien reconnaître que, comme elle le dit, ces partenaires utilisent déjà Puppet « en production et à grande échelle ». Et il est certain que cette association en jette !
En tout cas, il est certain que cette annonce se présente dans une dynamique très porteuse pour les outils de management de configuration. Avec le Cloud, la tendance à prendre en compte le Devops se confirme et c’est toute l’industrie qui va en bénéficier.
Rappelons que PuppetLabs édite aussi la solution commerciale Puppet Enterprise sortie il y a peu en version 2.0. Et pour ceux que ça intéresse, notons que ce récent article donne des pistes pour optimiser ses éditeurs texte et parle même de Geppetto, un IDE basé sur Eclipse pour Puppet.

Le coin de la technique

Hibernate et ses performances anti-patterns

Pour ceux qui n’ont pas encore vu cette présentation de Patrycja Wegrzynowic à Devoxx, Mathilde Lemée en reparle ici. Cet article détaillé revient avec des exemples précis sur des cas d’utilisation réel de l’outil. On y retrouve les exemples de N+1 SELECT, de problème de synchronisation en écriture et bien d’autres.
L’accroche de la présentation à Devoxx est simple « I do think Hibernate is a great tool ». De plus en plus de débats se lèvent sur l’utilisation de ce framework. Il est évertué par les uns pour son gain de productivité et son utilisation simple mais décrié par les autres pour les contraintes de modélisation qu’il entraîne et son côté opaque.
Lors de notre dernier XKE (Xebia Knowledge Exchange), nous avons eu la chance d’assister à une présentation de David Gageot sur la notion d’outil et de framework. Lors de cette session, il a codé sous nos yeux une application Web simple, sans utiliser de grand framework. L’idée était de nous amener à nous poser les bonnes questions face aux outils que nous utilisons tous les jours:

• En ai-je vraiment besoin ?
• A quoi sert-il vraiment ?
• Son utilisation m’amène-t-elle plus de valeurs ajoutées que de contraintes ?

L’idée directrice de David était de nous montrer que nous ne sommes pas obligés d’utiliser des outils très imposants pour des tâches très simples.
Un outil, à la différence d’un framework, n’imposera que peu de contraintes à son utilisateur. Il restreint son périmètre d’utilisation pour être « expert » dans une tâche bien précise. L’avantage cependant d’un framework est d’offrir des guides d’utilisation, afin d’assurer une homogénéité au sein de plusieurs projets.
Il faut savoir adapter l’outil à la tâche qui lui correspond. Mieux vaut utiliser des outils simples, non intrusifs pour faire correctement ce qui est demandé en se laissant la possibilité de changer plus tard.
De la même manière, Hibernate est un outil puissant, encore faut-il savoir l’utiliser correctement. Tous les cas d’utilisation n’en on pas l’utilité. Mais rappelons nous que si nous voulons l’introduire dans notre projet, apprenons d’abord à bien l’utiliser.Tout est une question d’adaptation. C’est le coeur de notre métier, comprendre le contexte pour lui apporter la meilleure réponse possible. La réponse universelle n’existe pas et c’est cela qui rend notre profession intéressante.

Gitblit : le nouveau gestionnaire de repositories Git

GitBlit est une application Web Open-Source (licence Apache Software Foundation version 2.0), reposant sur une stack pure Java, et qui a pour objectif de gérer, consulter et héberger des repositories Git. Il utilise pour cela JGit, une implémentation Java du gestionnaire de sources distribué.

L’application se présente sous deux modes :

1. Gitblit GO : une solution clé en main basée sur Jetty. Il n’est pas nécessaire d’installer un quelconque serveur Web ou même Git lui-même, c’est l’option à privilégier si l’on veut démarrer le plus simplement et rapidement possible. L’objectif de ce mode est d’obtenir un serveur fonctionnel avec un minimum de configuration. En effet, un unique fichier texte permet de configurer le serveur et Gitblit. Aussi, un certificat pour communiquer via HTTPS est automatiquement généré pour localhost et un script permet d’en générer un pour n’importe quel hostname.
2. Gitblit WAR : si vous utilisez déjà un conteneur de servlets où vous déployer vos différents outils, le mode WAR est à privilégier. Les versions 6, 7 et 8 de Jetty ainsi que les versions 6 et 7 de Tomcat sont supportées. De manière générale, n’importe quelle implémentation de Servlet 2.5 ou 3.0 devrait fonctionner.

Gitblit peut être utiliser de différentes manières :

• Comme une simple IHM Web (inspirée de Gitweb) pour consulter les repositories Git sans accès administrateur ou ou gestion de comptes utilisateurs.
• Comme une stack Git complète pour cloner, « pusher » et contrôler l’accès aux repositories.
• Gitblit peut être utiliser sans aucun outil relatif à Git (dont Git lui-même) ou il peut collaborer avec vos outils existants.

Les administrateurs peuvent gérer les repos et comptes utilisateurs soit via l’IHM Web, soit via une interface JSON RPC accessible depuis le Gitblit Manager (une IHM Swing pour gérer les repos Git et administrer un serveur Gitblit de manière distante) ou depuis un outil custom.

L’application requière au minimum un JRE/JDK 6.

Evénements de notre communauté en France et à l’étranger

L’Apache Software Foundation et Subversion

Ben Collins-Sussman, fondateur du projet Subversion et membre actuelle de l’Apache Software Foundation, vient donner son point de vue sur un débat qui fait rage : Pourquoi l’ASF choisit encore Subversion comme gestionnaire de source ?
La première réponse apportée par Jim Jagielski, un des leaders de l’ASF, est de garantir l’intégrité des projets sur le long terme et ne pas céder aux dernières modes. Ben Collins-Sussman pense lui que l’ASF est aussi présente pour fournir des protections légales face à l’utilisation des outils et d’assurer une cohérence aux long-termes et non seulement sur le software mais aussi sur les membres de la communauté.
Pour lui ce dernier point est assuré au sein de la fondation avec ces quelques mots « community over code ». Les réponses apportées aux différents problèmes des projets se font par consensus et système de vote au sein des projets.
Cet esprit de communauté et de protection légale est la raison pour laquelle Ben Collins-Sussman défend l’idée que les projets Apache doivent joindre le Grand Repository Subersion d’Apache. Mais l’utilisation de ce dépôt de source ne doit en aucun cas être unique. Certains projets pourraient selon lui utiliser Git et déposer de façon automatisée les sources au sein du Subversion d’Apache une fois par jour.
Pour reprendre le titre de son article, entrer dans une communauté, ce n’est pas être forcé d’utiliser tous ses outils.

En vrac

Sortie de Lucene 3.5.0 réduisant entre autre de façon significative la consommation mémoire lors de l’ouverture d’un IndexReader.

Sortie de ElasticSearch 0.18.5 comprenant des corrections de bugs mais surtout reprenant Lucene 3.5.0.

Sortie de Solr 3.5.0 reprenant également Lucene 3.5.0.

Sortie de SpringSource Tool Suite 2.8.1 dont le but principal est de réduire les couts de migrations de m2eclipse à m2e. Il y a d’ailleurs une FAQ intéressante sur m2e fournie par SpringSource (elle est bien sûr applicable aux utilisateurs d’Eclipse version « normale »).

La revue de presse de l’actualité Java/J2EE hebdomadaire proposée par Xebia.

Actualité éditeurs / SSII

• MySQL 5.5
• Sonar 2.4
• Hibernate Search 3.3

Le coin de la technique

• Une Refcard sur JPA2

Actualité éditeurs / SSII

MySQL 5.5

Après le rachat de MySQL en avril 2009 il y avait des craintes qu’Oracle continue à développer cette application. Cette nouvelle version 5.5 devrait rassurer (un peu) les inquiets car elle vient avec un bon nombre d’améliorations (à lire par ailleurs cette interview de Monica Kumar, d’Oracle, sur la complémentarité des deux produits). Parmi les points intéressants à noter:

• InnoDB devient le choix par défaut pour le moteur de stockage à la place de MyISAM. Ce dernier n’était pas transactionnel, entre autres défauts, et la plupart des utilisateurs changeaient leur configuration pour InnoDB.
• meilleur gestion dans l’utilisation des processeurs multi-coeurs dans le cas d’InnoDB
• amélioration des mécanismes de réplication avec à présent un heartbeat entre le maître et les esclaves ainsi qu’un envoi d’une confirmation lorsque le premier esclave a fini sa réplication (réplication semi-synchrone).
• un nouveau statement LOAD XML pour charger des données dans un fichier xml.
• il est possible à présent de plugger son système d’authentification, par exemple le LDAP de son entreprise.

Une liste plus complète des nouvelles fonctionnalités se trouve ici. Oracle estime une amélioration de 360% des performances de MySQL comparée à l’ancienne version, à prendre bien sûr avec des pincettes en fonction des différents cas d’utilisation. Sur Windows les chiffres grimpent même jusqu’à 1500% (!) de gain, cette version proposant une meilleure intégration à ce système d’exploitation. Bref cette nouvelle version semble très recommandable.

Sonar 2.4

La sortie de Sonar 2.4 le mois dernier nous avait échappé, profitons d’un rappel d’InfoQ cette semaine pour faire un tour des nouveautés:

• Régles d’architecture: une régle consiste à définir des exclusions de référence à un package. Par exemple on peut exclure les packages .web. (couche de présentation) dans les packages .dao. (couche basse d’accès aux données). On peut aussi exclure des classes de java jugés obsolètes comme Vector ou Hashtable. Parler d’architecture à ce niveau semble un peu exagérer tant les règles sont relativement simple mais ça peut aider à améliorer du code legacy.
• Personnalisation des dashboards: une vue synthétique peuvent être proposés à des chefs de projet ou des managers tandis qu’un développeur utilisera une vue détaillée qui contiendra plus de widgets par exemple. Sonar prévoit par ailleurs d’ajouter de nouvelles widget.
• Un centre de mise à jour des plugins: une page permet à présent de lister les plugins installés, de les mettre à jours, d’en installer d’autres et de vérifier s’il existe une nouvelle version de Sonar.
• Support pour Maven 3.0: cette mise à jour est appréciable. Il est à noter qu’il existe malgrès tout une incompatibilité avec Clover.

Dans ce même article, Olivier Gaudin, de l’équipe Sonar, nous informe des prochaines évolutions. Les règles d’architectures devraient se complexifier grâce à l’ajout d’un DSL permettant d’exprimer une règle comme “La couche A ne peut être utiliser que par la couche B et C”. Il identifie également 3 axes pour diminuer sa dette technique: meilleure visibilité de la dynamique d’un projet (ajout ou suppression de violations de certaines règles), une zone de partage d’information pour les revues de code et intégration d’une version légère dans Eclipse pour anticiper avant les commits les éventuelles violations.

Hibernate Search 3.3

La nouvelle version d’Hibernate Search 3.3 est disponible. Elle contient en particulier un nouveau système de requêtes DSL qui permet de faciliter l’écriture des requêtes, Martin Fowler parlera plutôt de Fluent Interface. Voici un exemple :

Query luceneQuery = mythQB.keyword()
.onField("history")
.andField("name")
.boostedTo(5)
.andField("description")
.matching("storm")
.createQuery();

Ceci allège l’écriture et devrait donc faciliter l’élaboration de requêtes plus complexes.

Sous le capot, des modifications ont été apportées sur le mécanisme d’envoi de message pour mettre à jour les indexes, améliorant ainsi les performances. De plus ces indexes peuvent également être stockés sur une grille Infinispan (qui appartient à JBoss tout comme Hibernate Search). Pour ne rien gâcher, des nouveaux indicateurs sur les statistiques sont remontés via JMX pour mieux configurer l’outil.

Enfin Hibernate Search 3.3 est compatible avec Lucene 3.0. Bien que cette dernière version de Lucene contienne des problèmes de rétro-compatibilité, Hibernate Search les masquera. Par ailleurs il supporte le nouveau type @NumericField encore expérimental dans Lucene mais qui améliore beaucoup les performances.

Le coin de la technique

Une Refcard sur JPA2

Mike Keith, un expert en persistance Java nous avait offert la Refcard « Getting started with JPA » en septembre 2008. Il vient de récidiver pour notre plus grand plaisir avec « What’s New in JPA 2.0 »
Une Refcard sur JPA est une très bonne idée, car qui n’a jamais pesté de ne pas savoir immédiatement quelles étaient les bonnes façons d’annoter ses entités. Entre les annotations provider-specific et « normalisées JPA », il y a en effet souvent de quoi se perdre. En effet, on trouve parfois des pièges comme @Mapkey par exemple qui se comporte différemment selon le fournisseur.

La première Refcard était, tout comme JPA 1, assez basique et nous rappelait des notions comme les entity managers et les transactions (container-managed ou non) ainsi qu’une petite référence JPQL pour écrire ses requêtes…
Dans la nouvelle mouture, nous retrouvons les apports de JPA2 à la persistance comme par exemple:
- la suppression des orphelins avec l’attribut orphanRemoval de @OneToMany
- les nouvelles fonctionnalités de JPQL (tiens, on peut utiliser un ‘CASE’, bon à savoir ! )
- les requêtes typées pour ceux qui veulent éviter de caster les valeurs de retour

Et pour ceux désirant renforcer au maximum le typage de leur requêtes à la compilation, les requêtes Criteria fortement typées sont évoquées:

CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery c = cb.createQuery(Account.class);
Root acct = c.from(Account.class);
c.select(acct).where(cb.equal(acct.get(Account_.name), “Jim Morrison”));
List result = em.createQuery(c).getResultList();

Certes, la façon de générer la classe du metamodèle canonique (le Account_ avec l’underscore bizarre) n’est pas évoquée et il vous faudra trouver par vous même comment la générer avec Hibernate ou avec EclipseLink. Mais le principe d’une RefCard est justement de ne pas être exhaustif, mais de donner les clefs pour un survol rapide des possibilités. Se rafraîchir ainsi la mémoire fait généralement beaucoup de bien et cette nouvelle Refcard mérite donc de rejoindre sa grande sœur et de rester en permanence à porté de main.

La couverture est large : Hibernate Core, Search, Envers, Validator et Spatial. De nombreuses démos nous ont permis de nous familiariser avec ces nouveautés liées à JPA 2.
La session était animée, comme il se doit, par Emmanuel Bernard. Le code de la session est disponible sur GitHub et ce pour encore une petite semaine.

Hibernate Core – ORM

Après quelques nouveautés, dont le support de l’annotation @MapsId de JPA 2, le partial generator (pour générer une clé selon un algorithme spécifique) et le runtime fetch profile (qui définit plusieurs stratégies de fetch), Emmanuel commence sa première démo et nous présente la nouvelle API Criteria :

• query building API orientée objet,
• type-safe,
• fortement typé,
• avec la possibilité d’utiliser le méta-modèle statique (par annotation processor).

Et c’est sur ce dernier point qu’il insistera pendant toutes ses démos. En effet l’API est construite de telle manière que nous récupérerons des erreurs compile-time si un mauvais méta-modèle ou un mauvais attribut de méta-modèle est défini.

Concrètement, le méta-modèle est généré par annotation processor. Une fois celui-ci activé dans votre IDE, chaque compilation de fichier lancera le processus de génération des méta-modèles. Par exemple, une classe User aura un méta-modèle associé User_ qui contiendra plusieurs attributs statiques reflétant les attributs de la classe. Ainsi, si un attribut change de nom, toutes les requêtes utilisant l’ancien nom seront en compilation error. Voici un exemple à partir d’une capture d’un bout de code lors de cette démo :

On remarque ainsi dans les contraintes l’utilisation de User_.credits, credits étant un attribut de la classe User. On voit dès lors l’intérêt d’un tel mécanisme qui justifie ainsi son appellation type-safe et fortement typé. En effet, sur le 3ème exemple, imaginons que l’on donne un argument autre que User_.gender mais du même type que gender ; l’API nous donnera tout de même une erreur de compilation car ce qui est attendu est un Path<Gender> qui ne peut être obtenu qu’en ayant pris en paramètre un gender. Une fonctionnalité plutôt intéressante donc mais qu’il convient mieux de voir de ses propres yeux dans un IDE pour bien comprendre la puissance de la chose.

Cette nouvelle API criteria prend en compte toutes sortes de Joins et Where, les Subquery et les Map et Like. Cette API supporte ainsi tout le JP-QL : collections, maps, aggregation, order by, group by, having count, subselect, …

Le lock mode, qui prévient entre autres des dirty reads,  supporte l’optimistic et le pessimistic read/write. Le cache de second niveau a été amélioré et Hibernate supporte aussi Infinispan. Enfin, CGLIB se retrouve déprécié et se voit remplacé par Javassist.

Côté packaging, Hibernate passe de plusieurs modules à un seul core module qui contient Hibernate Annotations, Entitymanager, Envers et l’ancien Core. De même, tous les modules auront le même numéro de version simplifiant ainsi la gestion des dépendances entre modules (si un module est en 3.6.0, les autres devront l’être aussi).

Hibernate Search

Le point important est une fois de plus l’API programmatique permettant de faire ses requêtes full text directement telles que :

Dans les petits plus : un error handling pour reporter dans un log ou dans une pile, des statistiques avancées, une indexation des valeurs null, des query timeout et bien d’autres.

Hibernate Spatial

Hibernate Spatial est une extension d’Hibernate permettant de gérer des données géographiques. Il s’appuie sur le package Java Topology Suite ou JTS pour représenter les données géographiques dans le monde Java.

Voici ce que rajoute le projet à Hibernate :

• GeometryUserType.
• SpatialRestrictions API.
• HQL Spatial functions.
• SpatialDialectProvider.

Les bases de données supportées sont les suivantes :

• Oracle Spatial.
• Postgresql/Postgis.
• MySQL.
• Microsoft SQL Server 2008.
• H2 (GeoDB).
• IBM Informatix IDS (en cours).
• IBM DB2 (à planifier).

Les spatial queries s’écrivent comme des requêtes criteria normales mais dans le monde spatial. Un exemple tiré du slide :

A noter que pour l’instant le projet est un module à part d’Hibernate 3 mais qu’il sera packagé dans Hibernate Core en version 4.

Hibernate Envers

Comme pour les autres modules, l’API programmatique est tout de suite mise en avant avec des requêtes Criteria par révision sur les objets :

Hibernate Validator

Là encore, l’API a aussi été remaniée et l’on peut ainsi appeler directement des méthodes du type .constraint(SizeDef.class).min(1) dans notre requête Criteria (équivalent de l’annotation @Min).

Conclusion

Un bon tour d’horizon des produits Hibernate mais surtout beaucoup de démos les mains dedans où l’on voit le tout fonctionner en @Inject et Weld sous IntelliJ IDEA. Une bonne session !

Actualité éditeurs / SSII

• James Gosling sur l’affaire Oracle vs Google
• ActiveMQ 5.4.0

Le coin de la technique

• Hibernate ne supporte plus CGLIB

Actualité éditeurs / SSII

James Gosling sur l’affaire Oracle vs Google

James Gosling revient sur l’épisode Oracle vs Google avec un article dans lequel il nous donne quelques éléments pour mieux comprendre la politique de Sun vis à vis de Java et des brevets :

• Sun a principalement déposé des brevets afin de se protéger d’éventuelles attaques venant de ses concurrents. Un épisode malheureux dans lequel Sun fut attaqué par IBM concernant un brevet sur les processeurs RISC leur fit prendre conscience qu’il était nécessaire de posséder un arsenal de brevets. Le procès se termina en effet en leur défaveur et ils durent payer d’importantes indemnités à IBM, les mettant au bord du dépôt de bilan.
• Les brevets sur la technologie Java et le choix de la license CDDL avaient pour but de garantir l’interopérabilité des applications java sur les différentes plateformes. Cette protection a donné lieu à un procès entre Sun et Microsoft car ce dernier avait fournit une implémentation d’un machine virtuelle Java sur laquelle le code ne s’exécutait pas de la même manière que sur les autres JVM (dont celle de Sun) qui respectaient les spécifications. La machine virtuelle java de Google présentant elle aussi des problèmes d’interopérabilité, Oracle se sert de cette jurisprudence pour les poursuivre.
• Sun aurait souhaité obtenir une partie des bénéfices générés par la plateforme Android mais sans succès. Il semble donc qu’Oracle souhaite continuer dans cette voie mais en choisissant de sortir l’artillerie lourde pour parvenir à ses fins.

Cette affaire a un effet néfaste sur l’image de Java et James Gosling, loin de cautionner l’action d’Oracle, regrette l’absence de moralité des grandes compagnies informatiques actuelles.

ActiveMQ 5.4.0

Un peu moins d’un an après la dernière release, Apache sort une nouvelle version de son broker de message. Au-delà des 283 bugs résolus, on notera quelques nouvelles fonctionnalités intéressantes:

• Priorité des messages: Jusqu’à maintenant pour jouer sur la priorité de certains messages sur d’autres il fallait contourner le problème en utilisant plusieurs queues de messages qui pouvaient être, elles, priorisées. Le point de blocage jusqu’à maintenant était lié à l’ordonnancement des messages, trop gourmand en temps. Ce problème semble être en partie réglé et le paramètre priorité du message JMS (inclus dans l’API) sera pris en compte.
• Planifier ses messages: ActiveMQ possède à présent un planificateur persistant de message. En d’autres termes, il est possible à l’envoi du message de préciser la date réelle de l’envoi et la durée entre la répétition d’un envoi. L’interface permet même de préciser tout cela sous la forme d’une entrée CRON. Ceci peut être assez intéressant pour par exemple faire du heartbeat (envoi d’un message à intervalle régulier pour s’assurer du fonctionnement de l’application ou faire des calculs de performance).
• WebSocket: Le sujet est à la mode, surtout avec l’émergence d’HTML 5, HornetQ le propose également sur sa dernière version. Il s’agit d’utiliser le broker de messages depuis du code javascript. Tout comme HornetQ, ActiveMQ utilise son protocole de message simplifié STOMP. Deux librairies javascripts sont proposées sur leur site: Stomple et stomp-websocket.

Hormis ces nouveautés, des améliorations ont été apportées sur OSGI et le shell unix.

Le coin de la technique

Hibernate ne supporte plus CGLIB

Historiquement CGLIB a rendu de nombreux services à Hibernate et Spring pour permettre de manipuler le bytecode Java. Par exemple, vous avez sans doute déjà vu passer un proxy préfixé par CGLIB lorsque vous débuggez votre application. Mais récemment, Steve Ebersole, développeur chez Hibernate, a annoncé qu’il n’y aurait plus de support pour cette librairie. Cette décision aurait été prise non pas pour des raisons purement techniques mais parce que cette librairie n’aurait plus de support et semble figée à la version 2.2 qui date de 2008. L’auteur donne pour exemple un ancien bug sur une incompatibilité de version de la librairie ASM (qui manipule à un niveau plus bas le bytecode) avec celle de Spring et qui mit un an à être corrigé.

Hibernate à présent privilégiera Javassist, un projet JBoss (tout comme Hibernate, tiens, tiens…), aux fonctionnalités similaires mais encore en vie. Reste à savoir si Spring suivra la même démarche.

La JSR-303, finalisée en novembre 2009, fournit une standardisation de ces concepts et fait partie de Java EE 6. Emmanuel Bernard étant le spec lead de cette JSR, assez naturellement l’implémentation Hibernate Validator est devenue celle de référence. C’est cette dernière qui sera exclusivement évoquée dans cet article.

Concepts de base

On étudiera dans cet article la configuration par annotations, mais il reste possible de faire l’équivalent en fichier xml.

Contraintes

Une contrainte est une restriction sur un attribut d’un bean. Beaucoup sont déjà définies dans la JSR-303, Hibernate Validator en rajoute quelques-unes très utiles et l’utilisateur peut définir les siennes comme nous le verrons plus loin.

Voici un exemple pour valider qu’un attribut est non nul :

public class Personne{
    @NotNull
    private String nom;
    ...
}

Les contraintes peuvent être posées directement sur le champ, sur la propriété par l’intermédiaire de l’accesseur ou au niveau de la classe, ce qui nécessite de définir sa propre contrainte. La visibilité du champ n’a pas d’importance car il sera introspecté par réflexion mais il ne doit pas être statique.

Un graphe d’objets peut être validé dans son ensemble, ou bien plus finement. Si une entité à valider possède une autre entité ayant des contraintes, l’annotation @Valid permet de contraindre aussi la validation de cette entité. Cerise sur le gâteau, la validation sur une collection fonctionne aussi, tous les éléments de cette collection devant être valides.

Voici les contraintes standards:

Hibernate Validator ajoute des contraintes intéressantes : @CreditCardNumber, @Email, @NotBlank, @NotEmpty, @Range, @ScriptAssert, @URL. @ScriptAssert est sans doute la plus complexe à mettre en place, elle s’appuie sur la JSR-223 qui fournit une API pour introduire les langages de script, plus de détails ici.

Service de validation

Pour valider ses entités il faut se munir tout naturellement d’un validateur, on passe pour cela par une factory fournie par l’API standard ( javax.validator ) :

ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
Validator validator = factory.getValidator();

Pour récupérer l’implémentation du validateur, l’API utilise le Service Provider de Java. Son fonctionnement est assez simple. Dans le jar contenant l’implémentation il faut ajouter dans le répertoire META-INF/services un fichier nommé javax.validation.spi.ValidationProvider qui contient le nom de la classe implémentant l’interface ValidationProvider. Pour Hibernate Validator il s’agit de la classe HibernateValidator.

Donc pour résumer, il n’y a pas de configuration à faire pour spécifier que Hibernate Validator fournira le Validator, il suffit juste d’ajouter le jar, sauf s’il existe d’autres implémentations de l’API de validation. Dans ce dernier cas, et si on veut être sûr d’utiliser Hibernate Validator, il est possible de définir le provider explicitement :

ValidatorFactory factory = Validation.byProvider(HibernateValidator.class).configure().buildValidatorFactory();

Ensuite on passe à la validation de nos entités :

Set<ConstraintViolation<Voiture>> constraintViolations = validator.validate(voiture);

On introduit ici l’objet ConstraintViolation, très riche en informations sur les raisons de la non validation d’un élément. C’est cet objet qui va par exemple nous permettre de nous fournir le message associé à l’erreur. Les méthodes de cette classe :

C’est l’occasion de remarquer que l’API de validation propose une gestion interne des ressources, on peut soit récupérer le message directement associé à une propriété ( getMessage() ) soit la clé ( getMessageTemplate() ). Dans le chapitre suivant on détaillera davantage la gestion des ressources.

On peut aussi avoir besoin de ne valider qu’une sous partie des contraintes d’une entité ou de rassembler plusieurs des contraintes de plusieurs entités. L’attribut groups des annotations de contraintes sert à ça. Elle contient une interface (ou une classe, ce qui est moins recommandé) qui sera commune aux contraintes:

public class Facture {
    @Past
    private Date dateCommande;
    @NotNull(groups=PaiementCheck.class)
    private String nomBanque;
    @CreditCardNumber(groups=PaiementCheck.class)
    private String creditCardNumber;
}
public interface PaiementCheck {}
...
    validator.validate(facture, PaiementCheck.class);
...

Gestion des ressources

A chaque type de contrainte est associé une clé, elle même liée à une propriété. Toutes les contraintes de base ont des messages déjà définis et Hibernate Validator propose même les traductions françaises. Ce message peut être surchargé directement au niveau de la contrainte:

@Min(message="ce champ doit être supérieur à {value}")

Grâce aux accolades, on peut accéder aux données de l’annotation (dans cet exemple à la valeur minimale). On peut échapper les accolades avec .

Les propriétés sont résolues par l’intermédiaire de l’interface MessageInterpolator qui, par défaut, va chercher un fichier ValidationMessages.properties à la racine du classpath. S’il n’en trouve pas à la racine il ira chercher celui dans le package org.hibernate.validator. On peut donc ainsi, facilement surcharger les propriétés de Hibernate Validator.

Il est possible d’utiliser ses propres resource bundles si on veut par exemple utiliser d’autres fichiers properties, ou les stocker ailleurs que dans le classpath. Pour cela il faut surcharger l’implémentation de ResourceBundleLocator. Ci-dessous, un exemple tiré de la documentation:

HibernateValidatorConfiguration configure = Validation.byProvider(HibernateValidator.class).configure();
ResourceBundleLocator defaultResourceBundleLocator = configure.getDefaultResourceBundleLocator();
ResourceBundleLocator myResourceBundleLocator = new MyCustomResourceBundleLocator(defaultResourceBundleLocator);
configure.messageInterpolator(new ResourceBundleMessageInterpolator(myResourceBundleLocator));

A un plus haut niveau, on peut également ne pas passer par des resource bundles mais implémenter sa propre stratégie pour, par exemple, accéder à une base de données. Pour cela il faut fournir une implémentation de l’interface MessageInterpolator.

Configuration<?> configuration = Validation.byDefaultProvider().configure();
ValidatorFactory factory = configuration
   .messageInterpolator(new MyMessageInterpolator(configuration.getDefaultMessageInterpolator()))
   .buildValidatorFactory();
Validator validator = factory.getValidator();

MyMessageInterpolator implémente donc MessageInterpolator qui a deux méthodes:

String interpolate(String messageTemplate, Context context);
String interpolate(String messageTemplate, Context context,  Locale locale);

messageTemplate étant la clé de la contrainte et context contient des informations sur cette contrainte. Libre ensuite au développeur d’associer la ressource correspondante comme il veut.

Définir sa propre contrainte

Il est possible de créer sa propre contrainte, pour cela on passe par 3 étapes:

• créer l’annotation
• implémenter le validateur
• définir le message d’erreur

Nous allons faire un validateur pour les plaques d’immatriculation et vérifier qu’elles appartiennent à un département donné (il s’agira des anciennes normes, par exemple 123-ABC-93, pas des nouvelles normes européennes). Commençons par l’annotation :

@Target({METHOD,FIELD,ANNOTATION_TYPE})
@Retention(RUNTIME)
@Constraint(validatedBy=ImmaticulationValidator.class)
@Documented
public @interface CheckImmatriculation {
   String message() default "{fr.xebia.constraints.checkimmatriculation}";
   Class<?>[] groups() default {};
   Class<? extends Payload>[] payload() default {};
   String departement();
}

On voit apparaître la notion de Payload, elle peut être utilisée pour enrichir les informations sur cette contrainte. L’exemple proposé en général est le cas où on veut ajouter un niveau de sévérité à une contrainte. On peut récupérer la classe associée dans la description de la contrainte : ConstraintViolation.getConstraintDescriptor().getPayload().

On écrit ensuite le validateur associé :

public class ImmaticulationValidator implements
       ConstraintValidator<CheckImmatriculation, String> {
   private String departement;
   public void initialize(CheckImmatriculation constraintAnnotation) {
       departement = constraintAnnotation.departement();
   }
   public boolean isValid(String value, ConstraintValidatorContext context) {
       if (!Pattern.matches("
d{1,3}-[a-zA-Z]{2,3}-
d{2}", value)) {
           return false;
       }
       // On récupère le département donné
       String d = value.substring(value.length() - 2);
       return departement.equals(d);
   }
}

Enfin on doit ajouter le message qui sera retourné en cas d’erreur dans le fichier de properties ValidationMessages.properties comme vu précédemment. On peut par exemple afficher le département attendu:

fr.xebia.constraints.checkimmatriculation=Le département doit être {departement}.

Spring/SpringMVC

Depuis la version 3.0 de Spring MVC la JSR-303 est complètement supportée. Tout est donc grandement facilité et valider un formulaire devient quasiment immédiat. On peut résumer la procédure à l’ajout de l’annotation @Valid dans la requête POST de soumission du formulaire:

public void submitVoiture(@Valid VoitureForm voiture, , Errors errors){
     logger.info("Nombre d'erreur"+errors.getErrorCount());
     ...
}

Les contraintes non validées seront automatiquement injectées dans errors et donc accessibles dans la vue :

<form:form action="edit" modelAndAttribute="voiture">
    <form:errors path="*"/>
    <form:input path="immatriculation"/>
    ...
    <input type="submit"/>
</form:form>

Outre Spring MVC, de plus en plus de frameworks de présentation adoptent la JSR-303, remplaçant leurs anciens codes spécifiques par ce nouveau standard. Naturellement JSF 2.0 l’utilise mais on peut aussi citer Wicket ou Tapestry.

Hibernate

Nous avons vu qu’il était possible de valider programmatiquement une entité. Néanmoins, on peut vouloir être encore plus prudent et empêcher les opérations de persistance si une contrainte est violée. Hibernate propose un mécanisme de listeners sur les événements insert, update et remove. Voici un exemple de configuration possible:

<persistence ...>
  <persistence-unit ...>
    ...
    <properties>
      <property name="javax.persistence.validation.mode"
                value="callback, ddl"/>
    </properties>
  </persistence-unit>
</persistence>

Il existe plusieurs modes: none, auto (s’il n’y a aucun jar de validation, il n’y aura pas de validation), callback (s’il n’y a aucun jar une exception est lancée au démarrage), ddl. Cette dernière permet de générer le schéma de base avec les contraintes définies dans l’entité.

Il est possible de différencier les comportements selon le type d’opération:

<persistence ...>
  <persistence-unit ...>
    ...
    <properties>
      <property name="javax.persistence.validation.group.pre-update"
                value="javax.validation.group.Default, com.acme.group.Strict"/>
      <property name="javax.persistence.validation.group.pre-remove"
                value="com.acme.group.OnDelete"/>
      <property name="org.hibernate.validator.group.ddl"
                value="com.acme.group.DDL"/>
    </properties>
  </persistence-unit>
</persistence>

En cas de violation d’une contrainte une exception de type ConstraintViolationException est lancée, éventuellement englobée dans une exception RollbackException en mode transactionnel. Cette exception contient la liste des ConstraintViolation de l’API Bean Validation vue plus haut.

Une fonctionnalité de l’API encore non évoquée, mais qui rejoint les problématiques souvent rencontrées dans Hibernate, est la notion de traversabilité, formalisée par l’interface TraversableResolver. Celle-ci contient deux méthodes isReachable et isCascadable qui peuvent permettre dans certains cas de désactiver une validation d’un sous-objet. Cela peut permettre lorsqu’on manipule des objets en lazy loading, de préserver ce non-chargement.

Conclusion

Bean Validation impressionne par sa vision complète des problématiques de validation, peu de cas semblent avoir été ignorés ou oubliés, et dans le cas contraire l’API est suffisamment souple pour pouvoir être étendue proprement. Certains regretteront peut-être qu’il n’y ait pas plus de contraintes pré-définies, mais il est extrêmement difficile de définir des contraintes universelles et ajouter sa propre contrainte est vraiment facile.

Actualité éditeurs / SSII

• Apache Whirr, une proposition de librairie pour le Cloud

RIA

• Où l’on reparle de JavaFX

Le coin de la technique

• Des breaks dans Scala !
• Une troisième implémentation de JPA 2 finalisée

Actualité éditeurs / SSII

Apache Whirr, une proposition de librairie pour le Cloud

Whirr est une proposal intéressante qui vient d’apparaître au sein de la fondation Apache. Il s’agit de réunir au sein de ce projet tout un ensemble de scripts et de code source permettant d’intégrer facilement des services Apache avec les fournisseurs d’infrastructures de Cloud Computing. Parmi les première applications / services dont il est question, on compte sans grande surprise Hadoop (implémentation Java du modèle MapReduce de Google), HBase (implémentation de BigTable de Google au dessus d’Hadoop), ZooKeeper (service de configuration, nommage et synchronisation pour applications distribuées, implémentation Java de Chubby de Google), et Cassandra (base de données hybride BigTable et Dynamo, initialement développée par Facebook). Ces projets ont en effet acquis une grande popularité en quelques mois et font maintenant partie des applications typiques du Cloud Computing.

La raison d’être du projet est de mutualiser les efforts fournis par ces projets pour fournir des scripts et des mécanismes d’intégration de qualité sur les plate-formes de Cloud Computing. Au-delà de ces justifications techniques, on remarquera qu’il s’agit d’une véritable reconnaissance du Cloud Computing en tant qu’enjeu d’avenir. En effet cette proposition intervient dans un contexte où les projets liés à ce sujet se multiplient au sein de la fondation Apache, puis acquièrent leur indépendance : après la promotion de Cassandra hors de l’incubateur Apache, c’est au tour de HBase d’être promu top-level project sortant donc de l’affiliation au projet Hadoop. Enfin, on notera que les acteurs impliqués dans la proposition Whirr sont majeurs : Cloudera, Twitter ou encore HP Labs.

RIA

Où l’on reparle de JavaFX

JavaFX a beaucoup fait parler d’elle après sa sortie fin 2008. Elle n’avait guère convaincu : on lui reprochait de ne pas être mature, de ne pas offrir de composants graphiques de haut niveau, de ne pas tenir ses promesses de déploiement sur plusieurs plates-formes puisqu’il n’était alors pas possible de l’utiliser sur TV et sur mobile comme cela devait être le cas.

En février 2009, la version 1.1 avait permis le déploiement des applications JavaFX sur mobile (tout du moins théoriquement). La version 1.2, sortie en juin dernier, avait été une autre étape majeure en introduisant enfin des composants graphiques évolués.

Lors de la conférence Devoxx de novembre dernier, il avait été amusant de constater que les sessions et keynotes dédiés à JavaFX, si présents lors de la précédente édition, avaient été remplacés par leurs équivalents Flex avec l’annonce en grande pompe d’Adobe Catalyst. JavaFX disparaissait peu à peu de l’actualité.

Oracle vient d’annoncer l’arrivée de la version 1.3. Les nouveautés sont incontestablement conséquentes :

• Support étendu de CSS pour le design des widgets : JavaFX supportait déjà CSS, il va maintenant plus loin dans l’intégration de ce langage de style.

• Nouveaux widgets : une liste déroulante (ChoiceBox), un champ de saisie de mots de passe (PasswordBox), une vue scrollable (ScrollView), un séparateur (Separator) et une bulle d’information (ToopTip).

• Amélioration de widgets existants : divers améliorations des composants ListView, TextBox et Slider

• Le support des TV fait enfin son apparition : les TV faisaient historiquement partie des plates-formes de déploiement possibles pour JavaFX mais n’étaient pas accessibles jusqu’alors. Un émulateur de TV vient compléter ce support.

Pour rappel, l’équipe de développement de JavaFX expliquait que leur vision était qu’après une certaine période de développement, les différentes plate-formes RIA convergeront vers un niveau de fonctionnalités similaire et que JavaFX pourrait alors briller du fait de son intégration native à Java. Cette version 1.3 semble bien une étape pour rattraper le (grand) retard face à l’environnement RIA d’Adobe en terme de fonctionnalités, il sera alors intéressant de voir si JavaFX pourra maintenant rattraper son retard en terme d’adoption.

Le coin de la technique

Des breaks dans Scala !

Avec la sortie de la RC1 de Scala 2.8.0, la communauté est en ébullition et les articles sur les nouveautés de cette release majeure affluent sur la toile.

Ainsi, Scala ayant une syntaxe très allégée par rapport à Java, certains mots clés avaient tout simplement disparu du langage pour le malheur de certains java-istes. C’est le cas de break, souvent utilisé pour, par exemple, sortir d’une boucle, qui n’était jusqu’à présent pas disponible dans Scala. Le mot clé fait ainsi son apparition dans cette version 2.8.0, non pas en tant que mot clé mais en tant que trait/object.

La syntaxe sera donc un petit peu différente par rapport à ce que nous avions l’habitude d’utiliser en Java. Il faudra ainsi englober le code pouvant être arrêté dans un breakable, l’appel à break restant le même :

// Java
for(int i=0; i<10; i++)
   if(i==5) break;
   i++;
}
//Scala
breakable {
   for(int i=0; i<10; i++)
      if(i==5) break;
      i++;
   }
}

Rendez-vous sur cette page pour télécharger cette RC1 de Scala 2.8.0 et essayer de toute urgence les breaks mais aussi les Package objects, la nouvelle API de collection, les paramètres nommés et par défaut, le tout nouveau REPL ainsi que beaucoup d’autres nouveautés !

Une troisième implémentation de JPA 2 finalisée

La communauté Java dispose maintenant d’une troisième implémentation de la JSR-317 (JPA 2.0) : OpenJPA 2.0. Ce projet de la fondation Apache est utilisé dans WebSphere AS et constitue de ce fait un choix d’implémentation pertinent.

OpenJPA succède donc à EclipseLink (qui étant l’implémentation de référence avait logiquement été finalisée en premier) et Hibernate (qui a finalisé sa version 3.5 conforme à JPA 2.0 le mois dernier).

Les nouveautés d’OpenJPA 2.0 se limitent avant tout au support de JPA 2.0 ce qui inclut :

• La nouvelle API de construction de requêtes, basée sur l’interface QueryBuilder, qui standardise et étend l’API Criteria d’Hibernate.
• L’intégration à la JSR-303 (Bean Validation) qui apporte une logique de validation uniforme pour toutes les couches d’une application JEE.
• Une API de méta-modèle permettant de naviguer par programmation dans le modèle de données d’une unité de persistance.
• Diverses améliorations des APIs JPA

JPA avait connu une très large adoption par la communauté Java, mais on lui reprochait parfois quelques manquements qui nécessitaient de recourir aux APIs propriétaires de son implémentation. Ces ajouts permettent de contourner ces limites et donc de supprimer dans la plupart des cas le recours au fameux entityManager.getDelegate().

Pour rappel, nous avions laissé notre utilisateur unique avec un temps mirobolant de 1,7 secondes par requête en moyenne.

Le tableau ci dessous montre que la concurrence est nuisible à nos temps de réponse.

La base une ressource critique.

Première amélioration, quasiment gratuite. En allant chercher dans les problèmes que nous avions mis de coté (il y a quelques semaines sur le blog, mais quelques minutes auparavant lors du Xke , nous pouvons exhumer le traçage de la totalité des requêtes SQL dans les fichiers de log. Cette fonctionnalité est bien connue des utilisateurs d’Hibernate (très pratique pour débugger), mais elle se retrouve malheureusement bien trop souvent en production.

<prop key="hibernate.show_sql">false</prop>

Il suffit alors d’une simple modification dans la configuration d’Hibernate, d’un redéploiement, et miracle, les temps s’améliorent déjà un peu.

• hibernate.show_sql à false
• Temps moyen de 8,2 s à 7,6 s pour 5 utilisateurs
• 1 point pour l’équipe qui a trouvé

Après cette correction facile, attaquons nous à plus complexe.

Si la montée en charge induit une augmentation du temps de réponse, c’est que les utilisateurs sont en concurrence sur un certain type de ressource, ou bien qu’ils mettent la machine à genoux. Un rapide coup d’oeil dans VisualVm nous montre que la CPU et la mémoire ne sont pas saturées, on a donc à faire à une contention applicative.

Celles ci peuvent être de deux types :

• une concurrence applicative, mal gérée avec les outils fournis par java.concurrent.util
• une contention sur des ressources externes, comme un pool de connexions JDBC dans une DataSource.

Comme nous étions déjà sur Hibernate dans la correction précédente, continuons à creuser le sillon. Et profitons en pour dégainer un nouvel outil de notre couteau suisse de diagnostic : JMX.
Pour vérifier si nos connexions JDBC sont bloquantes, utilisons l’api de monitoring de Java. Une fois de plus, utilisons notre VisualVm, qui propose une interface graphique d’affichage des MBeans.
Nous sommes chanceux, nos GO ont utilisé la dataSource standard de Tomcat, elle est donc exposée Catalina:type=DataSource,class=javax.sql.DataSource,name="jdbc/petclinicMySQL"

En procédant par sondage rapide (à l’aide de la fonction ‘refresh’ du MBean), on constate rapidement que les valeurs maxActive et numActive se rejoignent autour de la valeur 3. Pas la peine d’en dire beaucoup plus… Comme d’habitude, la documentation va nous confirmer ce que nous pouvions supposer à la lecture de ces valeurs. maxActive nous donne le nombre maximal de connexion JDBC, alors que numActive nous donne celles qui sont utilisées à l’instant t. Ce qui signifie que lorsque les 3 connexions sont prises, les process suivant se mettent en attente, pendant un temps fixé par maxWait soit 3 secondes. Le goulet d’étranglement est évident. Il suffit donc de le fluidifier.

Ce paramétrage se trouve dans la configuration du serveur tomcat, dans le fichier server.xml. Nous allons agir sur deux paramètres : le maxActive, que nous allons positionner à 30 connexions (ce qui est plus que raisonnable) et sur le maxWait afin de ne pas attendre en vain une connexion qui ne viendra jamais.

<GlobalNamingResources>
    <Resource name="jdbc/petclinicMySQL" auth="Container" type="javax.sql.DataSource" driverClassName="org.gjt.mm.mysql.Driver" url="jdbc:mysql://localhost:3306/petclinic_light?autoReconnect=true" username="petclinic" password="petclinic" maxActive="30" maxIdle="10" removeAbandoned="true" removeAbandonedTimeout="60" logAbandoned="true" maxWait="60"/>
</GlobalNamingResources>

Les résultats sont immédiats et nous passons à un temps moyens de 7,2 s :

• Paramétrage de la datasource
• Temps moyen de 7,6 s à 7,2 s pour 5 utilisateurs
• 2 points pour l’équipe qui a trouvé

Ca coince toujours. Où le temps est il consommé ?

Pas la peine d’envisager de passer à plus d’utilisateurs tant que le temps moyen de requête est aussi catastrophique. Si l’on s’intéresse plus en détail aux résultats de JMeter, on constate que la requête Owner detail est la plus consommatrice. Sûrement quelque chose à optimiser de ce côté là.
On ne va pas déroger aux bonnes habitudes prises, on retourne dans VisualVm. Et quand quelque chose coince au niveau applicatif, on réalise un ensemble de ThreadDump. Comme nous sommes avides de nouveauté, nous allons laisser les commandes Unix vi et grep aux dinosaures et utiliser les possibilités de VisualVm, à savoir le plugin Tda.

Pour mettre en évidence notre problème, nous allons tout d’abord restreindre les scenarii JMeter à la seule et unique requête Owner Details. Ensuite, nous allons réaliser une série de ThreadDump très rapproché (de 5 à 10 en quelques secondes). Nous allons ensuite utiliser une des possibilités de TDA, à savoir la détection des Thread longue durée Long Running Thread. TDA va tenter d’identifier les threads ‘bloqués’ dans la même méthode au travers de n ThreadDump.
Comme auparavant, nous ne nous occuperons que des catalina-exec-xx RUNNABLE. Et nous avons de la chance, puisque sur nos cinq utilisateurs, nous trouvons 2 threads bloqués au même point, dans la même méthode (vous l’aurez compris, la détection de thread longue durée est principalement basée sur un ‘coup de sonde’ statistique).

Un petit tour dans le code, dans la classe incriminée.

/**
     <strong> Custom handler for rendering images.
     </strong>
     <strong> @param petId
     </strong>            the ID of the pet whose visits to display
     <strong> @param response to output the image bytes
     </strong> @throws IOException
     */
    @RequestMapping(value = "/owners/*/pets/{petId}/image", method = RequestMethod.GET)
    public void petImageHandler(@PathVariable int petId, HttpServletResponse response) throws IOException {
        int imgId = petId % 6;
        InputStream in = Thread.currentThread().getContextClassLoader().getResourceAsStream("img/pet-" + imgId + ".jpg");
        response.setContentType("image/jpeg");
        OutputStream out = response.getOutputStream();
        IoUtils.copy(in, out);
        clean();
    }

A priori, rien de très suspect dans la façon de servir des images stockées côté serveur (le but de l’exercice n’étant pas d’éliminer le problème, en changeant le comportement de l’application et en déplaçant ces images côté apache).
Si on revient à nos ThreadDump, nous constatons que nous pouvons encore descendre dans le code, à l’intérieur de la classe IoUtils.

    public static void copy(InputStream in, OutputStream out) throws IOException {
        OutputStream bufferedOutputStream = new BufferedOutputStream(out);
        byte[] buffer = new byte[512];
        int length;
        while ((length = in.read(buffer)) >= 0) {
            bufferedOutputStream.write(buffer, 0, length);
        }
        bufferedOutputStream.close();
    }

A priori, si les copies d’InputStream / Outputstream étaient à ce point sous performantes, cela se saurait. Mais ne mésestimons pas la fourberie de nos poseurs de bombes.

En y regardant de plus près, on constate en effet que nous avons une belle implémentation maison de la méthode write, inspirée de celle du ByteArrayOutputstream.

public synchronized void write(int b) {
            int newcount = count + 1;
            if (newcount > buf.length) {
                buf = Arrays.copyOf(buf, (buf.length << 1) / 2 + 3);
            }
            buf[count] = (byte) b;
            count = newcount;
        }

Et là où le ByteArrayOutputstream se redimensionne de manière intelligente pour accélérer la copie

    public synchronized void write(int b) {
	int newcount = count + 1;
	if (newcount > buf.length) {
            buf = Arrays.copyOf(buf, Math.max(buf.length << 1, newcount));
	}
	buf[count] = (byte)b;
	count = newcount;
    }

, l’implémentation maison reste définitivement bloquée et recopie les octets 2 à 2…

Si nous remplaçons cette implémentation par java.io.BufferedOutputstream, nous devrions avoir de bien meilleurs résultats.

Et en effet cette fois, c’est spectaculaire. Pour nos cinq utilisateurs, nous passons à un temps moyen de 1,4 s avec une très remarquée dégringolade du temps moyen de ownersDetail qui passe de 32 s à 3,7 s.

• Suppression d’un java.io maison
• Temps moyen de 7,2 s à 1,4 s pour 5 utilisateurs
• 3 points pour l’équipe qui a trouvé

Il va bientôt être temps de passer à un nombre d’utilisateurs « raisonnable ».

Actualité éditeurs / SSII

• Le meilleur de The Server Side

Le coin de la technique

• Spring Security seulement un alignement sur Spring 3.0 ?
• Tour d’horizon de JBoss Infinispan
• JGroups à l’heure du Cloud Computing

Actualité éditeurs / SSII

Le meilleur de The Server Side

Avec les fêtes vient le temps des rétrospectives. Et c’est TheServerSide qui ouvre le bal, avec son hit parade des neuf fils de discussion les plus vus en 2009. Sans surprise, on retrouve quelques stars de l’année, dont la popularité ne devrait pas faiblir en 2010 : JavaEE 6 et Glassfish 3, la persistance (JPA, les caches d’Hibernate, la démarcation transactionnelle avec Spring)… Mais aussi les buzz de l’année : Google App Engine, les langages next-gen… On trouve ensuite un grand article communautaire, sur ce que doit savoir un architecte applicatif.
Enfin, et nous devons bien avouer qu’à la vue des évènements passés, cela prête à sourire, un très beau fil de prospective : IBM parle de racheter Sun.

Cette première rétrospective reflète pour nous bien les tendances de l’année passée : pas mal de grandes manœuvres chez les éditeurs, des concurrents à Java de plus en plus présent, un nouvelle spécification très attendue, et des frameworks incontournables qui continuent à mener la danse.

Le coin de la technique

Spring Security seulement un alignement sur Spring 3.0 ?

Dans la foulée de la sortie de la version 3 de Spring Framework, c’est au tour de Spring Security de faire son annonce. Le point le plus marquant de cette version est l’utilisation du Spring Expression Language pour décrire les règles de contrôle d’accès qui simplifieront des vérifications simples comme @PreAuthorize("#contact.name == principal.name)") et surtout, couplé à des classes java transverses de sécurité, permettra d’effectuer élégamment des contrôles déclaratifs sophistiqués tels que :

@PreAuthorize("isPhysician(#patientFile.patient)")
public void create(PatientFile patientFile);

Bien sûr, il faudra programmer la méthode isPhysician(), Spring Security ne se substituera pas au code métier de votre application, il sera juste une aide précieuse .
Nous noterons au passage que l’Expression Language apporte à l’Aspect Oriented Programming le haut niveau d’abstraction qui permet de programmer des fonctionnalités métiers transverses sans être un spécialiste de la plomberie ProceedingJoinPoint et autres joyeusetés. L’AOP devient alors beaucoup plus accessible pour les développeurs d’informatique de gestion.

Les autres nouveautés que nous garderons en tête : des contrôles pré et post traitement (@PreAuthorize et @PostAuthorize), la restructuration des jars similaire à celle que Spring 2.5 a connu, et une clarification des règles de redirection post authentification.

Tour d’horizon de JBoss Infinispan

Le projet Infinispan a été initié en milieu d’année 2009 chez JBoss. Il s’agit d’une évolution de JBoss Cache d’un simple cache vers un DataGrid.

Dans le dernier épisode en date de JBoss Asylum, le podcast dédié à la communauté JBoss maintenu par Emmanuel Bernard et Max R Andersen, Mark Surtani, leader du projet Infinispan, était invité pour parler de son projet. Il a pu faire un tour d’horizon global en commençant par le lien entre JBoss Cache et Infinispan :

• Contrairement à JBoss Cache qui utilisait une organisation arborescente, Infinispan se base uniquement sur une structure clé-valeur à plat.
• Tout comme le faisait JBoss Cache, Inifinispan utilise JGroups pour assurer la découverte de ses instances.
• Une API d’adaptation permettra d’assurer la transition entre JBoss Cache et Infinispan, notamment en offrant une arborescence au dessus de la structure de base d’Infinispan. Des outils seront fournis afin de migrer les fichiers de configuration.

Manik Surtani a également abordé les fonctionnalités à venir, après la finalisation de la première version, dévoilant ainsi les ambitions de positionnement de ce produit :

• Utilisation de Lucene pour offrir une API de requêtes puissante permettant des recherches dans le DataGrid. Plusieurs possibilités d’architecture ont été évoquées telles que la réplication d’un index complet sur l’ensemble des noeuds ou la distribution de shards de l’index complet sur les noeuds via l’utilisation d’un InfinispanDirectory pour Lucene, actuellement en cours de développement.
• Intégration éventuelle avec Hibernate Search. Infinispan se substituerait à Hibernate Core et Hibernate Search lui apporterait alors la fonctionnalité de recherche.
• Possibilité d’effectuer des continuous requests pour que les résultats d’une requête s’enrichissent au fur et a mesure de l’arrivée de données sur la grille.
• API de MapReduce permettant de soumettre un Callable et un ensemble de clés d’objets sur lesquels doivent s’appliquer le traitement pour obtenir un Future représentant le résultat, à venir, après opération de réduction.

La plupart des fonctionnalités évoquées sont présentes dans les produits commerciaux que sont Oracle Coherence ou IBM eXtreme Scale. Toutefois, de telles possibilités seraient inédites dans un produit Open Source ce qui devrait faire d’Inifinispan un produit très intéressant à suivre en 2010…

JGroups à l’heure du Cloud Computing

JGroups est un framework permettant la communication au sein d’un groupe de serveurs. Actuellement développé au sein de JBoss, il est à la base de nombreux middlewares et frameworks d’entreprise permettant un fonctionnement distribué tels que JBoss Cache ou plus récemment Infinispan.

Après un an sans mise à jour majeure, Bela Ban, leader du projet, annonce la version 2.8. Outre de nombreuses évolutions améliorant la flexibilité de JGroups, un apport notable s’est glissé dans la liste : le support d’Amazon EC2. Il s’agit là d’une nouveauté emblématique de cette année 2009 qui va se conclure ; la majorité des frameworks cherche à afficher une compatibilité voire une synergie avec les environnements de Cloud Computing courant.
En pratique, cette intégration de JGroups à EC2 se fait par l’ajout d’un nouveau protocole de découverte de voisinage nommé S3_PING. Comme son nom l’indique, il utilise un stockage S3 commun dans lequel tous les membres d’un groupe écrivent leurs coordonnées. Ce mécanisme est particulièrement bien adapté à EC2 qui, de part la topologie réseau qu’il offre, ne permet pas le multicasting et n’est guère adapté aux autres protocoles de découvertes qui existaient jusqu’alors dans JGroups.

Notons tout de même que la principale nouveauté de cette version 2.8 est l’ajout du concept d’adresse logique que Bela Ban présentait il y a quelques mois. Une adresse logique permet de découpler l’identité d’un nœud JGroups de son adresse réseau ; l’association entre adresse logique et physique est résolue lors de la découverte des nœuds. Outre le découplage offert par ce concept, ces adresses permettent également de simplifier la gestion des pertes de messages lors de la ré-incarnation d’un nœud suite a son indisponibilité temporaire.

10 ans après sa création, JGroups continue donc de se maintenir à jour et, dans la mesure où il remplit toujours parfaitement son rôle, il devrait rester présent encore des années dans plusieurs middlewares et frameworks majeurs.

Nous avons déjà publié plusieurs articles sur Hibernate Search : de l’introduction qui se focalisera sur l’architecture de l’outil au Hands On qui vous permettra de mettre les mains dedans. Les différentes recherches Full Text disponibles (appoximation, phonétique…) ont aussi été résumées dans le compte-rendu de la présentation de l’outil à Jazoon.

Le speaker insistera surtout sur la convention over configuration une approche programmatique du produit. Après l’énumération des annotations possibles (@Indexed, @Field, @FieldBridge, @IndexedEmbededd, @Boost et @Analyzer), les premières questions sur la configuration par XML tombent et la réponse est assez direct : Because we hate XML

Il enchaîne ensuite avec quelques slides d’architecture. On retiendra ainsi que Hibernate Search est construit sur Hibernate Core, que le produit est Event Based et que l’indexation manuelle massive est optimisée. Un slide nous montrera les différentes étapes d’une recherche avec Hibernate Search, tout d’abord un appel à Lucène pour récupérer nos documents et, si besoin, un appel au cache ou à la base de données pour récupérer les entités souhaitées.

Emmanuel terminera avec une Road Map plutôt chargée dont :

• Amélioration des performances de l’API programmatique.
• Indexation massive multi-threadée.
• Clustering (travail en collaboration avec Infinispan).
• Meilleure intégration avec Solr.
• Amélioration des Query (construction simplifiée…).
• Statistiques.

Pas de date de sortie prévue pour cette nouvelle version mais il est toujours possible de jouer avec Hibernate Search 3.1.1 GA (version actuelle du produit qui date de 6 mois) et de mettre en œuvre quelques recherches Full Text !

RIA

• Vaadin 6
• Adaptateur Gilead pour GAE
• Une série d’annonces chez Adobe

Le coin de la technique

• Scalabilité avec Hibernate et Shards
• Jigsaw vs OSGi
• Pourquoi utiliser un portail ?
• Embarquer le Web dans Java avec JWebPane

Evènements de notre communauté en France et à l’étranger

• Xebia @ Jazoon 09

RIA

Vaadin 6

Au revoir IT Mill Toolkit et bienvenue à Vaadin (vu sur leur blog) !

Pour ceux qui ne le connaissent pas encore, Vaadin (anciennement IT Mill Toolkit) est un framework de développement d’applications RIA qui s’appuie sur GWT. Sa particularité est d’être runtime donc aucune compilation spécifique n’est demandée avant de packager la webapp (à l’inverse de GWT).

Simple changement de nom ? En tout cas très peu de changement côté API selon les auteurs du framework. Il faut plutôt se tourner vers l’outillage pour voir quelques nouveautés : un plugin eclipse (création de projets, de composants UI, de thèmes…) et, inclus dans le plugin, un éditeur WYSIWYG.

Côté liens utiles, l’habituel showcase, le livre et la comparaison maison avec les autres frameworks du marché (et la concurrence est rude dans le monde du RIA).

A noter que Vaadin sera présent à Jazoon pour une conférence sur RIA Security le mardi 23 juin à 15h (slides, projet et autres sur cette page).

Adaptateur Gilead pour GAE

Vous connaissez GWT, Gilead, et Google App Engine ? Et bien il ne reste plus qu’à mélanger tout ça et on obtient le Gilead GWT adapter for Google AppEngine (vu sur le GWT Blog).

Tout démarre d’un thread google groups avec comme point de départ la serialization exception lancée par les entités persistantes transférées vers GWT. Évidemment, la solution qui ressort très rapidement, outre l’utilisation de DTOs, est de passer par Gilead pour transformer nos entités persistantes en POJOs. Il suffit d’ajouter le jar adapter4appengine et de remplacer la classe PersistentRemoteService par EngineRemoteService dans vos remotes services. Dès lors, il sera possible d’envoyer ses entités persistantes vers le client GWT sans exceptions de sérialisation sur GAE.

1.0 M2 téléchargeable à cette url, documentation par ici. Attention toutefois, cette version n’est pas production ready.

Une série d’annonces chez Adobe

Après l’annonce de la sortie de la plateforme Flash il y a quelques semaines, voici une nouvelle série d’annonce de la part d’Adobe.

Pour commencer, deux news relayées par Andrew Twice dans InsideRIA.
La première concerne la sortie d’Adobe Table en version bêta. Cet outil permet de créer des feuilles de calcul, des plannings ou encore des listes de tâches en ligne:

• Les utilisateurs peuvent ajouter des données en même temps: les données sont mises à jour en temps réel pour tout le monde.
• Possibilité de savoir qui travaille sur Adobe Table.
• Création d’écrans communs et privés : les utilisateurs peuvent travailler de manière coopérative, et/ou créer des espaces privés pour ne garder que les informations importantes.
• Filtrage : les utilisateurs peuvent filtrer leurs données en temps réel.
• Tri.

Similaire à Google Document, cet outil a été développé sur la plateforme Flash et va continuer à évoluer. La démo se passe ici, la seule contrainte : avoir un compte Adobe.

La deuxième annonce concerne l’ouverture de la spécification de Real-Time Messaging Protocol (RTMP). Comme nous en avions parlé ici, la spécification a été publiée lundi dernier.

Enfin, Michael Chaize parle de la sortie de LiveCycle Data Services 3 en bêta. Disponible sur le labs d’Abobe, cette nouvelle version propose une meilleure qualité de service pour des applications dont la fiabilité est primordiale telles que les applications bancaires par exemple. Venant compléter la plateforme Flash (avec Flex 4 et Flash Builder 4), Adobe incite la communauté à faire ses retours sur le forum.

Le coin de la technique

Scalabilité avec Hibernate et Shards

Une session de QCon 2008, traitant de la scalabilité d’Hibernate, vient d’être mise en ligne. Présentée par Emmanuel Bernard, project lead d’Hibernate Search, et Max Ross, project lead d’Hibernate Shards, cette présentation offre une approche peu courante sur un problème pourtant récurrent.

Outre les classiques solutions permettant d’éviter certaines pertes de performance avec l’augmentation du volume traité, telles que la bonne gestion du cache, et les optimisations SQL, il a été question d’utiliser Hibernate Search et Hibernate Shards.

Hibernate Search est connu pour sa capacité à simplifier les recherches dans un ensemble d’entités grâce à l’utilisation de Lucene conjointement à la base de données. Emmanuel Bernard proposait ici de déléguer à Search certaines recherches qui s’avèrent très coûteuses à effectuer en base. Lucene étant placé sur une machine séparée, et pouvant même fonctionner en maître / esclave, il est ainsi possible d’obtenir une intéressante répartition de la charge.

Hibernate Shards, bien que plus ancien, est moins répandu du fait qu’aucune version finale n’a encore été produite. Il s’agit d’un module additionnel pour Hibernate permettant à une application de manipuler des données partitionnées sur plusieurs BDD. Le but étant d’encapsuler la conscience du partitionnement des données au sein de la couche Hibernate afin que l’application n’ait pas à gérer cette problématique. Les possibilités du framework sont intéressantes :

• La gestion correcte des Criterias sur des données partitionnées grâce à ShardedCriteria.
• Virtual Shards permettant de faire la distinction entre shard logique et shard physique et ainsi d’augmenter le nombre d’instances de base de données au fur et à mesure de l’augmentation des besoins.
• Generation d’IDs compatibles avec l’utilisation sous-jacente de plusieurs BDDs grâce à l’utilisation d’UUIDs.
• Gestion correcte de BDDs hétérogènes.

Ce sont finalement les fonctionnalités manquantes qui permettent de comprendre pourquoi Shards est toujours en version bêta. Max Ross s’est expliqué il y a plusieurs mois sur les problématiques rencontrées, de manière succincte sur un forum et plus longuement dans une interview. De nombreux défis restent ainsi à relever concernant la gestion correcte des agrégations dans les ShardedQuery et la fourniture d’outils d’aide au partitionnement et repartitionnement des données.
Max Ross est employé par Google et non par JBoss, tout comme les deux autres committers du projet (le code ayant été donné à JBoss par Google), et affirme ne disposer que de 20 % de son temps pour Shards. Ceci n’explique que partiellement le peu de commits sur le projet et ne nous rassure guère quant à sa finalisation prochaine.

Jigsaw vs OSGi

Sept mois après le démarrage du projet Jigsaw, sa légitimité n’est toujours pas reconnue face à OSGi qu’il est venu défier sur son propre terrain.

La semaine dernière JavaPosse diffusait une interview de Mark Reinhold et Alex Buckley, où ils ont pu présenter plus en détail leur vision de Jigsaw :

• Il a été conçu pour modulariser le JDK et est intégré au langage.
• Il ne repose pas sur une spécification car cela n’était pas possible compte tenu du calendrier de JDK 7. Il est donc à considérer comme un « détail d’implémentation » tout comme la gestion du classpath l’était dans les JVMs précédentes.
• Il n’est pas supposé entrer en concurrence avec OSGi, des outils permettant l’intégration entre modules Jigsaw et bundles OSGi étant prévus, mais non prioritaires.

Dans le même temps, Eric Newcomer (Co-Chair, Enterprise Expert Group de l’OSGi Alliance), postait une série de billets très virulents à l’égard du projet Jigsaw, reprochant principalement que Sun n’ait pas voulu se tourner vers OSGi, ne cherchant pas à combler les manques qu’il y trouvait, se tournant immédiatement vers une nouvelle technologie et ignorant donc les 10 années d’expérience acquises par OSGi.

En fait, il semble n’y avoir aucune justification technique permettant d’expliquer l’orientation de Sun vers Jigsaw plutôt que vers OSGi ou vers une évolution d’OSGi intégrée au langage. La véritable raison serait alors à chercher sur le plan politique : la modularisation est un concept important qui manque à Java actuellement et Sun ne pouvait probablement pas se permettre, pour l’ajout d’un tel concept, de s’appuyer sur une spécification émise en dehors du JCP sur lequel il a la gouvernance.

Pourquoi utiliser un portail ?

Le dernier podcast des Cast Codeurs était l’occasion d’une interview de Thomas Heute et Julien Viet sur les portails d’entreprise et sur le partenariat entre eXo et JBoss dont nous vous parlions la semaine dernière.

Les détails liés au partenariat ont déjà été largement couverts par la blogosphère, et c’est surtout le tour d’horizon du concept même de portail que l’on retiendra. Celui-ci reste en effet souvent un élément ambigu au sein de l’écosystème JEE.

Le rôle du portail est d’agréger plusieurs applications au sein d’une unique application Web. Ce besoin technique peut être atteint à plusieurs niveaux de l’architecture de l’application :

• Au niveau back-end, par agrégation de Web Service, se conformant ainsi à l’un des préceptes des SOAs.
• Au niveau applicatif, par l’utilisation d’un portail, ou d’une solution spécifique.
• Au niveau du navigateur Web, par l’utilisation de gadgets, en suivant le principe des Mashups.

En outre, il a également été question des problématiques d’intégration des frameworks Web aux portlets, de complexité éventuelle, et d’adaptation des technologies Web aux portlets. Déterminer si un portail doit être utilisé dans une architecture dépend alors du niveau de tolérance à ces problématiques.

Embarquer le Web dans Java avec JWebPane

Depuis plusieurs années, lorsque l’on veut afficher une page Web au sein d’une application Swing, il faut se tourner vers le composant Browser de la librairie Jdic. Ce composant utilise Embeddable Mozilla, et se présente sous la forme de code natif décliné pour chaque OS et d’un wrapper Java. Outre la nécessité de fournir une version spécifique à chaque OS, ce composant présente également l’inconvénient de mal s’intégrer aux applications Swing du fait de sa nature heavyweight. Pour rappel, un composant est dit heavyweight lorsqu’il est dessiné par l’environnement graphique du système d’exploitation ; à l’opposé il devient lightweight s’il est dessiné par l’application, ce qui est le cas de l’ensemble des composants Swing. Or, faire cohabiter les deux types de composants est délicat car n’étant pas dessinés au même moment, leur superposition est confuse et des chevauchements non contrôlables apparaissent.

Lors de JavaOne, Alexey Ushakov a fait la démonstration du composant JWebPane sur lequel il travaille actuellement et vient de poster des captures d’écrans. Contrairement à Jdic Browser, JWebPane se base sur le moteur WebKit pour effectuer le rendu HTML. Or celui-ci se caractérise par sa nature lightweight s’intégrant agréablement à Swing. La présentation d’Alex Ushakov permet également de constater que son composant est particulièrement riche en possibilité d’interactions et apporte un support pour d’éventuels plugins tels que Flash.

On ne peut qu’apprécier le choix de Sun de créer un composant pour Swing, réutilisable dans JavaFX, plutôt que de privilégier uniquement JavaFX comme cela est souvent le cas depuis son arrivée. L’intégration de JWebPane au JDK 7 est maintenant indispensable pour rendre ce composant réellement exploitable : se basant sur WebKit, il repose donc sur des librairies natives qu’il sera nécessaire de livrer avec les applications Java et seul l’intégration au JDK permettrait de l’éviter. Or, malgré les appels de la communauté, JWebPane reste pour le moment absent de la liste des features du JDK 7 et il est uniquement question d’une mise à disposition sur Java.net.

• Riena, la nouvelle plate-forme de la fondation Eclipse

RIA

• Flight Framework : le nouveau framework MVC pour les applications Flex et ActionScript

Le coin de la technique

• Hibernate Validator poursuit l’alignement avec la JSR-303
• Le positionnement de JavaFX toujours en question
• Mettre en ligne ses développements de BDD avec une application agile (tout au moins itérative).

Actualité éditeurs / SSII

Riena, la nouvelle plate-forme de la fondation Eclipse

La fondation Eclipse a annoncé la disponibilité de sa nouvelle plate-forme « Eclipse Riena » en version 1.0. Le but de ce projet est de fournir un environnement client et serveur pour développer des applications multi-tiers avec clients riches. En soit, rien de très original. En fait, la vraie nouveauté se situe dans les possibilités offertes et dans les technologies utilisées. En effet, cette plate-forme est basée sur Eclipse RCP et Equinox et offre la possibilité de développer des services OSGi sans pré-supposer de leur localisation sur le client ou le serveur.

Autour de ce modèle d’architecture, Riena propose un ensemble de fonctionnalités :

• Possibilité de faire évoluer des composants Eclipse existants vers la plate-forme Riena
• Gestion des mises à jour des clients pilotée par le serveur. Possibilité de procéder de manière incrémentale.
• Gestion des authentifications et des autorisations basée sur JAAS.
• Monitoring de l’état des clients. L’ensemble des logs et erreurs des clients peut être accédé depuis le serveur.

On notera également que la partie serveur est assurée par un module Jetty et que le protocole Hessian est utilisé pour la communication avec les clients. En outre Riena apporte des composants graphiques supplémentaires permettant de construire plus facilement des interfaces orientées processus métier ; Elias Volanakis en avait proposé un exemple il y a quelques mois.

Là où Eclipse RCP ne traitait que du développement de la partie cliente des applications d’entreprise, Riena apporte une réponse intéressante également sur la partie serveur. A l’heure où la majorité des développements se tournent vers le Web et ses récentes technologies RIA, pour des raisons de simplicité de déploiement et de maintenance, le nouveau projet de la fondation Eclipse propose une solution bien plus flexible, tout en se basant sur des technologies matures.

RIA

Flight Framework : le nouveau framework MVC pour les applications Flex et ActionScript

Le framework Flight est un nouveau framework MVC pour le développement d’application Flex / ActionScript. Il vient rejoindre la liste déjà importante de frameworks MVC existants, comme Cairngorm, PureMVC, Mate … InfoQ s’intéresse dans cet article à ce nouveau venu.

Ce framework a été créé par Tyler Wright, Rob Taylor et Jacob Wright, pour faciliter le développement de leurs applications. Son principe est le suivant : modulariser en domaines logiques, rationaliser le développement en équipe. Minimaliste, il offre des solutions robustes, avec entre autres :

• un système de mémorisation de l’historique pour pouvoir mettre en place le Annuler/Rétablir.
• la possibilité de configurer plus facilement le data binding

Pourquoi ce énième framework ? Tyler Wright répond à la question ici. Cairngorm étant très lourd à mettre en place, il lui fallait une solution plus efficace et répondant à son besoin. Pour le moment, le projet ne fournit que la liste des fonctionnalités et une version en beta release non documentée.

Le coin de la technique

Hibernate Validator poursuit l’alignement avec la JSR-303

Le développement de la version 4.0 d’Hibernate Validator est en cours et poursuit son alignement avec la JSR-303 (Bean validation). Cette JSR, actuellement en version beta, est dirigée par Emmanuel Bernard, également project lead d’Hibernate Validator, qui sera l’implémentation de référence. Par rapport à ce framework, outre une adaptation globale de l’API, la spécification diffère principalement sur deux points :

• l’apport de la notion de groupe, permettant de spécifier un ensemble de contraintes, à inclure ou non dans une validation
• la possibilité de spécifier la « traversabilité » des propriétés d’un objet. Ainsi, si une propriété ne doit pas être validée à un instant donné (pour cause de lazy loading par exemple), il sera possible de l’indiquer au framework.

Ces apports, bien que minimes en apparence, sont réellement utiles. En effet, les scénarios de validation dans les applications d’entreprises sont souvent constitués de nombreuses règles de gestion, qu’il est délicat d’appréhender sans un framework offrant une grande flexibilité.

Le positionnement de JavaFX toujours en question

Manque de communication de Sun ? Le positionnement de JavaFX par rapport à Swing fait toujours débat, 4 mois après la sortie de sa première version finale.

Ces derniers jours, deux interventions ont particulièrement entretenu le débat.

D’un coté, John O’Conner soutient que la relance de la JSR-296 (Swing Application Framework) est vaine et ne constitue qu’un investissement à court terme. Poursuivant dans cette vision d’un Swing obsolète, il conseille aux développeurs arrivant dans le monde des interfaces riches en Java de ne pas chercher à apprendre Swing mais de directement se tourner vers JavaFX.

De l’autre coté, Jan Erik Paulsen, rejette avec force JavaFX, tant comme concurrent de Flex / Silverlight, critiquant le manque de productivité offert par la solution de Sun pour les designers, que comme remplaçant de Swing, ne pouvant admettre le rejet de cette technologie mature et maîtrisée.

Au trouble existant sur l’évolution de Swing dont nous parlions la semaine dernière, s’ajoute donc ce positionnement ambiguë de JavaFX. S’il veut empêcher la fuite des javaistes vers les solutions concurrentes, Sun devra clarifier son discours dans les mois à venir et tenter de mettre un point final à ce genre de querelles (en apportant, lors de la prochaine release en Juin, un véritable gain de productivité grâce à un environnement de développement, à des composants graphiques de haut niveau, …).

Mettre en ligne ses développements de BDD avec une application agile (tout au moins itérative).

Pramod Sadalage, co-auteur, avec Scott Ambler en 2007 de Refactoring Databases: Evolutionary Database Development et auteur de Recipes for Continuous Database Integration, expose, dans une vidéo captée au QCon et relayée par infoQ, les grands principes d’un design de base de données évolutif (qu’on pourrait sous titrer ‘Comment attirer les DBA dans le monde itératif J2EE’).
Pour ceux qui n’auraient pas le temps d’ingurgiter les quelques 500 pages de ces 2 ouvrages, cette vidéo, illustrée par des démonstrations pertinentes, constitue un bon point de départ.

Cependant, et comme c’est malheureusement souvent le cas, les grands principes exposés ici se heurteront rapidement aux réalités projet (il est bien difficile de ‘vendre’ un pair programming développeur Java / DBA, de multiplier les environnements bac à sable…).
Malgré tout, il est facile d’extraire quelques trucs et astuces pleins de bon sens de cette présentation (automatisation, rôle de l’intégration continue, de la gestion de sources…).

Dans cet article, nous présenterons une solution simple et propre pour vous permettre une meilleure intégration d’Hibernate avec GWT.

Ce billet se découpe de la façon suivante :

• Nous commencerons par introduire la problématique d’intégration d’Hibernate avec GWT.
• Nous introduirons ensuite une solution pour faire cohabiter Hibernate avec GWT.
• Nous proposerons ensuite une solution légère et transparente pour intégrer Hibernate avec GWT.
• Nous détaillerons ensuite la procédure d’intégration de la solution sur votre projet.
• Et nous terminerons par un petit retour d’expérience.

Introduction

L’idée de base est d’utiliser mes objets du Domaine directement dans la couche présentation. Google Web Toolkit se basant sur Java, cela semblait l’une des forces de cette union. Mais malheureusement, les divergences techniques rendent la tâche difficile.

Plusieurs raisons empêchent d’utiliser les objets du Domaine directement dans la couche présentation :

• Héritage différent : Les objets Java échangés entre le client et le serveur doivent implémenter une interface de sérialisation Google IsSerializable, tandis que les classes Hibernate implémentent l’interface Serializable. Autre problème gênant, le compilateur GWT dans sa version 1.4 ne supporte pas l’interface Java Seriablizable et affiche une erreur.
• Types de données incompatibles : Les classes PersistentSet et java.sql.DateTime utilisées par Hibernate ne sont pas reconnues par le compilateur GWT.
• Chargement partiel (Lazy-Loading) : GWT ne sait manipuler que des POJO (Plain Old Java Object) et non des objets Hibernate. À l’exécution, Hibernate remplace les instances par des Proxies, alors que JavaScript, mis en œuvre par GWT, accepte uniquement les types primitifs et les POJO qui en sont composés. Or une classe Proxy n’est pas un type primitif, ni un type déclaré comme sérialisable en JavaScript.

Toutefois, intégrer Hibernate avec GWT est possible. Mais doit-on abandonner l’idée d’utiliser les objets du Domaine directement dans la couche présentation ? GWT 1.5 est peut-être la solution.

Faire cohabiter GWT et Hibernate

Une solution consiste à créer une hiérarchie de classes DTO correspondant à la hiérarchie des classes Hibernate, puis à cloner les objets du Domaine en objets DTO afin de les véhiculer vers la couche présentation sans difficulté. L’opération de clonage est prise en charge par la couche service qui assure les conversions Hibernate<->DTO en utilisant la librairie bean-lib. Celle-ci gère la duplication dynamique des objets Hibernate et convertit les données non supportées par GWT. Reste donc le problème de chargement partiel (Lazy loading) qui doit être géré par les développeurs.

Cette solution s’est avérée complexe et coûteuse en temps de développement. De plus, elle entraîne beaucoup trop de dépendances techniques. Elle a cependant le mérite de fonctionner.

Pour plus d’informations n’hésitez pas à consulter le billet suivant.

Hibernate4GWT arrive … GWT 1.5 aussi

Hibernate4GWT est une librairie Java prenant en charge la cohabitation dynamique d’Hibernate avec GWT. Elle permet ainsi d’utiliser les objets du Domaine directement dans la couche présentation sans se soucier de créer une hiérarchie de classes DTO juste vos objets du Domaine et du Domain Driven Architecture.

À noter que si vous utilisez toujours GWT 1.4, vos objets du Domaine doivent respecter la syntaxe Java 1.4, ce qui n’est pas facile à gérer et à intégrer dans du code existant. Et même avec Hibernate4GWT, vous êtes contraints de créer des classes DTO pour vous en sortir. Les objets du Domaine qui proviennent du serveur sont rapatriés et organisés dans les DTO par la librairie (l’opération de clone) et les objets DTO renvoyés vers le serveur sont également restitués par la librairie (l’opération de merge).

Avec l’arrivée de GWT1.5, vous n’avez plus ni à créer des classes DTO, ni à utiliser explicitement les opérations de merge et de clone. il est désormais possible d’utiliser vos objets du Domaine directement sur la couche présentation : d’où la nécessité de passer à GWT 1.5 pour une intégration transparente entre Hibernate et GWT.

La classe HibernateBeanManager, qui est le cœur de l’API, s’occupe de la suppression des proxies Hibernate. Elle gère la conversion des types de données incompatibles avec GWT en leur équivalent valide. Puis elle stocke les informations des attributs partiellement chargés (Lazy attributes) pour restituer correctement les objets du Domaine.

Hibernate4GWT, avec un minimum de configuration et des impacts techniques très légers, fournit un socle technique qui masque la complexité introduite par l’intégration d’Hibernate avec GWT et nous permet ainsi de respecter les règles de l’art.

Et concrètement qu’est-ce que ça donne ?!

Hibernate4GWT s’adapte à plusieurs types de configurations, selon vos besoins et les contraintes du projet dans lequel vous souhaitez l’intégrer.

Plusieurs configurations sont possibles :

• Stateless (configuration par défaut) : le serveur ne stocke aucune information sur l’état de la session. Les classes du Domaine doivent hériter de la classe LazyPojo pour stocker les attributs partiellement chargés (Lazy attributes).
• Dynamic Proxy : Une classe Proxy est générée par la librairie pour stocker les informations sur les attributs partiellement chargés (Lazy attributes) côté serveur et côté client. Les classes du Domaine doivent implémenter l’interface Serializable.
• Stateful : Les informations sur les attributs partiellement chargés (Lazy attributes) ne sont pas stockées dans les POJO mais dans la session HTTP. Les classes du Domaine ne nécessitent aucun héritage technique, mais votre serveur devient stateful (sticky session).
• Java5 support : GWT 1.4 ne supporte pas la syntaxe Java 5, Hibernate4GWT permet de cloner dynamiquement les classes du Domaine Java 5 en DTO associés compatibles Java 1.4. Pour cela, ces classes DTO doivent avoir le même nom que les classes du Domaine (placées dans un package différent) et doivent hériter de la classe LazyPojo.

Pour démarrer, vous devez d’abord choisir une configuration pour votre projet. Pour un nouveau projet, ou si vous avez la possibilité d’ajouter des héritages techniques dans vos classes du Domaine, l’auteur de la librairie recommande la configuration Dynamic proxy ou le mode Stateless. Sinon, si vous ne voulez pas modifier l’existant, vous pouvez utiliser le mode Stateful ou la configuration Dynamic proxy si vos classes du Domaine implémentent l’interface Serializable.

À noter que si vous utilisez des classes du Domaine Java 5 et GWT 1.4, vous êtes contraints d’utiliser la configuration Java5 support.

Intégrer Hibernate4GWT dans votre projet

Installation

L’installation d’Hibernate4GWT dans un projet GWT :

• Décompression de l’archive hibernate4gwt-1.x.x.zip,
• Ajout d’hibernate4gwt.jar et des dépendances présentes dans le répertoire lib dans le classpath de votre projet GWT,
• Édition du fichier de configuration GWT :

Avec GWT 1.4 :

<module>
       <!-- Inherit the core Web Toolkit stuff -->
       <inherits name='com.google.gwt.user.User'/>
       <!-- Inherit the hibernate4gwt stuff -->
       <inherits name='net.sf.hibernate4gwt.Hibernate4Gwt14'/>
       <!-- Specify the app entry point class -->
       <entry-point class='...'/>
       <!-- Additional source path -->
       <!-- To add for java5 support configuration -->
       <source path='dto'/>
       <!-- To add for other configurations -->
       <source path='domain'/>
       <source path='client'/>
       <!-- To add for dynamic proxy configuration -->
       <generate-with class="net.sf.hibernate4gwt.rebind.Gwt14ProxyGenerator">
          <when-type-assignable class="java.io.Serializable" />
       </generate-with>
       <!-- Servlet path -->
</module>

Avec GWT 1.5 :

<module>
       <!-- Inherit the core Web Toolkit stuff -->
       <inherits name='com.google.gwt.user.User'/>
       <!-- Inherit the hibernate4gwt stuff -->
       <inherits name='net.sf.hibernate4gwt.Hibernate4Gwt15'/>
       <!-- Uncomment if your Domain class use JPA mapping annotations -->
       <!-- <inherits name='net.sf.hibernate4gwt.emul.java5.ejb3.Ejb3'/> -->
       <!-- Specify the app entry point class -->
       <entry-point class='...'/>
       <!-- Additional source path -->
       <!-- To add for java5 support configuration -->
       <source path='dto'/>
       <!-- To add for other configurations -->
       <source path='domain'/>
       <source path='client'/>
       <!-- To add for dynamic proxy configuration -->
       <generate-with class="net.sf.hibernate4gwt.rebind.Gwt15ProxyGenerator">
         <when-type-assignable class="java.io.Serializable" />
       </generate-with>
       <!-- Servlet path -->
</module>

Classes du Domaine

Pour utiliser vos classes du Domaine dans GWT, il y a quelques détails à régler :

• Ajouter vos classes du Domaine dans le classpath de l’application GWT,
• Implémenter l’interface Serializable dans vos classes du Domaine pour le mode Stateful et la configuration Dynamic proxy,
• Étendre la classe net.sf.hibernate4gwt.pojo.java14.LazyPojo (GWT 1.4) ou net.sf.hibernate4gwt.pojo.java5.LazyPojo (GWT 1.5) pour le mode Stateless,
• Créer une hiérarchie de classes DTO compatibles avec GWT 1.4 pour la configuration Java5 support.

Initialisation d’HibernateBeanManager

Lors l’initialisation de l’instance d’HibernateBeanManager, il faut lui associer une instance d’Hibernate SessionFactory. Cette configuration est à faire dans le code d’initialisation serveur.

Mode Stateless :

HibernateBeanManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateBeanManager.getInstance().setEntityManagerFactory(emf);

Configuration Java5 support :

De plus, il faut également associer HibernateBeanManager à une instance de la classe DirectoryCloneMapper pour le mapping entre les classes du Domaine et les classes DTO.

HibernateBeanManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateBeanManager.getInstance().setEntityManagerFactory(emf);
DirectoryCloneMapper cloneMapper = new DirectoryClassMapper();
cloneMapper.setRootDomainPackage("com.testing.server.domain");
cloneMapper.setRootClonePackage("com.testing.dto");
cloneMapper.setCloneSuffix("DTO");
HibernateBeanManager.getInstance().setClassMapper(cloneMapper);

Mode Stateful :

En plus de la configuration de base, il faut associer une instance d’HttpSessionPojoStore à l’instance d’HibernateBeanManager.

HibernateLazyManager.getInstance().setPojoStore(new HttpSessionPojoStore());
HibernateLazyManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateLazyManager.getInstance().setEntityManagerFactory(emf);

Configuration Dynamic proxy :

Il est aussi nécessaire d’associer une instance de la classe ProxyClassMapper à l’instance d’HibernateBeanManager pour les opérations de clone et de merge.

HibernateBeanManager.getInstance().setSessionFactory(sessionFactory);
// or HibernateBeanManager.getInstance().setEntityManagerFactory(emf);
HibernateBeanManager.getInstance().setClassMapper(new ProxyClassMapper());

Service distant

L’implémentation du service GWT distant doit hériter de la classe HibernateRemoteService au lieu de la classe RemoteServiceServlet.

public class ProductRemoteImpl extends HibernateRemoteService
                            implements ProductRemote
{
    ...
    public Product getProduct(int id)
    {
         return _productDAO.getProductById(id);
    }
    public Product updateUser(Product product)
    {
         // Update the product in database
         _productDAO.updateProduct(product);
         // Send back a new clone (optimistic lock)
         return product;
    }
}

A noter qu’avec la configuration Java5 support, il faut merger les objets DTO en entrée et cloner les objets du Domaine en sortie.

public class ProductRemoteImpl extends HibernateRemoteService
                            implements ProductRemote
{
    ...
    public ProductDTO getProduct(int id)
    {
         return (ProductDTO) clone(_productDAO.getProductById(id));
    }
    public ProductDTO updateUser(ProductDTO productDTO)
    {
         // Update the product in database
         product = (Product)merge(productDTO);
         _productDAO.updateProduct(product);
         // Send back a new clone (optimistic lock)
         return (ProductDTO) clone(product);
    }
}

Conclusion

J’avais intégré l’API Hibernate4GWT sur un projet de petite taille avec une base de données de 10 tables et un nombre d’utilisateurs simultanés limité à 20. Lors de la mise en œuvre, l’API m’a facilité grandement la vie, et m’a permis une meilleure intégration d’Hibernate avec GWT. Je n’ai pas eu des problèmes particuliers en production ni d’impacts sur les performances de l’application, mais des questions se posent : peut-on utiliser l’API sur des grands projets ? Quel sera l’impact sur les performances lors de la montée en charge ?

Comme nous avons pu le voir, Hibernate4GWT est une petite librairie qui permet une intégration transparente et légère d’Hibernate avec GWT. L’auteur de la librairie nous promet beaucoup de choses dans l’avenir en renommant la librairie en Gilead ou Generic Light Entity Adapter, une nouvelle version Hibernate4ALL pour les technologies (Flex/BlazeDS, Web Services …).

Liens annexes :

• Présentation d’Hibernate4GWT sur le site officiel
• Présentation de Gilead sur le site officiel

Actualité éditeurs / SSII

• SpringSource rejoint le comité exécutif du JCP pour Java SE et EE
• Microsoft embrasse les Middlewares de Message Open Source

Agilité

• Scrum et le lavage en machine

RIA

• X2O framework ou comment faciliter la réalisation d’applications Flex.
• Pivot 1.0 : développer des applications RIA en Java et XML
• Testez vos applications Flex avec Fluint

Le coin de la technique

• Envers rejoint Hibernate

Evènements de notre communauté en France et à l’étranger

• GWT au Paris JUG de Novembre
• XKE, le programme de la session de Novembre

Actualité éditeurs / SSII

SpringSource rejoint le comité exécutif du JCP pour Java SE et EE

SpringSource était déjà présent dans des Expert Groups clefs de Java EE (JSR-316 : JavaEE 6, JSR-291 : Dynamic Component Support for Java SE – aka OSGi, etc). Rod Johnson fait un pas de plus dans cet organisme en se faisant élire membre du JCP Executive Committee for Java SE/EE, le comité qui encadre les JSR relatives à Java SE et Java EE. L’Executive Committee est à l’image de l’ouverture du JCP ; on y retrouve principalement des grands acteurs du monde Java (IBM, Oracle, Sun, etc) mais aussi l’ancien trublion aujourd’hui assagi des serveurs Java EE JBoss/Redhat et des membres individuels comme l’universitaire Doug Lea ou le polémique auteur du Bile Blog Hani Suleiman (qui ne s’est pas représenté cette année).

Rod Johnson place son mandat sous le signe de la transparence, de l’écoute de la communauté et du pragmatisme (Cf. A word about the election et our approach to the JCP). Cette vision s’inscrit dans la tendance actuelle du JCP dont les travaux s’ouvrent chaque année un peu plus (participation gratuite pour les individuels, publicité des débats, Reference Implementation (RI) et Technology Compatibility Kit (TCK) open source, etc).

La présence de SpringSource dans les instances dirigeantes du JCP participera au maintien de l’équilibre entre « petits et grands » dans un monde en phase de concentration (Oracle/BEA, IBM/ILog, Progress/IONA, etc). De plus, on peut espérer que Rod Johnson facilite le rapprochement entre le JCP et l’OSGi Alliance dont le fonctionnement ressemble plus au JCP d’il y a 10 ans (participation payante, membres essentiellement commerciaux, confidentialité des débats, des RI et des TCK, etc) qu’à la communauté que nous connaissons aujourd’hui : certes perfectible mais exemplaire par son ouverture.

Pour en savoir plus : SD Time : Rod Johnson on a mission to open up JCP, The 451 group : Spring forward.

Microsoft embrasse les Middlewares de Message Open Source

Microsoft avait déjà surpris la communauté Open Source cet été en devenant Platinium Sponsor de la Fondation Apache. La firme de Redmond poursuit aujourd’hui son rapprochement avec le monde Open Source en rejoignant l’AMQP Working Group pour soutenir le développement du protocole open source de middleware de messages AMQP destiné à concurrencer le duopole d’IBM et de Tibco (respectivement Websphere MQ et RendezVous).

Au delà de l’effet d’annonce, comment la firme de Redmond concrétisera-t-elle cet engagement ? Microsoft refondra-t-il Microsoft Message Queing (MSMQ) pour implémenter AMQP ? Contribuera-t-il à un projet Open Source comme par exemple Apache QPid, projet largement supporté par Redhat qui en a fait le socle de sa solution Redhat Messaging ?

En attendant plus de détails, ce ralliement pourrait d’une part être le soutien qui semblait manquer à AMQP pour prendre son essor et d’autre part être un différenciateur clef de Microsoft pour se lancer à l’assaut des parts de marché d’IBM et de Tibco.

Pour en savoir plus : InteropNews : Microsoft embraces AMQP open middleware standard

Agilité

Scrum et le lavage en machine

On connaissait la métaphore du Rugby pour expliquer Scrum, voici une comparaison plus originale : le lave-linge ! Le Touilleur Express fait l’analogie entre Scrum et le lavage en machine pour expliquer quelques notions :

• Product backlog : le linge sale représente la liste des tâches à faire.
• Itérations : le lavage s’effectue par cycle, comme le développement itératif.
• Capacité non extensible : ne demandez pas à votre lave-linge de laver plus de linge que sa capacité (5kg), de même une équipe ne peut produire qu’une quantité limitée de fonctionnalités par itération.
• Gestion de priorités : il faut trier le linge en fonction des priorités, si l’on a besoin de la chemise pour demain ou si elle peut attendre le prochain lavage.
• Ne pas perturber l’itération : il est impossible d’arrêter un programme en cours pour y ajouter une chemise oubliée. L’itération ne doit pas être perturbée non plus.

On pourrait rajouter qu’il faut éviter de mélanger les couleurs et les domaines métier, sinon le résultat pourrait déteindre !

RIA

X2O framework ou comment faciliter la réalisation d’applications Flex.

Après Exadel Flamingo, voici un nouveau framework nous facilitant le développement d’applications Flex : X2O. Dans cet article, InfoQ interroge Ka Wai Cheung de We Are Mammoth sur ce nouvel outil. X2O est une plateforme permettant de réaliser des applications Flex sans toucher au code de la partie serveur. Grâce à ce framework, nous n’avons plus aucune intégration à réaliser, pas de base de données à mettre en place. Tout est géré par le framework.

Il suffit pour cela de se créer un compte sur http://www.x2oframework.com/# puis de créer un modèle de données et de le soumettre à X2O.

Celui ci va ensuite générer :

• Un CMS sécurisé permettant de gérer les données.
• Un fichier SWC contenant les value objects du modèle de données ainsi que les CRUDs basiques et les méthodes de chargement qui ont été configurés dans le CMS.
• La documentation ActionScript 3 du projet.

Le CMS généré comprend une base de données, des procédures stockées, une couche d’accès aux données et une couche web service. Il est hébergé par le site et à tout moment, le développeur peut modifier son modèle de données dans le CMS et régénérer la librairie swc et la documentation ActionScript 3. La librairie fournit également des fonctionnalités supplémentaires comme l’envoi d’email et l’upload de fichiers. La plus grosse tâche est maintenant de créer son application Flex et d’appeler les méthodes du fichier swc pour charger les bonnes données.

Actuellement la version bêta est disponible et gratuite pour les développeurs. Ces derniers pourront donc tester ce framework (limité à deux projets par compte), donner leur avis et remonter des anomalies. La version définitive prévue en 2009 comportera probablement une version gratuite et une version payante sur plusieurs niveaux.

Pivot 1.0 : développer des applications RIA en Java et XML

Pivot est un framework Open Source pour le développement des applications RIA en Java. Ce dernier est le fruit d’un travail de l’équipe R&D de VMware, il fournit une alternative aux développeurs qui veulent développer leurs applications RIA en Java.

Les applications Pivot sont construites en Java et XML. La structure de l’interface utilisateur est décrite au format XML avec un langage de description d’écrans appelé WTKX, la gestion des événements et la logique applicative sont écrites en Java.

Pivot semble familier aux développeurs Swing, comme les deux utilisent Java2D et se basent sur une architecture MVC pour une séparation entre les données, la présentation et les traitements. Pivot fournit des composants graphiques dynamiques et réutilisables (panneaux, boutons, tables/grilles, boîtes de dialogues, menus et barres de menus …) pour créer des applications web de nouvelle génération.

Les applications Pivot peuvent s’exécuter à l’intérieur d’un applet java ou à déployer en local, tous systèmes d’exploitation confondus.

Le code source du projet est fourni sous licence Apache Version 2.0.
Une démo de Pivot en action : http://pivot-toolkit.org/tutorials/demo.standalone.html.

Testez vos applications Flex avec Fluint

Lors de l’une de nos récentes revue de presse nous vous parlions de FlexMonkey, outil permettant d’enregistrer des tests fonctionnels à la manière d’un Selenium, mais sur des applications Flex.

Dans cet article de Moxie Zhang, un autre outil nous est proposé et se nomme Fluint. A l’origine développé chez Digital Primates, cet outil est passé Open Source et permet de mettre en place des tests unitaires ainsi que des tests d’intégrations. En effet la majorité des outils ne permettent pas de tester les interactions (souvent asynchrones) entre les composants, et Fluint permet d’effectuer ce genre de tests.

La documentation pour la mise en place est bien fournie, et permet de créer assez rapidement des suites de tests.

A travers ces outils, nous voyons que les technologies RIA, et plus particulièrement Flex remportent de plus en plus de succès, alors qu’attendez vous pour franchir le pas ?

Le coin de la technique

Envers rejoint Hibernate

Peu de temps après sa première release officielle, Adam Warski, développeur principal de JBoss Envers, a annoncé cette semaine sur son blog l’intégration de ce framework de versioning d’entités comme module d’Hibernate. S’il n’apparaît pas encore sur la page officielle du projet, les sources ont d’ores et déjà été migrées sur le repository d’Hibernate. Aucun tag Hibernate ne dispose d’Envers pour le moment. Son intégration n’est d’ailleurs pas complètement terminée, quelques modifications restent à régler avant sa première release sous ce nouveau nom. Par exemple, l’annotation @Versioned sera renommée @Audited pour éviter toute confusion avec @Version de JPA. La première version d’Hibernate proposant les fonctionnalités d’Envers devrait donc être la future 3.4.

Pour mémoire, Envers vous permet de versionner simplement la plupart de vos mappings JPA et Hibernate. A l’image de Subversion, il offre un mécanisme de révisions et un moyen d’effectuer des recherches sur son historique.

Evènements de notre communauté en France et à l’étranger

GWT au Paris JUG de Novembre

Le prochain Paris JUG se tient demain 4 Novembre, dans les locaux de l’ISEP.

Au programme de la soirée:

• Une présentation de Google Web Toolkit, par Didier Girard, directeur technique de SFEIR.
• Puis une démonstration de l’API Restlet portée sur GWT, Restlet-gwt, par Jérôme Louvel, l’auteur de Restlet.

XKE, le programme de la session de Novembre

Le prochain XKE (Xebia Knowledge Exchange) aura lieu le jeudi 6 Novembre 2008. Les sujets suivants seront abordés :

• WSI-Basic profiles.
• Java Rebel.
• La galaxie GWT, un tour d’horizon des projets qui gravitent et améliorent le célèbre framework de Google.
• DDD – Domain Driven Design.
• Liquid Base, un outil qui gère les modifications de schéma de base de données.
• Spring Dynamic Modules, l’OSGI vu à la sauce Spring.
• Les outils de la JVM.

Comme nous l’annoncions, les XKE sont ouverts à l’ensemble des personnes à l’écoute du marché de l’emploi autour des technologies Java/J2EE. Si vous êtes l’une d’entre elles, n’hésitez pas à contacter Mélanie Bacrot pour vous inscrire.

Le scaffolding fait le bonheur des rubyistes en leur permettant, au prix de l’exécution de quelques lignes de commandes, de disposer d’une application web opérationnelle, autorisant la manipulation élémentaire des données de leur modèle au travers d’écrans de saisie et de listes – charge au développeur d’enrichir ensuite le code généré pour implémenter un comportement plus sophistiqué.

Le projet AppFuse, aujourd’hui dans sa version 2.0, s’appuie sur les archétypes Maven 2 pour offrir aux développeurs Java des fonctionnalités équivalentes. Dans cet article, nous vous proposons une introduction par l’exemple à AppFuse.

Maven : rappels

Pour ceux qui ne sont pas encore familiers avec Maven, voici quelques rappels de base pour pouvoir suivre cet article.

Maven est un outil open-source de build pour les projets Java. Il a été conçu pour simplifier les tâches difficiles du processus de build. Maven offre la possibilité de démarrer un projet en utilisant des squelettes d’application. Ces squelettes, dans la terminologie Maven, sont appelés « archétypes ». Grâce à eux, une ligne de commande permet de démarrer avec une hiérarchie de répertoire standardisée (sources, resources, builds).

Tous les archétypes Maven comportent un fichier « pom.xml » contenant toutes les directives de construction du projet, ses dépendances et différents plugins accessibles. Les plugins Maven couvrent, entre autres, des outils d’analyse de code, de formatage et de génération de rapport.

Pour plus d’informations sur ces notions, je vous conseille de jeter un oeil sur les sites suivants :

• Maven : http://maven.apache.org/
• Plugin d’intégration Maven/Eclipse : http://m2eclipse.codehaus.org/
• Mojo Project (plugins Maven) : http://mojo.codehaus.org/

AppFuse

Concept

Initialement créé par Matt Raible, AppFuse est un projet open source pour développer des applications web J2EE. Il permet aux développeurs de démarrer rapidement et facilement en utilisant des technologies open-source telles que Spring, Hibernate et différents frameworks web (Struts2, Spring MVC, Tapestry, …).

AppFuse est un ensemble de scripts de génération de code permettant de faire le travail le plus pénible très rapidement, typiquement les écrans CRUD (Create, Read, Update, Delete) de votre modèle de données.

Utilisation

Initialement conçu avec Ant, Appfuse s’appuie, depuis sa version 2, sur Maven via des archétypes et des plugins de génération de code.

Archétypes Maven

Les différents archétypes fournis par le projet AppFuse couvrent différents frameworks Web, couplés avec Hibernate et Spring :

• JSF
• Struts2
• Spring MVC
• Tapestry

AppFuse propose pour tous ces outils de généré un projet d’application simple ou un projet multi-modules contenant un projet noyau et des projets modulaires. Il est également possible de générer uniquement le backend d’application. Vous pourrez brancher dessus votre framework préféré.

Chaque archétype AppFuse crée une application complète comprenant :

• la gestion de la sécurité
• une interface d’administration des utilisateurs et des rôles.
• plusieurs thèmes CSS
• la création automatique de la base de données
• la population automatique de la base avec un jeu de données de test.

Plugins de génération de code

Une fois votre projet démarré avec l’archétype de votre choix, vous pourrez ajouter vos beans de données et les mapping Hibernate associés selon la méthode que vous préférez (annotations ou fichiers hbm.xml).

Une fois votre modèle posé, le plugin Maven « appfuse:gen » s’occupera pour vous de créer les classes de DAO, Managers et vues correspondantes pour obtenir les écrans de gestion élémentaires (CRUD).
Chaque lancement du plugin se fait sur une classe du modèle de données et fournit :

• une vue avec un tableau triable contenant l’ensemble des instances persistées en base
• un formulaire de saisie/suppression
• un jeu de données pour les tests
• les DAO et Managers associés

Conformément aux principes du scaffolding, la génération de code et de configuration possède ses limites et il est souvent nécessaire d’effectuer quelques corrections manuelles lorsque le modèle de données est un peu évolué.

Par exemple, dans le cas de relations ManyToOne, le formulaire de saisie d’un bean doit comporter une liste permettant de sélectionner avec quel objets faire le lien. Ce cas nécessite de faire des modifications dans l’Action Struts pour que la liste s’affiche effectivement dans le formulaire web. Nous allons voir ce genre de manipulation dans la partie pratique.

Hands-on : Hibernate, Spring, Struts2

Un bon exemple valant souvent mieux qu’un long discours, nous vous proposons de créer pas à pas une application web simple, permettant de saisir des constructeurs automobiles et des voitures liées à ces constructeurs.

L’environnement technique est le suivant :

• Struts 2
• Java 5
• Maven (>= 2.0.6 mais 2.0.9 est plus sûr pour les corrections sur les classpaths )
• accès au web depuis le poste de développement

Démarrage du projet

Création de notre squelette de projet avec l’archétype appfuse-basic-struts :

mvn archetype:create -DarchetypeGroupId=org.appfuse.archetypes
-DarchetypeArtifactId=appfuse-basic-struts
-DremoteRepositories=http://static.appfuse.org/releases
-DarchetypeVersion=2.0.1
-DgroupId=fr.xebia.blog.voiture -DartifactId=voiture-app

Un répertoire « voiture-app » contenant notre squelette applicatif vient d’apparaître. Les amateurs d’Eclipse pourront ajouter :

cd voiture-app
mvn eclipse:eclipse

… pour que Maven créé les fichiers indispensables à Eclipse pour importer le projet.

Les archétype AppFuse placent la majeure partie du code de l’application en dépendances dans le pom.xml.
Pour pouvoir modifier le comportement de l’application et avoir tout sous les yeux, nous devons couper ces dépendances avec AppFuse et rapatrier le code.

Cela se fait très simplement en lançant :

mvn appfuse:full-source

Écriture du modèle

Ajoutons maintenant notre modèle de données. Pour plus de simplicité, nous allons y intégrer directement les annotations utiles à la persistance. Les classes que l’on souhaite passer au générateur de code doivent se trouver directement dans le package « model » du projet. Dans notre cas il s’agit de « fr.xebia.blog.voiture.model ».

Classe : ConstructeurAutomobile

src/main/java/fr/xebia/blog/voiture/model/ConstructeurAutomobile.java

package fr.xebia.blog.voiture.model;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
@Entity
public class ConstructeurAutomobile {
  private Long id;
  private String nom;
  @Id
  @GeneratedValue(strategy=GenerationType.IDENTITY)
  public Long getId() {
    return id;
  }
  public void setId(Long id) {
    this.id = id;
  }
  @Column(length=50)
  public String getNom() {
    return nom;
  }
  public void setNom(String nom) {
    this.nom = nom;
  }
}

Classe : Voiture

src/main/java/fr/xebia/blog/voiture/model/Voiture.java

package fr.xebia.blog.voiture.model;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.JoinColumn;
import javax.persistence.ManyToOne;
@Entity
public class Voiture {
  private Long id;
  private String nom;
  private ConstructeurAutomobile constructeur;
  @Id
  @GeneratedValue(strategy=GenerationType.IDENTITY)
  public Long getId() {
    return id;
  }
  public void setId(Long id) {
    this.id = id;
  }
  @Column(length=50)
  public String getNom() {
    return nom;
  }
  public void setNom(String nom) {
    this.nom = nom;
  }
  @ManyToOne
  @JoinColumn(name="constructeur_id")
  public ConstructeurAutomobile getConstructeur() {
    return constructeur;
  }
  public void setConstructeur(ConstructeurAutomobile constructeur) {
    this.constructeur = constructeur;
  }
}

Génération des CRUD

Maintenant que nous disposons des classes, nous pouvons lancer la génération des écrans CRUD :

mvn appfuse:gen -Dentity=ConstructeurAutomobile
mvn appfuse:gen -Dentity=Voiture

N.B. : Si vous omettez l’option -Dentity le nom de la classe ciblée est demandé en prompt.

Le générateur de code comporte cependant une lacune. Les classes sont bien ajoutées aux mappings Hibernate, mais pas pour les tests unitaires. Par conséquent, un mvn test tombera en erreur.

Le palliatif à cela est de copier les lignes de mapping dans :

src/main/resources/hibernate.cfg.xml

<hibernate-configuration>
    <session-factory>
        <mapping class="fr.xebia.blog.model.User"/>
        <mapping class="fr.xebia.blog.model.Role"/>
<!-- Les deux lignes suivantes nous intéressent -->
        <mapping class="fr.xebia.blog.voiture.model.ConstructeurAutomobile"/>
        <mapping class="fr.xebia.blog.voiture.model.Voiture"/>
<!-- Stop, pas plus loin, deux lignes seulement -->
    </session-factory>
</hibernate-configuration>

et de les coller dans le fichier src/test/resources/hibernate.cfg.xml pour garder ces deux fichiers en phase.

Vous pouvez le vérifier par vous même en lançant :

mvn clean test -P hsqldb

{quote}
Plusieurs profils de base de données sont disponibles dans le pom.xml fourni par AppFuse (MySQL, PostgreSQL, Oracle, etc). Par souci de simplicité nous utilisons ici HSQLDB.
{quote}

Support du lien ManyToOne

Le générateur AppFuse, bien que pratique, n’est pas omnipotent. Nous avons donc quelques manipulations à réaliser manuellement pour que le formulaire de saisie d’une Voiture soit complet.

Dans le fichier src/main/webapp/WEB-INF/pages/voitureForm.jsp vous pouvez voir cette ligne :

<s:select name="voiture.constructeur.id" list="constructeurList" listKey="id" listValue="id"></s:select>

Il s’agit du tag Struts qui affiche la liste de sélection des constructeurs. Cependant, la classe VoitureAction, générée, ne fournit pas cette liste à la JSP, qui restera en conséquence désespérément vide à l’exécution. Notons également que par défaut, AppFuse affiche l’identifiant de l’entité dans la liste – ce qui ne correspond qu’exceptionnellement au besoin. Remplaçons la valeur de l’attribut listValue du tag select par « nom ». Ainsi, le nom du constructeur sera présenté dans la liste de sélection, plutôt que son identifiant.

Attaquons-nous au support de cette fameuse liste. Nous allons rajouter ceci au fichier :

src/main/java/fr/xebia/blog/voiture/webapp/action/VoitureAction.java

[...]
import fr.xebia.blog.voiture.model.ConstructeurAutomobile;
[...]
  private GenericManager constructeurAutomobileManager;
  public void setConstructeurAutomobileManager(GenericManager constructeurAutomobileManager) {
    this.constructeurAutomobileManager = constructeurAutomobileManager;
  }
  public List getConstructeurList () {
    return (List) constructeurAutomobileManager.getAll();
  }
[...]

Comme l’attribut que nous rajoutons respecte les conventions de nommage et que la configuration Spring générée par AppFuse est correcte, l’injection de dépendances se fait automatiquement pour le constructeur AutomobileManager.

La méthode getConstructeurList, quant à elle, sera appelée par la JSP pour obtenir le contenu de la liste de sélection.

Démarrage

Nous pouvons maintenant effectuer un premier lancement de notre application grâce au plugin Jetty de Maven. :

mvn jetty:run-war -P hsqldb

Je vous laisse faire le tour du propriétaire en allant avec votre navigateur web sur localhost:8080 pour vous mettre l’eau à la bouche, voici une liste non exhaustive de tout ce que nous avons obtenu en une demi-heure de travail :

• filtres de sécurité
• gestion des utilisateurs en base
• envois de mail en cas d’oubli d’un mot de passe ou de création de compte
• écrans CRUD pour les constructeurs automobiles
• écrans CRUD pour les voitures
• un jeu de données inséré à chaque lancement des tests
• export des listes de constructeurs et de voitures en CSV, XLS, PDF ou XML (Merci à DisplayTag)
• une CSS propre (ça fait toujours plaisir)
• une foule de plugins très utiles placés dans le pom.xml : Cobertura, PMD, DBunit et d’autres
• le support de l’internationalisation

Et j’en oublie.

Conclusions

AppFuse est, à mon avis, un excellent plugin Maven pour démarrer un projet d’application Web classique. Il n’est pas très polyvalent mais permet de se libérer d’une part assez fastidieuse du développement web : l’écriture des CRUD.

Le squelette d’application standardisé permet de s’y retrouver rapidement quand on gère plusieurs applications et de respecter un bon découpage des fichiers de configuration.

En fait ce plugin en fournit presque trop : trois semaines après je trouvais encore des morceaux de code inutilisés provenant du squelette, et qui m’ont facilité la vie, notamment pour l’exposition de WebServices grâce à XFire.

À mon avis un très bon outil, bien ciblé, à essayer.

Quelques ressources complémentaires :

• Seven simple reasons to use AppFuse par Matt Raible
• AppFuse QuickStart

Actualité éditeurs / SSII

• Hibernate 3.3 sous le signe de Maven et de JBoss Cache

Agilité

• Scrum-ban

Le coin de la technique

• AMQP, l’avenir des Middlewares Orientés Message ?
• Performance et monitoring d’une application Java

Actualité éditeurs / SSII

Hibernate 3.3 sous le signe de Maven et de JBoss Cache

Steve Ebersole, JBoss, présente dans Hibernate 3.3: Redesigned, Modular JARs and a Refactored Caching System les grandes nouveautés de la version 3.3 du célèbre framework de persistence. Nous retiendrons :

• La migration du projet vers un nouveau build basé sur Maven 2 alors que JBoss semblait jusqu’ici réticent à cet outil de la fondation Apache.
• La modularisation du monolythique hibernate.jar vers un ensemble de jars plus petits qui faciliteront la gestion des dépendances.
• Le redesign du système de cache de second niveau, pour offrir aux utilisateurs un contrôle plus fin de celui ci à travers une nouvelle SPI. Cette nouvelle SPI introduit le partitionnement du cache par ‘région’.
• L’intégration de JBoss Cache 2.x comme cache de second niveau, utilisant cette nouvelle SPI en exploitant le nouveau mécanisme de partitionnement. A noter que JBoss Cache 2.x est le seul cache supporté nativement par cette nouvelle SPI, les autres implémentations (EHCache, etc) étant ‘bridgées’ sur l’ancienne SPI aujourd’hui dépréciée.

On notera aussi que JBoss, jusqu’ici agnostique avec JBoss Micro Container, s’ouvre à OSGI avec l’appel de Steve Ebersole à la communauté pour participer à l’osgi-fication d’Hibernate (en réglant les problèmes de classloading et de redéfinition dynamique de la SessionFactory déclarés dans Jira)

Sur le futur d’Hibernate, Steve Ebersole reste flou et rappelle que JBoss communique peu sur les roadmaps. On peut y voir le mode de gouvernance exclusive des projets open source de JBoss à la différence des gouvernances partagées que nous connaissons notamment avec la Fondation Apache qui débat de ces sujets sur les mailing lists publiques. Nous noterons deux des axes de travail pour la futures version 3.4 :

• Amélioration des performances et de l’utilisation des ressources dans le cadre des scénarios de fail over en cluster. On peut y voir des synergies avec les travaux menés sur JBoss Application Server 5 et JBoss Cache.
• Introduction des « fetch profiles » qui rappellent JDO . Ces profiles permettent de définir des stratégies de requêtage en tant que metadata, et de les utiliser dynamiquement en Session à l’exécution.

L’intégralité de l’article à lire sur InfoQ.

Agilité

Scrum-ban

Corey Ladas propose aux équipes Scrum d’évoluer vers le Lean en introduisant un système de Kanban.

Le tableau des tâches utilisé par certaines équipes Scrum (avec les 3 colonnes A faire, En cours, Terminée) peut en effet rappeler le système des Kanban utilisé dans les méthode de gestion de la production Juste à temps (JAT).
Corey propose de compléter ou de remplacer certaines pratiques Scrum pour aller vers un vrai Kanban :

• Limiter le nombre de fiches (user stories) en circulation pour éviter d’avoir un tas de fiches « en cours »
• Amorcer une spécialisation fonctionnelle si le contexte s’y prête (si elle permet d’améliorer la productivité)
• Remplacer le Burndown chart par un Cumulative Flow Diagram qui apportent d’avantage d’informations

Il affirme également que la plupart des efforts dépensés dans les estimations sont du gâchis. Il rejoint ainsi le débat initié par J.B. Rainsberger sur le groupe Yahoo! extreme programming.

Au final Corey présente Scrum comme un cadre pouvant être utile à la construction d’une équipe avant d’aller vers une solution plus optimisée grâce au Kanban et au Lean.

Le coin de la technique

AMQP, l’avenir des Middlewares Orientés Message ?

Jeff Gouyd, Interop Systems, présente dans Can AMQP break IBM’s MOM monopoly? (part 2 et part 3) les grands enjeux de l’initiative AMQP (Advanced Message Queuing Protocol). Les points essentiels :

• AMQP vise à standardiser le protocole de transport des « middleware orientés message » (MOM) ; son objectif, très ambitieux, est de devenir le protocole le business messaging sur Internet à côté d’HTTP et de SMTP.
• Le marché des MOM est aujourdhui dominé par IBM (Websphere MQ) et Tibco (RendezVous et EMS) qui totalisent 93% des parts de marché selon Gartner ; le troisième acteur, Progress Software (Sonic MQ) ne détient que 2% du marché. Beaucoup de clients estiment qu’IBM et Tibco profitent de leur position pour pratiquer des tarifs élevés et être peu enclin à l’interropérabilité.
• AMQP a été initié par un client, JP Morgan Chase (JPMC) ; la version 1 du protocole est attendue pour la fin 2008 et les principales implémentations, toutes open source, sont OpenAmq (développé par iMatix pour JPMC), Apache QPid (ardement supporté par RedHat) et RabbitMQ (LShift et CohesiveFT.
• AMQP et JMS : JMS standardise l’API Java d’accès à un MOM quand AMQP standardise le protocole de communication du MOM. Ces deux standards sont complémentaires, il y aura des connecteurs JMS pour AMQP comme il en existe aujourd’hui pour Websphere MQ et pour Tibco EMS.
• AMQP et WS-RM (Reliable Messaging) : WS-RM a été introduit pour pallier au manque de fiabilité intrinsèque à HTTP alors qu’AMQP est un protocole qui intègre nativement la fiabilité ; il y a donc chevauchement. Les grandes différences d’AMQP par rapport à WS-RM sont le concept de file d’attente et le support de messages binaires. La participation de Paul Fremantle, président du comité du WS-RM à l’Oasis Group, à l’AMQP Working Group laisse augurer des synergies.
• AMQP et ESB : les ESB utilisent traditionnellement un MOM pour leur couche transport ; AMQP se positionne comme le protocole possible du MOM sous-jacent d’un ESB. Par exemple, l’implémentation AMQP RabbitMQ annonce avoir séduit des clients initialement intéressés par Websphere MQ comme transport pour leur ESB Mule.

Performance et monitoring d’une application Java

Dans un précédent article, nous vous avons présenté le top 10 des problèmes de performance.

Nicholas Whitehead présente dans Java Runtime Monitoring (part 1, part 2 et part 3) un guide sur le monitoring et la démarche d’évaluation de performance d’une application Java.

La gestion des performances applicatives suit des bonnes pratiques (APM, application performance management). Elle doit être :

• Exhaustive : tous les éléments applicatifs et leurs dépendances doivent être monitorés. Cela va de l’application au matériel, en passant par le système d’exploitation ,les différents middlewares, et toute la chaine réseau.
• Précise : afin de localiser au mieux la source des problèmes, il faut des mesures en boite blanche. Si les mesures sont faites en boîte noire (par exemple au niveau de la JVM), le problème ne pourra pas être identifié et les pistes seront nombreuses (problème mémoire, thread, garbage collector, configuration de la JVM…).
• Cohérente : un problème a, la plupart du temps, des causes multiples. Il faut relier les causes entre elles mais aussi les lier aux conséquences. Par exemple, un problème de base de données peut être remonté par les logs applicatives.
• Constante : le monitoring doit être effectué 7 jours sur 7, 24 heures sur 24. De plus, les intervalles de relevé de mesures doivent être suffisamment courts pour ne pas avoir un manque d’information. Attention cependant à l’overhead.
• Efficace : La règle d’or du monitoring est que les outils de monitoring doivent avoir un overhead minimal et garanti. Il est difficile de justifier une dégradation des performances dûe aux outils de monitoring.
• (proche du) temps-réel : selon le besoin de réactivité, les mesures doivent être collectées le plus rapidement possible.
• Tracée : Historisation, souvent négligé, est un outil très intéressant pour exploiter les applications J2EE. En effet, un problème de performance apparait dans un contexte défini (généralement de charge). Grâce à l’historisation des mesures et des problèmes, on peut caractériser repérer un problème identifié et (éventuellement) résolu. Ainsi les futures apparitions de ce problème pourront être anticipées.

Ainsi les difficultés du monitoring résident essentiellement dans :

• L’exhausitivité et la précision des informations relevées.
• L’intégration et l’articulation de sources d’information hétérogènes et nombreuses (matériel, OS, logs applicatives..)
• La gestion des spécificités de la plate-forme (spécificités applicatives, infrastructure réseau…)

Depuis la JVM 5 et surtout 6, Sun fournit beaucoup d’efforts afin de résoudre ces problèmes de performance et de monitoring sur la partie JVM. Plusieurs outils et techniques sont maintenant à votre disposition pour réaliser différentes mesures :

• API JMX, pour le monitoring à distance
• API d’instrumentation du code afin de réaliser des mesures boites blanches (java.lang.instrument)
• Un panel d’outils : hprof pour le profiling heap/CPU, jconsole pour la gestion et monitoring de la JVM (à distance), jhat pour l’analyse de la heap, jstat pour collecter des informations de performance sur la JVM, VisualVM …

Retrouvez l’intégralité des articles :

• part 1 : Run-time performance and availability monitoring for Java systems
• part 2 : Postcompilation instrumentation and performance monitoring
• part 3 : Monitoring performance and availability of an application’s ecosystem

Actualité éditeurs / SSII

• MySQL by Sun : Revirement de stratégie open source ? Choquant ?
• Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

Agilité

• User stories « En tant que … je veux … »

Le coin de la technique

• De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent
• Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers
• Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid
• JSR-311 JAX-RS REST une histoire de RESTaurant

Evènements de notre communauté en France et à l’étranger

• XKE, le programme de la session de mai

Actualité éditeurs / SSII

MySQL by Sun : Revirement de stratégie open source ? Choquant ?

Slashdot essaie de nous emmener sur une polémique « Sun gâche MySQL » avec Sun May Begin Close Sourcing MySQL Features à l’occasion de l’annonce par l’éditeur de fonctionnalités (online backup, etc) qui seront uniquement disponibles dans la version payante MySQL Enterprise. Au delà de l’insinuation peu crédible quand on se rappelle que l’essentiel du catalogue de Sun est disponible gratuitement, on retrouve le défi aujourd’hui classique de la monétisation de l’Open Source. Le rachat de MySQL par Sun change complétement le modèle économique de l’éditeur de base de données.

Hier, la startup MySQL, financée par des fonds de capital risque, se permettait d’être déficitaire car les candidats au rachat (Oracle puis finalement Sun) ne valorisaient pas MySQL Inc sur ses revenus mais sur les parts de marché de sa base de données. La stratégie a magnifiquement porté ses fruits puisque MySQL Inc s’est vendue un milliard de dollars à Sun, félicitations au management.

Aujourd’hui, MySQL est vraisemblablement devenue une division ‘classique’ de Sun et doit donc devenir rentable. L’équation de la rentabilité de l’open source est complexe, Red Hat et JBoss by Red Hat ont été des pionniers sur ce chemin, souhaitons à MySql by Sun de trouver lui aussi son modèle.

TSS : MySQL to get new features in Enterprise version

Modification du billet le 29 Avril 2008 : Jonathan Schwartz est finalement revenu en arrière et a annoncé que tous les produits que Sun distribue, sans exception, sont proposés gratuitement en licence Open source à la communauté. Pour plus de détails sur cette histoire, nous vous recommandons la série de The 451 Group : MySQL’s business model in a state of flux, Finding the right balance – MySQL’s changing development model et Jonathan Schwartz has the last word on MySQL

Superpackages (JSR-294) vs. OSGI : Episode n° 34291567….

La guerre continue entre les partisans de OSGI et ceux des JSR de SuperPackage et de JAM. Cependant, l’attaque vient cette fois-ci d’Alex Buckley de chez Sun.

Il explique dans son email les inconvénients qu’il voit dans l’implémentation actuelle des superpackages[1]. En substance, il propose d’introduire à la place un nouvel ‘access modifier’ (module).

Peter Kriens de l’OSGi Alliance semble plutôt emballé par cette proposition.

[1] Pour mémoire, nous avons publié en février dernier un article présentant les superpackages

Agilité

User stories « En tant que … je veux … »

Mike Cohn nous rappelle les 3 raisons pour lesquelles il préconise de décomposer les user stories sous forme de phrase « En tant que <role>, je veux <but>, pour que <raison> » (la raison est optionnelle) :

• L’emploi de la 1ère personne du singulier aide les développeurs à s’identifier à l’utilisateur
• La structure de la phrase – représentée par 3 colonnes dans le Product backlog – aide le Product Owner à comprendre et prioriser les user stories
• Pour ne pas rajouter de bruit dans la description des user stories, il suffit de nommer les colonnes du Product backlog « En tant que … », « je veux … », « pour que … » et le backlog devient intuitif à lire.

Le coin de la technique

De la sérialisation au parallélisme, une évolution incarnée par java.util.concurrent

La programmation multi-threadée en java a évoluée : anciennement on utilisait la sérialisation incarnée par synchronized, désormais on peut faire du parallélisme avec l’introduction des API java.util.concurrent en Java 5.

Sharadjava nous présente dans sa Java Concurrency Series les différents aspects de cette nouvelle librairie :

• Simple Executor example pour la parallélisation des tâches.
• Barrier pour l’attente entre tâches (on n’oubliera pas sur ce sujet le CountDownLatch).
• Meaning of volatile pour la visibilité inter-threads des valeurs des variables.

Innovation autour de JPA : JBoss Hibernate confirme son domination avec Envers

Après l’intégration de la recherche full text Lucene [1] et le support du Database Sharding, Hibernate confirme sa domination de l’innovation autour de JPA en ouvrant le chantier du versionnage des données. Cette problématique, bien que récurrente et accentuée par les nouvelles contraintes réglementaires (Sarbane & Oaxley, etc), restait largement ignorées par nos frameworks et nos très chers design patterns. Seul Martin Fowler nous éclairait sur ce sujet délicat avec Patterns for things that change with time.

JBoss comble aujourd’hui ce vide en lançant Envers, une extension d’Hibernate qui versionne les données persistantes selon un pattern similaire au Temporal Object de Martin Fowler. Envers n’est qu’en version preview mais le projet est très prometteur et déjà une source d’inspiration pour les projets qui n’ont pas le temps d’attendre la première version stable.

On notera au passage qu’Envers préfère l’API standard JPA EntityManager à l’historique Session Hibernate ; on peut y voir un signe que le temps est venu pour les équipes projets de privilégier les standards JPA aux API historiques Hibernate.

Exemple d’entité persistante versionnée avec JBoss Envers

@Entity
public class Person {
    @Id
    @GeneratedValue
    private Integer id;
    @Versioned
    private String name;
    @Versioned
    private String surname;
    @Versioned
    @ManyToOne
    private Address address;
   ...
}

[1] cf notre billet Introduction à Hibernate Search (Googling your Persistent Domain Model)

Cas d’utilisation des grilles Java avec WebSphere eXtreme Scale/ ObjectGrid

Billy Newport présente dans Video: Introduction to WebSphere eXtreme Scale/ObjectGrid with patterns and use cases les scénarios typiques d’utilisation de la grille Java d’IBM :

• Cache de proximité classique : la grille sert de Map distribuée ; l’application métier gère les données (chargement depuis les backends, mise en cache et sauvegarde des modifications dans les backends).
• Cache de proximité avec « Loader synchrone » dans la grille : l’application métier se limite à demander des données à la grille et à les modifier ; la grille, grâce à un Loader, s’occupe de charger les données depuis les backends et sauvegarde en synchrone les données modifiées dans les backends.
• Cache de proximité avec un « Loader à écriture différée » dans la grille : similaire au scénario précédent mais la sauvegarde des modifications dans les backends est asynchrone.
• Cache collocalisé : l’application et la grille s’éxécutent dans les même JVM, chaque JVM héberge un noeud du cluster de l’application et un noeud de la grille. Ce scénario est typique de la mise en cache des sessions HTTP.

On notera que les architectures de type Map/Reduce, qui nécessitent une conception radicalement différente, ne semblent pas encore très répandues.

JSR-311 JAX-RS REST une histoire de RESTaurant

Dans cet article, Nicolas Martignole nous présente l’architecture REST (Representational State Transfer) et JSR 311: JAX-RS: The Java API for RESTful Web Services. L’objectif de cette JSR est de faciliter la programmation d’applications REST en Java.
La première partie est consacrée à une introduction de REST (définition d’une ressource, lecture, création, mise à jour, suppression d’une ressource, Services Webs RESTfull).
La deuxième partie nous présente quelques détails sur l’implémentation JAX-RS avec Java.

Evènements de notre communauté en France et à l’étranger

XKE, le programme de la session de mai

Le prochain XKE (Xebia Knowledge Exchange) aura lieu le mardi 6 Mai 2008. Les sujets suivants seront abordés :

• Sessions Pratiques
  • Terracotta, the Network Attached Memory (NAM)
  • java.util.concurrent, concours de developpement

• Technique
  • Java et la Cryptographie

• Architecture
  • Retour sur l’architecture de l’un des plus grand site de ecommerce de France
  • Tests unitaires avec les librairies de Mock

• Xebia Hollande
  • Intervention du CTO de Xebia Hollande

Comme nous l’annoncions, les XKE sont ouverts à l’ensemble des personnes à l’écoute du marché de l’emploi autour des technologies Java/J2EE. Si vous êtes l’une d’entre elles , n’hésitez pas à contacter Mélanie Bacrot pour vous inscrire.

Ce billet présente, au travers d’un exemple simple, les capacités de recherche full-text d’Hibernate Search.
L’exemple proposé permet l’indexation et la recherche de documents auxquels sont attachés des auteurs.
Vous retrouverez l’ensemble des sources présentées dans ce billet dans le repository SVN de Xebia France.

Structuration du projet et démarrage

Le projet utilise maven. Une fois les sources récupérées depuis notre dépot SVN, vous pouvez donc générer une configuration Eclipse à l’aide de la commande :

mvn eclipse:eclipse

Le projet déclare des dépendances vers :

• hibernate-search en version 3.0.0.ga.
• hibernate-annotations en version 3.3.0.ga.
• hibernate-entitymanager en version 3.3.1.ga.
• lucene-analyzers en version 2.3.1.

<dependency>
	<groupId>org.hibernate</groupId>
	<artifactId>hibernate-search</artifactId>
	<version>3.0.0.ga</version>
</dependency>
<dependency>
	<groupId>org.hibernate</groupId>
	<artifactId>hibernate-annotations</artifactId>
	<version>3.3.0.ga</version>
</dependency>
<dependency>
	<groupId>org.hibernate</groupId>
	<artifactId>hibernate-entitymanager</artifactId>
	<version>3.3.1.ga</version>
</dependency>
<dependency>
	<groupId>org.apache.lucene</groupId>
	<artifactId>lucene-analyzers</artifactId>
	<version>2.3.1</version>
</dependency>

Le projet est structuré sur l’arborescence classique maven :

• src\main\java contient les sources du projet :
     - Le package fr.xebia.demo.hibernate.search.model contient les entités persistées qui seront mappées dans un index Lucene.
     - Le package fr.xebia.demo.hibernate.search.analysis contient un analyseur de langue anglaise.
• src\main\test contient les sources des tests. Les tests « unitaires » ont ici été détournés pour faire la démonstration des capacités d’indexation et de recherche full-text d’Hibernate Search.

Mapping des entités sur l’index

Le mapping des entités dans un index Lucene se fait par annotation :

• L’annotation @Indexed déclare une classe comme indexable
• L’annotation @Analyzer définit l’implémentation d’analyseur syntaxique à utiliser pour cette indexation :

@Entity
@Indexed
@Analyzer(impl = SimpleEnglishAnalyzer.class)
@Table(name = DOCUMENT_TABLE_NAME)
public class Document {

• L’annotation @DocumentId indique l’attribut à utiliser en tant qu’identifiant. Cet identifiant est utilisé par Hibernate Search afin d’assurer l’unicité des entités dans l’index :

@Id
@DocumentId
@Column(name = "id", nullable = false)
public Long getId() {
	return this.id;
}

• L’annotation @Field marque un attribut comme devant être indexé. La propriété index = Index.TOKENIZED indique que le texte va être « tokenisé » via l’analyseur définit au niveau de la classe. La propriété store = Store.NO indique que le texte de l’attribut ne sera pas stocké dans l’index.

@Column(name = "title")
@Field(index = Index.TOKENIZED, store = Store.NO)
public String getTitle() {
	return title;
}
@Column(name = "summary")
@Field(index = Index.TOKENIZED, store = Store.NO)
public String getSummary() {
	return summary;
}

• Dans le cadre d’une association, l’annotation @IndexedEmbedded indique que l’objet associé doit être indexé dans l’index de l’entité racine. Dans notre exemple, cette méthode permet d’effectuer une recherche full-text sur les entités de type Document basée sur les propriétés de son attribut author :

@ManyToOne(cascade = { CascadeType.PERSIST, CascadeType.MERGE,
		CascadeType.REFRESH }, fetch = FetchType.EAGER)
@JoinColumn(name = "author_id")
@Fetch(FetchMode.JOIN)
@ForeignKey(name = "fk_document_author_id")
@IndexedEmbedded
public Author getAuthor() {
	return author;
}

Analyseur et tokeniseur

La « tokenisation » consiste à découper un texte en mots. Ce découpage se fait en suivant les règles définies dans un analyseur. Hibernate Search propose par défaut l’utilisation de org.apache.lucene.analysis.standard.StandardAnalyzer.
Il est possible de définir son propre analyseur en étendant la classe abstraite Analyzer dont il faut implémenter la méthode

public abstract TokenStream tokenStream(String fieldName, Reader reader);

C’est ce que propose la classe SimpleEnglishAnalyzer :

@Override
public final TokenStream tokenStream(String fieldName, Reader reader) {
	if (fieldName == null)
		throw new IllegalArgumentException("fieldName must not be null");
	if (reader == null)
		throw new IllegalArgumentException("reader must not be null");
	TokenStream result = new StandardTokenizer(reader);
	result = new StandardFilter(result);
	result = new LowerCaseFilter(result);
	result = new StopFilter(result, stopTable);
	result = new PorterStemFilter(result);
	return result;
}

Cette implémentation passe les mots en minuscule, supprime les mots courants, et utilise le PorterStemFilter pour supprimer les terminaisons morphologiques communes.

Configuration Hibernate Search

La configuration d’Hibernate Search est câblée sur le système d’écoute d’événements. Elle est donc transparente avec Hibernate Annotations.
Dans le cadre de notre exemple, la configuration Hibernate est réalisée dans le set up de la classe HibernateSearchDemoTestCase. La seule propriété de configuration que nous spécifions pour Hibernate Search est le répertoire de stockage des index :

@Override
protected void setUp() throws Exception {
	AnnotationConfiguration cfg = new AnnotationConfiguration();
	[...]
	cfg.setProperty("hibernate.search.default.indexBase", "target");
	[...]
}

Création et indexation des données de test

La création des données de test se fait dans la méthode populateDB de la classe de test (HibernateSearchDemoTestCase). L’indexation des données de test est faite de manière transparente au moment du commit de la transaction :

Transaction tx = this.testSession.beginTransaction();
Author bTate = new Author(
		"Bruce",
		"Tate",
		"Bruce A. Tate is a [...]");
[...]
Document beyondJava = new Document();
beyondJava.setTitle("Beyond Java");
beyondJava
		.setSummary("In Beyond Java, [...]");
beyondJava.setAuthor(bTate);
this.testSession.persist(beyondJava);
[...]
tx.commit();

Recherches full-text sur les entités

La recherche full-text de documents dans l’index se fait au travers de la méthode searchDocuments de la classe de test (HibernateSearchDemoTestCase) :

private List<Document> searchDocuments(String queryString) {
	FullTextSession searchSession = Search
			.createFullTextSession(this.testSession);
	Transaction tx = searchSession.beginTransaction();
	MultiFieldQueryParser parser = new MultiFieldQueryParser(new String[] {
			"title", "summary", "author.lastName", "author.firstName",
			"author.resume" }, new SimpleEnglishAnalyzer());
	FullTextQuery query;
	try {
		query = searchSession.createFullTextQuery(
				parser.parse(queryString), Document.class);
	} catch (ParseException pe) {
		logger.error("Error while parsing query.", pe);
		return new ArrayList<Document>(0);
	}
	List<Document> result = query.list();
	tx.commit();
	return result;
}

Pour effectuer une recherche full-text, il faut :

• Créer une FullTextSession à partir de la session Hibernate.
• Créer un parseur (MultiFieldQueryParser) en lui indiquant les champs sur lesquels la recherche doit avoir lieu et l’analyseur à utiliser pour tokeniser les chaînes de recherche (il est bien évidemment préférable d’utiliser le même que pour l’indexation des documents).
• Créer une requête de recherche full-text à partir de la chaîne de recherche tokenisée.
• Exécuter la méthode list sur la requête.

Hibernate Search retourne alors une liste d’entités « managées ».

Les cas de test

La démonstration peut être lancée via maven avec la commande :

mvn test

Les cas de test proposés sont :

• Recherches simples ("java", "father", "JAVA"):

=====================================================
Simple Test (query == "java"):
Results list:
Document 1: Beyond Java:
   > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 2: From Java to Ruby:
   > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 4: AspectJ Cookbook:
   > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ...
   > Author: Russell Miles (3)
             > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ...
=====================================================
=====================================================
Simple Test (query == "father"):
Results list:
Document 1: Beyond Java:
   > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 2: From Java to Ruby:
   > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
=====================================================
=====================================================
Simple Case Test (query == "JAVA"):
Results list:
Document 1: Beyond Java:
   > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 2: From Java to Ruby:
   > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 4: AspectJ Cookbook:
   > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ...
   > Author: Russell Miles (3)
             > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ...
=====================================================

• Recherche par approximation ("jav~"):

=====================================================
Approximation Test (query == "jav~"):
Results list:
Document 1: Beyond Java:
   > Summary: In Beyond Java, Bruce Tate, author of the Jolt Award-winning Better, Faster, Lighter Java, chronicles the rise of the most  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 2: From Java to Ruby:
   > Summary: If you're trying to adopt Ruby in your organization and need some help, this is the book for you. Based on a decision tree  ...
   > Author: Bruce Tate (1)
             > Resume: Bruce A. Tate is a kayaker, mountain biker, and father of two. In his spare time, he is an independent consultant in Austin ...
Document 4: AspectJ Cookbook:
   > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ...
   > Author: Russell Miles (3)
             > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ...
=====================================================

• Recherche par proximité (""engineer UK"~5"):

=====================================================
Proximity Test (query == ""engineer UK"~5"):
Results list:
Document 4: AspectJ Cookbook:
   > Summary: This hands-on book shows readers why and how common Java development problems can be solved by using new Aspect-oriented pr ...
   > Author: Russell Miles (3)
             > Resume: Russell Miles is a software engineer for General Dynamics UK where he works with Java and Distributed Systems, although his ...
=====================================================

La vulgarisation et la généralisation de l’utilisation des moteurs de recherche ont définitivement changé les habitudes et les exigences des utilisateurs. Pourquoi la fonctionnalité de recherche d’une application de gestion ne serait-elle pas aussi simple et performante que Google ?
Difficile d’expliquer à son responsable que cela est dû à une divergence de paradigme entre l’indexation documentaire et SQL.
Hibernate Search vise à répondre à cette question, à moindre coût, en s’appuyant sur Apache Lucene afin d’offrir au travers du modèle de persistance d’Hibernate des capacités de recherche full-text.

Réconcilier la recherche full-text et les modèles de persistance relationnels

Par nature, SQL nous limite à l’écriture de requête de recherche par mot (par terme) avec l’aide éventuelle de wildcard (‘%’, ‘?’).
La recherche SQL sur un modèle relationnel n’offre pas (ou en tout cas pas sans de très gros efforts) un ensemble de capacités dignes d’un moteur de recherche moderne :

• L’approximation qui permet de s’affranchir des fautes de frappe (Ex : « xebi » -> « xebia »).
• La recherche par synonyme qui permet de remonter des résultats pertinents mais ne contenant pas le terme recherché (En SQL, « JEE » est différent de « J2EE »).
• La recherche par proximité (Ex : « persistance java » -> « Hibernate »).
• Le classement des résultats par pertinence (result scoring).
• La recherche multi-colonnes.

Ces fonctionnalités sont traditionnellement offertes par les solutions de recherche full-text qui s’appuient sur l’utilisation d’index inversés. Malheureusement, de telles solutions se marient souvent mal avec les systèmes de bases de données relationnelles en raison de décalages entre les deux paradigmes :

• Un déséquilibre structurel tout d’abord : Les index full-text ne sont que du texte. Ils ne reflètent pas une quelconque structuration des données. De plus, ils ne permettent pas de gérer des relations entre les documents.
• De plus, le mariage des deux systèmes pose des problèmes de synchronisation : comment s’assurer que le contenu de la base de données et l’index documentaire sont à jour et cohérents l’un vis-à-vis de l’autre ?
• Enfin, les résultats de recherches full-text sont des documents. En effet, les index ne stockent pas d’objets. Encore moins des objets « managés ».

A cela s’ajoute des problèmes de portabilité et de flexibilité dus au fait que la plupart des implémentations ne sont que des surcouches propriétaires au dessus du SQL.

L’objet d’Hibernate Search est de résoudre ces décalages et de réconcilier la recherche full-text et les modèles de persistance relationnels. Pour ce faire, Hibernate Search se base sur Apache Lucene, un moteur d’indexation et de recherche full-text standalone très puissant, mais plutôt bas niveau (et donc facile à mal utiliser).
Hibernate Search permet ainsi d’utiliser les capacités d’Apache Lucene dans le cadre d’une couche de mapping Hibernate.

Architecture

Hibernate Search est donc un moteur d’indexation et de recherche full-text reposant sur Apache Lucene. Il prend ainsi en charge la gestion d’un index Lucene et sa synchronisation avec une structure objet persistée en base de données.

La mise à jour de l’index est déclenchée au travers de la capture d’événements JPA : quand une entité est insérée, mise à jour ou supprimée en base de données, Hibernate Search récupère l’événement et programme une mise à jour de l’index. Cette mise à jour est effectuée de façon transparente par Hibernate Search et ne nécessite pas l’utilisation directe des API Lucene.
Par souci d’efficacité, les opérations d’écritures dans l’index Lucene sont traitées par lots. Le traitement de ces lots s’inscrit dans la transaction courante. De cette façon, la mise à jour de l’index n’est déclenchée que si celle-ci est « commitée », permettant ainsi de garantir l’ACID-ité du système.

La recherche dans l’index se fait au travers des APIs }}org.hibernate.Query ou javax.persistence.Query{{ de la même façon que l’on écrirait des requêtes natives, HQL ou JPA-QL. Une requête de recherche Hibernate Search retourne une liste d’entités « managées » sans que le développeur ait à se soucier du fastidieux travail de mapping Objet <-> Document Lucene.

Le traitement des opérations de mise à jour de l’index peut être traité par différents backend en fonction de l’architecture et des scénarii mis en place. Hibernate Search propose deux « backend sur étagère » : Un backend Lucene (synchrone) et un backend JMS (asynchrone).

Backend synchrone

Ce mode est le plus simple : toutes les opérations de mise à jour de l’index sont traitées par le nœud (la JVM) à l’origine de l’événement déclencheur. Le traitement des mises à jour est effectué de façon synchrone (au commit de la transaction).
Ce backend adresse des environnements standalones (non clusterisés) ou en clusters symétriques (tous les nœuds partagent la même instance d’index Lucene). C’est alors Lucene qui est en charge de la gestion de la stratégie de locking.

Les avantages de ce mode sont sa simplicité de mise en œuvre et la visibilité immédiate des mises à jour de l’index puisqu’elles sont traitées en synchrone.
Par contre, cette approche synchrone peut dégrader les performances de l’application front.

Backend asynchrone

Ce backend met en jeu le pattern maître / esclaves : Les opérations de mise à jour de l’index sont effectuées sur un index maître tandis que les opérations de lecture (recherche) sont effectuées sur des index esclaves. A intervalles réguliers, l’index maître est répliqué sur les esclaves (copies du maître).

Ce backend adresse des environnements clusterisés répondant à des besoins de haute performance de l’application front. Dans ce mode, chaque nœud utilise un index esclave en local. Ces indexes sont exclusivement utilisés en lecture. Lorsqu’un événement nécessite une opération de mise à jour de l’index, l’ordre de mise à jour est envoyé sur une queue JMS (tous les nœuds utilisant la même queue). Cette queue est dépilée par un consommateur unique en charge du traitement (asynchrone) des opérations de mise à jour qu’il effectue sur l’index maître.

Le principal avantage de ce mode est de ne pas surcharger l’application front avec les traitements de mise à jour de l’index.
Il entraîne par contre un délai de mise à jour des index de recherche (Traitement asynchrone des mises à jour + délai de réplication).

Pour bien commencer

• Le site du projet Hibernate Search.
• La documentation Hibernate Search.
• La documentation de la syntaxe de requêtes.

Et rendez-vous fin mars sur notre blog pour un premier sample.