Ubuntu 11.04 est sorti depuis le 28 avril 2011. Je ne reviendrai pas ni sur son ergonomie ni sur ses ajouts puisque cela a déjà été débattu sur de nombreux sites/blogs. Cependant, depuis la mise à jour, un point avait tendance à m’agacer. En effet, dans un shell bash, sur la complétion de la commande ls (entre autre) avec des répertoires contenant des espaces, il ne m’échappait plus ces derniers.
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.
Cela fait un moment que je n’ai pas bloggé faute de temps mais également d’inspiration… (ça c’est dit et ça, on s’en fout d’un coté ;-) ) Cet article parlera des repository manager. Rien de nouveau à l’horizon puisque la problématique et les solutions existent depuis un moment mais ayant dû en mettre un en place récemment et au vu de nombreuses questions que l’on m’a posées, je vais ici coucher sur “papier” ce qu’est un repository manager, c’est à dire quelques uns de ses concepts clé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.
