Netapsys Blog

[Eclipse] Recherche camelCase

Benoît Cotinat — Tue, 07 Jun 2011 19:34:00 +0200

Notre IDE préféré possède en effet cette petite feature, ma foi fort sympathique, pour la recherche de fichier.

Lors de la recherche de ressources (Ctrl+Shift+R) ou de types (Ctrl+Shift+T), il est en effet possible de mettre uniquement les lettres en majuscule. Par exemple pour un fichier nommé MonFichierDeTest.java, il vous suffira de rechercher MFDT... voir même souvent moins, les deux ou trois premières lettres suffisant généralement.

Démonstration en image :

À noter que j'aurais très bien pu obtenir le même résultat en recherchant GenericDH.

Très utile lorsque vous avez plusieurs fichiers/classes qui commencent par les mêmes 3-4 premiers mots !

[JMeter] Création et exécution de jeu de test

Benoît Cotinat — Thu, 12 May 2011 21:13:00 +0200

JMeter est un outil open-source permettant de faire des tests fonctionnels, ainsi que des tests de montée en charge d'applications web.

Sa configuration n'étant pas très intuitive, nous allons voir dans ce billet comment :
1- Enregistrer un jeu de test ;
2- Placer des assertions ;
3- Jouer le jeu de test.

Vous trouverez à la fin de ce billet le plan de test d'exemple qui a servi à sa rédaction.

1- Enregistrer un jeu de test

Pour enregistrer simplement les différentes actions faites sur l'application, JMeter contient un proxy HTTP. Ce proxy va sauvegarder les requêtes qu'il verra passer, ce qui permettra de les réutiliser dans le jeu de test.

Configuration du navigateur

Il faut d'abord dire à votre navigateur d'utiliser le proxy de JMeter, à l'adresse localhost, et sur un port libre (ici 9999).

Configuration de JMeter

Faire un clic-droit sur "Plan de test" > Ajouter > Groupe d'unités. Ce groupe d'unités (ou groupe de threads), va stocker les requêtes qui seront enregistrées par le proxy. Nous reviendrons sur sa configuration lors des tests de montée en charge.

Faire un clic-droit sur "Plan de travail" > Ajouter > Eléments hors test > Serveur proxy HTTP.

Les différents points de configuration sur cet écran sont :

Le port qui est utilisé pour enregistrer les requêtes ;
Le contrôleur cible, qui va contenir les requêtes enregistrées ;
Les motifs d'URL à inclure et à exclure (attention à la syntaxe : .*\.extension).

Il ne reste plus qu'à lancer le serveur.

Enregistrement

