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? Et ben, en fait, pour plusieurs raisons : J’ai toujours aimé la philosophie de LaTeX qui permettait d’écrire au kilomètre sans avoir à se soucier de la mise en forme.
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 n’a rien à voir avec le monde Java. Il s’agit plus d’un petit tutoriel surtout destiné… à moi-même… ;-) En effet, mon blog étant hébergé sur blogger, lorsque je rédige un article, je le fais le plus souvent directement en HTML. Afin d’avoir une idée de l’aperçu, je le charge directement dans mon navigateur mais passer son temps à faire du Alt-Tab/F5 a rapidement commencé à m’énerver.
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… ;-)
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.
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.
Pour ceux qui l’aurait loupé, le BreizhCamp dans sa version 2013 a actuellement lieu. Etant un grand amoureux de la Bretagne, je ne pouvais manquer le cru de cette année… En outre, j’ai eu la chance d’y présenter un Tools In Action d'1/2 heure sur le sujet des tests d’acceptance et plus précisément sur la façon dont il est possible d’intégrer Cucumber JVM, Selenium et FluentLenium. Les slides sont dès à présent disponibles :
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.
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.
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.
