-
Injection de logger avec CDI
Cette semaine, le projet Lombok a annoncé sa version 0.10 dans laquelle une nouvelle annotation @Log est annoncée. N’étant pas fan de ce projet, à cause de son coté trop magique, j’ai regardé ce qu’il fallait mettre en place pour faire quelque chose de similaire avec CDI. Plus précisément, j’ai voulu mettre en place le mécanisme d’injection pour obtenir un logger avec le moins de code possible.
L’idée n’est pas récente, puisque Seam 1 / 2 proposait déjà un mécanisme de ce type :
@Logger private Log log;
L’intérêt de CDI est de pouvoir choisir facilement l’utilitaire de Log et de ne dépendre d’aucune API non standard.
-
Découverte de Cloudbees
J’ai profité d’un passage en Suisse Romande pour assister à la réunion du 12 mai 2011 au JUG de Lausanne. Le sujet de la soirée était le plate-forme CloudBees, présentée par son fondateur, Sacha Labourey. Et bien que j’aie raté le début de la présentation, je dois dire que j’ai été convaincu par la pertinence de l’offre et par la vision de Sacha sur les services dans le nuage à apporter aux développeurs. J’ai donc fait un essai pour mieux comprendre le contenu de l’offre.
Ce billet retranscrit mon ressenti suite à la présentation et à mes premiers essais. Pour une vision plus large des solutions de développement dans le nuage, je vous renverrais vers le très bon article de Kalistic sur le sujet.
-
Mots de passe chiffrés pour les datasources de JBoss
Dans JBoss, les datasources sont configurées dans des fichiers XML qui contiennent les paramètres de connexion et la configuration du pool.
Parmi les paramètres de connexion, on trouve le nom d’utilisateur et le mot de passe, en clair…
<local-tx-datasource> <jndi-name>SewaDS</jndi-name> <connection-url>jdbc:derby://localhost:1527/sewadb</connection-url> <driver-class>org.apache.derby.jdbc.ClientDriver</driver-class> <user-name>sewatech</user-name> <password>sewapwd</password> <local-tx-datasource>
Évidemment, ce mot de passe en clair n’est pas la panacée et déclenchera une levée de bouclier au prochain audit de sécurité.
Il existe plusieurs techniques pour chiffrer le mot de passe. Je vais parler ici de la technique du SecureIdentityLoginModule, qui, si elle n’est pas la plus sécurisée, est simple et rapide à mettre en place. Si je veux en parler ici, c’est que malgré sa simplicité, je suis tombé récemment dans un vilain piège.
-
JUnit Runner pour CDI / Weld
Dans mon billet précédent, j’ai proposé d’utiliser un Rule pour tester des composants CDI. Cette technique n’est pas totalement satisfaisante, d’une part parce que l’initialisation se fait pour chaque test et d’autre part parce que son utilisation demande un peu de code. J’ai donc décidé de changer de tactique et développer un Runner.
Pour ce Runner, j’ai fait une classe qui hérite du runner par défaut et j’ai redéfini la méthode run() pour démarrer et arrêter Weld. J’ai redéfini aussi la méthode createTest() afin qu’elle retourne une instance gérée par Weld de la classe de test. Ceci permet d’injecter les objets à tester et donc de réduire sensiblement la quantité de code.
-
JUnit Rule pour CDI / Weld
Arquillian est l’outil poussé en avant par les équipes de JBoss pour le tests des composants JavaEE. Je trouve que pour certains tests CDI, cet outil ressemble à de la grosse artillerie et qu’on peut se débrouiller avantageusement sans elle.
Les techniques de Rule de JUnit permettent de faire les initialisations nécessaires avec WeldSE, à condition peut-être d’avoir les bons Scopes.