Pour cet exemple, nous allons naviguer sur l'interface de management d'un tomcat lancé en local, et déployer une nouvelle application (ce qui va permettre de tester l'upload de fichier).
Au fur et à mesure de la navigation, les requêtes se rajoutent au groupe d'unités spécifié dans le proxy. Par défaut elles sont nommées par le chemin de la page, mais il est conseillé de les renommer pour avoir des résultats plus parlant lors de l'exécution du jeu de test.

Lors du déploiement d'une nouvelle application (et donc de l'upload d'un fichier), on peut voir que JMeter a bien sauvegardé le fichier utilisé dans la requête :

Attention : il faut que le fichier en question soit dans le répertoire /bin de jmeter.

2- Placer des assertions

Les assertions servent à vérifier que la navigation se passe correctement, et que la page demandée s'affiche correctement lors de l'exécution automatique du jeu de test. Différents type d'assertions sont disponibles, nous allons ici faire de vérifications "de base" sur le contenu de la réponse.
Pour ajouter une assertion, faire un clic-droit sur la requête > Ajouter > Assertions > Assertion Réponse.

3- Jouer le jeu de test

Une fois le scénario enregistré, nous pouvons couper le proxy, et fermer le navigateur. Quelques étapes de configuration sont encore nécessaires afin de pouvoir exécuter notre jeu de test, et monitorer notre serveur.

Configuration HTTP

Pour permettre à JMeter de se connecter à l'administration de tomcat, il faut rajouter un composant d'authentification spécifique, en faisant un clic-droit sur "Groupe d'unités" > Ajouter > Configuration > "Gestionnaire d'autorisation HTTP".
Il faut paramétrer ce composant en indiquant l'identifiant et le mot de passe de connexion à l'administration du serveur.

Pour pouvoir suivre la santé du serveur, il faut ajouter une requête HTTP (clic-droit sur "Groupe d'unités" > Ajouter > Echantillons > Requête HTTP) vers la page de monitoring de tomcat /manager/status, en ajoutant le paramètre XML avec la valeur true, et indiquer qu'il faut utiliser cette requête en tant que moniteur.

Il faut indiquer à JMeter les paramètres par défaut (adresse IP, port, chemin de l'application) à utiliser pour exécuter les requêtes qu'il a enregistré. Pour cela, il faut faire un clic-droit sur "Groupe d'unités" > Ajouter > Configurations > Paramètres HTTP par défaut.

Ce composant permet de dissocier l'enregistrement du scénario, et son exécution sur des serveurs différents.
Attention : pour exécuter le scénario en local, il faut bien mettre 127.0.0.1 en nom/adresse, et non pas localhost.

Monitoring

Le groupe d'unités permet de paramétrer l'exécution même du jeu de test. Son paramétrage est assez poussé en laissant la main sur le nombre d'utilisateurs, le nombre d'itérations du plan de test, la durée de montée en charge, la possibilité de programmer le démarrage des test, ...

Différents "récepteurs" (=listeners, clic-droit sur "Groupe d'unités" > Ajouter > Récepteurs > ...) existent, selon ce que l'on veut monitorer : charge/mémoire du serveur, temps d'exécution des requêtes, ... Je vais montrer ceux que je trouve le plus parlant.

Le moniteur de résultats s'appuie sur la requête HTTP que l'on a paramétrée à l'étape précédente. Il permet d'avoir une vue de la santé globale du serveur, ainsi que des informations plus détaillées sur la mémoire et le nombre d'exécuteurs tomcat disponibles :

L'arbre de résultats permet de vérifier que les différentes assertions que l'on a pu placer sont bien vérifiées, avec les informations de la requête et de la réponse.

Enfin, le rapport agrégé permet d'avoir les statistiques de temps d'exécution de chaque requête.

À noter que chaque récepteur permet d'enregistrer les résultats des tests dans un fichier csv, ce qui permet de l'utiliser après dans votre tableur favori pour exploiter différemment les données.

Bons tests !

Sérialisation/Désérialisation XML avec Camel

Benoît Cotinat — Tue, 22 Mar 2011 17:20:00 +0100

Je vais présenter ici quelques moyens pour faire de la sérialisation/désérialisation en XML avec Camel, selon différents besoins :

mapping "simple" de et/ou vers des pojos java existants ;
mapping à partir d'un fichier XSD fourni, ou mapping à partir d'un modèle Java bindé.

Les sources (mavenisées) des exemples sont fournies à la fin de ce billet.

Tout d'abord, partons d'une configuration de base :

Nos pojos existants :
EssaiClinique.java :

/** Description d'un essai.
 * @author NETAPSYS
 * @date 15 mars 2011
 * @version $Revision$ $Date$
 */
public class EssaiClinique implements Serializable {
    /** Serial ID. */
    private static final long serialVersionUID = -3188027620920487407L;

    /** Nom de l'essai. */
    private String nom;

    /** Nombre de patients pour l'essai. */
    private Integer nbPatient;

    /** Date de début de l'essai. */
    private Date dateDebut;

    /** Liste des médicaments nécessaires à l'essai. */
    private List<Medicament> medicaments;

    /** {@inheritDoc} */
    @Override
    public String toString() {
        final StringBuffer sb = new StringBuffer();
        sb.append("
EssaiClinique " + this.nom + " du " + this.dateDebut);
        for (final Medicament medicament : this.medicaments) {
            sb.append(medicament);
        }
        return sb.toString();
    }

    // Getters & Setters

Medicament.java :

/** Description d'un médicament.
 * @author NETAPSYS
 * @date 15 mars 2011
 * @version $Revision$ $Date$
 */
public class Medicament implements Serializable {
    /** Serial ID. */
    private static final long serialVersionUID = 3111655483593665106L;

    /** Nom du médicament. */
    private String nom;

    /** Concentration du médicament. */
    private BigDecimal concentration;

    /** {@inheritDoc} */
    @Override
    public String toString() {
        return "
Medicament " + this.nom + " à concentration de " + this.concentration;
    }

    // Getters & Setters

Contexte camel :

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
        http://camel.apache.org/schema/spring http://camel.apache.org/schema/spring/camel-spring.xsd">

	<camelContext trace="false" xmlns="http://camel.apache.org/schema/spring">
		<packageScan>
			<package>com.netapsys.routes</package>
		</packageScan>
	</camelContext>
</beans>

Classe de test permettant d'appeller les routes :

public class RoutesTest extends CamelSpringTestSupport {
    /** {@inheritDoc} */
    @Override
    public void setUp() throws Exception {
        super.setUp();
    }

    /** {@inheritDoc} */
    @Override
    protected AbstractXmlApplicationContext createApplicationContext() {
        return new ClassPathXmlApplicationContext("/config/camel-context.xml");
    }
}

Mapping Pojo/XML

Mise en place

Librairie

Si le besoin est uniquement de faire de l'export/import xml de pojos Java existant (pour faire de la sauvegarde, ou partager des données pour une application répartie par exemple), le plus simple est d'utiliser le serialiseur Xstream.
Pour cela il faut commencer par inclure camel-xstream au classpath. Avec Maven il faut rajouter la dépendance :

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-xstream</artifactId>
</dependency>

Camel

Dans la définition de notre contexte camel, il faut rajouter le format qui sera utilisé dans la route :

<dataFormats>
    <xstream id="xstream-utf8" encoding="UTF-8"/>
</dataFormats>

La route permettant la sérialisation/désérialisation :

/** Routes utilisant le marshaller xstream.
 * @author NETAPSYS
 * @date 16 mars 2011
 * @version $Revision$ $Date$
 */
public class XStreamRoutes extends RouteBuilder {
    /** @see org.apache.camel.builder.RouteBuilder#configure() */
    @Override
    public void configure() throws Exception {
        this.from("direct:xstream-marshal")
            .marshal("xstream-utf8")
            .to("file:/testCamel?fileName=essais-xstream.xml");

        this.from("direct:xstream-unmarshal")
	    .unmarshal("xstream-utf8")
            .to("log:com.netapsys.routes?level=DEBUG");
    }
}

Test

Et enfin le test de nos routes :

/** Appelle les routes pour la sérialisation/désérialisation.
 * @throws Exception Exception lors de l'exécution des routes.
 */
@Test
public void test() throws Exception {
    final EssaiClinique essai = this.getEssaiForTest();

    this.template.sendBody("direct:xstream-marshal", essai);

    Thread.sleep(2000);

    this.template.sendBody("direct:xstream-unmarshal", new File("/testCamel/essais-xstream.xml"));

    Thread.sleep(2000);
}

/** Créé un Essai pour le test.
 * @return Essai
 */
private EssaiClinique getEssaiForTest() {
    // Créé un essai de test avec 2 médicaments.
    // Pour bien gérer l'export des concentrations, ne pas oublier de paramétrer le MathContext :
    final Medicament m1 = new Medicament();
    m1.setConcentration(new BigDecimal(1.2345, MathContext.DECIMAL32));
}

Résultats

Sérialisation

En éditant le fichier XML créé (/testCamel/essais-xstream.xml), on peut voir qu'il correspond bien à nos attentes :

<?xml version='1.0' encoding='UTF-8'?>
<com.netapsys.model.EssaiClinique>
    <nom>Essai n°1</nom>
    <nbPatient>3</nbPatient>
    <dateDebut>2011-03-16 18:10:08.270 CET</dateDebut>
    <medicaments>
        <com.netapsys.model.Medicament>
            <nom>Médicament 1</nom>
            <concentration>1.234500</concentration>
        </com.netapsys.model.Medicament>
        <com.netapsys.model.Medicament>
            <nom>Médicament 2</nom>
            <concentration>2.000100</concentration>
        </com.netapsys.model.Medicament>
    </medicaments>
</com.netapsys.model.EssaiClinique>

On peut voir que par défaut XStream nomme les noeuds avec le nom complet des classes, ce qui lui permet de s'y retrouver lors de la désérialisation.

Désérialisation

En regardant les logs, on peut voir que les informations on bien été récupérées :

2011/03/16 18:29:19 DEBUG service.process(74) : Exchange[ExchangePattern:InOnly, BodyType:com.netapsys.model.EssaiClinique, Body:
EssaiClinique Essai n°1 du Wed Mar 16 18:29:16 CET 2011
Medicament Médicament 1 à concentration de 1.234500
Medicament Médicament 2 à concentration de 2.000100]

Mapping à partir d'un fichier XSD / Modèle Java bindé

Il peut être nécessaire de faire évoluer une application pour exporter des données en XML, tout en respectant un fichier XSD fourni.
Dans ce cas le sérialiseur JAXB va être utilisé, et il faudra préalablement passer par une conversion en java entre nos pojos de notre modèle métier et le modèle qui sera généré. Tout d'abord, il va falloir commencer par générer le modèle Java correspondant au XSD.

Ce type de sérialisation/désérialisation peut aussi être utilisé si nos pojos sont déjà bindés.

1-Génération du modèle

XJC

XJC est un outil inclus dans le JDK qui va nous permettre de générer le modèle Java à partir d'un fichier XSD. Le fichier XSD de référence, essais.xsd, est dans le projet camel-jaxb, lié à ce billet.
XJC a besoin d'un fichier de binding, qui contient principalement le chemin vers le fichier XSD, et le package où seront stockées les classes créées.

binding.xjb :

<?xml version="1.0" encoding="UTF-8"?>
<bindings schemaLocation="../essais.xsd" xmlns="http://java.sun.com/xml/ns/jaxb" version="2.1">
    <schemaBindings>
        <package name="com.netapsys.model.xml" />
    </schemaBindings>
    <globalBindings>
        <serializable uid="100" />
    </globalBindings>
</bindings>

Commande à exécuter :

"C:\Program Files\Java\jdk1.6.0_20\bin\xjc.exe" -d D:\Projet\camel-jaxb\src\main\java\ -extension D:\Projet\camel-jaxb\src\main
esources\essais.xsd -b D:\Projet\camel-xsd\src\main
esources\schema\binding.xjb

Explication succincte des paramètres :

-d : répertoire où se situe le package spécifié dans le fichier xjb ;
-extension : chemin vers le fichier xsd (attention, le fait de mettre un chemin relatif peut être source de bug lors de l'exécution de la commande) ;
-b : emplacement du fichier xjb (même remarque que ci-dessus).

Modèle

Les traces dans les logs montrent les classes créées, qui sont visibles, dans le package spécifié dans le fichier de binding. Pour plus d'informations sur les annotations utilisées, je vous invite à consulter ce post.
Pour notre exemple, ces classes générées correspondront à un modèle métier déjà bindé.

2-Mise en place

Librairie

Pour effectuer la sérialisation/désérialisation, il faut inclure la librairie camel-jaxb au classpath. Avec maven, il faut rajouter la dépendance :

<dependency>
    <groupId>org.apache.camel</groupId>
    <artifactId>camel-jaxb</artifactId>
</dependency>

Camel

Il n'y a pas de modification à apporter au contexte Camel.
Écrivons la route que nous appellerons pour effectuer la sérialisation/désérialisation :

/** @see org.apache.camel.builder.RouteBuilder#configure() */
@Override
public void configure() throws Exception {
    final DataFormat dataFormat = new JaxbDataFormat("com.netapsys.model.xml");

    this.from("direct:jaxb-marshal")
          .marshal(dataFormat)
          .to("file:/testCamel?fileName=essais-jaxb.xml");

    this.from("direct:jaxb-unmarshal").unmarshal(dataFormat).to("log:logger.service?level=DEBUG");
}

Cette route ressemble beaucoup à la première, à la différence de l'utilisation d'une implémentation de DataFormat spécifique à JAXB, qui connaît l'emplacement du modèle à utiliser.

Test

Là aussi le test ressemble beaucoup au précédent :

/** Test de sérialisation/désérialisation.
 * @throws Exception Exception lors de l'exécution des routes.
 */
@Test
public void test() throws Exception {
    final XMLEssaiClinique essai1 = this.getEssaiForTest();

    this.template.sendBody("direct:jaxb-marshal", essai1);

    Thread.sleep(2000);

    this.template.sendBody("direct:jaxb-unmarshal", new File("/testCamel/essais-jaxb.xml"));

    Thread.sleep(2000);
}

/** Créé un Essai pour le test.
 * @return Bean du modèle XML pour le test.
 * @throws DatatypeConfigurationException Erreur lors de la conversion des données.
 */
private XMLEssaiClinique getEssaiForTest() throws DatatypeConfigurationException {
    // Attention à la gestion de la date :
    final XMLEssaiClinique essai1 = new XMLEssaiClinique();
    essai1.setDateDebut(DatatypeFactory.newInstance()
                                          .newXMLGregorianCalendar(new GregorianCalendar()));
    // Valorisation de l'essai avec deux médicaments.
}

La principale différence ici est le type des objets passés à la route. Il faut en effet passer des objets que JAXB connaît. Dans une application existante, cela implique la mise en place d'un mapping java entre les pojos existants (EssaiClinique.java et Medicament.java dans notre cas), vers les pojos du modèle XML générés par XJC.

3-Résultats

Sérialisation

Ici encore, le fichier XML correspond à nos attentes :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<XMLEssaiClinique>
    <nom>Essai n°1</nom>
    <nbPatient>3</nbPatient>
    <dateDebut>2011-03-17+01:00</dateDebut>
    <medicaments>
        <XMLMedicament>
            <nom>Médicament 1</nom>
            <concentration>1.234500</concentration>
        </XMLMedicament>
        <XMLMedicament>
            <nom>Médicament 2</nom>
            <concentration>2.000100</concentration>
        </XMLMedicament>
    </medicaments>
</XMLEssaiClinique>

Désérialisation

Toujours en étudiant les logs, on peut voir que les objets ont bien été créés. Pour les besoins du test, j'ai surchargé la méthode toString() dans les classes du modèle XML générées par xjc :

XMLEssaiClinique Essai n°1 du 2011-03-17+01:00
XMLMedicament Médicament 1 à concentration de 1.234500
XMLMedicament Médicament 2 à concentration de 2.000100

Conclusion

Nous avons présenté deux méthodes pour faire de la sérialisation/désérialisation d'objets en XML, chacune des méthodes répondant à un besoin différent. Les deux premiers avantages que je vois à l'utilisation de Camel sont la simplicité de la mise en place du système, tout en gardant de nombreuses possibilités de personnalisation grâce aux différentes annotations disponibles.

Liens :

XJC : http://download.oracle.com/javase/6/docs/technotes/tools/share/xjc.html
Camel - XStream : http://camel.apache.org/xstream.html
Camel - JAXB : http://camel.apache.org/jaxb.html

Comment scanner des répertoires ?

Benoît Cotinat — Sun, 20 Feb 2011 18:10:00 +0100

Le besoin de scanner le contenu de répetoires est assez courant, pour analyser des données, nettoyer des répertoires, ... à intervalles réguliers.

Une des réponses à ce problème est de mettre en place des CRON, appelant des classes java. C'est une solution, mais elle n'enlève pas le côté complexe de gestion des fichiers en java, surtout si ceux-ci sont situés sur un répertoire distant.

Or nous aimons les choses simples et bien faites :). Pour cela, la solution que nous avons choisie est d'utiliser Camel.

Cet outil, à la configuration très complète (mais pas complexe !) nous permet de "consommer" (traiter, transférer, ...) des fichiers en utilisant différents composants : "file://" pour un système de fichier local, ou "ftp://" pour attaquer un serveur ftp.
Quelques options de base :

possibilité de supprimer ou non le fichier
intervalle de temps entre 2 "poll" du répertoire
filtrer les fichiers qui seront récupérés sur leur nom

On peut facilement imaginer recopier en local des fichiers présents sur un ftp, avec une route de la forme :

from("ftp://192.168.2.42/folder/")
.beanRef("theBean") // traitement du fichier (ajout/suppression de données ?)
.to("file://C:\tmp");

CRON :

Camel :

http://camel.apache.org/
- avec son indispensable page des composants : http://camel.apache.org/components.html

[Spring] Gestion des propriétés et des messages

Benoît Cotinat — Fri, 17 Dec 2010 15:30:00 +0100

Dans ce billet je vais faire un rapide aperçu d'une des manières de gérer les messages et les propriétés d'un projet avec Spring.

Généralement, les messages sont stockés dans des fichiers properties inclus dans le projet.

Il y a deux manières de déclarer les fichiers properties, selon les besoins d'utilisation des propriétés.

Placeholder

Il arrive souvent que des propriétés techniques aient besoin d'être injectées dans des beans par Spring.

<bean id="testBean" class="com.netapsys.Bean">
     <property name="adress" value="${server.adress}" />
</bean>

Dans cet exemple, la propriété server.adress est stockée dans un fichier properties, et sera injectée par Spring au démarrage du serveur.

La liste des fichiers dans lesquels Spring ira rechercher ces propriétés est à définir dans un bean de type PropertyPlaceholderConfigurer :

<bean id="propertyConfigurer" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">
     <property name="locations">
          <list>
               <value>classpath:/config/project.properties</value>
               <value>classpath:/config/ldap.properties</value>
               <value>file:/etc/netapsys/config.properties</value> <!-- Les propriétés peuvent être surchargées dans un fichier présent sur le système. -->
          </list>
     </property>
     <property name="ignoreResourceNotFound" value="true"/> <!-- Permet de ne pas avoir d'erreur si un fichier n'est pas présent. -->
</bean>

À noter qu'il est possible de définir plusieurs beans de type PropertyPlaceholderConfigurer, et de customiser la syntaxe du placeholder (qui est par défaut ${key}).

MessageSource

Pour récupérer des messages depuis le code (en récupérant le contexte Spring grâce à la classe ApplicationContext), ou pour les afficher dans les JSP grâce au tag spring:message, il faut définir un bean messageSource étendant la classe AbstractMessageSource.

<bean id="messageSource" class="org.springframework.context.support.ResourceBundleMessageSource">
     <property name="basenames"> <!-- Liste des fichiers à utiliser, présents dans le classpath. -->
          <list>
               <value>ErrorResources</value>
               <value>LabelResources</value>
               <value>config/project</value>
          </list>
     </property>
     <property name="alwaysUseMessageFormat" value="true" /> <!-- Formatage de tous les messages. -->
     <property name="useCodeAsDefaultMessage" value="true"/> <!-- Utilise le code en tant que valeur par défaut. -->
</bean>

Cette implémentation est la plus simple, et convient dans la majorité des cas. Cependant dans certains projets, le client peut vouloir changer certains messages ou propriétés sans avoir à redémarrer le serveur. Or, comme indiqué, la classe ResourceBundleMessageSource se base sur la classe ResourceBundle du JDK, qui ne permet pas le rechargement des messages à chaud.

Dans ce cas il faut se tourner vers une autre implémentation de Spring : ReloadableResourceBundleMessageSource. La déclaration sera quelque peu différente :

<bean id="messageSource" class="org.springframework.context.support.ReloadableResourceBundleMessageSource">
     <property name="basenames"> <!-- Liste des fichiers à utiliser, présents dans le classpath. -->
          <list>
               <value>file:/etc/netapsys/config</value> <!-- Les propriétés peuvent être surchargées dans un fichier présent sur le système (premier élément de la liste !).  -->
               <value>classpath:ErrorResources</value>
               <value>classpath:LabelResources</value>
               <value>classpath:config/project</value>
          </list>
     </property>
     <property name="alwaysUseMessageFormat" value="true" /> <!-- Formatage de tous les messages. -->
     <property name="useCodeAsDefaultMessage" value="true"/> <!-- Utilise le code en tant que valeur par défaut. -->
     <property name="cacheSeconds" value="10" /> <!-- Taux de rafraîchissement des messages mis en cache. -->
</bean>

Contrairement à la première implémentation, il est maintenant possible d'indiquer un fichier présent sur le système, dans lequel notre client ira surcharger les messages voulus par exemple. Petite explication de la propriété cacheSeconds : lors de l'affichage d'un message, il est mis dans un cache. Si la clé du message est redemandée après "cacheSeconds" secondes, le bundle ira revérifié dans les fichiers properties si sa valeur n'a pas changée.

De plus, cette implémentation peut aussi être intéressante à utiliser dans le cadre du développement, lors de la construction des IHM.

[Hibernate] - Persistance de types personnalisés

Benoît Cotinat — Fri, 10 Dec 2010 18:30:00 +0100

Dans ce billet, nous allons voir comment Hibernate nous permet simplement, et de façon transparente, de persister des types Java qui ne sont pas gérés nativement par la base de données. Nous verrons aussi l'utilisation avec JPA.

Dans une application, la persistance des données et leur gestion par la couche DAO sont transparentes tant que les types manipulés sont gérés nativement par Hibernate (les nombres en général, chaînes de caractères, dates, données binaires). S'il y a besoin d'utiliser d'autres types de données, il y a généralement des "mappers" mis en place pour faire la conversion entre le type voulu et un type géré par Hibernate et le SGBD.

Hibernate met à disposition l'interface UserType, permettant de spécifier un mapper qu'il utilisera pour persister et transformer les types voulus.

Nous allons voir un exemple avec une classe possédant un attribut de type Color.

Commençons par décrire notre classe, sans information Hibernate pour l'instant :

/** Classe de test symbolisant un groupe.
 * @author Netapsys
 */
public class Groupe {
    /** Identifiant du groupe. */
    private Integer id;

    /** Couleur du groupe. */
    private Color couleur;

    // Getters et setters...
}

ColorUserType.java

Sans la classe fournie par Hibernate, il aurait fallu gérer la couleur avec des Integer, et faire le mapping vers la classe Color à divers endroits du code.
Dans le contrat imposé par l'interface UserType, seules quatre méthodes vont nous intéresser :

int sqlTypes();
- Indique sous quel type SQL sera stocké notre type personnalisé. Le type retourné doit correspondre au type de colonne de la base de données.

/** {@inheritDoc} */
@Override
public int[] sqlTypes() {
    return new int[] {Types.INTEGER }; // Notre couleur sera stockée sous forme d'entier.
}

Class returnedClass();
- Indique la classe de notre type personnalisé.

/** {@inheritDoc} */
@Override
public Class<Color> returnedClass() {
    return Color.class;
}

void nullSafeSet(PreparedStatement st, Object value, int index) throws HibernateException, SQLException;
- En charge de convertir notre type personnalisé en type de donnée SQL, indiqué dans la méthode sqlTypes().

/** {@inheritDoc} */
@Override
public void nullSafeSet(final PreparedStatement st, final Object value, final int index)
  throws HibernateException, SQLException {
    if (null == value) {
        st.setNull(index, Types.INTEGER);
    } else {
        final Color color = (Color) value;
        st.setInt(index, color.getRGB()); // on stocke en base la valeur RGB de la couleur.
    }
}

Object nullSafeGet(ResultSet rs, String names, Object owner) throws HibernateException, SQLException;
- En charge de convertir la donnée récupérée de la base dans le type souhaité, indiqué dans la méthode returnedClass().

/** {@inheritDoc} */
@Override
public Object nullSafeGet(final ResultSet rs, final String[] names, final Object owner)
  throws HibernateException, SQLException {
    final Integer value = (Integer) Hibernate.INTEGER.nullSafeGet(rs, names[0]); // on récupère la valeur RGB de la couleur.
    if (value != null) {
        return new Color(value);
    } else {
        return null;
    }
}

Une classe d'exemple, jointe à ce billet, contient les autres méthodes.

Déclaration Hibernate

Si le mapping Hibernate est fait avec des fichiers XML, il faut rajouter l'attribut type à la balise property de l'attribut que nous voulons mapper. Il faut indiquer à cet attribut le nom complet de la classe de mapping :

<property name="couleur" column="grp_color" type="com.netapsys.ColorUserType" />

Déclaration JPA

Si le mapping est fait grâce aux annotations JPA, il suffit de rajouter l'annotation @Type avec le nom complet de la classe de mapping sur l'attribut à mapper :

@Type(type = "com.netapsys.ColorUserType")

L'utilisation de ce mapping "automatique" permet de grandement simplifier le reste du code en évitant :

de mélanger deux types différents pour la même donnée ;
d'avoir à passer d'un type à l'autre à différents endroits du code, souvent source de duplication.

Vous trouverez en pièce jointe une archive contenant le code :

de la classe Groupe sans annotation : Groupe.java ;
du fichier de mapping Hibernate de la classe Groupe : groupe.hbm.xml ;
de la classe GroupeJpa, correspondant au bean Groupe avec les annotations JPA : GroupeJpa.java ;
de la classe ColorUserType réalisant le mapping : ColorUserType.java.

[Nantes JUG] - 25 novembre 2010 - Soirée RIA : Flex, HTML5

Benoît Cotinat — Fri, 19 Nov 2010 18:05:00 +0100

En tant que partenaire du JUG (Java User Group) de Nantes, Netapsys vous invite à la conférence du jeudi 25 novembre 2010, de 19h à 21h, à l'école des Mines de Nantes. Elle sera animée par François Le Droff, d'Adobe France.

Durant cette soirée, nous discuterons de RIA et Java :

de Flash, de Flex, d’HTML5 ;
d’applications multi-écrans: desktop, tablette, téléphone, télévision ;
des solutions offertes par Adobe dans ce domaine ;
nous verrons comment les technologies Adobe permettent aux développeurs et architectes de construire des applications internet riches et multi-écrans, tout en faisant fructifier leurs anciens investissements, notamment sur les technologies Java/JavaEE (EJB3, Spring, Hibernate JPA, Maven...).

À propos de François le Droff :
Brestois d’origine, parisien d’adoption, François est architecte technique chez Adobe France depuis 2007, après 9 ans d’expérience dans le développement d’applications Web, principalement en Java/JavaEE. Acteur et contributeur de la communauté open source (qsos, xradar, fna), François est membre de l’OSSGTP (Open Source Software Get Together Paris), et du ParisJUG.

Pour vous inscrire à cette soirée, c'est ICI.

Résumé :

Quoi : http://www.nantesjug.org/
Quand : Jeudi 25 novembre 2010, de 19h à 21h
Où : http://www.mines-nantes.fr/fr/Pratique/Venir-a-l-Ecole
Comment : http://jugevents.org/jugevents/event/registration.form?event.id=31710

[Spring Security] Authentification LDAP + autorisations BDD

Benoît Cotinat — Sat, 02 Oct 2010 14:56:00 +0200

Ce besoin est assez courant dans le développement d'applications : les utilisateurs sont présents dans un annuaire général, et c'est à chaque application de gérer ses droits d'accès. La documentation de Spring Security explique bien le fonctionnement général du framework, mais décrit principalement les cas nominaux que sont le "tout LDAP" et le "tout BDD". Je vais montrer ici les quelques points de configuration nécessaires afin de mélanger ces deux aspects.

Pré-requis :
- Spring security
- Spring ldap

Je vais commencer par présenter les différentes briques qui vont nous servir à faire fonctionner le tout.

Tout d'abord, nous allons définir la connexion à notre annuaire :

<bean id="contextSource" class="org.springframework.security.ldap.DefaultSpringSecurityContextSource">
	<constructor-arg index="0" value="ldap.example.com:389/dc=netapsys,dc=com" />
	<!--<property name="userDn" value="cn=manager,dc=netapsys,dc=com" />-->
	<!--<property name="password" value="password" />-->
</bean>

Ici, nous utilisons une connexion anonyme à l'annuaire, si une athentification est nécessaire, il suffit de décommenter les deux lignes.

Ensuite nous allons définir un objet capable de faire la recherche dans l'annuaire :

<bean id="ldapUserSearch" class="org.springframework.security.ldap.search.FilterBasedLdapUserSearch">
	<constructor-arg index="0" value="ou=personnes" /> <!-- Branche principale à partir de laquelle faire la recherche -->
	<constructor-arg index="1" value="(uid={0})" /> <!-- Critère de recherche LDAP, ici le login de l'utilisateur correspond à l'uid de l'entrée LDAP -->
	<constructor-arg index="2" ref="contextSource" />
	<property name="searchSubtree" value="true" /> <!-- Recherche dans les sous-branches -->
</bean>

Enfin, nous allons définir notre propre classe de gestion des droits :

<bean id="netapsysAuthoritiesPopulator" class="com.netapsys.security.NetapsysAuthoritiesPopulator" />

Petit artifice, bien que cette classe ait pour but de récupérer les autorisations en base de données, elle doit étendre la classe LdapAuthoritiesPopulator du framework. Notons qu'arrivés à ce stade, nous sommes sûrs que l'utilisateur est authentifié.

/** Classe permettant de récupérer les droits d'un utilisateur se connectant à l'application.<br />
 * Si le login n'existe pas en base, alors l'utilisateur a par défaut les droits d'un invité. */
public class NetapsysAuthoritiesPopulator implements LdapAuthoritiesPopulator
{
    /** Service des utilisateurs. */
    @Resource(name = "utilisateurService") private UtilisateurService utilisateurService;

    /** {@inheritDoc} */
    @Override public Collection<GrantedAuthority> getGrantedAuthorities(final DirContextOperations userData, final String username) {
        final List<GrantedAuthority> authorities = new ArrayList<GrantedAuthority>();
        final Utilisateur user = this.utilisateurService.getByLogin(username);	// Recherche de l'utilisateur en base
        if (user == null) {
            authorities.add(new GrantedAuthorityImpl("ROLE_GUEST"));
        } else {
            authorities.add(new GrantedAuthorityImpl(user.getProfil().getRole()));
        }
        return authorities;
    }

    /** Setter pour utilisateurService.
     * @param utilisateurService le utilisateurService à écrire. */
    public void setUtilisateurService(final UtilisateurService utilisateurService) {
        this.utilisateurService = utilisateurService;
    }
}

Assemblons maintenant toutes ces parties :

<bean id="ldapAuthProvider" class="org.springframework.security.ldap.authentication.LdapAuthenticationProvider">
	<constructor-arg index="0">
		<bean class="org.springframework.security.ldap.authentication.BindAuthenticator">
			<constructor-arg index="0" ref="contextSource" />
			<property name="userSearch" ref="ldapUserSearch" />
		</bean>
	</constructor-arg>
	<constructor-arg index="1">
		<bean ref="netapsysAuthoritiesPopulator" />
	</constructor-arg>
</bean>

Nous n'avons plus qu'à injecter ce provider au gestionnaire de sécurité de notre application :

<security:authentication-manager>
	<security:authentication-provider ref="ldapAuthProvider" />
</security:authentication-manager>

Et le tour est joué !

Vous trouverez en pièce jointe un fichier de configuration Spring d'exemple.

Générer le diagramme de séquence de votre application

Benoît Cotinat — Wed, 02 Jun 2010 10:15:00 +0200

Nous allons voir l'utilisation, avec tomcat, de jtracert, outil géré par Google permettant de générer le diagramme de séquence d'une application Java, en fonction de votre navigation sur celle-ci.

- Nous allons commencer par récupérer l'archive de l'application : jTracert-x.x.x.zip.

- Dézipper l'archive.

- Editer le fichier catalina.bat ou catalina.sh du serveur tomcat.

- À la ligne définissant les paramètres Java (JAVA_OPTS), rajouter le paramètre suivant : -javaagent:<chemin vers jtracert>\jTracert.jar=7007

- Lancer le serveur tomcat (sans oublier de copier notre application dans le dossier webapps) : startup.bat ou startup.sh

- Le message suivant apparaît dans la console du serveur : Waiting for a connection from jTracert GUI on port 7007

- Lancer jtracert : 1. Répertoire de destination des fichiers générés
2. Nom du package des classes qui seront filtrées lors de la génération
3. Adresse du serveur tomcat
4. Port d'écoute
5. Paramètre à ajouter dans le fichier catalina

- Se connecter, le serveur tomcat démarre.

- Connectez-vous à l'application et naviguez. Jtracert génère les diagrammes en fonction du filtre appliqué.

- L'arborescence de gauche contient les les différentes classes qui ont été appelées, avec le nom de la méthode d'entrée :

- Le détail de l'appel d'une classe donne le diagramme de séquence correspondant :

- Bien qu'il soit possible d'affiche le diagramme en plein écran, sa lecture, et surtout son partage, ne sont pas aisés. C'est pourquoi jtracert propose de l'exporter dans un fichier image (s'il n'est pas trop grand), ou pdf.

Lors de l'arrivée sur un projet, jtracert apporte une vue d'ensemble au fonctionnement de l'application. Il permet donc de remplacer, ou au moins de précéder, une longue et fastidieuse phase de debug.

[Eclipse] Working set

Benoît Cotinat — Thu, 22 Apr 2010 22:57:00 +0200

Petit point sur une notion d'eclipse : les "working set". Cela permet de créer nos propres environnements de travail au sein de l'IDE, en filtrant les éléments voulus (et donc enlever, entre autre, le répertoire "target"). Ils sont utilisés dans plusieurs recherches et vues.

Création d'un working set

"Window" -> "Working Sets" -> "Edit..." -> "New..." -> "Java"
Dérouler votre projet et ne cocher/sélectionner que les composants qui vous intéressent
Donner un nom au working set -> "Finish"
Cocher le working set créé et valider

Vous pouvez bien évidemment créer plusieurs working set pour un même projet eclispe.

Filtrer les recherches

Search (Ctrl+H)
1. Dans la partie "Scope", sélectionner "Working set", puis cliquer sur "Choose"
2. Cocher le working set créé et valider par OK
3. Faites votre recherche, elle ne s'effectuera que dans les dossiers que vous avez sélectionnés

Open Resource/Open Type (Ctrl+Shift+R/Ctrl+Shift+T)
- Accéder au menu de la fenêtre (petite flèche vers le bas) -> "Select Working Set"

Filtrer les vues (Package explorer, Navigator, Hierarchy, Breakpoints, ...)

Accéder au menu de la vue (petite flèche vers le bas) -> "Select Working Set"

Pour revenir au workspace :

Accéder au menu de la vue -> "Deselect Working Set"

Et il est aussi possible de n'afficher qu'un projet (ou partie du projet) du workspace (indépendemment des working set) :

Clique-droit sur le projet (ou son composant) -> "Go Into"