Netapsys Blog

Web service REST avec JAXB. Simple vraiment ?

Jean-Baptiste Defard — Wed, 23 Feb 2011 14:48:00 +0100

Ce billet discute de la réalisation d'un web service REST avec JAXB dans le contexte d'un code existant. Dans ce cadre, REST/JAXB est elle la solution la plus simple ?

La mise en oeuvre de REST décrite ici et là est intéressante par sa simplicité et son économie. Je l'ai utilisée pour mettre en oeuvre un service de supervision très simple, juste une opération echo() :

public interface MonitorService
{
  String echo(final String valeur);
}

@Controller
@RequestMapping(value="/monitoring")
public class MonitorServiceImpl
implements MonitorService
{

    final private Logger log = LoggerFactory.getLogger(MonitorServiceImpl.class);

    @ResponseBody
    @RequestMapping(value = "/echo/{valeur}", method = RequestMethod.GET)
    public String echo(@PathVariable final String valeur)
    {
    	log.info("echo("+valeur+")");
    	if (valeur == null) {
    		return "NULL";
    	}
    	return valeur.toUpperCase();
    }
}

Avec les déclarations Spring suivante aux "bons endroits" : Dans le web.xml

<servlet>
  <servlet-name>monitor</servlet-name>
  <servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
  <load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
  <servlet-name>monitor</servlet-name>
  <url-pattern>/do/*</url-pattern>
</servlet-mapping>

Dans le fichier Spring monitor-servlet.xml de configuration de la servlet :

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
  <property name="messageConverters">
    <list>
       <bean class="org.springframework.http.converter.xml.Jaxb2RootElementHttpMessageConverter"/>
    </list>
  </property>
</bean>

<bean id="monitor.service.http"  class="org.netapsys.monitor.impl.MonitorServiceImpl"/>

Le tout est assemblé dans un war, puis déployé sur un serveur d'application.

Il ne reste plus qu'à écrire la partie cliente :

public class MonitoringClientImpl 
implements MonitorService
{
    private RestTemplate restTemplate  = null;
    
    private String urlServeur = StringUtils.EMPTY;

    @Override
    public String echo(final String valeur) {
        return getRestTemplate().getForObject(
                getUrlServeur() + "/do/monitoring/echo/{valeur}",
                String.class,
                reference);
    }
}

Avec le fichier Spring de configuration pour le test :

<bean id="monitor.client" class="org.netapsys.monitor.client.MonitoringClientImpl">
  <property name="restTemplate" ref="rstemp.rest.template"/>
  <property name="urlServeur" value="${rstemp.url}"/>
</bean>
<bean id="rstemp.rest.template" class="org.springframework.web.client.RestTemplate"/>
<!-- rstemp.url est une valeur substituée par un PropertyPlaceholderConfigurer -->

Et le code de test :

public class MonitorRestClientImplTest
extends AbstractSpringContexteTestNg
{

    private final String[] fichiersContextes = {"test-context.xml"};

    @BeforeClass
    public void chargerContexte()
    {
        chargerContexte(this.fichiersContextes);
    }

    @Test
    public void testHello()
    {
        final MonitorService service = (MonitorService) getBean("monitor.client");
        final String result = service.echo("hello");
        info(result);
        Assert.assertEquals(result, "HELLO");
    }
}

Malheureusement, le test échoue :

698 DEBUG RestTemplate(78): Created GET request for "http://localhost:8080/rstempx/do/monitoring/echo/hello"
700 DEBUG RestTemplate(520): Setting request Accept header to [text/plain, */*]
930  WARN RestTemplate(478): GET request for "http://localhost:8080/rstempx//do/monitoring/echo/hello" resulted in 406 (Not Acceptable); invoking error handler
FAILED: testHello
org.springframework.web.client.HttpClientErrorException: 406 Not Acceptable

La trace côté serveur confirme que l'invocation est bien reçue mais qu'il y a un problème dans le traitement :

