Il y a déjà un long moment, j’avais posté une série d’article expliquant comment il était possible de faire des web service de type REST de manière simple via RestEasy-Netty ou via Undertow. Dans la continuité de cette course au plus léger, je me suis dit que cela pouvait être intéressant de faire une petite étude un peu plus exhaustive des solutions légères qui existaient. L’objectif étant extraire une sorte de bench un peu naïf et un peu out of the box.
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 ceux qui auraient manqué l’information, le BreizhCamp s’est déroulé en mai dernier et j’y avais la chance d’y présenter un talk sur un retour d’expérience concernant le passage à l’échelle d’un SI afin de lui permettre de supporter 4 millions d’utilisateurs. Le synopsis était le suivant : De 20 000 à 4 millions d’utilisateurs Pour ce faire, il a été nécessaire de revoir certaines parties du SI afin de pouvoir stocker en masse les données des utilisateurs mais également afin d’être capable de les traiter.
De nombreuses applications ou systèmes d’informations nécessitent le chargement de données issues de fichiers. Bien souvent, cet import est exécuté par batch, mais il peut aussi être intéressant de faire cet import au fil de l’eau. En outre, bien souvent, les fichiers à importer sont, soient nombreux, soient volumineux. Du coup, écrire un code simple et fiable peut devenir plus ardu que ce qu’il n’y parait. Si, de plus, on veut ajouter des logs parlant (c’est à dire avec, au minimum, le temps de traitement d’un fichier et son nom), cela a tendance a rajouter du bruit au code.
Cet article fera un rapide tour d’horizon sur les différentes stratégies qui peuvent être utilisées pour Logstash. Pour ce faire, je m’appuierai sur le très bon livre officiel que je me suis procuré (moyennant environ 10€) et qui fournit une très bonne vision sur ce qui est possible de faire ainsi que sur les différents concepts mais également sur les différentes stratégies de déploiement. Même si je résumerai succinctement quelques-uns des concepts afin que cet article soit un minimum compréhensible, cet article traitera surtout sur la façon dont il est possible de déployer les agents Logstash.
Comme certain ont pu le constater, le look & feel du blog a évolué et j’espère qu’il vous plait. Normalement, en plus d’un meilleur confort pour moi lorsque j’écris, une amélioration devrait être visible sur le temps de chargement des pages en raison d’un allègement de ces dernières. Cependant, 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…).
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é.
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.
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.
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é.
Ç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.
Ç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).
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).
Au cours de la vie d’un projet, il est courant d’avoir recours à des tests de charge. Cependant, je me suis rendu compte que, trop souvent, le sujet est mal maîtrisé et donc malheureusement mal traité. En effet, combien de fois n’ai-je pas vu un test de charge effectué avec la méthodologie “clic clic partout”, l’utilisation de Selenium, la commande curl, ou, dans le meilleur des cas, avec quelques scénarii JMeter issus de l’utilisation du recorder de ce dernier.
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?
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.
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.
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.
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.
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é.
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…
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. Parmi ces produits, on peut y trouver : Apache CXF (Fuse Service Framework) Apache ServiceMix (Fuse ESB) Apache ActiveMQ (Fuse Message Broker) Apache Camel (Fuse Mediation Router) En fait, si elle propose un package gratuit de ces différents produits, elle offre également un support ainsi que l’accompagnement aux personnes ou entreprises qui le souhaitent en offrant différentes formules.
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.
Ci-dessous se trouve une présentation que j’ai donné sur les problématiques liées aux architectures distribuées. Pour information, c’est un retour d’expérience d’une mission qui date un peu puisque c’était en 2007 mais les préconisations restent identiques à ce jour. Enjoy et n’hésitez pas à commenter ;-) Introduction sur les problématiques d'une architecture distribuée View more presentations from jetoile
Ci-dessous se trouve une présentation que j’ai donné sur un retour d’expérience sur Maven 2. Enjoy et n’hésitez pas à commenter ;-) Présentation sur Maven 2 et petit retour d'expérience View more presentations from jetoile
Voilà, pour ceux qui l’auraient manquée ou qui ne le savaient pas (ouh!!!), le JugSummerCamp a fermé ses portes ce vendredi 16 septembre 2011. Ce fut une journée bien remplie, fatigante mais que du bonheur : des sessions intéressantes, des speakers compétents mais également une super organisation (merci au Poitou-Charente Java User Group mais également à tous les sponsors de l’évènement sans qui rien n’aurait été possible… (on les oublie tout le temps… ;-) ))!
Cela fait un petit moment (plus d’un mois déjà…) qu’a eu lieu le BreizhCamp. Pour les néophytes, BreizhCamp est une journée de conférence sur diverses technologies allant de Python, en passant par .Net pour, finalement finir sur Java. Cette année, elle a eu lieu le vendredi 17 Juin à Rennes dans les locaux de l’ISTIC et a été organisée par l’équipe du BreizhJug qui comprend : Nicolas De loof, Michel David, Julien Coste.
Dans le cadre d’une problématique d’une usine logiciel, il peut s’avérer utile de posséder un patron ou template de projet qui fournit les “bonnes” pratiques que doivent respecter l’ensemble des applications du projet. Bien sûr, notre cher IDE est capable de générer un joli patron de projet. Cependant, il reste toujours nécessaire de modifier la configuration du projet pour y mettre, par exemple : la version de jdk, les libs utilisées (comme mockito par exemple), optionnellement, la configuration de plugins, optionnellemet, l’url du SCM, ou tout simplement, la référence à un projet parent qui permet de définir, par exemple, la version des librairies ou des plugins utilisés.
Cet article fait suite à mon article précédent afin de donner mon rapide retour d’expérience sur quelques écueils qui peuvent être commis lors de l’écriture d’un microBenchmark et dans lesquels je suis, bien sûr, tombé :(. Pour remettre dans le contexte, c’est l’écriture de ce benchmark qui a entrainé l’écriture de mon article précédent suite aux résultats que j’ai pu constater et pour lesquels j’ai eu l’aide de mes camarades.
Cet article fait suite à une petite discussion que j’ai eue récemment avec un collègue sur qui était le plus fort entre le for et le foreach. Question qui peut paraitre, au premier abord, stupide mais qui m’a fait pas mal me creuser les neurones sur des points qui n’ont pas grand chose à voir avec le problème initial… (mais là, je m’avance un peu sur mon article… ;-) ).
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.
Cet article fait suite à mon article précédent et a pour objectif de présenter un petit POC (Proof Of Concept) simplicime mettant en oeuvre JGroups en version 2.11.0.GA (la dernière version stable à ce jour). Le principe est de montrer comment il est possible d’utiliser JGroups pour permettre à plusieurs instances d’une même application de se partager les valeurs d’une donnée. Enfin, pour être plus précis, cet objet partagé ne le sera pas vraiment (ndlr : partagé) par toutes les instances mais il s’agira plutôt de permettre à chaque nouvelle instance de récupérer la valeur d’une donnée auprès des autres instance déjà présentes dans le système.
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.
Voilà, ça fait quelques jours que je travaille sur un petit projet perso. Aussi, afin de pouvoir le hoster, je me suis créé un compte sur GitHub : https://github.com/jetoile. Pour toutes informations sur Git, je vous renvoie sur le site : http://blog.gitfr.net/ De mon coté, je continue mon petit projet que je documenterai via de nouveaux articles d’ici peu. Rester à l’écoute ;-)
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.
Actuellement, le besoin de rendre les systèmes ou les applications interopérables est indéniable. Pour ce faire, de nombreuses technologies ont vues le jour. Il peut s’agir des MOM (Message-Oriented Middleware), des protocoles de communication entre les applications clientes et serveurs (REST, Soap, RMI, …), de solutions propriétaires utilisées pour permettre la communication entre les serveurs pour des problématiques de réplication ou de synchronisation ou même de solutions basées sur le paradigme NoSQL.
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.
Voilà! C’est la rentrée!… et c’est aussi la rentrée de tous les User Group : cela annonce une année bien chargée en conférences (et donc en émotion ;-) ) et il est probable qu’il y en ait pour tous les goûts! Donc plus aucune excuse pour ne pas trouver chaussure à son pied! A titre d’exemple, et pour n’en citer que quelques-unes (désolé pour celles que j’aurais oubliées mais il y en a trop et cela me prendrait trop de place pour toutes les mettre (ainsi que les logos)…), voilà un petit aperçu de ce qui nous attend en ce mois de septembre 2010 :
Ce petit article est plus une tranche de vie ayant pour objectif de montrer l'importance de savoir lire une documentation qu'un "vrai" post intéressant... Il est vrai que savoir trouver son information s’applique énormément dans le monde Open Source où il est crucial de savoir fouiller (documentation, forum, …) lorsqu’un fait technique (anomalie? framework incomplet? cas d’usage délirant? …) a lieu mais cela s’applique aussi dans notre vie de programmeur de tous les jours.
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?
J’ai déjà longuement parlé de maven 2 dans des posts précédents (Petites astuces avec maven 2, De l’art du livrable et Retour sur la mise en œuvre d’un environnement de développement). Ici, je vais revenir sur le plugin release en version 2.0 en explicitant ce que font ses goals prepare et perform plus concrètement. En effet, il peut être utile de vouloir savoir quels sont les actions appelées et comment il est possible d’y ajouter son petit grain de sel… ;-)
Lors d’un post précédent, j’avais parlé des EIPs (Enterprise Integration Patterns) en expliquant qu’il s’agissait de Patterns permettant de normaliser les échanges de messages dans un système asynchrone. Dans cet article, je vais tenter de présenter succinctement deux de ses implémentations : Spring Integration et [Apache Camel](https://camel.apache.org/. En fait, pour être plus précis, je vais plutôt tenter de présenter la vision que j’en ai ainsi que la façon dont je les ai compris.
Dans des posts précédents (ici et là), j’avais parlé d’une façon d’utiliser maven 2 pour fournir, entre autre, une solution pour accélérer le déploiement d’applications web avec Cargo. Cependant, afin d’optimiser le temps de développement, il est préférable, plutôt que d’avoir à redéployer l’application web à chaque modification de son contenu (que ce soit sa vue, son contrôleur ou son modèle) ou de ses librairies tierces (ce qui est connu pour être un anti-pattern), de n’avoir pas à le faire mais d’avoir plutôt un mécanisme permettant de prendre les modifications à chaud afin de pouvoir tester le plus rapidement possible.
Au cours de certaines missions, je suis arrivé à un constat qui était que le processus de génération d’un livrable était souvent délaissé au profit de l’effort de développement de l’application. C’est vrai qu’il peut être concevable qu’il ne s’agit que de la dernière étape d’un processus de développement, cependant, avec l’introduction de cycles courts (agilité, …), pouvoir fournir rapidement un livrable de qualité au client est primordial. Dans un post précédent, j’avais parler de la façon dont j’avais en place maven dans un processus d’usine logicielle.
Cet article présente la mise en œuvre que j’ai appliquée lors de la mise en place d’un environnement de développement devant s’interfacer, dans une démarche pseudo-agile, avec des outils d’intégration continue. Il présentera, dans un premier temps, le contexte et les problématiques puis, dans un second temps, comment j’ai tenté de répondre à ces problématiques que ce soit d’un point de vue méthodologique que d’un point de vue technique. Bien sûr, les choix et les implémentations utilisés sont discutables, mais c’est aussi pour cela que j’ai créé ce blog (afin de faire partager mon expérience et d’avoir un retour) ;-)
Voilà mon premier article. Il a pour objectif de présenter JBI (Java Business Service) aussi connue sous le doux nom de JSR 208 (Java Specification Release). Pourquoi un article sur JBI? Vous pouvez vous demander pourquoi un article sur JBI? Les réponses sont simples : j’aime bien cette spécification et je trouve qu’elle a du potentiel et qu’elle est sous exploitée. Bien sûr, me direz-vous, en tant qu’utilisateur d’un PEtALS ou ServiceMix, pourquoi devrais-je comprendre la technologie sous-jacente?
