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) ).

Jetty, Maven et JMX

Vous avez peut être remarqué que ces derniers temps, j'étais très Maven et JMX. Cet article ne déroge pas à la règle puisque je vais parler de... Maven et de JMX.

Enfin pour être plus précis, je vais montrer comment il est facilement possible de déployer une application web dans le conteneur embarqué Jetty via Maven en activant la couche JMX afin de pouvoir tester de manière intégrée cette couche.

Pour ce faire, je présenterai dans un premier temps le contexte, puis comment cela peut être mise en œuvre.

Bien sûr, cet article montre comment j'ai fait mais il ne représente pas la seule manière de faire... ;-). En outre, il ne présente rien de novateur mais je me suis dit que cela pouvait toujours être utile afin d'éviter de faire perdre du temps à d'autres personnes.

Pour les gouverner tous - partie 3/3

Cet article fait suite à mes précédents posts (ici et là) et à pour objectif d'intégrer la partie JMX à mon petit POC JGroups afin d'offrir une solution permettant de rendre complètement scalable la partie supervision/administration par JMX d'une application distribuée (ie. d'aggréger tous les MBeans au sein de tous les serveurs JMX). Pour rappel, le post précédent introduisait JGroups dans une petite application qui permettait à chaque instance d'une application d'obtenir la valeur d'une donnée offerte par les autres instances.

Pour les gouverner tous - partie 1/3

Pour ceux qui l'auraient manqués (comment ça? Personne ne me suit... :( ), j'ai annoncé dans un post précédent que j'avais ouvert un compte sur GitHub pour hoster du code. Bien sûr, il y avait une petite idée derrière... ;-)

En fait, l'idée est partie d'un constat assez simple : sur différent projet, à chaque fois que j'ai voulu mettre en place JMX, ce qui m'a toujours profondément attristé était de ne pas pouvoir regrouper l'ensemble des informations des MBeans à un même endroit, c'est-à-dire, qu'il me fallait me demander où se trouvait tel ou tel MBean dans mon système alors que j'aurais aimé pouvoir me connecter sur n'importe quelle instance de mon système et y trouver tous les MBeans présents dans mon système. Enfin, pour être plus précis, j'aurais aimé pouvoir me connecter à n'importe quelle JVM qui hébergeait mon application et avoir accès à tous les serveurs JMX.

Petites astuces avec JMX

Ce rapide article fournit un petit retour d'expérience de quelques galères que j'ai pu avoir avec JMX (Java Management eXtension), galères certes stupides mais qui pourront peut être servir à d'autres... ;-)
Sera donc abordé deux points :

1. Erreur lors de l'arrêt de tomcat configuré avec JMX
2. Impossibilité de se connecter à l'agent JMX

JMX pour les nuls... - Les connecteurs - Partie 8

Ce huitième et dernier article sur JMX clôture cette petite série de posts sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX, partie 4 sur les classes de base, partie 5 sur le MBeanServer, partie 6 sur le chargement dynamique des MBeans et partie 7 sur les services JMX). Il abordera succinctement la notion de connecteur.

JMX pour les nuls... - Les services JMX - Partie 7

Ce septième et avant dernier article sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX, partie 4 sur les classes de base, partie 5 sur le MBeanServer et partie 6 sur le chargement dynamique des MBeans) abordera les différents types de services JMX.

JMX pour les nuls... - Chargement dynamique de MBeans - Partie 6

Cet article toujours dans la lignée de ma petite série d'articles sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX, partie 4 sur les classes de base et partie 5 sur le MBeanServer) sera plus accès sur les capacités de chargement dynamique des MBeans. Cependant, il n'abordera que succinctement cette partie car il est nécessaire  d'avoir une très bonne connaissance du fonctionnement du classloader et qu'un simple article ne saurait l'aborder comme il se doit.

JMX pour les nuls... - Le MBean Server - Partie 5

Cet article reste dans la lignée de ma petite série d'articles sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification, partie 3 sur les agents JMX et partie 4 sur les classes de base) et portera sur le MBean Server.

JMX pour les nuls... - Les classes de base - Partie 4

Cette quatrième partie sur JMX (cf. introduction, partie 1 portant sur les généralités, partie 2 portant sur les différents MBeans et le concept de Notification et partie 3 sur les agents JMX) permettra de présenter les classes de bases de JMX c'est-à-dire les classes qui sont manipulées en interne par les API de JMX à savoir :

• ObjectName
• ObjectInstance
• Attribute
• AttributeList

JMX pour les nuls... - Les agents JMX - Partie 3

Cette troisième partie sur JMX reste dans la continuité de la série d'article sur ce sujet (cf. introduction, partie 1 portant sur les généralités et partie 2 portant sur les différents MBeans et le concept de Notification) en introduisant plus précisément ce qu'est un agent JMX et à quoi il sert.

Les articles qui feront suite préciseront les concepts manipulés par un agent JMX beaucoup plus en profondeur.

JMX pour les nuls... - Les différents MBeans et la notion de Notification - Partie 2

Mon précédent article portant sur la présentation générale de JMX a permis de poser les bases quant aux concepts fondamentaux. Cette seconde partie ainsi que les suivantes consistent en une descente plus en profondeur dans les entrailles des spécifications en reprenant les différentes notions vues précédemment. 

Ainsi, cette partie traitera des différents MBeans et du concept notification.

JMX pour les nuls... - Les concepts - Partie 1

Comme promis lors de mon article précédent (et pour éviter de vous faire languir ;-) ) la première partie de cette série d'article sur JMX!

JMX pour les nuls... - Introduction

Certains l'auront peut être remarqué mais cela fait un moment que je n'ai rien posté sur mon blog. En fait, j'ai été un peu occupé à faire quelque chose qui me tenait à coeur depuis un moment... : la lecture complète des spécifications JMX (ouais, ça va, on s'amuse comme on veut/peut... ;-) ). Du coup, je me suis dit que cela pouvait également intéresser d'autres personnes qui aurait pu être découragées par la version agrégée de la spécification (ie. contenant la JSR 3 - Java Management Extensions (JMX) Specification - en version 1.4 et la JSR 160 - Java Management Extensions (JMX) Remote API - en version 1.0) qui fait très exactement 290 pages et qui se veut être, à ce jour, la dernière en date.

JMX et Firewall

Cet article fait suite à mon post précédent qui, je le rappelle, pour ceux qui auraient eux le courage de le lire jusqu'à la fin ;-), avait pour objectif de rappeler en quoi JMX (Java Management eXtension) pouvait être une bonne réponse aux problématiques de supervision et d'administration dans une application (au sens large du terme). Cet article portera sur le sujet que je voulais initialement traiter, à savoir, comment accéder à un serveur JMX se trouvant derrière un Firewall. Cette problématique est indiquée sur le site de Sun/Oracle mais je vais, ici, faire un résumer de la méthode à suivre.

JMX ou comment administrer et superviser son système...

Je n'ai encore fait aucun article sur JMX (Java Management eXtension). Pourtant, je pense qu'il s'agit d'une technologie indispensable pour toute application qui se veut un minimum sérieuse et industrialisable. Dans ce post, je ne parlerai pas de "comment ça marche" ou je ne fournirai pas de tutoriaux. Il s'agit juste d'un petit coup de gueule parce que j'en ai marre d'entendre toujours les mêmes inepties sur JMX...

Bon, pourquoi JMX me direz-vous? Encore une technologie? Encore un nouveau truc dans mon architecture à mettre en œuvre sur lequel il va falloir faire monter des gens en compétence et qu'il va falloir maintenir?