Bonne Année 2008 !

Je vous souhaite une excellente année 2008 !

Avec cette nouvelle année, quelques bonnes résolutions à prendre pour faire vivre ce blog avec des billets un peu plus fréquent de mon coté ... des commentaires un peu plus nombreux également pour alimenter le débat qu'il soit technique ou écologique !

Laurent

OGM = moins de pesticides ???

Un argument des industriels commercialisant les semences OGM est de dire qu'avec les OGM, les agriculteurs vont consommer moins de pesticides. Qu'en est-il exactement ?

La réponse est en fait loin d'être aussi simpliste. Pour la communication, les industriels ont avantage à simplifier le discours et rester dans des généralités pour mieux défendre leurs intérêts. Si on creuse un peu, on s'aperçoit que ce discours est biaisé ...

De manière générale, les OGM dit "à pesticides*" représentent plus de 99% des OGM à travers le monde. Il en existe de 2 sortes :

• ceux qui résistent à un pesticide (le fameux "Soja RR - RoundUp Ready" en est un exemple). Ils représentent environ les 3/4 des OGM dans le monde.
  
• ceux qui sécrètent un pesticide et fait que la plante devient "poison" pour l'animal ravageur (le maïs MON810 cultivé en France). Ils représentent pas loin du 1/4 des OGM dans le monde.
  

Dans le premier cas, la raison d'être de l'OGM est de résister à un pesticide afin, par exemple, de pulvériser sur un champ un herbicide systémique comme le RoundUp. Dans ce cas, je vois mal comment l'argument "OGM = moins de pesticides" peut se justifier. De plus, dans les pays où ce type d'OGM est utilisé, on voit la vente des pesticides augmenter de manière plus importante que l'utilisation des OGM. Les plantes génèrent des résistances impliquant l'augmentation tous les ans des doses de pesticides utilisés.

Dans le second cas, celui du maïs BT MON 810 cultivé en France, c'est plus délicat. Effectivement, les agriculteurs utilisant habituellement un insecticide à base de toxine BT n'ont plus besoin d'utiliser ce traitement puisque la plante le secrète elle-même. Mais ce n'est pas parce que l'agriculteur ne traite pas
qu'il n'y a pas d'insecticide dans la nature ... Bien au contraire, les insectes visés (pyrale et autres lepidoptères) sont soumis en permanence à cet insecticide, leur permettant ainsi de générer des résistances ... Je ne parle même pas de nos productions de viandes et lait à partir de vaches qui ingurgitent ces OGM ...

On voit donc que l'argument "OGM = moins de pesticides" ne tient pas la route. Je dirais même que c'est de la propagande. J'ai récemment vu un reportage sur une chaîne publique où l'agriculteur cultivant des OGM se disait même écologiste ...

Dès qu'il s'agit de gagner de l'argent à court terme, l'environnement et nos vies ne valent pas grand chose ...

A nous de réagir en refusant d'acheter des produits touchant de près ou de loin les OGM. En Bretagne, on peut utiliser le site Consommer sans OGM en Bretagne. Sinon, il faut se replier derrière des labels (BIO, Label Rouge notamment).


*Pesticide est un terme générique dans lequel on englobe les herbicides, fongicides, insecticides

Gutsy Gibbon ... C'est parti

Ca y est, la dernière mouture Ubuntu 7.10 est sortie.

Une news que j'imagine vous avez vu fleurir un peu partout sur le Net.

Le download est déjà fait de mon coté ... et je grille une galette pour y poser l'ISO !
Un petit rappel, le torrent est très utile pour éviter l'engorgement des serveurs Ubuntu ...

J'ai également commandé les CDs (en 2 ex.) pour faire du lobbying !
Vous aussi, vous pouvez les commander pour que les CDs arrivent dans votre boîte aux lettres. C'est gratuit et sur le site officiel. Il faut juste être un petit peu patient (4 à 6 semaines).

Tutoriel JAX-WS - Partie IV (Spring)