904 DEBUG DispatcherServlet(693): DispatcherServlet with name 'monitor' processing GET request for [/rstempx//do/monitoring/echo/hello]
911 DEBUG DefaultAnnotationHandlerMapping(266): Matching patterns for request [/monitoring/echo/hello] are [/monitoring/echo/{valeur}]
913 DEBUG DefaultAnnotationHandlerMapping(290): URI Template variables for request [/monitoring/echo/hello] are {valeur=hello}
915 DEBUG DefaultAnnotationHandlerMapping(221): Mapping [/monitoring/echo/hello] to HandlerExecutionChain with handler [org.netapsys.monitor.impl.MonitorServiceImpl@3f3cbbbf] and 2 interceptors
919 DEBUG DispatcherServlet(769): Last-Modified value for [/rstempx//do/monitoring/echo/hello] is: -1
962 DEBUG HandlerMethodInvoker(173): Invoking request handler method: public java.lang.String org.netapsys.monitor.impl.MonitorServiceImpl.echo(java.lang.String)
962  INFO MonitorServiceImpl(51): echo(hello)
967 DEBUG AnnotationMethodHandlerExceptionResolver(132): Resolving exception from handler [org.netapsys.monitor.impl.MonitorServiceImpl@3f3cbbbf]: org.springframework.web.HttpMediaTypeNotAcceptableException: Could not find acceptable representation

Le problème est que la classe java.util.String n'est pas annotée avec JAXB, et plus précisement, qu'elle ne déclare pas l'annotation @XmlRootElement. Or, c'est une condition nécessaire pour que le convertisseur Jaxb2RootElementHttpMessageConverter fonctionne comme prévu. Une solution est de rajouter un convertisseur qui prend en charge les Strings. En modifiant la liste des convertisseurs côté serveur :

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
  <property name="messageConverters">
    <list>
	<bean class="org.springframework.http.converter.xml.Jaxb2RootElementHttpMessageConverter"/>
	<bean class="org.springframework.http.converter.StringHttpMessageConverter"/>
     </list>
  </property>
</bean>

Le test est en succès :

667 DEBUG RestTemplate(78): Created GET request for "http://localhost:8080/rstempx//do/monitoring/echo/hello"
668 DEBUG RestTemplate(520): Setting request Accept header to [text/plain, */*]
679 DEBUG RestTemplate(465): GET request for "http://localhost:8080/rstempx//do/monitoring/echo/hello" resulted in 200 (OK)
680 DEBUG RestTemplate(71): Reading [java.lang.String] as "text/plain" using [org.springframework.http.converter.StringHttpMessageConverter@49c4a5ec]
681  INFO SupportLoggingImpl(72): HELLO
PASSED: testHello

Par défaut, le bean AnnotationMethodHandlerAdapter est initialisé pour utiliser, entre autres, le convertisseur StringHttpMessageConverter. Dans le cas où l'on souhaite mettre en oeuvre un convertisseur qui n'est pas initialisé par défaut, ce qui est le cas du convertisseur JAXB, il faut également spécifier les convertisseurs par défaut (au besoin). Il n'y a pas à ma connaissance de possibilité de rajouter un convertisseur à ceux déjà utilisés lors de la déclaration du bean, car la propriété messageConverters est un tableau et non une collection.

En fait, comme la requète est simple, on peut tester la méthode directement avec un navigateur :

Au final dans mon cas, le résultat est correct. Cependant, on peut faire plusieurs remarques:

L'invocation de la méthode echo() n'utilise à aucun moment JAXB. La déclaration du convertisseur JAXB est inutile. Conséquence on peut se contenter dans ce cas du bean par défaut :

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter"/>

A contrario, si côté client, on attend une réponse sous la forme d'un fragment XML, le fait de retourner une chaine "brute" représente un cas particulier : parfois je retourne du XML, parfois non... De plus, comme Spring fournit un convertisseur pour les String, il n'y a pas de problème. Mais si l'on considère des opérations comme :

int getValue(final int v);
boolean getStatus(final boolean status);

les invocations de ces méthodes ne fonctionnent pas et l'erreur est du même type que précédement : 406 Not Acceptable.

Il existe plusieurs solutions :

1 Ecrire les convertisseurs pour tous les types utilisés dans les signatures des API.
2 Reformuler toutes les API pour n'utiliser que des classes annotées avec JAXB.
3 Utiliser un sérialiseur XML supportant les types simples.

La solution 1 présente l'inconvénient de ne pas répondre simplement à tous les cas, particulièrement dans le cas d'utilisation de collections dans les signatures de méthodes. J'ai choisi de ne pas l'explorer dans la suite de ce billet, car il ne me semble pas facile à généraliser.

Reformuler les API en utilisant JAXB

Ce n'est pas un problème en pratique, si l'utilisation des méthodes dans un contexte REST/JAXB est prévue lors de la conception de l'API. Au pire, il est toujours possible d'utiliser un Adaptateur au dessus de l'API existante. Par exemple l'utilisation de la classe ci-dessous permet de régler le cas des méthodes précédentes :

@XmlRootElement(name="response")
@XmlAccessorType(XmlAccessType.FIELD)
public class SimpleResponse<T> 
{
  @XmlElement(name="value")
  private T value;

  public SimpleResponse() {
    // empty
  }

  public SimpleResponse(final T v) {
    this.value = v;
  }

  public T getValue() {
    return this.value;
  }

  public void setValue(final T value) {
    this.value = value;
  }
}

La classe de service devient :

@Controller
@RequestMapping(value="/monitoring")
public class MonitorServiceImpl
implements MonitorService
{

  final private Logger log = LoggerFactory.getLogger(MonitorServiceImpl.class);

  @ResponseBody
  @RequestMapping(value = "/echo/{valeur}", method = RequestMethod.GET)
  public SimpleResponse<String> echo(@PathVariable final String valeur) {
    log.info("echo("+valeur+")");
    if (valeur == null) {
      return new SimpleResponse<String>("NULL");
    }
    return new SimpleResponse<String>(valeur.toUpperCase());
  }

  @ResponseBody
  @RequestMapping(value = "/value/{v}", method = RequestMethod.GET)
  public SimpleResponse<Integer> getValue(@PathVariable final int v) {
    log.info("value("+v+")");
    return new SimpleResponse<Integer>(v * 2);
  }

  @ResponseBody
  @RequestMapping(value = "/status/{status}", method = RequestMethod.GET)
  public SimpleResponse<Boolean> getStatus(@PathVariable final boolean status) {
    return new SimpleResponse<Boolean>(!status);
  }
}

Il faut aussi modifier le client :

public class MonitoringClientImpl 
implements MonitorService
{

  private RestTemplate restTemplate  = null;

  private String urlServeur = StringUtils.EMPTY;

  public SimpleResponse<Integer> getValue(int v) {
    return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/value/{v}",
        SimpleResponse.class,
        v);
  }

  public SimpleResponse<Boolean> getStatus(final boolean status) {
    return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/status/{status}",
        SimpleResponse.class,
        status);
  }

  public SimpleResponse<String> echo(final String reference) {
    return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/echo/{reference}",
        SimpleResponse.class,
        reference);
  }
}

Et enfin le test :

@Test
public void testEcho()() {
  final MonitorService service = (MonitorService) getBean("monitor.client");
  final String result = service.echo("hello").getValue();
  Assert.assertEquals(result, "HELLO");
}

@Test
public void testValue() {
  final MonitorService service = (MonitorService) getBean("monitor.client");
  final int result = service.getValue(21).getValue();
  Assert.assertEquals(result, 42);
}

@Test
public void testStatus() {
  final MonitorService service = (MonitorService) getBean("monitor.client");
  final boolean result = service.getStatus(true).getValue();
  Assert.assertEquals(result, false);
}

Cela devient plus compliqué lorsque les signatures des méthodes comportent des collections et que l'on ne peut pas radicalement modifier les contrats. C'est une situation fréquente dans le contexte de réalisation d'un web service au dessus d'un code existant que l'on ne souhaite pas modifier. Il faut écrire une classe dérivée d'XmlAdapter, et "saupoudrer" le tout d'annotations judicieusement choisies. En gros pour une méthode retournant une collection "simple" style Vector<Integer>, comme :

@ResponseBody
@RequestMapping(value = "/list/{base}", method = RequestMethod.GET)
public VectorIntegerResponse getList(@PathVariable int base) {
  log.info("list(" + base + ")");
  Vector<Integer> result = new Vector<Integer>();
  result.add(base);
  result.add(base * 2);
  result.add(base * 4);
  result.add(base * 8);
  return new VectorIntegerResponse(result);
}

Cela revient à écrire 3 classes :

@XmlAccessorType(XmlAccessType.FIELD)
@XmlRootElement(name = "VectorSupportInteger")
public class VectorSupportInteger 
{
    @XmlElement(name = "item", required = true)
    private final List<Integer> chunck = new ArrayList<Integer>();

    public List<Integer> getChunck() {
        return this.chunck;
    }
}

public class VectorIntegerAdaptor 
extends XmlAdapter<VectorSupportInteger,Vector<Integer>>
{
	@Override
	public Vector<Integer> unmarshal(VectorSupportInteger v) throws Exception {
        final Vector<Integer> result = new Vector<Integer>();
        for ( final Integer e : v.getChunck() ) {
            result.add(e);
        }
        return result;
	}

	@Override
	public VectorSupportInteger marshal(Vector<Integer> v) throws Exception {
		final VectorSupportInteger result = new VectorSupportInteger();
        for ( final Integer e : v) {
            result.getChunck().add(e);
        }
		return result;
	}
}

@XmlRootElement(name="response")
@XmlAccessorType(XmlAccessType.FIELD)
public class VectorIntegerResponse 
{

	@XmlJavaTypeAdapter(VectorIntegerAdaptor.class)
	private Vector<Integer> value;

	public VectorIntegerResponse()
	{
		// vide;
	}
	
	public VectorIntegerResponse(final Vector<Integer> v)
	{
		value = v;
	}
	
	public Vector<Integer> getValue() {
		return value;
	}

	public void setValue(final Vector<Integer> value) {
		this.value = value;
	}
}

Pour être complet voici le fragment XML résultant de l'invocation :

Il est possible de limiter le nombre de classes en utilisant la généricité de façon plus poussée, mais cela ne change pas vraiment la situation : pour un type Collection retourné par une méthode, il faut fournir 3 classes de support à la liaison avec JAXB. Partant de ce constat, les arguments des tenants d'une approche "schéma en premier" plutôt que "code en premier" commencent à prendre du sens. Dans une approche "schéma en premier", les classes d'adaptateurs sont générées à partir du schéma et par conséquent la complexité d'écriture est masquée. Dans l'approche "code en premier" précédente on utilise JAXB à l'envers. En pratique, dans un contexte de code existant et avec la motivation de ne pas "trop" faire évoluer les contrats d'interfaces, il n'est pas facile de faire autrement.

Mise en oeuvre d'un autre sérialiseur XML.

Pour diminuer la complexité induite par JAXB, le mieux est d'éviter de l'utiliser dans ce contexte. Une solution de remplacement est de mettre en oeuvre XStream pour la sérialisation/désérialisation des fragments XML. C'est assez facile à mettre en oeuvre car Spring fournit tout ce qu'il faut. On commence par rétablir les méthodes du service dans leurs versions originales :

@Controller
@RequestMapping(value="/monitoring")
public class MonitorServiceImpl
implements MonitorService
{

    final private Logger log = LoggerFactory.getLogger(MonitorServiceImpl.class);

    @ResponseBody
    @RequestMapping(value = "/echo/{valeur}", method = RequestMethod.GET)
    public String echo(@PathVariable final String valeur) {
    	log.info("echo("+valeur+")");
    	if (valeur == null) {
    		return "NULL";
    	}
    	return valeur.toUpperCase();
    }

    @ResponseBody
    @RequestMapping(value = "/value/{v}", method = RequestMethod.GET)
    public int getValue(@PathVariable final int v) {
    	log.info("value("+v+")");
    	return v * 2;
    }
    
    @ResponseBody
    @RequestMapping(value = "/status/{status}", method = RequestMethod.GET)
    public boolean getStatus(@PathVariable final boolean status) {
    	return !status;
    }
    
    @ResponseBody
    @RequestMapping(value = "/list/{base}", method = RequestMethod.GET)
    public Vector<Integer> getList(@PathVariable int base) {
    	log.info("list(" + base + ")");
    	Vector<Integer> result = new Vector<Integer>();
    	result.add(base);
    	result.add(base * 2);
    	result.add(base * 4);
    	result.add(base * 8);
    	return result;
    }
}

Ensuite, on déclare le bean XStream et on modifie la configuration de la servlet monitor pour qu'elle utilise le marshaller XStream :

<bean id="xml.xstream.marshaller" class="org.springframework.oxm.xstream.XStreamMarshaller"/>

<bean class="org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter">
  <property name="messageConverters">
    <list>
      <bean class="org.springframework.http.converter.xml.MarshallingHttpMessageConverter">
         <property name="marshaller" ref="xml.xstream.marshaller"/>
         <property name="unmarshaller" ref="xml.xstream.marshaller"/>
      </bean>
    </list>
  </property>
</bean>

<bean id="monitor.service.http"  class="org.netapsys.monitor.impl.MonitorServiceImpl"/>

Côté client, on modifie le RestTemplate de manière analogue :

<bean id="monitor.client" class="org.netapsys.monitor.client.MonitoringClientImpl">
  <property name="restTemplate" ref="rstemp.rest.template"/>
  <property name="urlServeur" value="${rstemp.url}"/>
</bean>

<bean id="rstemp.rest.template" class="org.springframework.web.client.RestTemplate">
  <property name="messageConverters">
    <list>
      <bean id="messageConverter" class="org.springframework.http.converter.xml.MarshallingHttpMessageConverter">
         <property name="marshaller" ref="xml.xstream.marshaller" />
         <property name="unmarshaller" ref="xml.xstream.marshaller" />
      </bean>
    </list>
  </property>
</bean>

Le code du client devient :

public class MonitoringClientImpl 
implements MonitorService
{
   private RestTemplate restTemplate  = null;
    
   private String urlServeur = StringUtils.EMPTY;

   public int getValue(int v) {
     return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/value/{v}",
        Integer.class,
        v);
   }

   public boolean getStatus(final boolean status) {
     return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/status/{status}",
        Boolean.class,
        status);
   }

   public String echo(final String reference) {
     return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/echo/{reference}",
        String.class,
        reference);
   }

   public Vector<Integer> getList(int base) {
     return getRestTemplate().getForObject(
        getUrlServeur() + "/do/monitoring/list/{base}",
        Vector.class,
        base);
   }

}

Enfin les résultats d'invocation :

http://localhost:8080/rstempx/do/monitoring/echo/Hello
résultat =>    <string>HELLO</string>
http://localhost:8080/rstempx/do/monitoring/value/21	  
résultat =>    <int>42</int>
http://localhost:8080/rstempx/do/monitoring/status/false   
résultat =>     <boolean>true</boolean>
http://localhost:8080/rstempx/do/monitoring/list/21
résultat =>
<vector>
  <int>21</int>
  <int>42</int>
  <int>84</int>
  <int>168</int>
</vector>

La solution demande moins de code et permet de respecter les contrats existants, comparativement à la solution utilisant JAXB, elle est beaucoup plus simple.

Conclusion

Si l'utilisation RestTemplate est une bonne solution pour écrire un web-service REST, JAXB ne rime pas toujours avec simplicité, surtout dans une approche "code en premier" avec du code hérité. Il me semble préférable dans ce cas d'utiliser un sérialiseur XStream pour le marshalling/unmarshalling des données. Il faut noter que la solution RestTemplate présentée n'a pas que des avantages par rapport à une solution JAXRS. Par exemple, elle ne permet pas de fournir un descriptif WADL des opérations utilisables.

Apache Camel - Transformation des données d'un fichier texte

Jean-Baptiste Defard — Sun, 13 Feb 2011 16:20:00 +0100

Une erreur d'appréciation fréquente concernant Apache Camel est de croire que son utilisation est réservée à des contextes client/serveur du style mise en oeuvre de Webservice, ou d'une messagerie JMS... Il est vrai que c'est pour ce genre de besoins que bien souvent on l'utilise la première fois. A l'usage, on découvre rapidement qu'il permet de faire beaucoup d'autres choses sympathiques.

Combien de fois ai-je écrit un bout de code qui lit un fichier de données et transforme celles-ci pour utilisation dans une application? En fait, je ne sais pas exactement, mais trop souvent, c'est certain, je l'avoue, C'est le genre de code que j'ai en de multiples exemplaires, quelque part, "juste quelques adaptations" (comprendre un bon copié/collé) et hop ! Voilà, c'est fait...

Pour commencer

Grâce au composant file et aux formats de données existants, l'utilisation de Camel fournit une solution plus concise. Par exemple, la lecture ligne par ligne d'un fichier texte et l'affichage du contenu dans les logs s'écrit avec la route:

from("file:/tmp/csv?noop=true&fileName=test.csv")
.split(body().tokenize("
"))
.log("ligne: ${body}").end();

Autrement dit : lire le fichier /tmp/csv/test.csv, éclater son contenu en morceaux en cherchant les fins de lignes, écrire le tout sur la sortie de log et c'est fini. Bon d'accord, il n'y a pas vraiment de traitement des données, mais cela reste une bonne base.

Utilisation du format Bindy

Apache Camel est plutôt bien outillé pour réaliser des transformations de données. Après un petit tour dans la documentation, je peux faire en sorte que Camel convertisse les lignes. Dans mon exemple, le fichier test.csv contient des valeurs séparées par des virgules :

nexistepas,com,2020-01-03,OWN-3121-4959
nomdomaine,fr,2013-11-14,OWN-4242-4431

Je modifie ma route pour insérer la conversion de chaque ligne en une liste de valeurs correspondant à chacune des colonnes :

from("file:/tmp/csv?noop=true&fileName=test.csv")
.split(body().tokenize("
"))
.log("ligne: ${body}")
.unmarshal().csv()
.log("colonnes: ${body}")
.end();

L'exécution de cette route avec le fichier de test donne comme résultat dans les logs :

21,737  INFO route1(212): ligne: nexistepas,com,2020-01-01,OWN-3121-4999
21,745  INFO route1(212): colonnes: [nexistepas, com, 2020-01-01, OWN-3121-4999]
21,746  INFO route1(212): ligne: nomdomaine,fr,2013-10-11,OWN-4413-4431
21,747  INFO route1(212): colonnes: [nomdomaine, fr, 2013-10-11, OWN-4413-4431]

On obtient bien une liste de String contenant les valeurs des colonnes. Il ne reste plus qu'à ajouter un bean de traitement qui utilise les valeurs. Par exemple :

public class InportSimple
{
    Logger log = LoggerFactory.getLogger(InportSimple.class);

    public void importer(final List<String> colonnes)
    {
        for( final String colonne: colonnes) {
            this.log.info("c:" + colonne);
        }
    }
}

Comme le bean ne contient qu'une seule méthode et n'a besoin de rien d'autre qu'un Logger, il est possible de le créer directement. Dans des cas plus complexes, Camel sait injecter le bean depuis Spring par exemple. De même, il pourrait implémenter Processor, ce qui a l'avantage de donner l'accès à l'objet Exchange courant. Pour la mise en oeuvre du bean, il faut modifier la route, qui devient :

from("file:/tmp/csv?noop=true&fileName=test.csv")
.split(body().tokenize("
"))
.log("ligne: ${body}")
.unmarshal().csv()
.log("colonnes: ${body}")
.bean(InportSimple.class)
.end();

La trace montre que l'on obtient bien le comportement attendu :

45,061  INFO route1(212): ligne: nexistepas,com,2020-01-01,OWN-3121-4999
45,067  INFO route1(212): colonnes: [nexistepas, com, 2020-01-01, OWN-3121-4999]
45,069  INFO InportSimple(27): c:nexistepas
45,069  INFO InportSimple(27): c:com
45,069  INFO InportSimple(27): c:2020-01-01
45,069  INFO InportSimple(27): c:OWN-3121-4999
45,071  INFO route1(212): ligne: nomdomaine,fr,2013-10-11,OWN-4413-4431
45,072  INFO route1(212): colonnes: [nomdomaine, fr, 2013-10-11, OWN-4413-4431]
45,073  INFO InportSimple(27): c:nomdomaine
45,073  INFO InportSimple(27): c:fr
45,073  INFO InportSimple(27): c:2013-10-11
45,073  INFO InportSimple(27): c:OWN-4413-4431

Il est possible d'améliorer cette solution pour obtenir directement la conversion d'une ligne en un objet. Dans le cas d'un fichier CSV, cela passe par l'utilisation du format de données Bindy. Après l'inclusion de l'artefact camel-bindy dans le classpath, il faut écrire un bean POJO correspondant aux colonnes. La liaison entre les données et les objets est spécifiée avec des annotations :

package org.netapsys.csv.descripteur;

import org.apache.camel.dataformat.bindy.annotation.CsvRecord;
import org.apache.camel.dataformat.bindy.annotation.DataField;

@CsvRecord(separator = ",", crlf = "UNIX")
public class Descripteur
{
    @DataField(pos = 1)
    private String nom = "";

    @DataField(pos = 2)
    private String zone = "";

    @DataField(pos = 3, pattern = "yyyy-MM-dd")
    private Date date = null;

    @DataField(pos = 4,required = false)
    private String titulaire = "";

    // Omission des accesseurs .../...

    // Juste pour faciliter la lecture des traces.
    @Override
    public String toString()
    {
        return "Descripteur [nom=" + getNom() + ", zone=" + getZone() + ", date=" + getDate()
                + ", titulaire=" + getTitulaire() + "]";
    }
}

Reste ensuite à modifier la route, pour demander la conversion :

from("file:/tmp/csv?noop=true&fileName=test.csv")
.split(body().tokenize("
"))
.log("ligne: ${body}")
.unmarshal().bindy(BindyType.Csv, "org.netapsys.csv.descripteur")
.bean(ImportBindy.class).end();

On utilise un autre bean pour traiter chaque objet car le format Bindy retourne une liste de dictionnaires d'objets :

public class ImportBindy
{
    Logger log = LoggerFactory.getLogger(ImportBindy.class);

    public void importer(final List<HashMap<String, Descripteur>> donnees)
    {
        for (final HashMap<String,Descripteur> dictionnaire : donnees) {
            for (final String cle : dictionnaire.keySet()) {
                    this.log.info("toString: " + dictionnaire.get(cle));
            }
        }
    }
}

La trace d'exécution permet de vérifier que c'est bien la méthode toString() de la classe Descripteur qui est finalement appelée :

55,250  INFO route1(212): ligne: nomdomaine,fr,2013-10-11,OWN-4413-4431
55,251 DEBUG BindyCsvDataFormat(178): Size of the record splitted : 4
55,251 DEBUG BindyCsvFactory(177): Pos : 1, Data : nomdomaine, Field type : class java.lang.String
55,251 DEBUG BindyCsvFactory(177): Pos : 2, Data : fr, Field type : class java.lang.String
55,252 DEBUG BindyCsvFactory(177): Pos : 3, Data : 2013-10-11, Field type : class java.util.Date
55,252 DEBUG BindyCsvFactory(177): Pos : 4, Data : OWN-4413-4431, Field type : class java.lang.String
55,252 DEBUG BindyCsvFactory(213): Counter mandatory fields : 0
55,252 DEBUG BindyCsvDataFormat(191): Graph of objects created : {org.netapsys.csv.descripteur.Descripteur=Descripteur [nom=nomdomaine, zone=fr, date=Fri Oct 11 00:00:00 CEST 2013, titulaire=OWN-4413-4431]}
55,253  INFO ImportBindy(30): toString: Descripteur [nom=nomdomaine, zone=fr, date=Fri Oct 11 00:00:00 CEST 2013, titulaire=OWN-4413-4431]

Le code présenté n'est qu'un exemple de ce qu'il est possible de réaliser avec Apache-Camel. Le même type d'approche est utilisable avec d'autre formats de données, et il existe d'autre approches envisageables pour la transformation, notamment l'utilisation du pattern Message Translator.

Le cas des gros fichiers.

A l'utilisation, le code précédent présente un défaut, qui n'apparaît que lors du traitement de "gros" fichiers. Dans ce cas, il est probable que l'on rencontre des erreurs de saturations mémoires. Par exemple, avec un fichier de 4 Mo environ, on obtient avec Java VisualVM le graphe mémoire suivant :

La consommation mémoire est beaucoup trop importante par rapport au traitement. C'est une conséquence de la façon dont le splitter fonctionne. Heureusement, il est possible de lire le fichier d'entrée par morceaux en mode "streaming". En ajoutant streaming() à la route :

from("file:/tmp/csv?noop=true&fileName=test.csv")
.split(body().tokenize("
"))((/public/memoire_camel/memory-csv-nostream.png|Evolution mémoire sans streaming|C))
.streaming()
.log("ligne: ${body}")
.unmarshal().bindy(BindyType.Csv, "org.netapsys.csv.descripteur")
.bean(ImportBindy.class).end();

Le graphe montre une diminution très significative de la mémoire :

Conclusion : l'utilisation du streaming est toujours préférable dès que le volume des données à traiter est un peu important. De plus, en mode streaming, la charge CPU est moindre car le gestionnaire mémoire est moins sollicité.

Apache Camel - Configuration des timeouts HTTP

Jean-Baptiste Defard — Tue, 18 Jan 2011 12:35:00 +0100

La mise en œuvre d'une requête HTTP avec Camel est assez simple. Après avoir ajouté le composant camel-http.jar au classpath, la route suivante fait une requête de recherche sur Google.

from("direct:start").
to("http://www.google.com/search?q=netapsys).to("mock:result");

Un simple appel dans un test Camel permet de s'assurer que tout s'exécute comme prévu :

@Test
public void test()
throws Exception
{
    this.template.sendBody("direct:start", null);
.../...
}

Le composant s'appuie sur la librairie commons-httpclient-3.x.jar pour l'implémentation. Pour la configuration des temporisations HTTP, un petit tour dans la documentation, montre qu'il existe (au moins) deux solutions :

Soit, on passe en paramètre la valeur du délai sur la route. Dans ce cas, la route précédente devient :

from("direct:start").
to("http://www.google.com/search?q=netapsys&httpClient.soTimeout=5000").to("mock:result");

Soit, on configure le composant directement en injectant un objet ClientConnectionManager correctement paramétré. Si, comme c'est mon cas, vous utilisez Spring comme registre Camel, il suffit de déclarer un bean correspondant au composant et de le paramétrer. Par analogie avec :

final MultiThreadedHttpConnectionManager connectionManager = new MultiThreadedHttpConnectionManager();
final HttpConnectionManagerParams params = connectionManager.getParams();
params.setConnectionTimeout(6000);
connectionManager.setParams(params);
HttpClient client = new HttpClient(connectionManager));

Cela revient dans un contexte Spring, aux déclarations :

<bean id="http.connection.manager.params"
	class="org.apache.commons.httpclient.params.HttpConnectionManagerParams">
    <property name="connectionTimeout" value="6000" />
    <property name="soTimeout" value="4000" />
</bean>

<bean id="http.composant" class="org.apache.camel.component.http.HttpComponent">
    <property name="httpConnectionManager">
	<bean
		class="org.apache.commons.httpclient.MultiThreadedHttpConnectionManager">
		<property name="params" ref="http.connection.manager.params" />
	</bean>
    </property>
</bean>

Il y a même plus court et surtout plus souple. La configuration précédente présente l'inconvénient de fixer les valeurs de temporisation pour l'ensemble des routes utilisant le composant HTTP. Pour une configuration "par route" à la demande, on peut utiliser le paramétrage par référence. Avec les déclarations Spring suivantes :

<bean id="clientConnectionManager2"
	class="org.apache.commons.httpclient.MultiThreadedHttpConnectionManager">
	<property name="params">
		<bean
			class="org.apache.commons.httpclient.params.HttpConnectionManagerParams">
			<property name="connectionTimeout" value="5000" />
			<property name="soTimeout" value="2000" />
		</bean>
	</property>
</bean>

<bean id="clientConnectionManager3"
	class="org.apache.commons.httpclient.MultiThreadedHttpConnectionManager">
	<property name="params">
		<bean
			class="org.apache.commons.httpclient.params.HttpConnectionManagerParams">
			<property name="connectionTimeout" value="10000" />
			<property name="soTimeout" value="12000" />
		</bean>
	</property>
</bean>

Il suffit de configurer les routes avec la référence du bean souhaité :

from("direct:start1").
to("http://www.google.com/search?q=netapsys&clientConnectionManager=#clientConnectionManager2").to("mock:result");

from("direct:start2").
to("http://www.google.com/search?q=netapsys&clientConnectionManager=#clientConnectionManager3").to("mock:result");

Il existe un composant Camel utilisant la version 4.x d'HttpClient que je n'ai pas encore eu l'occasion d'utiliser. La configuration doit être probablement légèrement différente.

Lightning pour Thunderbird 3.1.x sous Linux 64 bits.

Jean-Baptiste Defard — Mon, 17 Jan 2011 15:28:00 +0100

Suite à une mise à jour de Thunderbird (en version 3.1.7 chez moi), je n'ai plus accès à mes calendriers, car le composant Lightning refuse de se lancer. Après recherche, je n'ai pas trouvé une version toute prète du composant pour mon Ubuntu 64 bits. La solution restante et qui marche ;-) est de compiler le composant en local. Voila la procédure.

Installation des paquets nécessaires :

sudo apt-get build-dep thunderbird firefox
sudo apt-get install mercurial libasound2-dev libcurl4-openssl-dev libnotify-dev libiw-dev autoconf2.13 cvs
sudo apt-get install yasm mesa-common-dev

Récupération des sources :

mkdir mozilla
cd mozilla
hg clone http://hg.mozilla.org/releases/comm-1.9.2/ src
cd src
python client.py checkout

Dans le répertoire src, il faut créer le fichier .mozconfig avec le contenu suivant :

ac_add_options --enable-application=mail
ac_add_options --enable-calendar
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir-tb-release

Et enfin, construire la chose :

make -f client.mk

Après un bon café et un roulement de tambour, les binaires sont dans : src/objdir-tb-release/mozilla/dist Il ne reste plus qu'a installer les .xpi avec le gestionnaire de modules complémentaires de Thunderbird (Menu: /outil/modules complémentaires/ installer).

L'intégration continue au JUG de Tours

Jean-Baptiste Defard — Sat, 30 Aug 2008 12:17:00 +0200

Pour sa rentrée, le JUG de Tours organise le 10 septembre une soirée autour de l'intégration continue que j'aurai le plaisir d'animer. La présentation se veut très pratique et orientée retour d'expériences. Après un rappel des principes, je présenterai l'infrastructure d'intégration articulée autour d'Hudson que nous utilisons chez Netapsys. Une dernière partie traitera de l'intégration de Sonar comme un exemple de la contribution potentielle de l'environnement à la mise en oeuvre d'une démarche d'assurance qualité.

Si vous êtes intéressés par cette discussion, dans une ambiance détendue et conviviale, il ne vous reste plus qu'a vous inscrire ;-).

Nouvelle version de Sonar

Jean-Baptiste Defard — Mon, 09 Jun 2008 14:22:00 +0200

La version 1.3RC1 est sortie la semaine dernière. J'ai retardé la mise en production car dans l'infrastructure test la migration depuis la version 1.2.1 supprimait des mesures. Renseignement pris (merci Simon), il semblerait qu'il faille relancer une collecte pour que les mesures réapparaissent. Je suis vraiment très content de l'évolution du logiciel. Il s'améliore à chaque nouvelle version.

Les nouveautés :

Possibilité de déployer sous Tomcat
Détails des mesures par paquetage (très pratique :-))
Nouveaux ratios pour les commentaires et le code dupliqué
Amélioration des performances de l'ensemble

Pour les notes de releases c'est par ici. Un site de démonstration a été ouvert en même temps que la release de la 1.3RC1.

La prochaine version (1.3) devrait sortir au début du mois de juin et semble bien avancée.

Maven au ParisJUG

Jean-Baptiste Defard — Sun, 18 May 2008 12:19:00 +0200

J'ai assisté mardi soir dernier à la présentation, par Arnaud Heritier, de Maven au Paris JUG . C'était une présentation vraiment intéressante. Arnaud a répondu avec beaucoup d'intelligence et de gentillesse à un certain nombre de questions concernant la communauté, l'organisation des repositories, les plugins et l'avenir du projet. Il a présenté les principales nouveautés de la version 2.0.9 et l'actualité de la communauté.

Concernant les bonnes pratiques, des confirmations de ce que nous faisons déjà :

Utiliser Maven 2.0.9 sur lequel un gros travail d'amélioration a été réalisé, notamment en ce qui concerne la gestion des dépendances.
Eviter les mises à jour automatiques des plugins en déclarant les versions des plugins utilisés dans le POM.
Déclarer les versions des dépendances dans le POM parent et référencement dans les POM dérivés.
Même si Maven 2.0.9 améliore les choses, ne pas faire (trop ) confiance à la résolution des dépendances transitives.
Limiter l'utilisation des profils au strict minimum indispensable pour les configurations multi-environnements.

Pour la configuration des plugins de rapport, il faut placer la configuration par défaut dans la section <report> et éventuellement modifier cette configuration par défaut dans la section <build> d'un POM dérivé. Autre information intéressante, configurer les plugins de rapport dans la section <pluginManagement> ne sert à rien, car cette configuration est ignorée.

L'intégration à Eclipse devrait s'améliorer notablement d'ici à la fin de l'année. Eclipse prévoit d'intégrer dans ses distributions soit le plugin Q4e, soit le plugin m2Eclipse. Ces deux plugins sont actuellement en compétition pour l'intégration à Eclipse. Netbeans a, semble-t-il, un meilleur support de Maven 2.

En passant, j'ai bien apprécié la nouvelle fonctionnalité de Maven 2.0.9 permettant de modifier les dépendances d'un plugin. Vraiment pratique, par exemple pour utiliser AspectJ 1.6.0 avec le plugin maven.

En résumé, une bonne soirée au JUG et plein d'informations utiles pour améliorer les builds.

But Sierra 1, azimut 15, distance 3000...

Jean-Baptiste Defard — Sat, 26 Apr 2008 19:15:00 +0200

Contrairement à ce que pourrait laisser suggérer le titre, je n'ai pas l'intention de commenter le dernier techno-thriller maritime sorti en librairie... Sonar est un outil de suivi des indicateurs de qualité produits par des outils comme PMD, Checkstyle, Cobertura, JavaNCSS. C'est beau, c'est simple à installer et c'est facile à mettre en œuvre dans une intégration continue. Surtout, Sonar permet d'afficher et de comparer les évolutions chronologiques des indicateurs, sur autant de projets que l'on souhaite. Un superbe outil, à mon avis. L'équipe de développement a décidé de sortir une release environ tous les mois, la version 1.3 ne devrait donc plus tarder.