Changement d'hébergeur

Cet article n'a rien à voir avec Java et il est plus à titre informatif.

En effet, j'ai décidé de passer de Blogger pour l'hébergement de mon blog à une solution basée sur Octopress et un hébergement sur github.io.

Pourquoi ce choix? Je vous invite à aller voir l'article qui en parle sur le "nouveau blog" ;-) .

Pour ceux qui accédait à ce blog par l'url http://blog.jetoile.fr, il n'y a rien de changé : le nom de domaine a été conservé et redirigé. Par contre, pour ceux qui y accédait de l'ancienne manière (à savoir http://jetoile.blogspot.com ou http://jetoile.blogspot.fr), si vous voulez accédez aux nouveaux articles, je vous invite à modifier vos bookmark pour pointer sur la nouvelle url...

En outre, le flux rss a subi un petit changement : en effet, en raison d'une limitation de feedburner sur la taille du fichier atom.xml, j'ai été obligé de ne faire pointer que la catégorie Java (je n'ai pas trouver comment il était possible de générer ce fichier avec seulement une partie de l'article ou juste le titre...).

Du coup, je vous invite à modifier vos lecteurs rss si vous en utilisez un pour pointer directement sur le nouveau flux :

• soit par celui de feedburner mais dans ce cas, il n'y aura que la catégorie Java : http://feeds.feedburner.com/jetoile ,
• soit en utilisant celui-ci : http://blog.jetoile.fr/atom.xml .

Je m'excuse par avance pour ce changement et j'espère que le nouveau blog vous plaira ;-)

Pour plus d'information sur les raisons qui m'ont poussé à changer ou pour avoir plus de détails, je vous invite à vous rendre sur ici.

Rendez vous sur le nouveau blog! ;-)

PS : pour info, même si je garde ce blog, il est fort probable que je ne le maintienne plus...

JAXRS, Netty4 et Spring Integration : ils reviennent et ils ne sont pas content!

Pour faire suite à mes articles resteasy-netty et resteasy-netty4, nous allons voir, dans cet article, comment il est possible de créer un service activator avec Spring Integration qui exposera via resteasy-netty4 un service REST.

Ce service REST esposera simplement une opération en POST qui, via Spring Integration, écrira dans un fichier et qui, pour le fun, écrira également sur la console.

Pour ce faire, rien de plus simple, un Service Activator de type gateway a été utilisé.

Cet article montrera donc comment il est possible d'intégrer Spring Integration à notre petite stack basé sur Resteasy-Netty4, Jackson, Metrics, Swagger et Jolokia.

Le code se trouve sur Github ici.

JAXRS, Netty 4, Jackon 2... les mêmes mais en mieux...

Pour faire suite à mon article précédent qui montrait comment il était possible de construire une stack légère basée sur Resteasy-Netty3, Jackson, Jolokia et Swagger, cet article montrera comment il est possible de faire la même chose avec Resteasy-Netty4 et Jackson 2.

Même si les changements ne sont pas énormes, il y a quand même quelques variantes, et, histoire d'être exhaustif, cela permet de faire le tour complet... ;-)

En fait, les seuls points qui diffèrent, par rapport au code précédent, touchent :

• les dépendances,
• l'intégration de Resteasy-netty4,
• l'intégration du JacksonConfig (changement d'API coté Jackson),
• le support de JodaTime dans Jackson 2,
• et le support du CORS dans Resteasy-Netty4.

C'est donc ces différents points qui seront abordés dans cet article.

Le code se trouve sur github sur la branche netty4.

JAXRS, Netty et bien plus encore... mode d'emploi...

L'informatique évolue constamment et c'est également le cas des architectures qui ont tendance à s'orienter de plus en plus vers l'utilisation de services REST. Ces services REST doivent, en outre, être de plus en plus véloces afin de pouvoir répondre à une charge de plus en plus forte (que ce soit d'un point de vue temps de réponse mais également d'un point de vue charge suportée). C'est dans ce contexte que des solutions comme Restlet ou RestX (pour n'en citer que quelques-unes) ont vu le jour.

En effet, en plus d'offrir la possibilité de servir des services REST, elles s'appuient sur des framework dont la particularité est d'offrir des traitements non bloquant sur les entrées/sorties (NIO).