Quatrième partie de la série "Tutoriel JAX-WS" : Intégration de Spring avec Metro. Cette partie est destinée à des personnes connaissant un minimum Spring. L'objectif est d'utiliser Spring pour configurer le déploiement du Web Service en lieu et place du fichier sun-jaxws.xml.
Ceci est intéressant si vous avez déjà Spring sur votre projet. Dans ce cas, on aura alors accès à tous les bienfaits de Spring pour configurer notre service : AOP, injection de dépendance, ...

Intégration de Spring au projet

Avant de pouvoir utiliser Spring, il faut d'abord l'intégrer à notre application. Pour ceux qui veulent un lien, la dernière version (2.0.7) est ici (prenez la version avec les dépendances).
On va faire simple et mettre le fichier spring.jar (dans le répertoire dist de la distribution Spring) dans le répertoire WEB-INF/lib de notre projet.

Au niveau dépendances, nous allons faire simple également. On se limitera à copier le fichier commons-logging.jar (du répertoire lib/jakarta-commons de la distribution Spring) dans notre répertoire WEB-INF/lib.

Nous en avons terminé avec l'intégration de spring. Maintenant, nous allons ajouter une extension pour combiner JAX-WS et Spring.

Intégration de l'extension JAX-WS-spring

Il existe une extension JAX-WS (dans les projets JAX-WS commons) qui permet de configurer nos services Web avec Spring. Vous la trouverez ici. Elle reste malheureusement assez peu documentée ...

Cette librairie à intégrer dans notre webapp (répertoire WEB-INF/lib) se nomme jaxws-spring-1.7.jar. Seule cette librairie ne suffira pas. Il nous faut ajouter une librairie externe permettant l'ajout d'extension spring : xbean-spring, détail important que je n'ai pas vu dans la documentation...

Nous sommes maintenant prêt à modifier notre configuration.

Descripteur de déploiement (fichier web.xml)

Nous allons ajouter le listener de Spring classique pour charger la configuration du (des) fichier(s) Spring :
Et changer de servlet pour en prendre une spécifique pour Spring :

Configuration Spring (fichier applicationContext.xml)

Il ne reste plus que la configuration Spring qui se fait dans le fichier WEB-INF/applicationContext.xml de la manière suivante :

Il ne vous reste plus qu'à redémarrer votre Tomcat et re-tester votre Web Service ...

Tutoriel JAX-WS - Partie III (Déploiement)

Voici la troisième partie de la série "Tutoriel JAX-WS". Cette dernière va nous permettre de déployer votre Web Service à l'aide de Metro.

Descripteur de déploiement (web.xml)

Globalement, ce dont on a besoin, c'est d'exposer notre Web Service sur une URL donnée. Metro met à disposition une servlet pour le "routage" des appels clients vers les services Web. On va donc indiquer ce qu'il faut à notre container Web (Tomcat) pour cette servlet dans le fichier WEB-INF/web.xml :
Le pattern utilisé pour l'URL d'accès à la servlet permet d'intercepter toutes les URLs commençant par /services/. Ceci nous permet de déployer plusieurs Web Services.

Il manque encore l'information de mapping entre l'URL complète (appelé endpoint en Web Service) et notre classe d'implémentation. Metro utilise pour cela un fichier xml de configuration (WEB-INF/sun-jaxws.xml) qui est chargé par un listener. Nous devons donc également déclarer ce listener dans notre fichier web.xml.
Au final, voici à quoi doit ressembler notre descripteur de déploiement :


Configuration du endpoint (sun-jaxws.xml)

La configuration de notre Web Service sous Metro se fait donc dans le fichier WEB-INF/sun-jaxws.xml. L'ensemble des endpoints doivent se retrouver dans ce fichier. Voici celui qui correspond à notre cas d'école :


Configuration de Tomcat

