jmx

Il y a quelques temps, j’avais fait une série d’articles sur resteasy-netty et resteasy-netty4. Cette article repart du même besoin, à savoir disposer d’une stack légère pour réaliser un service REST, mais en utilisant Undertow plutôt que Resteasy-Netty. Au niveau des besoins, ils seront identiques ie. : utiliser JAX-RS, intégrer Swagger, intégrer Jolokia, générer un livrable autoporteur. RestEasy-Netty, même s’il existe de nombreux points d’entrée, demande quelques phases de hack (gestion du crossover domain par exemple) et dispose d’un mécanisme un peu limité concernant la partie sécurité.

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

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.

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.

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

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… ;-) Seront donc abordés deux points : Erreur lors de l’arrêt de tomcat configuré avec JMX Impossibilité de se connecter à l’agent JMX Message d’erreur lors de l’arrêt d’Apache Tomcat? Cas d’usage Les options permettant d’activer JMX sur la JVM ont été passées via la variable JAVA_OPTS ou autre (via le catalina.

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.

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. Le MBean Server propose, par défaut, un ensemble de fonctionnalités qui se présente sous forme de services JMX (ie.

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.

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. Table des matières JMX, qu’est ce que c’est? Généralités Architecture JMX Niveau instrumentation Niveau agent Niveau service distribué Composants JMX MBeans Modèle de notifications Classe de métadonnées de MBeans Serveur de MBeans Service d’agents Spécifications JMX Instrumentation MBean MBean Standard Dynamic MBean Notification Open MBean Model MBean Agent JMX Concepts ObjectName ObjectInstance Attribute et AttributeList Les Exceptions MBean Server Chargement dynamique des MBeans Les services JMX Service Monitoring Service Timer Service Relation Service Sécurité Les Connecteurs MBean Server Le MBean Server est un annuaire de MBeans se trouvant dans l’agent JMX.

Cette quatrième partie sur JMX (cf. [introduction](/2010/10/jmx-pour-les-nuls-introduction.html, 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 Table des matières JMX, qu’est ce que c’est? Généralités Architecture JMX Niveau instrumentation Niveau agent Niveau service distribué Composants JMX MBeans Modèle de notifications Classe de métadonnées de MBeans Serveur de MBeans Service d’agents Spécifications JMX Instrumentation MBean MBean Standard Dynamic MBean Notification Open MBean Model MBean Agent JMX Concepts ObjectName ObjectInstance Attribute et AttributeList Les Exceptions MBean Server Chargement dynamique des MBeans Les services JMX Service Monitoring Service Timer Service Relation Service Sécurité Les Connecteurs ObjectName Un nom d’objet permet d’identifier un MBean dans le MBean Server de manière unique.

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. Table des matières JMX, qu’est ce que c’est?

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. Table des matières JMX, qu’est ce que c’est? Généralités Architecture JMX Niveau instrumentation Niveau agent Niveau service distribué Composants JMX MBeans Modèle de notifications Classe de métadonnées de MBeans Serveur de MBeans Service d’agents Spécifications JMX Instrumentation MBean MBean Standard Dynamic MBean Notification Open MBean Model MBean Agent JMX Concepts ObjectName ObjectInstance Attribute et AttributeList Les Exceptions MBean Server Chargement dynamique des MBeans Les services JMX Service Monitoring Service Timer Service Relation Service Sécurité Les Connecteurs MBean Un MBean est une classe java concrète qui :

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! Table des matières JMX, qu’est ce que c’est? Généralités Architecture JMX Niveau instrumentation Niveau agent Niveau service distribué Composants JMX MBeans Modèle de notifications Classe de métadonnées de MBeans Serveur de MBeans Service d’agents Spécifications JMX Instrumentation MBean MBean Standard Dynamic MBean Notification Open MBean Model MBean Agent JMX Concepts ObjectName ObjectInstance Attribute et AttributeList Les Exceptions MBean Server Chargement dynamique des MBeans Les services JMX Service Monitoring Service Timer Service Relation Service Sécurité Les Connecteurs JMX, qu’est ce que c’est?

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.

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.

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?