ViaXoft

Aller au contenu | Aller au menu | Aller à la recherche

jeudi 4 décembre 2008

Utilisation de Dozer pour le mapping Bean à Bean

Nous utilisons Dozer au sein de notre application lorsque nous avons besoin de faire du mapping Bean à Bean et notamment lors de l'appel de services web publiés par nos partenaires.

Dozer offre des fonctionnalités assez poussées comme la possibilité de surcharger les setter/getter ou les méthodes de création de Bean.

L’une des fonctionnalités indispensables, mais pourtant assez mal documentée, lors du mapping avec des classes générées par XMLBean ou JAXB2, est la possibilité de mapper les inner class :

<mapping>
  <class-a>com.viaxoft.Availability$Response</class-a>
  ...

Le $ remplace le point dans le chemin vers l’inner class.

mercredi 23 juillet 2008

Modification de template Velocity au runtime

Velocity est un moteur de template Open Source Java de la fondation Apache. Nous utilisons Velocity depuis pas mal de temps pour tout ce qui est rapport aux fusions (Mail, publipostage,...).
Jusqu'à présent nous l'utilisions sous sa forme la plus "traditionnelle", basée sur des fichier template (.vm), que nous chargions au runtime pour être fusionnés à une map de paramètres :

  // Initialisation du moteur velocity
  VelocityEngine engine = new VelocityEngine();
  engine.init();
  // Chargement du template
  Template template = engine.getTemplate( "test.vm" );
  // Création du contexte
   VelocityContext context = new VelocityContext();
  context.put("nom", "Durand");
  // Exécution du template dans une String
  StringWriter writer = new StringWriter();
  template.merge( context, writer );

  System.out.println( writer.toString() );

Dernièrement nous avons eu le besoin de composer une variable sur la base de plusieurs autres. Il s'agit de faire un peu plus que de la concaténation ; nous avons donc laissé nos utilisateurs créer leur propres variables de la sorte :

  politesse = &civilite &nom &prenom

Mais nous devions à ce moment là modifier nos template au runtime. Velocity offre pour cela une méthode evaluate qui permet d'évaluer un template (sous forme de String) :

  VelocityContext velocityContext = new VelocityContext(params);
  StringWriter result = new StringWriter();
  try {
    velocityEngine.evaluate(velocityContext, result, "template", template);
  } catch (Exception e)...

Ceci nous a permis de stocker les modèles en base de données sans avoir ensuite à recréer des InputStream ou autre pour les fusionner.

Nous modifions les modèles au runtime en leur ajoutant les variables créées par les utilisateurs.

vendredi 6 juin 2008

Gestion des logs

La gestion des logs est un sujet qui est souvent sous estimé de la part des équipes de développement. Avec l'utilisation des outils de développement moderne et leur débugger intégré, les logs applicatives ont bien moins d'intérêts au moment du développement. Par contre, lorsque l'application est testée ou déployée, les logs reprennent tout leur sens.

L'apparition de framework Java tels que Log4J ou celui intégré au JDK facilite grandement la vie du développeur, mais l'écriture de logs reste toujours à la discrétion de ce dernier.

L'AOP (Programmation Orientée Aspect) apporte une réponse à cette problématique. Nous pouvons grâce à celle-ci générer des logs à chaque entrée/sortie de méthode et à chaque levée d'exception. Voici un exemple d'implémentation de gestion des logs utilisant Spring et Spring AOP :

Nous définissons tout d'abord un greffon (advice) qui implémente MethodBeforeAdvice, AfterReturningAdvice et ThrowsAdvice. Ceci nous permet de redéfinir les trois méthodes before, afterReturning et afterThrowing afin de générer les logs à chaque entrée/sortie de méthode et à chaque levée d'exception.

package com.viaxoft.ext.logging;

import java.lang.reflect.Method;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
import org.springframework.aop.AfterReturningAdvice;
import org.springframework.aop.MethodBeforeAdvice;
import org.springframework.aop.ThrowsAdvice;

public class LoggingAdvice implements MethodBeforeAdvice, AfterReturningAdvice,
ThrowsAdvice {
private static Log logger = null;

public LoggingAdvice() {
}

public void before(Method arg0, Object[] arg1, Object arg2)
throws Throwable {
logger = LogFactory.getLog(arg2.getClass());
logger.info("Entrée dans la méthode : " + arg0.getName());
}

public void afterReturning(Object arg0, Method arg1, Object[] arg2,
Object arg3) throws Throwable {
logger = LogFactory.getLog(arg3.getClass());
logger.info("Sortie de la méthode : " + arg1.getName());
}

public void afterThrowing(Method m, Object[] args, Object target,
Throwable ex) {
logger = LogFactory.getLog(target.getClass());
logger.error("Exceptiondans la méthode : " + m.getName() + " L'exception : "
+ ex.getMessage());
}
}

Nous devons ensuite définir notre aspect sous forme de bean au sein du fichier de config Spring. Nous utilisons l'implémentation RegexpMethodPointcutAdvisor qui nous permet de matcher les méthodes sur lesquelles notre aspects doit s'appliquer grâce à une expression régulière :

<bean id="loggingAdvisor"   class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
  <property name="advice" ref="loggingAdvice" />
  <property name="patterns" value=".*" />
</bean>

A noter ici que nous générons la log pour toutes les méthodes. On pourrait imaginer générer plusieurs niveau de log (DEBUG, INFO, ...), en fonction de la méthode à laquelle on s'adresse ; par exemple les méthodes du layer DAO seraient en DEBUG, alors que celles de la couche service en INFO.

L'implémentation RegexpMethodPointcutAdvisor permet de définir à la fois l'aspect et la coupe au sens AOP.

Nous définissons également le greffon :

<bean id="loggingAdvice"
  class="com.viaxoft.ext.logging.LoggingAdvice">
</bean>

Il ne nous reste plus ensuite qu'à tisser les aspects. Nous utilisons DefaultAdvisorAutoProxyCreator pour un tissage automatique :

<bean   class="org.springframework.aop.framework.autoproxy.
 DefaultAdvisorAutoProxyCreator" />

Le résultat dans le fichier de log :

juin 06 08:54:25 INFO iaxoft.dao.impl.AddressDaoImpl before Entrée dans la méthode: saveAddress
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl before Entrée dans la méthode: openSession
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl afterReturning Sortie de la méthode : openSession
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl before Entrée dans la méthode: getTransactionManager
juin 06 08:54:25 INFO ernate.impl.SessionFactoryImpl afterReturning Sortie de la méthode : getTransactionManager
juin 06 08:54:25 INFO iaxoft.dao.impl.AddressDaoImpl afterReturning Sortie de la méthode : saveAddress

page 2 de 2 -