Avant de commencer l’année 2012, je vous propose un petit quiz adapté d’un cas réel.

Un programme standalone parse un fichier et insère les données parsées dans une base de données. Le même programme est exécuté dans trois régions différentes à savoir l’Europe, l’Amérique et l’Asie. Les entités persistées ont toutes un champ uid unique. La valeur de ce champ doit être sous la forme ‘E-1234′ ce qui est interprété comme l’enregistrement n° 1234 d’Europe. La base de données est la même pour les trois régions.

Lorsqu’on lance le programme dans les trois régions en parallèle, une exception est levée, laquelle et pourquoi est-elle levée ?

Lire la suite de cet article »

Dans un récent billet, je vous ai présenté JPDA afin de résoudre le problème d’envoi de mail à l’interception des exceptions levées dans une application legacy. Dans cette deuxième partie de la série, je vous propose de résoudre le même problème avec l’API Java Instrumentation.

Lire la suite de cet article »

Il y a quelques jours un ami a sollicité mon aide pour résoudre un problème peu commun. Il avait comme tâche de lever des alertes sur les exceptions levées par une application dont il ne peut modifier le code. L’application utilise mal l’API de log et ne loggue pas (toutes) les exceptions. De plus, elle est peu documentée et le peu qui existe est obsolète.

A chaque exception qui survient pendant l’exécution de l’application, il doit envoyer un mail d’alerte.

L’application est un programme JAVA standalone lancé via un script shell. Ci après les solutions auxquelles j’ai pensé :

1. Utiliser JPDA (Java Platform Debugger Architecture).
2. Utiliser l’api instrumentation de Java.
3. Utiliser de l’AOP.

Je vous propose dans cette série de trois articles de développer chacune de ces solutions.

Dans cette première partie, je vais explorer JPDA. Je commencerais par une brève introduction, avant de présenter la résolution du problème.

Lire la suite de cet article »

Cet article est le premier d’une série d’articles dont le but est de montrer aux lecteurs comment implémenter en Scala les différents design patterns connus.

Chaque article étudiera un ou plusieurs design patterns, rappellera la définition de chacun, et montrera les différences d’implémentation entre Scala et Java.

Je couvrirai dans cette série d’articles les 23 design patterns cités par le GOF et quelques autres design patterns propres à Scala et/ou provenant du monde de la programmation fonctionnelle.

Lire la suite de cet article »

SLF4J (Simple Logging Facade For Java) est une API d’abstraction de frameworks de log de plus en plus adoptée. Lorsque j’ai découvert cette API j’étais surtout fasciné par l’élégance des messages paramétrés utilisant des placeholders et par la simplicité de changement du framework de logging (juste en modifiant le classpath). La puissance de l’implémentation native Logback m’a fait adopter le couple SLF4J/Logback. J’ai aussitôt commencé à les utiliser sur mes nouveaux projets et à migrer ceux en cours vers SLF4J/Logback. Hélas le passage vers SLF4J et sa mise en place sur mes nouveaux projets n’a pas été exempt de surprises.

Dans cet article je vous présente deux problèmes parmi les nombreux que j’ai rencontrés: l’erreur de binding et la perte de log. Chaque problème sera accompagné d’un exemple de code. Mais avant cela je vous propose un petit rappel sur le fonctionnement de SLF4J.

Lire la suite de cet article »