Si vous utilisez le JDK 6, vous allez être confronté au même souci de conflit de version de JAX-WS. Par défaut, Eclipse lance Tomcat avec l'option : -Djava.endorsed.dirs="/chemin_de_tomcat6/common/endorsed"
Il suffit donc de copier la librairie webservices-api.jar de Metro ou les librairies jaxws-api.jar/jaxb-api.jar de JAX-WS RI (ce qui est équivalent) dans le répertoire défini ci-dessus.

Test du Web Service

Voilà, vous êtes maintenant prêt à lancer Tomcat et tester votre Web Service. Si vous avez tout suivi, l'URL d'accès à votre Web Service (endpoint) sera :
http://localhost:8080/testMetro/services/addnumbers
Vous devriez avoir quelque chose du genre :


Pour faire des tests complets, vous pouvez utiliser un outil comme soapUI ou celui fourni avec Eclipse (un peu plus lourd à mon goût).

N'hésitez pas à laisser des commentaires si vous avez des questions ...

Tutoriel JAX-WS - Partie II (Développement)

Voici la seconde partie de la série "Tutoriel JAX-WS". Celle-ci est consacrée au développement à proprement parlé du Web Service. On va commencer par importer un WSDL d'exemple. Par la suite, on va générer du code avec les outils de JAX-WS. Enfin, on terminera par l'implémentation du service à proprement parler.

Import du WSDL

La configuration n'es pas complètement terminée mais on peut commencer à coder notre Web Service. Dans notre cas d'école, on va prendre un WSDL fourni avec les samples de Metro, plus précisément, le fichier samples/fromwsdl/etc/AddNumbers.wsdl. Nous allons importer ce fichier dans le répertoire src du projet. La copie d'écran suivante montre à quoi doit ressembler votre eclipse à ce stade :

Génération de code

Nous allons maintenant générer le code du service et des "artifacts" associées à partir du fichier WSDL. Je n'ai pas trouvé de plugin Eclipse pour Metro ou JAX-WS alors on va utiliser directement l'outil fourni avec l'implémentation JAX-WS (dans le Jar webservices-tools.jar). Pour cela, on va lancer l'utilitaire WSImport à partir d'eclipse.

A partir du menu Run/Open Run Dialog..., on va créer un nouveau "lanceur" de type Java Application. Vous pouvez lui donner un joli petit nom histoire de pouvoir le reconnaître par la suite. Ensuite, dans l'encart Main class et à l'aide du bouton Search, vous allez utiliser la classe com.sun.tools.ws.WsImport qui correspond à l'outil de génération de code. Vous devez avoir quelque chose du genre :

Il faut passer des infos à cet outil, notamment le fichier WSDL à prendre en entrée et lui dire à quel endroit mettre les fichiers générés. Toutes ces options sont documentées sur le site de JAX-WS. Attention, si vous avez des espaces dans les noms de répertoire (je pense aux personnes sous Windows avec le C:\Documents and Settings par exemple), veillez à mettre entre "" les options ...

Si vous utilisez le JDK 6+, vous allez être confronté à un problème de conflit de version entre l'API JAX-WS intégrée au JDK (version 2.0) et celle utilisée par Metro (Version 2.1). Le symptôme est le suivant :