C'est dans ce contexte que cet article parlera principalement de Resteasy-Netty 3 (la version 3 a été utilisé en raison de contraintes techniques (connexion à Apache Cassandra dont le driver utilise Netty 3)).

Cependant, ce ne sera pas le seul protagoniste car, comme on verra par la suite, il est très simple à utiliser...

Le vrai sujet de cet article est, en fait, comment il a été possible d'ajouter d'autres framework comme Swagger ou Jolokia à Resteasy-Netty 3.

Cet article sera découpé en deux parties :

• Besoin et conception
• Mise en oeuvre

Le code se trouve sur Github ici.

Jolokia : le piment qui vous veut du bien

Dans des articles précédents, je m'étais déjà exprimé sur le fait que je trouvais qu'il était important de monitorer son application (qu'il s'agisse d'une application web, d'un batch ou d'une application standalone) (cf. ici). J'avais même creusé un peu la spécification JMX (cf. là).

Pour faire suite à ce besoin, je vais, dans cet article, faire un focus sur un outils que j'ai découvert récemment (merci Romain ;-) ) mais qui existe depuis un moment (la version 1.0.0 est apparue en octobre 2011 sur le repo Maven central et le premier commit apparaissant sur Github date de Juillet 2010) : cet outils est Jolokia.

Comme à mon habitude, pour présenter cet outils, je m'appuierai sur la document officielle dans sa version courante, à savoir la 1.2.0.

Cependant, je ne ferai pas un plagiat exhaustif de la documentation qui est très complète (et surtout, je n'ai pas envie de me traduire les 92 pages de cette dernière... ;-) ) mais j'essaierai de faire un focus sur les points que je trouve les plus intéressants (à savoir les principes ainsi que le mode agent JVM (cf. plus tard) ).

Industrialiser la récolte de métriques Web

A l'origine, une des principales raisons à la mise en place d'un serveur d'intégration continue était l'automatisation des processus qui, fait manuellement, étaient souvent consommateur de temps et générateur d'erreurs humaines. Petit à petit, ce dernier s'est imposé comme l'orchestrateur de tous les processus et est devenu un des points central de l'usine de développement. En effet, en plus de ses capacités à compiler, packager, faire passer les tests unitaires, d'intégration et d'acceptance, il est souvent utilisé pour livrer mais également pour effectuer des tests de non régression.

Parmi ces tests de non regression, il est possible d'y inclure (en plus des classiques tests unitaires, d'intégration et d'acceptances) les tests de performances (JMeter, Gatling, Clif) et la remontée de métriques de qualité de code (PMD/CPD, Findbugs, Checkstyle, ou plus simplement Sonar).

Bien évidemment, récupérer des métriques sans les consolider ni les comparer avec l'historique est totalement inutile car cela n'offrirait aucune visibilité sur l'amélioration ou la dégradation du produit.

Ce petit laïus semble trivial pour ceux qui font du Java (enfin je l'espère... ;-) ). Cependant il l'est un peu moins dans le monde pur web (ie. lorsque l'on veut tester une couche pur front). Bien sûr, il y a Selenium & co mais cela ne permet de ne tester que le fonctionnel. En outre, en cherchant dans la littérature (pour rappel, je ne suis pas développeur front), on peut constater que, souvent, les outils utilisés pour obtenir des métriques sur la qualité de rendu d'une page ou le temps de chargement de ses différents composants sont souvent intégrés au navigateur du développeur et que, souvent, il est nécessaire de se faire des nœuds au cerveau pour les intégrer aux usines logicielles telles que celles dont l'écosystème Java a l'habitude.

Vous l'aurez compris, cet article a donc pour objectif de montrer comment il est possible d'intégrer tout ce beau monde...

Il se limitera cependant à la récupération de métriques sur la qualité de rendu d'une page ainsi qu'à son temps de chargement.

Dans un premier temps, cet article présentera donc comment il est possible de récupérer des métriques type YSlow ou Pagespeed (ie. une note globale sur la page) puis, dans un second temps, comment il est possible de récupérer des métriques sur le temps de chargement des pages. Enfin, pour faire le liant avec mes articles précédent, on verra comment il est possible de remonter et historiser ces métriques au travers un test d'acceptance.

Evidemment, l'objectif n'étant pas d'obtenir ces métriques de manière "one shot", une attention particulière sera portée sur l'intégration de ces outils à une usine logicielle et à leurs capacités à fournir une évolution dans le temps.

FluentLenium et Cucumber JVM... complément et precision

Dans mon article précédent, j'avais tenté d'expliquer comment il était possible d'intégrer les frameworks Cucumber JVM et Selenium au travers de FluentLenium.

En effet, pour rappel, FluentLenium permettait d'abstraire Selenium en lui offrant une API plus fluent mais également en lui apportant nativement ce qu'il préconise, à savoir le Page Object Design Pattern.

Pour ce faire, j'avais proposé d'utiliser la délégation de l'initialisation de FluentLenium à une classe tierce injectée via le mécanisme d'injection de Cucumber JVM.

Cependant, suite à discussion avec la créatrice de FluentLenium (à savoir Mathilde), on s'est rendu compte que l'axe utilisé était légèrement biaisé (même s'il fonctionnait...).

Cet article revient donc sur ce point en proposant une solution plus simple mais présentera également comment il est possible de tester le scénario Cucumber avec différents navigateurs et il y aura un petit mot sur l'utilisation de navigateurs déportés (via les RemoteWebDriver de Selenium 2).

Pour ce faire, il sera découpé en 3 parties qui couvriront des usecases différents se traduisant donc par des implémentations différentes :

• cas de tests pour un site simple,
• cas de tests pour un site complet,
• cas de tests multi-navigateurs pour un site complet.

A noter que je ne reviendrai pas sur les principes des différents frameworks/concepts mais juste sur comment il est possible d'implémenter ces différents usecases.

A noter également que l'article précédent aurait pu être modifié mais qu'en raison du nombre important de changements, il était plus simple d'en initier un autre...

FluentLenium et Cucumber JVM sont sur un bateau...

Dans un article précédent, j'avais abordé comment il était possible de démarrer une application web dans un conteneur de Servlet de manière embedded au sein de la phase integration de Maven. Bien sûr, cela n'a pas été fait que pour l'exercice de style et il y avait une petite idée derrière : pouvoir exécuter des tests d'acceptance en mode boite noire sur l'application.

Pour faire les tests d'acceptance, le choix de Cucumber JVM a été fait afin de permettre l'expression de tests d'acceptance avec une sémantique utilisant le pattern Given/When/Then mais également afin de permettre à des non développeurs de comprendre/écrire les scénarii de test à exécuter.

L'application à tester étant une application web, un besoin s'est fait sentir de tester la partie rendue. Dans cet article, lorsque l'on parlera de tester la partie rendue, il sera question de vérifier que l'élément recherché se trouve bien dans le document html remonté dans le navigateur web. Pour rappel (cf. le paragraphe Contexte de ce post), l'application testée s'appuie sur un framework web java de type Struts2.

Aussi, il ne sera pas question, ici, de tester le rendu dans différents navigateurs.

Il a été décidé de partir sur une solution s'appuyant sur un runtime à base de Selenium : en effet, un besoin latent étant, à terme, de tester le rendu de l'application web sur les différents navigateurs, cette solution semblait correspondre le mieux aux besoins.

Bref, passons ce besoin pour revenir à notre objectif premier, à savoir, vérifier la présence des éléments dans l'arbre DOM remonté par l'application web.

Pour résumer, il a été décidé de partir sur :

• Cucumber JVM pour la partie représentation/écriture des scénarii,
• Selenium pour la partie exécution des tests.

Cependant, la syntaxe sur la partie WebDriver de Selenium 2 étant assez verbeuse, il a été décidé d'utiliser le framework FluentLenium qui offre une API plus simple et plus naturelle (enfin plus fluent quoi! ;-) ). En outre, en plus d'une API plus facile d'utilisation, la notion native de Page de FluentLenium poussant à mieux découpler la représentation d'une page et son test, cela a joué en sa faveur ;-)

Ainsi, cet article présentera comment il a été possible d'intégrer Cucumber JVM avec FluentLenium afin de pouvoir faire tourner des tests avec Selenium.

A noter que je ne m'attarderai pas, dans cet article, à présenter exhaustivement les différents protagonistes mais seulement les quelques points qu'il est nécessaires de connaitre afin d'intégrer ensemble ces différents framework.

[update] Suite à discussion avec la créatrice de FluentLenium, un autre article a été initié et apporte de nombreux compléments mais également correction à cet article. Pour en savoir, plus, rendez vous ici...

Démarrer une webapp en mode embedded avec Maven

La mouvance actuelle dit que tout projet qui se veut un minimum industrialisé doit pouvoir détecter les anomalies au plus tôt. Pour ce faire, il est dit qu'il doit disposer de tests, qu'ils soient unitaire, d'intégration, fonctionnel ou d'acceptance.

 Pour adresser le problème des tests d'intégration, il est souvent utile de démarrer l'application cible de manière embedded. 

Cette article montrera comment il est possible de faire pour un contexte donné.

En outre, vu que ce blog me sert également d'aide mémoire, cela me donnera une excuse pour marquer noir sur blanc des informations que je peine toujours à retrouver... ;-)

Pour les habitués de ce blog (oui, je sais, cela fait un moment que je n'ai rien écrit... ;-) , le plan sera toujours le même : dans un premier temps, le contexte sera décrit puis des ébauches de solutions seront proposées jusqu'à tendre vers celle qui a été retenue.

Devoxx 2012 : Versionner son service dans une architecture SOA et/ou Cloud

Ça y est... Devoxx est fini... :'(

Comme je l'ai dit dans un article précédent, je ne ferai pas de compte-rendu exhaustif de présentations auxquelles j'ai pu assisté à Devoxx.

Cependant, je tenais à revenir sur la présentation "Service Versioning in SOA and Cloud" par Ignaz Wanders (@ignazw) dont le synopsis était :

Keeping versioning under control is essential in the success of a SOA. However, there are no industry standards for service versioning, thus leaving the responsibility of implementing a service versioning system up to the architects and developers within the IT enterprise.

We often see design-type versioning, resulting in Big Bang governance strategies. A runtime versioning strategy may be, in fact, be preferable.

Every change must be built, and every change must be governed. A "cheap" build may lead to a large governance impact. But conversely, a small governance cost may lead to a large build impact. Both build and governance costs need to be taken into account and carefully balanced when choosing and implementing a service versioning strategy.

Dans cet article, je me contenterai de montrer quelques-uns des slides de la présentation de Ignaz Wanders qui définissent et synthétisent très bien les différentes stratégies possibles en partant de comment numéroter ses services pour arriver à une proposition qu'il aimerait avoir du coté du consortium OASIS avec un WS-Versioning. Les slides étant suffisant en eux-mêmes et n'ayant pas envie de répéter/déformer leur contenu, je ne mettrai donc que les photos prises pendant la conférence...

D'ailleurs, une version pdf dont le contenu est similaire (identique?) est accessible ici.

Enjoy! ;-)

Devoxx 2012 : c'est fini...

Ça y est... Devoxx est fini... :'(

Pour ceux qui ne le sauraient pas encore, Devoxx est L’évènement à ne pas manquer.

Pour faire court, Devoxx est une conférence Java indépendante qui en est à sa 11ième édition et qui a lieu à Anvers (Belgique). Elle a également fait récemment de nombreux petits avec Devoxx France qui en est à sa 2ième édition et qui aura lieu cette année du 27 au 29 mars 2013 à Paris mais également avec le petit nouveau : Devoxx UK (du 25 au 26 mars 2013 à Londres).

Elle a regroupé cette année prêt de 3400 participants venant de tous les pays dont environ 200 français.

Précompiler ses jsp

Parce qu'il est parfois nécessaire de valider ses jsp, cet article fera un petit retour sur comment cela peut être mis en oeuvre.

Oui, je sais, les jsp c'est has been me diront certains... Cependant, il ne faut pas oublier que dans le monde Java, cela reste une des technologies indispensables quelle que soit le framework utilisé (j'entends par là dans le cas où les pages sont rendus dynamiquement par une technologie java).

Ayant eu récemment à intégrer une phase de validation des jsp maintenus principalement par des équipes "front" n'ayant que peu de connaissance en Java, ce rapide retour d'expérience tentera d'exposer les quelques points qui ont pu me poser problème et en l'occurrence les quelques-unes des différentes solutions possibles pour traiter ce point.

Aussi, dans une première partie, je présenterai le contexte, pour ensuite aborder trois des solutions possibles (et relativement récentes car il en existe plusieurs dans différentes versions...) pour valider les jsp.

Découpage de projets : projet vs. modules

Lorsqu'un projet débute, il est important (à mon avis) de se poser la question sur la façon dont celui-ci sera découpé. Pour être plus précis, il existe deux types d'approches :

• le découper fonctionnellement,
• le découper techniquement.

En outre, en plus de ce type de découpage, il est également important de s'interroger sur la façon dont il sera représenté dans le SCM : faut-il tout mettre dans le même projet (au sens SVN ou git du terme) en utilisant éventuellement des sous modules maven si c'est ce dernier qui est utilisé, ou faut-il en créer plusieurs?

C'est de ce dernier point dont il sera question dans ce court article qui présentera l'avis que j'ai pu me faire concernant le découpage technique du projet ie. s'il vaut mieux le découper en projets séparés ou en module (au sens maven du terme).

Maven : créer une branche - Mode d'emploi

Il y a un moment déjà, j'avais fait un article sur le plugin release oh combien pratique dans notre utilisation de maven. J'y avais mentionné les 2 goals prepare et perform qui sont les plus connus et qui, pour rappel, permettent de :

• vérifier que lors du lancement du processus de génération du livrable, le code est bien conforme à ce qui se trouve sur le SCM,
• tagger le code source à partir duquel le livrable est produit et permettant ainsi sa reproductivité,
• incrémenter le numéro de version des poms,
• générer le livrable,
• et le déployer sur le remote proxy repository.

Dans cet article, je me concentrerai sur un goal du plugin release malheureusement assez méconnu mais qui est tout aussi pratique et important (à mon sens) que ses 2 comparses prepare et perform. Il s'agit du plugin branch.

Devoxx 2012 - ElasticSearch : moteur de recherche NoSQL/REST/JSON taillé pour le cloud

Pour ceux qui l'aurait loupé, du 18 au 20 avril 2012 dernier a eu lieu la toute première édition de Devoxx France.

L'annonce avait été faite pendant la dernière édition de Devoxx "l'originale" à Anvers en Belgique qui fêtait pour l'occasion ses 10 ans.

Ayant eu l'opportunité d'y assister (chose que je conseille vivement à tous les développeurs), j'ai écrit un petit compte rendu d'une des moultes conférences qui m'ont marquées aussi bien par sa qualité scénique que par son contenu.

Cette conférence était une présentation d'ElasticSearch faite par David Pilato (@dadoonet) qui a, alors, abordé les points suivants :

• Définition d’un moteur de recherche
• Concepts d’ElasticSearch
• Utilisation d’ElasticSearch
• Architecture d’ElasticSearch

Ce petit compte rendu a été écrit pour le compte du site developpez.com et peut se trouver ici.

http://soat.developpez.com/articles/elasticsearch/

Merci à Developpez.com et aux différents relecteurs!
Bonne lecture ;-)

Petits retours sur Cassandra

Suite à de nombreuses présentations de Cassandra (faites, entre autre, par Michaël Figuière) et à une opportunité de regarder plus précisément ce qui se cachait réellement derrière cette implémentation d'une solution de la famille des produits NoSQL orienté colonnes, je vais, dans cet article, tenter de décrire ce que j'ai aimé et ce que je n'ai pas aimé sur Apache Cassandra.

Je tiens toutefois à préciser que je n'ai aucune expérience réelle sur le produit et que je ne m'appuierai donc que sur sa documentation officielle en version 1.0 qui date du 2 mars 2012.

En outre, je ne m'attarderai que sur les points qui m'ont semblé intéressants et marquants.

Pour ceux qui sont coutumiés de ce blog, je ne changerai pas mes habitudes et je me contenterai seulement de traduire de manière libre les passages qui m'ont intéressés ;-). A noter que de nombreux points sont rappelés à différents endroits dans ce document mais c'est également le cas dans la documentation officielle.

Petit focus sur 2 plugins Maven

Bon, ça fait un moment que je n'ai rien écrit... je n'ai pas foncièrement d'excuses si ce n'est que j'ai été pas mal occupé sur un projet sur lequel j'essaierai de faire un petit retour dans un futur proche...

En fait, dans ce rapide post, je tenais à faire partager 2 "petits" plugins maven que j'ai eu l'opportunité de découvrir récemment par le biais de 2 Olivier :

• Olivier Lamy (http://olamy.blogspot.com/), qui est architecte open source et commiteur actif de moultes projets (je ne les citerai pas, il y en a trop... ;-) ) et qui travaille chez Talend,
• et Olivier Bazoud (http://blog.bazoud.com/) qui est architecte chez Ekino et également co-auteur du livre Spring Batch In Action aux éditions Manning.

Les deux plugins sont les suivants :

• Tomcat 7 Maven Plugin
• Application Assembler Maven Plugin

En fait, je ne rentrerai pas en détail dans les 2 plugins Maven qui, pour un, est assez connu mais je me contenterai juste de décrire les fonctionnalités que j'ai appréciées.

N'étant pas expert sur ces derniers et n'ayant pas creusé dans tous les paramétrages, j'espère que la présentation qui suit ne dira pas trop de bêtises... ;-)

Devoxx 2011 - What's probably coming in Java Message Service 2.0

La semaine dernière, j'ai eu la chance d'aller à Devoxx en Belgique à Anvers.

Pour ceux, qui ne connaissent pas, je vous invite à aller directement à la pêche aux informations sur le site : http://www.devoxx.com/ et même à vous y inscrire l'année prochaine et/ou même mieux... d'aller assister à Devoxx France!!

Bon, sinon, pour revenir à nos moutons, cet article est un petit retour de la session de Nigel Deakin présentée à Devoxx 2011 et à laquelle j'ai assisté. 

Elle avait pour objectif de montrer l'avancée des travaux sur JMS 2.0 (Java Message Service) aussi connu sous le doux nom de JSR 343. A ce jour, en version early draft, elle devrait être intégrée à JEE7.

Cet article a donc pour vocation de tenter de retranscrire ce que nous a présenté Nigel.

Petite découverte de CloudBees

La semaine dernière, j'ai eu la chance d'assister à un atelier sur CloudBees chez nos amis de Xebia. 

Ce dernier a été organisé avec brio par (je le fais par ordre alphabétique pour éviter tout favoritisme ;-) ) :

• Eric Briand
• Simon Caplette
• Nicolas De Loof 
• Cyrille Leclerc
• Olivier Michallat
• Jean-Louis Rigau
• Emmanuel Servent 

Comme d'habitude, organisation bien rodée et atelier préparé aux petits oignons mais ce n'est pas le but de mon article...

L'objectif de cet article est, pour ceux qui n'étaient pas présents, de faire un rapide tour d'horizon de ce qui m'a marqué dans la solution qu'apporte Cloudbees avec ses offres DEV@Cloud et RUN@Cloud. Cet article sera surtout focalisé sur la partie usine logicielle offerte par Cloudbees car c'est celle qui a été mise en avant pendant l'atelier et c'est aussi celle qui me semble la plus intéressante du point de vue de mes besoins actuels.

Je vais donc essayer de vous résumer ce que j'ai apprécié... Pour ce faire, je ne reviendrai pas sur le usecase qui a été utilisé car je pense qu'il vaut mieux assister à l'atelier et qu'il faut bien laisser un peu de suspens... ;-). De même, je ne parlerai ni de l'intérêt du cloud ni de comment mettre en place DEV@Cloud ou RUN@Cloud.

Cet article s'articulera donc en deux parties :

• la première consistant en un très rapide retour sur ce que propose CloudBees,
• et la deuxième sur ce qui me plait dans une approche telle que celle proposée par CloudBees.

PS : au passage, encore un grand merci aux organisateurs de l'atelier!

FuseSource Community Day 2011

Ce jeudi 13 octobre dernier a eu lieu la troisième édition du FuseSource Community Day à la Défense.

Pour ceux qui ne connaissent pas la société FuseSource, il s'agit, en fait, du nouveau nom de Iona et c'est une société spécialisée dans l'open source qui propose un ensemble de produits packagés et intégrés de différentes solutions de la fondation Apache.