You are running on JDK6 which comes with JAX-WS 2.0 API, but this tool requires JAX-WS 2.1 API. Use the endorsed standards override mechanism (http://java.sun.com/javase/6/docs/technotes/guides/standards/), or use -Xendorsed option.

Pour résoudre ce problème, il faut indiquer à la JVM où trouver la bonne version avec le mécanisme suggéré par le message d'erreur. Le screenhot suivant montre, en plus des options de génération de code, l'argument à passer à la JVM (les Jar jaxws-api.jar et jaxb-api.jar suffisent) :

Voici une explication rapide des options utilisées :

• -wsdllocation : JAX-WS utilise le WSDL au "runtime" et cette balise permet de mettre une annotation JAX-WS pour spécifier où trouver le WSDL. Dans notre exemple, c'est pour le retrouver dans notre projet dans le package par défaut. Par défaut, l'URL ou le chemin utilisé pour la génération de code est utilisé. Ne voulant pas mettre une dépendance avec ce lien dans mon code, je spécifie cette option.
• -verbose : Permet d'afficher ce que fait l'outil dans la console.
• -s : Donne le répertoire où mettre le code généré.
  

Cliquez sur le bouton Run et faîtes un Refresh sur votre projet. Les sources vont alors apparaître dans votre projet. Il ne nous reste plus qu'à implémenter notre classe de service. Une classe peut être supprimée, celle du client, à savoir AddNumbersService.

Implémentation du service

Une interface a été générée (org.example.duke.AddNumbersPortType). Nous allons l'implémenter. Pour cela, on créé une classe org.example.duke.AddNumbersServiceImpl qui implémente cette interface. On rajoute la décoration JAX-WS pour exposer cette classe sous forme de Web Service à l'aide de l'annotation @WebService avec en paramètre l'interface exposée : @WebService(endpointInterface="org.example.duke.AddNumbersPortType").
Il reste à ajouter du code dans nos méthodes et nous aurons terminé l'implémentation. Voici ce que cela peut donner :


Note : J'ai rencontré dans certain cas, des erreurs de compilation d'eclipse que je n'ai pas su expliquer. En redémarrant Eclipse, aidé d'un petit "clean", j'ai résolu le problème mais cela n'est quand même pas très "clean' ...

Nous avons terminé l'implémentation du service. Il reste maintenant à déployer notre Web Service sous Tomcat à l'aide de Metro. Ceci fera l'objet de la 3ème partie du tutoriel ...

Tutoriel JAX-WS - Partie I (Projet Eclipse)

Voici le premier article d'une série pour présenter l'utilisation de JAX-WS avec Metro, Tomcat 6, Eclipse 3.3 et le JDK 6.0.

Introduction

Le nombre de frameworks Web Services en Java EE est assez important avec, pour chacun, un historique plus ou moins lourd. On va retrouver des noms comme Axis (1 et 2), XFire, Apache CXF (pour Celtix XFire, considérée comme la V2 de XFire), JBossWS, ... Depuis quelques temps émerge un standard qui simplifie et uniformise le développement des Web Services en Java : JAX-WS.

Dans la suite de ce billet, on va créer un Web Service (Serveur et Client) avec JAX-WS sous Eclipse 3.3 / Tomcat 6.0 avec le JDK 6.0. Je profite de la sortie de la version 1.0 finale de Metro (Framework Sun Open Source incluant JAX-WS RI/ JAXB et Tango) pour ce mini-tutoriel. L'approche utilisée sera celle du "contract-first" (développement à partir du WSDL).

Pré-Requis

Avant de commencer, il vous faut installer tous les outils :

• Le dernier JDK 6.0 (si vous avez le 5.0, cela fera l'affaire également).
  
• Eclipse 3.3 avec WTP et touti quanti.
• Tomcat 6.0 (la version 5 ou 5.5 devrait également fonctionnée)
• Metro (qui inclut JAX-WS et JAXB)

On suppose que tout ces outils sont installés correctement et notamment que, dans Eclipse :

• Tomcat 6 a bien été configuré dans les runtimes de serveurs
  
• le JDK 6.0 est également le JDK par défaut.

Création et configuration d'un projet Eclipse

La première étape va être de créer un projet Web dynamique dans Eclipse.


Lors du "wizard" de création de projet, on veillera à choisir le Tomcat 6.0 avec les valeurs par défaut.

Eclipse créé alors le projet Web dans votre Workspace ainsi qu'une instance de configuration de serveur Tomcat 6 qui nous servira pour tester notre Web Service.

Configuration de notre WebApp avec Metro

Maintenant que nous avons notre WebApp, il va falloir qu'on ajoute les librairies de Metro. Pour cela, il suffit de copier les librairies de Metro (fichiers jar présent dans le répertoire lib de la distribution Metro) dans le répertoire du projet Eclipse WebContent/WEB-INF/lib.
Voici ce qu'indique la documentation Metro sur ces librairies :